FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

FAQ: STM32MP1 How to bring up STM32MP1

Emmanuel COMBETTE DE RYMON
ST Employee

on ‎2020-05-29 10:43 AM - edited on ‎2023-06-27 11:40 PM by Community manager

The new design board is received and you wonders how to get started.
Design is composed of  STMP32MP1x, DDR RAM , STPMIC1 for power supply, a boot flash device.
How to configure the boot loaders to your application ?
What to check if the boot chains fails to start or return errors ?
What tool to download the software in Flash?
 

  • Procedure

Describes what has to be configured to load for the first time :

  • the TF-A FSBL in SYSRAM
  • the Uboot SSBL in DRAM.

TF-A and Uboot firmwares can be loaded from serial link boot device (USB or UART) or from a boot flash device like Sdcard, eMMC, SLC NAND, Serial NAND, Serial NOR.
Additional resources:

 

  • ​​How to validate STM32MP1-DRAM connection on PCB
  • We recommend strongly to read the Troubleshooting for classical issues 

FAQ https://community.st.com/s/article/FAQ-STM32MP1-bring-up-troubleshooting-guide
or
https://wiki.st.com/stm32mpu/wiki/Bring-up_troubleshooting_grid

 

  • Lab for TF-A& Uboot device tree creation for STM32MP1 part number adapted to your design with STM32CubeMx
 
  • STM32MPU forum and other FAQs

1 Adapt the TF-A configuration to your PCB application

Configuration is done in the device tree files of TF-A. 
Two possibilities :
  •  if your PCB is exactly the same as ST reference boards for the HSE/UART/IC24 for PMIC/DRAM/SDMMC sub-systems you can reuse the TF-A binary provide in the starter package.
  • if your PCB is different from ST reference board -other STM32MP15x, DRAM, Flash, GPIOs-, the method is to create TF-A , OP-TEE, U-boot and Kernel device tree files from empty files and add the ‘nodes’ of the ST32MP1 peripherals used by your application.
For the peripherals driver used in by TF-A there is a relative ‘node’ in the device tree file that provides the driver configuration. The link below for each peripheral points on the device tree node parameters. https://wiki.st.com/stm32mpu/wiki/Category:Device_tree_configuration. These articles provide links to the driver ‘binding files’ (st,txt files) that gives the meaning of the node parameters.  These parameters are in majority the same across TF-A, Uboot and Kernel.

 

To elaborate the device tree file, you start a STM32CubeMX project from STM32CubeMx MCU selector. STM32CubeMX generates partially the device tree.
The device tree files generated by STM32CubeMX are incomplete, it cannot be used as it.
 
The device tree will contain the GPIO pin muxing (STM32CubeMx is doing checks to prevent issues where GPIO would have multiple definitions), the RCC settings, the DRAM configuration and HW execution context for peripheral isolation.  The driver nodes properties are not generated by the tool.
All these nodes must be manually inserted under user sections . You must set the right parameters that are adapted to the components on your PCB (USB, Flash, DRAM, Power supplies tree, etc). You need to carefully check also default parameters generated by STM32CubeMx accordingly to your design (default parameters might not be adapted in some cases). To find the right properties you have the wiki device tree articles and the ST reference boards device tree files in OpenSTlinux source files.
Be careful, the default parameters presented in the wiki page may not be adapted to your design.
For additional guidance, there is a lab Lab-BringUpFromPartNumber to get used with this device tree creation process
The purpose of this lab to create minimal device tree for TF-A and also for U-Boot that boots correctly.
Starting a 'bring up' device tree from STM32CubeMx MCU selector with the DK2 STM32MP157 part number (DK13 STM32MP135F) (project almost empty) it shows which nodes from a DK2 (DK13) STM32CubeMX project device tree to add in the ‘bring up’ device tree.
The slide set shows how to configure the clock tree (RCC), the STMPIC, the DDR controller, the UART for the console, USB for DFU. Further info in 
https://community.st.com/s/article/FAQ-STM32MP1-How-to-create-a-device-tree-adapted-to-your-design-with-STM32CubeMx
This lab can be used as getting started to create your device tree files suitable for your STM32MP1 part number and your design. The nodes given as examples in the lab remains to be adapted to your design. 

2 Load & launch TF-A (without DDR initialization)

