2023-08-22 01:50 PM
Hi,
I am trying to migrate my project (custom board using stm32mp153a and 256MB mem) from 4.1.0 to 5.0.0 but I am getting a panic when booting u-boot:
Board: MBfdd8 Var2.15 Rev.B-14
DRAM: 256 MiB
E/TC:0 tzc_it_handler:79 TZC permission failure
E/TC:0 dump_fail_filter:420 Permission violation on filter 0
E/TC:0 dump_fail_filter:425 Violation @0xcff09000, non-secure privileged write, AXI ID 480
M/TC: CPU : 0
M/TC: usr_sp : 0x00000000
M/TC: usr_lr : 0x00000000
M/TC: irq_spsr : 0x00000000
M/TC: irq_sp : 0x00000000
M/TC: irq_lr : 0x00000000
M/TC: fiq_spsr : 0x00000000
M/TC: fiq_sp : 0x00000000
M/TC: fiq_lr : 0x00000000
M/TC: svc_spsr : 0x00000000
M/TC: svc_sp : 0xcdef2ca0
M/TC: svc_lr : 0xcff0a2f0
M/TC: abt_spsr : 0x00000000
M/TC: abt_sp : 0x00000000
M/TC: abt_lr : 0x00000000
M/TC: und_spsr : 0x00000000
M/TC: und_sp : 0x00000000
M/TC: und_lr : 0x00000000
M/TC: pmcr : 0x41072000
E/TC:0 Panic
M/TC: CPU : 0
M/TC: usr_sp : 0x00000000
M/TC: usr_lr : 0x00000000
M/TC: irq_spsr : 0x00000000
M/TC: irq_sp : 0x00000000
M/TC: irq_lr : 0x00000000
M/TC: fiq_spsr : 0x00000000
M/TC: fiq_sp : 0x00000000
M/TC: fiq_lr : 0x00000000
M/TC: svc_spsr : 0x00000000
M/TC: svc_sp : 0xcdef2ca0
M/TC: svc_lr : 0xcff0a2f0
M/TC: abt_spsr : 0x00000000
M/TC: abt_sp : 0x00000000
M/TC: abt_lr : 0x00000000
M/TC: und_spsr : 0x00000000
M/TC: und_sp : 0x00000000
M/TC: und_lr : 0x00000000
M/TC: pmcr : 0x41072000
I am posting the full boot log as an attachment.
I am stuck any help is appreciated.
Solved! Go to Solution.
2023-10-27 06:19 AM
In the end, these are the settings that worked for me (a board with 256MB of memory):
memory@c0000000 {
device_type = "memory";
reg = <0xc0000000 0x10000000>;
/* USER CODE BEGIN memory */
/* USER CODE END memory */
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* USER CODE BEGIN reserved-memory */
optee@ce000000 {
reg = <0xce000000 0x2000000>;
no-map;
};
/* USER CODE END reserved-memory */
};
2023-09-07 07:54 PM
I ran into this problem as well. For me it was u-boot attempting to overwrite memory controlled by optee. I had to insert a memory reservation into the u-boot devicetree to ensure it wouldn't try and overwrite optee.
One of the root causes of my problem was the fact that I am using 256MiB of RAM and Optee is hard coded for a different amount of RAM. So the full fix was to edit the conf.mk in Optee to reduce the system ram available to 256MiB and then calculate the offset and size of the reservation to make in u-boot's devicetree. The version of optee I'm using reserves 0x02000000 memory and given I have 256MiB of RAM my reservation is:
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* USER CODE BEGIN reserved-memory */
optee@0xCE000000 {
reg = <0xCE000000 0x02000000>;
no-map;
};
/* USER CODE END reserved-memory */
};
After this u-boot was booting.
2023-09-13 06:25 PM
I saw issues with BL2 trying to overwrite areas as well and problem loafing BL32. It seem you are beyond that point on ECO 5.0. If you have any suggestion or idea ?
2023-09-15 12:04 AM
If this is a known or confirmed issues, it would be nice for ST to confirm this u-boot matter is 256MB specific or a common issues and post a WIKI on this.
2023-09-15 04:56 AM - edited 2023-09-15 07:34 AM
Just got the same error in a 512MB board. How to fix this ?
OP-TEE DT:
memory@c0000000 {
device_type = "memory";
reg = <0xc0000000 0x20000000>;
/* USER CODE BEGIN memory */
/* USER CODE END memory */
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* USER CODE BEGIN reserved-memory */
optee_framebuffer: optee-framebuffer@dd000000 {
/* Secure framebuffer memory */
reg = <0xdd000000 0x1000000>;
st,protreg = <TZC_REGION_S_RDWR 0>;
};
/* USER CODE END reserved-memory */
};
and U-boot:
memory@c0000000 {
device_type = "memory";
reg = <0xc0000000 0x20000000>;
/* USER CODE BEGIN memory */
/* USER CODE END memory */
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* USER CODE BEGIN reserved-memory */
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
optee_framebuffer@dd000000 {
reg = <0xdd000000 0x1000000>;
no-map;
};
optee@de000000 {
reg = <0xde000000 0x02000000>;
no-map;
};
};
};
0xDD0000000 was used as posted in the below WIKI , assuming that is the area to be used for 512MB
Though, This WIKI is for STM32MP135. There is no WIKI version for STM32MP15 (in my case 512MB) or any information ho to configure this for different CPU and memory configurations.
Same issue :https://community.st.com/t5/stm32-mpus-products/op-tee-error-on-new-v5-0-0-sdk/m-p/578239
2023-09-20 12:00 AM - edited 2023-09-20 12:00 AM
Hi,
can you check your U-boot device tree to see if you have the following name?
If not, you can add it and this should normally correct the error.
reserved-memory {
optee@de000000 {
reg = <0xde000000 0x2000000>;
no-map;
};
};
regards,
Grégory
2023-09-22 08:35 AM - edited 2023-09-22 08:45 AM
it is as in my previous post above,
MY boot log shows NOTICE: BL2: Booting BL32
INFO: Entry point address = 0x2ffc0000
but I read it should be 0xDE000000. I do not know why mine is different, Here is my post, we could continue there as this tread should be closed by the original OP.
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* USER CODE BEGIN reserved-memory */
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
optee_framebuffer@dd000000 {
reg = <0xdd000000 0x01000000>;
no-map;
};
optee@de000000 {
reg = <0xde000000 0x02000000>;
no-map;
};
};
};
2023-10-26 02:38 AM
I am working on STM32MP151a, ST ecosystem v5, openstlinux-6.1-yocto-mickledore-mp1-v23.06.21.
I faced the same issue. When flashing my board.
I also solved adding the below nodes to u-boot.xxx.dts file
memory@c0000000 {
device_type = "memory";
reg = <0xc0000000 0x20000000>;
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
optee@de000000 {
reg = <0xde000000 0x02000000>;
no-map;
};
/* USER CODE END reserved-memory */
};
2023-10-27 06:19 AM
In the end, these are the settings that worked for me (a board with 256MB of memory):
memory@c0000000 {
device_type = "memory";
reg = <0xc0000000 0x10000000>;
/* USER CODE BEGIN memory */
/* USER CODE END memory */
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* USER CODE BEGIN reserved-memory */
optee@ce000000 {
reg = <0xce000000 0x2000000>;
no-map;
};
/* USER CODE END reserved-memory */
};
2024-08-12 03:32 PM - edited 2024-08-12 03:33 PM
This solved my issue too with STM32MP151 processor!
I hope a ST employee can explain why.
Thank you.