Contribute
Register

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

Results are the same:
-usb 3.1(a) dont work at all
-Thunderbolt dont work in Windows
-Thunderbolt work with hotplug in osx but without screen.
Thanks for testing the various mods. Alas, that’s all we can do with this card on that motherboard.
 
Updating the BIOS to F9H and back to F9B allowed me to boot again from Clover.

F9H gives me a black screen when trying to access BIOS Setup, or upon getting to the apple logo to boot. I can access the Clover screen and the verbose boot gets displayed, but screen gets black after this. I know it gets to the login screen as I get OSX error sounds trying to click randomly. Trying to boot from the OC EFI also leads to a black screen.
Thankfully, it still gives access to the Q-Flash menu. It seems to be an issue other users have encountered. I cannot find F9G anywhere, if a kind soul had a link I'd love to test it.

Seeing I could kind of get back to a working situation, I went through the tutorial again, starting from scratch.
However, I still get stuck on the Apple logo without a progress bar of any sort. I've reset NVRAM again, and verified the CFGLock to no avail.
Interestingly, after trying to boot once from the USB stick, a boot option appeared in the BIOS called OpenCore. Trying to boot from it leads to the same results as before, and the same error when trying to boot from Clover.

Updating to F9H and reverting to F9B and resetting the BIOS as per the 1st post allows me to boot from the Clover config again.

@CaseySJ I'll try CMOS reset ASAP. Is there something else to try in the meantime?
We should avoid F9h and use F9g instead. Flashing BIOS has the same effect as CMOS Reset.
 
I successfully reset the CMOS, reset the BIOS, tried again, but to no avail.
I again had to re-install F9B on my board to be able to boot without issues. Just found F9G so trying with that again.

Attached is my OpenCore Folder without the serial numbers.
 

Attachments

  • EFI.zip
    3.9 MB · Views: 51
@CaseySJ
Look how Thunderbolt DROM auto repair is easy now with HackinDROM :)

TB Bus ID
TB UID
TB Vendor and Device names are extracted and ready to be compiled with a correct customizable DROM!
 
I successfully reset the CMOS, reset the BIOS, tried again, but to no avail.
I again had to re-install F9B on my board to be able to boot without issues. Just found F9G so trying with that again.

Attached is my OpenCore Folder without the serial numbers.

F9g gives me the same results as before, stuck at Apple Logo and no way to reboot from the Clover install without flashing the board BIOS.
 
Hi fellow Pro Tools user... I am also running a flashed Titan Ridge in a motherboard with no TB header or native support. In fact I have an Asus z370 board and am using the Gigabyte card. I followed the verse first flashing guide from here using one of the cheap USB programmers off Amazon and it has been working since day 1. I initially used the Elias NVM23 but after other users reported good results with the Designare NVM33 I flashed again to that and have not touched it in months.

With no TB header I jumped the pins on the back of the card as recommended and have had no power issues in my board. I did not even bother hooking up the TR card to my power supply or USB2 header yet it seems to work fine even powering some bus powered USB drives.

My motherboard has 3 x16 slots (2xCPU PEG and 1xPCH) and I have only ever tried it in the bottom PCH as I remember reading others had better results in a non PEG. I had to modify the SSDT to match my RP and calculated my own DROM as per the guide but other than that it just worked. All that stuff is much easier now with HackinDROM anyway.

Hotplug works fine, except for complex devices like my Thunderbolt dock requires a reboot to load the drivers for the ethernet and audio output. The only thing that doesn't work for me is devices won't automatically reconnect after a wake from sleep, but a quick unplug / replug of the cable mounts them again without the need to reboot and load drivers.

Having had such a positive experience with adding thunderbolt to a machine I never thought would be possible, I guess my advice would be to start again and just follow the amazing guides in this thread. Don't over complicate things with additional scripts or kexts. I am simply using the 2 SSDT files from the guide modified to my machine. If you have other PCI slot options it might be worth trying another.
Hi @c0c0p0ps - thanks for chipping in. Im also using a hackindrom modified SSDT for my machine. Ive done the swapping of slots too. Its in the slot that yields best results a x16. Funny thing it kicked in on first boot this morning but that is a rare event. Once its going - its fine as I said, but after 50 boots you get fed up. Im on the DSM NV23 flash - Not sure what the difference is with yours - My Mb is not a designare. I wonder what the differences are. Would you mind sharing your Tb SSDT? also - whats a "non PEG"?
 
