Why should there be a uboot? Take you to fully analyze the role of uboot in the boot process of embedded Linux system

1. Why should there be uboot

1.1, the main components of the computer system

(1) The computer system is the CPU as the core to run systems. Typical computer systems are: PC (desktop + notebook), embedded devices (mobile phones, tablets, game consoles), single-chip microcomputer (household appliances like rice cookers, air conditioners)

(2) Computer system components are very many, different computer system components are different. But all the main core components needed to run a computer system are 3 things:

CPU + external memory (flash/HDD) + Internal memory (DDR Sdram/sdram/sram)

1.2, the PC startup process

(1) Deployment: The typical PC BIOS program is deployed on the PC motherboard (as the motherboard has been prefabricated), the operating system is deployed on the hard disk, there is no effect of power down, the CPU does not work when power down.

(2) Start-up process: the PC after power on the first implementation of the BIOS program (in fact, the bios of the PC is Norflash), the BIOS program is responsible for initializing the DDR memory, is responsible for initializing the hard disk, and then from the hard disk to read the OS image into the DDR, Then jump into the DDR to execute the OS until it starts (the BIOS is useless after OS boot)

1.3. Typical embedded Linux system startup process

(1) Deployment of a typical embedded system: The Uboot program is deployed in Flash (which can be used as the boot device flash), the OS is deployed in Flash (embedded system with flash instead of the hard drive), the memory is not in power-down, the CPU does not work when power is lost.

(2) Start-up process: The embedded system executes Uboot first, then Uboot is responsible for initializing the DDR, initializing the Flash, then reading the OS from Flash into the DDR, and then starting the OS (Uboot is useless after OS startup)

Summary: The startup process of the embedded system and PC is almost the same, but the BIOS becomes the uboot, the hard disk becomes flash.

1.4. Android System startup process

(1) The startup of the Android system is almost the same as the Linux system (the typical embedded system boot mentioned earlier). Almost the same means that the front is exactly the same, but it is different after the kernel starts loading the root filesystem.

(2) It can be considered that the start-up is divided into 2 stages: The first phase is uboot to OS boot, the second stage is OS boot to rootfs loading to the command line execution; Now we are mainly studying the first stage, the Android startup and Linux differences in the second phase.

1.5. Summary: What the hell is uboot?

(1) The main function of Uboot is to start the operating system kernel.

(2) Uboot is also responsible for the deployment of the entire computer system.

(3) Uboot in the operation of Flash and other boards on the drive.

(4) Uboot also has to provide a command line interface for people to operate.

2. Why is Uboot

2.1. Where did Uboot come from?

(1) Uboot is an open source project on SourceForge.

(2) One of the first Germans to launch the Uboot project

(3) Uboot is initiated by a person, and then by the entire network of all interested people together to maintain the development of a bootloader.

2.2. The development course of Uboot

(1) Self-employed small open source projects.

(2) be accepted by more people

(3) supported by the SOC vendor by default.

Summary: Uboot After years of development, has become the de facto industry bootloader standards. Most embedded devices now use Uboot as bootloader by default.

2.3, the Uboot version number problem

(1) The version number of the earlier uboot is similar to this: uboot1.3.4. Later the version number became similar to uboot-2010.06.

(2) The core of the uboot is almost unchanged, the newer version supports more development boards, for an older version of the chip, the old and new versions of the Uboot are not different.

2.4. Correct understanding of portability of uboot

(1) Uboot is universal bootloader (generic startup code), universal means can be used in all kinds of places. Therefore, Uboot is portable.

(2) Uboot portability is not to say uboot in which Development board can be used casually, but that Uboot has at the source code level of the porting ability, can be for a number of development boards for porting, after the transplant can be used on the Development Board.

3.uboot What problems must be resolved

3.1, self-powered direct start

(1) The General Soc supports a variety of start-up methods, such as SD card boot, Norflash start, Nandflash startup, etc. Uboot to be able to boot, the uboot must be designed according to the specific SOC start-up design.

