Essential U-Boot Knowledge for Embedded Beginners

This article has been authorized for reprint by Embedded ARM (Original) Author: Fu Bin. Please contact the source for reprinting.

Why is U-Boot needed?

1. Main components of a computer system

(1) A computer system is a system that operates with the CPU at its core.

Typical computer systems include:

PCs (desktop + laptop)

Embedded devices (phones, tablets, game consoles)

Microcontrollers (home appliances like rice cookers, air conditioners)

(2) There are many components that make up a computer system, and different computer systems have different components. However, all computer systems require three main core components to operate:

CPU + External storage (Flash/hard drive) + Internal storage (DDR SDRAM/SDRAM/SRAM)

2. Boot process of a PC

(1) Deployment:

Typical BIOS programs of a PC are deployed on the motherboard (pre-installed at the factory), the operating system is deployed on the hard drive, memory is ineffective during power loss, and the CPU does not operate during power loss.

(2) Boot process:

When the PC is powered on, it first executes the BIOS program (which is actually NorFlash), the BIOS program is responsible for initializing DDR memory, initializing the hard drive, then reading the OS image from the hard drive into DDR, and then jumping to execute the OS until it boots (once the OS boots, the BIOS is no longer needed).

3. Typical boot process of embedded Linux systems

(1) Deployment of typical embedded systems:

The uboot program is deployed on Flash (as a boot device), the OS is deployed on Flash (where Flash replaces the hard drive in embedded systems), memory is ineffective during power loss, and the CPU does not operate during power loss.

(2) Boot process:

When the embedded system is powered on, it first executes uboot, then uboot is responsible for initializing DDR, initializing Flash, then reading the OS from Flash into DDR, and then starting the OS (once the OS boots, uboot is no longer needed).

Summary:

The boot process of embedded systems and PCs is nearly identical; only the BIOS has become uboot, and the hard drive has become Flash.

4. Boot process of the Android system

(1) The boot process of the Android system is almost the same as that of the Linux system (the typical embedded system boot discussed earlier).

That is, the first part is completely the same, but it differs after the kernel starts and the root filesystem is loaded.

The difference between Android and Linux occurs in the second stage.

(2) The boot process can be considered in two stages:

The first stage is from uboot to OS startup;

The second stage is from OS startup to rootfs loading and command line execution;

5. Summary: What exactly does uboot do?

(1) Uboot’s primary role is to start the operating system kernel.

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

(3) Uboot must also drive some peripherals like Flash, LCD, touch screens, etc.

(4) Uboot must provide a command line interface for user interaction.

What is UBOOT?

1. Where does uboot come from?

(1) Uboot is an open-source project initiated by a German on SourceForge.

(2) Uboot was started by one person and has since been maintained and developed by everyone interested on the internet.

2. Development history of uboot

(1) Initially a small personal open-source project.

(2) Gained recognition and usage by more people.

(3) Default support by many SoC manufacturers.

Summary:

After years of development, uboot has become the de facto standard for bootloaders in the industry. Most embedded devices now default to using uboot as their bootloader.

3. Uboot version number issues

(1) Early versions of uboot had version numbers like uboot1.3.4. Later, the version numbers changed to something like uboot-2010.06.

(2) The core parts of uboot have not changed much; newer versions support more development boards, and for an older version of a chip, there is little difference between new and old versions of uboot.

4. What is the portability of uboot?

(1) Uboot is a universal bootloader, meaning it can be used in various places. Thus, uboot is portable.

(2) The portability of uboot does not mean it can be used indiscriminately on any development board; rather, it has the ability to be ported at the source code level for multiple development boards, allowing it to be used after porting.

Functions of UBOOT

1. Can boot directly

(1) Most SoCs support various boot methods, such as SD card boot, NorFlash boot, NandFlash boot, etc. Uboot must be designed according to the specific SoC’s boot design to ensure it can boot from the corresponding boot medium.

(2) Uboot must undergo code-level modifications and porting corresponding to the hardware to ensure it can boot from the respective boot medium. The first stage start.S file in uboot specifically handles this.

