| license | Apache-2.0 |
| name | doca-bf3-deployment |
| description | Use this skill for BlueField-3 (BF3) day-1 platform bring-up via the classic RShim/BFB path: pushing a BlueField bundle (BFB) to the DPU over RShim with bfb-install from the host, the host-to-DPU TMFIFO management channel (tmfifo_net0, the 192.168.100.x convention), RShim daemon state and console-over-rshim, DPU mode selection (DPU/embedded-function vs separated-host/NIC mode) via mlxconfig, post-BFB recovery, a six-state BlueField-state classifier, and verifying the install (cat /etc/mlnx-release plus version checks). Trigger even when the user does not say "BF3" — typical phrasings include {push a BFB to my BlueField-3}, {bfb-install exited 0 but the DPU never came back}, {ping 192.168.100.2 works but ssh fails}, or {is DOCA on the host or the Arm side?}. BFB reflash, mlxconfig set, mode changes, and firmware burns are destructive: require explicit target-bound confirmation and load doca-hardware-safety. App launch, container deploy, env install, and the BF4 BMC-Redfish path route elsewhere.
|
| metadata | {"kind":"library"} |
| compatibility | No DOCA install required to read this skill (it is a platform-lifecycle overlay loaded against BF3 hardware); the bring-up and validation steps within DO require a real BlueField-3, host-side RShim access (PCIe or USB), the matching DOCA-Host install, and a BlueField bundle (BFB) image downloaded from the public DOCA Downloads page.
|
DOCA BlueField-3 (BF3) deployment
Where to start: This skill is the bundle's home for BlueField-3
day-1 platform bring-up — taking a BF3 from "powered card in the
slot" (or a card that just came back broken from a BFB push) to
"Arm OS healthy, TMFIFO up, host PFs bound, four-way version match
closed, ready to run a workload". It owns the classic RShim/BFB
path that BF3 uses today; the newer BMC-Redfish provisioning path
is the sibling skill
doca-bf4-deployment (the BF4
equivalent). If the user has a BF3 and needs to push a BFB, recover
a DPU that did not come back, or verify the install, open
TASKS.md and start at
## configure. If the question is what shape
does the BF3 platform-bring-up surface even have, start at
CAPABILITIES.md. Once the BF3 is healthy, this
skill routes onward to the deployment skills — running a binary
goes to
doca-bare-metal-deployment;
deploying a service container goes to
doca-container-deployment.
Every mutating burn invoked from a bring-up step — the BFB
reflash itself, any mlxconfig set (including a DPU/separated-host
mode flip), a firmware burn, or a kernel-boot-parameter change — is
governed by the change-application meta-policy in
doca-hardware-safety, which
the agent loads ALONGSIDE this skill. This skill adds only the
BF3-specific operational sequencing on top; it does NOT redefine
the preflight / OOB-console / maintenance-window / rollback
discipline that meta-policy owns.
Audience
This skill serves external DOCA operators bringing up a real
BlueField-3 — i.e. people who already have:
- a physical BlueField-3 in a host (or a standalone BF3 they can
reach over its console / management network),
- host-side RShim access to the DPU (the RShim userspace daemon and
the
/dev/rshim* character-device tree present over the PCIe or
USB RShim interface), and
- a matching DOCA-Host install on the host plus a BlueField bundle
(BFB) image downloaded from the public DOCA Downloads page.
It is not for:
- BlueField-4 bring-up (the BMC-Redfish provisioning path) — route
to
doca-bf4-deployment, the
BF4 equivalent of this skill,
