0.5 er2026 2026-05-27 2026-05-28 2 00:05 https://cfp.embedded-recipes.org https://cfp.embedded-recipes.org/media/er2026/img/ER_logo_2025_ejt2hna_niFWmWP.webp Europe/Paris Auditorium Talk 2026-05-27T09:45:00+02:00 09:45 00:40 The EU Cyber Resilience Act introduces new obligations across the software supply chain, for both manufacturers and for the new category of open source stewards. We've been thinking about what this means for the Yocto Project - what are our obligations? And what can we do to help our users meet their obligations as manufacturers? For manufacturers, the CRA requires the avoidance of known exploitable security issues, tracking of software components & vulnerabilities, reporting to relevant Computer Security Incident Response Teams (CSIRTs) and provision of software updates for the useful lifetime of products. Today, the Yocto Project provides a repeatable build process and tooling that will help manufacturers to meet these requirements. With further development, we could make it easier to achieve the required level of security and vulnerability tracking. For the Yocto Project itself, the requirements on open source stewards are more lightweight. We will need to align the project's cybersecurity policy with the CRA and be prepared to share information with market surveillance authorities if requested. er2026-92256-yocto-project-and-the-cyber-resilience-act Paul Barker en This talk will: - Introduce the challenges and opportunities of the CRA from the Yocto Project perspective. - Discuss changes needed to our security policy to meet our new obligations. - Review the existing features that we provide to help manufacturers meet their obligations: SPDX3 SBoM generation, reproducible builds and CVE tracking. - Present a roadmap of security features that we should adopt to further help our users: secure-by-default software images, improved secure boot support, more comprehensive detail in our SBoMs and more flexible CVE tracking with sbom-cve-check. - Invite questions and feedback from the audience. false https://cfp.embedded-recipes.org/er2026/talk/CUMR8D/ https://cfp.embedded-recipes.org/er2026/talk/CUMR8D/feedback/ Auditorium Talk 2026-05-27T10:30:00+02:00 10:30 00:40 Bootc is a system to boot regular container image as a full operating system, including a kernel. This gives an extremely flexibly and powerful mechanism to build, manage and deploy images to machines which reuses existing, known infrastructure and tools. However, to use this in embedded systems we also need to support for runtime validation of data (like dm-verity) and signatures (secureboot, android verified boot), which is not typically available for containers. This talk will describe how technologies like bootc, composefs and ukiboot can be used to achive an end-to-end signed and verified boot, and demonstrate how this works in the automotive Linux platform we are building. er2026-91880-booting-validated-containers-in-your-car Alexander Larsson en false https://cfp.embedded-recipes.org/er2026/talk/M8CYMB/ https://cfp.embedded-recipes.org/er2026/talk/M8CYMB/feedback/ Auditorium Talk 2026-05-27T11:15:00+02:00 11:15 00:40 In embedded systems, the ability to efficiently transition from low power states back to active operation is critical. Wakeup events are the mechanism used to communicate to the system to leave a low power state and enter an active state. However, implementing effective wakeup mechanisms requires navigation of hardware constraints, such as understanding signal routing, IRQ configurations, and determining which wakeup sources remain available when various system components are powered down. Linux provides architecture to easily model and configure wakeup sources, allowing developers to enable wakeup sources across different platforms. This talk will cover the Linux architecture and APIs behind wakeup sources such as managing wakeup events, wake IRQs, and what considerations are needed when selecting and configuring the right wakeup source. Additionally, this talk will open a discussion and explore the existing frameworks of modeling wakeup sources for devices that wakeup the system even when their power domain is off. er2026-91972-mastering-wakeup-sources-in-linux-architecture-apis-and-constraints Kendall Willis en false https://cfp.embedded-recipes.org/er2026/talk/P8A8DR/ https://cfp.embedded-recipes.org/er2026/talk/P8A8DR/feedback/ Auditorium Lightning Talk 2026-05-27T13:30:00+02:00 13:30 00:15 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 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. er2026-92297-rsinit-a-tiny-initramfs-toolbox-for-embedded-systems Michael Olbrich en rsinit was briefly introduced in the talk [The Cost of Security: Measuring and Reducing Boot-Time Impact ](https://osseu2025.sched.com/event/25Vso/the-cost-of-security-measuring-and-reducing-boot-time-impact-michael-olbrich-pengutronix) at ELCE 2025. false rsinit on GitHub https://cfp.embedded-recipes.org/er2026/talk/JHLWDM/ https://cfp.embedded-recipes.org/er2026/talk/JHLWDM/feedback/ Auditorium Talk 2026-05-27T13:45:00+02:00 13:45 00:40 Basic UEFI support was added to U-Boot back in 2016. Back then it had - Rudimentary UEFI support - Ability to read/store UEFI variables to/from the U-Boot environment - No UEFI secure boot - No UEFI measured boot - No capsule update support, even without authentication - UEFI Boot Manager was just merged with only basic features Over the years the UEFI implementation has matured making it easy to launch standard off the shelf distros in embedded hardware. We'll go through the features, starting from the initial EBBR support in U-Boot up to booting an OS (installing the OS over a disk or HTTPs as well as running live images) and all the problems we solved along the way. - A small introduction to UEFI, EBBR and SystemReady - How to install and boot off the shelf distros on embedded boards - What is UEFI secure boot and how you can enable it on your hardware. Multiple options exist and it depends on the available storage -- SPI, RPMB, eMMC, SD card only etc - How to enable and use UEFI measured boot - EFI HTTPs boot (with lwIP and mbedTLS support) - Authenticated capsule updates. How to add support for your board and how to use them via LVFS - A/B update support for firmware - SetVariable at runtime options and why distros need it er2026-90884-u-boot-running-an-off-the-shelf-distro-on-your-embedded-board Ilias Apalodimas en I plan to cover the entire lifecycle of booting distros on embedded hardware. My team and I have written many blog posts for Linaro over the years (https://www.linaro.org/blog?tags=u-boot) explaining most of the functionality. I'd like to have a presentation on the entire end to end flow. false https://cfp.embedded-recipes.org/er2026/talk/QRSV8Q/ https://cfp.embedded-recipes.org/er2026/talk/QRSV8Q/feedback/ Auditorium Lightning Talk 2026-05-27T14:30:00+02:00 14:30 00:15 Secure boot is a security feature that enables device manufacturers to ensure that a device only boots trusted and signed software. This feature depends on certain hardware capabilities like a hardware root of trust and signature verification. The Rockchip RK3588 SoC supports these features. However, limited documentation and reliance on a closed-source vendor OP-TEE binary and development tools raise concerns regarding security and maintainability. With OP-TEE 4.9.0 and barebox v2026.02.0, users may enable and use Secure Boot on RK3588 without needing any special Rockchip tools. In this session, Michael will show you how to enable Secure Boot on RK3588 with upstream barebox and upstream OP-TEE. He will also highlight differences between the upstream implementation and Rockchips downstream solution. Lastly, he will briefly explain technical details to help you with adapting the implementation for other Rockchip SoCs and with using the OP-TEE PTA from Linux or U-Boot. er2026-92277-open-source-tools-for-secure-boot-on-rockchip-rk3588 Michael Tretter en [OP-TEE Pull Request](https://github.com/OP-TEE/optee_os/pull/7661) [barebox Patch series](https://lore.kernel.org/all/20260105-rockchip-secure-boot-v1-0-eaf5053a7d7e@pengutronix.de/) false https://cfp.embedded-recipes.org/er2026/talk/ULWYUJ/ https://cfp.embedded-recipes.org/er2026/talk/ULWYUJ/feedback/ Auditorium Talk 2026-05-27T14:45:00+02:00 14:45 00:40 Contemporary SoCs perform initial system boot on a dedicated core and start the additional cores only after the system was fully initialized. This boot core may be a Cortex-M, which is also capable of running U-Boot, and remains active even after the other cores started. This talk first clarifies the specifics of porting U-Boot to Cortex-M, including read-only text and read-write data at offset, limited SRAM size, partial relocation, console access, and start of the additional cores. Next, the talk explains how U-Boot running on the boot core can be used as an always-on debug tool, to inspect the state of the other cores, peripherals and memory in the system. This includes interaction with peripherals even if the other cores may have crashed, and the use of DMA to access memory above the 32bit boundary. The talk ends with a real-world example of such a setup. er2026-92185-u-boot-on-boot-core-as-an-always-on-debug-tool Marek Vasut en false https://cfp.embedded-recipes.org/er2026/talk/9RX7LL/ https://cfp.embedded-recipes.org/er2026/talk/9RX7LL/feedback/ Auditorium Lightning Talk 2026-05-27T15:30:00+02:00 15:30 00:15 Everyone loves "cleaning up" code in the Linux kernel using macros from linux/cleanup.h. It's one of the latest fads. There have been hundreds of "clean up" patches and these macros are used thousands of times in the kernel now. However, these macros have some hidden secrets that can result in hard-to-spot bugs and mysterious compiler warnings! As these gain wider use and acceptance, let's see what the problems are and what we should do about it. er2026-92228-watch-your-scope-the-hidden-pitfalls-of-scopedguard-and-other-cleanup-h-macros David Lechner en Spoiler alert: scoped_guard() contains a for loop, so using break and continue keywords in this scope doesn't do what one might think. I've found and reported a number of cases where this mistake made it into the kernel. Even experienced kernel maintainers are missing this and submitting patches with bugs. This makes me wary of using scoped_guard() in general, but I seem to be in the minority. The other cleanup macros introduce local variables. The clang compiler doesn't like this when you use them in a switch statement. I'll show the compiler warning/error and how to avoid it. false https://cfp.embedded-recipes.org/er2026/talk/VTTZDS/ https://cfp.embedded-recipes.org/er2026/talk/VTTZDS/feedback/ Auditorium Talk 2026-05-27T16:15:00+02:00 16:15 00:40 Modern motorsport telemetry systems generate massive amounts of data including GPS traces, IMU measurements, CAN signals, and vehicle dynamics. In most cases, analysis happens after the session, often in the cloud. By the time insights are available, the opportunity to correct driving behavior in real time is already gone. For deterministic feedback during a session, cloud-dependent approaches are too slow, too fragile, and sometimes simply unavailable. In this talk, we walk through the engineering journey of building a real-time telemetry analysis system that runs entirely at the edge on embedded Linux. The objective was straightforward: detect driving patterns and performance anomalies during a session without relying on connectivity. Achieving that goal required solving a set of practical system-level challenges that extend far beyond data acquisition and model training. We begin with the development pipeline: training a model offline, exporting to ONNX or TFLite, quantizing for constrained hardware, and deploying to embedded System-on-Modules. We compare CPU-only execution against NPU acceleration, highlighting latency, memory footprint, and sustained-load behavior. Real benchmark results demonstrate where hardware acceleration delivers measurable gains and where it introduces additional constraints. Running inference once is not the hard part. Shipping a complete embedded systems product is. The talk then focuses on the integration and production aspects of edge AI systems. We examine kernel driver and user-space runtime alignment, accelerator operator support limitations, memory pressure under sustained workloads, and thermal behavior during continuous inference. We discuss containerized deployment on embedded Linux, using Torizon OS as a reference implementation, including hardware access from containers, separation of sensor ingestion and inference pipelines, reproducible builds, and safe over-the-air model updates without reflashing the device. By the end of the session, attendees will have a practical blueprint for taking an AI model from experimentation to a production-ready embedded deployment. More importantly, they will gain an honest understanding of what breaks, what scales, and what must be designed early when building real-time intelligence on embedded Linux systems. This is not a showcase of AI capabilities, but a systems engineering story about building, benchmarking, integrating, and maintaining edge AI under real-world constraints. er2026-92293-from-track-to-edge-shipping-real-time-ai-on-embedded-linux João Victor "Teddy" Martins en Artificial intelligence at the edge is often described as just moving machine learning from the cloud to a local device. In embedded systems, however, it is much more complex than simply running inference. It involves dealing with hardware limitations, operating system constraints, runtime compatibility, power consumption, and long-term maintenance. These challenges make deploying AI on embedded Linux a full systems engineering problem rather than just a data science task. This talk presents a practical, end-to-end workflow for building and deploying a real-time edge AI system on embedded Linux using open-source tools within the Toradex ecosystem. Using a motorsport telemetry use case that requires low-latency analysis without cloud connectivity, we go through the entire development process, including model training and export, quantization for limited hardware, CPU versus NPU trade-offs, sustained performance testing, containerized deployment, reproducible builds, and safe over-the-air updates. false https://cfp.embedded-recipes.org/er2026/talk/USZT33/ https://cfp.embedded-recipes.org/er2026/talk/USZT33/feedback/ Auditorium Talk 2026-05-27T17:00:00+02:00 17:00 00:40 For the past 20 years, the engineers at Bootlin have been building, fixing, porting, debugging, and occasionally arguing with Embedded Linux systems across many industries and products. In that time, we've met spectacular boot failures, drivers that almost worked, hardware that didn’t quite match the datasheet, race conditions that only appeared on Tuesdays, and bugs that vanished the moment we added a printk(). In this end-of-day session, we'll share a carefully curated selection of our favorite war stories. Real bugs. Real root causes. Real debugging techniques. No hindsight magic. We’ll walk through what broke, why it broke, how we tracked it down, and what it taught us. Expect kernel deep dives, bootloader surprises, hardware-software boundary confusion, and more. If you've ever spent hours chasing a bug that turned out to be one flipped bit, this talk will feel strangely familiar. er2026-92281-embedded-war-stories-from-the-bootlin-team Bootlin's team en Twenty engineers from Bootlin will be roaming the halls of Embedded Recipes. A subset of us will take the stage to confess our mistakes, celebrate the fixes, and share the lessons learned the hard way, so you don’t have to. false https://cfp.embedded-recipes.org/er2026/talk/NGEGSL/ https://cfp.embedded-recipes.org/er2026/talk/NGEGSL/feedback/ Auditorium Talk 2026-05-28T09:30:00+02:00 09:30 00:40 What is OP-TEE? How does it work? And why are so many features for OP-TEE disabled by default? This talk will give an introduction to OP-TEE and than highlight the lesser known features such as asynchronous notifications, Secure Data Path or Function Tracing. It will also take a look into future, where industrial arm64 SoC are no longer limited to ARMv8.2 and with ARMv8.4 can provide virtualization of the secure world to implement the Firmware Framework for A-Profile (FFA) specification. er2026-92317-op-tee-and-its-many-features Rouven Czerwinski en The talk aims to provide an introduction to OP-TEE, describe how different boot up flows work and will describe how an execution environment differs from a full operating system implementation. With this foundation we will start to look at interesting features implemented into OP-TEE, many of which are disabled by default either because most platforms don't require them or they are primarily aimed for debugging and have a performance impact. Among those features, at least the following will be covered: - OP-TEE & Linux kernel support for synchronous and asynchronous notifications - Secure Data Path and the OP-TEE Heap implementation for protected buffer sharing - Function Tracing for Applications running within OP-TEE - OP-TEE support to communicate with external secure elements via the Linux kernel We will than take a look into the Firmware Framework for A-Profile (FFA) specification which becomes relevant with ARMv8.4 implementations and explain how OP-TEE fits into it. This will also cover other components which are affected by FFA i.e. TF-A & hafnium. false https://cfp.embedded-recipes.org/er2026/talk/YSADJ9/ https://cfp.embedded-recipes.org/er2026/talk/YSADJ9/feedback/ Auditorium Talk 2026-05-28T10:15:00+02:00 10:15 00:40 postmarketOS is a community project aiming to bring real mainline linux to your smartphones (and other consumer devices). What was once a far dream, has developed into a vibrant community with many smartphones receiving enough features in mainline kernels for people to daily-drive them. However, community and manual testing can only gets us so far. To be able to scale, avoid regressions, and ensure long-term reliability automated testing is a requirement. After many years of work and multiple attempts, postmarketOS has been able to build a system to test phones directly into CI. The system is FOSS, distributed, simple enough to be deployed by a hobbyist at a hacker-space for <200€, and easy to scale-up. It uses [CI-tron](https://docs.ci-tron.dev) for all the orchestration, and a custom PCB as PDU for phone-specific needs. In this talk, we will discuss the different approaches we took over time, lessons learned from successes and failures, current status, and a look into the future. er2026-91811-a-distributed-phone-ci-for-postmarketos Pablo Correa GomezCasey en false https://cfp.embedded-recipes.org/er2026/talk/ZLSMQG/ https://cfp.embedded-recipes.org/er2026/talk/ZLSMQG/feedback/ Auditorium Talk 2026-05-28T11:00:00+02:00 11:00 00:40 Heterogeneous embedded SoCs increasingly require display hardware sharing between Linux and real-time firmware cores. For e.g., In automotive instrument clusters, safety-critical telltales must be rendered by an RTOS on a real-time core (e.g., R5F) while Linux drives the GPU-composited UI on the same display. No generic upstream solution exists to cleanly bridge these worlds within the DRM/KMS subsystem. We present rpmsg-kms, a vendor-agnostic DRM helper framework that unifies display sharing across heterogeneous cores. The design leverages the kernel's remoteproc/virtio/rpmsg transport chain for automatic driver binding, eliminating manual integration. The framework and firmware communicate through the firmware's resource table and rpmsg name-service announcement, enabling independent development and deployment. The session will be addressing two distinct models: Model 1: Universal Framebuffer Handoff targets platforms where firmware owns the display pipeline. Linux communicates per-frame plane updates (address, geometry, format, Z-order) over rpmsg to firmware, which programs hardware registers. Vsync can be delivered via rpmsg. This suits any processor and display controller where firmware needs complete control and Linux is in charge of passing GPU-rendered framebuffers for firmware-side for post-processing, composition and display. Model 2: Hardware-Assisted Display Partitioning targets SoCs like TI's K3 family with hardware support for partitioning display resources across cores. The hardware enforces isolation, for e.g. one scenario could be where firmware owns specific planes (e.g., overlay1-3) while Linux owns others (e.g., overlay4-7), with hardware Z-ordering ensuring firmware planes appear on top. Here, rpmsg is used at probe time for resource negotiation where Linux requests partition assignments then writes display registers directly using it's own alloted register-space for all runtime updates, achieving zero IPC overhead per frame. rpmsg remains active for system events: suspend/shutdown notifications and fatal error handling ensure display integrity across core transitions. Following DRM's atomic helper pattern, rpmsg-kms provides a reusable core with vendor-specific callbacks, enabling platform choice between rpmsg-based updates or direct register access. This talk covers the architecture, protocol, device tree bindings, and vendor-ops interface along with open-challenges such as passing framebuffer addresses over rpmsg. er2026-92310-rpmsg-kms-a-unified-drm-framework-for-display-sharing-on-heterogeneous-embedded-socs Devarsh ThakkarBeleswar Prasad Padhi en false https://cfp.embedded-recipes.org/er2026/talk/PCYPJP/ https://cfp.embedded-recipes.org/er2026/talk/PCYPJP/feedback/ Auditorium Lightning Talk 2026-05-28T11:45:00+02:00 11:45 00:15 An in-kernel bootsplash has been part of the TODO list of the Linux DRM subsystem for quite a long time; some attempts to integrate one have been made in the past, without a successful merge. The talk will present a simple solution that has been recently proposed [0] by the author of the talk itself, the motivation behind the work and why it may be relevant for the embedded field, along with the reviews it received and the open points. But first, a quick detour will be made to present the drm-draw infrastructure and its other in-kernel users. [0] https://lore.kernel.org/all/20260106-drm_client_splash-v2-0-6e86a7434b59@valla.it/ er2026-92322-in-kernel-drm-based-bootsplash-past-present-and-future Francesco Valla en false https://cfp.embedded-recipes.org/er2026/talk/UCD33E/ https://cfp.embedded-recipes.org/er2026/talk/UCD33E/feedback/ Auditorium Lightning Talk 2026-05-28T13:30:00+02:00 13:30 00:15 Arm's Live Firmware Activation (LFA) spec (Arm DEN0147) describes an interface to trigger system firmware updates while the system is running. This could include SCP or other board controller firmwares, but also firmware running on the application processors, like Trusted Firmware-A. The talk will describe what the spec covers, which components are involved, and their upstream story. It will also give examples of already existing LFA firmware support, to illustrate what is possible and where the limitations are. er2026-92093-arm-lfa-update-your-firmware-at-runtime Andre Przywara en false https://cfp.embedded-recipes.org/er2026/talk/VFWHFS/ https://cfp.embedded-recipes.org/er2026/talk/VFWHFS/feedback/ Auditorium Talk 2026-05-28T13:45:00+02:00 13:45 00:40 The Linux camera landscape has transformed drastically since the kernel received its first ISP driver fifteen years ago. New kernel APIs and userspace frameworks have enabled development of fully open-source camera stacks. Constant engagement with vendors has slowly but steadily born fruits. This key combination of technical and non-technical efforts is starting to paint a brighter future for camera support in Linux. This talk will present the current state of the camera landscape, briefly explain the journey we took, and focus on the planned and foreseen evolutions. We will explore the impact on all actors in the industry, including image sensor vendors, ISP (SoC) vendors, and system integrators. Attendees will learn how they should get ready for the future of cameras in Linux and how it will benefit them. er2026-92141-linux-and-cameras-past-present-and-future Laurent Pinchart en false https://cfp.embedded-recipes.org/er2026/talk/8DPKWD/ https://cfp.embedded-recipes.org/er2026/talk/8DPKWD/feedback/ Auditorium Lightning Talk 2026-05-28T14:30:00+02:00 14:30 00:15 Cameras - especially the ones built out of a sensor connected to an embedded board - have a tendency to be hard to develop and debug. After the initial bringup and getting the core mechanics to work it is often time to look at actual images. Connecting external displays or opening single frames saved to the filesystem quickly becomes a tedious task. Time to introduce camshark, a tool that makes working on libcamera based cameras easier than ever. Camshark grew from an idea to a tool that is in daily use by many of the core libcamera developers. This talk will give an overview on the underlying concepts and show how camshark can be used for problem analysis and debugging of libcamera based cameras. er2026-92267-inspect-your-camera-using-camshark Stefan Klug en false https://cfp.embedded-recipes.org/er2026/talk/YELFES/ https://cfp.embedded-recipes.org/er2026/talk/YELFES/feedback/ Auditorium Talk 2026-05-28T14:45:00+02:00 14:45 00:40 Linux in combination with PREEMPT_RT is a popular operating system for embedded devices in real time environments and Time Sensitive Networks (TSN). Linux Real time networking applications range from industrial fieldbuses like PROFINET and Ethercat, Audio and Video Bridging (AVB) up to Automotive. Over the last years several networking technologies such TSN Qdiscs, XDP, zero-copy and busy polling have been added into the Linux kernel or improved for real time use cases. In this contribution we will show concepts and tools like the RTC-Testbench, evaluate what precision and performance as well as limitations and pitfalls can be expected when deploying Linux as operating system for these devices. er2026-92245-real-time-networking-with-preemptrt Kurt Kanzenbach en false https://cfp.embedded-recipes.org/er2026/talk/PDB3ZG/ https://cfp.embedded-recipes.org/er2026/talk/PDB3ZG/feedback/ Auditorium Lightning Talk 2026-05-28T15:30:00+02:00 15:30 00:15 Ethernet bring‑up on embedded hardware is supposed to be predictable: reset the PHY, bring up clocks, negotiate the link, and move on with your life. A routine kernel upgrade on an Arria 10 platform turned into an unexpectedly deep debugging journey through PHY reset sequencing, Ethernet CRC errors, and a behavior that only surfaced reliably with PREEMPT_RT. Along the way, I’ll introduce the basics of the Linux network stack as it applies to embedded devices: how drivers, PHYs, resets, and the kernel’s initialization paths interact, and why ordering matters. What followed was a debugging journey that went much deeper than expected. The symptoms were loud -CRC errors, severe packet loss at boot, and a driver that only behaved after an unbind/rebind but the root cause was hiding behind assumptions we never realized we’d made. The hardware, PHY, and DMA path all appeared to check out, leaving us to suspect something subtle in the initialization order. PREEMPT_RT made the failure reproducible, and that was the real clue. It forced us to revisit everything: PHY reset timing, misleading device‑tree reset names, and the subtle ways real‑time preemption changes how the kernel actually runs. A probe path that had always “worked” was only working because the non‑RT kernel had been quietly guaranteeing an execution order it never promised. This talk walks through the investigation, the wrong turns, and where things stand today. While we’ve narrowed the problem to initialization ordering and reset handling, the full picture is still emerging - and the ongoing work highlights how PREEMPT_RT doesn’t break your code, it just stops covering for it. er2026-92203-when-preemption-exposes-what-you-missed Mamta Shukla en false https://cfp.embedded-recipes.org/er2026/talk/8D7H8V/ https://cfp.embedded-recipes.org/er2026/talk/8D7H8V/feedback/ Auditorium Talk 2026-05-28T16:15:00+02:00 16:15 00:40 For years, utilizing hardware acceleration for machine learning at the edge meant being tethered to a vendor’s Board Support Package (BSP): a world of stagnant kernels, proprietary binary blobs, and zero auditability. The companies that wanted to run a modern ML workload had to accept their outdated software or spend months fighting it, in both situations risking vendor lock-in. That era is ending. Thanks to recent work in the Linux accel subsystem and Mesa, a truly open-source AI stack is now a reality. This talk goes over what is currently supported by the mainline stack and the existing four hardware drivers: Etnaviv (Vivante), Rocket (Rockchip), Ethos-U (Arm), and Thames (TI C7x). I will also explain what is missing and what is coming next. er2026-93086-four-npus-one-stack-zero-blobs-edge-ai-acceleration-in-mainline Tomeu Vizoso en false https://cfp.embedded-recipes.org/er2026/talk/7LYZUY/ https://cfp.embedded-recipes.org/er2026/talk/7LYZUY/feedback/ Auditorium Lightning Talk 2026-05-28T17:00:00+02:00 17:00 00:15 Is it possible to build a custom IoT device that feels as polished as a commercial product but remains entirely under your control? This talk explores a personal quest to escape cloud-based ecosystems using Matter over Thread for local-only communication. We will dive into the technical stack required to build your own gadgets using Zephyr, or ESP SDK. You’ll learn how to leverage the Matter standard to achieve seamless local control, avoid the Wi-Fi clutter with Thread and achieve impressive battery life. Lessons learned from integrating DIY sensors with Home Assistant and existing IKEA hardware, proving that you don't have to choose between customization and compatibility. er2026-92314-matter-over-thread-taking-full-control-of-your-iot-gadgets Stefan Schmidt en false https://cfp.embedded-recipes.org/er2026/talk/GMVQHM/ https://cfp.embedded-recipes.org/er2026/talk/GMVQHM/feedback/