The MIMXRT1064-EVK target merged in #66 is a complete worked example of the framework: a BSP implementing the five interfaces in bsp/include/bsp/, three demos, a vendored NetX ENET and KSZ8081 PHY driver, pinned and checksummed SDK fetch scripts, and Renode CI. An i.MX RT1050 port is mostly a matter of following it, which makes this a good way to learn the framework on real hardware.
Most of the work transfers unchanged. The three demos are board-independent by construction, and the BSP is five small files. The TRNG is the same IP: comparing the NXP device headers, the RT1052 and RT1064 TRNG blocks define 326 symbols each and differ in exactly one place, where RT1064 names two SEC_CFG bits UNUSED0/UNUSED2 and RT1052 names them SH0/SK_VAL. Same bit positions, same base address 0x400CC000, same ENT[16] layout, and the clock gate is CCGR6 CG6 on both. Ethernet is present and the EVKB's PHY sits at address 0x02, matching what the RT1064 target's Renode platform already declares.
What genuinely differs is boot and flash. The RT1064 has 4 MB of internal FlexSPI NOR, while the RT1050-EVKB boots from external QSPI or Hyperflash, so the linker script, the flash configuration block and the XIP boot header all need replacing with the RT1050 equivalents. Clock config and pin mux come from the RT1050 board files in nxp-mcuxpresso/mcuxsdk-examples under _boards/evkbimxrt1050; pin them to a commit and checksum them, the way scripts/fetch_sdk.sh already does.
One part is harder than the rest and is best treated as optional. Renode 1.16.1 ships no RT1050 platform at all -- platforms/ contains only imxrt1064, imxrt500, imxrt700 and mimxrt798s -- so there is no board or CPU description to build on, unlike the RT1064 target which extends platforms/boards/mimxrt1064_evk.repl in 30 lines. A port validated on a physical board, without a Renode CI job, is a complete and welcome contribution on its own. Deriving an imxrt1050 platform from the RT1064 one is a natural follow-up for anyone who wants it, and should be a separate PR.
A working RT1050 port would also settle most of #70. The TRNG driver has never run on silicon, and since the register sets are identical, a board that exercises MCTL[PRGM], the ENT15 block-consume path and ENT_VAL re-arming would validate the logic even though the part number differs.
Start from targets/NXP/MIMXRT1064-EVK/ and templates/target/, and read docs/architecture.md sections 2 and 4 for how a target is expected to be laid out. Questions are welcome on this issue.
The MIMXRT1064-EVK target merged in #66 is a complete worked example of the framework: a BSP implementing the five interfaces in
bsp/include/bsp/, three demos, a vendored NetX ENET and KSZ8081 PHY driver, pinned and checksummed SDK fetch scripts, and Renode CI. An i.MX RT1050 port is mostly a matter of following it, which makes this a good way to learn the framework on real hardware.Most of the work transfers unchanged. The three demos are board-independent by construction, and the BSP is five small files. The TRNG is the same IP: comparing the NXP device headers, the RT1052 and RT1064 TRNG blocks define 326 symbols each and differ in exactly one place, where RT1064 names two
SEC_CFGbitsUNUSED0/UNUSED2and RT1052 names themSH0/SK_VAL. Same bit positions, same base address0x400CC000, sameENT[16]layout, and the clock gate isCCGR6CG6on both. Ethernet is present and the EVKB's PHY sits at address0x02, matching what the RT1064 target's Renode platform already declares.What genuinely differs is boot and flash. The RT1064 has 4 MB of internal FlexSPI NOR, while the RT1050-EVKB boots from external QSPI or Hyperflash, so the linker script, the flash configuration block and the XIP boot header all need replacing with the RT1050 equivalents. Clock config and pin mux come from the RT1050 board files in
nxp-mcuxpresso/mcuxsdk-examplesunder_boards/evkbimxrt1050; pin them to a commit and checksum them, the wayscripts/fetch_sdk.shalready does.One part is harder than the rest and is best treated as optional. Renode 1.16.1 ships no RT1050 platform at all --
platforms/contains onlyimxrt1064,imxrt500,imxrt700andmimxrt798s-- so there is no board or CPU description to build on, unlike the RT1064 target which extendsplatforms/boards/mimxrt1064_evk.replin 30 lines. A port validated on a physical board, without a Renode CI job, is a complete and welcome contribution on its own. Deriving animxrt1050platform from the RT1064 one is a natural follow-up for anyone who wants it, and should be a separate PR.A working RT1050 port would also settle most of #70. The TRNG driver has never run on silicon, and since the register sets are identical, a board that exercises
MCTL[PRGM], theENT15block-consume path andENT_VALre-arming would validate the logic even though the part number differs.Start from
targets/NXP/MIMXRT1064-EVK/andtemplates/target/, and readdocs/architecture.mdsections 2 and 4 for how a target is expected to be laid out. Questions are welcome on this issue.