Jump to content

[GUIDE] Dell XPS 15 (9550) Mojave 10.14 / 10.15 Quick Installation

Krim404

By Krim404,
in Installation Guides

 Share
1,806 posts in this topic

Recommended Posts

nabeelmoeen
nabeelmoeen
Posted
Posted

Errrm... 

so I don't know what I did, but now I can get the TB16 dock and the external monitor and USB ports (plugged into the dock) to be recognized when I plugged in the thunderbold cable to my Dell on a running system (hotplug).

(earlier it would only work if plugged in before boot).

When i closed the lid 'after' connecting the dock, instead of system going to sleep it moved all the open windows to the monitor. / disconnecting the laptop display

 

as per the previous post the changes I made today:

1. Changed SMBIOS from MAC17,1 to MBP13,3

2. Updated the AppledGraphicsDevicePolicy.kext to add the board-id to the info.plist file (my board-Id was missing, so I added one with 'none' value)

 

(oh and Btw, running 10.12.5)

 

THIS IS PERFECT!!!

 

 

(only peeve, with windows dual boot I can't use the same keyboard and mouse without pairing everytime. Since both are LE (Bluetooth 4) devices, the older way of copying the same authentication key between the 2 systems doesn't work.

fortunately, I got a CSR 4.0 bluetooth dongle with my Varmilo keyboard and I use that when on Sierra).

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Errrm... 

so I don't know what I did, but now I can get the TB16 dock and the external monitor and USB ports (plugged into the dock) to be recognized when I plugged in the thunderbold cable to my Dell on a running system (hotplug).

(earlier it would only work if plugged in before boot).

When i closed the lid 'after' connecting the dock, instead of system going to sleep it moved all the open windows to the monitor. / disconnecting the laptop display

 

as per the previous post the changes I made today:

1. Changed SMBIOS from MAC17,1 to MBP13,3

2. Updated the AppledGraphicsDevicePolicy.kext to add the board-id to the info.plist file (my board-Id was missing, so I added one with 'none' value)

 

(oh and Btw, running 10.12.5)

 

THIS IS PERFECT!!!

 

 

(only peeve, with windows dual boot I can't use the same keyboard and mouse without pairing everytime. Since both are LE (Bluetooth 4) devices, the older way of copying the same authentication key between the 2 systems doesn't work.

fortunately, I got a CSR 4.0 bluetooth dongle with my Varmilo keyboard and I use that when on Sierra).

 

Try to hot-unplug your TB16 (but first save all your work ;) ) There is big chance that macOS will crash. But anyway all possible feedbacks for all use cases are welcome

Link to comment
Share on other sites
nabeelmoeen
nabeelmoeen
Posted
Posted

Try to hot-unplug your TB16 (but first save all your work ;) ) There is big chance that macOS will crash. But anyway all possible feedbacks for all use cases are welcome

lol, you are right, it does crash after 3-5 seconds on unplugging!!

 

 

EDIT:

besides that, i think i messed up my system by upgrading to 10.12.6 .. now it's not picking any devices attached to the dock (TB16), though monitor still works when plugged in at boot. (didn't try plugging in after boot yet).

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

lol, you are right, it does crash after 3-5 seconds on unplugging!!

 

 

EDIT:

besides that, i think i messed up my system by upgrading to 10.12.6 .. now it's not picking any devices attached to the dock (TB16), though monitor still works when plugged in at boot. (didn't try plugging in after boot yet).

Waiting for my TB15 to try it out. I need debug information, logs etc to understand where and why it is crashing - then it will be possible to check whether we can fix it or not. Unfortunately, AAPL has absolutely different behavior how TB3 is working.

Link to comment
Share on other sites
gujiangjiang
gujiangjiang
Posted
Posted

For those, who have TB device on hands, and have already working config for USB-C (i mean - fully working, with hot-plug) - try to replace your SSDT-TB.aml with mine, reboot without TB device connected - and try to hotplug it after boot. Wait 10-20 second - and make dump from IOJones.

 

P.S. Finally i got USB-C properly working with USBC-to-USBC cable connected between laptop and my lovely Google Pixel XL! Yes! It is working natively, and with hotplug ;)

 

I test it again and found only when i delete drop xh_rvp10 then i can boot into osx but the internal camera disappear.

 

When i drop xh_rvp10 then it always show kernel panic when boot into osx.

 

Can you give us an example of config.plist and apci/patched so we can learn from that.

 

Additional bug:

 

When i sleep and wake up then the wifi become very slow only reboot can solve this,someone said it maybe related with XHC bluetooth bug and delete the extra XHC port to deal with it.

 

I have no idea.

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

I test it again and found only when i delete drop xh_rvp10 then i can boot into osx but the internal camera disappear.

 

When i drop xh_rvp10 then it always show kernel panic when boot into osx.

 

