Why U-Boot is Needed1.1. Main Components of Computer Systems(1) A computer system is a system centered around the CPU. Typical computer systems include: PCs (desktop + laptop), embedded devices (smartphones, tablets, game consoles), and microcontrollers (home appliances like rice cookers, air conditioners).(2) There are many components that make up computer systems, and different computer systems have different components. However, the three main core components required for the operation of all computer systems are: CPU + External Storage (Flash/Hard Drive) + Internal Storage (DDR SDRAM/SDRAM/SRAM).1.2. Boot Process of a PC(1) Deployment: The BIOS program of a typical PC is deployed on the PC motherboard (pre-installed at the factory), the operating system is deployed on the hard drive, and the memory is non-functional during power loss; the CPU does not operate during power loss.(2) Boot Process: When the PC is powered on, the BIOS program (actually, the BIOS of the PC is NorFlash) is executed first. The BIOS program initializes the DDR memory, initializes the hard drive, reads the OS image from the hard drive into the DDR, and then jumps to the DDR to execute the OS until it boots (after the OS starts, the BIOS is no longer needed).1.3. Boot Process of a Typical Embedded Linux System(1) Deployment of a typical embedded system: The U-Boot program is deployed on Flash (Flash that can serve as a boot device), the OS is deployed on Flash (in embedded systems, Flash replaces the hard drive), and the memory is non-functional during power loss; the CPU does not operate during power loss.(2) Boot Process: When the embedded system is powered on, U-Boot is executed first, then U-Boot initializes DDR, initializes Flash, reads the OS from Flash into DDR, and then boots the OS (after the OS starts, U-Boot is no longer needed).Summary: The boot process of embedded systems and PCs is almost identical; only the BIOS has become U-Boot, and the hard drive has become Flash.1.4. Boot Process of the Android System(1) The boot process of the Android system is almost the same as that of Linux systems (the typical embedded system boot process described earlier). Almost the same means that the first part is completely identical, with differences occurring after the kernel starts and the root filesystem is loaded.(2) It can be considered that the boot process is divided into two stages: the first stage is from U-Boot to OS boot; the second stage is from OS boot to rootfs loading to command line execution. Currently, we mainly study the first stage; the difference between Android’s boot and Linux occurs in the second stage.1.5. Summary: What is U-Boot Used For?(1) The main function of U-Boot is to boot the operating system kernel.(2) U-Boot is also responsible for deploying the entire computer system.(3) U-Boot also includes drivers for operating Flash and other storage devices on the board.(4) U-Boot must provide a command line interface for user operations.2. Why U-Boot?2.1. Where Did U-Boot Come From?(1) U-Boot is an open-source project on SourceForge.(2) The author of the U-Boot project: a German initiated the project.(3) U-Boot was initiated by one person and has been maintained and developed collaboratively by everyone interested on the network.2.2. Development History of U-Boot(1) Initially a small open-source project used by individuals.(2) Gained recognition and use by more people.(3) Default support from SoC manufacturers.Summary: After years of development, U-Boot has become the de facto standard bootloader in the industry. Most embedded devices now default to using U-Boot as their bootloader.2.3. U-Boot Version Number Issues(1) Early U-Boot version numbers looked like this: U-Boot 1.3.4. Later, version numbers became like U-Boot-2010.06.(2) The core part of U-Boot has not changed much; newer versions support more development boards. For an older version of a chip, there is no difference between the old and new versions of U-Boot.2.4. Correct Understanding of U-Boot’s Portability(1) U-Boot is a universal bootloader, meaning it can be used in various settings. Therefore, U-Boot is portable.(2) U-Boot’s portability does not mean it can be used indiscriminately on any development board, but rather that U-Boot has the capability for source-level portability, allowing it to be ported to multiple development boards; once ported, it can be used on that development board.3. Problems U-Boot Must Solve3.1. Self-Booting Capability(1) General SoCs support multiple boot modes, such as SD card booting, NorFlash booting, NandFlash booting, etc. U-Boot must be designed according to the specific SoC’s boot design to enable booting.(2) U-Boot must make code-level changes and porting corresponding to the hardware to ensure it can boot from the respective boot medium. The start.S file in the first stage of U-Boot specifically handles this.3.2. Ability to Boot the Operating System Kernel and Pass Parameters(1) The ultimate goal of U-Boot is to boot the kernel.(2) The Linux kernel is designed to accept parameters. This means we can prepare some boot parameters in memory at a specific location in U-Boot and pass them to the kernel. After the kernel starts, it will go to this specific location to retrieve the parameters provided by U-Boot, which will guide the Linux kernel’s boot process.3.3. Ability to Provide System Deployment Functions(1) U-Boot must allow users to complete the entire system’s (including U-Boot, kernel, rootfs images) flashing and downloading work on Flash.(2) The bare-metal tutorial on flashing (part three of ARM bare-metal) uses the fastboot feature in U-Boot to flash various images to iNand and then boot from iNand.3.4. Ability to Manage SoC-Level and Board-Level Hardware(1) U-Boot implements some hardware control capabilities (initializes some hardware) because it must make these hardware work to complete some tasks. For example, U-Boot must drive iNand to implement flashing, must drive the LCD to display a progress bar during flashing, and must drive the serial port to provide an operation interface. U-Boot must also drive the network card chip to implement network functions.(2) SoC-level (e.g., serial port) refers to peripherals within the SoC, while board-level refers to hardware outside the SoC on the development board (e.g., network card, iNand).3.5. The “Lifecycle” of U-Boot(1) The lifecycle of U-Boot refers to when U-Boot starts running and when it stops running.(2) U-Boot is essentially a bare-metal program (not an operating system); once U-Boot starts, the SoC will run U-Boot exclusively (meaning no other programs can run while U-Boot is executing). Once U-Boot finishes running, it cannot return to U-Boot (so after U-Boot starts the kernel, U-Boot itself is terminated; to see the U-Boot interface again, the system must be restarted. Restarting does not revive the previous U-Boot; restarting is just another instance of U-Boot).(3) The entry and exit of U-Boot: U-Boot’s entry is the automatic startup upon power-on, and the only exit is the kernel startup. U-Boot can perform many other tasks (such as flashing the system), but after completing those tasks, it can return to the U-Boot command line to continue executing U-Boot commands; however, once the kernel startup command is executed, it cannot return.Summary: Everything is aimed at booting the kernel.4. How U-Boot Works4.1. Starting with the Bare-Metal Program Image U-Boot.bin(1) The essence of U-Boot is a bare-metal program, similar to those bare-metal programs we write as xx.bin. If there must be a distinction, it is that most of our programs are smaller than 16KB, while U-Boot is larger than 16KB (generally between 180k-400k).(2) U-Boot is an open-source project composed of several .c and .h files; after configuration and compilation, it generates an image file called U-Boot.bin, which is the bare-metal program image of U-Boot. This image file is properly flashed to the boot medium for the SoC to use to boot. In other words, when U-Boot is not running, it appears as U-Boot.bin, typically residing in the boot medium.(3) When U-Boot runs, it is loaded into memory and executed instruction by instruction by the CPU.4.2. U-Boot’s Command-Line Shell Interface(1) Ordinary bare-metal programs execute directly upon running, and the effect depends on the code.(2) Some programs need to interact with users, so a shell (which provides a human-machine interaction interface) is implemented in the program (recall the ARM bare-metal series, part sixteen). U-Boot implements a shell.Note: A shell is not an operating system and has no relation to an operating system. Opening a terminal in Linux gives you a shell where you can input commands and execute them. The shell in U-Boot works similarly to the terminal shell in Linux (almost identical, except for different command sets; for example, you can use ls in Linux, but U-Boot does not recognize ls).4.3. Two Key Points in Mastering U-Boot Usage: Commands and Environment Variables(1) Most of U-Boot’s time and work is done in the shell after startup (for example, deploying the system requires entering commands in the shell, setting environment variables also requires command-line input, and starting the kernel must also be done at the command line).(2) Commands are various commands recognized in U-Boot’s shell. U-Boot has dozens of commands, some common and some less common (we can also add our own commands to U-Boot). We will spend several sessions learning commonly used commands in U-Boot.(3) U-Boot’s environment variables work similarly to the environment variables in operating systems. U-Boot borrowed design concepts from operating systems (the command-line working style is inspired by Linux terminal commands, and environment variables borrow from operating system environment variables; U-Boot’s driver management closely follows the Linux driver framework).(4) Environment variables can be considered system-wide variables, and the names of environment variables are system built-in (you either know them or you don’t; this part consists of default environment variables, e.g., PATH; however, some environment variables are user-added, which the system does not recognize but we do). The system or our own programs can read environment variables to guide program execution. This design allows flexibility; for example, if we want a program to change its execution method, we can modify the corresponding environment variable without needing to modify the program code and recompile it.(5) Environment variables are runtime configuration attributes.5. Common U-Boot Commands 15.1. Line Buffering Command Line Similar to Linux Terminal(1) Line buffering means that when we input commands into the terminal command line, these commands are not immediately recognized by the system; instead, they are buffered in a cache (the system thinks we have not finished inputting). When we press the Enter key (newline), the system considers the input complete and analyzes all the commands in the buffer.(2) The Linux terminal design has three buffering mechanisms: no buffering, line buffering, and full buffering.(3) Some commands have simplified aliases; for example, the printenv command can be simplified to print, and setenv can be simplified to set.(4) Some commands will take parameters (note that the format is fixed). Each command in U-Boot has pre-defined formats. Some commands do not take parameters, such as printenv/print; some commands have optional parameters (which can be included or not, but including or excluding parameters results in different execution outcomes); some commands have mandatory parameters (such as setenv/set).(5) Use “help + command name” to query detailed information about a command; entering just help will print the command list.5.2. Special Symbols in Commands (e.g., Single Quotes)(1) Some commands in U-Boot take very long parameters. To indicate to U-Boot that this long parameter contains multiple spaces, we enclose it in single quotes.(2) Other symbols may also have specific meanings. When encountering special symbols in U-Boot’s command line, be careful not to confuse them; they may have special significance.5.3. Command Families (e.g., movi)(1) A command family means that multiple commands start with the same command keyword but have different parameters, each with different functions and effects. This is called a command family.(2) All commands in the same command family are closely related. For example, commands starting with movi are related to moviNand (EMMC, iNand) operations.5.4. First Command: printenv/print(1) The print command does not require parameters and serves to print all environment variables in the system.(2) Environment variables are like global variables in programs. Any part of the program can call or modify environment variables as needed (usually just calling). The difference between environment variables and global variables is that global variables exist during a single run of the program, created when the program starts and destroyed when it ends; when the program runs again, it starts from scratch. However, environment variables are stored in a dedicated area on Flash (there is an environment variable partition on Flash); once we save an environment variable in the program, its value will maintain the last changed value the next time the system boots.6. Common U-Boot Commands 21. Set (Add/Change) Environment Variables: setenv/setUsage: set name value2. Save Changes to Environment Variables: saveenv/saveThe saveenv/save command does not take parameters and is executed directly. It serves to synchronize the values of environment variables in memory to the Flash environment variable partition. Note: Saving environment variables is an overall overwrite, meaning that all environment variables in memory will completely overwrite the original content in the Flash environment variable partition.Summary: To thoroughly change the value of an environment variable, two steps are needed:The first step: Use the set command to change the environment variable in memory.The second step: Use the save command to synchronize it to the Flash environment variable partition.Sometimes we just want to test an environment variable without affecting the next boot; in that case, we only set but do not save. This way, the set command takes effect in the current run of U-Boot, but without saving, it will revert to its original state on the next boot.3. Network Testing Command: ping(1) Command usage: ping ip addressNote: Ping tests the network connection between the development board and the host. Follow these steps:1) First, plug in the network cable.2) Attempt to ping the host Windows. Note the address settings of the wired network card in Windows (set the local connection). Set the local connection IPv4 address in Windows to 192.168.1.10.3) The third step is to confirm that several network-related environment variable values in U-Boot on the development board are correct. The most important is ipaddr (this environment variable indicates the current IP address of the development board); this address must be in the same subnet as the host Windows IP address.Concept of subnet: An IP address consists of two parts: one part is the subnet address, and the other part is the host address within the subnet (distinguished by the subnet mask). In the case of a subnet mask of 255.255.255.0, the first three parts of the IP address 192.168.1.10 (192.168.1.) belong to the subnet address, and the fourth part (10) belongs to the host address.7. Successful Ping Between Development Board and HostThe result at the end of the last lesson was: the ipaddr in U-Boot and the host Windows local connection address were already set to the same subnet, but it still could not ping.We also observed the following phenomenon: 1) When I changed both subnets from 192.168.1.x to 192.168.0.x, it pinged once, but after that, it could not ping again; 2) Some students said that the inability to ping might be because the gatewayip in U-Boot was not set. I tested setting the gateway to .1 in the same subnet, and the conclusion was that it pinged successfully the first time, but could not ping again afterward.7.1. Ping Between Development Board Running Linux and Host Windows(1) First, flash the development board with a Linux + QT image (flashing is covered in the bare-metal tutorial, part three) and then start it in the Linux command line terminal.(2) In Linux, use the ifconfig command to set the IP address of the development board’s Linux system to be in the same subnet as the host Windows (for convenience in class, we will fix it: the host Windows address is 192.168.1.10, the development board’s U-Boot or Linux address is 192.168.1.20, and the virtual machine Ubuntu address is 192.168.1.141).(3) At this point, the development board can ping Windows.(4) The Windows system can also ping the development board.Conclusion: This indicates that both the hardware and network connections of the development board and host are functioning properly, and the network software settings in the host Windows are correct.7.2. Ping Between Development Board Running Linux and Virtual Machine Ubuntu(1) In the basic Linux course, we discussed that the virtual machine’s network card settings can choose several modes, commonly NAT and bridged (bridged).(2) The virtual machine can only communicate with the development board through the bridged mode.(3) To ensure the virtual machine can be pinged by the development board, follow these steps:First step: Set the virtual machine to bridged mode.Second step: In the virtual machine menu, there is a ‘Virtual Network Editor,’ where it should be set to bridge to the wired network card. (By default, it is automatic, which generally affects ping success. Since computers typically have two network cards—one wired and one wireless—if automatic is selected, the virtual machine will bridge to the wireless network card, but we are connecting the development board via the wired network card, so it naturally cannot ping).Third step: Set the IP address in the virtual machine Ubuntu to 192.168.1.141 (this can be done by setting it statically in the /etc/network/interfaces file and rebooting, or directly setting it through the command line with ifconfig).(4) At this point, the development board should be able to ping the virtual machine Ubuntu.(5) The virtual machine Ubuntu should also be able to ping the development board.7.3. Ping Between Development Board Running U-Boot and Host Windows(1) Since the development board was able to ping both Windows and the virtual machine Ubuntu while running Linux, it indicates that the hardware, connections, and host settings are correct.(2) Now, when the development board restarts and enters U-Boot, I set the ipaddr and gatewayip, then attempt to ping Windows and find that it still cannot ping. I suspect that there is an issue with U-Boot’s network driver.(3) I then tried to ping the virtual machine Ubuntu under the same conditions; theoretically, it should not ping, but it actually did.7.4. Ping Between Development Board Running U-Boot and Virtual Machine UbuntuU-Boot and the virtual machine Ubuntu can ping each other (provided that the virtual machine Ubuntu is set to bridged mode, bridged to the wired network card, and the IP address is set correctly).Conclusion: There seems to be a small bug in the U-Boot running on the development board, as it cannot ping Windows but can ping the virtual machine Ubuntu.8. Common U-Boot Commands 38.1. TFTP Download Command: tftp(1) The main goal of U-Boot is to boot the kernel, and to accomplish this, it must be able to deploy the kernel. U-Boot needs to download the kernel image from the host (Windows or virtual machine Ubuntu) and flash it to local Flash. There are many ways for U-Boot to download images to the development board; the mainstream methods are: fastboot and tftp.Fastboot transfers data via USB cable.TFTP transfers data over the wired network. This method is typical, while fastboot has only been developed in recent years.(2) When using TFTP, U-Boot acts as the TFTP client program, and a TFTP server must be set up on the host Windows or virtual machine Ubuntu. The image file to be downloaded should be placed in the server’s download directory, and then the tftp command in U-Boot can be used to download it.(3) Some people prefer to set up a TFTP server in Windows, usually using software like tftpd32, which is relatively simple to use; others prefer to set up a TFTP server in Linux. You can refer to the tutorial ‘Embedded Development Environment Setup – Based on 14.04.pdf’ in the virtual machine download directory on the cloud drive, which contains instructions for setting up a TFTP server in Ubuntu, or you can search online for tutorials to try. (If you are using my virtual machine, it is already set up, so no need to set it up again; if you installed it fresh, refer to the document to set it up; if your version is different from mine, the setup process may vary).(4) In my virtual machine setup, the TFTP download directory is /tftpboot, and the image to be downloaded should be copied to this directory.(5) Check the environment variables in U-Boot on the development board; note that serverip must be set to the IP address of the virtual machine Ubuntu. (The significance of the serverip environment variable is that it indicates the IP address of the TFTP server on the host).(6) Then, in U-Boot on the development board, first ping the virtual machine Ubuntu, and then attempt to download: tftp 0x30000000 zImage-qt (this means to download the file named zImage-qt from the server to the memory address 0x30000000 on the development board).(7) After the image is downloaded to the DDR of the development board, U-Boot can use the movi command to flash the image.Note:If you are using a TFTP server in Windows, then the serverip in U-Boot must be set to the same IP address as the TFTP server in Windows (there is a step in the TFTP server software setup where you set the server’s IP address, which must be in the same subnet as the host Windows).9. Common U-Boot Commands 49.1. SD Card/iNand Operation Command: movi(1) If the development board uses an SD card/EMMC/iNand as Flash, the command to operate Flash in U-Boot is movi (or mmc).(2) The movi command is a command set with many subcommands; you can view specific usage with help movi.(3) The movi commands are grouped into movi read and movi write. movi read is used to read from iNand to DDR, and movi write is used to write the content from DDR to iNand. When understanding these commands, pay attention to the two hardware components involved: iNand and DDR memory.(4) Command usage: movi read {u-boot | kernel} {addr}. This command uses a general description method: movi and read have no external markers indicating that each use of this command is mandatory; one part enclosed in curly braces {} is required; the vertical line in the braces indicates a choice; square brackets [] indicate optional parameters.(5) The command has various usages; for example, movi read u-boot 0x30000000 means to read the u-boot partition from iNand to the starting address 0x30000000 in DDR. (In the U-Boot code, iNand is divided into several partitions, each with a range of addresses and partition names; U-Boot can operate the iNand partition using either direct addresses or partition names). Note that 0x30000000 can also be written as 30000000; both mean the same thing (all numbers in U-Boot’s command line are treated as hexadecimal by default, regardless of whether you add 0x).9.2. NandFlash Operation Command: nandUnderstanding and operating methods are completely similar to the movi command.9.3. Memory Operation Commands: mm, mw, md(1) There are no partitions in DDR (only hard drives and Flash are partitioned, not memory). However, when using memory, it is crucial not to overwrite others’ data. Since U-Boot is a bare-metal program, unlike an operating system that manages all memory, U-Boot does not manage all memory; memory is used freely. If the programmer (the user of U-Boot) is not careful, they may accidentally overwrite their own data. (So consider why we place U-Boot at address 23E00000).(2) md stands for memory display, used to display the contents of memory.(3) mw stands for memory write, used to write content to memory.(4) mm stands for memory modify, which modifies a specific block in memory; in other words, it is still writing to memory (if you need to modify memory in bulk, mm is the most suitable).9.4. Kernel Startup Commands: bootm, go(1) The ultimate goal of U-Boot is to boot the kernel, and booting the kernel in U-Boot is represented by a command; calling this command in the U-Boot command line will start the kernel (regardless of success or failure, so this command leads to a dead end).(2) Differences: bootm starts the kernel while passing parameters to it, whereas the go command starts the kernel without passing parameters. bootm is actually the proper command for starting the kernel, which is generally used; the go command was not originally designed for kernel startup. Internally, the go command is a function pointer that points to a memory address and directly calls that function. The essence of the go command is that the PC jumps to a memory address to execute it. The go command can be used to execute any bare-metal program in U-Boot (one debugging method for bare-metal programs is to start U-Boot first, then download the bare-metal program in U-Boot and use the go command to execute it).10. Common Environment Variables in U-Boot 110.1. How Environment Variables Participate in Program Execution(1) There are two copies of environment variables: one in Flash and one in DDR. U-Boot reads all environment variables from Flash into DDR at boot as the initialization values for the environment variables. During use, only the DDR copy is utilized, and users can use the saveenv command to write the DDR environment variables back to Flash to update the Flash environment variables. The next time the system boots, it will read from Flash again.(2) Environment variables in U-Boot are represented as strings, meaning U-Boot distinguishes each environment variable through character matching. Therefore, be careful not to misspell them when using.1. Auto-Run Countdown: bootdelay2. 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 uses the tftp command to download items.(3) gatewayip is the local gateway address of the development board.(4) netmask is the subnet mask.(5) ethaddr is the MAC address of the development board’s network card.11. Common Environment Variables in U-Boot 211.1. Setting Auto-Run Commands: bootcmd(1) After U-Boot starts, it will count down bootdelay seconds. If no one presses Enter to interrupt the startup, U-Boot will automatically execute the startup command to boot the kernel.(2) The auto-start of U-Boot actually executes the command set corresponding to the value of the bootcmd environment variable internally: bootcmd=movi read kernel 30008000; bootm 30008000.This means: read the kernel partition from iNand into DDR memory at address 0x30008000, and then use the bootm command to start the kernel from memory at 0x30008000.(3) Set bootcmd printenv, then saveenv; after restarting, you will see the printenv command automatically executed after the countdown. This small experiment demonstrates that bootcmd is executed automatically at startup.(4) To set the bootcmd environment variable: set bootcmd ‘movi read kernel 30008000; bootm 30008000’.11.2. U-Boot Passing Parameters to Kernel: bootargs(1) The Linux kernel can receive boot parameters passed to it by U-Boot during startup. These boot parameters are in a form and content agreed upon by U-Boot and the kernel, guiding the Linux kernel’s startup process. This design aims for flexibility, allowing the kernel to start differently without recompiling.(2) What we need to do is set bootargs in U-Boot’s environment variables, and then the bootm command will automatically pass bootargs to the kernel when starting it.(3) The environment variable bootargs=console=ttySAC2,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext3.Meaning explanation:console=ttySAC2,115200 indicates that the console uses serial port 2 at a baud rate of 115200.root=/dev/mmcblk0p2 rw indicates that the root filesystem is on the SD card port 0 device (iNand) in the second partition, and the root filesystem is readable and writable.init=/linuxrc indicates the path of the Linux process 1 (init process).rootfstype=ext3 indicates that the type of the root filesystem is ext3.(4) Passing parameters to the kernel is very important. During kernel porting, novices often forget to pass parameters to the kernel or pass incorrect parameters, resulting in the kernel failing to boot.11.3. Methods to Create, Change, and Delete an Environment Variable(1) To create a new environment variable, use set var value.(2) To change an environment variable, use set var value.(3) To delete an environment variable, use set var.Note: After modifying environment variables, be sure to save them; otherwise, the changes will be lost on the next boot.12. U-Boot’s Management of Flash and DDR12.1. Flash Partitioning in U-Boot Stage(1) Partitioning is the process of managing Flash in blocks.(2) In products like PCs, because everyone uses hard drives under the operating system, the entire hard drive is managed uniformly by the operating system, which uses a file system to manage hard drive space (ensuring that files do not overlap). Thus, users do not need to worry too much about partitioning.(3) In U-Boot, there is no operating system; therefore, we must define partitions for Flash (equivalent to hard drives). In U-Boot and the kernel, there is a partition table, which is the method of overall management and allocation of Flash during system porting. With this definition, we can deploy the system according to the partitioning method, and the software of U-Boot and the kernel will work according to this partitioning method without error.(4) The partitioning method is not fixed and can be changed. However, in a porting project, it must be predetermined. Generally, during system porting design, it will be determined, and the standard is:U-Boot must be stored at the starting address of Flash (this could be sector 0, sector 1, or another location, depending on the SoC’s boot design), and the size of the U-Boot partition must ensure that U-Boot can fit; it is generally designed to be 512KB or 1MB (since U-Boot generally does not exceed 512KB, making it larger is possible but wasteful);The environment variable partition is generally stored adjacent to U-Boot, with a size of 32KB or slightly larger.The kernel can be stored adjacent to the environment variable, typically sized at 3MB or 5MB or other sizes.rootfs:······The remaining space is free partitioning; generally, after the kernel starts, this free partition is mounted under rootfs for use.Summary: The general rules are as follows:(1) Each partition is connected, with the end of one partition being the start of the next.(2) The entire Flash is fully utilized, from start to finish.(3) U-Boot must be at the beginning of Flash; the relative positions of other partitions can vary.(4) The sizes of each partition are determined by the system porting engineer, generally chosen to be appropriate (not too small, as that risks overflow; not too large, as that wastes space).(5) The partitioning must be determined before system porting, and the same partition table must be used in U-Boot and the kernel. In the future, during system deployment, the partitioning method in the system code must also match.12.2. DDR Partitioning in U-Boot Stage(1) The partitioning of DDR differs from that of Flash, mainly because Flash retains its data when powered off, while DDR loses its data when powered off, meaning DDR is allocated and used only during each system run.(2) Memory partitioning mainly occurs before the Linux kernel starts; after the kernel starts, the kernel’s memory management module takes over the entire memory space, and then we no longer need to manage it.(3) The key to memory partitioning is to allocate specific memory blocks for specific functions to avoid different functions using the same memory block and causing conflicts. For example, if we use tftp 0x23E00000 zImage to download zImage to the 0x23E00000 address, it will result in an error because this address is where the U-Boot image resides. Downloading here would overwrite the U-Boot in memory.
– END –
Source: “Electronic Engineering Magazine”
Optoelectronic Sensing
Smart Manufacturing