2. 设备端硬件适配要点：Flash分区规划、存储选型与安全模块集成
硬件适配，说白了就是给OTA升级打好地基。我见过不少项目，软件写得漂漂亮亮，结果硬件选型没想清楚，升级到一半就变砖了。这一章咱们就聊聊Flash分区怎么划、存储芯片怎么挑、安全模块怎么集成。
2.1 Flash分区规划——升级的命脉
分区规划是OTA升级的起点。你想想看，升级过程中要擦写Flash，如果分区没留够余量，或者Bootloader和App区重叠了，那后果就是设备变砖。我个人习惯，分区规划要遵循三个原则：隔离、冗余、容错。
2.1.1 典型分区结构
一个标准的OTA升级分区，至少包含以下三个区域：
| 分区名称 | 功能 | 典型大小 | 注意事项 |
|---|---|---|---|
| Bootloader | 启动引导、校验App、回滚决策 | 64KB ~ 256KB | 必须写保护，不能OTA更新 |
| App (主运行区) | 当前运行的固件 | 512KB ~ 4MB | 根据实际固件大小留20%余量 |
| OTA临时区 | 下载新固件、校验、备份 | ≥ App区大小 | 必须独立，不能与App区共用 |
核心原则：OTA临时区的大小必须 ≥ App区大小。我曾经遇到一个项目，临时区只留了App区的80%，结果新固件稍微大了一点，下载到一半就写不下了——那叫一个尴尬。
2.1.2 分区布局示例
以一颗16MB的Flash为例，我常用的分区布局是这样的：
// 16MB Flash 分区布局示例
// 地址从0x000000开始
0x000000 - 0x03FFFF (256KB) Bootloader
0x040000 - 0x07FFFF (256KB) 参数区 (NVS/配置)
0x080000 - 0x47FFFF (4MB) App (主运行区)
0x480000 - 0x87FFFF (4MB) OTA临时区 (下载+备份)
0x880000 - 0xFFFFFF (7.5MB) 文件系统/日志/用户数据我的经验：参数区最好单独划出来，不要和App混在一起。升级时参数区不动，这样升级完配置还在，用户体验好很多。
2.1.3 避坑指南
- Bootloader写保护：硬件上把Bootloader区设为只读，防止意外擦写。我曾经见过一个产品，Bootloader和App共用一块Flash，结果升级时擦错了地址，直接变砖。
- OTA临时区不要太小：留足余量，至少是App区的1.2倍。新固件可能会增加功能、修复bug，体积只会越来越大。
- 分区对齐：Flash的擦除块大小通常是4KB或64KB，分区起始地址要对齐到擦除块边界，否则擦写效率会很低。
2.2 存储介质选型——NOR、NAND还是eMMC？
存储介质的选择，直接影响升级的可靠性和速度。我做过几个项目，从NOR Flash到eMMC都折腾过，这里说说我的体会。
2.2.1 三种主流存储对比
| 特性 | NOR Flash | NAND Flash | eMMC |
|---|---|---|---|
| 读取速度 | 快（XIP直接执行） | 较慢（需要先读到RAM） | 快（内置控制器） |
| 写入速度 | 慢（按字节写） | 快（按页写） | 快（缓存+并行） |
| 擦除块大小 | 64KB ~ 256KB | 128KB ~ 2MB | 由内部FTL管理 |
| 坏块管理 | 不需要 | 必须软件管理 | 内置（FTL） |
| 典型容量 | 1MB ~ 64MB | 128MB ~ 8GB | 4GB ~ 128GB |
| 典型应用 | Bootloader、小容量IoT | 中容量嵌入式 | 大容量、高性能设备 |
注意：NAND Flash有坏块问题，必须做坏块管理和ECC校验。我有个朋友做智能家居，用了NAND没做坏块管理，结果设备用了半年就频繁死机——升级时写到了坏块上。
2.2.2 选型建议
- 小容量设备（< 64MB）：优先选NOR Flash。XIP特性让代码可以直接在Flash上执行，省RAM，升级也简单。
- 中容量设备（64MB ~ 2GB）：NAND Flash性价比高，但要做好坏块管理和ECC。我个人习惯用SLC NAND，寿命长、可靠性高。
- 大容量设备（> 2GB）：直接上eMMC。内置FTL和坏块管理，软件工作量少很多。升级时用eMMC的专用命令，速度也快。
2.3 硬件安全模块集成——SE/TPM
OTA升级的安全，不能只靠软件。硬件安全模块（SE/TPM）是防止固件被篡改、密钥被窃取的关键。嗯，这里要注意，不是所有设备都需要，但如果你做的是金融、车联网、医疗设备，那必须上。
2.3.1 SE vs TPM 对比
| 特性 | SE (安全元件) | TPM (可信平台模块) |
|---|---|---|
| 核心功能 | 密钥存储、加密运算 | 平台完整性度量、密钥管理 |
| 通信接口 | I2C/SPI | LPC/SPI |
| 典型应用 | 移动支付、身份认证 | PC、服务器、IoT网关 |
| 成本 | 较高 | 中等 |
| OTA安全场景 | 固件签名验证、密钥协商 | 固件完整性度量、安全启动 |
2.3.2 集成要点
- 密钥生成：在SE/TPM内部生成密钥对，私钥永远不离开芯片。我见过有人把私钥写在代码里，那跟没加密一样。
- 固件签名验证：升级包用私钥签名，设备端用SE/TPM里的公钥验证。验证过程在安全芯片内部完成，防止软件被篡改。
- 安全启动链：Bootloader验证SE/TPM的度量值，SE/TPM验证App的签名，形成一条信任链。任何一个环节被破坏，设备就不启动。
我的建议：如果预算允许，尽量用SE。TPM虽然便宜，但功能偏平台完整性，对OTA升级的密钥管理支持不如SE直接。当然，如果设备已经有TPM了，那就别浪费，用起来。
2.4 本章知识结构图
下面这张图，把Flash分区、存储选型、安全模块的关系串起来了。你一看就明白。
一句话总结：Flash分区要留够余量，存储选型看容量和可靠性需求，安全模块能上就上。这三样搞定了，OTA升级的硬件基础就稳了。