release – Page 2

Linux 3.15 released, an overview of Bootlin contributions

The 3.15 of the Linux kernel was released just a few days ago by Linus Torvalds. As explained by LWN.net, the headline features in 3.15 include some significant memory management improvements, the renameat2() system call, file-private POSIX locks, a new device mapper target called dm-era, faster resume from suspend, and more. One can also read the coverage by LWN.net of the first part and the second part of the merge window to get more details about the major new features in this release.

As usual, Bootlin contributed to the Linux kernel during this 3.15 cycle, and with a total of 218 patches contributed, it’s a new record for Bootlin. According to the KPS statistics, Bootlin ranked #12 in the list of companies contributing to the Linux kernel for the 3.15 kernel (if you exclude the “Unknown” and “Hobbyists” categories, which aren’t really companies).

The main features contributed by Bootlin again centered around the support for ARM processors:

By far, the largest contribution this cycle was the initial support for the new Armada 375 and Armada 38x processors from Marvell. Gregory Clement, Ezequiel Garcia and Thomas Petazzoni have been working on the code to support these processors since a few months ago, and started pushing the patches to the public in February this year. For the Marvell Armada 38x processor, it means that the code was pushed in mainline even before the processor was announced publicly! The features supported in 3.15 for these processors are: interrupts, GPIO, clocks, pin-muxing, serial, I2C, SPI, timer, L2 cache, SDIO (only for 375), SATA (only 375), XOR, PCIe, MBus, networking (only for 38x), NOR and NAND support. Many other features such as SMP, I/O coherency and various other peripherals will be supported in 3.16.
Convert support for the Atmel AT91SAM9RL processor to the Device Tree, done by Alexandre Belloni.
Addition of iio-hwmon to the Freescale i.MX23 and i.MX28 processors, which allows to use the internal temperature sensor of the processor. Done by Alexandre Belloni.
Multiple fixes and improvements to the AT91 ADC support. Done by Alexandre Belloni.
Support for the watchdog in Armada 370 and Armada XP was added, done by Ezequiel Garcia.
A driver for the SPI controller found in Allwinner A31 SoC was added, as well as all the Device Tree information to describe this controller and related clocks. Done by Maxime Ripard.
Support for the I2C controller found in the Allwinner A31 SoC was added into the existing mv64xxx-i2c driver, as well as the necessary Device Tree information to use I2C on this SoC. Done by Maxime Ripard.
Audio support was enabled on the Armada 370 SoC, re-using existing code for Kirkwood, and therefore making audio work on the Armada 370 DB platform. Done by Thomas Petazzoni.
A number of issues in the PCIe support for Marvell processors have been fixed, thanks to the reports from a number of users. Done by Thomas Petazzoni, with help from these users.

We also contributed other things than just support for ARM processors:

The main contribution in this area is the addition of UBI block, a driver that allows to use read-only block filesystems such as squashfs on top of a UBI volume. The code was originally written by David Wagner who was an intern at Bootlin, and later taken by Ezequiel Garcia who did a lot of additional cleanup work and community discussion to get the driver merged. Some details about this feature can be found in the Linux-MTD documentation.
A generic Device Tree binding to express NAND ECC related information in the Device Tree was contributed by Ezequiel Garcia.
The quest to remove IRQF_DISABLED continued, by Michael Opdenacker.

In details, all our contributions are:

Linux 3.14 released, Bootlin contributions inside!

Linus Torvalds has just released the 3.14 version of the Linux kernel. As usual, it incorporates a large number of changes, for which a good summary is available on the KernelNewbies site.

This time around, Bootlin is the 19th company contributing to this kernel release, by number of patches, right between Cisco and Renesas. Six of our engineers have contributed to this release: Maxime Ripard, Alexandre Belloni, Ezequiel Garcia, Grégory Clement, Michael Opdenacker and Thomas Petazzoni. In total, they have contributed 121 patches to this kernel release.

