Using BusyBox to make a root file system

1, BusyBox Introduction

BusyBox is a single executable implementation of many standard Linux tools. BusyBox contains a few simple tools, such as Cat and Echo, and includes some larger, more complex tools such as grep, find, Mount, and Telnet, and some people call BusyBox the "Swiss Army Knife" in the Linux tool.

BusyBox uncovered the fact that many standard Linux tools can share many common elements. For example, many file-based tools, such as grep and find, need to search the directory for a file's code. When these tools are incorporated into an executable program, they can share these same elements, which can result in smaller executable programs. In fact, BusyBox can wrap approximately 3.5MB of tools into approximately 200KB sizes. This provides more functionality for bootable disks and embedded devices that use Linux. We can use BusyBox for the 2.4 and 2.6 versions of the Linux kernel.

The Linux commands we normally use are like discrete electronic components, and busybox is like an integrated circuit that compresses common tools and commands into an executable file, which is basically the same, and the size is much smaller, and in embedded Linux applications, BusyBox has a very wide range of applications.

2, the use of BusyBox

You can use busybox like this.

#busybox ls

His function would quite run the LS command

The most common use is to establish links to BusyBox, with different link names to accomplish different functions.

#ln-S BusyBox ls

#ln-S BusyBox RM

#ln-S BusyBox mkdir

Then run each of these three links:

#./ls

#./rm

#./mkdir

The functions of the LS, RM, and MKDIR commands can be completed separately. Although they all point to the same executable program BusyBox, but as long as the link name is different, the completion of the function is different, busybox is so magical.

3. Configuring compilation BusyBox

? Download

First you need to download the BusyBox source code. The latest version of BusyBox can be downloaded directly from Http://busybox.net. For example the current latest version is 1.5.1.

? Extract:

Tar xvf busybox-1.5.1.tar.bz2

? Configuration

The BusyBox configuration program and Linux kernel menu configuration are virtually identical and easy to use. You can configure it using the Make Menuconfig command.

There are a few things to change in the configuration process:

I need to compile the busybox with the cross compiler ARM-LINUX-GCC because we are going to busybox cross-compiling the arm executable to execute on the board. So you need to modify the makefile in the BusyBox root directory to find

ARCH = $ (subarch)

Cross-compile? =

Modify the configuration to arm as follows:

Arm? = Arm

Cross-compile? = arm-linux-

L Modify several configurations in the BusyBox configuration interface:

Busybox Settings--->

Build Options

Build BusyBox as a static binary (no shared libs)

This option must be selected so that the BusyBox can be compiled into a statically linked executable that is independent of the other libraries, otherwise the library file must be run.

Busybox Settings--->

Installation Options

Don ' t use/usr

This option is also to be selected, otherwise make install after BusyBox will be installed in the original system/USR, which will overwrite the system's original command. When this option is selected, make install will generate a directory called _install in the BusyBox directory with BusyBox and links to him.

Init Utilities--->

Init

This option is best chosen so that BusyBox can initialize the script inittab, which can be used to initialize the Linux system.

If you want BusyBox to include a shell that can be used to interpret Linux commands, you need to configure the contents of the busybox shells option:

Shells--->

There are a variety of shell options available here, including Ash,hush,lash,msh. It is best to use ash because it is the most functional and most similar to bash in a general Linux system. Also note the first line:

Choose your default shell (none)--->

You need to go in here. Select the default shell, for example, when you select Ash, the contents of the first line become:

Choose your default shell (ASH)--->

This busybox generates a link to SH and points the sh to the corresponding shell (ASH).

Other options are some Linux basic command options, you can choose the configuration according to your needs, the first time with the default settings.

? Compile

If you have configured BusyBox, you can use the make command to compile.

#make

#make Install

By default, when make is completed, a new local subdirectory, _install, is created under the BusyBox directory, which contains the basic Linux environment. In this directory, there will be a LINUXRC program linked to the BusyBox. This LINUXRC program is useful when building an installation disk or an emergency disk (allowing for a modular boot in advance). Also in this directory, there is a/sbin subdirectory that contains the operating system binaries. There is also a/bin directory that contains user binaries. This _install directory can be migrated to the root of the target environment when building a floppy disk release or an embedded initial RAM disk.

4, make the complete root file system

BusyBox Although we have created the most basic shell and some common commands for the Linux root system, a root filesystem contains not just these, but also some other content.

? Create a more complete root file system directory structure

