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

[CaseySJ]

@CaseySJ

Yes, your suggested configuration with Clover 5120 works!

I took my current Clover 5119 and installed Clover 5120 de-selecting the memory driver install option. That left the OcQuirks.efi, OpenRuntime.efi, and OcQuirks.plist files unchanged from 5119. I double-checked to make sure none of the OcQuirks checkboxes were selected in Clover Configurator. I rebooted in verbose and Catalina loaded fine without hanging.

So I've got Clover 5120 booting fine. What, if anything, is gained by using Clover 5120 in this configuration without the built-in memory driver?

The benefit of packaging OcQuirks/OpenRuntime into Clover itself is, of course, the ease of updates. As you know, OpenCore -- and hence OpenRuntime -- is evolving rapidly, with new versions being released about every couple of months. To keep up with this, there are 3 options:

1. Wait for yours truly to keep supplying updated versions of OcQuirks separately from Clover
2. Download latest OcQuirks yourself and modify OcQuirks.plist
3. Just upgrade Clover and not worry about OcQuirks/OpenRuntime ever again!

Option 3 sounds best to me!

 

[thenightflyer]

Hi Casey...I need your help. I bought a Titan Ridge Card v1 with patched firmware "GC-TITAN-RIDGE-NVM23-Elias64Fr.bin"
I've an Asus Sage 10G motherboard so I use it in slot 2. I put all needed SSDT following your guide but unfortunately I've no hot plug working.
I tried with a Lacie D2Big disk thunderbolt 3 and with a WD my passport pro RAID TB2 with apple adapter to TB3. Peripherals are seen as connected in system info but they are not mounted. I'm in panic. I attach here my EFI and Ioreg....please can you take a look when you've time? Thanks in advance.

 

[CaseySJ]

Hi Casey...I need your help. I bought a Titan Ridge Card v1 with patched firmware "GC-TITAN-RIDGE-NVM23-Elias64Fr.bin"
I've an Asus Sage 10G motherboard so I use it in slot 2. I put all needed SSDT following your guide but unfortunately I've no hot plug working.
I tried with a Lacie D2Big disk thunderbolt 3 and with a WD my passport pro RAID TB2 with apple adapter to TB3. Peripherals are seen as connected in system info but they are not mounted. I'm in panic. I attach here my EFI and Ioreg....please can you take a look when you've time? Thanks in advance.

Hello @thenightflyer

The IOReg indicates that the Thunderbolt SSDT is not removing the correct default device(s) before creating the new UPSB device. This should be easy to fix. Please run MaciASL and select File --> New from ACPI --> DSDT. In many cases, this "DSDT" will open automatically when MaciASL is launched. Then save the file File --> Save As... (in either of the two available formats), and upload.

 

[thenightflyer]

Here is the file

 

[CaseySJ]

Here is the file

The Thunderbolt SSDT is actually correct -- your board's DSDT does in fact define a PXSX device, but that device is not being removed and replaced with UPSB. There might be a different problem. Please do the following in Terminal:

log show --last boot | head -500 > ~/Documents/syslog.txt

This will create a file in Documents folder called syslog.txt. Please post that file.

 

[joeblough]

thanks for the replies!

