Bootlin – Embedded Linux and kernel engineering

sbom-cve-check 1.4.0 released

sbom-cve-check is a lightweight, standalone tool that analyzes a Software Bill of Materials (SBOM) against public vulnerability databases and reports which software components are affected by known vulnerabilities. It supports SBOMs in both SPDX v2.2 and SPDX v3.0 formats. It checks them against the NVD and CVE List vulnerability databases. Results can be exported in several formats, including SPDX v3.0 and the Yocto Project cve-check manifest format. It is developed and maintained by Bootlin engineer Benjamin Robin.

We are happy to announce the release of sbom-cve-check 1.4.0. This release adds an OpenVEX exporter, substantially improves the analysis of Linux kernel CVE version ranges, and makes version parsing and annotation handling more robust. As usual, the new version is available from PyPI and the release page, and the complete list of changes is in the changelog.

Continue reading “sbom-cve-check 1.4.0 released”

A safety net for eBPF: adding KASAN support to JITed programs

The eBPF technology implemented in the Linux kernel keeps on gaining traction in various areas: infrastructure, observability, security, debugging, and many more. Its wider adoption reinforces one core concept that drives its development: it must be safe for the kernel to load an eBPF program, and so a program that cannot be proven to be safe must be rejected. This fundamental concept led to the development of some complex mechanisms such as the BPF verifier; but this guarantee is not foolproof: the verifier is written in C and can have the same kinds of bugs as the rest of the kernel. Addressing this kind of risk is a key strategy for Alpha-Omega, which is funding initiatives to improve the security and safety of widely used software projects and technologies. Alpha-Omega allocated a grant to the eBPF Foundation, which teamed up with Bootlin, to improve the security and safety of the eBPF technology by implementing KASAN support in eBPF programs, with the goal of enabling better detection of memory-safety issues for eBPF subsystem developers.

Continue reading “A safety net for eBPF: adding KASAN support to JITed programs”

Yocto Blacksail released, Bootlin contributions inside

Yocto Blacksail 6.1 is now released. This is the new stable release of the Yocto Project and will be maintained until April 2027. Bootlin is a very active contributor to the Yocto Project, most notably with Antonin Godard being the official Yocto Project documentation maintainer, and Mathieu Dubois-Briand being a core member of the Yocto SWAT team, but also with other Bootlin engineers who use and deploy Yocto to create optimized and long-term maintainable Linux systems for the embedded devices of our customers. This 6.1 release was no exception, and we were again very active in this release cycle, with over 200 commits authored by Bootlin engineers.

Continue reading “Yocto Blacksail released, Bootlin contributions inside”

Rockchip SoCs: a foray into eFuse territory

Every System-on-Chip has a boot ROM taking care of finding the next component in the boot process, load and run it. Each different vendor tends to implement a different strategy for their boot ROM, often with similar capabilities.

We have written about the Rockchip SoCs boot ROM before on this blog, for instance to discuss their recovery boot capability and the related tooling.

This time, we’re going to look into a particular piece of memory on the SoC, that is very important to the security of the SoC: the secure eFuse.

Continue reading “Rockchip SoCs: a foray into eFuse territory”

Linux 7.3 released, Bootlin contributions inside

Tux Linus Torvalds has released the 7.3 kernel last Sunday afternoon. LWN once again covered extensively the content of this new version through two merge window posts (see part 1 and part 2). This release continues the record-breaking spree started a few releases ago, with 18,765 non-merge commits from 3,021 developers, with plenty of first-time kernel contributors. You can find more details and facts about this release in the 7.3 coverage from LWN.

Continue reading “Linux 7.3 released, Bootlin contributions inside”

Device tree addons: describing non-discoverable addon boards and connectors

Lots of embedded devices exist that have a connector for addon boards: BeagleBone Black Capes and Raspberry Pi Hats are just some common de facto standards, each with a whole ecosystem of base boards and addon boards that can be mixed and matched in countless ways. Most of them are based on embedded System-on-Chips, and thus use device tree to describe their hardware. Yet there is no good way to describe the connectors and addons in an efficient, modular and effective way.

At Bootlin we have been working for a few years to implement a proper way of describing such addon boards and their connectors using device tree. We have found a huge interest in the embedded systems community, but the road to get there is steep.

Our initial effort based on device tree overlays was rejected due to fundamental shortcomings in the device tree overlay design at its root. After discussing with the community we are now proposing a totally new concept: device tree addons. It’s a huge work, a lot has been done but there is still a lot to be done.

This post introduces the rationale and use cases, shows a practical example, describes how to test our current proposal and, last but not least, suggests how to contribute to the mailing list discussion to help this work land upstream for everyone’s benefit.

