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

[mathgeek]

OK, things took a curious turn. Wonder if any of you flashrom experts had any thoughts on how to handle the write failed, chip in unknown state error I am getting below when trying to flash my Titan Ridge card? If not, I'll see if there is a way to force a reflash and then try to go from there. Perhaps it is a hardware problem.

BTW, @CaseySJ, the chip was not found if pin 8/VCC was connected, so the below is all without pin 8 connected.

pi@raspberrypi:~/T2 $ sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -r Titan-Ridge-1.bin
flashrom  on Linux 4.19.97-v7l+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q80.V" (1024 kB, SPI) on linux_spi.
Reading flash... done.
pi@raspberrypi:~/T2 $ sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -r Titan-Ridge-2.bin
flashrom  on Linux 4.19.97-v7l+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q80.V" (1024 kB, SPI) on linux_spi.
Reading flash... done.
pi@raspberrypi:~/T2 $ sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -r Titan-Ridge-3.bin
flashrom  on Linux 4.19.97-v7l+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q80.V" (1024 kB, SPI) on linux_spi.
Reading flash... done.
pi@raspberrypi:~/T2 $ shasum Titan-Ridge-1.bin Titan-Ridge-2.bin Titan-Ridge-3.bin
ecc4ee80e7d4c48f721fd1fd15c59e53bc067025  Titan-Ridge-1.bin
ecc4ee80e7d4c48f721fd1fd15c59e53bc067025  Titan-Ridge-2.bin
ecc4ee80e7d4c48f721fd1fd15c59e53bc067025  Titan-Ridge-3.bin
pi@raspberrypi:~/T2 $ sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -w GC-TITAN-RIDGE-NVM23-Elias64Fr.bin
flashrom  on Linux 4.19.97-v7l+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q80.V" (1024 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00019002! Expected=0xff, Found=0xef, failed byte count from 0x00019000-0x00019fff: 0x326
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... FAILED at 0x00002000! Expected=0x00, Found=0xff, failed byte count from 0x00000000-0x000fffff: 0xf71c9
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom@flashrom.org, thanks!
pi@raspberrypi:~/T2 $

@CaseySJ - thanks for asking. It was very straightforward. I used the supplemental procedure and your breadboard wiring. Fortunately both the cases made it very easy to get to the chip from the back. I flashed both a primary machine and a secondary that both read cleanly the first time and had easy writes.

I'll try the GC-Titan Ridge again. It may be a bad board - I had problems getting it to work 18 months ago in a different configuration.

This is all great. Thank you!

 

[CaseySJ]

OK, things took a curious turn. Wonder if any of you flashrom experts had any thoughts on how to handle the write failed, chip in unknown state error I am getting below when trying to flash my Titan Ridge card? If not, I'll see if there is a way to force a reflash and then try to go from there. Perhaps it is a hardware problem.
...

I hate to be the bearer of bad news, but that output is bad news... I encountered the same problem on an Asus ThunderboltEX 3. Read functionality was fine, but the chip could not be erased or written. I desoldered and replaced it with a brand new chip, but the board never came back to life. If desoldering and chip replacement is necessary, it's best to have it done by an experienced technician.

It seems GC-Titan Ridge cards are scarce right now. eBay has a few, but most r(e)tailers are sold out.

FYI, we can use a higher frequency such as 4096 (spispeed=4096) to save time.

 

[mathgeek]

I hate to be the bearer of bad news, but that output is bad news... I encountered the same problem on an Asus ThunderboltEX 3. Read functionality was fine, but the chip could not be erased or written. I desoldered and replaced it with a brand new chip, but the board never came back to life. If desoldering and chip replacement is necessary, it's best to have it done by an experienced technician.

It seems GC-Titan Ridge cards are scarce right now. eBay has a few, but most r(e)tailers are sold out.

FYI, we can use a higher frequency such as 4096 (spispeed=4096) to save time.

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

 

[noname0]

Let's start over:

• Motherboard: Gigabyte GA-H170-HD3 with on-board Thunderbolt header
• GC-Alpine Ridge installed into second PCIe 3.0 long slot? -> correct
• Thunderbolt Header connected? -> correct (tried jumper as well since it was mentioned for the V3 firmware)
• The second PCie 3.0 long slot appears in IOReg as RP05? -> correct
• Operating system: Mojave or Catalina? -> Catalina (10.15.4 to be precise)

I added some short answers in the quote above.

Which devices have you tested so far?

• USB-C flash disk or other simple USB-C device?
  • Does it work when connected to either of the two Thunderbolt/USB-C ports?
• Razer Core X eGPU is a complex Thunderbolt 3 device. Do you have any simpler Thunderbolt 3 devices such as:
  • Thunderbolt 3 dock
  • Thunderbolt 3 SSD
  • Thunderbolt 2 device connected via TB3-to-TB2 adapter