By far, the largest number of patches are related to the addition of NAND support for the Armada 370 and Armada XP processors. This required a significant effort, done by Ezequiel Garcia, to re-use the existing pxa3xx_nand driver and extend it to cover the specificities of the Armada 370/XP NAND controller. And these specificities were quite complicated, involving a large number of changes to the driver, which all had to also be validated on existing PXA3xx hardware to not introduce any regression.
Support for high speed timers on various Allwinner SOCs has been added by Maxime Ripard.
Support for the Allwinner reset controller has been implemented by Maxime Ripard.
SMP support for the Allwinner A31 SOC was added by Maxime Ripard.
A number of small fixes and improvements were made to the AT91 pinctrl driver and the pinctrl subsystem by Alexandre Belloni.
Michael Opdenacker continued his quest to finally get rid of the IRQF_DISABLED flag.
A number of fixes and improvements were made by Grégory Clement and Thomas Petazzoni on various Armada 370/XP drivers: fix for the I2C controller on certain early Armada XP revisions, fixes to make the Armada 370/XP network driver usable as a module, etc.

In detail, our contributions were:

Bootlin contributions to Linux 3.13

Version 3.13 of the Linux kernel was released by Linus Torvalds on January, 19th 2014. The kernelnewbies.org site has an excellent page that covers the most important improvements and feature additions that this new kernel release brings.

As usual Bootlin contributed to this kernel: with 121 patches merged in 3.13 on a total of 12127 patches contributed, Bootlin is ranked 17th in the list of companies contributing to the Linux kernel. We also appeared on Jonathan Corbet kernel contribution statistics at LWN.net, as a company having contributed 1% of the kernel changes, right between Renesas Electronics and Huawei Technologies.

Amongst the contributions we made for 3.13:

Standby support added to the Marvell Kirkwood processors, done by Ezequiel Garcia.
Various fixes and improvements to the PXA3xx NAND driver, as well as to the Marvell Armada 370/XP clocks, in preparation to the introduction of NAND support for Armada 370/XP, which will arrive in 3.14. Work done by Ezequiel Garcia.
Added support for the Performance Monitoring Unit in the AM33xx Device Tree files, which allows to use perf and oprofile on platforms such as the BeagleBone. Work done by Alexandre Belloni.
Support added for the I2C controllers on certain Allwinner SOCs, as well as several other cleanups and minor improvements for these SoCs. Work done by Maxime Ripard.
Continued the work to get rid of IRQF_DISABLED, as well as other janitorial tasks such as removing unused Kconfig symbols. Work done by Michael Opdenacker.
Added support for MSI (Message Signaled Interrupts) for the Armada 370 and XP SoCs. Work done by Thomas Petazzoni.
Added support for the Marvell Matrix board (an Armada XP based platform) and the OpenBlocks A7 (a Kirkwood based platform manufactured by PlatHome). Work done by Thomas Petazzoni.

In detail, the patches contributed by Bootlin are:

Buildroot 2013.08 released, new features and contributions from Bootlin

The 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 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:

Buildroot 2013.05 released, Bootlin contributions inside!

As 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:

Buildroot 2011.11 released: details on new features

As planned, Buildroot 2011.11 has been released at the end of November. You can download this release as a tarball or through the Git repository.

This release brings a set of new features on which I thought it would be nice to give some details.

The `file` and `local` site method

Each package in Buildroot defines from where the source code for the particular component being built is fetched. Buildroot has of course always supported fetching a tarball from HTTP of FTP servers. Later on, Buildroot has added support for fetching from Git, Subversion and Bazaar repositories, for example by doing:

MYPKG_SITE = http://somelocation.com/svn/foobar/trunk
MYPKG_SITE_METHOD = svn

MYPKG_SITE = git://somelocation.com/foobar.git

The <pkg>_SITE_METHOD variable allows to define the fetching method. When not specified, Buildroot tries to guess it from the <pkg>_SITE value. Of course, in ambiguous cases such as Subversion or Git repositories over HTTP (as shown in the first example), the <pkg>_SITE_METHOD must be specified.

This new version of Buildroot brings two new site methods: file and local.

The file site method allows to specify the location of a local tarball as the source code for the component to be built. For example:

MYPKG_SITE = /opt/software/something-special-1.0.tar.gz
MYPKG_SITE_METHOD = file

This can be useful for internal software that isn’t publicly available on a HTTP or FTP server or in a revision control system. This new site method was added by David Wagner, who has been an intern at Bootlin between April and September this year.

The new local site method allows to specify the location of the source code to be built as a local directory. Buildroot will automatically copy the contents of this directory into the build directory of the component and build it from here. This is very useful because it allows to version control your source code as you wish, make changes to it, and easily tell Buildroot to rebuild your component. Note that the copy is using rsync so that further copies are very fast (see the pkg-reconfigure and pkg-rebuild targets below). An example of using the local site method:

MYPKG_SITE = /opt/software/something-special/
MYPKG_SITE_METHOD = local

