4. 版本管理机制：内核版本号规范、设备树（DTB）版本管理、固件版本一致性检查
版本管理这事儿，说大不大，说小不小。我见过太多回滚失败的案例，最后定位下来，根因就是版本号乱写、设备树和内核不匹配、固件各管各的。你想想看，启动参数设计得再完美，如果版本管理一团糟，回滚保护就是个摆设。
这一节，咱们就聊聊怎么把版本管起来。内核版本号怎么定、设备树怎么跟内核绑定、固件之间怎么互相校验——这三件事搞定了，回滚保护才算有了根基。
4.1 内核版本号规范：别让版本号变成流水号
很多团队喜欢用日期当版本号，比如 kernel-20250101。说实话，这玩意儿除了告诉你哪天编译的，啥信息都没有。回滚的时候，你根本不知道这个版本能不能跟当前设备树配合，也不知道它修复了哪些关键问题。
我个人习惯用 语义化版本 + 构建元数据 的组合。格式如下：
MAJOR.MINOR.PATCH-构建号-硬件平台-提交哈希举个例子：
5.10.100-20250101-imx8m-ga7b3e2f拆开来看：
| 字段 | 含义 | 回滚时怎么用 |
|---|---|---|
| 5.10.100 | 内核主线版本 | 判断是否支持当前硬件驱动 |
| 20250101 | 构建日期（UTC） | 快速定位构建时间线 |
| imx8m | 目标硬件平台 | 防止刷错固件到不同硬件 |
| ga7b3e2f | Git 提交哈希 | 精确回溯代码变更 |
另外，内核在运行时也会暴露版本号。你可以在 /proc/version 里看到它。我建议在启动参数里加一个 kernel.version= 字段，让 bootloader 把预期版本号传给内核。内核启动时自己校验一下，不匹配就直接 panic，别硬跑。
4.2 设备树（DTB）版本管理：绑定比独立更重要
设备树这玩意儿，说白了就是硬件的「身份证」。内核通过它知道板子上有哪些外设、怎么初始化。但问题来了——设备树和内核是分开编译的，很容易出现版本错配。
我记得有一次，客户反馈某款设备在升级后网口不工作了。查了半天，发现是 DTB 来自旧版本内核，新内核改了网口驱动，但 DTB 里还用的是旧的中断号。嗯，这就是典型的 DTB 版本没管好。
怎么解决？我的做法是 DTB 和内核强绑定：
- DTB 版本号嵌入内核版本号：在 DTB 的
/节点下加一个kernel-version属性。 - bootloader 校验 DTB 兼容性：加载 DTB 前，先读这个属性，跟内核的预期版本比对。
- 不匹配就 fallback：如果 DTB 版本太老或太新，bootloader 自动加载备份 DTB。
DTB 里的版本信息长这样：
/dts-v1/;
/ {
model = "MyBoard v2";
compatible = "mycompany,myboard-v2";
kernel-version = "5.10.100";
dtb-version = "2.1.0";
chosen {
bootargs = "console=ttymxc0,115200";
};
memory@80000000 {
device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
};compatible 字符串也要纳入版本管理。如果硬件改版了，compatible 必须跟着变。否则内核可能会用错的驱动匹配表，导致初始化失败。
另外，我建议在构建系统里把 DTB 和内核镜像打包成一个 .itb 文件（FIT Image）。这样 bootloader 一次加载，要么全对，要么全错，不存在「内核是新的、DTB 是旧的」这种尴尬局面。
4.3 固件版本一致性检查：别让一个老鼠屎坏了一锅粥
嵌入式系统里，固件不止一个。bootloader、内核、rootfs、甚至 FPGA 固件、MCU 固件……它们之间往往有依赖关系。比如某个 bootloader 版本只支持特定版本的内核启动参数格式，或者某个 FPGA 固件需要特定版本的驱动。
我参与过一个项目，升级了 FPGA 固件，但忘了更新对应的 MCU 固件。结果两个芯片之间的通信协议对不上，整机直接死机。从那以后，我强制要求所有固件在启动时做 版本一致性检查。
检查流程是这样的：
- bootloader 收集所有固件版本：从每个固件的头部信息里读取版本号。
- 比对版本兼容性矩阵：bootloader 内部维护一张兼容性表，或者从 DTB 里读取兼容性规则。
- 不兼容则触发回滚：如果发现某个固件版本不在兼容范围内，直接切换到备份分区。
兼容性矩阵可以放在 DTB 的 chosen 节点里：
chosen {
firmware-compatibility {
bootloader = ">=2.0.0,<3.0.0";
kernel = ">=5.10.100";
fpga = ">=1.5.0";
mcu = ">=2.1.0,<2.3.0";
};
};bootloader 解析这个矩阵，然后逐一比对。如果某个固件版本不在范围内，就记录错误日志，然后执行回滚。
4.4 整体版本管理流程
说了这么多，咱们画张图把整个流程串起来。这样你脑子里能有个全局印象。
这张图展示了从构建到部署的完整流程。你看，每个阶段都有版本管理的「关卡」。构建时嵌入版本号，打包时生成校验信息，部署时 bootloader 做一致性检查。任何一个环节出问题，都能在启动早期被发现。
4.5 避坑指南
最后，分享几个我踩过的坑：
- 别用「自动递增」版本号：自动递增的版本号没法回溯代码变更。我建议用 Git 提交哈希或者 Tag 作为版本号的一部分。
- DTB 和内核的兼容性要双向检查：不光要检查 DTB 是否支持当前内核，还要检查内核是否支持当前 DTB。我遇到过内核新版本删除了旧 DTB 的兼容代码，结果 DTB 虽然版本对，但内核已经不认了。
- 固件版本一致性检查要覆盖所有固件：别只检查 bootloader 和内核。FPGA、MCU、甚至传感器固件，只要它们之间有依赖关系，都得纳入检查范围。
- 版本兼容性矩阵要可更新：兼容性规则不是一成不变的。我建议把矩阵放在 DTB 或者单独的配置分区里，这样升级时可以直接更新规则，不用改 bootloader 代码。
chosen 节点里加一个 version-history 属性，记录每次 DTB 变更的摘要。这样调试时一眼就能看出 DTB 改了什么，不用去翻 Git 日志。
版本管理这事儿，说白了就是「给每个组件一个身份证，然后互相验一下」。做好了，回滚保护就有了底气。做不好，再好的启动参数设计也白搭。