Building the simplest root file system

This article will show you how to build the simplest root filesystem and initially analyze how the kernel executes the first kernel program.

Hooking up the root file system

Before you hook up the root filesystem, you need to make the root file system. The root filesystem requires some basic commands, directories, and device files, and the following describes how to use BusyBox to make the root file system.

As we all know, the Init process is the first application executed after the system starts, and according to the general Linux application configuration structure, an executable file is usually paired with a configuration file for, for example, the Samba feature for/etc/samba/ smb.conf configuration file, NFS feature for/dev/exports configuration file, then init initialization function is also for a configuration file, this configuration file is called/etc/ Inittab. The configuration file, depending on the level, specifies that different applications are executed under different circumstances.

With the introduction of the BusyBox configuration file format, we learned about the Inittab file format:

Format for each entry: <id>:<runlevels>:<action>:<process>

ID entry: Each ID becomes/dev/id, used as the terminal device used by the program's input and output files, such as Id=s3c2410_serial0, for the terminal is S3c2410_serial0

can be set to null without the need for terminal output

Runlevels: The control used for the start level, which can be omitted from the Arm-linux.

Action item: When executing an application execution time can only be set to a few valid moments, BusyBox supports the following points in time.

Valid actions Include:sysinit, respawn, Askfirst, wait, once, restart, Ctrlaltdel, and shutdown.

Askfirst: It is known from the name that the trigger point is to ask the user first to see if it needs to be executed.

Ctraltdel: When the user presses Ctrl+alt+del, the kernel initiates a SIGINT signal to the INIT process, and when the INIT process receives this signal, it executes the specified Ctrlaltdel type of application, which executes the reboot command by default.

Process: Specify the application full path

If the user does not set the/etc/inittab file in the root file system, BusyBox provides a default configuration option, which is equivalent to the following configuration.

BusyBox will follow Sysinit--->wait---->once---->[respawn--->askfirst----> respawn----> Askfirst-> ...]

In addition to the basic Linux file framework provided by BusyBox, the root file system requires a program runtime library.

With the above knowledge foreshadowing, the following to build the minimum root file system, then the minimum root file system should be what?

1./dev/console. /dev/null

2./sbin/init----> BusyBox

3./etc/inittab and its custom applications

4. C Library at runtime

Steps to make the root file system:

1. Configuring the compilation BusyBox

I choose busybox-1.7.0, compile the steps and compile kernel almost, first make menuconfig, then make, and finally make install. In this, you need to pay attention to the following points:

If you cannot configure the cross-compilation tool in Menuconfig, you need to modify it in makefile to specify a specific tool.

Add command line code completion function: Busybox Settings--->busybox Library Tuning---> Tab completion

Whether to use static connection: Busybox Settings----> Build Options----> Build Busybox as a static binary is generally set as a dynamic library

Hot swap Supported: Linux System Utilities-----> Mdev

Then make, execute make config_prefix=. /test_busybox_compile install, do not directly make install, this will overwrite the original code on the PC. After the installation is complete, the results are as follows:

The results of the BusyBox compilation are the bin directory, the Sbin directory, and the USR directory, and a LINUXRC link file under the root directory, pointing to Bin/busybox. Look at all the generated files, they are linked files, all pointing to/bin/busybox. This kind of directory construction is not enough to start a normal Linux, continue to make the following.

2. Add other required files

Add a basic device node, modeled on the current system's console device node and the null device node, in the BusyBox directory.

3. Construct your own boot configuration file/etc/inittab

For the sake of simplicity, this only sets the shell input on startup. Create the ETC directory first, and then do the following.

4. Install C library

Copy all the dynamic link libraries in the cross-compilation toolchain to the BusyBox installation directory, create the Lib directory, and do the following:

The native cross-compilation tool is installed in the/OPT directory, in the Copy C library should be noted that the-D option, this option makes the copy process, the link file keeps the file attributes do not change, otherwise, the content of the linked file will be the entire content pointing, not the link file itself.

5. Making image files

The root filesystem format generally has two kinds, one is the yaffs format, this one is for the small page 512 bytes of NAND Flash file system, called YAFFS1, and the other is for large page 2K NAND Flash file system. Here, depending on the hardware, the file system in the YAFFS2 format is used.

Generate the minimum root file system image, then burn it to the board and write the following command:

TFTP 0x30000000 TEST_BUSYBOX_COMPILE_FS.YAFFS2

NAND erase root; NAND write.yaffs 0x30000000 0x00260000 $ (filesize); Reset

After startup, it appears as follows:

Done.

After a few steps above, one of the simplest root file systems has been established, and since then, it is possible to gradually add functionality based on this.

Additional Features

The minimum root file system made above has many imperfections, and after booting, some mount commands need to be executed automatically.

1. Create a proc directory

Add this sentence in/etc/inittab: Sysinit:/etc/init.d/rcs, make the RcS script file automatically after boot.

In the RCS script file, add mount–t proc None/proc to enable automatic Mount proc virtual file system

2. If you need to mount multiple file systems, it is recommended to use the MOUNT-A option, which reads the mount commands in the Etc/fstab configuration file.

