Linux Boot Process Insider

Linux Boot Process Insider

Guidance from a master boot record to the first user space application

In the early days, starting a computer meant feeding the computer a tape containing a bootloader, or manually loading the bootloader with the front panel address/data/control switch. Although the current computer is equipped with many tools to simplify the boot process, it does not necessarily simplify the process.

Let's look at the Linux boot process from a high-level perspective, so you can see the whole process in its entirety. Then you'll review what happened at each step. Throughout the process, refer to the kernel source code to help us better understand the kernel source tree, and later on it in-depth analysis.

Overview

Figure 1 is the view we see at a height of 20,000 feet.

Figure 1. A 20,000-foot view of the Linux boot process

When the system is first booted, or when the system is reset, the processor executes a code at a known location. In a personal computer (PC), this location is in the basic input/output system (BIOS), which is stored in the flash memory on the motherboard. The central processing Unit (CPU) in the embedded system calls this reset vector to start a program at a known address in the Flash/rom. In both cases, the results are the same. Because the PC provides a lot of flexibility, the BIOS must determine which device to use to boot the system. We'll cover this process in more detail later.

When a boot device is found, the first stage of the boot loader is loaded into RAM and executed. The bootloader is less than 512 bytes in size (a sector) and is loaded with the second stage of the bootloader.

When the second stage of the boot loader is loaded into RAM and executed, an animated screen is typically displayed and Linux and an optional initial RAM disk (temporary root file system) are loaded into memory. When the image is loaded, the second stage of the bootloader gives control to the kernel image and the kernel can decompress and initialize it. During this phase, the second stage of the bootloader detects the system hardware, enumerates the system-linked hardware devices, mounts the root device, and then loads the necessary kernel modules. After you complete these operations, start the first User space program ( init ) and perform advanced system initialization work.

This is the whole process of Linux booting. Now let's dig into the process and delve into some of the details of the Linux boot process.

System boot

The system boot phase relies on booting the hardware on the Linux system. In an embedded platform, a boot environment is used when the system is power-up or reset. Examples of this include the micromonitor of U-boot, Redboot and Lucent. Embedded platforms are typically sold with a boot monitor. These programs are located in a particular area of flash memory on the target hardware, and they provide a way to download the Linux kernel image to flash memory and continue execution. In addition to storing and booting Linux images, these boot monitors perform a certain level of system testing and hardware initialization. In an embedded platform, these boot monitors typically involve the first and second stages of the boot loader.

Extracting information from MBR

To view the contents of your MBR, use the following command:

# dd if=/dev/hda of=mbr.bin bs=512 count=1 # od -xa mbr.bin

This dd command needs to run as the root user, which reads the first 512 bytes of content from/dev/hda (the first IDE disk) and writes it to the mbr.bin file. The od command prints the contents of this binary in 16 binary and ASCII format.

In a PC, booting Linux starts at the address 0xffff0 in the BIOS. The first step in the BIOS is a power-on self-test (POST). The job of POST is to detect the hardware. The second step of the BIOS is to enumerate and initialize the local device.

Given the different uses of BIOS functionality, the BIOS consists of two parts: the POST code and the runtime service. When the POST is finished, it is cleaned out of memory, but the BIOS runtime service remains in memory and the target operating system can use the services.

To boot an operating system, the BIOS runtime searches for active and bootable devices in the order defined by the CMOS settings. The boot device can be a floppy disk, a CD-ROM, a partition on the hard disk, a device on the network, or even a USB flash.

Typically, Linux is booted from the hard disk, where the master boot Record (MBR) contains the primary boot loader. The MBR is a 512-byte sector that is located in the first sector on the disk (0 0 Cylinder 1 sectors). When the MBR is loaded into RAM, the BIOS will give control to the MBR.

First Stage boot loader

The master boot loader in the MBR is a 512-byte image that contains the program code and a small partition table (see Figure 2). The first 446 bytes are the master boot loader, which contains the executable code and the error message text. The next 64 bytes are the partitioned table, which contains 4 partitions of records (the size of each record is 16 bytes). The MBR ends with a byte (0xaa55) of two special digits. This number is used to check the validity of the MBR.

Figure 2. MBR anatomy

The main boot loader works by locating and loading the secondary boot loader (phase two). It does this by looking for an active partition in the partitioned table. When an active partition is found, it scans other partitions in the partitioned table to ensure that they are not active. When this process is verified, the boot record for the active partition is read into RAM from this device and executed.

Second Stage boot loader

The secondary boot loader (second-stage boot loader) can be more visually referred to as the kernel loader. The task at this stage is to load the Linux kernel and the optional initial RAM disk.

GRUB Stage Boot Loader

/boot/grubThe directory contains stage1 , stage1.5 and the stage2 bootloader, and many other loaders (for example, Cr-rom is used iso9660_stage_1_5 ).

In the x86 PC environment, the first and second stages of the boot loader are collectively called the Linux Loader (LILO) or GRand Unified Bootloader (GRUB). Since LILO has some drawbacks, and grub overcomes these shortcomings, let's look at grub below. (For more information about GRUB, LILO, and related topics, see the Resources section later in this article.) ）

