what do I need to adapt for the stm32mp157f-ev1 device tree to work for the stm32mp151 SoC?

[M.Assuncao]

Since stm32mp157 node descriptions are inherited from stm32mp153 and stm32mp151.

[Erwan SZYMANSKI]

Hello @Matheus Assunção​ ,

As you well said, stm32mp157 SoC device tree inherit from stm32mp153, then on stm32mp151.

Why ? Because the very base SoC is the stm32mp151. Other ones are just adding features based on this first SoC.

So for you, how to process ?

Your board level device tree will just target directly the SoC you have. If your custom board have a stm32mp151 SoC, you will include directly stm32mp151.dtsi, because you will not need properties of the 2 upper level SoC device tree.

I hope this information will help you to go forward.

Kind regards,

Erwan.

[M.Assuncao]

Hello @Erwan SZYMANSKI​ , thanks for your response!

My custom board can use SoC stm32mp157 or stm32mp151, to create the custom device tree I used stm32mp157f-ev1 as a base. My custom board using the SoC stm32mp157 worked correctly, however using the stm32mp151, it did not work. Note: When using device tree for stm32mp151, removed CAN, DSI, GPU, CPU1 related nodes. The same was done in the TFA code.

Below is a demonstration of initializing stm32mp157 and then stm32mp151.

NOTICE: CPU: STM32MP157FAC Rev.Z

NOTICE: Model: STMicroelectronics STM32MP157F-DK2 Discovery Board

INFO: PMIC version = 0x21

INFO: Reset reason (0x15):

INFO: Power-on Reset (rst_por)

INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe2000

INFO: FCONF: Reading firmware configuration information for: stm32mp_io

INFO: Using SDMMC

INFO: Instance 1

INFO: Boot used partition fsbl1

NOTICE: BL2: v2.6-stm32mp1-r1.0(debug):v2.6-dirty

NOTICE: BL2: Built : 13:14:26, Nov 23 2021

INFO: BL2: Doing platform setup

INFO: RAM: DDR3-DDR3L 16bits 533000kHz

INFO: Memory size = 0x20000000 (512 MB)

INFO: BL2: Loading image id 31

INFO: Loading image id=31 at address 0x2ffff000

INFO: Image id=31 loaded: 0x2ffff000 - 0x2ffff226

INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x2ffff000

INFO: FCONF: Reading firmware configuration information for: dyn_cfg

INFO: FCONF: Reading firmware configuration information for: stm32mp1_firewall

INFO: BL2: Loading image id 4

INFO: Loading image id=4 at address 0x2ffc5000

INFO: Image id=4 loaded: 0x2ffc5000 - 0x2ffd9820

INFO: BL2: Skip loading image id 21

INFO: BL2: Skip loading image id 22

INFO: BL2: Loading image id 23

INFO: Loading image id=23 at address 0xc0500000

INFO: Image id=23 loaded: 0xc0500000 - 0xc051c668

INFO: BL2: Loading image id 26

INFO: Loading image id=26 at address 0x2ffc0000

INFO: Image id=26 loaded: 0x2ffc0000 - 0x2ffc4612

INFO: BL2: Loading image id 5

INFO: Loading image id=5 at address 0xc0100000

INFO: Image id=5 loaded: 0xc0100000 - 0xc01e8888

NOTICE: BL2: Booting BL32

INFO: Entry point address = 0x2ffc5000

INFO: SPSR = 0x1d3

NOTICE: SP_MIN: v2.6-stm32mp1-r1.0(debug):v2.6-dirty

NOTICE: SP_MIN: Built : 13:14:26, Nov 23 2021

INFO: ARM GICv2 driver initialized

INFO: Set calibration timer to 60 sec

INFO: stm32mp1 IWDG1 is secure

INFO: SP_MIN: Initializing runtime services

INFO: SP_MIN: Preparing exit to normal world

U-Boot 2021.10-stm32mp-r2-00014-g3becdd498f (Mar 01 2023 - 17:29:27 -0400)

----------------------------------------------------------------------------------------------------------

NOTICE: CPU: STM32MP151CAC Rev.Z

NOTICE: Model: STMicroelectronics STM32MP157F-DK2 Discovery Board

INFO: PMIC version = 0x21

INFO: Reset reason (0x15):

INFO: Power-on Reset (rst_por)

INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe2000

INFO: FCONF: Reading firmware configuration information for: stm32mp_io

INFO: Using SDMMC

INFO: Instance 1

INFO: Boot used partition fsbl1

NOTICE: BL2: v2.6-stm32mp1-r1.0(debug):v2.6-dirty

NOTICE: BL2: Built : 13:14:26, Nov 23 2021

INFO: BL2: Doing platform setup

INFO: RAM: DDR3-DDR3L 16bits 533000kHz

INFO: Memory size = 0x20000000 (512 MB)

INFO: BL2: Loading image id 31

INFO: Loading image id=31 at address 0x2ffff000

INFO: Image id=31 loaded: 0x2ffff000 - 0x2ffff226

INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x2ffff000

INFO: FCONF: Reading firmware configuration information for: dyn_cfg

INFO: FCONF: Reading firmware configuration information for: stm32mp1_firewall

INFO: BL2: Loading image id 4

