Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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 starts initiation begins with the "_start” subroutine (start" subroutine, written in 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 process then advances proceeds to execute the "xboot_main" subroutine, serving which serves as the main C main function within x-boot.

...

“xbootThe "xboot_main()" subroutine starts begins with “init_cdata” the "init_cdata" subroutine for initializing C global data. Then “initIt is followed by the "init_uart()" subroutine for initializing to initialize all UARTs , “init_hw” and the "init_hw()" subroutine for initializing hardware initialization. Finally, run “bootthe sequence progresses to run the "boot_flow()" subroutine.

...

“bootThe "boot_flow()" subroutine starts with by initializing the DDR SDRAM controller and PHY, and then train followed by PHY . Next, initialize 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 fip and U-Boot the respective partitions within ISPBOOOT.BINthe boot device, storing them in DRAM, respectively. Finally, it proceeds the process advances to execute “bootthe "boot_uboot()" subroutine.

...

“bootThe "boot_uboot()” subroutine starts with verify image " subroutine begins by verifying the images of fip and U-Boot. If Upon successful verification is successful, it moves the TF-A (Trusted Firmware-A ) and OP-TEE (Open Portable Trusted Execution Environment) images from the load position to the dedicated location of in DRAM. Subsequently, it setup 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 a64 the a64up module for all cores and then issue triggers a warm-reset to switch CPU itself (core 0) to 64-bit (aarch64) mode.

In a64up modeAfter the warm-reset, CPU core 0 operates in the a64up module at 64-bit mode. It then wakes up core cores 1, 2 and3, and switch 3, switching them to 64-bit (aarch64) mode . Then all core 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 TfTF-A (BL31).

...

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

...

Drivers locations and features

...