Can you give us an example of config.plist and apci/patched so we can learn from that.

 

Additional bug:

 

When i sleep and wake up then the wifi become very slow only reboot can solve this,someone said it maybe related with XHC bluetooth bug and delete the extra XHC port to deal with it.

 

I have no idea.

Once again - forget about it. It is not working as expected. Just got my TB15 today - but next 2 weeks i'll be on vacation abroad. So, when i'll return - i'll continue my investigation against thunderbolt. Good part - hotplug works just perfectly, but hot-unplug gives kernel panic - macos is not expecting that TB chip can disappear (dell is using dynamic power management by acpi/efi). So, there are two possible vectors - find a way to keep tb chip always online (not 100% this is possible, may be depended on physical chip soldering), or find a way to patch macos (most probably problem is in iopcifamily.kext) to avoid kernel panic on chip power-off.

  • Like 3
Link to comment
Share on other sites
serg992313
serg992313
Posted
Posted

Have it on second partition starting from DP1. Just updated to DP6 yesterday - good flight, no new bugs detected :)

Hello, where did you put apfs.efi? To UEFI64 driver folder in clover? Still getting panic with unknown reason, after full install or upgrade from 10.12.6.

Link to comment
Share on other sites
Mr.C
Mr.C
Posted
Posted

activity manager crash has been fixed by rehabman with new batterymanager kext. i already updated the repository.

 

well I copied it to System/Lirary/Extension, set permissions, retouched and working, no FC in activity monitor. However, coconut battery cannot recognize the battery... And the system cannot too...

Anyone with this problem?

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Hehe, new finding from me regarding ThunderBolt:

 - removing AppleThunderboltNHI.kext will at least help to avoid kernel panic on TB unplug - hot-plug will still work (even plugging after boot)

 - looks like i found how to force power TB controller on our dell machines!!! In ACPI there is specific method! \_SB.TBFP - thunder-bolt-force-power :))) Will try it in next days to see how it is working and will try to make thunderbolt work in always-on mode.

This ACPI method is also exposed as PNP0C14 in WMI interface to allow Intel thunderbolt updater (fwupd) to update tb firmware in sutuation when there is no tb device connected - so it is doing force-power for it.

  • Like 4
Link to comment
Share on other sites
KNNSpeed
KNNSpeed
Posted
Posted

You're right. TBFP was it.

 

Here--I made an SSDT that enables it.

 

Hotplug of Thunderbolt devices doesn't work for me, though. USB's still OK.

 

I think this is because there are still a lot of properties that need to be injected into the TB device. Looking at my rMBP 2013, the ioreg shows a lot more info.

 

EDIT: Well, I got the below image to work once, and then it stopped on reboots. :/

post-1024628-0-99225900-1504932794_thumb.png

SSDT-TBON.zip

  • Like 4
Link to comment
Share on other sites
KNNSpeed
KNNSpeed
Posted
Posted

Found something:

 

1575 DSL6340 Thunderbolt 3 NHI [Alpine Ridge 2C 2015]

1576 DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]

1577 DSL6540 Thunderbolt 3 NHI [Alpine Ridge 4C 2015]

1578 DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]

 

We all have the DSL6340 (1575/1576 device ID), but I noticed in Apple's SSDT for MBP13,3 it's checking for 0x15788086. Perhaps the NHI driver is also looking for the 1578 NHI. It appears as though the primary issue is that IOThunderboltFamily is not loading onto the thunderbolt controller. This is something it should do even if a device is plugged in on boot (so until TBFP can be made reliable in Mac OS that's something to work on).

 

Not sure what's preventing TBFP from working 100% in Mac OS. I can toggle it in Windows with AIDA64 just fine and it brings up the controller (TBFP (1)) or takes it down (TBFP (0)) no problem.


Here's something similar to what it should look like (taken from rMBP 2013, which has TB2), if everything were working natively.

post-1024628-0-36017500-1505060678_thumb.png

  • Like 1
Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Found something:

 

1575 DSL6340 Thunderbolt 3 NHI [Alpine Ridge 2C 2015]

1576 DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]

1577 DSL6540 Thunderbolt 3 NHI [Alpine Ridge 4C 2015]

1578 DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]

 

We all have the DSL6340 (1575/1576 device ID), but I noticed in Apple's SSDT for MBP13,3 it's checking for 0x15788086. Perhaps the NHI driver is also looking for the 1578 NHI. It appears as though the primary issue is that IOThunderboltFamily is not loading onto the thunderbolt controller. This is something it should do even if a device is plugged in on boot (so until TBFP can be made reliable in Mac OS that's something to work on).

 

Not sure what's preventing TBFP from working 100% in Mac OS. I can toggle it in Windows with AIDA64 just fine and it brings up the controller (TBFP (1)) or takes it down (TBFP (0)) no problem.

Here's something similar to what it should look like (taken from rMBP 2013, which has TB2), if everything were working natively.

 

Could you post ioreg from rMBP with something connected to TB and output of kextstat (and one - after disconnecting TB device)?

Also, the main problem may be that root node of pci device has thunderbolt attribute on rMBP - our doesn't have. And injecting it through _DSM is not working - i did try already. I think it is injected on real mac by efi TB driver - so, we can try to inject it with Clover.

 

Also, key for working correct NHI interface may be in RTPC method in mac acpi ;)

