The i.MX RT1064 TRNG driver added in #66 (targets/NXP/MIMXRT1064-EVK/app/trng.c) is written against the reference manual but has never run on silicon, and the CI suite cannot tell whether it is correct.
Renode's IMX_TRNG model implements neither half of the sequence the driver depends on. It logs Unhandled write for MCTL[PRGM], MCTL[RST_DEF] and SDCTL[SAMP_SIZE]/SDCTL[ENT_DLY], so the programming-mode bring-up is a no-op there. It also returns a fresh pseudo-random word on any ENT[n] read, where silicon refills the block only when ENT15 is read and re-arms ENT_VAL. A driver that skipped the bring-up entirely, or that read ENT[0] in a loop and returned the same word every time, would pass the current tests identically.
What would settle it, on a physical MIMXRT1064-EVK:
MCTL[ENT_VAL] clears after ENT15 is read and sets again on the next round.- Successive
trng_get_random_u32 calls return distinct words across several full 16-word blocks, rather than one repeating value.
MCTL[ERR] stays clear through the PRGM -> RST_DEF -> SDCTL -> run-mode transition in trng_init.- Entropy survives a basic sanity check over a few kilobytes. A repeating four-byte pattern is the failure mode this is guarding against.
A TRNG that repeats looks fine in a demo and is fatal in whatever product copies the demo, which is why this wants a board rather than another emulator run. The README records the limitation in the meantime.
The i.MX RT1064 TRNG driver added in #66 (
targets/NXP/MIMXRT1064-EVK/app/trng.c) is written against the reference manual but has never run on silicon, and the CI suite cannot tell whether it is correct.Renode's
IMX_TRNGmodel implements neither half of the sequence the driver depends on. It logsUnhandled writeforMCTL[PRGM],MCTL[RST_DEF]andSDCTL[SAMP_SIZE]/SDCTL[ENT_DLY], so the programming-mode bring-up is a no-op there. It also returns a fresh pseudo-random word on anyENT[n]read, where silicon refills the block only whenENT15is read and re-armsENT_VAL. A driver that skipped the bring-up entirely, or that readENT[0]in a loop and returned the same word every time, would pass the current tests identically.What would settle it, on a physical MIMXRT1064-EVK:
MCTL[ENT_VAL]clears afterENT15is read and sets again on the next round.trng_get_random_u32calls return distinct words across several full 16-word blocks, rather than one repeating value.MCTL[ERR]stays clear through thePRGM->RST_DEF->SDCTL-> run-mode transition intrng_init.A TRNG that repeats looks fine in a demo and is fatal in whatever product copies the demo, which is why this wants a board rather than another emulator run. The README records the limitation in the meantime.