/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:
  author: NVIDIA <doca-feedback@nvidia.com>
  kind: library
  doca_version: "3.5"
  tags:
    - doca
    - bluefield-3
    - deployment
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.
  The validation steps require a live DOCA install.

DOCA BlueField-3 (BF3) deployment

Examples

• **"I have a BlueField-3 and a BFB — how do I push it?"** — RShim

plus bfb-install from the host. Exit 0 is not success until the DPU is ready.

• **"bfb-install exited 0 but the DPU never came back."** — start

at the six-state classifier, not a second burn.

Instructions

Follow Loading order below. Open the tasks companion for BFB push and recover. Open the capabilities companion for the RShim/BFB contract and safety overlay. Do not open every companion file.

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

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

or the BFB image itself (outside the scope of field deployment),

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

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

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

`doca-setup ## 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/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`, 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