OSS + ELC EU 2026

Traditionally, Linux has been fully responsible for and in full control of all hardware components in an embedded system, as described by its Device Tree (DT). With the advent of heterogeneous System-on-Chips (SoCs) with multiple CPU cores (Application and Real-Time) and security technologies (Secure Boot, Trusted Environments, Virtualization), this is no longer the case. To avoid compromising system integrity, Linux must now be prevented from controlling system resources used by other CPU cores, and cannot be tasked with control of shared system resources, while Linux still needs to access these resources.

The Arm System Control and Management Interface (SCMI) is intended to solve this, by providing a firmware interface to handle access to system resources like clocks and power domains.

In this presentation, targeting Embedded Linux Developers and System Architects, Geert will give an overview of SCMI, and its impact on DT hardware description. He will discuss the challenges of supporting multiple evolving firmware versions and lineages, and possible solutions, based on experience gained while upstreaming Linux support for R-Car X5H, Renesas' fifth-generation automotive SoC.

Modern SoCs have a variety of CPU cores on board - e.g. on ARM we often see Cortex A, plus Cortex M, plus System Controllers. The number of cores is as increasing as the demands. Concepts like 'Software Defined Vehicle' (SDV) from the automotive sector is just one example for such complex demands. One obvious requirement is to run other OS than Linux on dedicated cores. Which means that resources like memory, clocks, pin control, power domains, etc. may not be under the sole control of Linux anymore. They now need to be shared and synchronized between all the participants. How does this work in practice? How do technologies like remoteproc, rpmsg, mailboxes, hardware spinlocks, virtio, and devicetree come into play here? How is their status-quo? And what about the non-Linux sides? What is open, what is proprietary, and how does this affect actual solutions? This talk is the result of a journey trying to support LinuxZephyr based AMP using a complete FreeSoftware stack on a Renesas community board.

Over time, Pulse Width Modulators went from simple devices with only an input clock and a prescaler to more complex ones.
Nowadays, we can find PWM with several input clocks, several channels, shared and unshared prescalers among channels, and even bypasses which permits the PWM to act as a clock provider itself.

This talk covers a presentation of PMW basics, how to write a kernel driver with the new PWM waveform internal API.
Then, we will present a complex real life PWM device (Allwinner H616 PWM) and show how to leverage the power of the Common Clock Framework to help writing the kernel driver.
We'll continue with use cases of the H616 PWM internal bypass, which short-cuts the PWM logic and outputs a sine wave.
And finally, we'll show how to handle this bypass in the PWM driver and in the device tree.

Containers ship everywhere, yet their software supply chain remains murky. Today's SBOM tools work backwards, scanning a finished image to guess what's inside — an approach prone to omissions and inaccuracies that the EU Cyber Resilience Act will make increasingly untenable.

The Yocto Project uses a fundamentally different path. Because we build everything from source, we generate an accurate, complete SPDX 3.0 SBOM during the build, not after it — with full license and provenance information. In this presentation, we discuss a new approach that lets us build minimal, multi-layer OCI container images using standard Yocto tooling, with no special privileges required, to produce repeatable and auditable results.

We will demonstrate end-to-end automation on the Yocto Project AutoBuilder: building reference container images, attaching SBOM and license attestations, signing them, and pushing to public registries. Attendees will leave understanding how reproducible builds, from source, close the container manifest gap — and how to consume these images today.

Modern OSPI NAND devices are pushing the Linux SPI memory stack beyond its original assumptions. Features such as DDR transfers, continuous read modes, multi-frequency operation, and PHY tuning promise substantial performance improvements, but at the cost of added complexity. Furthermore, there is no well-established standard for these implementations, leading vendors to adopt different approaches and assumptions that software must accommodate.

This talk will walk through recent upstreaming efforts to enable advanced OSPI NAND capabilities in Linux. We will focus on one of the most challenging aspects: the introduction of fine-grained PHY tuning, which allows operating frequencies to be doubled or even tripled, enabling significantly faster transactions between the NAND device and the host controller.

Introducing such features has raised a number of architectural challenges. We will discuss both the specifics of PHY tuning and the broader subsystem considerations required to support increasingly sophisticated flash devices. Particular attention will be given to integration challenges across the SPI-MEM and MTD stacks, as well as the lessons learned while upstreaming the solution.

Reducing electromagnetic interference (EMI) is often a key requirement for embedded products seeking EMC certification. Spread Spectrum Clocking (SSC) is a common hardware technique used to lower peak emissions by slightly modulating clock frequencies.

This talk describes the journey of bringing SSC support to the Linux Clock Subsystem on platforms such as TI Sitara, STM32 and i.MX8M. The work started from customer requirements and platform-specific solutions, then evolved into a more generic approach integrated with the Linux clock framework and Device Tree.

After a brief introduction to SSC and the real-world use cases behind this work, the talk explores the challenges of exposing SSC configuration through Linux abstractions. We will cover the design of new Device Tree bindings, the implementation of SSC support within the Linux clock framework, and the upstream review process that helped shape a reusable solution across different SoCs, highlighting how Linux can turn existing silicon capabilities into practical product solutions.

This talk clarifies what Hafnium secure partition manager is, where it is useful, and how to port it to a compatible SoC. First, Marek explains the ARM CPU core exception levels and security states, elaborates which software usually runs in the secure world, which does include TEEs, and clarifies why running only a single TEE instance may no longer be sufficient. Next, Marek introduces Hafnium secure partition manager, which allows running multiple isolated software instances in S-EL1, called secure partitions. Marek explains where Hafnium and secure partitions fit into the CPU security model, how other components of the firmware stack interact with Hafnium, and how Linux interacts with the software in secure partitions. Finally, Marek explains how Hafnium port to Renesas R-Car X5H was implemented, provides tips for debugging the Hafnium port, and elaborates in detail what changes were necessary to the rest of the firmware stack components, specifically TFA, OPTEE-OS and U-Boot, to make them compatible with the newly added Hafnium in S-EL2.

ZBus (Zephyr Bus) is a thread-to-thread message and data exchange protocol based on a bus topology. Since Zephyr v4.4.0, it also supports IPC between multiple Zephyr domains running on different CPU cores.

While this fits well for homogeneous multicore systems, heterogeneous SoCs typically run different operating systems on different cores. A common ARM-based setup uses Linux on a Cortex-A core for high-level tasks and Zephyr on a Cortex-M core for real-time workloads.

Communication between these environments requires data exchange across both cores and operating systems. Currently, the practical approach is to transfer raw bytes through RPMsg channels, requiring developers to implement custom protocols on both sides.

ZBus for Linux bridges this gap by connecting Linux applications to a remote ZBus instance, enabling structured communication across heterogeneous systems.

This talk presents the implementation of an early prototype, the challenges encountered, and the overall architecture of ZBus for Linux.