OSS + ELC EU 2026

XDP (eXpress Data Path) is about running eBPF programs on network packets as early as possible. The goal of such an approach is performance: we minimise operating system networking stack overhead by letting the user decide which packets should reach it.

XSK is an extension to XDP allowing zero-copy redirect from the Ethernet driver directly to userspace processes. This approach approximates kernel-bypass solutions while remaining well integrated into the Linux networking stack for less critical traffic.

Both bring benefits but require adaptations on an Ethernet MAC driver standpoint; we'll dig into those. Quite some ground will be covered:
- allocators, their allocation patterns and memory layout,
- networking subsystem callbacks to be implemented,
- scheduling logic at runtime,
- performance numbers,
- etc.

Experience has been acquired through the upstreaming process of XDP & XSK support to the MACB/GEM controller driver, after having added Mobileye EyeQ5 support to the same driver.

References:
https://en.wikipedia.org/wiki/Express_Data_Path
https://ebpf.io/
https://www.kernel.org/doc/html/latest/networking/af_xdp.html

Edge AI runs on dozens of NPUs — Ethos-U, Hexagon, APUs, DSPs — each with its own closed toolchain and proprietary profiling tools. Application developers have no standard way to answer the basic question: what is my NPU actually doing?

This talk walks through the edge AI software stack — frameworks, delegates, drivers, hardware counters — and shows what it takes to make performance visible. Building on Tomeu Vizoso's Ethos-U PMU kernel work (upstream), we are instrumenting ONNX Runtime and TFLite operators with per-operator CPU PMU data (cycles, cache miss, bandwidth), surfaced via open trace formats, and wiring NPU hardware counter values into ExecuTorch ETDump traces on Zephyr.

The goal: per-operator timing, CPU cache and bandwidth data, and NPU cycle counts in a single open trace — without a proprietary tool.

Contributing to the Linux perf subsystem, this work lays the groundwork for open profiling support on other NPU targets.

Running a language model used to mean a datacenter GPU. This talk shows a 1-billion-parameter model generating tokens on a roughly $10 RISC-V board (the SOPHGO SG2002, as on the Sipeed LicheeRV Nano) with 256 MB of RAM no GPU, no Python, no cloud. The speaker walks the full embedded stack: a minimal C transformer inference engine running quantized GGUF weights, cross-compiled for RISC-V on embedded Linux, plus the quantization (4-bit GGUF), memory-mapping, and KV-cache choices that make it fit. The session is honest about the trade-offs, tokens-per-second, accuracy loss from aggressive quantization, and where an NPU or a microcontroller-class TinyML model is the better call. Attendees leave with a reproducible recipe for putting useful local inference on cheap, disconnected, privacy-sensitive hardware, and a clear-eyed sense of what 256 MB can and cannot do.

AI is inexorably puncturing into our daily lives in some way, shape or form. Up to now, cloud-based LLMs have been the most notable incarnations. And yet, our daily lives contain a slew of devices that remain, for now, of the "dumb" variant. As AI technology evolves, matures and gradually commoditizes, several underlying forces, which we'll examine, will increasingly push such functionality into edge devices. This will be especially true of Linux-grade devices that, on the surface, would seem to have the requisite capabilities to support AI-grade stacks.

This talk will examine the AI software stacks available to build edge AI devices based on Linux-grade systems, especially the seemingly infinite functionality permutations made possible by generative AI. While there have been several “open weights” models with licensing constraints, the recent introduction of the Gemma 4 family (under ASL), which includes models specifically targeted at IoT, is a game changer and likely a taste of things to come. We’ll survey available models and engines, such as llama.cpp and ollama, and how to build real systems with them while accounting for in-the-field challenges.

2nd of two companion talks.

