2. BlueField 启动与固件管理

BlueField DPU 本质上是一台“藏在网卡里的独立计算机”：它拥有自己的 CPU 核心、内存、存储、网络接口和固件栈，同时又与宿主机通过 PCIe 紧耦合。理解它的启动流程与固件管理，是保证 DPU 在生产环境中稳定、可升级、可恢复的前提。本节围绕 DPU 从上电到可用的完整启动链、UEFI/ATF 固件分工、BMC 带外管理、固件升级与恢复模式，以及生产环境的版本管理策略展开。

一、DPU 启动流程：从复位到可用

BlueField 的启动链与普通服务器类似，但多了一层“宿主机视角”的复杂性。上电或复位后，最先运行的是片内 Boot ROM，它根据启动模式（Boot Mode）选择从哪里加载第一阶段固件。BlueField-2 常见的启动源包括 eMMC、SPI Flash、网络（PXE/HTTP）以及通过 PCIe 由宿主机注入的启动镜像。Boot ROM 完成最小化初始化后，把控制权交给 ATF（Arm Trusted Firmware）的 BL1/BL2 阶段。

ATF 是 Arm 架构的安全固件基础，负责建立可信执行环境、初始化 DDR、配置安全与非安全世界切换，并最终跳转到 UEFI 固件。UEFI 阶段完成 PCIe 枚举、设备树/ACPI 表构建、网络与存储控制器初始化，然后按启动顺序寻找可引导的操作系统。对于 BlueField 上运行的 DOCA/Ubuntu 等系统，UEFI 会加载 GRUB 或直接引导内核，随后 systemd 拉起 DPU 侧的服务，包括 DOCA 运行时、OVS/OVS-DOCA、容器运行时等。此时 DPU 才真正“可用”，宿主机也能通过 PCIe 看到完整的虚拟功能（VF）与代表（Representor）接口。

需要特别注意的是启动顺序中的“先后依赖”：ATF 必须在 UEFI 之前完成 DDR 与安全环境初始化，UEFI 必须在 OS 之前完成 PCIe 与设备枚举。任何一环固件版本不匹配，都可能导致 DPU 无法被宿主机识别，或启动后网络功能异常。

二、UEFI 与 ATF 固件的职责边界

很多初学者会把 UEFI 和 ATF 混为一谈，实际上二者职责清晰分离。ATF 运行在最高异常等级（EL3），负责安全启动、可信根、DDR 训练与电源域初始化，它不关心操作系统是什么。UEFI 运行在非安全世界，负责标准化的硬件抽象与引导服务，包括 PCIe 配置空间枚举、ACPI 表生成、网络协议栈（PXE/HTTP Boot）以及启动项管理。

在 BlueField 上，UEFI 还承担一项特殊任务：向宿主机暴露正确的 PCIe 配置。DPU 的 PF（Physical Function）在 UEFI 阶段完成 BAR 空间分配与 SR-IOV 能力声明，宿主机 BIOS 才能正确枚举并分配资源。如果 UEFI 固件版本过旧，可能出现 VF 数量受限、MSI-X 中断异常等问题。因此升级固件时，ATF 与 UEFI 通常作为同一固件包（Bundle）一起更新，避免版本错配。

三、BMC 与带外管理

BlueField 板卡上集成了 BMC（Baseboard Management Controller），它独立于 DPU 主 CPU 运行，拥有独立的供电、网络接口和固件。BMC 的核心价值在于“带外”：即使 DPU 操作系统崩溃、ATF 启动失败，只要板卡供电正常，管理员仍可通过 BMC 的 Redfish/IPMI 接口执行电源控制、读取传感器、查看事件日志，甚至挂载虚拟光驱/镜像进行远程重装。

在生产环境中，BMC 网络应与业务网络物理或逻辑隔离，使用独立的管理 VLAN。典型操作包括：通过 Redfish 查询 DPU 健康状态、通过虚拟介质挂载恢复镜像、通过串口重定向（Serial over LAN）观察启动日志。当 DPU 无法正常启动时，BMC 往往是唯一的“救命通道”。

四、固件升级与恢复模式

BlueField 固件升级通常使用 mlxup 或 mlxfwmanager 工具，在 DPU 操作系统内执行，也可通过 BMC 带外升级。升级前必须确认当前固件版本与目标版本，并备份关键配置。以下为 DPU 内查询与升级的典型命令示例：

# 查询当前固件版本
mlxfwmanager --query

# 升级固件（指定固件包）
mlxfwmanager -u -f /path/to/fw-BlueField-2.bin

# 升级后重启 DPU 使新固件生效
reboot

升级过程中最需要警惕的是“断电或中断”。固件写入 Flash 时若发生掉电，可能导致 Boot ROM 无法找到有效固件，设备变砖。为此 BlueField 提供了恢复模式（Recovery Mode）：通过板卡上的物理跳线或 BMC 命令，强制 Boot ROM 从备用启动源（如 BMC 虚拟介质或网络）加载恢复镜像，重新烧写固件。恢复模式是生产环境升级流程中必须提前验证的“安全网”。

五、生产环境版本管理策略

在多台 DPU 的生产集群中，固件版本管理不能靠“逐台手动升级”。推荐策略是：建立固件基线（Baseline），将 ATF、UEFI、BMC 固件、DOCA 版本作为一个整体版本集进行管理；使用配置管理工具（如 Ansible）批量查询与升级；升级前记录当前版本，升级后通过 mlxfwmanager --query 与 doca_version 校验一致性。

最后需要强调：DPU 固件与宿主机驱动之间存在强耦合。升级 DPU 固件前，应确认宿主机侧的 OFED/mlx5 驱动版本在兼容列表内。若宿主机驱动过旧，可能出现 DPU 升级后宿主机无法识别设备的情况。因此，生产环境的版本管理应同时覆盖 DPU 侧与宿主机侧，形成完整的“端到端版本视图”。