U-Boot Warm Reset: The Sysreset Walker Can Fall Back to a Stronger Reset

Requesting a warm reset does not always establish that only the
warm-reset domain will be affected. In U-Boot v2025.01’s sysreset
command path, the requested type is a starting point for a walker that
tries available reset devices and then advances to later reset types if
none reports a reset in progress.

A retained-memory or peripheral-state experiment therefore needs
evidence of the actual reset mechanism. The command’s -w
option alone is insufficient proof that DDR, GPIOs or power domains
remained in the intended state.

Identify the command
implementation first

The reset
command guide describes cold reset as the default and warm reset as
the optional request. This article narrows that interface to the
implementation enabled by CONFIG_SYSRESET_CMD_RESET in the
sysreset
uclass.

That command initializes the requested type to cold and changes it to
warm for -w. It then calls
sysreset_walk_halt(). Boards using another
architecture-specific command implementation must be reviewed
separately; sharing the command name does not establish the same
fallback policy.

Trace both levels of the
search

The walker starts at the requested reset type. For that type, it
walks the sysreset devices and calls each request operation. If none
returns -EINPROGRESS, it increments the type and repeats
the device walk.

The sysreset
interface orders the types as warm, cold, power reset and power off.
Its walker contract explicitly describes trying the next type when the
requested one is unavailable.

This is not a promise that all those effects will occur. The
available drivers, their supported operations and the point at which
execution actually resets determine the outcome. It does mean a warm
request is not intrinsically restricted to warm-only attempts. A product
that requires preserved state must inspect that fallback path rather
than relying on its initial request label.

Understand the
driver’s completion contract

The request-operation documentation distinguishes unsupported
operation from a reset that has started but has not yet taken effect. A
driver initiating an asynchronous reset should return
-EINPROGRESS. A reset that already happened normally does
not return to the old execution context.

The walker specifically stops on -EINPROGRESS; an
ordinary returned zero is not its stopping condition. A custom driver
that merely submits a reset and returns zero can therefore let the
walker continue to other devices or later types. Review that contract
when porting a reset controller instead of interpreting zero as
universal asynchronous success.

After the walker reports a reset in progress,
sysreset_walk_halt() allows a short delay for it to take
effect. If execution still continues, the helper emits a failure message
and halts. It does not provide a normal successful shell-return path
from which a script can validate the reset’s physical scope.

Build a reset-domain receipt

For an approved development fixture, record the selected command
implementation, starting type, linked reset devices, request return
values and actual controller used. Separately capture the target’s
reset-cause evidence early enough that startup code does not erase or
replace it.

Then compare the retained objects the product actually depends on: a
particular RAM region, a peripheral configuration or a power-domain
state. A surviving software marker does not alone prove that every
intended domain was retained. The selected SoC and board reset
specifications remain necessary to interpret those observations.

Exercise supported warm reset and unavailable-warm fallback as
different proposed cases. Do not perform the latter on production
equipment or assume it cannot reach a power-affecting operation. No
reset request or retention test was executed here.

The acceptance statement should name the demonstrated reset path and
preserved state. “We passed -w” records a request; it does
not identify the reset that the walker ultimately caused.