BayLibre does HW and SW support for embedded (Linux) systems, and also does kernelci.
Lab in a box = PC with stuff to connect a board and running LAVA.
KernelCI is a distributed test farm on 250 boards doing 2700 boot-tests per day. Pulls from various trees, builds various configs, distributes them to the boards, and sends the results to the relevant mailing lists. The build servers that pull the git repos and build the kernels are centralized, the boards are distributed in a dozen labs. The Lab in a Box is an easy-to-set-up lab. Also AGL uses the KernelCI tools but with a different centralized test master.
First reason for Lab in a box is to clean up the cable mess and shelves. Provide something that is easily maintainable, shareable and easily duplicated. Also simplify the administration (i.e. deploy LAVA, now easier though through the use of Docker, simplify device description, simplify which tty device is which board) by adding a web administration & control panel. Ultimately, accelerate deployment. Everything in one case, including the software. But still relatively low cost.
- A lot of stuff in one box, not much space.
- Power control, different boards have different supply requirements.
- Make it easy to install a board so you don’t have to spend a day to install a board.
The box is a normal PC tower with
- Celeron quadcore with 8GB RAM and 120GB SSD – required for LAVA.
- Plenty of fans in case cooling is needed.
- ATX power supply also powers the boards – it provides 5V and 12V. This saves on power wiring.
- Home made power measurement and control board called ACME cape on BBB.
- USB hub for network consoles + FTDI USB serial cables.
- Network switch. Each device on a separate LAN. Lavabox itself needs internet access to connect to kernelCI.
- 6 DUT: RPi3, BBB, Le Potato, DragonBoard, R-Car M3, SABRELight. They are installed in drive bays, so easy to insert and remove.
BOM cost (ex. DUTs) about 400 EUR, but you can use components that you already have to reduce costs.
For DragonBoard, it’s fastboot so extra USB cable to drive fastboot. Some don’t have Ethernet so instead use NCM gadget or USB storage. Some devices are powered over USB.
LAVA slave provides the DHCP, TFTP, NFS, … It also knows (through config) the USB-serial ports to the boards (using udev rules, FTDI cables have a unique ID). Manages update through fastboot or USB storage where needed. lavapdu-daemon controls power of each board, with backends for various PDUs including BBB-ACME.
LAVA master schedules the tests. It also has the descriptions of the boards and gives them to the slaves (even though they are no use to the master, would be more logical to put this on the slaves). Board has a device-type (e.g. BBB, includes how to boot and give it a kernel) and device (instance, specifies which ports etc. to use). Written in jinja2 templating language, which makes it very powerful e.g. can set up custom things for a specific device.
squid proxy to avoid downloading the same kernel from kernelci.org over and over again.
All the pieces are in docker containers and combined with docker-compose.yml file.
Lab in a Box is an example, you can build your own and replace any of the components. The SW doesn’t depend on the specific HW, thanks to the LAVA abstraction layers that put everything in config files.
- Less of a mess, can all fit in a nice box. Fits comfortably in an appartment.
- Integrated SW and easy administration (still under development).
- Good demonstrator to evangelise CI.
- Easy to replace DUTs.
- Tedious to build the PC case. Needs drilling and soldering.
- Pretty densely packed so not easy to build.
- Limit on DUT size to fit in a drive bay.
- Only 5V and 12V DUTs, and must be balanced across ATX outputs. Can be solved with a higher-power ATX supply that has more rails.
- No button presses for boards that need that, need separate relay for it.
- Even with a larger case, it wouldn’t be possible to add more devices: wiring is the limitation.
- Does not really scale to installations with dozens of boards. Develop a rack-mounted solution for that.
- No standard DUT connector for the boards, it’s always custom wiring. Should work with board manufacturers to develop a standard connector.
- Too complex and expensive for a 1-board lab. Build mini version for this use case.
- Administrative control panel doesn’t exist yet – currently a YAML file.
- No documentation (yet).
Competing project: a nanoPi hat that connects to a single DUT, that will be open hardware. Published on Tizen wiki.