Among all activities I’ve been doing at Bootlin during the past few months, one has been to add support for the Maxim MAX7360Key-Switch Controller and LED Driver/GPIOs chip to the Linux kernel. Together with my colleague Kamel Bouhara, we developed Linux kernel device drivers to support it and upstreamed them to the mainline kernel. The full set of drivers have been merged in the upstream Linux kernel, and will be available in the upcoming Linux 6.18 release.
In this blog post, we will share some details on how this hardware works, and how it is now supported by the Linux kernel.
More specifically, this project is a BR2_EXTERNAL repository for Buildroot, with a number of defconfigs that allow to quickly build embedded Linux systems for the STM32MPU Discovery Kit platforms and Evaluation board. It’s a great way to get started with Buildroot on those platforms.
This blog post is the third installment in our eBPF blog post series, following our posts about eBPF selftests and eBPF trampolines.
In the previous blog post, we discussed how eBPF trampolines are dynamically generated to allow hooking tracing programs to functions’ entry and/or exit. Each trampoline is tailored specifically for the target function on which we want to hook programs: it is then able to read the function context (e.g. function arguments and return value) and to pass those to the hooked programs. However there is one detail that we did not address: how does the trampoline generator know exactly about the function layout ? To be able to generate trampolines that can read and store the function arguments, the trampoline generator needs many details about each argument: the location (a register ? If so, which one ? Or maybe it is on the stack ? And if so, at which offset ?) and its size. Parsing the function machine code is not enough to learn about those, and even if it was, compiler optimizations would obfuscate this kind of info even more. What if besides the actual executable code, the kernel image could be bearing some data about its internal functions ? In this post, we will dive into the DWARF debug information format, and the BPF Type Format (BTF) derived from it to support such a purpose.
Linux 6.17 was released a bit over a week ago, and as usual LWN.net gave the best summary of the new features and important changes in this release: part 1, part 2.
As usual, Bootlin contributed to this kernel, with a total of 98 patches authored by Bootlin engineers, but also another 94 patches that were reviewed/merged by Bootlin engineers, mostly by Alexandre Belloni (RTC and I3C maintainer, reviewed/merged 58 patches), Miquèl Raynal (MTD co-maintainer, reviewed/merged 20 patches) and Grégory Clement (Marvell EBU platform maintainer, reviewed/merged 8 patches).
The X.Org Developer’s Conference (XDC) is the key annual event for developers shaping the future of Open Graphics technologies, including the Linux kernel, Mesa, DRM, Wayland, and X11. It is taking place on Sep 29, Sep 30 and Oct 1 in Vienna, Austria.
Bootlin engineer and Linux graphics specialist Louis Chauvet will be attending and giving a talk on Display Testing without Hardware: Discovering the Power of VKMS!. In this session, he will introduce VKMS, demonstrate its testing capabilities with real examples, and share details on the new features that Bootlin is actively driving upstream.
After participating in the Display Next Hackfest earlier this year, this second graphics-focused event confirms Bootlin’s involvement in the Linux graphics ecosystem. It reflects our commitment not only to staying at the cutting edge of graphics technologies, but also to contributing improvements that benefit the entire community.
If your projects involve Linux graphics and you are looking for expertise, feel free to get in touch with us to see how Bootlin can help.
Bootlin had a very strong presence at the recent Open Source Summit Europe, with 26 members of our team attending the event, 8 talks given by our engineers, and a booth at the technical showcase.
As the Linux Foundation just posted the videos of all talks from the event, now is a good time to publish the slides of our talks, alongside with the videos.
We are excited to announce the release of a new version of our freely available, pre-compiled cross-compilation toolchains, hosted at toolchains.bootlin.com.
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 2025.08 release, the versions are:
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.
Congatec’s x86 System-on-Modules (SoM) include a Board Controller component connected to the processor via an eSPI bus, and providing various features such as I²C buses, GPIOs, a watchdog timer, and various sensors for monitoring voltage, fan speed, and more.
Conga-SA7 datasheet extract
For their x86 System-on-Modules (SoMs), Congatec provides a Yocto meta-layer: meta-congatec-x86. This meta-layer includes, among other components, a driver, a library, and tools for interfacing with the Board Controller.
The primary issue with the provided driver is its deviation from standard Linux APIs. It exposes a custom character device and relies on custom ioctl() for communication with userspace. This non-standard approach leads to compatibility and portability challenges. For example, an application using the standard Linux GPIO API would need to be adapted to access the GPIOs from Congatec’s Board Controller. Similarly, software designed specifically for the Board Controller’s GPIOs would require changes to work with GPIOs on other platforms.
Additionally, because the driver is out-of-tree, it raises concerns about long-term support and maintainability. Questions naturally arise—will the driver be regularly updated to remain compatible with future Linux kernel versions, given the instability of internal APIs? Will bugs and security vulnerabilities be addressed in a timely manner?
One of our customers, planning to use the Conga-SA7 board in a commercial product, recognized these challenges early on. As a result, they asked us to integrate support for the Congatec Board Controller directly into the mainline Linux kernel. Upstreaming the driver into the kernel would eliminate these issues by ensuring better portability, long-term maintenance, and community support.
This blog post is the second installment in our eBPF blog post series, following our blog post about eBPF selftests.
As eBPF is more and more used in the industry, eBPF kernel developers give considerable attention to eBPF performance: some standard use cases like system monitoring involve hundreds of eBPF programs attached to events triggered at high frequencies. It is then paramount to keep eBPF programs execution overhead as low as possible. This blog post aims to shed some light on an internal eBPF mechanism perfectly showcasing those efforts: the eBPF trampoline.
This year, the Linux Display Next Hackfest was hosted by AMD in Toronto. The event brought together a diverse group of contributors from a wide range of projects and companies, all united by a shared interest in advancing Linux Graphics. Participants included kernel developers, compositor maintainers, hardware vendors, and others deeply involved in the graphics stack. For the second year in a row, I had the opportunity to attend in person—an important step for Bootlin, as staying closely engaged with the latest developments in the Linux Graphics Stack is key to delivering upstream-friendly, cutting-edge support for our customers.
As usual, a wide range of topics were discussed: commit failure feedback, backlight API, adaptive backlight management, testing, pageflip, scheduling, variable refresh rate (VRR), atomic commits, and others. What made this edition especially noteworthy was the presence of two color experts: a full day was dedicated to exploring HDR—what it is, how it works, and how we can support it properly in Linux.
You can read the notes for this event on Harry’s blog, or from Xaver Hugl, more will probably be posted later by other participants.
Among all activities I’ve been doing at Bootlin during the past few months, one has been to add support for the Maxim MAX7360 Key-Switch Controller and LED Driver/GPIOs chip to the Linux kernel. Together with my colleague Kamel Bouhara, we developed Linux kernel device drivers to support it and upstreamed them to the mainline kernel. The full set of drivers have been merged in the upstream Linux kernel, and will be available in the upcoming Linux 6.18 release.
The 
Linux 6.17 
The 
Bootlin had a very strong presence at the recent 
