Free Electrons 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. Free Electrons engineers again contributed to this release, with 99 patches integrated, making Free Electrons 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, Free Electrons 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, Free Electrons 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, Free Electrons has again participated significantly to the development of Buildroot:

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

Amongst the features and improvements contributed by Free Electrons:

  • 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 Free Electrons Jenkins system that Maxime has set up.
  • A huge number of build issues trigerred by the autobuilders have also been fixed thanks to Free Electrons 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 Free Electrons were:

Free Electrons 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, Free Electrons 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 Free Electrons. According to these statistics, Free Electrons 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 Free Electrons 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, Free Electrons top #17 contributor

Thomas Petazzoni and Grégory Clement, Free Electrons 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, Free Electrons 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 Free Electrons 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, Free Electrons 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, Free Electrons 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!

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

or

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 Free Electrons 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 Free Electrons 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.

Free Electrons contributions

Free Electrons 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 Free Electrons
    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 Free Electrons
     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.

Buildroot 2011.08 released!

Buildroot logoAs promised by the time-based release schedule, a new version 2011.08 of Buildroot has just been released. For those just coming in, Buildroot is a utility that automates the process of building an embedded Linux system: generating a cross-compilation toolchain or importing an existing one, cross-compiling multiple user-space libraries or applications, generating a root filesystem image and building the kernel or bootloader images. We use it extensively at Free Electrons for various projects and therefore contribute regularly to this project.

The major highlights of this version are :

  • An updated version of udev. For a long time, Buildroot has been stuck with an ancient udev release, due to the slightly more complicated dependencies of newer udev versions. Fortunately, Yegor Yefremov and other contributors have done the work to integrate those dependencies and get a modern version of udev to work in Buildroot.
  • An updated version of util-linux has been integrated. Here as well, updating it wasn’t completely straightforward, due to utility libraries such as libuuid, which is also present and e2fsprogfs, and used by multiple other packages.
  • The conversion of the Linux kernel build process and the bootloaders build process to the GENTARGETS infrastructure of Buildroot. This makes the build process of the kernel and the bootloaders much more similar to regular packages, and allows to provide the capability of fetching kernel sources not only from tarballs over http/ftp, but also from Git or Subversion repositories.
  • The kernel build process has been extended to support Linux 3.x versions and also release candidates versions.
  • Some improvements for using Buildroot to generate systems for non-MMU targets
  • Some new packages have been added: acl, attr, ebtables, gnutls, inotify-tools, ipset, libargtable2, libiqrf, libmnl, libnspr, libnss, libroxml, libyaml, live555, mxml, orc, rsyslog, sredird, statserial, stunnel, ti-utils, uboot-tools, yajl, and many, many packages have been upgraded or fixed.

The amount of patches merged for this release (287) is almost identical to the number of patches for the past release (286), but the number of contributors has increased from 28 to 35. Generally speaking, we are seeing an increasing number of requests and contributions from users :

   143  Peter Korsgaard
    36  Thomas Petazzoni
    21  Sven Neumann
    13  Gustavo Zacarias
    13  Yegor Yefremov
     9  Maxime Ripard
     7  Yann E. MORIN
     4  Baruch Siach
     4  Daniel Mack
     4  Luca Ceresoli
     3  Jean-Christophe PLAGNIOL-VILLARD
     3  Thomas De Schampheleire
     2  Allan W. Nielsen
     2  Mike Williams
     2  Phil Edworthy
     2  Will Newton
     1  Arnout Vandecappelle (Essensium - Mind)
     1  Arnout Vandecappelle (Essensium/Mind)
     1  Benoit Mauduit
     1  Benoît Mauduit
     1  Daniel Hobi
     1  Daniel Nyström
     1  Danomi Mocelopolis
     1  Evgeni Dobrev
     1  Francis Mendes
     1  Frederic Bassaler
     1  Frederik Pasch
     1  H Hartley Sweeten
     1  Heiko Helmle
     1  Marek Belisko
     1  Michael J. Hammel
     1  Milton Soares Filho
     1  Philippe Reynes
     1  Robin Holt
     1  Tristan Lelong

Two developers from Free Electrons have contributed patches for this release: my colleague Maxime Ripard has contributed 9 patches (Python build fixes, toolchain configuration fix, new rsyslog package, rework of the logging init scripts, new stunnel package, /dev/shm fix for the initialization scripts, code cleanup) and I (Thomas Petazzoni) have contributed 36 patches (conversion of the kernel and bootloaders to the GENTARGETS infrastructure, support for Linux 3.x and release candidates, improvements for non-MMU targets, the new scons package, upgrade of valgrind, some other code cleanup and fixes).

