Out-of-band: BMC, Redfish, and the BlueField-4 path

1The BlueField BMC and how you reach it

Every BlueField-3 model, DPU and SuperNIC alike, carries an integrated BMC.^[11] Its documentation (release 26.04) covers Connecting to BMC Interfaces, Platform Management Interface, First-time Installation, BlueField Management, BMC Management, NIC Subsystem Management, a Table of Common Redfish Commands, and Unsupported BMC Functionalities in NIC Mode.^[3] That last title is worth noting: some BMC functions depend on the Arm being active.

Three interfaces. The BMC “based on the Intelligent Platform Management Interface (IPMI) standard, supports both out-of-band (OOB) dedicated interfaces, and a serial port to access the CLI of the BMC”.^[2] Over the LAN the documented form is ipmitool -C 17 -I lanplus -H <bmc_ip> -U ADMIN -P ADMIN <ipmitool_arguments>; over the UART it is plain ipmitool <ipmitool_arguments>.^[2] And “The BlueField’s BMC provides a standard DMTF Redfish management interface, which is accessible via an HTTPS RESTful interface”, entered with:^[2]

curl -k -u root:'<password>' -H 'Content-Type: application/json' -X GET https://<bmc_ip>/redfish/v1

The ADMIN/ADMIN and root credentials in those examples are documentation defaults; the bf.cfg keys BMC_PASSWORD and NEW_BMC_PASSWORD exist so a BFB push can rotate them.^[6] A Dell PowerEdge adds a second controller to this picture: iDRAC manages the server, the card’s BMC manages the card. Which iDRAC features touch the BlueField BMC is covered in lesson 2.6, with its evidence limits.

ssh root@<bmc_ip>          # first login forces a change of the default password 0penBmc (12–20 chars)
curl -k -u root:'<password>' https://<bmc_ip>/redfish/v1/Systems/Bluefield/Oem/Nvidia

{ … "Mode": "DpuMode" … }

2Mode and privilege over Redfish

The BMC exposes the same mode switch you know from mlxconfig, without host involvement. Read the mode with GET /redfish/v1/Systems/Bluefield/Oem/Nvidia; the response carries "Mode": "DpuMode" or "NicMode".^[1] Set it with a POST to /redfish/v1/Systems/Bluefield/Oem/Nvidia/Actions/Mode.Set and a body of {"Mode": "NicMode"} or {"Mode": "DpuMode"}; “Two consecutive Arm reboots are required to apply configuration”.^[1]

Zero Trust is a different resource: PATCH /redfish/v1/Chassis/Card1/NetworkAdapters/NvidiaNetworkAdapter/Oem/Nvidia/HostPrivilegeConfig/Settings with {"PrivilegeMode": "Restricted"} to lock the host out or "Privileged" to let it back in; “Power cycle is required to apply configuration”.^[1] This is the BMC equivalent of mlxprivhost r and mlxprivhost p on the Arm, and it is the path you use when the Arm OS is not reachable.^[12]

BMC=https://<bmc_ip>; AUTH="-k -u root:<password> -H Content-Type:application/json"
# read mode (read-only)
curl $AUTH -X GET  $BMC/redfish/v1/Systems/Bluefield/Oem/Nvidia
# set mode (mutating: two consecutive Arm reboots to apply)
curl $AUTH -X POST $BMC/redfish/v1/Systems/Bluefield/Oem/Nvidia/Actions/Mode.Set -d '{"Mode": "NicMode"}'
# host privilege (mutating: power cycle to apply)
curl $AUTH -X PATCH $BMC/redfish/v1/Chassis/Card1/NetworkAdapters/NvidiaNetworkAdapter/Oem/Nvidia/HostPrivilegeConfig/Settings -d '{"PrivilegeMode": "Restricted"}'

The reset rules line up with the modes page: configuration takes effect only after the Arm and NIC components reset, and the order rule (Zero Trust to DPU first, then DPU to NIC) applies whichever interface you use.^[12] GET is read-only; POST and PATCH are mutating and belong inside a window with a rollback, exactly like mlxconfig s.

3Who owns rshim: the BMC-host handoff