(2) Uboot must perform code-level changes and migrations corresponding to the hardware to ensure that it can be started from the appropriate boot media. Start of the first phase of the uboot. The S file specifically deals with this piece.

3.2, be able to boot the operating system kernel to boot and send 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 transmitted. That is, we can in uboot in advance to the Linux kernel to prepare some of the boot parameters in memory and then to the kernel, the kernel will go to this specific location to take Uboot passed to his parameters, and then parse these parameters in the kernel, These parameters will be used to guide the boot process of the Linux kernel.

3.3, can provide the system deployment function

(1) Uboot must be able to be used by people to complete the entire system (including Uboot, kernel, ROOTFS, etc.) on the flash on the burning download work.

(2) The bare metal tutorial in the brush machine (arm bare metal Third part) is the use of uboot in the FastBoot function to burn various images to Inand, and then start from Inand.

3.4 Ability to manage SOC-and board-level hardware

(1) A part of the hardware control capability is implemented in Uboot (part of the hardware is initialized in uboot) because Uboot has to work on the hardware in order to accomplish some tasks. For example, uboot to achieve the brush must be able to drive the inand, such as Uboot to the LCD on the screen to display the progress bar must be able to drive the LCD, such as uboot can provide the interface through the serial port must drive the serial port. For example, to realize network function, Uboot must drive the NIC chip.

(2) Soc level (such as serial port) is the SOC internal peripherals, board level is the SOC outside the Development Board hardware (such as network card, Inand)

3.5. Uboot "Life cycle"

(1) Uboot life cycle means: Uboot When to start running, when the end of the run.

