Last edited 3 months ago

OP-TEE remoteproc framework overview

Applicable for STM32MP15x lines, STM32MP25x lines

1. Framework purpose[edit source]

The OP-TEE remote processor (RPROC) framework allows the different platforms/architectures to control (power on, load firmware, power off) remote processors in the secure context. In addition, it offers services to authenticate the firmware image and isolate the associated memories to ensure the integrity of the firmware running on the coprocessor. See also the wiki article How to protect the coprocessor firmware.

2. System overview[edit source]

Remoteproc overview.png

2.1. Component description[edit source]

  • remoteproc trusted application (TA): this is the remote processor framework generic part. Its role is to provide an interface to the Linux remoteproc framework to:
    • Load and authenticate a firmware image in the remote processor memory.
    • Provide the resource table address.
    • Control the remote processor execution (start, stop...).
  • remoteproc pseudo trusted application (PTA): this component is the STM32MPU platform implementation of the services associated with the management of the Cortex®-M coprocessor. Its role is to provide atomic services to the remoteproc TA:
    • Load and authenticate the image segment in the remote processor memory.
    • Manage the memory regions isolation.
  • stm32_remoteproc driver: configuration of the Cortex®-M coprocessor and associated memory based on the OP-TEE device tree. Based on the device tree configuration. Its role is to determine if the Cortex®-M firmware image is managed by:
    • The OP-TEE remoteproc framework (signed firmware images): In this configuration the remoteproc driver lists the memory regions declared in the device tree for the Cortex®-M usage and manages the Cortex®-M configuration (reset, boot address, TrustZone®...).
    • The Linux remoteproc framework (ELF firmware image): In this configuration the remoteproc driver disables the TrustZone® and provides access rights to the Linux remoteproc framework, in the nonsecure context, to manage the Cortex®-M (reset and nonsecure boot address).


Info white.png Information
In the STM32MPU embedded software distribution, the OP-TEE remoteproc framework imposes that the remoteproc firmware is signed to use the Cortex®-M TrustZone®.

2.2. API description[edit source]

3. Configuration[edit source]

3.1. Build configuration[edit source]

  • CFG_DRIVERS_REMOTEPROC and CFG_STM32MP_REMOTEPROC enable the support the stm32_remoteproc drivers.
  • CFG_REMOTEPROC_PTA enables the support of the remoteproc PTA but also the remoteproc TA.
  • CFG_IN_TREE_EARLY_TAS += remoteproc/80a4c275-0a47-4905-8285-1486a9771a08 specifies that the remoteproc TA is embedded in the OP-TEE OS firmware and accessible during the boot stage (refer to How_to_start_the_coprocessor_from_the_bootloader for detail)).
  • RPROC_SIGN_KEY specify the key used for the firmware image signature (default key is keys/default.pem ).
  • CFG_REMOTEPROC_TA_HEAP_SIZE specify the size of the HEAP used by the remoteproc TA(default is 4kBytes).

3.2. Device tree configuration[edit source]

3.2.1. STM32MP15x lines More info.png[edit source]

The memory-region property defines the RETRAM and MCU SRAM base addresses and sizes in RETRAM and MCU SRAMs reserved for the Cortex®-M firmware and for inter-processor communication.

The memory regions are defined at board level:

  • On the STM32MP157Fx-ED1 evaluation board: The memory-regions are declared and referenced in stm32mp157f-ed1.dts[1].
  • On the STM32MP157Fx-DK discovery board: The memory-regions are declared and referenced in stm32mp15xx-dkx.dtsi[2].

Device tree deltas between signed and nonsigned firmware support:

Nonsigned (ELF) firmware
image support
Signed firmware
image support
&m4_rproc {
	/* no remoteproc device management need in OP-TEE */
	compatible = "st,stm32mp1-m4";
	status = "disabled";
};
&m4_rproc {
	compatible = "st,stm32mp1-m4-tee";
	status = "okay";
	/*
	 * Declare  memories used to run the CM4 firmware and shared memory
	 * used for inter-processors communication (including the resource table)
	 */
	memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&ipc_shmem>;

	/* The resets are managed by the Linux  remoteproc driver */
	resets = <&rcc RST_SCMI_MCU>,
			 <&rcc RST_SCMI_MCU_HOLD_BOOT>;
	reset-names = "mcu_rst", "hold_boot";
};
Info white.png Information
The firmware memory mapping must be set according to these values in the STM32Cube firmware linker script.

For additional details, refer to the wiki article STM32MP15 RAM mapping.

3.2.2. STM32MP25x lines More info.png[edit source]

The memory-region property defines the DDR, RETRAM and/or MCU SRAMs base addresses and sizes reserved for the Cortex®-M secure firmware (TF-M) and nonsecure firmware (STM32Cube firmware), and reserved for inter-processor communication.

The memory regions are defined at board level:

  • On the STM32MP257x-EV1 evaluation board:
    • The memory-regions are declared in stm32mp257f-ev1-ca35tdcid-resmem.dtsi[3].
    • The memory-regions are referenced in the m33_rproc node in stm32mp257f-ev1.dts[4].
  • On the STM32MP257x-DK discovery board:
    • The memory-regions are declared in stm32mp257f-dk-ca35tdcid-resmem.dtsi[5].
    • The memory-regions are referenced in the m33_rproc node in stm32mp257f-dk.dts[6].

Device tree deltas between signed and nonsigned firmware support:

Nonsigned (ELF) firmware
image support
Signed firmware
image support
&m33_rproc {
	compatible = "st,stm32mp2-m33";
	status = "okay";
};
&m33_rproc {
	compatible = "st,stm32mp2-m33-tee";
	status = "okay";
	/*
	 * Declare  memories used to run the CM4 firmware and shared memory
	 * used for inter-processors communication (including the resource table)
	 */
	memory-region = <&cm33_cube_fw>, <&cm33_cube_data>,
					<&ipc_shmem>, <&tfm_code>, <&tfm_data>,
					<&cm33_sram2>;
	/* The resets are managed by the Linux  remoteproc driver */
	resets = <&rcc C2_R>, <&rcc C2_HOLDBOOT_R>;
	reset-names = "mcu_rst", "hold_boot";
};
Info white.png Information
The firmware memory mapping must be set according to these values in the:

4. How to use the framework[edit source]

Refer to the wiki article How to protect the coprocessor firmware.

5. How to debug[edit source]

Refer to the wiki article How to debug OP-TEE.

6. Source code location[edit source]

7. References[edit source]