Sibling went back into the TRM and found §2.4.3 'Registers Summary
For DDRPHY' which I'd missed — it names almost every PHY PUB register
we'd been calling 'RE guess':
+0x110 = DDRPHY_CAL_RD_VWML0 (Read Valid Window Margin Left Code 0)
+0x120 = DDRPHY_CAL_RD_VWMR0 (Read Valid Window Margin Right Code 0)
+0x160 = DDRPHY_CAL_CON5 (Calibration Control 5: wrtrn_cyc_mode/en/th)
+0x684 = DDRPHY_PRBS_CON0 (PRBS Training Control — was 'CalBusy')
+0xa24 = DDRPHY_SCHD_TRAIN_CON0 (MASTER training scheduler; full bit map
in the TRM — every training type + per-rank)
+0xb88 = DDRPHY_DQSDUTY_CON2 (DQS rise-duty monitor — was 'UctShadow')
SCHD_TRAIN_CON0 is the master — the blob selects a training type via
its enable bits and polls bit[1] phy_train_done. Four of our 16 poll
sites are almost certainly polling this bit across different training
stages.
Still reserved in TRM: +0x118, +0x154, +0x184 — training-engine
private FSMs. Only dynamic tracing can name these.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Decoded all 16 poll sites against RK3588 TRM Part 2 where possible:
- 1 site (site 3) polls DDRCTL_DFISTAT (vendor-canonical, TRM-named)
- 4 sites (2,4,5,7) poll DDRCTL + 0x10014 — likely STAT.operating_mode
per generic DWC uMCTL2 convention; TRM cross-ref TBD
- 11 sites are DWC PUB / Innosilicon PHY — still RE-only (TRM does
not republish the PHY register map)
- 1 unusual site (site 10) polls absolute 0xff000024 in SRAM_BOOT
region — possibly a BL2 handoff word, not a PHY poll. Flagged for
special treatment in the v3fb bisection plan.
Known tensions documented:
- Site 3's DFISTAT test uses bits[2:1] (mask 0x6), generic uMCTL2 has
only bit[0] defined there → RK3588 likely extends DFISTAT with
vendor-specific bits. Need to verify from TRM bit tables.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
marfrit