4. Zynq启动与配置测试

Zynq 的启动过程本质上是“BootROM 先跑、FSBL 接管、PL 配置与软件镜像随后加载”的三级接力。产品化测试要验证的不是“板子能亮”，而是在指定启动介质、指定镜像组合、指定异常条件下，系统能否按预期进入目标状态，并在失败时按策略回退。本节围绕 QSPI、SD、eMMC 三种典型启动介质，给出可执行的验证方法、比特流加载检查点、多启动镜像回退测试以及故障注入手段。

一、启动链路与介质差异

上电后 BootROM 依据启动模式引脚（MIO[8:2] 等）选择启动介质，从介质头部读取 Boot Header，校验并搬移 FSBL 到 OCM，随后由 FSBL 完成 DDR 初始化、PL 配置、加载 SSBL（如 U-Boot）或直接加载裸机应用。QSPI 属于 NOR 类，支持 XIP 与随机读，适合小容量、高可靠场景；SD 卡可插拔、便于产线烧录与现场升级；eMMC 容量大、带宽高，适合量产固件与根文件系统。三者的镜像布局、分区方式与回退能力不同，测试用例必须分别设计。

二、QSPI 启动验证

QSPI 启动验证的核心是确认 Boot Header、FSBL、bitstream 与 SSBL 在 Flash 中的偏移与 BIF 描述一致。典型做法是用 Vitis 生成 BOOT.BIN，再通过 JTAG 或 U-Boot 的 sf 命令写入。写入后必须做一次完整断电重启，而不是软复位，因为软复位可能保留 DDR 与 PL 状态，掩盖真实启动问题。

# U-Boot 下写入 QSPI（示例）
sf probe 0 0 0
sf erase 0x0 0x1200000
sf write 0x30000000 0x0 0x1200000
# 设置启动模式引脚为 QSPI，断电重启
# 观察串口是否依次输出 FSBL、bitstream 加载、U-Boot

判断依据：串口在 FSBL 阶段应打印 “Boot mode: QSPI” 与 PL 配置完成信息；若卡在 “Loading bitstream” 或出现 “PL configuration failed”，优先检查 bitstream 偏移是否与 BIF 一致、Flash 是否真正擦除干净。可用 sf read 回读前 0x100 字节，与 BOOT.BIN 头部比对。

三、SD 与 eMMC 启动验证

SD 启动依赖 FAT 分区中的 BOOT.BIN，BootROM 只识别 FAT16/32。测试时先用 fdisk 确认分区起始扇区，再用 mkfs.vfat 格式化，最后把 BOOT.BIN 与 image.ub 拷入。eMMC 启动则需注意 boot0/boot1 分区是否使能、是否设置了 PARTITION_CONFIG 与 BOOT_BUS_CONDITIONS。eMMC 的 extcsd 中 BOOT_PARTITION_ENABLE 必须指向正确槽位，否则 BootROM 会回落到 user 分区而找不到镜像。

# 查看 eMMC 启动配置（Linux 下示例）
mmc extcsd read /dev/mmcblk0 | grep -i boot
# 期望：BOOT_PARTITION_ENABLE = 0x1（boot0）或 0x2（boot1）
# 若为 0x0，则 BootROM 不会从 boot 分区取镜像

SD 与 eMMC 的常见故障是“分区表正确但文件系统不被识别”。此时应检查分区类型是否为 0x0C（FAT32 LBA），以及 BOOT.BIN 是否放在根目录。另一个高频问题是 eMMC 的 boot_bus_width 与硬件走线不匹配，表现为启动极慢或 CRC 错误，可通过降低到 4-bit 或 1-bit 验证。

四、比特流加载与 PL 状态确认

比特流加载有两种路径：FSBL 在启动阶段配置 PL，或 Linux 起来后通过 fpga_manager 动态加载。产品化测试要分别覆盖。启动阶段加载的判据是 FSBL 日志中的 “Bitstream download done” 以及 PCAP 状态寄存器 PCAP_STATUS 的 DONE 位。动态加载则通过 sysfs 写入 .bin 文件，再读回 /sys/class/fpga_manager/fpga0/state，期望为 operating。

# Linux 动态加载 bitstream（示例）
echo firmware.bin > /sys/class/fpga_manager/fpga0/firmware
cat /sys/class/fpga_manager/fpga0/state
# 期望输出：operating
# 若为 unknown 或 firmware request failed，检查文件名与 /lib/firmware 路径

PL 配置完成后，还应通过 AXI GPIO 或自定义寄存器做一次读写回环，确认 PL 逻辑真正可用，而不是仅 DONE 置位。这一步能发现“比特流版本与软件寄存器映射不一致”的问题。

五、多启动镜像回退测试

回退机制依赖“启动尝试计数 + 看门狗 + 标志位”。以 eMMC 双槽为例：U-Boot 在启动槽 A 前把 bootcount 加一，若系统在限定时间内未清除该计数，下一次启动就切换到槽 B。测试时必须人为制造槽 A 失败，而不是只验证正常切换。

可执行的故障注入方式包括：把槽 A 的 BOOT.BIN 头部 CRC 改错、把 FSBL 长度字段改大、在 U-Boot 中设置 bootdelay 后直接 reset 模拟看门狗超时。观察点：第一次重启后串口应出现 “Boot slot A failed, switching to B”，第二次重启应从槽 B 正常进入系统，且 bootcount 被清零。

六、故障注入与结果判读

故障注入的目标是验证“系统能识别异常并按策略处理”，而不是把板子彻底变砖。建议按以下顺序逐级注入：镜像头部损坏、镜像截断、PL 比特流错误、DDR 初始化参数错误、看门狗超时。每一级都要记录串口日志、启动耗时、最终进入的槽位与系统状态。

最终验收标准应写成可判定的条目：指定介质下冷启动成功率、回退触发时间上限、回退后系统可用性、PL 配置成功率。只有把这些结果与注入条件一一对应，启动与配置测试才算形成闭环。