This new site method has been implemented by myself, as the result from my experience of using Buildroot with various Bootlin customers.

The source directory override mechanism

The local site method described above is great for packaging special components that are specific to the embedded device one is working on, like the end-user application, or special internal libraries, etc.

However, there are cases where it is needed to work with a specific version of an open-source component. This is typically the case for the Linux kernel or the chosen bootloader (U-Boot, Barebox) or with other components. In that case, one may want to keep using Buildroot to build those components, but tell Buildroot to fetch the source code from a different location than the official tarball of the component. This is what the source directory override mechanism provide.

For example, if you want Buildroot to use the source code of the Linux kernel from /opt/project/linux/ rather than download it from a Git repository or as a tarball, you can write the following variable definition in a board/company/project/local.mk file:

LINUX_OVERRIDE_SRCDIR = /opt/project/linux

Then, you reference this file through the BR2_PACKAGE_OVERRIDE_FILE option, in Build options -> location of a package override file. When building the Linux kernel, Buildroot will copy the source code from /opt/project/linux into the kernel build directory, output/build/linux-VERSION/ and then start the build process of the kernel.

Basically, this mechanism is exactly like the local site method described previously, except that it is possible to override the source directory of a package without modifying the package .mk file, which is nice for open-source packages supported in Buildroot but that require local modifications.

To summarize, here is my recommendation on how to use Buildroot for packages that require project-specific modifications:

You are using an existing open-source component on which you make some tiny bug fixes or modifications. In this case, the easiest solution is to add additional patches to the package directory, in package/<thepackage>/.
You are using an existing open-source component, but are making major changes to it, that require proper version control outside of Buildroot. In this case, using the source directory override feature is recommended: it allows to keep the Buildroot package .mk file unmodified while still using your custom source code for the package.
You have project-specific libraries or applications and want to integrate them in the build. My commendation is to version control them outside of Buildroot, and then create Buildroot packages for them using the local site method. Note that in the pkg_SITE variable, you can use the $(TOPDIR) variable to reference the top source directory of Buildroot. I for example often use MYAPP_SITE = $(TOPDIR)/../myapplication/.

The `<pkg>-rebuild` and `<pkg>-reconfigure` targets

For a long time, when one wanted to completely rebuild a given package from scratch, a possibility was has been to remove its build directory completely before restarting the build process:

rm -rf output/build/mypackage-1.0/
make

Or, using the -dirclean target available for each package:

make avahi-dirclean
make

As these commands remove completely the build directory, the build process is restarted from the beginning: extracting the source code, patching the source code, configuring, compiling, installing.

In 2011.11, we have added two new per-package targets to make it easy to use Buildroot during the development of components:

make mypkg-reconfigure will restart the build process of mypkg from the configuration step (the source code is not re-extracted or repatched, so modifications made to the build directory are preserved)
make mypkg-rebuild will restart the build process of mypkg from the compilation step (the source code is not re-extracted or repatched, the configuration step is not redone)

So, a typical usage could be:

emacs output/build/mypkg-1.0/src/foobar.c
make foobar-rebuild

However, beware that all build directories are removed when you do make clean, so the above example is only useful for quick testing of changes.

The case where the -reconfigure and -rebuild are really useful is in combination with the local site method or the source override directory mechanism. In this case, when pkg-reconfigure or pkg-rebuild is invoked, a synchronization of the source code is done between the source directory and the build directory is done before restarting the build.

Let’s take the example of a package named mypkg for which package/mypkg/mypkg.mk contains:

MYPKG_SITE = /opt/mypkg
MYPKG_SITE_METHOD = local

Then, to work on your package, you can simply do

emacs /opt/mypkg/foobar.c    # Edit as usual your project
make mypkg-rebuild           # Synchronizes the source code from
                             # /opt/mypkg to the build directory
                             # and restart the build

Integration of real-time extensions

In this 2011.11, an interesting addition is the integration of the Xenomai and RTAI real-time extensions to the Linux kernel. The Xenomai integration was initially proposed by Thomas de Schampheleire and then extended by myself, and I have also added the RTAI integration. This integration allows to seamlessly integrate the kernel patching process and the compilation of the required userspace libraries for those real-time extensions.

Conversion of the documentation to asciidoc