(2) Uboot is essentially a bare-metal program (not the operating system), once the Uboot starts the SOC will simply run uboot (meaning that the uboot run when the other program is not possible to run at the same time), Once the uboot is finished, it is no longer possible to return to Uboot (so uboot starts the kernel and uboot itself is dead, to see that the Uboot interface can only restart the system. Restarting is not the resurrection of the uboot just now, restarting just Uboot's other life)

(3) Entrance and exit of Uboot. Uboot's entrance is the boot automatically start, Uboot's only exit is the boot kernel. Uboot can also perform many other tasks (such as burning the system), but all other tasks can go back to the Uboot command line to continue executing the uboot command, and the boot kernel command will not return once it is executed.

Summary: Everything is to start the kernel

How the 4.uboot works

4.1, from the bare metal program image Uboot.bin talk about

(1) The essence of Uboot is a bare-metal program, and there is no essential difference between those bare-metal programs written in our bare-metal complete xx.bin. If there is a difference, it is: most of us write less than 16KB, and uboot greater than 16KB (general uboot between 180k-400k)

(2) Uboot itself is an open source project, consisting of several. c files and. h files, and a uboot.bin is generated after the configuration is compiled, which is the image file for uboot this bare-metal program. The image file is then properly burned to the boot media for booting to the SOC. In other words, Uboot is uboot.bin when it is not running and generally lies in the boot media.

(3) The Uboot runtime is loaded into memory and then an instruction is directed to the CPU to run.

4.2. Uboot command Shell interface

(1) Ordinary bare-metal programs run directly to execute, and the execution of the effect and code-related.

(2) Some programs need to interact with people, so that the program implemented a shell (the shell is to provide an interface of human-computer interaction, recalling the arm bare Metal Complete part 16th), Uboot implemented a shell.

Note: The shell is not an operating system and has nothing to do with the operating system. After you open a terminal in Linux, you get a shell that you can enter to perform the command return. The way the shell works in Uboot is very much like the terminal Shell in Linux (it's almost the same, but the command set is different.) For example, Linux can be ls,uboot in the LS is not recognized)

4.3. Mastering the 2 key points used by Uboot: command and environment variables

(1) Uboot after startup most of the time and work is done under the shell (for example, uboot to deploy the system to the shell to lose command, to set the environment variable is also on the command line underground, to start the kernel also to the command line under the command)

(2) The command is a variety of commands that can be identified in the Uboot shell. There are dozens of commands in Uboot, some of which are often not used (we can also add commands to uboot ourselves), followed by several classes of time to learn the commands commonly used in Uboot.

(3) Uboot environment variables and operating system environment variables work almost exactly the same way. Uboot in the design of the use of the operating system design concept (command-line mode of operation borrowed from the Linux Terminal command line, environment variables for reference to the operating system environment variables, Uboot Drive management almost completely copied the Linux driver framework).

(4) Environment variables can be considered as the global variables of the system, the environment variable name is the system built-in (understanding, do not know, it is not known, this part of the system comes with the default environment variables, such as path; but some of the environment variables are added by themselves, the system they add does not know but we know it). The system or our own programs can guide the program's operation by reading the environment variables at run time. The advantage of this design is flexibility, for example, we want a program to change the running method, not to re-modify the program code and then recompile the run, as long as the corresponding environment variables can be modified.

(5) The environment variable is the configuration property at runtime.

Common commands for 5.uboot 1

5.1. Line buffer command line similar to Linux terminal

(1) The meaning of the line buffer is: When we enter commands to the terminal command line, these commands are not immediately recognized by the system, but are buffered to a buffer (that is, the system thinks we have not entered), when we press ENTER (line break), the system thinks we have entered, It then takes all the input in the buffer as the command to parse the processing.

(2) Linux terminal design has 3 kinds of buffering mechanism: No buffering, row buffering, full buffering

(3) Some commands have simplified aliases, such as the printenv command can be simplified to print, such as setenv can be simplified to set

(4) Some commands take parameters (note that the format is fixed), uboot each command has a predetermined format. Some commands are not parameters, such as the Printenv/print command, some commands with optional parameters (can or without, of course, with no parameters of the execution result is different); some commands have the necessary parameters (such as the Setenv/set command)

(5) Use "help+ command name" to query the command details, only enter help, then print out a list of commands.

5.2. Special symbols in commands (such as single quotes)

(1) Uboot Some of the parameters of the belt is very long, in order to tell Uboot this very long and a lot of space in the middle of the thing is to give him a whole parameter, so in single quotation marks this very long and space between the parameters of the argument is caused.

(2) Other symbols may also have, and have specific meanings. When encountering Uboot's command line with special symbols, be careful not to make a mistake, but may have a special meaning.

5.3. Some commands are a command family (e.g. movi)

(1) The command family means that multiple commands start with the same command keyword, but the following parameters are different, and the functions and roles of these commands are not the same. This is called a command family.

(2) All commands in the same command family are highly correlated, for example, the command families beginning with movi are related to Movinand (EMMC, Inand) operations.

5.4. First command: Printenv/print

(1) The Print command does not take parameters, it is the function of printing out all the environment variables in the system.

(2) Environment variables are like the global variables of a program. Anywhere in the program can call or change the environment variables (generally called), environment variables and global variables are different in that: the life cycle of the global variable is in one run of the program, the beginning of the run when the birth program ends at the end of death, the next time you run the program from the beginning But the environment variable is stored in another special area of Flash (there is an environment variable partition on the Flash), and once we save the environment variable in the program, the value of the environment variable will maintain the last change value after the next boot.

Common commands for 6.uboot 2

1. Set (Add/change) environment variables: setenv/set

Usage: Set Name value

2. Save changes to environment variables: saveenv/save

The Saveenv/save command executes directly with no parameters, saving the value of the environment variable in memory to the partition of the environment variable in Flash. Note: The environment variable is saved as a whole, which means that all the environment variables in memory will be overall overwritten with the original contents of the environment variable partition in Flash.

Summary: It takes 2 steps to completely change the value of an environment variable:

First step: Set command to change environment variables in memory

Step two: Synchronize it to the partition of the environment variable in flash with the Save command.

Sometimes we just want to test this environment variable, do not want to affect the next boot, then only set not save, so set after the current operation of the uboot has been effective, but no save the next boot or will revert to the original situation.

3. Network Test instruction: Ping

(1) Command usage: Ping IP address

Note: Ping is a network link between the test board and the host, note the following steps:

1) First to plug in the network cable.

2) Try to ping the host Windows first. Note the address settings for the wired network card in Windows (set up local Area connection). Set local connection for host Windows IPv4 address is 192.168.1.10

3) The third step is to confirm the value of several network-related environment variables in the Uboot in the Development Board right. The most important is ipaddr (this environment variable represents the IP address of the current Development Board), which must be the same network segment as the host Windows IP address.

Network Segment concept: An IP address is divided into 2 parts, part of the network segment address, the other part is the network segment of the host address (subnet mask to distinguish which part is the network segment address, which part is the IP address). In the case where the subnet mask is 255.255.255.0, 192.168.1.10 the first three parts of this IP address (192.168.1.) belong to the network segment address, and section 4 (10) belongs to the host address.

7. Ping of the Development Board and the host

The final result of the last lesson is that the ipaddr in Uboot and the host Windows Local Area Connection address have been set to a network segment, but the actual ping does not pass.

Also found that the phenomenon: 1, I put 2 of the network segment from 192.168.1.x to 192.168.0.x will be ping once, the second start on the ping does not pass; 2, some students say ping is not possible because the Uboot Gatewayip not set, I will actually test the settings for the same network segment. 1, again test the conclusion is the first ping pass, the second start is not through.

7.1, the Development Board runs Linux under and the host Windows Ping Pass

(1) The development of the scrub brush machine into a LINUX+QT image (brush machine See the third part of the bare metal tutorial), and then launch into the Linux command line terminal.

(2) Under Linux, use the Ifconfig command to set the IP address of the Linux system in the board to the same network segment as the host Windows (for class convenience, Fixed later: Host Windows Address 192.168.1.10, Development Board Uboot or Linux address is 192.168.1.20, Virtual machine Ubuntu address is 192.168.1.141)

(3) At this time the Development Board end ping Windows pass.

(4) The Ping Development Board in Windows is also a pass.

Description: First Development Board and host network part of the hardware is good, network connection is good, host Windows network software Settings is good.

7.2, the Development Board runs Linux under and the virtual machine Ubuntu Ping Pass

(1) In the Linux Basic Course said: Virtual Machine network card settings can be selected several ways, commonly used is NAT and bridging (bridged).

(2) Virtual Confidential and Development Board for network communication, can only be connected by bridging mode.

(3) Virtual Confidential want to be developed board Ping Pass, set the steps as follows:

The first step: the virtual machine is set up as a bridging mode.

The second step: the Virtual Machine menu has a "virtual network editor", where the face is set to bridge to the wired network card. (The default is automatic, and automatic usually affects the ping pass.) Because the computer now generally has 2 network cards: A wired one wireless. If you choose Automatic, then the virtual opportunity to automatically bridge to the wireless card, but we are through the wired network card to connect the development Board, Natural Ping does not pass)

The third step: in the virtual machine Ubuntu set the IP address is 192.168.1.141 (can be set by the/etc/network/interfaces file to reset the static and then restart; you can also directly command line ifconfig to set)

(4) At this point the Development Board ping Virtual machine Ubuntu should be on the pass.

(5) At this time the virtual machine Ubuntu Ping Development Board is also pass.

7.3, the Development Board runs Uboot and the host Windows Ping Pass

(1) Just before the Development Board ran Linux and the host Windows, virtual machine Ubuntu are ping, the hardware and the connection and host settings are correct.

(2) At this time the Development Board restart into the Uboot, set up a good ipaddr, Gatewayip, and then go to ping windows found is still not through. Suspect that Uboot itself has a problem with the network driver.

(3) Then the same situation to try to ping the virtual machine Ubuntu, theoretical analysis should also not pass, but the actual discovery is through.

7.4, the Development Board runs Uboot and the virtual machine Ubuntu Ping Pass

