marfrit
5aef5bd118
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>
RE-tool benchmark — three functions from the RK3588 DDR blob
Three small, self-contained functions extracted from
rk3588_ddr_lp4_1848MHz_lp5_2112MHz_v1.19.bin, each with canonical
ground-truth semantics so you can judge decompiler output against a
known answer.
| dir | blob offset | size | ground truth |
|---|---|---|---|
01_memset/ |
0x0aac |
28 B / 7 insts | memset(void*, u8, size_t) byte-wise |
02_memcpy32/ |
0x1200 |
36 B / 9 insts | memcpy32(u32*, const u32*, size_t) word-aligned |
03_magic_memset/ |
0x0da4 |
40 B / 9 insts | if (*(u32*)0x1fe004 == 0x54410001) memset(0x1fe000, 0, 0x32c); |
Each subdir contains:
func.bin— raw little-endian AArch64 machine codefunc.s— objdump'd GNU asm, same absolute addresses as the blobreference.c— ground-truth C (our belief)ghidra.md— load-in-Ghidra recipe + expected outputdecompme.md— decomp.me scratch recipe (matching-decomp)retdec.md— retdec command lineretdec.c— retdec's actual output (captured 2026-04-15)
Summary of findings: see RESULTS.md. Short version:
- Ghidra got all three right with minor type-label cleanup needed.
- retdec failed on #1 and #2 (can't infer register-passed arguments on raw binary), did well on #3 (the one with absolute-address refs).
- decomp.me is a matching-decomp comparator, not a decompiler — judged on a different axis.
Load address matters
All three functions are extracted as raw bytes starting at offset 0 in
their func.bin. When loading into Ghidra / retdec, set the base
address to the function's original blob offset (first column above),
otherwise branch targets and absolute-address refs in function #3 will
be off.