尧图网页设计 
简介在Zynq SoC平台的Linux开发中由于芯片同时集成ARM Cortex-A9与FPGA驱动与硬件交互复杂调试宏头文件便成为定位问题的利器一份极简压缩包聚焦调试宏头文件设计面向嵌入式驱动开发、系统优化及底层维护人员可在Linux v2.13.6环境下辅助跟踪变量状态与函数调用、检查寄存器及中断处理逻辑、定位性能瓶颈。包内共2个文件包含1个C源程序与1个C源程序整体大小仅2KB却集中呈现了调试宏的编译开关控制、断言处理和自定义日志输出等可复用写法调试宏通常定义在头文件以便多文件共享借助编译选项可灵活开启或关闭调试信息便于在发布版本中优化性能与存储占用非常适合快速阅读并迁移到实际驱动项目中。压缩包内容涉及音频设备驱动与Zynq硬件访问封装开发者可借此理解驱动与硬件交互过程中如何输出关键信息、在条件不满足时终止程序以及自定义宏记录函数执行时间用于性能分析。目前已有191人学习下载无论是刚入门Zynq Linux开发的工程师还是需要精简代码结构、加快驱动排错的老手都能从中得到启发。1. 拿到 zynq.rar_V2 先看这 3 个文件再决定要不要解压做 Zynq 的人收到一个zynq.rar_V2第一反应不是解压而是猜交付物里有什么。V2 通常意味着硬件改过版或者工程迭代过一轮压缩包里大概率是一整套 Zynq Linux 启动文件FSBL、bitstream、U-Boot、内核、设备树甚至还有 .xsa 硬件导出文件。判断这套材料能不能直接上板只需要找三个文件BOOT.BIN、boot.scr、image.ub。三个都在说明构建链路完整解压后做一张 SD 卡就能启动缺任何一个都得从 PetaLinux 重新构建。这篇就把从 rar 解压到 Zynq Linux 上电启动的完整路径写一遍覆盖解包、构建、制卡、烧写和验证。2. 解压与识别Linux 下解开 rar 并确认 Zynq 启动链路文件2.1 用 unar 解压 rar处理中文文件名乱码常见的unrar在处理交付物时有两个痛点一是部分 Windows 侧打包的 rar 用了 GBK 编码文件名解压到 Linux 后中文目录名乱码检索里面文件根本对不上号二是unrar对 rar5 压缩包的支持不稳定。我一般直接用unar它会自动识别文件名编码对 CJK 场景省事很多。安装和解压命令如下# Ubuntu / Debian 系 sudo apt update sudo apt install -y unar unrar p7zip-full # 先列出压缩包内容确认是否有 BOOT.BIN 等关键文件 lsar ./zynq.rar_V2 # 解压到指定目录避免把当前目录搞乱 unar -o ./zynq_v2 ./zynq.rar_V2逻辑说明lsar只列出归档内容不解压适合先确认包内文件是否存在unar -o指定输出目录解压后文件编码会被自动修正。如果老板或者同事传过来的压缩包是分卷zynq.rar_V2.part1这种形式直接解压第一个分卷即可unar 会自动读取后续分卷。参数补充-e可以强制指定编码比如-e GBK但一般不需要自动模式识别失败时再用。2.2 用 file 命令识别 Zynq 启动链路文件解压完之后不要直接拿 Vivado 去烧先用file命令把所有二进制过一遍。Zynq 启动链表里的文件格式各不相同file的输出能直接暴露文件的真实身份防止把 bitstream 当 U-Boot 用。cd ./zynq_v2 file BOOT.BIN boot.scr image.ub u-boot.elf system.bit zynq_fsbl.elf以 Zynq-7020 全流程工程为例输出通常长这样文件file 输出特征在启动链路中的作用zynq_fsbl.elfELF 32-bit LSB executable, ARM, version 1第一级引导初始化 DDR、时钟和 MIOsystem.bitXilinx BIT data可编程逻辑配置PL 侧 bitstreamu-boot.elfELF 32-bit LSB executable, ARM第二级引导负责加载内核BOOT.BINXilinx Bootgen Boot Image三者封装Zynq BootROM 直接加载它boot.scrU-Boot scriptU-Boot 的启动脚本替代交互式命令image.ubFIT Image / uImage打包 kernel dtb有时含 rootfs逻辑说明BOOT.BIN实际是 FSBL、bitstream 和 U-Boot 的封装体由 Bootgen 生成image.ub是 Flattened Image Tree内核、设备树和可选 ramdisk 都在里面。如果file BOOT.BIN输出是 Xilinx Bootgen Boot Image 而不是 data说明这个文件可以被 BootROM 识别如果显示data则多半是部分烧写脚本直接把 BIT 或者 ELF 改名成.bin了这种交付物没法用。2.3 核对目录缺什么文件会导致什么现象对着目录结构检查完整性比逐个打开文件快得多。Zynq Linux 交付物从构建产物到可启动 SD 卡文件关系可以归纳成下面这张对照tree -L 2 ./zynq_v2一个健康的 V2 交付目录应该长这样zynq_v2/ ├── BOOT.BIN ├── boot.scr ├── image.ub ├── zynq_fsbl.elf ├── u-boot.elf ├── system.bit ├── system.dtb └── hw/zynq_v2.xsa检查要点缺BOOT.BINBootROM 无文件可引导串口没有任何输出缺boot.scrU-Boot 起来后停在Hit any key to stop autoboot需要手动输入命令缺image.ubU-Boot 有脚本但 load 不到内核日志停在Wrong Image Format缺.xsa后续想改配置重新构建会非常被动PetaLinux 创建工程没法挂硬件描述。这四个文件里.xsa和BOOT.BIN是硬关联拿到BOOT.BIN没有.xsa也能启动但改不了 FSBL 配置反过来只有.xsa没有BOOT.BIN就得走一遍完整构建流程下一章做这件事。3. PetaLinux 2025.1 生成 boot.bin、boot.scr、image.ub 的命令链3.1 PetaLinux 2025.1 下生成 BOOT.BIN 的完整命令交付物里缺BOOT.BIN或BOOT.BIN版本和 V2 硬件不匹配时直接用 PetaLinux 2025.1 重建是效率最高的路径。PetaLinux 对 Zynq-7020 生成 FSBL 是开箱即用的不需要手动写任何 C 代码前提是拿到.xsa。整个构建链路两端都是 Xilinx 系工具链Vivado 导出.xsaPetaLinux 消费它版本对齐了基本不会出幺蛾子。source /opt/Xilinx/PetaLinux/2025.1/settings.sh petalinux-create --type project --template zynq --name zynq_v2_app cd zynq_v2_app petalinux-config --get-hw-description ../hw/zynq_v2.xsa petalinux-build petalinux-package --boot \ --fsbl ./images/linux/zynq_fsbl.elf \ --fpga ./images/linux/system.bit \ --u-boot ./images/linux/u-boot.elf \ --output ./images/linux/BOOT.BIN逻辑说明petalinux-create --template zynq指定的是 Zynq-7000 家族模板对应 Zynq-7020 没有问题petalinux-config --get-hw-description把硬件描述导入工程FSBL 会按.xsa里的 DDR、MIO、时钟配置生成。参数说明里最需要注意的是--fpga当system.bit需要和 FSBL 一起打包时--boot后面必须显式指定如果 PL 侧没有逻辑省略--fpga可以缩小 BOOT.BIN 体积启动时间也能缩短几十毫秒。同理DDR 初始化参数和 FSBL 里的 PS 配置不匹配时恰好是 BOOT.BIN 不可用的高发原因之一重新打包前务必确认.xsa版本和实际硬件版本一致。表petalinux-package --boot的常用参数参数作用不传会怎样--fsbl指定 FSBL 的 elfBootrom 没有可执行的引导代码卡死在启动--fpga把 PL bitstream 并入 BOOT.BIN逻辑不加载PS 侧 Linux 不受影响--u-boot指定 U-Boot elf无法进入第二级引导--output指定输出文件名默认生成images/linux/BOOT.BIN--offset指定 partition 偏移QSPI 启动时配合 flash 布局使用3.2 手写 boot.cmd 并用 mkimage 生成 boot.scrpetalinux-package --boot只打包 FSBL、bit 和 U-Boot不生成boot.scr。PetaLinux 工程里虽然能看到boot.scr相关工具但最常见、最可控的做法是手写一份boot.cmd再用mkimage转成 U-Boot 脚本。U-Boot 支持脚本文件这个机制是启动链里最灵活的一环想改启动参数、换分区、模拟在线升级场景都要动它。cat boot.cmd EOF setenv bootargs consolettyPS0,115200 root/dev/mmcblk0p2 rw rootfstypeext4 rootwait load mmc 0:1 0x2080000 image.ub bootm 0x2080000 EOF mkimage -A arm -O linux -T script -C none -d boot.cmd boot.scr逻辑说明boot.cmd里第一行是内核命令行consolettyPS0对应 Zynq 的 UART0波特率 115200root/dev/mmcblk0p2指向 SD 卡第二个分区也就是 rootfs 所在的 ext4 分区。load mmc 0:1表示从 SD 卡控制器 0 的 1 号分区加载文件地址0x2080000是 Zynq DDR 里避开 BootROM 和 U-Boot 占用的常规加载地址。bootm 0x2080000从该地址引导 FIT 镜像bootm会自动解析image.ub里的内核、设备树和 ramdisk。mkimage 的参数里-A arm指定 ARM 架构-O linux是操作系统类型-T script表示生成的是脚本而非内核镜像-C none表示不压缩。3.3 image.ub 的自检与 FIT 结构观察image.ub是 PetaLinux 在petalinux-build阶段自动生成的 FIT 镜像它和 BOOT.BIN 的最大区别是BOOT.BIN 是 BootROM 的引导格式FIT 是 U-Boot 的引导格式。拿到交付物之后验证image.ub是否完整最直接的办法是解包看里面有什么。U-Boot 源码的tools/目录下有dumpimage命令安装了u-boot-tools就会自带。dumpimage -l ./image.ub输出里能看到类似下面的结构FIT description: U-Boot fitImage kernel plus DTB Created: Thu Oct 24 10:24:08 2025 Configuration: confzynq-7020 Kernel Image: kernel1 FDT: fdt1逻辑说明Configuration字段给出的是配置名Zynq 工程下一般是confzynq-7020Kernel Image是内核本体FDT是设备树。如果dumpimage -l报错Invalid FIT image说明image.ub损坏或被误改名U-Boot 阶段必然加载失败。这种情况下不要重新打包 BOOT.BIN直接回到petalinux-build重新生成 image.ub 再接petalinux-package。4. Zynq Linux SD 卡制卡、烧写与 FSBL 报错处理4.1 用 sfdisk 脚本给 SD 卡分两个区Zynq Linux 的 SD 启动布局非常固定第一个分区 FAT32放 BOOT.BIN、boot.scr、image.ub第二个分区 ext4放 rootfs。手工用fdisk交互式分区容易误操作交付物验证场景下用脚本一次性搞定更稳执行环境是 Ubuntu 宿主机。# 假设 SD 卡设备节点是 /dev/sdb先确认再执行 lsblk # 清空分区表 sudo wipefs -a /dev/sdb # 用 sfdisk 创建两个分区1G FAT32 剩余空间 ext4 sudo sfdisk /dev/sdb EOF ,1G,c ,,L EOF sudo mkfs.vfat -F 32 -n BOOT /dev/sdb1 sudo mkfs.ext4 -L rootfs /dev/sdb2逻辑说明sfdisk的输入格式里c表示 W95 FAT32 (LBA) 类型L是 Linux 分区。wipefs -a先清掉 SD 卡上遗留的分区签名避免 mkfs 阶段报 superblock 错误。参数说明FAT32 分区大小给 1G 足够image.ub一般不到 30MBBOOT.BIN也就十几 MB留 1G 是为了以后在线升级放多版本文件不成瓶颈ext4 分区用剩余全部空间放 rootfs。分区完成后格式化FAT32 卷标建议用BOOTPetaLinux 的默认 fstab 里有时会引用卷标顺手取个不折腾。挂载后拷贝文件顺序要固定sudo mkdir -p /mnt/boot /mnt/rootfs sudo mount /dev/sdb1 /mnt/boot sudo mount /dev/sdb2 /mnt/rootfs sudo cp BOOT.BIN boot.scr image.ub /mnt/boot/ # 如果交付物带 rootfs 目录解压进去 sudo cp -a rootfs/* /mnt/rootfs/ sync4.2 烧写 BOOT.bin 时报 valid FSBL file 的三种处理交付场景里最容易卡的报错是 Vitis 烧写工具弹出的a valid fsbl file is required for flash operation第一次碰到容易误判为 BOOT.BIN 损坏。这个报错的本质是烧写工具需要用一个 FSBL 来初始化 DDR 和时钟再去擦写 flash而不是直接认你的 BOOT.BIN。# 方法QSPI Flash 模式下显式指定 FSBL 和 BOOT.BIN program_flash -f ./BOOT.BIN \ -fsbl ./zynq_fsbl.elf \ -flash_type qspi-x4-single \ -offset 0参数说明-fsbl指定用于 flash 编程器的 FSBL必须和 BOOT.BIN 中打包的是同一个 elf否则 DDR 参数不一致会在编程过程中随机失败-flash_type按硬件连接选择Zynq-7020 开发板常见的是qspi-x4-single个别板子用qspi-x1-single型号写错报错信息一样。另外两种替代处理一是只检查不烧写用dumpimage -l BOOT.BIN或bootgen -arch zynq -image boot.bif -w -o BOOT.BIN重新生成后再烧二是从 SD 启动直接跳过 flash很多验证工作不必碰 QSPISD 卡启动省掉烧写环节等 system.bit 在 PL 侧验证通过再回烧 QSPI。把 FSBL、bit、U-Boot 的 elf 存好遇到 flash 编程时随手能用。4.3 启动模式拨码与日志断点SD 卡和 QSPI 的启动文件都备好之后拨码设置错误是最隐蔽的上板失败原因。Zynq BootROM 根据 MIO 启动模式引脚选择引导方式开发板上通常是 5 位拨码开关具体对应关系受限于板级设计不存在的拨码组合会导致 BootROM 直接挂死串口不打印任何信息。启动媒体MIO[4:0]开发板常见设置说明SD 卡0b001102、3 拨上其余拨下最常用QSPI0b010101、3 拨上其余拨下回烧后使用JTAG0b00000全部拨下调试时用不会自动启动NAND0b01100视板卡而定部分 7020 板型有拨码错误的表现是上电后串口 115200 无任何输出minicom -D /dev/ttyUSB0一点日志都没有。此时不要怀疑 BOOT.BIN 坏了先核对拨码再查电源指示灯最后看串口接线交叉RX/TX 反接的问题。串口有输出但卡在某一行的断点定位法卡在 FSBL Banner 之前是 BootROM 没找到 BOOT.BIN卡在Hit any key to stop autoboot是 boot.scr 没加载卡在Wrong Image Format是 image.ub 坏了或加载地址不对。5. 上电验证用日志特征和文件校验确认 Zynq Linux 正常启动5.1 串口日志里三个必须看到的特征行验证 Zynq Linux 是否真正起来不用看完整 log三个特征行足够。把 SD 卡插上设置为 SD 启动模式上电串口 115200 captureminicom -D /dev/ttyUSB0 -b 115200第一个必须看到的特征行是Xilinx Zynq FSBL开头的 banner它出现在上电后几百毫秒内表明 BootROM 成功解析了 BOOT.BINFSBL 开始初始化 DDR第二个特征行是 U-Boot 的版本号说明二级引导已接管第三个特征是Starting kernel ...之后出现内核版本字符串说明 kernel 和设备树被正确加载。三个特征行逐级出现整条启动链就是通的。卡在 U-Boot 之前问题在 BOOT.BIN 的 FSBL 或 DDR 时序卡在Starting kernel之后问题在 rootfs 或内核命令行参数。5.2 面向在线升级的 SD 卡文件核对脚本交付物验证和后续升级场景里最容易犯的错误是构建目录里的 image.ub 和 SD 卡上的 image.ub 不是同一版本。手动比对 md5 太费时写一个两行核心的脚本用于升级前确认目标文件一致#!/bin/bash REF_DIR/opt/zynq_v2/images/linux SD_DIR/media/user/BOOT for f in BOOT.BIN boot.scr image.ub; do if cmp -s $REF_DIR/$f $SD_DIR/$f; then echo OK $f else echo DIFF $f fi done逻辑说明cmp -s静默模式只返回状态码不需要md5sum二次处理循环对象固定三个文件升级时只改image.ub的版本即可。脚本输出三行全部OK才允许断电重启只要出现DIFF说明 SD 卡上文件与构建产物不一致。在线升级场景下只有内核和设备树变更时单独拷 image.ub 覆盖 FAT 分区即可BOOT.BIN和boot.scr无需重烧FSBL 和 U-Boot 是 boot 这套耦合的二进制镜像动一个就要重烧整个分区。升级后从串口日志观察U-Boot 2025.01到Starting kernel的间隔再确认两个特征行Zynq Linux 的迭代就闭环了。本文还有配套的精品资源点击获取 Zynq Linux启动文件全解析：从RAR解压到SD卡跑通
简介在Zynq SoC平台的Linux开发中由于芯片同时集成ARM Cortex-A9与FPGA驱动与硬件交互复杂调试宏头文件便成为定位问题的利器一份极简压缩包聚焦调试宏头文件设计面向嵌入式驱动开发、系统优化及底层维护人员可在Linux v2.13.6环境下辅助跟踪变量状态与函数调用、检查寄存器及中断处理逻辑、定位性能瓶颈。包内共2个文件包含1个C源程序与1个C源程序整体大小仅2KB却集中呈现了调试宏的编译开关控制、断言处理和自定义日志输出等可复用写法调试宏通常定义在头文件以便多文件共享借助编译选项可灵活开启或关闭调试信息便于在发布版本中优化性能与存储占用非常适合快速阅读并迁移到实际驱动项目中。压缩包内容涉及音频设备驱动与Zynq硬件访问封装开发者可借此理解驱动与硬件交互过程中如何输出关键信息、在条件不满足时终止程序以及自定义宏记录函数执行时间用于性能分析。目前已有191人学习下载无论是刚入门Zynq Linux开发的工程师还是需要精简代码结构、加快驱动排错的老手都能从中得到启发。1. 拿到 zynq.rar_V2 先看这 3 个文件再决定要不要解压做 Zynq 的人收到一个zynq.rar_V2第一反应不是解压而是猜交付物里有什么。V2 通常意味着硬件改过版或者工程迭代过一轮压缩包里大概率是一整套 Zynq Linux 启动文件FSBL、bitstream、U-Boot、内核、设备树甚至还有 .xsa 硬件导出文件。判断这套材料能不能直接上板只需要找三个文件BOOT.BIN、boot.scr、image.ub。三个都在说明构建链路完整解压后做一张 SD 卡就能启动缺任何一个都得从 PetaLinux 重新构建。这篇就把从 rar 解压到 Zynq Linux 上电启动的完整路径写一遍覆盖解包、构建、制卡、烧写和验证。2. 解压与识别Linux 下解开 rar 并确认 Zynq 启动链路文件2.1 用 unar 解压 rar处理中文文件名乱码常见的unrar在处理交付物时有两个痛点一是部分 Windows 侧打包的 rar 用了 GBK 编码文件名解压到 Linux 后中文目录名乱码检索里面文件根本对不上号二是unrar对 rar5 压缩包的支持不稳定。我一般直接用unar它会自动识别文件名编码对 CJK 场景省事很多。安装和解压命令如下# Ubuntu / Debian 系 sudo apt update sudo apt install -y unar unrar p7zip-full # 先列出压缩包内容确认是否有 BOOT.BIN 等关键文件 lsar ./zynq.rar_V2 # 解压到指定目录避免把当前目录搞乱 unar -o ./zynq_v2 ./zynq.rar_V2逻辑说明lsar只列出归档内容不解压适合先确认包内文件是否存在unar -o指定输出目录解压后文件编码会被自动修正。如果老板或者同事传过来的压缩包是分卷zynq.rar_V2.part1这种形式直接解压第一个分卷即可unar 会自动读取后续分卷。参数补充-e可以强制指定编码比如-e GBK但一般不需要自动模式识别失败时再用。2.2 用 file 命令识别 Zynq 启动链路文件解压完之后不要直接拿 Vivado 去烧先用file命令把所有二进制过一遍。Zynq 启动链表里的文件格式各不相同file的输出能直接暴露文件的真实身份防止把 bitstream 当 U-Boot 用。cd ./zynq_v2 file BOOT.BIN boot.scr image.ub u-boot.elf system.bit zynq_fsbl.elf以 Zynq-7020 全流程工程为例输出通常长这样文件file 输出特征在启动链路中的作用zynq_fsbl.elfELF 32-bit LSB executable, ARM, version 1第一级引导初始化 DDR、时钟和 MIOsystem.bitXilinx BIT data可编程逻辑配置PL 侧 bitstreamu-boot.elfELF 32-bit LSB executable, ARM第二级引导负责加载内核BOOT.BINXilinx Bootgen Boot Image三者封装Zynq BootROM 直接加载它boot.scrU-Boot scriptU-Boot 的启动脚本替代交互式命令image.ubFIT Image / uImage打包 kernel dtb有时含 rootfs逻辑说明BOOT.BIN实际是 FSBL、bitstream 和 U-Boot 的封装体由 Bootgen 生成image.ub是 Flattened Image Tree内核、设备树和可选 ramdisk 都在里面。如果file BOOT.BIN输出是 Xilinx Bootgen Boot Image 而不是 data说明这个文件可以被 BootROM 识别如果显示data则多半是部分烧写脚本直接把 BIT 或者 ELF 改名成.bin了这种交付物没法用。2.3 核对目录缺什么文件会导致什么现象对着目录结构检查完整性比逐个打开文件快得多。Zynq Linux 交付物从构建产物到可启动 SD 卡文件关系可以归纳成下面这张对照tree -L 2 ./zynq_v2一个健康的 V2 交付目录应该长这样zynq_v2/ ├── BOOT.BIN ├── boot.scr ├── image.ub ├── zynq_fsbl.elf ├── u-boot.elf ├── system.bit ├── system.dtb └── hw/zynq_v2.xsa检查要点缺BOOT.BINBootROM 无文件可引导串口没有任何输出缺boot.scrU-Boot 起来后停在Hit any key to stop autoboot需要手动输入命令缺image.ubU-Boot 有脚本但 load 不到内核日志停在Wrong Image Format缺.xsa后续想改配置重新构建会非常被动PetaLinux 创建工程没法挂硬件描述。这四个文件里.xsa和BOOT.BIN是硬关联拿到BOOT.BIN没有.xsa也能启动但改不了 FSBL 配置反过来只有.xsa没有BOOT.BIN就得走一遍完整构建流程下一章做这件事。3. PetaLinux 2025.1 生成 boot.bin、boot.scr、image.ub 的命令链3.1 PetaLinux 2025.1 下生成 BOOT.BIN 的完整命令交付物里缺BOOT.BIN或BOOT.BIN版本和 V2 硬件不匹配时直接用 PetaLinux 2025.1 重建是效率最高的路径。PetaLinux 对 Zynq-7020 生成 FSBL 是开箱即用的不需要手动写任何 C 代码前提是拿到.xsa。整个构建链路两端都是 Xilinx 系工具链Vivado 导出.xsaPetaLinux 消费它版本对齐了基本不会出幺蛾子。source /opt/Xilinx/PetaLinux/2025.1/settings.sh petalinux-create --type project --template zynq --name zynq_v2_app cd zynq_v2_app petalinux-config --get-hw-description ../hw/zynq_v2.xsa petalinux-build petalinux-package --boot \ --fsbl ./images/linux/zynq_fsbl.elf \ --fpga ./images/linux/system.bit \ --u-boot ./images/linux/u-boot.elf \ --output ./images/linux/BOOT.BIN逻辑说明petalinux-create --template zynq指定的是 Zynq-7000 家族模板对应 Zynq-7020 没有问题petalinux-config --get-hw-description把硬件描述导入工程FSBL 会按.xsa里的 DDR、MIO、时钟配置生成。参数说明里最需要注意的是--fpga当system.bit需要和 FSBL 一起打包时--boot后面必须显式指定如果 PL 侧没有逻辑省略--fpga可以缩小 BOOT.BIN 体积启动时间也能缩短几十毫秒。同理DDR 初始化参数和 FSBL 里的 PS 配置不匹配时恰好是 BOOT.BIN 不可用的高发原因之一重新打包前务必确认.xsa版本和实际硬件版本一致。表petalinux-package --boot的常用参数参数作用不传会怎样--fsbl指定 FSBL 的 elfBootrom 没有可执行的引导代码卡死在启动--fpga把 PL bitstream 并入 BOOT.BIN逻辑不加载PS 侧 Linux 不受影响--u-boot指定 U-Boot elf无法进入第二级引导--output指定输出文件名默认生成images/linux/BOOT.BIN--offset指定 partition 偏移QSPI 启动时配合 flash 布局使用3.2 手写 boot.cmd 并用 mkimage 生成 boot.scrpetalinux-package --boot只打包 FSBL、bit 和 U-Boot不生成boot.scr。PetaLinux 工程里虽然能看到boot.scr相关工具但最常见、最可控的做法是手写一份boot.cmd再用mkimage转成 U-Boot 脚本。U-Boot 支持脚本文件这个机制是启动链里最灵活的一环想改启动参数、换分区、模拟在线升级场景都要动它。cat boot.cmd EOF setenv bootargs consolettyPS0,115200 root/dev/mmcblk0p2 rw rootfstypeext4 rootwait load mmc 0:1 0x2080000 image.ub bootm 0x2080000 EOF mkimage -A arm -O linux -T script -C none -d boot.cmd boot.scr逻辑说明boot.cmd里第一行是内核命令行consolettyPS0对应 Zynq 的 UART0波特率 115200root/dev/mmcblk0p2指向 SD 卡第二个分区也就是 rootfs 所在的 ext4 分区。load mmc 0:1表示从 SD 卡控制器 0 的 1 号分区加载文件地址0x2080000是 Zynq DDR 里避开 BootROM 和 U-Boot 占用的常规加载地址。bootm 0x2080000从该地址引导 FIT 镜像bootm会自动解析image.ub里的内核、设备树和 ramdisk。mkimage 的参数里-A arm指定 ARM 架构-O linux是操作系统类型-T script表示生成的是脚本而非内核镜像-C none表示不压缩。3.3 image.ub 的自检与 FIT 结构观察image.ub是 PetaLinux 在petalinux-build阶段自动生成的 FIT 镜像它和 BOOT.BIN 的最大区别是BOOT.BIN 是 BootROM 的引导格式FIT 是 U-Boot 的引导格式。拿到交付物之后验证image.ub是否完整最直接的办法是解包看里面有什么。U-Boot 源码的tools/目录下有dumpimage命令安装了u-boot-tools就会自带。dumpimage -l ./image.ub输出里能看到类似下面的结构FIT description: U-Boot fitImage kernel plus DTB Created: Thu Oct 24 10:24:08 2025 Configuration: confzynq-7020 Kernel Image: kernel1 FDT: fdt1逻辑说明Configuration字段给出的是配置名Zynq 工程下一般是confzynq-7020Kernel Image是内核本体FDT是设备树。如果dumpimage -l报错Invalid FIT image说明image.ub损坏或被误改名U-Boot 阶段必然加载失败。这种情况下不要重新打包 BOOT.BIN直接回到petalinux-build重新生成 image.ub 再接petalinux-package。4. Zynq Linux SD 卡制卡、烧写与 FSBL 报错处理4.1 用 sfdisk 脚本给 SD 卡分两个区Zynq Linux 的 SD 启动布局非常固定第一个分区 FAT32放 BOOT.BIN、boot.scr、image.ub第二个分区 ext4放 rootfs。手工用fdisk交互式分区容易误操作交付物验证场景下用脚本一次性搞定更稳执行环境是 Ubuntu 宿主机。# 假设 SD 卡设备节点是 /dev/sdb先确认再执行 lsblk # 清空分区表 sudo wipefs -a /dev/sdb # 用 sfdisk 创建两个分区1G FAT32 剩余空间 ext4 sudo sfdisk /dev/sdb EOF ,1G,c ,,L EOF sudo mkfs.vfat -F 32 -n BOOT /dev/sdb1 sudo mkfs.ext4 -L rootfs /dev/sdb2逻辑说明sfdisk的输入格式里c表示 W95 FAT32 (LBA) 类型L是 Linux 分区。wipefs -a先清掉 SD 卡上遗留的分区签名避免 mkfs 阶段报 superblock 错误。参数说明FAT32 分区大小给 1G 足够image.ub一般不到 30MBBOOT.BIN也就十几 MB留 1G 是为了以后在线升级放多版本文件不成瓶颈ext4 分区用剩余全部空间放 rootfs。分区完成后格式化FAT32 卷标建议用BOOTPetaLinux 的默认 fstab 里有时会引用卷标顺手取个不折腾。挂载后拷贝文件顺序要固定sudo mkdir -p /mnt/boot /mnt/rootfs sudo mount /dev/sdb1 /mnt/boot sudo mount /dev/sdb2 /mnt/rootfs sudo cp BOOT.BIN boot.scr image.ub /mnt/boot/ # 如果交付物带 rootfs 目录解压进去 sudo cp -a rootfs/* /mnt/rootfs/ sync4.2 烧写 BOOT.bin 时报 valid FSBL file 的三种处理交付场景里最容易卡的报错是 Vitis 烧写工具弹出的a valid fsbl file is required for flash operation第一次碰到容易误判为 BOOT.BIN 损坏。这个报错的本质是烧写工具需要用一个 FSBL 来初始化 DDR 和时钟再去擦写 flash而不是直接认你的 BOOT.BIN。# 方法QSPI Flash 模式下显式指定 FSBL 和 BOOT.BIN program_flash -f ./BOOT.BIN \ -fsbl ./zynq_fsbl.elf \ -flash_type qspi-x4-single \ -offset 0参数说明-fsbl指定用于 flash 编程器的 FSBL必须和 BOOT.BIN 中打包的是同一个 elf否则 DDR 参数不一致会在编程过程中随机失败-flash_type按硬件连接选择Zynq-7020 开发板常见的是qspi-x4-single个别板子用qspi-x1-single型号写错报错信息一样。另外两种替代处理一是只检查不烧写用dumpimage -l BOOT.BIN或bootgen -arch zynq -image boot.bif -w -o BOOT.BIN重新生成后再烧二是从 SD 启动直接跳过 flash很多验证工作不必碰 QSPISD 卡启动省掉烧写环节等 system.bit 在 PL 侧验证通过再回烧 QSPI。把 FSBL、bit、U-Boot 的 elf 存好遇到 flash 编程时随手能用。4.3 启动模式拨码与日志断点SD 卡和 QSPI 的启动文件都备好之后拨码设置错误是最隐蔽的上板失败原因。Zynq BootROM 根据 MIO 启动模式引脚选择引导方式开发板上通常是 5 位拨码开关具体对应关系受限于板级设计不存在的拨码组合会导致 BootROM 直接挂死串口不打印任何信息。启动媒体MIO[4:0]开发板常见设置说明SD 卡0b001102、3 拨上其余拨下最常用QSPI0b010101、3 拨上其余拨下回烧后使用JTAG0b00000全部拨下调试时用不会自动启动NAND0b01100视板卡而定部分 7020 板型有拨码错误的表现是上电后串口 115200 无任何输出minicom -D /dev/ttyUSB0一点日志都没有。此时不要怀疑 BOOT.BIN 坏了先核对拨码再查电源指示灯最后看串口接线交叉RX/TX 反接的问题。串口有输出但卡在某一行的断点定位法卡在 FSBL Banner 之前是 BootROM 没找到 BOOT.BIN卡在Hit any key to stop autoboot是 boot.scr 没加载卡在Wrong Image Format是 image.ub 坏了或加载地址不对。5. 上电验证用日志特征和文件校验确认 Zynq Linux 正常启动5.1 串口日志里三个必须看到的特征行验证 Zynq Linux 是否真正起来不用看完整 log三个特征行足够。把 SD 卡插上设置为 SD 启动模式上电串口 115200 captureminicom -D /dev/ttyUSB0 -b 115200第一个必须看到的特征行是Xilinx Zynq FSBL开头的 banner它出现在上电后几百毫秒内表明 BootROM 成功解析了 BOOT.BINFSBL 开始初始化 DDR第二个特征行是 U-Boot 的版本号说明二级引导已接管第三个特征是Starting kernel ...之后出现内核版本字符串说明 kernel 和设备树被正确加载。三个特征行逐级出现整条启动链就是通的。卡在 U-Boot 之前问题在 BOOT.BIN 的 FSBL 或 DDR 时序卡在Starting kernel之后问题在 rootfs 或内核命令行参数。5.2 面向在线升级的 SD 卡文件核对脚本交付物验证和后续升级场景里最容易犯的错误是构建目录里的 image.ub 和 SD 卡上的 image.ub 不是同一版本。手动比对 md5 太费时写一个两行核心的脚本用于升级前确认目标文件一致#!/bin/bash REF_DIR/opt/zynq_v2/images/linux SD_DIR/media/user/BOOT for f in BOOT.BIN boot.scr image.ub; do if cmp -s $REF_DIR/$f $SD_DIR/$f; then echo OK $f else echo DIFF $f fi done逻辑说明cmp -s静默模式只返回状态码不需要md5sum二次处理循环对象固定三个文件升级时只改image.ub的版本即可。脚本输出三行全部OK才允许断电重启只要出现DIFF说明 SD 卡上文件与构建产物不一致。在线升级场景下只有内核和设备树变更时单独拷 image.ub 覆盖 FAT 分区即可BOOT.BIN和boot.scr无需重烧FSBL 和 U-Boot 是 boot 这套耦合的二进制镜像动一个就要重烧整个分区。升级后从串口日志观察U-Boot 2025.01到Starting kernel的间隔再确认两个特征行Zynq Linux 的迭代就闭环了。本文还有配套的精品资源点击获取