Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

do I need a clover update after the firmware patch? so that thunderbold is recognized? help me pls
Hello @Rulebreaker01,

Please describe the problem you are seeing. Even better, please post screenshots of (a) what is working and (b) what is not working.

Because you might be using a language translator, it is hard for us to understand your posts. So screenshots can be more helpful.
 
...
Once I put SSDT-TbtOnPch-ASRock-Z370-ITX-AC.aml (no changes was needed: same _E17 event and RP21 location) to CLOVER/ACPI/patched and rebooted – Thunderbolt Bus appeared in System Information under Thunderbolt section!
...
Was it necessary to apply an ACPI rename for the RP21 _INI() method? Or did you simply rename the _INI() method in the SSDT to PINI()?
 
It's been a while since I've last checked this wonderful thread. So many incredible things were achieved through the last months by collective enormous efforts of truly amazing people whom I really admire.

Thank you for all your hard work guys!

I'm going now through the whole Thunderbolt journey documented here and there in this thread.
It's absolutely amazing achievement!



I'm currently using Z390 Aorus Pro motherboard and GC-Alpine Ridge card with my Apple Thunderbolt Display.
It all worked perfectly with all functions of the display. I used old TB3HP SSDT since last summer. No problems at all.

So today I decided to try this SSDT-only approach to activate Thunderbolt Bus on my system.
It worked! I can't believe my eyes.

Once I put SSDT-TbtOnPch-ASRock-Z370-ITX-AC.aml (no changes was needed: same _E17 event and RP21 location) to CLOVER/ACPI/patched and rebooted – Thunderbolt Bus appeared in System Information under Thunderbolt section!

But unfortunately, it only happens when no device is connected to the TB card.

If I try to boot with Apple Thunderbolt Display connected before turning machine on, it will not show up.
And Thunderbolt section of System Information will say No hardware found.

So the only way to have both Thunderbolt Bus properly appear AND Apple Thunderbolt Display working is to connect the display to the GC-Alpine Ridge only AFTER you've booted the system.

@CaseySJ Just in case my information might be useful, you can add my config to repository.
Z390 Aorus Pro + GC-Alpine Ridge + Apple Thunderbolt Display.
Thunderbolt Bus appears. Display is working perfectly. But only when plugged in after system booted.

Just need to figure out what happens when I try to boot with display already connected and it will be a miracle :)
I have the same hardware setup as you. I'm using the no-flash approach but I'm using an SSDT that @dgsga created and modded for my AR. his approach also uses clover/OC device property injection for DROM. (I will experiment later with an AR SSDT if @CaseySJ creates one).

anyway, once in a while a boot doesn't load TB properly ("no hardware found"). what I have done in that case is first a PSU power off for a few seconds, and if that isn't sufficient, I do a CMOS reset. then everything is fine with the TB display connected at boot (until some unknown event or sequence of events again triggers the "no hardware connected" problem).
 
@CaseySJ,

Thank you again for your wonderful work and truly incredible collaboration with @Elias64Fr !
I'm digging through the whole TB investigation process now step by step.
It's unbeliveable, I feel like I'm reading a fascinating detective book.

I also fully agree with you that something in SSDT can be imroved further to properly handle both cold and warm boot with and without devices connected.

To answer your question about ACPI rename:

I was having difficulties making a proper patch to rename RP21._INI to RP21.XINI so I decided to edit DSDT directly.
Tried to de-cypher your hex sequences but no luck.
So, I dumped original tables via F4 and then just hard-coded XINI and XE17 in DSDT.aml which I put in ACPI/patched
Not ideal, but works as a temporary solution once I figure out proper patch for RP21._INI to RP21.XINI rename
 
