rng: seed-error recovery for Mk3 (port of #693 to v4-legacy) - #699
Closed
Silexperience210 wants to merge 1 commit into
Closed
rng: seed-error recovery for Mk3 (port of #693 to v4-legacy)#699Silexperience210 wants to merge 1 commit into
Silexperience210 wants to merge 1 commit into
Conversation
Coldcard#693 fixes the Mk4/Mk5/Q. This is the same change for the Mk3, on the branch that actually builds it: master has no Mk3 target, so the copy of stm32/COLDCARD/rng.c there is never compiled, and v4-legacy carries the code that shipped as 4.2.0 on 2026-07-31. stm32/COLDCARD/rng.c here is byte-identical to master's, and has the same gap: rng_init() only tests RNGEN, but a seed error latches SEIS and stops DRDY while leaving RNGEN set, so the peripheral is never recovered and every later rng_get() times out for the rest of the boot session. Since the hotfix wired rng_get() to the hardware TRNG, that reaches the keypad scan-order shuffle in _start_scan(), which runs from a Pin.irq callback before login. mempad.py: same try/except OSError as Coldcard#693. This branch has no keyboard.py, so nothing else to guard. Reference note in the header: the Mk3 is an L475 (RM0351), which documents the shorter clear-SEIS-then-toggle-RNGEN sequence. The 12-word flush is RM0432 wording, kept so this file stays identical to the Mk4 version rather than diverging.
Author
|
Closing — duplicate of #695, which predates this and is more complete (it also covers The only thing here that isn't in #695 is a standalone testbench that mocks RNG_CR/SR/DR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#693 fixes Mk4/Mk5/Q. This is the same change for the Mk3, filed against the branch that
actually builds it —
masterhas no Mk3 target, so the copy ofstm32/COLDCARD/rng.cthere is never compiled, while this branch carries the code that shipped as 4.2.0 on
2026-07-31.
The file here is byte-identical to master's and has the same gap:
rng_init()only testsRNGEN, but a seed error latchesSEISand stopsDRDYwhile leavingRNGENset, so theperipheral is never recovered and every subsequent
rng_get()times out for the rest ofthe boot session. Since the hotfix wired
rng_get()to the hardware TRNG, that path nowreaches the keypad scan-order shuffle in
_start_scan(), which runs from aPin.irqcallback before login.
shared/mempad.pygets the sametry/except OSErroras #693. This branch has nokeyboard.py, so there is nothing else to guard.On the reference: the Mk3 is an STM32L475, covered by RM0351, which documents the
shorter clear-SEIS-then-toggle-RNGEN sequence. The 12-word pipeline flush is RM0432
wording. I kept it, with a note in the header, so this file stays identical to the Mk4/Q
version rather than quietly diverging — the extra discards are harmless. Say the word if
you would rather I trim it to the RM0351 sequence.
Should go in after #693. I have no Mk3 to test on, so this needs a look from someone who
does.