Revision as of 10:04, 25 February 2014 by ThomasPetazzoni (talk | contribs) (Suggestions for candidates)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

2014 is the second year of participation of Buildroot to the Google Summer of Code program. This year, we are proposing the following ideas.


Improve support of multimedia features

Last year, thanks to the GSoC program, Spenser Gilliland improved the support in Buildroot for the multimedia features of a number of ARM processors. This year, we are proposing a topic that consists in continuing this effort by:

  • Extending it to more ARM platforms, and increase the number of supported features
  • Extending it to other architectures, especially x86 and x86-64

More and more embedded systems rely on processors and hardware platforms that provide advanced multimedia features, like OpenGL acceleration, OpenVG acceleration, accelerated video encoding or decoding features (either through dedicated hardware units or DSPs). For example, the OMAP processors from Texas Instruments (used on the BeagleBoard, PandaBoard and BeagleBone), the i.MX processor from Freescale, the BCM2835 from Broadcom (used on Rasberry Pi), or the vast majority of x86 and x86-64 platforms.

Using those multimedia features require specific libraries provided by the different processor vendors, and then such features must be enabled in higher-level components in the stack such as Qt, Gtk, Cairo, Wayland, and so on. They are usually not trivial to integrate, because the libraries provided by the processor vendors often use uncommon build systems, have bizarre dependencies and so on. However, getting the support for those libraries in Buildroot is very important so that Buildroot users can fully benefit from the multimedia features of their hardware.

This project idea is not about doing reverse engineering of multimedia hardware and implementing drivers. It is about creating Buildroot packages for the various multimedia libraries that already exists. We are primarily interested in packaging the official multimedia support provided by the hardware vendor (generally in the form of binary-only libraries), but it may also be interesting to package the open-source drivers available (generally implemented by reverse engineering) if any. Our goal is to make it easy for Buildroot users to enable the multimedia features of their hardware.

The Buildroot project will provide several hardware development boards to the student. The GSoC will then be approximately be split in the following steps, for each platform:

  • Get used to the platform (get a working kernel and minimal userspace)
  • Investigate the libraries provided by the processor vendor to use the multimedia features, and make experiments to get them working
  • Create proper Buildroot packages to allow other users to easily integrate those libraries in their embedded Linux systems.
  • Get some packages accepted upstream in the official Buildroot Git repository, by going through the traditional patch submission/review process.

Skills suggested/required:

  • Basic Embedded Linux knowledge (basics of cross-compilation, building/configuring a kernel, etc.)
  • Basic understanding of multimedia features (OpenGL, OpenVG, video acceleration)
  • A minimal knowledge of Buildroot is a plus.

Interested in participating? Please contact:

  • Thomas Petazzoni,, or kos_tom on #buildroot on Freenode.

Improve testing infrastructure

The Buildroot project uses automated build testing of random configurations to help validate that the millions of possible Buildroot configurations build correctly. This automated build testing has been running since about a year (results visibles at [1]) and have helped improved the quality of Buildroot. However, the project would like to bring a number of improvements to this testing infrastructure:

  • In addition to the existing testing of random configurations, do regression testing on a set of well-defined configurations. This would involve defining the configurations to be tested, design, implement and deploy the infrastructure to test those configurations. This infrastructure will have to be flexible enough to easily allow the addition of new configurations to be tested, so that the Buildroot community can progressively enrich the number of test cases.
  • Add runtime testing. For now, the automated testing is limited to checking that a given Buildroot configuration builds. We would like to add runtime testing, i.e really boot the generated system under Qemu, and verify, for the different packages that are part of the system, that they at least minimally work. For example, if the Python interpreter has been selected to be part of the system, verify that we can run it, and run a simple Python test application on the target. This involves creating an infrastructure to start Qemu, run tests inside Qemu, and integrate the tests in the Buildroot packages themselves.

Skills suggested/requires:

  • Basic Embedded Linux knowledge (cross-compilation, kernel configuration/build, etc.)
  • Knowledge of the Python scripting language, used for the development of the testing infrastructure.
  • Some Web development skills and/or knowledge of tools like Jenkins would be a plus.

Interested in participating? Please contact:

  • Thomas Petazzoni,, or kos_tom on #buildroot on Freenode.

Suggestions for candidates

If you want to apply, we recommend you to prove that you have some basic knowledge about Buildroot and open-source contributions:

  • Subscribe to the mailing list and come to the IRC channel
  • Post some patches to the mailing list. Here are some possible contribution ideas:
    • Look at some items in our TODO list at, implement some of them, and send patches
    • Find some software component that is useful on embedded systems, create a Buildroot package for it, and send patches
    • Find some embedded hardware platform, create a Buildroot defconfig for it, and send patches
    • Look at some build failures in our autobuilders at and send patches to fix them. Note that some build failures may be difficult to solve.
    • Look at the bug tracker at and send patches to fix them. Some patches may be difficult to look at.