Bootlin the top #18 contributor to the 3.11 kernel

The 3.11 Linux kernel has now been released by Linus Torvalds, and as usual as thousands of patches coming from a large number of companies and contributors. For this release, Bootlin has contributed a total of 128 patches (yes, exactly 2^7), which makes Bootlin the 18th contributor in the list of companies contributing to the kernel, according to http://www.remword.com/kps_result/3.11_whole.html, before Broadcom and Cisco, and after ARM and Oracle. It is also the first time that six different engineers from Bootlin contribute code to the Linux kernel in a single release!

As usual, most of our contributions were centered around support for the Marvell Armada 370 and XP SOCs, the Allwinner SOCs and the Crystalfontz i.MX28 platforms:

  • Added support for the PCIe controllers of the Armada 370 and Armada XP platforms, and used it for the already supported Kirkwood platform. Supporting PCIe has been a very long process, which got started in December 2012, required long discussions with various kernel maintainers and multiple iterations of the patch series. Armada 370/XP was the first ARM platform to add Device Tree based PCIe support, and therefore this required many discussions to sort out the Device Tree bindings for PCIe controllers. This work was done by Thomas Petazzoni.
  • Enable an additional USB interface on the OpenBlocks AX3 platform, which is available as part of the mini-PCIe connector inside the device. This work was done by Thomas Petazzoni.
  • Cleaned up all the Kirkwood platform Device Tree files to assign the pin muxing configurations to the appropriate devices. This work was done by Thomas Petazzoni.
  • Made various cleanups and improvements in the Armada 370/XP platform code (in arch/arm/mach-mvebu) to make it possible to support different base address for the internal registers depending on the board being used. Many hardcoded physical addresses were removed, as well as the static virtual to physical mapping. This work was done by Thomas Petazzoni.
  • Cleaned up many ARM platforms to remove their unneeded ->init_irq() callback, and also the ->map_io() callback which we changed to default to calling debug_ll_io_init() when not provided. This work was done by Maxime Ripard.
  • Extended the ssd1307fb driver that we contributed a few releases ago to also support the SSD1306 device. The SSD1306 and SSD1307 are OLED screens controlled over I2C that are used on Crystalfontz i.MX28 platforms. We also optimized significantly the communication with the SSD130x devices. This work was done by Maxime Ripard.
  • Added an Ethernet driver for the Allwinner SOCs. The work was initially done by Stefan Roese, and our engineer Maxime Ripard did all the final cleanup, development of an MDIO driver, and integration with all the Device Tree files of the Allwinner platforms.
  • Added support for the Allwinner I2C controller, by re-using and extending the existing i2c-mv64xxx driver used on Marvell platforms, since the hardware block was very similar. The Allwinner Device Tree files were also updated to add the I2C controllers. This work was done by Maxime Ripard.
  • Added basic support for the Allwinner A10s SOC: pin muxing information and Device Tree information. This work was done by Maxime Ripard.
  • Added support for the Olimex A10s-Olinuxino-micro, a new hardware platform manufactured by Olimex that uses the Allwinner A10s SOC. This work was done by Maxime Ripard.
  • Implemented a “Device Bus” driver for the Marvell SOCs, that allows to configure the access to NOR flash and other devices connected to the memory bus. It has been used to enabled NOR support on the Armada XP DB development platform. This work was done by Ezequiel Garcia.
  • Fixed a few bugs in the IIO subsystem, and a build failure on AT91 platform when CONFIG_PHYLIB was not enabled. This work was done by Alexandre Belloni.
  • Fixed the ARM low-level code that handles compatibility with ATAG bootloaders, to properly convert 32 bits memory sizes passed by the bootloader into 64 bits cells of the Device Tree, when LPAE is used. This work was done by Gregory Clement.
  • Michael Opdenacker made a few improvements and fixes to the documentation.

For the upcoming 3.12, we already have 131 patches lined up, and a few more will probably show up after this blog post is written. Over the last release cycles, Bootlin has become a regular contributor to ARM support in the Linux kernel, and we’re looking forward to doing more contributions in the future.

The details of our 3.11 contributions is:

Bootlin at Kernel Recipes, September 2013, Paris

Kernel Recipes conference logoFor the second year, a company called Hupstream, located in Paris, is organizing in France a conference fully dedicated to kernel development: Kernel Recipes (French), on September 24th and 25th.

While we at Bootlin couldn’t participate to last year edition, it looked like a very interesting conference, with both useful talks and an audience grouping a significant number of kernel developers and companies interested in kernel development in France. So this year, we are very happy to participate to this conference:

We are definitely looking forward to meeting some of the French kernel developers we have been in contact with over the last months (see the list of participants). It is also worth mentioning that Bootlin has an open position for a kernel or embedded Linux engineer, and that this conference is a great opportunity to meet us!

Bootlin at Linux Plumbers 2013, September 2013, New Orleans

Linux Plumbers conference logoThe Linux Plumbers conference has been running since quite a few years now, and has established itself as an important event for the Linux community that takes care of the low-level aspects of the Linux system: the kernel of course, but also the related userspace low-level components. It was originally the primary goal of this conference: get the userspace developers of the low-level components and the kernel developers to meet together. Nowadays, Linux Plumbers is organized as both a set of regular talks and a set of half-day mini-conferences.

The 2013 edition will be held from September 18th to September 20th in New Orleans, United States, and will cover a wide range of topics: ACPI, power management, PCI, Android, Graphics, Automotive, Boot and Core OS, File and Storage systems, LLVM, Network virtualization, Scaling, Secure Boot, Virtualization and more.

As part of Bootlin strong engagement in the community, and continuous effort to ensure its engineers are up-to-date with the latest Linux developments, our engineer Maxime Ripard will attend this conference. For those attending the conference, do not hesitate to meet Maxime, who has an interesting Android experience to share thanks to the Android training course he created at Bootlin, as well has a nice ARM kernel development experience as the maintainer of the Linux kernel support for the Allwinner ARM processors.

Contributions to Barebox: initial Marvell SoC support

Barebox is a bootloader that strives to be a modern alternative to U-Boot. It currently supports ARM, Blackfin, MIPS, NIOS2, OpenRISC, PowerPC and x86 as CPU architectures, and while it doesn’t have as much hardware support as U-Boot yet, it does have a number of very significant advantages over U-Boot: a proper device model very similar to the one used in the Linux kernel, which makes the code very clean and nice, and a configuration system that uses kconfig, like the Linux kernel, which is a lot better than the per-board header files used by U-Boot with lots of cryptic macros.

Bootlin had already contributed to Barebox in the past, as our engineer Maxime Ripard added the support for the Crystalfontz i.MX28 boards.

More recently, we contributed basic support for the Marvell Kirkwood, Marvell Armada 370 and Marvell Armada XP ARM processors. This work was released as part of the 2013.07.0 release. For now, the support is fairly minimal, as it only allows to boot a Barebox bootloader that has serial port support. The most important part of the work was to write a kwbimage tool (see kwbimage.c), which allows to generate bootable images for Marvell processors. Our work contained minimal support for the Armada XP-based OpenBlocks AX3 board, the Armada XP-based GP development board, the Armada 370-based Mirabox from Globalscale and the Kirkwood-based Guruplug from Globalscale. Our work was quickly extended by Sebastian Hesselbarth, who added basic support for the Marvell Dove processor, and the Cubox platform from SolidRun, which uses the Dove processor.

Of course, such support is far from being complete, we are hoping in the future to add support for network, NAND and SD, in order to make Barebox really useful and usable on Marvell platforms.

The details of our contributions are:

Bootlin contributions to the 3.10 kernel

The 3.10 Linux kernel has been released a few days ago. According to LWN, with almost 13.500 non-merge commits, the 3.10 has been the busiest ever, and also the fastest. Bootlin engineers again contributed to this release, with 99 patches integrated, making Bootlin the 28th most active company contributing, right between ST-Ericsson (103 patches) and ARM (97 patches). See http://www.remword.com/kps_result/3.10_whole.html for the complete statistics.

