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...