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

[jkbuha]

Thanks. Could you post the IFR variable you used? That way all of us won't (semi-)brick our laptop.

The following two methods should unbrick your 9360:

1) Unplug battery, plug into mains power, press power for more than 60sec
2) Download latest (any) 9360 bios, rename to BIOS_IMG.rcv, place on FAT32 USB, insert into left port, press left arrow and insert power.

 

[TrustedDeveloper]

Hey all,
I installed OSX 10.13.4 on my Dell XPS 9360, and MacOS works well. However, I have three problems:

1. I lose Bluetooth after reboot and after sleep. I went back in the forum and read previous forum posts. I used DarkVoid's excellent Clover folder, which I have attached to this forum post. I also tried the commands below, but to no avail.

   sudo pmset -a hibernatemode 0
   sudo pmset -a standbydelay 90000

2. When I reboot on occasion, the keyboard doesn't work.
3. After rebooting, the headphone jack cuts out and sounds heavily distorted. If I use the --patch-hda option included in DarkVoid's folder it doesn't work at all.

I'm running BIOS version 2.6.2.

Any thoughts on how I can fix this?
Thanks!

 

[egore]

Battery menu bar status

Has the issue of battery status in the menu bar not updating been resolved? I understand it was suggested APFS and TRIM were contributing factors.

One thing I have noticed, every time I open the terminal app, the battery status (percentage and charger plugin status) appropriately updates to the correct values. This is repeatable. It seems launching terminal activates some sort of check and corrects the issue, once. The status remains stagnant until terminal is launched again.

Any ideas how to correct this? Debug files attached here. Thanks.

 

[RehabMan]

Battery menu bar status

Has the issue of battery status in the menu bar not updating been resolved? I understand it was suggested APFS and TRIM were contributing factors.

One thing I have noticed, every time I open the terminal app, the battery status (percentage and charger plugin status) appropriately updates to the correct values. This is repeatable. It seems launching terminal activates some sort of check and corrects the issue, once. The status remains stagnant until terminal is launched again.

Any ideas how to correct this? Debug files attached here. Thanks.

Your kextcache output proves kexts are not installed correctly.
All kexts you need must be installed to the system volume.
Read post #2 of the Clover guide for details:
https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/

Also, NVMe+APFS tends to cause boot delays, which causes problems for battery status. You can install on HFS+J instead or read here regarding abm_firstpolldelay:
https://www.tonymacx86.com/threads/readme-common-problems-in-10-13-high-sierra.233582/

 

[selfassembled]

Thanks. Could you post the IFR variable you used? That way all of us won't (semi-)brick our laptop.

The following two methods should unbrick your 9360:

1) Unplug battery, plug into mains power, press power for more than 60sec
2) Download latest (any) 9360 bios, rename to BIOS_IMG.rcv, place on FAT32 USB, insert into left port, press left arrow and insert power.

No it's well and truly bricked. I've tried every recovery method ever mentioned, including those. Which is part of my warning; I was under the impression that if I messed up I could always recover it, but apparently it's not always possible.

It was 0x6E8, Aperture size. My understanding is that the UHD 620 graphics limit themselves to a maximum of 1024MB of VRAM, but 2048MB is possible. I tried to set it to 2048. Before making this change, I had successfully enabled speed shift and rebooted just fine.

 

[jkbuha]

No it's well and truly bricked. I've tried every recovery method ever mentioned, including those. Which is part of my warning; I was under the impression that if I messed up I could always recover it, but apparently it's not always possible.

It was 0x6E8, Aperture size. My understanding is that the UHD 620 graphics limit themselves to a maximum of 1024MB of VRAM, but 2048MB is possible. I tried to set it to 2048. Before making this change, I had successfully enabled speed shift and rebooted just fine.

Ok folks, so this is a prime example as to why it's very important to follow the instructions carefully when modifying IFR variables, and also why we need a modded bios going forward, so we can modify variables in the safety of the watchdog timer (WDT), so if the BIOS POST detects an incorrect configuration the parameters are reset to a safe default.

0x6E8 (in all bios versions from 1.x to 2.6.2) does not refer to the internal HD620 card aperture size, but instead to the external Gfx card config (using eGPU for example). It's possible that modifying this parameter lead to disabling the display-connector parameters. This param was never referenced in this forum; the correct variable pair to be modified is the 0x785-0x786 combo (initial aperture size and max aperture size respectively). Indeed the OP makes reference to my post which recommends the correct variables to modify, ie 0x785-786.

