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 to ensure the integrity of the firmware running on the coprocessor.
See also How_to_protect_the_coprocessor_firmware.
2. System overview[edit source]
2.1. Component description[edit source]
- remoteproc Trusted application(TA): this is the remote processor framework generic part. Its role is to provide interface to the Linux remoteproc framework to:
- Load and authenticate a firmware image in the remote processor memory.
- Provide 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 to the management of the Cortex-M coprocessor. Its role is to provide atomic services to the remoteproc TA:
- Load and authenticate image segment in the remote processor memory.
- manage the memory regions isolations
- stm32mp_remoteproc driver: configuration of the Cortex-M coprocessor and associated memory based on the OP-TEE device tree.Based on the device tree configurationits 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 list the memory regions declared in the device tree for the Cortex-M usage. and manage the Cortex-M configuration (reset, boot address, Trust Zone,...)
- The Linux remoteproc framework (ELF firmware image): In this configuration the remoteproc driver disables the Trust Zone and provides access right to the Linux remoteproc framework, in the non secure context, to manage the Cortex-M (reset and non secure boot address).
- Determine if the Cortex-M firmware image is managed by:
2.2. API description[edit source]
- The emoteproc TA API is available in ta/remoteproc/include/ta_remoteproc.h .
- The remoteproc PTA API is available in lib/libutee/include/remoteproc_pta.h .
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 )
3.2. Device tree configuration[edit source]
3.2.1. STM32MP15x lines
[edit source]
The memory regions properties define the RETRAM and MCU SRAMs 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 non signed firmware support:
Non-signed (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>, <&vdev0vring0>, <&vdev0vring1>, <&vdev0buffer>, <&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"; }; |
3.2.2. STM32MP25x lines
[edit source]
The memory regions properties define the DDR, RETRAM and/or MCU SRAMs base addresses and sizes reserved for the Cortex-M secure firmware (TF-M) and non-secure firmware (STM32Cube firmware), and reserved for inter processor communication.
The Memory regions are defined at board level:
- On the STM32MP257x-EV1 Evaluation board:
OP-TEE_OS | core/arch/arm64/boot/dts/st/stm32mp257f-ev1-ca35tdcid-resmem.dtsi| STM32MP257F EV1 board reserved memory device tree configuration file}}</ref>
- The memory-regions are referenced in the m33_rproc node in stm32mp257f-ev1.dts[3]
- On the STM32MP257x-DK Discovery board:
Device tree deltas between signed and non signed firmware support:
Non-signed (ELF) firmware image support |
Signed firmware image support | |
---|---|---|
&m33_rproc { compatible = "st,stm32mp1-m33"; status = "okay"; }; |
&m33_rproc { compatible = "st,stm32mp1-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| The firmware memory mapping must be set according to these values in the:
- STM32Cube firmware linker scripts.
- TF-M linker script
- OP-TEE RIF device tree.
4. How to use the framework[edit source]
Refer to How_to_protect_the_coprocessor_firmware.
5. How to debug[edit source]
Refer to How_to_debug_OP-TEE
6. Source code location[edit source]
- Remoteproc trusted application:
- Remoteproc pseudo trusted application:
- Remoteproc stm32 driver:
7. References[edit source]