RAUC Field Update Demonstrator

Here we demonstrate robust and secure image-based updating with the flexible RAUC update framework. Six Raspberry Pis represent a fleet of devices that we would like to maintain.

Updating is always a necessary but critical step during the life cycle of an embedded system. Updates are important - either to fix system bugs, solve security problems or simply to add new features. But, as embedded devices are often placed in locations that make them difficult or expensive to access, updates must be performed unattended and thus have special needs in terms of robustness and security.

In practice, the actual deployment mechanism can vary from simple individual updates over USB sticks up to fully automated network-based deployments using sophisticated roll-out scheduling strategies.

RAUC itself focusses on being a lightweight service that reliably controls the process of updating your device with a new firmware version. It is flexible by design and can handle all common system layouts. And of course: it's Open Source and licensed under LGPL.

In our demo, all Raspberry Pis are connected via WiFi to a central deployment server running the Eclipse hawkBit roll-out framework. The RAUC hawkBit Client, also a RAUC project, interfaces between the hawkBit server and RAUC. This setup demonstrates one possibility of using RAUC in a larger context with custom roll-out scheduling.

The devices are running two variants of firmware: one based on Pengutronix' PTXdist, the other based on Yocto - two completely different Embedded Linux distribution build systems, but both equipped with RAUC.

In the demo, the update is scheduled in 3 phases. When the devices of the prior phase did update successfully, the next phase will be scheduled.

When an update is scheduled for a device, it will download the new image. After successful cryptographic verification, the image will be written to the next free slot. If this is successful, the new image will be marked as "active" and the system will reboot. The bootloader will now select the new image.

Latest developments and added features for RAUC are:

• Streaming updates over HTTP(S) without the need for local intermediate bundle storage
• Full encryption of update bundles
• Built-in incremental updates for partition images

Labgrid / LXA Test Automation Controller

Engineering a working Linux for your Embedded Device is one thing. Maintaining this software stack over security updates and new features, maybe even for 10 or more years, is a completely different story.

Automated testing of the complete embedded software on real hardware plays an important role in maintaining the device for a long time. In this demonstration we will show you some tools that can help you with this challenge.

The first component is Labgrid: Labgrid is a Python-based Open Source board control library. It allows you to interactively control embedded devices on your desk - or at a remote location. It also has a strong focus on automation: You can either use it as a library in your scripts or as a pytest plugin. This way, you can run tests on real hardware that feel like pure software testing.

The next component is a product from our spin-off: Linux Automation. Our Test Automation Controller (TAC) connects the physical world to labgrid. It provides interfaces such as an UART, a power switch with voltage and current measurement, USB host and device ports and general purpose I/Os.

The test controller can be powered using Power over Ethernet (PoE) and has an integrated Ethernet switch. This means, that in most cases, you only have two connections to your test setup: power for your device under test and Power over Ethernet for the Test Automation Controller. The device runs Linux based on Yocto. Of course, the Yocto layers will be released as Open Source once the device is launched. It will most likely be available at the end of 2022.

In this demonstration we run a few tests on the device under test (DUT), in this case, a Beagle Bone with a separate motor board.

At the beginning of a test-run, labgrid switches the device off and provisions the newest software image on the SD-Card using the USB-SD-Mux. Afterwards, the DUT is powered on and labgrid interrupts the boot process to run a first test inside the bootloader. Then, the boot process is resumed and labgrid takes control over the Linux shell.

In the shell, the main functionality of this device is tested: We want to spin the disk at a given speed. By slowing the disk down manually, we can let the tests fail intentionally. In a real-world scenario these results would now be collected by the test runner and some engineer would have to investigate what has happened. But in our demonstrator the process simply starts over again.

i.MX8MQ Four Video Demo

Here, we will show you a use-case for hardware-accelerated video decoding and output on the NXP i.MX8MQ. The hardware is an entertainment panel, as sometimes seen on airplanes or long distance coaches and features a 4K display. The real-world use-case for this device would be to play videos either from local or network storage or from your own smartphone. The software stack running on this device consists of Mainline Linux, GStreamer, Qt Quick, OpenGL and the Etnaviv graphics driver. So, the software is one hundred percent Open Source - no vendor blobs needed. This gives you full control over the software running on your device and reduces dependencies on any single supplier.

In this blogpost, Lucas Stach takes a deep dive into the issues we had with the closed source driver for this GPU in the past and shows how the Open Source drivers solved these problems.

Rockchip with Mainline Linux

In this demonstration we show you the driver for the VOP2 display controller used on modern Rockchip SoCs starting with RK3566 / RK3568, which was recently merged into the Mainline Linux kernel with 5.18. Think about it as a hardware unit that transforms a rectangular piece of memory into signals for your display.

Traditionally, our customers have been using well established European or American CPU vendors for their industrial, aerospace or medical devices. But since a few years Asian vendors have been targeting these markets as well. Now add a global chip shortage for devices from western suppliers: This makes devices from the Asian market even more attractive; simply because you can buy them.

In this case a customer selected a Rockchip SoC and decided to invest in mainlining the still-missing components into the Mainline Kernel. So our colleague Sascha had the opportunity to get the drivers for these components ready for merging by reworking them according to the requirements of the upstream kernel.

Open Software on Open Gateware

Here we demonstrate Linux booting to a login prompt on a soft core RISC-V. While this might not look like much, there are many interesting parts under the hood:

The board is an ECPIX-5, which is built around Lattice's ECP5, a medium size FPGA. In the last few years, the open FPGA toolchain community has improved the support for this FPGA to the point where it's often easier and faster to use LiteX, Yosys and nextpnr to generate the bitstream from a high-level description of the SoC.

The ECP5 has no built-in CPU, so we have to include a CPU in the FPGA bitstream. As RISC-V is free and open architecture, of course there are also free and open FPGA IP cores available such as the multi-core vexRiscv from SpinalHDL, which was used in our demo.

We used Yocto to automate the full build process of the gateware and software from source, ensuring full reproducibility. As the upstream FPGA toolchain is still evolving quickly, this approach makes it possible to perform pin-point fixes without the risk of running into incompatible changes.