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.

Table of Contents

Features

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

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

3. Support initialization of DDR controller and PHY.

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

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

6. Support secure boot:

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

   • Decrypt fip image.

7. Support warm-boot:

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

8. Support reading and writing OTP bits using Sunplus OTPTool through UART0.

Flow

The x-boot initiation begins with the "_start" subroutine, written in assembly code, responsible for initializing the C execution environment. The process then proceeds to execute the "xboot_main" subroutine, which serves as the main C function within x-boot.

Open

The "xboot_main()" subroutine begins with the "init_cdata" subroutine for initializing C global data. It is followed by the "init_uart()" subroutine to initialize all UARTs and the "init_hw()" subroutine for hardware initialization. Finally, the sequence progresses to run the "boot_flow()" subroutine.

Open

The "boot_flow()" subroutine starts by initializing the DDR SDRAM controller and PHY, followed by PHY training. It then initializes the controller of the boot device, which is recorded in the C structure g_bootinfo. Subsequently, it loads the fip (firmware image package) image and U-Boot image from the respective partitions within the boot device, storing them in DRAM. Finally, the process advances to execute the "boot_uboot()" subroutine.

The "boot_uboot()" subroutine begins by verifying the images of fip and U-Boot. Upon successful verification, it moves the TF-A and OP-TEE images from the load position to the dedicated location in DRAM. Subsequently, it executes the “go_a32_to_a64()” subroutine.

In the “go_a32_to_a64()” subroutine, it configures the CPU reset vector to the entry-point of the a64up module for all cores and triggers a warm-reset to switch itself (core 0) to 64-bit (aarch64) mode.

After the warm-reset, CPU core 0 operates in the a64up module at 64-bit mode. It then wakes up cores 1, 2, and 3, switching them to 64-bit (aarch64) mode by triggering a warm-reset (in i-boot). Following the warm-reset, cores 1, 2, and 3 operate in the a64up mode at 64-bit mode. Subsequently, all cores make a jump to TF-A (BL31).

The flow chart below illustrates the process from i-boot's reset vector to the jump to TF-A for all cores

Source Files

The source files for x-boot are located in the "boot/xobot/" directory under the project's top folder. The entry point for x-boot is the label "_start" in the assembly file "arch/arm/sp7350/start.S". Notably, "_start" is situated at an offset of 32 bytes within the x-boot module, with the initial 32-byte space reserved for a header. The "_start" subroutine initializes the C execution environment and subsequently jumps to the C main function, the "xboot_main()" subroutine in the "xboot.c" file. The "xboot.c" file serves as the top-level control file for x-boot, governing the entire flow of operations.

The table below lists and explains the main files and folders in x-boot:

Driver Specifications and Features

x-boot incorporates a range of device drivers, each offering specific features to facilitate various operations. The following table outlines the detailed specifications and features of these drivers.

SRAM Space Allocation

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

Let's delve into the purpose of each segment:

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

• bootinfo: Contains the bootinfo segment with the g_bootinfo structure, recording essential boot-related information.

• boothead: The boothead segment stores the g_boothead array, used for GPT data in eMMC or header data in NAND flashes.

• a64up: Dedicated to the a64up module, responsible for transitioning the CPU from 32-bit mode to 64-bit mode.

• cdata: This is the C data segment, hosting global and static variables in C.

• storage_buf: Reserved for device driver data related to boot devices like eMMC and NAND flash. Multiple boot device drivers share this space during a single boot, with only one boot device driver utilized per boot.

• mmu_pgtbl: The page table of MMU.

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

• bootcomp: CPU run control fields.

• reserved: This segment is designated for warm-boot retention data.

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

x-boot Log and Explanation

Line 1: Banner (version) of x-boot

Line 5: PLLC (CPU frequency) is set to 1.5GHz.

Line 6: PLLL3 (L3 cache frequency) is configured to 1.2GHz.

Line 7: PLLD (DRAM clock) is set to 800MHz, with a data-rate of DDR SDRAM is 3200 Mbps.

Line 14: “{{emmc_boot}}” indicates that x-boot is executing the 'emmc boot' flow.

Line 19: Boot-device is 0x1F (MX[6..2]), indicating eMMC boot.

Line 20: Banner (version) of DDR training firmware

Line 23: DDR SDRAM part number is MT53E1G32D2 version B, with FBGA code ‘D8CJG’.

LIne 24: DDR SDRAM clock is at 1600MHz.

Line 28: The length of the x-boot image is 0xAEA0 (44,704 bytes), excluding DDR training firmware.

Line 29-30: 1D training firmware has benn successfully loaded, with the checksum verified.

Line 42: 1D training has successfully completed.

Line 44-45: 2D training firmware has been successfully loaded, with the checksum verified.

Line 52: 2D training has successfully completed.

LIne 57: Testing DRAM (only 1kB range)

Line 61: The bus clock of eMMC is configured to 200kHz (divisor = 1789) for the IdentifyStorage command.

Line 69: The bus clock of eMMC is adjusted to 25MHz (divisor = 14) for subsequent Read and other commands.

Line 70: Read GPT of eMMC.

LIne 71-73: Loading header of uboot1 image (factory default)

Line 74-78: Loading uboot2 image (the latest update). Size of uboot2 image is 858,952 bytes. The checksum of uboot2 image is successfully verified.

Line 79-81: Loading fip image (including TF-A and OP-TEE images). Size of fip image is 408,462 bytes. The checksum of fip image is successfully verified.

Line 82: uboot image is loaded at 0x00500040.

Line 83: fip image is loaded at 0x01000000.

Line 84: Initializing Cortex M4 hardware. Reset of CM4 is asserted here.

Line 85-86: CPU core is preparing to switch to 64-bit mode, and a64up module is located at 0xFA218400.

Line 87: CPU core 0 is at secure EL3 mode and proceeds to execute TF-A (BL31), which is located at 0x00200000.