U-Boot PStore Retrieval: Check the Ramoops Layout Before Interpreting Missing Output

An empty U-Boot pstore display result does not establish
that Linux produced no crash record. The retained memory might be
missing, the reader might be looking at different record boundaries, or
the record might be compressed and unavailable as console text.

This article follows the v2025.01 PStore command with a known, valid
ramoops layout configured before the first retrieval. Linux v6.12
documentation provides the persistence context. Malformed-memory
hardening, ECC correction and per-CPU ftrace decoding are outside this
limited retrieval analysis.

Preserve
the memory before interpreting its contents

The Linux
ramoops guide requires a predefined memory region whose contents
survive the relevant restart. Its existence in a device tree does not
prove that a particular reset path retains it or that earlier firmware
leaves it intact.

Distinguish warm reset, watchdog reset and complete power loss
according to the board’s actual memory behavior. Also audit firmware
relocation, memory initialization and image-loading ranges against the
reserved region. A correct Linux logger cannot recover bytes overwritten
before the U-Boot command runs.

Preserve the original memory image before experiments when practical.
Rebooting into a new producer or writing more records can change the
evidence being investigated. This article does not trigger a kernel
panic or request one on a production device.

Match every layout field

The U-Boot
command guide requires U-Boot’s settings to match the kernel’s
ramoops parameters. The base and total length are necessary, but so are
the dump-record, console, ftrace and userspace-message region sizes.

In the command
implementation, dump records occupy the initial region. The code
computes its end by subtracting the console, ftrace and
userspace-message sizes from the total. The remaining regions are
located from those same configured lengths. A mismatched tail-region
size therefore changes where the reader looks, even if the base address
is correct.

The setter parses sizes and addresses as hexadecimal. Omitted
optional arguments retain their existing values; they are not
automatically reset to zero or re-read from Linux. Record the complete
effective tuple instead of copying only the first two parameters from a
previous board.

There is also a status trap: if the total length is smaller than the
sum checked by the setter, it prints a diagnostic and sets the internal
length to zero, yet returns success. A successful setter status does not
establish an enabled, usable layout. The later display or save command
rejects a zero-length configuration.

Separate record
validity from printable text

For ordinary dump records, the reader checks the persistent-buffer
signature and stored size, reconstructs the circular-buffer contents,
then looks for the kernel-message header. A missing signature, empty
buffer or unrecognized header can result in no displayed dump.

A recognized header can also mark the payload as compressed. The
display path reports that compressed-buffer display is unavailable and
skips printing its contents. That is different from an absent
record.

The save path retains compressed dump content with an
.enc.z filename suffix rather than decoding it on the
console. Match any later decoding tool to the actual producer and
format; the suffix is not permission to assume a particular compression
algorithm.

Verify retrieval at the
right boundary

Saving records requires an existing destination directory and a
working filesystem write path. In this version, the PStore save routine
calls the filesystem helper without propagating its individual return
values. Confirm that expected files actually exist and contain the
intended bytes before treating the command’s return as a successful
export.

A controlled fixture should preserve the source bytes, record the
complete reader/producer layout, and distinguish empty, uncompressed and
compressed records. These checks separate retention, addressing,
recognition, presentation and export failures without assuming that one
blank console result explains them all.

No target memory was read, record exported or crash induced here. The
conclusion is a retrieval diagnostic: establish retained bytes and
matching layout first, then ask whether the recognized record can be
printed or must be preserved for later decoding.