U-Boot Binman Inputs: Detect Stale Files and Missing-Blob Success Before Packaging

A firmware image has the expected filename and a plausible size, yet
one region contains an older binary or placeholder content. Binman can
correctly follow its input-search and diagnostic options while producing
an output that is unsuitable for deployment.

The useful review unit is an entry’s resolved input, not just the
final image. This article uses U-Boot v2025.01’s Binman implementation,
including host-side packaging for a Buildroot product. No image was
built or flashed for this analysis.

The first matching input
path wins

The Binman
guide allows multiple input directories through -I. The
input-file
helper walks those directories in order and returns the first
existing path for a relative filename. An absolute filename bypasses
that search.

Two directories containing the same basename therefore create an
ordering dependency. A new file in a later directory does not replace an
older matching file in an earlier one. A successful lookup establishes
that a file exists at the selected location, not that it belongs to the
intended firmware release.

For each external entry, record the resolved path and content digest
after lookup. Comparing only the configured filename misses this class
of stale-input error. Keep build outputs and approved external inputs in
distinct, deliberately ordered directories.

Missing inputs
can still produce an output image

The guide’s --allow-missing option permits diagnostic
builds without required external blobs or tools. Ordinarily such
incomplete output leads to exit status 103. Combining it with
--ignore-missing converts the final invalid-image result
into a warning and successful exit status.

The control
implementation classifies missing required blobs, fake blobs and
missing tools as non-functional-image problems. Its final status
handling follows the configured ignore option. Consequently, a generic
CI rule that promotes every zero-exit packaging result is insufficient
if that diagnostic option is permitted.

Treat diagnostic packaging and release packaging as separate
invocations with explicit allowed flags. Do not rely on a log phrase
remaining visible after CI output truncation; record whether
invalid-image allowances were enabled in the job’s structured
result.

An assumed size is not
supplied firmware

The guide describes assume-size as a way to reserve an
entry’s expected extent when its contents are unavailable. The blob
entry code can fill missing content with zeros of the assumed size
or use generated fake content when configured.

This makes layout testing useful without every proprietary or
separately built component, but it also explains why file length is weak
evidence. Padding or placeholder content can preserve the overall shape
while the executable component is absent.

Optional blobs are a different case. The image description can
deliberately declare an external blob optional, and missing optional
content does not trigger the same non-functional result. That property
is a design assertion that the image can operate without the component.
Review it against the board’s actual boot requirements instead of using
it to silence an inconvenient packaging failure.

Do not create
an implicit cross-image build graph

The guide also warns that one image consuming a file generated by
another image in the same description has undefined behavior. The
consumer may encounter a missing file or a leftover file from a previous
run. Ordering the nodes visually is not a dependency declaration.

Represent the dependency through supported entry composition or
produce the prerequisite in an explicitly ordered external build step. A
clean workspace is a useful check, but it does not make an unsupported
dependency model reliable.

Review content and
placement together

A Binman map reports entry offsets and sizes, including section
nesting. Use it to identify where each resolved component was placed,
while keeping the source digest alongside the entry. The map describes
layout; it does not establish that the input was current, complete or
authorized for the product.

Targeted regression cases are two matching basenames in differently
ordered input directories, a required missing blob, an intentionally
optional blob and a leftover cross-image intermediate. Verify which
cases the release job rejects and which it accepts by design.

The release gate should require approved resolved inputs and an
acceptable content state before it trusts the final layout. That catches
a stale or absent component even when the output file exists, its size
looks reasonable and the packaging command returned success.