Use cases

The Linaro Automation Appliance is a single piece of hardware, but it is used in three fairly different ways. Each one has its own audience, its own setup steps and its own security trade-offs.

Pick the one that matches what you are trying to do.

👩‍💻 Developing on a DUT

You have a board on your desk, or in a lab down the corridor, and you want to power it, flash it, watch its console and get your build onto it, without re-cabling anything and without needing to be in the same room.

🔁 Hardware in the CI loop

You want every commit tested on real hardware, driven by GitLab CI, Labgrid, LAVA or KernelCI.

🤝 Sharing a DUT

You want someone outside your team (a customer, a partner, Linaro support) to use your hardware, without giving them access to your lab network.

Which one is for me?

	Developer	CI	Sharing
DUT user	You, interactively	A pipeline or a scheduler	Someone outside your team
Main interface	Web UI, laam or SSH	GitLab runner, LAVA, Labgrid, KernelCI	Web UI or laam
Driven from	Your laptop	The CI service	The internet
Setup effort	Minutes	Hours, if enablement is needed	Minutes
Needs LMS configuration	No	Yes	Only for Linaro remote support

They are not exclusive

The same appliance can be used interactively today and enrolled as a CI runner tomorrow. The DUT wiring, the MIB and the serial console configuration are shared between all three use cases. What changes is who is allowed to talk to the appliance, and through which interface.

What every use case shares

Whatever you do with it, the LAA gives the DUT the same environment:

• a private network where the DUT is always 198.18.0.2 and cannot reach your lab network

• network services for the DUT: DHCP, DNS and NTP, plus TFTP and NFS shares for automation

• managed power rails, USB ports and serial consoles driven by laacli

• OTA updates with rollback managed from LMS

Before any of them, the appliance has to be unboxed and put on the network: start with the QuickStart and the Connectivity guide.