USB-C Hotplug not working

[Mork_vom_Ork]

Thunderbolt is not 100% working on hacks... It is a work in progress...

Is it? WHO is working on it to make it a 100% working solution?
I tried this for over a week now - and have made some progress. As you may notice, all Thunderbolt-featured real Macs are using SSDT for Thunderbolt. So i compared the various SSDTs from for example MacPro_2013, MacBookPro_late2015 and MacBookPro_2017(touchbar). in their ground structure they all seem to follow the same way and i think, the way we dont see it to appear on Hackintosh under section THUNDERBOLT within System Profiler is, cause we are missing something from a "correct built SSDT".

So what do i mean exactly:
if u just use built-in TB2 or TB3 ports of your motherboard, connected Thunderbolt devices will appear within SystemProfiler under their respective Entries: Ethernet, AHCI, Firewire or USB. For example: i have a CalDigit Thunderbolt2 Station, which features 2 eSATA- , 1 HDMI- , 1 Ethernet GB-, 2 USB3.0- and MIC/Headphone ports. If i connect this one via Apple Thunderbolt3-to-Thunderbolt2 adaptor into my ASUS onboard USB-C/TB3 port, all devices get detected by macOS SIERRA and are fully working.
BUT: they will be detect all as "Expresscard-Slots"! All the ports are visible in System Profiler as their main devices: Ethernet, AHCI, USB and Headphone/Microphone. But under Thunderbolt System Profiler says: no Thunderboltdriver loaded.

Also my Akitio NODE eGPU box is connected via Gigabyte AlpineRidge TB3 PCIe card - and it is working. Also a big BUT: i could not make it via running the script from eGPU.io, cause the script expects the Akitio Node as a working ThunderboltDevice - which is NOT possible at this time under Hackintosh. So i have to make the neccesary modifications to the desired Kextfiles by "hand". Et voila - eGPU is running.

I remember the days i have had an X99 ASUS Board with Thunderbolt EXii card: it was important, into which PCIe port the card was connected to, otherwise the result was the same as above described. But once i switched the PCIe slot, BANG it also shows up in Systemprofiler as Thunderbolt Device. Havn't tried this with the AlpineRidge card yet, cause on some pages you read: "plugin to the nearest CPU PCIe slot", others say "plug it into the nearest TB.Header PCIe slot".

I would be interested to help for making Thunderbolt fully work under Hackintosh - but right now, i feel like i am the only one who actively wnats to find a solution. Maybe you (RehabMan) would like to help?

 

[RehabMan]

Is it? WHO is working on it to make it a 100% working solution?
I tried this for over a week now - and have made some progress. As you may notice, all Thunderbolt-featured real Macs are using SSDT for Thunderbolt. So i compared the various SSDTs from for example MacPro_2013, MacBookPro_late2015 and MacBookPro_2017(touchbar). in their ground structure they all seem to follow the same way and i think, the way we dont see it to appear on Hackintosh under section THUNDERBOLT within System Profiler is, cause we are missing something from a "correct built SSDT".

So what do i mean exactly:
if u just use built-in TB2 or TB3 ports of your motherboard, connected Thunderbolt devices will appear within SystemProfiler under their respective Entries: Ethernet, AHCI, Firewire or USB. For example: i have a CalDigit Thunderbolt2 Station, which features 2 eSATA- , 1 HDMI- , 1 Ethernet GB-, 2 USB3.0- and MIC/Headphone ports. If i connect this one via Apple Thunderbolt3-to-Thunderbolt2 adaptor into my ASUS onboard USB-C/TB3 port, all devices get detected by macOS SIERRA and are fully working.
BUT: they will be detect all as "Expresscard-Slots"! All the ports are visible in System Profiler as their main devices: Ethernet, AHCI, USB and Headphone/Microphone. But under Thunderbolt System Profiler says: no Thunderboltdriver loaded.

Also my Akitio NODE eGPU box is connected via Gigabyte AlpineRidge TB3 PCIe card - and it is working. Also a big BUT: i could not make it via running the script from eGPU.io, cause the script expects the Akitio Node as a working ThunderboltDevice - which is NOT possible at this time under Hackintosh. So i have to make the neccesary modifications to the desired Kextfiles by "hand". Et voila - eGPU is running.