Back in 2004, one of my first contribution to Buildroot was to start writing documentation. At the time, the amount of documentation was small, so a single and simple HTML document was sufficient. Nowadays, Buildroot documentation has been extended significantly, and will have to be extended even further in the future. The approach of a single raw HTML document was no longer up to the task.

Therefore, I have worked on converting the existing documentation over to the asciidoc format. This allows us to split the source of the documentation in several files, for easier edition, and allows to generates a documentation in multiple formats: single HTML, split HTML, raw text or PDF.

Just run make manual in Buildroot 2011.11 to generate the manual. Note that the version available on the website is still the old HTML version, but it should soon be updated to the new asciidoc version.

Bootlin contributions

Bootlin has again contributed to this Buildroot release:

$ git shortlog -sen 2011.08..2011.11 | head -12
   126	Peter Korsgaard
   104	Gustavo Zacarias
    62	Thomas Petazzoni, from Bootlin
    27	Yann E. MORIN
    21	Sven Neumann
    13	Yegor Yefremov
    10	Thomas De Schampheleire
     7	H Hartley Sweeten
     5	Frederic Bassaler
     4	Arnout Vandecappelle (Essensium/Mind)
     4	Maxime Ripard, from Bootlin
     3	Baruch Siach

Our contributions have been:

Implementation of the source directory override mechanism
Implementation of the local and file site methods
Implementation of the pkg-rebuild and pkg-reconfigure targets
Conversion of the documentation to asciidoc and documentation improvements
Various improvements for external toolchain support: optimization of the toolchain extraction and copy (reduced build time), integration of the support of the CodeSourcery x86 toolchains, update of all CodeSourcery toolchains to the latest available versions
Removed useless arguments from the CMAKETARGETS, AUTOTARGETS and GENTARGETS macros, used by all packages in Buildroot. Instead, such pieces of information are automatically figured out from the package .mk file location in the source tree
Added the cifs-utils package (for mounting CIFS network filesystems), the libplayer package, the picocom package.
Cleanup, improve and merge the Xenomai integration done by Thomas de Schampheleire, and implement the RTAI integration
Did a lot of cleanup in the source tree by creating a new support/ directory to contain various tools and scripts needed by Buildroot that were spread over the rest of the tree: the kconfig source code, the special libtool patches, various scripts, etc.

Next release cycle and next Buildroot meeting

The next release cycle has already started. After the meeting in Prague, it was decided that Peter Korsgaard (Buildroot maintainer) would maintain a next branch between the -rc1 and the final version of every release, in order to keep merging the new features for the next release while debugging the current release. This next branch for 2012.02 has already been merged. For example, the addition of the scp and Mercurial site methods has already been merged for 2012.02, as well as numerous other package updates.

On my side, besides usual package updates, I’d like to focus my work for this 2012.02 cycle on improving the testing coverage and on improving the documentation. My colleague Maxime Ripard is working on integrating systemd into Buildroot, as an alternate init mechanism.

The Buildroot community will also be organizing its next meeting in Brussels, on Friday February, 3rd 2012, right before the FOSDEM conference. Buildroot users and developers are invited to join, just contact us through the Buildroot mailing list.

uClibc 0.9.32 released, with NPTL support

A little bit more than one year after 0.9.31, the uClibc project has recently released a new version of the famous C library, uClibc 0.9.32. For the record, uClibc is an alternative standard C library for embedded Linux systems, which features a smaller size than the usual glibc or eglibc, a high-level of configurability and support for non-MMU architectures. uClibc usage is mandatory on non-MMU architectures running a Linux kernel since the traditional glibc or eglibc do not support non-MMU architectures. On architectures with MMU, uClibc may also be interesting for its reduced size, and has been used in a large number of systems over the last years.

The 0.9.32 release brings one major new feature : the support of the Native Posix Threads Library for the most common architectures (ARM, MIPS, PowerPC, x86, x86_64, SuperH and SuperH 64). NPTL is a different way of implementing the pthread userspace API than the one previously used in Linux, called LinuxThreads. The kernel mechanisms needed to implement NPTL have been added in 2.6 and support in glibc has been added a long time ago. uClibc was lagging behind in this area, and the new release fills this gap. This feature does not bring any visible API change, but completely changes the internal implementation of the threading mechanism, with better performance and a behavior that is more similar to the one we have on glibc based hosts. For more details about the differences about NPTL and LinuxThreads, one can check Ulrich Drepper and Ingo Molnar’s paper on this topic: NPTL Design paper.