Thank You! I flashed original firmware. I used the ssdt you modified according with my DSDT, renamed in acpi/patch - copying the values you provided in config.plist file (not sure if it's ok, or it must be customised in function of my mobo and TB3). Also changed what @CaseySJ said at post 20772. I don't have DROM visible on Hackintool/Logs/System.
My AR TB3 isn't Asus, but GB.
Please, tell me what I need to do next. Also, in this context (switching old ssdt for patched firmware with the new one for original) do I need SSDT-DTPG.aml anymore?
Please try the new procedure just added to the Repository:

Screen Shot 2020-05-13 at 7.26.40 AM.png

Your board only needs the _E17 to XE17 rename as mentioned in the guide. Please disable or delete the "_INI" to "XINI" rename.
 
@CaseySJ,

Thank you again for your wonderful work and truly incredible collaboration with @Elias64Fr !
I'm digging through the whole TB investigation process now step by step.
It's unbeliveable, I feel like I'm reading a fascinating detective book.

I also fully agree with you that something in SSDT can be imroved further to properly handle both cold and warm boot with and without devices connected.

To answer your question about ACPI rename:

I was having difficulties making a proper patch to rename RP21._INI to RP21.XINI so I decided to edit DSDT directly.
Tried to de-cypher your hex sequences but no luck.
So, I dumped original tables via F4 and then just hard-coded XINI and XE17 in DSDT.aml which I put in ACPI/patched
Not ideal, but works as a temporary solution once I figure out proper patch for RP21._INI to RP21.XINI rename
Fortunately for your board there is no need to rename _INI() because Gigabyte's awesome amazing wonderful DSDT checks if there's a PINI() method and if it exists, then _INI() automatically calls PINI().

So all we have to do is edit the SSDT-TbtOnPCH and rename the "_INI" method to "PINI". Then find and remove all references to XINI. This has been done in the Repository.
 
This looks like a memory driver issue. If you were using OsxAptioFix2Drv-free2000.efi, then check that no other memory drivers (such as AptioMemoryFix.efi, OsxAptioFix3Drv.efi, etc) are installed in CLOVER/drivers/UEFI.
It was the memory driver. After a brief panic, I remembered that I still had my USB install, so I hit F 12 and booted off of the USB install UEFI partition and into an earlier r4920 version of Clover. Once I got into clover, I just selected my normal macOS Mojave disk and booted without any problems.

Now this is where things get really weird. I had none of the above mentioned drivers in my old folder. I remember previously unlocking my MSR register, but I was always relying on RC scripts and nvram emulations. However if you take another look at my screenshot that I posted of two directories side-by-side, you will notice that my drivers64UEFI folder doesn't have any. Given that my hack has been rock solid for last year and a half, how was this possible?

And last but not least... I have gone ahead and implemented native NVRAM as per your instructions. Somewhere in those instructions there should also be a warning that updating the Motherboard BIOS/Firmware will lock the MSR Register thereby breaking NVRAM as well as introduce other issues and that it will once again have to be unlocked. I decided against updating to F9b and did all the work on the current F6 (perhaps foolishly), however, new users might first wish to update to latest one PRIOR to undertaking the effort to unlock the MSR. This is especially important because unlocking MSR is not for the faint of heart and should only be done when absolutely necessary. So it's best to do this once and not have to do it again.
 
It was the memory driver. After a brief panic, I remembered that I still had my USB install, so I hit F 12 and booted off of the USB install UEFI partition and into an earlier r4920 version of Clover. Once I got into clover, I just selected my normal macOS Mojave disk and booted without any problems.

Now this is where things get really weird. I had none of the above mentioned drivers in my old folder. I remember previously unlocking my MSR register, but I was always relying on RC scripts and nvram emulations. However if you take another look at my screenshot that I posted of two directories side-by-side, you will notice that my drivers64UEFI folder doesn't have any. Given that my hack has been rock solid for last year and a half, how was this possible?

And last but not least... I have gone ahead and implemented native NVRAM as per your instructions. Somewhere in those instructions there should also be a warning that updating the Motherboard BIOS/Firmware will lock the MSR Register thereby breaking NVRAM as well as introduce other issues and that it will once again have to be unlocked. I decided against updating to F9b and did all the work on the current F6 (perhaps foolishly), however, new users might first wish to update to latest one PRIOR to undertaking the effort to unlock the MSR. This is especially important because unlocking MSR is not for the faint of heart and should only be done when absolutely necessary. So it's best to do this once and not have to do it again.
Please see this guide for unlocking MSR 0xE2 on Designare Z390 -- and the "URGENT NOTE" at the bottom of the guide.
 
If someone is wiling to unflash their NUC (i.e. flash the original firmware back) and experiment with an SSDT-only solution, then simply post the NUC's DSDT.aml as follows:
  • Ensure Thunderbolt is enabled in BIOS.
  • Then press F4 at the Clover Boot Menu. This will save all original ACPI files in the CLOVER/ACPI/origin folder.
  • Boot into macOS and Mount EFI partition.
  • Then post the DSDT.aml from CLOVER/ACPI/origin
I have 3 identicals NUCS, I can test on one of the two unflashed, here are the one original DST.aml to experiment, thank you !
 

Attachments

  • DSDT.aml
    250.4 KB · Views: 74
I have 3 identicals NUCS, I can test on one of the two unflashed, here are the one original DST.aml to experiment, thank you !
Please try the procedure just added to the Alpine Ridge repository (click here):

Screen Shot 2020-05-13 at 8.37.14 AM.png
I'm using a call to MMRP() so please test and let me know if it works or fails. If it fails I can provide a different version of SSDT. Please ensure that any previous Thunderbolt SSDT is removed.
 
Back
Top