STM32MP13 RAM mapping

Applicable for

STM32MP13x lines

---

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

1 Overview

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 Arm core characteristics

The integration of Arm^® Cortex^® cores sets some constraints on the device memory mapping: the main ones are listed in this article.

2.1 Reset address

Arm^® Cortex^® cores start running from address 0x00000000 on reset, which is why this address respectively points to:

• The ROM code on the Arm^® Cortex^® side. This read-only memory embeds the boot code that is executed when the platform boots (and executes the boot chain) or wakes up from low power STANDBY mode.

3 Memory mapping

3.1 Overall memory mapping

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 STM32MP13 reference manuals.

4 Internal RAM mapping

4.1 Overview

SYSRAM and SRAM can be used by secure and non-secure Arm^® Cortex^® contexts as described in SYSRAM internal memory and STM32MP13 SRAM internal memory articles.

SYSRAM is split in two parts:

• 124kB Secure region dedicated to OP-TEE mainly for secure monitor services.
• 4kB non-secure region dedicated to SCMI shared memory for message exchange between OP-TEE and non-secure firmware

4.2 How to configure Internal RAM mapping

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.

4.2.1 SRAM

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>;
};

5 DDR mapping

Coming soon