This time, Bootlin contributions include:

  • LPAE support for the Marvell Armada XP SoC, done by Grégory Clement.
  • Fix for errata 4742 of the PJ4B CPU core (used in Armada 370/XP), which prevented booting Armada 370 platforms after ARM optimized some TLB operations. Done by Grégory Clement.
  • Support for NOR flash on Marvell Armada 370 and Armada XP SoC, done by Ezequiel Garcia
  • Addition of a mvebu-mbus driver to handle the address decoding mechanism and configurable memory windows of Marvell SoC. The mach-kirkwood, mach-orion5x, mach-dove, mach-mv78xx0 and mach-mvebu Marvell platforms are all converted to use it. Developping this driver was a requirement to enable PCIe in a Device Tree compatible way on these platforms. Done by Thomas Petazzoni.
  • Addition of Device Tree information for the PCIe controllers of the Armada 370 and Armada XP, but unfortunately not the PCIe driver itself (which will arrive in 3.11). Done by Thomas Petazzoni.
  • Support for the thermal sensor on Marvell Armada 370 and Armada XP SoC, done by Ezequiel Garcia
  • A lot of reorganization of the Device Tree compatible strings for the Allwinner ARM SoC support, to prepare for the addition of additional SoCs in the future. Done by Maxime Ripard.
  • Improvements to the Allwinner pinctrl driver, with support for the A10 and A13 SoC. Done by Maxime Ripard.
  • Enabling of the I2C GPIO expander of the Armada 370 based Mirabox platform. Done by Grégory Clement.
  • A few updates to the support for the i.MX28 Crystalfontz boards: touchscreen and one-wire support on CFA10049. Done by Alexandre Belloni.
  • Various cleanups and improvements to the OMAP GMPC driver, done by Ezequiel Garcia.
  • Various cleanups and improvements to the Marvell Armada 370/XP IRQ controller driver, done by Thomas Petazzoni.

In detail, the contributions are:

Workshop on the Altera SoC FPGA platform

On June 25, 2013, Altera and some partner companies where organizing a workshop in Toulouse (where some of the Bootlin offices are located) about the Altera SoC FPGA platform. For $99, I participated to this full-day workshop, with a small training of the hardware and software tools available for this platform, and went away with a the development kit that was used for the practical labs, the Arrow SoCKit evaluation board.

sockit-1

The Altera SoC FPGA platform is a single chip that combines a dual Cortex-A9 processor and a Cyclone V FPGA (other variants are available, such as single core ARM, or bigger FPGAs). Since both are integrated on the same chip, it removes the need for a complex bus between the application processor and a separate FPGA, and it provides a very high bandwidth between the processor and the FPGA to exchange data. As can be seen on the following diagram, the Arrow SocKit evaluation board has a good number of peripherals, some of them connected to the HPS side of the processor (HPS stands for Hard Processor System, which is dual Cortex-A9 and all the hard peripherals), and some others connected to the FPGA side of the processor. Specifically, the workshop was centered around playing with the LEDs and the buttons connected to the FPGA side.

Block diagram of the SoCKit evaluation board
Block diagram of the SoCKit evaluation board

The morning of the workshop was dedicated to the hardware part, using two tools: Qsys (Altera’s System Integration Tool) and Quartus II (FPGA design). The Qsys tool allows to graphically build the hardware architecture of the SoC FPGA: you can bring the Hard Processor System, and then some additional FPGA IPs and connect them together. In the examples, two PIO IPs were added to the FPGA side, one to control LEDs and the other to control buttons. All the pin muxing and the DRAM configuration also takes place in Qsys, which in the end will automatically generate numerous elements:

  • FPGA code to be used by Quartus (for the FPGA side)
  • pre-loader source code (actually modifications to U-Boot to take into account the pin muxing and the DRAM configuration)
  • a Device Tree for the Linux kernel (that takes into account all the peripherals enabled in the system configuration)
  • etc.
Qsys allows to design the overall architecture of the SoC FPGA components, including all the FPGA IPs. On this picture, we see the two PIO IPs used to control LEDs and buttons.
Qsys also to design the overall architecture of the SoC FPGA components, including all the FPGA IPs. On this picture, we see the two PIO IPs used to control LEDs and buttons.

