U-Boot Standard Boot Order: Resolve Environment Overrides Before Approving Removable Media

A product is expected to start from its internal storage, yet a USB
stick changes what boots. The bootloader may be following its configured
policy correctly. The engineering problem is establishing which policy
source actually controls the deployed scan, including values retained
from an older release.

This article examines U-Boot v2025.01 Standard Boot, with
CONFIG_BOOTSTD_FULL where its devicetree ordering features
are needed. It applies to the U-Boot bootloader selected for a Buildroot
product, but does not assume that every Buildroot configuration enables
Standard Boot. Traditional distro scripts, board-specific boot commands
and other entry paths need their own audit.

Establish the entry path
first

Start the review at the command that the product actually executes.
Record the selected boot command, any intervening script and the
bootloader configuration. A list named boot_targets is
meaningful only when the executed path consumes it. A factory script
that directly boots a named image can bypass the Standard Boot iterator
entirely.

Separate three questions in the release record: which storage devices
are eligible, which order they receive, and which boot methods can
interpret their contents. An engineer can reorder storage successfully
while leaving an unexpected interpretation method available. Conversely,
disabling a method can make an intended recovery device unusable even
when the device remains first in the list.

The tagged
Standard Boot overview describes the device, method and bootflow
layers. It also identifies global methods, which choose their own boot
device and are normally considered before ordinary device scanning. A
local storage list therefore cannot be treated as a complete inventory
of every reachable boot path.

Resolve the
effective list from the implementation

The decisive v2025.01 function is
bootstd_get_bootdev_order(). It reads
boot_targets and uses the environment list only when the
value exists and is nonempty. Otherwise it returns the ordering held by
the Standard Boot device. With the relevant full configuration, that
ordering is read from the bootdev-order property. The tagged
bootstd implementation establishes this precedence.

That distinction matters when cleaning up an inherited environment.
Removing a nonempty override does not necessarily select the generic
priority order: a devicetree list may become effective instead.
Documentation’s broad description of an empty variable should be
interpreted alongside this branch and the board’s actual property
value.

The next boundary is visible in bootdev_setup_iter().
Without an explicit single-device selection, it obtains that list. If a
list exists, it advances through labels; otherwise it selects devices by
priority. This gives the reviewer a concrete resolution chain rather
than a guess based on typical board defaults.

Do not confuse a label without a sequence suffix with one specific
physical device. Labels, device numbering and the exact available
devices need verification against the product build. The policy should
name the intended role, such as internal storage or approved service
media, alongside its implementation identifier.

Review upgrades as
well as fresh devices

Create a small evidence sheet for each supported deployment
state:

• The compiled configuration and control devicetree identity
• The relevant persisted environment values before startup
• The command that enters Standard Boot
• The effective device list or priority fallback
• The enabled ordinary and global methods
• The first permitted artifact expected for that state

Include a clean device and a device carrying the previous release’s
environment. Otherwise a new devicetree policy can look correct in
development while a retained nonempty variable overrides it in the
fleet. The desired migration behavior must be explicit: preserve the
user’s choice, replace a release-owned value, or reject an unsupported
configuration.

Do not erase the entire environment simply to make the observed order
match the design. Other variables may contain product-specific
provisioning. A migration should be bounded to the values it owns and
reviewed with the same care as the new default.

Use distinguishable media
fixtures

A useful qualification setup gives each approved test medium a
harmless, distinct boot marker. Start with internal storage only. Then
add removable media containing a valid test bootflow, an invalid
bootflow and no bootflow. For each condition, record discovery, selected
method, attempted artifact and the final observed outcome
separately.

Repeat with the nonempty environment override present, with that
override absent, and with the intended devicetree policy. Include an
unavailable first target to expose fallback behavior. If the product
enables a global method, exercise its separate selection path rather
than assuming a device-list test covers it.

These are proposed tests, not results from a board. Use
recovery-capable fixtures and preserve the product’s authentication
requirements. This article does not recommend executing untrusted media
or weakening verification to make a selection test easier.

Define the acceptance
statement precisely

A useful release statement identifies the build, entry command,
effective policy source and tested media combinations. “Internal storage
was first on one boot” is weaker than evidence that the approved policy
remains effective after an upgrade with retained settings.

Ordering is also distinct from authorization. A later target may
still be reachable when earlier targets fail, and an interactive or
board-specific command may take a different path. Security review must
cover those paths independently. The practical outcome is a traceable
boot-selection policy, with retained configuration and fallback behavior
accounted for before removable media reaches field service.