Buildroot

Buildroot官方全英文使用手册的链接是https://buildroot.org/downloads/manual/manual.html

Chapter 1. About Buildroot

Buildroot is a tool that simplifies and automates the process of building a complete Linux system for an embedded system, using cross-compilation.

Buildroot is able to generate a cross-compilation toolchain, a root filesystem, a Linux kernel image and a bootloader for your target.

Chapter 3. Getting Buildroot

Buildroot releases are made every 3 months, in February, May, August and November. Release tarballs are available at http://buildroot.org/downloads/.

Chapter 4. Buildroot quick start

Important: you can and should build everything as a normal user. There is no need to be root to configure and use Buildroot.  The first step when using Buildroot is to create a configuration.  From the buildroot directory, run  $ make menuconfig Once everything is configured, the configuration tool generates a .config file that contains the entire configuration. This file will be read by the top-level Makefile. To start the build process, simply run: $ make The make command will generally perform the following steps: download source files (as required);configure, build and install the cross-compilation toolchain, or simply import an external toolchain;configure, build and 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/. This directory contains several subdirectories: images/ where all the images (kernel image, bootloader and root filesystem images) are stored. These are the files you need to put on your target system. build/ where all the components are built (this includes tools needed by Buildroot on the host and packages compiled for the target). This directory contains one subdirectory for each of these components. host/ contains the installation of tools compiled for the host that are needed for the proper execution of Buildroot, including the cross-compilation toolchain.

Chapter 6. Buildroot configuration

The  make *config  commands also offer a search tool. Read the help message in the different frontend menus to know how to use it: in menuconfig, the search tool is called by pressing /;

6.1. Cross-compilation toolchain

Buildroot provides two solutions for the cross-compilation toolchain:

The internal toolchain backend, called Buildroot toolchain in the configuration interface.The external toolchain backend, called External toolchain in the configuration interface.

6.1.1. Internal toolchain backend

The internal toolchain backend is the backend where Buildroot builds by itself a cross-compilation toolchain, before building the userspace applications and libraries for your target embedded system. Once you have selected this backend, a number of options appear. The most important ones allow to: Change the version of the Linux kernel headers used to build the toolchain. This item deserves a few explanations. In the process of building a cross-compilation toolchain, the C library is being built. This library provides the interface between userspace applications and the Linux kernel. In order to know how to "talk" to the Linux kernel, the C library needs to have access to the Linux kernel headers (i.e. the .h files from the kernel), which define the interface between userspace and the kernel (system calls, data structures, etc.). Since this interface is backward compatible, the version of the Linux kernel headers used to build your toolchain do not need to match exactly the version of the Linux kernel you intend to run on your embedded system. They only need to have a version equal or older to the version of the Linux kernel you intend to run. If you use kernel headers that are more recent than the Linux kernel you run on your embedded system, then the C library might be using interfaces that are not provided by your Linux kernel.Change the version of the GCC compiler, binutils and the C library.

6.1.2. External toolchain backend

The external toolchain backend allows to use existing pre-built cross-compilation toolchains.  Buildroot knows about a number of well-known cross-compilation toolchains Then, you have three solutions to use an external toolchain: Use a predefined external toolchain profile, and let Buildroot download, extract and install the toolchain. Use a predefined external toolchain profile, but instead of having Buildroot download and extract the toolchain, you can tell Buildroot where your toolchain is already installed on your system. Use a completely custom external toolchain. 

6.2. /dev management

n a Linux system, the /dev directory contains special files, called device files, that allow userspace applications to access the hardware devices managed by the Linux kernel.  Under System configuration, /dev management, Buildroot offers four different solutions to handle the /dev directory : The first solution is Static using device table. This is the old classical way of handling device files in Linux. With this method, the device files are persistently stored in the root filesystem (i.e. they persist across reboots), and there is nothing that will automatically create and remove those device files when hardware devices are added or removed from the system. Buildroot therefore creates a standard set of device files using a device table, the default one being stored in system/device_table_dev.txt in the Buildroot source code. This file is processed when Buildroot generates the final root filesystem image, and the device files are therefore not visible in the output/target directory. The second solution is Dynamic using devtmpfs only. devtmpfs is a virtual filesystem inside the Linux kernel that has been introduced in kernel 2.6.32 (if you use an older kernel, it is not possible to use this option). When mounted in /dev, this virtual filesystem will automatically make device files appear and disappear as hardware devices are added and removed from the system. This filesystem is not persistent across reboots: it is filled dynamically by the kernel. Using devtmpfs requires the following kernel configuration options to be enabled: CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT. When Buildroot is in charge of building the Linux kernel for your embedded device, it makes sure that those two options are enabled. However, if you build your Linux kernel outside of Buildroot, then it is your responsibility to enable those two options (if you fail to do so, your Buildroot system will not boot).The third solution is Dynamic using devtmpfs + mdev. This method also relies on the devtmpfs virtual filesystem detailed above (so the requirement to have CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT enabled in the kernel configuration still apply), but adds the mdev userspace utility on top of it. mdev is a program part of BusyBox that the kernel will call every time a device is added or removed. Thanks to the /etc/mdev.conf configuration file, mdev can be configured to for example, set specific permissions or ownership on a device file, call a script or application whenever a device appears or disappear, etc. Basically, it allows userspace to react on device addition and removal events. mdev can for example be used to automatically load kernel modules when devices appear on the system. mdev is also important if you have devices that require a firmware, as it will be responsible for pushing the firmware contents to the kernel. mdev is a lightweight implementation (with fewer features) of udev. For more details about mdev and the syntax of its configuration file, see http://git.busybox.net/busybox/tree/docs/mdev.txt.The fourth solution is Dynamic using devtmpfs + eudev. This method also relies on the devtmpfs virtual filesystem detailed above, but adds the eudev userspace daemon on top of it. eudev is a daemon that runs in the background, and gets called by the kernel when a device gets added or removed from the system. It is a more heavyweight solution than mdev, but provides higher flexibility. eudev is a standalone version of udev, the original userspace daemon used in most desktop Linux distributions, which is now part of Systemd. For more details, see http://en.wikipedia.org/wiki/Udev.

