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

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

 

[CaseySJ]

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

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.

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

Sorry I should have been more precise: Vcc Pin 8 should be removed before PSU is flipped on. In other words, when PSU is supplying power, then Raspberry Pi should not be supplying power. And when RPi is supplying power, then PSU should be turned off.

 

[CaseySJ]

@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?

This may be coming from 10.15.4 itself when multiple monitors are attached. As an experiment, please try connecting the two monitors directly to the AMD GPU.

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.

Yes, write it off!

 

[bigboosh]

Hey hey @CaseySJ

After my long battle with Catalina and audio/system freezing issues, I’ve managed to solve my audio issues by swapping out the UA thunderbolt 3 card in my silver face Apollo for a Thunderbolt 2 card. The UA TB3 card in the silver face Apollo works fine on a real Mac and in windows, but is weird on a hack. The UA TB3 card in my newer, Apollo x8 works fine on the hack.

I also thought I had solved my system freezing issues, but I think it was the initial 10.15.4 update that seemed to get me more than a week of no freezing, but came back with a vengeance when I installed the 10.15.4 supplemental update. It seems that Catalina for me is too much of a rollercoaster ride with my setup, so I’ve made the tough decision to roll back to Mojave and buy an rx 580 for now and wait until things sort themselves out this year or hopefully next.

Ive already rolled back to Mojave and everything works fine except for bluetooth for some reason. It works in clover boot, but when I get to the OS it isn’t recognized. I’m using the same efi folder and config.plist that I was using for Catalina, as I can’t see any reason not to. I did add your rx580 file into the ACPI patched folder though.

Would you have any ideas about why BT wouldn’t show up for me in Mojave, assuming I’m using your lastest Catalina guide? Maybe I’m crazy for using the EFI from my Catalina build.