Jump to content

378 posts in this topic

Recommended Posts

1 hour ago, obus said:

Ok guys.

After switching my Titan Ridge from PCIE_ 16x2 to PCIE_4x1 slot on my mobo with connected USB cable I can confirm that KGP:s SSDT-X299-TB3HP-TTR is reconnecting to my thunderbolt and USB-C device after sleep without first ejecting with no issues and no black screen. As a bonus fully loaded bus drivers and some other cosmetic stuff.

Obviously this has something to do with witch PCIE slot my TB3-card is connected. With the card connected to PCIE_16x2 only @maleordebride:s  SSDT-TB3 was reconnecting to booth USB-C and TB device (with TB2 adapter) after sleep without any need to first eject and no black screen after sleep. 

Screenshot 2018-12-05 at 20.25.53.png

Screenshot 2018-12-05 at 20.24.37.png

Screenshot 2018-12-05 at 20.23.33.png

SSDT-C422-TB3HP-RP05-TTR.aml

 

A result that is just obvious. Always one needs to adjust ACPI path and ACPI replacements in concordance with his /her mobo and slot population. 

Edited by KGP-iMacPro

Share this post


Link to post
Share on other sites
Advertisement
39 minutes ago, KGP-iMacPro said:

 

A result that is just obvious. Always one needs to adjust ACPI path and ACPI replacements in concordance with his /her mobo and slot population. 

No it's not so obvious!! If I use your (attached) SSDT on my PCIE_16x2 I have to eject both USB-C and TB device before sleep, otherwise I get a black screen when resuming from sleep.  

SSDT-C422-TB3HP-BR1A-TTR.aml

Edited by obus

Share this post


Link to post
Share on other sites
12 minutes ago, obus said:

No it's not so obvious!! If I use your (attached) SSDT on my PCIE_16x2 I have to eject both USB-C and TB device before sleep, otherwise I get a black screen when resuming from sleep.  

SSDT-C422-TB3HP-BR1A-TTR.aml

 

Yup and nobody knows why.. I cannot confirm your findings with the Prime X299 Deluxe and he TTR aml is outdated anyway for months 

Edited by KGP-iMacPro

Share this post


Link to post
Share on other sites

The TTR aml with adjusted ACPI path and ACPI replacements is working perfect for me on PCIE_4 slot but not on PCIE_16 slot.

 

Funny!

 

Gigabyte recommend to connect the card to a PCIE_4 slot.

Might be a reason for that? 

Edited by obus

Share this post


Link to post
Share on other sites
On 12/6/2018 at 12:08 AM, KGP-iMacPro said:

 

Yup and nobody knows why.. I cannot confirm your findings with the Prime X299 Deluxe and he TTR aml is outdated anyway for months 

Exactly the same behaviour with your new SSDT-X299-TB3HP on my mobo.

PCIE_4 working HotPlug and reconnecting both USB-C and TB device after wake from sleep with no black screen.

PCIE-16 working HotPlug but KP and black screen after wake from sleep.

@maleordebride:s SSDT is working on both slots without injecting bus drivers of course.

Edited by obus

Share this post


Link to post
Share on other sites

So, where exactly would I place one of these SSDTs? 

Share this post


Link to post
Share on other sites
On 12/6/2018 at 12:17 AM, obus said:

The TTR aml with adjusted ACPI path and ACPI replacements is working perfect for me on PCIE_4 slot but not on PCIE_16 slot.

 

Funny!

 

Gigabyte recommend to connect the card to a PCIE_4 slot.

Might be a reason for that? 

 

On 12/9/2018 at 11:49 AM, obus said:

Exactly the same behaviour with your new SSDT-X299-TB3HP on my mobo.

PCIE_4 working HotPlug and reconnecting both USB-C and TB device after wake from sleep with no black screen.

PCIE-16 working HotPlug but KP and black screen after wake from sleep.

@maleordebride:s SSDT is working on both slots without injecting bus drivers of course.

 

 

Interesting. There is absolutely no change in the TTR behaviour on the ASUS Prime X299 Deluxe, if  I use my original TB SSDT or the SSDT resulting from the truncation by @maleorderbridge! I am using the TTR in Slot-4 (PCIX16_3). Always black screen on wake with a TB2 HDD connected via the Apple TB3 -> TB2 adapter during sleep. No issues with Alpine Ridge or TBEX 3 or when the TB2 HDD is not connected to the TTR during sleep. Absolutely same behaviour with both SSDTs!

 

984214518_Screenshot2018-12-13at05_22_33.thumb.png.c7a641fba808a8216bdc3ca364ca901b.png

 

 

 

Now the interesting part:

 

Inspecting my BIOS settings I witnessed the following under the PEG port configuration:

 

While PCIEX16_1 is correctly implemented as x16 (Sapphire Nitro+ Vega 64), and PCIXE16_2 (ASUS Aquantia 10GB NIC) and PCIXE16_4 (NVMe) are correctly implemented as x4, PCIEX16_3 with the TTR is not present!

 

IMG_2801.jpg.acb4a317bbbd6da744ee5b86e7a818ef.jpg

 

TTR incompatibility with x16 slots? Reason for black screen on wake with a TB2 HDD connected via the Apple TB3 -> TB2 adapter during sleep?

 

Now I wonder how you enable your TTR in any x4-slot of your Asus WS C422 FW PRO/SE in your Mainboard BIOS. In the BIOS of the ASUS Prime X299 Deluxe any TB Adaptor only can be enabled in one out of the four x16 slots (PCIEX16_1, PCIEX16_2, PCIEX16_3 or PCIEX16_4):

 

 IMG_2800.jpg.e2be1eda05c6629d6695e67f15fd61a8.jpg

 

 Does this implement that when running your TTR in some x4-slot, you do not enable TB at all in your Mainboard BIOS? Does this likely remove the black screen on wake with a TB2 HDD connected via the Apple TB3 -> TB2 adapter during sleep?

Share this post


Link to post
Share on other sites

Ok.

I will try to clarify som points after upgrading to Mojave 10.14.2.

@maleordebride:s Minimal SSDT now give me KP after wake from sleep in booth PCIE_16x2 and PCIE 4_x1 bus. This SSDT was working flawlessly in both PCIE_16x2 bus and PCIE 4_x1 bus under 10.14.1 so obviously something has changed in 10.14.2.

 

1600135394_Screenshot2018-12-13at17_06_12.thumb.png.546dc300de58298ca606bb2fbf807aff.png

 

"Now I wonder how you enable your TTR in any x4-slot of your Asus WS C422 FW PRO/SE in your Mainboard BIOS. In the BIOS of the ASUS Prime X299 Deluxe any TB Adaptor only can be enabled in one out of the four x16 slots (PCIEX16_1, PCIEX16_2, PCIEX16_3 or PCIEX16_4):"

 

I've just have one PCIE_4 slot on my mobo and I connect my TitanRidge on this slot. I have tested my TitanRidge-card only on PCIE_16x2 and PCIE_4x1 and the card is recognised fine in bios.

My earlier AlpineRidge-card was tested and recognised in bios on all my four PCIE-16 and my PCIE_4 slots. From that fact I maybee can draw the conclusion that my TitanRidge-card as-well should be recognized in bios on all PCIE slot:s.

 

This is the result with your SSDT in PCIE_4x1 slot:

1437121162_Screenshot2018-12-13at17_52_07.thumb.png.75361633b2d8ba1e2216ac6217d2c249.png

SSDT-C422-RP05-TB3HP.aml

 

Now everything is working with my card in PCIE_4 with hotplug. Booth USB-C device and TB3 device (with or without TB2 adapter) is recognised after sleep and no further problems with black screen. In other words everything works as it should. Bus driver is loaded and the cosmetic is there.

 

If I put my TitanRidge (with adjusted ACPI patch and replacements) in PCIE_16x2 only Hotplug is working and KP after wake from sleep.

 

"TTR incompatibility with x16 slots? Reason for black screen on wake with a TB2 HDD connected via the Apple TB3 -> TB2 adapter during sleep?"  

 

Could this have something to do with my 48-Lane CPU. X299 has only 44 lanes?

 

Edited by obus

Share this post


Link to post
Share on other sites
34 minutes ago, obus said:

Ok.

I will try to clarify som points after upgrading to Mojave 10.14.2.

@maleordebride:s Minimal SSDT now give me KP after wake from sleep in booth PCIE_16x2 and PCIE 4_x1 bus. This SSDT was working flawlessly in both PCIE_16x2 bus and PCIE 4_x1 bus under 10.14.1 so obviously something has changed in 10.14.2.

 

I've just have one PCIE_4 slot on my mobo and I connect my TitanRidge on this slot. I have tested my TitanRidge-card only on PCIE_16x2 and PCIE_4x1 and the card is recognised fine in bios.

