This article lists all internal peripherals embedded in STM32MP13 device and shows the assignment possibilities to the runtime contexts for each one of them.
From this article, you can also access to individual peripheral articles with information related to the overview and configuration aspects.
1. Internal peripherals overview[edit source]
The figure below shows all peripherals embedded in STM32MP13 device, grouped per functional domains that are reused in many places of this wiki to structure the articles.
Several runtime contexts exist on STM32MP13 device, corresponding to the Arm Cortex-A7 security modes:
- Arm Cortex-A7 secure (Trustzone), running a Secure Monitor or Secure OS like OP-TEE
- Arm Cortex-A7 non secure , running Linux
Some peripherals can be strictly assigned to one runtime context, this is the case for most of the peripherals, like USART or I2C.
Other ones can be shared between several runtime contexts, this is the case for system peripherals like PWR or RCC.
The legend below shows how assigned and shared peripherals are identified in the assignment diagram that follows.
Both the diagram below and the following summary table (in the Internal peripherals assignment chapter below) are clickable in order to jump to each peripheral overview article and get more detailed information (like the software frameworks used to control them). These list STMicroelectronics recommendations. The STM32MP13 reference manual [1] may expose more possibilities then what is shown here.
![](/stm32mpu/nsfr_img_auth.php/2/28/STM32MP13IPsOverview.png)
2. Internal peripherals assignment[edit source]
Click on the right to expand the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned (☑) to the given runtime context.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are statically connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possiblities might be described in STM32MP13 reference manuals.
3. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the ADC peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
4. Peripheral overview[edit source]
The ADC peripheral is a successive approximation analog-to-digital converter.
The STM32MP13x SoCs have two ADC blocks, except for the STM32MP131 SoC which has only one ADC block. There is one physical ADC per block:
- Each ADC has up to 19 multiplexed channels (including 6 internal channels available only on ADC2).
- Configurable resolution: 6, 8, 10, 12 bits.
- The conversions can be performed in single, continuous, scan or discontinuous mode.
- The result can be read in a left- or right-aligned 32-bit data register by using CPU or DMA[2].
- The analog watchdog feature allows the application to detect if the input voltage goes beyond the user-defined, high or low thresholds.
- Each ADC clock can be selected between two different clock[3] sources (Synchronous or Asynchronous clock).
- The common reference voltage can be provided by either VREFBUF[4] or any other external regulator[5] wired to VREF+ pin.
Each ADC supports two contexts to manage conversions:
- Regular conversions can be done in sequence, running in background
- Injected conversions have higher priority, and so have the ability to interrupt the regular sequence (either triggered in SW or HW). The regular sequence is resumed, in case it has been interrupted.
- Each context has its own configurable sequence and trigger: software, TIM[6], LPTIM[7] and EXTI[8].
Refer to the STM32MP13 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
5. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
5.1. Boot time assignment[edit source]
5.1.1. On STM32MP13x lines
[edit source]
The ADC is usually not used at boot time. But it may be used by the SSBL (see Boot chain overview), to check for power supplies for example.
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.
Domain | Peripheral | Runtime allocation | Comment | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) |
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A7 secure (ROM code) |
Cortex-A7 secure (TF-A BL2) |
Cortex-A7 non-secure (U-Boot) | |||
Analog | ADC | Any instance | ☐ |
5.2. Runtime assignment[edit source]
5.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Analog | ADC | ADC1 | ☐ | ☐ | Assignment (single choice) |
ADC2 | ☐ | ☐ | Assignment (single choice) ADC2 can be used for system supplies monitoring |
6. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the ADC peripheral for the embedded software components listed in the above tables.
- Linux®: IIO framework
- OP-TEE: OP-TEE ADC driver
- U-Boot: U-Boot ADC driver
7. How to assign and configure the peripheral[edit source]
The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:
- partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
- HAL initialization code generation for the STM32CubeMPU Package.
The configuration is applied by the firmware running in the context in which the peripheral is assigned.
For the Linux kernel, U-boot and OP-TEE configuration, please refer to ADC device tree configuration article.
8. How to go further[edit source]
See application notes:
- How to get the best ADC accuracy in STM32[9].
9. References[edit source]
10. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the VREFBUF peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
11. Peripheral overview[edit source]
The VREFBUF peripheral is an internal voltage regulator.
The VREFBUF is supplied via the VDDA pin. When enabled, it can provide a reference voltage in the range of: 1,65V, 1,8V, 2,048V or 2,5V. The VREFBUF can be used to provide an analog voltage reference for:
- ADC internal peripheral
- External components through the dedicated VREF+ pin.
The VREFBUF can be left unused. In this case, an external voltage regulator can provide reference voltage to VREF+ pin.
Refer to the STM32MP13 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
12. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
12.1. Boot time assignment[edit source]
12.1.1. On STM32MP13x lines
[edit source]
The VREFBUF is usually not used at boot time. But it may be needed by the SSBL (see Boot chain overview), to supply the internal ADC for example.
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A7 secure (ROM code) |
Cortex-A7 secure (TF-A BL2) |
Cortex-A7 non-secure (U-Boot) | |||
Analog | VREFBUF | VREFBUF | ☐ |
12.2. Runtime assignment[edit source]
12.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Analog | VREFBUF | VREFBUF | ☐ | ☐ | Assignment (single choice) |
![]() |
As soon as one VREFBUF client peripheral (ADC1 or ADC2) is set secure, the VREFBUF should be set secure with ETZPC configuration. In OpenSTlinux, VREFBUF is only managed by OP-TEE exported through SCMI even if all ADC are non-secured. |
13. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the VREFBUF peripheral for the embedded software components listed in the above tables.
- Linux®: regulator framework
- OP-TEE: OP-TEE SCMI
14. How to assign and configure the peripheral[edit source]
The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:
- partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
- HAL initialization code generation for the STM32CubeMPU Package.
The configuration is applied by the firmware running in the context in which the peripheral is assigned.
- For the Linux kernel configuration, please refer to device internal regulator. An example can be found also in ADC DT configuration examples
14.1. DT configuration example[edit source]
In OP-TEE device tree:
&etzpc { st,decprot = < DECPROT(STM32MP1_ETZPC_VREFBUF_ID, DECPROT_S_RW, DECPROT_UNLOCK) >; }; &scmi_regu { scmi_vrefbuf: voltd-vrefbuf { reg = <VOLTD_SCMI_VREFBUF>; voltd-supply = <&vrefbuf>; }; }; &vrefbuf { vdda-supply = <&vdd>; status = "okay"; };
In Linux device tree:
&adc_1 { ... vref-supply = <&scmi_vrefbuf>; status = "okay"; };
&scmi_regu {
scmi_vrefbuf: voltd-vrefbuf {
reg = <VOLTD_SCMI_VREFBUF>;
regulator-name = "vrefbuf";
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <2500000>;
};
};
15. References[edit source]
STM32MP13 RTC internal peripheral
STM32MP13 SYSCFG internal peripheral
16. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the SRAM internal memory peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
17. Peripheral overview[edit source]
The SRAM peripheral is 32-Kbyte wide, split into three separate banks:
- SRAM1 (16 Kbytes)
- SRAM2 (8 Kbytes)
- SRAM3 (8 Kbytes)
Those banks have individual security control (see security support in the runtime assignment table below) and automatic clock gating (for power management optimization), but they are not supplied when the system goes to Standby low power mode, so their content is lost in that case.
Refer to the STM32MP13 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
18. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
18.1. Boot time assignment[edit source]
18.1.1. On STM32MP13x lines
[edit source]
The ROM code uses:
- the SRAM1 and SRAM2 to store internal data
- the SRAM3 to store the FSBL header
This ROM code mapping strategy aims to leave the whole SYSRAM internal memory free for FSBL binary loading then execution.
The TF-A BL2 uses:
- the SRAM1 to store boot NAND 4kB scratch buffer
- the SRAM2 to store MbedTLS in case of secure boot
- the SRAM3 to store fw-config DT
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A7 secure (ROM code) |
Cortex-A7 secure (TF-A BL2) |
Cortex-A7 non-secure (U-Boot) | |||
Core/RAM | SRAM | Any instance | ✓ | ☑ | ☐ | SRAM first used by ROM code, then TF-A BL2. After assignment free to user |
18.2. Runtime assignment[edit source]
18.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Core/RAM | SRAM | SRAM1 | ☐ | ☐ | Assignment (between A7 S and A7 NS) |
SRAM2 | ☐ | ☐ | Assignment (between A7 S and A7 NS) | ||
SRAM3 | ☐ | ☐ | Assignment (between A7 S and A7 NS) |
19. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the XXX peripheral for the embedded software components listed in the above tables.
- Linux®: reserved memory, that is used by the dmaengine (for DMA buffers management)
- OP-TEE: OP-TEE
- TF-A BL2: TF-A BL2
20. How to assign and configure the peripheral[edit source]
The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:
- partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
- HAL initialization code generation for the STM32CubeMPU Package.
The configuration is applied by the firmware running in the context in which the peripheral is assigned.
21. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the PWR peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
22. Peripheral overview[edit source]
The PWR peripheral is used to control the device power supply configuration.
It has 6 input pins (named wakeup pins) which can be programmed to wake the system up from low power. The wakeup pins are listed with WKUP prefix in the STM32MP13 Datasheet.
These pins can be used by the Cortex®-A7 non secure (via Cortex®-A7 secure services).
The PWR peripheral provides 3 output hardware lines named PWR_ON, PWR_LP and PWR_CPU_ON:
- In STPMIC1 configuration, PWR_ON allows to select the register bank (active or low power). PWR_LP and PWR_CPU_ON are not used.
- In the power discrete solution they drive VDDcore which feeds the Cortex®-A7 and the peripherals. They also control the DDR power supplies (VDD_DDR, VREF_DDR, VTT_DDR) and VDDCpu that feeds the porcessor.
Refer to the STM32MP13 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
23. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
23.1. Boot time assignment[edit source]
23.1.1. On STM32MP13x lines
[edit source]
The PWR is closely configured together with RCC by all the boot components: the ROM code, the FSBL, the SSBL. Its configuration is carried by the device tree.
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A7 secure (ROM code) |
Cortex-A7 secure (TF-A BL2) |
Cortex-A7 non-secure (U-Boot) | |||
Power & Thermal | PWR | PWR | ✓ | ✓ |
23.2. Runtime assignment[edit source]
23.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Power & Thermal | PWR | PWR | ✓ |
24. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the PWR peripheral for the embedded software components listed in the above tables.
- Linux®: power management, regulator framework with SCMI regulators
- OP-TEE:
25. How to assign and configure the peripheral[edit source]
The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:
- partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
- HAL initialization code generation for the STM32CubeMPU Package.
The configuration is applied by the firmware running in the context in which the peripheral is assigned:
26. How to go further[edit source]
The PWR is interfaced with the hardware debug port (HDP) of the STM32MP13. This link offers the flexibility to observe the main PWR state signals on debug pins.
Please refer to STM32MP13 reference manuals for the exact list of signals that can be monitored.
STM32MP13 RCC internal peripheral
STM32MP13 ETZPC internal peripheral STM32MP13 HASH internal peripheral
27. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the DDRMCE peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
28. Peripheral overview[edit source]
The DDRMCE (DDR Memory Cipher Engine) peripheral allows to define one AES encrypted region in DDR memory.
![]() |
Functions and registers names declared in the embedded software are using "MCE" / "mce" acronym instead of the longest "DDRMCE" / "ddrmce" ones, so take care about this for any research in the code. |
The DDRMCE 128-bit master key is provisioned during boot processing, in order to use AES[1] block ciphering feature. It must be fully saved in BKPSRAM for low power sequences.
Refer to the STM32MP13 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
29. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
29.1. Boot time assignment[edit source]
29.1.1. On STM32MP13x lines
[edit source]
The DDRMCE peripheral, part of the DDR subsystem, is configured inside TF-A BL2 to setup the security of a DDR region thanks to TF-A FW Configuration. This should be done before accessing DDR region if encryption is required.
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A7 secure (ROM code) |
Cortex-A7 secure (TF-A BL2) |
Cortex-A7 non-secure (U-Boot) | |||
Security | DDRMCE | DDRMCE | ☑ |
29.2. Runtime assignment[edit source]
29.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Security | DDRMCE | DDRMCE | ⬚ | ⬚ |
30. Software frameworks and drivers[edit source]
All system bus traffic going through an encrypted region is managed on-the-fly by the DDRMCE, automatically decrypting reads and encrypting writes: see the memory mapping.
31. How to assign and configure the peripheral[edit source]
The DDRMCE configuration is generated via STM32CubeMX tool, according to the region characteristics (address, length, type). This configuration is applied during boot time by the FSBL (see Boot chain overview): TF-A.
32. References[edit source]
33. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the PKA peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
34. Peripheral overview[edit source]
The PKA (public key accelerator) peripheral is used to ease computation of cryptographic public key primitives, specifically those related to RSA, Diffie-Hellmann or ECC (elliptic curve cryptography) over GF(p) (Galois fields).
Refer to the STM32MP13 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
35. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
35.1. Boot time assignment[edit source]
35.1.1. On STM32MP13x lines
[edit source]
The PKA peripheral is a boot device, it is used for signature verification on secure boot processing.
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A7 secure (ROM code) |
Cortex-A7 secure (TF-A BL2) |
Cortex-A7 non-secure (U-Boot) | |||
Security | PKA | PKA | ✓ | ☑ | ⬚ | Assignment is mandatory only for secure boot |
35.1.2. On STM32MP2 series[edit source]
Click on to expand or collapse the legend...
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A35 secure (ROM code) |
Cortex-A35 secure (TF-A BL2) |
Cortex-A35 non-secure (U-Boot) | |||
Security | PKA | PKA | ✓ | ☑ | ⬚ | Assignment is mandatory only for secure boot |
35.2. Runtime assignment[edit source]
35.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Security | PKA | PKA | ☐ | ⬚ | Assignment (single choice) |
35.2.2. On STM32MP25x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | |||||
---|---|---|---|---|---|---|---|---|
Instance | Cortex-A35 secure (OP-TEE / TF-A BL31) |
Cortex-A35 non-secure (Linux) |
Cortex-M33 secure (TF-M) |
Cortex-M33 non-secure (STM32Cube) |
Cortex-M0+![]() (STM32Cube) | |||
Security | PKA | PKA | ☐OP-TEE | ⬚ | ☐ | ⬚ |
36. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the PKA peripheral for the embedded software components listed in the above tables.
- OP-TEE: PKA driver through the ECC framework
- TF-A BL2: TF-A Crypto Library
37. How to assign and configure the peripheral[edit source]
The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:
- partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
- HAL initialization code generation for the STM32CubeMPU Package.
The configuration is applied by the firmware running in the context in which the peripheral is assigned.
STM32MP13 RNG internal peripheral
38. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the SAES peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
39. Peripheral overview[edit source]
The SAES peripheral provides hardware acceleration to encrypt or decrypt data using the AES[1] algorithms. It supports two key sizes (128 bits and 256 bits) and different chaining modes. It incorporates protections against differential power analysis (DPA) and the related side-channel attacks.
Refer to the STM32MP13 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
40. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
40.1. Boot time assignment[edit source]
40.1.1. On STM32MP13x lines
[edit source]
The SAES instance is used to decrypt the firmware.
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A7 secure (ROM code) |
Cortex-A7 secure (TF-A BL2) |
Cortex-A7 non-secure (U-Boot) | |||
Security | SAES | SAES | ☐ | ☑ | ROM code allocation is managed with the bit 7 in OTP 9 |
40.1.2. On STM32MP25x lines
[edit source]
Click on to expand or collapse the legend...
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A35 secure (ROM code) |
Cortex-A35 secure (TF-A BL2) |
Cortex-A35 non-secure (U-Boot) | |||
Security | SAES | SAES | ☐ | ☑ | ⬚ | ROM code allocation is managed with the bit 8 in OTP 16 |
40.2. Runtime assignment[edit source]
40.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Security | SAES | SAES | ☐ | ⬚ | Assignment (single choice) |
40.2.2. On STM32MP25x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | |||||
---|---|---|---|---|---|---|---|---|
Instance | Cortex-A35 secure (OP-TEE / TF-A BL31) |
Cortex-A35 non-secure (Linux) |
Cortex-M33 secure (TF-M) |
Cortex-M33 non-secure (STM32Cube) |
Cortex-M0+![]() (STM32Cube) | |||
Security | SAES | SAES | ☐OP-TEE | ⬚ | ☐ | ⬚ |
41. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the SAES peripheral for the embedded software components listed in the above tables.
- Linux®: crypto framework
- OP-TEE: SAES driver and Cryptographic Provider API (CP API)
- TF-A BL2: SAES driver
42. How to assign and configure the peripheral[edit source]
The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:
- partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
- HAL initialization code generation for the STM32CubeMPU Package.
The configuration is applied by the firmware running in the context in which the peripheral is assigned.
43. References[edit source]
STM32MP13 TAMP internal peripheral
44. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the DCMIPP peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
45. Peripheral overview[edit source]
The DCMIPP (digital camera memory interface pixel processor) peripheral is used to receive video data from an external parallel camera sensor device, or from any other digital video equipment supporting a parallel interface.
The DCMIPP hardware block can receive various frame data formats such as: RAW8, RGB565, YUV422 and other formats, as well as compressed data such as JPEG.
Moreover, on STM32MP25x lines :
- the DCMIPP is also connected to the CSI internal peripheral that provides an interface to communicate with MIPI® CSI-compliant camera sensors: the DCMIPP is able to get pixels from the parallel or MIPI® CSI interface.
- the DCMIPP embeds 3 dedicated pixel pipelines named "dump", "main" and "auxiliary": camera sensor data go into these pixel pipelines before they are sent to memory for further processing or display purposes.
Refer to the STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.
46. Peripheral usage[edit source]
This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.
46.1. Boot time assignment[edit source]
46.1.1. On STM32MP1 series[edit source]
The DCMIPP peripheral is not used at boot time.
46.1.2. On STM32MP2 series[edit source]
Click on to expand or collapse the legend...
- ☐ means that the peripheral can be assigned to the given boot time context.
- ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.
Domain | Peripheral | Boot time allocation | Comment ![]() | |||
---|---|---|---|---|---|---|
Instance | Cortex-A35 secure (ROM code) |
Cortex-A35 secure (TF-A BL2) |
Cortex-A35 non-secure (U-Boot) | |||
Visual | DCMIPP | DCMIPP | ⬚ |
46.2. Runtime assignment[edit source]
46.2.1. On STM32MP13x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP13 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | ||
---|---|---|---|---|---|
Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) | |||
Visual | DCMIPP | DCMIPP | ☑ |
46.2.2. On STM32MP25x lines
[edit source]
Click on to expand or collapse the legend...
Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:
- ☐ means that the peripheral can be assigned to the given runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.
Domain | Peripheral | Runtime allocation | Comment ![]() | |||||
---|---|---|---|---|---|---|---|---|
Instance | Cortex-A35 secure (OP-TEE / TF-A BL31) |
Cortex-A35 non-secure (Linux) |
Cortex-M33 secure (TF-M) |
Cortex-M33 non-secure (STM32Cube) |
Cortex-M0+![]() (STM32Cube) | |||
Visual | DCMIPP | DCMIPP | ⬚OP-TEE | ☑ | ⬚ | ☐ |
47. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the DCMIPP peripheral for the embedded software components listed in the above tables.
- Linux®: V4L2 framework
- STM32Cube:
- for STM32MP13x lines
: DCMIPP HAL driver and header file of DCMIPP HAL module
- for STM32MP25x lines
: DCMIPP HAL driver and header file of DCMIPP HAL module
- for STM32MP13x lines
48. How to assign and configure the peripheral[edit source]
The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:
- partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
- HAL initialization code generation for the STM32CubeMPU Package.
The configuration is applied by the firmware running in the context in which the peripheral is assigned.
See also additional information in the DCMIPP device tree configuration article for Linux®.
49. References[edit source]