Spent the day trying to untangle firmware weirdness on my Arc B580.
Arc splits its firmware into several layers: PCode, GSC, OpROM code/data, GuC, and HuC.
If one of them fails early enough, the whole graphics stack dies before /dev/dri even exists.
(New GPU firmware stacks are annoyingly complicated, but Intel exposing these layers publicly made debugging possible.)
In my case, it looked like the previous owner corrupted the GSC firmware somehow.
Every cold boot caused the xe driver to fail during early initialization while interacting with PCode,
so the card never came online properly.
xe hangs immediately after "deactivate VGA console"lspci after reseatingAt one point it looked more like hardware damage than firmware corruption. I checked for obvious shorts on 12V and 3.3V rails, and measured resistance/voltages on Vcore, memory, and memory controller rails. Nothing abnormal showed up, but that's the extent of my EE knowledge.
Using Intel's igsc tool compiled from source, I was able to access the Graphics Security Controller
through /dev/mei1 and reflash the GSC firmware from 21.1137 to 21.1182.
There's also a separate upstream bug in the Linux 6.17 xe driver where the GuC scheduler
crashes at idle on Battlemage. As far as I can tell it has nothing to do with the firmware problem.
Between xe, Mesa, fwupd and igsc, I could recover the card without switching to Windows,
which wouldn't have been possible on Linux not long ago.
Firmware distribution is still a mess, though. The firmware for my ASRock card isn't on LVFS yet, so some regions may still need the vendor's Windows flashing tools.
Also collected VRM rail resistance measurements during debugging if someone needs it(provided i didnt delete the pics from my phone lol).
Board / teardown / reference images: