在 SWUpdate 中，使用 恢复模式（Recovery Mode） 而不是 A/B 分区（A/B Seamless）模式 部署更新，通常需要以下步骤。恢复模式的核心思想是通过一个独立的恢复分区（或恢复系统）来管理更新，确保在主系统更新失败时能够回滚到已知的正常状态。
- 系统分区设计
恢复模式通常需要以下分区布局（示例）：
boot：引导分区（包含内核和 initramfs）。rootfs：主系统根文件系统。recovery：独立的恢复系统分区（包含恢复环境和 SWUpdate）。data：数据分区（可选，用于持久化数据）。swupdate：SWUpdate 的专用分区（存储更新镜像.swu文件，可选）。
- 配置 SWUpdate 恢复模式
(1) 启用恢复模式
在 SWUpdate 的配置文件（swupdate.conf）中，配置恢复模式：
conf
recovery
enabled = true
device = /dev/mmcblk0p3 恢复分区设备路径
mountpoint = /recovery 挂载点
bootloader = “uboot” 使用的引导加载程序（如 U-Boot）
(2) 配置镜像类型
在 .swimage 描述文件（如 sw-description）中，指定镜像类型为 recovery：
conf
images:
{
filename = “rootfs.ext4”;
device = “/dev/mmcblk0p2”; 主系统根文件系统分区
type = “raw”;
installed-directly = true;
}
{filename = "recovery.ext4";device = "/dev/mmcblk0p3"; 恢复分区type = "recovery"; 关键：标记为恢复镜像
}
- 构建恢复系统镜像
恢复系统需要包含：
- 最小化的 Linux 系统（如 BusyBox）。
- SWUpdate 可执行文件。
- 必要的驱动和工具（如
mtd-utils、uboot-env）。 - 启动脚本（例如自动检测并应用更新）。
示例恢复系统目录结构：
/recovery
├── bin
│ ├── sh
│ └── swupdate
├── etc
│ └── swupdate.conf
└── init 恢复系统的初始化脚本
- 引导加载程序（Bootloader）配置
配置引导加载程序（如 U-Boot）支持恢复模式：
- 设置一个环境变量（如
boot_recovery）用于触发恢复流程。 - 默认启动主系统，更新失败时自动切换到恢复系统。
U-Boot 示例配置：
bash
正常启动主系统
setenv bootcmd “load mmc 0:1 ${loadaddr} zImage; bootm ${loadaddr}”
恢复模式启动命令
setenv boot_recovery “load mmc 0:3 ${loadaddr} zImage_recovery; bootm ${loadaddr}”
检测是否需要恢复
if test “${swupdate_status}” = “failed”; then
run boot_recovery;
else
run bootcmd;
fi
-
更新流程
-
触发更新：
bash
swupdate -i firmware.swu -v- SWUpdate 会将镜像写入主系统分区（
rootfs）和恢复分区（recovery）。
- SWUpdate 会将镜像写入主系统分区（
-
重启并验证：
- 系统重启后，首先尝试启动主系统。
- 如果主系统启动失败（例如无法挂载根文件系统），引导加载程序会切换到恢复分区。
-
恢复系统操作：
- 恢复系统启动后，自动检测到更新失败，并触发回滚：
bash
swupdate --recover - 回滚到之前的已知正常版本。
- 恢复系统启动后，自动检测到更新失败，并触发回滚：
- 回滚机制
- 在恢复系统中实现回滚逻辑（例如从备份分区恢复）。
- 可以通过在
data分区保存状态文件（如/data/swupdate.status）记录更新结果。
-
关键注意事项
-
分区冗余：
- 恢复分区和主系统分区需要足够的空间，确保更新过程中不会因空间不足失败。
-
原子性操作：
- 使用
installed-directly = true确保镜像直接写入目标设备，避免中间状态。
- 使用
-
恢复系统独立性：
- 恢复系统必须独立于主系统，避免依赖主系统的任何组件。
-
测试回滚流程：
- 强制模拟失败（如写入损坏的镜像），验证恢复系统是否能正确回滚。
总结
- 恢复模式适合资源有限的设备，无需双系统（A/B）的冗余开销。
- 需要仔细设计分区布局、引导流程和回滚逻辑。
- 与 A/B 模式相比，恢复模式需要更长的停机时间（需重启），但实现更简单。
如果需要进一步优化，可以结合 RAUC 或自定义脚本增强可靠性。
