【Xilinx】【ZynqMP】Petalinux 2020.1 QSPI Flash启动Linux：从分区规划到固件合成的避坑实践

1. 为什么你的ZynqMP板子从QSPI启动总是失败？

最近在调试一块Xilinx Zynq UltraScale+ MPSoC开发板时，遇到了一个让人头疼的问题：按照官方文档配置Petalinux 2020.1后，系统死活无法从QSPI Flash正常启动。要么报"Offset exceeds device limit"错误，要么出现"Bad data crc"校验失败。经过三天三夜的折腾，我终于摸清了其中的门道。

很多工程师在使用Petalinux 2020.1为ZynqMP平台构建QSPI启动系统时，都会遇到类似的困扰。这主要是因为2020.1版本引入了distro boot机制，U-Boot的启动流程发生了较大变化。传统的配置方法不再适用，而官方文档又没能及时更新，导致开发者们只能自己摸索。

2. 硬件环境与准备工作

2.1 开发板与Flash规格确认

首先需要确认你的硬件配置。我使用的是Xilinx ZCU102开发板，板载的QSPI Flash是Micron的MT25QU256ABA，容量为32MB（256Mb）。不同开发板的Flash型号可能不同，这直接影响后续的分区规划。

在U-Boot启动时，可以查看Flash的详细信息：

ZynqMP> sf probe SF: Detected mt25qu256 with page size 256 Bytes, erase size 64 KiB, 512 MiB total

关键参数是擦除块大小(erase size)，这里是64KB。这意味着我们所有的分区边界都必须是64KB的整数倍，否则会导致擦除或写入失败。

2.2 Petalinux工程创建

使用Petalinux 2020.1创建工程：

petalinux-create -t project --template zynqMP -n zynqmp_qspi cd zynqmp_qspi petalinux-config --get-hw-description=<path_to_hdf>

在配置界面中，确保选择了正确的处理器型号和Flash类型。特别要注意的是，在"Subsystem AUTO Hardware Settings" → "Flash settings"中，确认QSPI Flash的配置与实际硬件一致。

3. 分区规划的艺术

3.1 理解Petalinux 2020.1的启动流程

与早期版本不同，Petalinux 2020.1采用了distro boot机制。启动流程大致如下：

1. ZynqMP ROM代码加载FSBL
2. FSBL加载U-Boot
3. U-Boot从指定位置加载boot.scr脚本
4. 执行boot.scr中的命令加载内核和设备树

这个流程中，boot.scr成为了关键环节。它需要被放置在Flash的特定位置，并且U-Boot需要知道这个位置。

3.2 实战分区方案设计

对于32MB的QSPI Flash，我推荐以下分区方案：

这个方案考虑了以下几点：

1. BOOT.BIN需要足够空间容纳FSBL、PMU Firmware和U-Boot
2. image.ub包含内核、设备树和根文件系统，通常较大
3. bootscr和环境变量分区使用最小擦除块大小64KB

在Petalinux-config中配置：

petalinux-config

进入"Image Packaging Configuration" → "Flash Partition"，按上述方案设置分区。

4. U-Boot的关键配置

4.1 设置boot.scr偏移地址

执行以下命令进入U-Boot配置：

petalinux-config -c u-boot

导航到：

ARM architecture → Boot script offset

设置为bootscr分区的起始地址，本例中为0x1F0000。

4.2 修改内核加载参数

编辑文件project-spec/meta-user/recipes-bsp/u-boot/u-boot-zynq-scr.bbappend，修改以下参数：

QSPI_KERNEL_OFFSET = "0xA00000" QSPI_FIT_IMAGE_SIZE = "0x1500000"

这两个参数告诉U-Boot在哪里找到内核镜像以及它有多大。

5. 固件合成与烧录技巧

5.1 解决CRC校验失败的秘密

直接使用生成的boot.scr会导致CRC校验失败，这是因为：

1. U-Boot会读取整个bootscr分区(64KB)做CRC校验
2. 原始boot.scr可能只有几KB，剩余部分是未初始化的Flash内容(0xFF)
3. 0xFF的CRC值与实际脚本的CRC不匹配

解决方法是用0x00填充剩余空间：

objcopy -I binary -O binary --pad-to=0x10000 --gap-fill=0x00 boot.scr bootscr-pad.bin

5.2 一键合成完整镜像

为了简化烧录过程，可以先将所有文件填充到各自分区大小，然后合并成一个完整镜像：

objcopy -I binary -O binary --pad-to=0xA00000 --gap-fill=0x00 BOOT.BIN BOOT-pad.bin objcopy -I binary -O binary --pad-to=0x1500000 --gap-fill=0x00 image.ub image-pad.bin objcopy -I binary -O binary --pad-to=0x10000 --gap-fill=0x00 boot.scr bootscr-pad.bin cat BOOT-pad.bin image-pad.bin bootscr-pad.bin > BOOT-ALL.bin

5.3 烧录方法选择

有多种方法可以将镜像烧录到QSPI Flash：

1. U-Boot命令行烧录：

tftpboot 0x100000 BOOT-ALL.bin sf probe 0 0 0 sf erase 0x0 0x2000000 sf write 0x100000 0x0 ${filesize}

2. 使用Petalinux工具：

petalinux-package --boot --u-boot --kernel --offset 0xA00000 --add image.ub

3. 通过JTAG烧录：

program_flash -f BOOT-ALL.bin -offset 0 -flash_type qspi-x4-single -verify

6. 常见问题排查指南

6.1 "Offset exceeds device limit"错误

这个错误通常有两个原因：

1. 分区地址超出了Flash的物理大小
2. 分区边界没有对齐到擦除块大小

解决方法：

1. 检查分区表，确保所有地址都在Flash容量范围内
2. 确保所有分区起始地址和大小都是擦除块大小(64KB)的整数倍

6.2 "Bad data crc"错误

如前所述，这个错误通常是由于boot.scr填充不完整导致的。确保：

1. 使用objcopy填充整个bootscr分区
2. 填充值为0x00而不是0xFF
3. 烧录的是填充后的文件

6.3 系统启动后卡住

如果系统启动过程中卡住，可以：

1. 检查U-Boot环境变量是否正确
2. 确认内核和设备树是否正确加载
3. 检查串口输出，定位卡住的具体阶段

7. 高级技巧与优化建议

7.1 多镜像备份方案

为了提高系统可靠性，可以在QSPI Flash中实现双备份系统：

1. 将Flash分为两个相同的区域
2. 每个区域包含完整的启动镜像
3. 在U-Boot中添加镜像验证和切换逻辑

7.2 压缩内核减小体积

如果kernel分区空间紧张，可以考虑：

1. 使用更高压缩率的压缩算法（如LZMA）
2. 裁剪不必要的内核模块
3. 将部分驱动编译为模块，放在根文件系统中

7.3 性能优化

QSPI Flash的读取速度直接影响启动性能：

1. 启用DMA传输
2. 使用更高的时钟频率
3. 启用Quad SPI模式（如果Flash支持）

在U-Boot中可以通过以下命令验证SPI时钟设置：

ZynqMP> sf probe SF: Detected mt25qu256 with page size 256 Bytes, erase size 64 KiB, 512 MiB total, 108 MHz clock

如果时钟频率偏低，可以在设备树中调整spi-max-frequency参数。