This is a short one — a field note, not a benchmark post. But it closes a loop I left open last week, where I said I'd try to unlock ROCm on this board by flashing firmware. I started cheaper than I threatened, and here's how it went.
The setup, briefly
My Bosgame M5 (Sixunited AXB35-02 board, Ryzen AI MAX+ 395, gfx1151) cannot run ROCm. Every attempt to load a sizeable model into the GPU under ROCm dies with the same non-recoverable HSA fault — Memory critical error by agent node-0 … Reason: Memory in use — fired during the GPU's queue/scratch setup, before the model is even resident. That's ROCm issue #6182, and it's the reason everything I publish runs on Vulkan instead.
The important detail is that this is board-specific, not chip-specific. The exact same silicon runs ROCm fine on other machines — kmarble's Minisforum MS-S1 Max, for instance, same gfx1151, ROCm working. The #6182 report narrowed the difference to the board/firmware side and flagged the obvious diagnostic: the same physical AXB35 board ships as the GMKtec EVO-X2 with a different (GMK) BIOS, so cross-flashing that BIOS onto a Bosgame is the natural test of whether firmware is the cause.
So firmware is a candidate cause. The question is which firmware change, if any, moves the needle. There's a ladder of escalating risk:
- Bosgame's own newer BIOS — same vendor, official update, low risk.
- Cross-flashing a rival OEM's BIOS (GMK's, onto a Bosgame) — unsupported, higher risk.
- Below the BIOS entirely — silicon revision, board traces, the EC — in which case no flash helps.
I started at rung 1, because it's the cheap one.
Rung 1: the newest official BIOS
The #6182 report was filed in late April against BIOS 1.07 (September 2025) — at the time, the only BIOS Bosgame had ever shipped. Since then Bosgame has put out 1.09 (May 2026), newer than anything the report could have tested. No changelog published, so no way to know in advance whether it touches the memory-init path. But it's an official same-vendor update on the supported path, so the only way to find out is to flash it and re-run the exact thing #6182 dies on.
I flashed it, booted, and confirmed the 96 GB VRAM carveout had survived the flash — photograph your BIOS settings first regardless, since a flash can reset them. Then the smoke test: load a sizeable model into the GPU under ROCm, watch for the fault.
It faulted. Same signature, same point in the queue setup, same as on 1.07. Bosgame's newest BIOS does not fix #6182.
Why the negative is useful
A null result that rules something out is still information. This one collapses the most hopeful branch of the tree: "Bosgame just needs to ship a newer BIOS." They did. It doesn't help. Anyone on a Bosgame M5 waiting for a firmware update to quietly fix their ROCm problem can stop waiting — at least through 1.09.
What's left is narrower and more interesting:
- Either a cross-OEM BIOS (GMK's, rung 2) hits a different memory-init path than Bosgame's own firmware line — in which case firmware is the lever, just not Bosgame's firmware — or
- The fault sits below the BIOS, in the silicon revision or board traces or EC, and no BIOS flash of any origin will fix it.
The cross-flash is the only remaining test that distinguishes those two. Which brings me to why I'm not doing it this week.
Why the cross-flash is parked (and the recovery reality)
Rung 2 — flashing GMK's BIOS onto a Bosgame — is community-confirmed to work (the AXB35 firmwares are cross-compatible), but it is emphatically not supported, and the failure mode is unforgiving. This board has no recovery mechanism. No BIOS flashback button, no dual-BIOS. If a cross-flash corrupts the ROM to the point the board won't boot, your only path back is reflashing the chip directly with an external programmer.
And that path has a detail worth knowing before you order anything, because it's the kind of thing that quietly destroys your recovery kit: the BIOS ROM is a Winbond W25R256JWEQ, and it runs at 1.8 V, not 3.3 V. A CH341A programmer ships configured for 3.3 V. Drive this chip at 3.3 V and you can kill it. You need a 1.8 V adapter, plus a WSON8 probe in the 8×6 mm variant specifically (the 5×6 mm one and the clip bundled with the programmer don't fit), plus the chip lives on the back of the board, so recovery means full disassembly.
There's also a fresh reason to doubt the upside. While I was writing this, an EVO-X2 owner — same AXB35-02 board, already on the GMK BIOS I'd flash to — reported on the thread that ROCm there hits a different wall: a hard ~30 GB allocatable ceiling, anything larger failing to allocate, and they're on Vulkan too. That's not my fault — mine is the queue-setup crash, theirs is an allocation limit — but it means the best case for a cross-flash isn't obviously "working ROCm." I might just trade my crash for their ceiling and land exactly where I am.
For a box that's also my production inference node, disassembling it to cross-flash a rival's firmware — on the chance it dodges the bug — is not a Thursday-evening gamble. The expected value isn't there right now: ROCm working would be nice, but Vulkan already carries my whole stack, and last week's numbers showed the Vulkan-only ceiling isn't even a meaningful handicap at full context. So the cross-flash is parked, with the recovery kit speced out, to revisit later this year if AMD hasn't moved on #6182 by then.
Reported upstream
The report itself raised a question AMD never resolved: whether the fault is gated on BIOS version. My 1.09 result speaks directly to it — the newest Bosgame BIOS changes nothing. I'm adding that data point to the thread (which has since reopened); it's the cheapest contribution I can make to a bug that's shadowed this whole series, and it closes off one branch the reporter explicitly left open.
The larger question — whether a board AMD markets as a first-class ROCm citizen should require any of this, six months into shipping — is for the next post. There's a new wave of Strix Halo hardware landing right now with the same first-class-ROCm framing, and I've got six months of production reality to hold up next to it.
Discussion