U-Boot Command Timeout: Typing Does Not Restart the bootretry Deadline

An engineer can be actively typing at a U-Boot prompt and still
encounter a command timeout. In v2025.01’s simple CLI path,
bootretry establishes a command-input deadline; receiving
each character does not restart it as an idle-after-last-key timer.

When diagnosing an unexpectedly interrupted maintenance session,
identify the parser and retry configuration first. Increasing typing
speed may conceal the symptom without explaining when the deadline
starts, which commands restart it or what the timeout triggers.

Locate the deadline’s owner

The simple
CLI loop calls bootretry_reset_cmd_timeout() before
reading a line when the previous command result is nonnegative. Its
initial result also takes that path. A negative result does not rearm
the deadline at the next loop iteration.

The boot-retry
implementation reads the retry duration from the environment or its
configured default. Nonnegative values below the configured minimum are
raised to that minimum. Resetting the timeout computes a new end time;
disabling retry changes the duration state to a negative value.

These operations belong to command-loop and initialization logic.
They are not performed automatically for every received byte. The
statement is specific to the inspected simple CLI path, not an
assumption about every shell or board-specific console
implementation.

Follow the character wait

Both inspected character-reading paths in cli_readline.c
use bootretry_tstc_timeout() while obtaining input. That
helper waits while no input is available, checks the existing deadline
and returns a timeout once it has expired. It also calls
schedule() while waiting.

There is no deadline refresh after a character arrives in that
helper. A person can type several characters before the deadline, pause
briefly after it and then trigger the timeout at the next empty-input
wait. The relevant elapsed interval is not simply the duration since the
most recent keystroke.

There is an important limit to this interpretation: the helper tests
expiry inside its no-input loop. A continuously available stream can
defer that check. This is therefore not a hard watchdog that interrupts
arbitrary command execution or guarantees termination at one exact
instant regardless of queued input.

Separate
timeout detection from its consequence

The line reader reports timeout as -2. The simple CLI
recognizes that result and either returns toward another autoboot
attempt or invokes reset when RESET_TO_RETRY selects that
behavior. A disappearing prompt and a board reset can therefore be
different configured consequences of the same input-timeout path.

The boot
Kconfig documents the retry duration, minimum and reset option. It
also distinguishes the unencrypted keyed-autoboot delay string from the
stop string: the latter disables retry. Do not infer the active prompt
policy solely from the fact that autoboot was interrupted.

Qualify the
maintenance interaction deliberately

A proposed console fixture should record prompt entry, timeout rearm,
character arrival, empty-input waits and the resulting timeout branch.
Compare a line completed within the interval with a slowly entered line
that pauses after the original deadline. Use benign input and an
isolated target with a known recovery path.

Then compare the next prompt after a nonnegative command result with
the next prompt after a negative result. This distinguishes deadline
ownership from a generic keyboard-idle interpretation. Record the actual
parser and resolved configuration with the trace.

No console input, autoboot attempt or reset was executed here. The
practical conclusion is that a maintenance procedure must fit the
deployed command-input policy; character activity alone is not evidence
that bootretry was extended.