Category: Technical

Increasing activity in the Buildroot community

In the recent times, the Buildroot project has seen a particular high level of activity, with a significant number of new contributors and contributions. It is an interesting opportunity to have a look at some statistics of the project activity in the last years: they show that the Buildroot project is really active, and in rapid development.

First, a look at the number of commits per month is an obvious way of looking at the activity of an open-source project. For two years, the project has seen each month at least 150 commits, and since for the last year, most of the months have seen between 300 and 400 commits.

Buildroot activity in commits

Another interesting data point is that this increasing number of commits is not only due to an increasing effort from the existing core developers, but rather due to an increasing number of contributors. The following graph, which displays the number of unique contributors having had patches merged each month, clearly shows that the Buildroot community is growing. From an average of 10-15 contributors per month a few years back, the project is now having between 30 and 40 unique contributors each month.

Number of Buildroot contributors

The mailing list activity also nicely reflects this increasing activity: it is now receiving almost each month between 1500 and 2000 e-mails, which means between 50 and 65 e-mails per day, and it starts to be difficult to read everything!

Number of Buildroot mailing list posts

Finally, the number of packages has also increased progressively over the last two years. As can be seen on the graph below, the period 2008 → 2011 hasn’t seen a big increase in the number of packages, as it was a period mainly focused on refactoring and cleanup work. After this cleanup work, it seems that Buildroot has started gaining in popularity, and more work was done to add more packages for various useful open-source components in embedded systems. Since 2011, the number of packages has been growing regularly, starting from less than 700 in 2011 to reach almost 1200 packages today.

Number of Buildroot packages

All in all, those four graphs clearly show a nice increase of activity within the Buildroot project, which is really cool!

Some notes on how the data was computed:

  • The number of commits per month was obtained by doing a git log --pretty=online --since=yyyy-mm-dd --until=yyyy-mm-dd | wc -l for each month.
  • The number of contributors was obtained by doing a git shortlog -sn --since=yyyy-mm-dd --until=yyyy-mm-dd | wc -l for each month.
  • The e-mail statistics were obtained by looking at the number of messages displayed in the HTML archives, per month, as in http://lists.busybox.net/pipermail/buildroot/2013-August/thread.html.
  • The number of packages was computed using an approximate method, that consists in counting the number of .mk files in Buildroot (a few .mk files are not packages, but the vast majority of them are). The exact command used was git checkout -q $(git rev-list -n 1 --before=2013-08-01 master) && find . -name '*.mk' | wc -l.

Crystalfontz boards support in Yocto

The Yocto 1.5 release is approaching and the Freescale layer trees are now frozen.
Bootlin added support for the various Crystalfontz boards to that release as you can check on the OpenEmbedded metadata index.

Yocto Project

First some preparative work has been done in the meta-fsl-arm layer in order to add the required features to generate an image able to boot on the Crystalfontz boards:

  • Support for a newer version of the Barebox mainline, 2013.08.0. As the previously supported version of Barebox was too old, it didn’t include support for the Crystalfontz boards. Also, some work has been done to make the recipe itself more generic so that custom layers can reuse it more easily.
  • Inclusion of the patches allowing the imx-bootlets to boot Barebox. The imx-bootlets were only able to boot U-Boot or the Linux kernel until now.
  • Creation of a new image type, using the imx-bootlets, then Barebox to boot the Linux kernel. All the boards based on a Freescale mxs SoC (i.mx23 and i.mx28) will benefit of this new image type. This is actually the difficult part where you lay out the compiled binaries (bootloaders, kernel and root filesystem) in the final file that is an SD card image ready to be flashed.

Then, the recipes for the Crystalfontz boards have been added to the meta-fsl-arm-extra layer:

  • First the bootloaders, imx-bootlets and Barebox, including the specific patches and configurations for the Crystalfontz boards.
  • Then the kernel. The linux-cfa recipe uses the 3.10 based kernel available on github.
  • The machine configurations themselves, selecting Barebox as the bootloader and the correct kernel recipe. Also, these are choosing to install the kernel in the root filesystem instead of in its own partition.
  • Touchscreen calibration for the cfa-10057 and the cfa-10058 boards. This is required to get xinput-calibrator working properly as it can’t calibrate without starting values.

In a nut shell, you can now use the following commands to get a working image for your particular Crystalfontz board:

  • For your convenience, Freescale is providing a repo manifest to retrieve all the necessary git repositories. So first download and install repo:
    mkdir ~/bin
    curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
    chmod a+x ~/bin/repo
    PATH=${PATH}:~/bin
  • We will work in a directory named fsl-community-bsp:
    mkdir fsl-community-bsp
    cd fsl-community-bsp
  • Ask repo to get the master branch, when Yocto 1.5 is released, you could select the new branch. (Edit: starting from September, 28th, you can use the branch named dora)
    repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master
  • Download the layers:
    repo sync
  • Configure the build for cfa-10036:
    MACHINE=cfa10036 source ./setup-environment build
  • Start the build with:
    bitbake core-image-minimal
  • Grab a cup of coffee!