My earlier AlpineRidge-card was tested and recognised in bios on all my four PCIE-16 and my PCIE_4 slots. From that fact I maybee can draw the conclusion that my TitanRidge-card as-well should be recognized in bios on all PCIE slot:s.

 

This is the result with your SSDT in PCIE_4x1 slot:

1437121162_Screenshot2018-12-13at17_52_07.thumb.png.75361633b2d8ba1e2216ac6217d2c249.png

SSDT-C422-RP05-TB3HP.aml

 

The SSDTs are macOS independent! Your hypotheses now really start to be off the road . I don't believe in any different performance of both SSDTs (fully implemented or truncated) as when comparing the underlying simple basics (taken from SSDT-9.aml of the iMacPro dump) they are identical. You are creating lots of confusion with your contradicting statements and conclusions.  

 

BTW PCI snapshots for PCIE_4x1 and PCIE_16x2 should be identical if the SSDT has been properly implemented for each of the two slots. I don't know what you are intending to demonstrate by the above screenshot. What counts more are anyway the TB IOREG results. And they also should be the same for both slots! 

 

Alpine Ridge and TBEX 3 anyway work flawless also with my SSDT. I guess one should not only read your comments here but also those of hundreds of users in my respective threads in the other forum. This discussion here really starts to be totally off the road as already stated above. 

 

Else I would prefer to see clear statements from your side like... To improve SSDT-TB3HP change a.) code/ line.. b.) code/line because line a.) and line b.)  in truncated  SSDT-TB3HP implements code a.), code b.) ... Don't just intent to apply the codes, but rather try to improve what in your opinion is wrong in the codes.

 

The community certainly will be grateful for all your efforts..

 

BTW... ASUS repeatedly confirmed in private conversations  that the TTR needs a firmware update to fully work, when I addressed the wake on sleep issue with the ASUS Prime X299 Deluxe  to them within a bunch of e-mails. They are not able to fix the issue within the ASUS Prime X299 Deluxe firmware , as based on their conclusions, there is no respective issue in the latter firmware. However, they have been able to reproduce the issue with the TTR on the ASUS Prime X299 Deluxe without using any of the two SSDTs you blame guilty for... :wink_anim:

 

The only part of the code that could affect sleep/wake would be 

 

                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return (Package (0x02)
                    {
                        0x69, 
                        0x03
                    })
                }

 which you can remove entirely without witnessing any difference.. :P

 

 

 

Edited by KGP-iMacPro

Share this post


Link to post
Share on other sites
1 hour ago, obus said:

Ok.

I will try to clarify som points after upgrading to Mojave 10.14.2.

@maleordebride:s Minimal SSDT now give me KP after wake from sleep in booth PCIE_16x2 and PCIE 4_x1 bus. This SSDT was working flawlessly in both PCIE_16x2 bus and PCIE 4_x1 bus under 10.14.1 so obviously something has changed in 10.14.2.

 

Sorry @maleordebride my bad.

 

Tested your SSDT again after a NVRAM reset and everything is working as it should.

Edited by obus

Share this post


Link to post
Share on other sites
1 hour ago, KGP-iMacPro said:

The community certainly will be grateful for all your efforts..

 

 

 

What is the problem @KGP?

 

I was just confirming, for the second time in this thread, that your SSDT TB3HP.aml is working perfect on my rig on PCIE_4 but not on PCIE16_2. 

I don't understand your frustration?

 

Edited by obus

Share this post


Link to post
Share on other sites
1 minute ago, obus said:

What is the problem @KGP?

 

I was just confirming, for the second time in this thread, that your SSDT TB3HP.aml is working perfect on my rig on PCIE_4 but not on PCIE16_2. 

I don't understand your frustration?

 

 

I don’t see any frustration at my side. I just tried to bring this discussion to some useful level. Seems also you totally misunderstood my feedback and intentions. Sorry for that. 

 

Enjoy and have fun the both of you! I am off of this thread and all this discussion :wink_anim:

 

Cheers, 

 

KGP

Share this post


Link to post
Share on other sites
On 12/12/2018 at 8:44 PM, KGP-iMacPro said:

Now I wonder how you enable your TTR in any x4-slot of your Asus WS C422 FW PRO/SE in your Mainboard BIOS. In the BIOS of the ASUS Prime X299 Deluxe any TB Adaptor only can be enabled in one out of the four x16 slots (PCIEX16_1, PCIEX16_2, PCIEX16_3 or PCIEX16_4):

 

