STM32MP13 RAM mapping

This message will disappear after all relevant tasks have been resolved.

Semantic MediaWiki

There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

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[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. Arm core characteristics[edit source]

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[edit source]

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[edit source]

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

STM32MP13 memory mapping

4. Internal RAM mapping[edit source]

4.1. Overview[edit source]

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[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.

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

5. DDR mapping[edit source]

Coming soon