Configuring Linux pstore and ramoops to Read Kernel Panic Logs After Reboot
Decide which failures the product can preserve
The useful question is whether a particular failure leaves readable evidence after the actual reset path used by the product. A kernel panic, an oops, a watchdog reset and removal of power are different events. Some failures reach a kernel dump handler; a hard lockup followed by a direct hardware reset may never execute it. A normal reboot is also not automatically a panic test.
This guide uses Linux v6.6 as the upstream reference. Record the vendor kernel commit, configuration, DTB, bootloader and board revision before applying it. The ramoops documentation describes records held in a reserved RAM region that survives a restart. Ordinary DRAM does not promise retention through power loss, and the resulting log fragment is not a complete vmcore. No board-specific retention result is claimed here.
Choose a reserved region from the real memory map
Have the board or BSP owner identify a region that every boot stage agrees to preserve. Check DRAM boundaries, secure firmware, bootloader relocation, decompression destinations, CMA, framebuffer allocations and other reserved-memory users. An address copied from a tutorial can overlap live memory even when the kernel accepts the configuration.
The review must cover the interval before Linux runs again. A bootloader memory test, DRAM initialization or firmware scrub can destroy evidence that the crashing kernel successfully wrote. Ask which reset types preserve the region and which stages may write it. Save that answer with the memory-map revision and repeat the review after a bootloader update.
Do not guess memory mapping attributes to improve retention. Their correctness depends on the architecture and atomic-access requirements. A safe reservation and a compatible mapping solve different problems; both need platform evidence.
Pin kernel options and backend availability
Check the actual build configuration against Linux v6.6 pstore Kconfig. CONFIG_PSTORE provides the subsystem and CONFIG_PSTORE_RAM selects the RAM backend. Optional console, userspace-message and function-tracing facilities have separate configuration and space requirements. Enable only the record types required by the diagnostic objective.
Choose built-in or module integration with the failure window in mind. A backend loaded by late userspace cannot capture an earlier kernel failure through that backend. Built-in support can reduce the window, but it does not guarantee coverage before the relevant initialization completes. Retain startup messages showing registration rather than relying solely on a configuration fragment in the source tree.
Keep two columns in the design record: “requested configuration” and “observed running configuration.” This catches deployment errors where a new kernel boots with an old DTB, or the bootloader chooses a different image than expected.
Allocate record budgets in the device tree
The v6.6 ramoops binding defines the reserved region and optional subregions. record-size budgets individual kernel-message dumps; console-size holds console history. pmsg-size and ftrace-size serve different data producers. Their budgets compete for the same reservation, and internal metadata, alignment or ECC affect usable capacity. Do not equate reserved bytes with guaranteed text payload.
| Record area | Intended evidence | Planning question |
|---|---|---|
| kmsg records | Panic/oops message snapshots | How many useful tails fit? |
| console | Kernel console history | Which recent context is needed? |
| pmsg | Selected userspace messages | Who writes and sanitizes them? |
| ftrace | Persistent function tracing | Is overhead acceptable? |
The following is a non-compilable layout template. Replace every placeholder using the reviewed board map and correct address/size cell encoding. It intentionally provides no reusable physical address.
reserved-memory {
#address-cells = <BOARD_ADDRESS_CELLS>;
#size-cells = <BOARD_SIZE_CELLS>;
ranges;
ramoops@BOARD_APPROVED_BASE {
compatible = "ramoops";
reg = <BOARD_APPROVED_BASE_AND_SIZE_CELLS>;
record-size = <REVIEWED_RECORD_BYTES>;
console-size = <REVIEWED_CONSOLE_BYTES>;
max-reason = <2>; /* upstream v6.6: panic + oops */
};
};For v6.6, dump reasons distinguish panic and oops; verify vendor changes before using max-reason. Validate the completed tree against the target binding and inspect the driver’s accepted sizes.
Confirm registration and the read path after boot
Collect boot messages mentioning pstore and ramoops, then compare the effective device tree with the built DTB and reservation map. Check whether the pstore filesystem is mounted and where. The conventional /sys/fs/pstore location is useful, but merely finding that directory proves neither a mounted filesystem nor a stored crash.
Read-only observations can start with /proc/mounts, the kernel release, /proc/cmdline and permitted kernel-log access. Configuration may be available in /proc/config.gz only when that feature is enabled; otherwise retrieve the exact build artifact. Root permissions, log restrictions and missing utilities should be recorded as collection limits rather than interpreted as backend failure.
An empty filesystem before any eligible event is expected. Also identify boot-time collectors before testing: an archive service may already have moved records by the time an engineer signs in.
Validate one controlled event on a recoverable lab board
Schedule the test on a development unit with backed-up data, serial capture, an approved maintenance window and a proven recovery procedure. Have the responsible engineer choose a trigger appropriate to the configured kernel. This guide intentionally does not provide a copy-and-run production panic command.
Before the event, record a unique marker, build identifiers and the intended reset route. Capture the console tail and the next boot from its earliest available stage. After reboot, copy any records before another crash, collector or cleanup operation can alter them. Compare the marker, reason and record type instead of accepting any old file as success.
Test warm reboot, watchdog behavior and cold power-up as separate cases only when approved. A warm-reset success does not establish power-loss retention. If the record is absent, preserve the observations and use a diagnostic tree rather than repeatedly crashing the device.
Save the baseline and the boundaries that remain
The acceptance package should contain kernel and boot-chain identities, the effective DTB, configuration, reviewed memory reservation, test reset path and the actual collected record. Add the test date, capture method and known gaps, including early boot, hard lockups or unsupported reset types. This creates a capability statement a later release can recheck.
If a configured device returns no record, continue with empty-pstore troubleshooting. Once records exist, use field evidence collection to define archiving, build matching and controlled sharing. The board bring-up baseline remains the foundation for interpreting reset behavior.
For a BSP crash-retention review, prepare the SoC, memory map, kernel/DT/bootloader versions and observed reset type. Those facts determine whether ramoops can cover the failure you actually need to diagnose.
