FPGAer独立日：不用再求Linux同事，手把手教你用Vitis自己生成MPSOC的BOOT.bin

FPGA工程师的独立宣言：用Vitis自助生成MPSOC启动文件的完整指南

作为一名FPGA开发者，你是否经历过这样的场景：硬件设计迭代了十几个版本，每次修改完bit文件后，都要低声下气地找Linux同事帮忙重新打包BOOT.bin？调试进度卡在等待启动文件生成的环节，明明只是改了个LED闪烁频率，却要耗费半天时间走流程？这种依赖关系不仅影响效率，更让人在团队中处于被动地位。今天，我们就来打破这个桎梏。

1. 为什么FPGA工程师需要掌握BOOT.bin生成技术

在ZYNQ/MPSOC平台上，BOOT.bin是系统启动的核心文件，它包含了FPGA配置bit流、FSBL（First Stage Bootloader）、PMU固件、ARM Trusted Firmware（bl31）和U-Boot等关键组件。传统分工模式下，Linux工程师负责这个文件的打包工作，但这种协作方式存在几个明显痛点：

• 响应延迟：简单修改需要跨团队沟通，打断他人工作流
• 版本混乱：多次迭代时容易产生文件版本管理问题
• 调试瓶颈：无法快速验证硬件修改对启动流程的影响
• 技术局限：难以深入理解完整的启动链和硬件-软件交互

掌握自助生成BOOT.bin的能力，意味着FPGA工程师可以：

1. 实时验证硬件修改
2. 独立完成启动参数调优
3. 快速定位启动阶段问题
4. 提升全栈开发能力

注意：此技术最适合硬件接口稳定（ZYNQ IP配置不变）但内部逻辑需要频繁修改的场景。若涉及DDR配置等硬件参数变更，仍需协同验证。

2. 准备工作：获取必要组件与工具配置

2.1 必备文件清单

在开始前，请确保已准备好以下文件：

2.2 软件环境配置

确保已正确安装以下工具链：

1. Vivado Design Suite（2021.2或更新版本）
2. Vitis统一软件平台（与Vivado同版本）
3. 对应的Xilinx设备支持包

推荐在Windows环境下操作，但Linux平台同样适用。关键是要保证Vivado和Vitis版本严格匹配，否则可能出现兼容性问题。

# 检查工具版本一致性示例 vivado -version vitis -version

3. 分步指南：使用Vitis生成BOOT.bin

3.1 创建Platform工程

1. 启动Vitis IDE，选择工作空间目录
2. 点击"Create Platform Project"
3. 输入项目名称（如mpsoc_boot_platform）
4. 选择从XSA文件创建，导入最新的.xsa硬件描述文件
5. 保持其他选项默认，点击Finish

提示：如果硬件接口未改变，可以重复使用同一个platform工程，只需更新.xsa文件即可。

3.2 生成FSBL和PMU固件

在Platform工程中：

1. 右键点击工程名，选择"Build Project"
2. 构建完成后，在<project>/export目录下找到：
   • fsbl.elf- 第一阶段引导加载程序
   • pmufw.elf- 电源管理单元固件

// FSBL的主要职责包括： // 1. 初始化PS（处理系统）基础外设 // 2. 配置PL（可编程逻辑）的bit流加载 // 3. 加载后续启动阶段组件

3.3 使用Create Boot Image工具

这是最关键的步骤：

1. 在Vitis菜单栏选择Xilinx → Create Boot Image
2. 创建新的BIF（Boot Image Format）文件：

   // 示例BIF文件内容 the_ROM_image: { [bootloader] fsbl.elf pmufw.elf [destination_device=pl] top.bit bl31.elf u-boot.elf }

3. 添加所有必需组件文件：
   • 按顺序选择：fsbl.elf、pmufw.elf、.bit文件、bl31.elf、u-boot.elf
4. 指定输出路径和文件名（通常命名为BOOT.bin）
5. 点击"Create Image"生成最终文件

常见问题排查：

• 如果遇到FSBL exit breakpoint not hit错误，检查：

  • DDR配置是否正确
  • 硬件设计中ZYNQ IP的时钟配置
  • FSBL等待超时参数是否足够

• 文件顺序错误会导致启动失败，务必保持上述顺序

4. 高级技巧与实战经验

4.1 自动化脚本方案

对于需要频繁更新的场景，可以创建TCL脚本自动化流程：

# 示例自动化脚本片段 set bif_path "boot_image.bif" set output_dir "output" proc generate_boot_bin {} { global bif_path output_dir # 生成BIF文件 set bif_file [open $bif_path w] puts $bif_file "the_ROM_image:\n{\n\t[bootloader] fsbl.elf\n\tpmufw.elf\n\t..." close $bif_file # 调用bootgen工具 exec bootgen -image $bif_path -arch zynqmp -o $output_dir/BOOT.bin -w }

4.2 版本控制策略

建议采用以下文件命名规范：

BOOT_<日期>_<版本>_<描述>.bin 示例：BOOT_20230801_v1.2_ADC优化.bin

同时维护一个变更日志：

4.3 调试技巧

当BOOT.bin无法正常启动时：

1. 通过JTAG连接评估板
2. 在Vitis中创建Debug配置
3. 单步跟踪FSBL执行流程
4. 关键检查点：
   • PMU初始化完成
   • DDR校准通过
   • bit流加载成功
   • 控制权移交bl31

# 在U-Boot中检查启动信息的命令 => bdinfo => printenv => fpga info

5. 系统集成与部署

生成BOOT.bin后，需要将其部署到目标系统的启动介质中（如SD卡、QSPI Flash等）。这里介绍最常用的SD卡方案：

1. 准备FAT32格式的SD卡
2. 将以下文件拷贝到卡根目录：
   • BOOT.bin（刚生成的启动文件）
   • image.ub（Linux内核和根文件系统）
   • boot.scr（U-Boot脚本）
3. 确保SD卡分区表为MBR格式
4. 设置开发板从SD卡启动

性能优化建议：

• 对于生产环境，考虑将BOOT.bin烧写到QSPI Flash以获得更快启动速度
• 在开发阶段，可以启用FSBL的调试输出辅助问题定位
• 精简U-Boot功能可以减少启动时间

在实际项目中，我发现最耗时的往往不是文件生成本身，而是确保各组件版本兼容性。建议建立一个组件版本对应表，记录每个BOOT.bin使用的各组件版本号，这在排查诡异问题时特别有用。