"Go" Linux advanced Perspective to view the Linux boot process

"Original" Https://www.toutiao.com/i6594210975480545800/

1. Overview

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

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.

2. System Startup

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.

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.

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

# Ddif=/dev/hda Of=mbr.bin bs=512 Count=1#od-xambr.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 file in 16 binary and ASCII format.

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.

4. 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.

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.

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 load from the Reiser log file system) or e2fs_stage1_5 (to load 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 on request (defined in/etc/grub.conf, along with several soft symbolic links/etc/grub/menu.lst and/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.

Grub Stage Boot loader: The/boot/grub directory contains the Stage1, stage1.5, and stage2 boot loaders, as well as many other loaders (for example, Cr-rom uses iso9660_stage_1_5).

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.

5. Kernel

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 are from the./arch/i386/boot/head. The start assembly routine of S begins execution (see Figure 3 for the main flowchart). This routine executes some basic hardware settings and calls the./arch/i386/boot/compressed/head. The startup_32 routines in S. This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). Then call a C function called Decompress_kernel (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.

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 takes you into the architecture-independent Linux kernel section. In fact, this is the main function of the Linux kernel.

Figure 3. Main function flow of Linux kernel i386 boot

Note that the function Decompress_kernel is where we usually see the decompression message:

Uncompressing Linux ... Ok, booting Thekernel.

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, which is the first user-space process (user-spaceprocess). Finally, start the empty task, and now the scheduler can take over control (after calling 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. Because the modules required to interact with peripherals may be part of the INITRD, the kernel can be very small, but it still needs to support a large number of possible hardware configurations. After the kernel boots, you can formally equip the root filesystem (via Pivot_root): The INITRD root file system is unloaded and the real root filesystem is mounted.

The INITRD function 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 without a hard drive, the INITRD can be the ultimate root file system, or it can be mounted on a network file system (NFS) to mount the final root file system.

6. 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 rich initialization functionality provided by Init (which is configured through/etc/inittab). In many cases, we can invoke a simple shell script to launch the required embedded application.

7. Concluding remarks

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).

"Go" Linux advanced Perspective to view the Linux boot process