Linux 4.20 released, Bootlin contributions

Penguin from Mylène Josserand
Drawing from Mylène Josserand, based on a picture from Samuel Blanc (https://commons.wikimedia.org/wiki/File:Manchot_royal_-_King_Penguin.jpg)
The Linux 4.20 kernel has been released just before Christmas, on December 23. As usual, LWN had a very nice coverage of the most significant features and improvements provided by this new release as part of the merge window articles: part 1 and part 2.

Bootlin once again contributed to this Linux 4.20 release, with a total of 216 non-merge commits, which puts us the 13th contributing company by number of commits and the 8th contributing company by number of lines changed, according to LWN statistics for the 4.20 release.

Significant Bootlin contributions

For Linux 4.20, the most significant contributions from Bootlin have been:

  • On the support for Marvell platforms
    • Antoine Ténart reworked how the “software thread” mechanism is handled in the mvpp2 network driver, used on Marvell Armada 375 and 7K/8K.
    • Maxime Chevallier enabled XPS support in the same mvpp2 driver
    • Maxime Chevallier added logic to support 2.5G speed in the mvneta driver, but this logic is not enabled yet, as we don’t have the necessary COMPHY driver for Armada 38x to really allow using 2.5G speed.
    • Miquèl Raynal added suspend/resume support for the Armada 37xx clock driver. This is part of a larger work to enable suspend/resume on the Armada 37xx platform.
    • Miquèl Raynal improved the Marvell ICU driver to support SEI interrupts. The ICU is the Interrupt Collector Unit, found on Marvell Armada 7K/8K. It turns wired interrupts from a part of the chip called the “Communication Processor” (CP) into message interrupts so that they can be notified to the other part of the chip called the “Application Processor” (AP), which contains the CPU core and GIC.
    • Thomas Petazzoni introduced some common code in the PCI subsystem to emulate a PCI root port bridge, and converted the pci-mvebu and pci-aardvark drivers to use it. pci-mvebu already had such an emulation logic, but since it became also needed for pci-aardvark, we turn it into a piece of common code so that it can be shared by both drivers (and perhaps others in the future). pci-mvebu is used on Marvell Armada XP, 370, 375, 38x, while pci-aardvark is used on Marvell Armada 37xx.
  • On the support for Allwinner platforms
    • Paul Kocialkowski contributed the Cedrus VPU driver, with for now just MPEG2 decoding support. This work was done thanks to the successful crowd-funding campaign we did in February/March 2018.
    • Paul Kocialkowski contributed a few fixes to the sun4i DRM display driver.
  • On the support for Microchip/Microsemi MIPS platforms
    • Alexandre Belloni added support for the Microsemi Jaguar2 in the Designware SPI controller driver
    • Alexandre Belloni added support for the Microsemi Ocelot in the Designware I2C controller driver
    • Quentin Schulz contributed a new driver in the PHY subsystem to configure the SERDES muxing on Microsemi Ocelot platforms
    • Quentin Schulz contributed a new Device Tree description for the Microsemi Ocelot PCB120 platform
  • On the support Microchip/Atmel ARM platforms
    • Alexandre Belloni got the first step of the clock drivers rework merged. The purpose of this rework is to move from a Device Tree representation with one Device Tree node per clock to a much simpler representation with only one Device Tree node for the whole clock controller. The SAMA5D2, SAMA5D4, AT91SAM9260, AT91SAM9x5 at AT91SAM9RL clock drivers have already been converted. Other platforms and DT changes will arrive in future releases.
  • In the support for RaspberryPi platforms
    • Boris Brezillon contributed a few minor fixes for the vc4 DRM driver.
  • In the RTC subsystem
    • As the subsystem maintainer, Alexandre Belloni as usual did a number of cleanups and improvements in numerous drivers, especially to use more modern APIs where possible.
  • In the network subsystem
    • Quentin Schulz contributed extensive support for the Microsemi VSC8574 and VSC8584 Ethernet PHYs.
  • In the MTD subsystem
    • Subsystem maintainer Boris Brezillon did a lot of changes to pass a nand_chip object to numerous NAND subsystem hooks, and fixed all the drivers accordingly.
    • Boris Brezillon also deprecated a significant number of NAND subsystem hooks, by introducing a nand_legacy structure with legacy hooks. This should encourage developers to move their drivers to the more modern MTD/NAND APIs.

Bootlin maintainers activity

A number of Bootlin engineers are maintainers in the Linux kernel, so their work is not visible as patch authors, but rather as developers reviewing and merging patches contributed by others. As part of this maintainer work:

  • Maxime Ripard reviewed and merged 47 patches from other developers, as the Allwinner platform co-maintainer
  • Boris Brezillon reviewed and merged 36 patches from other developers, as the MTD subsystem co-maintainer
  • Alexandre Belloni reviewed and merged 64 patches from other developers, as the RTC subsystem maintainer and the Microchip/Atmel platform co-maintainer
  • Grégory Clement reviewed and merged 25 patches from other developers, as the Marvell platform co-maintainer
  • Miquèl Raynal reviewed and merged 71 patches from other developers, as the NAND subsystem co-maintainer

Detailed list of Bootlin contributions

MIPI I3C support is now in upstream Linux

MIPI I3C specification publishedBack in August 2017, we wrote in a blog post about the first iteration of the Linux kernel subsystem we proposed to support the brand new MIPI I3C bus. Almost a year and half later, there are some really good news:

  • The Linux I3C support now has its own Git repository on kernel.org
  • The Linux I3C community has its mailing list.
  • Besides the first I3C controller driver we wrote for the Cadence I3C Master, Synopsys has contributed a second driver for their I3C master IP: i3c: master: Add driver for Synopsys DesignWare IP. This definitely helped show that there is interest in I3C beyond our contributions, and also helped validate that the subsystem was working fine for a different I3C controller.
  • The Linux I3C tree has been part of linux-next since November 6, 2018: linux-next: Tree for Nov 6.
  • The Linux I3C subsystem has received a Reviewed-by: Arnd Bergmann and later on a Acked-by: Greg Kroah-Hartman, which were two key approvals to move forward with the merging of I3C support.
  • I3C subsystem maintainer Boris Brezillon has therefore sent a pull request to get this subsystem merged in the upcoming 4.21 (or 5.0 ?) Linux kernel: [GIT PULL] i3c: Initial pull request, and this pull request has been merged by Linus Torvalds, so the I3C subsystem is now visible in Linus Git tree: drivers/i3c. The merge commit has been done on December 25, so it arrived as a very nice Christmas present!

It has been a long process, but we are proud and happy to have pioneered the support for I3C in the Linux kernel, from the design of the subsystem based on the I3C specifications all the way to its merging in the upstream Linux kernel and the creation of a small (but hopefully growing) community of developers around it.

Buildroot 2018.11 released, Bootlin contributions inside

Buildroot logoThe 2018.11 release of Buildroot was published a few days ago. As is well-known, Bootlin is a strong contributor to this project, and this blog post proposes a summary of the new features provided by 2018.11, and highlights the contributions made by Bootlin.

What’s new in 2018.11 ?

  • From a CPU architecture support point of view, by far the most important addition is support for the RISC-V 64 architecture. For now, only the 64-bit version of the architecture is supported, but the patches for the 32-bit version have been posted already, and will hopefully be merged for the next release. It is worth mentioning that we have already used the RISC-V 64 support in Buildroot to provide a pre-built toolchain for this architecture on our toolchains.bootlin.com site.
  • In the toolchain support area, the most important change is that glibc was upgraded to version 2.28. This caused a number of build issues with various packages, which were detected by the project autobuilders and fixed. musl was bumped to version 1.1.20, and the ARM (formerly Linaro) pre-built toolchains for ARM and AArch64 were updated.
  • The support for hardening flags, i.e flags passed to gcc to improve the “security” of programs, has been changed, and is now done directly as part of the compiler wrapper that Buildroot has. Indeed, when using Buildroot, arm-linux-gcc is not directly the usual gcc compiler, but a small wrapper program that Buildroot uses to make sure we always pass the appropriate flags when calling the cross-compiler. Passing those hardening flags through the wrapper allowed to solve a number of build issues. Options such as BR2_RELRO_PARTIAL, BR2_RELRO_FULL, BR2_SSP_REGULAR, BR2_SSP_STRONG and BR2_SSP_ALL should therefore work better now.
  • In terms of filesystem images, while Buildroot already supports the most popular filesystem types, two additional filesystems are now supported: btrfs and f2fs.
  • A number of new default configuration for various boards have been added: Amarula a64-relic, Bananapi m2 ultra, Embest riotboard, Hardkernel Odroid XU-4, QEMU riscv64-virt.
  • A number of packages have been added: bird, bluez5_utils-headers, btrfs-progs, checksec, davici, duktape, ell, haproxy, libclc, libcorrect, libopencl, libopenresolv, nss-myhostname, riscv-pk, sedutil, spandsp, tini, waffle, xapian, not counting the dozens of new Perl and Python modules that have been added.

Bootlin contributions

By far and large, the most significant contribution from Bootlin to Buildroot is the activity of Thomas Petazzoni as a co-maintainer for the project. Out of the 1366 commits made between the 2018.08 and 2018.11 release, Thomas authored 126 commits, but more importantly reviewed and merged 883 patches from other developers, or in other words 64% of the commits that have been made.

As part of the 127 commits Bootlin contributed, we:

  • Fixed a large number of build issues reported by the autobuilder, or by the CI testing the build of our defconfigs.
  • Introduced a make check-package target to more easily use Buildroot check-package tool to verify the coding style of packages.
  • Updated the musl C library to 1.1.20.
  • Updated the Solidrun MacchiatoBin defconfigs (board powered by a Marvell Armada 8K processor) to use the most recent kernel, U-Boot and ATF versions.
  • Started adding a virtual package for opencl.
  • Fixed a number of missing dependencies on host-pkgconf (i.e pkg-config) which were detected by our work on per-package directories, that we will discuss in a future blog post.

Here is the detailed list of our contributions to this release:

Updated cross-compilation toolchains, RISC-V 64 bit toolchain added

RISC-V 64 toolchainWe have just published an updated version of the cross-compilation toolchains available at toolchains.bootlin.com.

The significant changes are:

  • A RISC-V 64 bit toolchain is now provided, following the addition of support for this architecture to the Buildroot project.
  • The stable toolchains are now using gcc 7.3.0 (instead of 6.4.0), gdb 7.12.1 (instead of 7.11.1), kernel headers 4.1.52 (instead of 4.1.49), glibc 2.27 (instead of 2.26), musl 1.1.19 (instead of 1.1.18) and uclibc 1.0.30 (instead of 1.0.28). We are still using a 7.x gdb version because the 8.x versions need C++11 support, which requires a recent enough host compiler, which in turn requires using a more modern distribution. Thus, those toolchains would be unusable with older distributions as they would require a recent glibc version on the host. Currently, our stable toolchains are still built within an old Debian Squeeze system, for maximum compatibility with old distributions.
  • The bleeding-edge toolchains are still using gcc 8.2.0, but gdb is now 8.1.1 (instead of 8.1), kernel headers 4.14.80 (instead of 4.14.57), glibc 2.28 (instead of 2.27), musl 1.1.20 (instead of 1.1.19).

We will continue to update those toolchains with more recent versions of gcc, binutils, gdb and the different C libraries, and add support for more architectures. Do not hesitate to ask for additional features or report any issue encountered when using those toolchains in our bug tracker.

Bootlin at Capitole du Libre in Toulouse, France

Capitole du LibreNext week-end, a local free and open-source software conference called Capitole du Libre will take place in Toulouse, France, where Bootlin has one of its offices. Bootlin will participate to this event in several ways:

We encourage free software developers and users from the south west of France to join this event, which has been organized for several years, and provides a very nice selection of talks and tutorials. And of course, this conference is entirely free, and no registration is required.

Back from ELCE 2018: our selection of talks

The Embedded Linux Conference Europe edition 2018 took place a few weeks ago in Edinburgh, Scotland, and no less than 9 engineers from Bootlin attended the conference. While our previous blog post shared the videos and slides of our talks, tutorials and demos, in this blog post we would like to highlight a selection of talks that Bootlin engineers found interesting. We asked each of the 9 engineers who attended the event to pick one talk they liked, and make a small write-up about it. Of course, many other talks were interesting and what makes a talk interesting is very subjective!

Getting Your Patches in Mainline Linux: What Not To Do (and a Few Things You Could Try Instead), by Marc Zyngier

Talk selected by Maxime Ripard

Marc gave a talk on a subject that is often debated, and still confusing to newcomers: how to contribute. He first started by presenting the various actors involved in a contribution: a contributor, a maintainer and a reviewer. He also took the time to explain the various objectives that everyone has which is something that is often overlooked by the other parties and the conferences on this subject. He then went on to explain and document the good practices that can be used in order to contribute to most subsystems. This was overall a great overview, and we definitely recommend it to people willing to start contributing.



Real Time is Coming to Linux; What Does that Mean to You? , by Steven Rostedt

Talk selected by Michael Opdenacker

In this talk about PREEMPT_RT, the speaker, who’s a long time contributor to this feature, was approaching the subject on a new angle, taking for granted that PREEMPT_RT is in mainline Linux. That’s not quite right yet, but this is possible before the next Embedded Linux Conference, in August next year. One proof that this is on the verge of being true is that its authors no longer call it a patch set, but just PREEMPT_RT. Rostedt also added that Linux can now be called a Deterministic Operating System (aka DOS!).

So, Rostedt first explains what PREEMPT_RT is about and how it addresses the challenges of users who are determined to be deterministic (that’s my pun here, not Steven’s).

Doing this, Steven recalled the “Priority inheritance” issue that is best known through the fact that it happened on Mars on the Pathfinder robot. A high priority and critical system process got starved by a lower priority one because an even lower priority process was holding the lock the high priority process was waiting for, causing some system services to be unavailable. This caused a watchdog to kick in and reboot the system endlessly. Such an issue is addressed by “Priority inheritance”, allowing a lock-holding process to inherit the priority of the highest priority process waiting for the lock. Priority inheritance is now supported in kernel locks thanks to PREEMPT_RT.

By the way, I learned that there are now 5 preemption models in the kernel, instead of four originally with PREEMPT_RT. There is now a “Basic RT” option in which you have all the PREEMPT_RT features except the sleeping spinlocks, which is useful for debugging such features.

So now that PREEMPT_RT is almost in mainline, what should kernel developers do? The main thing is to stop adding non determinism to Linux. For example, Rostedt strongly advised against rw_locks and semaphores on multiple CPUs. That’s horrible for cache lines, as they do not scale. You should use RCU mechanisms instead.

As a kernel developer, you shouldn’t use preempt_disable() either, unless you know it is done for a very short amount of time. Similarly, if you find code that uses local_irq_save(), that’s most likely a bug. Instead, people should use spin_lock_irqsave() and spin_lock_irq(), which disable interrupts only when PREEMPT_RT is not enabled.

Rostedt ended his talk by answering a question about what will remain of the PREEMPT_RT patch set. Even when the most important parts of PREEMPT_RT are in mainline, some changesets are likely to remain for some time, just to address cases that don’t have a solution yet. 99.9% of the users will be able to do without it. That’s what a mainline solution means: no patches to apply.



Uh-oh, It’s I/O Ordering! by Will Deacon

Talk selected by Miquèl Raynal

Will gave his second talk at an ELCE about I/O ordering, 6 years after the first talk on that subject. For this purpose, he started with an introduction to the memory consistency models (in 5 minutes!) to show the audience how a very simple program, ran on two CPUs, could produce very strange results due to store buffering. Because his assumption was a bit hard to believe for such a simple program, he proved us he was right by actually running it on his laptop. While such kind of tricky behavior applies to memory, the same odd situation may happen with I/Os! After a theoretical explanation, he gave a few examples (mostly taken from the mainline Linux kernel) of good and bad code sections and explained why. If you are a device driver writer, this talk should be of interest! The examples are real use cases that you might encounter someday (if not already) and knowing how to workaround the most generic caveats with the right memory barrier or even doing a dummy read to enforce ordering is something you will want to master to avoid strange random bugs.




[PDF]

The Power Supply Subsystem, by Sebastian Reichel

Talk selected by Quentin Schulz

Sebastian started the talk by presenting what this subsystem is used for and its history, which he knows in great length since he took over the maintainership of the power supply subsystem in the Linux kernel in 2014. While it’s not the subsystem with the hardest concepts to grasp, Sebastian explained that he aimed, with his talk, at providing an accessible approach to the subsystem for people who’re trying to get started in the Linux kernel or in this specific subsystem. Having contributed to this subsystem a few patches and drivers in my early days as a kernel developer, I can say that I wish I had seen his talk before to quicken my understanding of the power supply subsystem. Scrolling down the slides, he presented a very simple example of a dummy driver, Device Tree nodes and how to configure what’s exposed to sysfs. Sebastian also gave a few words on Open-Circuit Voltage in batteries which is interesting for getting more precise values of the battery capacity depending on its age and temperature, and the ongoing work on supporting this in the kernel. He concluded with the future plans for the subsystem, which are mainly related to batteries, their fuel gauges and chargers.




[PDF]

The End of Time, 19 Years to Go, by Arnd Bergmann

Talk selected by Alexandre Belloni

Arnd gave an update on the status of the effort to get a 32-bit kernel handle the 32-bit time_t overflow which will happen in January 2038. He first started to explain why this is necessary. This boils down to the huge number of 32-bit products that are still being introduced on the market with some of them having a very long service life. Arnd said this work has been on-going since 2014, when John Stultz switched the internal timekeeping code to a 64-bit second counter. The device drivers then needed fixing. This was done by addressing them individually by changing:

  • time* to ktime_t
  • time* to jiffies
  • time_t to time64_t
  • timespec/timeval to timespec64
  • CLOCK_REALTIME to CLOCK_MONOTONIC

The driver userspace interface also needed to be changed. Some IOCTLs were easy to change because they are already using different numbers depending on the size of the argument they take. The other IOCTLs had to be redefined. It gets worse Arnd said, explaining how the read, write and mmap callbacks are getting fixed.

While the VFS layer got fixed earlier this year, some filesystems are still work in progress and other ones are not fixable because they use a 32-bit time on disk. The only way is to move away from those.

Arnd then went over the biggest remaining part of the work, the system calls. The 32-bit compat syscalls mechanism is reused and a __kernel_timespec type has been introduced to handle time at the boundary. He then listed the affected system calls and their current status.

He ended by talking about userspace and the plan to handle the issue in glibc. Finally, he mentioned what distributions will have to do.




[PDF]

On this Rock I will Build my System – Why Open-Source Firmware Matters, by Lucas Stach

Talk selected by Grégory Clement

Lucas started to present what we used to have in embedded world: a minimalist firmware which acts only as a bootloader and with no interaction with the kernel.

Then he showed why with the virtualization there were some needs to have CPU power management in a single place. This was defined by the PSCI: the purpose of it was to have the bare-metal and the virtualized kernel seeing the same interface. What should have been a simple and delimited interface then became more and more complex due to the hardware constraints. Indeed, in many SoCs multiples devices or CPUs can share the same register. Besides, an interface such as the I2C used by a PMIC can also be shared. This lead to moving the entire register inside the firmware or to have lock mechanisms between the kernel and the firmware. In conclusion, the kernel implementation became easier but at the expense of a complex firmware.

The sad news, is that most of the firmwares are not copyleft which can lead to closed source binaries, making the debugging very difficult for the kernel. Even if the firmware remains open source, having the hardware management split in two parts, makes the debugging more complex. However, there is nothing we can do about it, because there are valid reasons to have a firmware. The only thing we should be vigilant about is the openness of the firmware source.




[PDF]

Handling Security Flaws in an Open Source Project, by Jeremy Allison

Talk selected by Antoine Ténart

Samba is a well known re-implementation of the SMB protocol and as such is used in several consumer devices — such as NAS. As open source software are more and more used in new products, correctly handling security flaws and their fixes is becoming an important topic.

Jeremy Allison, one of the core developers of Samba, gave a talk about how Samba is dealing with security issues and what questions other projects should ask themselves to handle those the right way. He talked about the process to put in place to take security seriously, how to respond to vulnerability reporters and to security issues, and how to notify downstream vendors so that products in the wild are patched before the CVE is made public.

Jeremy Allison also presented three examples of security flaws in Samba. He described how they were handled at the time, the difficulties the Samba developers encountered, and gave a postmortem.

Security is important and we found this talk to be a must-see for open source maintainers and developers, as it gave a good insight on how to properly handle security vulnerabilities in a project. One of the key points was how to coordinate the security responses to avoid having the users being at risk.



[PDF]

Improve Linux User-Space Core Libraries with Restartable Sequences, by Mathieu Desnoyers

Talk selected by Maxime Chevallier

Following-up on the good LWN coverage of the restartable sequences, Mathieu Desnoyers gave an interesting talk on the current userspace support, and some feedback regarding the shortcomings of the current implementation.

Restartable sequences allow to implement lockless per-cpu sections of code, that will be automatically aborted (or restarted) whenever migration, preemption or signal delivery occurs before the final “commit” operation is done.

This is useful to read some performance counters from userspace with a minimal overhead since there’s no lock involved to protect the critical section.

Mathieu explained that these critical sections need to be written in assembly code, but thanks to the librseq and its set of macros, users shouldn’t have to worry about this.

Mathieu then presented some of the shortcomings of rseqs, one of them being that they can’t be debugged in step-by-step (since a signal interrupts the sequence, causing it to abort). To solve these shortcomings, Mathieu gave a quick glimpse of a possible new system-call, cpu_opv(), that would allow users to execute a limited sequence of instructions with preemption and migration disabled.

Power Debugging with JTAG, by Patrick Titiano & Alexandre Bailon, Baylibre

Talk selected by Thomas Petazzoni

In this talk, BayLibre engineers Patrick Titiano and Alexandre Bailon introduced libSoCCA (SoC Continuous Analyzer), a Python library that allows to watch over JTAG what a SoC is doing.

This library allows remote access to the registers of a SoC through JTAG, and uses the SoC interconnect debug port rather than the CPU debug port. Non-intrusive observation of what the SoC is doing is thus possible, even when the CPU is idle or in a low-power state.

libSoCCA uses SVD (System View Description) files, which are XML files that describe all the registers of the SoC, their bitfields and possible values. This format is not specific to libSoCCA, since it is already used by Keil, and apparently some SoC vendors provide such SVD files for their SoCs. Unfortunately, not all vendors do this, and creating such SVD files from the SoC datasheet is a very long and boring process. In addition, the speakers pointed out that the SVD file format lacked an include directive, which would be very useful to share register definitions between SoC.

With the information provided by the SVD files and a connection to the target over JTAG that uses OpenOCD, libSoCCA is then used to implement a number of different
tools:

  • PMUGraph, which shows power management statistics of the device. Compared to solution such as perf or powertop, this solution has the advantage of being non-intrusive.
  • memtool, which provides a way of manipulating registers without having to manually fiddle with register offsets and bitfields. It could be summarized as a remote devmem that knows your SoC registers. This kind of feature can be found in proprietary JTAG tools, and was lacking in the open-source world.
  • clocktool (development not started yet), which shows the state of the SoC clocks remotely, a bit like clk_summary in debugfs, but which works even when the SoC is idle or in a low power state, which is precisely a moment where getting clock status may be useful for debugging.

Overall, we found libsocca very interesting as it opens up lots of possibilities. It would be useful to have a better file format than SVD to describe SoC registers though, and it would also be nice to have an on-target variant of memtool.




[PDF]

Back from ELCE 2018: talks, tutorials and demos from Bootlin

The Embedded Linux Conference Europe edition 2018 took place last week in Edinburgh, Scotland, and no less than 9 engineers from Bootlin attended the conference. In this blog post, we would like to share the slides, materials and videos of the talks, tutorials and demos we gave during this conference.

Talk: Supporting Hardware Codecs in a Linux system – Maxime Ripard

This talk was given by Bootlin engineer Maxime Ripard, who has worked since spring 2018 with Paul Kocialkowski on adding support in the upstream Linux kernel for hardware-accelerated video decoding on Allwinner platforms. This project was the topic of the successful crowd-funding campaign we launched in February 2018, and for which we regularly posted updates on our blog.

[PDF] [Sources]


Talk: Networking: From the Ethernet MAC to the Link Partner – Maxime Chevallier & Antoine Ténart

This talk was given by Bootlin engineers Maxime Chevallier and Antoine Ténart, who shared their knowledge and experience working on enabling network hardware in Linux, trying to clarify how Ethernet MAC and PHYs interact, how PHYs communicate with their link partner, what are the protocols involved, etc.



[PDF] [Sources]

Talk: SPI Memory support in Linux and U-Boot – Miquèl Raynal

This talk was given by Miquèl Raynal, who has worked with Bootlin engineer Boris Brezillon on adding support for SPI NAND in U-Boot and Linux, as well as improving in general the support for SPI flash memory, see our previous blog post.



[PDF] [Sources]

Tutorial: Introduction to Linux kernel driver programming – Michael Opdenacker

This tutorial was given by Bootlin CEO and founder Michael Opdenacker, as part of the Embedded Apprentice Linux Engineer track.


[PDF] [Sources]

The video will be published later, as it was not recorded by the Linux Foundation, but by the E-ALE track organizers.

Tutorial: Getting started with Buildroot – Thomas Petazzoni

This tutorial was given by Bootlin CTO Thomas Petazzoni, as part of the Embedded Apprentice Linux Engineer track.



[PDF] [Sources]
The video will be published later, as it was not recorded by the Linux Foundation, but by the E-ALE track organizers.

Demo: Hardware Video Codec Support on Allwinner SoCs – Maxime Ripard

In this demonstration, Maxime Ripard was showing the upstream Linux kernel support for the Allwinner VPU, which provides hardware-accelerated video decoding for MPEG2, H264 and H265 within the Kodi media player on Allwinner platforms.



[PDF] [Sources]

Demo: Upstream Linux kernel support for Microsemi switches – Alexandre Belloni

Alexandre Belloni showing upstream Linux kernel support for Microsemi Ethernet switches
Alexandre Belloni showing upstream Linux kernel support for Microsemi Ethernet switches at the Embedded Linux Conference Europe 2018

In this demonstration, Bootlin engineer Alexandre Belloni was showing the upstream Linux kernel support for the VSC5713 and VSC7514 Microsemi Ethernet switches, which we presented in a previous blog post. Thanks to this support in upstream Linux, the different ports of the switch are seen as regular Linux network interfaces, and standard Linux user-space tools can be used to bridge the ports, set up VLAN filtering, and more. This makes such switches a lot easier to use than vendor-specific SDKs.



[Poster] [Sources]

Allwinner VPU support in mainline Linux status update (week 37)

Even though the bulk of the development on the Allwinner VPU support is done, we are still working on completing the upstreaming of the kernel driver, and some progress has been made recently on this topic:

  • On September 10, core Video4Linux developer Hans Verkuil sent a pull request to Video4Linux maintainer Mauro Carvalho Chehab to get the Cedrus driver merged. This means we’re getting closer and closer to have the driver merged. Unfortunately, some last minute issues were found in the patch series, so this pull request wasn’t merged.
  • On September 13, Bootlin engineer Maxime Ripard sent a new iteration of the Cedrus driver, version 10, which addresses those issues.
  • In addition, as the Allwinner platform maintainer, Maxime Ripard has merged the patches adding the Device Tree description of the Allwinner VPU, which reduces the Cedrus patch series to just 5 patches. They are now in the branch sunxi/dt-for-4.20, which should be part of the upcoming 4.20 Linux release.
T-Shirt for Allwinner VPU campaign supporters
T-Shirt for Allwinner VPU campaign supporters

In addition to this progress on the Linux kernel driver upstreaming process, we also moved forward with delivering the perks to the companies and individuals who supported our campaign:

  • A CREDITS file has been added to the libva-v4l2-request base, thanking all our backers who pleged more than 16 EUR.
  • The T-Shirts for the backers who pledged more than 128 EUR have been sent to those in the EU. We are also working on sending the t-shirts to those outside the EU, but it takes a bit more time due to the need for customs declarations. Don’t hesitate to take a picture of you with the T-Shirt, and post it on Twitter with the hashtag #VPULinuxDriverSupporter.

Bootlin at the Linux Plumbers 2018 conference

Last year, a number of Bootlin engineers attended the Linux Plumbers conference. This year again, Bootlin will participate to the event, with engineer Antoine Ténart traveling to Vancouver, Canada on November 13-15 for this conference.

Linux Plumbers 2018

We are particularly interested in attending the new Networking Track added to Linux Plumbers for the first time, but there will certainly be useful discussions as well in the BPF micro-conference, the Real-time micro-conference or the Power Management and Energy-awareness micro-conference.

If you’re attending this conference, don’t hesitate to get in touch with Antoine and meet during the event!

Bootlin at Kernel Recipes 2018: speaking and attending

Kernel RecipesThe Kernel Recipes conference, to be held in Paris on September 26-28, has become over the years a very popular conference on kernel topics, with its atypical single-track format and limitation to 100 attendees. With this conference taking place in Paris, France, Bootlin engineers obviously never missed the chance to attend, and this year again, several of us will participate to the event.

Our engineers Grégory Clement, Mylène Josserand and Boris Brezillon will be attending. In addition, Grégory Clement will be giving a talk titled Overview of SD/eMMC, their high speed modes and Linux support, in which he will share his experience working on MMC support in the Linux kernel.

Do not hesitate to get in touch with us during Kernel Recipes to discuss Linux kernel development, consulting projects, and opportunities at Bootlin!