Last edited:
Hi @c0c0p0ps - thanks for chipping in. Im also using a hackindrom modified SSDT for my machine. Ive done the swapping of slots too. Its in the slot that yields best results a x16. Funny thing it kicked in on first boot this morning but that is a rare event. Once its going - its fine as I said, but after 50 boots you get fed up. Im on the DSM NV23 flash - Not sure what the difference is with yours - My Mb is not a designare. I wonder what the differences are. Would you mind sharing your Tb SSDT? also - whats a "non PEG"?
I don't have a Designare MB but trusted other peoples results from this thread who reported most stable results using that firmware on their TR cards and so far have seen no adverse effects. I never used the DSM2 version, only the ones modified here by Casey and Elias, which I also figure probably helps using their SSDT as well.

The PEG slots are the full length ones you can install graphics cards into. I have 2 of them in my Asus as well as another full length x16 which is what I have always used. It worked straight away so I never even experimented, again trusting what I read from other peoples findings.

SSDT is attached. I need it on RP21 for my MB, and also renamed my slot name to match my PCI address so it all matches in System Profiler. Especially when my dock is connected as that populates PCI with its extra ports.
 

Attachments

  • SSDT-TBOLT3-RP21.aml
    2.2 KB · Views: 51
  • Screenshot 2020-08-27 at 17.22.42.png
    Screenshot 2020-08-27 at 17.22.42.png
    399 KB · Views: 54
Thanks for testing the various mods. Alas, that’s all we can do with this card on that motherboard.
If screen can work under Windows with MOD-1, I think that problem is in OSX. After many many restarts, I get the screen to work from warm boot until osx loaded graphic driver. After kext was loaded, the screen goes black. Or maybe after loaded Thunderbolt driver?
 
Alright, time for some status updates, specifically interesting for @CaseySJ and @Mightymouseuk007 who originally reported an EFIClone issue.

Today I acquired a 970 Pro which I'm using as my test drive for Big Sur. I'm using the complete drive, newly formatted, to ensure that no APFS shenanigans lay undetected until later on.

First off, the install itself went swimmingly, just like the first time. This time I did not do an upgrade but a full-fresh install by creating an Install Media USB Stick. I booted from my main drive's EFI, selected the "Install Big Sur" entry and went off to the races. Everything worked fine and boot option selection was automatic, as expected (due to working NVRAM), so a completely unattended install.

The first time around I booted into the setup screen after the main installation was done and tried to migrate all my data from my existing disk. The process itself worked and I was able to access the desktop afterwards. However, after rebooting, I encountered the same issue as before where the boot would fail due to some possibly APFS-related issues.

My thinking was that migrating the data instead of upgrading would simply copy the data to the new APFS structure and hence it should be compliant and boot without issues. This is not the case. Neither a direct upgrade nor a later migration work. The only option is a fresh install without data migration.

In any case, I did eventually wind up with a working system that was capable of rebooting reliably without failing.

I then set out to test EFIClone_v2.sh to reproduce whatever issue mightmyouse was having. Turns out the script worked perfectly fine on my end, in a dry run. It found the correct EFI partitions of both the source as well as the target disk and initiated the copy. As such there might be an issue on their end instead, or there is an issue in the script in the case that mightymouse has a very unusual disk configuration or something.

If you could, @CaseySJ, since you have Big Sur up and running as well, could you give it a try? It would be good to get a third data point to see the trend that's forming. You can invoke the script via the command line directly for convenience as well.

I suspect the bootable backup issue may be more related to CCC itself not being updated to fully support Big Sur yet.
This is the note from their latest pre-release:
This build continues our beta testing cycle for macOS "Big Sur" 11. In the current macOS beta, CCC will create data-only backups of any Big Sur startup volumes. Apple's APFS replication utility is not currently capable of replicating a Big Sur System volume. We're working with Apple to develop the functionality within macOS that will allow third-party backup applications to continue making backups of macOS System volumes. In the meantime, we're making complete backups of your data, and those backups can be seamlessly used alongside the macOS Installer or Migration Assistant to produce a bootable backup or to facilitate a restore.

This means no bootable backups on Big Sur for now.
 
Back
Top