它同时包含eMMC用户数据区 ├── GPT分区15 │ eMMC专用硬件区 ├── boot0 ├── boot1 └── RPMB另外板子还有 SD 卡接口、SPI NOR Flash 和 DDR。它们不是同一类存储。一、先看整块板子的存储关系STM32MP135 │ ├── DDR │ └── 运行内核、程序、缓存 │ 断电后内容消失 │ ├── eMMCmmc1约7.28GiB │ ├── boot04MiB硬件启动区 │ ├── boot14MiB硬件启动区 │ ├── RPMB4MiB安全区 │ └── 用户数据区 │ ├── p1 metadata1 │ ├── p2 metadata2 │ ├── p3 fip-a │ ├── p4 boot │ └── p5 rootfs │ ├── SD卡mmc0 │ └── SPI NORW25Q12816MiB你板子的启动日志已经识别到mmcblk1 eMMC用户数据区 mmcblk1p1p5 GPT逻辑分区 mmcblk1boot0 eMMC硬件启动区0 mmcblk1boot1 eMMC硬件启动区1 mmcblk1rpmb eMMC安全RPMB区其中/dev/mmcblk1p1和/dev/mmcblk1boot0不是一回事mmcblk1p1 用户区里的第1个GPT分区 mmcblk1boot0 eMMC芯片独立的硬件启动区这是初学时最容易混淆的地方。你的启动日志显示 eMMC 用户区约为 7.28GiB并且存在 boot0、boot1 和 RPMB 硬件区。二、你板子的实际GPT分区表你之前在 U-Boot 中执行part list mmc 1得到的实际布局是分区名称约大小主要作用mmcblk1p1metadata1512KiB固件更新元数据主副本之一mmcblk1p2metadata2512KiB固件更新元数据冗余副本mmcblk1p3fip-a8.5MiBU-Boot、OP-TEE等启动固件包mmcblk1p4boot64MiBLinux内核、设备树、initrd、模块mmcblk1p5rootfs约7.21GiBLinux根文件系统及应用程序这是根据你板子的实际 LBA 范围计算的U-Boot 输出也明确显示当前 eMMC 是mmc 1并列出了这5个GPT分区。三、eMMC boot0 和 boot1最早启动的TF-A这两个不是GPT分区而是eMMC芯片内部专门的硬件启动区/dev/mmcblk1boot0 /dev/mmcblk1boot1在ST默认的eMMC启动方案中这两个区域通常分别保存一份 TF-A BL2也就是第一阶段引导程序的两个冗余副本。芯片BootROM上电后会从eMMC启动区读取TF-A。ST官方资料明确说明eMMC的TF-A会复制到两个隐藏的boot area中以实现冗余。启动的最前面几步是芯片内部BootROM ↓ eMMC boot0或boot1中的TF-A BL2 ↓ 读取metadata1/metadata2 ↓ 加载fip-a这两个区域非常重要。不要随便执行类似dd ifxxx of/dev/mmcblk1boot0 dd ifxxx of/dev/mmcblk1boot1写错后开发板可能连U-Boot都进不去只能通过STM32CubeProgrammer重新烧写。四、分区1metadata1设备节点/dev/mmcblk1p1名称metadata1大小约512KiB它保存的是TF-A固件更新元数据用来记录当前应该使用哪个FIP槽位FIP镜像是否有效固件升级状态固件版本或bank状态。它不是ext4文件系统不能使用mount /dev/mmcblk1p1 ...也不能用ext4ls mmc 1:1 /把它当普通目录查看。ST的固件更新设计会使用metadata来选择FIP-A或FIP-Bmetadata1是其中一个副本。五、分区2metadata2设备节点/dev/mmcblk1p2名称metadata2大小也是约512KiB它与metadata1保存相同类型的信息主要用于冗余。为什么有两份更新metadata1 ↓ 如果写入时突然断电 ↓ 还可以使用metadata2恢复或判断有效状态ST官方说明两份metadata用于提高FIP更新过程中的掉电安全性。你当前板子只有fip-a没有列出fip-b因此metadata当前通常选择的就是FIP-A。不要手工修改这两个分区。六、分区3fip-a设备节点/dev/mmcblk1p3名称fip-a你板上实际分配约8.5MiBFIP全称是Firmware Image Package 固件镜像包它不是Linux内核也不是普通文件系统。FIP中通常封装U-Boot二进制U-Boot使用的设备树OP-TEETF-A加载需要的固件配置可选的签名或认证信息。严格来说TF-A BL2本体 通常位于eMMC boot0/boot1 fip-a 包含TF-A后续要加载的U-Boot、OP-TEE等组件不要把fip-a简单理解成“Linux boot分区”。ST官方对OpenSTLinux FIP内容的说明中包括U-Boot、U-Boot DTB、OP-TEE和固件配置。当这个分区损坏时可能出现TF-A能够运行 但是无法加载U-Boot 最终停在Linux内核启动之前更新U-Boot时通常更新的是FIP镜像而不是Linux的uImage。七、分区4boot分区设备节点/dev/mmcblk1p4分区名称boot实际分区大小64MiB因为ext4文件系统本身有元数据开销所以你在Linux中执行df -h /lib/modules看到的可用总容量约58MiB而不是完整64MiB这是正常的。1. 它在Linux中的挂载位置你当前系统把该分区挂载到/lib/modules对应关系是/dev/mmcblk1p4 ↓ mount /lib/modules你执行的结果已经证明/dev/mmcblk1p4 on /lib/modules type ext4这个布局比较特殊。很多普通Linux系统会把boot分区挂载到/boot模块放在根文件系统的/lib/modules但正点原子这套镜像直接把第4分区挂载到了/lib/modules。因此Linux中 /lib/modules/uImage U-Boot中 mmc 1:4 /uImage指向的是同一个eMMC文件。2. 里面存放的内容你板子的boot分区中实际包含uImage uImage.test uInitrd stm32mp135d-atk.dtb stm32mp135d-atk-hdmi.dtb stm32mp135d-atk-wifi-bluetooth.dtb boot.scr.uimg mmc0_extlinux/ mmc1_extlinux/ 5.15.24/ alientek_1024x600.bmp alientek_1280x800.bmp alientek_480x272.bmp alientek_800x480.bmp你的U-Boot日志已经列出了这些文件。3. 每种文件有什么作用uImageLinux内核镜像U-Boot把它加载到DDR中再使用bootm启动。uImage.test这是你自己放进去的测试内核。它和旧内核不冲突因为默认启动配置仍然加载/uImage只有你手动执行ext4load mmc 1:4 ${kernel_addr_r} /uImage.test才会加载测试内核。*.dtb设备树文件用来描述板子的硬件CPU和内存GPIOI2C和SPICAN两个以太网口串口显示屏时钟和中断。设备树不是驱动代码而是告诉驱动“硬件在哪里、如何连接”。uInitrd启动早期使用的临时根文件系统。U-Boot会把它加载到DDRLinux启动初期先解包或使用其中的/init随后再挂载正式的/dev/mmcblk1p5mmc1_extlinux保存eMMC启动配置。你板上的配置实际指定KERNEL /uImage INITRD /uInitrd FDT /stm32mp135d-atk.dtb APPEND root/dev/mmcblk1p5 rootwait rw consolettySTM0,115200也就是说内核来自p4 设备树来自p4 uInitrd来自p4 正式根文件系统来自p55.15.24/这里通常存放与当前内核版本匹配的.ko模块例如/lib/modules/5.15.24/kernel/...内核模块必须和运行中的内核版本、配置及符号基本匹配否则可能出现invalid module format version magic mismatch Unknown symbolboot.scr.uimgU-Boot启动脚本镜像可能包含加载内核、设备树、Logo等命令。*.bmpU-Boot或出厂系统启动期间显示的Logo图片。八、分区5rootfs根文件系统设备节点/dev/mmcblk1p5分区名称rootfs大小约7.21GiB它在Linux中挂载为/也就是整个Linux系统的根目录。你的启动参数中明确写着root/dev/mmcblk1p5启动日志也显示mmcblk1p5被挂载为ext4根文件系统。rootfs中主要存放什么/ ├── bin/ 基础命令 ├── sbin/ 系统管理命令 ├── etc/ 系统配置 ├── usr/ 应用、库、资源 ├── lib/ 动态库 ├── home/ 用户数据 ├── root/ root用户目录 ├── var/ 日志和运行数据 ├── opt/ 自定义应用 ├── dev/ 设备节点 ├── proc/ 内核进程信息虚拟文件系统 ├── sys/ 内核设备模型虚拟文件系统 ├── tmp/ 临时文件 └── run/ 运行时数据你自己开发的普通程序例如CAN通信程序 I2C读取程序 串口程序 Qt应用 后台服务 Shell脚本通常放在rootfs例如/opt/app /usr/local/bin /home/root更新普通应用时不需要更新uImage只需要把程序复制到p5的文件系统中。九、为什么/lib/modules看起来属于rootfs却实际是p4Linux刚挂载p5为/后根文件系统本身会有一个目录/lib/modules随后启动脚本又执行把/dev/mmcblk1p4挂载到/lib/modules挂载后p5中原来的/lib/modules内容会暂时被遮住当前看到的是p4中的内容rootfs p5 └── /lib/modules ← 挂载点 boot p4 └── 内容显示在 /lib/modules所以你执行cp /tmp/uImage.test /lib/modules/uImage.test实际是写入p4而不是写入p5。卸载p4后umount /lib/modules理论上才会看到p5目录本身原有的内容。但系统运行期间不要随意卸载它因为驱动模块和启动文件都依赖该分区。十、RPMB分区是什么设备节点/dev/mmcblk1rpmbRPMB全称Replay Protected Memory Block 防重放保护存储区特点需要认证密钥带写计数器防止旧数据被重放常用于安全存储、可信系统、密钥或计数数据普通cp、mount、dd不能像一般分区那样使用。在带OP-TEE的系统中RPMB可能被用于安全存储。不要格式化、分区或随便向它写数据。十一、SPI NOR W25Q128是什么启动日志还识别到了w25q128 16384 Kbytes它是16MiB的SPI NOR Flash。它与eMMC不是同一个设备常用于存放备用固件调试启动固定配置SPI Flash驱动实验。具体是否承担启动任务取决于开发板拨码和烧写布局。当前你是从eMMC启动所以主要操作对象仍然是mmc 1 /dev/mmcblk1十二、完整启动时各分区怎么配合这块板子的典型启动过程可以理解为1. 芯片上电 ↓ 2. BootROM运行 ↓ 3. 从eMMC boot0/boot1读取TF-A BL2 ↓ 4. TF-A读取metadata1/metadata2 ↓ 5. 根据metadata选择fip-a ↓ 6. 从fip-a加载U-Boot、OP-TEE等 ↓ 7. U-Boot读取eMMC第4分区boot ├── uImage ├── uInitrd └── DTB ↓ 8. 加载到DDR ├── 内核0xc2000000附近 ├── DTB0xc4000000附近 └── ramdisk0xc4400000附近 ↓ 9. U-Boot执行bootm ↓ 10. Linux内核运行 ↓ 11. Linux挂载/dev/mmcblk1p5为/ ↓ 12. Linux挂载/dev/mmcblk1p4到/lib/modules ↓ 13. 启动Shell、Qt、网络和用户程序U-Boot的主要作用就是初始化必要硬件、把Linux内核从eMMC等存储复制到DDR并启动内核。十三、修改什么内容对应更新哪个分区修改内容更新位置普通C应用、Qt程序、脚本p5rootfs系统配置、启动服务p5rootfsLinux内核p4boot中的uImage设备树p4中的.dtbinitramfsp4中的uInitrd外部驱动模块.kop4中的版本目录如5.15.24/U-Boot、OP-TEEp3fip-aTF-A BL2eMMCboot0/boot1硬件区FIP升级选择信息p1/p2 metadata整个Linux系统p4 boot p5 rootfs必要时还包括启动固件十四、不同分区损坏后的表现boot0/boot1损坏芯片无法进入TF-A 可能连U-Boot日志都没有恢复难度最高。metadata损坏TF-A可能无法确定使用哪个FIP 启动固件升级流程异常fip-a损坏TF-A可能能启动 但无法进入U-Bootboot分区损坏可以进入U-Boot 但找不到uImage、DTB或uInitrd Linux无法启动rootfs损坏内核可以启动 但挂载根文件系统失败 可能出现 VFS: Unable to mount root fs No working init found Kernel panic普通应用损坏Linux可以启动 只是对应业务程序无法运行十五、查看分区的常用命令在U-Boot中确认设备mmc list查看eMMC分区表part list mmc 1查看boot分区ext4ls mmc 1:4 /查看rootfs分区ext4ls mmc 1:5 /查看boot分区某个目录ext4ls mmc 1:4 /5.15.24/在开发板Linux中查看块设备cat /proc/partitions查看挂载关系mount | grep mmc查看容量df -h查看当前根分区cat /proc/cmdline查看eMMC设备节点ls -l /dev/mmcblk1*查看boot分区内容ls -lh /lib/modules十六、你当前最应该记住的对应关系U-Boot中的 mmc 1 Linux中的 /dev/mmcblk1 板载eMMCU-Boot中的 mmc 1:4 Linux中的 /dev/mmcblk1p4 挂载点 /lib/modules 存放 uImage、DTB、uInitrd、模块U-Boot中的 mmc 1:5 Linux中的 /dev/mmcblk1p5 挂载点 / Linux根文件系统和应用程序eMMC boot0/boot1 ≠ mmcblk1p1/mmcblk1p2你当前更新内核采用保留 /uImage 新增 /uImage.test U-Boot手动加载 /uImage.test是合理且安全的因为它只操作第4分区中的一个新增文件不涉及TF-A、metadata、FIP和rootfs。