STM32MP25 memory mapping

Applicable for

This article describes how the STM32 MPU Embedded Software distribution maps the various software memory needs in internal and external volatile memories.

1. Overview[edit source]

This article shows the default memory mapping defined by STMicroelectronics in STM32MPU Embedded Software. It uses a subset of all memory regions that are exposed at hardware level: customers may use other memory regions or aliases that are not shown here but are described in the STM32MP13 reference manuals.
The objective of the default STM32MPU Embedded Software memory mapping is to propose a generic memory mapping that:

allows to demonstrate all the features proposed by hardware platform and associate software
is compliant with the official ST boards

2. Memory mapping[edit source]

2.1. Overall memory mapping[edit source]

The memory mapping below is a subset of all regions that are exposed at hardware level: it shows the default configuration used in OpenSTLinux but the customer may choose a different mapping to take advantage of other address ranges defined in STM32MP25 reference manuals.
The different memory aliases required by Cortex-M33 Armv8-M architecture to differentiate secure and non-secure memories are not represented in below figure.

STM32MP25 memory mapping

3. Internal RAM mapping[edit source]

3.1. Overview[edit source]

The SYSRAM, RETRAM, SRAM1/2 and VDERAM (if Video decoder and Video encoder are not used) can be used assigned to the different execution contexts of the platform by configuring the [RISAB internal peripheral|RISAB]] memory firewall.

The STM32MPU Embedded Software is based on a default internal RAM memory mapping which can be modified by customer to fit with its product requirements. The next chapters describe the constraints per type of RAM and memory region.

3.1.1. SYSRAM[edit source]

The SYSRAM is mainly dedicated to the Cortex-A35. As it is used by the ROM code during the cold boot and the D1Standby exit, it is not recommended to dedicated a region of the SYSRAM to the Cortex-M33. Anyway it could be could as shared memory between Cortex-A35 and Cortex-M33 to exchange some data.

At runtime, the SYSRAM is split in two regions:

128kB Cortex-A35 Secure region dedicated to TF-A BL31 secure monitor.
128kB Cortex-A35 non-secure region dedicated to HPDMA linked lists management

See SYSRAM internal memory for more information.

3.1.2. SRAM1 and SRAM2[edit source]

SRAM1 and SRAM2 are currently not used by default by STM32MPU Embedded Software. SRAM1 and SRAM2 main allocation is Cortex-M33 secure and non-secure firmware, when not located in DDR for some low power or performance reasons.

3.1.3. RETRAM[edit source]

3.1.4. VDERAM[edit source]

In STM32MPU Embedded Software, VDERAM is by default allocated to hardware video encoder and decoder. It is not allocation to any execution context.

3.2. How to configure Internal RAM mapping[edit source]

The memory usage is defined in both Arm^® Cortex^® contexts:

on secure Arm^® Cortex^®-A7: in OP-TEE device tree, using Reserved_memory mechanism
on non-secure Arm^® Cortex^®-A7: in Linux^® device tree, using Reserved_memory mechanism

To ensure the consistency of the system, both memory declarations have to be updated according to the expected configuration.

3.2.1. SRAM[edit source]

By default part of the SRAM is reserved for DMA chaining for Linux^® features. It can be freed for some other purposes by removing the following declarations in Linux^® device tree :

&sram {
    dma_pool: dma_pool@0 {
    reg = <0x0 0x4000>;
    pool;
};

&dma1 {
	sram = <&dma_pool>;
};

&dma2 {
	sram = <&dma_pool>;
};

4. DDR mapping[edit source]

Coming soon