Creating a RootFS with Buildroot

1 Introduction

is a set of scripts and patches for the creation of a cross-compilation toolchain as well as the creation of a complete root file system. Buildroot provides:

• support for prebuilt or external toolchains
• configuration through menuconfig, gconfig and xconfig interfaces
• lots of available libraries, tools, packages and utilities
• support for all the major filesystems (JFFS2, UBIFS, CRAMFS, ...)
• uClibc, glibc, eglibc generation, or use of the libc from the external toolchain
• easy customization through Makefiles

1.1 References

• Buildroot project page:

• Buildroot User Manual:

• Buildroot on eLinux:

2 Starting up

2.1 Requirements

Buildroot needs some software to be already installed on the GNU/Linux host system. Please check:

Please make sure that at least the mandatory packages are installed before launching a build.

2.2 Getting Buildroot

Buildroot releases can be downloaded from

Daily Snapshots of the latest Buildroot source tree can be downloaded from

The source tree can be browsed online: and a copy of the repository can be grabbed with the following commands:

• git clone
• git clone (Use this if you're behind a firewall blocking git)

The following is the project directory tree:

.
├── arch
├── board
├── boot
├── CHANGES
├── Config.in
├── Config.in.legacy
├── configs
├── COPYING
├── docs
├── fs
├── linux
├── Makefile
├── Makefile.legacy
├── package
├── support
├── system
└── toolchain

3 Configuring Buildroot

For modifying the Buildroot configuration, enter the project directory and enter the following command:

make menuconfig

You can optionally use the O= parameter to set a specific build folder:

make O= menuconfig

Once everything is configured, the configuration tool generates a .config file that contains the description of the configuration. It will be used by the Makefiles to do what’s needed.

3.1 Setting up the target architecture

From the menuconfig interface, you need to select:

• Target Architecture -> Select "ARM (little endian)"
• Target Architecture Variant -> Select "cortex-A8"
• Target ABI -> Select "EABI"

3.2 Configure the build options

From the Build options menù you can define some custom directories for compilation output and file download. It is also recommended to enable the compiler cache and optionally set a custom directory.

3.3 Setting up the external toolchain

You need to set the path and prefix for the external toolchain:

• Toolchain -> Toolchain type -> Select "External Toolchain"
• Toolchain -> Toolchain -> Select "Custom Toolchain"
• Toolchain -> Toolchain origin-> Select "Pre-installed toolchain"
• Toolchain -> Toolchain path (eg. /home/shared/devel/dave/naon-DAA/sw/linux/sdk/arm-2009q1)
• Toolchain -> Toolchain prefix (eg. $(ARCH)-none-linux-gnueabi)
• Toolchain -> External toolchain C library -> Select glibc/eglibc
• Toolchain -> Activate RPC support
• Toolchain -> Activate C++ support

3.4 System configuration

Entering the "System configuration" option you should set:

• System hostname (NEW)
• System banner (NEW)
• Port to run a getty (login prompt) on -> Enter ttyO0
• () Custom script to run before creating filesystem images -> If required, you can run custom scripts to do board-specific cleanups, add-ons and the like, so the generated files can be used directly without further processing.

3.5 Package selection

The list of available packages can be accessed entering the Package selection for the target option

It's important that busybox provides the depmod command, which is not enabled by default. To enable it, you need to modify the buildroot/package/busybox/busybox-1.20.x.config file adding

CONFIG_DEPMOD=y
CONFIG_DEFAULT_DEPMOD_FILE="modules.dep"

4 Building the root file system

Once the configuration step is completed, launch

make O=

to start the build process (the "O=" parameter is optional), which will perform the following tasks:

• download source files (as required);
• configure, build and install the cross-compiling toolchain using the appropriate toolchain backend, or simply import an external toolchain;
• build/install selected target packages;
• build a kernel image, if selected;
• build a bootloader image, if selected;
• create a root filesystem in selected formats.

Buildroot output is stored in a single directory, output, and you'll find all the built images (kernel image, bootloader and root filesystem images) stored into the images subdirectory. In particular, the root file system is saved as a rootfs.tar file. This file can be decompressed to a NFS share and used to boot the target from the network for testing and further customization steps.

For more information, please refer to on the User Manual.

5 Adding platform specific components not provided with Buildroot

The targets usually provides specific features that relies on software components which can't be provided by the standard Buildroot project. Adding these components to the Buildroot root file system usually requires further operations, which depends on the particular target. The following sections provide instructions on how to perform these operations on DAVE's targets.

5.1 Adding Naon/Maya specific components

The following procedure allows adding the NELK components to the Buildroot root file system:

• modify the EZSDK_INSTALL_DIR/Rules.make file, making the EXEC_DIR variable point to the Buildroot root file system directory
• enter the EZSDK_INSTALL_DIR and launch the make all command to build the components
• from the EZSDK_INSTALL_DIR, launch the make install command

Unfortunately, the last command doesn't install all the components, so further operations are required. Assuming that:

• EXEC_DIR (Rules.make) points to the directory containg the buildroot RFS;
• $(EXEC_DIR).ori is the name of the original root file system provided with the NELK distribution;
• the busybox built with Buildroot and installed on the root file system supports the depmod command

you can easily add the following two targets to the EZSDK_INSTALL_DIR/Makefile:

load-firmware-buildroot-rfs_install:
    cp $(EXEC_DIR).ori/etc/init.d/load-hd-firmware.sh $(EXEC_DIR)/usr/share/ti/ti-media-controller-utils/buildroot_rfs_firmware.sh
    ln -s /usr/share/ti/ti-media-controller-utils/buildroot_rfs_firmware.sh $(EXEC_DIR)/etc/init.d/S70firm
    cp $(EXEC_DIR).ori/usr/share/ti/ti-media-controller-utils/mm_dm81xxbm.bin $(EXEC_DIR)/usr/share/ti/ti-media-controller-utils

load-firmware-buildroot-rfs_clean:
    rm -rf $(EXEC_DIR)/usr/share/ti/ti-media-controller-utils/buildroot_rfs_firmware.sh
    rm -rf $(EXEC_DIR)/etc/init.d/S70firm
    rm -rf $(EXEC_DIR)/usr/share/ti/ti-media-controller-utils/mm_dm81xxbm.bin

The first target completes the installation. The following is a brief description of the commands:

• The first command copies the original load-hd-firmware.sh script renaming it "buildroot_rfs_firmware.sh".
• The second command creates a symbolic link to the "buildroot_rfs_firmware.sh" file, so that init can launch that script at startup
• The third command copies the mm_dm81xxbm.bin (external memory mapping) binary file, required by the "buildroot_rfs_firmware.sh" file

The second target restores the previous situation.