Open Source Summit Europe 2024

Over time, many features have been introduced into the Linux kernel to tackle various Power Management related needs. Most features rely upon the device model to provide its features, making each feature in isolation have rather understandable behavior and straight forward APIs. Complexity can creep in however when those various features interact with each other. We'll therefore cover features in isolation: system-wide suspend, hibernation, runtime power management, power domains, Quality of Service, etc. On each new step added, we'll stop to reflect on potential interactions or conflicts with previously seen features. Some of those will come from concrete issues encountered during the upstreaming effort of Suspend-to-RAM support on an automative SoC, the TI J7200 platform.

The Linux Kernel has two subsystems that handle external pins: pinctrl that handles function muxing and electrical characteristics, and GPIO that handles generic input/output usage on individual pins. Depending on how the hardware is implemented, the two could be completely separate, or deeply intertwined. This presentation will introduce the hardware integration designs , how they should map to the kernel subsystems. We will dive deeper into the latter case and show how the kernel subsystems can handle it properly with "strict" GPIO pin muxing, and what could happen if the driver isn't implemented correctly, using existing in-tree drivers.

DeviceTree (DT) based systems usually lack a platform or firmware based device power management framework. Device drivers are left to figure out if a device is already powered on at probe and duplicate power management logic to manage system resources such as clks or interconnects. This is unlike ACPI based systems where the firmware provides standardized device power states to power on or off a device and mostly hides system resources behind a firmware interface. This session will make the case for implementing an ACPI-like power management framework in the Linux kernel via pmdomains registered by a System-on-Chip (SoC) driver. First we'll discuss the problem and previously attempted or ongoing solutions. Then we'll cover a case study implementing an SoC power management driver. Attendees will leave with a greater understanding of SoC power management techniques and the problems kernel developers face in supporting such hardware upstream along with a possible solution to implement this design elsewhere.

Imagine a world in which you can try the Yocto Project without even using it. This was possible in the past with the Ångström distribution, offering ready-made images which could be extended through binary package feeds. Though Ångström is long gone, the Yocto Project still has the ability to generate such images and package feeds. While system makers are still using this feature, the Yocto Project itself has never published such binaries. The Yocto Project, thanks to funding from the Sovereign Tech Fund, has recently developed its abilities to support binary distributions, by creating tooling to verify the ability to upgrade the images built for its releases through package feeds, and to support managing a "local" distribution that can customize packages offered by an "upstream" distribution. Since Yocto is about recipes, I will first present a cookbook for building your own images so that they can be updated through package feeds. I will then describe the recently developed features related to binary distributions and what possibilities they open for the Yocto Project and its users.

RISC-V is an open instruction set that is taking the world by storm, enabling new and creative hardware designs across the spectrum of computing devices - many of which are themselves open. This BoF is a meeting place at EOSS to discuss the current state of RISC-V as well as the RISE Project, an open source initiative under LF Europe to support the RISC-V software ecosystem.

This BoF provides an open forum for the Embedded Linux community to ask questions and discuss issues with the Yocto Project and OpenEmbedded community. We open with a Yocto Project summary and OpenEmbedded State of the Union. All users, contributors and maintainers as well as curious minds are invited to bring their thoughts and topics.

Building embedded Linux systems is getting increasingly complex. The complexity does not only come from the technical aspects. The number of different packages and dependencies also make the fulfilment of license obligations quite challenging. Build systems and distro generators support us with this task. They can help in getting an overview of the licenses being used and packaging the relevant compliance material. But how far does their support really go? And is the information being provided complete?

This presentation will take a look into different licensing obligations (e.g. information obligations and disclosure obligations) and (based on the examples of the Yocto project, ELBE and ISAR) the licensing support of modern build systems will be evaluated.

Tracing is a capable mechanism for deep system analysis and profiling with a minimal overhead. By recording defined system events, in Linux but also Android, tracing can be used to analyze concurrency or latency issues, for example. Android’s systrace tool made it easy to analyze and correlate traces and events due to a graphical UI, in order to help developers identify performance bottlenecks. The successor to this advanced and convenient tool is called Perfetto. It’s available for pure Linux too, and part of Yocto (meta-oe) since Langdale now. In the talk, we’ll have a look into - using Perfetto with Android and Yocto, - adding trace events to your applications, - recording traces and - analyzing system and application traces with the graphical GUI. This will allow you to take full advantage of the Perfetto trace viewer UI for analyzing memory usage, CPU scheduling, latency and more.

It is challenging to debug hard to reproduce crashes on embedded devices. Due to limited space constraints, it is often not feasible to deploy full debug symbols. Core dumps are a great tool to debug such crashes. The Yocto project offers several features to help with working with core dumps, such as minidebuginfo and debuginfod combined with debug symbol servers. Used with crash-monitoring software and systemd core dump tooling, those features make it easier for developers to analyze and solve crashes happening only e.g. in production.