1. 课程导入与工程全景

在嵌入式Linux产品从“能跑起来”走向“可交付、可维护、可远程运维”的过程中，固件升级能力往往是最容易被低估、却最容易在量产阶段暴露问题的一环。STM32MP系列（如STM32MP157、STM32MP135）作为ST主推的异构多核MPU平台，运行完整Linux系统，其升级方案不能照搬MCU时代的“跳转Bootloader+擦写Flash”思路，而必须面对分区布局、根文件系统切换、掉电安全、回滚策略等一系列系统级问题。本课程围绕“OTA（Over-The-Air）远程升级”与“A/B双分区升级”两条主线展开，目标是让学员能够独立设计并实现一套在STM32MP平台上可落地、可验证、可回滚的升级系统。

为什么STM32MP的OTA不能简单照搬MCU方案

STM32MP1内部集成Cortex-A7与Cortex-M4双核，A7运行Linux，M4可运行RTOS或裸机固件。一次完整的系统升级，可能涉及TF-A（Trusted Firmware-A）、U-Boot、Linux内核、设备树、根文件系统，甚至M4的协处理器固件。这些组件分布在eMMC、SD卡或QSPI-NOR等不同存储介质上，启动链层层递进。如果升级过程中只更新了内核却忘了同步设备树，或者根文件系统写入一半断电，设备就可能彻底无法启动。因此，OTA在MPU平台上的本质不是“传文件”，而是“在保证可启动、可回滚的前提下，安全地替换一整套启动资产”。

A/B双分区机制正是为解决这一矛盾而生的工程手段。系统维护两套完整的启动分区（A与B），当前运行的分区称为active，另一套称为standby。升级时，数据只写入standby分区，active分区保持原样；写入完成并校验通过后，通过修改启动标志（bootcount、bootslot等）让Bootloader在下一次启动时切换到新分区。若新分区启动失败，Bootloader根据失败计数自动回退到旧分区。这样，升级过程对当前运行系统“零干扰”，掉电或写入错误也不会导致设备变砖。

典型应用场景与工程约束

在工业网关、边缘计算盒子、医疗设备、车载终端等场景中，STM32MP设备往往部署在难以物理接触的位置。一旦现场设备出现软件缺陷，返厂维修的成本远高于远程推送一次升级包。OTA的价值在于：设备联网后，由云端或本地服务器下发升级包，设备端完成下载、校验、写入、切换、验证的全流程。而A/B机制则保证了这个流程在任意时刻断电都不会导致设备无法启动。

实际工程中需要关注的约束包括：升级包大小与网络带宽的匹配（例如一个包含RootFS的完整包可能达到200MB以上，而4G网络下需要断点续传）；eMMC的写入寿命（频繁全量写入会加速磨损，因此需要差分升级或增量更新策略）；启动失败判定的阈值（bootcount上限通常设为3次，超过则回滚）；以及升级过程中的电源稳定性要求（建议在升级期间检测电源电压，低于阈值时暂停写入）。这些约束不是理论假设，而是决定方案能否量产的关键参数。

整体学习路径与实战项目

本课程按照“先建立全景认知，再逐层深入实现”的思路组织。前几章会先讲清楚STM32MP的启动链与分区结构，理解TF-A、U-Boot、Kernel、RootFS各自在升级中的角色；随后进入U-Boot环境变量与启动脚本的改造，这是A/B切换的核心控制点；接着实现用户态的升级代理程序，负责下载、校验、写入standby分区并设置启动标志；最后完成回滚验证与产线烧录方案。

贯穿课程的实战项目是：为一块STM32MP157开发板（eMMC启动）构建一套完整的A/B OTA系统。项目会提供具体的分区表配置、U-Boot脚本片段、升级代理的伪代码与关键实现、以及一套可复现的测试用例——包括正常升级、升级中断电、新分区启动失败自动回滚三种场景。学员完成项目后，应能独立将这套方案移植到自己的STM32MP产品上。

关键概念速览