Skip to content

Support additive FAT files via files_append#28

Draft
jetm wants to merge 2 commits into
mainfrom
eng-2134-stone-files-append
Draft

Support additive FAT files via files_append#28
jetm wants to merge 2 commits into
mainfrom
eng-2134-stone-files-append

Conversation

@jetm

@jetm jetm commented Jul 23, 2026

Copy link
Copy Markdown

Problem

The device-tree-overlay feature needs to add compiled .dtbo files to a target's FAT boot partition at bundle time, but stone's manifest had no way to append files to an existing FAT image.

Solution

Add files_append support to the manifest so additional files are injected into a FAT partition image without redefining it.

Key changes

  • manifest: support additive FAT files via files_append
  • provision: bind guarded partition size with if let

Reviewer notes

Enabler for the Avocado device-tree-overlay feature (ENG-2134). meta-avocado's overlay delivery hook and the avocado-cli DTO commands build on this. First to merge in the stack: stone -> meta-avocado -> avocado-cli.

jetm added 2 commits July 17, 2026 13:56
`cargo clippy --all-targets -- -D warnings`, which CI enforces, flags
`partition.size.unwrap()` guarded by a preceding `partition.size.is_some()`
as `unnecessary_unwrap`. The two-step check-then-unwrap also lets the guard
and the use drift apart.

Match the value once with `if let Some(size)` and use the binding directly,
so the guard cannot diverge from the unwrap and clippy passes clean.

Signed-off-by: Javier Tia <javier@peridio.com>
Both supported boot chains deliver a custom device-tree overlay by
enumerating it in a FAT partition's `files` list, but that list is
authored by the BSP and stone replaces (never merges) a manifest's
file arrays. A project could therefore only add its own overlay by
restating the entire BSP file list, which goes stale the moment the
BSP changes its boot files.

Add a `files_append` field the FAT builder concatenates onto `files`,
keyed by output path. An identical {in,out} re-emitted on an incremental
rebuild collapses to a no-op, so a regenerative delivery step is safe to
run every build; two entries targeting the same output from different
inputs error out instead of silently overwriting a boot file. Both build
paths (bundle and provision) and the describe output honor the field, and
manifests without it still parse.

Also normalizes pre-existing rustfmt drift in the touched files (and one
adjacent bundle test) so `cargo fmt --check` passes; the repo's drift was
confined to exactly these files.

Signed-off-by: Javier Tia <javier@peridio.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant