Linux system startup process on ARM platform

Linux system startup process on ARM platform

I have been using the Linux system as a learning platform since I started learning embedded development. Now, both PC and ARM development boards can successfully run the Linux system, but I still don't know much about the Linux Startup Process. So I started to introduce various Baidu and Google, and of course I saw the introductions written by various great gods. In general, it is: bootloader ----> kernel ----> root filesystem. Of course, it also introduces which stages have been completed. For example, bootloader obtains control of the cpu when it is powered on, while bootloader implements hardware initialization. Bootloader became the "first crab" code after power on.

When talking about this, we have to think about how the hardware mechanism meets this function. Taking the S3C2440 chip as an example (my hardware platform uses this chip as the main chip), the CPU is integrated with a 4 kb sram (also known as stapping stone stepping stone ), when the system is powered on, NAND controler automatically copies the first 4 K content in nand flash to the stepping stone, and the PC Pointer Points to the starting address 0x00000000 as soon as it is powered on. This part of the code can be executed. As you can imagine, if this part of the code is part of the bootloader, will it be possible to run the bootloader when it is powered on? Indeed, in the embedded Linux software system, the first part of nandflash code is usually bootloader, then kernel, and then the root file system.

After talking about this, I didn't seem to have mentioned the starting process. Don't worry. Let's talk about it slowly.

Let's talk about the starting process. If we only briefly describe where and who did what, we may only know the result. I personally think that the entire process can be understood only when the cpu pc pointer goes through the Code footprint. When the code execution process is found, I will analyze the code again, naturally, you know what has been done, and more importantly, it lays a solid foundation for code porting. Naturally, this process is painful and boring. It is not even clear after reading the code for a few days, but it is also a kind of exercise. Now, let's get started with the topic.

Bootloder:

As mentioned above, bootloader gets the cpu usage right when it is powered on. Of course, it has to do some initialization work, for example, it is urgent to disable the watchdog, set the cpu running mode, and set the stack. Of course, we also need to initialize some other hardware on the motherboard, such as NIC, display, and nand flash, and finally load the Linux kernel into the memory. The so-called "responsibility" and "power" coexist. If you get an interest, you must pay for it. After bootloader completes its mission, it will hand over the cpu usage right to the next part of the Code: kernel.

Kernel:

Before discussing how the kernel is started, first understand the composition structure of the kernel and how it is obtained.

The following figure shows the information displayed when the kernel compilation is about to end:

The following figure shows the above compilation process,

 

As you can see, when the kernel source file is compiled to a vmlinux file, several modules are compiled and linked. Among them, vmlinux is an object file in ELF format, which is only a file obtained after the source code is connected and cannot be run on the arm platform. After conversion by the objcopy tool, the binary format file Image is obtained. Compared with the vmlinux file, the Image file has different formats, but also many comments and debugging information. After the imagefile is compressed, piggy.gz is obtained. This file is only a compressed version of the Image, and there is no other difference. Then compile and generate several other module files misc. o big_endian.o head. o head-xscale.o, these files constitute a component called bootstrap loader, also known as the boot program. Compile and generate the piggy. o file. The piggy. o file and bootstrap loader form a bootable kernel Image file (which can be started ).

We can see that the final executable file is the rightmost one, which is also the image we burned to the Development Board. Piggy. o is the kernel image, and the remaining several files constitute the boot program.

The following describes the CPU Transfer Process:

You can also use a chart to display it:

As you can see, the system starts executing bootloader as soon as it is powered on. After the bootloader is executed, the control is handed over to the head of the pilot program. o In the start label of the file, after the boot program completes the boot work, the control is transferred to the real kernel head. o. Here is the entry point of the kernel, and the head. o of the kernel is handed over to the start_kernel function of main. o. In this way, you can view the corresponding code to know what the code has done. Here we can find the corresponding code and analyze it to see what they have done. The following is my analysis result:

Pilot Program: head. o takes control from bootloader and completes the following tasks:

1. Enable I/D caches, close the interrupt, establish a C Runtime Environment (that is, set the stack) completed by head. o and head-xscal.o

2. decompress and relocate the code, which is completed by misc. o.

3. Other hardware-related settings, such as big. endian. o.

Kernel entry point: takes control from the boot program and completes the following tasks:

1. Check valid cpu and cpu Information

2. Create the page table initialization Portal

3. Enable MMU

4. check and report errors

5. Jump to the start_kernel () function in the main. c file of the kernel itself.

 

Kernel startup: takes control from the head. o of the kernel and starts kernel startup. kernel Initialization is completed here, such as initialization of various subsystems of the kernel.

This article permanently updates the link address: