Intel Arc B580 firmware debugging, part 3 (CH341A physical flash)
CH341A prep: killing the 5V line
Stock CH341A programmers are not safe to use on modern SPI flash chips without modification. Or so they say, Im doing it anyways. 3.3v feels safer than 5v when its the flashers says 3.3v operation. The board supplies 5V on the data lines by default(MOSI and MISO I believe), the SPI chip on the b580 runs at 1.8v, so after modification, you will need another 1.8v adapter to go on top
The fix was to destroy the 5V trace feeding the ZIF socket with a blade, then run a jumper wire from the 3.3V rail to the point where the 5V line used to feed. After the mod, MOSI and MISO were confirmed clean at 3.3V before the SOIC8 clip touched anything on the card(and the adapter going on) I obviously didnt have a jumper, so I just wrapped the 3.3v and 5v header with some cable organizer wires.
Dumping the SPI flash
I got to the SPI flash on the ASRock B580 Challenger with a SOIC8 clip, with the card fully powered off and out of the system. I read it three times and all three dumps diffed identical, so the capture was clean. The Asrock variant of the b580 uses a GigaDevice 8MB 25LB64ESIG
Then I got hold of a second ASRock B580 Challenger and dumped it the same way, to have a known-good bios to compare against.
Binary comparison: b580true1.bin vs b580working.bin
Both images have the same SPI layout, and these regions are byte-for-byte identical between the two dumps (Im still on the edge of whether to share it with the firmware matrix yet, but likely claude probably already has it lol):
- FPT partition structure
- fwcode version: 21.1098 on both
- FITB partition: all
0xFFon both, so neither card has anything in its backup firmware slot - Primary VBT block: 7,287 bytes, identical in both
Where they differ is the opromdata region. In b580working.bin, the OROM manifest
entry (a-OROM.man) sits at the expected offset within the $CPD partition,
correctly aligned. In b580true1.bin, that same manifest entry is shifted 16 bytes forward
from where it should be.
The OROM code build also differs between the two: build 1051 in the working image versus build 1065 in the corrupted one. My guess is the card got a partial or interrupted opromdata update at some point that shifted the manifest and never finished, which fits the card's history of occasional PCODE failures before things became permanent.
Both opromdata slots on the corrupted card (A and B) had the same 16-byte shift and were identical to each other, so there was no clean copy anywhere on the chip to recover from.
Writing the working firmware
I wrote the firmware from b580working.bin to the SPI chip with the CH341A, then read it
back and diffed it. It came back byte-for-byte identical to the source image.
Post-flash state
The card was stable enough to reach the desktop and run light stuff at 720p low. At 1080p medium it started artifacting and crashing, and FurMark gave me a DMA violation BSOD on Windows with ReBAR enabled.
After some additional reboots, these issues seemed to go away.... So likely theres some training/driver quirks that persists across my xe and arc control graphics on linux and windows machines. The good ending!
Later I added Resizable BAR support to my X99 board's BIOS for this card: ReBar BIOS mod.
Board / teardown / reference images:
