i-boot, stored in the chip's internal mask ROM, plays a crucial role in the system's initialization process. During power-on reset, the program counters of all four ARM Cortex A55 CPUs are configured to point to the entry point address of i-boot. Upon the completion of power-on reset, the CPUs commence execution from this entry point. i-boot undertakes a series of essential tasks, including CPU initialization, setting up interrupt vectors, stack initialization, cache setup, serial port configuration, timer configuration, and more.
Following this initialization phase, i-boot loads x-boot from external storage devices into SRAM and performs a checksum verification. If the verification passes, i-boot proceeds to execute x-boot.
Table of Contents |
---|
Key features of i-boot
Output log at UART0 with a baud rate of 115,200 bps.
UART0 pins can be turned off through an OTP bit.
Read bootstrap pins IV_MX[6..3] to decide boot-device.
Support for five boot devices: SPI-NOR flash, SPI-NAND flash, 8-bit NAND flash, eMMC, SD card, and USB flash drive (on either USB2.0 or USB3.0 port).
Implementation of secure-boot with the ability to verify the digital signature of the x-boot image and decrypt it.
Secure-boot activation controlled by an OTP bit.
Support for warm-boot, enabling wake-up from deep-sleep mode.
Support for the peripheral-reset signal (output from G_MX2).
Main flow
The i-boot flow initiates with the reset vector, followed by the execution of the "cpu_init" subroutine responsible for initializing the CPU. Next in the sequence is the "start_boot" subroutine, which sets up the C execution environment. The flow then advances to execute the "iboot_main" subroutine, serving as the C main function within i-boot.
The "iboot_main" subroutine commences by invoking the "init_cdata" subroutine to initialize global C data. It then proceeds to read boot-strap pins from a dedicated hardware register, storing the information in the C structure g_bootinfo. In the event of a warm-boot scenario, it checks the readiness of DRAM (where CM4 handles the restoration of DDR IO retention data and specific hardware registers or settings). If DRAM is confirmed ready, the subroutine redirects to the start address of the warm-boot module to continue the warm-boot processes.
In cases where a warm-boot is not applicable (in cold-start scenario), the process continues to execute the "AV1_STC_init()", "init_uart()", and "init_hw()" subroutines to initialize hardware components. Finally, it advances to run the "boot_flow()" subroutine.
The "boot_flow()" subroutine begins by examining the C structure g_bootinfo to determine the preferred boot device: eMMC, SPI-NAND flash, 8-bit NAND flash, SD card, or USB flash drive. It then initializes the controller of the selected boot device and loads the x-boot image into SRAM from the chosen source. After loading, the subroutine checks the image checksum. If the checksum passes verification, it proceeds to execute x-boot.
In the case of secure-boot activation through OTP bits, the subroutine additionally checks the digital signature and decrypts the image after the checksum validation.
It's essential to note that i-boot does not initialize DDR DRAM, rendering it temporarily unavailable. Hence, x-boot must be loaded into SRAM for execution.
Boot devices
i-Boot supports five boot devices, each with specific specifications and requirements. Below is a detailed table outlining the specifications for each boot device:
Boot devices | Specifications |
8-bit NAND flash |
|
eMMC device |
|
SPI-NAND flash |
|
SPI-NOR flash |
|
SD card |
|
USB flash drive |
|
Boot core and other cores
CPU core 0 serves as the boot core, responsible for all boot processes from i-boot to Linux. Meanwhile, CPU core 1, 2, and 3 enter a spin state (wfe mode) inside i-boot after initialize itself, awaiting activation by core 0. The following assembly shows the processes.
Run Control of CPU (at bootcompat session) :
CPU_WAIT_INIT_VAL (0xffffffff) // CPU waiting (spinning)
CPU_WAIT_A64_VAL (0xfffffffe) // CPU goes to A64
x (address other than above) // CPU goes to x
Bootstrap pins of SP7350
The state of bootstrap pins of SP7350 is read into bootstrap register (G0.31) upon releasing power-on reset. Refer to definition of boot-strap pins in i-boot below:
Boot-strap pins of SP7350 | Boot devices | |||||||
MX6 | MX5 | MX4 | MX3 | MX2 | MX1 | MX0 | ||
1 | 1 | 1 | 1 | 1 | x | x | eMMC boot | |
1 | 1 | 1 | 0 | 1 | x | x | SPI-NAND boot | |
1 | 1 | 0 | 1 | 1 | x | x | USB boot | |
1 | 1 | 0 | 0 | 1 | x | x | SDC boot | |
1 | 0 | 1 | 1 | 1 | x | x | SPI-NOR boot | |
1 | 0 | 0 | 0 | 1 | x | x | 8-bit NAND boot |
Note:
If MX1 = 0, the JTAG interface of CA55 of SP7350 will be enabled.
If MX2 = 0, SP7350 will enter test mode. Always set to 1 for normal operation.