INFO: Loading image id=4 at address 0x2ffc5000

INFO: Image id=4 loaded: 0x2ffc5000 - 0x2ffd9820

INFO: BL2: Skip loading image id 21

INFO: BL2: Skip loading image id 22

INFO: BL2: Loading image id 23

INFO: Loading image id=23 at address 0xc0500000

INFO: Image id=23 loaded: 0xc0500000 - 0xc051c668

INFO: BL2: Loading image id 26

INFO: Loading image id=26 at address 0x2ffc0000

INFO: Image id=26 loaded: 0x2ffc0000 - 0x2ffc4612

INFO: BL2: Loading image id 5

INFO: Loading image id=5 at address 0xc0100000

INFO: Image id=5 loaded: 0xc0100000 - 0xc01e8888

NOTICE: BL2: Booting BL32

INFO: Entry point address = 0x2ffc5000

INFO: SPSR = 0x1d3

PANIC at PC : 0x2ffc9929

Exception mode=0x00000016 at: 0x2ffc9929

[PatrickF]

Hi @Matheus Assunção​ 

Is your 2nd board DDR ok ?

Maybe try to use MP151 image on a working MP157 board (not tested on my side, I guess it should work).

Maybe something in your DT somewhere regarding the presence of 2nd Cortex-A7 core (single core on MP151).

Regards.

[M.Assuncao]

Hi @PatrickF​ , thanks for your response!

Yes, the device tree for the single core SoC (MP151) worked for the dual core SoC (MP157). It is also possible to verify that the cpu core 1 is disabled through the "/sys/devices/system/cpu/" directory. In the device tree I disabled all the features added in the MP153 and MP157 but it still didn't work for MP151.

[Erwan SZYMANSKI]

Hello @Matheus Assunção​ ,

Do you think you can share the device tree used for TF-A compilation in attachment ?

Just to well understand the context, you made a custom board with a stm32mp151 SoC, and you are also trying your custom device tree with a stm32mp157f-ev1 (in a test context) that is a native ST board right ?

Kind regards,

Erwan.

[PatrickF]

Maybe you have an HW issue on your board with MP151 (bad solder join somewhere which make DDR not working). Maybe look at DDRFW-UTIL to confirm.

Regards.

[M.Assuncao]

Hello @Erwan SZYMANSKI​ , thanks for your response!

My team developed two custom boards, the first with the stm32mp157 SoC and the other with the stm32mp151. While the board with the stm32mp157 SoC was being manufactured, its device tree, kernel and bootloaders were tested in the stm32mp157f-ev1 kit. After manufacturing the custom boards, the kernel, device tree and bootloaders were tested on the board with SoC stm32mp157 and it worked perfectly. To perform the test on the board with SoC stm32mp151, the changes mentioned above were made, but it did not work. Apparently hangs on TF-A.

One more piece of information, the same company that manufactured the two board models and the same company assembled the components.

[M.Assuncao]

I was researching problems similar to mine and I found this "https://community.st.com/s/question/0D53W000009340DSAQ/how-to-configuration-for-stm32mp151" where it was recommended to look at the following link "https:// community.st.com/s/article/FAQ-STM32MP1-how-to-adapt-DT-to-MP151-and-MP153", but that link is currently down. Is there any similar tutorial?

[PatrickD]

Normally in your device tree tree, for your board, you need to include the correct SoC dtsi for the used variant?

For example:

/dts-v1/;

- #include "stm32mp157.dtsi"
- #include "stm32mp15xd.dtsi"
+ #include "stm32mp151.dtsi"
+ #include "stm32mp15xa.dtsi"

and change compatible, for example.
+ compatible = "st,stm32mp157d-ed1", "st,stm32mp157";
- compatible = "st,stm32mp151a-ed1", "st,stm32mp151";

Running the OpenSTLinux with STM32MP157F device tree on STM32MP151A SoC is not recommanded,
because some feature in SW component are based on device tree (in particular in U-Boot, OP-TEE and Linux kernel).

In your trace you crash in TF-A SPM_MIN

NOTICE: BL2: Booting BL32

I konw that in the  secure monitor TF-A SP_MIN the support of hold boot for the core1  information
is based on PAR NUMBER on not on device tree in TFA v2.6-stm32mp1-r1.0
see stm32mp_is_single_core(), called in plat/st/stm32mp1/stm32mp1_pm.c

but some other part of SP_MIN can be activated by device tree
(see dt_open_and_check(dt_addr) call in sp_min_early_platform_setup() )

I think about security or OPP features (max frequency supported on the SoC)  for A,C,D, F variant :
./fdts/stm32mp15xa.dtsi
./fdts/stm32mp15xc.dtsi
./fdts/stm32mp15xd.dtsi
./fdts/stm32mp15xf.dtsi

it is difficult to be sure with more debug  => at least search in TF-A map file where you have the panic with address, 
PANIC at PC : 0x2ffc9929

You can activate trace in TF-A BL32 = SP_MIN
in particular in plat/st/stm32mp1/sp_min/sp_min_setup.c
but you can use also GDB to found the call stack 

https://wiki.st.com/stm32mpu/wiki/How_to_debug_TF-A_SP-MIN

Regards
Patrick