Continue reading “Device tree addons: describing non-discoverable addon boards and connectors”

Welcome to Thomas Païta and Paul Cercueil

We recently welcomed two engineers to our team: Thomas Païta, based at our Lyon office, and Paul Cercueil, working from Madrid, Spain.

Thomas Païta

Thomas Païta Thomas joined Bootlin at the end of June 2026. After graduating from the Université de Technologie de Compiègne, he worked on embedded Linux and FreeRTOS at Sagemcom, followed by Rust and C++ development in the space industry. At Bootlin, his work will focus not only on Embedded Linux, but also on Zephyr.

Thomas is currently the 5th Thomas at Bootlin, joining Thomas Petazzoni, Thomas Perrot, Thomas Richard, and Thomas Bonnefille.

See his profile page for more details.

Paul Cercueil

Paul Cercueil Paul joined Bootlin in September 2026. After graduating in 2014 from the Université de Technologie de Belfort-Montbéliard, Paul worked at Analog Devices, where he designed and developed the ecosystem around Linux’ IIO subsystem and authored the companion libiio project. In addition to his work on IIO, Paul has extensive Linux kernel experience, with over 750 patches, mainly focused on supporting MIPS-based Ingenic SoCs, for which he is the platform maintainer. Paul also has a solid background in Buildroot, having been the main developer and maintainer of the Buildroot-based OpenDingux distribution, as well as contributing more than 60 patches to upstream Buildroot. Paul also enjoys tinkering with other retro-gaming console projects, including the KallistiOS project, an operating system for the SEGA Dreamcast, and a MIPS-to-everything JIT compiler for the PlayStation 1.

Paul is French and also speaks English and Spanish fluently. See his profile page for more details.

audio-iio-aux: when IIO meets audio

Some time ago, one of our customers came to us with a hardware design featuring the Renesas X9250 digital potentiometer in an audio path, as shown in the following diagram. Naturally, our goal was to find the proper way to support this hardware design in the upstream Linux kernel.

Audio path with potentiometer

Since the X9250 is part of an audio path, the first thing that came to mind was the ALSA subsystem of the Linux kernel. However, the Renesas X9250 is a generic digital potentiometer, and audio is only one of its many possible use cases.

The Linux kernel also has a separate subsystem called IIO (Industrial I/O), which provides support for a wide range of devices, including accelerometers, various types of sensors, ADCs, DACs, and potentiometers. Potentiometers are already supported by IIO, as can be seen in the drivers/iio/potentiometer directory.

IIO is not specific to audio, so implementing the Renesas X9250 driver as an IIO driver made more sense than implementing an ALSA-specific driver. This way, the same driver can be reused for non-audio use cases as well.

However, we still needed a way for the potentiometer to be handled as a regular component of an audio path through the ALSA subsystem.

Continue reading “audio-iio-aux: when IIO meets audio”

Bootlin toolchains 2026.08 released

We are happy to announce the release of a new version of our freely available, pre-compiled cross-compilation toolchains, hosted at toolchains.bootlin.com.

This update covers a range of 43 CPU architecture variants, including: aarch64, aarch64be, arcle-750d, arcle-hs38, armv5-eabi, armv6-eabihf, armv7-eabihf, armebv7-eabihf, armv7m, m68k-68xxx, m68k-coldfire, microblazebe, microblazeel, mips32, mips32el, mips32r5el, mips32r6el, mips64-n32, mips64el-n32, mips64r6el-n32, openrisc, powerpc-440fp, powerpc-e300c3, powerpc-e500mc, powerpc64-e5500, powerpc64-e6500, powerpc64-power8, powerpc64le-power8, riscv32-ilp32d, riscv64-lp64d, s390x-z13, sh-sh4, sh-sh4aeb, sparc64, sparcv8, x86-64, x86-64-v2, x86-64-v3, x86-64-v4, x86-64-core-i7, x86-core2, x86-i686, xtensa-lx60.

As with previous releases, we provide two editions of each toolchain: a stable version based on the N-1 releases of GCC, binutils, GDB, and slightly older kernel headers, and a bleeding edge version featuring the latest available components. For the 2026.08 release, the versions are:

The bleeding-edge toolchains are based on gcc 16.2, binutils 2.46.1, gdb 17.1, kernel headers 6.12, glibc 2.44, musl 1.2.6 or uclibc-ng 1.0.59.
The stable toolchains are based on gcc 15.3, binutils 2.45.1, gdb 16.3, kernel headers 5.10, glibc 2.44, musl 1.2.6 or uclibc-ng 1.0.59.

All toolchains are built for x86-64 Linux hosts and are compatible even with relatively old Linux distributions. We welcome bug reports and feedback through our project issue tracker.