Uboot and virtual machine Ubuntu ping each other (provided that the virtual machine Ubuntu is set to bridge, and the bridge to the wired network card, and the IP address is set correctly)

Conclusion: The uboot running in the development Board is a bit small bug,ping windows will not pass, ping the virtual machine Ubuntu on the pass.

8.uboot Common Commands 3

8.1. TFTP download Instructions: TFTP

(1) The main goal of the Uboot itself is to start the kernel, in order to complete the boot kernel must be able to deploy the kernel, uboot in order to deploy the kernel will need to download kernel image from the host and then burn to local flash. Uboot How do I download the image from the host (Windows or virtual machine Ubuntu) to the Development Board? There are many ways to mainstream the way: FastBoot and TFTP.

The FastBoot method is to transmit data via USB cable.

The TFTP method is through the wired network. The typical way is through the network, FastBoot is a new development in recent years.

(2) When TFTP is actually downloaded, the Uboot acts as a TFTP client program role, the host Windows or virtual machine Ubuntu must have a TFTP server, and then the image file to be downloaded is placed in the server's download directory, Then use the Uboot TFTP command in the Development Board to download.

(3) Some people are accustomed to build a TFTP server in Windows, usually with some software (such as TFTPD32, easy to use); some people are accustomed to build a TFTP server under Linux, you can refer to a tutorial under the virtual machine download directory in the network disk Built-in embedded development environment-based on 14.04.pdf, there is a tutorial on setting up a TFTP server in Ubuntu, or you can search for tutorials online. (If you use my virtual machine directly, it has been set up, no longer set up, if it is their own clothes, then refer to the document building; If your version is different from mine, the build process may be different)

(4) When my virtual machine is set up, the TFTP download directory is/tftpboot and the image to be downloaded will be copied to this directory.

(5) Check the environment variables of the Development Board Uboot, note that ServerIP must be set to the IP address of the virtual machine Ubuntu. (ServerIP the meaning of this environment variable is the IP address of the host TFTP server)

(6) Then ping the virtual machine Ubuntu under the uboot of the Development Board before attempting to download: TFTP 0x30000000 zimage-qt (meaning to download the file named ZIMAGE-QT on the server to the 0x30000000 address of the board memory.) ）

(7) After the image is downloaded to the DDR in the Development Board, the uboot can be burned with the movi instruction.

Attention:

If you are using a TFTP server under Windows, then the Uboot ServerIP will be set to the same IP address as the TFTP server under the Windwos (there is a step in the TFTP Server Software setup under Windows that allows you to set the IP address of the server. This IP address and host Windows must be in a network segment).

Common commands for 9.uboot 4

9.1, SD card/inand operation instruction Movi

(1) If the Development Board uses SD card/emmc/inand and so on as Flash, then the command to operate flash in Uboot is movi (or MMC)

(2) Movi command is a set of commands, there are many subcommands, the specific use can help movi view.

(3) Movi instructions are movi Read and movi write group, movi read is used to read Inand to the DDR, and Movi write is used to write the contents of the DDR to Inand. When you understand these instructions, be aware of the 2 hardware involved: Inand and DDR memory.

(4) movi Read {u-boot | kernel} {ADDR} This command uses a general-purpose descriptive method to describe: There is no markup outside of Movi and read stating that each use of this instruction is required, and that a pair of braces {} must be selected in 1 ; The vertical bar table in curly braces is more than one; brackets [] indicate optional parameters

(5) Instructions are used in many ways, such as Movi read U-boot 0x30000000, which means that the U-boot partition in the Inand is read out to the location where the 0x30000000 of the DDR begins. (The Uboot code divides the Inand into many partitions, each with an address range and a partition name, a uboot program operation that uses a direct address to manipulate the Inand partition, or a partition name to manipulate a partition.) Note that the 0x30000000 can also write 30000000 directly, meaning the same (all the numbers in the Uboot command line are treated by default as hexadecimal, whether you add 0x or not).