2. Can guide the OS kernel startup and provide parameters to the kernel

(1) The ultimate goal of uboot is to start the kernel.

(2) The Linux kernel is designed to accept parameters. This means we can prepare some startup parameters in a specific memory location before starting the Linux kernel, and when the kernel starts, it will retrieve the parameters from that location, which will guide the Linux kernel’s startup process.

3. Provides system deployment functionality

(1) Uboot must be able to assist in the entire system’s (including uboot, kernel, rootfs, etc. images) flashing and downloading work on Flash.

4. Can perform SoC-level and board-level hardware management

(1) Uboot implements some control capabilities over hardware (initializing some hardware) as it must enable these hardware components to complete certain tasks. For example, if uboot needs to display a progress bar on the LCD during flashing, it must drive the LCD; if uboot needs to provide an interface via serial port, it must drive the serial port. If uboot needs to implement network functionality, it must drive the network chip.

(2) SoC-level refers to internal peripherals of the SoC, while board-level refers to hardware on the development board external to the SoC (e.g., network card, iNand).

5. The ‘lifecycle’ of uboot

(1) The lifecycle of uboot refers to when uboot starts running and when it stops running.

(2) Uboot is essentially a bare-metal program (not an operating system); once uboot starts, the SoC will only run uboot (meaning no other programs can run simultaneously while uboot is running), and once uboot finishes running, it cannot return to uboot (so after uboot starts the kernel, uboot itself is no longer active; to see the uboot interface again, the system must be restarted. Restarting does not revive the previous uboot; it is just another instance of uboot).

(3) The entry and exit of uboot. The entry point of uboot is automatic startup when powered on, and the only exit is kernel startup. Uboot can also perform many other tasks (such as flashing the system), but after completing other tasks, it can return to the uboot command line to continue executing uboot commands. However, once the command to start the kernel is executed, it cannot return.

Summary: Everything is to start the kernel.

How Uboot Works

1. Starting from the bare-metal program image uboot.bin

(1) Uboot is essentially a bare-metal program, and there is no fundamental difference from those bare-metal programs we write as xx.bin. If we must highlight a difference, it is that most of our programs are smaller than 16KB, while uboot is larger than 16KB (usually between 180k-400k).

(2) Uboot itself is an open-source project, consisting of several .c and .h files, which after configuration and compilation generates a uboot.bin, the image file of this bare-metal program. This image file is then properly flashed onto the boot medium for the SoC to boot. In other words, uboot appears as uboot.bin when not running, generally lying on the boot medium.

(3) Uboot is loaded into memory and executed instruction by instruction by the CPU.

2. The command-line shell interface of uboot

(1) Ordinary bare-metal programs run directly, and the effects depend on the code.

(2) Some programs require user interaction, so a shell (which provides a human-machine interface) is implemented in the program.

Note:

The shell is not an operating system and has no relation to an operating system. In Linux, when you open a terminal, you get a shell where you can input commands and execute them. The shell in uboot works similarly to the terminal shell in Linux (in fact, they are almost identical, just with different command sets; for example, ls is recognized in Linux, but not in uboot).

3. Two key points to master uboot usage: commands and environment variables

(1) Most of the time and work in uboot is done in the shell after startup (for example, deploying the system requires inputting commands in the shell, setting environment variables must also be done in the command line, and starting the kernel requires entering commands in the command line).

(2) Commands are various commands recognized in uboot’s shell. Uboot has dozens of commands, some are commonly used while others are not (we can also add commands to uboot ourselves).

(3) The environment variables in uboot and the operating system’s environment variables work almost identically. Uboot borrowed design concepts from the operating system (the command line working method is modeled after Linux terminal commands; the environment variables are similar to those of the operating system; uboot’s driver management is almost entirely copied from Linux’s driver framework).

(4) Environment variables can be considered system-wide variables; the names of environment variables are built-in (you either know them or you don’t; some are default environment variables such as PATH, while others are user-added variables that the system does not recognize but we do).

