(use-case-developer)= # 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](/software/web-ui.md) or [`laam`](/software/laam_console.md): * power the DUT on and off from the [power rails](/hardware/sib-header.md#power-rails) * press [virtual buttons](/software/laacli.md#button) (reset, recovery, boot select) that would otherwise need a finger on the board * power-cycle individual [USB ports](/hardware/peripherals.md#dut-usb) * open the [serial console](/guides/device_type_enablement.md#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](/software/dut-services/automation.md) * expose a disk image to the DUT as a [USB mass storage device](/software/laacli.md#usbg-ms) * read the [DUT temperature](/hardware/peripherals.md#thermal-probes) and [power consumption](/software/laacli.md#watt) ## Setting up ### 1. Connect the appliance and the DUT Follow the [QuickStart](/guides/unbox_quickstart.md) to unbox the appliance and attach your DUT through the right [MIB](/hardware/mibs.md). If your board is already enabled, its wiring is documented in the {ref}`devices-index` section. Then plug the appliance into your network (see [Connectivity](/guides/connectivity.md)) 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](/software/api.md#authentication). ### 3. Install `laam` [`laam`](/software/laam_console.md) is the command line client for the [LAA REST API](/software/api.md). It runs on your laptop, not on the appliance: ```console python3 -m venv venv source venv/bin/activate python3 -m pip install --upgrade laam ``` Register the appliance as an identity: ```console laam identities add --uri http://192.168.1.234 --token default ``` You can register as many identities as you have appliances and pick one per command with `laam -i ...`. See [Configuration](/software/laam_console.md#configuration) for the details. ## A typical session Check that the appliance is online and reachable: ```console $ laam system version ``` Power the DUT and watch it boot: ```console $ 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. :::{admonition} Device configuration :class: info 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](/guides/device_type_enablement.md#configuration-file). ::: If you want the individual steps instead: ```console $ 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](/guides/device_type_enablement.md#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: ```console $ 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](/software/dut-services/automation.md) 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](/hardware/peripherals.md#public-ethernet), 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](/hardware/peripherals.md#private-ethernet) 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](/software/dut-services/internet-direct-access.md). * 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](/software/ssh-keys.md). :::{admonition} SSH access :class: warning 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](/software/laam_python.md), which is what you want for a flashing or bring-up script * from any language, through the [REST API](/software/api.md) directly * from an AI agent, through the [MCP server](/software/laam_console.md#mcp) that `laam` can start * with [labgrid LAA support](https://gitlab.com/Linaro/lava/appliance/labgrid-laa-examples) 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](/use-cases/ci.md). ## Bringing up a board that is not yet supported If your DUT is not in the {ref}`devices-index` 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](/guides/device_type_enablement.md), and the background on what makes a board automatable is in [Intro to Device Testing](/guides/device_test_intro.md). `laam dut new`, `laam dut check` and `laam dut test` are the helpers built for exactly this. See [`laam dut` helper](/guides/device_type_enablement.md#laam-dut-helper).