cancel
Showing results for 
Search instead for 
Did you mean: 

Boot failure at BL2 or OP-TEE. Maybe wrong DDR Tuning or not?

Adam_Carpenter
Associate II

Hi,

We are building Linux for STM32MP157D using Buildroot, and we are experiencing an issue where the boot process sometimes does not proceed from BL2 to OP-TEE, and sometimes OP-TEE does not proceed to U-Boot.
Occasionally, the kernel does boot successfully.

Could this be caused by incorrect DDR3 controller settings? We are using a custom board.

If so, would compiling the STM32DDRFW-UTIL source code and using it in engineering mode be the right solution?
I have read that for some chips it is possible to perform automatic tuning and receive the optimal configuration as a result.
Is this possible in this case? If not, what is the proper method to determine the correct DDR controller settings?

If DDR is not the issue, do you have any other suggestions?

For testing with DDR-UTIL, I see that there is no development board listed for the 157D series, as the utility supports "STM32MP157C-EV1_DDR_UTILITIES_A7".
If we order the "STM32MP157D-EV1", will I be able to run DDR tests on it to compare with our custom board, or do we need to order the "STM32MP157C-EV1" because only that one is compatible with DDR-UTIL?

I am attaching 3 log files. One for the BL2 stop, one for the OP-TEE stop, and one for a successful kernel boot.

Thanks in advance,
Adam

https://wiki.st.com/stm32mpu/wiki/STM32DDRFW-UTIL

10 REPLIES 10

Hi @Adam_Carpenter 
Nice to see you identified the issue but as well the rationale behind the weird behavior.

You deserve kudos as I think it was giving you some headache.

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Tip of the day: Try Sidekick STM32 AI agent, see here