...
Refer to sources: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Table of Contents
Table of Contents |
---|
Boot
...
Process of Trusted Firmware-A
The implementation of the TF-A boot process can be 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 Platform
Within In the SP7350 software architecture, BL1 is represented by i-boot, BL2 by x-boot, BL31 by TF-A (secure monitor), 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.
...
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.
BL31
...
BL31 plays a crucial role in establishing a secure execution environment for the subsequent stages of the boot process. The primary responsibilities of BL31 include:
Secure Environment Setup: BL31 initializes the secure world, setting up the Trusted Execution Environment before handing control to the next stage in the boot process.
Secure Exception Handling: It provides secure exception handling services and manages secure interrupts.
Secure Context Management: BL31 manages secure contexts, ensuring the secure world's isolation from the non-secure world.
Secure Resource Management: It handles secure resource allocation and management.
Trusted Services: BL31 may provide trusted services to other firmware components or the operating system running in the secure world.
Source files
...
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.
The device tree source (dts) of the SP7350 platform reserves a one-megabyte area beginning at 0x200000 for BL31. Please refer to the dts node provided below:
Code Block |
---|
reserved-memory {
:
:
/* TF-A reserve memory: 0x200000-0x2fffff, total 1M */
tfa_reserve@200000 {
reg = <0x0 0x200000 0x0 0x100000>;
no-map;
};
:
:
}; |
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 folder. Some platform-related files 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 | build/ | Contains output files.|
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. |
BL31 Log 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.
Code Block |
---|
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 |