About the joy and tears of testing Embedded Devices (Chris Fiege)

Embedded development is complex enough. By automating repetitive parts during development and employing testing, a lot of time can be saved and human errors avoided. Additionally, embedded development is usually a team effort: scarce hardware must often be shared between developers and sometimes even with automated testing. labgrid is an open source tool for remote control and testing of Embedded Linux Devices in a distributed lab. In this talk the presenter takes a look at how labgrid can be used in your Embedded lab and what labgrid's developers have learned in over three years of using and developing it.

At first the presenter takes a closer look at what is actually needed to fully remote-control an Embedded Linux Device: What are the typical interfaces that need to be covered? What remote-control hardware is commercially available?

Next the presenter will focus on the labgrid framework. Labgrid is an embedded board control python library, with a focus on testing, development and general automation. After a short overview of the key design-concepts the presenter will discuss labgrid's architecture. This part finishes with a demo of how interactive development with labgrid looks like and how tests are implemented using pytest.

The talk will conclude with a lessons-learned with the joy and tears of over three years of active labgrid development and use.

From Reset Vector to Kernel: Navigating the ARM Matryoshka (Ahmad Fatoum)

Long gone are the times of executing the OS in-place from memory-mapped flash upon reset. A modern SoC now comes with complex mask ROM firmware, with driver, filesystem, protocol and crypto support for loading... yet another bootloader.

In his talk, Ahmad follows this chain of bootloaders until the kernel is started, stopping along the way for RAM setup, peripherial initialization, runtime services and other interesting sights.

Getting acquainted with the bootstrap process on a modern ARM-based SoC can be an intimidating task: Documentation speaks of Boot ROM, blobs, SPL, secure monitor, trusted execution environment, Open Firmware Device Trees all interacting with each other and with a bootloader to facilitate kernel boot.

The talk intends to shed some light onto this. Starting with an overview of the bare minimum needed to bootstrap an i.MX8M, it retraces the steps of the barebox bootloader, and firmware loaded by it, until Linux eventually takes over.

The Road to the Mainline ZynqMP VCU Driver (Michael Tretter)

The Xilinx ZynqMP SoC includes a powerful H.264/H.265 Video Codec Unit (VCU) which Xilinx supports with an out-of-tree driver and user space library. The allegro driver from mainline Linux allows to use the VCU using the standard V4L2 encoder API without requiring any custom user space.

I will explain why I wrote the driver, show how the VCU is used from a driver perspective, and present the current state of the driver and which features are still missing.

The Zynq UltraScale+ MPSoC integrates several ARM cores and an FPGA into a single chip. One variant of this SoC includes an H.264/H.265 Allegro DVT Video Codec Unit (VCU).

Although Xilinx did a good job supporting the ZynqMP in mainline Linux, the VCU was originally only supported via an out-of-tree driver. It consists of a user space library and a firmware blob, which interact via a custom IOCTL interface. Unfortunately, this has security implications as the user space handles physical buffer addresses.

Fortunately, the V4L2 mem2mem device API for video codecs avoids this problem by using abstract DMA buffers. Many applications already use these APIs, and various drivers for hardware codecs already implement these APIs. Thus, a V4L2 driver for the VCU allows reusing existing applications such as FFmpeg and GStreamer on the ZynqMP.