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.
Capitole du Libre is the leading annual open-source and free software conference in Toulouse, France, and has been a key event in the community for over a decade. With offices based in Toulouse, Bootlin has been a long-time participant and active contributor to this event, and 2025 will be no exception.
Bootlin is part of the 4 Platine sponsors of the event, the highest sponsorship level
Bootlin will have a booth in the main hall of the conference, which will allow visitors to meet the Bootlin team, discuss Bootlin activities, career and internship opportunities, and more
Bootlin engineers will be giving a number of talks, related to Embedded Linux or not:
Thomas Petazzoni will be giving a talk titled What’s new in the Linux kernel: a year of changes in review
Alexis Lothoré and Maxime Chevallier will be delivering a hands-on workshop on Mastering eBPF and XDP: creating a high-performance ad blocker
The same Alexis Lothoré will be talking about a more personal project: An Open-Source Blind Test from Start to Finish: When Free Software Makes Our Parties Buzz
Looking forward to meet you at Capitole du Libre in November!
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).
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.
Linux 6.16 was released last Sunday, and as usual LWN provides the best coverage of what’s new: part 1 and part 2, as well as the KernelNewbies.org page for this release.
This time around, the engineers at Bootlin contributed 89 patches to the 6.16 release, but also as maintainers, they reviewed/merged 117 patches from other contributors!
Linux 6.15 has been released last Sunday, and we as usual encourage our readers to look at the LWN summaries of the merge window (part 1, part 2) for a good summary. CNX-Software also has a summary more oriented towards hardware support for ARM and RISC-V platforms.
On our side, we have been quite active in this release cycle, with no less than 145 commits from Bootlin engineers merged. Also, our engineers who maintain various subsystems in the Linux kernel reviewed and merged a total of 104 patches from other contributors.
We are proud to announce the launch of a brand new addition to our lineup of training courses: Embedded Linux Networking!
This training course is designed to provide embedded Linux engineers with a deep and practical understanding of networking concepts and their implementation in both the Linux kernel and user-space — with a strong focus on real-world embedded applications. Continue reading “Announcing our new Embedded Linux Networking training course”
As kernel developers, we often find ourselves writing device drivers—pieces of code that are typically registered using module_init() in the Linux kernel. But have you ever paused to wonder: just how late in the boot process does this happen? What exactly takes place between the moment we see the famous "Starting kernel..." message and the point where drivers are finally registered and devices probed?
If you’re curious about the intricate steps that occur before the system even reaches a working init process, you’re in the right place. Join us as we explore the fascinating journey of the Linux kernel boot sequence—step by step.
Throughout this article, you’ll find clickable links to our Elixir source code browser. We encourage you to dive in and follow along!
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.
Linux 6.17 
