Contribute
Register

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

@CaseySJ Good to hear about the GC-Titan Ridge AIC. Would you mind testing without the TB header cable attached as I have the GC-TR card but not the header on my motherboard. Without the header I can’t change the security mode to legacy so I’m not sure if I’ll ever be able to get it to work.Thanks very much!
Just performed the test without Thunderbolt header cable. Unfortunately, as suspected, Thunderbolt does not work because the header cable allows BIOS to turn on the Thunderbolt controller (i.e. to Force Power).

In the screenshot we can see that Thunderbolt is disabled, but the USB controller (XHC2) is active.

Screen Shot 2020-02-29 at 10.41.26 AM.png
 
Last edited:
This pin mod (jump 3 to 5) has the same effect as Force Power (from the egpu.io forum). Where there’s a will there’s a way...
73D6B42E-E098-46A9-B757-C93AA4884BA1.jpeg
 
Last edited:
This pin mod (jump 3 to 5) has the same effect as Force Power (from the egpu.io forum). Where there’s a will there’s a way...
View attachment 452357
Now I'm going to have to remove this card from the Asus X99 and move it to the Designare Z390 with jumper attached!

P.S. It's really spectacular to see this working so well.
 
Yes! I've run it with the test switch on and both EFI partitions got mounted and the log files shows all files in the source EFI folder listed. I'm guessing it's ok to edit it to TEST_SWITCH="N"?
Many thanks for you help @CaseySJ and @byteminer!
Thanks for testing! You may set the switch to N now.
 
This pin mod (jump 3 to 5) has the same effect as Force Power (from the egpu.io forum). Where there’s a will there’s a way...
View attachment 452357
Now I'm going to have to remove this card from the Asus X99 and move it to the Designare Z390 with jumper attached!

P.S. It's really spectacular to see this working so well.
Alas I thought I had these jumpers in my Arduino kit, but I don't. Will order a handful from Amazon, then perform this test.

Update: Jumpers will arrive tomorrow.
 
Last edited:
** Quick Analysis of Patched GC-Titan Ridge Firmware **

The Osy86 article on GitBook states that for an Alpine Ridge controller we should only look for differences in the first 0x1000 (4096) bytes of the Active Partition. We do this by comparing the firmware of our device with the closest matching firmware from Apple. But this technique has apparently had limited success with Titan Ridge.

So it is instructive to compare differences between the modified GC-Titan Ridge firmware and the original. Fortunately, my GC-Titan Ridge comes with NVM 23, which is the same version on which the DSM2.Hackintosh patch is based.

If we start at byte offset 0x4000, which is the start of the Active Partition, and compare the next 0x5D120 byes (381,216 or 372 KB), we find the following:

Original Firmware on left and Modified Firmware on right.

The list at the bottom of the screenshot shows 26 differences. In the first 0x1000 (4096) bytes, we find these few differences that we should be able to figure out by comparing the equivalent bytes in the closest Apple firmware:

Screen Shot 2020-02-29 at 4.18.29 PM.pngScreen Shot 2020-02-29 at 4.18.50 PM.pngScreen Shot 2020-02-29 at 4.19.00 PM.png
But much further below, at offset 0x152EB from the start of the active partition, we see a set of empty values (0xFF) in the original firmware. These have all been replaced as we see on the right side:
Screen Shot 2020-02-29 at 4.19.10 PM.png

The same thing happens again at offset 0x30054 from the start of the active partition. Another group of 0xFF is replaced entirely.
Screen Shot 2020-02-29 at 4.19.34 PM.png

And finally we see this again at offset 0x4A8AE from the start of the active partition.
Screen Shot 2020-02-29 at 4.19.40 PM.png

If the three sets of changes at offsets 0x152EB, 0x30054, and 0x4A8AE are significant and consequential (I have not removed these changes to observe the effect), then it seems that a successful firmware patch for Titan Ridge is much more complex than the Osy86 technique would suggest.

So where did these "filler" values come from?

One possibility is that DSM2 copied them from the closest Apple firmware. But based on some of his claims over at MacRumors, it's more likely that he somehow generated them himself. If that's true, it makes it much harder to replicate this work to other Titan Ridge firmware.

Question:

If the firmware that we see in these screenshots is compiled code, is anyone familiar enough with the subject to disassemble this code? Several x86 disassemblers are available.
 
@Elias64Fr,

A handful of people on the Internet have attempted to patch Titan Ridge firmware and they have had varying degrees of success. The patch by DSM2.Hackintosh seems to be the best one yet, but it is still not perfect.

First, let's look at some of the technical problems:
  • Thunderbolt devices do not seem to connect to Port 2. They only attach to Port 1. This is, however, the same problem we're facing with our SSDT.
  • Thunderbolt devices do not seem to connect at boot, but only when hot-plugged. Not sure if this is due to something in the Asus X99 Deluxe II. I'll test the modified GC-Titan Ridge on other Hackintoshes, including the Designare Z390 Test Bench (just waiting for jumper wires to arrive tomorrow).
Now let's look at some of the practical and logistical problems with this approach:
  • If DSM2 compiled and inserted some of his own code into the firmware, it means we cannot just copy-and-paste it into other devices. I have already looked at the Designare Z390 Titan Ridge firmware, and it does not have blocks of 0xFF at offsets 0x152EB, 0x30054, and 0x4A8AE. So already we know we cannot just copy his work.
  • While it is relatively easy to read the Winbond SPI Flash ROM on the GC-Titan Ridge, it is exceedingly difficult to read/write to that chip on the Designare Z390, which has a tiny resistor next to one of the pins. That resistor might be the reason why CH341a chip readers are generally unable to access the chip.
  • So even if we somehow patch the Designare Z390 firmware, hardly anyone will be able to flash it. And simply by the law of statistics, several people will damage their board in the process.
Therefore:
  • The best solution for Designare Z390 is a SSDT-based solution. If successful, it can be applied by every user with no risk of damage.
  • An SSDT-based solution might allow both Port 1 and Port 2 to function.
  • An SSDT-based solution can be more easily adapted to other motherboards.
So there is no question that the work we're doing with the SSDT is by far the best approach. It is the holy grail of Thunderbolt solutions. Of course, we are not making any promises other than the promise to try.
 
Back
Top