For the next release, I expect to contribute a set of patches that has already been reviewed on the list, and which adds the possibility of building packages from an existing source directory instead of letting Buildroot handle the download/extract/patch part of the build process. This feature will make it much much easier to use Buildroot during the development of the kernel, an application or a library for the target embedded system. I have also posted patches that convert the documentation over to the asciidoc format and I intend to do various additions to this documentation.

It is also worth mentioning that the Buildroot developers (Peter Korsgaard and myself) and the Crosstool-NG maintainer Yann E. Morin are organizing a Developer Day on October, 29th in Prague, the day after the Embedded Linux Conference Europe. All developers or users interested in Buildroot and/or Crosstool-NG are invited to join. See http://lists.busybox.net/pipermail/buildroot/2011-August/045066.html for more details.

Barebox 2011.03 released, with contributions from Free Electrons

BareboxBarebox is a bootloader started about two years ago for embedded systems of various architectures. It plays the same role as U-Boot, which is the best known project in this area, but has several advantages over U-Boot. First, it has a much better configuration and compilation system, based on the one used by the Linux kernel: instead of the rusty include/configs/myboard.h configuration headers in U-Boot, Barebox provides a nice menuconfig/xconfig/defconfig based configuration system, that everyone is familiar with. Second, Barebox has a source code organization very similar to the one of the Linux kernel and has replicated the device/driver model of the kernel. This allows to have a nice separation between device drivers and their instantiation, and a source code that looks familiar to anyone that already does kernel development.

Of course, as Barebox is newer than U-Boot, the number of architectures and platforms is more limited, but it is growing rapidly. It already supports ARM, PPC, Blackfin, x86 and a testing sandbox architecture. On ARM, the supported platforms are AT91, EP93xx, iMX, Nomadik, OMAP, S3C24xx and Versatile. On PPC, a single mpc5xxx platform is supported. Patches to add support for the NIOS architecture have also been posted recently (NIOS is a soft-core architecture from Altera).

As a young but fast-growing project, Barebox has chosen a quick development cycle: new releases are made each month, and Barebox 2011.03 has been released a few days ago. It has many ARM and generic improvements, but is also the first release with contributions from Free Electrons :

Gregory CLEMENT (3):
      BMP: Add support for 32bpp video frame buffer
      ARM STM/i.MX: Add possibility to choose the bit per pixel for STM video driver
      fb i.MX23/28: Add the reset control of LCD

My colleague Gregory Clement has contributed several improvements to framebuffer support on the i.MX platform. Those improvements were made in the context of a customer project, for which Barebox was used as a way of showing immediately after the device start-up a nice logo on the screen, while the system continues to boot in the background. Initially, the user had to wait 20+ seconds to see a logo on the screen showing that the system was booting. With our Barebox based solution, a logo is now visible on the screen less than 2 seconds after the power on button is pushed.

Buildroot 2010.08 released!

Buildroot logoOn the last day of August, just in time, the 2010.08 version of Buildroot has been released. For the record, Buildroot is an easy-to-use embedded Linux build system: it can build your toolchain, your root filesystem with all its components (Busybox, libraries, applications, etc.), your kernel and your bootloaders, or any combination of these components.

Amongst the interesting changes in this version :

  • Complete rewrite of the bootloader build code. It contained a lot of legacy, unused and unclear stuff, it is now much easier to use and extend. We’ve removed support for Yaboot and added support for the new Barebox bootloader, and all the code to support AT91Bootstrap, AT91DataFlashBoot, U-Boot, Grub and Grub 2 has been rewritten.
  • Complete rewrite of the Linux kernel build code. It was also complicated to use, with an horribly complicated kernel version selection mechanism, the new code is much easier to configure and use.
  • The configuration file .config is now located in the out-of-tree directory when the O= option is used. So typically, for an out-of-tree build (which are very convenient when using the same Buildroot source tree for different projects/tests), you could do : mkdir ~/myoutput ; make O=~/myoutput menuconfig ; make O=~/myoutput
  • Support for building NPTL toolchains with uClibc, using the latest uClibc snapshots.
  • Support for the gconfig Gtk-based configurator, in addition to the already available menuconfig and xconfig
  • A particular effort has been put on fixing many of the bugs in our Bugzilla, improving robustness thanks to automated random builds, and converting even more packages to the generic and autotools infrastructure
  • Various things have also been deprecated: support for the CRIS, IA64, Sparc64 and Alpha architectures, support for Gtk over DirectFB (which is at the moment not supported upstream), Java support (no maintainer has volunteered to maintain this in Buildroot)
  • Many components have been bumped to newer versions
  • The shared configuration cache, which allowed to speed up the configuration of different packages, has been disabled by default, since it was causing a lot of problems with certain package configurations

