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, 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 ), application launch, or library APIs.