In this series of articles, I want to consider the buildroot distribution system build system and share its customization experience. There will be practical experience in creating a small OS with a graphical interface and minimal functionality.
First of all, do not confuse the build system and distribution. Buildroot can build a system from a set of packages that have been offered. Buildroot is built on makefiles and therefore has great customization capabilities. Replace the package with another version, add your package, change the package building rules, customize the file system after installing all the packages? All this can buildroot.
In Russia, buildroot is used, but in my opinion there is little Russian-language information for beginners.
The purpose of the work is to build a distribution with live-download, icewm interface and browser. The target platform is virtualbox.
Why build your distribution? Often you need limited functionality with limited resources. More often in automation you need to create firmware. Adapting a general-purpose distribution kit, cleaning out extra packages and turning it into a firmware path is more laborious than building a new distribution kit. Using Gentoo also has its limitations.
Buildroot is a very powerful system, but it does nothing for you. It can only enable and automate the assembly process.
Alternative build systems (yocto, open build system and others) are not considered or compared.
Project site - buildroot.org . Here you can download the latest version and read the manual. You can also contact the community, there is a bugtracker, mail-lists and irc-channel.
Buildroot uses defconfig for target build boards. Defconfig is a configuration file that stores in itself only options that have no default values. It is he who determines what and how will be collected. In this case, you can separately configure the configs of busybox, linux-kernel, uClibc, boot loaders u-boot and barebox, but they will all be tied to the target board.
After unpacking the downloaded archive or cloning from git, we get a buildroot ready for work. Details on the directory structure can be found in the manual, tell you about the most important:
board - directory with files specific to each board. These can be scripts for forming system images (iso, sdcart, cpio, etc.), the overlay directory, the kernel config, etc.
configs is the board defconfig itself. Defconfig is an incomplete board configuration. Only parameters other than default settings are stored in it.
dl - directory with downloaded source codes / files to build
output / target - collected OS file system. Further images are created from it for download / installation.
output / host - host utilities for building
output / build - build packages
Build configuration is done via KConfig. The same system is used to build the linux kernel. The list of the most frequently used commands (run in the buildroot directory):
Buildroot does not reassemble the already assembled packages! Therefore, a situation may arise when a complete reassembly is required.
You can rebuild a separate package with the make packagename-rebuild command . For example, you can rebuild the linux kernel:
make linux-rebuild
Buildroot stores the state of any package by creating .stamp files in the output / build / $ packagename directory:
Therefore, you can rebuild root-fs and images without rebuilding the packages:
rm output/build/host-gcc-final-*/.stamp_host_installed;rm -rf output/target;find output/ -name ".stamp_target_installed" |xargs rm -rf ; make
Buildroot has a set of variables for easy configuration.
Buildroot has the ability to visualize. You can build a dependency diagram, build timeline, schedule of packages in the final system. The results are in the form of pdf files (there is a choice of svn, png) in the output / graph directory.
Examples of visualization commands:
make graph-depends
build dependency treemake <pkg>-graph-depends
to build a dependency tree for a specific packageBR2_GRAPH_OUT=png make graph-build
build timeline with output to PNGmake graph-size
build a packet size chartIn the buildroot directory there is a utils subdirectory with useful scripts. For example, there is a script that checks the correctness of the package description. This can be useful when adding your packages (I will do this later). In the file utils / readme.txt there is a description of these scripts.
It is important to remind that all operations are conducted on behalf of a regular user, not root.
All commands are executed in the root buildroot. The buildroot delivery already has a set of configurations for many common boards and virtualization.
See the list of configurations:
Switching to the qemu_x86_64_defconfig config
make qemu_x86_64_defconfig
And run the build
make
The build is completed successfully, we look at the results:
Buildroot has collected images that can be run in Qemu and make sure they work.
qemu-system-x86_64 -kernel output/images/bzImage -hda \ output/images/rootfs.ext2 -append "root=/dev/sda rw" -s -S
The result is a system running in qemu:
See the list of configurations:
In the list we see pc_x86_64_efi_defconfig. We will create our board by copying it from the configuration:
cp configs/pc_x86_64_bios_defconfig configs/my_x86_board_defconfig
Immediately create a board directory to store your scripts, rootfs-overlay and other necessary files:
mkdir board/my_x86_board
Switch to this defconfig:
make my_x86_board_defconfig
Thus, now the build configuration (stored in .config in the root directory of the buildroot) corresponds to the target x86-64 legacy (bios) machine by loading.
Copy the linux-kernel configuration (useful later):
cp board/pc/linux.config board/my_x86_board/
Run the setup:
make menuconfig
The KConfig window opens. It is possible to configure with a graphical interface (make nconfig, make xconfig, make gconfig):
We enter the first section Target Options. Here you can select the target architecture under which the assembly will be conducted.
Build options - there are various build options. You can specify directories with source codes, the number of build threads, mirrors for downloading source codes, and other settings. Leave the default settings.
Toolchain - here the assembly toolkit is configured. More about him.
Toolchain type - the type of toolchain used. This can be either built into the buildroot or an external toolchain (you can specify the directory with the already built or the url to download). For different architectures there are additional options. For example, for arm, you can simply select the version of Linaro external toolchain.
C library - choice of library C. The work of the whole system depends on it. Usually glibc is used, which supports all possible functionality. But it may be too big for the embedded system, so often choose uClibc or musl. We will select glibc (later this will be required to use systemd).
Kernel Headers and Custom Kernel Headers series - must match the version of the kernel that will be in the assembled system. For kernel headers, you can also specify the path to the tarball or git repository.
GCC COMPILER VERSIONS - select the compiler version that will be used to build
Enable C ++ support - choose to build with support for c ++ libraries in the system. In the future, it will be useful to us.
Additional gcc options - you can set additional compiler options. We needlessly for now.
System configuration allows you to set future parameters of the created system:
Most of the points are clear from the title. Pay attention to the following points:
Path to the users tables - a table with created users ( https://buildroot.org/downloads/manual/manual.html#makeuser-syntax ).
Sample file. A user will be created with the password admin, automatically gid / uid, / bin / sh shell, default user group, root group member, comment Foo user
[alexey@alexey-pc buildroot ]$ cat board/my_x86_board/users.txt user -1 user -1 =admin /home/user /bin/sh root Foo user
Root filesystem overlay directories is a directory overlaid on the compiled target-fs. Adds new files and replaces existing ones.
Custom scripts to run before creating filesystem images - Scripts executed just before the file system collapses into images. The script itself is left empty
Go to the Kernel section
Here are the kernel settings. The kernel itself is configured via make linux-menuconfig.
You can set the kernel version in different ways: choose from the suggested ones, enter the version manually, specify the repository or the finished tarball.
Kernel configuration - the path to the kernel configuration. You can choose the default configuration for the selected architecture or defocnfig from Linux. The Linux source has a set of defconfigs for different target systems. You can find the right one by looking directly at the source here . For example, you can select a config for the beagle bone black board.
The Target packages section allows you to choose which packages will be installed on the build system. For now, leave it unchanged. Later we will add our packages to this list.
Filesystem images - a list of filesystem images to be collected. Add an iso image
Bootloaders - the choice of collected loaders. Choose isolinix
Systemd becomes one of the linux posts, along with kernel and glibc. Therefore, I made its setting in a separate item.
It is configured via make menuconfig, then Target packages β System tools β systemd. Here you can specify which systemd services will be installed and started at system startup.
We save this config via KConfig.
Then save our defconfig:
make savedefconfig
Configuring the linux kernel is invoked with the following command:
make linux-menuconfig
Add support for Virtualbox
Add Virtualbox Guest integration support
Save and exit. IMPORTANT : the configuration will be saved in output / build / linux- $ version / config, but not in board / my_x86_board / linux.config
Therefore, you need to manually copy the config to the storage location:
cp output/build/linux-4.19.25/.config board/my_x86_board/linux.config
With this command, I copy the FULL kernel configuration, which is not always necessary. A better way is to save the kernel defconfig:
linux-update-defconfig
After that, we will perform a complete reassembly of the entire system. Since buildroot does not reassemble already assembled, then you must manually specify the packages for reassembly. In order not to waste time and nerves, itβs easier to rebuild a small system entirely):
make clean;make
When the build is completed, we start VirtualBox (tested on version 5.2 and 6.0) with booting from a cd-disk. System parameters:
Run from compiled iso:
Source: https://habr.com/ru/post/448638/
All Articles