| 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.