9.2. Nandflash Operation Instruction NAND

Understanding methods and operating methods are exactly similar to movi directives

9.3, Memory operation instruction: MM, MW, MD

(1) There is no partition in the DDR (only heard of the hard disk, flash partition, have not heard of the memory partition. ), but memory use should be aware that you must not cross the border to step on someone else. Because Uboot is a bare-metal program, unlike an operating system that manages all of the memory from the system as a whole, the system is responsible for allocation and management, and the system ensures that memory does not cross over. Then the bare-metal program Uboot does not manage all the memory, the memory is random, so if the programmer (the person who uses uboot) does not pay attention to it may appear that they have their own data to cover. (So you think about why we put Uboot at 23E00000 addresses)

(2) The MD is the memory display, which is used to display the contents of the RAM.

(3) MW is memory write, writes the contents to the RAM

(4) mm is the memory modify, modify a piece of RAM, white or write memory (if you need to batch-by-unit modification memory, with mm most suitable)

9.4. Boot kernel command: BOOTM, go

(1) The ultimate goal of Uboot is to start the kernel, the boot kernel in uboot as an instruction, Uboot command line call this command will start the kernel (whether successful or not, so this command is a dead end).

(2) Difference: BOOTM boot kernel simultaneously to the kernel parameters, and go command to start the kernel does not pass the parameter. Bootm is actually the original command to boot the kernel, generally use this; Go command is not designed for the boot kernel, the Go command is actually a function pointer to a memory address and then directly call that function, the essence of the Go command is the PC directly to a memory address to run it. The GO command can be used to execute any bare-metal program in Uboot (one way to debug a bare-metal program is to start Uboot in advance, then download the bare-metal program in Uboot and go to execute the bare-metal program with the Go command)

Common environment variables for 10.uboot 1

10.1. How environment variables participate in program operation

(1) There are 2 environmental variables, one in Flash and the other in DDR. Uboot Read all environment variables from flash to DDR as initialization values for environment variables at boot time, and then use this part in DDR, the user can use the saveenv instruction to re-write environment variables in the DDR to Flash to update the environment variables in Flash. The next time you turn it on, you'll read it again from Flash.

(2) The environment variable is represented by a string in Uboot, that is to say, the uboot is to distinguish each environment variable in the way of character matching. So use it when you must be careful not to hit a typo.

1. Auto-run countdown time: BootDelay

2, network settings: IPAddr ServerIP

(1) ipaddr is the local IP address of the Development Board

(2) ServerIP is the IP address of the TFTP server when the Development Board downloads something from the TFTP server via the TFTP instructions.

(3) Gatewayip is the local gateway address of the Development Board

(4) netmask is a subnet mask

(5) ETHADDR is the MAC address of the local network card of the Development Board.

Common environment variables for 11.uboot 2

11.1, autorun command settings: bootcmd

(1) uboot start automatically countdown bootdelay seconds, if no one press ENTER interrupt start, then Uboot will automatically execute the start command to start the kernel.

(2) Uboot boot automatically when the actual execution of the BOOTCMD this environment variable value corresponding command set: Bootcmd=movi read kernel 30008000; Bootm 30008000

This means: Read the Inand kernel partition to the 0x30008000 address of the DDR memory, and then use the BOOTM startup command to boot the kernel from memory 0x30008000.

(3) Set Bootcmd printenv, then saveenv, then restart will see the auto-execute printenv command after the countdown to print out the environment variables. This small experiment shows that the boot automatically executes the bootcmd.

(4) Setting BOOTCMD environment variable: set Bootcmd ' movi read kernel 30008000; Bootm 30008000 '

11.2, uboot to kernel: Bootargs

(1) When the Linux kernel starts, it can receive the boot parameters uboot to him, these boot parameters are the form and content of uboot and kernel conventions, and the Linux kernel completes the boot process under the guidance of these boot parameters. This is designed to be flexible, so that the kernel can be started in different ways without recompiling.

