Buildroot 2013.08 released, new features and contributions from Bootlin

Buildroot logoThe 2013.08 release of Buildroot has been published a few days ago by Peter Korsgaard, the project maintainer. As usual, this release contains a number of improvements and new features that are summarized in Peter’s release e-mail, and also visible in the CHANGES file.

On a total of 744 commits merged for this release, Bootlin has contributed 141 patches, focusing on the following main improvements:

  • Conversion of the “internal toolchain back-end” of Buildroot to use the package infrastructure. The internal toolchain back-end is the piece of code in Buildroot that is responsible for building a cross-compilation toolchain (i.e building binutils, gcc, the C library, gdb and the necessary dependencies). Until now, this code was using some basic makefiles, many of which dating from many years back in the history of Buildroot. By converting this piece of code to use normal Buildroot packages, it is now easier to maintain and extend. It is worth noting that the internal toolchain back-end is only one of the two back-ends of Buildroot in terms of toolchains: it can also use pre-built external toolchains.
  • Thanks to the clean up highlighted above, we have added eglibc support to the internal toolchain back-end. Until now, using eglibc or glibc was only possible using pre-built external toolchains. Now, Buildroot is directly capable of building eglibc-based toolchains, in addition to the uClibc library which has been supported for many years by Buildroot. Note that we have already posted patches that also add glibc support, they should hopefully be included for the next release, 2013.11.
  • Vast improvements in the way Buildroot supports the various floating point possibilities on ARM: we’ve added support for the EABIhf ABI, improved how the various floating point units can be selected, etc. Selecting the right floating point solution for your embedded Linux system should now be a lot easier.
  • Support to build a system using the Thumb2 instruction set available on ARM, which provides a smaller code size compared to the classical ARM instruction set.
  • Updates to the available external toolchains: addition of the Arago ARMv5 and ARMv7 toolchains, and update the versions of the available Linaro toolchains for ARM and AArch64.
  • Addition of packages to support the video decoding hardware of some AT91 SoCs, the Hantro x170.

Moreover, in the absence of the official maintainer Peter Korsgaard, Thomas Petazzoni has played the role of interim maintainer during approximately one month, and has handled the first two release candidates of the 2013.08 cycle.

Last but not least, Thomas has also been the mentor of Spenser Gilliland, a student working on Buildroot as part of the Google Summer of Code. His work consists in improving support for ARM multimedia features in Buildroot, and a part of his work went into the 2013.08 release:

  • Addition of a libvpx package
  • Addition of a libopenmax virtual package to support various OpenMAX implementations
  • A complete bump of the Glib/Gtk stack
  • The addition of GStreamer 1.x support (Buildroot already had support for GStreamer 0.10.x, but not the more recent 1.x)
  • Addition of the gst-omx package which allows accelerated video decoding on the Raspberry Pi board thanks to an OpenMAX specific implementation
  • Addition of a ti-gfx package that allows to support OpenGL on TI OMAP platforms, it has been successfully tested with the BeagleBoard XM
  • Addition of the sunxi-mali package to support OpenGL on Allwinner SOCs, and the sunxi-cedarx package to support accelerated video decoding on Allwinner SOCs

The Google Summer of Code is still on-going until the end of September, and Spenser has already posted patches to improve support for Mesa3D, libdrm and the addition of the glmark2 OpenGL benchmark. Those improvements will hopefully be part of the next 2013.11 release.

In detail, the contributions from Bootlin for this release have been:

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: