Contribute
Register

[Guide] Dell XPS 13 9360 on MacOS Sierra 10.12.x - LTS (Long-Term Support) Guide

Status
Not open for further replies.
the-darkvoid said:
1) CPU: i7-8550U

2) Both banks have a RAM chip with the following specs:
Code: 
Memory Device
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 8192 MB
    Form Factor: Row Of Chips
    Type: LPDDR3
    Type Detail: Synchronous Unbuffered (Unregistered)
    Speed: 2133 MT/s
    Manufacturer: SK Hynix
    Part Number: H9CCNNNCLGALAR-NVD
    Configured Clock Speed: 2133 MT/s
    Minimum Voltage: 1.25 V
    Maximum Voltage: 1.25 V
    Configured Voltage: 1.2 V

3) No
Click to expand...

Thanks. I've found a few ways to disable bootguard so modded BIOSes can be flashed, however (so far) they require a hardware SPI. In theory, we will be able to change the SPD# and voltage settings to get higher speeds and/or less voltage. That and of course a modded BIOS. Will need to investigate further to see if there is a software-only way to get there.

As to your other question; yes my native device-id is 8086:5916; however I thought that the 8th gen came with a different graphics chipset to the 620, though I may be wrong.
 
RehabMan said:
You will need FakeID and changes to FakePCIID_Intel_HD_Graphics for the 5917 (not native).
Click to expand...

RehabMan, good to see you around!

Made those changes already to FakePCIID_Intel_HD_Graphics. Let me collect all the necessary details as per error reporting, maybe you'll spot something I did not.


@jkbuha,

Note that my laptop already came with BIOS version 2.2.1. Also since its already running on 2133, I don't think there's a need for SPD modification on my BIOS. Are there any other motherboard / chipset comparisons you want to do to ensure that your hardware revision can indeed also support 2133 mhz?

Note that I had to drop ACPI table BGRT in order for mac OS not to crash immediately on boot. It looks like the table is broken as mentioned in http://wiki.osdev.org/Broken_UEFI_implementations#BGRT_Table

I'll try the new BIOS upgrade today (since mac OS isn't running yet anyways).
 
I think your memory timings are fine, esp when compared to the other boards that came out with 1867MHz modules.

The SPD modifications are for those boards that currently run on 1867 or below, such as mine. I have the same memory modules except that the timings are different. Enabling SPD write and/or XMP profiles should solve this issue.

Interestingly I didn't have the BGRT issue, but I did have to drop DVAR, xvh and MCFG tables on mine.
 
jkbuha said:
Thanks. I've found a few ways to disable bootguard so modded BIOSes can be flashed, however (so far) they require a hardware SPI. In theory, we will be able to change the SPD# and voltage settings to get higher speeds and/or less voltage. That and of course a modded BIOS. Will need to investigate further to see if there is a software-only way to get there.
Click to expand...

Can you explain how to prepare the rom for spi flash?
I have access to bth 9350 and 9360, so it could be nice to use a custom unlocked rom for my laptop
 
I was hoping you'd ask as I'm going to need some help to get this finalised :)

However you will need the following:
1) an SPI flash programmer with SOIC8 SOP8 adapter so you can read/write the Winbond chip without desoldering
2) an understanding of where the Winbond BIOS/ME 32MB chip lies on your board (and easy access to it)

The process is still manual, however these are the steps
1) Dump the whole chip via SPI to a rom/bin file.
2) Dump the descriptor part and load it into FITC
3) Enable reserve_hap=1 and save back into descriptor
4) That should disable secure boot but not bootguard. Thanks to 0xf56=0 we should be able to bypass the latter
5) Decompile BIOS (with the well known tool I won't mention here), add modded ROMs, re-compile
6) Flash modded chip back with SPI

I've managed to complete steps 2, 3, 4 and 5. I'm awaiting the SPI programmer this week and will be able to finish 1 and 6.
 
jkbuha said:
I was hoping you'd ask as I'm going to need some help to get this finalised :)

However you will need the following:
1) an SPI flash programmer with SOIC8 SOP8 adapter so you can read/write the Winbond chip without desoldering
2) an understanding of where the Winbond BIOS/ME 32MB chip lies on your board (and easy access to it)

The process is still manual, however these are the steps
1) Dump the whole chip via SPI to a rom/bin file.
2) Dump the descriptor part and load it into FITC
3) Enable reserve_hap=1 and save back into descriptor
4) That should disable secure boot but not bootguard. Thanks to 0xf56=0 we should be able to bypass the latter
5) Decompile BIOS (with the well known tool I won't mention here), add modded ROMs, re-compile
6) Flash modded chip back with SPI

I've managed to complete steps 2, 3, 4 and 5. I'm awaiting the SPI programmer this week and will be able to finish 1 and 6.
Click to expand...

Thanks for the info!

If you have a Raspberry Pi or Beagle Bone around, those can also flash the SPI. Save you a few bucks if you keep anything like that around the house.
 
jkbuha said:
I was hoping you'd ask as I'm going to need some help to get this finalised :)

However you will need the following:
1) an SPI flash programmer with SOIC8 SOP8 adapter so you can read/write the Winbond chip without desoldering
2) an understanding of where the Winbond BIOS/ME 32MB chip lies on your board (and easy access to it)

The process is still manual, however these are the steps
1) Dump the whole chip via SPI to a rom/bin file.
2) Dump the descriptor part and load it into FITC
3) Enable reserve_hap=1 and save back into descriptor
4) That should disable secure boot but not bootguard. Thanks to 0xf56=0 we should be able to bypass the latter
5) Decompile BIOS (with the well known tool I won't mention here), add modded ROMs, re-compile
6) Flash modded chip back with SPI

