x-boot

x-boot (external boot code) serves as the first-stage boot-loader, residing in storage devices such as eMMC, NAND flash, or SD cards. It is loaded into the system SRAM by i-boot, as DRAM is not yet ready during this phase. As it operates in SRAM, its overall size, including code, data, and stack, must not exceed the capacity of the system SRAM. The primary objective of x-boot is to initialize the DDR SDRAM controller and PHY, conduct calibration on the PHY and signals, and once calibrated, make the DRAM ready for use.

Subsequently, x-boot loads the images of TF-A (BL31), OP-TEE (BL32), and U-Boot (BL33) from a storage device into DRAM. The CPU (core 0) then switches itself from 32-bit mode to 64-bit by triggering a software reset. It proceeds to awaken other cores (core 1, 2, 3) and transitions them to 64-bit mode. Finally, all cores execute TF-A.

Contents

Features

1. Output log at UART0 (at 115,200 bps set by i-boot).

2. Support loading firmware of DDR3, DDR4 or LPDDR4 from boot devices.

3. Support initialize DDR controller and PHY.

4. Support 1D and 2D training of PHY for DDR3, DDR4, and LPDDR4.

5. Support loading image of TF-A (BL31), OP-TEE (BL32) and U-Boot (BL33) from boot devices.

6. Support secure-boot:

   1. Verify digital signature of fip (TF-A and OP-TEE) and U-Boot images.

   2. Decrypt fip image.

7. Support warm-boot.

8. Switch CA55 to 64-bit mode and jump to run TF-A.

9. Support read and write OTP bit using Sunplus OTPTool through UART0.

Flow

The x-boot starts with the “_start” subroutine (assembly code) responsible for initializing start.S reset vector, followed by the execution of the "cpu_init" subroutine responsible for initializing C execution environment. The flow then advances to execute the "xboot_main" subroutine, serving as the C main function within x-boot.

“xboot_main()” subroutine starts with “init_cdata” subroutine for initializing C global data. Then “init_uart()” subroutine for initializing all UARTs, “init_hw” subroutine for initializing hardware. Finally, run “boot_flow()”.

“boot_flow()” starts with initializing DDR controller and PHY, and then train PHY. Next, initialize the controller of boot-device which is recorded in C structure g_bootinfo. Subsequently, it loads the fip (firmware image package) image and U-Boot image from fip and U-Boot partitions within ISPBOOOT.BIN, storing them in DRAM, respectively. Finally, it proceeds to execute “boot_uboot()” subroutine.

“boot_uboot()” subroutine starts with verify image of fip and U-Boot. If verification is successful, it moves TF-A (Trusted Firmware-A) and OP-TEE (Open Portable Trusted Execution Environment) images from the load position to dedicated location of DRAM. Subsequently, it setup CPU reset vector to entry-point of a64 module for all cores and then issue a warm-reset to switch CPU (core 0) to 64-bit (aarch64) mode.

In a64up mode, CPU core 0 wakes up core 1, 2 and3, and switch them 64-bit (aarch64) mode. Then all core make a jump to Tf-A.

The following illustrates the process from reset vector of i-boot to jump to TF-A for all cores.

Drivers locations and features

x-boot supports many device drivers for accessing devices. The following table shows the locations of drivers in project diretory boot/xboot/ and features of each driver.

Other files

The following table shows the locations of important forlders or files of x-boot in project diretory boot/xboot/.

All defconfig files are placed at configs/. Normally, the file name proceed with sp7350- and followed by defconfig, like sp7350_emmc_ev_defconfig, sp7350_sdcard_ev_defconfig, and etc.

SRAM Space Allocation

To facilitate program maintenance and data sharing, x-boot and i-boot utilize the same SRAM segment division and structure. Figure 4.2 illustrates the segmentation of SRAM into 9 segments, ranging from low to high addresses: xboot_buf, bootinfo, boothead, a64up, cdata, storage_buf, stack, bootcompat, and spacc_ram.

Below are explanations of each segment's purpose:

• xboot_buf: x-boot program segment, where the x-boot program is loaded and executed.

• bootinfo: bootinfo segment containing the g_bootinfo structure, which records boot-related information.

• boothead: boothead segment holding the g_boothead array, used to store GPT data for eMMC or header data for NAND flash.

• a64up: a64up segment where the a64up program resides, responsible for transitioning the CPU from 32-bit mode to 64-bit mode.

• cdata: C data segment containing global variables or static variables in C.

• storage_buf: Device driver data segment for boot devices such as eMMC and NAND flash. Different boot device drivers share the same space here during a single boot, as only one boot device driver is utilized per boot.

• mmu_pgtbl: Page table of MMU.

• stack: Stack segment where the stack for C is located.

• bootcomp: CPU run control data.

• reserved: warm-boot reteion data

During system boot, i-boot reads boot-related information from the boot switch and the OTP (One-Time Programmable) memory within the C chip. This information is then stored in the g_bootinfo structure. Consequently, the data in the g_bootinfo structure determines the i-boot boot mode and the subsequent boot process. x-boot directly utilizes the data in the g_bootinfo structure to determine the boot mode and process.