第三篇不再讲“怎么构建”，而是讲系统上电之后，怎样一步步证明它真的可用。

先从最小可观测性开始

第一次启动新镜像时，最重要的不是马上跑业务程序，而是建立最小可观测性。串口最好用，因为它能覆盖  FSBL、U-Boot、kernel 和用户空间；如果串口不可用，至少要准备 JTAG、SD 卡离线挂载、网络扫描三种  fallback。没有观测入口，就没有排障。

按阶梯验证，不要跳步

新板 bring-up 最忌讳一上来就做高速数据面。正确顺序是：先确认 Linux 启动，再确认网络，再确认 PYNQ 环境，再确认 overlay，再只读寄存器，再安全写读回，最后才进入 PL DDR、DMA、ADC/DAC 或业务数据流。

Linux 启动后的第一组命令

系统起来后，先不要急着加载复杂 overlay。用基础命令确认内核、设备树、网络、磁盘和服务状态。每条命令都应该能回答一个具体问题，而不是“看看有没有异常”。

如果使用了板卡配置文件，例如 `/boot/test-board.json`，建议让一个 systemd 服务在启动早期读取它，设置 hostname、网络模式和板卡角色。这样多块板可以使用同一张镜像，只通过启动分区的小文件区分差异。

PYNQ overlay 验证要看 hwh

PYNQ  加载 bitstream 只是第一步。真正影响 Python 侧开发体验的是 hwh 解析结果：`ip_dict` 是否有你的  AXI-Lite IP，`mem_dict` 是否有预期的数据窗口，地址范围是否和 Vivado address editor 一致。如果  hwh 缺失或来自旧构建，Python 代码可能找不到 IP，或者找到的是错误地址。

如果  overlay 加载失败，先看三件事：bit/hwh 是否来自同一次导出；FPGA manager 是否启用；设备树里是否保留了 FPGA  manager、clock、reserved memory 或相关驱动配置。不要急着改 Python wrapper，先证明底层资源存在。

寄存器访问先只读再写

AXI-Lite  是 PS 和 PL 联调最适合的第一条路。建议先选择版本号、构建时间、板卡 ID 这类只读寄存器。读值稳定后，再选择一个不会触发  reset、trigger、DMA start、DAC enable 的配置寄存器做写读回。每次写之前保存原值，测试结束恢复原值。

数据通路用闭环证明

控制面通过以后，再验证数据面。若  PS 需要访问 PL DDR，硬件上应有 PS HPM master 到 PL DDR controller 的地址通路，软件上应清楚这是  MMIO、UIO、DMA 还是用户态 mmap。验证策略从小到大：先 4KB pattern，再扩大到一帧业务数据，再进入持续读写。

如果数据不一致，不要立刻怀疑算法。先查地址单位是否一致：旧驱动可能用 word address，Linux MMIO 常用 byte offset；上位机 RPC 又可能包装了一层兼容转换。其次查缓存策略、字节序、位宽截断和突发长度。最后再看硬件状态机。

常见问题排障矩阵

把验证结果写成可复用记录

每次镜像、bit/hwh、XSA、device  tree 或 runtime package 变化，都应该记录版本和验证结论。最小记录包括：镜像  SHA256、构建时间、硬件导出时间、启动日志摘要、网络地址、overlay  解析结果、只读寄存器值、安全写读回结果、数据闭环结果。这样下一次异常时，你不是从记忆里排障，而是从证据里排障。

做到这里，你已经拥有一条完整的  Zynq PS Linux 移植闭环：硬件平台可导出，板级 Linux 可构建，SD 镜像可启动，PYNQ 或用户态程序可访问  PL，控制面和数据面都能被最小测试证明。后续要做的，就是把临时脚本收敛成工程化工具，把 bring-up 经验沉淀为自动测试。

参考资料

• PYNQ SD Card image 文档：https://pynq.readthedocs.io/en/v3.1/pynq_sd_card.html
• PYNQ sdbuild README：https://github.com/Xilinx/PYNQ/blob/master/sdbuild/README.md
• AMD UG1144 PetaLinux boot and packaging：https://docs.amd.com/r/2024.1-English/ug1144-petalinux-tools-reference-guide/petalinux-package