* STM32MP1: Adding TF-A causes kernel errors [not found] ` <6a493688-6c0f-6e8b-d072-88855236e677@st.com> @ 2020-09-30 9:51 ` Jan Kiszka 2020-09-30 10:03 ` Marek Vasut 2020-10-01 9:52 ` Jan Kiszka 0 siblings, 2 replies; 15+ messages in thread From: Jan Kiszka @ 2020-09-30 9:51 UTC (permalink / raw) To: u-boot [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.I773bf523d9f4d1a6212483d030e34113b832a779 at changeid/ > I can confirm that this resolves the errors I've seen. Will that patch still hit 2020.10? > And it shows an issue in kernel, with GPU and CMA regions. > A correction in kernel should also be done: > > diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts > b/arch/arm/boot/dts/stm32mp157c-ed1.dts > index ca109dc18..685dd61c0 100644 > --- a/arch/arm/boot/dts/stm32mp157c-ed1.dts > +++ b/arch/arm/boot/dts/stm32mp157c-ed1.dts > @@ -66,8 +66,8 @@ > no-map; > }; > > - gpu_reserved: gpu at e8000000 { > - reg = <0xe8000000 0x8000000>; > + gpu_reserved: gpu at f6000000 { > + reg = <0xf6000000 0x8000000>; > no-map; > }; > }; > There might be more issues: [ 3.428914] stm32_rtc 5c004000.rtc: IRQ index 1 not found [ 3.432892] stm32_rtc 5c004000.rtc: alarm can't wake up the system: -6 [ 3.440290] stm32_rtc 5c004000.rtc: registered as rtc0 [ 3.444560] stm32_rtc 5c004000.rtc: setting system clock to 2000-01-01T00:00:07 UTC (946684807) [ 3.453530] stm32_rtc 5c004000.rtc: Date/Time must be initialized [ 3.459333] stm32_rtc 5c004000.rtc: registered rev:1.2 [ 3.465993] i2c /dev entries driver [ 3.490226] stm32f7-i2c 40013000.i2c: can't request DMA tx channel [ 3.494951] stm32f7-i2c 40013000.i2c: can't use DMA [ 3.504213] stm32f7-i2c 40013000.i2c: STM32F7 I2C-0 bus adapter [ 3.529032] stm32f7-i2c 40015000.i2c: can't request DMA tx channel [ 3.533779] stm32f7-i2c 40015000.i2c: can't use DMA [ 3.539356] stm32f7-i2c 40015000.i2c: STM32F7 I2C-1 bus adapter [ 3.567561] stm32f7-i2c 5c002000.i2c: can't request DMA tx channel [ 3.572312] stm32f7-i2c 5c002000.i2c: can't use DMA But those would be a kernel topic, I suppose. Thanks for the quick resolution, Jan > > Regards, > Yann > > On 9/30/20 11:18 AM, Jan Kiszka wrote: >> On 30.09.20 10:40, Yann GAUTIER wrote: >>> Hi Jan, >>> >>> The optee nodes should be removed by U-Boot. >>> Check arch/arm/mach-stm32mp/fdt.c file and function >>> stm32_fdt_disable_optee(). >> >> CONFIG_OPTEE is obviously enabled in stm32mp15_trusted_defconfig, and >> there must be something found by tee_find_device()... >> >> FWIW, I've now also tested TF-A and U-Boot HEAD, just to avoid missing >> some fix, but there is no change. >> >>> >>> I'll check with my colleagues in charge of U-Boot and kernel and get >>> back to you. >>> >> >> TIA! >> Jan >> >>> >>> Regards, >>> Yann >>> >>> On 9/30/20 9:05 AM, Jan Kiszka wrote: >>>> On 29.09.20 23:42, Jan Kiszka wrote: >>>>> Hi Yann, >>>>> >>>>> not sure if TF-A is the one to blame, but it's the variable that >>>>> triggers the following on the STM32MP15x eval board for me. I think I'm >>>>> following tfa/docs/plat/stm32mp1.rst and >>>>> u-boot/doc/board/st/stm32mp1.rst correctly. >>>>> >>>>> Working: >>>>> - U-Boot 2020.07, stm32mp15_basic_defconfig >>>>> - Linux 5.9-rc7 (or 5.4.x), defconfig >>>>> >>>>> [ 0.000000] Memory: 815540K/917500K available (13312K kernel code, 1800K rwdata, 5452K rodata, 2048K init, 407K bss, 36424K reserved, 65536K cma-reserved, 196604K highmem) >>>>> >>>>> Failing: >>>>> - TF-A 2.3, PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \ >>>>> AARCH32_SP=sp_min STM32MP_SDMMC=1 STM32MP_EMMC=1 STM32MP_RAW_NAND=1 \ >>>>> STM32MP_SPI_NAND=1 STM32MP_SPI_NOR=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb >>>>> - U-Boot 2020.07, stm32mp15_trusted_defconfig >>>>> - Linux as above >>>>> >>>>> [ 0.000000] Memory: 881076K/917500K available (13312K kernel code, 1800K rwdata, 5452K rodata, 2048K init, 407K bss, 4294938184K reserved, 65536K cma-reserved, 262140K highmem) >>>>> >>>>> which causes issues like >>>>> >>>>> [ 0.047215] BUG: Bad page state in process swapper/0 pfn:fa000 >>>>> [ 0.047236] page:(ptrval) refcount:0 mapcount:-128 mapping:00000000 index:0x1 pfn:0xfa000 >>>>> [ 0.047249] flags: 0x80000000() CMA >>>>> [ 0.047273] raw: 80000000 e7f29004 e7f49004 00000000 00000001 0000000b ffffff7f 00000000 >>>>> [ 0.047281] page dumped because: nonzero mapcount >>>>> [ 0.047287] Modules linked in: >>>>> [ 0.047305] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc7 #1 >>>>> [ 0.047314] Hardware name: STM32 (Device Tree Support) >>>>> [ 0.047358] [<c0311708>] (unwind_backtrace) from [<c030b88c>] (show_stack+0x10/0x14) >>>>> [ 0.047384] [<c030b88c>] (show_stack) from [<c0718a40>] (dump_stack+0xc8/0xdc) >>>>> [ 0.047408] [<c0718a40>] (dump_stack) from [<c047b3c8>] (bad_page+0xdc/0x10c) >>>>> [ 0.047426] [<c047b3c8>] (bad_page) from [<c047c060>] (__free_pages_ok+0x2e8/0x36c) >>>>> [ 0.047447] [<c047c060>] (__free_pages_ok) from [<c1623a80>] (init_cma_reserved_pageblock+0x58/0x68) >>>>> [ 0.047469] [<c1623a80>] (init_cma_reserved_pageblock) from [<c16266c8>] (cma_init_reserved_areas+0x170/0x1c8) >>>>> [ 0.047491] [<c16266c8>] (cma_init_reserved_areas) from [<c0301ef8>] (do_one_initcall+0x54/0x22c) >>>>> [ 0.047513] [<c0301ef8>] (do_one_initcall) from [<c160102c>] (kernel_init_freeable+0x188/0x1ec) >>>>> [ 0.047537] [<c160102c>] (kernel_init_freeable) from [<c0f4a340>] (kernel_init+0x8/0x118) >>>>> [ 0.047559] [<c0f4a340>] (kernel_init) from [<c03001a8>] (ret_from_fork+0x14/0x2c) >>>>> [ 0.047570] Exception stack(0xe68b7fb0 to 0xe68b7ff8) >>>>> [ 0.047584] 7fa0: 00000000 00000000 00000000 00000000 >>>>> [ 0.047600] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >>>>> [ 0.047614] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 >>>>> [ 0.047624] Disabling lock debugging due to kernel taint >>>>> >>>>> Still, the system boots, and I can login. >>>>> >>>>> That reserved value the kernel finds is obviously off. Does it come from >>>>> TF-A, is U-Boot causing this in the presence of TF-A, or is the kernel >>>>> itself getting it wrong? Or am I missing some switch that is not in the >>>>> kernel defconfig? >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>> >>>> Looking at the dtb diff (no-tfa -> with-tfa, based on >>>> /sys/firmware/fdt), I'm starting to believe it's a kernel issues, >>>> possibly some signed 32-bit -> 64-bit expansion: >>>> >>>> --- /dev/fd/63 2020-09-30 08:39:43.870749258 +0200 >>>> +++ /dev/fd/62 2020-09-30 08:39:43.874749249 +0200 >>>> @@ -1,6 +1,6 @@ >>>> /dts-v1/; >>>> >>>> -/memreserve/ 0x00000000cfbcb000 0x00000000004349c5; >>>> +/memreserve/ 0x00000000cfb5c000 0x00000000004a3faa; >>>> / { >>>> serial-number = "003100453338511534383330"; >>>> #address-cells = <0x01>; >>>> @@ -8,12 +8,19 @@ >>>> model = "STMicroelectronics STM32MP157C eval daughter on eval mother"; >>>> compatible = "st,stm32mp157c-ev1\0st,stm32mp157c-ed1\0st,stm32mp157"; >>>> >>>> + firmware { >>>> + >>>> + optee { >>>> + method = "smc"; >>>> + compatible = "linaro,optee-tz"; >>>> + }; >>>> + }; >>>> + >>>> cpus { >>>> #address-cells = <0x01>; >>>> #size-cells = <0x00>; >>>> >>>> cpu at 0 { >>>> - enable-method = "psci"; >>>> compatible = "arm,cortex-a7"; >>>> clock-frequency = <0x26be3680>; >>>> device_type = "cpu"; >>>> @@ -21,7 +28,6 @@ >>>> }; >>>> >>>> cpu at 1 { >>>> - enable-method = "psci"; >>>> compatible = "arm,cortex-a7"; >>>> clock-frequency = <0x26be3680>; >>>> device_type = "cpu"; >>>> @@ -30,8 +36,7 @@ >>>> }; >>>> >>>> psci { >>>> - status = "okay"; >>>> - compatible = "arm,psci-1.0\0arm,psci-0.2"; >>>> + compatible = "arm,psci-1.0"; >>>> method = "smc"; >>>> }; >>>> >>>> @@ -3804,9 +3809,9 @@ >>>> }; >>>> >>>> chosen { >>>> - linux,initrd-end = <0xcffff9c5>; >>>> - linux,initrd-start = <0xcfbcb000>; >>>> - bootargs = "root=PARTUUID=0a553417-d224-4c81-b052-0679fb761cf5 rootwait rw console=ttySTM0,115200"; >>>> + linux,initrd-end = <0xcfffffaa>; >>>> + linux,initrd-start = <0xcfb5c000>; >>>> + bootargs = "root=PARTUUID=a9089592-b0fe-4c14-8b27-e1b398043c47 rootwait rw console=ttySTM0,115200"; >>>> stdout-path = "serial0:115200n8"; >>>> }; >>>> >>>> @@ -3820,6 +3825,10 @@ >>>> #size-cells = <0x01>; >>>> ranges; >>>> >>>> + optee at fe000000 { >>>> + reg = <0xfe000000 0x2000000>; >>>> + }; >>>> + >>>> mcuram2 at 10000000 { >>>> compatible = "shared-dma-pool"; >>>> reg = <0x10000000 0x40000>; >>>> >>>> >>>> OTOH, I'm wondering what that optee entry is about - I have none >>>> configured... >>>> >>>> Anyway, if you can confirm it's a kernel thing, I'm happy to move this >>>> to another list. >>>> >>>> Thanks, >>>> Jan >>>> >>>> PS: This was supposed to be quick (which worked exceptionally well for >>>> the first, "untrusted" part, thanks to everything-is-upstream), just to >>>> demonstrate custom TF-A packing for Debian via the image generator >>>> Isar... ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors 2020-09-30 9:51 ` STM32MP1: Adding TF-A causes kernel errors Jan Kiszka @ 2020-09-30 10:03 ` Marek Vasut 2020-09-30 10:05 ` Jan Kiszka 2020-09-30 13:06 ` Tom Rini 2020-10-01 9:52 ` Jan Kiszka 1 sibling, 2 replies; 15+ messages in thread From: Marek Vasut @ 2020-09-30 10:03 UTC (permalink / raw) To: u-boot On 9/30/20 11:51 AM, 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.I773bf523d9f4d1a6212483d030e34113b832a779 at changeid/ >> > > I can confirm that this resolves the errors I've seen. > > Will that patch still hit 2020.10? Is that patch a bugfix or a feature ? OpTee seems like a feature. Since it has no Fixes: tag, it seems like a feature? >> And it shows an issue in kernel, with GPU and CMA regions. >> A correction in kernel should also be done: >> >> diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts >> b/arch/arm/boot/dts/stm32mp157c-ed1.dts >> index ca109dc18..685dd61c0 100644 >> --- a/arch/arm/boot/dts/stm32mp157c-ed1.dts >> +++ b/arch/arm/boot/dts/stm32mp157c-ed1.dts >> @@ -66,8 +66,8 @@ >> no-map; >> }; >> >> - gpu_reserved: gpu at e8000000 { >> - reg = <0xe8000000 0x8000000>; >> + gpu_reserved: gpu at f6000000 { >> + reg = <0xf6000000 0x8000000>; >> no-map; >> }; >> }; >> Why do you even need reserved memory for GPU ? Etnaviv to my knowledge doesn't use this ? > There might be more issues: > > [ 3.428914] stm32_rtc 5c004000.rtc: IRQ index 1 not found > [ 3.432892] stm32_rtc 5c004000.rtc: alarm can't wake up the system: -6 > [ 3.440290] stm32_rtc 5c004000.rtc: registered as rtc0 > [ 3.444560] stm32_rtc 5c004000.rtc: setting system clock to 2000-01-01T00:00:07 UTC (946684807) > [ 3.453530] stm32_rtc 5c004000.rtc: Date/Time must be initialized > [ 3.459333] stm32_rtc 5c004000.rtc: registered rev:1.2 > [ 3.465993] i2c /dev entries driver > [ 3.490226] stm32f7-i2c 40013000.i2c: can't request DMA tx channel > [ 3.494951] stm32f7-i2c 40013000.i2c: can't use DMA > [ 3.504213] stm32f7-i2c 40013000.i2c: STM32F7 I2C-0 bus adapter > [ 3.529032] stm32f7-i2c 40015000.i2c: can't request DMA tx channel > [ 3.533779] stm32f7-i2c 40015000.i2c: can't use DMA > [ 3.539356] stm32f7-i2c 40015000.i2c: STM32F7 I2C-1 bus adapter > [ 3.567561] stm32f7-i2c 5c002000.i2c: can't request DMA tx channel > [ 3.572312] stm32f7-i2c 5c002000.i2c: can't use DMA > > But those would be a kernel topic, I suppose. Which kernel version is that ? Mainline on MP1 works just fine, with etnaviv too. Note that the DMA warnings might be bogus if you don't enable DMA for i2c in DT, which is often the case, as i2c doesn't really need DMA and would only waste the DMA channels. [...] ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors 2020-09-30 10:03 ` Marek Vasut @ 2020-09-30 10:05 ` Jan Kiszka 2020-09-30 13:06 ` Tom Rini 1 sibling, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2020-09-30 10:05 UTC (permalink / raw) To: u-boot On 30.09.20 12:03, Marek Vasut wrote: > On 9/30/20 11:51 AM, 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.I773bf523d9f4d1a6212483d030e34113b832a779 at changeid/ >>> >> >> I can confirm that this resolves the errors I've seen. >> >> Will that patch still hit 2020.10? > > Is that patch a bugfix or a feature ? OpTee seems like a feature. > Since it has no Fixes: tag, it seems like a feature? > >>> And it shows an issue in kernel, with GPU and CMA regions. >>> A correction in kernel should also be done: >>> >>> diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts >>> b/arch/arm/boot/dts/stm32mp157c-ed1.dts >>> index ca109dc18..685dd61c0 100644 >>> --- a/arch/arm/boot/dts/stm32mp157c-ed1.dts >>> +++ b/arch/arm/boot/dts/stm32mp157c-ed1.dts >>> @@ -66,8 +66,8 @@ >>> no-map; >>> }; >>> >>> - gpu_reserved: gpu at e8000000 { >>> - reg = <0xe8000000 0x8000000>; >>> + gpu_reserved: gpu at f6000000 { >>> + reg = <0xf6000000 0x8000000>; >>> no-map; >>> }; >>> }; >>> > > Why do you even need reserved memory for GPU ? Etnaviv to my knowledge > doesn't use this ? > >> There might be more issues: >> >> [ 3.428914] stm32_rtc 5c004000.rtc: IRQ index 1 not found >> [ 3.432892] stm32_rtc 5c004000.rtc: alarm can't wake up the system: -6 >> [ 3.440290] stm32_rtc 5c004000.rtc: registered as rtc0 >> [ 3.444560] stm32_rtc 5c004000.rtc: setting system clock to 2000-01-01T00:00:07 UTC (946684807) >> [ 3.453530] stm32_rtc 5c004000.rtc: Date/Time must be initialized >> [ 3.459333] stm32_rtc 5c004000.rtc: registered rev:1.2 >> [ 3.465993] i2c /dev entries driver >> [ 3.490226] stm32f7-i2c 40013000.i2c: can't request DMA tx channel >> [ 3.494951] stm32f7-i2c 40013000.i2c: can't use DMA >> [ 3.504213] stm32f7-i2c 40013000.i2c: STM32F7 I2C-0 bus adapter >> [ 3.529032] stm32f7-i2c 40015000.i2c: can't request DMA tx channel >> [ 3.533779] stm32f7-i2c 40015000.i2c: can't use DMA >> [ 3.539356] stm32f7-i2c 40015000.i2c: STM32F7 I2C-1 bus adapter >> [ 3.567561] stm32f7-i2c 5c002000.i2c: can't request DMA tx channel >> [ 3.572312] stm32f7-i2c 5c002000.i2c: can't use DMA >> >> But those would be a kernel topic, I suppose. > > Which kernel version is that ? > That was from a 5.9-rc7 boot. > Mainline on MP1 works just fine, with etnaviv too. > Note that the DMA warnings might be bogus if you don't enable DMA for > i2c in DT, which is often the case, as i2c doesn't really need DMA and > would only waste the DMA channels. I'm just testing "all defconfig" for all components here. Jan ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors 2020-09-30 10:03 ` Marek Vasut 2020-09-30 10:05 ` Jan Kiszka @ 2020-09-30 13:06 ` Tom Rini 2020-09-30 15:20 ` Etienne Carriere 1 sibling, 1 reply; 15+ messages in thread From: Tom Rini @ 2020-09-30 13:06 UTC (permalink / raw) To: u-boot On Wed, Sep 30, 2020 at 12:03:06PM +0200, Marek Vasut wrote: > On 9/30/20 11:51 AM, 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.I773bf523d9f4d1a6212483d030e34113b832a779 at changeid/ > >> > > > > I can confirm that this resolves the errors I've seen. > > > > Will that patch still hit 2020.10? > > Is that patch a bugfix or a feature ? OpTee seems like a feature. > Since it has no Fixes: tag, it seems like a feature? That linked commit could/should be a Fixes tag it looks like at first read. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200930/8f21a1d2/attachment.sig> ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors 2020-09-30 13:06 ` Tom Rini @ 2020-09-30 15:20 ` Etienne Carriere 0 siblings, 0 replies; 15+ messages in thread From: Etienne Carriere @ 2020-09-30 15:20 UTC (permalink / raw) To: u-boot Hi Yann, Tom and all, On Wed, 30 Sep 2020 at 15:06, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Sep 30, 2020 at 12:03:06PM +0200, Marek Vasut wrote: > > On 9/30/20 11:51 AM, 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.I773bf523d9f4d1a6212483d030e34113b832a779 at changeid/ > > >> > > > > > > I can confirm that this resolves the errors I've seen. > > > > > > Will that patch still hit 2020.10? > > > > Is that patch a bugfix or a feature ? OpTee seems like a feature. > > Since it has no Fixes: tag, it seems like a feature? > > That linked commit could/should be a Fixes tag it looks like at first > read. > Yes, I agree with you. This is definitely a fixup. Regards, Etienne > -- > Tom ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors 2020-09-30 9:51 ` STM32MP1: Adding TF-A causes kernel errors Jan Kiszka 2020-09-30 10:03 ` Marek Vasut @ 2020-10-01 9:52 ` Jan Kiszka 2020-10-05 6:07 ` Jan Kiszka 1 sibling, 1 reply; 15+ messages in thread From: Jan Kiszka @ 2020-10-01 9:52 UTC (permalink / raw) To: u-boot 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.I773bf523d9f4d1a6212483d030e34113b832a779 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors 2020-10-01 9:52 ` Jan Kiszka @ 2020-10-05 6:07 ` Jan Kiszka 2020-10-12 22:02 ` Jan Kiszka 0 siblings, 1 reply; 15+ messages in thread From: Jan Kiszka @ 2020-10-05 6:07 UTC (permalink / raw) To: u-boot 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.I773bf523d9f4d1a6212483d030e34113b832a779 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. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: STM32MP1: Adding TF-A causes kernel errors 2020-10-05 6:07 ` Jan Kiszka @ 2020-10-12 22:02 ` Jan Kiszka 0 siblings, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2020-10-12 22:02 UTC (permalink / raw) To: Yann GAUTIER, Etienne Carriere Cc: U-Boot Mailing List, linux-arm-kernel, Patrick Delaunay 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.I773bf523d9f4d1a6212483d030e34113b832a779@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/d17e72a1c58a2786d60d68852b710a7aae95b676 [2] https://github.com/STMicroelectronics/linux/commit/4707072246129cd68390e59b7c0dc3b878a6bf5c -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors @ 2020-10-12 22:02 ` Jan Kiszka 0 siblings, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2020-10-12 22:02 UTC (permalink / raw) To: u-boot 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.I773bf523d9f4d1a6212483d030e34113b832a779 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/d17e72a1c58a2786d60d68852b710a7aae95b676 [2] https://github.com/STMicroelectronics/linux/commit/4707072246129cd68390e59b7c0dc3b878a6bf5c -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: STM32MP1: Adding TF-A causes kernel errors 2020-10-12 22:02 ` Jan Kiszka @ 2020-10-13 11:06 ` Patrick DELAUNAY -1 siblings, 0 replies; 15+ messages in thread From: Patrick DELAUNAY @ 2020-10-13 11:06 UTC (permalink / raw) To: Jan Kiszka, Etienne Carriere Cc: Alexandre TORGUE, Yann GAUTIER, Patrice CHOTARD, U-Boot Mailing List, Christophe PRIOUZEAU, linux-arm-kernel Hi Jan, > From: Jan Kiszka <jan.kiszka@siemens.com> > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors @ 2020-10-13 11:06 ` Patrick DELAUNAY 0 siblings, 0 replies; 15+ messages in thread From: Patrick DELAUNAY @ 2020-10-13 11:06 UTC (permalink / raw) To: u-boot Hi Jan, > From: Jan Kiszka <jan.kiszka@siemens.com> > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: STM32MP1: Adding TF-A causes kernel errors 2020-10-13 11:06 ` Patrick DELAUNAY @ 2020-10-13 14:26 ` Jan Kiszka -1 siblings, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2020-10-13 14:26 UTC (permalink / raw) To: Patrick DELAUNAY, Etienne Carriere Cc: Alexandre TORGUE, Yann GAUTIER, Patrice CHOTARD, U-Boot Mailing List, Christophe PRIOUZEAU, linux-arm-kernel On 13.10.20 13:06, Patrick DELAUNAY wrote: > Hi Jan, > >> From: Jan Kiszka <jan.kiszka@siemens.com> >> 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") Which repo are you referring to? U-Boot? I do not find those commits yet. > > 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]) > Never mind, and thanks for the detailed explanation! > 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. That would be better, indeed. Jan PS: I've already sent out Debian/Isar integration for TF-A and OP-TEE using the STM32MP15x as demo/test case (https://groups.google.com/forum/#!topic/isar-users/ijj6mdBfb2w). I'll see how I can improve that queue to reflect what you wrote. > > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors @ 2020-10-13 14:26 ` Jan Kiszka 0 siblings, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2020-10-13 14:26 UTC (permalink / raw) To: u-boot On 13.10.20 13:06, Patrick DELAUNAY wrote: > Hi Jan, > >> From: Jan Kiszka <jan.kiszka@siemens.com> >> 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") Which repo are you referring to? U-Boot? I do not find those commits yet. > > 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]) > Never mind, and thanks for the detailed explanation! > 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. That would be better, indeed. Jan PS: I've already sent out Debian/Isar integration for TF-A and OP-TEE using the STM32MP15x as demo/test case (https://groups.google.com/forum/#!topic/isar-users/ijj6mdBfb2w). I'll see how I can improve that queue to reflect what you wrote. > > Patrick > > [3) http://patchwork.ozlabs.org/project/uboot/list/?series=206296 > > >> -- >> Siemens AG, T RDA IOT >> Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: STM32MP1: Adding TF-A causes kernel errors 2020-10-13 14:26 ` Jan Kiszka @ 2020-10-15 9:45 ` Jan Kiszka -1 siblings, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2020-10-15 9:45 UTC (permalink / raw) To: Patrick DELAUNAY, Etienne Carriere Cc: Alexandre TORGUE, Yann GAUTIER, Patrice CHOTARD, U-Boot Mailing List, Christophe PRIOUZEAU, linux-arm-kernel On 13.10.20 16:26, Jan Kiszka wrote: > On 13.10.20 13:06, Patrick DELAUNAY wrote: >> Hi Jan, >> >>> From: Jan Kiszka <jan.kiszka@siemens.com> >>> 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") > > Which repo are you referring to? U-Boot? I do not find those commits yet. > Found them in U-Boot master now and applied them, dropping the kernel changes. I can confirm that those to fix the issue, just updated my queue (https://groups.google.com/forum/#!msg/isar-users/ijj6mdBfb2w/rBzD2il8BwAJ). Thanks again, Jan >> >> 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]) >> > > Never mind, and thanks for the detailed explanation! > >> 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. > > That would be better, indeed. > > Jan > > PS: I've already sent out Debian/Isar integration for TF-A and OP-TEE > using the STM32MP15x as demo/test case > (https://groups.google.com/forum/#!topic/isar-users/ijj6mdBfb2w). I'll > see how I can improve that queue to reflect what you wrote. > >> >> Patrick >> >> [3) http://patchwork.ozlabs.org/project/uboot/list/?series=206296 >> >> >>> -- >>> Siemens AG, T RDA IOT >>> Corporate Competence Center Embedded Linux -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* STM32MP1: Adding TF-A causes kernel errors @ 2020-10-15 9:45 ` Jan Kiszka 0 siblings, 0 replies; 15+ messages in thread From: Jan Kiszka @ 2020-10-15 9:45 UTC (permalink / raw) To: u-boot On 13.10.20 16:26, Jan Kiszka wrote: > On 13.10.20 13:06, Patrick DELAUNAY wrote: >> Hi Jan, >> >>> From: Jan Kiszka <jan.kiszka@siemens.com> >>> 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") > > Which repo are you referring to? U-Boot? I do not find those commits yet. > Found them in U-Boot master now and applied them, dropping the kernel changes. I can confirm that those to fix the issue, just updated my queue (https://groups.google.com/forum/#!msg/isar-users/ijj6mdBfb2w/rBzD2il8BwAJ). Thanks again, Jan >> >> 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]) >> > > Never mind, and thanks for the detailed explanation! > >> 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. > > That would be better, indeed. > > Jan > > PS: I've already sent out Debian/Isar integration for TF-A and OP-TEE > using the STM32MP15x as demo/test case > (https://groups.google.com/forum/#!topic/isar-users/ijj6mdBfb2w). I'll > see how I can improve that queue to reflect what you wrote. > >> >> Patrick >> >> [3) http://patchwork.ozlabs.org/project/uboot/list/?series=206296 >> >> >>> -- >>> Siemens AG, T RDA IOT >>> Corporate Competence Center Embedded Linux -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-10-15 9:46 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <d643d22d-58c5-1e02-d5be-cb26d3902c37@web.de>
[not found] ` <fcf2dbe2-c5d8-7042-5c59-ab9bcb1e612d@web.de>
[not found] ` <e5533f9b-bf88-526d-5594-a719d928f01c@st.com>
[not found] ` <746e3c3b-7b2a-f815-a000-bcb2c31317cb@web.de>
[not found] ` <6a493688-6c0f-6e8b-d072-88855236e677@st.com>
2020-09-30 9:51 ` STM32MP1: Adding TF-A causes kernel errors Jan Kiszka
2020-09-30 10:03 ` Marek Vasut
2020-09-30 10:05 ` Jan Kiszka
2020-09-30 13:06 ` Tom Rini
2020-09-30 15:20 ` Etienne Carriere
2020-10-01 9:52 ` Jan Kiszka
2020-10-05 6:07 ` Jan Kiszka
2020-10-12 22:02 ` Jan Kiszka
2020-10-12 22:02 ` Jan Kiszka
2020-10-13 11:06 ` Patrick DELAUNAY
2020-10-13 11:06 ` Patrick DELAUNAY
2020-10-13 14:26 ` Jan Kiszka
2020-10-13 14:26 ` Jan Kiszka
2020-10-15 9:45 ` Jan Kiszka
2020-10-15 9:45 ` Jan Kiszka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.