Re: STM32MP1: Adding TF-A causes kernel errors
[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.I773bf523d9...
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@e8000000 {reg = <0xe8000000 0x8000000>;
gpu_reserved: gpu@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@0 {
enable-method = "psci"; compatible = "arm,cortex-a7"; clock-frequency = <0x26be3680>; device_type = "cpu";@@ -21,7 +28,6 @@ };
cpu@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@fe000000 {reg = <0xfe000000 0x2000000>;};mcuram2@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...
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.I773bf523d9...
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@e8000000 {reg = <0xe8000000 0x8000000>;
gpu_reserved: gpu@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.
[...]
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.I773bf523d9...
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@e8000000 {reg = <0xe8000000 0x8000000>;
gpu_reserved: gpu@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
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.I773bf523d9...
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.
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.I773bf523d9...
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
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.I773bf523d9...
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
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.I773bf523d9...
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.
Thanks, Jan
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.I773bf523d9...
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... [2] https://github.com/STMicroelectronics/linux/commit/4707072246129cd68390e59b7...
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
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
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
participants (6)
-
Etienne Carriere -
Jan Kiszka -
Jan Kiszka -
Marek Vasut -
Patrick DELAUNAY -
Tom Rini