TRM Part 2 chapter 2 (DMC, 522 pages) reveals the offsets we poll at
+0x10080/+0x10090/+0x10514 are NOT PHY firmware scratch regs as our
earlier analysis guessed. They are uMCTL2 controller registers:
+0x10080 = DDRCTL_MRCTRL0 (Mode Register Control)
+0x10090 = DDRCTL_MRSTAT (Mode Register Status — wait for MR complete)
+0x10514 = DDRCTL_DFISTAT (DFI Status — wait for PHY handshake)
Semantics are now grounded in vendor docs instead of educated guesses.
The PHY-side polls (0x110, 0x118, 0x184 etc. in d328) remain
undocumented — TRM does not republish the Synopsys DWC PUB register
map. Still need RE for those.
TRM cached at boltzmann:~/projects/AMPere/vendor/trm/ (pdf + txt).
Fetched via Stanford mirror (surfaced by the Chinese-language research
sibling alongside rk-open-docs, mfkiwl/rk-open-docs which has Rockchip
internal DDR docs for RK322x..RK1808 era — Innosilicon PHY, not our
DWC multiPHY, so useful for methodology but not direct reference).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
FUN_0000d10c @ 0xd10c (49 insts) contains poll site 11.
Semantically decoded as a PHY-side prologue for frequency-change
handshake: saves current state of one PHY CTL + four secondary-table
entries, waits for PHY firmware to reach state 1 (idle).
Matching-decomp iteration deferred vs the clean first lift (d328) —
d10c's two-base-pointer csel pattern plus parity-dependent offset
chain gives GCC too much register-allocation freedom. Getting to
>=90% byte-match would be an afternoon of iteration; time better
spent expanding pre-UART coverage breadth.
Poll-site coverage so far:
d328: sites 12, 13, 14, 15 (C candidate at 89.7% size match)
d10c: site 11 (reference C only, no matching iteration)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- benchmark/ai_ghidra/SETUP.md documents the GhidrAssist 1.5.0 install
at /opt/ghidra/Ghidra/Extensions/GhidrAssist/ on oppenheimer (CT131),
with dirac endpoints (Hermes-2-Pro 8B @ :8080, Qwen-coder 1.5B @ :8081)
already reachable + tested. Final enable+config is UI-only; two
clicks on next Ghidra launch.
- gdb_debug/harness.c extended with case 4 = train_phy_block running
under a synthetic PHY at 0x40000000. Static MMIO shim satisfies
polls 1-3; poll 4 needs dynamic state-machine (next session, via
SIGBUS handler or ptrace) — documented in the README.
Vendor tree investigation: Rockchip's own sdram_rk3588.c / sdram_rk3568.c
are STUBS (return -1). No free function names from there. Path forward:
mine the vendor kernel's rockchip_dmc.c (devfreq DDR scaling driver)
for register-offset naming hints at runtime-call level.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Three small functions extracted from the v1.19 conservative blob with
ground-truth C and per-tool (Ghidra / retdec / decomp.me) docs:
01_memset — byte memset, 28 B
02_memcpy32 — word-aligned memcpy, 36 B
03_magic_memset — magic check + tail-call to memset, 40 B
04_train_phy_block — first real poll-site function (104 B, 26 insts),
contains poll sites 12-15
Results in RESULTS.md:
- Ghidra: A on all four. Auto-decompile is close to final.
- retdec: A on #3, F on #1 and #2 (no register-arg inference on raw),
C on #4 (mistakes & 0xF0000000 for < 0x10000000).
GRIND_LOG.md (in 04_train_phy_block/) records the matching-decomp
iteration: 116-byte candidate.c at -Os vs vendor 104 bytes = 89.7%
size match on first real iteration. Remaining gap is GCC's choice of
`cmp w, w_const; b.ls` over vendor's `tst w, #imm; b.eq` for the
mask tests.
gdb_debug/ holds a native-aarch64 GDB single-stepper for the three
benchmark functions — boltzmann smoke test passed (memset:
buf[10] 0x00→0xab).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
marfrit