The first section of this chapter has described some of the directories in the root file system that are required for Linux to function properly. We can create a complete root file system directory on the basis of BusyBox _install, the following general steps:

• Create a directory on the PC for the target root filesystem, such as/rootfs, to copy all the contents of the _install directory in BusyBox into this folder: Cp–r _install/rootfs

L Create the Directory etc/,dev/,lib/,tmp/,usr/,var/directory under/rootfs, while the var/directory also needs to create directories such as Var/run and Var/log.

L Generate device files in etc/, such as TTY,CONSOLE,FB (FrameBuffer), Mtdblock (Memory technology Device), etc., which are the basis of many Linux drivers and the normal work of using the program. These device files are related to the corresponding hardware, mainly contain several kinds of information: device type, main device number, secondary device number.

The device type mainly includes character devices (Character device) and block devices (block device), character device main characters input such as keyboard, mouse, etc., block device mainly refers to the whole block of data input, such as flash, hard disk and other storage devices, The buffer mechanism is generally included.

The main device number is used to distinguish between different kinds of devices, while the secondary device number is used to differentiate multiple devices of the same type. For common devices, Linux has a conventional number, such as the main device number of the hard disk is 3, and the secondary device corresponds to each specific device, generally in the/proc/devices file can find relevant information.

For an existing device file, you can obtain information about its device through the ls–l command.

Ls–l/dev/console

CRW-RW----1 root root 5,1 Apr 23:08/dev/console

You can see that the first letter is C, which means that/dev/console is a character device, and if the first letter is B, it is a block device. and Root after the 5,1 is the corresponding device's primary and secondary equipment number.

It needs to be stressed here that the device files are similar to configuration files, which store some device information, which does not contain instructions under a specific platform, so the device files themselves are platform-independent, that is, the device files created on I386 can be placed on arm's root filesystem and can be correctly identified by Linux.

After you have a basic understanding of the device, you also need to create them, and you can typically use Mknod to generate the appropriate device files. Mknod is the command used in Linux to create device files, in the following format:

Mknode [–m MODE] NAME TYPE [MAJOR MINOR]

Where mode is used to specify access permissions for the device files. Name is the file name of the device file, type is the corresponding device types (character device C, block device B, etc.), major and minor are the primary and secondary device numbers respectively.

For example, to create the console command that you just made, use the following command:

MKNODE–M 660 console C 5 1

Device file creation In addition to using the Mknod command, you can also use the Makedev command, Makedev can be more convenient to create a system of device files, the general Linux distribution has its own, the basic format is as follows:

Makedev–d directory-m maxdevices Device

Where directory is the target folder for the device files, or/dev under the current system if not specified. Maxdevices for the largest number of devices, because Makedev generally create a device of a series of device files, generally starting from 0 numbering, until maxdevices, so generally this need to specify, to not generate more related equipment files, and generally we do not need so much. The last parameter device is the corresponding file name, including Tty,vt,mem,null,zero,fd,hd,audio,sound. The details of these parameters, as well as more parameter options, can be consulted in the man manual.

You can create a device file for hard disk HD

Makedev–d/rootfs/dev-m 2 HDA

This command creates the HDA and hda1 two device files in the/rootfs/dev directory, pointing to the first partition of the first hard disk and first hard disk.

For device files in the target root file system, it should generally be placed in the etc/directory, which can be used to obtain the appropriate device files in the following ways:

ü You can manually use the Mknod command to create a device file;

u can use Makedev to create device files;

ü You can even copy some of the device files from the PC system to the target root file system directly.

L BUILD the lib/directory. lib/directory is the Linux application required for the library files, in fact, is also the target platform instruction code, so here the file and etc/, must correspond with the corresponding hardware platform, for example, i386 library files placed in the arm system can not be used, This is the same as the Linux executable file. Using the Ls/lib command on a PC, you can see a lot of. So end-of-Library files, these. So files are Linux dynamic link libraries (similar to DLL files under Windows). Note that the. So filename suffix may also be added with some version number flags such as. so.1,.so.1.2 and so on are dynamic link libraries.

ü Where does the library file from the target root file system come from?

Generally these libraries are pre-compiled, and compiler-related (glibc, etc.), for example, we use ARM-LINUX-GCC to compile requires the corresponding version of some library files, these library files can be copied directly from the directory where the compiler resides. For the ELDK development package, you can copy the corresponding files from the arm/lib/directory in the ELDK directory.

What basic library files do you need for the target root file system?

