U-Boot BCB Text Fields: Inspect the Encoded Recovery Message Before Storing It

A recovery message entered through U-Boot’s bcb set
command is not an arbitrary byte string copied unchanged to disk. The
v2025.01 implementation interprets colons as separators, enforces a
field-length limit and edits a staged in-memory structure. A later
bcb store writes that structure back to storage.

This distinction matters when an integration test passes a path,
option list or generated recovery instruction through the command. The
exact encoded field, rather than the original shell argument, is the
message the next consumer receives. The scope here is BCB text staging;
Android A/B slot selection uses a separate mechanism.

Load selects the
snapshot being edited

The BCB command operates on a static in-memory
bootloader_message and its selected block device and
partition. Its load path resolves the target, checks that the structure
fits and reads it into memory. Failed initialization or loading resets
the cached context. Set, clear, test, dump and store reject a missing
loaded context. Tagged
BCB command implementation.

After loading, a field edit modifies this snapshot. It does not
reload unrelated fields immediately before storage. If another writer
changes the BCB between load and store, storing the older snapshot can
replace those changes. That follows from the whole-structure write path;
the command is not a per-field merge protocol.

The official BCB guide describes the block as a communication channel
between Android userspace, recovery and the bootloader. Its ownership
therefore matters when defining who may update the shared structure at a
given stage. BCB
integration guide.

Check encoding and
capacity independently

__bcb_set() first measures the supplied string. An input
length greater than or equal to the destination field size is rejected,
leaving space for termination. This check occurs before separator
processing, so do not expect a long input to be accepted merely because
its encoded result might be shorter.

The setter then splits the duplicated input at colons and
reconstructs the field with newline separators. For ordinary nonempty
segments, a hypothetical input such as
recovery:option-one:option-two becomes three lines. A
literal colon is not preserved by this command, and the implementation
supplies no escape branch that turns a colon back into an ordinary
character. Field
setter.

There is a precise edge case behind the guide’s broad separator
description. The setter inserts a newline only when the output field is
already nonempty. Leading empty segments therefore do not generate
leading newlines. Interior empty segments after nonempty text can
generate blank lines. If blank-line placement is significant to a
consumer, test the actual bytes rather than applying a blanket “replace
every colon” rule.

A shorter
string does not clear the entire field

Setting a field begins by writing a terminator at its first byte and
then appending the encoded segments. It does not zero the entire
fixed-size field. Replacing a long string with a shorter one can leave
old bytes beyond the new terminator. A string-based consumer may ignore
them, but a raw dump or whole-structure store still contains those
bytes.

By contrast, clearing a specific field uses memset()
across that field’s full size. Clearing without a field clears the
entire BCB structure. Choose the intended scope deliberately; clearing
all fields to prepare one message can discard unrelated staged state. Clear
and set implementations.

Use bcb dump to inspect the staged field’s fixed-size
byte representation when qualifying encoding. A successful dump before
storage says what is in memory, not what a later boot will read.
bcb store separately checks whether the requested block
count was written and returns failure otherwise.

A focused proposed fixture covers ordinary separators, leading and
interior empty segments, the capacity boundary and long-to-short
replacement. Compare staged bytes, explicit store status and a fresh
readback from disposable storage. No BCB field or disk was modified for
this article. The goal is to make text encoding, snapshot ownership and
persistence three visible steps rather than one assumed successful
“set.”