Open Source Summit North America 2025

U-Boot provides a fairly new feature called Standard Boot, which replaces the scripts and masses of environment variables previously used. Standard boot can boot your device automatically and quickly.

This session dives into how embedded devices boot, how Standard Boot works under the hood, the benefits of adopting Standard Boot and how to write your own bootmeth and bootdev drivers. By way of example, some existing drivers are covered, including UEFI, extlinux, Android and ChromeOS.

It also provides a general update on U-Boot and what the future might hold.

SoCs are increasingly heterogeneous, featuring multiple processor clusters and special-purpose accelerators. As a result, Asymmetric Multiprocessing (AMP) systems must support different operating environments running concurrently on the same chip. This talk outlines the software architecture needed to develop applications for AMP setups, enabling operating systems to interact across diverse homogeneous and heterogeneous configurations. In this way, AMP applications can leverage the parallelism provided by these varied architectures.

Our prototyping efforts focus on low-cost RISC-V processor cores configured as AMP systems, running both the Linux kernel and RTOSes such as ThreadX. This setup includes an IPC layer that implements RPMSG communication between cores. Additionally, our proxy infrastructure highlights how a proxy on the master core can handle POSIX library calls from RTOS-based remote contexts.

Software Bill of Materials (SBoMs) are being increasingly called for in all Software ecosystems, to the point of being mandatory for regulatory compliance. The Embedded space is no different in this regard, so being aware of the available options for complying with SBoM is becoming critical for Embedded development.

In this talk, Joshua will outline prominent options for dealing with SBoM requirements across Open Source Embedded-focused projects, and what to look for in SBoMs for embedded projects to maximize their usefulness.

Leveraging the recently added Power over Ethernet (PoE) Power Supply Equipment (PSE) support, this talk will go over the current status and the experience implementing support for the LTC4266, the last major PSE chipset on the market. We'll go over the basics of Power over Ethernet, the existing upstream support and in-kernel framework, the user-space interface for controlling PSE, and then dive into the LTC4266 driver specifics.

This presentation is the story of Honda's first in-house software development of IVI(In-Vehicle Infotainment) software.
Why Honda promotes in-house software development - Building an in-house software development team that started with two people, All development process from scratch, There is no silver bullet that will solve many problems.
However, we were able to launch this model successfully based on Honda's DNA of Waigaya, A00, and 120% quality products. The key to this is the use of AOSP(Android Open Source Project) and some OSS.
This presentation will show how a traditional automotive OEM like Honda was able to create an in-house software development team and use OSS, including AOSP. By applying OpenChain(ISO/IEC 5230) self-certification and SPDX Lite to our development process, we solved many problems and achieved a higher starting point.
However, vehicles have difficult requirements, so we will tell you the points to minimize the customization of OSS.

While working with the RADXA ROCK 5B, a low-cost/high-performance RK3588 aarch64-based development board, we discovered that it is picky concerning the used USB Type-C power source. What was rather strange is that while it worked on our upstream Linux kernel (at the time of writing v6.13.1) based Embedded Linux system, it just boot-looped running RADXA's Debian (using a Rockchip downstream v6.1 based kernel). At the same time, my colleagues were working on the Testing in a Box version 2 (TIABv2) integrating USB Type-C power delivery which we plan to use in our board farm once ready. Of course, as soon as they had prototypes I gave it a try and it also showed the problem. By chance, both sides are using the exact same onsemi FUSB302B programmable USB Type-C controller with power delivery. The TIABv2 one is configured as a power source and the ROCK 5B one is configured as a power sink. This talk introduces the USB Type-C power delivery topic and then discusses how we joined forces and debugged both sides, at times giving the ball to the TIABv2 firmware, at other times to the Linux kernel fusb302 driver and back and forth again.

SPI offloading is a new feature slated to land in the 6.15 kernel. Come learn what it is and what it can be used for.

“Offloading” is a generic term that refers to using additional hardware connected to a SPI controller to handle tasks traditionally done in software, like initiating a SPI transfer and handling an interrupt when the transfer is complete. Having these functions offloaded to hardware is useful for applications like high speed data acquisition (think 1 million samples per second for an ADC) or to meet latency requirements (think CAN bus controller).

In this session, we will cover the thought process that went into designing an interface that can handle these varied applications and the solution we arrived at. We will also take a side trip to discuss hardware triggers that can be used as part of the SPI offload functionality and how they could potentially become a standalone subsystem for generic hardware triggers. Then we will take a look at how we put it all together in a real ADC driver to get 2.5 million samples per second. Finally, we will cover other potential use cases for SPI offloading and how one could go about adding support for these.

This presentation showcases optimizing sensor data acquisition for embedded systems using the Linux IIO subsystem and libiio, with a special focus on developing algorithms on the host to capture data from remote hardware. The IIO subsystem offers a versatile framework for interfacing with sensors like ADCs, DACs, and IMUs, streamlining the management of diverse data streams. With libiio, developers can capture data from remote devices efficiently, simplifying integration and allowing for sophisticated data processing in user-space applications. We explore the architecture of the IIO subsystem, highlighting its modular design that enhances scalability and adaptability in embedded settings. The paper also covers practical methods for configuring and optimizing IIO drivers to improve performance and reliability. Real-world examples with Raspberry Pi demonstrate how libiio supports the rapid prototyping and deployment of sensor applications, with an emphasis on developing algorithms on the host. Attendees will learn best practices for creating high-performance data acquisition systems that ensure seamless integration and efficient resource use across distributed systems.

Traditionally, Virtio is primarily used in virtualized environments to allow the Hypervisor to Guest communication in an agnostic way. But Virtio as a standard can be leveraged outside virtualization for communication between any two entities.