Thats just because the X299-Prime does not have any x4 slots. It only has x16 and x1. I can confirm that on Asus boards that have x4 slots that the option appears in the menu.

g\

Share this post


Link to post
Share on other sites

I found this topic finally. I'm wondering if it is possible at all to make Apple Thunderbolt Display to work and properly communicate with on-board Titan Ridge controller of new Gigabyte Z390 Designare? I'm having really hard time to connect Apple Thunderbolt display to my new system. I'm using an SSDT file for Titan Ridge controller based on @KGP-iMacPro solution and controller itself gets properly recognized in macOS, but when I plug Apple Thunderbolt display to one of Thunderbolt ports nothing happens. IORegistry/IOJones show no changes in the device's tree, and display stays black and doesn't turn on.

 

I'd very appreciate if someone could point me to the right direction: where should I be looking at? Maybe there's a special BIOS settings that can solve this detection issue (already tried increasing reserved memory and/or i/o lanes - no luck), or I need to tweak my DSDT patch further.

 

Btw, I also have a Macbook Pro 2012 and Apple Thunderbolt display works perfectly with it. Just thought, that it may help in case of some info extraction in order to apply it to new system.

Edited by ALLEX

Share this post


Link to post
Share on other sites

I can't reproduce this on my X299 system, but one of my older ASUS X99 (Deluxe II) systems shows the below with an old ASUS TB2 card. I attached two IOreg's, and the SSDT I am using is the same one I posted earlier with only the address modified for this board (to BR1A). BIOS settings do not matter beyond the card being Enabled and set to the right slot (PCIE 5 in my case). I was able to have this info show years ago and posted it in an old Thunderbolt thread that had similar goals to this one, but nothing further ever came of it in that thread.

 

The second picture and IOreg is the same configuration but with UniqueID now enabled in the BIOS (instead of legacy). Thunderbolt still works.

 

To do this yourself you must have a "Thunderbolt Bridge" device available in System Preferences->Network to have it appear this way in IOreg or System Profiler. AFAIK, this can only be generated during a fresh install in which you already have Thunderbolt enabled and a device connected.

 

edit: I put in a Titan Ridge card and while I still am allowed to remove and re-add the "Thunderbolt Bridge" from Network I no longer can use UniqueID and nothing shows in System Profiler. I guess UniqueID is the only special piece here, and that old ASUS TB2 card could do it for whatever reason.

 

Here are the relevant bits from Library/Preferences/SystemConfiguration/NetworkInterfaces.plist, perhaps someone else can spoof this network device or find something helpful with it.

 

		<dict>
			<key>Active</key>
			<true/>
			<key>BSD Name</key>
			<string>en3</string>
			<key>IOBuiltin</key>
			<true/>
			<key>IOInterfaceNamePrefix</key>
			<string>en</string>
			<key>IOInterfaceType</key>
			<integer>6</integer>
			<key>IOInterfaceUnit</key>
			<integer>3</integer>
			<key>IOMACAddress</key>
			<data>
			AgAAAAAB
			</data>
			<key>IOPathMatch</key>
			<string>IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/BR1A@1/IOPP/UPSB@0/IOPP/DSB0@0/IOPP/NHI0@0/AppleThunderboltHAL/AppleThunderboltNHIType2/IOThunderboltController/IOThunderboltLocalNode/AppleThunderboltIPService/AppleThunderboltIPPort/en3</string>
			<key>SCNetworkInterfaceInfo</key>
			<dict>
				<key>UserDefinedName</key>
				<string>Thunderbolt 2</string>
			</dict>
			<key>SCNetworkInterfaceType</key>
			<string>Ethernet</string>
		</dict>
		<dict>
			<key>Active</key>
			<true/>
			<key>BSD Name</key>
			<string>en4</string>
			<key>IOBuiltin</key>
			<false/>
			<key>IOInterfaceNamePrefix</key>
			<string>en</string>
			<key>IOInterfaceType</key>
			<integer>6</integer>
			<key>IOInterfaceUnit</key>
			<integer>4</integer>
			<key>IOMACAddress</key>
			<data>
			rIejHH3p
			</data>
			<key>IOPathMatch</key>
			<string>IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/BR1A@1/IOPP/UPSB@0/IOPP/DSB3@3/IOPP/pci-bridge@0/IOPP/pci-bridge@0/IOPP/ethernet@0/BCM5701Enet/en4</string>
			<key>SCNetworkInterfaceInfo</key>
			<dict>
				<key>UserDefinedName</key>
				<string>Thunderbolt Ethernet</string>
			</dict>
			<key>SCNetworkInterfaceType</key>
			<string>Ethernet</string>
		</dict>

 

 

