Contribute
Register

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

I have a motherboard that apparently has never had its TB3 ROM dumped - it is an Asus X299 Deluxe 2 with a Titan Ridge controller. I've found 2 SPI flash devices on the back sided of the board, but neither are Winbond chips. Not that it's necessary for a SPI flash to be Winbond, but most of the stuff I've read around the web about extracting motherboard Thunderbolt firmware makes reference to Winbond SPI flash chips. If I were to dump one or both of these chips is there a way to tell if it indeed holds a Titan Ridge firmware? Or are they probably just not the TR firmware memories because they are the wrong mfg? They are MXIC devices, MX25L3233F and MX25L8006E.

Also I see that the Gigabyte Titan Ridge card seems to have 2 flash memories, but most motherboards only have 1. Is that correct?
 
I have a motherboard that apparently has never had its TB3 ROM dumped - it is an Asus X299 Deluxe 2 with a Titan Ridge controller. I've found 2 SPI flash devices on the back sided of the board, but neither are Winbond chips. Not that it's necessary for a SPI flash to be Winbond, but most of the stuff I've read around the web about extracting motherboard Thunderbolt firmware makes reference to Winbond SPI flash chips. If I were to dump one or both of these chips is there a way to tell if it indeed holds a Titan Ridge firmware? Or are they probably just not the TR firmware memories because they are the wrong mfg? They are MXIC devices, MX25L3233F and MX25L8006E.

Also I see that the Gigabyte Titan Ridge card seems to have 2 flash memories, but most motherboards only have 1. Is that correct?
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.
 
