After a first episode, our series of blog posts with our selection of talks we liked at the latest Embedded Linux Conference continues. Read on to discover 4 more talks that we enjoyed, and decided to summarize and highlight for you.
Talk Whack-a-Mole with DTS Validation in the Linux Kernel, by Krzysztof Kozlowski, Linaro
Talk chosen by Bootlin engineer Alexandre Belloni
Krzysztof is one of the co-maintainers of the Device Tree bindings in the Linux kernel. The Device Tree is a hierarchical data structure used to describe the hardware components of a system. It provides a way for the operating system to discover and initialize the hardware without relying on previously hardcoded information in the kernel. This structure is compiled from sources (Device Tree Source – DTS) to a binary format called Device Tree Blob (DTB).
The Device Tree bindings define the rules and guidelines for writing device tree source (DTS) files for specific hardware components. These bindings describe the required and optional properties for each type of hardware, how those properties should be formatted, and what values they can take. They serve as documentation. They used to be simple text files but are now getting rewritten in the Device Tree schema which is YAML based and can be parsed by a machine. The bindings can then be used to validate device tree source files, ensuring that they adhere to the specified format and contain all necessary information.
This helps catch errors early in the development process and ensures compatibility with the kernel. In Linux 6.8, there were still about 1500 bindings in plain text format.
Krzysztof then explains that is is getting important to have proper bindings to validate new Device Trees because while upstreaming support for a new SoC, about a third of the changes are in the Device Tree versus actual C code for platform and drivers support.
He then presents compelling statistics on how Device Tree Compiler (DTC) warnings in the upstream kernel have evolved from version 5.3 to version 6.8, decreasing from up to 77 per target to fewer than 10 per target. Subsequently, he provides DT schema validation warning statistics for the same kernel versions, noting that progress in addressing these warnings has been slower.
The final analysis examines the actual impact of fixing issues reported by the DT schema validation. It reveals that 10% of the fixes addressed actual bugs, and another 10% likely resolved pre-existing issues, underscoring the value of this effort.
The remaining issue is that for some platforms, the number of introduced warnings persists, leading to a continuous cycle of addressing new warnings as they appear—hence the “Whack-a-mole” reference in the title.
Debugging Heterogeneous SoC Using OpenOCD, by Nishanth Menon, Texas Instruments
Talk chosen by Bootlin engineer Richard Genoud
This talk is about debugging microcontroller(s) that are inside a heterogeneous SoC, like the TDA4VM from TI but it could also work for a STM32MP15x from ST for instance.
Nishanth Menon, like most of us, is a lazy kernel developer. He would like to debug his microcontroller(s) without the burden – and cost ! – of buying a JTAG, find the headers on the board, buy another cable because the one you have is not the right one, plug it… Just to start debugging.
Usually, to start debugging a microcontroller, we are using GDB with openOCD on our PC, plug a USB-JTAG interface on our board so that openOCD can talk to the debug subsystem of the microcontroller (via ARM CoreSight technology).
How could we get rid of that hardware (USB-JTAG header) ? Nishanth’s clever hack is to soft-wire OpenOCD directly on debug registers via /dev/mem, from a Linux system installed on the Cortex-A72. If this works directly with the Cortex M4F (direct access to the CoreSight access port), he had to put more effort and create an emulated Access Port to make that work for the Cortex R5Fs.
Of course, openOCD has to be cross-compiled (with --enable-dmem) for the Cortex A72 target, and the kernel must have CONFIG_DEVMEM set, but once done, you’ll have access to all the microcontrollers of your SoC without plugging any cable.
The beauty of this is that the access is blazing fast (100s MHz) compared to hardware access (10s MHz for the more expensive ones). The drawback is that there’s no discovery possible as the ROM table is behind the JTAG access path. So, definitions have to be static.
I was really impressed by this hack, that gets rid of expensive hardware while being way faster ! Kudos to Nishanth Menon & Jason Peck !
Talk WirePlumber 0.5: Bringing Smart Audio Filters to PipeWire by Julian Bouzas, Collabora
Talk chosen by Bootlin engineer Louis Chauvet
This presentation provided an update on Pipewire and Wireplumber, the new audio and video servers for Linux. Julian Bouzas introduced the latest release of Wireplumber, version 0.5, which features a stable API. This version includes several new features, such as an improved event dispatcher, JSON configuration, settings management, and, most notably, a smart filter policy.
Previously, Pipewire allowed for the management of certain filters, such as noise cancellation, echo cancellation, and equalizers. However, their configuration was complex, as users had to manually adjust them each time they wanted to change the configuration. This meant that every time a device was switched, the configuration needed to be modified. For example, if noise cancellation was desired for a headset, but echo cancellation was needed when using speakers, the configuration had to be adjusted accordingly.
The new smart filter policy allows for the configuration of filters per device. This means that users can set up specific filters for different types of devices, such as “add noise cancellation when using this type of device, or add an equalizer for external headsets.” As a result, when a new device is connected, the appropriate filter will be automatically applied.
One great application of this feature is the ability to automatically add a filter to switch from HPD to A2DP profile on a Bluetooth device. The A2DP profile does not have a record feature, while the HPD device has a lower quality audio but has a record. The filter will always expose a record and play source/sink and will automatically switch the profile if needed.
This presentation was very informative about the current state of Pipewire and Wireplumber. I am thrilled to see these types of advancements, as they greatly improve usability of audio and video in Linux.
Accelerated Porting of Linux, U-Boot and Yocto for Production Ready Embedded Systems – Vaishnav Mohandas Achath, Texas Instruments
Talk chosen by Bootlin engineer Grégory Clement
In this talk, Vaishnav Achath, an engineer from Texas Instruments (TI), presents a comprehensive overview of how to port U-Boot, Linux, and Yocto on a new System on Chip (SoC) or a new board. Keerthy J, who is also an engineer from TI, co-wrote this talk but was not present.
While it’s impossible to cover step-by-step instructions for adapting the code for these three major pieces of software in just 40 minutes, this talk does an excellent job of highlighting all the key steps you need to go through to port U-Boot, Linux, and Yocto for a new platform.
In the first part of the talk, Vaishnav focuses on SoC bring-up for these three components. Although this task is typically done by the SoC vendor, it’s still useful to understand how a SoC is supported, and it can provide a good starting point for debugging your own board.
Next, he presents the board bring-up process. This is more commonly done by developers, and while this section is relatively short, it concludes with a helpful list of common issues and, of course, how to debug them.
Finally, Vaishnav presents case studies and examples. Having real-world cases is incredibly useful, and although most of the things presented are TI-oriented, it’s still quite informative if you plan to use a TI platform.
Overall, I highly recommend this talk if you’re looking to start using Linux on a new platform. At the very least, I encourage you to read the 30 slides and jump to the relevant sections of the video for more in-depth explanations.