I’ve again contributed to a significant portion of this release, being the author of the bootloader build code cleanup, the Linux kernel build code rewrite, leading an effort to reduce the number of outstanding bugs in our Bugzilla and many other little things. The contributors for this release are shown below :

   175  Peter Korsgaard
   168  Thomas Petazzoni
    38  Gustavo Zacarias
    18  cmchao
     8  Luca Ceresoli
     7  Paul Jones
     6  Lionel Landwerlin
     6  Malte Starostik
     5  Yann E. MORIN
     3  Julien Boibessot
     3  Khem Raj
     2  Dmytro Milinevskyy
     2  Francois Perrad
     2  Nick Leverton
     2  Peter Huewe
     2  Stanislav Bogatyrev
     1  Baruch Siach
     1  Bjørn Forsman
     1  Daniel Hobi
     1  Darcy Watkins
     1  Darius Augulis
     1  H Hartley Sweeten
     1  Karl Krach
     1  Kelvin Cheung
     1  Ossy
     1  Sagaert Johan
     1  Simon Pasch
     1  Slava Zanko
     1  Thiago A. Correa
     1  Will Wagner
     1  Yegor Yefremov

For the next release, there are already a few things in the pipeline :

  • Cleanup of all the board support code in Buildroot, in order to cleanly add support for more boards like BeagleBoard, Qemu boards, Calao boards, etc. We’ll use the new minimal defconfig mechanism used by the kernel. I’ve already started working on this
  • Cleanup of the package download process, to support Git and SVN download. The code has already been written by Maxime Petazzoni, reviewed on the list, so I expect it to be included fairly soon
  • Rewrite of libtool handling code, to remove some of our ugly libtool hacks. The code is currently being worked on by Lionel Landwerlin
  • Support for compiling toolchain using Crosstool-NG as a backend. The code is currently being finalized by Yann E. Morin, the author of Crosstool-NG
  • Further work on package uninstallation, clean partial rebuild. Some work has been started by Lionel Landwerlin, but it needs some discussion
  • Continue the conversion of packages to the generic and autotools infrastructures
  • I have also a ton of other things on my TODO-list : rework gdb/gdbserver support with external toolchains, rework the configuration of IPv6/RPC/locale/etc. with external toolchains, set up a Wiki-based Buildroot website with tutorials and better documentation, clean up the toolchain build process, reduce the number of “enhancement” bugs waiting in our Bugzilla, etc.

As Peter Korsgaard, Buildroot maintainer, said in the 2010.08 announcement: The next release is going to be 2010.11. Expect the first release candidate in late October and the final release at the end of November..

It is worth noting that we will be having a Buildroot Developer Day, on Friday 29th October, right after Embedded Linux Conference Europe. At least Peter Korsgaard, Lionel Landwerlin, Yann E. Morin and myself should be there.

Buildroot 2010.05 released: again many Free Electrons contributions

Buildroot logoJust one day before the end of May, Buildroot 2010.05 has been released by Peter Korsgaard, as predicted by the fixed release schedule used by the project. It can be downloaded at http://buildroot.org/downloads/buildroot-2010.05.tar.bz2. For the record, Buildroot is a simple and efficient tool to build embedded Linux systems: cross-compiling toolchain, root filesystem, kernel image and bootloader.

Major changes

The major user-visible changes are:

  • Re-organization of the menuconfig layout for packages. All packages are now organized in categories, making them easier to find
  • Our X.org package set has been upgraded to X.org 7.5.
  • Several new packages have been added: cdrkit, cramfs, genext2fs, genromfs, libatomic_ops, librsync, libusb-compat, lmbench, netperf, squashfs, squashfs3, squid. Many of them have been added as the result of a filesystem code generation cleanup
  • On the internal toolchain side (i.e toolchains generated by Buildroot), we have added support for uClibc 0.9.31, GCC 4.4.4, GDB 7.x and binutils 2.20.1.
  • On the external toolchain side (i.e. re-using existing toolchains), we have improved support for multilib toolchains (such as CodeSourcery toolchains)

In addition to these changes, 41 bugs of our bug tracker have been fixed, and dozens of packages have been upgraded or fixed.

Free Electrons contributions

Free Electrons has again made significant contributions to this release:

git shortlog -s -n 2010.02..
   224  Paulius Zaleckas
   182  Thomas Petazzoni, from Free Electrons
   148  Peter Korsgaard
    28  Gustavo Zacarias
    26  Will Wagner
    14  Lionel Landwerlin
     6  Yann E. MORIN
[...]

The things we have contributed include:

  • A big cleanup in the Buildroot code that generates the root filesystem images. It has been moved from various directories in target/ to a single, central location: fs/. The code that handled the compilation of host utilities to generate the filesystem images (genext2fs, cdrkit, mtd-utils, cramfs, squashfs, etc.) has been moved to normal packages, and an infrastructure has been added to factorize the common code of the various filesystem generation makefiles.
  • Better support for multilib external toolchains
  • A new script that generates nice dependency graph (see below)
  • A clarification of the gettext integration, to make it work properly with glibc toolchains.
  • Fixes to bug #75, bug #1789.
  • Dozens of build fixes found by testing random configurations.
  • Various code cleanups, that lead to the removal of several configuration options, which makes the usage of Buildroot a little bit easier.

Dependency graph generation

Thanks to the new package infrastructure that we have included in Buildroot a few releases ago, it is now easier to retrieve the list of dependencies of each package in a generic way. Using this, I recently implemented a dependency graph generation tool. It allows to generate nice graphs of the dependencies for a given package, like libgtk2 in the following example (click for the full sized version):

Note that packages in red are packages that do not use the generic or autotools infrastructure, so we couldn’t determine what their dependencies are.

We can also generate the dependency graph for a complete Buildroot configuration, with all packages:

Using this tool is fairly easy. You must first install the graphviz package on your distribution. For a single package dependency graph:

./scripts/graph-depends libgtk2 > libgtk2.dot
dot -Tpdf libgtk2.dot -o libgtk2.pdf

For a full dependency graph:

./scripts/graph-depends > full.dot
dot -Tpdf full.dot -o full.pdf

Note that the dependency graph always depends on the selected set of packages. It is not the absolute dependency graph, which would contain all existing dependencies. It only show the dependencies as they are in your current configuration.

Plans for the next release

The next release is scheduled for August (2010.08). I have in mind various things:

  • Cleanup of the bootloader compilation code and integration of support for Barebox. This is already implemented in one of my branch, so I should be able to push this fairly soon to Buildroot
  • Cleanup of the Linux kernel compilation code, with a much-wanted simplification of this. Again, this is already implemented on my side, but requires a little bit more work before being able to push this
  • Continue the effort to convert packages to the generic or autotools infrastructure. I have already sent a status update on this topic to the project mailing-list. We have 56 packages to convert to the generic infrastructure and 77 to convert to the autotools infrastructure.
  • Integration with Crosstool-NG, which is a job that Yann Morin, developer of Crosstool-NG has already started.
  • More improvements of the external toolchain integration
  • If some time is left, a cleanup and reorganization of the board support mechanism, so that we can add more boards in a sane way

Crosstool-NG 1.7.0, Free Electrons contributed basic Blackfin support

Yann E. Morin, maintainer of Crosstool-NG, has just announced version 1.7.0 of his toolchain building tool we like so much at Free Electrons. For the record, Crosstool-NG allows to build cross-compiling toolchains for a wide-range of architectures, using either glibc, uClibc, eglibc or newlib, and everything is configured through a menuconfig interface, familiar to all embedded Linux developers.

Blackfin architectureFree Electrons has contributed to this release, by adding some support for the Blackfin architecture, on which we have been working recently. Crosstool-NG is now capable of generating a FDPIC cross-compiling toolchain for Blackfin. FDPIC allows to use shared libraries even on no-MMU architectures like the Blackfin. This support of Blackfin in Crosstool-NG is only the beginning, a lot of work remains to be done to make sure that the toolchain works really well, and to support FLAT binaries and bare-metal as well.

Here are the patches that Free Electrons has contributed for this release :

The other major changes for this release are :

  • two new architectures have been added: Blackfin and mips64
  • building canadian-crosses has been enhanced
  • experimental support for gcc-4.5 has been added
  • eglibc can be optimized for size (instead of speed)
  • companion libraries can be built statically, removing the need for a wrapper
  • many components versions have been added, and associated patchsets updated
  • some less important new features, or enhancements for stability and usability
  • a lot of bug-fixes, of which some to help on Darwin & *BSD

The 1.7.0 release can be downloaded at http://ymorin.is-a-geek.org/download/crosstool-ng/crosstool-ng-1.7.0.tar.bz2 and the homepage of the Crosstool-NG project is http://ymorin.is-a-geek.org/projects/crosstool. Enjoy !