I remember the days i have had an X99 ASUS Board with Thunderbolt EXii card: it was important, into which PCIe port the card was connected to, otherwise the result was the same as above described. But once i switched the PCIe slot, BANG it also shows up in Systemprofiler as Thunderbolt Device. Havn't tried this with the AlpineRidge card yet, cause on some pages you read: "plugin to the nearest CPU PCIe slot", others say "plug it into the nearest TB.Header PCIe slot".

I would be interested to help for making Thunderbolt fully work under Hackintosh - but right now, i feel like i am the only one who actively wnats to find a solution. Maybe you (RehabMan) would like to help?

It is one of those things I want to look at, but don't have really any TB devices yet.
Also, I'm about to spring for an i7-7700k, DDR4, and probably other parts in order to build out a new desktop, so I probably won't be spending any money on TB peripherals that I don't need (at least for a while).

I'm aware of this thread: http://www.insanelymac.com/forum/topic/323540-thunderbolt-drivers/

I don't know if you have your own thread for your findings...

I did a little investigation the other day, and it seems there is some dependency on particular ACPI names. For example, you will find NHI0 in iMac17,1(and others) ioreg (comes from ACPI, provider of AppleThunderboltHAL). And if you grep the thunderbolt kexts, you will find they also reference NHI0. So, there could be such 'silly name dependencies'...

 

[Mork_vom_Ork]

I did a little investigation the other day, and it seems there is some dependency on particular ACPI names. For example, you will find NHI0 in iMac17,1(and others) ioreg (comes from ACPI, provider of AppleThunderboltHAL). And if you grep the thunderbolt kexts, you will find they also reference NHI0. So, there could be such 'silly name dependencies'...

YES, it does. This is what i have done so far with a self-build SSDT:

