1. Zephyr OTA概述：从概念到实战

大家好，我是你们的嵌入式固件讲师。今天咱们聊聊OTA升级——这个在物联网时代绕不开的话题。说实话，我最早接触OTA是在一个智能家居项目里，设备已经部署到用户家里了，结果发现有个bug需要修复。你想想看，总不能派人挨家挨户去刷机吧？OTA就是解决这个问题的。

1.1 OTA到底是什么？

OTA，全称Over-The-Air，说白了就是通过无线方式给设备升级固件。我习惯把它理解成「设备的空中加油」。没有OTA，你的设备出厂时是什么样，一辈子就是什么样。有了OTA，设备就能持续进化。

为什么需要OTA？我总结了三个核心原因：

• 修复漏洞：产品上市后发现的bug，OTA能快速修补
• 功能迭代：给已部署设备增加新功能，延长产品生命周期
• 降低运维成本：不用派人现场维护，省时省力省钱

1.2 Zephyr OTA架构：一张图看懂

Zephyr的OTA架构，我习惯把它分成三层来看：

层级	组件	职责
应用层	固件管理子系统（FMU）	管理固件版本、触发升级、处理升级结果
传输层	HTTP/MQTT/CoAP + 下载管理器	从云端获取固件包，支持断点续传
引导层	MCUboot引导加载程序	验证固件签名、切换运行分区、回滚

嗯，这里要注意：Zephyr的OTA架构是解耦的。什么意思呢？就是你可以单独替换传输层协议，而不影响引导层的工作。我在项目中就试过把HTTP换成MQTT，MCUboot那边完全不用动。

1.3 MCUboot引导加载程序简介

MCUboot，这是Zephyr OTA的核心组件。我刚开始接触它的时候，觉得它就是个「启动管理器」。后来深入用了才发现，它远不止这么简单。

MCUboot的核心能力：

• 双分区管理：维护两个固件分区，一个运行，一个待升级
• 签名验证：用数字签名确保固件来源可信
• 安全回滚：新固件启动失败，自动切回旧版本
• 交换机制：支持swap、overwrite等多种升级策略

1.4 固件管理子系统（FMU）概览

FMU，全称Firmware Management Update。它是Zephyr里负责「升级流程」的模块。说白了，MCUboot管「怎么启动」，FMU管「怎么升级」。

FMU的主要功能：

1. 版本管理：记录当前固件版本，对比新版本
2. 下载管理：调用传输层下载固件包
3. 完整性校验：下载完成后检查固件哈希
4. 触发升级：通知MCUboot执行分区切换
5. 结果上报：升级成功或失败，反馈给应用层

FMU的代码结构，我给大家看个简化版：

// FMU核心数据结构
struct fmu_image {
    uint32_t version;      // 固件版本号
    uint8_t  hash[32];     // SHA256哈希
    uint32_t size;         // 固件大小
    uint8_t  *data;        // 固件数据指针
};

// 升级流程
int fmu_update_start(struct fmu_image *img);
int fmu_update_write(struct fmu_image *img, 
                     uint32_t offset, 
                     const uint8_t *data, 
                     uint32_t len);
int fmu_update_finish(struct fmu_image *img);

1.5 三者如何协同工作？

我画个流程图给大家看：

应用层触发升级
    ↓
FMU下载固件包
    ↓
FMU校验完整性
    ↓
FMU通知MCUboot
    ↓
MCUboot验证签名
    ↓
MCUboot执行分区交换
    ↓
设备重启
    ↓
MCUboot引导新固件
    ↓
新固件运行成功 → FMU上报成功
    ↓ (如果失败)
MCUboot自动回滚到旧固件

这个流程看起来简单，但每个环节都有坑。比如下载过程中断电怎么办？MCUboot有应对机制——它会在交换前备份旧固件，确保任何时候断电都不会变砖。

1.6 本章小结

好了，这一章我们聊了OTA的基本概念、Zephyr的OTA架构、MCUboot和FMU的职责。说白了，OTA升级就是「下载-验证-切换」三步走。MCUboot负责安全启动，FMU负责流程管理，两者配合才能实现可靠的远程升级。

下一章，我会带大家实际搭建Zephyr OTA开发环境，手把手配置MCUboot。到时候咱们再细聊那些踩过的坑。