Development environment - Linux system quick start

========================= Basic common sense======================= ==

Basic boot process of Linux system:

1. The CPU reads the code from the 0x0 address of the ROM (if any) and executes the loader;

2. Loader initializes ram, copies uboot or kernel image from rom to the specified address of ram and executes;

3. Uboot (if any) copies the kernel image and dtb file to the specified address of ram, and runs the kernel;

4. The setting bootargs will be overwritten and the kernel will start;

5. Kernel self-extracting;

6. Kernel initialization;

7. Kernel loads the built-in driver and starts the hardware device;

8. Load the file system, read and execute /etc/inittab.

 

 

========================= Quick start principle====================== ===

1. Basic principles

1. Hardware IO time;

2. Streamlined process;

3. Streamlined kernel;

 

2. Start-up process analysis

1. 0x0, level one loader, configuration ram; à must;

2. Copy uboot or kernel and dtb to ram; à must, read value from ROM, IO time;

3. Uboot (if any) copies kernel and dtb; à can be removed, skip directly;

4. Set bootargs and start the kernel; ànot required, it does not take up IO time;

5. Kernel self-extracting; à can be streamlined, but will increase the IO time of 2;

6. Kernel initialization; à must;

7. Kernel loads the built-in driver and starts the hardware device; à can be streamlined, taking up a lot of IO time;

8. Scan ROM; à can be removed;

9. Mount the file system; à must, but for 8, it can be adjusted to 2;

10. Read and execute /etc/inittab. à must;

 

Three, the basic idea

1、 Loader

1. The purpose of Loader is to guide the system;
2. Unless necessary, loader is not needed to drive the hardware, otherwise there is no need for linux;

2、 Kernel

1. Necessary common sense: the startup of Kernel is only related to CPU and ram;
2. Kernel embedded driver is to deal with hardware IO operations that must be done before firmware is mounted;

3. File system

1. When Kernel starts, the file system does not have to be read from rom, but can also be read from ram;
2. Rom can already be used in the loader, you can take advantage of this time to read what you need at one time, there is no need to take up the precious time of kernel startup;
3. In order to speed up the loading speed of the file system by the loader, the file system can be divided into a general part (<3mb) and a firmware part. The cramfs driver in the kernel loads the startup file system, first completes the startup task, and then loads the rom device from the startup file system , Then load the firmware file system;

 

Fourth, the adjusted startup process

1. 0x0, first level loader, configuration ram; 

2. Copy kernel (reduced), dtb, file system mirror (reduced) to ram;

3. Set bootargs and start the kernel; 

4. Kernel self-extracting;

5. Kernel initialization;

6. Kernel loads the necessary driver preparation;

7. Mount the general file system;

8. Read and execute /etc/inittab;

9. Mount the firmware, including drivers, additional application software and LIB;

 

 

========================= Quick start configuration====================== ===

1. Streamline loader

Ideas:

1. The purpose of Loader is to prepare the conditions for the kernel to start;

2. Loader skips the steps of preparing the running environment and loads the kernel directly;

method:

Note: The bootloaders of major manufacturers are very different, and only general methods can be introduced.

1. If the official project has a method to skip uboot, then use this method directly;

2. If 1 is undesirable, delete and modify the uboot code. After entering uboot and the hardware initialization is completed, the uboot user environment is not initialized, and the source code is used to load and start the mirror directly;

Effect: time-consuming process of bootloader is reduced; bootloader volume is reduced;

 

Two, streamline the kernel

Idea: Keep only the drivers necessary for startup, such as cramfs read and write drivers, audio drivers (boot music), and the rest of the drivers are made into ko files and placed in the file system;

method:

1. Make ARCH=arm menuconfig, cut off the drivers that will not be used;

2. Drivers that are not needed at startup but required by the application are set to module and stripped from the kernel;

3. Busybox must provide insmod function;

Effect: The size of the kernel is reduced, the time for loadder to load the kernel is shortened, the time for kernel decompression is shortened, and the time from kernel startup to mounting the file system is shortened;

 

Three, streamline rootfs (that is, make general parts)

Ideas:

Only keep: 1. busybox; 2. general /etc configuration files; 3. drivers needed to load firmware (rom related); 4. files needed to start tasks (such as audio players); 5. related runtime libraries ; Packed with cramfs, the volume is about 2.4mb;

Effect: The file system can run directly in ram, and can delay loading rom driver;

 

Fourth, make firmware

1. All remaining files are packaged in the firmware system (ext4 format or ubi format);

2. But it should be noted that there needs to be an rc.local file in the firmware /etc. When the task customized in rootfs is completed, the file is called to start the firmware task;

3. In order to maintain the normal operation of the system, the rcS file in the original /etc should be added after the firmware is mounted:

# Mount firmware

Mount /dev/*** /mnt

# Overwrite general etc with firmware etc, apply firmware configuration and restore write permissions

Mount /mnt/etc /etc

# Overwrite the general var with firmware var, restore read and write permissions

Mount / mnt / var / var

# Extend the lib search range to /lib and /usr/lib of the firmware to ensure the normal operation of the program

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/lib:/mnt/usr/lib

# Execute firmware startup configuration script

/etc/init.d/rc.local