(2) The thing we have to do is to set the Bootargs in the UBOOT environment variable and BOOTM the Bootargs to the kernel when the command is started.

(3) environment variable bootargs=console=ttysac2,115200 root=/dev/mmcblk0p2 RW init=/linuxrc rootfstype=ext3

Meaning explanation:

The CONSOLE=TTYSAC2,115200 console uses a serial port of 2 and a baud rate of 115200.

ROOT=/DEV/MMCBLK0P2 RW root file system on SD card Port 0 Device (Inand) 2nd partition, the root filesystem is readable and writable

INIT=/LINUXRC Path of Process 1 (init process) for Linux

The type of ROOTFSTYPE=EXT3 root file system is ext3

(4) kernel parameters are important. When the kernel is migrated, the novice often forgets to give the kernel a parameter, or the kernel passes the wrong parameters, causing the kernel to boot up.

11.3. How to create, change, and delete an environment variable

(1) Create a new environment variable using the set var value

(2) Changing an environment variable, using set var value

(3) Delete an environment variable, using set var

Note: Be sure to save after modifying the environment variables, otherwise the next boot change is gone.

Management of Flash and DDR in 12.uboot

12.1. Uboot Stage Flash partition

(1) The so-called partition, that is, the flash of the block management.

(2) PC and other products, because everyone is using the hard disk under the operating system, the entire hard drive by the operating system unified management, the operating system will use the file system to help us manage hard disk space. (management ensures that files don't stack with each other), so users don't have to be too concerned about partitioning issues.

(3) There is no operating system in the Uboot, so we have to use the flash (equivalent to hard disk) management must be used in advance partition definition (in fact, there is a partition table in Uboot and kernel, partition table is the overall management of flash when we do the system migration method). With this definition, we deploy the system in accordance with the partitioning method, and Uboot and kernel also work in accordance with this partition definition.

(4) The partitioning method is not certain, not fixed, and can be changed. However, in a transplant must be designed in advance to die, generally in the design system transplant will be set, the standard is:

Uboot:uboot must be stored from the Flash start address (perhaps sector 0, perhaps sector 1, perhaps other, depending on the SOC's boot design), the size of the Uboot partition must be guaranteed to uboot down, The general design is 512KB or 1MB (because the general uboot certainly less than 512KB, to big can actually also work, but waste);

Environment variables: The environment variable partition is usually kept close to the uboot, size 32KB or more.

Kernel:kernel can be stored close to the environment variables, generally 3MB or 5MB or other.

Rootfs:

The rest is the free partition, the general kernel boot after the free partition mount to rootfs use

Summary: The general rule is as follows:

(1) Each partition is connected to each other, and the end of the previous partition is the beginning of the next partition.

(2) The entire flash is fully utilized, from the beginning to the end.

(3) Uboot must be at the beginning of Flash, the relative position of other partitions is variable.

(4) The size of each partition is determined by the system transplant engineer himself, generally set as the appropriate size (not too small, too small easy overflow; not too big, too big wasted space)

(5) Partitions are determined before the system is migrated, using the same partition table in Uboot and kernel. The partitioning method in future system deployment and system code must also be the same.

12.2. Uboot stage DDR partition

(1) The partition of DDR and the partition of Flash are different, mainly because the flash is a power-down, and the DDR is lost power, so it can be said that the DDR is used every time the system runs.

(2) The memory partition is mainly before the Linux kernel boot up, the kernel memory management module after the Linux kernel boot will take over the entire memory space, then we do not have to control.

(3) Note that the key to memory partitioning is what is used in memory for what to do must be allocated in order to avoid different functions using the same piece of memory caused by the mutual trampling. For example, we tftp 0x23e00000 zimage to download zimage to the memory of the 0x23e00000 error, because this memory is actually the uboot image is located. This will cause the downloaded zimage to flush out the uboot in memory.

Why should there be a uboot? Take you to fully analyze the role of uboot in the boot process of embedded Linux system