Notwithstanding, you *still* will be able to recover, using my recommendations above. In the 9360/65/70 (not 9350) Dell wisely implemented a fail-safe (read-only) bootloader that first checks for a recovery situation before POSTing. Removing the battery and performing a hard reset with power depressed for 60sec, and/or inserting a BIOS recovery file with left-port left-key combo both will successfully recover your BIOS.

I should know, I've committed far greater sins on this laptop and it's always resurrected fine...

 

[necrodst]

Hello,

I don't know why I can't boot anymore on my Hackintosh 10.13.4 ... I use The Darkvoid CLOVER config files.
Everything was running perfectly until I restarted my computer yesterday.

I've got a loading wheel at the very end of the boot sequence (just before the login screen).
When I go to verbose mode I can see that this message is shown in loop :
gioscreenlockstate 3 hs 0 bs 0 now 0 sm 0x0 9360

I tried to see what files may have been modified in Single User Mode but without success..

Also, I couldn't boot anymore on the USB install key I used before to install... Such a very strange situation... I verified my BIOS settings, I didn't notice modifications :/

Hope you could bring me some help.

 

[RehabMan]

Hello,

I don't know why I can't boot anymore on my Hackintosh 10.13.4 ... I use The Darkvoid CLOVER config files.
Everything was running perfectly until I restarted my computer yesterday.

I've got a loading wheel at the very end of the boot sequence (just before the login screen).
When I go to verbose mode I can see that this message is shown in loop :
gioscreenlockstate 3 hs 0 bs 0 now 0 sm 0x0 9360

I tried to see what files may have been modified in Single User Mode but without success..

Also, I couldn't boot anymore on the USB install key I used before to install... Such a very strange situation... I verified my BIOS settings, I didn't notice modifications :/

Hope you could bring me some help.

You should try booting with invalid ig-platform-id (in case it is graphics related).

No "Problem Reporting" files attached.
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
Use the gen_debug.sh tool mentioned in the FAQ, that way it is less likely you'll omit something.

Also, please fix your profile as per FAQ (lacking important details such as screen resolution).

 

[selfassembled]

Ok folks, so this is a prime example as to why it's very important to follow the instructions carefully when modifying IFR variables, and also why we need a modded bios going forward, so we can modify variables in the safety of the watchdog timer (WDT), so if the BIOS POST detects an incorrect configuration the parameters are reset to a safe default.

Given that there is a rom chip, I'm unsure as to why recovery attempts didn't work. In any case, unlocking the bios is definitely an important problem.

I found this here (different bios)

To do it yourself, extract any module you want to unlock DECOMPRESSED. You should replace the 01 (bolded) with 00 so the BIOS thinks you're a consumer and you should have access to that menu/those settings. For example:


0x6014 Form: Advanced, Form ID: 0x1 {01 86 01 00 5C 00}
0x601A Suppress If: {0A 82}
0x601C 64 Bit Unsigned Int: 0x0 {45 0A 01 00 00 00 00 00 00 00}
0x6026 Numeric: (3405916100100-3405916100100) , Variable: 0x3F {07 A6 5F 00 5F 00 7B 27 03 00 3F 00 04 10 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
0x604C Default: 8 Bit, Value: 0x0 {5B 0D 00 00 00 00 00 00 00 00 00 00 00}
0x6059 Default: 8 Bit, Value: 0x0 {5B 0D 01 00 00 00 00 00 00 00 00 00 00}
0x6066 End {29 02}
0x6068 End If {29 02}

I'm wondering if something similar could be changed from UEFI shell or not.

 

[jkbuha]

Indeed. If you look at the topic that was referenced (the L511z) you may find the OP and initial approach to that form of BIOS modding was written by a familiar user....

A bit more of an explanation to this, but slightly offtopic for this forum. The problem with that approach is that in the latest generation of Dell BIOSes (9360 et al) you can't correct the Suppress If condition as an IFR variable; this is a jump condition that has been hardcoded by Dell to TRUE {46 02} in the 9360 (and most other BIOSes). In previous generations, you could set the conditional jump to false through a variable check, but in our case you (mostly) need to negate the suppression through hard-coding the conditions, which means patching the BIOS. Due to these security issues, Intel (and Dell) wisely implemented verified boot algorithms that check the binary signatures of the executable and semi-brick if an error is found.

Which is why if you find a loophole in SecureBoot or Verified Boot, you'd best use it wisely