STM32MP13 RAM 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 | 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 | 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 | 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 | edit source]

3.1. Overall memory mapping[edit | 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 | edit source]

4.1. BKPSRAM[edit | edit source]

In the STM32MPU Embedded Software architecture, the BKPSRAM internal memory is used as follows:

At boot time: not used during a cold boot
At runtime:

DDR off in Standby: not used
DDR in self-refresh in Standby: contains the low-power context used by the runtime secure monitor (the Trusted Firmware-A (TF-A) BL2 as the FSBL or the OP-TEE secure OS) during wake-up from Standby low-power mode. Refer to STM32MP1 power overview for details.

4.2. SYSRAM[edit | edit source]

At boot time, the ROM code leaves the SYSRAM internal memory secure when it jumps to the entry point of the FSBL (Trusted Firmware-A (TF-A)) that it has just loaded.

At runtime, SYSRAM is secure and contains the Trusted Firmware-A (TF-A) for low-power purposes.

Refer to boot chain for details.

4.3. SRAM[edit | edit source]

The memory usage is defined in Linux^® device tree, using Reserved_memory mechanism

To ensure the consistency of the system, memory declarations have to be updated according to the expected configuration. 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 | edit source]

STM32MPU Embedded Software defines a generic DDR mapping that supports DDR sizes from 256 MB to 1 GB. This mapping demonstrates all features of STM32MPU Embedded Software.

The last 32 MB are reserved for OP-TEE secure OS firmware.
The rest of DDR is allocated to the Linux kernel and applications.

The following figure shows how the 1 GB DDR mapping changes during the boot sequence.