Hardware validation against an RX 7900 XTX (navi31 / psp_13_0_0)

Card driven directly over a USB<->PCIe bridge (root@192.168.1.200, tinygrad, no amdgpu binding). Four open questions were taken to silicon. Two produced results, one is not host-observable, one needs a build that does not exist yet. Recorded with the boundary of each stated, because "checked on hardware" means nothing without saying what the host can actually see.

1. Ring status codes: emulator vs silicon -- 7/9 exact

The host's only PSP interface is the GFX ring (LOAD_TA, INVOKE_CMD, GET_FW_ATTESTATION, ...). Submitting commands and reading resp.status:

0x100 = unknown command id, 0x117 = bad session/TA, 0x5 = bad parameter.

The two differences are NOT reportable as firmware divergence. They are the only two state-dependent paths in the set: hardware has a live TMR and loaded TAs, while fuzz_sos_ring's harness is a bare sOS with neither. Inputs were equalised (buf_size=0x400 on both sides, after finding tinygrad leaves it 0) and they still differ, which is consistent with differing internal state, not differing code. Equalising that state is what would make the comparison sound.

Extraction trap worth keeping

Three successive attempts to read the emulator's status were wrong, and each produced a confident, entirely fake comparison table:

• R0 after tee_cmd_dispatch -- returned 0x206164, a code address;
• ring frame +20 -- gave a clean 0 for every command, which was my own input echoed back. A sentinel (0xDEADBEEF) proved sOS never writes there, and would have been reported as "emulator says 0 for everything, hardware says 0x100" -- a fabricated divergence;
• the real location is resp.status at offset 864 of the 1024-byte host command buffer, confirmed independently on both sides (ctypes offset on the host, sentinel-overwrite in the emulator).

The sentinel is the whole reason this table is trustworthy. Any future emulator-vs-hardware comparison must sentinel the output location first.

2. TA versions: our RAS is the card's RAS, byte for byte. The others are not.

/lib/firmware/amdgpu/psp_13_0_0_ta.bin carries four TAs. Comparing each container body (strip the 0x100 header) against our extracted images:

Full RAS hash, both sides: db2ed53ef8e5c92f8a011219191931cd93a6b473d42470a9dd1d4d2056b58385

This cuts both ways and both directions matter:

• RAS findings apply to this silicon directly. The TA we have been emulating is bit-for-bit the one this card loads.
• HDCP, DTM and ASD findings are against versions this card does not run. That is a scope qualification on the largest body of work in the tree (the HDCP fuzzing), and it was not previously stated anywhere. Our vdiff directory holds HDCP 23.0.0.49/.70/.82 -- the card runs .63, which we do not have in the tree at all.

The card's own HDCP/DTM/ASD bodies are extractable from this blob, which is the cheap way to make the existing harnesses hardware-relevant.

3. SYS_DRV RPC opcode 0x3141 -- not decidable from the host

The remaining emitter candidate was the host driver. It is architecturally the wrong place: the host speaks GFX ring commands, while 0x3141 is a TA -> SYS_DRV RPC internal to the PSP, on a path the host never addresses.

Checked anyway. amdgpu.ko (28 MB, decompressed -- the first attempt ran lzma on a .zst, silently searched compressed bytes and returned a meaningless 0) contains the dword 37 times, all in mov eax,[rax+8]; add eax,0x3141 register-offset arithmetic, none string-like, none an RPC emission. Controls passed (amdgpu 11354 hits, psp 696).

So the static negative from the module is real but does not bear on the question, and the dynamic question is unanswerable from the host. The emitter search result stands as recorded in OBSERVATION-SYSDRV-3141-NULL-PTR-NONZERO-LEN.md.

4. sOS gate semantics -- not host-observable at all

SVC permission checks and pointer region validation happen inside the PSP, between a TA and sOS. The host cannot issue an SVC, cannot observe one, and cannot read PSP SRAM. There is no host-side oracle for these, so hardware cannot confirm or refute the gate.check_ptr / gate.check_svc models. Stated plainly rather than substituting a weaker check and implying it covered them.

The same applies to the 0xE575B8 capacity blocker: it is SYS_DRV-internal state. Driving RAS commands over the ring would be indirect evidence (success would imply the context gets populated on a real boot), but tinygrad has no LOAD_TA path and building one is a real piece of work with a wedge risk. Feasible -- the signed RAS blob is present and matches ours -- but not done.

Incidental fix

vram_probe.py reported PSP heartbeat -> FROZEN on a perfectly healthy card: it sampled the counter three times back-to-back, and the counter ticks ~132/s (~7.6 ms per tick), so all three reads landed inside one tick. Measured with 500 ms spacing: deltas 68/57/71/69. Patched on the box to space the samples; backup at vram_probe.py.bak. A detector that reports a working card as dead invites pointless cold-cycling.