ThunderBolt Drivers

[Loloflat6]

19 minutes ago, zipb said:

Already checked, works fine(computer shuts down without issue) when  I don't have your SSDT installed

So may you try this SSDT : seems be the same TB3 on your mobo.

12 hours ago, Ribor92 said:

Almost couldn't believe my eyes first! But... SUCCESS FOR ME!!

Used this SSDT and just hotplugget my Focusrite Clarett 4Pre multiple times, tried both turning on and off the device and pulling the thunderbolt cable out and in. The ioreg shows red when disconnected and green when reconnected. WOW! 

I have a GB Z270x Gaming 5 with a GB Alpine Ridge Rev 1.0,  Strange this is that after sleep the device don't disconnect properly and is unusable, so strange! And sleep with TB is the main thing I'm after lol!

 

Any ides about it not working when waking from sleep. It seems in the ioreg that it doesn't disconnect properly when going in to sleep, bios related?

 

Edited April 19, 2018 by Loloflat6

[zipb]

I think I have already tried that SSDT. Didn't work either. I will check with maciasl tonight to see if it is really the same version.

In general, there's much more going on on a real Mac when pluggin/unplugging TB devices. None of the solutions presented in this thread even come close to generating the same sort of activity(as observed in the ioregistry tool).

I presume that an adapted SSDT should trigger the right (preferably Apple) services that deal with Thunderbolt i/o, that's not happening now. Just some very general/default routines are patched in, and all subtleties like hot swap/sleep/networking are not catered for at all.

[lelet]

@Loloflat6 No trick, no magic  The SSDT you are using is the work of @Matthew82 who recently tried to adapt the work done for the Asus ThunderboltEX on X299 to the Gigabyte platform. Unfortunately it did not work, so I preferred to start from a very lightened version to understand what was the minimum requirement to have the hotplug.
Obviously I'm everything, except an expert in this matter, so I'm moving in the dark mostly.

Today I had another success, even if still partial (again)... However, we can say that we are at 90% of the work.

With this version happens (This version is almost identical to the one you are using): SSDT-TB3 V2.aml.zip

STEP 1: UAD-2 Satellite and Apollo Twin connected and turned on at boot time.

STEP 2: I turned off and then turned on the Apollo Twin, which was reconnected properly.

STEP 3: I turned off and on both devices, but only the first (UAD-2 Satellite) connected correctly.

I noticed that to get the hotplug without Arbitrary inject I just have to add PCI-Thunderbolt One to DSB1. However doing this, the XHC2 controller in DSB2 is excluded.
Is it possible that the problem is the wrong slot? My Thunderbolt card is installed in Slot 5, but I can not change it in the SSDT.

Another important thing is that if I connect my Belkin Thunderbolt dock to the base of everything, the Apollo Twin (the last device in the chain) will no longer disconnect properly and the only hotpluggable device is the UAD-2 Satellite ( At least until I turn off the Belkin dock, then go back to the conditions explained above.)

[zipb]

ssdt-tb3 v2 enables hot plug for me too... Great! I can plug/unplug my Startech tb3-tb2 adapter/Apple tb2-ethernet adapter/MH 3D audio interface and it disappears/reappears as it is supposed to!

 

Will do more testing, I need USB3.1 to work too. And sleep.

Nice one, Lelet!

 

Hm. USB 3.1 is completely dead. You removed everything non-TB from the SSDT, Lelet?

[zipb]

I slept my hack once with no ill effect. TB wakes up AFAIK.

[zipb]

OK, only 1 of my 2 TB ports work. The other one doesn't. USB3.1 doesn't work on either ports.

But it's a step in the right direction, I guess.

[Ribor92]

I wonder what could be the cause with TB not disconnecting and reconnecting with sleep/wake. It just freezes like it did before this ssdt. But at reboot it all works fine again with Hotplug. 

 

Any thoughts?

[lelet]

1 hour ago, zipb said:

Hm. USB 3.1 is completely dead. You removed everything non-TB from the SSDT, Lelet?

 

5 hours ago, lelet said:

I noticed that to get the hotplug without Arbitrary inject I just have to add PCI-Thunderbolt One to DSB1. However doing this, the XHC2 controller in DSB2 is excluded.

Everything is still very experimental and there are some errors. Be patient for now

[egroys]

@lelet and everyone, this is amazing!

I have been struggling to get anything to hotplug with my Asus Prime x299 deluxe and Asus tbex3 card even though so many people have claimed it to be working. After trying every sort of arbitrary entry, and variation, nothing worked. 

I have been following this thread for a while and now I just copied the PCI-Thunderbolt section to DSB1 in my SSDt from SSDTv2 as you mentioned, and now I can reconnect only my Apollo, but not my satellite.

