全部 BL1、BL2、BL31、BL32(OP-TEE)、BL33(U‑Boot) 都存于同一片板载 128MB SPI NAND Flash，但分两层独立分区存放，不是平铺在同一地址：

1. BL1：独立存 miniboot 主分区（A/B 双备份槽）；
2. BL2、BL31、BL32(OP‑TEE)、BL33(U‑Boot)：打包在同一个 FIP 固件镜像里，同样放在 miniboot 分区内部、BL1 之后的固定偏移位置；
3. 额外独立分区 ubootenv 单独存放 U‑Boot 环境变量，不属于 FIP/BL 体系。

一、SPI NAND 整体 MTD 分区（RDK X5 固定布局）

plaintext

0x00000000 ~ 0x00700000  → mtd0: miniboot 分区（7MB）
0x00700000 ~ 0x00880000  → mtd1: ubootenv 环境变量分区（1.5MB）

所有底层启动固件全部在 miniboot 分区内，SD 卡完全不包含这些固件。

二、miniboot 分区内部两层存储结构

1. BL1 独立段（分区最起始位置）

• 二进制文件：bl1.bin
• 作用：上电由芯片片内 BOOTROM读出、加载到片内 SRAM 运行；
• 位置：miniboot 分区最开头，独立一段，不在 FIP 包内；
• A/B 双备份：miniboot 分区内存在 slot0、slot1 两套完整 BL1+FIP，升级固件时写入备用槽，启动失败自动切回旧固件防砖。

2. FIP 固件包（紧跟 BL1 之后，单一容器整合 4 个固件）

FIP = Firmware Image Package，ARM TF-A 标准打包容器，一个 fip.bin 内部按偏移顺序封装：

1. BL2（二级引导、DDR 初始化）
2. BL31（EL3 安全监控）
3. BL32 OP‑TEE（安全操作系统 TEE）
4. BL33 U‑Boot（主引导）

关键细节

• 编译阶段用 fiptool 将 BL2/BL31/BL32/BL33 合并为单一 fip.bin；
• BL1 运行后，才会从 SPI NAND 读取整个 FIP 包、按内部索引拆分、逐个验签加载到内存；
• 物理上这四段固件连续打包在一起，共享同一大块 Flash 偏移，只是 FIP 内部有头部索引区分各自起始地址。

三、启动读取逻辑（对应你串口日志）

1. 上电 → 芯片内置 BOOTROM（不在 SPI NAND）→ 读取 SPI NAND miniboot 分区头部 BL1；
2. BL1 初始化 SPI NAND、校验自身签名，读取同分区内的 FIP 镜像；
3. BL1 解析 FIP 头部，依次读出 BL2、BL31、OP‑TEE、U‑Boot；
4. BL2 初始化 DDR 内存后，把 BL31/OP‑TEE/U‑Boot 加载进 DDR 执行。

四、通俗类比理解

整片 SPI NAND = 一个硬盘

• miniboot 分区 = 系统盘主分区
  • BL1 = 分区最开头的独立引导程序
  • fip.bin = 一个压缩包，里面同时装了 BL2、BL31、OP‑TEE、U‑Boot 四个程序
• ubootenv 分区 = 单独的配置文件盘，只存启动参数，和 FIP 无关

五、容易混淆的边界区分

1. 片内 BOOTROM ≠ SPI NAND BOOTROM 烧在旭日 5 芯片内部，出厂固化，不属于 Flash；BL1 才是 SPI NAND 里第一个固件。
2. BL2/BL31/OPTEE/U-Boot 不是 4 个独立 Flash 分区 它们只是 FIP 包内的分段镜像，物理存储连续、同属 miniboot 分区内一块连续空间。
3. SD 卡不含任何 BL 系列固件 烧 SD 镜像只会更新 Linux 内核、dtb、Ubuntu 系统，不会触碰 SPI NAND 里 BL1/FIP；升级底层固件必须单独刷 miniboot 镜像。
4. ubootenv 是独立分区，只存启动环境变量，不属于 FIP 包内容，你日志里 bad CRC 就是这个分区校验出错。

六、精简总结

1. 载体：全部 BL1~BL33 都在同一片 SPI NAND Flash；
2. 分区归属：全部固件都在 miniboot 主 MTD 分区；
3. 内部排布：
   • BL1：分区起始独立存放；
   • BL2 + BL31 + BL32 (OP‑TEE) + BL33 (U‑Boot)：打包在同一个 FIP 镜像、BL1 后方连续存储；
4. 独立附加分区：ubootenv 单独存放 U‑Boot 启动参数，与 FIP 分离。