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.
The objective of the default STM32MPU Embedded Software memory mapping is to propose a generic memory mapping that:
- allows to demonstrate all the features proposed by hardware platform and associate software
- is compliant with the official ST boards
2. Memory mapping[edit source]
2.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 STM32MP25 reference manuals.
The different memory aliases required by Cortex-M33 Armv8-M architecture to differentiate secure and non-secure memories are not represented in below figure.
3. Internal RAM mapping[edit source]
3.1. Overview[edit source]
The SYSRAM, RETRAM, SRAM1/2 and VDERAM (if Video decoder and Video encoder are not used) can be used assigned to the different execution contexts of the platform by configuring the [RISAB internal peripheral|RISAB]] memory firewall.
The STM32MPU Embedded Software is based on a default internal RAM memory mapping which can be modified by customer to fit with its product requirements. The next chapters describe the constraints per type of RAM and memory region.
3.1.1. SYSRAM[edit source]
The SYSRAM is mainly dedicated to the Cortex-A35. As it is used by the ROM code during the cold boot and the D1Standby exit, it is not recommended to dedicated a region of the SYSRAM to the Cortex-M33. Anyway it could be could as shared memory between Cortex-A35 and Cortex-M33 to exchange some data.
The following figure shows the evolution of the SYSRAM mapping during boot flow.
At runtime, the SYSRAM is split in two regions:
- 128kB Cortex-A35 Secure region dedicated to TF-A BL31 secure monitor.
- 128kB Cortex-A35 non-secure region dedicated to HPDMA linked lists management
See SYSRAM internal memory for more information.
3.1.2. SRAM1 and SRAM2[edit source]
In Cortex-A35 main processor mode, SRAM1 is used by FSBL TF-A BL2 to store DDR controller firmware and prepare OTP shadow.
At runtime, the first 4kByte of the SRAM1 are reserved for OTP shadow allowing to share OTP between Cortex-A35 OP-TEE secure OS and Cortex-M33 TF-M secure OS.
Rest of SRAM1 and SRAM2 are allocated in STM32MPU Embedded Software to Cortex-M33 secure and non-secure firmware, when not located in DDR for some low power or performance reasons.
The following figure shows the evolution of SRAM mapping during boot flow:
3.1.3. RETRAM[edit source]
In STM32MPU Embedded Software, RETRAM is used for:
- DDR parameters saving to restore DDR access on low power modes exit
- Cortex-M33 firmware that must be preserved in low powoer Standby mode. It is mainly the low power entry and exit functions executed by the Cortex-M33 secure context.
3.1.4. BKPSRAM[edit source]
In STM32MPU Embedded Software, the BKPSRAM is used as following:
- 4kB dedicated to secure SW components context saving for restoration during low power exit sequence
- 4kB for TF-M Internal Trusted Storage (ITS)
3.1.5. VDERAM[edit source]
In STM32MPU Embedded Software, VDERAM is by default allocated to hardware video encoder and decoder if VENC or VDEC is assigned to one execution context.
Else if none is used, VDERAM could be allocated to any execution context.
3.1.6. LPSRAM[edit source]
LPSRAM are dedicated to Cortex-M0+ firmware and associated shared memory. The default memory mapping is the following one: File:STM32MP25 lpsram mapping
Note LPSRAM are currently not used in STM32MPU Embedded Software.
3.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.
3.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>;
};
4. DDR mapping[edit source]
|
Coming soon |
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 