TB2.png

Archive.zip

TB2 Unique ID Enabled.png

Edited by maleorderbride

Share this post


Link to post
Share on other sites
On 12/18/2018 at 10:29 AM, ALLEX said:

I found this topic finally. I'm wondering if it is possible at all to make Apple Thunderbolt Display to work and properly communicate with on-board Titan Ridge controller of new Gigabyte Z390 Designare? I'm having really hard time to connect Apple Thunderbolt display to my new system. I'm using an SSDT file for Titan Ridge controller based on @KGP-iMacPro solution and controller itself gets properly recognized in macOS, but when I plug Apple Thunderbolt display to one of Thunderbolt ports nothing happens. IORegistry/IOJones show no changes in the device's tree, and display stays black and doesn't turn on.

 

I'd very appreciate if someone could point me to the right direction: where should I be looking at? Maybe there's a special BIOS settings that can solve this detection issue (already tried increasing reserved memory and/or i/o lanes - no luck), or I need to tweak my DSDT patch further.

 

Btw, I also have a Macbook Pro 2012 and Apple Thunderbolt display works perfectly with it. Just thought, that it may help in case of some info extraction in order to apply it to new system.

 

Are you are running a displayport connection from your video card to your TB3 card?

 

You should look at my first post in this thread (first page) and make sure the SSDT you are using is for your ACPI addresses. You can't just assume an SSDT will work if it is for a different motherboard.

 

 

Share this post


Link to post
Share on other sites
On 1/15/2019 at 4:34 AM, maleorderbride said:

 

Are you are running a displayport connection from your video card to your TB3 card?

 

You should look at my first post in this thread (first page) and make sure the SSDT you are using is for your ACPI addresses. You can't just assume an SSDT will work if it is for a different motherboard.

 

 

 

Thank you for the response @maleorderbride 

 

Of course, I've routed my video card's DP out to DP input of the motherboard. I've properly implemented the TB SSDT accordingly. In my case it is located on PCI0.RP05. I'm able to see UPSB, DSB0 and NHI on the tree, as well as XHC5 USB3.1/TB hub in IOReg (screenshot attached). Btw, USB-C storage devices work perfectly with good speeds when connected to those ports.

 

I saw some succesful reports of running various UAD TB devices on Z390 Designare and even – LG 5K Ultrafine, which is modern TB3 display.

Unfortunately, nothing happens when I connect my Apple Thunderbolt Display. I tried to plug it powered before PC boot, tried adjusting various BIOS settings, still no luck at all.

Doesn't work in Windows 10, latest Ubuntu and macOS 10.14.2. But works perfectly with my Macbook Pro 2012 (just in case you might think it's faulty display).

 

I haven't found anyone who could make Apple Thunderbolt Display work with Titan Ridge on PCH or as an add-in card. Starting to think if it is possible at all?

It should be, because display worked perfectly with Alpine Ridge and some previous Thunderbolt capable motherboards. And in some cases I saw how it started to work right from the POST/Clover stage.

 

Trying to solve this issue for more than a month. Already was in touch with Intel Thunderbolt team engineers (they say that it should work and Titan Ridge support all generations of TB devices), Gigabyte engineers (they say it is not validated to work, as Titan Ridge operates in native TB mode and works with only TB3 devices, while older devices would only work in legacy TB mode which is not longer supported).

 

In the meantime, I was exploring the Macbook Pro 2018 SSDTs recently. This model also has the same Titan Ridge JHL7540 controller on PCH, which is also located on the PCI0.RP05. There's very interesting SSDT called "TbtOnPch". It contains a lot of various functions, including ACPI notifications, mode switching and many more. I think, that in all our TB SSDTs we tend to skip this things (and that's fine for most of use cases), while they may be very important for a complete Thunderbolt support implementation in our systems. 

 

There's also a very interesting fact I discovered while exploring the MBP 2018 IOReg: seems like it has both Titan Ridge (DSB0, NHI, 0x15ea(b)8086) and Alpine Ridge (UPSB, 0x15788086) chips inside. Maybe it was done by Apple in order to support some legacy devices. Just random thoughts.

 

I just think that Apple Thunderbolt Display requires some special SSDT magic that may be there and that we currently don't have in our TB SSDTs.

Unfortunately, I don't have such great ACPI skills to manually adapt and properly implement that table.

 

