From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51FC7C433E7 for ; Tue, 13 Oct 2020 11:08:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C9A4320659 for ; Tue, 13 Oct 2020 11:08:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tO/vHZsB"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=st.com header.i=@st.com header.b="zqM2l31g" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9A4320659 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=st.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cUSG2gUmi9lp+vgrgRcNFIb/vZjcACea76+hoOUIyiE=; b=tO/vHZsBRfKSNxTUrYb4mtUcc FzDSLAb6uQ1b+c4wpdkb8JS43/xJV4npO4g4BKlCepMqwdU9+A9/Ah+iGhyQUOPjTD377mzcZWmaK xc/5cEowP9OZpua2IfJeMj5zgwgAvqCWMsdBafb87YmGBa1ojB3WmoR8ZVpA9stHIhPvHNxqCsF60 nOzLPzDdAUdWZUR4fy/CMSK+lrGIEjxVZzvOd12IOlYXYjvEK8YYSKN92bBHWJsUYe/f3PPV9vNGu NQILR7fhhredWc5JFE1jFLwmN2BQsansRxEiWkg5v8Jre0Op9JUPQaYPhVnwHGLJTBIn+omIr2y4a 0wgErwP5w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSI8d-0000QR-KT; Tue, 13 Oct 2020 11:06:39 +0000 Received: from mx08-00178001.pphosted.com ([91.207.212.93] helo=mx07-00178001.pphosted.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSI8a-0000P1-33 for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 11:06:38 +0000 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09DB27Qe019973; Tue, 13 Oct 2020 13:06:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=STMicroelectronics; bh=HiRbzfD6BbjzN2bY4LxE3Oh4re5pzyO0LePtEsvFW48=; b=zqM2l31g2ZPrLNjy+ia5/VWkDeBhQD/a5Q0E9LNN4fy0gH//2xnxQXlG4qMMuh0MRPWH EpRb3NEMfAO2kSfHmzVR3LW8J1sC5cg0F9yNvkCK9xq32A3QhYnn5bAH2HufyQdiE92l emtpesmnSCue1FW3QuPZ1KkpDM7mck/Wdj2yYkjf9Nzwvc/a9Ev7f+CUhr9Pfex5L9Nq CG8/bAghEIEIMrNZmWMpAEcESIKptppJor6WkYL4ek0PYYd4tTHeqoXvN14GC1E0/liC 1pS0Bbs6vH1WnGU7ynpwTBVfLzsgq9Kw6iqUbpFo7bSXYMEI/hcDx4+wvyvtUsgfQApq LQ== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 34353w6tmp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Oct 2020 13:06:28 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5239B100038; Tue, 13 Oct 2020 13:06:09 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag2node3.st.com [10.75.127.6]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 3DD452B53EA; Tue, 13 Oct 2020 13:06:09 +0200 (CEST) Received: from SFHDAG2NODE3.st.com (10.75.127.6) by SFHDAG2NODE3.st.com (10.75.127.6) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 13 Oct 2020 13:06:08 +0200 Received: from SFHDAG2NODE3.st.com ([fe80::31b3:13bf:2dbe:f64c]) by SFHDAG2NODE3.st.com ([fe80::31b3:13bf:2dbe:f64c%20]) with mapi id 15.00.1473.003; Tue, 13 Oct 2020 13:06:08 +0200 From: Patrick DELAUNAY To: Jan Kiszka , Etienne Carriere Subject: RE: STM32MP1: Adding TF-A causes kernel errors Thread-Topic: STM32MP1: Adding TF-A causes kernel errors Thread-Index: AQHWlw8+pG08p6cAXkmKAJ24y+K7QKmCYV+AgAYKqwCADAsGAIAA01YQ Date: Tue, 13 Oct 2020 11:06:08 +0000 Message-ID: <5edd1c1ddd154000b14e87246555bf3b@SFHDAG2NODE3.st.com> References: <746e3c3b-7b2a-f815-a000-bcb2c31317cb@web.de> <6a493688-6c0f-6e8b-d072-88855236e677@st.com> <4ccf4dcc-a340-6c34-c5b4-ff06d79aa29d@web.de> <2aa485b5-ee8f-38e6-317e-513cd3be8a1e@siemens.com> <1e4c88dd-2a61-570f-718b-d47a2e0ba18a@siemens.com> In-Reply-To: <1e4c88dd-2a61-570f-718b-d47a2e0ba18a@siemens.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.48] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-13_03:2020-10-13, 2020-10-13 signatures=0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201013_070636_637086_D86D9705 X-CRM114-Status: GOOD ( 36.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre TORGUE , Yann GAUTIER , Patrice CHOTARD , U-Boot Mailing List , Christophe PRIOUZEAU , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jan, > From: Jan Kiszka > Sent: mardi 13 octobre 2020 00:02 > > On 05.10.20 08:07, Jan Kiszka wrote: > > On 01.10.20 11:52, Jan Kiszka wrote: > >> On 30.09.20 11:51, Jan Kiszka wrote: > >>> [BCC'ed TF-A only, migrating to u-boot, including folks involved > >>> there] > >>> > >>> On 30.09.20 11:20, Yann GAUTIER wrote: > >>>> Hi Jan, > >>>> > >>>> After discussing with my colleagues, it seems there are 2 issues there. > >>>> One patch is missing in U-Boot: > >>>> http://patchwork.ozlabs.org/project/uboot/patch/20200605092244.1.I7 > >>>> 73bf523d9f4d1a6212483d030e34113b832a779@changeid/ > >>>> > >>> > >>> I can confirm that this resolves the errors I've seen. > >>> > >> > >> Picking up again, this time for OP-TEE: > >> Do I need more patches, wherever, to get that one running as well? > >> > >> NOTICE: CPU: STM32MP157AAA Rev.B > >> NOTICE: Model: STMicroelectronics STM32MP157C eval daughter on eval > mother > >> NOTICE: Board: MB1263 Var1 Rev.C-01 > >> NOTICE: BL2: v2.3(): > >> NOTICE: BL2: Built : 10:11:55, Sep 30 2020 > >> NOTICE: BL2: Booting BL32 > >> I/TC: Early console on UART#4 > >> I/TC: > >> I/TC: Pager is enabled. Hashes: 2144 bytes > >> I/TC: Pager pool size: 100kB > >> I/TC: No non-secure external DT > >> I/TC: Embedded DTB found > >> I/TC: OP-TEE version: Unknown (gcc version 8.3.0 (Debian 8.3.0-2)) #2 > >> Thu Oct 1 06:53:58 UTC 2020 arm > >> I/TC: Primary CPU initializing > >> I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT > >> stm32mp157c-ev1.dts > >> I/TC: RCC is non-secure > >> I/TC: DTB enables console (non-secure) > >> I/TC: Primary CPU switching to normal world boot > >> > >> > >> U-Boot 2020.07 (Oct 01 2020 - 06:54:18 +0000) > >> > >> CPU: STM32MP157AAA Rev.B > >> Model: STMicroelectronics STM32MP157C eval daughter on eval mother > >> Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1) > >> Board: MB1263 Var1.0 Rev.C-01 > >> DRAM: 1 GiB > >> Clocks: > >> - MPU : 650 MHz > >> - MCU : 208.878 MHz > >> - AXI : 266.500 MHz > >> - PER : 24 MHz > >> - DDR : 533 MHz > >> NAND: 1024 MiB > >> MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1 > >> Loading Environment from EXT4... ** File not found /uboot.env ** > >> > >> ** Unable to read "/uboot.env" from mmc0:7 ** > >> In: serial > >> Out: serial > >> Err: serial > >> Net: eth0: ethernet@5800a000 > >> Hit any key to stop autoboot: 0 > >> Boot over mmc0! > >> Saving Environment to EXT4... Unsupported feature metadata_csum found, not > writing. > >> > >> ** Unable to write "/uboot.env" from mmc0:7 ** Failed (1) switch to > >> partitions #0, OK > >> mmc0 is current device > >> Scanning mmc 0:7... > >> Found U-Boot script /boot/boot.scr > >> 562 bytes read in 26 ms (20.5 KiB/s) > >> ## Executing script at c4100000 > >> 57629 bytes read in 38 ms (1.4 MiB/s) > >> 9474560 bytes read in 429 ms (21.1 MiB/s) > >> 4410487 bytes read in 212 ms (19.8 MiB/s) Kernel image @ 0xc2000000 [ > >> 0x000000 - 0x909200 ] ## Flattened Device Tree blob at c4000000 > >> Booting using the fdt blob at 0xc4000000 > >> Loading Ramdisk to cfbcb000, end cffffc77 ... OK > >> Loading Device Tree to cfbb9000, end cfbca11c ... OK > >> OP-TEE: revision 3.10 > >> > >> Starting kernel ... > >> > >> I/TC: Secondary CI/TC: Secondary CPU 1 switching to normal world boot > >> E/TC:1 tzc_it_handler:19 TZC permission failure > >> E/TC:1 dump_fail_filter:417 Overrun violation on filter 0 > >> E/TC:1 dump_fail_filter:420 Permission violation on filter 0 > >> E/TC:1 dump_fail_filter:430 Violation @0xff000000, non-secure privileged > read, AXI ID 4a0 > >> E/TC:1 Panic > >> > >> > >> Besides the U-Boot patch I also have the kernel fixup for > >> gpu_reserved applied. > >> > >> Thanks, > >> Jan > >> > > > > Gentle ping, at least for a pointer where to report this best. > > > > As I received no reply, I debugged that further along the line of reservations. And > it quickly turned out that mainline is missing [1]. > With that patch applied and the gpu reservation change [2], the kernel can finally > boot when OP-TEE is present. > > Any reason why all this is only in a downstream repo? > > Jan > > [1] > https://github.com/STMicroelectronics/linux/commit/d17e72a1c58a2786d60d68852 > b710a7aae95b676 > [2] > https://github.com/STMicroelectronics/linux/commit/4707072246129cd68390e59b7 > c0dc3b878a6bf5c Sorry for the delay. The management of OP-TEE reserved memory was not stable in downstream and we are upstreaming only the final solution: 1/ OP-TEE node present only in U-Boot device tree and absent in kernel device tree 2/ the nodes is copied by U-Boot in kernel device tree (in lib/optee/optee.c::optee_copy_fdt_nodes() ) [1] will be never upstreamed and it will be reverted in next downstream release This patch avoid U-Boot copy to kernel device tree ( U-Boot don't update the existing op-tee nodes) [2] upstream is in progress => target v5.10 then U-Boot DT need to be aligned after But it shul be blocking for OP-TEE (it is not the root cause of the issue) I checked the OP-TEE config and node in U-Boot: the configuration are ok for DK1 and EV1 ./core/arch/arm/plat-stm32mp1/conf.mk:50:CFG_TZDRAM_START ?= 0xde000000 ./core/arch/arm/plat-stm32mp1/conf.mk:59:CFG_TZDRAM_START ?= 0xfe000000 reserved-memory { optee@de000000 { reg = <0xde000000 0x02000000>; no-map; }; }; reserved-memory { optee@fe000000 { reg = <0xfe000000 0x02000000>; no-map; }; }; Then I check copied node in kernel device tree (tested on EV1 board) on U-Boot master: / { serial-number = "004700223338511534383330"; #address-cells = <0x00000001>; #size-cells = <0x00000001>; model = "STMicroelectronics STM32MP157C eval daughter on eval mother"; compatible = "st,stm32mp157c-ev1", "st,stm32mp157c-ed1", "st,stm32mp157"; firmware { optee { method = "smc"; compatible = "linaro,optee-tz"; }; }; ..... reserved-memory { #address-cells = <0x00000001>; #size-cells = <0x00000001>; ranges; optee@fe000000 { no-map; reg = <0xfe000000 0x02000000>; }; .... The nodes for OP-TEE is correctly copied in kernel device tree. But it is not working on v2020.10 (the no-map property is missing) reserved-memory { #address-cells = <0x00000001>; #size-cells = <0x00000001>; ranges; optee@fe000000 { reg = <0xfe000000 0x02000000>; }; => this issue is corrected by the 2 commit in master branch - de51e96daf6b ("dtdec: optionnaly add property no-map to created reserved memory node") - 12c3caa6494 ("optee: add property no-map to secure reserved memory") Sorry again the delay of my answer, at the first reading the issue was linked for other OP-TEE issue (speculative access to OP-TEE reserved memory corrected by [3]) PS: in future, with FIT support in TF-A, the management of OP-TEE node change again: The OP-TEE nodes is absent in U-Boot and in kernel device tree. 1/ TF-A BL2 load 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 So only OP-TEE manage its node and we have no more alignment issue. Patrick [3) http://patchwork.ozlabs.org/project/uboot/list/?series=206296 > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick DELAUNAY Date: Tue, 13 Oct 2020 11:06:08 +0000 Subject: STM32MP1: Adding TF-A causes kernel errors In-Reply-To: <1e4c88dd-2a61-570f-718b-d47a2e0ba18a@siemens.com> References: <746e3c3b-7b2a-f815-a000-bcb2c31317cb@web.de> <6a493688-6c0f-6e8b-d072-88855236e677@st.com> <4ccf4dcc-a340-6c34-c5b4-ff06d79aa29d@web.de> <2aa485b5-ee8f-38e6-317e-513cd3be8a1e@siemens.com> <1e4c88dd-2a61-570f-718b-d47a2e0ba18a@siemens.com> Message-ID: <5edd1c1ddd154000b14e87246555bf3b@SFHDAG2NODE3.st.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Jan, > From: Jan Kiszka > Sent: mardi 13 octobre 2020 00:02 > > On 05.10.20 08:07, Jan Kiszka wrote: > > On 01.10.20 11:52, Jan Kiszka wrote: > >> On 30.09.20 11:51, Jan Kiszka wrote: > >>> [BCC'ed TF-A only, migrating to u-boot, including folks involved > >>> there] > >>> > >>> On 30.09.20 11:20, Yann GAUTIER wrote: > >>>> Hi Jan, > >>>> > >>>> After discussing with my colleagues, it seems there are 2 issues there. > >>>> One patch is missing in U-Boot: > >>>> http://patchwork.ozlabs.org/project/uboot/patch/20200605092244.1.I7 > >>>> 73bf523d9f4d1a6212483d030e34113b832a779 at changeid/ > >>>> > >>> > >>> I can confirm that this resolves the errors I've seen. > >>> > >> > >> Picking up again, this time for OP-TEE: > >> Do I need more patches, wherever, to get that one running as well? > >> > >> NOTICE: CPU: STM32MP157AAA Rev.B > >> NOTICE: Model: STMicroelectronics STM32MP157C eval daughter on eval > mother > >> NOTICE: Board: MB1263 Var1 Rev.C-01 > >> NOTICE: BL2: v2.3(): > >> NOTICE: BL2: Built : 10:11:55, Sep 30 2020 > >> NOTICE: BL2: Booting BL32 > >> I/TC: Early console on UART#4 > >> I/TC: > >> I/TC: Pager is enabled. Hashes: 2144 bytes > >> I/TC: Pager pool size: 100kB > >> I/TC: No non-secure external DT > >> I/TC: Embedded DTB found > >> I/TC: OP-TEE version: Unknown (gcc version 8.3.0 (Debian 8.3.0-2)) #2 > >> Thu Oct 1 06:53:58 UTC 2020 arm > >> I/TC: Primary CPU initializing > >> I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT > >> stm32mp157c-ev1.dts > >> I/TC: RCC is non-secure > >> I/TC: DTB enables console (non-secure) > >> I/TC: Primary CPU switching to normal world boot > >> > >> > >> U-Boot 2020.07 (Oct 01 2020 - 06:54:18 +0000) > >> > >> CPU: STM32MP157AAA Rev.B > >> Model: STMicroelectronics STM32MP157C eval daughter on eval mother > >> Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1) > >> Board: MB1263 Var1.0 Rev.C-01 > >> DRAM: 1 GiB > >> Clocks: > >> - MPU : 650 MHz > >> - MCU : 208.878 MHz > >> - AXI : 266.500 MHz > >> - PER : 24 MHz > >> - DDR : 533 MHz > >> NAND: 1024 MiB > >> MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1 > >> Loading Environment from EXT4... ** File not found /uboot.env ** > >> > >> ** Unable to read "/uboot.env" from mmc0:7 ** > >> In: serial > >> Out: serial > >> Err: serial > >> Net: eth0: ethernet at 5800a000 > >> Hit any key to stop autoboot: 0 > >> Boot over mmc0! > >> Saving Environment to EXT4... Unsupported feature metadata_csum found, not > writing. > >> > >> ** Unable to write "/uboot.env" from mmc0:7 ** Failed (1) switch to > >> partitions #0, OK > >> mmc0 is current device > >> Scanning mmc 0:7... > >> Found U-Boot script /boot/boot.scr > >> 562 bytes read in 26 ms (20.5 KiB/s) > >> ## Executing script at c4100000 > >> 57629 bytes read in 38 ms (1.4 MiB/s) > >> 9474560 bytes read in 429 ms (21.1 MiB/s) > >> 4410487 bytes read in 212 ms (19.8 MiB/s) Kernel image @ 0xc2000000 [ > >> 0x000000 - 0x909200 ] ## Flattened Device Tree blob at c4000000 > >> Booting using the fdt blob at 0xc4000000 > >> Loading Ramdisk to cfbcb000, end cffffc77 ... OK > >> Loading Device Tree to cfbb9000, end cfbca11c ... OK > >> OP-TEE: revision 3.10 > >> > >> Starting kernel ... > >> > >> I/TC: Secondary CI/TC: Secondary CPU 1 switching to normal world boot > >> E/TC:1 tzc_it_handler:19 TZC permission failure > >> E/TC:1 dump_fail_filter:417 Overrun violation on filter 0 > >> E/TC:1 dump_fail_filter:420 Permission violation on filter 0 > >> E/TC:1 dump_fail_filter:430 Violation @0xff000000, non-secure privileged > read, AXI ID 4a0 > >> E/TC:1 Panic > >> > >> > >> Besides the U-Boot patch I also have the kernel fixup for > >> gpu_reserved applied. > >> > >> Thanks, > >> Jan > >> > > > > Gentle ping, at least for a pointer where to report this best. > > > > As I received no reply, I debugged that further along the line of reservations. And > it quickly turned out that mainline is missing [1]. > With that patch applied and the gpu reservation change [2], the kernel can finally > boot when OP-TEE is present. > > Any reason why all this is only in a downstream repo? > > Jan > > [1] > https://github.com/STMicroelectronics/linux/commit/d17e72a1c58a2786d60d68852 > b710a7aae95b676 > [2] > https://github.com/STMicroelectronics/linux/commit/4707072246129cd68390e59b7 > c0dc3b878a6bf5c Sorry for the delay. The management of OP-TEE reserved memory was not stable in downstream and we are upstreaming only the final solution: 1/ OP-TEE node present only in U-Boot device tree and absent in kernel device tree 2/ the nodes is copied by U-Boot in kernel device tree (in lib/optee/optee.c::optee_copy_fdt_nodes() ) [1] will be never upstreamed and it will be reverted in next downstream release This patch avoid U-Boot copy to kernel device tree ( U-Boot don't update the existing op-tee nodes) [2] upstream is in progress => target v5.10 then U-Boot DT need to be aligned after But it shul be blocking for OP-TEE (it is not the root cause of the issue) I checked the OP-TEE config and node in U-Boot: the configuration are ok for DK1 and EV1 ./core/arch/arm/plat-stm32mp1/conf.mk:50:CFG_TZDRAM_START ?= 0xde000000 ./core/arch/arm/plat-stm32mp1/conf.mk:59:CFG_TZDRAM_START ?= 0xfe000000 reserved-memory { optee at de000000 { reg = <0xde000000 0x02000000>; no-map; }; }; reserved-memory { optee at fe000000 { reg = <0xfe000000 0x02000000>; no-map; }; }; Then I check copied node in kernel device tree (tested on EV1 board) on U-Boot master: / { serial-number = "004700223338511534383330"; #address-cells = <0x00000001>; #size-cells = <0x00000001>; model = "STMicroelectronics STM32MP157C eval daughter on eval mother"; compatible = "st,stm32mp157c-ev1", "st,stm32mp157c-ed1", "st,stm32mp157"; firmware { optee { method = "smc"; compatible = "linaro,optee-tz"; }; }; ..... reserved-memory { #address-cells = <0x00000001>; #size-cells = <0x00000001>; ranges; optee at fe000000 { no-map; reg = <0xfe000000 0x02000000>; }; .... The nodes for OP-TEE is correctly copied in kernel device tree. But it is not working on v2020.10 (the no-map property is missing) reserved-memory { #address-cells = <0x00000001>; #size-cells = <0x00000001>; ranges; optee at fe000000 { reg = <0xfe000000 0x02000000>; }; => this issue is corrected by the 2 commit in master branch - de51e96daf6b ("dtdec: optionnaly add property no-map to created reserved memory node") - 12c3caa6494 ("optee: add property no-map to secure reserved memory") Sorry again the delay of my answer, at the first reading the issue was linked for other OP-TEE issue (speculative access to OP-TEE reserved memory corrected by [3]) PS: in future, with FIT support in TF-A, the management of OP-TEE node change again: The OP-TEE nodes is absent in U-Boot and in kernel device tree. 1/ TF-A BL2 load 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 So only OP-TEE manage its node and we have no more alignment issue. Patrick [3) http://patchwork.ozlabs.org/project/uboot/list/?series=206296 > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux