1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
# Card recovered — it was the dual-BIOS slot, not anything we did
**Outcome:** the card works again. The fix was a **physical BIOS selector switch**
on the board. Nothing in software fixed it, and nothing in software broke it.
```
AMDev OPENED
vram_size = 0x5ff000000 (24560 MB)
PSP version = 0x310036
compute = 4096.0 (sum of 2x+1 over 0..63, numerically correct)
```
Stable across a PCIe link reset.
---
## The two BIOS images
The selector switches between two 2 MiB images that differ by only **3,525 bytes
(0.17%)** — same firmware, different build/state.
| | **BIOS-2 (selected now, WORKS)** | **BIOS-1 (previously selected, STUCK)** |
|---|---|---|
| sha256 | `ca37959e9f60d54b3e1b2862077d8b11` | `b2c77f1dad76f614e3e0195b8158c976` |
| **ISH B generation** | **`gen=1`** | **`gen=0`** (stale) |
| ISH B checksum | `0xd70a0f40` | `0xd6fc0f3f` |
| `$AMDVBFL` @ `0x7000` | absent (zeros) | present |
| cold boot | trains memory, `MEMSIZE=0x5ff0` | never trains, `MEMSIZE=0x0` |
Largest differing region is `0x13000–0x1a0ff` (28,928 bytes) — starting exactly at
**ISH B**.
## We did not cause it
`psp_out/spiflash.bin` — a dump predating this session's work — is **BIOS-1**
(8 differing bytes: only the `$AMDVBFL` marker), and it **already had ISH B
`gen=0`**. So the stale slot was present before anything we ran.
That also explains the whole episode: BIOS-1 likely could never complete a cold
boot. The card appeared healthy only because it was carrying initialised state
forward — our short 2.5 s link blips preserved it, and the first genuine cold cut
exposed it.
## Files
| file | what |
|---|---|
| `flash_BIOS2_KNOWNGOOD_20260917.bin` | current, working slot |
| `flash_BIOS1_STUCK_20260917.bin` | the stuck slot (byte-exact, restored by us) |
| `spiflash.bin` | BIOS-1 before the marker was written |
---
## Corrections to conclusions made during the investigation
1. **ISH B `gen=0` is NOT benign.** I checked its fletcher32 and found it valid, and
concluded the slot was fine. Internal consistency is not validity — the working
BIOS has `gen=1`. This is very likely why `ifwi-all` died at **item `0x7` (ISH B)**
with `error=0x11`: the PSP was rejecting a stale slot, and the tool was faithfully
sending it.
2. **`$AMDVBFL` absent is the healthy state** — the opposite of the direction I pursued
for several rounds. The working image has zeros at `0x7000`. I still would not claim
the marker *causes* anything (`vbios_flash_verify` writes it as an output, and it
lies in a gap no directory covers); both it and `gen=0` look like symptoms of BIOS-1
being left mid-update.
3. **"No VBIOS POST in this setup"** — my leading theory late in the investigation —
was wrong. BIOS-2 cold-boots and trains memory over the same bridge, same host,
with no PC POST involved.
4. **The `notes.md` resume-path DF-scratch theory** was also not the cause; the card
recovered without touching it, after measured cold cycles had already failed.
5. **My "flipper firmware IS present" claim was unsound** — a clean build with no
`0xF4` handler also ACKs `0xF4`, so that test never discriminated.
## What actually held up
* Flash integrity work was sound: byte-exact restore verified by two independent
read engines, AMD's own fletcher32 validating on `$PSP` directories and ISH headers.
* The PSP-liveness analysis was correct: the bootloader was genuinely alive and
healthy throughout, stuck only in requesting off-chip item `0x80`.
* The access inventory was accurate for the state it described.
The lesson worth keeping: **every software layer was measured and eliminated, and the
fault was still physical.** When a fault survives a byte-exact flash restore, a clean
bridge reflash, and measured cold power cycles, the remaining explanation is hardware
state — which here meant a second flash image selected by a switch nobody had mentioned.
## If BIOS-1 is ever wanted back
BIOS-2 is a known-good donor but **not** a byte-identical build, so it cannot be blindly
copied over BIOS-1. The minimal, targeted repair would be ISH B (`0x13000`, and its
`gen`/checksum), written with the card running on BIOS-2 so the other slot is idle.
Not attempted.
|
