Buildroot simplified for users!

Buildroot logoYesterday, a set of patches I’ve authored that aims at simplifying Buildroot for users has been merged into the official version of the project, and will therefore be part of the next stable release (scheduled for November, according to our 3 months release cycle). This work is probably my major contribution to Buildroot, outside of external toolchain support and various fixes here and there. Here are quick details about the improvements brought by these patches :

  • Remove the “project” feature. The project feature removal was the main point of this patch set. This feature, that allows to compile a system for different, but very similar platforms, without recompiling everything from scratch, was rarely used and introduced a lot of complexity in the usage of Buildroot for newcomers. Who hasn’t been confused by this project_build_arm directory? This thing is gone now.
  • Remove the BOARD/LOCAL feature, which duplicates another way of adding support for new targets in Buildroot. This is the kind of feature that has been added at the time Buildroot was basically unmaintained, when nobody was able to say « Hey, but you’re just trying to-reimplement something that already exists »
  • Move all output directories in an output directory. By default, when Buildroot is compiled, it generates several directories in the middle of its source code. Now, with this patch, everything is grouped into an output directory, unless out-of-tree compilation is used, of course (with O=)
  • Remove TOPDIR_PREFIX and TOPDIR_SUFFIX since the same effect could already be done using out-of-tree compilation with O=. Another duplicated feature that should never have reached the tree.
  • Rename the output directories. Now that everything is properly stored in an output directory, it was time to rename the subdirectories to make them more meaningful. So now, we have build where all packages are built, images that contains the final binary images of the root filesystem and the kernel, staging which contains the staging directory (all packages installed with their development headers and libraries), target that contains the root filesystem for the target (without the device files), host that contains the installation of the host tools that Buildroot requires for its execution, stamps that contains the stamp files used by Buildroot to keep track of the compilation progress. Therefore, all directories such as build_ARCH or toolchain_build_ARCH have disappeared.
  • Major documentation update, to of course make sure that our documentation is up-to-date with the latest changes.

Getting all these changes mainlined is really a nice thing. I also have tons of other ideas to improve Buildroot infrastructure, and I’m sure the coming Buildroot Developer Day will be a great opportunity to discuss these.

First Buildroot Developer Day after ELCE, on October 17th in Grenoble, France

Buildroot logoThe first Buildroot Developer Day will take place on Saturday, October 17th in Grenoble, France, just the day after Embedded Linux Conference Europe. This Developer Day aims at allowing Buildroot developers to meet and exchange ideas on the project and its future.

As the number of places is limited, interested candidates are invited to send an e-mail to Peter Korsgaard (jacmet at uclibc dot org) and Thomas Petazzoni (thomas dot petazzoni at free-electrons dot com).

Peter Korsgaard and I are organizing this Developer Day thanks to the sponsorship of Calao Systems (offering the location for the meeting) and Bootlin (offering free lunch to the participants).

See also the announcement of the mailing list and on Buildroot website.

Kernel and BSP development and mainlining

Offering free mainlining for Linux kernel, device driver and BSP development

Note: Due to the number of requests we get for mainlining work, we can no longer continue the offer described below.

Bootlin is best known worldwide for its kernel and embedded Linux system training sessions and its free training materials, and also perhaps for sharing videos from technical conferences.

However, did you know that Bootlin is not a training company?

We are actually embedded Linux system and kernel developers like the people we support, train and work for. This is essential to be good trainers, in addition to our passion for sharing what we learn. For example, have you ever had a look at the description of our engineering services?

In our training activity, we differentiate with other suppliers by offering custom sessions, being completely transparent with our training materials, costs and customer evaluations. Here’s how we can also make a difference in our development activity:

  • As in all our activities, by focusing only on the Linux kernel, device drivers, bootloaders, embedded and real-time system development.
  • By offering free mainlining to any customer who orders Linux board support packages or Linux device drivers from us. Having our code accepted in the official Linux and U-boot sources brings terrific benefits to our customers and can be a key contributor to the success of their products.
  • By working inside the Linux development community. Being part of it, we know this community very well: its people, its rules, its best practices and its best resources. This helps us to make the right decisions (if needed, collecting advice from the right people), and quickly obtain the expected results.