The RISC-V ecosystem is maturing so rapidly that it's often hard to keep track, especially in the world of embedded systems. Now that RISC-V platforms meeting the "general-purpose" RVA23 specification - which mandates the vector and hypervisor extensions, among others - are available, this rate of change will only increase. We've been working hard on supporting RISC-V from the bottom up through Android, the Yocto Project, the Linux kernel, and we've even helped enable the Python ecosystem for AI at the edge. We want to share our experiences with our peers so that they can help contribute, avoid common pitfalls, and build great projects with our favorite new computer architecture. To do so, we'll cover everything we've done over the past year, what we're most excited about, and where we think the most challenging aspects of supporting RISC-V in embedded systems remain. We hope that this will be an inspiring roadmap for others looking to join the RISC-V community on its journey forward.

Processing large volumes of sensor data (e.g. Cameras, IMUs, Radar, etc.) on embedded hardware for real-time machine learning inference requires two critical performance metrics: high throughput and minimal latency.

Remote Direct Memory Access (RDMA) which originated in high-performance computing and cloud datacenters was designed for this use case . By enabling direct host-to-host memory transfers without kernel or CPU intervention, RDMA delivers throughputs exceeding 100 Gbps with microsecond-level latency.

In this talk, we present a complete, open-source sensor acquisition pipeline that brings RDMA to an embedded device. We demonstrate how camera data is acquired on an AMD Kria KR260, packetized into RDMA frames entirely within the FPGA fabric, and transmitted over Ethernet to a Jetson AGX Orin platform. The goal of this talk is that attendees will leave with a practical understanding of RDMA’s benefits in the embedded sector and have access to a powerful, open-source tool for high-performance data transfer.

Automotive Linux products must assess supply chain security at every release.
Yocto-based SBOMs can serve as the foundation, but many teams have yet to answer how much CVE triage to automate and where humans should make the call.
An OSS toolchain also enables the same foundation to be shared with suppliers, with no license barriers.

Yocto-generated VEX and rule-based filtering handle many CVEs, but ambiguity remains — provenance of third-party components, applied patches, unintended dependencies.
AI agents can handle that ambiguity, but opaque and non-deterministic outputs make it impossible to explain a missed CVE or a false positive that blocked a release.

This talk presents a design for that, with a Yocto-based CVE triage pipeline as the example.

The workflow begins with frozen inputs, passes through layered triage, and ends with human approval: inputs locked at CI trigger time (Input Freezing); rule-based and lightweight LLM filtering of straightforward cases (Layered Triage); a high-performance LLM presenting suggestions, with humans making the final call (Suggestion-and-Approval Loop).
These patterns apply to embedded supply chain management beyond automotive Linux.

With embedded devices now everywhere, from home appliances to industrial systems, it is vital to regularly scan them so that any known vulnerability (CVE) in software components can be identified and addressed before they become 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 towards more accountable and proactive security in embedded systems.

Released in December 2025, sbom-cve-check is an open-source automated vulnerability analysis tool. It operates directly on a Software Bill of Materials (SBOM), without requiring access to the original build environment. SBOMs can be generated from build systems such as Yocto, enabling post-build security analysis even when the build infrastructure is unavailable.

This talk will present sbom-cve-check, highlight its major improvements over the past six months, and explain how it is now fully integrated into Yocto, replacing the built-in cve-check class.

sbom-cve-check is provided under the GPLv2 license, and contributions are, of course, welcome :)

Eliminating cloud dependency and making connectivity optional is becoming essential for applications where data privacy, low latency, and reliability are critical. Running AI locally allows the system to respond immediately and keeps sensitive data on device which guarantees security. However, the cost is high. It introduces significant challenges due to computing, memory, and power constraints.

This session explores optimization techniques and algorithms mandatory for deploying vision, audio, and language models on resource-constrained edge devices. We will dive into methods such as quantization, model compression, and graph optimization, and show how to balance latency, accuracy, and energy efficiency.

Using widely adopted open-source frameworks like PyTorch and TensorFlow, along with intermediate ecosystems such as ONNX, we will demonstrate how to efficiently deploy from training a model to highly optimized edge inference. We will provide insight into making AI models smaller, faster, and more efficient with minimal impact on their accuracy, allowing them to run on microprocessor and microcontroller-class devices.

Come join us for the Embedded Linux Conference Annual Closing Game! Walt Miner, ELC Program Co-chair, will host the event, which is a fun opportunity for attendees to win amazing prizes.