Re: STM32MP1: Adding TF-A causes kernel errors
On 13.10.20 16:26, Jan Kiszka wrote: > On 13.10.20 13:06, Patrick DELAUNAY wrote: >> Hi Jan, >> >>> From: Jan Kiszka >>> Sent: mardi 13 octobre 2020 00:02 >>> >>> On 05.10.20 08:07, Jan Kiszka wrote: On 01.10.20 11:52, Jan Kiszka wrote: > On 30.09.20 11:51, Jan Kiszka wrote: >> [BCC'ed TF-A only, migrating to u-boot, including folks involved >> there] >> >> On 30.09.20 11:20, Yann GAUTIER wrote: >>> Hi Jan, >>> >>> After discussing with my colleagues, it seems there are 2 issues there. >>> One patch is missing in U-Boot: >>> http://patchwork.ozlabs.org/project/uboot/patch/20200605092244.1.I7 >>> 73bf523d9f4d1a6212483d030e34113b832a779@changeid/ >>> >> >> I can confirm that this resolves the errors I've seen. >> > > Picking up again, this time for OP-TEE: > Do I need more patches, wherever, to get that one running as well? > > NOTICE: CPU: STM32MP157AAA Rev.B > NOTICE: Model: STMicroelectronics STM32MP157C eval daughter on eval >>> mother > NOTICE: Board: MB1263 Var1 Rev.C-01 > NOTICE: BL2: v2.3(): > NOTICE: BL2: Built : 10:11:55, Sep 30 2020 > NOTICE: BL2: Booting BL32 > I/TC: Early console on UART#4 > I/TC: > I/TC: Pager is enabled. Hashes: 2144 bytes > I/TC: Pager pool size: 100kB > I/TC: No non-secure external DT > I/TC: Embedded DTB found > I/TC: OP-TEE version: Unknown (gcc version 8.3.0 (Debian 8.3.0-2)) #2 > Thu Oct 1 06:53:58 UTC 2020 arm > I/TC: Primary CPU initializing > I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT > stm32mp157c-ev1.dts > I/TC: RCC is non-secure > I/TC: DTB enables console (non-secure) > I/TC: Primary CPU switching to normal world boot > > > U-Boot 2020.07 (Oct 01 2020 - 06:54:18 +) > > 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 c410 > 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 @ 0xc200 [ > 0x00 - 0x909200 ] ## Flattened Device Tree blob at c400 >Booting using the fdt blob at 0xc400 >Loading Ramdisk to cfbcb000, end cc77 ... 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 @0xff00, 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
Re: STM32MP1: Adding TF-A causes kernel errors
On 13.10.20 13:06, Patrick DELAUNAY wrote: > Hi Jan, > >> From: Jan Kiszka >> Sent: mardi 13 octobre 2020 00:02 >> >> On 05.10.20 08:07, Jan Kiszka wrote: >>> On 01.10.20 11:52, Jan Kiszka wrote: On 30.09.20 11:51, Jan Kiszka wrote: > [BCC'ed TF-A only, migrating to u-boot, including folks involved > there] > > On 30.09.20 11:20, Yann GAUTIER wrote: >> Hi Jan, >> >> After discussing with my colleagues, it seems there are 2 issues there. >> One patch is missing in U-Boot: >> http://patchwork.ozlabs.org/project/uboot/patch/20200605092244.1.I7 >> 73bf523d9f4d1a6212483d030e34113b832a779@changeid/ >> > > I can confirm that this resolves the errors I've seen. > Picking up again, this time for OP-TEE: Do I need more patches, wherever, to get that one running as well? NOTICE: CPU: STM32MP157AAA Rev.B NOTICE: Model: STMicroelectronics STM32MP157C eval daughter on eval >> mother NOTICE: Board: MB1263 Var1 Rev.C-01 NOTICE: BL2: v2.3(): NOTICE: BL2: Built : 10:11:55, Sep 30 2020 NOTICE: BL2: Booting BL32 I/TC: Early console on UART#4 I/TC: I/TC: Pager is enabled. Hashes: 2144 bytes I/TC: Pager pool size: 100kB I/TC: No non-secure external DT I/TC: Embedded DTB found I/TC: OP-TEE version: Unknown (gcc version 8.3.0 (Debian 8.3.0-2)) #2 Thu Oct 1 06:53:58 UTC 2020 arm I/TC: Primary CPU initializing I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT stm32mp157c-ev1.dts I/TC: RCC is non-secure I/TC: DTB enables console (non-secure) I/TC: Primary CPU switching to normal world boot U-Boot 2020.07 (Oct 01 2020 - 06:54:18 +) 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 c410 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 @ 0xc200 [ 0x00 - 0x909200 ] ## Flattened Device Tree blob at c400 Booting using the fdt blob at 0xc400 Loading Ramdisk to cfbcb000, end cc77 ... 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 @0xff00, 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 =>
RE: STM32MP1: Adding TF-A causes kernel errors
Hi Jan, > From: Jan Kiszka > Sent: mardi 13 octobre 2020 00:02 > > On 05.10.20 08:07, Jan Kiszka wrote: > > On 01.10.20 11:52, Jan Kiszka wrote: > >> On 30.09.20 11:51, Jan Kiszka wrote: > >>> [BCC'ed TF-A only, migrating to u-boot, including folks involved > >>> there] > >>> > >>> On 30.09.20 11:20, Yann GAUTIER wrote: > Hi Jan, > > After discussing with my colleagues, it seems there are 2 issues there. > One patch is missing in U-Boot: > http://patchwork.ozlabs.org/project/uboot/patch/20200605092244.1.I7 > 73bf523d9f4d1a6212483d030e34113b832a779@changeid/ > > >>> > >>> I can confirm that this resolves the errors I've seen. > >>> > >> > >> Picking up again, this time for OP-TEE: > >> Do I need more patches, wherever, to get that one running as well? > >> > >> NOTICE: CPU: STM32MP157AAA Rev.B > >> NOTICE: Model: STMicroelectronics STM32MP157C eval daughter on eval > mother > >> NOTICE: Board: MB1263 Var1 Rev.C-01 > >> NOTICE: BL2: v2.3(): > >> NOTICE: BL2: Built : 10:11:55, Sep 30 2020 > >> NOTICE: BL2: Booting BL32 > >> I/TC: Early console on UART#4 > >> I/TC: > >> I/TC: Pager is enabled. Hashes: 2144 bytes > >> I/TC: Pager pool size: 100kB > >> I/TC: No non-secure external DT > >> I/TC: Embedded DTB found > >> I/TC: OP-TEE version: Unknown (gcc version 8.3.0 (Debian 8.3.0-2)) #2 > >> Thu Oct 1 06:53:58 UTC 2020 arm > >> I/TC: Primary CPU initializing > >> I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT > >> stm32mp157c-ev1.dts > >> I/TC: RCC is non-secure > >> I/TC: DTB enables console (non-secure) > >> I/TC: Primary CPU switching to normal world boot > >> > >> > >> U-Boot 2020.07 (Oct 01 2020 - 06:54:18 +) > >> > >> 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 c410 > >> 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 @ 0xc200 [ > >> 0x00 - 0x909200 ] ## Flattened Device Tree blob at c400 > >>Booting using the fdt blob at 0xc400 > >>Loading Ramdisk to cfbcb000, end cc77 ... 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 @0xff00, 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
Re: STM32MP1: Adding TF-A causes kernel errors
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 +) >> >> 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... >>
Re: STM32MP1: Adding TF-A causes kernel errors
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 +) > > 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 c410 > 57629 bytes read in 38 ms
Re: STM32MP1: Adding TF-A causes kernel errors
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 +) 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 c410 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 @ 0xc200 [ 0x00 - 0x909200 ] ## Flattened Device Tree blob at c400 Booting using the fdt blob at 0xc400 Loading Ramdisk to cfbcb000, end cc77 ... 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 @0xff00, 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
Re: STM32MP1: Adding TF-A causes kernel errors
Hi Yann, Tom and all, On Wed, 30 Sep 2020 at 15:06, Tom Rini 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@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
Re: STM32MP1: Adding TF-A causes kernel errors
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@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 signature.asc Description: PGP signature
Re: STM32MP1: Adding TF-A causes kernel errors
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@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@e800 {
>>> - reg = <0xe800 0x800>;
>>> + gpu_reserved: gpu@f600 {
>>> + reg = <0xf600 0x800>;
>>> 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
Re: STM32MP1: Adding TF-A causes kernel errors
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@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@e800 {
>> -reg = <0xe800 0x800>;
>> +gpu_reserved: gpu@f600 {
>> +reg = <0xf600 0x800>;
>> 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.
[...]
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.I773bf523d9f4d1a6212483d030e34113b832a779@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@e800 {
> - reg = <0xe800 0x800>;
> + gpu_reserved: gpu@f600 {
> + reg = <0xf600 0x800>;
> 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.00] 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.00] 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:
> index:0x1 pfn:0xfa000
> [0.047249] flags: 0x8000() CMA
> [0.047273] raw: 8000 e7f29004 e7f49004 0001 000b
> ff7f
> [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] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [0.047384] [] (show_stack) from []
> (dump_stack+0xc8/0xdc)
> [0.047408] [] (dump_stack) from []
> (bad_page+0xdc/0x10c)
> [0.047426] [] (bad_page) from []
> (__free_pages_ok+0x2e8/0x36c)
> [0.047447] []
