cancel
Showing results for 
Search instead for 
Did you mean: 

STM32MP15 ECO 5.0.0 OPTEE in SYSRAM non-secure privileged write AXI ID 480

debugging
Senior III

Same or related posts

https://community.st.com/t5/stm32-mpus-products/op-tee-error-on-new-v5-0-0-sdk/td-p/578239/page/2

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

Custom STM32MP157AAA3 board,  512MB. TF-A OP-TEE in SYSRAM

Two outcomes.

[a] building u-boot with stm32mp1_trusted_defconfig : boot loops around (restart), does not even reach u-boot

[b] building u-boot with stm32mp1_defconfig: dump_fail_filter:425 Violation @0xdfb19000, non-secure privileged write, AXI ID 480

This area  was firewalled in fw-config.dts based on the Wiki how to configure FW-CONF and also added as a reserved area in TF-A, OPTEE and u-boot DT,  Though u-boot (or something else for that matter) tries to access this area ?

Does this violation have anything to do with

a. conf.mk  in OP-TEE or the OP-TEE DT ?  (memory reservation was added)

b.  FW-CONFIG DT?  (Firewall for this region was added)

c.  U-BOOT  DT?  (the memory reservation was added)

d. Anything else ?

The U-boot WIKI states that stm32mp15_defconfig is to be used when when FIP is used in OpenSTLinux" and als that the two next defconfig are kept only for compatibility with upstream and should not be used:/ Those are basic & trusted

That leaves me with the memory violation issue.

No idea what else can be done to configure TZC and U-boot to solve this issues. Some help will be really appreciated Logs attached.

1 ACCEPTED SOLUTION

Accepted Solutions

Started with a new set of ECO 5.0.0 and Cube-MX files. Did not apply the 2MB reserved area in the fw-config firewall this time, The AXI 480 error appeared again. After adding the optee reserved area in U-boot.dts the AXI  error went away.  This thus AXI 480 is caused by missing optee-reserved area in u-boot DTS. While this error is generated by OP-TEE code, it happens at u-boot execution. My hypothesis is that of u-boot is using OP-TEE services.

View solution in original post

17 REPLIES 17
debugging
Senior III

Found the following on the ST Chinese website:

https://wiki.stmicroelectronics.cn/stm32mpu/index.php?title=Visual_troubleshooting_grid&oldid=62487

This trace indicates that the TZC internal peripheral is detecting a "permission violation" made by the master whose AXI ID is 0x403. It corresponds to the LTDC internal peripheral (LTDC NSAID=0b0011.

In this case , what is AXI ID 480 ? Is there a list of AXI ID's ? Could it be a device driver that potentially is trying to access a  privileged location ? Should I edit the .config of u-boot and disable non-used but enabled default drivers such as SPI, USB  Network etc..  This board currently only uses UART and SD card to attempt to boot. where other peripherals such as the NIC, LTDC etc.. are not used (yet)

Followed this :https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG for firewall, and this line ism missing in the DT from  the ECO:

 0xdfe00000 0x00200000 TZC_REGION_S_NONE
              TZC_REGION_ACCESS_RDWR(STM32MP1_TZC_A7_ID)>;

but with our without, still errors occurs.

and I found the error is generated from tzc400.c

The DT has:

0xde000000 0x01e00000 TZC_REGION_S_RDWR 0

Can someone form ST explain why with this firewall setting, u-boot is still trying to access a firewalled area or should it be allowed but osmehow it still generates an exeption  ? How can ST "flavored" Boards can boot  w/o this setting ? form the sources it seems the ST board are not uses OPTEE. (at least no optee memory configured in the DT's)

I also wonder if the this cachaeable sizefor DDR in WIKI https://wiki.st.com/stm32mpu/wiki/How_to_configure_a_256MB_DDR_mapping_from_STM32_MPU_Distribution_Package

CONFIG_DDR_CACHEABLE_SIZE

In case of overlap between the cacheable area before U-Boot relocation and the reserved and secured by OP-TEE region, the U-Boot code execution on Arm® Cortex®-A7 normal world can generate a speculative access to this secured area which cause a firewall error.

Does this applies to a configuration wirh 512MB DDR as well?

debugging
Senior III

Checked CONFIG_DDR_CACHEABLE_SIZE in uboot .config and it's  correct (0x800000).

based on this post

https://wiki.stmicroelectronics.cn/stm32mpu/index.php?title=Visual_troubleshooting_grid&oldid=62487

tried to disable function in u-boot  .config to see if that helped in case a peripheral was trying to access the protected region. such as unselecting PMIC and selecting regulator power. But somehow uboot build fails on pmic_read etc.. functions. (why does it compile pmic if not configured ?)  Tried to disable SPI, I2C , Ethernet in .config as well , but that also caused u-boot error and a failure  to build (errors those functions for spi, i2c. ). why if those were all disabled in CubeMX ?)   t's a kind of ridiculous that it is not possible to build a minimum viable configuration for a custom board that has been proven fine for the hardware on an older ECO system.

Strongly consider to  give up on ECO 5.0.0 and wait for better days.

debugging
Senior III

debugging_0-1695279262899.png

Even there is a u-boot sign on, the actual error occurs in tzc400.c in the OP-TEE code tree in the dump_fail_filter function . That was a bit misleading, I was assuming u-boot is running, and perhaps it is, but the memory access could be checked by OP-TEE code. not sure how this works but guess  OPTEE is a "service" to u-boot

it is a PRIVILEGED write but a non-secure access. I interpreted that as that caller has right to access the memory area but not for write access. Perhaps that is a wrong conclusion.

it reports filter "0" , where can this filter be found ? what is AXI ID 480 ?

io_read32(tzc.base + FAIL_ID(filter))) = 480

 

