U-Boot mtest: Check the Accumulated Error Count as Well as the Final Status

A zero command status is not sufficient evidence that every
mtest pass was clean in the U-Boot v2025.01 implementation
examined here. The command accumulates errors for its printed summary,
but calculates its return value from the most recent test result.

For an intermittent memory fault, an earlier failing pass followed by
a clean final pass can therefore produce a nonzero summary count with a
zero return. Qualification automation must not discard the former just
because its shell condition accepted the latter.

Identify the two different
variables

The mtest
guide describes a destructive RAM test with optional repeated
iterations and alternative patterns. Its general success/failure
description needs to be read alongside the exact command
source when defining an automated acceptance rule.

In do_mem_mtest(), errs holds the latest
test routine’s result. count accumulates those results
across completed work. At the end, the command prints
count, but returns the Boolean expression
errs != 0.

The normal loop does not stop merely because a test routine returns a
positive error count. It stops for the configured iteration limit or an
interruption result. The next ordinary iteration overwrites
errs with a new result while count retains
earlier errors.

Work through a
source-derived counterexample

Consider a hypothetical two-iteration quick-test sequence whose
routine results are two errors and then zero errors. After the first
iteration, both errs and count are two. After
the second, errs is zero while count remains
two.

The resulting command return is zero even though the printed
accumulated count is nonzero. This is a control-flow example derived
from the code, not an observed RAM failure or an executed U-Boot
test.

The alternate configuration adds another opportunity for the
distinction. When the additional bit-flip test is enabled, the command
adds the alternate test’s result to count before assigning
the bit-flip result to errs. A later clean subtest can
replace the earlier positive result even within one outer iteration.

An interruption follows a different path and leaves a nonzero
sentinel result. Do not combine an operator-aborted run, an exhausted
iteration limit and a completed clean run into one unspecified “test
stopped” category.

Define the
acceptance record before running

For this pinned version, require both a completed intended run and
zero accumulated errors. Preserve the complete summary and enough
preceding diagnostics to identify failing addresses and patterns. A
wrapper parsing the summary must be tied to the actual firmware output
format rather than assuming every U-Boot release prints identical
text.

A product-maintained command can instead return an aggregate failure
result deliberately. That is a source change requiring its own review
and tests; no patch or test executable was produced here. Keep the
original failing-result sequence as a regression case so a later clean
pass cannot erase the operation’s failure status.

Keep the
memory-test boundary safe and explicit

mtest writes the selected RAM. It is not a
nondestructive inspection command, and its range arguments do not
establish ownership of that memory. Determine the active bootloader,
stack, buffers and reserved regions before an authorized board test.

Record the selected quick, alternate and optional bit-flip
configuration as part of the test identity. The guide distinguishes
their range and pattern behavior, including the optional bit-flip
treatment of the end address. Do not copy a range from a different build
and assume the same write footprint.

Use an explicitly bounded iteration count for an unattended fixture
and check how the command parses it. No target memory operation was
executed for this article. The useful conclusion is narrow: a later
clean result must not hide an earlier recorded error, and command status
alone does not enforce that requirement in this version.