实验室里能接 JTAG 或一直开着串口，内核 panic 还好查。量产设备常常是看门狗复位或电源抖一下，再连上去时串口早已空了，只剩“它重启了”。这时 pstore 加 ramoops 很有用：在 RAM 里划出一块重启后仍能读到的区域，把 console、oops、ftrace 或用户标记的记录写进去，下次启动从 /sys/fs/pstore 读出来。它不是黑盒子里的完整核心转储，而是一份足够定位的“临终遗言”。

设备树里通常有 reserved-memory 下的 ramoops 节点，指定起止地址、record 大小、console 大小。地址必须落在复位后不会被 Bootloader 或早启代码清掉的那一段，也别和内核自己的 mem= 裁剪、CMA、可信固件工作区打架。很多板子翻车就是：内核记下了日志，U-Boot 上电把整段 DRAM 初始化成 0，或者下一次启动的内核把这片内存当普通页用掉。所以这块内存要同时从内核内存布局和 Bootloader 的清区列表里排除。

内核侧打开 CONFIG_PSTORE、CONFIG_PSTORE_RAM，以及你需要的 PSTORE_CONSOLE / PSTORE_PMSG。启动后应能看到 /sys/fs/pstore；一旦发生 panic 或你向 /dev/pmsg0 写了一行，重启后这里会出现 dmesg-ramoops-N、console-ramoops-N 或 pmsg-ramoops-N。读完记得清掉或归档，否则下次新记录可能被旧的挤掉，也容易让人误判成“还是那次崩溃”。注意 ramoops 依赖“冷复位后 RAM 内容还在”；如果看门狗切的是整板断电，或 PMIC 把 DRAM 掉电了，这块区域一样是空的，那就得改接到 flash 上的 pstore 后端，或在复位前把日志刷到 eMMC 的一个小分区。

我建议把三件事写进板级文档：ramoops 的物理地址和大小、Bootloader 保证不擦除的承诺、以及量产镜像里采集这些文件的脚本（开机拷到 /var/log 再上传）。再补一条：panic=5 或自己的重启策略要给 pstore 留出刷入时间，复位太快会只写到一半。能复现的问题继续用串口和 crash dump；不能复现、只在客户现场半夜重启的问题，才是 pstore 真正值钱的地方。