In case you might be interested in having a look, I'm attaching the "TbtOnPch" and MBP's IOJones report. Also attaching my TB SSDTs as well (I have one more extended and one more minimal, based on yours). Just in case.

Will highly appreciate any your thoughts on this. Thank you!

 

z390-designare-rp05.png

iojones-mbp-dump.iojones

tbt-on-pch.aml

SSDT-Z390-DESIGNARE-TB3HP-V3.aml

SSDT-TB3.aml

Edited by ALLEX

Share this post


Link to post
Share on other sites
On 1/17/2019 at 1:19 PM, ALLEX said:

 

Thank you for the response @maleorderbride 

 

Of course, I've routed my video card's DP out to DP input of the motherboard. I've properly implemented the TB SSDT accordingly. In my case it is located on PCI0.RP05. I'm able to see UPSB, DSB0 and NHI on the tree, as well as XHC5 USB3.1/TB hub in IOReg (screenshot attached). Btw, USB-C storage devices work perfectly with good speeds when connected to those ports.

 

I saw some succesful reports of running various UAD TB devices on Z390 Designare and even – LG 5K Ultrafine, which is modern TB3 display.

Unfortunately, nothing happens when I connect my Apple Thunderbolt Display. I tried to plug it powered before PC boot, tried adjusting various BIOS settings, still no luck at all.

Doesn't work in Windows 10, latest Ubuntu and macOS 10.14.2. But works perfectly with my Macbook Pro 2012 (just in case you might think it's faulty display).

 

I haven't found anyone who could make Apple Thunderbolt Display work with Titan Ridge on PCH or as an add-in card. Starting to think if it is possible at all?

It should be, because display worked perfectly with Alpine Ridge and some previous Thunderbolt capable motherboards. And in some cases I saw how it started to work right from the POST/Clover stage.

 

Trying to solve this issue for more than a month. Already was in touch with Intel Thunderbolt team engineers (they say that it should work and Titan Ridge support all generations of TB devices), Gigabyte engineers (they say it is not validated to work, as Titan Ridge operates in native TB mode and works with only TB3 devices, while older devices would only work in legacy TB mode which is not longer supported).

 

In the meantime, I was exploring the Macbook Pro 2018 SSDTs recently. This model also has the same Titan Ridge JHL7540 controller on PCH, which is also located on the PCI0.RP05. There's very interesting SSDT called "TbtOnPch". It contains a lot of various functions, including ACPI notifications, mode switching and many more. I think, that in all our TB SSDTs we tend to skip this things (and that's fine for most of use cases), while they may be very important for a complete Thunderbolt support implementation in our systems. 

 

There's also a very interesting fact I discovered while exploring the MBP 2018 IOReg: seems like it has both Titan Ridge (DSB0, NHI, 0x15ea(b)8086) and Alpine Ridge (UPSB, 0x15788086) chips inside. Maybe it was done by Apple in order to support some legacy devices. Just random thoughts.

 

I just think that Apple Thunderbolt Display requires some special SSDT magic that may be there and that we currently don't have in our TB SSDTs.

Unfortunately, I don't have such great ACPI skills to manually adapt and properly implement that table.

 

In case you might be interested in having a look, I'm attaching the "TbtOnPch" and MBP's IOJones report. Also attaching my TB SSDTs as well (I have one more extended and one more minimal, based on yours). Just in case.

Will highly appreciate any your thoughts on this. Thank you!

 

z390-designare-rp05.png

iojones-mbp-dump.iojones

tbt-on-pch.aml

SSDT-Z390-DESIGNARE-TB3HP-V3.aml

SSDT-TB3.aml

 

If it doesn't work in Windows even then I would assume you have a more fundamental problem than an SSDT will address. I'm pretty sure I've seen threads where others are using an Apple TB display successfully, but I can't be of any help. You've done already what I would recommend for MacOS.

 

Your screenshot of the IOreg looks fine, so I would try getting it to work in Windows first. Perhaps a BIOS setting, or a different motherboard slot?

 

Thunderbolt on a hackintosh is just PCI-e detection--not true Thunderbolt. So while those sections from the newer Mac models you are discussing certainly matter, they will need to be part of a completely different approach.

 

Share this post


Link to post
Share on other sites

It turned out that there's a firmware issue of Titan Ridge controller in Z390 Designare motherboard and GC-Titan Ridge add-in card. Both products affected by this.

 

For some reason, Titan Ridge controller doesn't switch to Legacy Mode properly, when needed, and only operates in Native Mode (which isn't supported by Thunderbolt 1 devices).

 