Only one rshim back end can be attached to a card at a time. When a second one tries, the daemon reports another backend already attached; the troubleshooting guide calls this “correct behavior as there can only be one RShim back end active at any given time”.^[4] On cards with an integrated BMC the BMC owns rshim by default, so a host that runs rshim and sees no /dev/rshim0 is usually not broken; it is second in line.^[4]

The documented handoff is symmetrical:^[4]

# BMC -> host
bmc#  systemctl stop rshim
bmc#  systemctl disable rshim
host# systemctl enable rshim
host# systemctl start rshim
# host -> BMC: the same four commands with the roles swapped

Stop, then disable, on the side that gives up ownership; enable, then start, on the side that takes it. Disabling matters: a stopped-but-enabled service comes back at the next boot and takes the channel again.

The daemon also has a force mode. rshim -h lists -F, --force run in force mode, and the same option can be set as FORCE_MODE in the daemon’s configuration file; in force mode “we will send a one-time ownership request command for each rshim backend if they are found to be detached (aka. in drop mode)”.^[5] Use it when the other side is unreachable and you have decided the host must own the channel. How the flag reaches the daemon depends on your distribution’s unit file; check with systemctl cat rshim and put -F where that unit passes options. The pages fetched for this lesson do not document a specific OPTIONS= variable, so read the unit rather than assuming one.

The same BMC can be driven from a BFB push. bf.cfg carries BMC_USER (default root), BMC_PASSWORD / NEW_BMC_PASSWORD, UPDATE_BMC_FW (yes), BMC_REBOOT (no), UPDATE_CEC_FW (yes), BMC_IP_TIMEOUT (600 s) and BMC_TASK_TIMEOUT (1800 s), so one install can update the Arm OS, the NIC firmware and the BMC firmware together.^[6]

4BlueField-4: ISO and PLDM, not a BFB over rshim

BlueField-4 is not in the DOCA 3.5.0 supported-hardware tables; the release notes list BlueField-3, BlueField-2 and ConnectX adapters only.^[10] What exists today is NVIDIA’s own deployment skill, and it is explicit that “BF4 is not BF3”: the methods, the Grace naming and the dpu-bmc/Redfish surface are BF-4-specific, and the BF-3 rshim/BFB path is a different skill.^[9][7]

Day-1 bring-up of a BF-4 is “driven from its BMC”. Grace is “the Arm CPU complex on BlueField-4”, and the standards in play are Redfish (DMTF), PLDM for Firmware Update (DMTF) and UEFI (HTTP Boot, PXE, Boot Manager).^[7] Three OS install methods:^[7]

• A. UEFI HTTP Boot (recommended). An operator HTTP server hosts the bundle ISO; through BMC SSH and obmc-console-client you set, in UEFI, Device Manager, Network Device List, the OOB MAC, HTTP Boot Configuration, Boot URI, then Boot Manager, UEFI HTTP.
• B. PXE Boot. DHCP plus TFTP; the method to reach for “when you … need a custom bf.cfg”.
• C. Redfish Virtual Media. Upload the ISO to the BMC eMMC via Redfish SimpleUpdate (a “5 GB local-payload limit”), attach it via Redfish VirtualMedia, set BootSourceOverride to USB (Once, UEFI), reset Grace; it “requires a recent dpu-bmc version”, and you must “detach all virtual media afterward to avoid boot loops”.

Firmware (BMC, NIC firmware, SBIOS, ERoT) moves by PLDM: a multipart POST of the .fwpkg to the Redfish UpdateService update-multipart endpoint, then monitor the Redfish Task (PercentComplete, Messages), verify with pldmtool fw_update GetFwParams -m <eid>, activate with a power cycle; Redfish FirmwareInventory is the cross-check, and BMC factory reset is recovery-only.^[7][8] Cloud-init works through a seed ISO labelled CIDATA, with BMC-facing URIs fixed to image.iso and config.iso.^[8] The post-install anchor is still cat /etc/mlnx-release on Grace.^[7]

Why the change: BF-3 provisioning depends on a host-visible rshim function and a bootstream format; BF-4 standardises on what every server BMC already speaks (Redfish, PLDM, UEFI boot), so the same tooling that provisions the server can provision the card, from the BMC, with no host cooperation. Treat everything in this segment as NVIDIA guidance from the skills repository, not as DOCA product documentation, until BF-4 appears in a DOCA release.^[9]