OSS + ELC EU 2026

Modern IOMMUs are deployed across wildly different environments. In enterprise servers, they require massive scalability, heavy virtualization support, and a zero-tolerance policy for lock contention. On the other hand, as these high-performance IOMMUs increasingly find their way into mobile, automotive, and edge SoCs, aggressive dynamic power management becomes mandatory.

Using arm-smmu-v3 as a case study, this talk explores the design challenges in integrating the Linux Runtime Power Management (RPM) framework into high-performance IOMMU drivers. Modern IOMMU drivers operate primarily with in-memory data structures, rely on HW-shared queues and are designed for lockless, concurrent access, often from strictly atomic contexts.

The RPM framework’s reliance on locks fundamentally clashes with this lockless architecture and atomic execution constraints. This session walks through the design choices evaluated while implementing runtime power management for a modern IOMMU driver, without sacrificing its lockless, concurrent, and efficient behavior.

The talk is backed by the arm-smmu-v3 RPM Series upstream: lore.kernel.org/all/[email protected]/

In a system with "secure boot", you want to lock down most aspects of the system, in particular the bootloader.

On the other hand, implementing A/B updates requires to keep a writable bootloader environment to implement several aspects of A/B updates: adapting the kernel command line to the active partition, counting boot attempts and implementing recovery after deploying a defective update. Without a careful implementation, this could open the door to altering the sequence of boot commands or to introducing unwanted kernel parameters, therefore breaking the security of the bootloader and the rest of the system.

Both secure boot and A/B updates techniques are well documented, but most often without considering their mutual requirements. In this presentation, I will share solutions I found and used in a recent project. I will also share implementation details with U-Boot and the Yocto Project.

Designing immutable filesystems is becoming the default for embedded Linux development: they're more secure, easier to reason about, and resilient to field drift. But they make a once-easy thing surprisingly awkward: a one-line fix to a single script means shipping a whole new rootfs and rebooting the device.
systemd-sysext addresses half this problem by merging extension images onto /usr/ at runtime, with integrity enforced via dm-verity. But sysext is the activation mechanism only — it says nothing about how those signed images reach a fleet of devices in the first place.
This talk walks through a working proof-of-concept that closes the gap: a verity-signed sysext image, delivered over the air through a standard OTA framework, merged live onto a read-only Ubuntu rootfs, with health checks and automatic rollback on failure — all without a single reboot.
This talk covers the architecture end to end, the non-obvious operational gotchas, and an honest accounting of what this approach does and doesn't replace.

The last decade has shown a clear trend in dramatically increasing the boot process of modern SoC. If the i.MX6 bootflow reads like a short novel, the i.MX95 or TI K3 bootflow is a whole encyclopedia.

Today's heterogeneous SoCs combine CPUs of different types — Cortex-R/M cores alongside the application-class Cortex-A — and boot now begins on one of the smaller cores before handing control over to the Cortex-A. There are good reasons for this, such as meeting functional-safety requirements, but it is also a real burden for system designers who simply want to run Linux on the Cortex-A cores and make use of the GPU or VPU.

Each new component needs its own firmware: ideally built from open source, though closed-source pieces remain in the chain. The result is no shortage of cryptic acronyms — TF-A, FF-A, TEE, SCMI, PSCI, SCP, FIP.

This talk sheds some light into the dark. It explains what each of these components actually does and how they fit together. Attendees will leave able to map this general picture onto their own SoC, see which parts are open source and which are not, and know where to look when the bootflow misbehaves.

While bootc has been gaining a lot of momentum over the last few years, we had been using a similar technology in production for over a decade. This timeline has given us long enough to go through the whole life-cycle of thousands of devices: initial provisioning, operating, delivering updates, and decommissioning.

Though our system is based on Yocto and Moby and specifically tailored for over 100 different (mostly edge/embedded) device types, it shares the same core principle of modern bootable container architecture: shipping the OS as a container image and configuring the init system to boot directly into it.

During the session, you will learn:
* How to boot into a containerized rootfs.
* How to manage state, persistent data, and OS updates via container registries over unstable networks.
* Lessons learned from 10 years of using bootable containers on 100+ different edge hardware types.

Prerequisites: Attendees should have a general understanding of OCI containers, Dockerfiles, and container registries.

Traditionally, embedded systems were simple enough that an initramfs was not needed at all. This has changed in the last recent years with new requirements, often related to verified boot. That means that additional steps are now needed before the rootfs can be mounted.

Existing solutions, such as the Yocto initramfs-framework have significant drawbacks. The resulting initramfs is quite big (multiple megabytes) which has a noticeable impact on the boot time. And while the shell scripts make it easy to customize, robust error handling is difficult.

In this talk, Michael will introduce rsinit (https://github.com/pengutronix/rsinit), a single-binary-initramfs for embedded systems, written entirely in Rust.
It is tiny (less than 200 KiB), very fast and "just works" for simple use-cases. Alternatively, it can be uses as a library crate to build a fully custom binary.

Beyond being small, it brings the full power of Rust to the initramfs, which allows building additional features (such as splash screens or read-ahead) without pulling in further dependencies.

Michael will present the existing features, explain the design choices and give an overview of what is planed for the future.

Android Auto requires Google's device integrity checks before it will connect to a car head unit, which by design locks the protocol to stock Android. Mainline mobile Linux phones have no path to car integration as a result.

LibreCar is an open-source implementation of the Android Auto protocol for the phone side. It lets any mainline Linux phone connect to a head unit wirelessly over Bluetooth and Wi-Fi, or wired over USB, without depending on Android or Google.
.
This talk walks through what it takes to open a session with a head unit, how to compose and stream the video output it expects, and how to read touch input back from the interface.

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.

Since the introduction of the first Samsung DSI panel, the Linux DRM panel API became an important piece of software used to enable displays across very different hardware architectures. However, the panel support API hasn't evolved much since then.

Currently, the API is showing its age alongside modern graphics stacks. It doesn't support the atomic DRM API and lacks the ability to adapt the power setup while changing DRM modes. Furthermore, it doesn't support the advanced features that new Display Driver ICs (DDIC) heavily rely on, such as standby and advanced power states, advanced color management, dynamic rate switching, command mode self-refresh and more.

Neil will present you the history of the panel API from its origins, outline its current architectural limitations, and lead this BoF to discuss how to bring Linux DRM Display Panel support into the modern age. This open discussion will focus on how to collaboratively solve all those missing features to support modern devices and close the widening gap with downstream vendor support.