There are other ways to dump the firmware. Maybe ThunderboltPatcher can work on a hackintosh (I couldn't get it to work on a Mac). You can dump Thunderbolt firmware using Linux (install Ubuntu 20.20). It only dumps the active firmware (but that might be ok since you probably don't have an older inactive firmware and you don't need it anyway). Ubuntu dumps don't include the 16K header so DROM will start at 0x200 instead of 0x4200.

Page 8 | Blackmagic eGPU/Pro Firmware Update Tool on macOS

Page 8 | Blackmagic Design released a firmware update package for the Blackmagic eGPU/Pro. What interests me the most is that it's for macOS. I downlo...

egpu.io

I can definitely boot Ubuntu 20.20 on this thing, no problem. When you say it only dumps the active firmware, do you mean it will only dump the "blue dot" chip rather than both the firmware and PD firmware that CaseySJ describes below? If it is only the main FW is that enough to work with?

MXIC (Macronix) chips are definitely supported by the Thunderbolt Mini-Guides in this thread. The two most common Flash ROM chips for Thunderbolt firmware are Winbond and Macronix.

To determine which chip contains Thunderbolt firmware we can do either or both of the following:

• Look for a blue or green dot on the chip (if it exists). Chip with blue dot contains Thunderbolt firmware. Chip with green dot contains Thunderbolt Power Delivery (PD) firmware.
• Extract the firmware for both chips and post here. We can open the files using Hex Fiend and check offset 0x4000. It will be immediately apparent which file contains Thunderbolt firmware.

Also note that Thunderbolt firmware chips are located physically close to the Intel Thunderbolt controller itself (JHL 7540 for Titan Ridge, but just look for Intel JHL....). The firmware chip can be on the same side of the board as the JHL chip or on the backside. In both cases it should be very close to the JHL chip.

Unfortunately, those two Macronix chips have no colored dots on them. Does the size (in MB) of the two chips and the fact that they are close to one another indicate that they are probably the FW and PD FW for the JHL 7540? they are near the Thunderbolt ports at least.

These two parts are on the back side of the motherboard and are exposed thru the hole in the bottom of the case. I'll have to take the motherboard out to inspect it more carefully. These newfangled boards have those huge shrouds over the I/O port area, and there is also some kind of heatsink underneath the shroud. I have had the shroud off to replace the WiFi, so I know how to take it off, but it's possible I won't be able to see any ICs under there due to the heatsink. Given how much power a Thunderbolt port can supply, I would not be surprised if the heatsink is attached to the 7540. Or is the TB power supply external to the 7540 (huge mosfets?)

The JHL7540 "datasheet" (really kind of just a glossy) implies that the controller is in a BGA package. I don't see any evidence of a pad grid for that kind of package on the back side of the board. But maybe they use blind Vias or something. Still I'd expect to see some Vias for power that go all the way thru the board forming a square pattern. There are a handful of small caps back in the vicinity of the flash memories that could be power supply bypass caps for the 7540 though.

Anyway, I'll have to take the board out of the case and remove the shroud and see what I can see. It would be a problem if the flash chips were on the component side of the board. If I am lucky I can at least confirm that the two Macronix parts are near the 7540. If the linux dump is just as useful maybe I should try that first?

 

[CaseySJ]

thanks for the replies!

I can definitely boot Ubuntu 20.20 on this thing, no problem. When you say it only dumps the active firmware, do you mean it will only dump the "blue dot" chip rather than both the firmware and PD firmware that CaseySJ describes below? If it is only the main FW is that enough to work with?

Linux will access the active partition of the Thunderbolt firmware chip. What does this mean? To avoid bricking a system if the firmware upgrade process is somehow interrupted, firmware upgrades are done as follows:

• The Flash ROM chip (Winbond or Macronix) is generally about 1 MB in size.
• There is enough space for at least 2 full copies of Thunderbolt firmware.
• One copy of the firmware comes with the board, and it is "marked" as being the active firmware.
• When we upgrade the firmware, the new firmware is written into a different section of the chip. If the upgrade process completes successfully and is verified, then this new section of the chip is marked as being the "active" firmware. The previous firmware is no longer used.
• When we upgrade the firmware once again, then the new firmware overwrites the original active partition and that partition gets marked once again as the "active" partition.

Thus:

• Linux will dump the contents of the currently "active" partition.
• But this won't help you to identify the physical chip on your board.

Unfortunately, those two Macronix chips have no colored dots on them. Does the size (in MB) of the two chips and the fact that they are close to one another indicate that they are probably the FW and PD FW for the JHL 7540? they are near the Thunderbolt ports at least.

Possibly, but see next part of reply.

These two parts are on the back side of the motherboard and are exposed thru the hole in the bottom of the case. I'll have to take the motherboard out to inspect it more carefully. These newfangled boards have those huge shrouds over the I/O port area, and there is also some kind of heatsink underneath the shroud. I have had the shroud off to replace the WiFi, so I know how to take it off, but it's possible I won't be able to see any ICs under there due to the heatsink. Given how much power a Thunderbolt port can supply, I would not be surprised if the heatsink is attached to the 7540. Or is the TB power supply external to the 7540 (huge mosfets?)

On motherboard with on-board Thunderbolt, so far we have seen that the Intel JHL chip is on the front side, but the Flash ROM chip (firmware) is on the back side. They are still "close" to each other regardless of which side they're on. The Flash ROM chip has generally been accessible easily, with no shrouds or obstructions. There is no need to locate the Intel JHL chip itself. You can instead try to find an image of the motherboard (Google Image Search) to see where the JHL chip is located, but again there is no need to physically remove shrouds or otherwise disassemble the motherboard.

The JHL7540 "datasheet" (really kind of just a glossy) implies that the controller is in a BGA package. I don't see any evidence of a pad grid for that kind of package on the back side of the board. But maybe they use blind Vias or something. Still I'd expect to see some Vias for power that go all the way thru the board forming a square pattern. There are a handful of small caps back in the vicinity of the flash memories that could be power supply bypass caps for the 7540 though.

Anyway, I'll have to take the board out of the case and remove the shroud and see what I can see. It would be a problem if the flash chips were on the component side of the board. If I am lucky I can at least confirm that the two Macronix parts are near the 7540. If the linux dump is just as useful maybe I should try that first?

Just to reiterate: no need to locate the Intel JHL chip. It's better to do a Google Image Search.

 

[thenightflyer]

The Thunderbolt SSDT is actually correct -- your board's DSDT does in fact define a PXSX device, but that device is not being removed and replaced with UPSB. There might be a different problem. Please do the following in Terminal:

log show --last boot | head -500 > ~/Documents/syslog.txt

This will create a file in Documents folder called syslog.txt. Please post that file.

Here is the log

 

[joeblough]

Linux will access the active partition of the Thunderbolt firmware chip. What does this mean? To avoid bricking a system if the firmware upgrade process is somehow interrupted, firmware upgrades are done as follows:

• The Flash ROM chip (Winbond or Macronix) is generally about 1 MB in size.
• There is enough space for at least 2 full copies of Thunderbolt firmware.
• One copy of the firmware comes with the board, and it is "marked" as being the active firmware.
• When we upgrade the firmware, the new firmware is written into a different section of the chip. If the upgrade process completes successfully and is verified, then this new section of the chip is marked as being the "active" firmware. The previous firmware is no longer used.
• When we upgrade the firmware once again, then the new firmware overwrites the original active partition and that partition gets marked once again as the "active" partition.

Thus:

• Linux will dump the contents of the currently "active" partition.
• But this won't help you to identify the physical chip on your board.

understood about inactive/active. can all of this firmware dump and firmware upgrade to a TB3 firmware be accomplished completely with software? i'm only asking this because clearly some people are dumping the firmware (and apparently upgrading it) with USB-SPI hardware. obviously if i can avoid using the USB hardware, i'd rather do that.

anyway, i know linux won't tell me where the part is located. what i was asking is if it is 1) possible to dump the firmware using linux in a way that is useful to you for purposes of patching, and 2) if the linux dumper can only see one of the two firmware chips (not the active/backup partition, but the PD firmware + TB firmware), does that make the linux dump method useless as far as a complete patch goes? using linux avoids me having to verify that those two chips are truly the thunderbolt firmware chips, and avoids me going out to buy the USB-SPI hardware (but i am perfectly willing to do that)

Possibly, but see next part of reply.

On motherboard with on-board Thunderbolt, so far we have seen that the Intel JHL chip is on the front side, but the Flash ROM chip (firmware) is on the back side. They are still "close" to each other regardless of which side they're on. The Flash ROM chip has generally been accessible easily, with no shrouds or obstructions. There is no need to locate the Intel JHL chip itself. You can instead try to find an image of the motherboard (Google Image Search) to see where the JHL chip is located, but again there is no need to physically remove shrouds or otherwise disassemble the motherboard.

Just to reiterate: no need to locate the Intel JHL chip. It's better to do a Google Image Search.

yes i know that the chips are still close to one another despite being on opposite sides of the board (i have designed PCBs and i am an FPGA/ASIC designer so i'm pretty familiar with all this stuff.) i was only trying to verify that these two flash memories really belong to the intel TB controller by finding the TB controller itself.

i already tried doing the google image search and unfortunately the only thing i could find with detailed photos was an Anandtech article about the x299 prime deluxe (not the -II). the boards are different, so it was not much use (and i don't think they removed any of the shrouds anyway.)

anyhow it sounds like if i dumped these roms with a SPI header that you'd be able to tell if they are TB firmware or not, so there's probably no reason to worry - i can buy the USB/SPI thing and just do it unless you think the linux method is good enough.

 

[CaseySJ]

Here is the log

The log indicates that table name TBTTITAN is not being loaded. It's missing from the log. Possible reasons/suggestions:

• Are you booting the correct EFI folder?
  • Press F12 at the BIOS splash screen to open the BIOS Boot Menu.
  • Select the correct internal macOS disk from the menu.
  • At the Clover boot menu, boot macOS normally.
  • Then look at RP05 in IORegistryExplorer. Do you see a sub-device PXSX or UPSB? If you see UPSB, then the Thunderbolt SSDT is loaded.
• If there are multiple EFI partitions on your system, mount all EFI partitions. Then look through them one by one. If there's an EFI/CLOVER folder, does that folder also contain the file SSDT-TB3.aml in CLOVER/ACPI/patched?

ACPI:
ACPI:
SSDT 0x000000004A90E000 000064 (v02 KGP    DTPG     00001000 INTL 20180427)
SSDT 0x000000004A90E000 000064 (v02 KGP    DTPG     00001000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000004A90D000 0001D6 (v01 KGP    X299HDEF 00000000 INTL 20180427)
SSDT 0x000000004A90D000 0001D6 (v01 KGP    X299HDEF 00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000004A90C000 000219 (v01 KGP    X299ANS  00000000 INTL 20180427)
SSDT 0x000000004A90C000 000219 (v01 KGP    X299ANS  00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB7A000 00014B (v01 KGP    X299PMCR 00000000 INTL 20180427)
SSDT 0x000000003DB7A000 00014B (v01 KGP    X299PMCR 00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB79000 00012A (v01 KGP    X299SAT1 00000000 INTL 20180427)
SSDT 0x000000003DB79000 00012A (v01 KGP    X299SAT1 00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB78000 000144 (v01 KGP    X299THSS 00000000 INTL 20180427)
SSDT 0x000000003DB78000 000144 (v01 KGP    X299THSS 00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB77000 0000B9 (v01 KGP    X299USBX 00000000 INTL 20180427)
SSDT 0x000000003DB77000 0000B9 (v01 KGP    X299USBX 00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB76000 0001FA (v01 KGP    X299XHCI 00000000 INTL 20180427)
SSDT 0x000000003DB76000 0001FA (v01 KGP    X299XHCI 00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB75000 0003E4 (v01 KGP    X299XHC  00000000 INTL 20180427)
SSDT 0x000000003DB75000 0003E4 (v01 KGP    X299XHC  00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB74000 0002C2 (v01 KGP    X299ETH  00000000 INTL 20180427)
SSDT 0x000000003DB74000 0002C2 (v01 KGP    X299ETH  00000000 INTL 20180427)

ACPI:
ACPI:
SSDT 0x000000003DB73000 000058 (v01 PmRef  CpuPm    00003000 INTL 20120320)
SSDT 0x000000003DB73000 000058 (v01 PmRef  CpuPm    00003000 INTL 20120320)

     efend: @ authenticated restart support is unavailable (800000000000000E, 8)
ACPI:
ACPI:
15 ACPI AML tables successfully acquired and loaded
15 ACPI AML tables successfully acquired and loaded