When updating from arm-trusted-firmware-v2.4-stm32mp-r1 to arm-trusted-firmware-v2.4-stm32mp-r2 I get PANIC on UART

[cfilipescu]

I didn't change anything in the device tree just compiled the arm-trusted-firmware-v2.4-stm32mp-r2 instead of arm-trusted-firmware-v2.4-stm32mp-r1 and I get the following on UART:

PANIC at PC : 0x2ffcfd2b

What is different between the two versions?

[Olivier GALLIEN]

Hi @cfilipescu​ ,

I understand you are migrating from ecosystem V3.0 to V3.1.

Did you also update FIP (ssbl) accordingly ?

Could you please share the complete boot traces ?

Are you on ST board or custom board?

thanks

Olivier

[cfilipescu]

Hi @Community member​.

I am trying to update to V3.1, and yes it is a custom board, however, it is very similar to stm32mp157c-dk2.

I did not do anything to the FIP (ssbl). I am using buildroot (with the STM repos) to build the sdimage, so I might need to figure out how to do so.

There is nothing else to share "PANIC at PC : 0x2ffcfd2b" is the only thing coming through the UART.

Regards,

[Olivier GALLIEN]

Hi @cfilipescu​ ,

How did you manage the dts ?

Did you simply reuse the same or did you generate new one from CubeMX ?

Panic a early stage may come from problem in Clock configuration. eg HSE.

Can you double check ?

Else I'm not buildroot expert and I cannot help much how to generate BSP using this env.

But for a kind of bring-up Developer package can be simpler to use.

Olivier

[cfilipescu]

Hi Oliver,
I manage the dts using cubemx/cubeIDE and I did regenerate the dts. I will have to double check. Last time I had this issue I had to create a new project and diff the dts files for any difference.
Regards,

[Olivier GALLIEN]

Hi @cfilipescu​ ,

Yes, keep in mind that CubeMX generate up and running dts only for board project ( EV1, DK2)

For custom board project you have to carefuly fill the user section taking reference from ST board and adapting to you specific hardware.

Hope it help

Olivier

[cfilipescu]

I compared the dts vs stm32mp157d-dk1 autogenerate files in cubeMX and updated a few things and now I get the following:

NOTICE: CPU: STM32MP153AAC Rev.B

NOTICE: Model: STMicroelectronics custom STM32CubeMX board - openstlinux-5.10-dunfell-mp1-21-11-17

ERROR:  CMD13 failed after 5 retries

ERROR:  SDMMC1 init failed

PANIC at PC : 0x2ffc9afd

The updated dts files still work with arm-trusted-firmware-v2.4-stm32mp-r1 as a sanity check

[cfilipescu]

some more background information, I am building the arm-trusted-firmware with STM32MP_USE_STM32IMAGE=1 as a compile flag. Could this be the problem?

[Olivier GALLIEN]

Hi @cfilipescu​ ,

Don't know if it's the problem but good information.

You are working with the so call "legacy" BSP partitioning without FIP which is the default from DV3.0.

In both case did you properly follow the guideline here :

How to cross-compile with the Developer Package - stm32mpu

( pay attention to click on [expand] section )

Thanks

Olivier

[cfilipescu]

You are correct I am using the "legacy" BSP partitioning without FIP.

I must be compiling it correctly if it works in DV3.0, and I don't see any changes when it comes to DV3.1.

[AlexandrShipovsky]

Hi @cfilipescu​ ,

I had a similar problem. It turned out that tfa did not configure the power chip that is on the board. On my STM32MP157A-DK1, it connected to I2C 4. When I edited my device tree, everything worked. (I just copied part of the code that ST supplies)

[cfilipescu]

@AlexandrShipovsky​ I encountered that problem before but the device tree has the correct user data.

[Olivier GALLIEN]

Hi @cfilipescu​ ,

Trace you are providing still make me think about a Device Tree problem around clock or power.

Even with a miss configuration wrt STM32MP_USE_STM32IMAGE=1 you should not have crash until trial to launch the next step ( ssbl or fip )

Could you please share your Device Tree file ?

Thanks

Olivier

[Olivier GALLIEN]

