📚 课程目录第3章 Edge AI设备存储结构

3、Edge AI设备存储结构：了解常见存储分区（boot、rootfs、app、data）及更新时的影响范围

Edge AI设备的离线更新，本质上是对设备存储介质上特定分区内容的替换或修补。如果对存储分区结构没有清晰认知，任何更新操作都如同在黑暗中拆解炸弹——你可能成功替换了应用代码，却意外破坏了引导加载程序，导致设备变砖。本章将深入剖析Edge AI设备中常见的四类存储分区（boot、rootfs、app、data），明确每个分区的功能边界、更新影响范围以及操作中的关键约束，帮助你在制定离线更新策略时做到“指哪打哪”，避免误伤。

上图展示了Edge AI设备存储介质的典型分区布局。在实际硬件中，这些分区可能位于同一颗eMMC芯片、NAND Flash或SD卡上，通过分区表（如或MTD分区）进行逻辑划分。理解每个分区的角色，是制定安全更新策略的第一步。

3.1 核心原理：四大分区的功能边界与依赖关系

Edge AI设备的存储分区设计遵循“关注点分离”原则，每个分区承担独立职责，同时通过启动链和挂载关系形成紧密协作。下面逐一剖析每个分区的核心功能。

3.1.1 Boot分区：设备启动的“第一级火箭”

Boot分区存放设备上电后最早执行的代码，通常包括：

SPL/第一阶段引导程序：初始化DDR内存、时钟和存储控制器，加载U-Boot主程序。
U-Boot主程序：负责加载内核镜像到内存，传递启动参数，支持网络/串口/存储等多种启动方式。
设备树（DTB）：描述硬件拓扑、寄存器地址、中断映射等硬件信息，供内核启动时解析。
内核镜像（zImage/Image）：Linux内核的压缩或非压缩版本，是操作系统的核心。

Boot分区的更新影响范围是全局性的。一旦Boot分区损坏，设备将无法完成最基本的启动流程，表现为上电无串口输出、指示灯异常、无法进入升级模式等“变砖”症状。因此，几乎所有Edge AI设备都会对Boot分区实施写保护或采用A/B备份机制。

3.1.2 Rootfs分区：系统运行的“地基”

Rootfs分区挂载为根文件系统（/），包含Linux运行所需的全部基础组件：

系统库：glibc/musl、OpenSSL、zlib等动态链接库。
内核模块：设备驱动（.ko文件），如WiFi驱动、摄像头驱动、NPU驱动。
系统服务：systemd/init脚本、网络管理、日志服务（syslog/journald）。
基础命令：busybox或coreutils提供的shell工具。

Rootfs的更新影响范围是系统级的。更新Rootfs会替换系统库和驱动，可能导致已安装的应用因依赖版本变化而无法运行。例如，将glibc从2.28升级到2.31后，某些旧版AI推理框架可能因符号缺失而崩溃。Rootfs更新通常需要重启设备才能生效，且更新过程中断电会导致系统不完整。

3.1.3 App分区：业务逻辑的“容器”

App分区是Edge AI设备中更新最频繁的区域，存放用户业务相关的所有内容：

AI推理引擎：TensorFlow Lite、ONNX Runtime、RKNN等运行时库。
业务应用代码：Python/Node.js/C++编写的推理服务、数据采集程序。
模型文件：训练好的神经网络权重（.tflite/.rknn/.onnx格式）。
配置文件：应用级参数，如推理阈值、相机参数、网络配置。

App分区的更新影响范围是应用级的。更新App分区通常不影响系统稳定性和其他分区数据，但需要确保新版本应用与当前Rootfs中的库版本兼容。例如，如果新模型需要更高版本的NPU驱动，而Rootfs未同步更新，则推理性能可能下降或直接报错。

3.1.4 Data分区：持久化数据的“保险箱”

Data分区挂载为/data或/userdata，用于存储运行过程中产生的动态数据：

日志文件：应用运行日志、系统审计日志。
用户配置：设备序列号、校准参数、网络凭据。
缓存数据：临时推理结果、图像缓存、OTA下载包。
数据库：SQLite等嵌入式数据库文件。

Data分区的更新影响范围是数据级的。在系统升级时，Data分区通常被保留，以确保用户数据和设备配置不丢失。但某些特殊场景（如恢复出厂设置）会主动擦除Data分区。

核心记忆点：Boot分区管“启动”，Rootfs分区管“系统”，App分区管“业务”，Data分区管“数据”。更新影响范围从全局到局部依次递减：Boot > Rootfs > App > Data。

3.2 判断方法：如何识别设备的分区布局与更新影响

在实际维护中，你需要快速判断目标设备的分区结构，才能决定更新包应该写入哪个分区。以下是标准判断流程：

查看分区表：通过串口或SSH登录设备，执行 cat /proc/partitions 或 fdisk -l 查看当前分区列表。
识别挂载点：执行 mount 命令，查看每个分区对应的挂载路径，确认哪个分区是rootfs、哪个是data。
检查Boot分区内容：执行 ls /boot/ 查看是否包含内核镜像和设备树文件。
确认App分区路径：通常App分区挂载在 /app、/opt 或 /userdata，具体取决于系统设计。
评估更新影响：根据更新包内容判断其目标分区，并评估对现有系统的影响。

以下是一个典型的分区信息输出示例：

# cat /proc/partitions
major minor  #blocks  name
  93        0    7634944 mmcblk0
  93        1     131072 mmcblk0p1   # Boot分区 (128MB)
  93        2    2097152 mmcblk0p2   # Rootfs分区 (2GB)
  93        3    1048576 mmcblk0p3   # App分区 (1GB)
  93        4    4194304 mmcblk0p4   # Data分区 (4GB)

# mount | grep mmcblk0
/dev/mmcblk0p2 on / type ext4 (rw,relatime)
/dev/mmcblk0p3 on /app type ext4 (rw,relatime)
/dev/mmcblk0p4 on /data type ext4 (rw,relatime)

3.3 案例拆解：一次U盘更新引发的“分区灾难”

某工业视觉检测设备使用瑞芯微RK3588平台，存储为64GB eMMC，分区布局如下：Boot分区256MB、Rootfs分区8GB、App分区16GB、Data分区剩余空间。设备运行Linux 5.10内核，AI推理应用部署在App分区。

初始现象：现场工程师使用U盘执行离线升级，更新包中包含新的内核镜像（zImage）、设备树（rk3588-evb.dtb）和升级后的AI推理应用。工程师按照旧版升级文档操作，将整个更新包直接写入App分区，未对Boot和Rootfs分区做区分处理。

关键参数与日志：升级完成后设备重启，串口输出以下信息：

U-Boot SPL 2021.04
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
ERROR: FDT image not found!

分析判断过程：从日志可见，U-Boot在加载设备树时失败。进一步检查发现，更新包中的内核镜像和设备树被错误地写入了App分区，而Boot分区中的旧内核仍在尝试加载旧设备树，但新旧内核与设备树版本不匹配，导致启动中断。

实际操作步骤：

使用串口进入U-Boot命令行，通过 mmc 命令手动加载Boot分区中的备份内核。
从备份内核启动系统后，将正确的内核镜像和设备树重新写入Boot分区：
```
mount /dev/mmcblk0p1 /mnt/boot
cp zImage rk3588-evb.dtb /mnt/boot/
sync
umount /mnt/boot
```
将AI推理应用更新包单独写入App分区，并重启验证。

结果对比：修复后设备正常启动，AI推理应用运行稳定。但整个排障过程耗时4小时，导致产线停线损失约8万元。

风险与代价：该事故的根本原因是更新脚本未区分分区类型，将Boot相关文件与App文件混在一起写入。如果Boot分区完全损坏且无备份，设备将需要返厂维修，成本更高。

复盘经验：离线更新包必须按分区打包，每个分区独立校验；更新前应检查Boot分区写保护状态；建议在Boot分区保留一份可用内核备份。

风险警示：切勿将内核镜像、设备树等Boot分区文件写入App或Data分区。Boot分区更新失败可能导致设备永久变砖，且现场无法恢复。

3.4 常见误区与总结复盘

在Edge AI设备的存储分区管理中，以下误区需要特别警惕：

误区	后果	正确做法
认为所有分区都可以随意覆盖	Boot分区损坏导致设备无法启动	对Boot分区实施写保护或A/B备份
更新Rootfs后不检查应用兼容性	AI推理应用因库版本不匹配而崩溃	更新前检查依赖库版本，必要时同步更新App
升级时格式化Data分区	设备序列号、校准参数丢失	升级脚本中保留Data分区，仅清除缓存目录
忽略分区剩余空间检查	写入过程中空间不足，分区损坏	更新前检查 `df -h` 确认空间充足

总结复盘：Edge AI设备的存储分区管理是离线更新的基石。Boot分区是“高压线”，Rootfs分区是“承重墙”，App分区是“工作台”，Data分区是“档案室”。在实际操作中，务必遵循以下原则：

分区隔离：更新包必须按分区独立打包，禁止跨分区写入。
版本兼容：更新App前，确认其与当前Rootfs的库版本兼容。
数据保护：除非恢复出厂设置，否则Data分区应始终保留。
备份优先：更新Boot分区前，必须确保有可用的备份引导方案。
校验闭环：写入后必须进行完整性校验（如MD5/SHA256），确认数据正确后再重启。