OSS + ELC EU 2026

U-Boot and Linux boot flows lack safety monitoring for mixed-criticality systems. We address this gap for low-criticality use cases and development stages where customers work toward safety certification on TI K3 SoCs, offering a flexible alternative to rigid safety-critical frameworks. This approach can be extended to any of the heterogeneous SoCs with safety hardware support.

We cover safety drivers in both U-Boot and Linux that increase the safety level of a system: Error Signaling Module (ESM) for error routing, Power-OK (POK) voltage monitors (upstreaming WIP), Voltage-Thermal Monitor (VTM), Timeout Gasket (TOG, upstreaming WIP), DDR Inline ECC for memory protection, and watchdog. In U-Boot, we leverage its sequential non-threaded flow to initialize ESM, POK, VTM, TOG, and DDR ECC via uclasses, establishing hardware safety guarantees before kernel handoff. In the kernel, we cover configuration and error handling of watchdog, and ECC for self-resets and synchronous aborts. DDR thermal self-refresh rate management and runtime monitoring of POK, VTM, and TOG via hwmon (WIP) will also be covered. Testing approaches via U-Boot cmdline tests and LTP-DDT will also be discussed.

Achieving both low power consumption and deterministic real-time performance is a key challenge for modern embedded systems. Intel embedded platforms are widely deployed in industrial, medical, robotics, and other edge computing applications where strict timing requirements must be satisfied while maintaining energy efficiency. Traditional real-time system configurations often disable CPU frequency scaling and deep CPU idle states to minimize latency and jitter. While this approach can improve real-time responsiveness, it significantly increases power consumption and reduces battery life in power-constrained deployments.
This proposal presents practical techniques for balancing power management and real-time performance on Intel embedded platforms running Linux with the PREEMPT_RT kernel. Based on experimental evaluation, we demonstrate that modern Intel power management features can be selectively enabled and tuned to reduce energy consumption while maintaining deterministic real-time behavior. These findings offer practical guidance for deploying power-efficient real-time applications on Intel edge platforms.

In industrial and real-time applications, strict timing constraints can exceed the capabilities of standard Linux systems—even when enhanced with the PREEMPT_RT patch. As a result, developers increasingly deploy real-time operating systems (RTOS) on application-class cores (e.g., ARM Cortex-A) to meet deterministic requirements.
This session presents a comparative study of latency characteristics measured on identical hardware platforms running Linux with PREEMPT_RT, Zephyr, and FreeRTOS. We first analyze how the PREEMPT_RT patch impacts kernel latency across different workload scenarios, highlighting both its strengths and practical limitations. We then extend the comparison to RTOS environments, focusing on scheduling latency and interrupt (IRQ) handling behavior under equivalent conditions.
The results are based on systematic benchmarking and provide insight into latency trade-offs, determinism, and suitability of each system for industrial workloads. We will also provide industrial specific examples of target use-cases, where this performance numbers are key parameter.

Real-time Linux systems are often judged with timer-based benchmarks such as cyclictest, a useful baseline for wakeup latency caused by scheduling and system activity. Yet many embedded workloads are driven by external events, not periodic timers: GPIO edges, network packets, serial I/O, or other hardware interrupts. In these systems, the critical value is the latency from an interrupt to a high-priority task.

This talk asks how much end-to-end interrupt-driven latency timer-based benchmarks can explain, and where path-specific measurements are required.

We revisit RT evaluation on modern PREEMPT_RT Linux by combining cyclictest with measurements for GPIO interrupt paths, network receive paths, and interrupt-to-userspace wakeups. Across scenarios with CPU isolation, IRQ affinity tuning, and other common RT optimizations, we compare what each method reveals and misses. For selected setups, we also compare kernel/PREEMPT_RT revisions and use ftrace to locate latency sources.

Rather than treating one benchmark as a complete RT verdict, this session clarifies how timer-based results can inform, but not replace, measurements for practical interrupt-driven embedded workloads.

Industrial Ethernet protocols (EtherCAT, EtherNet/IP, PROFINET) require deterministic, low-latency packet processing that degrades when real-time and best-effort traffic compete for CPU resources. This work investigates the extent to which bounded latency behaviour can be achieved for real-time industrial traffic on a multi-core ARM Cortex-A53 SoC running PREEMPT_RT Linux while sharing a single Ethernet interface with concurrent best-effort traffic. The study demonstrates that both traffic types can coexist on a single physical port and be separated across cores using software-based techniques such as the XDP framework. To enforce bounded latency, CPU isolation, processor affinity, and real-time scheduling policies are applied to networking-related kernel threads and application tasks. Results compare real-time traffic latency and jitter across three configurations: no traffic steering, traffic steering to dedicated cores, and traffic steering with techniques to enforce bounded latency. The goal is a reproducible tuning guide for engineers deploying deterministic networking on Linux-based industrial platforms.

With the increasing availability of high-performance Arm® Cortex-A cores and multiple Cortex-M cores in modern MPUs, industrial systems are evolving toward heterogeneous multi-core architectures. For example, compute-intensive applications running on Linux with PREEMPT_RT on A cores, while deterministic real-time tasks running on A core with RTOS (Zephyr or FreeRTOS).
This session will explore the key challenges and corresponding solutions in enabling efficient multi-OS deployment on a single MPU. Topics include:

- Unified life cycle management for booting and orchestrating multiple operating systems across cores using TF-A, U-Boot, and Linux, and fast-boot optimization with TF-A mechanism.
- High-performance inter-core communication mechanisms for low-latency data exchange
- Resource sharing that allow different operating systems to access shared hardware IPs as isolated “virtual peripherals”

The session provides practical insights into building efficient and deterministic heterogeneous systems for industrial applications.

The Linux tracing infrastructure provides several methods for recording events in the operating system. Apart from many other use cases, tracing is often being used to identify the root cause of high latencies on Linux with enabled real-time configuration. The possibility of filtering and a fine granular selection of the events to be recorded reduces the overhead and therefor allows tracing of time critical sections with low impact on the runtime behavior. Events generated by the tracing infrastructure can also serve as a hook for eBPF programs, which run in a sandbox inside the kernel. These can be used for timing analysis within the kernel without the need of switching to userspace. This presentation will give a brief overview of the Linux tracing infrastructure, eBPF and how they can be used to analyze scheduling latencies on a Linux system with real-time requirements.

At balena, a 6 person team maintains 1 distro meta for 80+ boards across multiple Yocto versions. This talk unpacks the layer layout that make this level of scale possible.
Maintaining one distro across multiple architectures and vendor BSPs is, above all, a separation-of-concerns problem. Centralizing every board in one BSP layer, forking vendor trees, or splitting repos without clear boundaries each trades one pain for another: merge hell or upgrade paralysis when vendors move at different speeds.
Yocto's layer model is built for it but the boundaries are easy to miss. I learned it the hard way: managing boards from several vendors in a single BSP works at first, then fails to scale.
During the session, you'll learn:
- How to structure distro logic, version-specific, board and vendor layers
- Anti-patterns from real projects
- Strategies for on-boarding new hardware boards without duplicating distro logic or getting blocked by a lagging vendor BSP
You will leave with a concrete layout to evaluate against your own BSPs and enough pointers using balenaOS’s oss repositories as a reference implementation to start migrating toward a maintainable global BSP.