Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Trusted Firmware-A (TF-A) is an open-source project initiated by ARM to provide a reference implementation of secure world firmware for ARMv7-A and ARMv8-A architectures. Specifically, TF-A is designed to execute at the highest Exception Level (EL3) on ARM processors, serving as the Trusted Execution Environment (TEE) firmware in systems.

Refer to official web: https://www.trustedfirmware.org/projects/tf-a/

Refer to sources: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/

Contents

Boot process of Trusted Firmware-A

The implementation of the TF-A boot process is divided into 5 stages, in the order of their execution:

  • Boot Loader stage (BL1): Executed by AP Boot ROM.

  • Execution stage 2 (BL2): Trusted Boot Firmware.

  • Execution stage 3-1 (BL31): EL3 Runtime Firmware.

  • Execution stage 3-2 (BL32): Secure-EL1 Payload.

  • Execution stage 3-3 (BL33): Non-trusted Firmware.

Boot process of SP7350

In the SP7350 software architecture, BL1 is represented by i-boot, BL2 by x-boot, BL31 by TF-A, BL32 by OP-TEE, and BL33 by U-Boot. As shown in the figure below, the blue arrows indicate the boot sequence. Notably, i-boot, x-boot, and TF-A operate at EL3, U-Boot at EL2, while OP-TEE and Linux run at EL1.

image-20240213-141038.png

BL31, a EL3 runtime firmware, is a specific stage or component within Trusted Firmware-A (TF-A). When referring to the TF-A in SP7350 software, it specifically points to the BL31 since only the code associated with BL31 in TF-A is utilized.

During the boot process, the image files of BL31 (TF-A), BL32 (OP-TEE), and BL33 (U-Boot) are loaded by the second-stage boot-loader, x-boot (BL2). Following this, x-boot (BL2) facilitates the transfer of control to BL31 (TF-A). BL31 operates as a secure monitor with Exception Level 3 (EL3) privileges, adhering to the AArch64 architecture standard.

The BL31 image is loaded and functions at the address 0x200000. The device tree source (dts) for the SP7350 platform reserves a one-megabyte area beginning at 0x200000 for BL31. Please refer to the dts node provided below

reserved-memory {
		:
		:
		/* TF-A reserve memory: 0x200000-0x2fffff, total 1M */
		tfa_reserve@200000 {
			reg = <0x0 0x200000 0x0 0x100000>;
			no-map;
		};
		:
		:
};

BL31

As the final security barrier at EL3, BL31 operates differently from BL1 and BL2, as it is not a one-time execution. As implied by its runtime designation, it continuously provides securely designed services to the non-secure world through SMCs (Secure Monitor Calls). It is responsible for executing BL32.

BL31 resides in DRAM and operates in EL3 mode. In addition to architecture and platform initialization, it performs the following tasks:

  • Initialization of PSCI services to enable CPU power management operations.

  • Initialization of the BL32 image for execution in Secure EL1 mode.

  • Initialization of Non-Secure EL2 or EL1, followed by a jump to execute BL33.

  • Facilitation of secure and non-secure world transitions.

  • Distribution of secure service requests.

Power state coordination interface (PSCI)

It is a standard interface defined by ARM that facilitates power management operations in a ARMv8-A system. PSCI specifies the interface protocol for the Linux kernel to call power management-related services provided by BL31. It includes the interfaces necessary to implement the following functionalities:

  • CPU idle management

  • Hot-plug, which involves dynamically adding or removing CPUs from the system

  • Secondary CPU startup

  • System shutdown and reset operations

PSCI is invoked by the Linux kernel to access secure services provided by BL31. By leveraging PSCI, the Linux kernel can interact with BL31 to perform operations such as CPU power state transitions (e.g., turning CPUs on or off), dynamic voltage and frequency scaling (DVFS), and other power management tasks in a secure and coordinated manner. This collaboration between the Linux kernel and the secure monitor (BL31) ensures efficient and reliable CPU power management while maintaining system security.

Source files

Source files of TF-A can be found in the "boot/trusted-firmware-a/" directory under the project's top directory. Refer to table below for main sub-directories and descriptions.

Files or folders

Descriptions

blx/

Contains boot stage-specific code. TF-A code is divided according to BL stages:

bl1, bl2, bl2u, bl31, bl32. Only bl31 is used in SP7350 software.

build/

Contains output files.

common/

Contains platform and architecture-independent code.

docs/

Contains documentation files.

drivers/

Contains device drivers for various peripherals and hardware components.

lib/

Contains PSCI implementation and other EL3 runtime frameworks.

include/

Contains header files that define interfaces, constants, and data structures.

plat/

Contains architecture or platform-specific code.

services/

Contains source files related to services provided by TF-A.

tools/

Contains tools and scripts used for building, configuring, and debugging TF-A.

Some files or folders are added or modified for SP7350 platform. Table below lists the files or folders:

Files or folders

Descriptions

lib/psci/

Contains power state coordination interface (psci) files.

plat/sp/

Contains SP7350 platform-related files.

sp7350.mk

Make file of sp7350 platform.

Platform-related header files

Platform-related header files, residing under "plat/sp/common/include" and "plat/sp/sp7350/include," contain essential definitions for UART, platform settings, DRAM configurations, register addresses, and watchdog registers. Modifying these files is crucial when adapting TF-A to specific platform requirements.

plat/sp/common/include/

Files

Descriptions

sp_uart.h

Contains definitions of bits and registers of UART.

sp_def.h

Contains definitions of platform.

plat/sp/sp7350/include/

Files

Descriptions

platform_def.h

Contains most definitions of platform, include DRAM base address, size, and etc.

sp_mmap.h

Contains definitions of address DRAM, registers, GIC base and etc..

sp_pm.h

Contains definitions of registers watchdog.

Log of BL31 and explanation

Line 1-2: Banner (version) of BL31.

Line 3-7: BL31 is in the process of initializing itself.

Line 8: BL21 is initializing BL32 (OP-TEE).

Line 9-12: Log of OP-TEE, redirected to UART0.

Line 10: Banner (version) is OP-TEE.

Line 11-12: Indicate that the primary CPU (core 0) has completed initialization in secure mode and then switches back to normal world boot.

Line 13-15: OP-TEE is completed initialization and is preparing to execute U-Boot, located at 0x500040.

NOTICE:  BL31: v2.4(release):5dd30df
NOTICE:  BL31: Built : 02:10:02, Jan 14 2024
NOTICE:  BL31: Detected SP7350 SoC (0a30)
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
NOTICE:  PSCI: plat_setup_psci_ops
INFO:    BL31: Initializing BL32
I/TC: 
I/TC: OP-TEE version: 150e2ba (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 Sat Jan 13 06:09:33 PM UTC 2024 aarch64
I/TC: Primary CPU initializing
I/TC: Primary CPU switching to normal world boot
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x500040
INFO:    SPSR = 0x3c9
  • No labels