The PCI Endpoint subsystem in the Linux kernel is used to run Linux on tiny PCI endpoint devices such as modems, NIC, GPU, etc... It requires the developers to write function drivers to communicate with the host. On most occasions, these function
drivers also require counterpart drivers on the host systems. This increases the time required for the project's development, as the development needs to happen on both the host and endpoint systems.

This is where Virtio comes in handy for the PCI Endpoint subsystem. With Virtio, developers can focus on developing the back-end drivers on the endpoint side and leverage the existing front-end drivers on host systems (such as virt-net, virt-gpu, etc...).

In this talk, Manivannan Sadhasivam will present the proposals received from the community for adding Virtio backend support to the PCI Endpoint subsystem and elaborate on the one that got a consensus to move forward, along with the future plans.

In June last year a bunch of new laptops, based on the Snapdragon X Elite, have been launched. All major laptop vendors launched devices, with over three
dozen to choose from at the time of this writing. Offering a nice alternative to ChromeBooks or MacBooks for Arm enthusiasts. No matter if you are intrigued by the battery life, performance or always wanted an arm64 based system to natively
compile for your embedded targets.

The core question is, how good is the Linux support. Being designed for Windows-on-ARM there is a risk Linux support is rudimentary at best. Does boot with UEFI work out of the box? Is there a device tree description for your specific device? Which hardware features are already supported mainline?
Is the firmware for various drivers available? How is the performance?

In short, is it usable as a daily driver for a developer? Stefan set out to find out, and report here.

In this talk he will provide details on the current state of development of these devices. An in-depth view on the hardware support: what is in mainline, which patches are pending and what is missing completely.
[Target: ELC North America]

The Web engine is the most important component of a Web browser, enabling developers to leverage the Web Platform for their applications. And thanks to Open Source Web engines like WPE, it is now possible to build all kinds of products for embedded devices using Web-based technologies, from set-top boxes and smart home appliances to GPS devices and in-flight infotainment systems, to name a few.

Unfortunately, companies usually fall into the trap of applying one-off fixes to meet their immediate needs, accumulating technical debt and struggling to adapt to the evolving nature of the Open Source projects they heavily rely on. On top of that, it makes it difficult to ensure that the stable releases of such projects properly fit the needs of the products they intend to build, leading to spending too much time being reactive to integration-related problems instead of focusing on building a great product.

In this session, we will focus on explaining the best practices to unlock the full power of WPE without falling into such traps, so that you can focus on building a stronger foundation for your future embedded products with WPE, while keeping maintenance costs under control.

The test harness (aka board farm) was initially designed to enable automated testing of Linux drivers on actual hardware. This ultimately became a way to implement continuous testing on hardware, every commit or PR, a build and test is run, and results are reflected back to the commit. It is designed to cater a wide range of peripheral devices and platforms mainly for Analog Devices' Kuiper Linux distribution which is built with more than 1000 Linux device drivers compatible with Xilinx and Intel FPGAs, Raspberry Pi boards, and several other platforms.

This talk covers the design and implementation of such a fully automated test harness. The implemented architecture leverages the use of readily available components/technologies such as Jenkins, Docker, NetBox, and JFrog Artifactory and, at the same time, includes custom-built tools that can be tailored and extended to support existing or new devices and platform types.

This talk will also cover how the team handled the challenges encountered while implementing and addressing features such as resource queueing to minimize waiting time of running builds and also how we make use of sdcardmux to handle recovery.

Virtio-msg is a new virtio transport that allows Virtio to be used on AMP systems between Linux and Zephyr on a co-processor, between the Linux Kernel and Secure World TEEs like Trusty and OP-TESS, and other places where Virtio-mmio and Virtio-pci do not work.

Media Request API was designed to allow V4L2 devices like memory to memory video processing or codec devices and complex camera pipelines to support per frame settings and per frame metadata. In this talk we will deep dive on the details of this API with example use cases such as memory to memory video processing devices and complex ISP pipelines using this API for per frame settings and per frame metadata.

The Yocto project offers unparalleled flexbility in how you structure your embedded Linux image builds. Yocto's multilayered approach enables us to build different images for different purposes (e.g. development, production, etc). This flexibility extends beyond the image build process out to runtime.

What if you could load debug symbols onto an edge device? Restart your application with gdbserver? Start bpftrace sessions? Connect to a VPN? All at the press of a button? You can through the magic of systemd and overlayfs. systemd-sysext activates and deactivates system extension images merging them together to compose the contents of your /usr/ and /opt/ directories.

By separating your root filesystem into individual layers that each do one thing and one thing only, you can respond to trouble by reconfiguring your system at runtime. I will show you how to leverage system extension images and btrfs subvolumes to build Yocto images that can be reassembled on demand.

OP-TEE is an open source Trusted Execution Environment (TEE) designed as a companion to the rich Linux operating system environment. Memory safety is critical to OP-TEE because its applications provide secure interfaces that can be used by the (potentially compromised) rich OS to manipulate user's/system credentials, keys and confidential data. In particular Rust's memory-safety guarantees can be a huge step forward to harden the OP-TEE environment against any memory based exploits.

This session will focus on the evolution of Rust within the OP-TEE ecosystem, the story to make Rust a first class citizen for writing OP-TEE Trusted Applications (TAs) and how we can build Rust TAs at performance parity with their C counterparts. As well as reviewing the work to date, we'll also look at some options for leveraging Rust's memory- and thread-safety features within OP-TEE core itself: should we start with enabling pseudo trusted applications to be written in Rust?