At this point, modify the files in the RCS, change to mount-a, and create the above file contents in the Etc/fstab directory.

3. Enable hot-swappable function Mdev

According to the instructions in Mdev.txt in BusyBox, we know that the Enable Mdev function needs to do the following: The following operations are in the root file system and directory

mkdir SYS & mount–t sysfs sysfs/sys # Mdev get device information via Sysfs file system

Mount–t TMPFS Mdev/dev # uses a memory file system to reduce read and write to Flash

Mkdir/dev/pts # devpts support for external network connection (Telnet) virtual terminal

Mount–t devpts devpts/dev/pts

Echo/bin/mdev >/proc/sys/kernel/hotplug # Set Kernel HotPlug event callback program

Mdev–s #在/dev directory, generate all device nodes currently supported by the kernel

The above mount related commands can be written in fstab, and other execution commands can be written in the RCS startup script, and the result is as follows:

Fstab

Rcs:

Following the above operation, a complete root filesystem with a basic architecture is set up once the burn is written.

Introduction to Knowledge: how Mdev works

When performing mdev-s, Mdev scans the dev properties file in both directories in/sys/class and/sys/block, obtains the device number from the Dev property file, and takes the name of the directory containing the Dev property file as the device name, Device_name. And that part of the catalogue between/sys/class and Device_name became subsystem,

[Subsystem] [Device_name] Dev

For example: Cat/sys/class/tty/tty0/dev inside the content is 4:0 "Major:minor", then subsystem for Tty,device_name for TTY0

Mdev will create the appropriate device files in the Dev directory based on this information

When Mdev is called because of the Uevent event (formerly known as the HotPlug event), Mdev obtains two variables through the environment variable passed to it by the Uevent event.

One is the action that raised the Uevent event

The other is the device path where the appliance resides.

Mdev judgment Action, if add, indicates that a new device (virtual device or physical device) is added to the system, Mdev will obtain the device number from the Dev properties file under the device path, and then establish the device node in the/dev directory based on the information about the path. If the action is remove, which means that the device has been removed from the system, remove the device node under the/dev/directory.

From the above, to play Mdev automatically create the device node function, there must be three conditions.

1. Under one of the subsystem in/sys/class/

2. Under subsystem, create a directory with the device name Device_name as the name

3. In this directory, a dev attribute file is included, which outputs the device number as "major:minor\n".

A class can be seen as a container in which a large container contains and manages many class_device, each class_device a specific device.

Optimized operation:

According to the above-mentioned root file system, there are many places that can be optimized, for example, you can tailor the C library in the file system according to the actual need, you can use Arm-linux-strip to optimize the dynamic link library and Bin/busybox under Lib.

How to execute the first program

   1:  staticint noinline init_post (void)

   2:  {

   3:      free_initmem ();

   4:      unlock_kernel ();

   5:      Mark_rodata_ro ();

   6:      system_state = system_running;

   7:      numa_default_policy ();

   8:  

   9:      /*hao:open Console device * /

if (Sys_open (const char "/dev/console"        , O_RDWR, 0) < 0)

One   :          "warning:unable to open an initial console.\n");

  :  

  :      (void) sys_dup (0);  /*hao:copy an opened file num,make both file num pointed to the same file.  */

  :      (void) sys_dup (0);  /*make 1 (standard output) and 2 (Error output) point-to-0 (standard input) */

  :  

  :      if (Ramdisk_execute_command) {

  :          run_init_process (Ramdisk_execute_command);

  :          "Failed to execute%s\n",

  :                  Ramdisk_execute_command);

  :      }

  £ º  

*   /      *

At   :       * We Try each of the these until one succeeds.

  :       *

  :       * The Bourne shell can be used instead of the init if we is

  :       * Trying to recover a really broken.

  :       * /

  :/       *

  £ º       hao:execute_command equal the Bootargs named init.  E.G:INIT=/LINUXRC

  :  then      execute_command= = "/LINUXRC

      "*   /  

  :      if (Execute_command) {

  :          run_init_process (Execute_command);

  :          "Failed to execute%s.  Attempting "

  :                      "defaults...\n", Execute_command);

  :      }

  Panax Notoginseng  :

      /*hao:if we don ' t define init cmd, then we call/sbin/init to start system. * /

  :      run_init_process ("/sbin/init");

Max   :      run_init_process ("/etc/init");

A   :      run_init_process ("/bin/init");

  :      run_init_process ("/bin/sh");

  :  

  :      Panic ("No init found.  Try passing init= option to kernel. ");

  :  }

After the kernel boots, execute init_post, which will open an end device (referred to as/dev/console), and then point the standard output file and the error output file to the console device pointed to by the standard input file.

Ramdisk_execute_command Uboot passed to kernel rdinit parameter, here is empty, so Ramdisk_execute_command is also empty.

Execute_command for Uboot to kernel init parameter, here is/LINUXRC, so execute_command=linuxrc.

If Uboot does not define the Rdinit and init parameters, then kernel searches and executes the/sbin/init,/etc/init ... Until a program executes successfully and if none are found, the kernel panic is displayed and the corresponding prompt is printed.

Reference Links:

BusyBox simplifies embedded Linux systems

Building the simplest root file system