EMSG("Violation @0x%"PRIx64", %ssecure %sprivileged %s, AXI ID %"PRIx32,
addr,
nonsecure_not_secure(filter) ? "non-" : "",
priv_not_unpriv(filter) ? "" : "un",
write_not_read(filter) ? "write" : "read",
io_read32(tzc.base + FAIL_ID(filter)));
debugging
Senior III

The default firewall setting in stm32mp15-fw-config.dtsi  are

DDR_NS_BASE DDR_NS_SIZE TZC_REGION_S_NONE TZC_REGION_NSEC_ALL_ACCESS_RDWR
DDR_SEC_BASE DDR_SEC_SIZE TZC_REGION_S_RDWR 0

DDR_SEC_BASE = 0xDE000000 and DDR_SEC_SIZE  = 0x02000000

ST WIKI mentioned:

0xDE00 0000: 30-Mbyte region where only secure accesses are allowed and

0xDFE0 0000: 2-Mbyte region where secure accesses are forbidden and non-secure accesses are possible only from an A7 CPU

0xdfe00000 0x00200000 TZC_REGION_S_NONE TZC_REGION_ACCESS_RDWR(STM32MP1_TZC_A7_ID

The region from 0xDE00000 is 30MB, not 32MB, in length as was set in the dtsi (0x0200000). The error occurred in the 30-32MB area (dfb19000.) but the shared should have different permissions than the ones for 0xDE000000. Thus changed the length from  0xDE000000 in the fw-config.dts firewall settings to 0x01E00000.

DDR_SEC_BASE 0x01E00000 TZC_REGION_S_RDWR 0

That did not solve it :crying_face:.  dtb decompiled:

st-mem-firewall {
compatible = "st,mem-firewall";
memory-ranges = <0xc0000000 0x1e000000 0x00000000 0x87fb87fb 0xde000000 0x01e00000 0x00000003 0x00000000 0xdfe00000 0x00200000 0x00000000 0x00010001>;

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 @0xdfb19000, non-secure privileged write, AXI ID 480
M/TC: CPU : 0

Could ST confirm that the firewall setting for

0xdfe00000 0x00200000 TZC_REGION_S_NONE TZC_REGION_ACCESS_RDWR(STM32MP1_TZC_A7_ID

is correct and if this need  settings in OPTEE or U-boot DTS  , since the additional memory area for the DT in the WIKI did also not solve it? Perhaps the DT's for STM32MP157AAA3 it needs different values ?

I don't see any replies from ST, So it either means

1. This error is new (it is not, other posts reported the same480 error)

2. ST does not  have manpower or don't bother to reply.

3. The readers of this post have no idea either

4. This post is regarded stupid by readers  and I should go and read a WIKI/manual somewhere else.

5. The reader knows the answer but don't borh to reply. (for whatever reason)

whatever it is, when you read up to this point, it may have mattered to you and thank you for your interest :D

debugging
Senior III

Did a complete exercise to compare the WIKI (ref "256/512MB WIKI") to the actual ECO 5.0 source code:

Ref: https://wiki.st.com/stm32mpu/wiki/How_to_configure_a_256MB_DDR_mapping_from_STM32_MPU_Distribution_Package

In make build command AARCH32_SP_OPTEE=1 and STM32MP1_OPTEE_IN_SYSRAM=1 were applied

From stm32mp15-fw-config.dtsi:

#define DDR_NS_BASE STM32MP_DDR_BASE
#ifdef AARCH32_SP_OPTEE
#define DDR_SEC_SIZE STM32MP_DDR_S_SIZE
#define DDR_SEC_BASE (STM32MP_DDR_BASE + (DDR_SIZE - DDR_SEC_SIZE))
#define DDR_NS_SIZE (DDR_SEC_BASE - DDR_NS_BASE)
#else /* !AARCH32_SP_OPTEE */
#define DDR_NS_SIZE DDR_SIZE
#endif /* AARCH32_SP_OPTEE */

From /plat/st/stm32mp1/stm32mp1_def.h"

STM32MP_DDR_BASE U(0xC0000000)

from /plat/st/stm32mp1/stm32mp1_fip_def.h:

STM32MP_DDR_S_SIZE U(0x02000000) /* 32 MB */

from the dtsi generated by CubeMX /fdts/<board>-mx-fw-config.dts:

DDR_SIZE 0x20000000 /* 512MB */

Thus:

DDR_SEC_SIZE = 0x02000000
DDR_SEC_BASE = 0xC0000000 + (0x20000000 - 0x02000000) = 0xDE000000
DDR_NS_SIZE = 0xDE000000 - 0xC0000000 = 0x1E000000

firewall: From: https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG:

memory-ranges = <
DDR_NS_BASE DDR_NS_SIZE TZC_REGION_S_NONE TZC_REGION_NSEC_ALL_ACCESS_RDWR
30MB_SECURE_REGION 30MB_SECURE_SIZE DDR_SEC_SIZE TZC_REGION_S_RDWR 0
2MB_NON_SECURE_REGION 2MB_NON_SECUE_SIZE TZC_REGION_S_NONE TZC_REGION_ACCESS_RDWR(STM32MP1_TZC_A7_ID)
>;

Issues:

[1] For 512 MB, The "256/512MB" WIKI lists for the  512MB configuration  DDR_SEC_BASE = 0xDE200000 while after the source code compilation DDR_SEC_BASE results in 0xDE0000000 (de-compling fw.config.dtb also hows this value for DDR_SEC_BASE)

[2] The "256/512MB" WIKI mentions 30MB is DDR_SEC_SIZE, (0x02000000) while the actual source code this is named as DDR_NS_SIZE (non secure?) (0x01E00000)

[3] The 2MB_NON_SECURE (shared) region mentioned in the "how to configure FW_CONFIG" is missing in stm32mp15-fw-config.dtsi generated by CubeMX.

[4] DDR_SHARE_BASE is mentioned in the "256/512MB" WIKI, but not in the actual source code. It was removed from TF-A source code by a patch:
./tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8497:-#define DDR_SHARE_BASE (STM32MP_DDR_BASE + (DDR_SIZE - DDR_SHARE_SIZE))
./tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8501:-#define DDR_SEC_BASE (DDR_SHARE_BASE - DDR_SEC_SIZE)
./tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8531:- DDR_SHARE_BASE DDR_SHARE_SIZE TZC_REGION_S_NONE

[5] For OP-TEE and U-BOOT optee_framebuffer: where and how can this address be determined ? Based on the "256/512MB" WIKI this should be DDR_SHARE_BASE but based on the actual source code (see above) this is the same as DDR_SEC_BASE (0xDE000000 for 512MB), that should not be correct.

[6] in U-bOOT: in the "256/512MB" WIKI the optee region is defined as DDR_SHARE_BASE, but this is removed in the source code by the patch. How can this address and size be determined ?

I could have something wrong, but ST please take a look at these. Due to this I am not able to configure the DT's correctly. Please add a WIKI how to configure U-BOOT, FW-CONFIG and OPTEE DT for STM32MP157 with  512MB. Thank you.

 

debugging
Senior III

Several patches had been made in the code related to shared optee memory. As you can calculate these patches removed the "shared" memory definitions. it looks like the coders could not make their mind up how to structure the definitions for the memory map. if these definitions were not removed  the calculations would be:

DDR_SHARE_SIZE STM32MP_DDR_SHMEM_SIZE
STM32MP_DDR_SHMEM_SIZE U(0x00200000) /* 2 MB */
STM32MP_DDR_SHMEM_SIZE U(0) /* empty */

DDR_SHARE_SIZE STM32MP_DDR_SHMEM_SIZE
DDR_SHARE_BASE (STM32MP_DDR_BASE + (DDR_SIZE - DDR_SHARE_SIZE))
DDR_SEC_BASE (DDR_SHARE_BASE - DDR_SEC_SIZE)

DDR_SHARE_BASE = 0xC0000000 + (0x20000000 - 0x00200000) = 0xDE00000000 (?? same as DDR_SEC_BASE?)
DDR_SHARE_SIZE = 0x002000000 or 0 ?

Really don't understand how this boot code expects optee and optee_framebuffer. to be configured.

./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8497:-#define DDR_SHARE_BASE (STM32MP_DDR_BASE + (DDR_SIZE - DDR_SHARE_SIZE))
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8501:-#define DDR_SEC_BASE (DDR_SHARE_BASE - DDR_SEC_SIZE)
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8531:- DDR_SHARE_BASE DDR_SHARE_SIZE TZC_REGION_S_NONE
user@H3:/media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources$grep -Rnw . -e 'DDR_SHARE_SIZE'
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8496:-#define DDR_SHARE_SIZE STM32MP_DDR_SHMEM_SIZE
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8497:-#define DDR_SHARE_BASE (STM32MP_DDR_BASE + (DDR_SIZE - DDR_SHARE_SIZE))
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8531:- DDR_SHARE_BASE DDR_SHARE_SIZE TZC_REGION_S_NONE
user@H3:/media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources$grep -Rnw . -e 'STM32MP_DDR_SHMEM_SIZE'
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:8496:-#define DDR_SHARE_SIZE STM32MP_DDR_SHMEM_SIZE
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:14511:- STM32MP_DDR_SHMEM_SIZE);
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:16925:-#define STM32MP_DDR_SHMEM_SIZE U(0x00200000) /* 2 MB */
./arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/0001-v2.8-stm32mp-r1.patch:16928:-#define STM32MP_DDR_SHMEM_SIZE U(0) /* empty */

And there were issues weith OP-TEE, so I wonder if it was really fixed in ECO 5.0 ?

https://github.com/OP-TEE/optee_os/issues/5275

ST TF-A v2.6 (e.g. tag v2.6-stm32mp-r1) and mainline OP-TEE don't comply on the location of the secure memory and reserved shared memory in DDR. ST TF-A v2.6-stm32mp-r1 locates the 2MB rsv shm below the 30MB secure DDR whereas mainliine OP-TEE (and mainline TF-A v2.6/v2.7) locates the rsv shm above the secure DDR area. Once consistent, boot is fine.

debugging
Senior III

The "256/512MB" WIKI states for OPTEE:

The OP-TEE memory configuration is defined in the file core/arch/arm/plat-stm32mp1/conf.mk

CFG_TZDRAM_START ?= ($(CFG_DRAM_BASE) + $(CFG_DRAM_SIZE) - $(CFG_TZDRAM_SIZE))
= 0xc0000000 + 0x10000000 - 0x1e00000 = 0xce200000
CFG_SHMEM_START  ?= ($(CFG_TZDRAM_START) - $(CFG_SHMEM_SIZE))
= 0xce200000 - 0x200000 = 0xce000000

These definitions are not in the conf.mk for for STM32MP15

 

debugging
Senior III

There were issues about the location of the shared memory before:

https://github.com/OP-TEE/optee_os/issues/5275

ST TF-A v2.6 (e.g. tag v2.6-stm32mp-r1) and mainline OP-TEE don't comply on the location of the secure memory and reserved shared memory in DDR. ST TF-A v2.6-stm32mp-r1 locates the 2MB rsv shm below the 30MB secure DDR whereas mainliine OP-TEE (and mainline TF-A v2.6/v2.7) locates the rsv shm above the secure DDR area. Once consistent, boot is fine.

My best guesses are

1. That the memory map is as follows:

debugging_0-1695277874167.png

2. that for the DT's the following values should be used:

OPTEE_FRAMEBUFFER: = 0xDD000000 size 0x01000000 (in u-boot DT "optee-framebuffer)

DDR_SEC_BASE  / SIZE =  0xDE000000 0x02000000  (in optee and uboot DT for "optee" and fw-config.dts firewall) 

DDR_SHARED_BASE / SIZE = 0xDFE00000 0x00200000 (in fw-config firewall)

3. That the regions in the firewall in (in board-fw-config.dtsi) should be defined as follows:

//#define DDR_SEC_SIZE STM32MP_DDR_S_SIZE
//#define DDR_SEC_BASE (STM32MP_DDR_BASE + (DDR_SIZE - DDR_SEC_SIZE))
#define DDR_NS_SIZE (DDR_SEC_BASE - DDR_NS_BASE)

#define DDR_SHARE_SIZE 0x00200000
#define DDR_SEC_SIZE (STM32MP_DDR_S_SIZE - DDR_SHARE_SIZE)
#define DDR_SEC_BASE (STM32MP_DDR_BASE + (DDR_SIZE - DDR_SEC_SIZE - DDR_SHARE_SIZE))
#define DDR_SHARE_BASE (DDR_SEC_BASE + DDR_SEC_SIZE)
#ifdef AARCH32_SP_OPTEE

That is:

DDR_NS_BASE = 0xC0000000

DDR_NS_SIZE = 0x1E000000

DDR_SHARE_SIZE 0x00200000

DDR_SEC_SIZE 0x01A00000

DDR_SEC_BASE = 0xDE000000

DDR_SHARE_BASE = 0xDFE00000

memory-ranges = <
DDR_NS_BASE DDR_NS_SIZE TZC_REGION_S_NONE TZC_REGION_NSEC_ALL_ACCESS_RDWR
DDR_SEC_BASE DDR_SEC_SIZE TZC_REGION_S_RDWR 0
// PATCH Added for firewall shared memory 2MB area below top of DDR
DDR_SHARE_BASE DDR_SHARE_SIZE TZC_REGION_S_NONE TZC_REGION_ACCESS_RDWR(STM32MP1_TZC_A7_ID)
>;
#else

Conclusion,  still the same error:

U-Boot 2022.10-stm32mp-r1 (Sep 21 2023 - 11:44:11 +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

fdtdump board.fw-config.dtb :

/ {
dtb-registry {
compatible = "fconf,dyn_cfg-dtb_registry";
hw-config {
load-address = <0x00000000 0xc0500000>;
max-size = <0x00040000>;
id = <0x00000002>;
};
nt_fw {
load-address = <0x00000000 0xc0100000>;
max-size = <0x00400000>;
id = <0x00000005>;
};
tos_fw {
load-address = <0x00000000 0x2ffc0000>;
max-size = <0x00022000>;
id = <0x00000004>;
};
};
st-mem-firewall {
compatible = "st,mem-firewall";
memory-ranges = <0xc0000000 0x1e000000 0x00000000 0x87fb87fb 0xde000000 0x01e00000 0x00000003 0x00000000 0xdfe00000 0x00200000 0x00000000 0x00010001>;
};

Attached the build log.

Funny footnote watching the STM32MP1 training video ... "This OPTEE , but can't remember what it does"...   hm, so how I am supposed to learn this ? https://academy.st.com/s/learning-activity-detail-standard?ltui__urlRecordId=a5x3W000000ZXiBQAW&ltui__urlRedirect=learning-activity-detail-standard&ltui__parentUrl=learning-plan-detail-standard

 

 

debugging
Senior III

These  are settings from OP-TEE conf.mk

CFG_TZDRAM_SIZE ?= 0x02000000
CFG_DRAM_BASE ?= 0xc0000000
CFG_DRAM_SIZE ?= 0x20000000
CFG_TZDRAM_SIZE ?= 0x02000000

CFG_TZDRAM_START ?= ($(CFG_DRAM_BASE) + $(CFG_DRAM_SIZE) - $(CFG_TZDRAM_SIZE))

= 0xC000000 + 0x20000000 - 0x02000000 ) = 0xDE000000   => This matches the  memory map as best guessed above and  is DIFFERENT than in the WIKI https://wiki.st.com/stm32mpu/wiki/How_to_configure_a_256MB_DDR_mapping_from_STM32_MPU_Distribution_Package

0xde200000 | DDR_SEC_BASE/CFG_TZDRAM_START

 So which one is correct. the WIKI or STMCubeMX and ST's source tree code ?

This post states:

https://www.spinics.net/lists/arm-kernel/msg845973.html

1/ TF-A BL2 loads OP-TEE, U-Boot and its device tree in DDR 
2/ OP-TEE update the U-Boot device tree to add its nodes      
3/ U-Boot copy the OP-TEE nodes in kernel device tree       

In which step of these is the AXI 480 error occurring. ?  Since the error occurs in OP-TEE code it loos like step 2.

as a wild guess, put the following in u.boot.dts, but did not fix it

optee@de000000 {
reg = <0xde000000 0x02000000>;
no-map;
};

secure_memory@de000000 {
reg = <0xde000000 0x02000000>;
no-map;
};

 

Normally after DRAM size message there is the following, though in my case there is an violation. Where in the code is this point ?

optee optee: OP-TEE: revision 3.19
Clocks:
- MPU : 650 MHz
- MCU : 200 MHz

l