Board Farm APIs for Automated Testing of Embedded Linux

Schedule

In this talk Tim Bird and Harish Bansal reported on the state of their unified API for Board Farming. The term Board Farming in Embedded Linux development describes the situation where you have infrastructure to remote-control a lot of Embedded Linux devices in some sort of lab. The basic idea behind a unified API for controlling of such a lab is simple: In open source a problem usually has to be solved once. Afterwards it's all about using or improving an existing solution.

This is not the case for testing of Embedded Devices. There is a lot of fragmentation in how a lab is controlled and how tests are structured. In consequence tests are rewritten all over the community - or some things may not be tested at all.

Tim and Harish present a the specification of a REST-API that tries to cover the most important interfaces to control an Embedded Device in a lab. With this specification it should be possible to add a thin adaption-layer on top of whatever hardware abstraction is running a lab to allow third-party test suits to run on your lab. The REST-API specification is available on the Timesys Github.

Tutorial: Debugging Embedded Devices using GDB

Schedule

For a lot of my colleagues in software development using GDB to remote debug software on a device under test is a common case. But even in hardware development I am often confronted with software problems - so adding another tool to my toolbox sounds like a good idea.

In this tutorial Chris Simmonds gives a broad overview on how to remote debug on a target using GDB. Chris does a great job in giving a step-by-step introduction in how to set up GBD and GBD-server and gives a lot of usability hints. All resources (slides, Raspberry Pi Image, Yocto SDK and more) are available on 2net.co.uk.

Unfortunately I had no SD-Card for my Raspberry PI at hand. Thus following all steps myself is still on my personal TODO-list.

When You Come to a Fork in the Road, Take It

Schedule

Paul Gazillo views the Linux kernel from an academic perspective, and tries to find minimal Kconfig settings that are necessary e.g. to trigger a certain bug, or to test patches for their effectiveness. In essence, it turns out, that this problem can be reduced to a boolean satisfiability problem, and he also explains the tools he and his team wrote for this purpose, and how they can help during kernel development. Although (or because?) this is an academic talk, it was well structured and explained the matter at hand very well.

The State of Open Source Licensing Clarity (or the lack thereof)

Schedule

Of course, this talk is just another opportunity to talk about SPDX, right? :-) But Philippe Ombredanne also shows the underlying problems with the licensing situation in the current open source and free software world, why "This code is GPL" is not enough as a software license, and the ideal criteria that a software package should fulfill in terms of licensing. After all – without licensing, there is no FOSS, and unclear licensing makes it harder for everyone to build in top of existing software. He also shows results from his own work analysing a large catalog of open source software packages and assigning a "license clarity score" to them, and proposes three solutions to improve the current situation.

Introducing TPM NV Storage with E/A Policies and TSS-FAPI

Schedule

Andreas presents an introduction into the non-volatile storage and policy components of modern TPMs. He also presents usable examples from the tpm2-software project on how to employ policies to create storage areas which fulfill certain requirements, such as write once read many (WORM). On the policy side, he offers a great explanation of the possible abstractions to write policies in, either from a low-level or high-level point of view. The presentation of TSS2-FAPI is especially interesting, since the modeling of policies using JSON is much more approchable than writing low-level policies in TSS2-ESYS.

Using the TPM - It's Not Rocket Science (Anymore)

Schedule

Johannes und Peter gave a comprehensive overview of TPMs, their APIs and why one would want to use them. They explained how the TPM2-Software Community has improved the support of TPMs by implementing the higher-level APIs, especially in the area of defining policies. As the TPM2 stack supports several alternative APIs (native SAPI/ESAPI/FAPI, PKCS#11 or OpenSSL engine), it's possibly to let applications access hardware protected keys even if they don't have explicit TPM support. If you want to access the TPM directly, there are Python and Rust libraries in addition to the classic C API.

Share System Resources on Multi-Processor System

Schedule

Lionel explained how the needed for coordinated access to resources (such as clocks, resets and power) is growing with modern SoCs such as the STM32MP1: CPU cores for different use cases (Cortex-A for Linux, Cortex-M for bare-metal real-time and system management) share periperials, both statically and dynamically.

He continued with the possible approaches to implement a system manager either as a dedicated core or as high-priviledged software on a shared core. For ARM CPUs, the SCMI standard defines transports and interfaces which can be used by the different agents to request the resources they need. Lionel reported that SCMI support is merged for release in OP-TEE, TF-A and U-Boot which should make it possible to use this on the STM32MP1 with upstream code soon.

What the Clock! - Linux Clock Subsystem Internals

Schedule

The Linux common clock framework (not to be confused with POSIX clocks, clocksource or clock events) clk_ family of functions is now a prevalent sight in most SoC drivers. Niel talks about its beginnings and how it fared so far mapping the physical reality of different clock generators, PLLs, dividers, gates and muxes onto a uniform software interface. Informative watch as introduction into what the framework is supposed to do and how it does it.