Open Source Summit North America 2025

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]

We describe about a userspace daemon that integrates with the Linux kernel's Pressure Stall Information (PSI) mechanism to monitor and detect memory pressure events, and requests for adding/removing memory blocks from the host based on real-time memory demands in the system without need for intervention of an admin/host. The virtio-mem interface is used for communicating with the host for adding/removing memory blocks.

Detecting increase in memory demand – the daemon registers to certain PSI events and monitors pressure building up when memory allocations occurs. Using these predefined thresholds trigger the daemon to request additional memory from the host when minimal pressure is detected, indicating an active memory-intensive use case is running.

Detecting decrease in memory pressure – the daemon monitors pressure decay and psi averages (avg10, avg60, avg300) along with other memory stats. and makes an educated guess about memory usecases have ended and releases blocks back to host. The process of tracking memory pressure going down and releasing memory back to host is done in a separate thread. 

More details on design and logic will be explained in the presentation session.

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.