Timeline
Timeline
2025-12-26
init
This article introduces the complete boot process of an SoC from power-on to loading the operating system, detailing the mechanism of BootROM initializing hardware and loading programs into internal SRAM via Bootstrap Pins. To address the limited capacity of internal SRAM, the article further explores U-Boot relocation and SPL solutions, and takes Rockchip as an example to analyze the division of responsibilities where TPL is responsible for system hardware initialization, and SPL is responsible for loading U-Boot and Trust images.
BootROM
Generally speaking, SoC manufacturers build a ROM inside the SoC. This ROM is very small and contains the solidified power-on boot code (once solidified, it can never be changed; it is built in when the chip is made); this part of the code is called BootROM, also known asFirst-stage bootloader。
After the chip is powered on, the SoC manufacturer’s BootROM takes over the system first. It initializes the hardware and then loads the program into the SRAM.
Initialize hardware
- CPU configuration
- Disable watchdog
- Initialize clocks
- Initialize some peripherals (such as USB Controller, MMC Controller, Nand Controller, etc.);
Load program into SRAM
A new SoC generally hasexternal storage devices(eMMC, Nand, Nor, SDCard, etc.) and memory (SDRAM, DDR, etc.) attached to the chip.
Then we need to flash a program for the CPU to execute. Flashing a program essentially means writingexecutable binary filestoexternal storage devices(eMMC、Nand、SD, etc.). When the system is powered on and starts, it willread them into memory for execution.。
After power-on, the SoC manufacturer’s BootROM takes over the system first. Other executable programs (U-Boot, Kernel) are placed (flashed) onto external memory; therefore, in addition to initializing the hardware environment, the BootROM code also needs to read the next executable program from the external memory into memory for execution.
Since it is read into memory for execution, can this memory be our onboard DDR?
Theoretically, it is possible. However, the DDR controller designed by the SoC manufacturer generally supports many types of DDR devices and provides a compatibility list. How could the SoC manufacturer know exactly what type of memory the user has on their PCB?
Therefore, directly reading external executable programs into DDR is obviously not very friendly. Thus, generally speaking,An SoC usually includes a small-capacity internal SRAM ，BootROM reads the external executable program from the external memory and puts it into SRAM for execution；
So which specific memory does BootROM read the binary file from?
SoC manufacturers generally support multiple boot methods, such as:
- Reading from eMMC
- Reading from SDCard
- Reading from Nand Flash, etc.
When powered on, it needs to be told which peripheral it should read the subsequent boot binary file from;
The general design approach is to create a set of Bootstrap Pins. Upon power-on, BootROM reads the levels of these IOs to determine which external memory to load the subsequent executable file from; for example, 2 IOs, 2’b00 means booting from Nand, 2’b01 means booting from eMMC, 2’b10 means booting from SDCard, etc.;
After BootROM reads these values, it initializes the corresponding peripheral and then reads the subsequent code to be executed; generally, these IOs are implemented as onboard DIP switches to adjust the chip’s boot method;
Here, when reading the burned binary, some details need to be noted. For example, the SoC manufacturer tells you that you need to initialize the SDCard into a certain file system first, and then put the content in for it to be valid, etc.; becauseA file system is a way of organizing files, not a raw partition; youput it in according to file system A, and then the SoC’s BootROM also reads it out according to file system A, so that an agreement can be reached；
SPL
After the chip is powered on, BootROM determines which memory to read the executable binary file from into SRAM for execution based on the Bootstrap Pins; theoretically, this binary file could be ouru-boot.binfile; that is, BootROM directly loadsu-boot.bin；
Theoretically, this is the case, but there is a problem here: SRAM is expensive. Generally, the on-chip SRAM of an SoC is not very large, usually ranging from 4KB, 8KB, 16KB… to 256KB; however, the compiled u-boot is very large, hundreds of KB, and cannot fit.
What to do if it doesn’t fit? There are two ways:
- Assuming the on-chip SRAM is 4KB,the first 4KB of uboot implements uboot’s relocation, i.e.,Copy uboot to SDRAM to run；
- Make a smaller boot program,first let BootROM load this small program, and then let this small boot load uboot later;
Option 1: uboot relocation
For example, our uboot is 400KB, SRAM is 4KB, and external SDRAM is 64MB;
If we use the first scheme, the first 4KB of uboot is loaded into SRAM for execution, uboot is truncated, and we need toensure that in the first 4KB of uboot code, the onboard SDRAM is initialized, the entire uboot is copied to SDRAM, and then jump to SDRAM for execution；
Scheme 2: SPL
In the second scheme, we make a small uboot, this uboot is calledSPL（Secondary Program Loader), it is very small (smaller than the SRAM size), itis first loaded into SRAM by BootROM to run, the main thing SPL needs to do isinitialize the memory controller, then read the real large u-boot from external memory into SDRAM, and then jump to the large uboot。
As shown in the figure above:
- After power-on, BootROM starts execution, initializes the clock, turns off the watchdog, turns off Cache, turns off interrupts, etc., determines the boot device based on the Bootstrap Pin, and initializes peripherals;
- Use peripheral drivers to read SPL from memory;
---------------- The above part is the SoC manufacturer’s job, the following is what the user needs to do ----------------
- SPL is read into SRAM for execution, at this moment, control has been handed over to our SPL;
- SPL initializes external SDRAM;
- SPL uses drivers to read uboot from external memory and put it into SDRAM;
- Jump to the uboot in SDRAM for execution;
- Load the kernel;
In actual situations, there are still many issues to pay attention to:
- Link address during compilation, does it need to be position-independent?
- Is there any overlap between SPL code and uboot code? If so, does it mean that what SPL has executed will be executed again when jumping to uboot?
- In specific cases, which hardware needs to be configured? How to configure?
Rockchip boot flow
For different solutions, Rockchip provides two different bootloader methods, and their steps and generated image files are also completely different.
- TPL/SPL loading: Using the TPL/SPL officially provided by Rockchip (which is the small U-Boot we mentioned above), this method is fully open source;
- Official firmware loading: Using Rockchip idbLoader, which consists of
Rockchip rkbin projectofRockchip ddr init binandminiloader bincombined, this method is not open source;
Above we introduced SPL, so what is TPL? Actually, taking what we mentioned abovethe part of SPL that initializes SDRAM and other hardware, and making it independent, is TPL. So let’s summarize:
- TPLisTarget Program Loader, which ischip-level initialization process, at this time the code is all based on the chip platform part, it performs DDR initialization and some other system configurations during the boot process, so that the subsequent SPL can run correctly;
- SPLisSecondary Program Loader, it reads from the storage devicetrust (such as ATF/OP-TEE) and U-Boot binary files, loads them into the system memory and runs them, thereby starting the complete operating system；
The difference between TPL and SPL lies in their different responsibilities. TPL is mainly responsible for initializing system hardware, while SPL is responsible for loading and running other software components, such as trust and U-Boot.
Furthermore, in some special cases, such as encrypted boot or secure boot modes, TPL may also perform other additional tasks.
Boot stages
1 | +--------+----------------+----------+-------------+---------+ |
The boot stages involve multiple image files:
- The BootROM in Stage 1 is provided by the SoC vendor;
- Stage 2 method needs to provide a
idbloader.img； - Stage 3 is actually the U-Boot image file, there are two types here: uboot.img (needs to be paired with trust.img)andu-boot.itb (this is because it has already packaged ATF into it); besides both containing the original u-boot.bin binary file, these two files also put in some other things, which can be recognized by
idbloader.img, and then loaded; - Stage 4 and Stage 5 are the kernel image and root file system;
When we discuss booting from eMMC/SD/USB drive/network, they involve different concepts:
- The first stage is always in BootROM, which loads the second stage and may load the third stage (when SPL is enabled_BACK_TO_BROM option);
- Booting from SPI flash means the second and third stage firmware (only SPL and U-Boot) is in SPI flash, and the fourth/fifth stages are elsewhere;
- Booting from eMMC means all firmware (including the second, third, fourth, and fifth stages) is in eMMC;
- Booting from SD Card means all firmware (including the second, third, fourth, and fifth stages) is in SD Card;
- Booting from USB drive means the fourth and fifth stage firmware (excluding SPL and U-Boot) is in the disk, optionally including only the fifth stage;
- Booting from Net/TFTP means the fourth and fifth stage firmware (excluding SPL and U-Boot) is on the network.
idbloader.img
The idbloader.img file is a Rockchip-format pre-loader that works when the SoC starts up, it contains:
- IDBlock header known by Rockchip BootROM;
- DDR initialization program, loaded into SRAM by BootROM, running inside SRAM;
- Next-level loader, loaded by BootROM and running on DDR;
u-boot.img
u-boot.bin is the original binary image generated after compiling the uboot source code, which can be directly flashed into the device’s flash memory. While u-boot.img is generated bymkimagetools adding a header information on top of u-boot.bin, this header information may also include some extra data, such as boot parameters and kernel image addresses, etc.
Therefore, byusing u-boot.img instead of u-boot.bin, it can make it easier for the boot ROM to identify the uboot image, and better guide uboot to boot correctly on the device.
u-boot.itb
u-boot.itb is actually another variant of u-boot.img, also built by mkimage. In addition to the two files compiled from the uboot source code, u-boot.dtb and u-boot-nodtb.bin, it also contains ARM trust firmware such as bl31.elf, bl32.bin, and tee.bin. Among them, bl31.elf is mandatory, while bl32.bin and tee.bin are optional and can be omitted.
trust.img
ARM64 SoCs also need to compileATF (ARM Trust Firmware)，ATF is mainly responsible for switching the CPU from secure EL3 to EL2 before booting uboot，and then jumping to uboot, and is responsible for starting other CPUs after the kernel boots。
ATF makes a complete and unified division of system booting from the lowest level, placing the functions of the secure monitor into bl31. In this way, after the system is fully booted, when an smc or other interrupt is triggered in CA or TEE OS, it first traverses the corresponding services registered in bl31 to determine the specific handle, allowing for unified management and allocation of all key smc or interrupt operations in the system. The block diagram of the entire ATF code boot process is as follows:
As shown in the figure above:
- Boot flow 1 is the typical Rockchip boot flow using the Rockchip miniloader;
- Boot flow 2 is used for most SoCs, using U-Boot TPL for DDR initialization, and using SPL to load the u-boot.itb file;
Note 1: If loader1 has multiple stages, the program will return to BootROM, which will load and run to the next stage. For example, if loader1 is TPL and SPL, BootROM will first run to TPL, TPL initializes DDR and returns to BootROM, and then BootROM will load and run to SPL.
Note 2: If trust is enabled, in secure mode (EL3 in armv8), loader1 needs to load both trust and U-Boot, then run into trust, trust initializes in non-secure mode (EL2 in armv8), and runs to U-Boot.
Note 3: For trust (in trust.img or u-boot.itb), armv7 only has a tee.bin with or without TA, armv8 has bl31.elf and optionally includes bl32.
Note 4: In boot.img, the content can be Linux’s zImage and its dtb, grub.efi can be selected, or it can be AOSP boot.img, ramdisk is optional.