Contributed by Ariel D’Alessandro, Collabora
TL;DR: As RISC-V adoption grows, the need for reliable, scalable hardware testing infrastructure becomes critical. To address this gap in the ecosystem the RISE Project and Collabora added two RISC-V boards (Banana Pi BPI-F3 and SiFive HiFive P550) to Collabora’s public LAVA testing lab. Using tools like LAVA and Boardswarm, this project enabled full remote automation, from high-level OS testing to low-level recovery and reflashing of the bootloaders. This initiative provides the open-source community with a crucial, publicly accessible hardware-in-the-loop testing facility for RISC-V and fully documented instructions for developers to replicate the setup
The RISE (RISC-V Software Ecosystem) Project is an initiative under the Linux Foundation dedicated to accelerating open source development for the RISC-V architecture. One of the key challenges the ecosystem has identified is the limited availability of easy and reliable hardware-in-the-loop testing with RISC-V platforms. Addressing this gap is essential for fostering innovation and broadening the adoption of RISC-V technology.
At Collabora we’re big believers in the value of hardware in the loop (HIL) testing of open source software. For this purpose, Collabora runs a big LAVA testing lab with close to 400 devices of almost 70 different types. This lab is used by various open source projects such as KernelCI, Mesa, and Apertis for HIL testing.
As part of the RISE RP012 project, we worked with RISE to add RISC-V boards to the Collabora LAVA lab. This setup has been fully documented to make it easy to reproduce for those wanting to create their own board farm. For this purpose we used:
Lab enablement was broken down into two parts: LAVA enablement, and lower-level testing of the boot chain. First was the more standard LAVA enablement, which essentially boils down to a combination of automated power control, serial console, and a network capable bootloader. For both device types, this allows LAVA to turn on the device, take control of the bootloader (u-boot), network boot the test system, and drive the tests over serial once booted. This is enough to allow both kernel and Linux userspace testing.
The second part of enablement focused on allowing lower-level testing of the initial boot chain (u-boot, opensbi, etc), in an interactive way. To support this we’re using the Boardswarm board service. For a deeper dive, check out our previous blog post Meet Boardswarm, a new Open Source tool for board management and distributed development.
To understand how this works, some background on SoC boot flows is required. The first instructions that run after power on any SoC come from the BootROM, which is hardwired in the SoC itself. One of its main responsibilities is to load and execute a first stage bootloader (FSBL), the first software any system executes. On a “normal” boot this resides on a form of local storage, e.g., SPI flash, eMMC, SD Card, UFS, etc. However all modern SoCs also have boot modes that allow uploading a first stage bootloader to the SoC instead, typically over USB. The main use cases of this functionality are to either load initial software onto the device or recover the device. The exact jargon used is different per vendor, but “download mode” is probably the most common term.
Almost all development boards have ways to enable this mode, often as simple as a button that has to be pressed during boot or some DIP switches that have to be set. In the case of the Banana Pi F3, this is a button, requiring a little bit of hardware hacking to enable automatically “pressing” it. The SiFive board, apart from physical DIP switches, also has a small micro-controller which, among other things, allows configuring boot modes via a serial interface. As part of this project we added support for this serial interface to Boardswarm, so that it can be used for power control as well as boot mode configuration.
After powering a device in “download mode”, the next step is to actually upload a loader to it. The protocol used for this is defined by the SoC vendor. In the case of the Banana Pi, it actually pretends to be a USB drive. It simply expects a first stage bootloader to be written as a single file on that drive—something we’ve added support to Boardswarm to do. For the SiFive, the BootROM implements the fastboot protocol (as defined by the Android project). While Boardswarm already supported the fastboot “flash” command, it had to be extended to support the fastboot “stage” command required by the BootROM. This essentially tells the fastboot implementation to just download data to memory, without writing it to storage, but staging it for execution as a next step.
Once the first stage bootloader is loaded, we’re now in full control as the board is running software of our choice. For both boards these loaders have been configured to start fastboot over USB, which can finally be used to reflash the local storage with the intended boot loaders. In the case of the SiFive, we added u-boot support to write SPI flash memories over fastboot to avoid vendor custom commands and stick to standard fastboot implementation.
All this combined means we can fully remotely reset a device, switch to download mode, and replace all software. While this all seems quite complex, it is actually a reasonably simple flow for both. Better summarized by some diagrams:
After all this work, both boards are available in the Collabora LAVA lab, ready to be used for upstream testing by projects such as KernelCI. For those considering creating their own lab setup, documentation is of course available.
The documentation described in detail the bring-up and enablement of both platforms:
- Required hardware setup and BOM for board bring-up
- U-boot boot chain sources and artifacts
- Bootloader update mechanism
- Boardswarm configuration for automation and remote control
- Debian and Linux Kernel artifacts for LAVA testing.
These integrations mark important milestones in continuous integration and testing for RISC-V, providing the foundation needed for robust software development and long-term platform stability in such critical components as the Linux kernel.
