Events in room UD2.120 (Chavanne)

Welcome talk covering some organizational questions

llama.cpp has become a key tool for running LLMs efficiently on any hardware. This talk explores how multimodal features have grown in the project. It focuses on libmtmd, a library added in April 2025 to make multimodal support easier to use and to maintain in llama.cpp.

We will first cover main achievements. These include combining separate CLI tools for different models into one single tool called llama-mtmd-cli. Next, we will discuss how libmtmd works with llama-server and show real examples of low-latency OCR applications. We will also talk about adding audio support, which lets newer models summarize audio inputs. Plus, we will cover the challenges of handling legacy code while keeping the project flexible for future models.

Looking forward, the talk will share plans for new features like video input, text-to-speech support, and image generation. Attendees will also learn how to contribute and use these multimodal tools in their own project.

Running modern Large Language Model (LLM) workloads on macOS presents a unique challenge: reconciling powerful local hardware with a mature, Linux-first AI tooling and container ecosystem.

The Problem: Bridging the OS and Acceleration Gap

While containerization offers macOS developers access to Linux-centric tools like Ramalama and the Podman Desktop AI Lab, introducing a virtualization layer immediately compromises GPU acceleration. Direct device passthrough is infeasible, as it monopolizes the display and host system resources. Consequently, achieving high-performance LLM inference requires a sophisticated bridging mechanism.

The Solution: Para-Virtualization via GGML API Remoting

We present the implementation of an API-remoting, para-virtualized execution path for llama.cpp. This novel design is built directly on the GGML API, allowing us to selectively offload compute-intensive operations to execute on the macOS host. Crucially, this execution path natively leverages the GGML-Metal backend, achieving full-speed host performance. This strategy preserves a fully containerized Linux developer experience inside the virtual machine while achieving hardware-level acceleration outside of it.

Performance and Implications

We will share concrete performance results demonstrating near-native inference speed compared to running llama.cpp directly on the host. The talk will examine the architectural trade-offs of this split-execution model, providing insight into:

• The implementation details of the para-virtualized GGML API bridge.
• The latency overhead of API remoting versus the throughput gain from host GPU execution.
• How this open-source approach fundamentally changes the future of containerized and accelerated AI tooling on non-Linux platforms, specifically addressing the needs of macOS users in the open-source AI community.

Deploying neural networks in production environments presents unique challenges: models must run efficiently across diverse hardware, from powerful servers to resource-constrained embedded devices, while maintaining predictable performance without heavy runtime dependencies.

This talk introduces tract, Sonos's open-source neural network inference toolkit started in 2018 and written in Rust. We'll explore how tract bridges the gap between training frameworks and production deployment by offering a no-nonsense, self-contained inference solution used today to deploy deep learning on millions of devices at Sonos.

This toolkit has some unique strengths thanks to embedded graph optimization, automated streaming management, and symbolic abstraction for dynamic dimensions — plus support for multiple open exchange standards including ONNX, NNEF, and TensorFlow Lite.

tract also has a companion project coined torch-to-nnef that strive to export PyTorch models to an NNEF optimized for tract with maximum compatibility. It enables some unique features like quantization, better Fourier Transform support and easier extensibility: this will also be discussed shortly during this presentation.

Can an ESP32-based MCU run (tiny)ML models accurately and efficiently? This talk showcases how a tiny microcontroller can transparently leverage neighboring nodes to run inference on full, unquantized torchvision models in less than 100ms! We build on vAccel, an open abstraction layer that allows interoperable hardware acceleration and enable devices like the ESP32 to transparently offload ML inference and signal-processing tasks to nearby edge or cloud nodes. Through a lightweight agent and a unified API, vAccel bridges heterogeneous devices, enabling seamless offload without modifying application logic.

This session presents our IoT port of vAccel (client & lightweight agent) and demonstrates a real deployment where an ESP32 delegates inference to a GPU-backed k8s node, reducing latency by 3 orders of magnitude while preserving Kubernetes-native control and observability. Attendees will see how open acceleration can unify the Cloud–Edge–IoT stack through standard interfaces and reusable runtimes.

During 2025 we ported ExecuTorch, the extension to PyTorch for embedded systems, to a bare metal multi-core RISC-V microcontroller based on the CORE-V CV32E40Pv2 processor.

In this talk we'll explain the steps we had to take to achieve this. - removing dependencies on an underlying operating system - how to handle memory management between slow main memory and fast local memory - how to handle tiling and operators on bare metal multicore systems - how to take advantage of custom acceleration

