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 STM32MP15 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 Cortex-A7 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.
4. Internal RAM mapping[edit source]
4.1. Overview[edit source]
- MCU SRAM4 (DMA) can be used for other purpose if DMA1 and/or DMA2 is not used in chained mode (using MDMA)
4.2. How to do that in practice[edit source]
The memory usage is defined in both Cortex contexts:
- on 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. MCU SRAM4[edit source]
By default the MCU SRAM4 is reserved for DMA chaining for Linux features. It can be freed for some other purposes by removing following:
- Linux device tree
- Remove followings declarations:
&sram { dma_pool: dma_pool@0 { reg = <0x50000 0x10000>; pool; };
&dma1 { sram = <&dma_pool>; }; &dma2 { sram = <&dma_pool>; };