The good thing about GRUB is that it contains knowledge about the Linux file system. Instead of using bare sectors like LILO, GRUB can load the Linux kernel from the ext2 or ext3 file system. It does this by converting the two-stage boot loader into a three-stage bootloader. Phase 1 (MBR) guides a phase 1.5 boot loader that understands the special file system that contains the Linux kernel image. Examples of this include reiserfs_stage1_5 (to be loaded from the Reiser log file system) or e2fs_stage1_5 (to be loaded from a ext2 or ext3 file system). When the boot loader for phase 1.5 is loaded and running, the boot loader for phase 2 is ready to load.

When phase 2 is loaded, GRUB can display a list of available kernels ( /etc/grub.conf defined in, and several soft symbolic links) on request /etc/grub/menu.lst /etc/grub.conf . We can choose the kernel and even modify the additional kernel parameters. Alternatively, we can use a command-line shell to perform advanced manual control of the boot process.

After the second stage of the boot loader is loaded into memory, the file system can be queried and the default kernel image and initrd image are loaded into memory. When these image files are ready, the boot loader for stage 2 can invoke the kernel image.

Manual boot in kernel grub

In the GRUB command line, we can use the initrd image to boot a specific kernel, as follows:

Grub> kernel/bzimage-2.6.14.2
[Linux-bzimage, setup=0x1400, size=0x29672e]
Grub> initrd/initrd-2.6.14.2.img
[Linux-initrd @ 0x5f13000, 0xcc199 bytes]
grub> Boot
Uncompressing Linux ... Ok, booting the kernel.

If you do not know the name of the kernel to boot, simply use the slash (/) and press the Tab key. GRUB displays a list of kernels and initrd images.

The kernel phase begins when the kernel image is loaded into memory and the boot loader for phase 2 releases control. The kernel image is not an executable kernel, but a compressed kernel image. Usually it is a zimage (compressed image, less than 512KB) or a bzimage (larger compressed image, greater than 512KB), which is compressed in advance using zlib. In front of this kernel image is a routine that implements a small set of hardware settings, extracts the kernel contained in the kernel image, and then puts it into high-end memory, and if there is an initial RAM disk image, it is moved into memory and marked for later use. The routine then invokes the kernel and starts the process of booting the kernel.

When Bzimage (for i386 images) is called, we ./arch/i386/boot/head.S start with the start assembly routines (see Figure 3 for the main flowchart). This routine performs some basic hardware setup and invokes ./arch/i386/boot/compressed/head.S the startup_32 routines in. This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). Then call a decompress_kernel C function called (in ./arch/i386/boot/compressed/misc.c ) to decompress the kernel. Once the kernel has been extracted into memory, it can be called. This is another startup_32 function, but this function is in ./arch/i386/kernel/head.S .

In this new startup_32 function (also known as the Purge program or process 0), the page table is initialized and the memory paging feature is enabled. The type of CPU is then detected for any optional floating-point unit (FPU) and stored for later use. Then call the start_kernel function (in init/main.c ), which will take you into the architecture-independent Linux kernel section. In fact, this is the function of the Linux kernel main .

Figure 3. Main function flow of Linux kernel i386 boot

By calling start_kernel , a series of initialization functions are called to set interrupts, perform further memory configuration, and load the initial RAM disk. Finally, to invoke kernel_thread (in arch/i386/kernel/process.c ) to start the init function, this is the first user-space process (user-space). Finally, start the empty task, and now the scheduler can take over control (after the call cpu_idle ). By enabling interrupts, the preemptive scheduler can periodically take over control to provide multitasking capabilities.

During the kernel boot process, the initial RAM disk ( initrd ) is loaded into memory by the Phase 2 boot loader, which is copied into RAM and mounted on the system. This initrd is used as a temporary root file system in RAM and allows the kernel to fully boot without mounting any physical disks. The initrd kernel can be very small, but it still needs to support a large number of possible hardware configurations because the modules needed to interact with the peripherals may be part of the system. After the kernel boots, you can formally equip the root filesystem (via pivot_root ): The root filesystem is initrd unloaded and the real root filesystem is mounted.

Decompress_kernel output

The function decompress_kernel is where we usually see the decompression message:

Uncompressing Linux ... Ok, booting the kernel.

initrdfunction allows us to create a small Linux kernel that includes drivers that are compiled as loadable modules. These loadable modules provide the kernel with a way to access the file system on disk and disk, and provide drivers for other hardware. Because the root file system is a file system on disk, the initrd function provides a startup method to gain access to the disk and mount the real root filesystem. In an embedded environment that does not have a hard disk, initrd it can be the ultimate root file system, or it can be mounted on a network file system (NFS) to mount the final root filesystem.

Init

Once the kernel is booted and initialized, the kernel can launch its first user-space application. This is the first call to a program compiled using the standard C library. Prior to this, no standard C application was implemented.

On a desktop Linux system, the first program to start is usually /sbin/init . But that's not certain. Few embedded systems will need to use the init rich initialization functionality provided (this is /etc/inittab configured). In many cases, we can invoke a simple shell script to launch the required embedded application.

Conclusion

Very similar to Linux itself, the Linux boot process is also very flexible and can support many processor and hardware platforms. Initially, loading the bootloader provides an easy way to boot Linux without any showy. The LILO bootloader extends the boot capability, but it lacks the ability to perceive the file system. The latest generation of bootloader, such as GRUB, allows Linux to boot from some file systems (from Minix to Reise).

Linux Boot Process Insider