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.
2021-12-21 02:48 AM
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)
2021-12-21 07:08 AM
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.
2021-12-21 07:09 AM
@AlexandrShipovsky I encountered that problem before but the device tree has the correct user data.
2021-12-22 06:41 AM
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
2021-12-22 06:44 AM
Else, are you using git or package from st.com for sources ?
2021-12-22 06:48 AM
@Community member here is a link to the device tree
2021-12-22 07:12 AM
Sorry, the link is not working for me.
Again I need further information about your context and WoW.
You said arm-trusted-firmware-v2.4-stm32mp-r1 was and is working.
I understand you succeed to build an image DV3.0 with in legagy mode ( SSBL partition instread of FIP) right ?
Did you use Distribution package or developper package to set this up ?
Since "legacy" imply TF-A, uboot and flashlayout change, distribution package is a good choice.
Following recommandation in Release note :
Note that if no FIP binary support is expected, meaning use legacy mode with stm32 header binary files for bootloaders, remove 'fip' from MACHINE_FEATURES configuration on machine file with:
MACHINE_FEATURES_remove = "fip"
Now when you tell, updating from arm-trusted-firmware-v2.4-stm32mp-r1 to arm-trusted-firmware-v2.4-stm32mp-r2, how did you do that ?
This imply you also get the update of Uboot etc..
Probably redo the full image generation from Distribution is the fast forward way to go.
Olivier
2021-12-22 07:47 AM
Hi @Community member,
Some clarification from my side is necessary since I use buildroot to create my image.
In buildroot I specify the git sources for compiling the arm-trusted-firmware along with compile flags, platform, architecture. I also made my custom device tree into a patch that gets applied to the arm-trusted-firmware source file such that the device tree exists in the source. I do use SSBL partition.
When I say I upgrade I just changed the git tag from r1 to r2 so that buildroot checkout out the updated source code and compiles it.
Uboot and Linux kernel are the same so I can point them to different git tags and therefore mix and match. Right now uboot and Linux are both the latest version.
I also define a custom sdcard layout/partition table and I specify what image to use for each partition, which uses the legacy images.
I have created another link to the device tree: https://pastebin.com/7cikMx27
Since I am using buildroot I understand if this is outside the scope of this forum.
2021-12-22 07:58 AM
Hi @cfilipescu ,
Ok, indeed a key information !
Since ST and Bootlin company announced partnership from DV3.1 to support an official buildroot distribution this community is opened to this topic !
But, so far, I can not help you further and will point you to Bootlin support space you will find at this link :
Announcing buildroot-external-st, Buildroot support for STM32MP1 platforms - Bootlin's blog
Hope it help,
Olivier
2021-12-22 08:06 AM
That is good to hear, I used their articles from a few years ago on how to get buildroot going so I will look at their repo and hopefully I can figure it out from there.