Linux Drive learning Note 03--linux kernel boot

The process for the initial process from power on/reset to running Linux user space on the X86 PC. There are several stages of entering the Linux-related code.

(1) When the system is power up or reset, the CPU will assign the PC pointer to a specific address 0xffff0 and execute the instruction at that address. In a PC, the address is in the BIOS and is stored in the ROM or Flash on the motherboard.

(2) The BIOS runtime searches for devices that are active and bootable by following the boot device sequence defined by the CMOS settings. When booting from a hard drive, the BIOS loads the contents of the hard disk MBR (master boot record) into RAM. 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.
(3) The Master boot loader finds and loads the secondary boot loader. It looks for the active partition in the partition table, and when an active partition is found, the other partitions in the partitioned table are scanned 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) The secondary bootloader loads the Linux kernel and the optional initial RAM disk, handing control over to the Linux kernel source code.

(5) Run the loaded kernel and start the user space application.

Linux's boot process in embedded systems is similar, but generally more concise. Regardless of the specific way to achieve, as long as the following characteristics can be called Bootloader.

! It can be executed in a certain way when the system is power on or reset, including by the BIOS Boot execution, direct execution in NOR Flash, code in NAND Flash is automatically copied into internal or external RAM execution by the MCU.
! can be USB flash drive, disk, CD-ROM, Nor/nand Flash, ROM, SD card and other storage media, or even the network port, the operating system in the mouth load into RAM and control to the operating system source code execution.

The Bootloader to complete the above functions is very diverse, It can even be a simplified version of the operating system itself. The famous Linux Bootloader includes LILO and GRUB for PC applications, U-boot, Redboot, etc. for embedded systems.

The vast majority of processor architectures, such as ARM, MIPS, and X86, provide the necessary network protocols (BOOTP, DHCP, TFTP) to identify a wide range of file systems (Cramfs, Fat, JFFS2, and Registerfs) with peripheral drivers such as NICs, serial ports, and Flash. and other tools, such as debugging, scripting, and boot, are widely used. Redboot is the Bootloader Open source project that Redhat company ECos with, in addition to the powerful features u-boot similar, it also contains gdb stub (pile), so it can communicate with GDB via serial port or network port, debug any program generated by GCC (package including the kernel). It is necessary to perform a more detailed analysis of the 5th phase of the above process, which completes the INIT process that starts the kernel and runs the user space. When the kernel image is loaded into RAM, the Bootloader control is released and the kernel phase begins. The kernel image is not a fully executable target code, but a compressed zimage (small kernel) or bzimage (large kernel, bzimage B is the meaning of "big").
However, not everything in the zimage and bzimage images is compressed, otherwise Bootloader gives control to the kernel image and it is "silly". In fact, the image contains the uncompressed part, which contains the decompressor, which extracts the compressed part of the image.

both Zimage and bzimage are compressed with gzip, which is not only a compressed file, but also has a gzip uncompressed code embedded in the beginning of the two files.
when Bzimage (for i386 image) is called, it is from/arch/i386/boot/head. The start assembly routine for S starts execution. This program performs some basic hardware setup and calls/arch/i386/boot/compressed/head. The startup_32 routines in S. After the STARTUP_32 program sets some basic operating environment (such as a stack), clears the BSS segment and calls the Decompress_kernel () C function in/ARCH/I386/BOOT/COMPRESSED/MISC.C to extract the kernel. After the kernel is decompressed into memory,/arch/i386/kernel/head is called again. The startup_32 routine in the S file, this new startup_32 routine (known as the Purge program or process 0) initializes the page table and enables the memory paging mechanism, followed by any optional floating-point unit (FPU) detection
the type of CPU and store it for later use. After all this is done, the Start_kernel () function in/INIT/MAIN.C is called to enter the architecture-independent Linux kernel section. Start_kernel () invokes a series of initialization functions to set interrupts and perform further memory configuration. After that,/ARCH/I386/KERNEL/PROCESS.C Kernel_thread () is called to start the first core thread, which executes the init () function, and the original execution sequence calls Cpu_idle () to wait for the dispatch. The init () function as the core thread completes the loading and initialization of peripherals and their drivers, hooking up the root filesystem. Init () Turns on the/dev/console device, redirecting stdin, stdout, and stderr to the console. It then searches the file system for the INIT program (which can also be specified by the "init=" command-line argument) and executes the INIT program using the EXECVE () system call. The sequence of search init programs is:/sbin/init,/etc/init,/bin/init, and/bin/sh. In embedded systems, in most cases, a simple shell script can be passed to the kernel to launch a required embedded application. At this point, the long Linux kernel boot and boot process is over, and the first thread created by Start_kernel () for Init () also enters user mode.

Linux Drive learning Note 03--linux kernel boot