DOCA BlueField-4 (BF4) 部署
⚠️ 警告——不可逆的硬件操作。 本技能可能引导操作员执行具有潜在破坏性、不可逆的BlueField-4硬件操作：PLDM固件烧录、ISO重刷、电源重启以及BMC恢复出厂设置。这些操作可能使固件变砖、损坏启动介质或导致生产中断。在没有维护窗口和经过测试的回滚计划之前，不要继续。每个变更步骤都受
doca-hardware-safety的约束，该技能必须与之一同加载，然后才能执行任何破坏性操作。
在执行任何变更步骤（PLDM固件烧录、ISO重刷、电源重启或BMC恢复出厂设置）之前，智能体必须展示确切的命令及其影响范围（涉及哪个设备、什么会不可用、是否可逆），并获得用户对该特定操作的明确确认。切勿串行执行破坏性步骤，也不要将其作为其他任务的副作用而推测性执行。
从何处开始： 本技能是包内专门为通过BMC进行BlueField-4 DPU的“第1天”平台部署（day-1 bring-up）设立的“驻家”位置——将一台已通电但空白的BF4推进到“Grace OS已安装、固件处于目标版本、准备部署工作负载”的状态。它是两个应用部署技能（doca-container-deployment和doca-bare-metal-deployment）的上游：那些技能假定BlueField处于可用状态；本技能则是让BlueField-4“变为可用”的方法。如果用户有一台全新的BF4并希望安装OS或更新固件，请打开TASKS.md并从## configure开始。如果问题是到底存在哪些部署方法，以及每种方法的契约是什么，请从CAPABILITIES.md开始。
范围说明——BF4第1天部署按指令属于本技能范围。 包的
AGENTS.md ## 非目标第7条将BlueField BSP / BFB / RShim / TMFIFO层和BlueField BMC软件列为外部产品化事项。根据指令，BlueField-4通过BMC的第1天部署被划入本技能范围，因为第1天在该包内没有其他归属。该例外是狭隘的：本技能讲授已文档化的BMC驱动安装和固件更新流程（类别），并将每个变更步骤通过doca-hardware-safety路由，以应用变更的元策略。它不重新定义该元策略，也不覆盖BF3（引导至doca-bf3-deployment）、应用程序启动或库API。
受众
本技能面向正在部署新BlueField-4的外部操作员，他们已具备：
- 一台BlueField-4，其BMC可通过带外方式（BMC SSH及文档化的Redfish端点）访问，因此无需物理访问即可驱动DPU，
- 从公共NVIDIA下载面下载的BlueField/DOCA捆绑ISO（以及Grace-Ubuntu路径所需的Grace Ubuntu镜像），托管在操作员自己HTTP/HTTPS服务器的{iso-uri}，
- 从公开的BlueField/DOCA发布说明中读取目标固件和OS版本（本技能绝不引用具体的预发布固件版本）。
本技能不适用于：
- BlueField-3（BF3）部署——引导至
doca-bf3-deployment， - 希望在已工作的BlueField上运行DOCA服务容器或DOCA链接二进制的开发者——引导至
doca-container-deployment或doca-bare-metal-deployment， - 跨领域的硬件变更元策略本身（预检、带外控制台纪律、维护窗口、回滚）——由
doca-hardware-safety负责，本技能仅交叉引用，绝不重复， - 舰队级/编排式DPU配置——这属于DOCA Platform Framework的范畴，通过
doca-public-knowledge-map路由。
本技能教导智能体有文档记录的部署流程以及如何通过doca-public-knowledge-map引用Redfish / PLDM / UEFI标准操作及公开BlueField/DOCA文档的规则；它不会凭记忆编造BMC凭据、ISO URI、固件版本字符串、EID、Redfish任务ID或设备名称。
何时加载本技能
当用户正在通过BMC进行BlueField-4的实际第1天部署，或提出不属于后续应用部署步骤的跨领域BF4部署问题时，加载本技能。具体包括：
- 首次将BlueField/DOCA捆绑ISO安装到DPU（Grace），并在三种有文档记载的安装方法中进行选择——UEFI HTTP Boot（推荐）、PXE Boot或Redfish虚拟介质。
- 执行跨越BMC / NIC固件 / SBIOS / ERoT组件的PLDM固件更新流程：将
.fwpkg包通过Redfish UpdateService multipart端点推送、监控返回的任务、使用pldmtool验证待处理镜像，并通过电源重启激活。 - 通过Redfish虚拟介质安装Grace Ubuntu镜像（可选cloud-init，通过CIDATA标签的配置ISO），既可以本地托管在BMC eMMC上，也可远程托管在HTTPS服务器上。
- 访问DPU的带外串行控制台（BMC SSH加
obmc-console-client）以查看安装程序或UEFI菜单。 - 排查启动失败的问题——ISO无法启动、虚拟介质无法挂载、固件任务挂起或报告异常、待处理镜像永不激活、cloud-init被忽略，或者DPU因介质未分离而陷入启动循环。
- 跨领域问题：“HTTP Boot还是Redfish虚拟介质——我该用哪个，什么时候才需要PXE？”、“我怎么知道固件更新是否真正生效？”、“ISO已进入但NIC固件更新子步骤似乎失败——接下来怎么办？”。
不要针对BF3部署（引导至doca-bf3-deployment）；不要在已工作的BlueField上运行应用（引导至doca-container-deployment或doca-bare-metal-deployment）；不要在已安装的Grace OS上进行环境准备，如大页 / pkg-config / devlink（使用doca-setup）；不要为跨领域硬件变更元策略（引导至doca-hardware-safety）；也不要为舰队级编排式配置（通过doca-public-knowledge-map路由）加载本技能。
本技能提供的内容
这是一个薄加载器。实质性内容位于两个伴随文件中：
CAPABILITIES.md— BF4第1天部署契约：三种OS安装方法（UEFI HTTP Boot、PXE Boot、Redfish虚拟介质）和Grace-Ubuntu-plus-cloud-init虚拟介质路径；覆盖BMC / NIC固件 / SBIOS / ERoT的PLDM固件更新面；doca-version上的版本兼容性叠加（安装和固件目标来自公开发布说明，绝不来自记忆）；部署错误分类（启动源 -> 虚拟介质挂载 -> 固件任务 -> 激活 -> cloud-init -> 启动循环）；可观测性面（带外控制台、Redfish任务资源、Redfish FirmwareInventory、pldmtoolGetFwParams，以及安装构建检查cat /etc/mlnx-release）；以及安全策略（对doca-hardware-safety的叠加：每次PLDM烧录 / ISO重刷 / 电源重启 / BMC恢复出厂设置均为变更性硬件操作；绝不打印真实密码；务必分离虚拟介质以避免启动循环；任何NVIDIA URL仅使用公共主机）。TASKS.md— 针对范围内部署动词的分步工作流：configure、build（路由桩）、modify（路由桩）、run（三种安装方法加上PLDM固件更新流程和Grace-Ubuntu cloud-init路径，作为###子锚点）、test（安装后 / 更新后验证扫描）、debug（分层部署诊断），以及Deferred task verbs块，将BF3 / 应用启动 / 库API / 环境准备 / 硬件元策略 / 舰队问题路由到它们所属技能。
本技能假设BlueField-4目标：
- BMC可通过带外访问且操作员拥有BMC凭据（{bmc-user} / {bmc-password}），这些凭据由操作员提供——此处绝不臆造，
- 捆绑ISO（以及任何Grace Ubuntu镜像 / cloud-init配置ISO）已从公共NVIDIA下载面下载并托管在{iso-uri}，
- 操作员已从公开BlueField/DOCA发布说明中阅读目标固件和OS版本。
它不涵盖在主机上安装DOCA工具——该路径通过doca-setup——也不涵盖在Grace运行起来后运行工作负载——这些路径通过两个应用部署技能。
加载顺序
- 首先阅读本
SKILL.md以确认用户的问题在范围内（BF4第1天通过BMC部署；不是BF3、不是应用启动、不是库API问题、不是硬件变更元策略本身）。 - 关于部署契约（三种安装方法、Grace-Ubuntu cloud-init路径、PLDM固件更新面、版本叠加、部署错误分类、可观测性面和BF4安全叠加），参见CAPABILITIES.md。
- 关于分步工作流——
configure、build（路由桩）、modify（路由桩）、run（三种安装方法、PLDM流程和Grace-Ubuntu cloud-init路径为###子锚点）、test、debug，以及Deferred task verbs块——参见TASKS.md。 - 只要问题涉及变更步骤（PLDM固件烧录、ISO重刷、电源重启、BMC恢复出厂设置），就将
doca-hardware-safety与之一同加载。