全部BL1、BL2、BL31、BL32(OP-TEE)、BL33(U‑Boot)都存于同一片板载 128MB SPI NAND Flash但分两层独立分区存放不是平铺在同一地址BL1独立存miniboot主分区A/B 双备份槽BL2、BL31、BL32(OP‑TEE)、BL33(U‑Boot)打包在同一个FIP 固件镜像里同样放在miniboot分区内部、BL1 之后的固定偏移位置额外独立分区ubootenv单独存放 U‑Boot 环境变量不属于 FIP/BL 体系。一、SPI NAND 整体 MTD 分区RDK X5 固定布局plaintext0x00000000 ~ 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两套完整 BL1FIP升级固件时写入备用槽启动失败自动切回旧固件防砖。2. FIP 固件包紧跟 BL1 之后单一容器整合 4 个固件FIP Firmware Image PackageARM TF-A 标准打包容器一个 fip.bin 内部按偏移顺序封装BL2二级引导、DDR 初始化BL31EL3 安全监控BL32 OP‑TEE安全操作系统 TEEBL33 U‑Boot主引导关键细节编译阶段用fiptool将 BL2/BL31/BL32/BL33 合并为单一 fip.binBL1 运行后才会从 SPI NAND 读取整个 FIP 包、按内部索引拆分、逐个验签加载到内存物理上这四段固件连续打包在一起共享同一大块 Flash 偏移只是 FIP 内部有头部索引区分各自起始地址。三、启动读取逻辑对应你串口日志上电 → 芯片内置 BOOTROM不在 SPI NAND→ 读取 SPI NAND miniboot 分区头部 BL1BL1 初始化 SPI NAND、校验自身签名读取同分区内的 FIP 镜像BL1 解析 FIP 头部依次读出 BL2、BL31、OP‑TEE、U‑BootBL2 初始化 DDR 内存后把 BL31/OP‑TEE/U‑Boot 加载进 DDR 执行。四、通俗类比理解整片 SPI NAND 一个硬盘miniboot 分区 系统盘主分区BL1 分区最开头的独立引导程序fip.bin 一个压缩包里面同时装了 BL2、BL31、OP‑TEE、U‑Boot 四个程序ubootenv 分区 单独的配置文件盘只存启动参数和 FIP 无关五、容易混淆的边界区分片内 BOOTROM ≠ SPI NANDBOOTROM 烧在旭日 5 芯片内部出厂固化不属于 FlashBL1 才是 SPI NAND 里第一个固件。BL2/BL31/OPTEE/U-Boot不是 4 个独立 Flash 分区它们只是 FIP 包内的分段镜像物理存储连续、同属 miniboot 分区内一块连续空间。SD 卡不含任何 BL 系列固件烧 SD 镜像只会更新 Linux 内核、dtb、Ubuntu 系统不会触碰 SPI NAND 里 BL1/FIP升级底层固件必须单独刷 miniboot 镜像。ubootenv是独立分区只存启动环境变量不属于 FIP 包内容你日志里bad CRC就是这个分区校验出错。六、精简总结载体全部 BL1~BL33 都在同一片 SPI NAND Flash分区归属全部固件都在miniboot主 MTD 分区内部排布BL1分区起始独立存放BL2 BL31 BL32 (OP‑TEE) BL33 (U‑Boot)打包在同一个 FIP 镜像、BL1 后方连续存储独立附加分区ubootenv单独存放 U‑Boot 启动参数与 FIP 分离。