fwmanager: downstream update lifecycle tests with slot and boot-progress capabilities - #392
Draft
chrysh wants to merge 4 commits into
Draft
fwmanager: downstream update lifecycle tests with slot and boot-progress capabilities#392chrysh wants to merge 4 commits into
chrysh wants to merge 4 commits into
Conversation
chrysh
marked this pull request as draft
August 5, 2026 08:00
chrysh
force-pushed
the
add-lifecycle-itest
branch
from
August 5, 2026 12:12
c4194bb to
ae906f0
Compare
Add MockDownstreamDevice (reset line, boot-complete line, firmware flash, one shared state) and a host test driving the boot flow through the real adapters: verify firmware, release only on a pass, poll boot completion within a budget. Covers corrupt firmware, hung device, stale boot evidence, and both error seams. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
SlotControl: slot actuation with trial-boot semantics — set_trial arms one boot (one-shot), commit promotes, rollback disarms; commit and rollback error with no trial armed. await_boot renders one bounded boot window as a poll budget over BootMonitor, so tests never sleep. In-file contract tests against HAL-free mocks. Refs: openprot OpenPRoT#377 Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
Two firmware slots, a staging region, and a SlotControl store with one-shot arming (the boot consumes the trial selector; the armed slot stays promotable until commit/rollback). flash() becomes the boot-slot view, so the existing boot_flow tests pass unchanged. New ordering instrumentation (last_boot_slot, programs_while_running, commit_preceded_by_ready, commit/rollback counts) and fault injection (inject_program_fault, set_boots_after). Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
Host tests asserting only on externally visible signals: successful update (device held in reset while flashed, committed only after observed boot), failed firmware write, corrupt staged image, trial timeout rollback, and a negative control proving the instrumentation catches a careless driver. stage_update/activate_update are test-local stand-ins for the PR OpenPRoT#357 orchestrator: when it merges, the drivers go and the assertions stay. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
chrysh
force-pushed
the
add-lifecycle-itest
branch
from
August 5, 2026 14:22
ae906f0 to
565b627
Compare
This was referenced Aug 5, 2026
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.
Host-level, black-box integration tests for the downstream firmware-update lifecycle: a MockDownstreamDevice on the eRoT's seams (reset line, boot-complete line, slot flash, staging flash, slot store), with every assertion made on externally visible signals — reset transitions, what was flashed while the device was held, which slot the device booted, what got committed. Plain rust_test, no kernel, no QEMU.
Covered scenarios: a successful update proves the device is held in reset the whole time firmware is written, is rebooted on the new slot, and is committed only after the booted state was observed; a device whose firmware write path fails is noticed through the flash seam, with nothing armed or committed and the old slot untouched; a corrupt staged image is rejected during staging without disturbing the running device; a trial-boot window that expires without evidence rolls back and reboots the still-committed slot. A negative-control test runs a deliberately careless driver and asserts the instrumentation catches it, so the positive assertions cannot pass vacuously.
Supporting pieces: the SlotControl capability (trial/commit/rollback slot selection) and BootProgress/await_boot (a bounded boot window over the existing BootMonitor, rendered as a deterministic poll budget — tests never sleep) are added to the fwmanager api leaf, per #377. The mock downstream device grows A/B slots, a staging region, a slot store, fault injection for a broken write path, and the ordering instrumentation the tests assert on. The existing boot_flow tests pass unchanged on the extended mock.
There is deliberately no orchestrator dependency: stage_update/activate_update in the test file are the reference rendering of the trial-boot protocol sketched in the BootControl docs. They are the executable spec for the orchestrator from #357 — when it merges, the real state machine replaces these test-local drivers and the assertions stay.
Refs #377.