Contribute
Register

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

The screenshots I attached with are based on iMac19,1 firmware on GC-Titan Ridge. As for eGPU firmware on GC-Titan Ridge, it only can be recognised by my Macbook Pro, because it was in peripheral status.


Comparison between "iMac19,1 firmware" and "eGPU firmware"

iMac19,1 firmware:

  • Thunderbolt device connection to Port 1: Good
  • Thunderbolt device connection to Port 2: Good
  • USB-C device connection to Port 1: Should boot with devices plugged
  • USB-C device connection to Port 2: Should boot with devices plugged
  • Hot plug capability on both Port 1 and Port 2:Good
  • Recognized by motherboard: Positive
eGPU firmware:
  • Thunderbolt device connection to Port 1: Good
  • Thunderbolt device connection to Port 2: Good
  • USB-C device connection to Port 1: Good
  • USB-C device connection to Port 2: Good
  • Hot plug capability on both Port 1 and Port 2:Good
  • Recognized by motherboard: Negative
Thank you -- very useful!
---------------------------Here is a good news!--------------------

I found a software from TI which is specifically for designing firmware for Thunderbolt 3 devices. The software's full name is "TPS6598x configuration tool" (it is for Alpine Ridge and free to get it). As for Titan Ridge version of this software, only authorized companies can acquire it. But it doesn't matter, cause we probably can get some clues to customize firmware.

View attachment 455945

View attachment 455946
Please note that this is Thunderbolt Power Delivery firmware, which is separate from Thunderbolt Functionality firmware. Power Delivery is based on TI TPS6598x chip. But Thunderbolt Functionality is based on Intel Titan Ridge chip (JHL 7540).
 
This seemed to be the case for me but when I cold booted with no SSDT it came to life. In my experiences of late I've noticed that the wrong TBROM will kill it completely from showing up in OS.

The sign of life is if your boot time is still slower. Do you want my SSDT?

@Elias64Fr just offered a fix for the slow down above this post. Yay!
@NorthAmTransAm @CaseySJ
This DSDT fix is only for Z390 Designare but methodology can work on all kind of board : It depend on DSDT and TINI related call :)

Methodology is very simple and can be used for any other Patch:
  1. Copy your DSDT.aml on desktop (or wherever you want)
  2. Duplicate this file
  3. On one of these files, make the correction (here one line deleted) with MacIASL
  4. Open two files with HexFiend and make a Compare
  5. Search for one word (example TINI) on what you are removing/modified in order to locate approximately offset on Hex file (most difficult that what I have said!), you should find your files differences for this patch :shifty:
  6. Differences from two files .. added to previous byte is the patch :)
That's all !

Update:
Capture d’écran 2020-03-21 à 23.36.09.png
Capture d’écran 2020-03-21 à 23.42.58.png


Exemple for Designare removing boot delay due to thunderbolt controller (on thunderbolt patched firmware only):

Comment: disable \_GPE.TINI (Zero, RPS0, RPT0, Zero)
Find: FF5C2E5F 47504554 494E4900 52505330 52505430 00
Replace : FF
 
Last edited:
Thank you -- very useful!

Please note that this is Thunderbolt Power Delivery firmware, which is separate from Thunderbolt Functionality firmware. Power Delivery is based on TI TPS6598x chip. But Thunderbolt Functionality is based on Intel Titan Ridge chip (JHL 7540).

TPS65982 option is also included in this software! And TPS65982 is used for some of Alpine Ridge Thunderbolt 3 Devices.
 
@Loloflatsix this is the only SSDT that would work for me. I'm not sure why our current standard isn't.

@CaseySJ, confirmed working! I'm not getting DSB2 still though. I'm going to try a cold boot with a device and no SSDT to confirm. Standby.

Confirmed. No DSB2. I've got some more experiments on my list though.
 

Attachments

  • SSDT-TBOLT-NICO.aml
    1.7 KB · Views: 94
I have tried both the Raspberry Pi and CH341a.
  • On the Designare Z390, the Raspberry Pi wins hands down.
  • On the GC-Titan Ridge, both Raspberry and CH341A work just fine, but Raspberry is preferred because it provides 3.3V on SPI pins (MOSI, MISO, CLK) whereas CH341A overloads them to 5V.
MOSI = Master Out, Slave In
MISO = Master In, Slave Out
CLK = Clock
@CaseySJ
What about this CH341A model programmer that I own ? Note that on backside, we can choose voltage with the jumper (1-2 for ?! sorry I don't read Chinese and 2-3 for ?!TTL .. :) I known that.

51sg6wxbbSL._AC_SL1000_.jpg
and on front side, we have this following regulator component .. with 3.3 written :)
618KwQ5P9pL._AC_SL1000_.jpg
Capture d’écran 2020-03-21 à 14.41.44.png
 
Last edited:
@CaseySJ
What about this CH341A model programmer that I own. Note that on backside, we can choose voltage with the jumper (1-2 for ?! sorry I don't read Chinese and 2-3 for ?!TTL .. :) I known that.

and on front side, we have this following regulator component .. with 3.3 written :)
@Elias64Fr,

My CH341a has the same writing on the back, but I have already done this:
  • Connect Jumpers 1-2 and measure voltages with multi-meter:
    • MISO, MOSI, CLK are 5V
  • Connect Jumpers 3-4 and measure voltages:
    • MISO, MOSI, CLK are 5V
So moving the jumper has no effect!

On AMS1117 voltage regulator chip, the middle pin is 3.3V, but it is not being connected to MISO, MOSI, CLK.
 
@Elias64Fr,

My CH341a has the same writing on the back, but I have already done this:
  • Connect Jumpers 1-2 and measure voltages with multi-meter:
    • MISO, MOSI, CLK are 5V
  • Connect Jumpers 3-4 and measure voltages:
    • MISO, MOSI, CLK are 5V
So moving the jumper has no effect!

On AMS1117 voltage regulator chip, the middle pin is 3.3V, but it is not being connected to MISO, MOSI, CLK.
@CaseySJ
MISO MOSI CLK are supplied only by CH341A depending on power supplied on its Vcc pin.
That means MISO MOSI CLK are dynamic signals and shouldn't have to be connected on 3,3 DC voltage.
If we have a regulator on this board that mean it is only for CH341A power supply (no other active component onboard).

But It is probably a design mistake on Jumper layout !!

Here we have board schematic :
ch341a_miniprogrammer.png
 
Please check all Thunderbolt BIOS parameters, including: GPIOForcePwr --> Enabled. Feel free to take a screenshot of the Thunderbolt BIOS page as follows:
  • Insert FAT32 USB flash disk.
  • Go to BIOS Setup.
  • Press F12 (Print-Screen) to capture the current screen. It will be saved as a BMP file (I believe) on the USB disk.


Hi ,

my UAD thunderbolt 3 doesn't work yet

have you got a idea i have latet bios and i don't have now GPIOForcePwr option

can you help me pease
 
Back
Top