When you mention fixing items in "Device Name", is the CRC32c re-calculated if we edit the Device Name (that is, changing it to something other than the stock string that you've programmed) before pressing the "Generate SSDT" button?
This error was introduced only yesterday because I made a wrong changes in the code. Yes CRC32c is recalculated when we edit Thunderbolt Bus ID or Vendor or Device Names:


ThunderboltDROM decode.png



For example if you change the default “Device Name”, the new name (Ex: Macintosh) will be converted to hex byte then will replace the last yellow byte string
Then the Device name byte length is recalculated and replace the default (0x12 cyan byte just above the Device Name byte in yellow)
Then the byte length (in the screenshot is 0x5e in blue at line 6) is recalculated
Finally the CRC32c is generated


If you change Thunderbolt Bus ID too, as you can see in the screenshot the entire DROM will be regenerated.

All this is one-click when you use HackinDROM.

So you can’t mix your own chosen bytes with HackinDROM generated DROM.
 
Last edited:
And might it be possible to add another button above to the "Jump to DROM" that when pressed would re-calculate the DROM (something like "Generate New DROM")?
Just by clicking your browser refresh button you'll get a new Thunderbolt UID with correctly calculated CRC8.

On SSDT page click to "Jump to DROM", click to your browser refresh button and you'll see the Thunderbolt UID and the CRC8 get updated.
 
Kudos for having a backup! Questions/suggestions:
  • Are you running Mojave or Catalina?
  • Were you using OcQuirks-4/FwRuntimeServices or the more recent OcQuirks.efi/OcQuirks.plist/OpenRuntime?
  • Is MSR 0xE2 unlocked?
  • Have you tried enabling verbose mode by adding -v to the end of Boot Arguments? This can be done at the Clover Boot Menu itself (select "Options"). If so, what do you see when the boot process stops?

@CaseySJ

• I'm running Catalina 10.15.6.
• I was using OcQuirks.efi/OcQuirks.plist/OpenRuntime with Clover 5119 before deleting the OcQuirks.plist for Clover 5120.
• MSR 0xE2 is unlocked
• I booted with verbose several times yesterday, and the output looked similar to the picture with zkejonathan's post:

@CaseySJ
Hi Mate,
Thank you for your new mini-guide to upgrade the clover to the latest 5120 version.
unfortunately, I am confronting an error message from the beginning.
It worked without any problem when using 5119.
The message shows as below.
Thanks in advance!
Jon

Thanks for your thoughts. Perhaps it's just a bug with Clover 5120. I'll just continue to use 5119 which works fine.

At least I'm not the only one with the issue.
 
i have a motherboard that apparently has never had its TB3 rom dumped - it is an asus x299 deluxe 2 with a titan ridge controller. i've found 2 SPI flash devices on the back sided of the board, but neither are winbond chips. not that it's necessary for a spi flash to be winbond but most of the stuff i've read around the web about extracting motherboard thunderbolt firmware makes reference to winbond spi flash chips. if i were to dump one or both of these chips is there a way to tell if it indeed holds a titan ridge firmware? or are they probably just not the TR firmware memories because they are the wrong mfg? they are MXIC devices, MX25L3233F and MX25L8006E.

also i see that the gigabyte titan ridge card seems to have 2 flash memories but most motherboards only have 1, is that correct?
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.
 
No worries! I think that's might something wrong with the new kernel patch. Yea! it worked perfectly with 5119
@CaseySJ

• I'm running Catalina 10.15.6.
• I was using OcQuirks.efi/OcQuirks.plist/OpenRuntime with Clover 5119 before deleting the OcQuirks.plist for Clover 5120.
• MSR 0xE2 is unlocked
• I booted with verbose several times yesterday, and the output looked similar to the picture with zkejonathan's post:



Thanks for your thoughts. Perhaps it's just a bug with Clover 5120. I'll just continue to use 5119 which works fine.

At least I'm not the only one with the issue.
Please try this quick experiment with Clover 5120:
  • Uncheck all of the OcQuirks checkboxes in Clover Configurator
  • Replace OcQuirks.efi and OpenRuntime.efi with the original three files from your Clover 5119 folder:
    • OcQuirks.efi
    • OpenRuntime.efi
    • OcQuirks.plist
  • Reboot
  • Does it work?
 
Please try this quick experiment with Clover 5120:
  • Uncheck all of the OcQuirks checkboxes in Clover Configurator
  • Replace OcQuirks.efi and OpenRuntime.efi with the original three files from your Clover 5119 folder:
    • OcQuirks.efi
    • OpenRuntime.efi
    • OcQuirks.plist
  • Reboot
  • Does it work?

@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?
 
Please try this quick experiment with Clover 5120:
  • Uncheck all of the OcQuirks checkboxes in Clover Configurator
  • Replace OcQuirks.efi and OpenRuntime.efi with the original three files from your Clover 5119 folder:
    • OcQuirks.efi
    • OpenRuntime.efi
    • OcQuirks.plist
  • Reboot
  • Does it work?
Thanks mate! It works again, I reckon that might compatibility issues with the drivers.
 
HackinDROM has been updated!

The whole script was updated

New design:
  • Separated sections for TB controllers selectors, On-board and PCIe
  • Vendor and Device name changers are on the home page
  • New "Jump to DROM" button on the SSDT page
  • MaciASL download link
  • Link to the forum
  • New visual for Thunderbolt DROM
  • Color guide for modified bytes and others
New:
  • Thunderbolt Bus ID changer for all controllers
  • Correct Thunderbolt Buffer size for all controllers
  • AIC - Option to change PCI root path (only for RPxx for the moment) + link to the forum for more info
  • AIC - Option to change PCI Slot number

Fixed:
  • Incorrect CRC32c of Z390 AORUS Xtreme
  • Incorrect Byte length after changing Asus ThunderboltEX3's "Device Name"
  • Minor bugs

@CaseySJ Now its your turn to update the Mini-Guides :headbang:
Thanks again for the updates. Please note that Thunderbolt DROM should be listed as shown below (see the red box). Under Port Definitions/Flags, the first byte is the length of that row (including itself).

So at offset 0x16 we see 08 81 80 02 80 00 00 00, where the first 08 means total length of this record is 8 bytes.


Screen Shot 2020-07-06 at 8.17.47 AM.png


Also note that Asus ThunderboltEX 3 is a PCIe card so it should be moved in the right section as shown:

Screen Shot 2020-07-22 at 8.23.58 AM.png
 
Last edited:
Back
Top