I managed to have Gigabyte and Intel working together on this. Issue confirmed and solution found.

 

Currently Gigabyte already developed and succesfully tested custom firmware in their lab completely resolving this issue. 

 

Now they need to sign it by Intel, after that it will be shipped as a regular update to all users.

Edited by ALLEX

Share this post


Link to post
Share on other sites
On 2/28/2018 at 8:16 PM, maleorderbride said:

This is a mini-guide to get Thunderbolt hotswap working. My SSDT is for an ASRock TB3 (JHL6540) card in my X299 motherboard, but I know this also works with the Gigabyte X99 Designare's built-in TB3 port.

If you need a more basic overview of SSDTs then I suggest Shiloh's SSDT GPU Injection thread at the place that shall not be named.

 

Based on the TheRacerMaster's work, and remote.syst3m's idea to change the value of "PCIHotplugCapable", I have TB3 hotswap working. Thunderbolt does not show as loaded in System Profiler, and this is undoubtedly a bit of a hack, but it seems to work and it is quite easy to implement.

 

TheRacer Master's github work seems to be based on importing MacBookPro14,1 ACPI information. You can find some raw Darwin Dumps here from him that contain DSDTs, SSDTs, and IOreg.

 

Below is the seemingly relevant bit, pulled from TheRacerMaster's github, with only the "PCIHotplugCapable" value changed to enabled and a few values modified to fit my computer.


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

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

I implemented this as an SSDT, but perhaps one could simply inject the single property via Clover arbitrary, or just the DSB0 device with that one property.

 

1. What you need:

IOregistryExplorer (or IOJones)

