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

[Loloflatsix]

Thanks -- no need to do further tests. The original firmware should be flashed back until we can generate another version...

Thanks , OK let’s go

 

[Elias64Fr]

I don't think so. With a simple TB3 device (like Apple Gigabit Ethernet adapter) connected, my Designare Test Bench has about a 1 second gap. With a more complicated device with more ports such as Belkin Dock Pro, it's perhaps 2 seconds or so... Not very noticeable.

@CaseySJ @S1lla
OK, It seem to be native TINI method called at the boot that make a little more time to boot thunderbolt controller.

I have a Clover/OC patch to solve that on Z390 Designare. Now I have no slow down

Comment: disable \_GPE.TINI (Zero, RPS0, RPT0, Zero)
Find: FF5C2E5F 47504554 494E4900 52505330 52505430 00
Replace : FF

 

[NorthAmTransAm]

@CaseySJ
This morning I flashed the TBEX3 without warning and problem.
A reboot in BIOS in peripherals the TBEX3 isn't dead.
So i booted on MacOs but no Thunderbolt PCi on IOReg
In windows too in peripherals system I don't appears
Perhaps may I install the Alpine Ridge drivers , I will see if it works

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!

 

[bugsyraz]

He didn't brick the motherboard. He's playing with a lifetime supply of Winbond chips that he's soldering to the motherboard. He is on a different playground from the rest of us!

The preferred option for Designare Z390 is the Raspberry Pi. However, flashing a chip does incur risk. We ask everyone who's considering this option to evaluate the risk for themselves.

Thanks for clearing this up, Casey! The question in this case would be though, how likely is it to brick this?

Is this just at risk of bricking the chip or bricking the whole motherboard?

 

[svandive]

I have both a Titan Ridge AIC (Gigabyte) and my Designare z390 that eventually I want to get flashed. I'm looking at purchasing a second Designare as a backup. I also have a couple Raspberry Pi 4b that I can use for flashing. While I'm gathering together necessary items I wanted to check and see if folks think the programing for the AIC and the Mainboard would be easier and more successful using the Raspberry Pi or the Ch 341a USB programer?

 

[CaseySJ]

@Elias64Fr,

Yesterday I tried using Linux to flash the Thunderbolt controller on my primary Designare with the original firmware. Some notes:

• If we flash the Thunderbolt firmware with an external flasher to make it Mac compatible, then this device will disappear from Linux:
  • /sys/bus/thunderbolt/devices/0-0/active_nvm0/nvmem
• This is only an issue if we want to flash the original firmware back by using Linux.

But with original Thunderbolt firmware:

• We can use dd to read from .../0-0/active_nvm0/nvmem and write to ../0-0/non_active_nvm0/nvmem without any problem.
• After writing the modified firmware to non_active_nvm0, we need to send a "1" to /sys/bus/thunderbolt/devices/nvm_authenticate, but this returns:
  • ... Permission Denied
• Yes "sudo" is used, so the error most likely means that the new firmware was rejected.

I tried this using the special file you provided three days ago.

 

[CaseySJ]

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!

Does Thunderbolt Bus appear with the modified Asus Thunderbolt EX3 (after cold boot)?

 

[CaseySJ]

Thanks for clearing this up, Casey! The question in this case would be though, how likely is it to brick this?

Is this just at risk of bricking the chip or bricking the whole motherboard?

The risk is to the Thunderbolt chip, and in most cases it can be remedied by flashing original firmware back. But if we damage the pins on that chip or lightning-strike it with static or do something else that was "not part of the plan" then that's a different story.

 

[johnny7874209]

Have you fully compared the differences between flashing (a) eGPU firmware to GC-Titan Ridge and (b) flashing iMac 19,1 firmware to GC-Titan Ridge?

• eGPU is a peripheral device
• iMac 19,1 is a host device

In your IORegistry screenshot, I notice that RP05.UPSB.DSB2 has no USB ports showing. Was that screenshot taken with:

• iMac19,1 firmware on GC-Titan Ridge?
• eGPU firmware on GC-Titan Ridge?

I also notice that your SSDT does not define USB ports HS01 and HS02. Please see the sample SSDT located in the GC-Titan Ridge DROM Micro-Guide.

The screenshots I attached with are based on iMac19,1 firmware on GC-Titan Ridge. As for eGPU firmware on GC-Titan Ridge, it can only 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

I also notice that your SSDT does not define USB ports HS01 and HS02. Please see the sample SSDT located in the GC-Titan Ridge DROM Micro-Guide.

Thanks for your notice, I'll edit my SSDT soon.


---------------------------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 only 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.

 

[CaseySJ]

I have both a Titan Ridge AIC (Gigabyte) and my Designare z390 that eventually I want to get flashed. I'm looking at purchasing a second Designare as a backup. I also have a couple Raspberry Pi 4b that I can use for flashing. While I'm gathering together necessary items I wanted to check and see if folks think the programing for the AIC and the Mainboard would be easier and more successful using the Raspberry Pi or the Ch 341a USB programer?

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