4. Versal启动流程与工业固件部署

Versal 的启动不是“上电即运行应用”这么简单,而是一条由硬件固化逻辑、平台管理单元和用户固件共同接力的多阶段链路。理解这条链路,才能正确制作 BOOT.BIN 与 image.ub,并让工业控制固件从 QSPI、SD 卡或 eMMC 稳定启动。

一、启动链路的四个关键角色

Versal 上电后,最先运行的是芯片内固化的 BootROM。它不依赖外部 DDR,只使用片上 SRAM,负责最基本的启动介质探测、启动头解析和镜像校验。BootROM 根据启动模式引脚(如 QSPI24、QSPI32、SD1_LS、eMMC 等)选择介质,读取启动头,找到第一阶段引导程序并加载到 PMC 的片上内存中执行。

随后接管的是 PLM(Platform Loader and Manager)。PLM 运行在 PMC 内部,是 Versal 平台管理的核心固件。它负责初始化 PMC、配置时钟与电源域、加载 PL 的 PDI、加载 PS 的子系统固件,并在系统运行期间承担错误管理、电源管理和部分隔离控制。对工业控制场景而言,PLM 还决定了 PL 与 PS 的启动先后关系。

PMC(Platform Management Controller) 是承载 PLM 的硬件单元,同时管理启动、复位、时钟、电源域和安全性。它不直接运行业务逻辑,但所有启动阶段的切换都由它协调。可以把它理解为“启动总控室”。

PS 与 PL 是最终运行用户逻辑的两大部分。PS 包含 APU(ARM Cortex-A72/A53)和 RPU(Cortex-R5F),通常运行 Linux 或裸机实时控制程序;PL 是可编程逻辑,用于实现工业以太网、电机控制 PWM、编码器接口等硬实时功能。启动顺序上,PLM 可以先加载 PL 的 PDI,再释放 PS;也可以先启动 PS,再由 PS 通过 Linux 驱动加载 PL。工业固件通常选择“PL 先配置、PS 后启动”,以保证通信接口在 Linux 网络栈起来之前就已就绪。

Versal 启动链路与工业固件部署关系 BootROM 片上固化代码 探测介质 / 校验启动头 启动介质 QSPI24 / QSPI32 SD1_LS(SD 卡) eMMC PLM / PMC 平台加载与管理 时钟 / 电源域初始化 加载 PDI 与子系统固件 错误管理与复位控制 PL PDI 配置 工业以太网 / PWM PS APU:Linux RPU:实时控制 加载 image.ub 加载 读取 PDI 释放 就绪信号 BOOT.BIN PLM + PDI + FSBL + U-Boot 由 BootGen 打包 image.ub Kernel + DTB + RootFS 由 PetaLinux 生成 包含 加载 启动模式引脚 MODE[3:0] 决定 BootROM 选路 QSPI / SD / eMMC 选择 阶段1:BootROM 阶段2:PLM 初始化 阶段3:PL / PS 加载 阶段4:OS 启动

二、BOOT.BIN 的组成与 BootGen 打包

BOOT.BIN 是 BootROM 和 PLM 能够识别的启动镜像。它通常包含 PLM 固件、PL 的 PDI、PS 的 FSBL(First Stage Boot Loader)以及 U-Boot。制作 BOOT.BIN 的核心工具是 BootGen,输入是一个 BIF(Boot Image Format)文件。

一个典型的 BIF 文件结构如下:

// versal.bif
the_ROM_image:
{
    [destination_cpu = pmc, exception_level = el-3, trustzone = secure]
    plm.elf
    [destination_cpu = pl, image_type = cdo]
    design.pdi
    [destination_cpu = a72-0, exception_level = el-2]
    fsbl.elf
    [destination_cpu = a72-0, exception_level = el-2]
    u-boot.elf
}

执行打包命令:

bootgen -image versal.bif -arch versal -o BOOT.BIN -w on

其中 -arch versal 指定芯片架构,-w on 表示覆盖已有输出。打包完成后,BOOT.BIN 会被写入启动介质的起始偏移处。QSPI 通常从 0x000000 开始,SD 卡从 FAT 分区根目录读取,eMMC 则从 boot0 分区或用户分区起始位置读取。

三、image.ub 的生成与部署

image.ub 是 U-Boot 加载的 Linux 内核镜像,通常由 PetaLinux 构建产生,内部打包了 kernel、设备树 DTB 和根文件系统。在工业控制固件中,image.ub 需要包含工业以太网驱动、实时补丁、以及针对具体载板的设备树配置。

生成 image.ub 的典型流程是:在 PetaLinux 工程中执行 petalinux-build,然后在 images/linux 目录下得到 image.ub。将该文件放入 SD 卡的 FAT 分区,或写入 QSPI/eMMC 的指定分区,U-Boot 启动后通过 bootm 或 booti 命令加载。

对于 QSPI 启动,由于容量有限,通常只放 BOOT.BIN,image.ub 放在 eMMC 或通过网络加载。对于 SD 卡启动,BOOT.BIN 和 image.ub 可以放在同一个 FAT 分区,方便现场更换。对于 eMMC 启动,建议将 BOOT.BIN 写入 boot0 分区,image.ub 写入用户分区,并设置分区偏移。

四、三种启动介质的工程选择

启动介质 典型容量 适用场景 注意事项
QSPI 16~64 MB 紧凑型工业控制器,仅存 BOOT.BIN 容量小,image.ub 需外置
SD 卡 8~32 GB 开发调试、现场升级 接触可靠性低于 eMMC
eMMC 4~32 GB 量产工业设备,长期运行 需正确配置 boot0/boot1 分区

五、启动失败的常见判断点

如果系统上电后无输出,首先确认 MODE 引脚是否与目标介质一致。其次检查 BOOT.BIN 是否包含正确的 PLM 和 PDI,BootGen 打包时是否遗漏 destination_cpu。若 U-Boot 能启动但内核挂起,重点检查 image.ub 中的设备树是否匹配载板 DDR 容量和 QSPI 分区。若 PL 配置失败,观察 PLM 日志中的 PDI 加载错误码,确认 PDI 是否与当前 PL 时钟配置兼容。

工业现场建议保留一路 QSPI 作为“救砖”启动路径,量产固件放在 eMMC,SD 卡仅用于维护升级。这样即使 eMMC 固件损坏,仍可通过 QSPI 中的最小系统恢复。

掌握 BootROM → PLM → PMC → PS/PL 的接力关系,并正确制作 BOOT.BIN 与 image.ub,是 Versal 工业固件能够从 QSPI、SD 卡和 eMMC 稳定启动的基础。后续的工业通信协议栈和边缘控制应用,都建立在这条启动链路之上。