U-Boot USB Rescans: Why Repeating usb start Can Keep an Old Device Inventory

A removable USB device can be replaced while U-Boot still considers
its USB subsystem started. Repeating usb start then looks
reassuring but may perform no scan at all. In v2025.01, the command’s
already-started branch returns immediately.

For a product that accepts removable boot or service media, separate
subsystem initialization from refreshing the device inventory. This
article covers U-Boot’s driver-model USB host path. USB gadget mass
storage and operating-system hotplug behavior are different
mechanisms.

Read the command’s early
return

The USB
command implementation checks the global usb_started
state before starting USB. When it is already set, the command returns
zero without calling its startup helper.

That means the second invocation does not, by itself, establish that
a newly attached device was enumerated or that a removed device
disappeared from software state. The command name includes startup, but
an already-running instance is treated as sufficient for this
branch.

The reset branch is different: it calls usb_stop() and
then the startup helper. This is an explicit
teardown-and-reinitialization path, not simply another spelling of the
already-started fast path. Whether a product should invoke it at a
particular moment depends on what devices and console functions it would
interrupt.

Trace what stop removes

In the driver-model
USB uclass, stopping USB removes active bus devices and unbinds
their root-hub children. Those root hubs own the discovered USB device
hierarchy, so this is a lifecycle transition affecting the objects used
by higher layers.

The stop path also resets USB-storage state when that support is
built and clears the global started flag. Standard-boot integration can
have its USB discovery state cleared as well. Treat previous device
pointers, numeric selections and discovery results as belonging to the
old inventory until the relevant layer has resolved them again.

Removal and unbinding can report errors. The command’s reset branch
does not inspect the stop result before starting again, so a reset
command return is not a detailed teardown report. Keep the controller
and driver diagnostics when investigating a failed refresh.

Controller
startup is not target-device recognition

Initialization probes available USB controllers and then scans their
active buses. Companion-controller handling affects scan order. The
implementation sets usb_started when a suitable controller
path is initialized; that flag is not a count of recognized storage
devices and does not identify the intended removable medium.

After USB initialization succeeds, the command helper additionally
runs the storage scan when configured. These are separate layers: host
controller, USB device hierarchy, storage recognition and the partition
or filesystem eventually used by a loader.

A board can therefore have a started USB subsystem while the desired
disk is absent or not recognized. Do not collapse these observations
into one “USB ready” flag. Capture the device tree and storage inventory
corresponding to the same refresh attempt.

Qualify
replacement without trusting the old index

Use disposable media with distinguishable approved identifiers to
compare an unchanged attachment, removal, and replacement. First
demonstrate the already-started behavior; then exercise the product’s
authorized refresh path and resolve the intended storage again. The
question is whether the inventory changed as expected, not merely
whether the command returned zero.

A numeric storage index is insufficient evidence that the replacement
is the intended device. Check the resolved media identity and partition
layout before any write or boot action. Avoid conducting the experiment
through a USB-only recovery console unless an independent recovery route
is available, because teardown may remove that input path too.

The command’s startup and reset branches both return zero after their
helper calls; startup failures can therefore require reading diagnostics
and inspecting resulting state rather than relying only on shell status.
No USB command, reset, media replacement or boot was executed for this
analysis.

The practical result is a lifecycle rule: repeated start is not a
rescan contract. An intentional refresh needs teardown-aware handling
followed by a fresh check of the particular device the next operation
will consume.