Last edited 10 months ago

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

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.


DDRBackup registersBKPSRAMCAN SRAMSRAMSYSRAMROM
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.

  • 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

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]

Under construction.png Coming soon