Also, XRST, SXFP, TRPE methods of NHI0 in acpi are used - unfortunately, can't tell atm how important are they.

  • Like 2
Link to comment
Share on other sites
KNNSpeed
KNNSpeed
Posted
Posted

Here you go.


Do you mean injecting "PCI-Thunderbolt" = 1? Because that actually causes the device to show up in system profiler (PCI section) as "Thunderbolt@xxx" instead of "PCI Slot 1@xx," but breaks hotplug.

 

I think there's a whole layer of complexity that's missing. Just these past couple days I found that the MBP 14,1 DSDT and SSDT (found in the 10.12.6 update) have a LOT of debug statements left in them, and they actually explain what's going on in the thunderbolt ACPI code. :) I'm thinking worst case we might need to just port the whole SSDT to our machines if we can't do it in any simpler way. There's also an NVRAM variable called "tbt-options," and for the Skylake and Kaby Lake MBP series it appears the value should be "4."

 

Note: I tried adding RTPC, and it behaved like the rMBP (RTPC = true when nothing was plugged in, no RTPC value otherwise), but it didn't help with enumeration. I think we need to look at what TRPE is doing and see how to implement the same functions [RTPC, MUST, TRPE, SXFP, XRST] with the methods already available to us in Dell's DSDT--if we want to use the native TB drivers and stop relying on the ExpressCard hack. I noticed that the SGOV methods between Apple and Dell are actually the same (maybe an Intel thing?), and Apple added SGDO and GGDV, but I think for SXFP we might be able to just toggle TBFP instead.


Update: And here's the MBP14,1 stuff attached.

 

SXFP - Force Power (off, it seems) for SX (meaning S0, S3)

TRPE - Thunderbolt root port enable? enumerate?

MUST - related to USB/TB detection, specifically for determining whether a USB or TB device was attached

XRST - some sort of reset event

RTPC - related to when there's no USB or TB device attached

 

The other ACPI names (like XRIN) that are in the NHI kext I know are for TB2 and TB1 machines.

 

For our machines, I think the address supplied to SGOV is different; tracing TBFP gives the following:

CGWR - Configuration write

CGRD - Configuration read (from the TFPS method)

 

// These come from memory (GNVS Global Non Volatile Storage (NVRAM))

// FPAT - force power activate?, per Windows = 1

// FPEN - force power enable, per Windows = 0

// FPGN - force power group number (?), per Windows = 0x01060010

// FPLV - force power level, per Windows = 1

 

EDIT: Some links:

https://github.com/Dunedan/mbp-2016-linux/issues/24

https://www.spinics.net/lists/kernel/msg2525682.html

https://developer.apple.com/library/content/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011138-CH1-SW1

rMBP2013_TB.zip

MBP141.zip

  • Like 2
Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Here you go.

Do you mean injecting "PCI-Thunderbolt" = 1? Because that actually causes the device to show up in system profiler (PCI section) as "Thunderbolt@xxx" instead of "PCI Slot 1@xx," but breaks hotplug.

 

I think there's a whole layer of complexity that's missing. Just these past couple days I found that the MBP 14,1 DSDT and SSDT (found in the 10.12.6 update) have a LOT of debug statements left in them, and they actually explain what's going on in the thunderbolt ACPI code. :) I'm thinking worst case we might need to just port the whole SSDT to our machines if we can't do it in any simpler way. There's also an NVRAM variable called "tbt-options," and for the Skylake and Kaby Lake MBP series it appears the value should be "4."

 

Note: I tried adding RTPC, and it behaved like the rMBP (RTPC = true when nothing was plugged in, no RTPC value otherwise), but it didn't help with enumeration. I think we need to look at what TRPE is doing and see how to implement the same functions [RTPC, MUST, TRPE, SXFP, XRST] with the methods already available to us in Dell's DSDT--if we want to use the native TB drivers and stop relying on the ExpressCard hack. I noticed that the SGOV methods between Apple and Dell are actually the same (maybe an Intel thing?), and Apple added SGDO and GGDV, but I think for SXFP we might be able to just toggle TBFP instead.

Update: And here's the MBP14,1 stuff attached.

 

SXFP - Force Power (off, it seems) for SX (meaning S0, S3)

TRPE - Thunderbolt root port enable? enumerate?