Programs can read environment variables during execution to guide their operation. This design is beneficial because it allows a program to change its execution method without modifying the code and recompiling, simply by modifying the corresponding environment variable.

(5) Environment variables are runtime configuration properties.

Management of Flash and DDR in Uboot

1. Flash partitioning during the uboot phase

(1) Partitioning means managing Flash in blocks.

(2) In products like PCs, since everyone uses hard drives under an operating system, the entire hard drive is managed uniformly by the operating system, and the operating system uses a file system to manage hard drive space (ensuring files do not overlap). Therefore, users do not need to worry too much about partitioning.

(3) In uboot, there is no operating system, so we must define partitions for Flash (equivalent to hard drives) beforehand. (In fact, both uboot and the kernel have a partition table; the partition table is our overall management and allocation method for Flash during system porting). After this definition, we deploy the system according to the partitioning method, and both uboot and the kernel software work according to this partitioning, avoiding errors.

(4) The partitioning method is not fixed and can change. However, in a porting project, it must be predefined; generally, during system porting, it will be determined, and the standard is:

Uboot must be stored starting from the Flash starting address (it may be sector 0, sector 1, or others, depending on the SoC’s boot design), and the size of the uboot partition must ensure that uboot can fit, generally designed to be 512KB or 1MB (since uboot is usually less than 512KB; larger sizes can work, but are wasteful);

Environment variables: The environment variable partition is generally stored next to uboot, with a size of 32KB or a bit more.

Kernel: The kernel can be stored next to the environment variables, generally sized at 3MB, 5MB, or other sizes.

Rootfs: …

What remains is the free partition, which is generally mounted to rootfs after the kernel starts.

Summary: The general rules are as follows:

(1) Each partition is contiguous; the end of one partition is the beginning of the next.

(2) The entire flash is utilized from start to finish.

(3) Uboot must be at the beginning of Flash; the relative positions of other partitions can vary.

(4) The size of each partition is determined by the system porting engineer, generally set to a suitable size (not too small, as that may lead to 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 both uboot and the kernel. In the future, the partitioning method in the system deployment must also match that in the system code.

2. DDR partitioning during the uboot phase

(1) The partitioning of DDR differs from that of Flash, mainly because Flash retains data during power loss, while DDR loses data. Thus, DDR is allocated for use each time the system runs.

(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 we no longer need to manage it.

(3) The key to memory partitioning is to allocate specific memory blocks for specific purposes to avoid overlap among different functions.

For example, if we try to download zImage to memory at 0x23E00000 using tftp, it will fail because that memory location is where uboot’s image resides. This download would overwrite the uboot in memory.

Common commands in uboot 1

1. Line-buffered command line similar to Linux terminal

(1) Line buffering means that when we input a command into the terminal command line, these commands are not immediately recognized by the system but are buffered into 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 and processes the buffered commands.

(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 require parameters (note that the format is fixed); each command in uboot has various predefined formats. Some commands do not require parameters (like printenv/print); some commands have optional parameters (which can be included or not, but the results differ based on whether parameters are included); some commands must include parameters (like setenv/set).

(5) Use “help + command name” to query detailed information about a command; just entering help will print the command list.

2. Special symbols in commands (like single quotes)

(1) Some commands in uboot may have very long parameters, and to indicate to uboot that this long parameter, which contains multiple spaces, is a single parameter, it is enclosed in single quotes.

(2) Other symbols also have specific meanings; when encountering special symbols in uboot’s command line, be cautious not to confuse them as they may have special significance.

3. The 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 a program. Any part of the program can call or change environment variables (generally, they are called); the difference between environment variables and global variables is that the lifecycle of a global variable is during a program’s single execution, born at the start and dying at the end of the program; the next time the program runs, it starts anew.

However, environment variables are stored in a dedicated area of Flash (there is an environment variable partition on Flash), and once we save an environment variable in the program, its value will retain the last saved value on the next boot.

Common commands in 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 does not take parameters and is executed directly, serving to synchronize the values of environment variables in memory to the Flash environment variable partition.

Note: Saving environment variables is an overall overwrite; that is, all environment variables in memory will completely overwrite the original content in the Flash environment variable partition.

Summary: To completely change the value of an environment variable, two steps are needed:

Step one: Use the set command to change the environment variable in memory.

Step two: 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; we can just set it without saving, which will take effect for the current run of uboot, but without saving, it will revert to the original state on the next boot.

3. Network testing command: ping

(1) Command usage: ping ip address

Note: ping tests the network link between the development board and the host.

Note the following steps:

1) First, plug in the network cable.

2) Attempt to ping the host Windows. Note the settings for the wired network card address in Windows (set the local connection).

3) Confirm the values of several network-related environment variables in uboot on the development board. The most important variable is ipaddr (this environment variable represents the current IP address of the development board), which must be in the same subnet as the host Windows.

