/doca-bf3-deployment

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`](../doca-bf4-deployment/SKILL.md) (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`](TASKS.md) and start at [`## configure`](TASKS.md#configure). If the question is *what shape does the BF3 platform-bring-up surface even have*, start at [`CAPABILITIES.md`](CAPABILITIES.md). Once the BF3 is healthy, this skill routes **onward** to the deployment skills — running a binary goes to [`doca-bare-metal-deployment`](../doca-bare-metal-deployment/SKILL.md); deploying a service container goes to [`doca-container-deployment`](../doca-container-deployment/SKILL.md).

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`](../doca-hardware-safety/SKILL.md), 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`](../doca-bf4-deployment/SKILL.md), the BF4 equivalent of this skill,

• kernel-driver or BlueField-OS developers contributing to `mlx5_*`

or the BFB image itself (that is internal-tree work, not a field deployment),

• operators who already have a healthy BF3 and just want to *run a

binary* (route to [`doca-bare-metal-deployment`](../doca-bare-metal-deployment/SKILL.md)) or *deploy a service container* (route to [`doca-container-deployment`](../doca-container-deployment/SKILL.md)),

• fresh-no-hardware users with no DOCA install — route to

[`doca-setup ## no-install`](../doca-setup/TASKS.md#no-install).

The skill teaches the agent the BF3 bring-up *procedure* and the rules for quoting documented commands from the public BlueField Platform Software Manual, the public DOCA Installation Guide, and the MFT manual via [`doca-public-knowledge-map`](../doca-public-knowledge-map/SKILL.md); it does **not** invent `bfb-install` flag sets, BFB image filenames, RShim character-device paths, `bf.cfg` schema keys, `mlxconfig` parameter names, or TMFIFO subnets from memory. Where a fact is already vetted in [`doca-bare-metal-deployment ## bluefield-lifecycle`](../doca-bare-metal-deployment/TASKS.md#bluefield-lifecycle), this skill reuses that exact fact rather than restating a new one.

When to load this skill

Load this skill when the user is doing **hands-on BlueField-3 platform bring-up over the RShim/BFB path**, or asking a cross-cutting BF3 lifecycle question that is not specific to one library's API. Concretely:

• Pushing a BFB image to a BF3 for the first time (or re-pushing

after a failed install), from the host over the RShim interface with `bfb-install`.

• Bringing up or recovering the host-to-DPU TMFIFO management

channel (`tmfifo_net0`, the documented `192.168.100.x` convention) and the RShim console.

• Confirming RShim driver/daemon state on the host (the userspace

`rshim` daemon and the `/dev/rshim*` tree) before any push or console capture.

• Deciding (and routing) a DPU-mode change — DPU / embedded-function

mode vs separated-host / NIC mode — knowing the actual `mlxconfig set` burn leaves this skill