USB-C devices work on either port just fine (that wasn't the case before flashing / SSDT patches). I tested a flash drive and a hard disk (USB3) as well as a Magic Trackpad and an USB2 flash drive.

The only other Thunderbolt device I own is a OWC Thunderbolt Dock and I tested that one as well - same results.

[EDIT:] I forgot to mention the most obvious other TB3 device: Same thing when I connect a MacBook Pro - Link status is changing from 0x7 to 0x1 but status stays at "no device connected" and no change in ioreg (same as with any other device I tested).

 

[CaseySJ]

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

 

[makspaints]

Hi guys,
I have a problem where my Bluetooth magic track pad not working after sleep , in system Pr Bluetooth is on and shows it is connected to track pad. What could be done? Thanks.
Edit, although it shows on I can not turn it off or make changes.

 

[CODYQX4]

@CaseySJ Some more Intel Bluetooth notes...

I reported the version issue to the dev and he said it is just the firmware and not a bug in the kext, and that functionality is not impacted.

On closer look, those with a 9560 who did not have the issue were using version 1.0.2 and not 1.0.3 of the kext.

I downgraded to confirm and it fixed the version. 1.0.2 did this:
1. Bluetooth Core Spec is 5.0 (0x9) instead of Unknown (0xA). Same for LMP Version.

2. Older firmware version. 9.256 and not 10.256.

3. 1.0.2 correctly identifies device types. Example being my magic mouse and keyboard on 1.0.3 are Miscellaneous/Unknown.

---1.0.3---
    Magic Keyboard 2:
        Major Type: Miscellaneous
        Minor Type: Unknown
    Magic Mouse 2:
        Major Type: Miscellaneous
        Minor Type: Unknown
---1.0.2---
    Magic Keyboard 2:
        Major Type: Peripheral
        Minor Type: Keyboard
    Magic Mouse 2:
        Major Type: Peripheral
        Minor Type: Mouse

In addition, on 1.0.3 the AFH Map for the devices is different, looks more generic. Also, the Class of Device is all zeroes, which is probably why the major and minor types are off in 1.0.3.

The firmware from 1.0.2 feels more proper, though who knows if there are bugfixes and performances improvements in the newer firmware that outweigh what appear to just be cosmetic issues.

Worth noting the dev is getting these firmwares from Linux (I do not know which Linux builds he is sourcing from. Some of the files were an exact MD5 match with an Ubuntu Server install I have, others were different). We may find a firmware that better matches our card than what the developer has included. I might try to compile 1.0.3 with the older firmware from 1.0.2 (I will probably gut the firmwares that 9560 doesn't need, because I am running out of room in EFI partition).

I noticed one issue today that I don't know if it was in 1.0.3 or 1.0.2 so I am going back to 1.0.3 to see if it goes away. My AirPlay menu bar item always shows. Yes, you can hide it in all cases, but it's supposed to only show when there are available devices, and there are none in my case.

 

[gandem]

Sure, attached is the original NVM 23. Let us know if this improves/fixes dual-monitor functionality.

@CaseySJ - have you experienced “Drive not ejected properly” messages with patched gc-titan ridge card? Mine will hot plug and eject, but when physically unplugged, will get this message.

 

[CaseySJ]

@CaseySJ - have you experienced “Drive not ejected properly” messages with patched gc-titan ridge card? Mine will hot plug and eject, but when physically unplugged, will get this message.

Let me ask the obvious! Are you right-clicking the disk icon on your desktop and selecting Unmount?

 

[CaseySJ]

@CaseySJ Some more Intel Bluetooth notes...

I reported the version issue to the dev and he said it is just the firmware and not a bug in the kext, and that functionality is not impacted.

On closer look, those with a 9560 who did not have the issue were using version 1.0.2 and not 1.0.3 of the kext.

I downgraded to confirm and it fixed the version. 1.0.2 did this:
1. Bluetooth Core Spec is 5.0 (0x9) instead of Unknown (0xA). Same for LMP Version.

2. Older firmware version. 9.256 and not 10.256.

3. 1.0.2 correctly identifies device types. Example being my magic mouse and keyboard on 1.0.3 are Miscellaneous/Unknown.

---1.0.3---
    Magic Keyboard 2:
        Major Type: Miscellaneous
        Minor Type: Unknown
    Magic Mouse 2:
        Major Type: Miscellaneous
        Minor Type: Unknown
---1.0.2---
    Magic Keyboard 2:
        Major Type: Peripheral
        Minor Type: Keyboard
    Magic Mouse 2:
        Major Type: Peripheral
        Minor Type: Mouse

In addition, on 1.0.3 the AFH Map for the devices is different, looks more generic. Also, the Class of Device is all zeroes, which is probably why the major and minor types are off in 1.0.3.

The firmware from 1.0.2 feels more proper, though who knows if there are bugfixes and performances improvements in the newer firmware that outweigh what appear to just be cosmetic issues.

Worth noting the dev is getting these firmwares from Linux (I do not know which Linux builds he is sourcing from. Some of the files were an exact MD5 match with an Ubuntu Server install I have, others were different). We may find a firmware that better matches our card than what the developer has included. I might try to compile 1.0.3 with the older firmware from 1.0.2 (I will probably gut the firmwares that 9560 doesn't need, because I am running out of room in EFI partition).

I noticed one issue today that I don't know if it was in 1.0.3 or 1.0.2 so I am going back to 1.0.3 to see if it goes away. My AirPlay menu bar item always shows. Yes, you can hide it in all cases, but it's supposed to only show when there are available devices, and there are none in my case.

This is very helpful. Glad to have posted the Micro-Guide...

• It certainly makes a lot of sense to build 1.0.3 with the older firmware.
• There appears to be nice separation in the code between:
  • Firmware binaries that simply get copied-and-pasted into the hardware module, and
  • Supporting kext code that performs all the housekeeping functions
• If we can track down the source of the 10.256 firmware, we might get some insight into its status and issues.