1. Article purpose[edit | edit source]
The purpose of this document is to provide information on how to setup the DDR configuration on both STM32MP1 series and STM32MP2 series based products.
2. Introduction[edit | edit source]
This article is a guideline for the user to update the STM32MPU Embedded Software distribution package of the OpenSTLinux, with the objective to setup a new DDR configuration, which gathers settings from top level (DDR type, DDR size, bus width, frequency...) to bottom level (DDRCTRL and DDRPHYC register content).
Refer to the DDRCTRL and DDRPHYC internal peripherals for more information on this peripherals.
For each STM32MP1 series / STM32MP2 series, related changes are described per software component.
A special focus is done on the DDR size change, because there are several impacts notably in the Device tree content.
3. Pre-requesites[edit | edit source]
Before modifying the OpenSTLinux software components to setup your DDR configuration, you must construct it with the STM32CubeMX DDR tool, which creates the "device tree source include" file, see the wiki page STM32CubeMX for details.
STM32DDRFW-UTIL tool is recommended to create the new DDR configuration from top level parameters such as STM32MP1 series / STM32MP2 series, DDR type, bus width, frequency. This tool works with STM32CubeMX to run test algorithms for validation purpose.
As soon as the new DDR configuration fits with requirements and runs successfully all the STM32CubeMX test suite, it can be considered as a good candidate. Adaptations within OpenSTLinux software components can start.
4. STM32MP1 series[edit | edit source]
4.1. Context description[edit | edit source]
On STM32MP1 series we have:
- DDR base address = 0xC0000000
- DDR size is generally equal to 4Gbits (i.e. 512MB = 0x20000000) or 8Gbits (i.e. 1GB = 0x40000000). 2Gbits (i.e. 256MB = 0x10000000) specific case is described in the How to configure a 256MB DDR mapping from STM32 MPU Distribution Package article.
Along the following sub-chapters, a concrete example will be used to illustrate the method: update the DDR configuration on STM32MP135x-DK board with following changes:
| STM32MP135x-DK | Current config | New config |
|---|---|---|
| DDR size | 512MB | 1GB |
4.2. TF-A[edit | edit source]
The first step is to store the new DDR setting file within the TF-A source tree in this specific directory: fdts . In our example, the file name could be stm32mp13-ddr3-1x8Gb-1066-binF.dtsi. This file has been generated and tested with STM32CubeMX, so it just has to be formatted as other existing files (a large part of it is already done). Note that in our example, the file contains:
#define DDR_MEM_SIZE 0x40000000
This new file must be included in the top board device tree file. In our example, fdts/stm32mp135f-dk.dts file contains:
#include "stm32mp13-ddr3-1x8Gb-1066-binF.dtsi"
In this file, the memory node must also be aligned with the DDR_MEM_SIZE. In our example, you must have this:
memory@c0000000 { device_type = "memory"; reg = <0xc0000000 0x40000000>; };
Still in the top board device tree file, depending on the update, the DDR clock could change. In that case, PLL2 clock frequency must be aligned. DDR type or characteristics could imply to update the DDR related power supplies. This part is not detailed in this article, because closely linked to the hardware layout. Please refer to PMIC hardware components and examples provided in the TF-A source code.
The related FWCONFIG file contains the DDR_SIZE definition, it must fit with DDR_MEM_SIZE. In our example, fdts/stm32mp135f-dk-fw-config.dts file should contain:
#define DDR_SIZE 0x40000000
4.3. OP-TEE[edit | edit source]
In core/arch/arm/plat-stm32mp1/conf.mk , there are two flavor lists which depend on the DDR size (flavorlist-512M and flavorlist-1G). They cover all cases defined in the context of this article. You have to ensure that your flavor (created or modified) is classified correctly. It will assign the right value to CFG_DRAM_SIZE parameter.
In our example, 'flavor_dts_file_135F_DK' shall be moved from 'flavorlist-cryp-512M' to 'flavorlist-cryp-1G'. This implies a new CFG_DRAM_SIZE value of 0x40000000.
In the top board device tree file (or in lower level depending on cases), the memory and reserved-memory nodes must be aligned with the CFG_DRAM_SIZE. 'memory' node simply contains the DDR size. For 'reserved-memory' node, regions located at the end of the DDR must be shifted accordingly. In our example, core/arch/arm/dts/stm32mp135f-dk.dts must contain:
memory@c0000000 { device_type = "memory"; reg = <0xc0000000 0x40000000>; }; reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; optee_framebuffer: optee-framebuffer@ed000000 { /* Secure framebuffer memory */ reg = <0xed000000 0x1000000>; st,protreg = <TZC_REGION_S_RDWR 0>; }; };
Still in this file, as said before, user may need to update PLL2 clock frequency and DDR related power supplies (nominal and low power cases this time).
4.4. U-Boot[edit | edit source]
As on OP-TEE, in the top board device tree file (or in lower level depending on cases), the memory and reserved-memory nodes must be aligned with the the DDR size. In our example, arch/arm/dts/stm32mp135f-dk.dts must contain:
memory@c0000000 { device_type = "memory"; reg = <0xc0000000 0x40000000>; }; reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; optee@ed000000 { reg = <0xed000000 0x3000000>; no-map; }; };
4.5. Linux kernel[edit | edit source]
This is the same level of modifications as on U-Boot as device trees are aligned. In out example, arch/arm/boot/dts/st/stm32mp135f-dk.dts must contain:
memory@c0000000 { device_type = "memory"; reg = <0xc0000000 0x40000000>; }; reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; optee@ed000000 { reg = <0xed000000 0x3000000>; no-map; }; };
5. STM32MP2 series[edit | edit source]
5.1. Context description[edit | edit source]
On STM32MP2 series we have:
- DDR base address = 0x80000000
- DDR size is generally equal to 8Gbits (i.e. 1GB = 0x40000000),16Gbits (i.e. 2GB = 0x80000000) or 32Gbits (i.e. 4GB = 0x100000000).
Along the following sub-chapters, a concrete example will be used to illustrate the method: update the DDR configuration on STM32MP215x-DK board with following changes:
| STM32MP215x-DK | Current config | New config |
|---|---|---|
| DDR type | LPDDR4 | DDR3 |
| DDR size | 2GB | 1GB |
5.2. TF-A[edit | edit source]
Before all, on STM32MP2 series, the DDR type is mentioned in the TF-A build command so it has to be updated if necessary. It allows to select the correct firmware necessary to execute the DDR training. In our example, STM32MP_LPDDR4_TYPE=1 should be replaced by STM32MP_DDR3_TYPE=1.
The first step is to store the new DDR setting file within the TF-A source tree in this specific directory: fdts . In our example, the file name could be stm32mp21-ddr3-1x8Gbits-1x16bits-800MHz.dtsi. This file has been generated and tested with STM32CubeMX, so it just has to be formatted as other existing files (a large part of it is already done). Note that in our example, the file contains:
#define DDR_MEM_SIZE 0x40000000
This new file must be included in the top board device tree file. In our example, fdts/stm32mp215f-dk.dts file contains:
#include "stm32mp21-ddr3-1x8Gbits-1x16bits-800MHz.dtsi"
In this file, the memory node must also be aligned with the DDR_MEM_SIZE. In our example, you must have this:
memory@80000000 { device_type = "memory"; reg = <0x0 0x80000000 0x0 0x40000000>; };
Still in the top board device tree file, DDR type or characteristics could imply to update the DDR related power supplies. This part is not detailed in this article, because closely linked to the hardware layout. Please refer to PMIC hardware components and examples provided in the TF-A source code.
Depending on the update, the DDR clock could change. In that case, PLL2 clock frequency must be aligned. On STM32MP2 series, a device tree RCC specific file contains all configurations. In our example, this is gathered in fdts/stm32mp215f-dk-ca35tdcid-rcc.dtsi .
5.3. OP-TEE[edit | edit source]
In the top board device tree file, the memory node must be aligned with the DDR size. In our example, core/arch/arm/dts/stm32mp215f-dk.dts must contain:
memory@80000000 { device_type = "memory"; reg = <0x0 0x80000000 0x0 0x40000000>; };
Still in this file, as said before, user may need to update PLL2 clock frequency and DDR related power supplies (nominal and low power cases this time).
Depending on the update, the DDR clock could change. In that case, PLL2 clock frequency must be aligned. On STM32MP2 series, a device tree RCC specific file contains all configurations. In our example, this is gathered in core/arch/arm/dts/stm32mp215f-dk-ca35tdcid-rcc.dtsi .
On STM32MP2 series, RIF configuration allows to list and describe the memory regions with dedicated rights. Please refer to RISAF device tree configuration for more information. DDR regions can be impacted by a DDR size update. To ease understanding in this article, we can define four types of DDR regions:
- Bottom-ref regions are successively located from the DDR base address below "linuxkernel1". Updating DDR size has no impact on their descriptions.
- Top-ref regions are successively located above "linuxkernel1" until the DDR end address (if DDR size ≤ 2GB) or 0xFFFFFFFF (if DDR size = 4GB). Their offsets are impacted by the DDR size.
- "linuxkernel1" region is located between the two previous categories. Only its size is impacted by a DDR size change.
- "linuxkernel2" region is only present if DDR size = 4GB on fixed [0x100000000 .. 0x17FFFFFFF] area.
Address/size couples of each region is described in resmem board device tree file. Access rights and region list (append of RISAF4 node) are described in secure configuration board device tree file.
Back to our example, only the resmem file is modified, i.e. core/arch/arm/dts/stm32mp215f-dk-ca35tdcid-resmem.dtsi :
linuxkernel1: linuxkernel1@84000000 { reg = <0x0 0x84000000 0x0 0x3b800000>; no-map; }; ltdc_sec_layer: ltdc-sec-layer@bf800000 { reg = <0x0 0xbf800000 0x0 0x800000>; no-map; };
5.4. U-Boot[edit | edit source]
As on OP-TEE, in the top board device tree file (or in lower level depending on cases), the memory node must be aligned with the the DDR size. In our example, arch/arm/dts/stm32mp215f-dk.dts must contain:
memory@80000000 { device_type = "memory"; reg = <0x0 0x80000000 0x0 0x40000000>; };
The resmem board device tree also needs to be aligned with what has been done on OP-TEE side. Note that "linuxkernel" regions are never listed here. In our example, arch/arm/dts/stm32mp215f-dk-ca35tdcid-resmem.dtsi must be modified as this:
ltdc_sec_layer: ltdc-sec-layer@bf800000 { reg = <0x0 0xbf800000 0x0 0x800000>; no-map; };
5.5. Linux kernel[edit | edit source]
This is the same level of modifications as on U-Boot as device trees are aligned.
In our example, arch/arm64/boot/dts/st/stm32mp215f-dk.dts must contain:
memory@80000000 { device_type = "memory"; reg = <0x0 0x80000000 0x0 0x40000000>; };
And arch/arm64/boot/dts/st/stm32mp215f-dk-ca35tdcid-resmem.dtsi must contain:
ltdc_sec_layer: ltdc-sec-layer@bf800000 { reg = <0x0 0xbf800000 0x0 0x800000>; no-map; };
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 