Embedded Linux News

Version 2013.02 of the Buildroot embedded Linux build system has been released by its maintainer, Peter Korsgaard, see the release announcement. A tarball has been released, but most users will probably like the Git tag.

In this new version:

• The toolchain support has been updated: addition of GDB 7.5.1, switch to GCC 4.6.3 as the default compiler, usage of Crosstool-NG 1.17.0 for the Crosstool-NG toolchain backend, many updates to the external toolchains (updates of Linaro ARM and AArch64 toolchains, and to the MIPS Sourcery CodeBench toolchain).
• At the architecture level, added ARM Cortex-A5 and Cortex-A15, brought some Xtensa fixes, deprecated the support for OABI on ARM, added some missing PowerPC variants, and the ARM1136JF-S rev1 variant.
• Added default board configuration for Snowball, Calao USB-A9260, the ML705 (PowerPC440) emulated by Qemu and the ARM Exynos4210 platform emulated by Qemu.
• Addition of Eclipse integration. A Buildroot-specific plugin is provided, which allows Eclipse to automatically discover and use the Buildroot toolchains available on the current machine. See the project Wiki for more details.
• There are now configuration options to set the system root password, and the possibility of using post-image scripts (scripts that are executed after all filesystem images have been generated, for example to generate a final firmware image, or automatically uncompress a filesystem into a NFS directory).
• A number of packages were added: b43-firmware, b43-fwcutter, bustle, cache-calibrator, cegui06, celt051, classpath, curlftpfs, dvb-apps, dvbsnoop, elfutils, enlightenment, firmware-imx, flashbench, gd, gesftpserver, gst-fsl-plugins, httping, iftop, imx-lib, jamvm, jpeg-turbo, keyutils, libatasmart, libcofi, libebml, libevas-generic-loaders, libfslcodec, libfslparser, libfslvpuwrap, libgsasl, libiscsi, libmatroska, libmcrypt, libmhash, libqwt, libseccomp, libsha1, linenoise, mcrypt, media-ctl, ncdu, neard, neardal, nettle, perf, polkit, proxychains, python-bottle, python-pyparsing, rpi-firmware, rpi-userland, sg3_utils, slirp, snowball-hdmiservice, spice, spice-protocol, tcllib, tvheadend, udisks, usbredir, ux500-firmware, vde2, xcb-utils-keysyms, yavta, zd1211-firmware.
• A number of old X.org graphics drivers have been removed, as they are very unlikely to be used, especially in embedded contexts.
• And many, many package were upgraded or fixed.

With 849 commits, this three months cycle was almost as active as the previous one, which had 856 commits. The contributors having submitted more than 10 patches are:

247  Gustavo Zacarias
203  Thomas Petazzoni
127  Peter Korsgaard
 61  Yann E. MORIN
 39  Arnout Vandecappelle (Essensium/Mind)
 20  Samuel Martin
 15  Simon Dawson
 14  Maxime Ripard
 12  Stefan Fröberg

It is also worth noting that during this cycle, the Buildroot community had a meeting in Brussels early February, for which we published a report some time ago.

The Buildroot project has had its developers meeting on Monday and Tuesday earlier this week in Brussels, right after the FOSDEM. Google kindly offered to host the event, which took place in the Brussels offices of the company. Seven persons participated to the meeting: Peter Korsgaard (Buildroot maintainer), Arnout Vandecappelle, Samuel Martin, Thomas De Schampheleire, Dimitrios Siganos, and your editor, Thomas Petazzoni.

Five of the seven participants of the Buildroot Developers Meeting. From left to right: Samuel Martin, Arnout Vandecappelle, Thomas Petazzoni, Thomas de Schampheleire, Peter Korsgaard.

During the entire event, notes have been taken to keep track of the discussion and decisions taken, those notes are now available on the Wiki page of the event. Amongst the topics discussed:

• Addition of the support for post-image scripts, which would be executed after the root filesystem images are created, to allow project-specific customizations.
• Discussion on how to better guide Buildroot users as to what are the best practices to use this tool. The participants agreed to improve the Buildroot manual by describing a few use cases to help new users to organize their Buildroot-based projects.
• How to improve Buildroot when used during application/system development and not only as an integration platform. Specifically, the patch series that builds each package out-of-tree, making it easier to work with custom source trees has been discussed, and the general principle accepted.
• Arnout wondered if it would make sense to maintain stable, long-term releases. However, it seemed to most of the participants that this would require too much work for the project for now.
• There was also a wider discussion about how the project is doing. The consensus seems to be that the project is doing well: the number of contributors increases, and the number of users is apparently important. However, two potential threats were discussed. The first is the existence of an increasing number of Buildroot forks that do not contribute back their changes upstream. This means that the main project misses contributors, and those forks are not generally very well-maintained over the long run, giving a poor reputation to the project. The second threat discussed was the increasing size of flash and storage used in embedded systems, making tools like Buildroot, tailored for small embedded systems, less useful compared to binary distributions like Emdebian. However, many of the participants felt that Buildroot is not only about the size of the generated system, but also about its simplicity and therefore the amount of control it brings to embedded Linux developers.