For more specific ping tutorials, please refer to:

http://wiki.100ask.org/VMwareAndUbuntuNetworkSetupGuide

Common commands in uboot 3

1. TFTP download command: tftp

(1) Uboot’s main goal is to start the kernel, and to accomplish that, it must be able to deploy the kernel. Uboot needs to download the kernel image from the host and flash it to local Flash.

How does uboot download images from the host (Windows or virtual machine Ubuntu) to the development board?

There are many ways; the mainstream methods are: fastboot and tftp.

The fastboot method uses a USB cable for data transfer.

The tftp method uses a wired network. The typical way is through the network; fastboot is a newer development in recent years.

(2) During the tftp download, uboot acts as a tftp client program. The host Windows or virtual machine Ubuntu must have a tftp server, and the image file to be downloaded should be placed in the server’s download directory. The development board can then use the tftp command in uboot to download it.

(3) Some people prefer to set up a tftp server in Windows, typically using software like tftpd32, which is relatively easy to use; others prefer to set up a tftp server in Linux.

(4) Check the environment variables of the development board’s uboot; ensure that serverip is set to the IP address of the virtual machine Ubuntu (the serverip variable indicates the IP address of the host tftp server).

(6) Then, in uboot on the development board, first ping the virtual machine Ubuntu, and then try to download: tftp 0x30000000 zImage-qt (which means to download the file named zImage-qt from the server to the development board’s memory at address 0x30000000). After downloading, erase and flash.

Common commands in uboot 4

1. SD card/iNand operation command movi

(1) If the development board uses SD cards/EMMC/iNand as Flash, the commands for operating Flash in uboot are movi (or mmc).

(2) The movi command is a command set with many subcommands; the specific usage can be viewed with help movi.

(3) The movi commands are a set of movi read and movi write; movi read is used to read from iNand to DDR, and movi write is used to write content from DDR to iNand. When understanding these commands, it is important to pay attention to the two pieces of hardware: iNand and DDR memory.

(4) The command movi read {u-boot | kernel} {addr} uses a generic description method: movi and read are mandatory; one of the items enclosed in curly braces {} is required; the items within the braces are mutually exclusive; and items in square brackets [] are optional parameters.

(5) There are various usages for the command, for example, movi read u-boot 0x30000000 means to read the u-boot partition from iNand to the starting position of 0x30000000 in DDR (the uboot code divides iNand into several partitions, each with an address range and partition name; uboot can operate on iNand partitions using direct addresses or partition names).

Note that 0x30000000 can also be written as 30000000; both mean the same thing (in uboot’s command line, all numbers are assumed to be hexadecimal, regardless of whether you include 0x).

2. NandFlash operation command nand

The understanding and operation methods are completely similar to the movi command.

3. Memory operation commands: mm, mw, md

(1) There are no partitions in DDR (only hard drives and Flash can be partitioned, not memory); however, when using memory, care must be taken not to overwrite others’ data. Since uboot is a bare-metal program, unlike an operating system that manages all memory, uboot does not manage all memory, and memory is used freely, so if the programmer (the user of uboot) is not cautious, they may overwrite their own data.