You’ll end up with an image that you can flash using the following command:
sudo dd if=tmp/deploy/images/cfa10036/core-image-minimal-cfa10036.sdcard of=/dev/mmcblk0

Obviously, you need to replace cfa10036 by the board model you are using in the above commands. While not completely perfect, core-image-sato is also working.

In detail, the contributions from Bootlin are:

Embedded Linux and kernel engineer job openings

Bootlin team

We’re getting busier than ever! Bootlin is looking for developers:

  • With experience developing embedded Linux systems
  • With experience developing device drivers for the Linux kernel, and porting Linux on new hardware. See our contributions to the mainline Linux kernel!
  • With technical writing skills and an interest for training

We need to fill at least 2 open positions in the next months, and more will follow in 2014.

Newly graduated engineers are welcome too, provided they already have experience in the above technical fields or with Free Software development.

This time, we are looking for people who will be able to join one of our offices in France (Toulouse or Avignon), to strengthen our engineering teams there.

  • Toulouse is a dynamic city with lots of high-tech and embedded systems companies in particular. Our office in Colomiers can easily be reached by train from downtown Toulouse if you wish to settle there. You would be working with Maxime Ripard and our CTO Thomas Petazzoni.
  • Our main office is settled in Orange in the heart of the Provence region, close to Avignon, a smaller but dynamic city too. It enjoys a sunny climate and the proximity of the Alps and the Mediterranean sea. Accommodation is very affordable and there are no traffic issues! You would be working with our founder Michael Opdenacker and of course remotely with the rest of the engineering team. In particular, we are interested in foreign engineers who could help us develop our services in their home countries.

If you are unable to relocate this time, don’t hesitate to contact us anyway. Depending on your profile and experience, we are still planning to open home based jobs in a few months or years from now.

If you are interested in these positions, here are nice opportunities to meet us in the next weeks:

See a full description and details about how to contact us.

Bootlin at the ARM Kernel Summit, the Embedded Linux Conference and the Buildroot Developers Meeting

Late october will be a busy moment for all the embedded Linux developers meeting in Edinburgh, UK. The Linux Foundation is organizing a number of conferences here, including the Embedded Linux Conference Europe (October 24-25) and LinuxCon Europe (October 21-23), and many co-located other events.

Bootlin will be present at several of these events:

  • First, three Bootlin engineers will be present at the ARM kernel summit on October 22nd and 23rd. The ARM kernel summit is an invitation-only conference, organized in relation with the Linux Kernel Summit. Gregory Clement, Maxime Ripard and Thomas Petazzoni, engineers at Bootlin have been invited due to their participation to the ARM support in the kernel, mainly on Allwinner SOCs for Maxime and on Marvell SOCs for Gregory and Thomas. Being present at this event is an excellent opportunity to be part of the discussion that shapes the future of ARM support in Linux, and strengthen our relations with other members of this growing community.
  • Then, the entire technical team of Bootlin will attend the Embedded Linux Conference, on October 24th and 25th. Several talks will also be given by Bootlin engineers:
    • On Thursday, 24th October at 11:40 AM, Thomas Petazzoni will give a talk titled Device Tree for dummies!, which will give an introduction to the Device Tree on ARM: what it is, how it is compiled, how it used by the kernel, how Device Tree bindings are defined, how drivers are affected by the Device Tree, etc.
    • At the same time in another room, Michael Opdenacker will lead a Bird of a Feather session dedicated to Small Businesses in the embedded Linux world. Exchanging experiences, networking with other companies working in the same field, etc.
    • Still on Thursday, at 3 PM, Gregory Clement will give a talk on the Linux kernel Common Clock Framework, which will be an updated version of the talk he gave at ELC earlier this year.
    • On Friday, 25th October at 9:30 AM, Thomas Petazzoni will be part of the keynote panel session dedicated to a discussion on Embedded Linux build systems together with Tim Bird (Sony Mobile), Ross Burton (Intel), and Karim Yaghmour (Opersys), the panel being moderated by Jeff Osier-Mixon (Intel).
  • On Saturday 26th and Sunday 27th October, the Buildroot community is organizing its traditional Developers Meeting, to which Thomas Petazzoni will participate. Some of the core Buildroot developers will join for two days of discussion and work to improve this embedded Linux build system.

As you can see, this will be a very interesting and busy week, and we’re all looking forward to meeting more embedded Linux developers and learning about the latest technologies in this field.

Buildroot 2013.08 released, new features and contributions from Bootlin

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

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

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

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

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

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

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

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