So exciting! 

 

I am fairly new to SSDTs so I am not sure if this means anything, but upon investigating my IOReg vs the iMac Pro IOReg, I noticed this difference. Can this IOPCITunnelL1 be the tunnel that allows subsequent devices to also reconnect? 

And if so, how can we edit this value?

Hoping we can solve this completely!

 

Thanks

Edited April 20, 2018 by egroys

[Loloflat6]

Spoiler

 

Yes it might , but there are various other settings that are configured by the SSDT and loaded at startup.

At this point we are trying with @lelet ,  @Matthew82  and others to improve and perform Hot-plug on all ports.

Edited April 20, 2018 by Loloflat6

[lelet]

2 hours ago, egroys said:

I am fairly new to SSDTs so I am not sure if this means anything, but upon investigating my IOReg vs the iMac Pro IOReg, I noticed this difference. Can this IOPCITunnelL1 be the tunnel that allows subsequent devices to also reconnect? 

Unfortunately no:

When a device is connected: IOPCITunnelL1Enable = false

When a device is not connected: IOPCITunnelL1Enable = true

However there are other missing entries that I'm trying to implement.
One of the biggest differences is that Apple uses:

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

                    Return (Zero)
                }

While our SSDTs use:

Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If (LNot (Arg2))
                    {
                        Return (Buffer (One)
                        {
                             0x03                                           
                        })
                    }

                    Return (Package (0x02)
                    {
                        "PCIHotplugCapable", 
                        One
                    })
                }

 

[Loloflat6]

Your return is quite interresting :

In both cases, the arguments on Method (_DSM are conditional and return opposite results for package (0x02) "PCIHotplugCapable" Zero or One.

 

 

 

 

 

Edited April 20, 2018 by Loloflat6

[TheRacerMaster]

6 hours ago, lelet said:

Unfortunately no:

When a device is connected: IOPCITunnelL1Enable = false

When a device is not connected: IOPCITunnelL1Enable = true

However there are other missing entries that I'm trying to implement.
One of the biggest differences is that Apple uses:

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

                    Return (Zero)
                }

While our SSDTs use:

Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If (LNot (Arg2))
                    {
                        Return (Buffer (One)
                        {
                             0x03                                           
                        })
                    }

                    Return (Package (0x02)
                    {
                        "PCIHotplugCapable", 
                        One
                    })
                }

 

