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

[CristianP]

Some questions/suggestions:

• What is the make/model of your monitor(s)?
• Are they connected via DP or HDMI?
• Is there a small toggle switch on the Sapphire Nitro+ that flips between quiet and OC (over-clock) mode? If so, have you tried both modes?
• Which version of Clover are you using? Pressing "A" for About at the Clover Boot Menu will display the version.

Hi Casey! Thank you for your response!

• The model of the monitor is DELL U2414Hb.
• It is connected via DP.
• I see that the toggle switch is broken (lucky me..) and I guess I am stuck on the "Silent" bios since it is 1340mhz on both clocks.
• The version of clover when the "freeze" started was r5112 and I have updated to r5114.

 

[CaseySJ]

Hi Casey! Thank you for your response!

• The model of the monitor is DELL U2414Hb.
• It is connected via DP.
• I see that the toggle switch is broken (lucky me..) and I guess I am stuck on the "Silent" bios since it is 1340mhz on both clocks.
• The version of clover when the "freeze" started was r5112 and I have updated to r5114.

Are you still experiencing random freezes? Just to be clear, these freezes require reboot (i.e. they are not momentary freezes that unfreeze after a second or two)?

Feel free to compress and upload your CLOVER folder, but remove serial numbers from SMBIOS section of config.plist before uploading.

 

[gandem]

Good to know! Can you please clarify:

• After setting both monitors to DP 1.1 (via on-screen menu in the monitor) the dual-monitor system started to work again (even at 4K 60)?
• What is the make/model of the monitor(s)?

Interesting. I think I'll this a try this evening to see if it affects my monitor situation.

 

[juantrix]

Sure, please try the modified NVM 50 for GC-Titan Ridge attached here. Because I don't currently own Thunderbolt monitors, I cannot say whether this will work.

I tested NVM50 with GC-Titan ridge to 34WK95U (5k2k). I can enable HDR but only at 4k.
With NVM23 EliasFR support 5k res but no HDR.

Over DisplayPort _DisplayVendorID-1e6d_kext:

Over Thunderbolt:
Dual display detected(bug?) (but HDR enable at 4k).

How can I join dual DP to support max res to enable 5k over thunderbolt cable?

 

[CaseySJ]

...
How can I join dual DP to support max res to enable 5k over thunderbolt cable?

Have you already tried this?

• Connect DP cable from GPU to DP-In #1 on GC-Titan Ridge
• Connect DP cable from GPU to DP-In #2 on GC-Titan Ridge
• Connect Thunderbolt cable from Port 1 on GC-Titan Ridge to your LG UltraFine 5K

 

[iRamon]

@iRamon,

Sorry to hear that. After Step 1 in which flashrom said "VERIFIED", the chip was correctly programmed. In Step 2, the missing SSP1 and SSP2 ports were probably due to Thunderbolt SSDT. It would have been best to stop and report the problem here because we would troubleshoot that by examining the system log as follows:

log show --last boot | grep ACPI

We would also have looked at the complete IOReg file to determine if flashing itself was okay.

Suggestions:

• Run IORegistryExplorer and capture a screenshot of RP05. I suspect there won't be much there, but let's have a look.
• In the worse case it is possible to desolder and replace the Thunderbolt chip. But we should ask an experienced technician to do this. A local PC repair shop might have everything on-hand, including replacement W25Q80DVIS chips and the ability to flash them. They will just need the Thunderbolt firmware you captured from the chip.
• Because you created 3 backup files of the firmware, please type the following in Terminal: strings Backup1.bin and post just the last 25 or so lines of the output.

P.S. That is probably the best example of problem-reporting I've seen so far. Exceptionally detailed and organized.

Thanks @CaseySJ for helping out and thinking along.

During troubleshooting before clearing CMOS, I have saved screenshots of RP05 and a full dump from IOReg on my Desktop. However, since clearing CMOS I was no longer able to boot into macOS, so I can't access those files or create new ones.

