从 bootloader 到 rootfs 的完整 Linux 搭建：代码评审该盯住哪些细节
从 bootloader 到 rootfs 的完整 Linux 搭建：代码评审该盯住哪些细节
启动链路的代码评审不能只看“板子能否启动”。一次看似无害的环境变量、分区偏移或默认启动项变动，都可能把升级风险留到现场。
按阶段审查启动链路
先画出 ROM、bootloader、内核、设备树和 rootfs 的交接关系，并标注每一步从哪里读取、怎样校验、失败后落到哪里。评审时要核对镜像格式、加载地址和分区边界是否在同一份配置中定义；多处手写偏移量很难维护，也容易造成版本错配。
环境变量尤其需要谨慎。默认启动参数、网络启动地址和升级命令应有允许列表，并区分开发板调试值与交付值。若支持 A/B 分区，必须确认切换条件、成功标记的写入时机和失败后的回退行为。这里不预设某个平台的分区布局，实际值以板级文档和构建配置为准。
把可恢复性作为验收项
至少验证正常启动、校验失败、镜像不匹配和升级中断四条路径。每条路径都应留下所用镜像版本、串口输出和恢复步骤。能启动并不等于能交付；另一位维护者按文档恢复到已知版本，才说明启动链路的交接信息足够。
评审结论的边界
本清单用于发现配置与版本之间的矛盾，不替代安全启动、密钥管理或量产流程。涉及签名密钥、烧录权限和设备数据的改动，应在隔离环境中执行并保留审批记录。
一个可检查的交接物
可以把镜像清单写成机器可读的manifest.json，其中至少列出 bootloader、内核、设备树和 rootfs 的文件名、校验值及目标分区。验证时从一台空白测试设备依照清单刷写，再故意替换其中一个文件，确认校验阶段会停止而不是进入启动流程。该测试只能证明当前刷写链路的行为，不能替代量产环境的密钥与权限验收。
按启动顺序审查
先确认 ROM、SPL、U-Boot、内核、设备树和 rootfs 的版本组合是否明确，并核对每一步的加载地址和镜像校验。分区表、擦写长度和对齐要求应来自实际存储器规格，不能从另一块板子直接复制。
环境变量要有默认值和恢复路径。自动启动命令、网络下载地址、根文件系统参数以及控制台配置都应能从代码或构建配置中追溯，避免把本地调试状态当成发布配置。
把失败路径放进验收
评审时补齐下面几类测试：镜像校验失败、升级中断电、rootfs 无法挂载、设备树与内核不匹配，以及回滚镜像不存在。若设备需要远程升级，版本比较、写入完成标志和回滚触发条件必须由设备端决定，不能依赖上位机“应该不会出错”。
最后保留串口启动日志和镜像哈希。它们比一张“启动成功”的截图更适合排查交付后的问题。
失败后的判断顺序
刷写后无法启动时，先用manifest.json核对实际写入的文件名、校验值和目标分区，再读取串口中最早出现的错误。校验不符通常应回到制品生成或传输环节；校验一致但找不到 rootfs，则继续检查设备树、内核参数和分区表。不要先改环境变量或加载地址，这会覆盖本来可以定位的证据。
验证中故意替换一个镜像文件，预期结果是更新流程在校验点终止并留下可读错误，而不是继续写入。若替换后设备仍进入启动流程，说明清单没有被真正执行，应阻断发布。若回滚镜像缺失，即使当前镜像能启动，也只能说明正常路径可用，不能视为升级流程完成验收。