简介围绕XCZU4EV等Zynq UltraScale MPSoC器件这份资料面向FPGA与嵌入式系统开发者详解如何基于VITIS工具链完成程序固化覆盖XCZU2CG、XCZU2EG、XCZU4EV等常用型号解决从软件工程创建、硬件描述生成到启动镜像制作的完整流程问题。压缩包共2109个文件包含C/H源码、Vivado/Vitis工程配置xpr/xsa/bd、XDC约束与综合报告、boot/bit/bin/elf启动镜像、链接脚本以及makefile/tcl/sh等自动化编译脚本也有libxil.a、libxilsecure.a等驱动库文件整体约62.92MB目录按硬件工程、软件工程、启动镜像等模块划分便于按需检索。项目还包含9240_zynqmp_emmc.bin.50Mhz等eMMC固化镜像可帮助读者理解启动介质选择、分区表配置以及Vitis驱动库的引用方式通过阅读源码和编译脚本可掌握在XCZU2CG/XCZU2EG/XCZU4EV等平台上实施程序固化的完整思路。已有441人学习下载适合正在调试Zynq MPSoC固化、或希望提升Vitis软硬件协同设计能力的工程师参考。1. XCZU4EV 程序固化难点不在「烧写」而在「启动链」XCZU4EV 的「程序固化」不是把固件写进 flash 就完事而是让板子上电能自动跑完一整条启动链BootROM 按 BOOT_MODE 引脚从 QSPI 的 0 地址读镜像头把 FSBL 搬进片内 OCM 交给 Cortex-R5FSBL 再初始化 DDR、搬运 PMUFW 和 ATF/U-Boot最后才轮到你的应用。任何一级缺失或者分区属性写错现象都是「JTAG 能跑一上电就没输出」。VITIS 2019.2 之后的固化路径很固定Vivado 导 XSAVitis 生成引导组件bootgen 打包 BOOT.BINprogram_flash 写 QSPI最后拨启动模式上电。这篇按这条线讲清楚每一步的命令、参数与失败判读适合已经调通 ZU4EV 最小系统、正卡在固化这一关的工程师。2. 先理清 ZU4EV 的启动链与 BOOT.BIN 组成再动手固化2.1 BootROM → FSBL → ATF → U-Boot每一级加载器各自干什么ZU4EV 属于 Zynq UltraScale EV 系列PS 侧有三个处理域APU四核 Cortex-A53、RPU双核 Cortex-R5、PMU专用电源管理微控制器。固化启动时最先动起来的不是 A53而是 BootROM 和 R5。上电复位后CSU 里的 BootROM 采样 BOOT_MODE[3:0] 引脚决定从哪个介质读镜像。BootROM 只认固定偏移处的 boot header该头部记录了分区表位置和第一个可执行分区。校验通过后BootROM 把第一个分区也就是 FSBL搬到片内 OCM 并启动 R5 执行。FSBL 的职责是「初始化硬件加搬运后续分区」。它根据 XSA 里导出的 psu_init 配置时钟、MIO 和 DDR 控制器然后从 QSPI 里把 BOOT.BIN 的后续分区依次搬到各自的目的地址PMUFW 进 PMU 的私有 RAMATFbl31.elf放到 OCM 顶部区域U-Boot 放到 DDR。全部就位后 FSBL 跳转到 EL3 的 ATFATF 再切到 EL2 启动 U-BootU-Boot 最后把内核放到 EL1。注意一个容易混淆的点FSBL 本身跑在 R5 上A53 真正接管要到 ATF 之后。所以排查固化问题时先分清「卡在 R5 阶段」还是「卡在 A53 阶段」能省掉大量盲目改代码的时间。提示镜像头被擦掉时板子通常表现为完全无输出而且不会给你任何报错。排查顺序是拨回 JTAG 模式连上调试器确认芯片活着再用 xsct 读 QSPI 0 地址处的若干字节确认是否还是合法 BOOT.BIN 头部。2.2 BOOT_MODE[3:0] 引脚QSPI、SD、eMMC 与 JTAG 怎么选BOOT_MODE 是 4 根专用输入引脚多数 ZU4EV 板卡用拨码开关或 0 欧电阻拉到固定电平。上电瞬间采样一次采样之后再改引脚无效必须重新上电。常见取值如下表完整定义在 UG1085 的 Boot Mode Settings 章节。BOOT_MODE[3:0]启动介质典型用途0000JTAG烧写与调试不读 boot 设备0001QSPI24单24 位地址16MB 及以下 QSPI 固化0010QSPI24双叠片两片 QSPI 合成地址空间0100QSPI32单32 位地址大于 16MB 的 QSPI0111SDSD 卡放 BOOT.BIN开发期最常用1000eMMCeMMC 启动量产板常见选型逻辑看产品阶段。开发期我用 JTAG 模式配合 program_flash 反复烧写用 SD 模式调试 Linux 功能到了交付阶段再切到 QSPI。需要留意拨码开关丝印「ON」对应 0 还是 1不同板卡不统一别想当然顺着原理图上 BOOT_MODE0BOOT_MODE3 的走线用万用表量一下最稳。BOOT_MODE 拨错是最隐蔽的故障源固件烧得完全正确上电就是黑屏而你不一定会第一时间怀疑一排小小的拨码。2.3 BOOT.BIN 里到底装了什么BIF 分区描述长什么样BOOT.BIN 是 bootgen 把多个 ELF 和 bit 流按分区表打包出来的单一文件。文件开头是 boot header接着是镜像头表和分区头表后面才是各分区实体数据。BootROM 只负责加载第一个分区后续分区由 FSBL 按分区头里的加载地址和属性依次处理。因此分区顺序不是随意的Xilinx 推荐的 ZU 顺序是FSBL → PMUFW → PL bitstream可选→ ATF → U-Boot 或裸机应用。BIFBoot Image Format文件就是描述打包过程的输入。一个面向 Linux 的典型 BIF 如下裸机场景只需保留 FSBL 和应用两段// boot_linux.bif the_ROM_image: { [bootloader] zynqmp_fsbl.elf [pmufw_image] pmufw.elf [destination_devicepl] system.bit [destination_cpua53-0, exception_levelel-3, trustzone] bl31.elf [destination_cpua53-0, exception_levelel-2] u-boot.elf }每个方括号属性都对应分区头里的一个字段[bootloader]告诉 bootgen 这个分区是 BootROM 要拉进 OCM 并交权给 R5 的 FSBL[pmufw_image]是 PMU 固件专用类型[destination_devicepl]表示该分区由 FSBL 写入 PL 配置逻辑destination_cpua53-0指定加载到 A53 核 0exception_level对应 ATFel-3和 U-Bootel-2的运行特权级。属性写错最常见的后果是 A53 侧毫无打印——不是 U-Boot 坏了而是它被放到了错误的异常级别BL31 起不来。3. 在 VITIS 里生成 FSBL 与 PMUFW并用 BIF 打包 BOOT.BIN3.1 从 Vivado 导出 XSA再创建 VITIS 平台工程固化用的 FSBL 必须和硬件设计严格匹配因为 psu_init 里的 DDR、MIO、时钟配置全部来自 Vivado 导出的 XSA。先在 Vivado 里完成综合实现并生成 bitstream然后 File → Export Hardware勾选 Include bitstream导出为 xsa 文件比如 zup_zu4ev.xsa。如果只是纯 PS 裸机固化、PL 不参与不导 bitstream 也能工作但建议始终勾选避免后面想加 bit 分区时又要重导一遍。Vitis 里新建 Platform ProjectHardware Specification 选择这个 xsaVitis 会自动挂出 psu_cortexa53、psu_cortexr5、psu_pmu 三个处理器上下文。创建后先 build 一次平台确保 psu_init 和 standalone BSP 编译通过。命令行等价操作是 xsct 会话里执行platform create -name zu4ev_plat -hw zup_zu4ev.xsa -proc psu_cortexa53 -os standalone platform generate平台工程的 OS 默认选 standalone后面 FSBL 和 PMUFW 的 BSP 都基于这个库。版本上尽量保持 Vivado 和 Vitis 年号一致比如都是 2020.1跨大版本打开 XSA 通常直接报兼容错误。另外 2023.2 之后 Xilinx 把嵌入式开发并回 VivadoVitis 独立 IDE 不再更新但存量 ZU4EV 工程绝大多数仍是 2019.22022.2 的流程本文命令在这些版本上同样成立。3.2 用 Application 模板生成 FSBL 与 PMUFW处理器别选错在已 build 的平台工程上右键 New Application Project模板列表里找 FSBL 模板不同版本显示为 Zynq MPSoC FSBL 或 Zynq UltraScale MPSoC FSBL。这一步最容易踩的坑是处理器上下文FSBL 要选 psu_cortexr5 对应的 standalone 域PMU 固件要选 psu_pmu 域两者都和最终跑 Linux 用的 psu_cortexa53 无关。如果向导里看不到 R5 或 PMU 域先回平台工程属性里确认相应处理器有没有被勾选。两个工程分别 build 之后拿到两个 ELFzynqmp_fsbl.elf链接脚本在 OCM 区域产物通常在 zynqmp_fsbl/Debug/ 目录pmufw.elf链接到 PMU 私有 RAM编译结构和普通裸机程序完全不同不要拿别的 ELF 冒充。不方便开 GUI 时xsct 里可以用 createapp 命令快速生成这两个工程。拿到 ELF 后先别急着打包回 Hardware 窗口确认 FSBL 对应的平台确实是当前要固化的硬件。同时开好几个工程、最后打包进去一块别的板卡的 FSBL烧完上电毫无反应这类问题排查起来最耗时间。3.3 写 BIF 并调用 bootgen 生成 BOOT.BIN把 2.3 的 BIF 保存成文本文件路径用绝对路径或相对 bootgen 工作目录的相对路径。以纯裸机 A53 应用为例BIF 可以精简到两段// boot_baremetal.bif the_ROM_image: { [bootloader] zynqmp_fsbl.elf [destination_cpua53-0] app.elf }然后在 xsct 控制台或任意终端执行bootgen -image boot_baremetal.bif -o BOOT.BIN -w on-o指定输出文件名-w on表示覆盖已存在文件。bootgen 随 Vitis 一起安装找不到就把 Vitis 安装路径下的 bin 目录加进 PATH。生成后用十六进制编辑器看一眼头部应能看到镜像头魔数和分区表偏移如果 BOOT.BIN 只有几 KB多半是 ELF 路径写错bootgen 把空分区打了进去。GUI 路径 Xilinx → Create Boot Image 可以完成同样的事情差异是它自动生成 BIF 再调 bootgen。无论哪种方式结尾都要确认没有「分区间重叠」之类的告警。U-Boot 和裸机应用 ELF 自带加载地址bootgen 按地址摆放分区两个分区地址域交叠时它会直接报错看到立刻改链接脚本或加载地址不要试图忽略。4. 用 JTAG 把 BOOT.BIN 固化进 QSPI并上电验证自启4.1 先拨回 JTAG 模式再用 xsct 的 program_flash 烧写固化烧写出镜率最高的错误是没把 BOOT_MODE 拨回 0000 就直接烧写。program_flash 的原理是通过 JTAG 把 FSBL 加载进 OCM由 FSBL 驱动 PS 侧 GQSPI 控制器完成擦除和写入所以烧写期间必须让芯片处于 JTAG 引导模式。boot 模式停在 QSPI 时表现是连接成功但擦写超时。准备好 BOOT.BIN 和与硬件匹配的 zynqmp_fsbl.elf开 xsct 执行connect targets -set -filter {name ~ *PSU*} rst -system program_flash -f BOOT.BIN -fsbl zynqmp_fsbl.elf -flash_type qspi-x4-single -offset 0 -verify逐项说明参数-f是要写入的镜像-fsbl指定烧写辅助用的 FSBL它会先在 OCM 里跑起来再操作 flash随便给一个别的硬件版本的 FSBL 会导致 GQSPI 初始化错误-flash_type qspi-x4-single表示板子上挂单颗 QSPI、数据线走 x4ZU4EV 板卡常见器件是 Macronix MT25QU128 系列-offset 0是 flash 起始地址BootROM 固定从偏移 0 读镜像-verify写完后读回整片比对强烈建议保留固化比单纯跑功能多花的这几秒非常值。烧写卡在某个百分比不动时先看终端有没有 flash id mismatch 报错再检查 JTAG 频率。不少下载器在 30MHz 下写 QSPI 不稳定降到 15MHz 通常就好了。GUI 对应入口是 Xilinx → Program Flash对话框字段和上面命令一一对应。烧写完成后保持 JTAG 模式把-verify的结果记录成基线后面验证会用到。提示不要把 PL 侧的 AXI Quad SPI 和 PS 侧 GQSPI 混为一谈。BootROM、FSBL 和 U-Boot 的 sf 驱动都走 PS 的 GQSPIbitstream 里例化的 AXI QSPI 就算烧进 flash 也不会参与启动。4.2 拨回 QSPI 启动模式用串口确认完整启动链烧写完不要急着验收先断电把 BOOT_MODE[3:0] 从 0000 拨到 0001QSPI24 单接 115200/8N1 串口重新上电。上电瞬间应观察到 BootROM → FSBL → ATF → U-Boot 的接力日志正常顺序大致是FSBL 打印 Xilinx Zynq MPSoC First Stage Boot Loader 和 Release 版本号PMU 固件打印版本行ATF 打印 NOTICE: BL31 系列信息最后 U-Boot 打印版本号、DDR 容量和 Hit any key to stop autoboot。裸机场景则在 FSBL 日志后直接出现应用自己的打印。看到完整链路后再做一次彻底掉电重启确认不是靠复位残留状态起来的。如果两遍上电行为不一致先查 BOOT_MODE 拨码有没有在重新上电时被误碰再看调试器是否还挂在板子上把 JTAG 链电平拉偏。这一步是固化验收的核心动作直接决定板卡能不能交付产线。4.3 QSPI 器件、24/32 位地址与双片配置的注意点-flash_type必须和板卡 QSPI 实际接法一致三处最容易错单颗 x4 选 qspi-x4-single两颗叠片选 qspi-x4-dual选错后 program_flash 报 flash id mismatch不破坏 flash但白耗一轮排查。BOOT_MODE 0001 对应 24 位地址最大寻址 16MB超过 16MB 的器件要换 0100QSPI32否则 BootROM 和 FSBL 都访问不到高地址区。MT25QU128 是 128Mbit即 16MB用 0001 正好换 256Mbit 器件时记得同步改启动模式和烧写参数。还有一类问题出现在板卡把 QSPI 的片选或时钟接到 PL 侧引脚导致 PS GQSPI 初始化后完全找不到器件。判断方法是在 U-Boot 里跑sf probe能列出 JEDEC ID 说明 PS 链路没问题。ZU4EV 的 GQSPI 引脚全部来自 MIO这个约束在设计评审阶段就要确认软件层面绕不过去。5. 固化完成后的验证动作与不重烧 BOOT.BIN 的在线升级5.1 串口日志分段判读卡在哪一级加载器日志特征所在阶段优先怀疑完全无输出BootROM 之前BOOT_MODE 拨错、QSPI 0 地址为空FSBL Release 行后无后续FSBL 初始化DDR 配置错误、PMUFW 缺失BL31 NOTICE 后卡死ATFU-Boot 分区缺失或 exception_level 错U-Boot 起来后无应用应用加载分区偏移、加载地址不符对照这张小表能省大量时间。比如只出现 FSBL 的 Release 行几乎都是 DDR 初始化失败回 Vivado 检查 DDR 型号、位宽和速率配置常见对应 ddr4 cal 失败BL31 之后卡住先确认 BIF 里 U-Boot 那段属性再确认 flash 里写入的是完整 BOOT.BIN 而不是只含 FSBL 的空壳。5.2 用 U-Boot 的 sf 命令读回 QSPI 做 CRC 校验固化后不能只靠「能启动」判断 flash 内容完好。在 U-Boot 里读回 BOOT.BIN 存放区域算 CRC和第一次烧写验证时的基线比对sf probe sf read 0x1000000 0x0 0x100000 crc32 0x1000000 0x100000sf probe初始化 GQSPI 并识别器件sf read把 0 地址开始的 1MB 数据读到 DDR 的 0x1000000crc32计算该段校验值。把这个值和 4.1 烧写时-verify后记录下的结果比对一致说明 flash 数据链路稳定。这个动作适合写进产线抽检脚本也适合怀疑 flash 老化时快速定位。5.3 只更新应用分区不重烧 BOOT.BIN 的在线升级路径全量重烧 BOOT.BIN 的代价不只是时间长更在于擦除 0 分区的瞬间掉电板子可能彻底起不来。常见做法是把镜像布局固定下来0 地址放 BOOT.BIN0x100000 起放应用或内核与 dtb更新时只擦写数据分区。以 Linux 为例U-Boot 下走网络更新setenv autoload no tftp 0x1000000 image.ub sf probe sf erase 0x100000 0x400000 sf write 0x1000000 0x100000 0x400000tftp把新镜像拉到 DDR前提是 U-Boot 里 ipaddr 和 serverip 已配好sf erase按固定大小擦数据分区sf write写回。分区偏移必须大于实际 BOOT.BIN 尺寸并留出余量否则写入越界后 BootROM 连 FSBL 都可能读不到。裸机场景没有 U-Boot 时最稳妥的方案是启用 FSBL 的 MULTI_BOOT 宏把第二份镜像放到指定偏移启动失败自动回退旧版本该宏默认关闭改动后要重新生成 FSBL 并连同新 BIF 一起固化。JTAG 是永远最保底的恢复手段——只要拨回 0000program_flash 随时能重新救活板卡这也是所有固化操作的第一条逃生通道。本文还有配套的精品资源点击获取
简介围绕XCZU4EV等Zynq UltraScale MPSoC器件这份资料面向FPGA与嵌入式系统开发者详解如何基于VITIS工具链完成程序固化覆盖XCZU2CG、XCZU2EG、XCZU4EV等常用型号解决从软件工程创建、硬件描述生成到启动镜像制作的完整流程问题。压缩包共2109个文件包含C/H源码、Vivado/Vitis工程配置xpr/xsa/bd、XDC约束与综合报告、boot/bit/bin/elf启动镜像、链接脚本以及makefile/tcl/sh等自动化编译脚本也有libxil.a、libxilsecure.a等驱动库文件整体约62.92MB目录按硬件工程、软件工程、启动镜像等模块划分便于按需检索。项目还包含9240_zynqmp_emmc.bin.50Mhz等eMMC固化镜像可帮助读者理解启动介质选择、分区表配置以及Vitis驱动库的引用方式通过阅读源码和编译脚本可掌握在XCZU2CG/XCZU2EG/XCZU4EV等平台上实施程序固化的完整思路。已有441人学习下载适合正在调试Zynq MPSoC固化、或希望提升Vitis软硬件协同设计能力的工程师参考。1. XCZU4EV 程序固化难点不在「烧写」而在「启动链」XCZU4EV 的「程序固化」不是把固件写进 flash 就完事而是让板子上电能自动跑完一整条启动链BootROM 按 BOOT_MODE 引脚从 QSPI 的 0 地址读镜像头把 FSBL 搬进片内 OCM 交给 Cortex-R5FSBL 再初始化 DDR、搬运 PMUFW 和 ATF/U-Boot最后才轮到你的应用。任何一级缺失或者分区属性写错现象都是「JTAG 能跑一上电就没输出」。VITIS 2019.2 之后的固化路径很固定Vivado 导 XSAVitis 生成引导组件bootgen 打包 BOOT.BINprogram_flash 写 QSPI最后拨启动模式上电。这篇按这条线讲清楚每一步的命令、参数与失败判读适合已经调通 ZU4EV 最小系统、正卡在固化这一关的工程师。2. 先理清 ZU4EV 的启动链与 BOOT.BIN 组成再动手固化2.1 BootROM → FSBL → ATF → U-Boot每一级加载器各自干什么ZU4EV 属于 Zynq UltraScale EV 系列PS 侧有三个处理域APU四核 Cortex-A53、RPU双核 Cortex-R5、PMU专用电源管理微控制器。固化启动时最先动起来的不是 A53而是 BootROM 和 R5。上电复位后CSU 里的 BootROM 采样 BOOT_MODE[3:0] 引脚决定从哪个介质读镜像。BootROM 只认固定偏移处的 boot header该头部记录了分区表位置和第一个可执行分区。校验通过后BootROM 把第一个分区也就是 FSBL搬到片内 OCM 并启动 R5 执行。FSBL 的职责是「初始化硬件加搬运后续分区」。它根据 XSA 里导出的 psu_init 配置时钟、MIO 和 DDR 控制器然后从 QSPI 里把 BOOT.BIN 的后续分区依次搬到各自的目的地址PMUFW 进 PMU 的私有 RAMATFbl31.elf放到 OCM 顶部区域U-Boot 放到 DDR。全部就位后 FSBL 跳转到 EL3 的 ATFATF 再切到 EL2 启动 U-BootU-Boot 最后把内核放到 EL1。注意一个容易混淆的点FSBL 本身跑在 R5 上A53 真正接管要到 ATF 之后。所以排查固化问题时先分清「卡在 R5 阶段」还是「卡在 A53 阶段」能省掉大量盲目改代码的时间。提示镜像头被擦掉时板子通常表现为完全无输出而且不会给你任何报错。排查顺序是拨回 JTAG 模式连上调试器确认芯片活着再用 xsct 读 QSPI 0 地址处的若干字节确认是否还是合法 BOOT.BIN 头部。2.2 BOOT_MODE[3:0] 引脚QSPI、SD、eMMC 与 JTAG 怎么选BOOT_MODE 是 4 根专用输入引脚多数 ZU4EV 板卡用拨码开关或 0 欧电阻拉到固定电平。上电瞬间采样一次采样之后再改引脚无效必须重新上电。常见取值如下表完整定义在 UG1085 的 Boot Mode Settings 章节。BOOT_MODE[3:0]启动介质典型用途0000JTAG烧写与调试不读 boot 设备0001QSPI24单24 位地址16MB 及以下 QSPI 固化0010QSPI24双叠片两片 QSPI 合成地址空间0100QSPI32单32 位地址大于 16MB 的 QSPI0111SDSD 卡放 BOOT.BIN开发期最常用1000eMMCeMMC 启动量产板常见选型逻辑看产品阶段。开发期我用 JTAG 模式配合 program_flash 反复烧写用 SD 模式调试 Linux 功能到了交付阶段再切到 QSPI。需要留意拨码开关丝印「ON」对应 0 还是 1不同板卡不统一别想当然顺着原理图上 BOOT_MODE0BOOT_MODE3 的走线用万用表量一下最稳。BOOT_MODE 拨错是最隐蔽的故障源固件烧得完全正确上电就是黑屏而你不一定会第一时间怀疑一排小小的拨码。2.3 BOOT.BIN 里到底装了什么BIF 分区描述长什么样BOOT.BIN 是 bootgen 把多个 ELF 和 bit 流按分区表打包出来的单一文件。文件开头是 boot header接着是镜像头表和分区头表后面才是各分区实体数据。BootROM 只负责加载第一个分区后续分区由 FSBL 按分区头里的加载地址和属性依次处理。因此分区顺序不是随意的Xilinx 推荐的 ZU 顺序是FSBL → PMUFW → PL bitstream可选→ ATF → U-Boot 或裸机应用。BIFBoot Image Format文件就是描述打包过程的输入。一个面向 Linux 的典型 BIF 如下裸机场景只需保留 FSBL 和应用两段// boot_linux.bif the_ROM_image: { [bootloader] zynqmp_fsbl.elf [pmufw_image] pmufw.elf [destination_devicepl] system.bit [destination_cpua53-0, exception_levelel-3, trustzone] bl31.elf [destination_cpua53-0, exception_levelel-2] u-boot.elf }每个方括号属性都对应分区头里的一个字段[bootloader]告诉 bootgen 这个分区是 BootROM 要拉进 OCM 并交权给 R5 的 FSBL[pmufw_image]是 PMU 固件专用类型[destination_devicepl]表示该分区由 FSBL 写入 PL 配置逻辑destination_cpua53-0指定加载到 A53 核 0exception_level对应 ATFel-3和 U-Bootel-2的运行特权级。属性写错最常见的后果是 A53 侧毫无打印——不是 U-Boot 坏了而是它被放到了错误的异常级别BL31 起不来。3. 在 VITIS 里生成 FSBL 与 PMUFW并用 BIF 打包 BOOT.BIN3.1 从 Vivado 导出 XSA再创建 VITIS 平台工程固化用的 FSBL 必须和硬件设计严格匹配因为 psu_init 里的 DDR、MIO、时钟配置全部来自 Vivado 导出的 XSA。先在 Vivado 里完成综合实现并生成 bitstream然后 File → Export Hardware勾选 Include bitstream导出为 xsa 文件比如 zup_zu4ev.xsa。如果只是纯 PS 裸机固化、PL 不参与不导 bitstream 也能工作但建议始终勾选避免后面想加 bit 分区时又要重导一遍。Vitis 里新建 Platform ProjectHardware Specification 选择这个 xsaVitis 会自动挂出 psu_cortexa53、psu_cortexr5、psu_pmu 三个处理器上下文。创建后先 build 一次平台确保 psu_init 和 standalone BSP 编译通过。命令行等价操作是 xsct 会话里执行platform create -name zu4ev_plat -hw zup_zu4ev.xsa -proc psu_cortexa53 -os standalone platform generate平台工程的 OS 默认选 standalone后面 FSBL 和 PMUFW 的 BSP 都基于这个库。版本上尽量保持 Vivado 和 Vitis 年号一致比如都是 2020.1跨大版本打开 XSA 通常直接报兼容错误。另外 2023.2 之后 Xilinx 把嵌入式开发并回 VivadoVitis 独立 IDE 不再更新但存量 ZU4EV 工程绝大多数仍是 2019.22022.2 的流程本文命令在这些版本上同样成立。3.2 用 Application 模板生成 FSBL 与 PMUFW处理器别选错在已 build 的平台工程上右键 New Application Project模板列表里找 FSBL 模板不同版本显示为 Zynq MPSoC FSBL 或 Zynq UltraScale MPSoC FSBL。这一步最容易踩的坑是处理器上下文FSBL 要选 psu_cortexr5 对应的 standalone 域PMU 固件要选 psu_pmu 域两者都和最终跑 Linux 用的 psu_cortexa53 无关。如果向导里看不到 R5 或 PMU 域先回平台工程属性里确认相应处理器有没有被勾选。两个工程分别 build 之后拿到两个 ELFzynqmp_fsbl.elf链接脚本在 OCM 区域产物通常在 zynqmp_fsbl/Debug/ 目录pmufw.elf链接到 PMU 私有 RAM编译结构和普通裸机程序完全不同不要拿别的 ELF 冒充。不方便开 GUI 时xsct 里可以用 createapp 命令快速生成这两个工程。拿到 ELF 后先别急着打包回 Hardware 窗口确认 FSBL 对应的平台确实是当前要固化的硬件。同时开好几个工程、最后打包进去一块别的板卡的 FSBL烧完上电毫无反应这类问题排查起来最耗时间。3.3 写 BIF 并调用 bootgen 生成 BOOT.BIN把 2.3 的 BIF 保存成文本文件路径用绝对路径或相对 bootgen 工作目录的相对路径。以纯裸机 A53 应用为例BIF 可以精简到两段// boot_baremetal.bif the_ROM_image: { [bootloader] zynqmp_fsbl.elf [destination_cpua53-0] app.elf }然后在 xsct 控制台或任意终端执行bootgen -image boot_baremetal.bif -o BOOT.BIN -w on-o指定输出文件名-w on表示覆盖已存在文件。bootgen 随 Vitis 一起安装找不到就把 Vitis 安装路径下的 bin 目录加进 PATH。生成后用十六进制编辑器看一眼头部应能看到镜像头魔数和分区表偏移如果 BOOT.BIN 只有几 KB多半是 ELF 路径写错bootgen 把空分区打了进去。GUI 路径 Xilinx → Create Boot Image 可以完成同样的事情差异是它自动生成 BIF 再调 bootgen。无论哪种方式结尾都要确认没有「分区间重叠」之类的告警。U-Boot 和裸机应用 ELF 自带加载地址bootgen 按地址摆放分区两个分区地址域交叠时它会直接报错看到立刻改链接脚本或加载地址不要试图忽略。4. 用 JTAG 把 BOOT.BIN 固化进 QSPI并上电验证自启4.1 先拨回 JTAG 模式再用 xsct 的 program_flash 烧写固化烧写出镜率最高的错误是没把 BOOT_MODE 拨回 0000 就直接烧写。program_flash 的原理是通过 JTAG 把 FSBL 加载进 OCM由 FSBL 驱动 PS 侧 GQSPI 控制器完成擦除和写入所以烧写期间必须让芯片处于 JTAG 引导模式。boot 模式停在 QSPI 时表现是连接成功但擦写超时。准备好 BOOT.BIN 和与硬件匹配的 zynqmp_fsbl.elf开 xsct 执行connect targets -set -filter {name ~ *PSU*} rst -system program_flash -f BOOT.BIN -fsbl zynqmp_fsbl.elf -flash_type qspi-x4-single -offset 0 -verify逐项说明参数-f是要写入的镜像-fsbl指定烧写辅助用的 FSBL它会先在 OCM 里跑起来再操作 flash随便给一个别的硬件版本的 FSBL 会导致 GQSPI 初始化错误-flash_type qspi-x4-single表示板子上挂单颗 QSPI、数据线走 x4ZU4EV 板卡常见器件是 Macronix MT25QU128 系列-offset 0是 flash 起始地址BootROM 固定从偏移 0 读镜像-verify写完后读回整片比对强烈建议保留固化比单纯跑功能多花的这几秒非常值。烧写卡在某个百分比不动时先看终端有没有 flash id mismatch 报错再检查 JTAG 频率。不少下载器在 30MHz 下写 QSPI 不稳定降到 15MHz 通常就好了。GUI 对应入口是 Xilinx → Program Flash对话框字段和上面命令一一对应。烧写完成后保持 JTAG 模式把-verify的结果记录成基线后面验证会用到。提示不要把 PL 侧的 AXI Quad SPI 和 PS 侧 GQSPI 混为一谈。BootROM、FSBL 和 U-Boot 的 sf 驱动都走 PS 的 GQSPIbitstream 里例化的 AXI QSPI 就算烧进 flash 也不会参与启动。4.2 拨回 QSPI 启动模式用串口确认完整启动链烧写完不要急着验收先断电把 BOOT_MODE[3:0] 从 0000 拨到 0001QSPI24 单接 115200/8N1 串口重新上电。上电瞬间应观察到 BootROM → FSBL → ATF → U-Boot 的接力日志正常顺序大致是FSBL 打印 Xilinx Zynq MPSoC First Stage Boot Loader 和 Release 版本号PMU 固件打印版本行ATF 打印 NOTICE: BL31 系列信息最后 U-Boot 打印版本号、DDR 容量和 Hit any key to stop autoboot。裸机场景则在 FSBL 日志后直接出现应用自己的打印。看到完整链路后再做一次彻底掉电重启确认不是靠复位残留状态起来的。如果两遍上电行为不一致先查 BOOT_MODE 拨码有没有在重新上电时被误碰再看调试器是否还挂在板子上把 JTAG 链电平拉偏。这一步是固化验收的核心动作直接决定板卡能不能交付产线。4.3 QSPI 器件、24/32 位地址与双片配置的注意点-flash_type必须和板卡 QSPI 实际接法一致三处最容易错单颗 x4 选 qspi-x4-single两颗叠片选 qspi-x4-dual选错后 program_flash 报 flash id mismatch不破坏 flash但白耗一轮排查。BOOT_MODE 0001 对应 24 位地址最大寻址 16MB超过 16MB 的器件要换 0100QSPI32否则 BootROM 和 FSBL 都访问不到高地址区。MT25QU128 是 128Mbit即 16MB用 0001 正好换 256Mbit 器件时记得同步改启动模式和烧写参数。还有一类问题出现在板卡把 QSPI 的片选或时钟接到 PL 侧引脚导致 PS GQSPI 初始化后完全找不到器件。判断方法是在 U-Boot 里跑sf probe能列出 JEDEC ID 说明 PS 链路没问题。ZU4EV 的 GQSPI 引脚全部来自 MIO这个约束在设计评审阶段就要确认软件层面绕不过去。5. 固化完成后的验证动作与不重烧 BOOT.BIN 的在线升级5.1 串口日志分段判读卡在哪一级加载器日志特征所在阶段优先怀疑完全无输出BootROM 之前BOOT_MODE 拨错、QSPI 0 地址为空FSBL Release 行后无后续FSBL 初始化DDR 配置错误、PMUFW 缺失BL31 NOTICE 后卡死ATFU-Boot 分区缺失或 exception_level 错U-Boot 起来后无应用应用加载分区偏移、加载地址不符对照这张小表能省大量时间。比如只出现 FSBL 的 Release 行几乎都是 DDR 初始化失败回 Vivado 检查 DDR 型号、位宽和速率配置常见对应 ddr4 cal 失败BL31 之后卡住先确认 BIF 里 U-Boot 那段属性再确认 flash 里写入的是完整 BOOT.BIN 而不是只含 FSBL 的空壳。5.2 用 U-Boot 的 sf 命令读回 QSPI 做 CRC 校验固化后不能只靠「能启动」判断 flash 内容完好。在 U-Boot 里读回 BOOT.BIN 存放区域算 CRC和第一次烧写验证时的基线比对sf probe sf read 0x1000000 0x0 0x100000 crc32 0x1000000 0x100000sf probe初始化 GQSPI 并识别器件sf read把 0 地址开始的 1MB 数据读到 DDR 的 0x1000000crc32计算该段校验值。把这个值和 4.1 烧写时-verify后记录下的结果比对一致说明 flash 数据链路稳定。这个动作适合写进产线抽检脚本也适合怀疑 flash 老化时快速定位。5.3 只更新应用分区不重烧 BOOT.BIN 的在线升级路径全量重烧 BOOT.BIN 的代价不只是时间长更在于擦除 0 分区的瞬间掉电板子可能彻底起不来。常见做法是把镜像布局固定下来0 地址放 BOOT.BIN0x100000 起放应用或内核与 dtb更新时只擦写数据分区。以 Linux 为例U-Boot 下走网络更新setenv autoload no tftp 0x1000000 image.ub sf probe sf erase 0x100000 0x400000 sf write 0x1000000 0x100000 0x400000tftp把新镜像拉到 DDR前提是 U-Boot 里 ipaddr 和 serverip 已配好sf erase按固定大小擦数据分区sf write写回。分区偏移必须大于实际 BOOT.BIN 尺寸并留出余量否则写入越界后 BootROM 连 FSBL 都可能读不到。裸机场景没有 U-Boot 时最稳妥的方案是启用 FSBL 的 MULTI_BOOT 宏把第二份镜像放到指定偏移启动失败自动回退旧版本该宏默认关闭改动后要重新生成 FSBL 并连同新 BIF 一起固化。JTAG 是永远最保底的恢复手段——只要拨回 0000program_flash 随时能重新救活板卡这也是所有固化操作的第一条逃生通道。本文还有配套的精品资源点击获取
