Open Source Summit + Embedded Linux Conference North America 2026

Ten years ago, Zephyr set out to solve a problem that many embedded teams quietly struggled with: how to build dependable real-time systems without being locked into a single vendor, toolchain, or proprietary stack. Before beginning the project, open source developers were surveyed to identify the key problems they wanted to see a new open source RTOS to solve, such as security and safety certifications.

What followed over the next decade was more than steady adoption. Zephyr introduced a new model built around portability, adoption of security best practices, modern tooling, and a shared ecosystem of drivers and middleware. Contributors collaborate in the open to improve performance, connectivity, and reliability, enabling it to now be found embedded in products which need to last many years, if not decades.

As we head into our next 10 years, the Zephyr project reached out again to survey RTOS users and understand better what they value, and what the project should focus on improving in the years ahead. This talk will go through the results that LF Research team has identified from the survey and interviews, giving a peak at the focus points going forward.

Embedded Automotive RTOS (Real-Time Operating Systems) must meet stringent requirements for safety, reliability, and security, primarily governed by the ISO 26262 standard, which details ASIL (Automotive Safety Integrity Level) requirements.

This talk covers the Zephyr RTOS complies with key functional needs, including minimal latency, high determinism, efficient memory management, and robust multitasking capabilities to handle critical tasks. Currently, the project is actively moving toward greater alignment with the needs of the automotive industry, with specific plans outlined.

When our production power‑management IC (PMIC) firmware moved to Zephyr, it opened the door for us to streamline our development and validation workflow. Our production firmware used a proprietary RTOS, which required maintaining a separate codebase for pre-silicon validation. By standardizing on Zephyr, an RTOS supported across hundreds of MCUs, we were able to use single application codebase across the entire development flow.

In this talk, I’ll describe how we built a Zephyr‑based pre-silicon PMIC testing platform, enabling the same application to run on both the production as well as pre‑silicon hardware running on a completely different SoC (Raspberry Pi Pico) and a custom evaluation kit. I will briefly outline the software architecture: the application running on Zephyr with board configuration defined through device tree and Kconfig. I will also cover the hardware architecture that connects the Pico to the PMIC evaluation kit, and the Twister‑based Hardware-in-loop tests we incorporated for validation.

I’ll close by highlighting how Zephyr’s broad hardware support and tooling helped simplify our workflow and reduce duplicate effort across multiple platforms.

Zephyr’s build-time configuration excels at efficiency, but challenges mass production. When a single product design needs to support dozens of hardware variations, e.g. swapping out sensors or chargers due to supply chain constraints, the standard build flow often leads to managing a unique binary for every combination. This creates a validation nightmare.

This talk presents an architectural framework used in the ChromeOS Embedded Controller that brings runtime adaptability to Zephyr, achieving Linux-like flexibility without the memory overhead of a live DTB parser.

We cover two specific patterns:
1. Dynamic Driver Selection: We treat the Devicetree as a pool of supported components. By reading a configuration bitfield from manufacturing data (EEPROM or protected flash) at boot, the firmware dynamically initializes only the correct drivers for that specific unit.

2. Safe Hardware Discovery: Zephyr compiles away hardware descriptions, leaving the host OS blind to connected peripherals. We introduce a pipeline that exports Devicetree definitions into a "Component Manifest". This enables safe OS-level verification, avoiding the risks of "blind probing" on I2C buses.

Fuzzing, a type of dynamic analysis, is a testing method to find security flaws in software during execution. It involves providing randomized inputs to the application and observing for crashes.

Embedded applications present unique fuzzing challenges. Unlike general-purpose software, they run continuously in real-time without terminating, making it hard to use traditional fuzzing approaches. They receive inputs through specialized peripherals or direct memory/register accesses that require accurate modeling. Fuzzers must generate inputs satisfying highly constrained validation checks while maintaining application state, and crash detection is complicated by the lack of clear program termination.

Existing solutions use hardware, emulation, or rehosted systems with modeled peripherals, employing full source code level, binary-only or API-level fuzzing. Zephyr's current libFuzzer integration targets unit-level API fuzzing but misses system-wide bugs. We aim to integrate AFL++, a popular fuzzing engine, to create a generalized fuzzing strategy across Zephyr's supported platforms. Though still in development, we're exploring the optimal approach to achieve this integration.

FreeRTOS has long been the go-to RTOS for embedded developers. But as projects grow in complexity, demanding better modularity, richer middleware, and long-term maintainability, teams are turning to Zephyr. The migration, however, can feel daunting. Different APIs, build systems, configuration models, and abstractions create a steep learning curve.

This session delivers a practical, step-by-step guide for transitioning from FreeRTOS to Zephyr with confidence. We'll map the similarities and differences between the two RTOSes, demonstrate migration strategies for tasks, queues, and synchronization primitives, and show how to translate existing FreeRTOS designs into Zephyr's ecosystem — covering proven tips to avoid common pitfalls, validate your port, and leverage Zephyr's strengths from device trees to vendor-neutral drivers.

Key Takeaways:
- Core architectural differences between FreeRTOS and Zephyr
- Migrating primitives (tasks, queues, semaphores, timers) to Zephyr equivalents
- Adapting build systems, configuration, and drivers
- Best practices for validating and testing migrated code
- Leveraging Zephyr's ecosystem for scalability and long-term support