Buildroot - Linux Embedded systems

Build root is a project that helps you create root file systems and toolchains that use uClibc and BusyBox, a small C Library, and basic set of root file system tools. Buildroot grew out of the BusyBox and uClibc projects, two of the most commonly used pieces of software for embedded projects. Because this tool integrated both of these projects, it serves as a great starting point for creating a Linux distribution for a project.

Like LTIB, Buildroot uses an interface that’s similar the tool used to configure the kernel. Although this is comforting for a system-level engineer, the tool can be confusing if you’re a new engineer. The primary problem with this tool is that you have to keep track of where you are; after you use the software for a few minutes, nearly every page looks the same, and picking the correct options becomes tedious.

Build root configures an entire development environment kernel, root file system, and toolchain which means you need to configure the options for these complex projects before starting a build. There are literally hundreds of options to configure, and the sheer number of items makes the process mildly tedious. For some boards, default configuration files configure the build with the right settings.

Unfortunately, there aren’t many of these default configuration files, so the chances of one matching the board you’re using are fairly low.

Build root uses tar files as its package system and uses a collection of make files to configure the software before building. This implementation is easy to understand if you’ve used make in the past for moderately complex projects. Each package has a .mk file containing the make rules necessary to download, configure, build, and clean the package and a Config.in that is used by the configuration tool.

After you select the configuration options, you invoke make, and the build process starts running.

Using Buildroot

After the file is uncompressed, change directories, and run the configuration program:

The top-level Buildroot menu, which looks similar to LTIB

It’s worth pointing out that the configuration tool supports rudimentary searching: press the / key, and a search dialog appears. The dialog asks for a CONFIG_ symbol, but it searches for both the CONFIG_ symbol and the corresponding prompt text that appears in the dialog. If you’re new to this configuration program, the output is a series of lines defining the value of variables, all of which start with CONFIG_. If you’re familiar with the content and structure of the output file, you know the config var to be changed. But if you’re just get starting, the search on the prompt string is more useful.

It’s worth pointing out that the configuration tool supports rudimentary searching: press the / key, and a search dialog appears. The dialog asks for a CONFIG_ symbol, but it searches for both the CONFIG_ symbol and the corresponding prompt text that appears in the dialog. If you’re new to this configuration program, the output is a series of lines defining the value of variables, all of which start with CONFIG_. If you’re familiar with the content and structure of the output file, you know the config var to be changed. But if you’re just get starting, the search on the prompt string is more useful.

The search dialog

The output of the search is a list of the items that match. Unfortunately, it’s just a list you can’t go to one of the items in the list. The best way to use the output is to scan the list for potential matches and record the location of the desired items on a scratch pad, unless your memory is good enough to recall the menu paths of the interesting items.

The easiest way to quickly start a build is to use one of the default configurations stored under the./target/device directory. To get a quick listing of the configurations, do the following:

There are several default configurations under this directory for a variety of boards. Try using a basic ARM processor configuration to test things:

# make at91sam9261ek_defconfig

Several hundred lines scroll by in the terminal window as the configuration program reports what is being set as a result of using this configuration file. You may be prompted to press Enter a few times to accept the default options. All that output offers reassurance that the system is busily working to configure the project as requested. Next, kick off the make process:
$make The build now runs. This process takes a while as the software downloads what’s necessary for the build and starts the compilation process. At the end, the system will have built a kernel, a root file system, and a tool chain. Table below lists the locations of the key files and directories. These examples are specific to the choices used to create the configuration in the example; following each is an example with some place holders so you can see how the files would look for your configuration. Curious about the contents of the root file system created by the build? You can mount the root file system image via a loopback: # mkdir –p /mnt/arm-rfs # mount –t ext2 –o loop rootfs.arm-20090310.ext2 /mnt/arm-rfs Listing this directory shows what appears to be a regular root file system. Check that the files are appropriate for the ARM processor by doing the following: # file /mnt/arm-rfs/lib/libc.so.0 /mnt/arm-rfs/lib/libc.so.0: symbolic link to `libuClibc-0.9.30.so' # file /mnt/arm-rfs/lib/libuClibc-0.9.30.so /mnt/arm-rfs/lib/libuClibc-0.9.30.so: ELF 32-bit LSB shared object, ARM, version 1, stripped # file /mnt/arm-rfs/bin/busybox /mnt/arm-rfs/bin/busybox: setuid ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), stripped To run the toolchain, change directories into the ./build_arm/staging_dir/usr/bin folder, and get a directory listing to see what files have been built. The files follow one of two patterns: • arm-linux-*: These are the tools that use the glibc libraries. • arm-linux-uclibc-*: These tools use the uClibc libraries. In practice, the only difference between these files is that they use different C libraries when linking. To use one of these compilers in a project, you can add this directory to the path or copy the parent directory build_arm/staging_dir/usr to another location. Build root Tricks Build root has the concept of a project that contains all the settings necessary to build the packages into a distribution. After you go through the effort of configuring the kernel and root file system exactly as desired, you can save this information so that you can check it into a version control system or send it to a customer or another party to reproduce the output. To save the state of the project, use the following command from the Build root directory:$ make save config

This creates a local/<project name> directory containing the configuration files.

Build root downloads files when necessary as part of the build process. Some users, due to security restrictions or rules regarding how software is built, can’t download from the Internet during the build process. Build root offers a target that results in the packages necessary for the build being downloaded to the local cache of packages:

\$ make source

After this command runs, the ./dl directory is populated with all the packages necessary for the build process.

Getting Help

Build root, like most embedded projects, conducts support through a mailing list. The mailing list is active, with postings daily, and has a mix of newbie and superuser messages, so there’s no need to be shy about asking a question (or lending a hand). The same documentation is in the docs directory in the project, if connecting to the Internet is difficult.