Hardware Control :: FirmwareCI

DUTCTL

Mon, 01 Jan 0001 00:00:00 +0000

Run a command on a device that is connected to a dutagent. Use it to power the DUT on and off, flash firmware, or work with the serial console. The step sends one command to the agent and waits for it to finish. The agent receives command and args unchanged, so the step is equivalent to this CLI call: dutctl -s Attribute Type Required Default Description cmd const Yes dutctl Command Name name string Yes Name to uniquely identify the teststep. This name will show up in reports, logs and the WebUI options OptionsObject No Additional command options. The default timeout is 5m. parameters DUTCTLOptions Yes Options passed into the dutctl cmd Quick start A step that flashes the firmware under test:

PiKVM

Mon, 01 Jan 0001 00:00:00 +0000

Manage PiKVM operations. Attribute Type Required Default Description cmd const Yes pikvm Command name. name string Yes Unique identifier for the teststep. options OptionsObject No Additional command options. parameters PiKVMOptions Yes Parameters for the pikvm command. PiKVM Options Attribute Type Required Default Description command string Yes (must be one of: image, screenshot, keyboard, atx) Operation to perform via the PiKVM interface. host string Yes Hostname or IP address of the PiKVM (format: “https://hostname”). auth object Yes (must include username and password) Authentication details for the PiKVM API. image object Conditionally required when command is image Image configuration. Contains a path property with the image file path to upload and mount. keyboard object Conditionally required when command is keyboard Keyboard input configuration. Use either the keys (array of key sequences) or text (string) property. With keys, delay sets the pause after each key as a duration such as 500ms or 1s (default 500ms). atx object Conditionally required when command is atx ATX power control, see PiKVM ATX Power. The screenshot opens the PiKVM’s video stream itself, so no browser has to show it. It fails if the PiKVM gets no picture from the DUT within 10 seconds.

Qemu

Mon, 01 Jan 0001 00:00:00 +0000

Manage QEMU virtual machines. Attribute Type Required Default Description cmd const Yes qemu Command Name name string Yes Name to uniquely identify the teststep. This name will show up in reports, logs and the WebUI options OptionsObject No Additional command options parameters QemuOptions Yes Options passed into the qemu cmd Qemu Options Attribute Type Required Default Description mode string Yes Supported modes are start, run and stop. executable string Conditional (see below) The executable that should be executed. firmware string Conditional (see below) The firmware that should be used. image string No The image that should be booted. nproc integer No The number of processors that should be used. mem integer No The amount of memory that should be used. variable string Conditional (see below) Name a variable to store the qemu PID for later session return. serial QemuStepsOptions Yes Steps to interact with during test execution. Behavior and semantics The run mode can be used to attach to an already running QEMU instance. In this case, variable must be set to the PID of the QEMU process. If variable is not set, the run mode will behave like the start mode, launching a new QEMU instance. The stop mode will send a termination signal to the QEMU process identified by variable. Conditional rules:

Redfish

Mon, 01 Jan 0001 00:00:00 +0000

Run DMTF Redfish conformance testing against a BMC. Wraps the DMTF reference validators (Redfish-Service-Validator for schema, DSP8010; Redfish-Interop-Validator for profiles; Redfish-Protocol-Validator for protocol behavior, DSP0266) and adds three native engines: inventory for board-specific value checks the validators do not perform, request for writes, actions and firmware uploads, and events for the server-sent event stream. The validators run on the contest runner and connect to the BMC over HTTPS; their full reports (HTML/XLSX/TSV) are attached as downloadable artifacts while a per-check summary is folded into the step log.

IPMI

Mon, 01 Jan 0001 00:00:00 +0000

Read one IPMI value from a BMC and check it, or write one. A step names what it reads with get (a sensor, a FRU field, a SEL entry, or a field of a decoded IPMI command), writes a value with set, sends request bytes with raw, or captures the host console with sol, and states what it expects with expect, the same way Shell pairs command with expect. The step runs ipmitool, in-band on the transport target or over lanplus, and reports each check with the value it found.

VNC

Mon, 01 Jan 0001 00:00:00 +0000

Check a BMC’s KVM over VNC (RFB): connect from the runner, optionally send keys, capture one frame, check it and attach it as a PNG screenshot. Where PiKVM drives an external KVM device, vnc checks the KVM that the BMC serves itself. On OpenBMC, obmc-ikvm serves the host’s video and keyboard as a VNC server on TCP 5900, but it listens on localhost only. bmcweb forwards it as a websocket at /kvm/0, which is what the web UI uses, so the step goes through bmcweb by default. via: direct is for VNC servers that listen on the network, such as QEMU’s -vnc display.

BMC Virtual Media

Mon, 01 Jan 0001 00:00:00 +0000

Serve a disk image to a BMC’s virtual media, so the host sees a read-only USB disk. The runner itself is the server; no browser is involved. Where PiKVM emulates a USB drive from an external device, bmc-virtualmedia uses the virtual media that the BMC serves itself. On OpenBMC, bmcweb offers virtual media in proxy mode as a websocket at /vm/0/0, which is what the web UI uses. When a client opens it, the BMC attaches the disk and exposes it to the host as a USB mass storage device (“Virtual Media Device”). The step serves the image over that websocket with the NBD protocol.