I've managed to complete steps 2, 3, 4 and 5. I'm awaiting the SPI programmer this week and will be able to finish 1 and 6.
Click to expand...

Cool! I'm awaiting for new bios chips from ali to repair a broken 9350 board, so i'm gonna be able to test in week approx. Once done, I'll have replacement chips just in case of failure;)
Maybe there is a OTP region in the chip, which prevents overwrite after the first init? Like the servicetag on new motherboards shipped for RMA.
 
Intel UHD Graphics 620 works with AppleIntelKBLGraphics (on UHD display), it needs the following changes:

  • Addition in Rehabman's SSDT-IGPU hotpatch under LAPH section:
    Code: 
                // KabyLake/UHD620
            0x5917, 0, Package()
            {
                "AAPL,ig-platform-id", Buffer() { 0x00, 0x00, 0x16, 0x59 }, //UHD/QHD+
                "model", Buffer() { "Intel UHD Graphics 620" },
                "device-id", Buffer { 0x16, 0x59, 0x00, 0x00 },
                "hda-gfx", Buffer() { "onboard-1" },
            },
  • Addition in FakePCIID_Intel_HDGraphics.kext:
    Code: 
            <key>UHD620</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>org.rehabman.driver.FakePCIID</string>
            <key>FakeProperties</key>
            <dict>
                <key>RM,device-id</key>
                <data>FlkAAA==</data>
            </dict>
            <key>IOClass</key>
            <string>FakePCIID</string>
            <key>IOMatchCategory</key>
            <string>FakePCIID</string>
            <key>IOPCIClassMatch</key>
            <string>0x03000000&amp;0xff000000</string>
            <key>IOPCIPrimaryMatch</key>
            <string>0x59168086 0x59178086</string>
            <key>IOProbeScore</key>
            <integer>9001</integer>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
        </dict>
  • Framebuffer patch in Clover
    Code: 
                <dict>
                <key>Comment</key>
                <string>0x59160000, 80MB framebuffer 12MB cursor bytes (credit RehabMan)</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>AQMDAwAAIAIAAAAA</data>
                <key>Name</key>
                <string>com.apple.driver.AppleIntelKBLGraphicsFramebuffer</string>
                <key>Replace</key>
                <data>AQMDAwAAAAUAAMAA</data>
            </dict>
  • CoreDisplayFixup.kext and Lilu.kext in Clover kext folder
 
the-darkvoid said:
Intel UHD Graphics 620 works with AppleIntelKBLGraphics (on UHD display), it needs the following changes:

  • Addition in Rehabman's SSDT-IGPU hotpatch under LAPH section:
    Code: 
                // KabyLake/UHD620
            0x5917, 0, Package()
            {
                "AAPL,ig-platform-id", Buffer() { 0x00, 0x00, 0x16, 0x59 }, //UHD/QHD+
                "model", Buffer() { "Intel UHD Graphics 620" },
                "device-id", Buffer { 0x16, 0x59, 0x00, 0x00 },
                "hda-gfx", Buffer() { "onboard-1" },
            },
  • Addition in FakePCIID_Intel_HDGraphics.kext:
    Code: 
            <key>UHD620</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>org.rehabman.driver.FakePCIID</string>
            <key>FakeProperties</key>
            <dict>
                <key>RM,device-id</key>
                <data>FlkAAA==</data>
            </dict>
            <key>IOClass</key>
            <string>FakePCIID</string>
            <key>IOMatchCategory</key>
            <string>FakePCIID</string>
            <key>IOPCIClassMatch</key>
            <string>0x03000000&amp;0xff000000</string>
            <key>IOPCIPrimaryMatch</key>
            <string>0x59168086 0x59178086</string>
            <key>IOProbeScore</key>
            <integer>9001</integer>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
        </dict>
  • Framebuffer patch in Clover
    Code: 
                <dict>
                <key>Comment</key>
                <string>0x59160000, 80MB framebuffer 12MB cursor bytes (credit RehabMan)</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>AQMDAwAAIAIAAAAA</data>
                <key>Name</key>
                <string>com.apple.driver.AppleIntelKBLGraphicsFramebuffer</string>
                <key>Replace</key>
                <data>AQMDAwAAAAUAAMAA</data>
            </dict>
  • CoreDisplayFixup.kext and Lilu.kext in Clover kext folder
Click to expand...

This is actually Coffee Lake HD620, isn't it?

Note: I really need to do some work on SSDT-IGPU.dsl to allow for SKL-spoof vs. KBL native.
 
I thought it was Coffee Lake at first, but ark.intel.com says the following: "Products formerly Kaby Lake R"
While a comparable desktop processor for Coffee Lake shows "Products formerly Coffee Lake"

In the list of Intel Graphics Processors, the CPU is marked as Kaby Lake and the GPU device ID indicates as much: 0x59 series.

Notably, AppleIntelKBLGraphics.kext also supports 0x3E928086, which is the UHD Graphics 630, which is Coffee Lake based.
So in the end it looks like the driver for Coffee Lake based GPU's is still AppleIntelKBLGraphics.kext

Since my graphics card is 0x59178086 (Intel UHD Graphics 620), I thought 0x59168086 (Intel HD Graphics 620) would be closest. Clock rates min/max are identical across both devices for i5 and i7 versions.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top