Open Source Summit Europe 2024

PWMs are used in a wide range of applications. Most in-kernel usages have only soft requirements regarding precision and switching behaviour (LEDs, fan control, backlight). However if you control a motor you might have higher demands that currently cannot be mapped generically using the current PWM API given the wide variance of hardware drivers and hardware limitations. In this talk Uwe presents his vision how the PWM framework can be changed to better match the needs for higher precision and better control of PWM devices. This includes: * faster and easier control from userspace * tighter rules for lowlevel drivers * a way to determine the best request for a given use case on a certain hardware * more general abstraction of the PWM waveform

Ever since the GPIO character device was introduced as a proposed uAPI replacement for the deprecated sysfs interface, users have been pointing to the lack of persistence of GPIO state (as in: once the user-space process closes the file descriptor associated with a set of requested lines, their state is no longer defined - in practice: it's driver dependent) as the main issue with the new approach and a significant blocker in porting code from sysfs to libgpiod. Two solutions have been proposed: making the GPIO state persistent in the kernel or providing a centralized authority for controlling GPIOs from user-space. For various reasons the former has been rejected which led to the development of gpio-manager: a user-space daemon built on top of libgpiod that exposes an API to authorized clients and controls GPIOs on their behalf. This talk will present the features of the daemon, the DBus API it implements and the companion command-line client - gpiocli - which aims at allowing straightforward porting of sysfs-based scripts to the new interface.

Before setting up a test automation framework for your Yocto project, it is worth considering which options are available and most suitable. In this talk, we will explore which tools are appropriate depending on project complexity and scalability. For a small Yocto project where a test environment needs to be up and running as quickly as possible and only one piece of hardware is supported, a complete test setup can be created using only the testimage class for image testing and ptest for package testing. The tests can be carried out locally or in a CI/CD system. Using Gitlab CI/CD as an example, we will show how the results of testimage can be neatly displayed as a unit test report. For more complex projects that support a variety of architectures and require tests to be automatically scheduled on devices, it is advisable to use an automated test framework. We will demonstrate how ptest and pytest can be integrated into a LAVA test environment and what alternatives to LAVA exist.

8 years ago, at ELCE 2016, Geert talked about the benefits and modalities of organizing development boards in a board farm, and he introduced his personal board farm. Since then, more boards found their way into his farm, with more to come. Also, other developers asked him for remote access to his boards. In this presentation, Geert will talk about the evolution of his board farm. He will tell you about things that worked well, or didn't work well, and how he improved his farm, using readily available or custom hardware. He will discuss the challenges of growing your farm, in a changing world plagued by supply chain hick-ups. He will present a way to share boards in your farm with other developers and (automated) testers, using the backend-agnostic "FRAM" tool to grant remote control to only one or more boards, and not to your whole local infrastructure.

In face of the strict requirements of the CRA legislation on the horizon for EU markets, one of the key techniques to rapidly test new software releases is an automated testing setup. This session wants to collect the current state of the automated testing landscape and discuss current development directions, tools and projects. We will provide a quick summary of current projects in the space and than have a quick vote on which topics to discuss. Thereafter we encourage discussion between the audience members.

We'll be using a shared document to gather topics before and during the BoF and collect notes during the discussions:

https://docs.google.com/document/d/1oM0AREY_X-3QMBb8SRUHq1yYcJ4BaWE39gYxmYkr8AI/edit?usp=sharing

Considering a context where the hardware platform disposes of a restricted amount of RAM, developers need to understand how this resource is managed and consumed by the operating system and the applications running on it. In such situations, it is crucial to use the right metrics and tooling to identify which components are excessively allocating resources, trim them down, and finally get close to the strict necessary memory usage without compromising essential features. This presentation explores RAM management in the Linux kernel, focusing on how much memory is allocated across different areas and for what purposes. From a kernel space perspective, it will dive into the components of memory reserved in early boot. Considering the user space perspective, the presentation will explain how much memory is used by processes, both individually and collectively.

Linux-based embedded systems are increasingly common, yet they often face security challenges. While Linux already has a good set of security features, it is often not trivial to choose the right ones and use them properly.
In his presentation, Richard will discuss the typical issues he sees when collaborating with clients on embedded systems.

He aims to highlight essential pitfalls to steer clear of in your upcoming projects.

Mesa3D, often called Mesa, is a key part of the Linux graphics system, serving as an open-source implementation of the OpenGL API for rendering 3D graphics. It also supports other APIs like Vulkan and OpenGL ES.

This session will demystify Mesa3D, starting with GPU functions and its interaction with computers, laying the groundwork for understanding how Mesa powers 3D graphics. We'll use rendering a triangle as a case study to explore Mesa3D’s architecture—from initiating EGL and compiling shaders to sending work to the GPU, making the complex process more accessible.

The goal is for everyone to walk away with a clearer understanding of Mesa’s role in Linux graphics and its importance to the open-source community, specially on embedded platforms, where open-source drivers are getting much more relevance for long term maintainability, feature support and customization.

Here, I mention embedded platforms because many of our customers use open-source drivers. This allows them to include these drivers in their products without depending on proprietary solutions from manufacturers, which may not even be available (some are only available on Android, not Linux).

Direct Memory Access frees up the CPU for other important work, while devices read and write data in the background. This is as good as it sounds and most embedded systems make ample use of this; for good sound and otherwise. On the flipside, incorrectly configured DMA and the creeping memory corruption that results can decidedly be more unpleasant than the possible slow-down of using PIO. Ahmad's bootloader and kernel escapades have not been spared from the wrath of DMA masters. In this talk, he will share tales of his debugging campaigns and how tracking down memory corruption led him to learn, one bug at a time, more about the internals of Linux' and barebox' DMA API, ARM cache maintenance and the limitations of DMA controllers.