The goal is for others to be able to bring up ExecuTorch on other bare metal microcontrollers, learning from our experiences.

As AI workloads move to the browser, the lack of a unified low-level acceleration layer on Linux—equivalent to DirectML or CoreML—creates major bottlenecks. In this talk, we explore how WebNN and next-generation WebLLM can unlock efficient on-device inference on RISC-V, using Tenstorrent hardware and the emerging RVV 1.0 Variable-Length vector ISA. We cover the challenges of WebNN integration on Linux, the importance of WASM support for RVV, and demonstrate progress on running modern LLMs directly in the browser. We will also detail the RVV-enabled WASM implementation path for WebNN and what’s needed upstream.

Leveraging Rust and Khronos' emerging Slang initiative, we introduce our efforts toward a cross-platform GPU LLM inference ecosystem. With a single-source approach we aim to minimize backend-specific code and foster community participation by writing inference kernels once and run them everywhere.

AI workloads increasingly target heterogeneous accelerators, from GPUs and TPUs to novel RISC-V architectures, each with different scheduling, memory, and concurrency constraints. Traditional compilers rely on static heuristics that do not generalize across devices and custom neural network layers.

In this talk, we present the Daisytuner Optimizing Compiler Collection (DOCC), a self-learning compiler that closes the optimization loop by continuously collecting performance data from real executions and feeding it back into the compilation pipeline. The system represents code regions using stateful dataflow multigraphs, an open-source intermediate representation that enables symbolic dataflow analysis. Performance profiles in the form of hardware counters and execution times are ingested into an online embedding database that the compiler can query to derive and apply new optimizations.

We describe the generation of SDFGs from ONNX and PyTorch via IREE, the passes for mapping the IR to backends, and the benchmarking infrastructure running on our super-heterogeneous cluster. We conclude by showing how this feedback pipeline allows the compiler to evolve its optimization strategies automatically, improving schedules without human intervention.

Serving multiple models on a single GPU sounds great until something segfaults.

Two approaches dominate for parallel inference: MIG (hardware partitioning) and MPS (software sharing). Both promise efficient GPU sharing.

I tested both strategies for video generation workloads in parallel.

This talk digs into what actually happened: where things worked, where memory isolation fell apart, which configs crashed, and what survives under load.

By the end, you'll know:

1. How to utilize unused GPU capacity.
2. How to setup MIG and MPS.
3. Memory issues, crashes, and failures.
4. Workload specific configs

OneAI is an open-source framework that provides the foundation required to manage AI model artifacts and inference workloads across OpenNebula-based cloud infrastructures. In this talk, we present how OneAI discovers, imports, and deploys models directly from Hugging Face Hub into OpenNebula clusters—turning complex AI lifecycle operations into a streamlined, infrastructure-native workflow. OneAI is built around three core components: (1) HFHUB Marketplace, a lightweight catalog that indexes Hugging Face models as metadata, deferring artifact materialization until deployment to dramatically reduce storage overhead; (2) SharedFS Datastore, a specialized OpenNebula datastore that treats directories as images, enabling efficient model storage on high-performance shared filesystems; (3) AI Service REST API, an orchestration layer that provisions model deployments, supervises the vLLM inference engine, and exposes OpenAI-compatible endpoints. We will provide an overview of the architecture behind these components and how they work together to create a clean, reproducible pipeline – from model discovery to fully deployed inference services. OneAI offers a fully open-source alternative to proprietary inference platforms. By building directly on OpenNebula’s capabilities, it reduces TCO by exploiting existing HPC storages, supports secure multi-tenancy, and enables scalable, production-ready inference deployments.

Most Machine Learning tools use CUDA for hardware acceleration, and are as a result only compatible with Nvidia GPUs. AMD has been making a lot of progress enabling simple recompilation with minimal code changes to ROCm for their hardware, but why not use an open and broadly-compatible API instead? That's where Vulkan comes in, which was built up for game development, but also allows compute-only applications, and has broad and good driver support across many hardware vendors.

As a follow-up to last year's talk about my work on the llama.cpp/GGML Vulkan backend, this talk will discuss lessons learnt from optimizations and new features that we added since, how viable Vulkan is for Machine Learning and what it is still missing.

https://github.com/ggml-org/llama.cpp https://github.com/ggml-org/ggml

