ramoops ECC：暖复位后纠错能恢复什么
ramoops日志损坏时，需要分别回答两个问题：复位以后RAM内容是否仍在，以及保留下来的字节能否被纠正。启用ECC只涉及后一个问题的一部分。本文以Linux v6.12上游代码为边界，说明如何判断纠错是否适用、核对实际配置，并设计可审查的恢复验证。以下均为建议流程，不代表已经完成板级复位或故障注入实测。
先说明损坏现象，再讨论纠错
不要把“日志不存在”“正文夹杂乱码”和“恢复内核认为头部无效”放进同一个故障描述。先记录复位原因、固件版本、内核构建身份，以及是否重复采集了同一份记录。若启动固件已经清空该区域，空日志不能直接证明纠错功能失效；若原始内容根本未写入，增加校验字节也不能补回。
ramoops要求有关内存在重启后保留内容；软件ECC用于处理残留数据中的部分损坏。因此，断电、固件清零、覆盖写入和写入中断应分别建立假设。普通RAM不会因为打开ECC而成为非易失存储。依据见Linux 6.12 ramoops文档。
弄清校验保护了哪些对象
v6.12持久RAM实现分别维护数据块校验和缓冲区头部校验；调用者未指定时，默认数据块大小为128字节。恢复过程会累计已纠正字节和不可恢复块。这些计数描述解码器的观察结果，不能单独证明整次故障的日志已完整还原。相关实现见persistent RAM源码。
报告中至少区分三类结果：未检测到错误、发生纠正且恢复内容与独立参考一致、仍有内容不可相信。能读出一段调用栈不等于通过验收；还要核对事件标识和预期行号是否齐全。ECC也不提供防篡改认证，不能用它证明日志来源可信。
检查生效配置，避免沿用旧参数印象
在准确的构建配置中检查CONFIG_PSTORE与CONFIG_PSTORE_RAM。v6.12的PSTORE_RAM会选择Reed–Solomon编解码支持，但编译进这些组件并不意味着某个内存区域已经启用ECC。配置关系见pstore Kconfig。
# 在目标设备上进行只读检查
uname -r
cat /proc/cmdline
cat /sys/module/ramoops/parameters/ecc
dmesg | grep -Ei 'ramoops|persistent_ram|ECC'ecc的sysfs文件显示模块参数，v6.12驱动不会把设备树ECC设置同步到这里。使用设备树时，应核对实际ecc-size及启动证据，不能因这个文件显示零就断定纠错关闭。产品配置或权限可能使部分路径、信息不可见；此时应从交付物取出对应内核配置和实际部署的设备树。不能仅凭一个sysfs文件缺失作结论，也不应只看源码目录里尚未发布的配置。
模块参数ramoops.ecc=1具有历史兼容含义，表示16个ECC字节；设备树ecc-size则是字节数，应明确填写经过批准的值，例如16，不要把模块参数的简写照搬过去。核对启动日志、部署配置与参数来源是否一致。依据见ramoops驱动和设备树绑定。
把纠错开销放进证据预算
作为规划示例，128字节数据配16字节校验得到144字节块：校验相当于数据量的百分之十二点五，或整个块的约百分之十一点一。此外还有头部校验和取整开销。这个算式只解释比例，不能直接当作某个实际记录区的有效容量。
改变ECC设置前后，使用同一份有代表性的正常日志，检查定位故障需要的字段是否仍然保留。若新增冗余挤掉了关键前因，就应明确讨论纠错收益与上下文损失，不能把更大的ECC数值描述成无条件更可靠。配置评审还应保存布局版本，防止恢复系统使用不同几何参数读取旧内容。
在隔离环境设计损坏矩阵
优先建立离线或可控的测试程序，只操作归测试所有的可丢弃缓冲区，并匹配选定内核的布局和解码行为。准备包含连续行号、事件标识的已知消息，另存参考散列。分别安排未修改内容、数据字节修改、校验修改、头部损坏，以及集中在同一块与分散到不同块的损坏。所有输入必须标明人工合成。
每例保存注入前字节、修改位置、恢复输出、解码状态和逐字节比对结果。只有同时匹配预期内容，纠正计数才有充分解释价值。不可恢复案例必须明确失败，不能混入成功率。Reed–Solomon以符号工作，单纯记录翻转了几个比特并不足以描述测试条件，参见v6.12解码实现。
随后才考虑开发板暖复位实验：使用隔离设备，准备恢复手段，并获得中断工作负载的授权。不要在生产设备上通过物理内存接口随意注入。离线实验回答解码路径是否符合预期，板级复位实验还要回答实际保留行为，两者应各有记录。
交付有边界的验收结论
- 保存内核、固件、设备树、纠错几何与复位方式。
- 未损坏参考记录可读取，事件标识和关键行完整。
- 规定范围内的人工损坏有逐字节恢复证据。
- 不可恢复内容被显式标记，没有被当成完整日志。
- 说明断电、清零、覆盖和未完成写入的处理边界。
合适的结论是“该配置在规定复位路径下恢复了这些明确列出的损坏案例”。现场问题超出这个范围时，应重新检查保留假设，并保存现有证据，不能直接宣称ECC保证所有崩溃日志持久化。
