U-Boot Boot Timing: Distinguish Timestamp Marks, Accumulated Work and Stage Handoffs

A boot-time report shows a large delay before Linux starts, so the
team begins removing kernel features. The delay may instead belong to
loader discovery, a retry path or an earlier stage whose records were
not preserved. Before optimizing, establish what the timing report
measures and what it leaves outside its field of view.

This article follows upstream U-Boot v2025.01 bootstage interfaces
and implementation. It combines timestamp interpretation with
cross-stage evidence retention. For a Buildroot product, use the
selected bootloader configuration and platform timer implementation. No
boot-time measurements or speedup claims are presented.

Define the interval
the product cares about

Write the user-visible endpoint first: a first frame, an available
service or an application-ready signal. Then place reset, loader entry,
operating-system handoff and that endpoint on a conceptual timeline. A
loader report can explain part of the interval without covering all of
it.

Record the trigger and clock for every measurement source. A host
timestamp on the first serial character includes output and transport
effects. A firmware timestamp uses its configured timer. An application
log may use another clock origin. Do not subtract values from different
origins simply because each is printed in microseconds.

The bootstage
interface header defines timer_get_boot_us as the platform
time-since-boot interface used by this facility. Inspect the actual
implementation and its availability in each relevant phase. A
declaration of intended units is not a measurement of the board’s
resolution, continuity or error.

Read marks and
accumulators differently

The same header distinguishes an absolute mark from an activity
measured with paired bootstage_start and bootstage_accum calls. An
accumulator can collect repeated activity. It answers how much time was
spent in that instrumented activity, which is different from the time at
which a milestone was reached.

The tagged
implementation keeps the first ordinary record for an existing mark
identifier. Repeating a mark with the same identifier is therefore not a
general-purpose trace of every retry. The report also separates
accumulated time from its mark listing.

This creates a practical instrumentation choice. Use distinct
milestones when you need the order of transitions. Use a correctly
paired accumulator when you need total time spent in repeated work. If
you need per-attempt behavior, design evidence that preserves those
attempts instead of assuming a reused mark records each one.

Do not sum every reported quantity into a single boot total. An
accumulated activity can sit inside the elapsed interval between two
marks. Nested activities can overlap as well. Label each number as a
point, an interval or an accumulated category before comparing it with
another report.

Check that the
record set is complete enough

The implementation has a configured record capacity and can warn when
space is exhausted. A missing mark may mean that code was not reached,
the instrument was not enabled for that stage or recording capacity was
exhausted. Those explanations imply different next steps.

Preserve the full report, configuration and instrumented source
revision. A copied three-line excerpt can hide a capacity warning or
remove the earlier mark needed to interpret an elapsed value. Record
what identifiers were expected from the tested path, then compare the
observed set against that expectation.

Keep instrumentation overhead in view. Extra serial output,
dynamically named records or changed code layout can influence the boot
being measured. Start with the smallest set of boundaries that
distinguishes the competing hypotheses. If a change appears beneficial
only under a heavily instrumented build, repeat the comparison with an
appropriately controlled release-like configuration.

Preserve
evidence across SPL and main U-Boot deliberately

The bootstage
command implementation provides report handling and, when the stash
feature is enabled, stash and unstash operations using a configured or
supplied memory area. The underlying implementation checks stash
capacity and validates stored metadata on restoration.

That mechanism does not prove a board automatically carries every SPL
record into main U-Boot. Inspect the actual producer and consumer calls,
enabled phase configurations and reserved memory lifetime. The
destination must survive the transition without being overwritten by
later initialization or image placement.

Also verify clock interpretation across the handoff. Carrying records
into a later phase preserves data; it does not by itself reconcile
different timer origins or a timer that was reset. Keep cross-phase
timing claims bounded to the platform evidence available. If continuity
cannot be established, report separate phase intervals rather than
inventing an end-to-end number.

Use timing to choose
the next experiment

A proposed campaign first compares repeated boots under one
controlled condition. Record power-on versus warm reset, attached media,
network availability and the selected boot path. These conditions can
change discovery and retry work even when the firmware binary is
identical.

Then alter one suspected source of delay at a time. For example,
compare a known available boot device with a controlled absent-device
case, using a recoverable setup and the same expected milestones. A
larger interval around discovery is a reason to inspect that path; it is
not proof that every instruction inside the interval is responsible.

Record the success condition with the duration. A shorter boot that
skipped a required device or silently took another path is not a valid
optimization result. Keep the artifact identity and observed branch
behavior with each sample so that timing changes remain
attributable.

The final report should explain what interval was measured, which
clock and records support it, whether cross-stage evidence was retained
and which functional outcome accompanied it. With those boundaries in
place, the team can decide whether to investigate SPL, main U-Boot or
Linux instead of optimizing the stage that merely happens to print the
most visible log.