Library files are actually called by other executables, so the trade-offs of library files are determined by the executables contained in the root file system. However, in order to run the executable file, there are usually a few that are required by the system. They are LD (ld-linux), libc, and almost all executables need to be called to both library files.

LD (Ld-linux): ld-linux.so is actually an executable program. This is the code responsible for performing the dynamic loading. It reads the header information (elf format) from the executable program and then uses that information to determine the necessary libraries and the libraries that need to be loaded. After that, the dynamic link is executed to modify all the address pointers in the executable program and the loaded library, enabling the program to run. The generic file name may be ld-2.3.2.so,ld-linux.so.2, which is related to the compiler and the system version.

Libc:libc.so.6 is a ld-linux.so.2-based dynamic link library that is almost responsible for all common standard C function libraries, such as the Socket program written under Linux, where Connect (), bind (), Send () ..... Functions such as these are provided by libc.so.6.

So one of the most basic lib/directories should contain at least the two files of this ld-linux.so.2 and libc.so.6.

What library files does the application need?

As mentioned earlier, the dynamic link library is called by an application (executable file), and how does it determine which library files it needs for a particular executable file? It is generally possible to view the compiler's LDD command, such as ARM-LINUX-GCC contains the dynamic-link library that the ARM-LINUX-LDD command uses to view arm executable calls. Arm-linux-ldd's function is to list the executable files and the library files that are required for the dynamic link library to run, for example, to find out the dynamic link libraries that are needed for the libc.so.6 you just referred to. Here we assume the libc in ELDK.

# file/eldk/arm/libc.so.6

Libc.so.6:symbolic link to ' libc-2.3.5.so '

The file command shows that the libc.so.6 is actually a symbolic connection, linked to libc-2.3.5.so, so we continue to trace libc-2.3.5.so:

#file libc-2.3.5.so

Libc-2.3.5.so:elf 32-bit LSB Shared object, ARM, version 1 (arm), stripped

It is obvious from here that this is arm's shared Object, which is the dynamic link library in arm format. Here you can tell that libc.so.6 is an arm directive. Come down and see what library files libc.so.6 really need:

#arm-linux-ldd libc.so.6

Ld-linux.so.2 = not Found

You can see that the Libc.so.6 library file needs to ld-linux.so.2 this dynamic link library (not found indicates that the corresponding library is not found in the current system because the system is i386 and requires arm format, so it cannot be found).

This allows the ARM-LINUX-LDD command to determine the dynamic link libraries required for each program, and then place them in the lib/directory as needed to assemble the dynamic link libraries that comprise the target root filesystem.

L If you select the Init module for BusyBox, you need to configure the BusyBox initialization file. Since the Linux system loads the root file system, it needs to perform some configuration to initialize the entire Linux working environment and INIT program and Shell. This file is Etc/inittab. For more information about this file, you can view the man inittab. But BusyBox's inittab format is different from the general Linux Inittab format, so it is not possible to copy the/etc/inittab file on the PC directly to the root file system of the BusyBox production.

BusyBox has its own format of Inittab sample files, placed in the examples directory, the main content includes:

:: Sysinit:/etc/init.d/rcs

:: askfirst:-/bin/sh

Tty2::askfirst:-bin/sh

Tty3::askfirst:-bin/sh

Tty4::askfirst:-bin/sh

#Stuff to does when restarting the INIT process

:: Restart:/sbin/reboot

#Stuff to do before rebooting

:: Ctrlaltdel:/sbin/reboot

:: Shutdown:/bin/umount-a-R

:: Shutdown:/sbin/swapoff–a

Each line of the BusyBox Inittab is formatted as follows:

<id>:<runlevels>:<action>:<process>

A total of four items are separated by ":" Between each item.

The 12th <id> and <runlevels> are ignored in BusyBox, so you can see that all items from the Inittab sample file provided by BusyBox are prefaced with two colons "::".

The third <action> is description of the action, options are Sysinit, respawn, Askfirst, wait, once, restart, Ctrlaltdel and shutdown. Most of these actions can be directly understood by the action name. Where Askfirst prompts the user before logging in to the shell, and respawn does not prompt.

Item Fourth <process> Specifies the script file that the <action> action should execute.

Know the format, the following simple analysis of the Inittab sample file:

The first line:: Sysinit:/etc/init/rcs actually specifies the system initialization (SYSINIT) when the script is/etc/init/rcs, which can be changed according to your own needs.