Running various forms of inference on microcontroller NPUs is not new. Systems where machine learning is used to analyze sensor data or do light CV on microcontroller-grade systems under 1 watt, under few dozen MB of RAM and FLASH and under 10 USD bill-of-materials are being massively deployed (even if they stay in the long shadow of more flashy LLMs and GenAI). That area, however, historically has been a domain of specialized machine learning frameworks such as emlearn, LiteRT (artist formerly known as TensorFlow Lite) and a few others.

The question I will try to answer in this talk is the following: are there any benefits of trying to use more well established, but still pretty tightly optimized frameworks such as ggml and tinygrad for these types of deployments. I will share my experience with adopting these frameworks to targets such as Google Coral NPU and AI Foundry Erbium and what kind of interesting challenges it presented.

The growing energy demands of modern AI models pose a significant barrier to sustainable computing. As model complexity and deployment scale continue to rise, training and inference increasingly contribute to carbon emissions and operational costs. This talk begins by examining the technical challenges of accurately measuring energy consumption at multiple levels of abstraction—from system-wide and process-level metrics down to individual source code methods and API calls. Practical strategies for overcoming these measurement hurdles are discussed. The second part of the talk explores power consumption patterns in GPU kernels, highlighting how thread configuration, block geometry, and power limit settings shape kernel-level energy efficiency. We demonstrate how these characteristics influence power draw and discuss techniques for predicting consumption based on kernel properties. The session concludes with insights and best practices for managing performance–energy trade-offs in GPU-accelerated AI applications, offering a path toward more sustainable AI development.

Silicon engineering seems unobtainable elite industry only for those veterans of the industry that have access to expensive instruments and years of experience, right? Well, not anymore! With AI tools, coding agents and more and more available substrate to hook them up to, you can approach it as a system design, and start in days! Make new models inference on novel accelerator cards, put open cores in FPGA, and other tricks you can do without specialized engineering degrees. Not suggesting to tape it out and put it in production without proper review, but for prototyping and faster feedback cycles it's really changing the game! I'll demo a couple of examples all based on open IP!

