Contribute
Register

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

Hi,
Just wondering if anybody can help out:

I have a Gigabyte Designare Z390, i9900k 3.6Ghz, VEGA64 FE, 64GB 3200mhz, NVME 960pro. BIOS F9b

I've installed a fresh Opencore 0.5.6, 10.15.3 and after a bit of figuring out have unlocked CFG via recommended OC method.
I am just about to port USBs again as my previous Clover version was good but just double checking..

However I'm running a UAD Apollo 8 TB3 via TB2 Adapter with SSDT.. all good.

Are there any advances in the TB method, previous posts you're all on about heat guns etc.
Please don't tell me I've got to drag the Steinel out..

Or are there any OC/tweaks to get this build running even smoother than it is..??

TIA
 
Last edited:
This can be tricky to resolve so I need to ask a number of questions:
  • Is this a brand new installation?
  • Did the problem exist when macOS was first installed, or did the problem start some days or weeks or months later?
  • If you are on native NVRAM, have you removed EmuVariableUefi.efi and "rc" scripts?
  • Are you running Mojave or Catalina?
  • What devices are connected to your internal F_USB header (internal USB 2.0 header)?
  • When you configured your BIOS settings, did you start with Load Optimized Defaults?

Existing Catalina installation
Never occurred before
EmuVariableUefi and rc scripts are gone yes
There is nothing on internal usb header
And yes BIOS is ok configured.

Also when in sleep it starts right after sleep
 
$11 Programmer that is already 3.3V: This Programmer

This just seems to work and work well once clipped on tight. Definitely use a USB extension cable with it to make it easier on yourself.
This one has 3.3V on Vcc (pin 8) only. All SPI signal pins (MISO, MOSI, CLK, CS) are 5V.
 
This one has 3.3V on Vcc (pin 8) only. All SPI signal pins (MISO, MOSI, CLK, CS) are 5V.
Perhaps this is why my other card doesn't work anymore, whoops.
 
Okay all! @CaseySJ @Elias64Fr @NorthAmTransAm

Here are my results from my Z170X-DESIGNARE. About 2 hours worth of back and forth flashing, testing, reading the logs, for all of the versions posted. I am super grateful of you all taking a look at this firmware file.

ALL FIRMWARE WITHOUT SSDT:
- Nothing populates in IOreg or SYSInfo
- No mention of "THUNDERBOLT" in the log files, no errors or anything.
- USB-C works with No-Hotplug
- Only shows USB-C on cold boot.

