最近在折腾一块基于 Zynq UltraScale MPSoCzynqMP的自研 PCB dev-board从画板、贴片、上电到最终把 PetaLinux 跑起来整个过程断断续续花了三个多月。中间踩过的坑多到可以写一本书尤其是设备树、启动镜像、DDR 初始化这类跟自定义硬件强相关的东西官方开发板的现成资料基本都用不上每一步都得自己来。这块板子不是厂商公板而是完全根据项目需求定制的主芯片选了 Zynq UltraScale 系列的某个型号板载 DDR4、eMMC、QSPI Flash、千兆以太网还扩展了几路自定义 GPIO 和 I2C 外设。硬件方案定下来之后软件这边就面临一个核心问题没有官方 BSP所有东西都要从零搭建。这篇博文就把这套基于 Vivado PetaLinux 的自定义 zynqMP 开发板软件平台搭建过程完整拆开讲一遍包括硬件工程怎么建、XSA 怎么导、PetaLinux 工程怎么创建、设备树怎么改、启动镜像怎么打包以及那些常规文档里根本不会写的问题排查经验。适合手里正好有自定义 zynqMP 板子要调 Linux 的朋友也适合准备从公板转向自研板、想提前了解流程的嵌入式开发者。1. 项目整体设计与方案拆解1.1 自定义开发板为什么不能直接抄官方 BSP很多人第一次接触 zynqMP 都是用 UltraZed、ZCU104 这类官方或者第三方公板厂商会提供一个编译好的 PetaLinux BSP跑petalinux-create -t project -s就把整个工程拉下来了设备树、u-boot 配置、内核补丁全是现成的拿来就能用。但自定义 PCB 是完全另一码事。板子上的 DDR 型号、PHY 芯片、时钟源、外设地址映射、GPIO 分配甚至电源上电时序都可能和公板不一样。BSP 里固化的那些初始化代码和 dts 节点在自研板上可能有一半是不对的。最典型的就是 DDR公板的 DDR 颗粒是某款特定型号初始化参数写死在 FSBL 的 psu_init 里你换了一款不同容量的 DDR4时序参数对不上内存训练过不了系统直接卡死在启动早期连 u-boot 都进不去。所以自定义板子的核心思路就一句话从 Vivado 硬件工程开始把整个软件栈都建立在自己的硬件描述之上。这不是额外的工作量而是绕不开的必经之路。官方工具链本身是支持这种“半定制”流程的Vivado 负责生成硬件描述文件 XSAPetaLinux 吃进 XSA 后自动生成第一版软件工程然后你再基于自己的板子做裁剪和修改。1.2 工具链选型Vivado PetaLinux 的组合逻辑zynqMP 的软件方案其实有好几条路纯 u-boot 手动编内核 手写设备树或者用 Yocto 自己拉全套再或者直接用 Vitis 自带的轻量方案。我最终选了 Vivado PetaLinux原因是这套组合跟 Zynq 系列的硬件绑定最紧密XSA 机制能自动同步硬件配置到软件工程省掉了大量手工对齐的工作量。举一个具体的例子你在 Vivado 里给 PS 端配置了一个 UART1地址是 0xFF010000中断号是 54那么在导出 XSA 并导入 PetaLinux 后PetaLinux 自动生成的设备树里就会带上这个节点中断号、地址、时钟都是对齐的不需要你手工去查 TRM。这套流程之所以顺关键在 XSAXilinx Support Archive这个中间产物。它把硬件信息、PS 配置、外设 IP、地址映射、DDR 初始化参数全部打包在一个文件里。PetaLinux 的--get-hw-description指令会自动解析这个文件生成对应的设备树、u-boot 配置以及 FSBL 源码。可以说XSA 是软硬件之间的桥梁也是这个项目最重要的单一交付物。1.3 整体流程拆分和工作目录规划整个项目可以拆成三个大的阶段Vivado 硬件工程阶段、PetaLinux 软件工程阶段、烧写与调试阶段。硬件这边产出的是比特流和 XSA软件这边产出的是 BOOT.BIN 和 image.ub最后烧进板子启动。我建议从一开始就把目录结构规划好别东一榔头西一棒子否则后期版本管理会非常痛苦。推荐这样的目录布局zynqmp-custom-board/ ├── vivado/ │ ├── block_design/ │ ├── constraints/ │ └── outputs/ │ └── zynqmp_custom.xsa ├── petalinux/ │ └── zynqmp-custom-project/ └── images/ ├── BOOT.BIN └── image.ub这样做的目的很简单Vivado 工程和 PetaLinux 工程相互独立PetaLinux 工程不直接引用 Vivado 工程文件只用 XSA 作为输入。任何一方的改动都通过重新导出/导入 XSA 来同步避免两边文件交叉引用导致的不一致问题。2. 硬件平台搭建Vivado 工程从创建到导出2.1 创建 Vivado 工程与 Block Design新建 Vivado 工程时芯片型号一定要选对。zynqMP 家族里不同型号的资源差异很大比如 XCZU7EV 带 GPU、VCUXCZU3EG 相对精简选错型号会导致后续实现阶段各种资源不够或者 IP 无法例化。我是直接在 Vivado 的Create New Project里选择了板子上实际贴的那颗芯片这一步没什么技巧就是细心。进入工程后用 IP Integrator 创建 Block Design把 Zynq UltraScale MPSoC 这个 IP 拖进来。双击 IP 打开Re-customize IP进入 PS-PL Configuration这里有几个关键配置要对着自己的 PCB 原理图逐项核对PS-PL 接口根据实际连接到 PL 的外设勾选对应的 AXI、EMIO、GPIO、SPI、I2C 等接口不用的接口尽量关掉可以省 PL 资源也能减少后续设备树的冗余节点。时钟配置PS 端的参考时钟输入频率必须和板子上晶振一致。zynqMP 的 PS 参考时钟通常是 33.33MHz 或 50MHz设错了会导致 PLL 分频算出来的核心频率完全对不上。Vivado 的 GUI 里有时钟树预览可以直观看到最终 CPU 和 DDR 的时钟频率。DDR 配置这一步是整个硬件工程里最容易出错的地方。必须严格按 DDR4 颗粒的 datasheet 设置容量、位宽、Bank Group、突发长度和时序参数。DDR 初始化时序参数如果不对轻则内存训练失败重则启动时直接 hang 住或随机死机。这里建议对照 PCB 上实际贴的内存颗粒型号逐项核对容量和速度等级。Block Design 里还添加了几个自定义外设比如一个 AXI GPIO IP 用来控制板子上的几个 LED 和一个复位逻辑一路 AXI I2C 用来和板载传感器通信。添加 AXI 外设时需要注意地址分配Vivado 会自动给 AXI 互联分配地址但建议在 Address Editor 里把地址区间改成一个有意义的大段比如 0xA0000000 这段留给自定义寄存器方便后续在设备树里映射时一眼认出是什么外设。2.2 约束文件里那些容易忽略的坑zynqMP 这类 MPSoC 的 PCB dev-boardPL 部分约束通常不是最复杂的因为大部分引脚走的是 PS 的专用引脚不经过 PL。但如果你像我一样在 PL 端挂了一些外设约束文件就非常关键了。我这次遇到的第一个大坑是 LED 的引脚约束PCB 上 LED 接到了 PL 端的某个 Bank但这个 Bank 的 VCCO 电压只有 1.5V而 Vivado 默认的 IO 标准如果是 LVCMOS18综合虽然能过但实现阶段会因为引脚电压不匹配而报警。这个问题的正确解法是在约束文件里手写set_property IOSTANDARD LVCMOS15并且确认 Bank 的供电电压和 PCB 一致。另一个点是时钟约束。PL 端如果有时钟输入必须在约束文件里为这个时钟创建 Primary Clock否则时序分析会把它当成异步时钟绕射严重极可能导致时序收敛不了。我是用板子上一个 125MHz 的差分时钟作为 PL 端以太网和逻辑参考时钟在约束里用create_clock声明了时钟源和频率后续走线才能正常完成时序收敛。综合实现这块我的建议是第一次跑就老老实实看 Timing Summary。很多人养成错误习惯只关心有没有 Timing Violation不看具体是哪条路径违例。自研板的时序问题十有八九是约束漏了或者 IO 标准设置错误这类问题如果不解决硬件跑起来就是各种诡异现象寄存器偶尔跳变、中断丢、外设偶发超时。我这次就花了整整一个晚上排查一个 AXI GPIO 不定时“丢失中断”的问题最终定位是时序违例导致寄存器采样亚稳态。这个教训很深刻。2.3 比特流生成失败的排查思路Vivado 生成比特流失败在自定义板子上出现概率很高但原因通常比较集中。我整理了这次遇到的几类情况和对应排查方法综合阶段 CRC error 或 1600 系列错误这类错误大多跟工程目录路径有关。Vivado 对中文路径和多级超长路径的兼容性一直不好。我这次一开始把工程放在D:\硬件开发\zynqmp_custom_board_v1.0_final_2024这种目录下综合时直接报了 FATAL ERROR。把工程挪到纯英文、短路径的D:\fpga\zcu7_final后问题消失。这就是网传“Vivado 中文路径会出问题”的真实原因。实现阶段 Placement 失败Block Design 里的 IP 布局冲突。解法是先跑 Logic Optimization再重新 Place Design如果还是失败就要检查是不是 PL 资源占用率过高。zynqMP 的 LUT、FF 资源虽然多但如果你在 Block Design 里添加了过多 LED、GPIO、中断控制器很容易把某个 Slice 区域的布线资源挤爆。Bitgen 阶段 DRC 错误比如没接输入时钟、IO 标准不匹配等。Vivado 会给你一份详细的 DRC 报告我最常见的解决动作是打开 Report DRC 面板按 Error 严重程度排序先把最顶上的几条解决掉大部分情况下问题可以直接定位到具体引脚。比特流最终生成成功后需要同时导出两个东西比特流文件和 XSA 文件。XSA 的导出路径是File - Export Hardware勾选Include bitstream。这一步非常关键因为如果 XSA 里没有包含比特流后续 PetaLinux 打包 BOOT.BIN 的时候就会缺少 FPGA 的比特流导致 PL 端的逻辑在 Linux 启动后完全不起作用。我第一版就忘了勾这个选项后面 PetaLinux 启动了半天AXI GPIO 读写全量返回 0最后重新导出 XSA 才解决。3. 定制软件栈PetaLinux 工程从创建到启动镜像3.1 创建 PetaLinux 工程并导入 XSAPetaLinux 的版本必须和 Vivado 版本严格匹配这个没得商量。Vivado 2020.2 对应 PetaLinux 2020.2Vivado 2023.1 对应 PetaLinux 2023.1混搭会在导入 XSA 时报各种莫名其妙的解析错误。安装 PetaLinux 时建议直接source对应的settings.sh确保环境变量一致。创建工程和导入硬件描述的命令是# 创建工程 petalinux-create -t project -n zynqmp-custom-board --template zynqMP # 导入 XSA cd zynqmp-custom-board petalinux-config --get-hw-description../../vivado/outputs/zynqmp_custom.xsa执行petalinux-config后工具会自动解析 XSA 中的硬件信息并在project-spec/meta-user/recipes-bsp/device-tree/files/下生成一个默认的system-user.dtsi文件。这个文件就是你做设备树定制的主战场。同时PetaLinux 还会自动根据硬件配置生成 PL 端的设备树覆盖层那些在 Block Design 里添加的 AXI IP会在这个阶段自动生成对应的设备树节点。有一点需要特别留意PetaLinux 自动生成的设备树是基于 Vivado 工程里的“规范化”命名和地址生成的不一定完全符合你 PCB 上的实际外设映射。比如 Block Design 里分配的 AXI GPIO 地址是 0xA0000000设备树里会生成对应 node但这些 node 的 compatible 属性、中断号等往往需要手动微调才能真正让驱动正确 probe。3.2 设备树定制让内核真正认识你的板子设备树是这块自研板调试中耗时最多的部分。PetaLinux 生成的基础设备树能保证系统起来但要让板上所有外设都工作必须自己改system-user.dtsi。我用一个实例来说明。板子上有一颗 LM75 温度传感器挂在一路 I2C 总线上I2C 控制器用的是 PS 端的 I2C1地址是 0xFF030000。PetaLinux 基础设备树里已经有 I2C1 节点了但里面没有传感器子节点所以内核不会自动 probe LM75。我在system-user.dtsi里追加内容#include dt-bindings/interrupt-controller/arm-gic.h #include dt-bindings/gpio/gpio.h / { leds { compatible gpio-leds; led-red { label led-red; gpios axi_gpio_0 0 0 GPIO_ACTIVE_HIGH; }; }; }; i2c1 { status okay; lm7548 { compatible national,lm75; reg 0x48; }; };这段代码的含义是告诉内核在 I2C1 总线上地址 0x48 处有一个 LM75 传感器。这里有个非常关键的细节就是 I2C 地址。第一版我把 LM75 的地址写成了 0x4F结果驱动一直 probe 失败读 I2C 总线上设备地址时才发现 LM75 的 A0-A2 引脚硬件上全部接地实际地址是 0x48。这类硬件细节只能通过排查定位设备树文件本身不会告诉你。自定义 GPIO 的节点同样容易出错。zynqMP 的 PS 端 GPIO 在设备树里对应的是gpio节点但如果你用 AXI GPIO那就是另一个 IP。两者在gpios属性的 phandle 引用上完全不同。很多新手会把 AXI GPIO 的中断号写错。我踩过的坑是ATO GPIO IP 在 Vivado 里配置了中断输出但设备树里没有添加interrupt-parent和interrupts属性导致 GPIO 中断在 Linux 里面完全没有反应。正确写法是参考自动生成的 axi-gpio 节点手动补充中断属性。设备树的调试方法很简单在 u-boot 阶段用fdt print查看当前设备树在 Linux 里用/proc/device-tree查看实际加载的设备树。每次修改system-user.dtsi后需要重新petalinux-build并打包镜像但增量编译很快几分钟内就能拿到新的镜像测试。3.3 内核、u-boot 和根文件系统的个性化配置PetaLinux 默认的内核配置对自定义板子来说远远不够至少需要进入内核配置界面做几件事。petalinux-config -c kernel我的建议优先级如下首先确认架构是 ARM64然后确认有CONFIG_I2C、CONFIG_GPIO_SYSFS并把CONFIG_SENSORS_LM75编成模块。如果你的板子有以太网确认对应的 PHY 驱动已经编译进去这一步经常被忽略因为 PHY 芯片的驱动不是内核对 mac 地址的映射能解决的必须通过设备树里的phy-mode和phy-handle来关联。u-boot 配置同样重要。petalinux-config -c u-bootzynqMP 的 u-boot 主要关注两件事一个是启动介质SD、QSPI、eMMC另一个是环境变量。默认 u-boot 支持从 SD 卡启动但如果你板子是 eMMC 启动就需要调整启动设备。我在这个阶段就踩了一个典型的坑默认 u-boot 的 bootcmd 写的是mmc dev 0但如果板子只有 eMMC 没有 SD 插槽设备号对不上启动时 u-boot 会一直等 SD 卡超时然后掉进 u-boot shell。根文件系统这边如果只是调板子建议选最小化 rootfs 或者直接用 initramfs可以省掉一大部分构建时间。但如果是生产级项目还是建议用 SD 卡或者 eMMC 上放完整 rootfs把/etc、/user这些目录真实落盘方便后期调试驱动。3.4 全量构建与启动镜像打包硬件和软件配置都改完之后执行全量构建petalinux-build如果过程中报错优先看build/目录下的日志文件。最常见的错误是内核编译时缺少依赖或者设备树语法错误。设备树语法错误是构建阶段最容易遇到的一个分号遗漏就可能导致整个编译失败但日志里会明确给出 dts 文件的语法错误位置改起来很快。构建成功后打包启动镜像petalinux-package --boot --fsbl --fpga --u-boot --force petalinux-package --image --format IF --output images/linux/image.ub第一条命令生成 BOOT.BIN里面按顺序包含 FSBL、PMU 固件、FPGA 比特流、u-boot。第二条命令生成 image.ub里面包含内核、设备树和根文件系统。BOOT.BIN 和 image.ub 合在一起就是一整套 zynqMP 的标准 Linux 启动介质。打包时有一个容易忽略的参数--dtb。如果你手动修改过设备树或者有多套设备树需要切换到不同板型一定要用--dtb参数指定要打包的 dtb 文件。我在给不同 PCB 版本调试时就经常切换不同的 dtsi如果不显式指定image.ub 里打包的可能还是旧设备树。4. 烧写、启动与硬件调试实录4.1 SD 卡启动方案zynqMP 平台调试期最常用的启动方式就是 SD 卡。启动模式由硬件上的 mode 引脚BOOT_MODE[3:0]决定要在板子上拨到 SD 模式。SD 卡的分区格式很简单第一分区放 BOOT.BIN 和 image.ub第二分区放 rootfs 的压缩镜像或者解压好的 rootfs 目录。实际操作时我自己总结了一套效率比较高的脚本sudo dd if/dev/zero of/dev/sdc bs1M count8 sudo parted /dev/sdc mklabel gpt sudo parted /dev/sdc mkpart boot fat32 1MiB 128MiB sudo parted /dev/sdc mkpart rootfs ext4 128MiB 100% sudo mkfs.vfat /dev/sdc1 sudo mkfs.ext4 /dev/sdc2 sudo mount /dev/sdc1 /mnt/boot sudo cp images/BOOT.BIN /mnt/boot/ sudo cp images/image.ub /mnt/boot/ sudo mount /dev/sdc2 /mnt/rootfs sudo tar -xzf rootfs.tar.gz -C /mnt/rootfs sync这样做的逻辑是BOOT.BIN 和 image.ub 走 fat32 文件系统u-boot 可以直接读取rootfs 用 ext4 落盘文件系统可读写。这个方案在调试阶段既灵活又容易回滚。4.2 启动过程日志分析从 BOOT.BIN 到 Linux shell第一次启动自研 zynqMP 板子时串口输出就是唯一的生命线。我把 GDB 调试功底搬过来用串口日志一段一段地判断系统跑到哪一步了。启动日志分几个阶段FSBL 阶段输出Xilinx Zynq MP First Stage Boot Loader然后开始初始化 DDR、PMU、时钟。如果卡在这里大概率是 DDR 初始化参数错误或者 PMU 固件版本不匹配。正常启动需要能看到DDR init completed和一系列Running ...提示。ATF 阶段输出NOTICE: BL31: v2.x之类的信息这是 ARM Trusted Firmware 在运行。这一阶段卡住的常见原因是 ATF 没有适配板子的 DDR 配置。u-boot 阶段输出U-Boot 2020.xx以及板级信息然后进入倒计时等待按键中断。如果卡在这里检查bootcmd环境变量和启动介质是否挂载正确。内核阶段先是Starting kernel ...然后瞬间跳到内核日志。如果卡在Starting kernel之后没有任何输出通常是内存配置问题或者设备树和内核不匹配。我自己在调试中最害怕看到的现象是“卡在启动早期且无任何提示”——这种问题往往需要回退到 FSBL 阶段用 XSDB 和 JTAG 调试器单步跑 FSBL看它到底卡在哪个函数。4.3 JTAG 与 Vivado Hardware Manager 的联合调试zynqMP 板子上的 JTAG 调试在硬件平台搭建阶段几乎就是标配。Vivado Hardware Manager 里连接上 FTDI JTAG 后可以直接下载比特流并读取 PS 寄存器诊断 DDR 训练结果。一个比较推荐的流程是先用 JTAG 把比特流加载到 PL然后打开Hardware Manager里的Vivado Serial Terminal在 u-boot 阶段打断手动执行md命令读 DDR 地址验证内存读写是否正常。这一步调试非常高效如果md 0x0能显示出模式化数据说明 DDR 读写正常就可以放心加载内核。不过 JTAG 调试有个细节如果你的板子上有多个菊花链设备比如 FPGA 外部调试芯片需要在 Vivado 的 Hardware Manager 里手动配置扫描链。我的板子一开始只能识别到主芯片排查了半天才发现调试器连接座子上的一根信号线虚焊重新补焊后扫描链就正常了。这类问题画 PCB 的时候其实很难预判只能靠调试经验摸索。5. 常见问题与避坑指南5.1 Vivado 安装、License 与工程管理的常见问题开发自研 zynqMP 板Vivado 这个工具的稳定运行是第一前提。但 Vivado 本身就是个多坑软件我用过的版本从 2018.3 到 2023.1每个版本都遇到过安装和运行问题。最常见的安装问题是 WinPcap 安装失败和 Java 运行时错误。Vivado 安装时会自动安装 WinPcap 用于网络相关的 IP 调试如果失败并不会中断主安装但后续使用某些调试功能时会报错。解决方法是手动下载 WinPcap 或者 Npcap 安装安装后重启。Java 运行时错误a fatal error has been detected by the Java Runtime Environment多发于启动 Vivado 时。这类问题通常跟系统 JDK 环境变量有关系可以尝试在启动 Vivado 前清除JAVA_HOME或者安装 Vivado 自带的 JREunset JAVA_HOME vivadoLicense 问题也是重灾区。zynqMP 系列如果只做开发调试用评估版 license 就够但要注意评估版有器件支持限制。如果综合时报Security: Unsupported device就是 license 不支持当前器件。解决办法是到官方申请对应器件的评估 license然后把 license 文件路径配置到 Vivado 的 License Manager 中。别去网上找什么杂七杂八的 license稳定性完全不行还可能被植入恶意脚本。工程管理这块我强烈建议用 Tcl 脚本管理 Vivado 工程而不是只在 GUI 里操作。用 Tcl 脚本最大的优势是版本控制友好一个几百行的 Tcl 脚本可以在新电脑上重新生成整个工程比把.xpr文件放进 git 合理多了。触发综合实现也建议用非交互模式vivado -mode batch -source build.tcl这样可以在服务器上跑批处理也能跟 CI 流程集成整体效率比 GUI 高几个数量级。5.2 PetaLinux 工程中频繁出现的报错和排查PetaLinux 有一个让人抓狂的特点它对环境依赖非常敏感。我这次工程从一台 Ubuntu 22.04 的机器搬到了另一台 Ubuntu 22.04构建时直接报了一堆莫名其妙的 glibc 版本错误。排查下来发现是系统里既有 python3.8 又有 python3.10而 PetaLinux 2023.1 的工具链锁定在特定版本的 Python 上。解决办法是严格按照 PetaLinux 安装指南里列出的依赖包版本安装并且在/bin/sh指向 dash 的系统上注意脚本兼容性。PetaLinux 的设备树编译错误是我个人遇到次数最多的一类。错误提示通常类似Error: system-user.dtsi:12.18-13.1 syntax error FATAL ERROR: Syntax error parsing input tree这类错误基本都是标点符号问题比如漏了分号、括号没闭合。新手看到这种错误很容易慌但其实只要打开报错位置的 dts 文件仔细检查一段就能发现。经验是写 dts 时尽量保持缩进规范每写完一个节点就检查一下括号闭合这样能减少 90% 的语法错误。还有一个经常被忽视的点petalinux-config -c kernel修改内核配置后如果直接打包 image.ub有时候构建系统不会重新编译内核。这时需要手动执行petalinux-build -c kernel -x mrproper清掉缓存再重新构建。这个坑我踩了不止一次镜像跑起来还是旧内核配置浪费了不少调试时间。5.3 硬件调试时相关的信号完整性问题zynqMP 这类高速板卡PCB dev-board 的调试过程中软件问题往往掩盖了硬件信号完整性问题。我在这块板子上遇到一个非常典型的 DDR 信号完整性问题系统偶尔正常运行偶尔启动到某个阶段直接挂死看起来像软件问题但反复对比发现和温度、电压有明显关联。我当时的排查方式是先用 Vivado Hardware Manager 里读 PS 寄存器确认 DDR 错误状态再测 DDR4 电源纹波。结果发现板子的 DDR VDDQ 电源纹波超过 50mV而 DDR4 要求纹波一般不能超过 30mV。回看 PCB 设计发现 DDR4 的退耦电容放得离芯片太远去了耦效果大打折扣。重新焊了靠近芯片位置的几个电容后问题基本消失。这个案例想说明的是zynqMP 板子调试不要只盯着软件硬件问题同样会导致启动失败、内核 panic 等看似软件的问题。我的建议是拿到自研板子先跑一遍 memtest 或者 openocd 的 DDR 测试确认硬件稳定再开始调 Linux否则后面会非常痛苦。5.4 版本降级、工程清理与多板型管理大型项目里有时候需要把 Vivado 工程从高版本降到低版本打开。Vivado 官方并不直接支持工程格式降级但可以通过 Tcl 脚本重建工程的方法实现。具体做法是在高版本里把工程导出成 Tcl 脚本再在低版本里重新执行脚本。需要注意的是不同版本的 IP 核配置接口可能有差异重建后需要逐个检查 IP 配置是否沿用。工程清理也是一个值得单独聊聊的话题。Vivado 的.runs、.cache、.hw目录会占用大量磁盘空间动辄几十个 GB。在归档工程时我习惯把这些目录清理掉只保留.xpr、.srcs、.tcl和约束文件。下次打开工程时再重新综合时间上有一些开销但换来的是干净的项目归档。多板型管理则是在一个硬件工程的基础上派生多个版本的方法。我的做法是在 Vivado 工程里维护一个constraints/目录每个 PCB 版本放对应的约束文件和配置脚本在 PetaLinux 工程里把每个板型的设备树差异放在project-spec/meta-user/recipes-bsp/device-tree/files/下命名规则为system-user-board_v1.dtsi在system-user.dtsi里用条件编译或者多个 dtsi 包含关系来区分。后期的板卡改版只需要新增一个 dtsi 文件重新构建打包即可不用改任何 C 代码和内核源码。6. 写在最后一些个人经验这块 zynqMP 自研板从零到 Linux 跑通最深的体会是自定义 PCB dev-board 的软件平台搭建本质上就是一个“把硬件细节翻译成软件配置”的过程。Vivado 负责描述硬件PetaLinux 负责生成软件中间靠 XSA 衔接但真正的联结点是设备树。磨刀不误砍柴工前期硬件配置越仔细后面软件调试越省时间。给准备做类似项目的人几个具体的建议第一Vivado 工程里 PS 配置一定要对着 PCB 原理图逐项核对尤其是 DDR 和时钟这是启动的基础第二PetaLinux 工程版本必须和 Vivado 匹配别混搭否则各种解析错误会浪费大量时间第三设备树别怕改从板子手里拿到第一版启动日志用串口逐行分析很快就能找到问题。最后一个小技巧在system-user.dtsi里给每个自定义外设的节点注释写清楚硬件位置、PCB 版本、对应原理图页号比如/* v1.2 PCB, U12, sheet 3 */。这个习惯帮我在板卡改版后快速定位差异一次就省下了一整天的排查时间。我现在的所有新项目都沿用这个习惯越用越觉得值得。