6.3. init system

The init program is the first userspace program started by the kernel (it carries the PID number 1), and is responsible for starting the userspace services and programs (for example: web server, graphical applications, other network servers, etc.). Buildroot allows to use three different types of init systems, which can be chosen from System configuration, Init system: The first solution is BusyBox. Amongst many programs, BusyBox has an implementation of a basic init program, which is sufficient for most embedded systems. Enabling the BR2_INIT_BUSYBOX will ensure BusyBox will build and install its init program. This is the default solution in Buildroot. The BusyBox init program will read the /etc/inittab file at boot to know what to do. The syntax of this file can be found in http://git.busybox.net/busybox/tree/examples/inittab (note that BusyBox inittab syntax is special: do not use a random inittab documentation from the Internet to learn about BusyBox inittab). The default inittab in Buildroot is stored in system/skeleton/etc/inittab. Apart from mounting a few important filesystems, the main job the default inittab does is to start the /etc/init.d/rcS shell script, and start a getty program (which provides a login prompt).The second solution is systemV. This solution uses the old traditional sysvinit program, packed in Buildroot in package/sysvinit. This was the solution used in most desktop Linux distributions, until they switched to more recent alternatives such as Upstart or Systemd. sysvinit also works with an inittab file (which has a slightly different syntax than the one from BusyBox). The default inittab installed with this init solution is located in package/sysvinit/inittab.The third solution is systemd. systemd is the new generation init system for Linux. It does far more than traditional init programs: aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, etc. systemd will be useful on relatively complex embedded systems, for example the ones requiring D-Bus and services communicating between each other. It is worth noting that systemdbrings a fairly big number of large dependencies: dbus, udev and more. For more details about systemd,

The solution recommended by Buildroot developers is to use the BusyBox init as it is sufficient for most embedded systems. systemd can be used for more complex situations.

Chapter 7. Configuration of other components

Before attempting to modify any of the components below, make sure you have already configured Buildroot itself, and have enabled the corresponding package.

BusyBox

If you already have a BusyBox configuration file, you can directly specify this file in the Buildroot configuration, using BR2_PACKAGE_BUSYBOX_CONFIG. Otherwise, Buildroot will start from a default BusyBox configuration file.

To make subsequent changes to the configuration, use make busybox-menuconfig to open the BusyBox configuration editor.

It is also possible to specify a BusyBox configuration file through an environment variable, although this is not recommended. Refer to Section 8.6, “Environment variables” for more details.

uClibc Configuration of uClibc is done in the same way as for BusyBox. The configuration variable to specify an existing configuration file is  BR2_UCLIBC_CONFIG. The command to make subsequent changes is  make uclibc-menuconfig. Linux kernel

If you already have a kernel configuration file, you can directly specify this file in the Buildroot configuration, using BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG.

If you do not yet have a kernel configuration file, you can either start by specifying a defconfig in the Buildroot configuration, using BR2_LINUX_KERNEL_USE_DEFCONFIG, or start by creating an empty file and specifying it as custom configuration file, using BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG.

To make subsequent changes to the configuration, use make linux-menuconfig to open the Linux configuration editor.

Barebox Configuration of Barebox is done in the same way as for the Linux kernel. The corresponding configuration variables are  BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG and BR2_TARGET_BAREBOX_USE_DEFCONFIG. To open the configuration editor, use  make barebox-menuconfig. U-Boot Configuration of U-Boot (version 2015.04 or newer) is done in the same way as for the Linux kernel. The corresponding configuration variables are  BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG and  BR2_TARGET_UBOOT_USE_DEFCONFIG. To open the configuration editor, use  make uboot-menuconfig.

Chapter 8. General Buildroot usage

8.1. make tips

Display all commands executed by make: $ make V=1 <target>

Display the list of boards with a defconfig: 

$ make list-defconfigs

Display all available targets: 

$ make help

Not all targets are always available, some settings in the .config file may hide some targets:

busybox-menuconfig only works when busybox is enabled;linux-menuconfig and linux-savedefconfig only work when linux is enabled;uclibc-menuconfig is only available when the uClibc C library is selected in the internal toolchain backend;barebox-menuconfig and barebox-savedefconfig only work when the barebox bootloader is enabled.uboot-menuconfig and uboot-savedefconfig only work when the U-Boot bootloader is enabled.

Cleaning: Explicit cleaning is required when any of the architecture or toolchain configuration options are changed.

To delete all build products (including build directories, host, staging and target trees, the images and the toolchain):

$ make clean

Generating the manual: The present manual sources are located in the docs/manual directory. To generate the manual:

$ make manual-clean $ make manual

The manual outputs will be generated in output/docs/manual.