OP-TEE error (TZC permission failure) on new v5.0.0 SDK

cfilipescu · ‎2023-08-22

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.

cfilipescu · ‎2023-10-27

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 */
        };

View solution in original post

damien1 · ‎2023-09-07

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.

debugging · ‎2023-09-13

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 ?

https://community.st.com/t5/stm32-mpus-products/stm32mp15-eco-5-0-0-bl2-stuck-at-loading-bl32/m-p/590432

debugging · ‎2023-09-15

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.

debugging · ‎2023-09-15

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.

https://wiki.st.com/stm32mpu/index.php?title=How_to_configure_a_256MB_DDR_mapping_from_STM32_MPU_Distribution_Package

Same issue :https://community.st.com/t5/stm32-mpus-products/op-tee-error-on-new-v5-0-0-sdk/m-p/578239

Gregory PLANCHON · ‎2023-09-20

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

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

debugging · ‎2023-09-22

@Gregory PLANCHON

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.

https://community.st.com/t5/stm32-mpus-products/stm32mp15-eco-5-0-0-optee-in-sysram-non-secure-privileged-write/td-p/591438

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;
};
};
};

luaiza · ‎2023-10-26

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 */
	};

cfilipescu · ‎2023-10-27

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 */
        };

DMårt · ‎2024-08-12

This solved my issue too with STM32MP151 processor!

I hope a ST employee can explain why.

Thank you.

STM32MP151AAC3 custom board with STM32-OS as operating system: https://github.com/DanielMartensson/STM32-Computer