The GUID/etc stuff is not a meaningful difference - the second is just a simplified form of the same device property injection (by Pike IIRC, which skips the Apple _DSM GUID check and not using the DTGP method, which does another check). But the PCIHotplugCapable value does differ; this is merely using PCI hotplugging instead of true OS-level TB hotplugging (e.g. see the NHI in IOReg, there aren't any Tx/Rx packets, while there are many on a real Mac with TB3).

Edited April 20, 2018 by TheRacerMaster

[zipb]

So what are we supposed to do, TheRacerMaster? Where should we plug what to make it work properly? 

Please enlighten us.

I understand what you are saying, this is not proper TB patching but more basic and primitive PCI tinkering, which will never give us proper Mac-like TB behavior. You have ideas how to do this? Please share them.

Edited April 21, 2018 by zipb

[lelet]

On 20/4/2018 at 5:26 PM, TheRacerMaster said:

The GUID/etc stuff is not a meaningful difference - the second is just a simplified form of the same device property injection (by Pike IIRC, which skips the Apple _DSM GUID check and not using the DTGP method, which does another check). But the PCIHotplugCapable value does differ; this is merely using PCI hotplugging instead of true OS-level TB hotplugging (e.g. see the NHI in IOReg, there aren't any Tx/Rx packets, while there are many on a real Mac with TB3).

In fact, I noticed that it does not work.

I created a new SSDT based on the information of an original iMac18,3 (I used this SSDT- Original iMac18,3 Thunderbolt.dsl).

Mostly the differences are on:
- _DSM method: PCIHotplugCapable Zero instead of One;
- _RMW method: I used the same ones that Apple uses.

Now my ioreg is very similar to that of an original iMac18,3 (original iMac 18,3 ioreg Download), but the hotplug does not work.

 

If I insert PCI-Thunderbolt 1 on DSB1 (with Arbitrary inject in clover or with _DSM method), I get the hotplug of the first device and a connection attempt of the second. The addresses of the devices change, in fact they are mixed in a strange way on IOReg.

 

The SSDT I am using is this: SSDT-TB3 V3.aml.zip

IOReg with this SSDT and arbitrary PCI-Thunderbolt 1 on DSB1: Lele's iMac.zip

 

There's probably something wrong, but I do not understand what. @TheRacerMaster in your opinion, where is the problem?

Edited April 21, 2018 by lelet
added ioreg

[Loloflat6]

May be good improvment based on  iMac18,3 :

i will try and return what it give on my rig ;-)

[iamwithstupid]

Is there a simple guide somewhere that explains what to do to to help out testing your ssdt's? I got clover configurator, ioregexplorer and some basic knowledge but it's hard to find out where to start.  Also... if I was about to apply an ssdt... is it easily reversible or do I have do an reinstall every time I screw up?

 

Edit: Admire your work by the way. I've been google'n this for years. Hat's off! 

Edited April 23, 2018 by iamwithstupid

[lelet]

SUCCESS!!!

Finally all my THUNDERBOLT devices are hotpluggable!!

 

The solution is unbelievable, seems to work on all chipsets without using SSDT, and shifts the focus on the cause of all problems Thunderbolt: the cable THB_C!!

Already in my previous post I noticed strange behavior by inserting the _DSM method in DSB2: PCIHotplugcapable Zero.
Since then I've been trying to figure out how the XHC controller affected the Thunderbolt hotplug, until Crismac2013 suggested I disconnect the THB_C cable from the motherboard.
Once disconnected, it was enough to add as an arbitrary inject my first Thunderbolt address (PXSX):

             <dict>
				<key>Comment</key>
				<string>PCI THUNDERBOLT 15d3 first entry</string>
				<key>CustomProperties</key>
				<array>
					<dict>
						<key>Disabled</key>
						<false/>
						<key>Key</key>
						<string>PCI-Thunderbolt</string>
						<key>Value</key>
						<integer>1</integer>
					</dict>
					<dict>
						<key>Disabled</key>
						<false/>
						<key>Key</key>
						<string>IOName</string>
						<key>Value</key>
						<string>pci-bridge</string>
					</dict>
				</array>
				<key>PciAddr</key>
				<string>01:00.00</string>
			</dict>

and it works!!

Now I have also added my last SSDT to get PCI information on System info. Probably with my last SSDT the arbitrary inject are not needed, as PCI-Thunderbolt One is already inserted as a _DSM method in UPSB.
I suspect, however, that in this way the USB-C functionality will be lost, you should do a test!
In any case this is a huge step forward and makes it obvious that we need to work on XHCs controller to solve the problems with the hotplug with THB_C cable connected.

 

Edited April 24, 2018 by lelet

[jya]

AFAIK, the THB_C header on the motherboard has nothing to do with USB. It's a GPIO, though its use is undocumented.

 

On Gigabyte x299 and ASRock at least, if you do not connect the THB header, then the TB card won't activate at all, and the BIOS will not show a Thunderbolt entry...

 

I'm rather amazed that it would work for you in macOS, I'm 99.99% sure your TB is now broken in windows however (and the TB card won't even appear)...

 

I'm on a different problem now, since I added a 2nd nvidia 1080Ti, just having the TB SSDT causes a kernel panic at boot

Edited April 24, 2018 by jya

[lelet]

True, my card is not displayed now in the bios, but it works perfectly in MacOS! I do not use windows, so it's not a problem.

 

1 hour ago, jya said:

I'm on a different problem now, since I added a 2nd nvidia 1080Ti, just having the TB SSDT causes a kernel panic at boot

Try activating the 4G Decoding in the bios and check that the ACPI Thunderbolt paths are the same as those in the SSDT even now.

Edited April 24, 2018 by lelet

[Riley Freeman]

So you're saying the card works in macOS without the cable attached to the motherboard's TB header?

 

I wonder if it would be possible to add a TB card to my X79 system? I assumed it wasn't possible because there's no TB header on the board.

[Loloflat6]

 @lelet 

 

I'm upset: my Asus TBEX3 stopped working at startup yesterday: I think, something in the PCB is "dead ": so I ordered a new one today and maybe I'll take delivery tomorrow. Strange problem: the first time in twelve years of experience in PC hardware a component is "burned" so quickly. 

To the next 

Edited April 24, 2018 by Loloflat6

[Ribor92]

I tried unplugging my THB_C cable without success, the thunderbolt card doesn't work at all after that point.

 

I'm sill so confused why my Clarett 4Pre can be hotplugged by turning on and off and pulling the TB cable, but not waking from sleep. It's like it's not disconnecting properly and freezes just like when there was no hotplug at all.

 

I wonder if there is some Bios setting or if something else is wrong with my sleep causing this. 

[Loloflat6]

What TB model you have ? 

With SSDT you may have partial or full Hot-plug.

[Ribor92]

I have Alpine ridge rev. 1 into a Gigabyte z270 gaming 5

 

i have lelets ssdt v2 right now which is working. As long as i boot with my Clarett on i can hot plug it freely but no sleep like I said.