📚 课程目录第2章 BlueField启动与固件管理

2. BlueField启动与固件管理

BlueField DPU 本质上是一台“嵌在网卡里的服务器”：它拥有独立的 ARM 多核 CPU、内存、PCIe 端点与网络接口，因此也拥有一套完整的启动链。理解这条启动链，是后续做固件升级、故障恢复和批量部署的前提。BlueField 的启动过程可以概括为：上电后由片内 BootROM 加载第一阶段引导，随后进入 ARM Trusted Firmware（ATF）完成安全与时钟等底层初始化，再交给 UEFI 固件，由 UEFI 加载操作系统或网络引导镜像。整条链路自上而下逐级“接力”，任何一级损坏都会导致 DPU 无法进入系统。

需要先明确几个关键角色。BootROM 是固化在芯片内部的只读代码，不可修改，它负责最早期的最小初始化，并按启动模式（如从 eMMC、SPI Flash 或 PCIe 主机侧）寻找可执行的引导镜像。ATF（ARM Trusted Firmware）运行在 ARM 的 EL3 异常等级，承担安全启动、内存与时钟初始化、以及把控制权移交给 UEFI 的职责，它通常以 BL2/BL31 等阶段形式存在。UEFI 则是我们最常打交道的固件层，它提供启动菜单、设备管理、固件更新入口，并最终引导操作系统。三者关系是“BootROM → ATF → UEFI → OS”，越靠前越底层、越难替换。

在实际操作中，最常见的固件更新方式是使用 NVIDIA 提供的 .bfb（BlueField Bootstream）镜像。这个镜像是一个“打包体”，内部通常包含 BootROM 引导头、ATF、UEFI、操作系统镜像以及配置元数据。更新时，我们并不需要逐级替换，而是把整个 bfb 镜像写入 DPU 的存储介质，然后重启，让 BootROM 按新的引导头重新走一遍启动链。这样做的优点是原子性好、版本一致，缺点是镜像体积较大，写入时间较长。

写入 bfb 镜像的通道主要有三种：一是通过主机侧的 rshim 接口，这是最常用的方式，主机上会枚举出一个 /dev/rshim0 设备，把 bfb 文件写入该设备即可；二是通过 DPU 的 BMC 管理口，适合远程无人值守场景；三是通过串口或 USB 恢复模式，用于设备已经无法正常启动的极端情况。下面是一个通过 rshim 写入 bfb 镜像的典型命令示例：

# 在主机侧确认 rshim 设备已枚举
ls /dev/rshim0

# 将 bfb 镜像写入 DPU（示例路径）
cat /path/to/bluefield-3.bfb > /dev/rshim0/boot

# 写入完成后触发 DPU 重启
echo "SW_RESET 1" > /dev/rshim0/misc

写入过程中，可以通过 /dev/rshim0/misc 或 dmesg 观察进度。如果写入中断或镜像损坏，DPU 可能无法进入 UEFI，此时就需要进入恢复模式。恢复模式的核心思路是：让 BootROM 不从损坏的 eMMC 启动，而是从主机侧或外部通道接收一个完整的 bfb 镜像，重新刷写存储介质。进入恢复模式通常需要按住 DPU 上的恢复按钮，或在 BMC 中设置下一次启动为恢复模式，然后重新上电。

恢复模式下的操作与正常更新类似，但有一个关键区别：此时 DPU 的 ARM 核可能只运行了最小化的 BootROM 代码，UEFI 和 ATF 都未加载，因此只能通过 rshim 或串口进行通信。写入完成后，需要断电重启，让 DPU 从新写入的镜像正常启动。恢复成功后，应通过 bfb-install 或 mlxfwmanager 等工具确认 ATF、UEFI 和 OS 的版本号是否与预期一致。

在批量部署场景中，建议先在一台 DPU 上验证 bfb 镜像的完整性和启动结果，再通过 rshim 或 BMC 批量推送。每次更新前记录当前固件版本，更新后对比版本号，形成可追溯的升级记录。

不要随意中断 bfb 写入过程。BootROM 和 ATF 位于启动链最底层，一旦写入不完整，DPU 可能无法进入 UEFI，只能依赖恢复模式重新刷写。恢复模式操作前，务必确认主机侧 rshim 驱动已正确加载，且 bfb 镜像的校验和与官方发布一致。

总结来看，BlueField 的启动与固件管理围绕“BootROM → ATF → UEFI → OS”这条链展开，bfb 镜像是贯穿始终的载体。正常更新时，我们通过 rshim 或 BMC 写入完整镜像并重启；异常时，则进入恢复模式，用同样的镜像重新刷写。理解每一级固件的职责和更新入口，才能在 DPU 无法启动时快速定位问题，并选择正确的恢复路径。