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

[CaseySJ]

Something wicked this way comes...

Gigabyte's Z490 Motherboard Lineup Shows Up Early

Gigabyte's upcoming lineup of Intel 400 Series Z490 motherboards has showed up online early. The leak includes pictures and some motherboard specs including future PCIe Gen 4.0 support and compatibility with both Intel 10th Generation "Comet Lake" CPUs and future 11th Generation "Rocket Lake"...

www.tonymacx86.com

Source: techpowerup.com

 

[noname0]

@scottkendall, have you tried the minimal 3 patch approach on the active partition of the Rev1?

2727->3737 at offset 0x35 (decimal 53)
A0 -> 20 at offset 0x81 (decimal 129)
FFFFFFFF -> 8680D315 (or whatever your controller device-id is, byte reversed) at offset 0xBA0 (decimal 2976)

It has worked on all the Alpine Ridge firmware I've tried so far (Intel Hades Canyon15d3 and Asrock Z370 itx/ac 15c0)

@dgsga @CaseySJ @scottkendall: I would be happy to start digging into the firmware and patching it myself. Is there some documentation / summary of the reverse engineering progress so far? Will give it a try to just follow the instructions but I usually prefer to try to understand what's happening.

 

[karambit]

Because you're following the Mojave-to-Catalina upgrade guide, all kexts are located in the ZIP file attached to the Catalina Mini-Guide. You're always welcome to contribute to the site by clicking the Contribute button at the very top left of the web page.

Is my only option to Revert or is there something I can Modify in the Clover Boot menu to keep my progress?
If Reverting, do I need the backup I created in Step one of the Micro-guide ?

 

[CaseySJ]

@dgsga @CaseySJ @scottkendall: I would be happy to start digging into the firmware and patching it myself. Is there some documentation / summary of the reverse engineering progress so far? Will give it a try to just follow the instructions but I usually prefer to try to understand what's happening.

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?
  
• Thunderbolt Header connected?
• The second PCie 3.0 long slot appears in IOReg as RP05?
• Operating system: Mojave or Catalina?

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

 

[CaseySJ]

Is my only option to Revert or is there something I can Modify in the Clover Boot menu to keep my progress?
If Reverting, do I need the backup I created in Step one of the Micro-guide ?

You can try this:

• Connect the backup disk.
• Reboot computer and press F12 at BIOS splash screen to open the BIOS boot menu (not Clover boot menu).
• Select the backup disk from this menu.
• Now Clover Boot Menu will appear.
• Boot macOS from the backup disk because that disk should have the Ethernet kext.
• Then download/copy IntelMausiEthernet.kext to the CLOVER/kexts/Other folder in the EFI partition of the USB flash disk.
• Reboot, disconnect the backup disk, and press F12 at BIOS splash screen to select the USB flash disk.
• At the Clover Boot Menu, boot macOS from the internal SSD.

 

[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 [email protected], 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.