• Some big directions for the projects were discussed. The first important direction is that Buildroot needs to have more packages for the SoC-specific libraries used for 3D acceleration or video encoding/decoding. Those, general proprietary libraries, are often difficult to package, but are necessary to make Buildroot useful for a number of platforms. The second important direction was the interaction with the Crosstool-NG toolchain generator, and whether and how it would be possible to use it as the default backend for building toolchains in Buildroot. A number of problems remain to be solved, but the Crosstool-NG maintainer, Yann E. Morin, has asked to give another release cycle to find solutions to the problems discussed.
• Some discussion has taken place on how to handle the make targets that allow to configure the Linux kernel, Busybox or uClibc from Buildroot (make linux-menuconfig, make busybox-menuconfig, etc.), and how to keep the modified configuration. After much discussion, an agreement has been found on how to handle this.
• The problem of systemd and udev has been discussed. Buildroot is currently stuck with an old version of systemd and udev, because the project wants to be able to offer udev-based systems that don’t use systemd. Unfortunately, the modern version of systemd directly integrate udev, and it is not possible to build the latter without building the former, bringing D-Bus as a dependency. Investigating the eudev fork was discussing, but relying on a forked version of udev may be causing compatibility issues in the future.
• The removal of the support for development files and toolchain on the target has been discussed. This feature (which allows to install a compiler, headers and so on on the target) has been deprecated since the last release. However, participants generally felt we should give a little bit more time for Buildroot users to react on this, and therefore the feature will not be removed for now.
• The problem of kconfig select statement bypassing the depends on statements of the selected package has again been discussed at length, as during the previous meeting. Two solutions were proposed: either use an upper-level language on top of kconfig, which would be compiled into kconfig code having the right dependencies. Not many participants liked this idea, because it is moving away from its simplicity (“the project is based only on well-known tools and languages: kconfig and make”). The other solution was to add manually more options to handle this dependency problem (the so-called “AVAILABLE” proposal from Yann E. Morin), but unfortunately it didn’t solve the problem of the kconfig comments shown in Buildroot menuconfig when a package is not available for some reason. Participants felt these comments are really needed to let users know that a package exists in Buildroot, but that it isn’t available due to a missing toolchain feature. In the end, participants agreed that the only reasonable solution for now is to keep adding the needed depends on statements manually on all the reverse dependencies of a package having depends on statements.
• A number of other, smaller topics have been discussed and are reported on the Wiki page.

In addition to these discussions, the Buildroot developers also did some patch triaging in the project patchwork, taking decisions on a number of long-waiting patches.

All in all, the participants felt the meeting was very productive and that two days were a good duration for such a meeting, giving enough time for discussion. As it appears now to be a tradition, it is assumed that the next Buildroot meeting will next place near to the upcoming Embedded Linux Conference Europe.

It’s been a few weeks already, but useful to know: on December 28th, Automake 1.13 has been released. Automake is an important tool in the embedded Linux space as many components use it as part of their build system, along with autoconf and libtool. For the better or the worse, some could say, but the autotools are still omnipresent, and for the embedded Linux developers, they have generally shown a pretty decent handling of cross-compilation issues.

This new release by itself doesn’t bring that many important changes, but it announces major changes that will occur at the next Automake release, 1.14. Quoting from the release e-mail:

* WARNING: Future backward-incompatibilities!

  - Automake 1.14 will likely require Autoconf 2.70 or later (which is
    still unreleased at the moment of writing, but is planned to be
    released before Automake 1.14 is).

  - Automake 1.14 will likely drop support for the long-deprecated
    'configure.in' name for the Autoconf input file.  You are advised
    to use the recommended name 'configure.ac' instead.

  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
    be removed in Automake 1.14.  The $(mkdir_p) make variable and the
    @mkdir_p@ substitution will still remain available (as aliases of
    $(MKDIR_P)) for the moment, for better backward compatibility; but
    you are advised to stop using ASAP.

  - The ACLOCAL_AMFLAGS special make variable will be fully deprecated
    in Automake 1.14 (where it will raise warnings in the "obsolete"
    category).  You are advised to start relying on the new Automake
    support for AC_CONFIG_MACRO_DIRS instead (which is introduced with
    this release; see below for more information).
[...]
  - Support for the long-deprecated INCLUDES variable will be removed
    altogether in Automake 1.14.  The AM_CPPFLAGS variable should be
    used instead.

These changes are quite likely to break a number of open-source components that haven’t followed the progressive changes in the automake world. For example, there is still a certain number of open-source components that use the configure.in file name, and some are also probably still using some of the constructs that will get removed in Automake 1.14.

It is therefore probably a good time to look around at the projects you’re maintaining, or that you’re using or contributing to, and check whether they will pass the Automake 1.14 step properly!