MaciASL (use Rehabman's patchmatic)

Thunderbolt working (just without hotswap)

 

2. Identify the TB device address

2.1 Open IOreg and find your thunderbolt device(s) by typing in "thunderbolt" in the search bar. 

 

2.2. Take note of the address (PCI0.RP05 for me).

 

2.3. Now clear the thunderbolt search and switch to IOACPIPlane view on the top right of IOreg. Find that same address. You should see a few other entires under it, and make note of whatever does not begin with H (for X99), and any values for X299. In this case, mine are PXSX and SLT5. We are going to prevent these from loading by setting their STA value to Zero so that our devices load instead.

 

3. Modify stock SSDT

3.1 Download the attached base SSDT and replace any instances of PCI0.RP05 with your actual address. If you have multiple thunderbolt controllers then copy and modify accordingly.

 

3.2. Replace PXSX and SLT5 with your value(s) from IOACPIPlane view. You might only have one value, in which case you can delete the extra line from the stock SSDT.

 

That should be it! Reboot and open IOreg again. Look to see if you now have PCIHotplugCapable set to "True" on the right-hand side. If so, then it should be working.

 

4. BIOS Settings

4.1. If you have an ASUS X299 board then you should enabled ASPM and GPIO ForcePwr in addition to the normal BIOS settings (Legacy Security, Cache Line-in 128, any slot selection). If you don't do this then you will not see a USB 3.1 bus for the TB3 card unless you keep a USB 3.1 device plugged in to the TB3 port on startup.

 

5. Inject USB ports (not required for hotswap but clears up errors in boot log)

I also hardcoded the two USB 3.1 ports on my card to clear up some complaints during verbose startup. This was pulled from one of PikerAlpha's blog posts. I don't think it matters which device you inject this into (DSB2,3,4), but I chose DSB2 based upon the address on my particular card (0x0002000) locatable in IOreg. If I had had 0x0003000 then I would have done DSB3, etc. 

 

5.1. If you already have an XHC2 device, then name it XHC3, 4, or whatever is appropriate. If you only have one TB3 port, then you only need HS01 and SSP1.


            Device (DSB2)
            {
                Name (_ADR, 0x00020000)  // _ADR: Address
                Device (XHC2)
                {
                    Name (_ADR, Zero)  // _ADR: Address
                    Device (RHUB)
                    {
                        Name (_ADR, Zero)  // _ADR: Address
                        Device (SSP1)
                        {
                            Name (_ADR, One)  // _ADR: Address
                            Name (_UPC, Package (0x04)  // _UPC: USB Port Capabilities
                            {
                                0xFF, 
                                0x09, 
                                Zero, 
                                Zero
                            })
                            Name (_PLD, Package (0x01)  // _PLD: Physical Location of Device
                            {
                                Buffer (0x10)
                                {
                                    /* 0000 */  0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                                    /* 0008 */  0x31, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 
                                }
                            })
                            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                            {
                                If (LEqual (Arg2, Zero))
                                {
                                    Return (Buffer (One)
                                    {
                                         0x03                                           
                                    })
                                }

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

                        Device (SSP2)
                        {
                            Name (_ADR, 0x02)  // _ADR: Address
                            Name (_UPC, Package (0x04)  // _UPC: USB Port Capabilities
                            {
                                0xFF, 
                                0x09, 
                                Zero, 
                                Zero
                            })
                            Name (_PLD, Package (0x01)  // _PLD: Physical Location of Device
                            {
                                Buffer (0x10)
                                {
                                    /* 0000 */  0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                                    /* 0008 */  0x31, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 
                                }
                            })
                            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                            {
                                If (LEqual (Arg2, Zero))
                                {
                                    Return (Buffer (One)
                                    {
                                         0x03                                           
                                    })
                                }

                                Return (Package (0x02)
                                {
                                    "UsbCPortNumber", 
                                    0x02
                                })
                            }
                        }

                        Device (HS01)
                        {
                            Name (_ADR, 0x03)  // _ADR: Address
                            Name (_UPC, Package (0x04)  // _UPC: USB Port Capabilities
                            {
                                0xFF, 
                                0x09, 
                                Zero, 
                                Zero
                            })
                            Name (_PLD, Package (0x01)  // _PLD: Physical Location of Device
                            {
                                Buffer (0x10)
                                {
                                    /* 0000 */  0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                                    /* 0008 */  0x31, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 
                                }
                            })
                        }

                        Device (HS02)
                        {
                            Name (_ADR, 0x04)  // _ADR: Address
                            Name (_UPC, Package (0x04)  // _UPC: USB Port Capabilities
                            {
                                0xFF, 
                                0x09, 
                                Zero, 
                                Zero
                            })
                            Name (_PLD, Package (0x01)  // _PLD: Physical Location of Device
                            {
                                Buffer (0x10)
                                {
                                    /* 0000 */  0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                                    /* 0008 */  0x31, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 
                                }
                            })
                        }
                    }
                }
            }

 

SSDT-TB3.aml.zip

Could you please post the SSDT for X99 Designare EX?

Thanks in advance

 

Share this post


Link to post
Share on other sites

Well, the long story about Intel Titan Ridge Thunderbolt controllers and legacy Thunderbolt 1 hardware, such as Apple Thunderbolt Display has come to an end.

Today I got final response from Gigabyte Taiwan.


There will be no solution for TB1 devices at all. Never. It just won't happen. End of story.

They have been pushing Intel several times for a workable solution but neither of their requests have been responded or processed.

 

Intel strongly against releasing a "legacy mode Thunderbolt firmware of Titan Ridge" out to the market and end customers.

Intel also mentioned the Apple Thunderbolt Display was never in the Windows support category (even though it could somehow worked on older Gen. Thunderbolt chips). So they basically said that it was just special magic and you were lucky if you had it working before.

 

Gigabyte also contacted special Intel Israel Development Centre, and they also made an appointment with Intel Thunderbolt Team today.

The meeting just finished, and Intel direct response was:

 

1. Intel will modify and give more information on the Thunderbolt FAQ pages everywhere, which gave some confusions previously.
2. The Apple Thunderbolt Display is never in the Windows support category.
3. The Apple Thunderbolt Display worked in previous Windows Thunderbolt/Thunderbolt 2/Thunderbolt 3 were never validated, it might work but wasn’t guaranteed at all.

 

Gigabyte team is very sorry that Intel refuses in any ways of supplying a legacy mode firmware to get a workaround because that "never been validated at all" will cause even more troubles that nobody expected.

 

So after all, there will be no workarounds or updates to get an Apple Thunderbolt Display (and potentially any other TB1 devices being affected by this issue) to work with Z390 Designare, Z390 Extreme or any motherboard with GC-Titan Ridge add-in card.

Share this post


Link to post
Share on other sites
On 2/26/2019 at 11:46 PM, jlcdgd said:

Could you please post the SSDT for X99 Designare EX?

Thanks in advance

 

Your hotplug method doesn't work for me on my Gigabyte Z170X-UD5-TH. Unplugging/replugging a device kills everything hanging of my 2 (internal)TB/USB-c ports, TB & USB all disappears and a restart is needed.

Also, after sleep my TB device is gone. Basically, same behavior as no SSDT at all.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×