amd-psp-re.git/psp_out/FINDING-RING-LOADTA-WORKS-RAS-SPECIFIC-FAILURE.md, branch main

Record the inconclusive attempt to find RAS's init parameter source

2026-09-24T12:35:31Z

Tried to identify what legitimately produces the word RAS receives as 0, by reading sOS's init parameter block around 0x202D24 -- [r4+1] (the 0xff gate that decides whether params get filled at all), [r4+4], [r5+0x30], and the assembled block at the send. Every read fails with a Unicorn error: these are sOS virtual addresses and uc.mem_read does not resolve them in that hook context. The measurement says nothing about the firmware, so nothing is concluded from it in either direction. Recorded rather than discarded, because the failure mode is non-obvious and the next person would otherwise spend the same effort rediscovering it. The next attempt needs the VA->PA resolution first, which the harnesses already do elsewhere for TA address spaces.

RAS authors 0xffff000b itself; locate the single fix-point, do not patch it

2026-09-24T11:59:33Z

Ruled out the timeout reading first: both TAs execute during the send (HDCP 9 blocks, RAS 13), so RAS runs its handler and answers rather than going silent. Mechanism, from RAS's own code: 00402c6c bl #0x402ed0 00402c70 cbz r0, #0x402c94 ; callee returned 0 -> error 00402c94 ldr r0, [pc, #0x30] ; lit = 0xffff000b 0x402ed0 scans its argument for the first nonzero nibble and requires it to be 5, 6 or 7. RAS receives r0 = 0 as its first argument -- passed in, not read from memory (r0=0x0, r1=0x412010, r2=0x412008) -- so the callee returns 0 at once. The experiment needed its own control, and that turned out to matter. Forcing r0 at the function entry changed nothing, which reads as "hypothesis refuted": baseline 0xffff000b force r0 AFTER the call, at 0x402C70 0x00000000 <- success force r0 at entry, 0x402C64 0xffff000b <- no effect The middle row is the positive control: reg_write from a code hook does affect this TA, and supplying a nonzero value at the decision point makes the whole LOAD_TA succeed. The entry-site null is an artefact of writing a register at a translation-block boundary. Without that control I would have recorded a false refutation. So RAS's image loads and verifies, and its init declines only because one input word arrives as 0. This is an emulator environment gap, not a firmware defect, and it is deliberately NOT patched -- a forced register here would be precisely the "stub returning 0 is a silent lie" failure mode this project avoids. The remaining work is finding what legitimately produces the value; the card runs RAS 27.0.2.5 successfully, so it is observable on hardware.

Trace RAS's 0xffff000b to the TA init handshake, not the loader

2026-09-24T11:51:38Z

Continuing past 0x202CF2, tee_load_ta's sl == 2 arm checks a typeword against 0x4154, then sends command 3 (init/create) via ta_send_command at 0x202D4C and takes its return as the status. Measured for both TAs: HDCP typeword 0x4154 ok, ta_send_command -> 0x0 ring 0x00000000 RAS typeword 0x4154 ok, ta_send_command -> 0xffff000b ring 0xffff000b Both pass the gate, both reach the send; the host's status is that return verbatim. Full chain: ring LOAD_TA -> tee_cmd_dispatch (tbb @0x202922, cmd 1 -> 0x2029AC) -> tee_load_ta @0x202C24 -> bl_load_ta_image SUCCEEDS for both, r4 == 0 -> ta_send_command(cmd 3) HDCP 0x0, RAS 0xffff000b <- origin So RAS's image loads and verifies fine and the failure is the init handshake with the loaded TA. That agrees with the independent observation in this same harness that RAS's init gate at VA 0x4060E0 reads 0x00 while HDCP's reads 0x90. The remaining question is therefore not "why does LOAD_TA reject RAS" but "why does the RAS TA fail its init", a TA-side environment question -- the load trace shows sysdrv_rpc_3104/3105/1005 involvement. Recorded one caveat rather than glossing it: ta_send_command returning 0xffff000b does not prove the TA authored that code; it may be a timeout. The cheap discriminator is whether RAS's command handler executes during the send. Suite green.

Narrow RAS's 0xffff000b: not the image loader, and two hypotheses refuted

2026-09-24T11:07:24Z

Differentially traced HDCP (loads) against RAS (0xffff000b), fresh build each, filtering the idle spin loop that swamps the trace with 343k blocks of phase drift. Refuted "RAS is already loaded at boot": HDCP is equally loaded and succeeds. Refuted "RAS trips the size guard at 0x2041F2", which was the natural reading of the ta_prop_get_heap_pages trace. bl_load_ta_image has exactly one site setting error 0xb, reached from a page-count check and an available-memory check. Hooking both shows RAS never reaches it and the two TAs pass identically: combined field 0x6 against a 0x400 limit, need 0xf000, avail 0x3e0000, FITS. The runs are block-identical for 186 blocks and part at 0x2047F0, bl_load_ta_image's continuation test. r4 == 0 for BOTH, so the loader succeeds for RAS as well; HDCP loops back to +0x9c for a further segment while RAS falls out to 0x20480E and returns. In tee_load_ta the error branch at 0x202CCE is not taken for RAS, confirming a zero return, and RAS proceeds through the sl == 2 arm to 0x202CF2. So 0xffff000b is produced after the image loader, on tee_load_ta's path through 0x202CF2, with sl discriminating RAS from HDCP. The image loads fine; something downstream rejects it. Also worth recording: this trace was truncated twice by hook ranges ending exactly at the addresses that mattered (0x2029A0, then 0x204000), each time producing a plausible but wrong divergence point. Widening the range changed the answer both times.

Ring LOAD_TA works; the failure is RAS-specific, not a harness defect

2026-09-24T10:50:56Z

With Ring.response() reading the correct address, LOAD_TA over the host ring can finally be evaluated, and the picture is different again: RAS image status 0xffff000b session 0 HDCP image status 0x00000000 session 0 <- SUCCEEDS RAS, 0x40 bytes corrupted status 0x34 (52) <- signature failure all-zero image status 0x2d (45) Four distinct outcomes, so the path discriminates. LOAD_TA over the ring WORKS: HDCP loads with status 0. The earlier "LOAD_TA registers no session" was the stale readback, and the follow-on "LOAD_TA fails" holds only for RAS. The 0x34 matches the signature-verification failure code load_asd.py reports for a bit-flipped image, so verification is live and correct. It is also not "already loaded": HDCP is equally loaded at boot and succeeds. Located where it fails. tee_cmd_dispatch reaches cmd 1 via tbb [pc, r6] at 0x202922 (table 0x202926, cmd 1 -> 0x2029AC); the handler calls tee_load_ta at 0x202C24 and takes its return as the status, so 0xffff000b originates inside tee_load_ta. The sOS trace during the failing load runs through TA manifest parsing -- ta_prop_get, ta_prop_get_heap_pages, ta_prop_get_appid, bl_rpc_probe, sysdrv_rpc_3104/3105/1005 -- which points at a resource or property condition specific to RAS's manifest rather than image validity. What this unblocks: HDCP loads and returns a session over the ring, so the INVOKE_CMD path can now be exercised end to end in full_system against a TA that loads. That was what blocked command-coverage work, and it no longer depends on solving RAS first. Suite green.