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.

While changes to the internal kernel APIs and design are possible, that doesn't mean they are easy.

In preparation for a larger work to make the DRM subsystem support video output pipelines with hot-pluggable components, we have been working for the past two years to change the lifetime of `struct drm_bridge` in the DRM subsystem. This required changing the semantics of a dozen internal APIs and adaptations to more than 50 drivers.

This talk is not about the content of the changes but rather about the process to achieve it: the initial steps to find the best strategy, the continuation to convert all APIs, bugs introduced and reacting to them, working on lots of drivers without the chance to test them, dead ends encountered, tools used, the time required for the whole process, and the community interactions in the whole time span.

The focus will be on lessons learnt and which strategies worked better, and ultimately how to make a similar kind of massive conversion in the most efficient (and least frustrating!) way.

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.

All active components require power. The device tree should properly describe these supplies so that the software can control power to the devices. On the other side of things, regulators also have their power inputs, and constraints on their power outputs. The device tree should also describe this. Nothing should be left to default.

This session will present how to fully describe the regulator tree of a system, how to identify missing bits, and how to properly describe regulator constraints.

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.