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?

[Bernard PUEL]

My assumption is that buck4 regulator (v3v3) is switch ON just before the enumeration of the sdmmc1 and link to the pmic design of your board, It would fail due to oscillations.

Getting a plot of SD-Card signals and supply (as suggested by my HW expert colleague) would help to check this.

My assumption to explain the diff of behavior between v3.0 and v3.1 is a timing difference between the buck4 switch ON and the enumeration. I am checking this with SW Experts.

I guess you have not planned to redesign a new HW so I will try to check what is better for you on short term (as soon as we can confirm or not our assumptions).

[Bernard PUEL]

If assumption is confirmed: A simple delay (few ms) between buck4 enable and sdcard enumeration may solve the issue.

[cfilipescu]

Hi @Bernard PUEL​,

Thank you for the feedback, unfortunately, it will be a while before I can't get to a scope to look at the signals. However, I could try adding the delay. Would you have some sample code where in the arm-trusted-firmware source code I should add the delay?

Thank you

[Bernard PUEL]

You can do this simple test:

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.

Please let me know if it can solve the issue on your board. Dev team is thinking about a better correction .....

[cfilipescu]

NOTICE: Model: STMicroelectronics custom STM32CubeMX board - openstlinux-5.10-dunfell-mp1-21-11-17
NOTICE: BL2: v2.4-r2.0(release):2021.11
NOTICE: BL2: Built : 14:21:43, Jan 25 2022
NOTICE: BL2: Booting BL32
NOTICE: SP_MIN: v2.4-r2.0(release):2021.11
NOTICE: SP_MIN: Built : 14:21:43, Jan 25 2022

Awesome that worked and it booted.

Thank you for all the help.

[Bernard PUEL]

ok great. That way you will get the same behavior as for v3.0.

But the subject is not finished on ST side and I will propose probably a better correction in the coming days.

[Bernard PUEL]

After internal discussions, we will deploy a correction that will have the same effect as the previous solution. So you can go on with it on your side.

In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before.

[cfilipescu]

Awesome. Thank you again.

[Bernard PUEL]

Hi, here is the fix that will be integrated in next ST releases.

[GHers.1]

hello Bernard,

I am sending this message long after this thread was closed.

I hope you can reply to it.

We encountered this issue just recently. Every few power-ons, the system is stuck and we get the messages as described at the beginning of the thread. Resetting the PMIC / STM32MP153C solves this.

At first you suggested to remove the line for vmmc-supply from the TF-A dts.

My guess it that SDMMC initialization procedure in the TF-A powers the SDMMC device off/on (maybe to bring it to some initial state) and by removing this line, the TF-A code will not know which supply to toggle, so it will not perform it.

So, the instability/oscillations in BUCK4 (due to the off/on) will not happen, thus will not affect the eMMC.

Then you wrote "In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before."

I assume this is another justification to remove this line from the TF-A dts.

In my case, our custom board connects v3v3 (BUCK4) to both vmmc and vqmmc supplies.

So, should I remove both lines (vmmc-supply = <&v3v3>; vqmmc-supply = <&v3v3>) from the TF-A dts?

Then, you wrote: "After internal discussions, we will deploy a correction that will have the same effect as the previous solution. So you can go on with it on your side."

And, suggested a fix: a patch, to be applied to "regulator_core.c" (a file in the TF-A package).

Can you describe what this patch does?

What do you suggest we do? Apply the patch or modify the TF-A dts file?

thank you

Gil

[Bernard PUEL]

Hello Gil,

The patch "Add support for regulator-always-on at BL2 level" so that the regulator is not switched off during BL2 step if this property is in the dt. It was integrated in V3.1.1 and the following versions ....

What is the SW version you are using ?

 

[GHers.1]

Hello Bernard,

 

We are using Dunfell V3.1.

According to the thread above, the patch directs to drivers/regulator/regulator_core.c in project arm-trusted-firmware-v2.4-stm32mp-r1 (or r2).

However, in our project, we have this path: 

./arm-trusted-firmware-2.4/drivers/st/regulator/stm32mp_regulator.c

Is this the right path for the file in the patch?

Please advise.

thanks,

Gil

[Bernard PUEL]

Hello Gil,

the proposed patch is in the core part of the regulator (then not specific to stm32 device) so should be no issue to apply it on your release.

Please see the architecture from wiki V3 documentation: https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/Regulator_overview

[GHers.1]

hello Bernard,

I am replying to you just now, since we are trying now to fix the issue now.

In-case we are not able to apply the patch, there is a solution you originally suggested (before the patch was available):

In our case, our custom board connects v3v3 (BUCK4) to both vmmc and vqmmc supplies.

Should I remove both lines (vmmc-supply = <&v3v3>; vqmmc-supply = <&v3v3>) from the TF-A dts?

thanks,

Gil

[Bernard PUEL]

Hello Gil,

The goal was to avoid a new switch off/on of the sdcard (just after the Rom code one). So only vmmc-supply.