Else, are you using git or package from st.com for sources ?

[Bernard PUEL]

hello @cfilipescu​ ,

I am trying to catch up all the information given above. Sorry if i missed some.

From the last trace we can see the sdcard enumeration (in sdcard init procedure) is starting well and no answer is given to the last step CMD13 command after 5 retries.

Could you please confirm on your last trials ?:

• You flashed the starter kit for ST board (the ones from st.Com) and boot your board on your sdcard (meaning embedded SW and dts are aligned with ST delivery)
• v3.0 starter is ok but v3.1 starter fails

Could you please share the schematics of your board ?

The only diff we see related to sdmmc from v3.0 to V3.1 is the following:

Here are our DT changes:

git diff v2.4-stm32mp-r1..v2.4-stm32mp-r2 fdts/stm32mp15xx-dkx.dtsi

diff --git a/fdts/stm32mp15xx-dkx.dtsi b/fdts/stm32mp15xx-dkx.dtsi

index e5166706ee..fa1a4baaca 100644

--- a/fdts/stm32mp15xx-dkx.dtsi

+++ b/fdts/stm32mp15xx-dkx.dtsi

@@ -134,14 +134,15 @@

vtt_ddr: ldo3 {

regulator-name = "vtt_ddr";

- regulator-min-microvolt = <500000>;

- regulator-max-microvolt = <750000>;

regulator-always-on;

regulator-over-current-protection;

+ st,regulator-sink-source;

};

vdd_usb: ldo4 {

regulator-name = "vdd_usb";

+ regulator-min-microvolt = <3300000>;

+ regulator-max-microvolt = <3300000>;

};

vdda: ldo5 {

@@ -161,7 +162,6 @@

vref_ddr: vref_ddr {

regulator-name = "vref_ddr";

regulator-always-on;

- regulator-over-current-protection;

};

Did you report these changes in your board build ?

[cfilipescu]

Hi @Bernard PUEL​  

Your summation of the last trials is correct. I flashed the starter kit for the ST DK1 board and the embedded SW and dts are a carbon copy of the stm32mp157a-dk1 board. And to confirm v3.0 starter passes while v3.1 starter failed.

Those changes are in my board build.

I will PM you the board schematic.

[Bernard PUEL]

I have just checked our internal tests before delivery and the MP153A version is systematically tested thanks to a EV board with socket.

[Bernard PUEL]

Thanks for your schematics sharing. I could check with HW experts with the following outcomes:

I/ Overview:

cross checked schematics:

- SDMMC1 / SD-Card not found issues

- STPMIC1 inductors and capacitors models and size to be cross-checked with STPMIC1 datasheet recommendations. Maybe the supplies such as VDDCORE, VDD or the 3V3 (SD-Card supply) exhibit too much noise/ripple which could explain strange behavior (cannot explain why v3.0 if better than v3.1)

other:

- I2C4 pull-up 4.7k Vs 1.5K on DK1/DK2. likely not the root cause of this ticket

- 232 ohms pull-ups on SPI1-SPI6 are quite small. Might be an issue if too much current on STM32MP1 supply VDD rails. Not the root cause of this ticket

I recommended to get a plot of SD-Card signals and supply (3V3, SDMMC1_CLK, SDMMC1_CMD, SDMMC1_D0 to D3) and check what the difference between v3.0 and v3.1, especially confirm when/how the card stop answering.

II/ PMIC specific:

Regarding STPMIC1, value of inductors and capacitors are OK. BUT size of input capacitors of SMPS are 0805 (recommended 0603); ouptut SMPS capacitors are 1206 (recommended 0603) and inductors are 5x5mm (recommended 2.5x2.0mm).

Consequently, those discrete components are placed far from STPMIC1 making CIN/COUT and PMIC long GND track. This increases parasitics inductance (increasing ringing). Impacts:

+ Buck ouptut may oscillate in certain conditions (= Vout ripple increase)

+ high input or ouptut ringing may be destructive for PMIC in short/medium term.

Outcomes:

It is recommended to check PCB layout; especially CIN/COUT and PMIC GND track for buck1, 2, 3, 4.

It is recommended to use smaller discrete components, especially Cout and inductors.