A board's cached capability row records which emulator measured it, so a new emulator invalidates the row. For every nRF52 board it records the wrong one.
EmulatorFingerprint (internal/sim/boardcheck/boardcheck.go:85) reads QEMU first and only falls back to Renode when QEMU is unset:
path := os.Getenv(emulated.EnvQEMU)
if path == "" {
path = os.Getenv("MESHBENCH_RENODE")
}Which emulator a board runs under follows from its MCU, not from which variable happens to be set. An ESP32 board runs under QEMU and an nRF52 board under Renode, and a machine set up to probe both has both variables set.
What it costs
On a machine with both configured, the row for a Renode board is stamped with QEMU's path, size and mtime. So:
- Upgrading Renode does not invalidate any nRF52 board's row. The rows the upgrade should have retired stay
Stale: false and keep being served, which is the failure this fingerprint exists to prevent. The DIO1 fix is the precedent: a Renode change that altered what boards demonstrate.
- Upgrading QEMU spuriously invalidates every nRF52 row, throwing away probes that cost nine minutes each for a change that cannot have affected them.
Seen on a real probe just now: RAK_4631-v1.17.1.json carries
"EmulatorFP": "/home/alex/.cache/meshbench/tools/qemu-system-xtensa@66652856-1788261489"
for a board that ran under Renode.
The fix
The fingerprint has to follow the same choice the runner makes. internal/firmware/emulated already decides the emulator from the board's MCU, so this wants the board (or its MCU) as a parameter rather than a guess from the environment. A row whose emulator cannot be determined should say so rather than fingerprint the wrong binary.
Worth checking at the same time whether radioserver belongs in the fingerprint: every emulated node clocks its radio through it, so a change there moves what a board demonstrates just as an emulator change does.
Found while probing for #136.
A board's cached capability row records which emulator measured it, so a new emulator invalidates the row. For every nRF52 board it records the wrong one.
EmulatorFingerprint(internal/sim/boardcheck/boardcheck.go:85) reads QEMU first and only falls back to Renode when QEMU is unset:Which emulator a board runs under follows from its MCU, not from which variable happens to be set. An ESP32 board runs under QEMU and an nRF52 board under Renode, and a machine set up to probe both has both variables set.
What it costs
On a machine with both configured, the row for a Renode board is stamped with QEMU's path, size and mtime. So:
Stale: falseand keep being served, which is the failure this fingerprint exists to prevent. The DIO1 fix is the precedent: a Renode change that altered what boards demonstrate.Seen on a real probe just now:
RAK_4631-v1.17.1.jsoncarriesfor a board that ran under Renode.
The fix
The fingerprint has to follow the same choice the runner makes.
internal/firmware/emulatedalready decides the emulator from the board's MCU, so this wants the board (or its MCU) as a parameter rather than a guess from the environment. A row whose emulator cannot be determined should say so rather than fingerprint the wrong binary.Worth checking at the same time whether
radioserverbelongs in the fingerprint: every emulated node clocks its radio through it, so a change there moves what a board demonstrates just as an emulator change does.Found while probing for #136.