Once this system-level configuration is done with Qsys, Quartus is used to synthesize the FPGA side. Finally, the FPGA bitstream can be loaded into the FPGA, and using a JTAG connection and a System Console tool, one can directly read/write the registers of the FPGA IPs that have been integrated, and easily test them without having any software running. With the SOCKit evaluation board, the JTAG connection takes place through a USB to micro-USB cable, so no special hardware is needed.

The afternoon of the workshop was dedicated to the software part, obviously mostly centered on U-Boot and Linux. The pre-loader source code (actually the U-Boot SPL) is generated by the Qsys tool to take into account all the details of the system configuration, so after doing a build of U-Boot, the labs explained how to push the U-Boot binary to the board using the JTAG connection, under the DS-5 development environment (which is the development environment provided by ARM, based on Eclipse, with a special integration of Altera tools). The lab showed that you can set breakpoints, and do step by step execution of U-Boot, as one would expect. One nice thing is that the “Peripheral Registers” view in DS-5 is automatically updated according to the hardware components in the system: all the registers of the FPGA IPs we had integrated were immediately visible, and one was able to play with the LEDs and buttons directly from DS-5 through the JTAG connection. The remainder of the labs were dedicated to booting a pre-built Linux kernel, using a Device Tree generated by Qsys previously and loaded by U-Boot. Once Linux was booted, the labs were demonstrating how to play with the LEDs using /sys/class/leds/.

Registers of FPGA IPs are automatically visible in DS5
Registers of FPGA IPs are automatically visible in DS5

All in all, it was a great workshop, giving a good overview of the tools they offer and the capabilities of such platforms, I definitely recommend others to look for the other dates of this workshop and attend, it was well worth the price (dates in US, dates in Europe). I also appreciated that the amount of marketing/commercial was really reduced to the minimum. After the lunch break, there was an additional presentation by a person from Linear Technology about the power supply architecture of two boards based on this SoC FPGA processor, and it was very technical and highly informative.

As an embedded Linux developer, I’ve however found the tools to be too much based on graphical interfaces, with millions of windows and buttons to fill in, and a sensation of not really controlling which tool was doing what exactly. For example, it is a bit unclear at first which files are really your “source” files and which other files are generated. Having graphical interfaces also makes me wonder how all the build steps can be automated. It seems like version control and automated builds are not necessarily taken into account when designing those tools, but more investigation is certainly needed to get a good understanding of what those tools are doing.

On the Linux kernel side, it is worth noting that Altera has engaged into an upstreaming process for this architecture, and one can find some mainline support for this platform in arch/arm/mach-socfpga in the kernel tree. It is worth mentioning that Xilinx also has a similar architecture combining a dual Cortex-A9 and FPGA, called Zynq, which has mainline kernel support in arch/arm/mach-zynq.

And below, the front and bottom of the SoC Kit evaluation board:

SoC Kit evaluation board back side

SoC Kit evaluation board front side

GSoC: Buildroot gaining improved ARM multimedia support

Google Summer of Code 2013 logo

The Buildroot project is participating for the first time to the famous Google Summer of Code. This program, operated by Google, allows open-source projects to have students working on specific tasks for the summer, and the students get paid for their work, get mentored by open-source developers, learn about software development, open-source communities and more.

For its first participation to the GSoC, the Buildroot community has chosen one project: improving support for multimedia features of popular ARM SoCs. This consists in packaging in Buildroot all the necessary libraries and software components to support OpenGL, OpenVG, EGL, OpenMAX and similar technologies for the major ARM processors. The selected student for this project is Spenser Gilliland and Bootlin engineer Thomas Petazzoni is mentoring Spenser for this project.

The focus of the project is to add support for the multimedia features of the OMAP3, OMAP4 and AM33xx processors from Texas Instruments, the Broadcom processor found on the RasberryPi, the i.MX6 processor from Freescale, the Exynos 4 from Samsung and the Allwinner A1x processors. Throughout the next three months, support for the multimedia capabilities of those processors in Buildroot should become easier to use.

