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.
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.
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:
Code:
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:
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:
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.
Regardless of the outcome of step 1, reassemble the system and attempt booting again.
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.
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:
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.
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.
Regardless of the outcome of step 1, reassemble the system and attempt booting again.
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.
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]
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!
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.
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.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.