Conversation
The QEMU runner filled each FMC backing image with one byte, so a test could hand the device erased flash and nothing else. The integration test needs the device to already hold a firmware image the update agent can offer. cs0_contents and cs1_contents name a file to copy in at offset 0; the remainder stays 0xFF. Without them the fill byte behaves as before, so every existing test is unchanged. A contents file longer than flash_size is an error rather than a truncation. A half-written image still parses far enough to fail verification, which would make a verify-failure scenario pass for the wrong reason. Assisted-by: Claude
A QEMU test that offers a firmware image needs that image on flash before the guest boots. The harness can now seed a chip select from a file; this makes the file. The layout arrives as arguments but is built with the same Region, Slot and ImageLayout constructors the board tables use, so a layout this tool accepts is one the orchestrator would accept: unique slot ids, no overlap, no zero-length region, nothing past the end of the offset space. Re-deriving those rules here would let a test image drift from what the firmware believes about the same flash. Everything no image covers stays 0xFF, and a payload too large for its slot is an error rather than a truncation. The flash_image rule wraps the tool so a BUILD file can hand the result straight to cs0_contents or cs1_contents. Assisted-by: Claude
The QEMU integration test needs something on the other end of the RoT's reset and ready lines. This is that device: held in reset the ready line stays inactive, and once reset is released it goes active after a delay, or never. Generic over InputPin and OutputPin, so the lines can be GPIO on a board or whatever the wiring supplies in a test image. Time arrives as an argument to poll and nothing waits, so the same model runs from a kernel event loop or from a test that moves the clock by hand. Asserting reset drops the ready line and restarts the delay. The RoT has to see evidence disappear when it resets a device, or a stale ready line would answer for the new boot. Boots and Hangs are the only behaviours. A late boot is Boots with a delay past the window the RoT waits, which makes lateness a property of the deadline rather than of the device. Assisted-by: Claude
This branch has not been deployed
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.
Review the last commit only. The two before it are #532 and #533; the
fork cannot host a real stack.
Something has to sit on the other end of the RoT's reset and ready lines
for a boot-sequence test. This is that device: held in reset the ready
line stays inactive, and once reset is released it goes active after a
delay, or never.
Generic over InputPin and OutputPin, so the lines can be GPIO on a board
or whatever the wiring supplies in a test image. Time arrives as an
argument to poll and nothing waits, so the same model runs from a kernel
event loop or from a test that moves the clock by hand.
Boots and Hangs are the only behaviours. A late boot is Boots with a
delay past the window the RoT waits, which makes lateness a property of
the deadline rather than of the device.
Assisted-by: Claude