OP-TEE error on new v5.0.0 SDK

[GCici]

Hi, i get this error when uboot starts on custom MP153D board:

 

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 @0xdff09000, non-secure privileged write, AXI ID 480

 

Can someone point me in the right direction? I cannot find a correspondence for AXI ID 480 in order to inverstigate over.

[Gregory PLANCHON]

Hi,

 

Could you give me more details on the procedure you used to boot on openSTLinux 5.0?

In order to see if it could be due to the installation .

 

Regards,

Grégory

[GCici]

Hi, just compiled from downloaded sdk. I think it could be a RAM related issue. I tried the same configuration on a board with 256Mb (2Gbit) 16 bit DDR3 module (only the RAM capacity changes) and got AXI ID 4a0 error. Then I set a new ram configuration in CubeMX and now it runs OK. For the 512Mb (4Gbit) DDR3 module i still get AXI ID 480 error. I cannot find a valid configuration setup, neither I can use the bundled 1x4Gb dtsi. The RAM module is from the same family of the 2G one, same datasheet and same timings.

[Gregory PLANCHON]

Hi ,

 

I've had a look at your problem and I'll need some more information.

• Did you touch the optee compile line to change the RAM size?
• Can you share your TF-A device tree with me to check for errors?

 

Regards,

Grégory

[cfilipescu]

I am getting the same error when using stm32mp153a part and 256MB memory. Is there a solution to overcome this problem?

[debugging]

Bump in the same errors just now. That makes three of us.

 This is a board with discrete power that is 512MB  STM32MP157AAA3 and runs ECO 1.0 fine.

Same issue :https://community.st.com/t5/stm32-mpus-products/op-tee-error-tzc-permission-failure-on-new-v5-0-0-sdk/td-p/584339

Attached the boot log.

 

[debugging]

No further ideas how to debug this  from ST ?

[debugging]

@GCici  Did you find any clues ?

[GCici]

Hi, it was the DDR configuration file generated by CubeMX. Tried relaxed timings and it now works. But now I have another problem regarding i think u-boot. With 256Mb RAM i get the following error  just before loading the kernel:

Starting kernel ...

efi_free_pool: illegal free 0xcaee4040
efi_free_pool: illegal free 0xcaee1040
efi_free_pool: illegal free 0xcaedf040
efi_free_pool: illegal free 0xcaedd040
efi_free_pool: illegal free 0xcaedb040
efi_free_pool: illegal free 0xcaed9040
efi_free_pool: illegal free 0xcaed7040

then it goes in bootloop (i think because of wdt)

Same board with exactly the same hardware except for the 512Mb DDR3 module instead of the 256Mb one, no problem. All the 2 boards with the previous ecosystem run fine

[debugging]

Very interesting , where to set to relax those timings ? My 512MB board runs fine with ECO 1, but still have AXI 480 error with ECO 5.

[GCici]

 

[debugging]

Did not work for me. Same error.

I/TC: Early console on UART#4
I/TC:
I/TC: Pager is enabled. Hashes: 2848 bytes
I/TC: Pager pool size: 92kB
I/TC: Embedded DTB found
I/TC: OP-TEE version: Unknown_3.19 (gcc version 12.2.0 (GCC)) #1 Fri Sep 22 02:55:57 UTC 2023 arm
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT stm32mp157a-board-mx.dts
I/TC: DTB enables console (non-secure)
I/TC: HUK unlocked
I/TC: No power configuration found in DT
I/TC: Primary CPU switching to normal world boot
optee optee: OP-TEE: revision 3.19

U-Boot 2022.10-stm32mp-r1 (Sep 22 2023 - 10:56:19 +0800)

CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1)
DRAM: 512 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 DEBUG: status = 0x1
E/TC:0 dump_fail_filter:426 DEBUG: IT_STATUS = 0x10
E/TC:0 dump_fail_filter:427 DEBUG: filter = 0x0
E/TC:0 dump_fail_filter:428 DEBUG: tzc.base = 0x34806000
E/TC:0 dump_fail_filter:429 DEBUG: FAIL_ID(filter) = 0x2c
E/TC:0 dump_fail_filter:431 Violation @0xdfb19000, non-secure privileged write, AXI ID 480
E/TC:0 Panic

relaxed:

#define DDR_DRAMTMG0 0x131B1215
#define DDR_DRAMTMG1 0x000A051D
#define DDR_DRAMTMG2 0x06080A10
#define DDR_DRAMTMG3 0x0050400C
#define DDR_DRAMTMG4 0x09040709
#define DDR_DRAMTMG5 0x06060403
#define DDR_DRAMTMG6 0x02020002
#define DDR_DRAMTMG7 0x00000202
#define DDR_DRAMTMG8 0x00001005
#define DDR_DRAMTMG14 0x000000A0

w/o  relaxed:

#define DDR_DRAMTMG0 0x121B2414
#define DDR_DRAMTMG1 0x000A041C
#define DDR_DRAMTMG2 0x0608090F
#define DDR_DRAMTMG3 0x0050400C
#define DDR_DRAMTMG4 0x08040608
#define DDR_DRAMTMG5 0x06060403
#define DDR_DRAMTMG6 0x02020002
#define DDR_DRAMTMG7 0x00000202
#define DDR_DRAMTMG8 0x00001005
#define DDR_DRAMTMG14 0x000000A0

 

[debugging]

Thank you so much.  It  would be a bit surprising if this fixes the AXI violation issue. In case of DDR timing issues, one would expect random type of errors in different DRAM locations than a consistent error at the same memory address. It would be more likely to be related to the initialization of the memory ranges of the tzc400. But you never know. will try this !