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.
Thomas Petazzoni |
Atmel is a well-known silicon vendor, making all sorts of system-on-chip ranging from small micro-controllers to more powerful ARM based processors. On the high-end of its SoC family, Atmel has been providing over a number of years an ARM926 based range of SoCs, the latest ones being the SAM9G and SAM9X family. Those SoC from Atmel have a very good reputation for industrial-type applications: the SoC are very well supported in the mainline Linux kernel, U-Boot and Barebox projects, and are relatively simple to work with, making them a nice choice for many projects. The quality and public availability of the datasheet for all their SoCs is also quite certainly a reason of their success. However, being based on the now old ARM926 core (implementing the ARMv5 architecture), those SoC were starting to be limited for performance-sensitive applications.
To fill this need, approximately a week ago, Atmel has unveiled a new family of SoC, the SAMA5D3, based on the Cortex-A5 core from ARM, implementing the ARMv7 architecture. Besides the higher-performance, this new family also achieve low power consumption. This family is composed of four different SoCs at the moment, that differ in the peripherals that they provide:
- ATSAMA5D31, ARM Cortex-A5 processor-based embedded MPU, 536MHz, Linux support, FPU, LCD controller, 10/100 Ethernet, security
- ATSAMA5D33, ARM Cortex-A5 processor-based embedded MPU, 536MHz, Linux support, FPU, LCD controller, gigabit Ethernet, security
- ATSAMA5D34, ARM Cortex-A5 processor-based embedded MPU, 536MHz, Linux support, FPU, LCD controller, gigabit Ethernet, dual CAN, security
- ATSAMA5D35, ARM Cortex-A5 processor-based embedded MPU, 536MHz, Linux support, FPU, dual Ethernet, dual CAN, security
A summary datasheet is available, as well as a complete datasheet (1700+ pages).
Evaluation kits are available, for the ATSAMA5D31, the ATSAM5D33, the ATSAM5D34 and ATSAM5D35.
The software support is also already available, with a linux4sam Wiki containing informations about the new evaluation boards, and the Git repository at https://github.com/linux4sam having the source code for Linux, Barebox, U-Boot or Buildroot. A lot of those patches have already been pushed upstream for example in Linux or Barebox.
Thomas Petazzoni |
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 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.
Thomas Petazzoni |
The Linux Conference Australia 2013 edition took place from January 28 to February 1st in Canberra and provided a rich schedule of talks. As they have already released the videos, it is a good opportunity to look at the talks that could be of interest to embedded Linux developers.
- Performance / real-time
- And a lot of other topics
- An Introduction to Linux IPC Facilities by Michael Kerrisk, video
- Vampire Mice: How USB PM impacts you by Sarah Sharp, video
- Making RCU Respect Your Device’s Battery Lifetime by Paul McKenney, video
- The future of non-volatile memory by Matthew Wilcox, video
- Wiggle while you work by Neil Brown, video
- Open Source Firmware by Duncan Laurie, video
- A New Linux Platform, Hardware and Software by Ricky Ng-Adam, video
- Software Transactional Memory in GCC 4.7 by Dave Boutcher, video
- Big and Little Endian inside / out by Benjamin Herrenschmidt, video
- Why kernel space sucks by Michael Kerrisk, video
Thomas Petazzoni |
The FOSDEM conference took place this week-end in Brussels. Besides the almost 500 talks that took place in the official schedule, a discussion about the Common Display Framework was organized on Sunday morning. Laurent Pinchart, who currently leads the discussion on this framework, posted a report of those discussions.
In his report, Laurent explains:
CDF has two main purposes. The original goal was to support display panels in a platform- and subsystem-independent way. While mostly useful for embedded systems, the emergence of platforms such as Intel Medfield and ARM-based PCs that blends the embedded and PC worlds makes panel support useful for the PC world as well.
The second purpose is to provide a cross-subsystem interface to support video encoders. The idea originally came from a generalisation of the original RFC that supported panels only. While encoder support is considered as lower priority than display panel support by developers focussed on display controller driver (Intel, Renesas, ST Ericsson, TI), companies that produce video encoders (Analog Devices, and likely others) don’t share that point of view and would like to provide a single encoder driver that can be used in both KMS and V4L2 drivers.
Read on the report for more details about where the Common Display Framework is going.
Thomas Petazzoni |
The schedule of the upcoming Embedded Linux Conference (February 20-22 in San Francisco) and the Android Builders Summit (February 18-19 in San Francisco) have been published recently.
The Embedded Linux Conference schedule shows a number of talks related to hardware support, multimedia, real-time, debugging, tools and more. This year, ELC has 3 tracks on Wednesday and Friday, and 4 tracks on Thursday.
The Android Builders Summit schedule shows talks related to Android porting, the state of Android support in the mainline Linux kernel, Android security, and many talks specific to various subsystems of Android: graphics, multimedia, sensors, etc.
Thomas Petazzoni |
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
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!
Thomas Petazzoni |
We recently mentioned the publication of videos from the embedded track of last year’s FOSDEM. This year’s FOSDEM is also approaching, as it will be taking place on February 2nd and February 3rd in Brussels, Belgium. The schedule of the different tracks has been announced, and as usual, there will be a lot of interesting things for embedded Linux people:
- Of course, the Embedded and Mobile Devroom will be the one having the highest number of talks interesting to embedded developers. The BaseRock and Yocto build systems will be discussed, graphical application development with QML, open-source software to support DLNA, open hardware and hardware interaction, ARM 64 bits, and more.
- The Operating Systems main track will also feature interesting talks about Porting Fedora on ARM 64 bits, virtualization, Open ARM GPU drivers, ARM support in the Linux kernel and the maintenance of a kernel subsystem.
- A small Robotics track with two talks that may interest some embedded people.
- And of course, the traditional X.org Devroom. X.org is clearly part of the core components of many embedded Linux systems, and the Devroom will reflect that with a talk about MALI200/400 reverse engineering (the MALI is the 3D GPU from ARM that is used in a number of SoCs), a talk reporting on Tegra-DRM/OpenTegra (Tegra is the family of ARM SoCs from NVidia) and a talk reporting on Freedreno (the effort to reverse engineer the GPU used in Qualcomm SoCs), and of course many more related to core X.org topics.
Of course, beyond the embedded-related topics, FOSDEM has many more tracks and talks in its schedule, covering a wide range of topics, making the whole event interesting for practically any open-source developer. It’s also good to remind our readers that the entrance is entirely free, no registration is required, and the event takes place during the week-end.
Your editor will be part of the FOSDEM attendance again this year, and will be giving the ARM support in the Linux kernel talk.
Thomas Petazzoni |
The 2013.01 release of the popular U-Boot bootloader has been published by Tom Rini, the interim maintainer. The U-Boot developers unfortunately don’t really keep a log of the major changes, so it’s not really easy to figure out the big picture, differentiate the big interesting changes from the usual flow of bug fixes.
A quick inspection of the git commit log since the 2012.10 release shows more than 1200 commits, a strong activity. Amongst those commits, the things that seem to be the most important changes are:
- A big cleanup of the serial drivers and serial infrastructure done by Marek Vasut, quite possibly as part of his work towards bringing a proper Device Model in U-Boot
- The support for a number of boards has been removed, a few PowerPC boards and ARM boards. The open-source world generally has very high standards in terms of preserving support for old platforms during a long time, but after too much time, supporting old platforms often gets into the way of maintainability of the code. So seeing a project removing support for old platforms from time to time is a good sign.
- The support for a number of boards has been added: eco5pk board (TI AM35xx based), the Nokia N900 (OMAP3 based), the Colibri board (NVidia Tegra 2 based), several i.MX6 based boards and the Freescale MCF54418TWR ColdFire development board.
- The SPL framework (for small first stage bootloaders) has been ported to PowerPC, and also to the ARM1136 part of the U-Boot code base.
- Support for new PowerPC SoCs has been added: Freescale B4860, T4240, P5040, etc.
- Addition of a NAND torture command, that tests intensively a NAND block to find if it is really usable or not.
- Addition of a
bootstage command, which displays the results collected by the bootstage feature, which measures the timing of the different steps of U-Boot execution. A feature definitely useful for those seeking improvements in boot time.
- Interestingly, support for DocBook based documentation as been added, modeled after what the Linux kernel is doing. Some documentation has been added.
- Many sparse fixes have been made, with the goal of generalizing sparse usage in U-Boot, it seems.
- Also worth noting, a large number of updates in the x86 support, the AHCI support and the i.MX family of SoCs
See the U-Boot Git repository for more details, and to fetch the latest source code.
Thomas Petazzoni |
Free Electrons has just posted the videos from the last Embedded Linux Conference Europe 2012 who took place early November last year in Barcelona. There are about 50 talks on topics such as real-time, kernel development, multimedia, hardware, and more. Your editor, who participated to the recording effort, and did the entire encoding work for those videos, also left a few recommendations for talks he found really great at ELCE.
At the same time, Free Electrons is releasing videos from the the embedded track at FOSDEM 2012, who took place February last year in Brussels Belgium. Eight talks on various embedded topics: OpenRISC, Qt development, the IIO kernel subsystem, how to safely upgrade embedded systems in the field, power management for SoCs in the Linux kernel, etc.
The reason the encoding took so long is because our encoding script was no longer working in recent versions of Ubuntu: ffmpeg regularly introduces regressions in the processing of MPEG Transport Stream files that come out of our HD camcorders. So, your editor has now switched over to the Git version of libav (for which he received an absolutely excellent support from the #libav IRC channel), and built a Linux chroot with all the tools needed to do the video encoding. So hopefully, the video encoding for future conferences should now be a much easier experience, allowing to post the videos in a more timely fashion.
Thomas Petazzoni |