MUST - related to USB/TB detection, specifically for determining whether a USB or TB device was attached

XRST - some sort of reset event

RTPC - related to when there's no USB or TB device attached

 

The other ACPI names (like XRIN) that are in the NHI kext I know are for TB2 and TB1 machines.

 

For our machines, I think the address supplied to SGOV is different; tracing TBFP gives the following:

CGWR - Configuration write

CGRD - Configuration read (from the TFPS method)

 

// These come from memory (GNVS Global Non Volatile Storage (NVRAM))

// FPAT - force power activate?, per Windows = 1

// FPEN - force power enable, per Windows = 0

// FPGN - force power group number (?), per Windows = 0x01060010

// FPLV - force power level, per Windows = 1

 

EDIT: Some links:

https://github.com/Dunedan/mbp-2016-linux/issues/24

https://www.spinics.net/lists/kernel/msg2525682.html

https://developer.apple.com/library/content/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011138-CH1-SW1

 

I have acpi from 13,1, and looking on it - looks like detection of TB/USB mode is combination of RTPC, PCED/PCDA and UGIO methods and RUSB/RTBT + GNHI/GXCI attributes. And it is real mix how offten they are called :)

Also, there is no MUST in mbp13,1 acpi - so it can be skipped.

Link to comment
Share on other sites
KNNSpeed
KNNSpeed
Posted
Posted

Yeah--if you look at the 14,1 one, you'll see they left in a lot of "debug = " statements, and they explain what some of the 4-letter names are. It's as if someone left a bunch of debugging "printfs" in a C program. I don't think much at all changed between the 13,1 and 14,1 files except for that, and it looks like they removed some extra PCED and PCDA functions that weren't being used. You can see the differences with FileMerge.

  • Like 3
Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Yeah--if you look at the 14,1 one, you'll see they left in a lot of "debug = " statements, and they explain what some of the 4-letter names are. It's as if someone left a bunch of debugging "printfs" in a C program. I don't think much at all changed between the 13,1 and 14,1 files except for that, and it looks like they removed some extra PCED and PCDA functions that weren't being used. You can see the differences with FileMerge.

Yeah, this 14,1 acpi is really great peace, and really helpful to understand some parts of AAPL acpi code. As was supposed much earlier before - apple is using "manual" mode for TB - everything is controlled by driver and driver just triggers acpi methods - this is not Intel-way, as other vendors are doing much more automation in ACPI (look on our Dell acpi - TB is automated by _E42 event trigger that is called everytime you will plug-unplug something physical into port - and it is doing detection what kind of device was connected/was it USB/was it TB/etc.)

  • Like 5
Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

If it helps, I have attached a IOReg dump from a mid-2015 MacBook Pro 15" with an Thunderbolt Ethernet adapter plugged in.

 

And speaking of debug statements... I've also attached the Thunderbolt SSDT from an unreleased Mac (AAPJ1371, iMac Pro maybe?) (debug firmware present from 10.13 DP1). It also has debug statements in the SSDT (e.g. you can see that the ICMB method is used to enable the Internal Connection Manager [used on PCs to handle Thunderbolt events in ACPI/SMM, and also enabled on 2015+ Macs in Windows]).

MacBook Pro.ioreg.zip

SSDT-TbtPEG23.aml.zip

  • Like 1
Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Ok, now i have TB controller always-on on reboot, with NHI always populated, and with USB-C mode always on. Switch between TB-USB modes is broken - i was expecting this. Now i have to implement proper logic to provide macos information about current mode to have everything working.

By the way - without "dirty" express-card hack i have TB permanently on with working hotplug for USB - having Dell TB15 connected i can connect-disconnect it and always have proper working DP monitor (it is not going through pci-e lines as thunderbolt has separate line for DisplayPort connectivity). So we have 50% road finished :)


By the way, maybe it will be useful for somebody else - by design, all systems with TB host chip on-board, always have ability to force-power tb-controller. And this ability is done by WMI instruments in ACPI. There is always method in ACPI code with ID as "86CCFD48-205E-4A77-9C48-2021CBEDE341" that runs proper procedures for turning on and off TB.

For ex., in our ACPI this is method "WMTF" and this is identification part of it:

 

            Name (_HID, "PNP0C14")  // _HID: Hardware ID
            Name (_UID, "TBFP")  // _UID: Unique ID
            Name (_WDG, Buffer (0x14)
            {
                /* 0000 */  0x48, 0xFD, 0xCC, 0x86, 0x5E, 0x20, 0x77, 0x4A,
                /* 0008 */  0x9C, 0x48, 0x20, 0x21, 0xCB, 0xED, 0xE3, 0x41,
                /* 0010 */  0x54, 0x46, 0x01, 0x02                         
            })

 

So you can se in _WDG same ID as i have wrote here.

  • Like 4
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...