Retract sibling's d328 register names — they addressed wrong sub-block

Previous commit committed sibling claims without verifying against
the TRM bit tables. Verification fails for d328:

  Sibling: +0x110 = CAL_RD_VWML0 (from TRM §2.4.3).
  Blob: writes 0xF000F000 to that offset.
  TRM: CAL_RD_VWML0 is READ-ONLY, bits[9:0]=rd_vwml0 code, [25:16]=rd_vwml1.
        Writing is a no-op.

Root cause of sibling's error: conflated 'DDRPHY_OPB + offset' with
d328's 'DDRPHY_OPB + 0x8000 + offset'. The +0x8000 sub-block is NOT
documented in the TRM; offsets 0x110/0x118/0x120/0x154/0x160/0x184
WITHIN that sub-block mean something different from CAL_RD_VWML0 etc.

Kept the TRM-verified names I DID check:
  - DDRCTL_DFISTAT @ +0x10514 (site 3)
  - DDRCTL_STAT @ +0x10014 (sites 2,4,5,7)
  - DDRPHY_SCHD_TRAIN_CON0 @ +0xa24 — bit layout verified directly

Retracted names for d328's +0x8XXX accesses; restoring the PHY_CTL_110
etc. RE-guess labels as the safe fallback. True names remain unknown
until we get hardware-trace data or the Synopsys DWC PUB databook.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

POLL_SITE_MAP.md

@@ -138,3 +138,46 @@ and the six training sub-steps in step 6.
 - CSDN LPDDR5 series (DDR Study blog) turned out to cover JEDEC-layer
   protocol only; no register-level help. Useful background for training
   phase names but not for our RE.
+
+## Correction 2026-04-15 late evening — sibling over-trusted
+
+User pointed out I was applying sibling names without verification
+("weights from browsing Instagram"). Going back to verify each, found
+**the d328 register naming was wrong**:
+
+- Sibling said `+0x110` in d328 = `DDRPHY_CAL_RD_VWML0` (per TRM).
+- But the blob **writes** `0xF000F000` to that offset, and TRM lists
+  `CAL_RD_VWML0` as **READ-ONLY** with bits[9:0] carrying a
+  training-result code. Writes are no-ops; 0xF000F000 as a legit VWML
+  value makes no physical sense either.
+- Reason sibling was confused: **d328's effective address is
+  `ctx->b8 + 0x8000 + offset`**, not `DDRPHY_OPB + offset`. TRM's
+  CAL_RD_VWML0 is at `DDRPHY_OPB + 0x0110`, not
+  `DDRPHY_OPB + 0x8110`.
+- What's at `DDRPHY_OPB + 0x8000..0x8FFF`? TRM does not say. Only
+  chapters elsewhere in the TRM have 0x8xxx-offset registers (DPTX
+  PHY etc. — different peripherals, not DDR).
+
+**What d328 really does:** we still don't know the semantic register
+names for its +0x8110, +0x8118, +0x8120, +0x8154, +0x8160, +0x8184
+accesses. The 0xF000F000 / 0x30003 / 0x30000 values suggest a custom
+trigger/config/ack protocol of the +0x8000 sub-block, which is likely
+a per-rank-shadow or per-slice mirror of DDRPHY's Master block —
+but without docs, naming it would just be re-guessing.
+
+**Still verified (hold):** the early-cluster + MID-cluster offsets
+that access `ctx->b8 + 0x10000 + small` (i.e. the DDRCTL register
+space):
+
+- Site 3 @ 0x7ca8 → `DDRCTL + 0x10514` = **DDRCTL_DFISTAT** ✓ TRM-verified
+- Sites 2, 4, 5, 7 → `DDRCTL + 0x10014` = **DDRCTL_STAT.operating_mode** ✓ TRM-verified
+
+And at DDRPHY OPB + small (NOT the 0x8000 sub-block):
+
+- `DDRPHY + 0xa24` = `SCHD_TRAIN_CON0` — I verified the full 32-bit
+  layout directly from TRM §2.4.3 before committing, so this one stands.
+
+**Wrong/unsafe (retracted):** the `+0x8XXX` offsets in d328. Their
+sibling-proposed names (`CAL_RD_VWML0` etc.) are TRM-registered at
+`+0x0XXX`, not `+0x8XXX`, and the blob's write access patterns
+contradict the read-only TRM bit definitions.

rk3588_regs_annotated.h

@@ -175,6 +175,15 @@
                                                             (TRM HIGH) */
 
 /* -------------------------------------------------------------------
+ * CORRECTION 2026-04-15 LATE EVENING:
+ *   The 'CAL_RD_VWML0' etc. names above apply to DDRPHY_OPB + small
+ *   offsets. d328's accesses are at DDRPHY_OPB + 0x8000 + small,
+ *   which is an UNDOCUMENTED sub-block of the DDRPHY space.
+ *   Writing 0xF000F000 to a TRM-documented READ-ONLY register
+ *   would be a no-op — contradicting the blob's actual behaviour —
+ *   so those names DO NOT apply here. The `PHY_CTL_110` etc.
+ *   heuristic labels (in the block above) are the safe fallback.
+ *
  * Semantic re-interpretation of FUN_0000d328 (train_phy_block):
  *   Writes 0x30003 to CAL_CON5 (+0x160):
  *     bit[0] wrtrn_cyc_mode=1  (low-freq edge mode)