做ZYNQ MPSoC的板卡，SD卡启动盘制作是绕不开的第一道门槛。很多人从单芯片ARM或者ZYNQ-7000那边转过来，习惯性地把生成的BOOT.BIN往SD卡里一拖，拨码一拨，却发现板上串口没有任何反应，或者U-Boot起来了但内核起不来。问题往往不是工程编译搞错了，而是对MPSoC的SD启动链路理解得不够细。这篇文章我想把ZYNQ MPSoC SD卡启动盘的完整制作过程、背后的启动原理、以及我实际踩过的坑重新捋一遍，从分区格式化到文件摆放，从拨码设置到串口验证，再到常见的排查方法，尽量让零基础的人也能按步骤做出一张能稳定启动的SD卡，也让已经有经验的人能查到一些平时容易忽略的细节。
我把这套流程当作一个“可以照着抄的作业”来写。适合的人群包括：第一次在ZYNQ MPSoC上跑Linux的嵌入式软件工程师、FPGA工程师，以及需要维护多块板卡启动环境、经常重刷SD卡的项目维护人员。下面内容里的所有操作都基于Linux主机的常见发行版环境，Windows下的替代工具我也会一并提一下。
1. MPSoC的SD启动链路，为什么不能拿ZYNQ-7000的习惯去套
1.1 BootROM到U-Boot：一次启动先后经过哪几个“接力棒”
先理清楚一个问题：MPSoC的SD启动，实际上是从芯片内部的BootROM开始的。BootROM是一段固化在芯片里的程序，上电后它先读取BOOT MODE引脚的电平状态，判断这次从哪个设备启动，比如SD卡、QSPI、eMMC、JTAG。BootROM本身并不复杂，它做的事情就是把选中的启动设备里最前面的那段固件读进片内RAM，然后跳转过去执行。
在ZYNQ-7000那一代，这个接力相对简单：BootROM读到的是FSBL，FSBL负责初始化DDR和PS侧时钟，然后加载U-Boot，U-Boot再加载内核。整个过程就是一个“三级接力棒”。到了ZYNQ UltraScale+ MPSoC这一代，情况变复杂了。PS侧不仅有Cortex-A53和Cortex-R5，还多了一个PMU（Platform Management Unit），用来负责电源管理、错误管理这些事务。整个启动链路变成了类似：BootROM -> PMUFW + FSBL -> ATF（Arm Trusted Firmware）-> U-Boot -> 内核。
为什么说这个链路变化直接影响了SD卡制作？因为FSBL不再像以前那样只管DDR初始化和搬运镜像，它还要配合PMUFW做电源域管理，ATF则负责安全启动和运行时服务。所以BOOT.BIN里面装的不是“一个U-Boot”，而是好几个二进制文件的打包体，少一个或者版本不匹配，启动就会卡在某个看不见的地方。这也是“照搬ZYNQ-7000经验”最容易翻车的原因。
1.2 启动模式引脚与SD启动的位置
每块MPSoC板卡上，BOOT MODE引脚都对应一套拨码开关或者电阻配置。SD启动在绝大多数板卡上是BOOT MODE=“SD”。具体拨到哪一组，不同板卡定义不一样，必须查对应板卡的硬件手册，不能想当然。我曾经见过有人把QSPI启动的配置当SD启动，结果每次上电都跑回板上已有的旧系统，折腾了大半天才发现是拨码拨错位。
还有一个容易忽略的细节：SD启动位置通常在“SD0”或者“SD1”，对应PS侧的SDIO控制器。有些板卡用SD0，有些用SD1，U-Boot里的设备树和启动命令必须和它一致。制作SD卡前，建议先确认板卡的原理图，搞清楚SD卡插槽挂在哪个SDIO控制器上。否则就算卡里的文件全对了，U-Boot初始化mmc时也会出现找不到设备的错。
1.3 容易混淆的“两代ZYNQ”：PS侧架构变了，文件分工也变了
这里多说几句两代ZYNQ的区别，因为它直接决定了你的编译输出物该怎么拿。
第一代ZYNQ-7000的启动文件通常就是boot.bin（FSBL+U-Boot）、uImage或uImage+dtb；而MPSoC的启动文件至少包括BOOT.BIN和image.ub这两类。BOOT.BIN由多个分区组成，常见顺序是FSBL、PMUFW、ATF、U-Boot；image.ub则是用FIT（Flattened Image Tree）格式打包的内核、设备树、ramdisk。后者看起来像单个文件，实际是“多合一”。PetaLinux工具链在打包阶段会帮你自动完成这些，但如果手动做BOOT.BIN和image.ub，不理解这层结构就很容易把文件类型搞混。
两代ZYNQ在U-Boot阶段加载文件的方式也略有不同。ZYNQ-7000经常是U-Boot直接读uImage然后启动；MPSoC上PetaLinux默认生成的U-Boot环境变量是读出image.ub后，使用bootm命令配合FIT内部的配置来启动。所以有些人在ZYNQ-7000上习惯把kernel和dtb分开拷入SD卡，到MPSoC上仍然沿用这个习惯，结果U-Boot找不到对应的FIT配置，自然起不来系统。
2. 启动盘上的三个核心文件，分别解决什么问题
2.1 BOOT.BIN：不是“一个bootloader”，而是多个镜像的打包容器
BOOT.BIN是SD卡上最重要的文件。它并不是某一个程序编译出来的单文件，而是通过Bootgen工具把FSBL、PMUFW、ATF、U-Boot按顺序打包成的容器格式。BootROM启动后加载的其实只是这个容器的最前面一部分，然后由FSBL根据容器头部描述信息逐个把其余组件搬到DDR，再跳转执行。
这张“容器”里的组件各有分工：FSBL做最基本的硬件初始化，特别是DDR的配置，它依赖你原来工程里的XSA文件，也就是说换了DDR颗粒或者改了MIO分配，FSBL是需要重新生成的；PMUFW负责电源域、复位、错误管理，没有它，ATF和U-Boot阶段虽然不一定会立刻崩，但很多电源相关的操作会异常；ATF作为安全世界和非安全世界之间的桥梁，负责把运行模式切换到EL2；U-Boot则是最终把内核加载起来的引导程序。
我对BOOT.BIN的一个深刻感受是：它的“顺序”和“版本”特别敏感。FSBL、PMUFW、ATF、U-Boot最好来自同一套PetaLinux或同一时期Vitis导出的版本，否则容易出现启动到某个阶段直接“卡死”或者重启的现象。有些编译环境下Bootgen会对每个组件做校验，但版本之间的接口兼容性问题它是查不出来的。
2.2 image.ub：内核、设备树、根文件系统的“三合一”
image.ub这个文件有两种来源：一是PetaLinux执行打包命令后生成，二是用mkimage工具手工把kernel、dtb、ramdisk做成FIT镜像。它内部包含若干个“配置”，每个配置指定了使用哪个内核、哪个设备树、哪个ramdisk。U-Boot的bootm命令可以直接按配置名来选择启动项，这使得同一份image.ub可以适配多块硬件平台，只要你在打包时把多个设备树都放进去。
在SD启动盘里，image.ub的位置一般放在第一分区。U-Boot不关心它内部具体结构，只负责把它读进内存，然后按照FIT头里的默认配置启动。如果你改了设备树或者换了内核，不需要重新做卡，只需要用新文件覆盖SD卡里的image.ub即可。
有个常见的坑是：image.ub里打包的ramdisk可以是传统initrd，也可以是可选的rootfs。默认PetaLinux会把根文件系统放到单独的分区而不打进ramdisk，但只要配置了ramdisk，它就可能成为最终的根文件系统。判断一下你手上的image.ub里到底有没有ramdisk，可以用mkimage -l命令查看，否则后面排查“根文件系统挂载不上”时会多绕弯路。
2.3 boot.scr与uEnv.txt：让U-Boot知道下一步该干什么
BOOT.BIN和image.ub都准备好后，U-Boot还需要知道“去哪找image.ub、用什么样的启动参数”。这部分就是由U-Boot的环境变量和启动脚本控制的。
一种方式是U-Boot内建默认环境变量，PetaLinux生成的U-Boot一般会在默认环境里写好从MMC加载image.ub的命令；另一种更常用的是放一个boot.scr文件，它由boot.cmd源文件通过mkimage编译生成，本质是一段可执行的U-Boot命令脚本；还有一种uEnv.txt，里面以key=value的形式设置环境变量。如果板卡去读uEnv.txt，文件名必须绝对正确，大小写也不能错。
实际调板时，我一般会先用串口进入U-Boot命令行，手动执行几条命令验证文件能否正常加载，再回头修改boot.cmd重新生成boot.scr。不建议一上来就把boot.scr写得很复杂，因为一旦脚本里哪行写错，U-Boot可能反复尝试启动，刷日志刷得根本顾不上看报错。
3. 制作SD卡前的环境准备：分区方案与格式化工具的选择
3.1 为什么不能整卡格式化后直接拷文件
这个坑我见得太多了。很多第一次接触MPSoC的人觉得SD卡空就能用，直接格式化FAT32，然后把BOOT.BIN和image.ub放进去，插上板卡上电，U-Boot能跑，但最后内核完全起不来。原因在于：Linux根文件系统也需要放在SD卡上，而根文件系统通常要求放在ext4这样的文件系统里。如果整张卡只有FAT32，虽然U-Boot可以读FAT32，但内核挂载根文件系统时，对FAT32的支持往往没编进内核，或者根本就没法承载Linux的权限、软链接等特性。
再者，BootROM对SD卡读取其实很“挑剔”。它不一定支持复杂的GPT分区表，也不一定能识别可移动设备的第几个分区。业界普遍推荐的方案是MBR分区表+固定的分区顺序：第一分区放启动文件，第二分区放根文件系统。这能确保BootROM和U-Boot在启动早期用很简单的代码路径找到文件。
3.2 分区方案：FAT32 + EXT4还是单FAT32
我用的标准方案是两张表：
第一分区：格式FAT32，大小256MB到512MB。只放BOOT.BIN、image.ub、boot.scr这类引导文件。为什么不能小于256MB？其实128MB也够用，但考虑到调试过程中可能要在卡上放多个版本镜像来对比，备足一点会省去反复格式化分区的麻烦。
第二分区：格式EXT4，大小占剩余空间。内核启动后，通过root=/dev/mmcblk0p2来指定根文件系统在这里。注意设备节点名里的“p2”就代表第二分区，如果你把根文件系统放到了第三个分区，U-Boot传给内核的cmdline必须改成p3，否则内核会因为没有可挂载的rootfs而panic。
也有工程用单FAT32分区的，但那通常配合ramdisk把rootfs打包进image.ub，这时SD卡只作为启动介质，不承担真正的可写文件系统。对生产环境来说，FIT里带大ramdisk会浪费内存，不太划算。所以一般调试和学习用，双分区方案最稳定。
3.3 工具集：Linux下的fdisk/mkfs，Windows下的替代品
制作SD卡在Linux下用fdisk或parted分区，配合mkfs.vfat和mkfs.ext4格式化，使用dd做整卡备份或者裸镜像写卡。步骤清晰，整个过程可脚本化。
Windows下也有方便的方案：用SD Card Formatter类工具做整卡格式化，DiskGenius做分区调整，然后直接把启动文件拷进FAT32分区。如果拿到的是别人给的.img整卡镜像，用balenaEtcher或Win32DiskImager类似工具写SD卡。不过这类工具一般是“整卡镜像写入”，制作多分区卡时没有那么直观。
我不建议在Windows下直接把一个SD卡的img镜像通过Rufus写进另一张卡，除非你明确知道源卡分区表和目标卡容量完全兼容。很多“写完之后电脑只识别一个小分区”的怪现象，就是镜像大小和目标卡容量不匹配导致的。
3.4 不同容量、不同用途的SD卡参数参考
| 用途 | 建议容量 | 分区方案 | 说明 |
|---|---|---|---|
| 学习调试、跑最小Linux | 8GB~16GB | FAT32 512MB + EXT4剩余 | 够用，重刷成本低 |
| 需要存储运行日志或数据 | 32GB~64GB | FAT32 1GB + EXT4剩余 | 注意UHS-I速度等级 |
| 量产固化、批量烧录 | 8GB~32GB | FAT32 256MB + EXT4剩余 | 建议使用工业级卡 |
| 快速验证启动链路 | 任意闲置卡 | 单FAT32 + ramdisk | 不适合做持久化存储 |
必须提醒一句：MPSoC启动早期对SD卡识别能力弱于PC的读卡器。有些高速大容量卡在PC上读写一切正常，插到板卡上就是读不到或者启动到一半掉线。选卡时可以优先挑Class 10、普通UHS-I的卡，那些标榜极致速度的卡往往对嵌入式启动兼容性反而一般。
4. 实操记录：从空白SD卡到可启动盘的完整制作过程
4.1 第一步：确认设备节点，避免把硬盘格式化
把SD卡插到Linux主机前，先在终端里执行lsblk，记录下当前所有块设备。插入SD卡后再执行一次lsblk，多出来的那个就是SD卡对应的设备节点，一般叫/dev/sdb或者/dev/mmcblk0。这一步绝不能省，因为我见过有人在多块硬盘的机器上没确认设备名，直接把/dev/sda当SD卡写了进去，系统盘没了。
如果机器上已自动挂载了SD卡分区，先umount掉。否则后面fdisk对分区表的修改会失败，或者产生“设备忙”的提示。确认设备节点后，后面的所有操作都针对这个节点，我建议用变量记住它，比如DEV=/dev/sdb，避免在后面命令里手误写错。
4.2 第二步：fdisk分区与格式化
假设SD卡设备是/dev/sdb，整个过程这样走：
sudo fdisk /dev/sdb在fdisk交互界面里依次做这几件事：
- 输入
p查看当前分区表，确认这是SD卡而不是硬盘。 - 输入
o建立新的MBR分区表。 - 输入
n创建第一个分区。类型选p主分区，分区编号1，起始扇区直接回车用默认值，结束扇区写入+512M，表示第一个分区512MB。 - 输入
n创建第二个分区。类型选p，分区编号2，起始扇区回车默认，结束扇区回车默认，把剩余空间全部给第二分区。 - 输入
t修改分区类型：第一分区设为c（W95 FAT32 LBA），第二分区设为83（Linux）。 - 输入
w保存退出。
然后格式化：
sudo mkfs.fat -F32 -n BOOT /dev/sdb1 sudo mkfs.ext4 -L ROOTFS /dev/sdb2格式化的时间取决于卡的速度，一般十几秒到几分钟。格式化完成后用sudo partprobe /dev/sdb或者重新插拔SD卡，让系统重新读取分区表。
4.3 第三步：拷贝启动文件
先挂载两个分区：
mkdir -p /mnt/boot /mnt/rootfs sudo mount /dev/sdb1 /mnt/boot sudo mount /dev/sdb2 /mnt/rootfs把BOOT.BIN、image.ub、boot.scr拷进第一分区：
sudo cp BOOT.BIN image.ub boot.scr /mnt/boot/ sync sudo umount /mnt/boot如果第二分区已经有解压好的rootfs，就拷贝过去；如果暂时还没有根文件系统，留空也没关系，但后续内核一定会panic。建议第一次做启动卡时，先把一个能用的rootfs解压到第二分区，避免排查时同时面对“启动文件问题和根文件系统问题”两个变数。
4.4 第四步：配置启动拨码与串口终端
SD卡制作完成后，先看板卡硬件手册找到BOOT MODE拨码。通常拨到SD启动组合后，板卡上电就会优先从SD卡找BOOT.BIN。
连接串口是必须的。用USB转串口线连接调试串口，波特率设置为115200、8N1。打开串口终端后再上电，这样能完整看到BootROM跳转后U-Boot的打印。我给板子上电前的习惯顺序是：先开终端，再上电，避免漏掉最开始的启动日志。
4.5 第五步：上电观察串口输出，确认进入Linux
正常情况下，串口会依次出现U-Boot版本信息、DRAM容量、MMC设备识别信息，然后几秒后开始加载image.ub，最后看到内核启动日志并进入init进程。
如果看到U-Boot停在“Hit any key to stop autoboot”或者反复重启，先不要急着重新格式化卡。进入U-Boot命令行后，检查环境变量里的bootcmd和bootargs是否正确，具体方法下一节展开。我一般用printenv直接把环境变量打印全，看bootcmd里引用的mmc设备和文件名是否和我卡上的实际情况一致。
5. 掉过的坑：板卡无法启动的排查链路
5.1 排查顺序永远从串口log开始
很多人在板卡无法启动时，第一反应是怀疑SD卡文件被损坏，马上重新格式化。我的建议是，先稳下来，把串口log完整抓下来，从头读一遍。串口log会告诉你卡在哪个阶段：是BootROM就没读到数据（可能板卡根本没进入SD启动模式，或者BOOT.BIN没放对位置），是U-Boot阶段找不到文件（文件系统、文件名、分区索引问题），还是内核阶段挂不上根文件系统（cmdline或rootfs问题）。
排查顺序应该是：确认启动模式；确认U-Boot能否枚举到MMC设备；确认FAT分区里能看到文件；确认文件能加载到内存；确认bootm执行结果；最后才是内核日志。每验证一步，就把这一步的结果记下来。我发现大多数人调半天调不出来，其实是因为跳过了中间步骤，直接跳到“重新做一张卡”。
5.2 典型报错与根因对照表
下面是我实际遇到过的、比较有代表性的报错现象：
| 现象 | 可能根因 | 快速验证方法 |
|---|---|---|
| 上电后串口全无反应 | 启动拨码错、BOOT.BIN缺失、板卡供电或复位异常 | 检查拨码和电源指示灯；换JTAG试启 |
| U-Boot打印正常但找不到SD卡 | mmc设备未初始化、SD卡槽接触不良、卡不兼容 | 输入mmc list、mmc dev 0查看设备状态 |
| 能识别SD卡但找不到BOOT.BIN | 第一分区不是FAT32、文件名大小写不对 | fatls mmc 0:1列出第一分区文件 |
| BOOT.BIN加载执行后无输出 | FSBL/PMUFW/ATF/U-Boot版本不匹配、DDR配置错误 | 用Vitis重新导出XSA后重编Boot Image |
| 加载image.ub后报“Wrong image format” | image.ub不是FIT镜像、U-Boot未开启FIT支持 | 用mkimage -l image.ub检查文件头 |
| 内核启动后挂不上rootfs | bootargs中root设备名不对、第二分区无rootfs | 检查root=/dev/mmcblk0p2和分区内容 |
| 内核或设备树加载后系统重启 | DTB与硬件不匹配、DDR频率问题 | 换默认dtb，降低DDR频率验证 |
这张表不是万能的，但它能帮你把“不知道问题在哪”变成“先怀疑哪一个方向”。
5.3 一个“换了张卡就好了”的案例背后：为什么SD卡本身会背锅
有次我帮同事调一块板子，现象是U-Boot偶尔能起来，但10次有7次在网络初始化时卡死。换了张卡，问题居然消失了。当时我们都以为是原来那张卡的物理损坏，后来深入排查才发现，那张卡虽然是正品，但文件系统分区对齐做得不好，导致U-Boot在读取FAT表时耗费的时间不稳定，间接影响了后续驱动初始化时序。
这个案例想说明两点：一是卡本身的“健康状态”确实会引发各种诡异现象，所以手边常备一张验证过能正常启动的黄金卡很重要；二是当现象随机出现时，不妨真的先把卡换掉试试，它能快速帮你把“配置问题”和“介质问题”区分开。
我自己验证SD卡的手法是，直接用dd从整卡读一遍，再写一遍，再用fsck检查文件系统。整个过程虽然花时间，但能提前暴露很多看起来“高深莫测”的隐性故障。
5.4 用U-Boot命令行手动引导，反向验证文件链路
当自动启动失败时，不要只盯着bootcmd的日志看，直接进U-Boot命令行手动敲命令，是效率最高的排查方法。下面是一组典型的操作：
# 列出SD卡设备 mmc list # 选择设备0 mmc dev 0 # 查看第一分区文件列表 fatls mmc 0:1 # 加载FIT镜像到内存地址 fatload mmc 0:1 0x20000000 image.ub # 查看FIT镜像头文件信息 iminfo 0x20000000 # 启动镜像 bootm 0x20000000每一条命令成功后，问题范围就缩小一圈。如果fatload就报错了，说明板卡读FAT分区有问题，重点检查分区表、文件系统格式；如果iminfo显示不是FIT镜像，说明image.ub的生成方式和U-Boot编译配置不匹配；如果bootm执行后串口就没动静了，重点怀疑DTB与硬件匹配和内核本身的崩溃。这套“手动引导四步法”，我每次调启动问题都会优先使用。
6. 制作完成后的自检与增量维护技巧
6.1 黄金母卡：用好dd做备份和还原
启动盘第一次调通后，我建议马上做一张“黄金母卡”的完整镜像，用来应对后面无数次的重复烧写。制作方法很简单：
sudo dd if=/dev/sdb of=golden_sd.img bs=4M status=progress之后要还原时，把镜像写回SD卡：
sudo dd if=golden_sd.img of=/dev/sdb bs=4M status=progress syncdd是对整个设备做镜像，所以还原出来的卡分区表、文件内容、标签都完全一致。这个办法比逐分区拷贝、格式化省事太多。我一般还会把版本号写进镜像文件名，比如golden_sd_v1.0_linux5.4.img，否则几个月后你根本分不清哪张镜像对应哪个版本的系统。
需要注意：dd整卡镜像的目标卡容量必须大于等于源卡容量，否则写不下。另外dd不会检查损坏扇区，如果遇到坏卡，它只会反复报错。批量烧录多张卡时，建议先用普通方式格式化一张验证卡，再整卡dd生成镜像，批量还原后抽查启动成功率。
6.2 更新内核设备树，不用重新做卡
SD卡启动盘最大的好处之一就是更新成本极低。内核换版本时，只需要替换第一分区里的image.ub；设备树调整后，重新打包image.ub再覆盖即可。不需要重新格式化，不需要动第二分区的根文件系统。
但这里有个细节不能忽略：如果你从U-Boot传入的bootargs里指定了加载多个dtb，或者U-Boot从FIT内读取配置，那么替换image.ub后，必须确认FIT内的配置名和U-Boot脚本里写的配置名一致。否则可能出现“文件已经替换，但启动的还是旧设备树”这类假象。
我自己习惯在调试阶段把image.ub保留多个历史版本，比如image_v1.ub、image_v2.ub，然后在boot.cmd里临时指定加载不同版本，这样A/B对比内核行为非常方便。调完后再删掉多余文件，保持启动分区干净。
6.3 板载读写SD卡：在Linux下在线更新启动分区
很多项目交付后，设备已经在现场跑了，这时再为了换内核把SD卡拔出来重新制作，显然不合适。好在MPSoC跑起来之后，SD卡就是普通块设备，可以在Linux系统里直接挂载第一分区并更新文件。
先确认启动分区的设备节点，一般是/dev/mmcblk0p1：
sudo mount /dev/mmcblk0p1 /mnt/update cd /mnt/update # 备份旧文件 cp BOOT.BIN BOOT.BIN.bak # 复制新文件，注意顺序和完整性 cp /tmp/BOOT.BIN ./BOOT.BIN sync cd / sudo umount /mnt/update更新单文件时，务必先把新文件传到板载的临时目录，确认MD5无误后再覆盖。如果直接通过网络向已挂载的FAT分区写入，断电风险会更高。另外，更新过程中千万不要同时篡改第二分区的根文件系统，除非你知道自己在做什么。我曾经在一次测试里把启动分区和rootfs同时改了，结果现场环境乱套，最后只能抱着机箱回实验室重刷。
6.4 最后的小建议：把制作流程脚本化
制作SD卡的操作如果只做一次，手工敲命令完全没问题。但如果你要在不同项目里反复做启动盘，我强烈建议把整个流程写成一个Shell脚本。脚本里包含设备节点的确认、fdisk的交互输入、格式化命令、文件拷贝和挂载检查。这样不仅能避免手工操作时的低级失误，还能让团队里经验较少的同事也安全地完成同样的工作。
脚本里至少要有一层保护：检查目标设备是否已经被挂载，检查设备容量是否大于某个阈值，检查设备文件是否存在。宁可多写几行判断，也不能让误操作伤到主机硬盘。
我在实际项目中还有个习惯：每次做完启动盘，都会在卡的外壳上用记号笔写上项目名、版本号和日期。这个习惯帮了我很多次，因为多张SD卡混放在一起时，光看文件系统标签根本分不清哪张是哪个项目的，而外贴标签能让你三秒钟内找到正确的卡。这样的小细节，在紧急排障时能省下很多时间。
