U-Boot Bloblist Handoff: Successful Initialization Can Replace Rejected State

A later U-Boot stage can initialize its bloblist successfully while
losing the records supplied by an earlier stage. In v2025.01,
initialization can reject an incoming list and create a fresh one. The
resulting ready flag proves that a usable list exists, not that the
prior stage’s state survived.

This article focuses on configured fixed-address inter-stage handoff
and the ordinary fallback logic. Architecture-specific boot-argument
import, allocation policy and vendor changes require their own call-path
check. A bloblist checksum is an integrity check for this format, not
cryptographic authentication of its producer.

Finish after the final
producer mutation

The bloblist
design guide describes records identified by tags and carried
between boot phases. A producer might preserve information that cannot
be read again, such as a reset cause consumed by an early register
read.

The guide places checksum finalization at the handoff boundary
because updates can change the list while a stage is using it. The implementation
computes that checksum over the used region, and
bloblist_finish() stores the result in the header.

A producer that changes covered bytes afterward can leave a checksum
that no longer matches. “Finish was called once” is therefore weaker
than “finish followed the last covered mutation before handoff.” Review
the actual ordering of record creation, record updates and the
transition to the next stage.

Validation
has several distinct rejection reasons

The consumer’s bloblist_check() examines magic, version,
total size, used size, header size and checksum. When a nonzero
reserved-size bound is supplied, an incoming total size exceeding it is
rejected. A producer and consumer can therefore disagree about
admissible capacity even when both use the same address.

Preserve the exact return and diagnostic rather than calling every
failure corruption. A version mismatch, incorrect address, reserved-size
mismatch and changed covered bytes point to different corrections. None
is resolved merely by proving that RAM at the expected address is
readable.

The tagged
API declarations document the size and error contracts. They also
distinguish finding a tag from finding a tag with the expected record
size. A record can exist yet be unsuitable for a consumer compiled
against a different structure layout.

Initialization
may recover availability by discarding history

In the fixed-address later-stage path, initialization attempts to
check the existing list. If that attempt fails, the function logs the
condition and proceeds through its configured creation path. With a
usable fixed address or successful permitted allocation, it can create a
new header and eventually return success.

The new header’s used size initially covers only the header. Old
bytes elsewhere in the region are not automatically retained as visible
records. Creating a list is therefore a recovery of the container’s
availability, not a recovery of the rejected producer data.

A consumer using an ensure-style API can then create a missing
record, whose data is initialized to zero. Without an explicit
provenance check, a default zero can be mistaken for the early stage’s
actual observation. Decide whether each record is optional,
reconstructible or mandatory before accepting that fallback.

Require
record-level evidence at the consumer

For mandatory handoff state, inspect the validation outcome and
require the expected tag and size before interpreting fields. Define a
safe response when the record is absent or incompatible. Do not let a
generic initialization-success check silently turn unavailable evidence
into a valid reset cause or platform setting.

A proposed memory-only fixture can vary the header version, reserved
capacity, checksum and required record size independently. It should
distinguish rejected input followed by a new empty list from successful
preservation of an existing record. Keep any record recreation visible
in the result.

No boot stage, checksum fixture or target memory operation was
executed for this analysis. The useful distinction is between a ready
container and preserved cross-stage evidence. Both need their own
acceptance condition when the later boot decision depends on what the
earlier stage actually knew.