Another new feature of the 0.9.32 release is support for the C6x architecture, which is a DSP architecture from Texas Instruments, capable of running a Linux kernel (see http://linux-c6x.org). Having upstream support in uClibc allows this architecture to benefit from a nice standard C library.

Buildroot 2011.05 released

Buildroot logo As expected with the time-based releases, Buildroot 2011.05 has been released just a few days ago. We have already published many blog posts about Buildroot, but to summarize for our new readers, Buildroot is a tool that automates and simplifies the process of building an embedded Linux system. You define your system configuration and components in a menuconfig/xconfig interface similar to the one the kernel uses, then hit make, wait a bit, and you have your embedded Linux system ready to run on your device. At Bootlin, we appreciate the simplicity of Buildroot, and many of our customers also appreciate it for the same reason. Of course, we also contribute significantly to Buildroot and we have started a commercial support offering on Buildroot.

The 2011.05 release

The 2011.05 release cycle was a little bit more quiet than usual, so the number of new features or major changes is not as large as it was for past releases. Amongst the interesting things:

Until now, Buildroot was only capable of building systems using a static /dev, in which device files are statically listed in a device table and created at system build time. The 2011.05 has added a configuration option to select how the /dev directory on the target should be handled. It can be handled in four different ways:
- with a static /dev, just as before
- with just devtmpfs. It allows to have a dynamic /dev without any other userspace components, which is really nice.
- with devtmpfs and mdev. In addition to having a dynamic /dev, it allows allows to execute arbitrary scripts when device are added/removed and to customize the owner, group and permissions for the device files.
- with devtmpfs and udev. This is the full solution, as used in desktop distributions.
There has been an internal infrastructure change on support for external toolchains, and this change will make those toolchains slightly easier to use. In Buildroot terminology, an external toolchain is a toolchain that hasn’t been built by Buildroot, but which Buildroot uses to compile code for the target platform. It allows to re-use existing toolchains such as the CodeSourcery toolchains, or toolchains generated externally with Crosstool-NG. To support those toolchains, we rely on the sysroot mechanism that the GCC compiler provides since the 4.x era. This mechanism allows Buildroot to make a complete copy of the C library binaries, C library headers and kernel headers into a staging directory, and then tell the toolchain utility (compiler, linker, etc.) to use this new directory as their sysroot. This means that a --sysroot option needs to be passed at every invocation of those tools. As this was not very convenient, especially to use the Buildroot toolchain as a SDK to build applications not packaged in Buildroot, the 2011.05 has added wrappers for the toolchain tools, which makes this completely transparent. So one can now just use $(O)/host/usr/bin/arm-linux-gcc as usual, and it will do the right thing.
A few new packages have been added: bonnie++ (a block device benchmark), can-utils (userspace utilities for the famous industrial CAN bus), gdisk (a sort of fdisk program, but for the new GPT partition table format), htop (a nice top alternative to watch the activity of processes), input-event-daemon (a simple daemon that executes arbitrary command in reaction to input events), libexif (a library to read the contents of EXIF tags in pictures), libraw (a library to decode pictures in various RAW formats), libv4l (the library to interact with Video4Linux devices), ngircd (an IRC server).
Many packages have been upgraded: the Gtk stack, the U-Boot and Barebox bootloaders and the internal toolchain components (gcc and uClibc), with experimental gcc 4.6 support.

Buildroot in the Linux Journal

The Linux Journal has published an issue, numbered 206, dedicated to Embedded Linux. This issue has several articles around Embedded Linux related topics:

Hexapod, a Linux powered robot
Debugging Embedded Linux platforms with Python and GDB
Breaking free the Gumstix DSP
Speech I/O for Embedded Applications
CyanogenMod 7.0, Gingerbread in the house
Tiny Core Linux
Roll your own Embedded Linux System with Buildroot, written by Alexander Sirotkin, which gives a good introduction to what Buildroot is and how to use it.

It is great to see articles about Buildroot in a such widely read magazine, and it should definitely help increasing the awareness about this build system.

Buildroot used by Fabrice Bellard in jslinux

In May, the famous developer Fabrice Bellard (known as the initial author of ffmpeg, qemu, but also for his records for the computation of pi) has released an impressive new project: an x86 emulator completely written in Javascript, which runs in a Web browser. This emulator is sufficiently capable and powerful to boot a Linux system. And the good news is that the Linux system that Fabrice Bellard is using for the demonstration was generated with Buildroot, as Bellard says in his technical notes about the project.