📺B站：博主个人介绍
📘博主书籍-京东购买链接*：Yocto项目实战教程
📘加博主微信，进技术交流群：jerrydev
RK3588 分区表详解：每一块分区到底装了什么、负责什么
目标：把你给出的分区表“讲透”。你看完这篇之后，应该能回答三类问题：
每个分区里放的是什么（文件/镜像/数据结构）。
系统启动时它什么时候被用到。
开发/量产/OTA 时该怎么刷、怎么留、坏了会怎样。
场景默认：RK3588 + Linux（Buildroot/Yocto 都适用），分区采用 GPT，常见 Rockchip SDK 打包/烧录流程。
0. 先把分区表摆出来（你当前设备）
你在设备上看到的 GPT 分区如下：
- 1 uboot 4MB
- 2 misc 4MB
- 3 boot 64MB
- 4 recovery 128MB
- 5 backup 32MB
- 6 rootfs 14.0GB
- 7 oem 128MB
- 8 userdata 14.7GB (grow)
以及你前面讨论的（可选）
- security 常见 4MB（在
parameter.txt里额外加出来）
说明：实际项目里还可能出现
loader1/loader2、trust、resource、dtbo、vbmeta等分区。你这套布局属于“偏 Linux 发行版风格（rootfs 很大）”的方案。
1. 总览表（你要求的那张表，保持原样输出）
| 分区 | 大小 | 常见刷写文件（示例） | 主要包含内容 | 核心功能（你关心的“它干啥的”） |
|---|---|---|---|---|
| uboot | 4MB | uboot.img | U-Boot 启动链相关组件；RK3588 常见还会把TEE binary（BL32/OP-TEE）一起打包进去 | 上电后最关键的启动阶段：初始化硬件、加载内核/启动参数；并承载 Secure Monitor/TEE 相关入口（因此你看到很多 TEE/TA 话题最终都会“落到 uboot.img”） |
| misc | 4MB | misc.img | 少量“控制信息/标志位”数据（例如：下次启动是否进 recovery、升级/重试标志、reboot reason 等，具体由 BSP 实现） | 给 bootloader/系统传递“启动模式/升级模式/恢复模式”的控制开关；很多系统不大，但很关键 |
| boot | 64MB | boot.img | Linux Kernel（Image/zImage）、dtb（可能）、initramfs（可能）或 FIT 镜像 | 正常启动用的内核镜像分区：系统从这里把内核拉起来，然后再挂载 rootfs |
| recovery | 128MB | recovery.img | Recovery 内核 + ramdisk / 救援系统（实现方式依 BSP） | 用于“救援/升级/恢复出厂/刷机”路径；即使你不是 Android，也常用它做离线升级或维护模式 |
| backup | 32MB | backup.img（有的工程为空/不刷） | 备份/回滚相关数据（依 BSP）；有的 SDK 用来做升级过程的“临时备份区” | 给固件升级、回滚、异常恢复留后手；如果你的升级方案不用它，可能长期闲置 |
| rootfs | 14.0GB | rootfs.img/rootfs.ext4/*.wic（拆出来的 rootfs） | 你的 Linux 根文件系统（Buildroot/Yocto 生成的所有 /bin /lib /etc /usr…） | 这就是“系统本体”：用户态、服务、应用都在这里 |
| oem | 128MB | oem.img | OEM/厂商自定义内容：配置、资源、证书、预置应用、覆盖文件等 | 把“厂商定制”从 rootfs 拆出来，便于升级/恢复时分开处理（也常被挂载到/oem之类路径） |
| userdata | 14.7GB（grow） | userdata.img（也可不刷，现场格式化） | 可写数据分区：日志、应用数据、缓存、用户文件等 | 系统运行后的持久化数据区；“grow”表示可随剩余空间扩展 |
| （可选）security | 常见 4MB | 通常不刷具体镜像（它是数据区） | OP-TEE安全存储的数据落盘区：TA 持久化对象、密钥材料等加密后的 blob | 给 TA/TEE 放“敏感持久化数据”的地方；在parameter.txt里加0x00002000@0x000xxxxx(security)就是为了让系统出现这个分区 |
2. 从“启动链”角度理解：谁先被用、谁后被用？
很多人看分区表会陷入“每个分区里到底是什么文件格式”的细节里。更高效的理解方式是：把它们按启动链/维护链分组。
2.1 启动链分组
- 第一阶段（上电最早）：
uboot - 第二阶段（内核启动）：
boot（主路径） - 第三阶段（系统运行）：
rootfs+oem+userdata - 维护/救援路径：
recovery（以及misc触发进入） - 升级/回滚辅助：
backup（可选），misc（常用） - 安全数据落盘：
security（可选，OP-TEE Secure Storage 后端）
你会发现：
- 只要
uboot或boot坏了，系统通常直接起不来。 rootfs坏了，内核还能起，但会卡在挂载 rootfs 或 init 失败。userdata坏了，多数情况下系统还能起，但应用数据丢失。misc坏了，经常体现为：进不了 recovery、升级状态乱、重启原因读取异常。
2.2 典型启动过程（文字版时序）
ROM / loader（芯片内部）把执行权交给存储介质上的 bootloader
进入 uboot 分区：U-Boot 完成 DDR、时钟、存储、外设基础初始化
U-Boot 读取启动策略：
- 读取
misc看“是否进入 recovery/升级/特殊模式” - 默认走正常启动，加载
boot中的 kernel / dtb / initrd（如果有）
- 读取
内核启动，解析 cmdline
内核挂载
rootfs（ext4/其他）systemd/init 启动用户态服务
用户态服务按需求挂载
oem、userdata，启动应用
你可以把
misc理解成“启动路径的开关”，把backup/recovery理解成“救援/升级的备用路”，把security理解成“TEE 的小型保险箱落盘区”。
3. uboot 分区：为什么 4MB 却最关键？
3.1 uboot 分区里通常有什么
uboot.img并不是只有一个单纯的u-boot.bin。
在 Rockchip 的常见打包里，它是启动链组件的集合，可能包含：
- SPL / TPL（如果使用）
- U-Boot 正体（可带 dtb）
- ATF/BL31（EL3）
- TEE/BL32（OP-TEE OS）——在 RK3588 上常见会被一起打包进
uboot.img
你之前问过“trust.img 在哪”。对 RK3588 这种平台，工程里经常看不到单独
trust.img，因为 TEE/ATF 被整合到了uboot.img。
3.2 uboot 的核心职责
- 把硬件带起来：DDR、时钟、电源、存储控制器
- 选择启动路径：正常启动 / recovery / 升级 / 其它模式
- 装载并启动内核：读取
boot分区内容 - 安全相关入口（如果启用）：Secure Boot、TrustZone、OP-TEE 的启动对接
3.3 uboot 坏了会怎样
- 最常见：直接无法启动，停在 ROM/Maskrom，或无法加载下一阶段
- 安全链打开后：任何签名/校验不通过也可能导致停机或进入 recovery/升级模式
3.4 开发与量产建议
- 开发阶段：uboot 频繁调试，建议保留可靠的刷机入口（maskrom / recovery）
- 量产阶段：uboot 属于“不可随意更换”的关键件，通常需要配合签名校验
4. misc 分区：4MB 的“启动开关 + 状态机”
4.1 misc 里是什么
misc一般不放 Linux 文件系统，而是放一些结构化数据（BSP 定义）：
- 下次启动是否进入 recovery
- 升级/重试/回滚状态
- reboot reason（重启原因）
- 可能还有 OTA 状态、slot 信息（如果做 A/B）
它不是“装载某个大程序”，而是“写入几个字段”。所以 4MB 够用。
4.2 为什么不是 Android 也会需要 misc
因为“启动路径开关”这个需求并不只属于 Android：
- 你做离线升级（USB/SD 卡升级）也需要一个标志告诉 bootloader：下次进维护系统
- 你做 OTA 失败回滚，也需要一个状态告诉系统：这次启动属于回滚态
4.3 misc 出问题的表现
- 明明想进 recovery 却进不去
- 系统反复进 recovery（标志位没清掉）
- 升级状态机混乱：反复重试/回滚
5. boot 分区：内核从这里出发
5.1 boot.img 常见包含
不同项目打包不同，但本质上都围绕：
- Linux kernel（Image / zImage）
- dtb（可能内置，也可能单独）
- initramfs/initrd（可选）
- 或者 FIT 镜像把以上打成一个可校验的整体
5.2 boot 的职责
- 给 U-Boot 提供“可启动的内核镜像”
- 决定内核版本、基础驱动能力（尤其是存储、显示、网络等）
5.3 boot 坏了
- U-Boot 能跑，但会提示找不到内核或校验失败
- 即使进入内核，dtb 不匹配也会导致外设不可用、挂载失败
5.4 为什么 boot 64MB 看起来很大
- Kernel Image 本身可能 20~40MB
- initramfs 若包含升级工具/cryptsetup/网络工具，也会变大
- 留余量便于不同构建选项
6. recovery 分区：救援系统，不是“只给 Android 用”
6.1 recovery 里放什么
一套“可启动的内核 + ramdisk（最小根文件系统）”
里面通常包含：
- 分区刷写工具
- 升级脚本
- 基础网络/USB/存储支持
- 日志采集工具
6.2 recovery 的三种常见用途
- 离线升级：把 update 包放 U 盘/SD 卡，进入 recovery 执行刷写
- 救援维护：系统起不来时仍可进入 recovery 导出日志、修复文件系统
- 量产刷机入口：生产线可用 recovery 做统一刷写流程
6.3 recovery 与 misc 的关系
misc负责设置“下次进 recovery”- U-Boot 读取
misc决定是否跳转到recovery分区启动
7. backup 分区：升级/回滚的“备用仓”
7.1 backup 的定位
backup在不同 BSP 里差异很大：
- 有的工程用来做“升级前备份关键数据”
- 有的工程用来做“回滚点”
- 有的工程直接不用（空着或不刷）
7.2 什么时候你会真正需要 backup
- 你做 OTA，且希望失败后自动恢复关键分区
- 你做“升级原子性”（先写 backup，再切换）
7.3 不用 backup 会怎样
- 不影响系统正常运行
- 但升级策略需要靠其它机制保障（例如 A/B、分区校验、外部介质恢复等）
8. rootfs 分区：Linux 系统本体（14GB）
8.1 rootfs 里是什么
这就是你登录后看到的世界：
/sbin/init或 systemd/bin,/usr/bin：工具链、命令/lib,/usr/lib：动态库、驱动相关用户态库/etc：配置文件/var：日志、状态（有时会被单独挂载到 userdata）
对 Buildroot/Yocto 来说：rootfs 基本就是你构建产物的落地点。
8.2 rootfs 的核心功能
- 提供用户态、服务、应用
- 决定软件生态（weston/sato/你的业务 app）
8.3 rootfs 损坏的典型症状
- 内核启动成功，但卡在挂载 rootfs 或 init
- 文件系统损坏（ext4 error）导致只读或无法 mount
8.4 rootfs 与升级策略
- 最简单：整分区刷写 rootfs
- 更灵活：用包管理（opkg/rpm/deb）或增量更新
- 更可靠：A/B 双 rootfs（你现在这套表不是 A/B，但可扩展）
9. oem 分区：把“厂商定制”从系统本体拆出来
9.1 oem 里通常放什么
- 预置配置（网络、默认参数、出厂设置）
- 资源文件（logo、字体、音频、模型等也有人放这里）
- 证书/授权文件（注意：真正敏感的密钥不建议明文放这里）
- 应用 overlay（覆盖 rootfs 中某些文件）
9.2 oem 的价值
- rootfs 可作为“通用基础系统”稳定迭代
- oem 作为“定制层”更换频率低、也更便于客户差异化
- 升级时可选择只升级 rootfs，而保留 oem
9.3 oem 的挂载方式
常见：开机时挂载到/oem或作为 overlay 的下层
10. userdata 分区：业务数据与可写空间（grow）
10.1 userdata 放什么
- 应用数据（数据库、缓存、配置写入）
- 用户文件（下载、录制、图片、日志）
- 有些系统也会把
/var、/home放这里
10.2 grow 的意义
userdata:grow表示：分区会随剩余空间扩展。
好处：
- 同一套镜像刷到不同容量 eMMC 上，都能把剩余空间利用起来
- 量产方便
10.3 userdata 的典型策略
- 生产/首次开机：格式化 + 初始化目录结构
- OTA：尽量不动 userdata（保护用户数据）
11. security 分区：它不是镜像仓，是“TEE 安全存储的数据区”
11.1 最直接的回答：security 分区存什么？
它存的是：OP-TEE Secure Storage 的对象数据（加密后的 blob + 元数据）。
换句话说：
- 你不会刷一个
security.img把“程序”装进去 - 它更像一个“小型加密数据库分区”，由 TEE/TA 在运行中写入
典型存放内容：
- TA 的持久化对象（密钥材料、计数器、授权 token）
- 某些方案会把 TA 本体加密后“安装”到安全存储里（这样 TA 不再以明文留在 Linux 文件系统）
11.2 security 与 RPMB 的关系
OP-TEE 的安全存储后端通常有多种选择：
- RPMB：更强的防篡改能力，属于 eMMC 硬件特性
- security 分区：更通用，清理更方便（刷分区即可）
- Linux 文件系统：最弱，适合开发阶段
所以 security 分区属于“比普通文件系统强、比 RPMB 轻量/便利”的一种折中。
11.3 security 与 OTP/eFuse 的关系（你之前问过）
- security 分区存的是数据（密文对象）
- OTP/eFuse 更像根密钥来源（用于派生保护这些对象的密钥）
你可以理解为：
- OTP/eFuse：保险箱的“主钥匙材料”（硬件绑定）
- security：保险箱里的“抽屉”（放东西的地方）
11.4 security 分区坏了会怎样
取决于你用它存什么：
- 如果只存授权 token：可能表现为授权丢失、需要重新激活
- 如果存磁盘解密材料：可能导致系统无法解密启动（严重）
- 如果存 TA 安装包：可能导致 TA 无法运行
所以：量产方案里必须定义“重置策略”：
- 如何清空安全存储
- 如何重新 provisioning
12. 实战：每个分区该怎么刷？（开发 / 量产 / OTA 三种视角）
12.1 开发阶段（迭代快）
- 常刷：
boot、rootfs - 偶尔刷：
uboot（谨慎）、oem - 基本不刷：
userdata（除非你要清空测试数据） - security：开发阶段可以不建；要做 TEE demo 再建
建议：
- 保留可靠刷机入口（Maskrom / recovery）
- 不要频繁改分区布局，避免升级兼容性问题
12.2 量产阶段（稳定 + 可控）
uboot、boot、rootfs固化版本oem用于不同客户差异化userdata首次开机初始化security用于 provisioning（写入设备绑定的授权/密钥）
12.3 OTA 阶段（可恢复 + 少破坏）
- 最理想：只更新
rootfs或boot+rootfs - 尽量不动
userdata misc用于控制 OTA 状态机（升级中/回滚/恢复）backup若参与回滚，要明确策略
13. 一个“记忆用”的小结：一句话记住每块分区
- uboot：启动链的“总指挥”，最早、最关键。
- misc：启动模式/升级状态的“开关与记忆”。
- boot：内核从这里起跑。
- recovery：救援/离线升级的备用系统。
- backup：升级回滚的后手（可能不用）。
- rootfs：Linux 系统本体。
- oem：厂商定制层。
- userdata：可写业务数据区。
- security：TEE 安全存储的落盘数据区（不是镜像仓）。
14. 关键问答（帮助你把概念钉死）
Q1：trust.img是不是放在boot.img里？
不是。对 RK3588 常见做法是：TEE/ATF 等被打包进uboot.img。
Q2：security分区是不是放trust.img？
不是。security用于存放 OP-TEE Secure Storage 对象（加密数据）。
Q3：不是 Android 也需要misc/recovery吗？
很多项目仍然需要。它们解决的是“维护/升级/救援”的通用需求。
Q4：userdata:grow的真实作用是什么？
同一套镜像适配不同容量存储介质，把剩余空间自动给 userdata 使用。
—2
15. 你下一步做“模型保护 demo”时，分区层面怎么选？（给你一个落地建议）
如果你要做“模型加密/签名 demo”，推荐这样放置：
- 模型密文：放
oem或rootfs（随镜像出厂的模型），或者userdata（动态下载/更新的模型） - 模型密钥/授权 token：放
security（或 RPMB）
这样你能清晰演示：
- 模型文件拷走没用（只有密文）
- 没有设备绑定密钥无法解密
结尾提示：你如果把
parameter.txt的完整布局（含你准备加的 security offset）贴出来，我可以把它改成一份“不会重叠、对齐合理、便于 OTA”的版本，并给出对齐/起始地址计算方法（按 sector 对齐）。
📺B站：博主个人介绍
📘博主书籍-京东购买链接*：Yocto项目实战教程
📘加博主微信，进技术交流群：jerrydev
