Persistent storage does not work on emulated nRF52 boards

[A13xB0]

Every emulated nRF52 board comes up with no filesystem. The firmware says so on
the third line of boot:

DEBUG: Generating new keypair
DEBUG: IdentityStore::save() failed

It regenerates a keypair on every boot because it cannot load one, and it cannot
save the one it made. Nothing a repeater stores survives a restart: its identity,
its preferences, its region and transport keys, its contacts.

What is known

• The controller was missing. Renode's nrf52840 platform maps flash as
  plain writable memory with no NVMC behind it — the emulator log shows
  NVMC:ICACHECNF … unimplemented register … generated from SVD. NVMC is what
  LittleFS drives to erase and program pages. Modelled in
  tools/renode/peripherals/NRF52840_NVMC.cs (PR MSIM-560 every nRF52 board forwards: two faults, and they were masking each other #564).
• That was not sufficient. With NVMC in place IdentityStore::save() still
  fails, and the firmware never touches the NVMC registers at all. With the
  SoftDevice present, Adafruit's InternalFS writes through the SoftDevice's
  flash API (sd_flash_write / sd_flash_page_erase), not the controller
  directly — those are SVC calls the SoftDevice services on its own schedule and
  signals through the SoC event queue. Something in that path does not complete
  under Renode.

Why it is worth fixing

MyMesh::allowPacketForward reads its region transport codes, loop-detect table
and hop caps out of preferences. It currently works on defaults, which is why
forwarding is fine — but any test of region scoping, loop detection or a
configured repeater is testing defaults rather than what an operator set.

It also means an emulated node cannot be provisioned and rebooted, and every
board regenerates its identity each run.

Where to start

The SoftDevice's flash operations are queued around radio activity and completed
asynchronously. Tracing the SVC path and the SoC event that should report
completion is the next step. MESHBENCH_RENODE_TRACE now covers the interrupt
path as well as the buses.

ESP32 boards are unaffected — their flash was fixed separately (the quad-enable
bit and the dummy-phase width) and their filesystem works.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q9HbD44EKWWTRYgxbFGxf6

[A13xB0]

An emulated board's identity is not stored state, and that is what hides this
bug.

It is a pure function of the run seed and the node's name:

noiseSeedFor(RunSeed, NodeName)          internal/firmware/emulated/noiseseed.go:9
  -> MESHBENCH_NOISE_SEED                emulated_node.go:288
    -> vsx_set_noise_seed()              hw/ssi/sx1262.c:592
      -> the chip's receiver noise
        -> MeshCore takes its entropy from the radio
          -> the keypair

FNV-1a, and deliberately "stable across runs and machines". So a node called
bc-under-test at seed 4417 gets the same keypair on every boot, on any
board, whether or not anything was stored.

Why that matters here

This issue's symptom is IdentityStore::save() failed and a keypair
regenerated every boot. On real hardware that is loud: the repeater comes back
as a different node each time, and every contact it had is stale. Under the
emulator it is silent, because the regenerated keypair is byte-identical to
the one it could not save.

The simulator is kinder than the air here in a way that hides the fault rather
than softening it.

It cost a measurement today

Trying to establish whether storage works, I booted a board twice and compared
the identity - the obvious signal, and the first thing anyone would reach for.
It was stable, which reads exactly like a working filesystem. It is not
evidence of anything.

The same seeding also means two different boards report the same identity
when they share a node name. The board probe names every board under test
bc-under-test, so LilyGo_TDeck under QEMU and RAK_4631 under Renode both
answered 4049F3934C0E7D6E.... That looks like cross-contamination and is not:
it is the seed doing what it says.

What a valid persistence test needs

Something not derived from the seed. The repeater's own CLI has set backed by
CommonCLI::savePrefs, so: set a preference, reboot, read it back. Identity
cannot answer this question and should carry a warning against being used for
it.

A possible fix, with its cost

Advancing the seed per boot - rather than per run - would make a board that
cannot persist visibly come back as a different node, which is what the
hardware does and what would have made this issue self-announcing.

Emulated nodes are already scenario.NotReproducible, so this does not cost
determinism where determinism is promised; noiseSeedFor lives in
firmware/emulated and no native node touches it. What it would change is
every emulated board's identity between boots, which fixtures and any test
pinning a key would feel. Worth doing deliberately rather than as a side
effect of this issue, so recording it here rather than acting on it.

Not the ESP32 boards, as far as anything here shows

I reported a SPIFFS mount failure on LilyGo_TDeck earlier today. That came
from a console log I could not attribute to the run in front of me, and the
identity check I used to follow it up is the invalid one described above. So
this issue's existing statement that ESP32 boards are unaffected is neither
confirmed nor contradicted by anything I measured - it stands as it was.