2024-10-31 01:40 AM
Hello everyone,
I am trying to migrate a project for the STM32MP151C from dunfell to kirkstone.
The versions of the main components I am using are the following:
Component | Version |
tf-a-stm32mp | v2.6-stm32mp-r2.2 |
optee-os-stm32mp | v3.16.0-stm32mp-r2.2 |
u-boot-stm32mp | v2021.10-stm32mp-r2.2 |
linux-stm32mp | v5.15.145-stm32mp-r2.2 |
I used a given .ioc file with a newer version of STM32CubeMX (v6.8.0 - openstlinux-5.15-yocto-kirkstone-mp1-v22.11.23) to re-generate the devicetrees and added the custom changes from the old devicetrees (see devicetrees attached).
Eventually during boot following error occurs:
I/TC: Primary CPU switching to normal world boot
D/TC:0 tee_entry_exchange_capabilities:100 Asynchronous notifications are disabled
D/TC:0 tee_entry_exchange_capabilities:112 Dynamic shared memory is enabled
D/TC:0 0 core_mmu_xlat_table_alloc:513 xlat tables used 4 / 4
D/TC:? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_init_pseudo_ta_session:309 Open PTA-SCMI
D/TC:? 0 tee_ta_init_pseudo_ta_session:326 PTA-SCMI : a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:514 csess 0x2ffec928 id 1
D/TC:? 0 tee_ta_close_session:533 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:609 Re-open TA a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:514 csess 0x2ffec928 id 1
D/TC:? 0 tee_ta_close_session:533 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:609 Re-open TA a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:514 csess 0x2ffec928 id 1
D/TC:? 0 tee_ta_close_session:533 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:609 Re-open TA a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:514 csess 0x2ffec928 id 1
D/TC:? 0 tee_ta_close_session:533 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:609 Re-open TA a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:514 csess 0x2ffec928 id 1
D/TC:? 0 tee_ta_close_session:533 Destroy session
D/TC:? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA 94cf71ad-80e6-40b5-a7c6-3dc501eb2803
D/TC:? 0 tee_ta_init_pseudo_ta_session:309 Open bsec.pta
D/TC:? 0 tee_ta_init_pseudo_ta_session:326 bsec.pta : 94cf71ad-80e6-40b5-a7c6-3dc501eb2803
E/TC:0
E/TC:0 Core prefetch-abort at address 0x300135a8 (translation fault)
E/TC:0 fsr 0x00000207 ttbr0 0x2ffdf000 ttbr1 0x00000000 cidr 0x0
E/TC:0 cpu #0 cpsr 0x600001f3
E/TC:0 r0 0x2ffec588 r4 0x2ffec588 r8 0x00000000 r12 0x00000020
E/TC:0 r1 0x00000200 r5 0x00000024 r9 0xcdf0ee90 sp 0x2ffe10b0
E/TC:0 r2 0xdededede r6 0x00000000 r10 0x0badc0de lr 0x2ffca2b1
E/TC:0 r3 0x300135a9 r7 0x00000000 r11 0xe320f000 pc 0x300135a8
E/TC:0 TEE load address @ 0x2ffc0000
E/TC:0 Call stack:
E/TC:0 0x300135a8
E/TC:0 Panic 'abort outside thread context' at ?:0
E/TC:0 TEE load address @ 0x2ffc0000
E/TC:0 Call stack:
E/TC:0 0x2ffc2269
E/TC:0 0x2ffca375
E/TC:0 0x2ffc1e6f
E/TC:0 0x2ffc0b24
Has somebody an idea why this error occurs and/or how I can fix it?
Any help would be greatly appreciated :)
2024-10-31 03:59 AM - edited 2024-10-31 04:00 AM
Hi @dhk112
Before addressing technical point I would first understand/challenge your migration strategy.
What reason to migrate and why only on kirkstone (V4.x) which is close to end of maintenance ?
I would rather recommend to move to latest V5.1 / openstlinux-6.1-yocto-mickledore-mpu-v24.06.26, or even, if you can wait few weeks, the coming V6 ( Scarthgap kernel 6.6 ).
Else your migration strategy looks good, by generating DTS backbone with relevant MX version and porting the custom change.
Maybe a review/comparison against reference device tree generated by CubeMX for our evaluation board may help to catch some hidden policy change that may explain some issues.
Hope it help
Olivier
2024-10-31 06:11 AM
Hi Oliver,
thanks for the reply.
I am aware that kirkstone is already close to end of maintenance, but for the moment this project should be ported to kirkstone first and later on to a newer version for project-related reasons that are not relevant here.
I already compared a lot to the device trees of evaluation boards but I can not figure out what might be wrong with my devicetrees.
What parts of the device tree (or possibly other build configuration) could be related to this error?
Best regards