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
chrysh
force-pushed
the
flash-image-builder
branch
from
October 3, 2026 19:08
ae6f416 to
724f1dc
Compare
This was referenced Oct 3, 2026
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 first is #532, which this builds on;
the fork cannot host a real stack.
Makes the file the harness change seeds a chip select from.
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 hands the result
straight to cs0_contents or cs1_contents:
Assisted-by: Claude