Spenser has already contributed support for GStreamer 1.x in Buildroot (which required upgrading the entire GLib/Gtk/Webkit stack) and OpenMAX support for the RasberryPi, and he is currently working on OpenGL support for the OMAP3/OMAP4/AM33xx platforms. The initial part of Spenser’s work will be in the next 2013.08 Buildroot release, while the remainder will have to wait the 2013.11 release.

For more details about the project, see its description on the eLinux.org wiki, and you can also keep track of Spenser’s progress.

Buildroot 2013.05 released, Bootlin contributions inside!

Buildroot logoAs planned by the release schedule, the Buildroot 2013.05 version landed at the end of May. Peter Korsgaard, the project’s maintainer, highlighted the most important additions in his release email. With more than 900 commits, it has been the busiest ever development cycle, showing that the Buildroot project is more and more active.

With 175 commits in this release, Bootlin has again participated significantly to the development of Buildroot:

   217  Gustavo Zacarias
   167  Thomas Petazzoni (Bootlin)
   109  Will Wagner
    86  Peter Korsgaard
    44  Simon Dawson
    27  Yann E. MORIN
    25  gilles.talis@gmail.com
[...]
     6  Maxime Ripard (Bootlin)
[...]
     1  Alexandre Belloni (Bootlin)
     1  Ezequiel Garcia (Bootlin)
[...]

Amongst the features and improvements contributed by Bootlin:

  • Support for the next generation Wayland display server has been added. For now, only Wayland over the framebuffer is supported, but additional improvements are expected to come in the future.
  • Integration of packages to build all the Qt5 components: qt5base, qt5declarative, qt5graphicaleffects, qt5imageformats, qt5jsbackends, qt5multimedia, qt5quick1, qt5script, qt5svg, qt5webkit and qt5xmlpatterns.
  • A mechanism of virtual packages to expose the OpenGL, OpenVG and EGL implementations has been put in place, with for now the RasberryPi providing such implementations. Those virtual packages are for example used in the Qt5 packages mentionned above, for those that require OpenGL.
  • A cleanup of Buildroot core dependencies: flex and bison are no longer mandatory to use Buildroot, they are automatically built when needed. This apparently simple move required a number of fixes and updated to a significant number of packages.
  • Many external toolchains were updated, especially the Linaro toolchains.
  • The build process of gdb was converted to the package infrastructure, instead of being a hand-written Makefile. This is part of an effort to progressively convert the toolchain building process to the package infrastructure.
  • A default configuration was added for the Atmel AT91SAM9G45M10-EK evaluation board, which allows Buildroot users to easily build a minimal working system for this platform.
  • A number of build issues were fixed by Maxime Ripard, thanks to the daily automated builds done by the Bootlin Jenkins system that Maxime has set up.
  • A huge number of build issues trigerred by the autobuilders have also been fixed thanks to Bootlin engineers contributions.

In addition to this, Thomas Petazzoni has done some major improvements to the automated build system that the Buildroot project uses, which he detailed in an e-mail sent to the project mailing list. These improvements make the autobuilder infrastructure more scalable, and allows to provide statistics, and a much better daily report sent to the project’s mailing list.

In detail, the contributions of Bootlin were:

Bootlin contributions to the 3.9 kernel

A few months ago, we published a blog post showing our contributions to the 3.8 Linux kernel. With 128 commits merged in 3.8, Bootlin was ranked as the 17th company in terms of kernel contributions.

The 3.9 kernel has been released a few weeks ago, with again a significant number of contributions from Bootlin. According to these statistics, Bootlin contributed 92 patches during the 3.9 cycle, making the company the 26th most important contributor to the Linux kernel for this release, and this time, five engineers from Bootlin contributed patches.