ALL FIRMWARE WITH SSDT:
- Same as without SSDT, see above.
- :(

After reflashing the Original TB3 firmware, thunderbolt would NOT work no matter what I tried. So I ended up going back into windows and running the gigabyte FlashTBT app, and after the powerdown/unplug/reboot, thunderbolt was back to stock.

Here is what it looks like with the Antelope plugged into the built in TB3 at clover boot screen in IOREG with stock TB3 firmware fresh from windows FlashTBT. No SSDT:

View attachment 456402

After another reboot the Antelope will fully load into IOreg but like always drivers/coreaudio don't see the device.

Looks like it will be back to Titan Ridge testing for the time being. That has the potential for more successful outcomes it seems.

I may try reripping the stock firmware again and having one of the fine folks here check to see if its different after doing the windows reflash.

UPDATE:
Reinstalled the modified GC-Titan Ridge card, in doing so disables the Alpine Ridge controller. Nothing populates under RP05 when plugged in.
Some comments:
  • Whenever we install or remove a PCIe card or any other component on the motherboard, we must shutdown the system and flip power switch to OFF (or unplug power cable).
  • After the modified card is installed, flip PSU switch back on and boot the system (i.e. Cold Start).
  • When you say "nothing populates in IOReg or SysInfo, we should be more specific:
    • If no child node appears under RP05 or RP21 (or wherever the card is supposed to appear), then Thunderbolt is dead.
    • But if we see a small set of child nodes under RP05 or RP21, etc. then Thunderbolt may be fine, but it's operating in ICM Mode (Internal Connection Management Mode).
    • But if we see the entire set of child nodes -- including ThunderboltSwitch and ThunderboltPort -- then we know that Thunderbolt is operating in full Mac-compatible mode.
 
Perhaps this is why my other card doesn't work anymore, whoops.
In many cases the 5V SPI pins on CH341a have not been much of a problem. But you never know! This is another reason for recommending the Raspberry Pi because its SPI pins (MISO, MOSI, CLK, CS) are all at 3.3V. And you don't need another computer nearby. The Raspberry acts both as an external flasher and a "PC".
 
Would someone please determine the correct CRC32_C value for the ThunderboltDROM entry in the spoiler below? (My system never generates a DROM error code.) Thanks!

Code:
ThunderboltDROM",
Buffer (0x76)
{
   /* 0000 */  0x88, 0x00, 0x11, 0x11, 0x11, 0x11, 0x11, 0x00,
   /* 0008 */  0x00, 0xDC, 0x30, 0x48, 0x53, 0x01, 0x65, 0x00,
   /* 0010 */  0x86, 0x80, 0x34, 0x12, 0x01, 0x01, 0x08, 0x81,
   /* 0018 */  0x80, 0x02, 0x80, 0x00, 0x00, 0x00, 0x08, 0x82,
   /* 0020 */  0x90, 0x01, 0x80, 0x00, 0x00, 0x00, 0x08, 0x83,
   /* 0028 */  0x80, 0x04, 0x80, 0x01, 0x00, 0x00, 0x08, 0x84,
   /* 0030 */  0x90, 0x03, 0x80, 0x01, 0x00, 0x00, 0x05, 0x85,
   /* 0038 */  0x50, 0x00, 0x00, 0x05, 0x86, 0x50, 0x00, 0x00,
   /* 0040 */  0x02, 0x87, 0x0B, 0x88, 0x20, 0x01, 0x00, 0x64,
   /* 0048 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x89, 0x80,
   /* 0050 */  0x05, 0x8A, 0x50, 0x00, 0x00, 0x05, 0x8B, 0x50,
   /* 0058 */  0x00, 0x00, 0x09, 0x01, 0x41, 0x53, 0x52, 0x4F,
   /* 0060 */  0x43, 0x4B, 0x00, 0x0F, 0x02, 0x58, 0x35, 0x37,
   /* 0068 */  0x30, 0x20, 0x43, 0x72, 0x65, 0x61, 0x74, 0x6F,
   /* 0070 */  0x72, 0x00, 0x00, 0x00, 0x00, 0x00             
},
 
@CaseySJ Dude, your thread has now reached a level of comprehensiveness, where you really should start to worry about clarity and a (probable) summary :clap: (maybe another thread with all guides? After all, this is the build guide)
 
Existing Catalina installation
Never occurred before
EmuVariableUefi and rc scripts are gone yes
There is nothing on internal usb header
And yes BIOS is ok configured.

Also when in sleep it starts right after sleep

UPDATE:

Found it, somehow FixFirewire was unchecked in config.plist.
Problem fixed. Normal behaviour again.

BTW:

Geekbench 5 Metal score 45271 without IGPU so only RX580
 
Last edited:
...
Are there any advances in the TB method, previous posts you're all on about heat guns etc.
Please don't tell me I've got to drag the Steinel out..
If you follow the Clover-based build guide or the OpenCore guide for this motherboard, Thunderbolt will work just fine for most applications, including UAD Apollo devices with a TB3-to-TB2 adapter. What we are hyperventilating about these past few days is unlocking the full extended potential of Thunderbolt, which is something we previously didn't think was possible on a Hackintosh. But again, your UAD Apollo will work just fine without this.
Or are there any OC/tweaks to get this build running even smoother than it is..??
...
Please see this spoiler in Post #1, which includes a Gigabyte PDF that explains overclocking.

Screen Shot 2020-03-23 at 5.41.19 AM.png
 
Back
Top