Developing on a DUT

This is the simplest way to use an LAA: a single developer, a single board, no automation framework involved.

The appliance replaces the pile of accessories that usually sits around a development board — a USB hub, a relay board for the reset button, a smart plug, an FTDI cable, a TFTP server on your laptop — with one box that you can drive from a command line.

The important consequence is that nothing about your workflow changes when you stop sitting next to the board. The appliance is driven over HTTP os SSH, so whether the DUT is on your desk or in a rack in another building, you run the same commands.

What you can do

From your laptop with the LAA web interface or laam:

• power the DUT on and off from the power rails

• press virtual buttons (reset, recovery, boot select) that would otherwise need a finger on the board

• power-cycle individual USB ports

• open the serial console and interact with the bootloader, the kernel or userspace applications

• push a kernel, a device tree or a rootfs to the appliance and serve it to the DUT over TFTP or NFS

• expose a disk image to the DUT as a USB mass storage device

• read the DUT temperature and power consumption

Setting up

1. Connect the appliance and the DUT

Follow the QuickStart to unbox the appliance and attach your DUT through the right MIB. If your board is already enabled, its wiring is documented in the Devices Overview section.

Then plug the appliance into your network (see Connectivity) and note the IP address shown on the OLED display.

2. Create an API token

Browse to the appliance web interface at the address on the OLED, open the profile page and create a token. The procedure is described in Authentication.

3. Install laam

laam is the command line client for the LAA REST API. It runs on your laptop, not on the appliance:

python3 -m venv venv
source venv/bin/activate
python3 -m pip install --upgrade laam

Register the appliance as an identity:

laam identities add --uri http://192.168.1.234 --token <token> default

You can register as many identities as you have appliances and pick one per command with laam -i <identity> .... See Configuration for the details.

A typical session

Check that the appliance is online and reachable:

$ laam system version

Power the DUT and watch it boot:

$ laam dut interact device.yaml

dut interact powers the DUT on, attaches the serial console and powers it off again when you press Ctrl+C. This is usually the only command you need during a debug session.

Device configuration

The command expect a device configuration file that list the commands to power on, off the board along with the name of the serial console to use.

This is explained in the device-type enablement guide.

If you want the individual steps instead:

$ laam laacli power 12v on
$ laam serials connect ttymxc3

The list of available consoles, their names and their baud rates is in the ser2net configuration table. laam serials list shows the ones present on your appliance, and laam serials scan listens to all of them in parallel when you do not yet know which one your board uses.

Get your build onto the DUT:

$ laam files push ./arch/arm64/boot/Image Image
$ laam files push ./rootfs.tar.xz rootfs.tar.xz
$ laam files decompress rootfs.tar.xz

Everything pushed this way lands in /var/lib/lava/dispatcher/tmp on the appliance, which is exported to the DUT over TFTP and NFS at 198.18.0.1. From the DUT bootloader you can therefore tftp the kernel you just pushed, and mount the NFS share as a rootfs.

Files also travel the other way: laam files pull retrieves anything the DUT wrote into the share.

Local or remote, same commands

The appliance exposes its API on the public ethernet port, so the only thing that changes between “the board is on my desk” and “the board is in the lab” is the URI in your laam identity.

Two things are worth knowing when the board is not next to you:

• The DUT lives on the appliance’s private network and cannot reach your lab network. If your tests need to reach a cloud service, the appliance can open a tunnel for the DUT. See Internet direct access.

• If you need a shell on the appliance itself rather than API access, ask an admin to upload your public key and connect as torizon. See SSH keys.

SSH access

This gives full access to the appliance and to the network it sits on, so prefer the API when you only need the DUT.

Scripting and automation

Once the interactive workflow works, the same operations are available:

• from Python, with the laam library, which is what you want for a flashing or bring-up script

• from any language, through the REST API directly

• from an AI agent, through the MCP server that laam can start

• with labgrid LAA support

When those scripts start running on every commit instead of on demand, you should move to the next use case: Hardware in the CI loop.

Bringing up a board that is not yet supported

If your DUT is not in the Devices Overview list, it has to be enabled first: choosing a MIB, working out how to power it and reset it, finding its console. That work is described in Device-Type enablement, and the background on what makes a board automatable is in Intro to Device Testing.

laam dut new, laam dut check and laam dut test are the helpers built for exactly this. See laam dut helper.