从 bootloader 到 rootfs 的完整 Linux 搭建：代码评审该盯住哪些细节

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