The explosive growth of Large Language Models (LLMs) requires massively efficient and scalable inference systems. This talk will share key innovations NVIDIA Dynamo (https://github.com/ai-dynamo/dynamo) adds to enable system-level optimizations while leveraging performance from inference engines such as vLLM, SGLang, and TRT-LLM:

• Smart Scheduling that routes requests based on the KV cache hit rate and load, intelligently autoscales, and disaggregates the prefill and decode phases.
• Hierarchical Memory Management that utilizes HBM, host memory, local disk, and remote storage.
• Low-Latency Transfer of the KV cache across nodes and the memory hierarchy.

This talk will also introduce production-grade LLM serving features of Dynamo that enable users to: - Find the best configuration for disaggregated serving offline. - Tune performance automatically based on real-time traffic. - Dynamically scale prefill and decode workers via topology-aware gang scheduling. - Leverage LLM-specific fault tolerance.

Running LLMs is currently fraught with friction: dependency hell and the ungoverned management of massive weight files (GGUF, safetensors).

In this talk, we introduce Docker Model Runner (DMR), an open initiative to bring the same standard of reproducibility to AI models that containers brought to code. We will explore how DMR streamlines the "pull, push, run, serve" lifecycle by treating AI models as first-class OCI (Open Container Initiative) artifacts, decoupling the model weights from the inference engine.

We will dive deep into the architecture of the Docker Model Runner, covering:

Models as Artifacts: How we package and distribute GGUF and safetensors formats using OCI-compliant registries, eliminating the need for arbitrary file downloads.

A Unified Interface: How DMR abstracts the complexity of underlying inference backends. We will discuss the integration of llama.cpp for broad hardware compatibility (CPU/GPU) and vLLM for high-performance production serving.

The Model Driver Pack: How the runner handles hardware acceleration automatically, managing the interface between the container runtime and host resources (NVIDIA CUDA, Vulkan, etc.).

Developer Experience: A look at the docker model CLI plugin and the local REST API that allows developers to swap models without changing their client code.

Join us to see how we are building a standardized, open ecosystem where docker model run ai/gemma3 is all you need to start building AI applications.

Key Takeaways for the Review Committee (Why this fits FOSDEM): Open Standards: The talk focuses on OCI compliance and open weights (GGUF/safetensors).

Open Source Integration: It highlights the usage and orchestration of popular open-source projects (llama.cpp and vLLM).

Technical Depth: It addresses infrastructure challenges (GPU passthrough, artifact management) rather than just high-level AI concepts.

Last year, I shared Paddler, an open-source LLM load balancer. A year of community feedback and building Poet (a static site generator with AI features) on top of it taught me what actually matters when self-hosting LLMs. This talk shares practical patterns the open-source community needs. What works, what doesn't, and what tooling we still need to build together.

This talk will focus on ET Platform, the AI Foundry's open-source RISC-V based manycore architecture.

After a quick introduction, it will show how to get started on building and running the ET platform software in your machine, how to write software for ET accelerators and how to contribute to the project.

For more information about AI Foundry and the ET platform visit https://https://github.com/aifoundry-org/et-platform

The ET-SoC-1 chip contains more than one thousand RISC-V cores, with custom vector and tensor extensions on each core, and has recently been given a new open-source lease of life [1]. What do low-level AI software engineers do with novel hardware? Obviously the answer is to make it do matmuls.

Join me on a rapid journey from naïve matmul to optimized matmul, learning about ET-SoC-1 along the way. Some of its hardware features will help us, whereas others will be a hinderance.

[1] https://github.com/aifoundry-org

RISC-V is rapidly evolving into a serious platform for AI acceleration—from embedded devices to full AI PCs and datacenter-class compute. But building real, production-ready AI systems on open hardware still poses challenges: memory bandwidth bottlenecks, heterogeneous compute scheduling, toolchain maturity, and model deployment efficiency. As part of this session, we will also briefly share DeepComputing’s AI product roadmap to illustrate how these engineering breakthroughs translate into real devices. In this talk, engineers from DeepComputing and Tenstorrent will share how we are solving these challenges together across two ends of the computing spectrum: • AI PC / edge devices: How we integrate high-performance RISC-V CPUs with NPUs, optimize dataflow for multi-die architectures, and overcome compiler/runtime fragmentation to run LLMs locally. • AI servers: How Tenstorrent’s RISC-V cores and scalable mesh architecture handle AI workloads; how we bridge the software gap (compilers, toolchains, scheduling, kernel-level tuning); and how we standardize low-level interfaces for AI compute. The focus is on how these problems are solved—microarchitecture decisions, data movement, kernel optimizations, interoperability layers, and lessons learned from building real products. This session will show why “All in RISC-V, RISC-V All in AI” is no longer a slogan but a practical engineering path forward.

In the last 10 years there's been a hardware race to build the best application-specific integrated circuit (ASIC) for both machine learning training and inference i.e. AI accelerators. What started with vision processing units (VPUs) went through tensor PUs (TPUs) and now we are dealing with neural processing units (NPUs). What's next?

This talk will take a systematic look at the different hardware platforms for AI acceleration, but with a focus on the software stacks that support them on Linux. We'll take a look how individual vendors approached their ASICs from the kernel side, and how they exposed the acceleration functionality for user-space.

Is it all proprietary or is there liberté? We'll find out together!

Boltz-2 is a state-of-the-art model that builds on the general architecture of AlphaFold 3, predicting biomolecular structures and binding affinities.

BoltzGen is a system that builds on Boltz-2 and designs protein binders (potential drugs) to biomolecular targets.

We implement both systems on Tenstorrent hardware to make drug discovery more open, more efficient, and cheaper.

GitHub Repository: https://github.com/moritztng/tt-boltz My Thesis: https://moritztng.github.io/thesis/thesis.pdf

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

• https://www.ariel-os.org
• https://github.com/ariel-os/ariel-os/
• https://ariel-os.github.io/ariel-os/dev/docs/book/
• https://embassy.dev/
• https://github.com/rust-embedded/embedded-hal

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:

• GPU acceleration
• FOSS sensor calibration setup and color correction using CCMs
• Lens shade correction
• Linux distributions shipping softISP MIPI camera support OOTB

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.

Fluorite is a new open-source 3D game engine built in Flutter. It allows developers to leverage the Flutter & Dart ecosystem to write game logic, and to integrate it with Flutter’s rich UI toolkit to build stunning interactive experiences across the board.

At the same time, all the complexity is hidden away behind its highly-efficient C++ ECS core, ensuring performance and portability across mobile, desktop, embedded and console platforms.

By integrating Filament, Google’s 3D rendering engine, Fluorite delivers best-in-class PBR rendering performance and quality, enabling high-fidelity creative workflows.

In this intermediate-level session for Flutter and game developers, we will demonstrate Fluorite's tech demos and the code behind them, as well as illustrate how to set up 3D scenes and assets, and leverage Flutter widgets in your game UI. We’ll compare Fluorite’s approach against existing solutions, highlighting how its Dart-first architecture streamlines iteration with Hot Reload, multi-platform support, Widget Inspector, and the full pub.dev ecosystem.