Bootlin the top #18 contributor to the 3.11 kernel

The 3.11 Linux kernel has now been released by Linus Torvalds, and as usual as thousands of patches coming from a large number of companies and contributors. For this release, Bootlin has contributed a total of 128 patches (yes, exactly 2^7), which makes Bootlin the 18th contributor in the list of companies contributing to the kernel, according to http://www.remword.com/kps_result/3.11_whole.html, before Broadcom and Cisco, and after ARM and Oracle. It is also the first time that six different engineers from Bootlin contribute code to the Linux kernel in a single release!

As usual, most of our contributions were centered around support for the Marvell Armada 370 and XP SOCs, the Allwinner SOCs and the Crystalfontz i.MX28 platforms:

  • Added support for the PCIe controllers of the Armada 370 and Armada XP platforms, and used it for the already supported Kirkwood platform. Supporting PCIe has been a very long process, which got started in December 2012, required long discussions with various kernel maintainers and multiple iterations of the patch series. Armada 370/XP was the first ARM platform to add Device Tree based PCIe support, and therefore this required many discussions to sort out the Device Tree bindings for PCIe controllers. This work was done by Thomas Petazzoni.
  • Enable an additional USB interface on the OpenBlocks AX3 platform, which is available as part of the mini-PCIe connector inside the device. This work was done by Thomas Petazzoni.
  • Cleaned up all the Kirkwood platform Device Tree files to assign the pin muxing configurations to the appropriate devices. This work was done by Thomas Petazzoni.
  • Made various cleanups and improvements in the Armada 370/XP platform code (in arch/arm/mach-mvebu) to make it possible to support different base address for the internal registers depending on the board being used. Many hardcoded physical addresses were removed, as well as the static virtual to physical mapping. This work was done by Thomas Petazzoni.
  • Cleaned up many ARM platforms to remove their unneeded ->init_irq() callback, and also the ->map_io() callback which we changed to default to calling debug_ll_io_init() when not provided. This work was done by Maxime Ripard.
  • Extended the ssd1307fb driver that we contributed a few releases ago to also support the SSD1306 device. The SSD1306 and SSD1307 are OLED screens controlled over I2C that are used on Crystalfontz i.MX28 platforms. We also optimized significantly the communication with the SSD130x devices. This work was done by Maxime Ripard.
  • Added an Ethernet driver for the Allwinner SOCs. The work was initially done by Stefan Roese, and our engineer Maxime Ripard did all the final cleanup, development of an MDIO driver, and integration with all the Device Tree files of the Allwinner platforms.
  • Added support for the Allwinner I2C controller, by re-using and extending the existing i2c-mv64xxx driver used on Marvell platforms, since the hardware block was very similar. The Allwinner Device Tree files were also updated to add the I2C controllers. This work was done by Maxime Ripard.
  • Added basic support for the Allwinner A10s SOC: pin muxing information and Device Tree information. This work was done by Maxime Ripard.
  • Added support for the Olimex A10s-Olinuxino-micro, a new hardware platform manufactured by Olimex that uses the Allwinner A10s SOC. This work was done by Maxime Ripard.
  • Implemented a “Device Bus” driver for the Marvell SOCs, that allows to configure the access to NOR flash and other devices connected to the memory bus. It has been used to enabled NOR support on the Armada XP DB development platform. This work was done by Ezequiel Garcia.
  • Fixed a few bugs in the IIO subsystem, and a build failure on AT91 platform when CONFIG_PHYLIB was not enabled. This work was done by Alexandre Belloni.
  • Fixed the ARM low-level code that handles compatibility with ATAG bootloaders, to properly convert 32 bits memory sizes passed by the bootloader into 64 bits cells of the Device Tree, when LPAE is used. This work was done by Gregory Clement.
  • Michael Opdenacker made a few improvements and fixes to the documentation.

For the upcoming 3.12, we already have 131 patches lined up, and a few more will probably show up after this blog post is written. Over the last release cycles, Bootlin has become a regular contributor to ARM support in the Linux kernel, and we’re looking forward to doing more contributions in the future.

The details of our 3.11 contributions is:

Bootlin at Kernel Recipes, September 2013, Paris

Kernel Recipes conference logoFor the second year, a company called Hupstream, located in Paris, is organizing in France a conference fully dedicated to kernel development: Kernel Recipes (French), on September 24th and 25th.

While we at Bootlin couldn’t participate to last year edition, it looked like a very interesting conference, with both useful talks and an audience grouping a significant number of kernel developers and companies interested in kernel development in France. So this year, we are very happy to participate to this conference:

We are definitely looking forward to meeting some of the French kernel developers we have been in contact with over the last months (see the list of participants). It is also worth mentioning that Bootlin has an open position for a kernel or embedded Linux engineer, and that this conference is a great opportunity to meet us!

