2021-12-17 01:31 PM
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?
Solved! Go to Solution.
2022-01-25 07:34 AM
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 .....
2021-12-20 05:34 AM
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
2021-12-20 05:51 AM
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,
2021-12-20 06:00 AM
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
2021-12-20 06:51 AM
2021-12-20 06:54 AM
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
2021-12-20 10:54 AM
@Community member
I understand the user section is unique, but they must be correct since they worked with arm-trusted-firmware-v2.4-stm32mp-r1, or am I misunderstanding?
As for the clocks, they are the same as before and they worked so why would they stop working?
2021-12-20 01:25 PM
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
2021-12-20 02:55 PM
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?
2021-12-21 12:04 AM
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