Linux pstore 与 ramoops 配置入门：让内核 panic 日志在重启后可读

作者LIU, ZHUOHUI

先确认本产品能保留哪类故障证据

配置目标应是“某种真实故障经过指定复位路径后仍有证据可读”。kernel panic、oops、硬件看门狗复位和突然断电属于不同事件。部分故障能够进入内核dump路径，硬件直接复位或完全锁死则可能没有执行写记录的机会；普通reboot也不能自动当作panic验证。

本文以上游Linux v6.6为技术依据，产品必须另行锁定vendor kernel commit、config、DTB、bootloader及板卡修订。ramoops文档描述的是指定RAM跨重启保留记录；普通DRAM不保证掉电保存，panic文本片段也不是完整vmcore。以下方法尚未在具体板卡验证。不要把“有一份console历史”与“捕获了本次panic”混为一谈：前者可以帮助还原上下文，后者需要核对事件原因和唯一标识。

为ramoops选择安全的保留内存区域

由板卡或BSP负责人根据真实memory map选择区域，核对DRAM边界、安全固件、bootloader重定位、镜像解压目标、CMA、framebuffer及其他reserved-memory使用者。教程里的地址即使能被内核接受，也可能覆盖产品正在使用的内存。

审查范围必须覆盖下一次Linux运行之前：DRAM初始化、内存测试或固件清零，都可能破坏上一次内核已成功写入的内容。记录哪些复位类型能保留、哪些启动阶段会写入该区，并在bootloader升级后重新确认。内存映射属性还受架构与原子访问约束影响，不能为了“更可靠”随意修改。

内核写入保留RAM、经过复位保留、下一次启动通过pstore读取并归档的证据链。
原创保留路径示意。RAM内容是否跨复位保留取决于板级实现，不代表掉电后仍可保存。

固定内核选项与后端加载时机

依据v6.6 pstore Kconfig检查实际构建：CONFIG_PSTORE提供子系统，CONFIG_PSTORE_RAM提供RAM后端。console、pmsg与ftrace能力还涉及各自选项和容量，按取证目标启用，不要一次打开所有调试功能。

内建或模块方案取决于需要覆盖的故障窗口。用户态后期才加载的后端，无法依靠它记录更早的内核故障；内建只能缩小窗口，也不能保证覆盖自身初始化之前。保留启动注册日志，把“期望配置”与“运行配置”分两列，防止新kernel搭配旧DTB，或实际启动了另一个分区中的镜像。

编写设备树并分配记录预算

v6.6 ramoops binding分别定义记录区域。record-size用于每份内核消息dump，console-size用于控制台历史；pmsg-size与ftrace-size对应不同数据产生者。各区共享总保留空间，内部元数据、对齐和ECC还会影响有效载荷，不能把保留字节数直接当作可保存的文本量。

区域 证据类型 预算前要回答的问题
kmsg records panic/oops消息片段 需要保留几段有用尾部
console 内核控制台历史 需要多少故障前上下文
pmsg 选定用户态消息 由谁写入和脱敏
ftrace 持续函数跟踪 开销是否可接受

下面是不可直接编译的结构模板。所有占位符均须按已审查的板级地址和cell编码替换，故意不提供可照抄的物理地址。

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>; /* v6.6: panic + oops */
    };
};

上游v6.6的dump reason定义区分panic与oops，vendor补丁可能改变行为。完成后应做目标binding校验，并读取驱动实际接受的容量。规划记录数时，先扣除console等独立区域，再检查剩余空间能容纳多少个record。容量增加之前还需重新审查整张内存图，不能侵占已有保留区。可选ECC只帮助处理一定程度的内容损坏，并不能挽救已经断电丢失或被启动代码覆盖的数据。

在启动后确认注册与可读路径

收集含pstore和ramoops的启动消息，对照运行时设备树、构建DTB和保留内存图。检查pstore文件系统是否真正挂载、挂载在哪里。常见路径/sys/fs/pstore只是入口，目录存在不证明后端已就绪，更不证明发生过可记录事件。

可先只读检查/proc/mounts、kernel release、/proc/cmdline和有权限读取的内核日志。仅启用对应配置时才可能存在/proc/config.gz，否则应取得匹配构建的config。权限限制或工具缺失应记作采集限制，不能误判为后端故障。首次事件前目录为空很正常，还要提前查明启动采集器是否会取走记录。

在实验板完成一次受控panic验证

只在已备份、有串口记录、已批准维护窗口和恢复手段的开发设备上测试，由负责工程师选择与内核配置匹配的触发方式。本文不提供可直接复制到生产设备运行的panic命令。

触发前记录唯一marker、构建标识及预定复位方式，保存串口尾部与下一次启动早期日志。重启后先复制记录，避免下一次崩溃、归档服务或清理覆盖证据。核对marker、原因与记录类型，不能把任何旧文件都算作成功。暖重启、看门狗与冷启动分开测试，暖复位成功不能证明掉电保留；失败时先保存观察，再按排障树收敛。

保存配置基线与已验证边界

验收包应包含kernel和启动链标识、有效DTB、config、已审核保留区、测试复位路径及真实记录样例，同时写明日期、采集方法和未覆盖的早期启动、硬锁死或其他复位类型。这份能力说明应能在后续版本重新验证。

配置后没有记录，可继续pstore空目录排障；记录存在后，进入现场证据采集，规划归档、构建匹配与脱敏。解释复位行为仍需要可靠的板级bring-up基线。

开展BSP故障日志保留评估时，准备SoC、内存图、kernel/DT/bootloader版本与真实复位类型。这些信息决定ramoops能否覆盖实际故障，而非单靠一份设备树片段判断。

技术依据与验证范围

官方版本依据：ramoops · binding · kconfig · reasons

类似文章