Table of contents
1. First transplant uboot (everything about uboot is to start the kernel.)
2. What is the function of uboot?
3. Detailed explanation of the function of uboot
Second, transplant the Linux kernel
2. What is in the Linux kernel?
3. Recompile and transplant the device tree file
1. What is the device tree file?
2. What are the device tree files?
3. Introduction to the syntax of the device tree source file (.dts)
Fourth, finally transplant the root file system (rootfs)
1. What is the root file system?
2. Why is the root file system so important?
3. Common directories of linux file system
1. First transplant uboot (everything about uboot is to start the kernel.)
1. What is uboot?
Uboot is a kind of bootloader , which is used to boot and start the kernel. Its ultimate purpose is to read the kernel from the flash, put it in the memory , and start the kernel. Therefore, UBOOT needs to have the ability to read and write flash.
2. What is the function of uboot?
1) The main function of uboot is to start the operating system kernel . It is reflected in the last code of uboot to start the kernel.
2) uboot is also responsible for deploying the entire computer system. It is reflected in the last parameter passing of uboot.
3) In uboot, there are also drivers for operating hardware on boards such as Flash. For example, the serial port needs to be printed, whether the ping network is successful, whether the erasing and programming of the flash are successful, etc.
4) uboot has to provide a command line interface for people to operate. For example: Linux terminal command line interface.
For example: Windows system of the computer
The main core components that all computer systems need to run are 3 things: CPU + external memory (Flash/hard disk) + internal memory (DDR SDRAM/SDRAM/SRAM). The general PC startup process is: after the PC is powered on, the BIOS program is executed first (in fact, the BIOS of the PC is NorFlash). The BIOS program is responsible for initializing the DDR memory and the hard disk, and then reads the OS image from the hard disk to the DDR. , and then jump to DDR to execute the OS until it starts (the BIOS is useless after the OS starts).
So: the startup process of the embedded system is almost the same as that of the PC, except that the BIOS becomes uboot, and the hard disk becomes Flash.
3. Detailed explanation of the function of uboot
It can be started directly by itself
1) The general SoC supports multiple boot methods, such as SD card boot, NorFlash boot, NandFlash boot, etc. ••••• To enable uboot to boot, uboot must be designed according to the specific SoC boot design
2) uboot must be changed and transplanted at the code level corresponding to the hardware to ensure that it can be booted from the corresponding boot medium. This part is specifically dealt with in the start.S file of the first stage in uboot.
Able to boot the operating system kernel and pass parameters to the kernel
1) The ultimate goal of uboot is to start the kernel.
2) When the linux kernel is designed, it is designed to be able to be passed as parameters . That is to say, we can prepare some startup parameters for the Linux kernel in uboot, put them in a specific location in the memory and pass them to the kernel. After the kernel starts, it will go to this specific location to fetch the parameters passed to it by uboot, and then parse them in the kernel. Parameters, these parameters will be used to guide the boot process of the linux kernel.
Can provide system deployment function
1) uboot must be able to be used by people to complete the burning and downloading of the entire system (including uboot, kernel, rootfs, etc.) on Flash.
2) Flashing in the bare metal tutorial (the third part of ARM bare metal) is to use the fastboot function in uboot to burn various images into iNand, and then start from iNand.
Capable of SoC-level and board-level hardware management
1) uboot realizes the control capability of some hardware (a part of hardware is initialized in uboot), because uboot must make these hardware work in order to complete some tasks. For example, uboot must be able to drive iNand to implement flashing. For example, uboot must be able to drive LCD if it wants to display a progress bar on LCD when flashing. For example, uboot must drive the serial port to provide an operation interface through the serial port. For example, if uboot wants to realize the network function, it must drive the network card chip.
2) SoC level (such as serial port) is the internal peripherals of SoC, and board level is the hardware on the development board outside SoC (such as network card, iNand)
The "life cycle" of uboot
1) The life cycle of uboot refers to when uboot starts running and when it ends.
2) uboot is essentially a bare-metal program (not an operating system). Once uboot starts, the SoC will simply run uboot (meaning that other programs cannot run at the same time when uboot is running). Once uboot finishes running, it cannot go back. to uboot (so uboot itself is dead after uboot starts the kernel, if you want to see the uboot interface again, you can only restart the system. Restarting does not revive the uboot just now, restarting is just another life of uboot)
3) The entrance and exit of uboot. The entrance of uboot is to start automatically when booting, and the only exit of uboot is to start the kernel. Uboot can also perform many other tasks (such as burning the system), but after other tasks are executed, you can return to the uboot command line to continue executing the uboot command, and once the boot kernel command is executed, you cannot return.
4. How uboot works
Starting from the bare metal program image uboot.bin
1) The essence of uboot is a bare-metal program , which is not fundamentally different from the bare-metal program xx.bin written in our bare-metal collection. If there is a difference, it is: most of what we write is less than 16KB, while uboot is greater than 16KB (generally uboot is between 180k-400k)
2) Uboot itself is an open source project, which consists of several .c files and .h files. After configuration and compilation, a uboot.bin will be generated, which is the image file of the bare metal program uboot. Then this image file is properly burned into the boot media and given to the SoC to start. That is to say, uboot behaves as uboot.bin when it is not running, and generally lies in the boot medium.
3) When uboot is running, it will be loaded into the memory and then given to the CPU to run one instruction at a time.
Uboot's imperative shell interface
1) Ordinary bare-metal programs are executed directly when they are run, and the execution effect is related to the code.
2) Some programs need to interact with people, so a shell is implemented in the program (the shell is an interface that provides human-computer interaction, recall the sixteenth part of the ARM Bare Metal Complete Works), and uboot implements a shell.
Note: The shell is not an operating system, and has nothing to do with the operating system. After opening a terminal in Linux, you will get a shell, and you can enter a command and press Enter to execute it. The working mode of the shell in uboot is very similar to that of the terminal shell in linux (in fact, it is almost the same, but the command set is different. For example, ls can be used in linux, but ls in uboot does not recognize it).
Master the two key points of uboot use: commands and environment variables
1) After uboot is started, most of the time and work are done under the shell (for example, if uboot wants to deploy the system, it needs to enter commands under the shell, to set environment variables must also be under the command line, and to start the kernel must also be under the command line knock command).
2) Commands are various commands that can be recognized in the uboot shell. There are dozens of commands in uboot, some of which are commonly used and some are not commonly used (we can also add commands to uboot by ourselves), and we will use a few class time to learn the commonly used commands in uboot in turn.
3) The working principles and methods of uboot environment variables and operating system environment variables are almost identical. Uboot is designed with the help of the design concept of the operating system (the command line working method borrows from the linux terminal command line, the environment variables borrow from the environment variables of the operating system, and the driver management of uboot almost completely copies the driver framework of linux).
4) The environment variable can be regarded as the global variable of the system, and the environment variable name is built into the system (if you know it, you know it, if you don’t know it, you don’t know it, this part is the default environment variable that comes with the system, such as PATH; but there are also some The environment variables are added by ourselves, and the systems we add ourselves don’t know it but we know it ourselves). The system or our own program can guide the operation of the program by reading the environment variables at runtime. The advantage of this design is flexibility. For example, if we want to change the running method of a program, we don't need to re-modify the program code and then recompile and run, but only need to modify the corresponding environment variables.
5) The environment variable is the configuration property at runtime.
Second, transplant the Linux kernel
1. What is the Linux kernel?
The Linux kernel is the lowest level of easily replaceable software that interfaces with the hardware in a computer; the kernel is responsible for connecting all applications running in "user mode" to the physical hardware and allows processes to obtain information from each other using interprocess communication.
With more than 13 million lines of code, the Linux kernel is one of the largest open source projects in the world.
2. What is in the Linux kernel?
The Linux kernel is mainly composed of process management , memory management , device drivers , file systems , network protocol stacks, and a system call .
source code organization
3. Recompile and transplant the device tree file
1. What is the device tree file?
The essence of the device tree is also to operate the register, but the relevant information of the register is placed in the device tree. When configuring the register, you need to use the OF function to read the register data from the device tree and then configure it.
Before Linux 3.x, there was no device tree. Linux described the board-level information in the ARM architecture through the board-level description files in the arch/arm/mach-xxx and arch/arm/plat-xxx folders in the kernel source code. As the types of ARM hardware increase, there are more and more device files related to the board, resulting in a larger kernel. In fact, these hardware board-level information has nothing to do with the kernel.
In 2011, after Linus discovered the problem, he introduced the device tree mechanism already adopted by PowerPC and other architectures, separated the board-level information from the kernel, and described it in a dedicated file format (.dts file). The role of the device tree is to describe the hardware resources of the hardware platform, which can be passed to the kernel by the bootloader, and the kernel can obtain hardware information from the device tree. The device tree has two characteristics when describing hardware resources:
- Describe hardware resources in a tree structure
- Like a header file, a device tree file can reference another device tree file to achieve code reuse
2. What are the device tree files?
There are four types of device tree files, such as: DTS, DTSI, DTB, DTC files
The source code of the DTC tool is in the scripts/dtc/Makefile file of the Linux kernel:
hostprogs-y:= dtc
always:= $(hostprogs-y)
dtc-objs:= dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o checks.o util.o
dtc-objs+= dtc-lexer.lex.o dtc-parser.tab.o
......It can be seen from the above that the DTC tool depends on dtc.c, flattree.c, fstree.c and other files, and finally compiles and links the DTC host file. To compile a DTS file, you only need to enter the root directory of the Linux source code, and then execute the following command:
make all #编译Linux源码中的所有东西，包括zImage、.ko驱动模块以及设备树
make dtbs #只是编译设备树There are many SOCs based on the ARM architecture, and one SOC can produce multiple boards, each board has a corresponding DTS file, so how to determine which DTS file to compile? Take the board of I.MX6ULL chip as an example, open arch/arm/boot/dts/Makefile, there are the following contents:
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-ddr3-arm2.dtb \
imx6ul-14x14-ddr3-arm2-emmc.dtb \
......
dtb-$(CONFIG_SOC_IMX6ULL) += \
imx6ull-14x14-ddr3-arm2.dtb \
imx6ull-14x14-ddr3-arm2-adc.dtb \
......After I.MX6ULL is selected (ie CONFIG_SOC_IMX6ULL=y), all .dts files corresponding to the boards using this SOC will be compiled into .dtb. If you make a new board, you only need to create a corresponding .dts file, and then add the corresponding .dtb file name to dtb-$(CONFIG_SOC_IMX6ULL), so that the corresponding .dts will be compiled into binary when compiling the device tree .dtb file
3. Introduction to the syntax of the device tree source file (.dts)
The device tree uses a tree structure to describe the device information on the board. Each device is a node, called a device node. Each node describes the node information through some attribute information. The attribute is a key-value pair
node-name@unit-address{
属性1 = ...
属性2 = ...
子节点...
}
⏩ Node name: node-name is used to specify the node name, which should start with a letter and describe the device category (the root node is represented by a slash)
⏩ Unit address: @unit-address is used to specify the unit address, @ is the separator, followed by the actual unit address, its value is consistent with the first address of the node reg attribute, if there is no reg attribute value, the unit can be omitted address
⏩ Node attributes: The content contained in the curly brackets { } of the node is the node attributes. A node can contain multiple attribute information. The main content of the device tree is to write the attributes of the nodes. Attributes include custom attributes and standard attributes
model attribute: used to specify the manufacturer and model of the device, multiple strings are separated by ","
compatible attribute: composed of one or more strings, is one of the methods used to find nodes
status attribute: used Indicates the operating status of the device, and the device can be disabled or enabled through status
reg attribute: describes the address of the device resource in the address space defined by its parent bus, usually used to indicate the starting address and length of a register
#address-cells and #size -cells: These two attributes exist at the same time. The former determines the word length occupied by the address information in the subnode reg attribute, and the latter determines the word length occupied by the length information
. , parent address and address space length are composed of three parts
– child-bus-address: the physical address of the child bus address space, and the word length occupied by this physical address is determined by #address-cells of the parent node –
parent-bus-address: The physical address of the parent bus address space is also determined by the #address-cells of the parent node
. word length
4. Device tree OF function
The kernel provides a series of functions to obtain the attributes defined in the node from the device node. These functions start with of_ and are called OF functions. When writing the driver of the device tree version, in terms of hardware configuration, it is necessary to use these OF functions to obtain information such as register addresses from the device tree file, and then configure
Fourth, finally transplant the root file system (rootfs)
1. What is the root file system?
The root file system is first of all a file system. This file system not only has the function of storing data files of the ordinary file system, but compared with the ordinary file system, it is special in that it is mounted when the kernel starts (mount ), the image file of the kernel code is stored in the root file system, and the system boot program will load some initialization scripts (such as rcS, inittab) and services into the memory after the root file system is mounted. run. We need to understand that the file system and the kernel are two completely independent parts. The kernel transplanted in the embedded system is downloaded to the development board, there is no way to really start the Linux operating system, and there will be an error that the file system cannot be loaded.
2. Why is the root file system so important?
The root file system contains directories and critical files necessary for system startup, as well as files necessary for other file systems to be mounted. For example:
The application program of the init process must run on the root file system;
the root file system provides the root directory "/";
the information that linux relies on when mounting the partition is stored in the root file system /etc/fstab file; the
shell command program must Run on the root file system, such as ls, cd and other commands;
in short: a set of linux system, only the kernel itself cannot work, must be rootfs (configuration files under the etc directory on the rootfs, /bin/sbin and other directories) Shell commands, and library files in the /lib directory, etc.) can only work together.
When Linux starts, the first thing that must be mounted is the root file system; if the system cannot mount the root file system from the specified device, the system will make an error and exit the startup. After success, other file systems can be mounted automatically or manually. Therefore, different file systems can exist in one system at the same time. The process of associating a file system with a storage device in Linux is called mount. Use the mount command to attach a file system to the current file system hierarchy (root). When performing a mount, provide the filesystem type, the filesystem, and a mount point. After the root file system is mounted on "/" under the root directory, there are various directories of the root file system under the root directory, files: /bin /sbin /mnt, etc., and then other partitions are mounted on the /mnt directory , There are various directories and files of this partition under the /mnt directory.
The root file system includes at least the following directories:
/etc/: Store important configuration files.
/bin/: stores frequently used executable files that must be used when booting.
/sbin/: Stores the system execution files required during the boot process.
/lib/: Stores the link library required for the execution files of /bin/ and /sbin/, as well as the Linux kernel module.
/dev/: Storage device files.
Note: The five major directories must be stored on the root file system, and none of them can be dispensed with.
3. Common directories of linux file system
There are generally the following directories in the Linux file system:
/bin directory
This directory stores basic commands that all users can use. These commands can be used before other file systems are mounted, so the /bin directory must be in the same partition as the root file system.
The commonly used commands in the /bin directory are: cat, chgrp, chmod, cp, ls, sh, kill, mount, umount, mkdir, mknod, test, etc. When we use Busybox to make the root file system, we will create it in the bin directory , you can see some executable files, that is, some commands available.
/sbin directory
This directory stores system commands, that is, commands that only administrators can use. System commands can also be stored in /usr/sbin, /usr/local/sbin directories, and the /sbin directory stores basic system commands. , they are used to start the system, repair the system, etc. Similar to the /bin directory, /sbin can be used before mounting other file systems, so the /sbin directory must be in the same partition as the root file system.
Commonly used commands in the /sbin directory include: shutdown, reboot, fdisk, fsck, etc. The system commands installed by local users are placed in the /usr/local/sbin directory.
The /dev directory
stores device files in this directory. Device files are a unique file type in Linux. Under the Linux system, access to various devices in the form of files, that is, operate a specific hardware by reading and writing a device file. For example, the serial port 0 can be operated through the "dev/ttySAC0" file, and the second partition of the MTD device can be accessed through "/dev/mtdblock1".
/etc directory
This directory stores various configuration files. For the Linux system on the PC, there are many files and directories under the /etc directory. These directory files are optional, and they depend on the applications in the system. Depends on whether these programs require configuration files. In embedded systems, these contents can be greatly reduced.
The /lib directory
stores shared libraries and loadable (driver programs) in this directory, and the shared library is used to start the system. Run executable programs in the root file system, such as programs in the /bin /sbin directory.
The /home directory
is the user directory, which is optional. For each ordinary user, there is a subdirectory named after the user name under the /home directory, which stores user-related configuration files.
The /root directory
is the directory of the root user. Correspondingly, the directory of ordinary users is a subdirectory under /home.
The contents of the /usr directory
/usr directory can be stored in another partition, and then mounted to the /usr directory in the root file system after the system starts. It stores shared, read-only programs and data, which means that the contents of the /usr directory can be shared among multiple hosts, and these mainly comply with the FHS standard. Files in /usr should be read-only, and other host-related and variable files should be stored in other directories, such as /var. The /usr directory can be reduced in embedded.
The /var directory
is the opposite of the /usr directory. The /var directory stores variable data, such as the spool directory (mail, news), log files, and temporary files.
The /proc directory
is an empty directory, often used as the mount point of the proc file system. The proc file system is a virtual file system. It has no actual storage device. The directories and files in it are temporarily generated by the kernel to represent The operating status of the system, and the file control system in it can also be operated.
The /mnt directory
is used to temporarily mount the mount point of a certain file system. It is usually an empty directory, and you can also create an empty subdirectory in it, such as /mnt/cdram /mnt/hda1. It is used to temporarily mount CDs and hard disks.
The /tmp directory
is used to store temporary files, usually an empty directory, under the /tmp directory used by some programs that need to generate temporary files, so the /tmp directory must exist and be accessible.