Bootlin at Linux Plumbers 2013, September 2013, New Orleans

Linux Plumbers conference logoThe Linux Plumbers conference has been running since quite a few years now, and has established itself as an important event for the Linux community that takes care of the low-level aspects of the Linux system: the kernel of course, but also the related userspace low-level components. It was originally the primary goal of this conference: get the userspace developers of the low-level components and the kernel developers to meet together. Nowadays, Linux Plumbers is organized as both a set of regular talks and a set of half-day mini-conferences.

The 2013 edition will be held from September 18th to September 20th in New Orleans, United States, and will cover a wide range of topics: ACPI, power management, PCI, Android, Graphics, Automotive, Boot and Core OS, File and Storage systems, LLVM, Network virtualization, Scaling, Secure Boot, Virtualization and more.

As part of Bootlin strong engagement in the community, and continuous effort to ensure its engineers are up-to-date with the latest Linux developments, our engineer Maxime Ripard will attend this conference. For those attending the conference, do not hesitate to meet Maxime, who has an interesting Android experience to share thanks to the Android training course he created at Bootlin, as well has a nice ARM kernel development experience as the maintainer of the Linux kernel support for the Allwinner ARM processors.

Contributions to Barebox: initial Marvell SoC support

Barebox is a bootloader that strives to be a modern alternative to U-Boot. It currently supports ARM, Blackfin, MIPS, NIOS2, OpenRISC, PowerPC and x86 as CPU architectures, and while it doesn’t have as much hardware support as U-Boot yet, it does have a number of very significant advantages over U-Boot: a proper device model very similar to the one used in the Linux kernel, which makes the code very clean and nice, and a configuration system that uses kconfig, like the Linux kernel, which is a lot better than the per-board header files used by U-Boot with lots of cryptic macros.

Bootlin had already contributed to Barebox in the past, as our engineer Maxime Ripard added the support for the Crystalfontz i.MX28 boards.

More recently, we contributed basic support for the Marvell Kirkwood, Marvell Armada 370 and Marvell Armada XP ARM processors. This work was released as part of the 2013.07.0 release. For now, the support is fairly minimal, as it only allows to boot a Barebox bootloader that has serial port support. The most important part of the work was to write a kwbimage tool (see kwbimage.c), which allows to generate bootable images for Marvell processors. Our work contained minimal support for the Armada XP-based OpenBlocks AX3 board, the Armada XP-based GP development board, the Armada 370-based Mirabox from Globalscale and the Kirkwood-based Guruplug from Globalscale. Our work was quickly extended by Sebastian Hesselbarth, who added basic support for the Marvell Dove processor, and the Cubox platform from SolidRun, which uses the Dove processor.

Of course, such support is far from being complete, we are hoping in the future to add support for network, NAND and SD, in order to make Barebox really useful and usable on Marvell platforms.

The details of our contributions are:

Starting Linux directly from AT91bootstrap3

Here is an update for our previous article on booting linux directly from AT91bootstrap. On newer ATMEL platforms, you will have to use AT91bootstrap 3. It now has a convenient way to be configured to boot directly to Linux.

You can check it out from github:

git clone git://github.com/linux4sam/at91bootstrap.git

That version of AT91bootstrap is using the same configuration mechanism as the Linux kernel. You will find default configurations, named in the form:
<board_name><storage>_<boot_strategy>_defconfig

  • board_name can be: at91sam9260ek, at91sam9261ek, at91sam9263ek, at91sam9g10ek, at91sam9g20ek, at91sam9m10g45ek, at91sam9n12ek, at91sam9rlek, at91sam9x5ek, at91sam9xeek or at91sama5d3xek
  • storage can be:
    • df for DataFlash
    • nf for NAND flash
    • sd for SD card
  • our main interest will be in boot_strategy which can be:
    • uboot: start u-boot or any other bootloader
    • linux: boot Linux directly, passing a kernel command line
    • linux_dt: boot Linux directly, using a Device Tree
    • android: boot Linux directly, in an Android configuration

Let’s take for example the latest evaluation boards from ATMEL, the SAMA5D3x-EK. If you are booting from NAND flash:

make at91sama5d3xeknf_linux_dt_defconfig
make

You’ll end up with a file named at91sama5d3xek-nandflashboot-linux-dt-3.5.4.bin in the binaries/ folder. This is your first stage bootloader. It has the same storage layout as used in the u-boot strategy so you can flash it and it will work.

As a last note, I’ll had that less is not always faster. On our benchmarks, booting the SAMA5D31-EK using AT91bootstrap, then Barebox was faster than just using AT91bootstrap. The main reason is that barebox is actually enabling the caches and decompresses the kernel(see below, the kernel is also enaling the caches before decompressing itself) before booting.