(2) md is memory display, used to show the contents of memory.

(3) mw is memory write, used to write content to memory.

(4) mm is memory modify, used to modify a specific block of memory (if batch modification of memory is needed, mm is the most suitable).

4. Kernel startup commands: bootm, go

(1) The ultimate goal of uboot is to start the kernel, and starting the kernel in uboot is represented by a command; calling this command in the uboot command line will start the kernel (regardless of success, so this command leads to a dead end).

(2) The difference: bootm starts the kernel while passing parameters to the kernel, while the go command starts the kernel without passing parameters. Bootm is the authentic command for starting the kernel; generally, it is used; the go command is not specifically designed for kernel startup, but rather acts as a function pointer pointing 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 uboot (a debugging method for bare-metal programs is to start uboot first, then download the bare-metal program in uboot and use the go command to execute it).

Common environment variables in uboot 1

How environment variables participate in program execution

(1) There are two sets of environment variables; one is in Flash, and the other is in DDR. Uboot reads all environment variables from Flash into DDR at startup as the initialization values for the environment variables, and during use, the DDR set is utilized. Users can use the saveenv command to write the DDR environment variables back to Flash to update the Flash environment variables. On the next boot, it will read from Flash again.

(2) Environment variables in uboot are represented as strings, meaning uboot distinguishes each environment variable by character matching. Therefore, when using them, be careful not to make typographical errors.

1. Automatic 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 from which the development board downloads items via the tftp command.

(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 local network card of the development board.

Common environment variables in uboot 2

1. Automatic command execution setting: bootcmd

(1) After uboot starts, it counts down bootdelay seconds; if no one presses enter to interrupt the startup, uboot will automatically execute the startup command (bootcmd) to start the kernel.

(2) The automatic startup of uboot actually executes the command set corresponding to the value of the bootcmd environment variable internally; for example, bootcmd=movi read kernel 30008000; bootm 30008000 means to read the kernel partition from iNand to DDR memory at address 0x30008000 and then use the bootm command to start the kernel from memory at 0x30008000.

(3) Set the bootcmd environment variable; for example, set bootcmd printenv, then saveenv; after rebooting, you will see the printenv command executed automatically after the countdown. This small experiment shows that bootcmd executed automatically on boot.

(4) To set the bootcmd environment variable, for instance, set bootcmd ‘movi read kernel 30008000; bootm 30008000’

2. Uboot passes parameters to the kernel: bootargs

(1) The Linux kernel can receive startup parameters passed from uboot during startup. These parameters are in a predetermined format and content agreed upon by uboot and the kernel, and the Linux kernel completes the startup process under the guidance of these parameters. This design is flexible, allowing the kernel to start in different ways without recompiling.

(2) Our task is to set bootargs in uboot’s environment variables, and when the bootm command starts the kernel, it will automatically pass bootargs to the kernel.

(3) Example environment variables include:

bootargs=console=ttySAC0,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext3

Meaning explanation:

console=ttySAC0,115200: The console uses serial port 0 at a baud rate of 115200,

root=/dev/mmcblk0p2 rw: The root filesystem is on SD card port 0 device (iNand) partition 2, and the root filesystem is read-write.

init=/linuxrc: The path of the Linux process 1 (init process).

rootfstype=ext3: The type of the root filesystem is ext3.

(4) Passing parameters to the kernel is very important. During kernel porting, beginners often forget to pass parameters to the kernel or pass incorrect parameters, causing the kernel to fail to start.

3. Methods to create, change, and delete an environment variable

(1) To create a new environment variable, use set var value, for example: set ipaddr 192.168.1.110.

(2) To change an environment variable, use set var value, for example: set ipaddr 192.168.1.111.

(3) To delete an environment variable, use set var, for example: set ipaddr.

Note: After modifying an environment variable, be sure to save it; otherwise, the changes will be lost on the next boot.

Last issue review: Reprint | Basic Environment Configuration for Embedded System Development

Next issue content: Reprint | Revealing: How to Effectively Use “Delays” in Embedded Systems