so there are no longer names like "[email protected]" etc. They now are all named like in the scheme i found in MacBookPro13,3 SSDT-6. At the end of this SSDT you will find this part of code-snippet:

Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (OSDW ())
{
If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
{
Store (Package (0x02)
{
"PCI-Thunderbolt",
One
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}

Return (Zero)
}

and if i change this snippit into this:

Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
{
Store (Package (0x02)
{
"PCI-Thunderbolt",
One
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
Return (Zero)
}

it changes the connected device properties from "ExpressCard" into "Thunderbolt"

PS: i know about the "OSDW" function and i know, that it should not be used, cause under macOS we will always use Darwin as OS. But anyway: it is interesting, that changing this part of code makes the hardware "slots" egtting detected as "Thunderbolt slot", not as "ExpressCard slot".

 

[RehabMan]

YES, it does. This is what i have done so far with a self-build SSDT:

so there are no longer names like "[email protected]" etc. They now are all named like in the scheme i found in MacBookPro13,3 SSDT-6. At the end of this SSDT you will find this part of code-snippet:

Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (OSDW ())
{
If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
{
Store (Package (0x02)
{
"PCI-Thunderbolt",
One
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}

Return (Zero)
}

and if i change this snippit into this:

Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
{
Store (Package (0x02)
{
"PCI-Thunderbolt",
One
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
Return (Zero)
}

it changes the connected device properties from "ExpressCard" into "Thunderbolt"

You can simplify what you're doing quite a bit... the whole OSDW thing is kind of silly,... we know all our code will be running on Darwin as there is no possibility of loading patched ACPI on Windows/Linux/etc (files in ACPI/patched are only for macOS/OS X). Also, DTGP is not needed for _DSM injection...

And yes, I noticed the PCI-Thunderbolt inject also, but never found it to matter. I wasn't really looking in System Information though as those items tend to be purely cosmetic. It never hurts to try though...

The specifics that you need to do to match more closely the ACPI naming/etc will depend on what is already in native ACPI. My NUC6/NUC7 for example, doesn't have a lot of pci-bridge stuff, as there are ACPI identities already (just not the names that Apple used).

I couldn't find any references in the kexts to names like DSB0/DSB1/DSB2/UPS0, so I was just leaving mine as-is...

 

[KNNSpeed]

So far, it looks like you actually don't need to be too particular about most names (just some).
I think you just need some pretty expansive downstream bus code to get this to show up right. USB Type-C doesn't need much to work on the port compared to Thunderbolt (or so I am of the mind, currently, having just gotten Type-C working on my Dell XPS 15).

 

[RehabMan]

So far, it looks like you actually don't need to be too particular about most names (just some).
I think you just need some pretty expansive downstream bus code to get this to show up right. USB Type-C doesn't need much to work on the port compared to Thunderbolt (or so I am of the mind, currently, having just gotten Type-C working on my Dell XPS 15).

What was the key to making the TB controller show up on the PCIe bus even when nothing is plugged in upon boot?

That's kind of where I want to start.
My USB-C (eg. just USB functionality) actually works pretty well on the NUC6i7KYK, but you have to plug in prior to boot, otherwise TB doesn't even show on the PCI bus.
I haven't seen any well explained fix for just that single problem...
You have it working?

 

[KNNSpeed]

Yep. USB-C's at 100% functionality, see SSDT-TYPC.aml in "Failsafes" folder.
The SSDT-TYPC currently loaded is my attempt at recreating the entire TB device tree; the IOReg shows a Thunderbolt device that was plugged in at boot, but the screenshot above was the extent of a hotplug.

i.e. Right now, hotplugging Thunderbolt I can only get the NHI to show up (even after my giant device tree attempt :/).
I'm also including the current state of my commented .dsl, and my vanilla ACPI tables. You may want to look at the vanilla DSDT--the key area is around "method XTBT". There's a recursion that had to be fixed since macOS has native drivers that take over and don't require an infinite loop (I guess that's there for Windows? The REV = 0x05 thing is a Linux check Dell must have very recently added).

I think the main reason I get any response at all from the NHI is because the TB and Type-C controller are handled by the same methods & GPEs.

 

[RehabMan]

Yep. USB-C's at 100% functionality, see SSDT-TYPC.aml in "Failsafes" folder.
The SSDT-TYPC currently loaded is my attempt at recreating the entire TB device tree; the IOReg shows a Thunderbolt device that was plugged in at boot, but the screenshot above was the extent of a hotplug.

i.e. Right now, hotplugging Thunderbolt I can only get the NHI to show up (even after my giant device tree attempt :/).
I'm also including the current state of my commented .dsl, and my vanilla ACPI tables. You may want to look at the vanilla DSDT--the key area is around "method XTBT". There's a recursion that had to be fixed since macOS has native drivers that take over and don't require an infinite loop (I guess that's there for Windows? The REV = 0x05 thing is a Linux check Dell must have very recently added).

I think the main reason I get any response at all from the NHI is because the TB and Type-C controller are handled by the same methods & GPEs.

We need to start at the basics...

Was your Thunderbolt controller showing on the PCI bus (when nothing plugged in at boot) without any ACPI patching?

 

[KNNSpeed]

No. The key was this (credit @dpassmor):

 Scope (\_SB.PCI0.RP15.PXSX)
    {
        Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
        {
            Return (One)
        }

Because the Dell powers up/powers down the controller upon plug/unplug. Apple expects the controller to just always be there, so we have to fake ExpressCard-like behavior (removable PCIe).

 

[RehabMan]

No. The key was this (credit @dpassmor):

 Scope (\_SB.PCI0.RP15.PXSX)
    {
        Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
        {
            Return (One)
        }

Because the Dell powers up/powers down the controller upon plug/unplug. Apple expects the controller to just always be there, so we have to fake ExpressCard-like behavior (removable PCIe).

I saw the earlier notes regarding _PRW and tried it here. Doesn't work on the NUC6i7KYK...
Things are a bit different here... There is a TBTR at _SB.PCI0.RP05.TBTR, _ADR=0. Also a _SB.PCI0.RP05.PXSX, _ADR=0. So first, OS X seems to assume a 1:1 mapping of objects/_ADR, and can't handle many:1. But I tried the simple thing of adding _RMV method, returning 1 (there was none originally) to TBTR. Didn't work... booting without a device plugged into USB-C/TB results in no TB on PCI. So then, I tried with PXSX, _RMV, returning 1. Same result. Then, I even merged TBTR and PXSX... same result.

So... it is something else... when I have time, I spend it reading the chipset/TB/PCI spec...