My system is currently still disassembled to allow access for flashing. I will try reassembling and booting, but I it's possible/likely macOS still won't boot.

In my flashing attempts I created many ROM backups, with many different checksums. Due to the sheer amount of reads/backups (in total I'm guessing 100+), I deleted backups and reused backup filenames (overwriting existing backups).
I did save some ROM backups in seperate folders though. Based on timestamps and checksums, the earliest consistent backups (from day 1, around the first attempts) have a checksum of 35aa1ad94d61b67556f926184249130f97d1fec8. The last 25 lines of strings Backup1.bin output for that backup are in the spoiler below:

Spoiler: Strings Backup1.bin - last 25 lines

C8C(bvH,0
)k(j
C8C(bpH00
`L j!
C bRH
cakP
CYH40
C`b`j#!
C`bajKH$0
KIIK
 `q 
`j2I
C`b(H@8Ak
!`=(h
C(`!k
`pG@
Fc][
pGpG
a0566aa071c0a0cabf803a9532caee53ddd2ced5_03012018
MKJGHIL
UNKNOWN
APP `
TPS65983 HW     FW0001.38.04 ZTBT1
ACE0

Assuming TB ROM firmwares are identical across Z390 Designare boards, shouldn't their backup checksums also be identical?

If so, if you have a checksum for the original dumped ROM, it's way easier to spot which backup is the correct one. This original ROM checksum would also help in the programming process to know exactly when a read operation extracted the ROM correctly.

I plan on performing these next steps:

1. Make a few final attempts to flash the chip, starting from scratch with the breadboard/capacitor/resistor wiring (which gave the initial succes), trying both the Backup1.bin from above and the patched firmware.
2. Regardless of the outcome of step 1, reassemble the system and attempt booting again.
3. Last resort is to take the board to a local PC repair shop to have the chip reprogrammed and/or replaced.
   Instead of flashing the original firmware (Backup1.bin), I would rather opt to have them flash the patched firmware.

I will report back and consult you before moving to step 3.

Fingers crossed!

 

[CaseySJ]

Thanks @CaseySJ for helping out and thinking along.

During troubleshooting before clearing CMOS, I have saved screenshots of RP05 and a full dump from IOReg on my Desktop. However, since clearing CMOS I was no longer able to boot into macOS, so I can't access those files or create new ones.

My system is currently still disassembled to allow access for flashing. I will try reassembling and booting, but I it's possible/likely macOS still won't boot.

That boot failure screenshot is a common issue with 10.15.4. Please let me know if the problem persists after reassembling the system. That boot problem is not due to any Thunderbolt patching activity.

In my flashing attempts I created many ROM backups, with many different checksums. Due to the sheer amount of reads/backups (in total I'm guessing 100+), I deleted backups and reused backup filenames (overwriting existing backups).
I did save some ROM backups in seperate folders though. Based on timestamps and checksums, the earliest consistent backups (from day 1, around the first attempts) have a checksum of 35aa1ad94d61b67556f926184249130f97d1fec8
The last 25 lines of strings Backup1.bin output for that backup are in the spoiler below:

Spoiler: Strings Backup1.bin - last 25 lines

C8C(bvH,0
)k(j
C8C(bpH00
`L j!
C bRH
cakP
CYH40
C`b`j#!
C`bajKH$0
KIIK
`q
`j2I
C`b(H@8Ak
!`=(h
C(`!k
`pG@
Fc][
pGpG
a0566aa071c0a0cabf803a9532caee53ddd2ced5_03012018
MKJGHIL
UNKNOWN
APP `
TPS65983 HW     FW0001.38.04 ZTBT1
ACE0

Assuming TB ROM firmwares are identical across Z390 Designare boards, shouldn't their backup checksums also be identical?

If so, if you have a checksum for the original dumped ROM, it's way easier to spot which backup is the correct one. This original ROM checksum would also help in the programming process to know exactly when a read operation extracted the ROM correctly.

Yes their checksums should be the same. Here's the checksum from my original firmware file:

c8d46c49c43da200b7fd7390cc09531e5e7163a4  Gigabyte-Z390-Designare-TB3-ROM.bin

I plan on performing these next steps:

1. Make a few final attempts to flash the chip, starting from scratch with the breadboard/capacitor/resistor wiring (which gave the initial succes), trying both the Backup1.bin from above and the patched firmware.
2. Regardless of the outcome of step 1, reassemble the system and attempt booting again.
3. Last resort is to take the board to a local PC repair shop to have the chip reprogrammed and/or replaced.
   Instead of flashing the original firmware (Backup1.bin), I would rather opt to have them flash the patched firmware.

I will report back and consult you before moving to step 3.

Fingers crossed!

In step 1: When PSU is connected to motherboard with 24-pin cable and PSU is switched on (not motherboard, but PSU), then and only then should Vcc Pin 8 be disconnected.[/code][/quote]

 

[CristianP]

Are you still experiencing random freezes? Just to be clear, these freezes require reboot (i.e. they are not momentary freezes that unfreeze after a second or two)?

Feel free to compress and upload your CLOVER folder, but remove serial numbers from SMBIOS section of config.plist before uploading.

Up until this point I had no freezes. Yesterday I tested if my Universal Audio Apollo Twin MKII makes the computer freeze when I turn it ON/OFF but it seems that that is not the case.

Indeed, these freezes require reboot, the computer does not "unfreeze" itself. Also, if I turn on the computer before I turn on my display I get no image until I reboot. This strange issue I think it's related to DP since my other machine does the same thing with the same monitor and it's a completely different configuration (Motherboard: Gigabyte Z170, CPU:i5 6400, GPU: nVidia 1050Ti, 16GB RAM).

I have attached the CLOVER folder here. Thank you for all your help, you deserve a lot of beers!

 

[iRamon]

That boot failure screenshot is a common issue with 10.15.4. Please let me know if the problem persists after reassembling the system. That boot problem is not due to any Thunderbolt patching activity.

Thank you! I'll report back with my findings once I'm ready to boot my system again.

Yes their checksums should be the same. Here's the checksum from my original firmware file:

c8d46c49c43da200b7fd7390cc09531e5e7163a4  Gigabyte-Z390-Designare-TB3-ROM.bin

That is very helpful. I'll check if any of my ROM backups have the same checksum. The one I posted in my last reply has a different checksum, indicating that my reads were corrupted.

In step 1: When PSU is connected to motherboard with 24-pin cable and PSU is switched on (not motherboard, but PSU), then and only then should Vcc Pin 8 be disconnected.

I believe I did things in reverse order: disconnect VCC pin 8 before powering on the PSU!

Catching up on posts from the last couple of days, I found these posts quoted below for a similar "unknown status" issue, and with a possible fix ... Will also check if that solution works for re-flashing my chip.

@CaseySJ : Actually, this is a bad news / good news scenario. The bad news is that I was wrong about pin 8. I was finally able to get the chip to read with VCC on pin 8. I think this pomona clip is more sensitive than I realized. The good news is that with some fiddling and VCC attached I was able to read and write the flash to chip! Thanks for all the help!

Awesome! I see that you updated your previous post regarding Vcc (pin 8). Pin 8 is absolutely necessary for erasing/writing if another power source is not used.

 

[gandem]

@CaseySJ

So, disabling DP 1.2 on my monitor has brought it to life- but only connecting 30hz. So this limitation is from coming from the patched firmware? Do you think there is any way around it?

On another note, I have tested out the hot swap and eject capabilities on this patched NVM 50 firmware with a couple of Lacie Rugged SSD's that are TB2. No problems ejecting and then disconnecting drive- I don't receive any disconnect errors from MacOS. I still receive this error on my old TB1 GoFlex, but I'm writing that off as legacy.