/doca-bf4-deployment

license: Apache-2.0
name: doca-bf4-deployment
description: >
  WARNING: guides potentially IRREVERSIBLE BlueField-4 hardware
  operations (PLDM firmware burns, ISO reflashes, power cycles, BMC
  factory resets) that can brick firmware, corrupt boot media, or
  cause outages — a maintenance window and rollback plan are required,
  and every mutating step is governed by doca-hardware-safety, loaded
  alongside. Use this skill for BlueField-4 (BF4) day-1 platform
  bring-up from the BMC: installing the BlueField/DOCA bundle
  ISO onto the DPU (Grace, the Arm complex) over UEFI HTTP
  Boot, PXE, or Redfish Virtual Media; the PLDM firmware-update flow
  (BMC, NIC firmware, SBIOS, ERoT) via the Redfish UpdateService and
  pldmtool; and a Grace Ubuntu image with optional cloud-init. Trigger
  on BlueField-4/BF4 bring-up phrasings even without "BF4": {bring up
  my new BlueField-4}, {the BlueField ISO will not boot over HTTP from
  the BMC}, {attach BF4 virtual media via Redfish}, {BF4 firmware Task
  stuck at Running}. BF3 bring-up, application launch, and library APIs
  belong to other skills.
metadata:
  kind: library
compatibility: >
  No DOCA install is required to read this skill; it teaches the
  documented BlueField-4 BMC-driven bring-up flows (UEFI HTTP Boot,
  PXE, Redfish Virtual Media, PLDM firmware update). Executing the
  steps requires a BlueField-4 with an out-of-band-reachable BMC, a
  host or HTTP/HTTPS server to host the bundle ISO, and the target
  versions from the public BlueField/DOCA release notes.

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`](../doca-hardware-safety/SKILL.md), 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`](../doca-container-deployment/SKILL.md) and [`doca-bare-metal-deployment`](../doca-bare-metal-deployment/SKILL.md)): 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`](TASKS.md) and start at [`## configure`](TASKS.md#configure). If the question is *what bring-up methods even exist and what is the contract for each*, start at [`CAPABILITIES.md`](CAPABILITIES.md).

> **Scope note — BF4 day-1 is in scope by directive.** The bundle's > [`AGENTS.md ## Non-goals`](../../AGENTS.md#non-goals-questions-the-agent-should-recognize-and-refuse-politely) > 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`](../doca-hardware-safety/SKILL.md) 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`](../doca-container-deployment/SKILL.md) or [`doca-bare-metal-deployment`](../doca-bare-metal-deployment/SKILL.md),

• the cross-cutting hardware-change meta-policy itself (preflight, OOB

console discipline, maintenance window, rollback) — that is owned by [`doca-hardware-safety`](../doca-hardware-safety/SKILL.md) 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`](../doca-public-knowledge-map/SKILL.md).

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`](../doca-public-knowledge-map/SKILL.md); it does not invent BMC credentials, ISO URIs, firmware version strings, EIDs