Table of Contents

What is Trusted Firmware-A

Open

Copied from: https://www.trustedfirmware.org/

Trusted Firmware provides a reference implementation of secure software for Armv8-A, Armv9-A and Armv8-M. It provides SoC developers and OEMs with a reference trusted code base complying with the relevant Arm specifications.

The code on this website is the preferred implementation of Arm specifications, allowing quick and easy porting to modern chips and platforms. This forms the foundations of a Trusted Execution Environment (TEE) on application processors, or the Secure Processing Environment (SPE) of microcontrollers.

The Renesas BSP uses Trusted Firmware-A (TF-A) and OP-TEE.

Software Components

Below is a diagram showing the operations after device RESET.

Open

BL2: Boot Loader 2 (BL2) is first code to be run after RESET and is copied into internal RAM inside the device. BL2 will initialize DDR and then copy out additional software components into DDR. BL2 is also responsible for configuring and protected memory areas (ie, TrustZone). The BL2 code is run once, then never used again, meaning that RAM area is free to use.

BL31: The Secure Monitor code (BL31) will reside in DDR memory even after Linux boots. If the CPU (running u-boot or Linux) every issues an exception to transition to ARM level EL3, the Secure Monitor code will be run. Depending on the requested, the Secure Monitor might call in OP-TEE OS which was also loaded early in boot.

BL33: This is the code that the Secure Monitor will execute during boot after it transitions from Exception Level EL3 to EL2.

How to Build the Documentation

The documentation for Trusted Firmware-A can be found online: https://trustedfirmware-a.readthedocs.io/en/latest/

Any past version can be referenced by changing the URL: https://trustedfirmware-a.readthedocs.io/en/v2.7/index.html

However, Renesas has added additional documentation for each supported SoC to the source under the “trusted-firmware-a/docs” directory that you will not find on the TF-A website. These file are formatted in reStructuredText syntax and saved as .rst files located in “docs/plat”.

You can use the following commands to build the HTML version of these documents.

More information can be found online, https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/docs-build.html , but the commands below are more complete.

The Renesas SoC specific pages will be under:

• 6. Platform Ports

  • 30. Renesas RZ/G

  • 31. Renesas RZ/G2L

  • 32. Renesas RZ/V2H

  • 33. Renesas RZ/G3S

  • 34. Renesas RZ/T2H

  • 35. Renesas RZ/N2H

  • 36. Renesas RZ/V2N

OP-TEE Examples

• An example of using OP-TEE to read and write OTP values from a Linux application. The OTP area is in the secure area, so it cannot be access by Linux.

  • https://github.com/renesas-rz/rz_otp

Secure Monitor Services

The Secure Monitor (BL31) remains in a protected DDR memory area that Linux cannot access and is called from Linux by raising an exception.

The kernel prepares a message to send to the lower level (TrustedFirmware-A) by issuing a SMC (Secure Monitor Call) ARM instruction which will make the CPU enter EL3 (Exception Level 3) and then the CPU will execute the Secure Monitor code (TrustedFirmware-A BL31) that was loaded early in boot before the kernel started.

The Secure Monitor provides “services” which are identified by an ID that is passed in a CPU register when the SMC instruction is called.

The two main services that are used are SiP and PCSI.

Arm SiP Services

https://trustedfirmware-a.readthedocs.io/en/latest/components/arm-sip-service.html

SiP (“Silicon Provider”) services are non-standard, platform-specific services offered by the silicon implementer or platform provider. They are accessed via SMC (“SMC calls”) instruction executed from Exception Levels below EL3.

Basically, you can create any type of SiP service you would like.

Renesas has defined some SiP services that are used in the BSP to do things like:

• Read the lower level unique Device ID

• Read the lower level Chip ID

• Get the ECC mode

For example, on some devices, the multi-media or graphics kernel drivers will use SiP to read the Chip ID to know what device is running so it can know what capabilities exist.

To see what SiP services exist, you can view files:

• rzg_trusted-firmware-a/plat/renesas/rz/common/include/rz_sip_svc.h

• rzg_trusted-firmware-a/plat/renesas/rz/common/rz_plat_sip_handler.c

• rzg_trusted-firmware-a/plat/renesas/rzg/rzg_sip_svc.c (just declares DECLARE_RT_SVC and contains dummy ‘weak’ functions)

If you want, you could define your own ID and add your code to handle some low level operation. Then, from inside a kernel driver (not from application space), you can use the kernel function arm_smccc_smc() to access your service. More information can be found in rzg_trusted-firmware-a//ocs/getting_started/rt-svc-writers-guide.rst

Power State Coordination Interface (PSCI)

In general, the kernel does not want to deal with the low level power operations (like it did with 32-bit ARM Linux) because they are different for each SoC and board, and that is too much to manage in the kernel code. So now (with 64-bit ARM Linux) an API was created for the kernel to call.

The Power State Coordination Interface (PSCI) is an ARM standard that describes a software interface for power management between an operating system (not just Linux) and it’s supervisory firmware. The interface allows an operating system to perform power management tasks such as putting CPUs into an idle (low-power) state, bringing CPUs online/offline and turning the system off.

The kernel prepares a message to send to the lower level (TrustedFirmware-A) by issuing a SMC (Secure Monitor Call) ARM instruction which will make the CPU enter EL3 (Exception Level 3) and then the CPU will execute the Secure Monitor code (TrustedFirmware-A BL31) that was loaded early in boot before the kernel started. For example, to enter suspend, the PSCI API name is PSCI_SYSTEM_SUSPEND and is implemented in function psci_system_suspend() in the kernel file drivers/firmware/psci/psci.c. If there are no errors, the kernel will never return from that function (as in, CPU operation will be halted due to system suspend). For the system resume process, that is basically a warm boot, so the kernel starts executing from the beginning and detects that it needs to resume from a previous suspended state.

• More details can be found here: https://www.thegoodpenguin.co.uk/blog/an-overview-of-psci/

The code that handles the PSCI Service calls is located in directory rzg_trusted-firmware-a/lib/psci

The code that handles the system suspend for RZ/G3S is in rzg_trusted-firmware-a/plat/renesas/rz/soc/g3s/plat_pm.c

Updating TF-A on Your Board

• Update Trusted Firmware under Linux