However, the different configurations for different end-devices differ in the beginning of the logo, for example, for the Tty2 terminal, there is a corresponding operation tty2::askfirst:-bin/sh. The meaning of this line refers to the use of the shell for the Tty2/bin/sh, while the Askfirst (prompted to request a login). For a particular terminal device can be directly removed from the previous equipment signs, such as ttyS0, ttyS1 and so on.

Second line:: askfirst:-/bin/sh Specifies that the first terminal of the system loads the shell as/bin/sh and prompts the user before entering the shell. Other lines are requested to be analyzed by the reader themselves.

L in the etc/directory in addition to Inittab files, but also need some other basic documents, such as Fstab, passwd, group, INPUTRC, etc., due to space limitations, it is impossible to explain one by one, readers can refer to other books or man manual, For some file readers can also borrow other embedded root file system content, and then modify it to conform to their own system. Here is a brief introduction to several files in etc/:

Üfstab: This file describes the various file system information in the system. In this file, each file system is described by one line, and in each row, the fields are delimited by a space or tab symbol, and the lines that begin with * in the file are commented information. The general content may be as follows:

/DEV/MTDBLOCK2/JFFS2 Defaults 0 0

None/tmp Ramfs Defaults 0 0

NONE/PROC proc Defaults 0 0

First column (field): Device name or device volume label name (typically the corresponding device file in/dev)

Second column (field): Device mount directory (e.g. "/" or "/tmp" above)

Third column (field): Device file system (e.g. "ext3" or "VFAT" above)

Fourth column (field): Mount parameter (see Help man mount for details)

For a device that is already mounted, such as the/dev/sda2 above, now to change the mount parameter, you can not uninstall the device, and you can use the following command (no mounted device, remount This parameter is invalid)

#mount/mnt-o Remount,ro (change defaults to RO)

Please refer to the Man manual for additional parameters.

Fifth column (field): Indicates whether you want to back up. (0 is not backed up, 1 is to be backed up)

Sixth column (field): Indicates the self-test order. (0 is not self-test, 1 or 2 is to self-test, if the root partition to be set to 1, the other partition can only be 2)

ÜPASSWD and group Save the Linux system's user group and user name, and so on, regardless of the hardware platform, for convenience, can copy the past from the existing Linux system.

There are many configuration files in the etc/directory, it is impossible to explain one by one, and readers should refer to the existing systems when they are created.

5. Summary

The above has introduced a root file system creation process, if the complete follow the above steps down, should be in/rootfs under a relatively complete root file system, the root filesystem is mainly BusyBox bin/, sbin/directory, etc/ The system configuration file directory and the directory where the lib/dynamic link library is located, such that the minimum environment that a Linux application can perform is basically built. You can then add the required applications to the root file system, and so on.

But how does this root filesystem fit into the target Development Board?

It is common practice to package the entire root file system into an image of a file system format and then download it to the target Development Board's storage device (such as Flash).

What program can be used to package? Support several formats?

MKFS system commands are typically used. The MKFS command can generate an image file of the specified file system type. Different MKFS commands are required for different file system types, such as ext2,ext3 types of files that can use Mkfs.ext2 and mkfs.ext3, and so on. And usually the embedded Development Board uses Flash as the storage device, so the corresponding file system type is generally JFFS2, So using the command MKFS.JFFS2 command, this command is generally available on the Development Board tools, or can be downloaded from the Internet, this command is generally run on the PC system, so generally for the I386 executable file.

The basic command format for MKFS.JFFS2 is as follows:

Mkfs.jffs2-r dir-o file-e SIZE--pad=padsize

Where dir is the folder to be packaged, file is the path to the output files, and size is the block sizes for each erase (default is 64KB). Padsize is a fill size, this parameter forces the target file size to be at least padsize bytes, if the actual data is not so large, then use 0xFF padding, this parameter is important, when the image is written to the target Development Board should generally match the actual root filesystem size (similar to the total disk capacity), This has the effect of initialization, if not, there may be some problems when mounting the JFFS2 root file system.

Here is a simple example that packages this root filesystem of/rootfs into a file rootfs.img with a total size of 1M (0x100000 bytes).

Mkfs.jffs2-r/rootfs-o rootfs.img-e 0x40000--pad=0x100000

A good image file can be written to the target board, usually using U-boot and other bootloader through the network card to download to the Development Board memory, and then write to the Development Board flash. In U-boot, if the NIC driver is available, it is usually downloaded using TFTP, and then the relevant flash operation commands are used to write the data.

Using BusyBox to make a root file system