RK3588内核崩溃日志捕获：pstore与ramoops实战解析
1. 为什么需要内核崩溃日志捕获
搞嵌入式开发的兄弟应该都遇到过这种情况：设备跑着跑着突然死机，重启后一脸懵逼——刚才到底发生了什么？特别是像RK3588这样的高性能处理器，一旦内核崩溃，如果没有可靠的日志捕获机制，调试起来简直就像在黑暗中摸象。
我去年就踩过这个坑。当时给客户调试一个RK3588的视频处理设备，连续运行三天后突然挂掉。重启后查看常规日志，啥关键信息都没有。最后只能加printk大法，又熬了两个通宵才定位到问题。要是早点用上pstore和ramoops，至少能省下30%的调试时间。
pstore（Persistent Storage）是Linux内核提供的一个持久化存储子系统，它能在系统崩溃时保存关键日志。而ramoops则是pstore的一个具体实现，利用预留的内存区域来存储崩溃信息。这对组合最大的优势是：
- 不依赖外部存储设备
- 即使文件系统挂掉也能工作
- 支持多种日志类型（dmesg、console、ftrace等）
2. RK3588上的pstore配置实战
2.1 内核配置修改
首先得确保内核支持相关功能。我用的是RK3588的Linux 5.10内核，配置步骤如下：
make menuconfig找到这些关键选项：
Device Drivers ---> [*] Persistent store support [*] Log kernel console messages [*] Log user space messages [*] Log panic/oops to a RAM buffer (3) Panic timeout in seconds (NEW)更直接的方法是修改defconfig文件，添加以下配置：
CONFIG_PSTORE=y CONFIG_PSTORE_CONSOLE=y CONFIG_PSTORE_PMSG=y CONFIG_PSTORE_RAM=y CONFIG_PANIC_TIMEOUT=3这里有个实用技巧：CONFIG_PANIC_TIMEOUT=3表示系统崩溃后等待3秒再重启。时间太短可能来不及保存日志，太长又影响设备自恢复。经过多次测试，3秒是个比较稳妥的值。
2.2 设备树配置
接下来要在设备树中预留ramoops的内存区域。打开rk3588-linux.dtsi，添加：
ramoops: ramoops@110000 { compatible = "ramoops"; reg = <0x0 0x110000 0x0 0xf0000>; record-size = <0x20000>; console-size = <0x80000>; ftrace-size = <0x00000>; pmsg-size = <0x50000>; };参数解释：
reg：内存区域起始地址0x110000，大小0xf0000（约960KB）record-size：oops/panic日志大小console-size：控制台日志大小pmsg-size：用户空间消息大小
这里有个坑要注意：内存地址不能和其他区域冲突。建议先用cat /proc/iomem查看内存使用情况。
3. 触发测试与日志提取
3.1 手动触发崩溃
配置好后，可以用这个命令模拟内核崩溃：
echo c > /proc/sysrq-trigger系统会立即触发panic，3秒后自动重启。这个测试我在开发板上跑了十几次，稳得很。
3.2 日志存放位置
不同系统存放位置可能不同，常见的有：
- Ubuntu/Debian:
/var/lib/systemd/pstore/ - Android:
/sys/fs/pstore/ - 其他系统可能直接挂载到
/mnt/pstore
可以用这个命令查找：
find / -name "*ramoops*" 2>/dev/null找到的日志文件通常是这样的命名格式：
dmesg-ramoops-0 console-ramoops-03.3 日志分析技巧
拿到日志后，先用dmesg查看：
dmesg -wH --color=always | less -R重点看崩溃前的最后几条日志。如果日志不完整，可以调整console-size参数增大缓冲区。
我遇到过一个典型问题：视频解码时触发空指针异常。从ramoops日志中直接看到了调用栈：
[ 4563.721234] Unable to handle kernel NULL pointer dereference [ 4563.721567] Call trace: [ 4563.721789] rk_vcodec_dec_run+0x128/0x230 [ 4563.722012] rkvdec2_worker+0x64/0x100这比盲目猜测高效多了。
4. 高级调试技巧
4.1 多日志类型配置
除了基本的dmesg，还可以配置更多日志类型：
ftrace-size = <0x40000>; // 增加ftrace支持 pmsg-size = <0x30000>; // 用户空间日志需要对应的内核配置：
CONFIG_PSTORE_FTRACE=y CONFIG_PSTORE_PMSG=y4.2 自动上传日志
对于量产设备，可以写个systemd服务自动上传崩溃日志：
[Unit] Description=Upload panic logs After=pstore.service [Service] Type=oneshot ExecStart=/usr/bin/curl -F "file=@/var/lib/systemd/pstore/dmesg-ramoops-0" http://log-server/upload [Install] WantedBy=multi-user.target4.3 内存不足处理
如果遇到日志丢失，可能是内存不足。可以通过dmesg | grep ramoops查看实际分配情况。我建议预留至少1MB空间：
reg = <0x0 0x200000 0x0 0x100000>; // 1MB空间5. 常见问题排查
问题1：配置后看不到日志文件
- 检查内核是否真的panic过（
cat /proc/cmdline看是否有panic参数） - 确认文件系统有写入权限
- 检查内存区域是否被其他驱动占用
问题2：日志不完整
- 增大
record-size和console-size - 检查是否有early panic（在内核完全初始化前崩溃）
问题3：系统无法自动重启
- 确认
CONFIG_PANIC_TIMEOUT设置正确 - 检查硬件看门狗配置
记得第一次调试时，我忘了开看门狗，结果设备死机后就一直卡着。后来加了硬件看门狗+软件panic超时，双重保障才放心。
这套方案在RK3588上跑了半年多，捕获了不下20次崩溃日志，帮团队节省了大量调试时间。现在只要是Linux项目，我都会第一时间把pstore配置好——毕竟谁也不知道崩溃和明天哪个先来。