Start TF-A with STM32CubeProgrammer in UART or USB OTG
Configure the Boot pins to make the ROM code boot from serial boot device. The ROM code loads TF-A in internal SYSRAM from STM32MP1 USB-OTG (only 2 dedicated pins for USB-OTG are needed by ROM Code) or from UART (choose a UART different from UART4 which is TF-A trace console, available UART and related pins in https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#UART_Boot ).
 
Use a STM32CubeProgrammer .tsv file from the STM32MP1 Starter package with binaries of TF-A (Id=0x1)
For example in FlashLayout_SD-Card_stm32mp157c-dk2-trusted.tsv file, keep the first line (Id 0x1) remove the others or tick on this line if STM32CubeProgrammer GUI is used .
STM32CubeProgrammer and ROM Code will load TF-A in internal SYSRAM and start it execution.
You should see the TF-A traces on the UART4 for traces enabled by default of TF-A.
More info about how to use STM32CubeProgrammer
https://wiki.st.com/stm32mpu/wiki/STM32MP15_Discovery_kits_-_Starter_Package#Downloading_the_image_and_flashing_it_on_the_board
Since Uboot SSBL is not loaded by STM32CubeProgrammer you should see the TF-A error complaining the SSBL is not not found. 
Once you will have been able to load and execute successful TF-A you should see also
"Warning: DDR not configured".
 

3 Configuration of the DDR by T-FA

At this point, TF-A has not yet configured the DDR controller to get the DRAM functional.
 
1/DRAM parameters in Device Tree
 
DDR timings are loaded in DDR controller registers by TF-A FSBL and the register values are located in the FSBL device tree files ( *.dtsi) files of TF-A binary .
 
To build these files, there are 2 possibilities:
 
-your PCB contains a DDR3L@533Mhz you can re-use directly the ST reference boards (select the stm32mp15-ddr3-2x4Gb-1066-binG.dtsi or stm32mp15-ddr3-1x4Gb-1066-binG.dtsi according to your configuration). The timings can be applied for any DDR3L with the DDR Speed/bin Grade 1066-G .
 
-your PCB uses another DRAM (LPDDR2 for example), STM32CubeMX will help you to compute the DRAM timing configuration and will generate the TF-A device tree file relative to STM32MP1 DDR controller settings.
To get TF-A binary with DRAM timings save DRAM parameters to generate the dtsi DRAM file with the new parameters. Copy the files from CubeMx project in TF-A fdts folder, recompile TF-A.
 More info in : https://wiki.st.com/stm32mpu/wiki/DDRCTRL_and_DDRPHYC_device_tree_configuration
 
2/Recompile TF-A with DDR dtsi files 
Reload the TF-A with STM32CubeProgrammer and the ROMcode
and should see the TF-A trace (dk2 example on ecosystem V1.0.0) :   
"INFO:    RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.41                           
INFO:    Memory size = 0x20000000 (512 MB)  ……
SP_MIN: Preparing exit to normal world  "
 then you should be able to load&launch Uboot in DDR
More info to compile in Developper Package the TF-A (and Uboot) device tree https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Developer_Package#Updating_BOOT_firmwares
3/DDR test
Two possibilities:
  • DRAM works, no strange behavior with Uboot at this stage, skip the Cube MX DDR tool suite step.
Normally it is expected that the designers would have first followed carefully the rules of AN5122. These design rule are the very impacting the signal timings and are important. 
If your layout regarding DRAM-STM32MP1 chipset is picked-up from ST layout examples or from ST boards, Signal integrity tests have been passed on the DRAM-STM32MP1 connecxion.
 
  • DRAM does not work fine
0 if FSBL device tree has been adapted to the PCB, check binary is correctly updated on target
1 Check the pin muxing of the DRAM signals against PCB schematics
2 Measure the voltages VDD-DDR, VREF_DDR, VDD-VTT (if present) on the PCB. Double check the voltage values in device tree STPMIC node of Uboot-SPL
3 Check DRAM timings (for DDR3 Speed bin / grade) against data sheet of DRAM
4 Run the all the DDR tests with STM32CubeMX DDR tool.
 
How to run DRAM tests with the STM32CubeMX DDR suite ?
The DRAM test suite is Uboot-SPL FSBL in Uboot source files. Uboot-SPL binary is compiled in the developer package. Uboot-SPL for eval board or DK boards can be used directly if the PCB is similar (DDR3L, STPMIC, UART4, HSE digital by pass, USB-OTG)
If the PCB is different from ST board adjust to PCB the device tree files of Uboot-SPL.
HSE, Uart trace, I2Cx STPMIC pin : should have the same as TF-A nodes for these peripherals. Recompile Uboot-SPL in Uboot folder (device tree files are shared between Uboot and Uboot-SPL).
Behind STM32CubeMX DDR suite, STM32CubeProgrammer and ROM Code in DFU mode the loads & launches in SYSRAM the Uboot-SPL firmware. The STM32CubeMX DDR suite on PC controls DRAM tests executed by Uboot-SPL on target over UART4.
Boot pin are set on serial boot device. In STM32CubeMX DDR tool suite "Connect" via UART4 (or VCP with ST-link) to STM32MP1. In the tool GUI, read the info bubbles to get the precise instructions.
 
If DRAM tests are failing or application has strange behaviors
-double check DRAM connections in the schematics or in the layout 
-is there supply noise on VDDQ_DDR, DDR_VREF pin ?
-does the DDR signal tracks length comply with the AN5122 constraints ?
-24MHz Oscillator on HSE pin must be used if design includes LTCD // outputs, see errata sheet.
-There is additional DDR controller settings in CubeMX DDR parameters are described in AN5168, Impedance on DQ/DQS byte line can be modified as per AN5168 § 5 or relax timings AN5168 §6.
 

4 Check Uboot configuration

Start from a dts file where all the peripheral nodes are disabled.
Adapt form STM32CubeMx <project name >-u-boot.dtsi and dts files according to your board with the same TF-A method as above (illustration of the explained above in lab Lab-BringUpFromPartNumber).
Uboot needs USB OTG node for Uboot flashloading with STM32 CubeProgrammer. 
Especially OTG_VBUS and OTG_ID pin need different uboot device tree configuration whether the pin are connected to USB connector or not.
See https://wiki.st.com/stm32mpu/wiki/How_to_configure_U-Boot_for_your_board#USB_OTG_node
Note that the .dts file of Uboot is the same as the .dts file of the kernel. The <project name>_uboot.dtsi is an overlay if the .dts file of Uboot which overloads the values is the nodes. 
 

 5 Load Uboot in DRAM 

Similar methods than with TF-A boot: from serial link with STM32Cubeprogrammer 
In .tsv , keep the 2 first lines with binaries of TF-A (Id=0x1) and Uboot (id=0x3).
       

 6 Kernel bring-up 


Same T-FA method above, start from a dts file where all the peripheral nodes are disabled.
For each of them you have the device tree a first description in the wiki to add the adapted properties according to your PCB in the peripheral nodes. 
Entry for the device tree description : https://wiki.st.com/stm32mpu/wiki/Category:Device_tree_configuration
Also rely on the ST reference boards device tree files and relative schematics as example.
Note that when your flash boot device is not available or tested, It is also possible to boot the kernel with initramfs. In this case STM32CubeProgrammer load in DRAM the root filesystem (rootfs).
 

7 Check your device trees with hardware design
Check your device trees compared to your hardware design

AN2606 chapter 4.3 Hardware connection requirements Available here: https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

8 Boot from a flash device 


At this point TF-A and Uboot are configured to your PCB and can be loaded from serial boot device with ST32MPCubeProgrammer. 
Now these partitions containing TF-A, Uboot can be flashed then loaded to boot the kernel. 
Prior to boot the kernel from flash, partitions has to be written TF-A raw patition, FIP partition (Uboot and SecureMonitor),bootfs (Kernel), rootfs (Kernel modules and Uerland libraries), userfs, ...
See https://wiki.st.com/stm32mpu/wiki/STM32MP15_Flash_mapping
STM32CubeProgrammer and Uboot flashing service allow to write the partitions into the flash device.
you have to create the corresponding .tsv input file according to your flash device partition
.stv file from Starter Package can be a starting point.
Further information in https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#Typical_FlashLayout_file_without_FIP.
When boot device is a SLC NAND some Uboot configuration is needed to get a correct memory flashing.
https://wiki.st.com/stm32mpu/wiki/FMC_device_tree_configuration#DT_configuration_of_the_NAND_Flash_controller_-28board_level-29
if you have difficulties to boot from flash, see troubleshooting items to go further in details.
 

Back ground knowledge

 

When you power ON the STPMIC, it enters in internal POWER_UP state BUCK for VDDCORE and VDD are settled, NRST goes to 0. When POWER_UP sequence is over to internal POWER-ON state and releases its NRST pin but NRST signal is maintained to 0 by MP1 NRST pin. When the MP1 Power-On Reset (POR) has detected the right level of VDD and VDDCORE and some delay elapsed the MP1 releases NRST, then ROM code is started. (NSRT PAD is open drain with internal pull-up). MP1 PWR_ON pin goes to 1 once VDD is > POR/BOR threshold .
Further information in RefMan 0436rv4:
 9.3.2 PWR supply system startup sequence
10.3.14 Power-on and wakeup sequences

Keywords : STM32MP1 , bring up
Comments
Gencay
Associate III
‎2022-08-17 06:35 AM

is it possible to use this methods on dk2 board?

0 Kudos
debugging
Lead
‎2023-08-30 09:09 PM

Almost none of the links in this document still work.

 

0 Kudos
Version history
Last update:
‎2023-06-27 11:40 PM
Updated by:
Community manager
Top