Doca Bf4 Deployment

DOCA BlueField-4 (BF4) deployment

⚠️ WARNING — irreversible hardware operations. This skill guides operators through potentially destructive, irreversible BlueField-4 hardware operations: PLDM firmware burns, ISO reflashes, power cycles, and BMC factory resets. These can brick firmware, corrupt boot media, or cause production outages. Do not proceed without a maintenance window and a tested rollback plan. Every mutating step is governed by doca-hardware-safety, which MUST be loaded alongside this skill before any destructive action.

Before executing any mutating step — PLDM firmware burn, ISO reflash, power cycle, or BMC factory reset — the agent MUST show the exact command and its blast radius (which device, what becomes unavailable, whether it is reversible) and obtain the user's explicit confirmation for that specific action. Never chain destructive steps or run them speculatively as a side effect of another task.

Where to start: This skill is the bundle's deliberate in-bundle home for day-1 platform bring-up of a BlueField-4 DPU via the BMC — getting a powered-but-bare BF4 to "Grace OS installed, firmware at the target level, ready to deploy a workload." It is the upstream of the two application-deployment skills (doca-container-deployment and doca-bare-metal-deployment): those skills assume a working BlueField; this skill is how the BlueField-4 GETS to working. If the user has a fresh BF4 and wants to install the OS or update firmware, open TASKS.md and start at ## configure. If the question is what bring-up methods even exist and what is the contract for each, start at CAPABILITIES.md.

Scope note — BF4 day-1 is in scope by directive. The bundle's AGENTS.md ## Non-goals item 7 lists the BlueField BSP / BFB / RShim / TMFIFO layer and the BlueField BMC software as externally-productized. BlueField-4 day-1 bring-up via the BMC is carved into scope for this skill by directive because day-1 has no other home in the bundle. The carve-out is narrow: this skill teaches the documented BMC-driven install and firmware-update FLOWS (the CLASS), routing every mutating step through doca-hardware-safety for the change-application meta-policy. It does NOT redefine that meta-policy, and it does NOT cover BF3 (route to doca-bf3-deployment), application launch, or library APIs.

Audience

This skill serves external operators standing up a new BlueField-4 who already have:

• a BlueField-4 with its BMC reachable out-of-band (BMC SSH plus the documented Redfish endpoint), so the DPU can be driven without physical access,
• the BlueField/DOCA bundle ISO (and, for the Grace-Ubuntu path, a Grace Ubuntu image) downloaded from the public NVIDIA download surface, hosted at {iso-uri} on the operator's own HTTP/HTTPS server, and
• the target firmware and OS versions read from the public BlueField/DOCA release notes (this skill never quotes a specific pre-release firmware version).

It is not for:

• BlueField-3 (BF3) bring-up — route to doca-bf3-deployment,
• developers who want to RUN a DOCA service container or a DOCA-linked binary on an already-working BlueField — route to doca-container-deployment or doca-bare-metal-deployment,
• the cross-cutting hardware-change meta-policy itself (preflight, OOB console discipline, maintenance window, rollback) — that is owned by doca-hardware-safety and this skill cross-links it, never duplicates it,
• fleet-scale / orchestrated DPU provisioning — that is DOCA Platform Framework territory, routed via doca-public-knowledge-map.

The skill teaches the agent the documented bring-up procedure and the rules for quoting Redfish / PLDM / UEFI standard operations and public BlueField/DOCA documentation via doca-public-knowledge-map; it does not invent BMC credentials, ISO URIs, firmware version strings, EIDs, Redfish task IDs, or device names from memory.

When to load this skill

Load this skill when the user is doing hands-on day-1 bring-up of a BlueField-4 via the BMC, or asking a cross-cutting BF4-bring-up question that is not specific to a later application-deployment step. Concretely:

• Installing the BlueField/DOCA bundle ISO onto the DPU (Grace) for the first time, and choosing between the three documented install methods — UEFI HTTP Boot (recommended), PXE Boot, or Redfish Virtual Media.
• Running the PLDM firmware-update flow across the BMC / NIC firmware / SBIOS / ERoT components: pushing the .fwpkg bundle through the Redfish UpdateService multipart endpoint, monitoring the returned Task, verifying pending images with pldmtool, and activating with a power cycle.
• Installing a Grace Ubuntu image (with optional cloud-init via a CIDATA-labelled config ISO) through Redfish Virtual Media, with either local hosting on the BMC eMMC or remote hosting on an HTTPS server.
• Reaching the DPU's OOB serial console (BMC SSH plus obmc-console-client) to watch the installer or UEFI menus.
• Diagnosing a bring-up that is misbehaving — the ISO will not boot, virtual media will not attach, a firmware Task hangs or reports an Exception, a pending image never activates, cloud-init is ignored, or the DPU is stuck in a boot loop because media was never detached.
• Cross-cutting questions: "HTTP Boot or Redfish Virtual Media — which do I use, and when do I actually need PXE?", "how do I know the firmware update actually took effect?", "the ISO landed but the NIC firmware update sub-step seems to have failed — what now?".

Do not load this skill for BF3 bring-up (route to doca-bf3-deployment); for running an application on an already-working BlueField (route to doca-container-deployment or doca-bare-metal-deployment); for env preparation on the installed Grace OS such as hugepages / pkg-config / devlink (use doca-setup); for the cross-cutting hardware-change meta-policy (route to doca-hardware-safety); or for fleet-scale orchestrated provisioning (route via doca-public-knowledge-map).