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.

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 Embedded SW

by secure and non-secure Arm^® Cortex^® contexts as described in SYSRAM internal memory and STM32MP2 SRAM internal memory articles.

124kB Secure region dedicated to OP-TEE mainly for secure monitor services.

SYSRAM is split in two parts:

4kB non-secure region dedicated to SCMI shared memory for message exchange between OP-TEE and non-secure firmware

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