Among the contributions that we made:

  • Added a basic infrastructure for irqchip drivers in the drivers/irqchip directory. This directory is now used to store the drivers for the IRQ controllers of various processors.
  • Made a number of improvements to the Marvell SDIO driver, including the addition of a Device Tree binding for it, and enabled its usage on Marvell Armada 370 and Armada XP platforms, as well as converting the Marvell Kirkwood platforms to use Device Tree probing instead of legacy probing for their SDIO interface.
  • Contributed a number of improvements to support Crystalfontz i.MX28 based modules, including the Device Tree for the CFA10037 expansion board, various improvements for the CFA10049 expansion boards, and a driver for the Himax HX8357B LCD controller.
  • A large number of improvements to the support of the Allwinner ARM SoCs, most notably a pinctrl driver for those SoCs, which allows to configure the muxing of I/O pins, and a gpio driver, to use the pins as general-purpose I/Os. We also contributed the support for the Miniand Hackberry platform, based on an Allwinner SoC. This work is all done by our engineer Maxime Ripard, who is the maintainer of the Allwinner SoC support in the Linux kernel.
  • Improvements to the PCA953x driver (for I2C GPIO expanders) in order to support the PCA9505 chip, that has 40 GPIOs. This required quite some work, as the PCA953x was originally limited to chips having at most 32 GPIOs. This improvement was done in order to support the GPIO expander box provided by Globalscale for the Armada 370-based Mirabox platform.
  • We added support for the Real Time Clock on Armada 370 and Armada XP based platforms, added support for local timers on Armada XP, added support for the new Armada XP GP evaluation board.
  • We enabled support for the SPI controllers and the USB controllers on Armada 370 and Armada XP based platforms.

Our high rate of contributions is going to continue, as we already have 95 patches merged for the upcoming 3.10 kernel and have already submitted a number of patches for the 3.11 kernel.

Here are details about our contributions to the 3.9 kernel:

Linux kernel 3.8 released, Bootlin top #17 contributor

Thomas Petazzoni and Grégory Clement, Bootlin kernel engineers
Thomas Petazzoni (front) and Grégory Clement (back) at the Embedded Linux Conference 2013 in San Francisco, discussing ARM Linux kernel issues.
Early last week, version 3.8 of the Linux kernel has been released by Linus Torvalds. The KernelNewbies web site, has, as usual, a great summary of what’s new in this release, together with lots of links to the relevant LWN articles. With 12394 commits, 3.8 has been the busiest ever kernel release cycle, the previous record being held by 2.6.25 with 12243 commits.

Despite this huge activity, Bootlin has been the 17th most active employer during the 3.8 cycle, with 128 commits merged into the mainline Linux kernel, representing a bit more than 1% of the total number of commits. See the statistics by employer at http://www.remword.com/kps_result/3.8_whole.html and in the traditional LWN article. This puts Bootlin before Nvidia, Qualcomm, ARM or Oracle in number of commits, and just a few commits behind Freescale. See the Git repository for the list of our contributions.

In detail, Bootlin contributions for 3.8 have been:

  • A large number of contributions related to the support of the Marvell Armada 370 and Armada XP SoCs, done by Grégory Clement and Thomas Petazzoni. Contributions included: a new network driver for the Armada 370 and Armada XP, support for the Armada XP-based OpenBlocks AX3 platform, support for the Armada 370-based Globalscale Mirabox platform, a big number of improvements and Device Tree support for the Marvell XOR engine driver, beginning of Device Tree support for the older Marvell Orion5x SoC family, support for the L2 cache found in Armada 370/XP, clock drivers for Armada 370/XP, SMP support for Armada XP, enabling of SATA on Armada 370/XP platforms.
  • The contribution of the initial support for a new SoC family in the mainline Linux kernel: the Allwinner A10 and Allwinner A13 ARM SoCs. This support has been contributed by Maxime Ripard, who has become the maintainer for this new ARM sub-architecture.
  • A driver for the I2C-based SSD1304 OLED display, a nice 128×32 pixels monochrome OLED display, contributed by Maxime Ripard.
  • A number of improvements in the support for the Crystalfontz i.MX28-based platforms, the CFA10036 and its expansion board the CFA10049. These contributions have also been made by Maxime Ripard.

Through these contributions, Bootlin have gained a good expertise in support for ARM SoCs and boards inside the Linux kernel. If you are interested in having us help you bring the support of your ARM board or ARM SoC into the mainline Linux kernel, do not hesitate to contact us, you will be directly answered by our engineers doing Linux kernel development!