When a Python program crashes, a backtrace is printed — often enough to pinpoint and fix the issue. When a C or C++ program crashes on an embedded Linux system, however, nothing appears by default — except perhaps the dreaded “Segmentation fault” message. Unfortunately, there’s no simple --enable-backtrace option to enable human-readable backtraces at build time. Even worse, generating useful backtraces involves many subtle factors, and there’s no comprehensive resource that explains how to get them right.
This lack of clear information arises because backtraces depend on numerous variables: your hardware architecture, operating system, distribution, compiler, build configuration, and the specific tools used to unwind the stack.
In this talk, I’ll demystify how backtraces actually work and explore the key concepts behind them. I’ll also show how to leverage libunwind and minidebuginfo to obtain reliable backtraces on ARMv7 and ARMv8 systems, within the context of a Yocto-based embedded Linux distribution.
Rust is rapidly reshaping how we build reliable software — including in areas once dominated by C. But what does it really look like to bring Rust into an existing embedded codebase? This talk shares the hands-on experience of migrating a working ESP32 firmware from C to no_std Rust, highlighting what Rust changes, what it improves, and where the bumps in the road are.
Starting from a hobby project — a wireless arcade button used in a multiplayer blind test game (https://github.com/neon-beat) — we will explore the practical steps of developing Rust firmware on the ESP32, from toolchain setup and hardware abstraction to system architecture and debugging strategies. Along the way, we’ll discuss the key differences from traditional Rust development, the challenges faced in a no_std environment, and how the embedded Rust ecosystem and community helped the project move forward.
Whether you’re an embedded developer curious about Rust, someone evaluating the risks and benefits of adopting it in production, or simply interested in real-world migration stories, this talk aims to provide actionable insights, lessons learned, and a realistic view of what transitioning from C to Rust on micro controllers really looks like.
Ariel OS is a new RTOS for microcontrollers written fully in Rust. It supports popular hardware architectures (Cortex-M, ESP, RISC-V) and popular boards from vendors such as Espressif, Nordic, Raspberry Pi and ST. Ariel OS is built on top of Embassy and the embedded-hal traits, adding various OS functionalities and a multi-core capable scheduler. Ariel OS further aims to integrate the best of the available embedded Rust ecosystem to provide a seamless, batteries-included experience for microcontroller firmware development. Ariel OS is open source with dual Apache 2.0 / MIT license, available on GitHub
In this talk we demonstrate how easy it is to use Ariel OS on microcontroller-based hardware and how the different features help to quickly get a project up and running. We overview the OS and walk through creating a firmware for a common board, thus showcasing the features that make Ariel OS development unique and appealing
What happens when you mix German luxury engineering with a bit of DIY spirit? You get the world’s most over-engineered office chair.
This talk dives inside a BMW comfort seat — so when you get home in your 7-series, you can feel right at home in the same seat at your desk. Packed with ECUs, motors, pumps, heaters, ambient lighting and airbags, we’ll explore how it all works, how the seat communicates over CAN, j1850 CRCs, some quirks, and how an ESP32 can take control of everything from massage and lumbar support to heating and cooling, obviously all hooked up to homeassistant.
The hope is that this talk will inspire others to reuse car parts in interesting and wonderful ways. We'll also discuss slightly easier things like integrating an idrive controller or gearshifter which are much more common but rarely explained in detail how and why they work the way they do compared to a more complex device like a seat.
Secure-boot projects often end up with a zoo of nearly-identical bootloader images for development, factory, and field use with each variant adding more risk.
This showcase illustrates how to avoid this entirely: one bootloader image that adapts securely to each lifecycle stage using fuse-based state transitions, device-bound unlock tokens, and policy-driven access control.
With barebox and OP-TEE, we’ll show how these mechanisms enforce secure operation while still allowing controlled debugging and recovery, without ever maintaining multiple images.
Contemporary embedded SoCs increasingly act as a network of specialized CPU cores, some dedicated to user applications, other dedicated to real time tasks, others to security. All those cores still share one set of critical peripherals, which require resource access coordination. This is increasingly implemented by making all cores talk to a dedicated core called SCP, the System Control Processor, using SCMI protocol. The SCP is responsible for coordinating access to critical resources, clock, reset, power domain, and so on. An open source firmware, SCP-firmware, can be used on the SCP to offer the SCMI services. This talk explains how to implement a port of SCP-firmware to an SCP core, what is the architecture of SCP-firmware, its initialization process, its driver or module model, how the ordering of module start up is achieved, how to implement UART and mailbox driver modules, and finally how SCMI server services are bound to modules and exposed to other cores. This is illustrated by an example code from existing SCP-firmware port to contemporary SoC.
LINKS: - ARM SCP firmware https://gitlab.arm.com/firmware/SCP-firmware - SCMI specification v4.0 https://developer.arm.com/documentation/den0056/f
Secure-boot chains in embedded systems have largely converged on common building blocks like FIT, dm-verity or UKIs.
The bootloader is anchored in hardware trust, then verifies an operating system image, and the chain continues, eventually covering the application.
But there is a gap when it comes to adding unit-specific bits of information, such as per-device configuration, hardware calibration, or MAC addresses needed early in boot.
In this segment, I present the TLV framework recently added to the barebox bootloader, to which I contributed signature support. It allows device-specific key-value pairs to become part of the secure-boot chain from early on, providing the system with authenticated, replay-protected per-unit data.
This short presentation discusses - factory data and its relevance to a secure-boot chain - the barebox implementation using a signed Tag-Length-Value format - when and how to prevent interchange of TLV blobs across units - integration of the new feature
Most modern embedded SoCs provide a ROM-based recovery mechanism to bootstrap an unflashed device or revive a system whose bootloader has failed. Unfortunately, these mechanisms are typically vendor-specific, poorly documented, and supported only non-standard, sometimes closed, tools. Engineers end up juggling different utilities for each SoC family, with varying user interfaces and commands.
Snagboot addresses this fragmentation. It is a vendor-agnostic, fully open-source recovery and reflashing tool written in Python, with support for TI, NXP, Microchip, ST, Broadcom, Amlogic, and Xilinx platforms (and Rockchip on the way). Through its components snagrecover, snagflash, and snagfactory, Snagboot offers a unified workflow for recovery, reflashing, and factory programming. This talk will give a concise introduction to how Snagboot works and where it fits in the bring-up and manufacturing process.
With embedded devices now everywhere, from home appliances to industrial systems, it is vital to regularly check them for CVEs so that any known vulnerabilities in software components can be identified and addressed before they lead to security risks.
Regularly monitoring these CVEs will be mandatory in various cases to comply with the EU Cyber Resilience Act (CRA), which pushes the industry toward more accountable and proactive security in embedded systems.
We present sbom-cve-check: a new automated vulnerability-analysis tool based on an SBOM, without requiring access to the original build systems. The SBOM is initially obtained from build systems such as Yocto or Buildroot.
sbom-cve-check supports SBOMs in SPDX2 or SPDX3 formats, and CycloneDX compatibility is planned. The tool aims to be an efficient replacement for the cve-check logic currently available in Yocto. It pulls from several databases, including NVD and the CVE List, and supports multiple annotation formats such as OpenVEX and Yocto’s custom format. sbom-cve-check currently supports the following export formats: SPDX3, CSV, and Yocto’s cve-check output format.
The tool is provided under the GPLv2 license, and contributions are of course welcome :)
Last year, Buildroot, the embedded Linux image build system, extended its Long-Term Support (LTS) release channel to three years, up from one year previously. This has been made possible through the Buildroot LTS Sponsorship program, which funds developer time for ongoing open-source maintenance rather than relying solely on maintainers' free time.
In this talk, we will walk through the Buildroot contribution and release process, and explain how LTS branches are maintained. We will discuss: - When and why should you use a Buildroot LTS release ? - What can you expect from LTS releases ? - How the “LTS stewards” coordinate, analyze security issues and collaborate with upstream Buildroot maintainers - The challenges and lessons learned during the first year of the program - How to submit your contributions so they can be easily integrated in LTS releases - Why should you or your company sponsor the LTS program ?
Beyond mobile use cases, flash control is increasingly important in industrial imaging applications. Precise timing is essential for tasks such as barcode scanning and machine vision. However, controlling camera flashes in embedded Linux systems has long been (and still is) a hardware-specific challenge that is often only supported by the downstream drivers.
This talk presents the current efforts to improve flash and strobe control in the Linux kernel, with a focus on the V4L2 subsystem. It begins with an overview of flash timing concepts and their key components, followed by an introduction to the existing V4L2 controls and the latest extensions under development. These enhancements aim to standardize flash behavior across platforms and pave the way for a clean and robust user-space integration.
Many recent Windows (on ARM and x86) laptops have replaced the standard UVC USB camera module with a raw MIPI camera-sensor using a CSI receiver and ISP in the CPU to process the raw data into an image (and on smartphones this has been the norm for ages).
Supporting these cameras under Linux is an ongoing challenge. At FOSDEM 2024 a solution using a software ISP running on the CPU was presented as a solution to get these cameras to work with a fully opensource stack.
This talk will look at where we are at now, 2 years later, highlights:
When you first power up a new camera sensor, the images often look green, noisy, and far from realistic. Getting from that raw output to a natural, high-quality image is a complex process known as camera tuning, and until recently, it’s been an opaque and proprietary part of the imaging pipeline.
This talk introduces the fundamentals of open source camera bring-up and tuning, using tooling provided by the libcamera project to illustrate the process. Through real examples, we’ll look at what early images from a new sensor look like, and how they improve through calibration and tuning steps. We’ll cover the basic equipment and workflow needed to get started, and highlight community efforts to create an open repository of tuning data for phones, laptops, tablets, and embedded libcamera powered Linux devices.
Users wanting to run mainline Linux on ARM64 often face a familiar set of trade-offs: the hardware is too expensive, hard to find, outdated, or doesn’t support mainline at all. But this is starting to change, and Rockchip is one of the SoC vendors hitting the sweet spot.
Find out why Rockchip hardware, and Rockchip as a company, has been doing particularly well when it comes to mainline Linux support. This talk provides an overview of the available Rockchip hardware and the current state of the mainline software landscape around them. We will then highlight what the community has sucessfully upstreamed in 2025, and look at what's still baking in the developers' ovens.
The talk assumes the audience is already convinced that using the mainline kernel rather than vendor BSPs is the way to go. Beyond that, both veteran kernel hackers who are curious about hardware they're unfamiliar with, as well as people looking to get their feet wet in Linux kernel development, are welcome to attend.
In the course of the past months, Michael has added or expanded support for new ARM and RISC-V boards to the Linux kernel (6.19+), to Yocto BSP layers and hopefully before FOSDEM 2026, to the U-Boot bootloader.
This turned out to be much easier than expected, thanks to the availability of device drivers for most hardware blocks, and thanks to the possibility to reuse code (especially Device Tree) for already supported boards.
So, if you have hardware sitting idle or working suboptimally because of quick and dirty vendor kernels and BSPs, join this talk and learn how to let the mainline Linux kernel, U-Boot and appropriate Yocto Project layer fully support your board. This should enable other contributors to get involved, and make it much easier for community projects to adopt such hardware too.
The embedded ecosystem is evolving rapidly, and keeping track of the most important developments has become increasingly difficult, especially outside of our current main interests. Over the past year,there have been important changes in the state of regulation, cryptography, tooling and software supply chain practices. In this talk, Marta will present a curated overview of the key trends that marked the year across both Linux and RTOS-based platforms.
The session will highlight the impact of the EU Cyber Resilience Act on embedded development, recent progress in post-quantum cryptography, the growing influence of AI-assisted tooling, and notable changes in compilers and hardening features. It will also cover the state of vulnerability reporting, examples of high-impact security issues affecting embedded systems, and the maintainership challenges that arise as long-standing maintainers get closer to reaching retirement.
All topics will be supported with concrete references to articles, software releases and conference talks, giving attendees a clear and actionable picture of where embedded security is heading and what to pay attention to in the coming year.
For those who care about software upgrades, Android phones have long been sold with two to three years of software support at best. This situation left a lot of devices running an out-of-date system, with the consequence of exposing users to security issues and premature obsolescence.
This presentation takes the case of the Google Pixel 4a (and a couple of other old Pixel phones) to discuss the issue and to show how it has been updated from Android 13 to Android 16 successfully, using Evolution X custom ROM project, thus extending the device lifetime beyond what was commercially offered by the manufacturer.
MicroPythonOS is the first modern graphical operating system that's addressing the need for a complete, out-of-the-box OS for resource-constrained hardware such as microcontrollers.
It takes heavy inspiration from Android and iOS, with an easy to use appstore, a beautiful LVGL-based touchscreen and button UI with lots of widgets, gestures, theme support, wifi manager and over-the-air updates.
The software stack is fully open-source. This openness stands in contrast to the increasingly restrictive policies of traditional mobile ecosystems, which are increasingly becoming a walled-garden with tight controls on app distribution, content, and monetization.
The OS currently targets the ESP32 family, but it can run on anything that supports MicroPython, including the RP2350. It can also run as a regular desktop application, fullscreen or windowed, which makes app development super short cycle, and debugging much easier.
Hardware support currently includes WiFi, Bluetooth, many Intertial Measurement Units, Camera's, Touch Screens, IO Expanders, Displays, as well as low-level ADC pins, GPIO pins, I2C chips etc.
Presented by Toyota Connected North America (TCNA) Join TCNA for an advanced session showcasing how Flutter can truly power one app across many platforms—from automotive systems to smart TVs, all from a single source tree. This talk will explore the practical and strategic decisions behind creating a unified Flutter embedder capable of targeting diverse market segments including: Automotive * Desktop * Gaming * Internet of Things (IoT) * Point of Sale systems * Smart TVs
Expect real-world insights, deep technical dives, and live demos running on actual hardware. If you're building for multiple form factors and want to simplify your cross-platform pipeline, this session is for you.
One source tree. Endless platforms. One embedder to rule them all.