test(renode): model DBGMCU IDCODE — exercise 480 MHz/VOS0 + both revisions

[twitzelbos]

Summary

Renode could only ever run the 400 MHz / VOS1 clock path. clocks::init reads DBGMCU_IDCODE (0x5C00_1000) to gate 480 MHz / VOS0 on silicon rev V — but nothing modelled that address, so the read returned 0 → DEV_ID mismatch → always 400. The entire 480/VOS0 code path (iterative PLL1 → sys_ck 480, the overdrive VOSRDY/ODEN handshake) was untested in sim.

What's here

• Model DBGMCU_IDCODE as a small writable memory in daisy_seed.repl. A test plants a rev-Y or rev-V IDCODE before boot; default 0 → the 400 path, so every existing test is unaffected.
• clocks_boot.robot: two new cases (the suite is already in CI):
  • Rev V (REV_ID 0x2003, DEV_ID 0x450) → the bootloader lands sys_ck = 480 MHz via PLL1P, while PLL2R (FMC, 200 MHz) and PLL3P (SAI) stay put, and the CoreClocks hand-off guard = 0x1C9C3800 (480 MHz).
  • Rev Y (REV_ID 0x1003) → stays at 400 MHz, proving the REV_ID check (not just DEV_ID) gates the path.

Key finding

The existing RCC / PWR / SYSCFG models already handle 480/VOS0 — no model changes were needed, only the IDCODE. The RCC model computes sys_ck generically from the PLL registers (no hardcoded 400, no VCO clamp), PWR forces VOSRDY, and SYSCFG handles ODEN. The test confirms VOS0 overdrive doesn't hang and PLL2/PLL3 kernels are unperturbed by PLL1's overdrive VCO.

Scope / caveat

This validates that the 480 code path executes correctly in sim (right dividers, no VOSRDY hang, no VCO-config panic — the Iterative-strategy/LTO landmine would be caught here). The electrical reality of overdrive at 480 stays a hardware-only claim (already validated on rev V).

Test

clocks_boot.Bootloader clocks init lands PLL2R And SysCk ... OK   (400, default)
clocks_boot.Rev V IDCODE Boots At 480 MHz Under VOS0     ... OK
clocks_boot.Rev Y IDCODE Stays At 400 MHz               ... OK

🤖 Generated with Claude Code