TF-A failing at fsbl1 to BL2 transition. What could be causing it?

[RBaro.1]

Hello, 

I am currently working on bringing up a production board design with the OSD32MP157C-512M-BAA. The board design is very similar to the octavo systems osd32mp1-red board

Sdcard is located on SDMMC1 with the same pinout.

EMMC is located on SDMMC2 with the same pinout.

The board can boot all the way into Linux if I use the provided development kit sd card image from octavo. This indicates to me that the core of the PCB is functioning correctly.

A requirement of our project is to use buildroot. For testing, I am using the following setup: github. com / bootlin/buildroot-external-st

This (with the st_stm32mp157c_dk2_defconfig) builds a STM32mp1-DK2 development board compatible image with the following repository versions:

TF-A: v2.4-stm32mp-r1

U-Boot: v2020.10-stm32mp-r1.1

Linux: v5.10-stm32mp-r1

This buildroot image works on the DK2 development board without issue. However, I cannot get it to work on the OSD32MP157C SIP even with device tree updates based on the provided Octavo mx cube base configuration and provided device trees.

See the attached image of the console output, where the board continually boots, makes it to "INFO: Boot used partition fsbl1", then resets itself. 

I am trying to understand what is occurring during this period. I know that it is failing in the TF-A, specifically during the following sections of code:

In the arm-trusted-firmware-v2.4-stm32mp-r2>plat>st>stm32mp1>bl2_plat_setup.c at the end of the function call void bl2_el3_plat_arch_setup() the stm32mp_io_setup(); is called where it fails.

Any insights in regards to what this failure point is related to? Could it be ddr config? or SD card image partitioning with the FIP? In a correctly running system, the next terminal text to come up would be something like: NOTICE: BL2: v2.4-r2.0(release): openstlinux-5.10-buildroot-2021.02-mp1-21-11-17. Indicating that it's not making it to BL2.

Any direction from here would be greatly appreciated, I've spent days trying to get the board up and running. Thank you!

[Olivier GALLIEN]

Hi @RBaro.1​ ,

We are surprised to not see the trace STPMIC version .. which could come right after the reset reason.

Coud you please attach complete log in case of success with provided development kit sd card image from octavo ?

Did you perform a complete comparison of both TF-A DTS ?

You can also attach them for reference.

Thanks

Olivier

[RBaro.1]

Hi Olivier,

Thank you for the prompt response. I have found the solution! It was exactly the same issue as this post: https://community.st.com/s/question/0D53W00001GNrpOSAT/when-updating-from-armtrustedfirmwarev24stm32mpr1-to-armtrustedfirmwarev24stm32mpr2-i-get-panic-on-uart

It seems that the SD card read was getting corrupted by its supply being turned off/on. This solved the problem:

in tf-a dts (only in tf-a), remove this line: vmmc-supply = <&v3v3>;

 

It will remove the switch off/on of buck4 during sdmmc init.

In regards to the PMIC Version output, i also thought this was strange that it did not show up. I discovered that it only shows up if the TF-A is built with DEBUG=1 and not in release.

Thank you for your assistance!

[Olivier GALLIEN]

Hi @RBaro.1​ ,

Indeed ! Well spotted !

Thanks for feedback

Olivier