Re: [PATCH 6/6] ARM: dts: stm32: Add DHCOR based DRC Compact board

2022-06-14 Thread Patrice CHOTARD
HI Marek

On 6/13/22 11:55, Marek Vasut wrote:
> Add DT for DH DRC Compact unit, which is a universal controller device.
> The system has two ethernet ports, one CAN, RS485 and RS232, USB, uSD
> card slot, eMMC and SDIO Wi-Fi.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
>  arch/arm/dts/Makefile |   3 +-
>  .../arm/dts/stm32mp153c-dhcor-drc-compact.dts |  30 ++
>  .../stm32mp15xx-dhcor-drc-compact-u-boot.dtsi | 120 +++
>  .../arm/dts/stm32mp15xx-dhcor-drc-compact.dts |  16 +
>  .../dts/stm32mp15xx-dhcor-drc-compact.dtsi| 326 ++
>  .../dh_stm32mp1/u-boot-dhcor.its  |  15 +
>  configs/stm32mp15_dhcor_basic_defconfig   |   1 +
>  7 files changed, 510 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts
>  create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-drc-compact.dts
>  create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-drc-compact.dtsi
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0a2713c06a3..8a314210da6 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1172,7 +1172,8 @@ dtb-$(CONFIG_STM32MP15x) += \
>   stm32mp15xx-dhcom-drc02.dtb \
>   stm32mp15xx-dhcom-pdk2.dtb \
>   stm32mp15xx-dhcom-picoitx.dtb \
> - stm32mp15xx-dhcor-avenger96.dtb
> + stm32mp15xx-dhcor-avenger96.dtb \
> + stm32mp15xx-dhcor-drc-compact.dtb
>  
>  dtb-$(CONFIG_SOC_K3_AM6) += \
>   k3-am654-base-board.dtb \
> diff --git a/arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts 
> b/arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts
> new file mode 100644
> index 000..c8b9818499e
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright (C) 2022 Marek Vasut 
> + *
> + * DHCOR STM32MP1 variant:
> + * DHCR-STM32MP153C-C065-R051-V33-SPI-I-01LG
> + * DHCOR PCB number: 586-100 or newer
> + * DRC Compact PCB number: 627-100 or newer
> + */
> +
> +/dts-v1/;
> +
> +#include "stm32mp153.dtsi"
> +#include "stm32mp15xc.dtsi"
> +#include "stm32mp15xx-dhcor-som.dtsi"
> +#include "stm32mp15xx-dhcor-drc-compact.dtsi"
> +
> +/ {
> + model = "DH electronics STM32MP153C DHCOR DRC Compact";
> + compatible = "dh,stm32mp153c-dhcor-drc-compact",
> +  "dh,stm32mp153c-dhcor-som",
> +  "st,stm32mp153";
> +};
> +
> +&m_can1 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&m_can1_pins_c>;
> + pinctrl-1 = <&m_can1_sleep_pins_c>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi 
> b/arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi
> new file mode 100644
> index 000..407fed56167
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2022 Marek Vasut 
> + */
> +
> +#include "stm32mp15xx-dhcor-u-boot.dtsi"
> +
> +/delete-node/ &ksz8851;
> +
> +/ {
> + aliases {
> + mmc0 = &sdmmc1;
> + mmc1 = &sdmmc2;
> + usb0 = &usbotg_hs;
> + ethernet1 = &ks8851;
> + };
> +
> + config {
> + dh,board-coding-gpios = <&gpioh 9 0>, <&gpioh 8 0>, <&gpioh 3 
> 0>;
> + };
> +
> + /* This is actually on FMC2, but we do not have bus driver for that */
> + ks8851: ks8851mll@6400 {
> + compatible = "micrel,ks8851-mll";
> + reg = <0x6400 0x2>;
> + };
> +};
> +
> +ðernet0 {
> + phy-reset-gpios = <&gpioz 2 GPIO_ACTIVE_LOW>;
> +
> + mdio0 {
> + ethernet-phy@7 {
> + reset-gpios = <&gpioz 2 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <1000>;
> + };
> + };
> +};
> +
> +&pinctrl {
> + /* These should bound to FMC2 bus driver, but we do not have one */
> + pinctrl-0 = <&fmc_pins_b>;
> + pinctrl-1 = <&fmc_sleep_pins_b>;
> + pinctrl-names = "default", "sleep";
> +};
> +
> +&sdmmc1 {
> + u-boot,dm-spl;
> + st,use-ckin;
> + st,cmd-gpios = <&gpiod 2 0>;
> + st,ck-gpios = <&gpioc 12 0>;
> + st,ckin-gpios = <&gpioe 4 0>;
> +};
> +
> +&sdmmc1_b4_pins_a {
> + u-boot,dm-spl;
> + pins1 {
> + u-boot,dm-spl;
> + };
> + pins2 {
> + u-boot,dm-spl;
> + };
> +};
> +
> +&sdmmc1_dir_pins_b {
> + u-boot,dm-spl;
> + pins1 {
> + u-boot,dm-spl;
> + };
> + pins2 {
> + u-boot,dm-spl;
> + };
> +};
> +
> +&sdmmc2 {
> + u-boot,dm-spl;
> +};
> +
> +&sdmmc2_b4_pins_a {
> + u-boot,dm-spl;
> + pins1 {
> + u-boot,dm-spl;
> + };
> + pins2 {
> + u-boot,dm-spl;
> + };
> +};

[PATCH RFC v3 11/11] ci: world_build: test: Add requirements.txt

2022-06-14 Thread Neha Malcom Francis
To avoid ModuleNotFoundErrors during World Build in CI tests, add
installation of test/py/requirements.txt to .azure-pipelines.yml

Signed-off-by: Neha Malcom Francis 
---
 .azure-pipelines.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index ad540ea635..0fd57f59f4 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -551,6 +551,7 @@ stages:
   EOF
   cat << "EOF" >> build.sh
   if [[ "${BUILDMAN}" != "" ]]; then
+  pip install -r test/py/requirements.txt
   ret=0;
   tools/buildman/buildman -o /tmp -P -E -W ${BUILDMAN} ${OVERRIDE} 
|| ret=$?;
   if [[ $ret -ne 0 ]]; then
-- 
2.17.1



[PATCH RFC v3 09/11] ti: dtsi: j721e: Use binman to package sysfw.itb and tiboot3.bin

2022-06-14 Thread Neha Malcom Francis
By providing entries in the binman node of the device tree, binman will
be able to find and package board config binary artifacts generated by
TIBoardConfig with sysfw.bin and generate the final image sysfw.itb.

k3-j721e-r5-binman.dtsi has been introduced for R5 specific binman node.
It can be then be include by files that require it like
k3-j721e-r5-common-proc-board-u-boot.dtsi.

Signed-off-by: Tarun Sahu 
[n-fran...@ti.com: prepared patch for upstreaming]
Signed-off-by: Neha Malcom Francis 
---
 arch/arm/dts/k3-j721e-r5-binman.dtsi  | 88 +++
 .../k3-j721e-r5-common-proc-board-u-boot.dtsi |  1 +
 board/ti/j721e/Kconfig|  1 +
 3 files changed, 90 insertions(+)
 create mode 100644 arch/arm/dts/k3-j721e-r5-binman.dtsi

diff --git a/arch/arm/dts/k3-j721e-r5-binman.dtsi 
b/arch/arm/dts/k3-j721e-r5-binman.dtsi
new file mode 100644
index 00..e3aeefb08f
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-r5-binman.dtsi
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+
+#include 
+
+/ {
+   binman: binman {
+   multiple-images;
+   };
+};
+
+&binman {
+   tiboot3 {
+   filename = "tiboot3.bin";
+   ti-x509-cert {
+   content = <&image1>;
+   core = <16>;
+   load = ;
+   };
+   image1: u-boot-spl {
+   no-expanded;
+   };
+   };
+   binary {
+   filename = "sysfw.bin";
+   ti-x509-cert {
+   content = <&image2>;
+   core = <0>;
+   load = <0x004>;
+   };
+   image2: ti-sysfw {
+   };
+   };
+   itb {
+   filename = "sysfw.itb";
+   fit {
+   description = "SYSFW and Config Fragments";
+   #address-cells = <1>;
+   images {
+   sysfw.bin {
+   description = "sysfw";
+   type = "firmware";
+   arch = "arm";
+   compression = "none";
+   blob {
+   filename = "sysfw.bin";
+   };
+   };
+   board-cfg.bin {
+   description = "board-cfg";
+   type = "firmware";
+   arch = "arm";
+   compression = "none";
+   blob-ext {
+   filename = "board-cfg.bin";
+   };
+   };
+   pm-cfg.bin {
+   description = "pm-cfg";
+   type = "firmware";
+   arch = "arm";
+   compression = "none";
+   blob-ext {
+   filename = "pm-cfg.bin";
+   };
+   };
+   rm-cfg.bin {
+   description = "rm-cfg";
+   type = "firmware";
+   arch = "arm";
+   compression = "none";
+   blob-ext {
+   filename = "rm-cfg.bin";
+   };
+   };
+   sec-cfg.bin {
+   description = "sec-cfg";
+   type = "firmware";
+   arch = "arm";
+   compression = "none";
+   blob-ext {
+   filename = "sec-cfg.bin";
+   };
+   };
+   };
+   };
+   };
+};
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
index 48c6ddf672..75ec722e89 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
@@ -4,6 +4,7 @@
  */
 
 #include "k3-j721e-common-proc-board-u-boot.dtsi"
+#include "k3-j721e-r5-binman.dtsi"
 
 / {
chosen {
diff --git a/board/ti/j72

[PATCH RFC v3 10/11] ti: dtsi: j721e: Use binman to package tispl.bin

2022-06-14 Thread Neha Malcom Francis
tispl.bin must be packaged (with ATF, OPTEE, DM and A72 SPL) for J721E.
Binman picks up and packages entries according to the
description given in the device tree.

k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman
node. It is included by k3-j721e-common-proc-board-u-boot.dtsi

Signed-off-by: Neha Malcom Francis 
---
 arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 +++
 .../k3-j721e-common-proc-board-u-boot.dtsi|  1 +
 board/ti/j721e/Kconfig|  1 +
 3 files changed, 88 insertions(+)
 create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi

diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi 
b/arch/arm/dts/k3-j721e-a72-binman.dtsi
new file mode 100644
index 00..beb3424bb9
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+
+#include 
+
+#ifdef CONFIG_ARM64
+/ {
+   binman: binman {
+   multiple-images;
+   };
+};
+
+&binman {
+   tispl {
+   filename = "tispl.bin";
+   fit {
+   description = "FIT IMAGE";
+   #address-cells = <1>;
+   images {
+   atf {
+   description = "ARM Trusted Firmware";
+   type = "firmware";
+   arch = "arm64";
+   compression = "none";
+   os = "arm-trusted-firmware";
+   load = ;
+   entry = ;
+   atf-bl31 {
+   };
+   };
+   tee {
+   description = "OPTEE";
+   type = "tee";
+   arch = "arm64";
+   compression = "none";
+   os = "tee";
+   load = <0x9e80>;
+   entry = <0x9e80>;
+   tee-os {
+   };
+   };
+   dm {
+   description = "DM binary";
+   type = "firmware";
+   arch = "arm32";
+   compression = "none";
+   os = "DM";
+   load = <0x8900>;
+   entry = <0x8900>;
+   ti-dm {
+   };
+   };
+   spl {
+   description = "SPL (64-bit)";
+   type = "standalone";
+   os = "U-Boot";
+   arch = "arm64";
+   compression = "none";
+   load = ;
+   entry = ;
+   u-boot-spl-nodtb {
+   };
+   };
+   k3-j721e-common-proc-board.dtb {
+   description = 
"k3-j721e-common-proc-board";
+   type = "flat_dt";
+   arch = "arm";
+   compression = "none";
+   blob-ext {
+   filename = 
"spl/dts/k3-j721e-common-proc-board.dtb";
+   };
+   };
+   };
+   configurations {
+   default = "conf";
+   conf {
+   description = 
"k3-j721e-common-proc-board";
+   firmware = "atf";
+   loadables = "tee", "dm", "spl";
+   fdt = "k3-j721e-common-proc-board.dtb";
+   };
+   };
+   };
+   };
+};
+#endif
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 677a72d2a2..6490d71f7e 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -4,6 +4,7 @@
  */
 

[PATCH RFC v3 08/11] ti: j721e: Exclude makefile tispl.bin target for J721E

2022-06-14 Thread Neha Malcom Francis
tispl.bin is to be packaged (with ATF, OPTEE, DM and A72 SPL) using
binman. The tispl.bin target from the makefile is no longer needed for
J721E.

Signed-off-by: Neha Malcom Francis 
---
 arch/arm/mach-k3/config.mk | 5 +
 scripts/Makefile.spl   | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index d706d17788..dd5e42d9df 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -74,6 +74,7 @@ ifeq ($(CONFIG_SOC_K3_J721E),)
 export DM := /dev/null
 endif
 
+ifndef CONFIG_TARGET_J721E_A72_EVM
 ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
 SPL_ITS := u-boot-spl-k3_HS.its
 $(SPL_ITS): export IS_HS=1
@@ -98,9 +99,11 @@ cmd_k3_mkits = \
 $(SPL_ITS): FORCE
$(call cmd,k3_mkits)
 endif
+endif
 
 else
 
+ifndef CONFIG_TARGET_J721E_A72_EVM
 ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
 INPUTS-y   += u-boot.img_HS
 else
@@ -108,4 +111,6 @@ INPUTS-y+= u-boot.img
 endif
 endif
 
+endif
+
 include $(srctree)/arch/arm/mach-k3/config_secure.mk
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index f047d4e094..6104cb8587 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -591,6 +591,8 @@ $(obj)/$(SPL_BIN).multidtb.fit.lzo: 
$(obj)/$(SPL_BIN).multidtb.fit
@lzop -f9 $< > $@
 
 ifdef CONFIG_ARCH_K3
+ifndef CONFIG_TARGET_J721E_A72_EVM
 tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE
$(call if_changed,mkfitimage)
 endif
+endif
-- 
2.17.1



[PATCH RFC v3 06/11] ti: sysfw: Add support for packaging sysfw.itb

2022-06-14 Thread Neha Malcom Francis
For devices that require sysfw.itb, board config binary artifacts must
be populated in the R5 output directory. These can be used by binman to
package sysfw.itb.

config.mk for mach-k3 updated to generate the required binaries using
tibcfg_gen.py.

Signed-off-by: Neha Malcom Francis 
---
 arch/arm/mach-k3/config.mk | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index da458bcfb2..ed605adf39 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -28,6 +28,24 @@ else
 KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
 endif
 
+# Board config binary artifacts necessary for packaging of tiboot3.bin
+# and sysfw.itb by binman, currently for general purpose devices and
+# devices that require sysfw.itb in ROM boot image. Currently set up
+# for J721E
+ifeq ($(CONFIG_TARGET_J721E_R5_EVM),y)
+ifneq ($(CONFIG_TI_SECURE_DEVICE),y)
+
+CONFIG_YAML = $(srctree)/board/ti/$(BOARD)/config.yaml
+SCHEMA_YAML = $(srctree)/board/ti/common/schema.yaml
+board-cfg.bin pm-cfg.bin rm-cfg.bin sec-cfg.bin:
+   $(PYTHON3) $(srctree)/tools/tibcfg_gen.py -c $(CONFIG_YAML) -s 
$(SCHEMA_YAML) -o $(O)
+INPUTS-y   += board-cfg.bin
+INPUTS-y   += pm-cfg.bin
+INPUTS-y   += rm-cfg.bin
+INPUTS-y   += sec-cfg.bin
+endif
+endif
+
 # tiboot3.bin is mandated by ROM and ROM only supports R5 boot.
 # So restrict tiboot3.bin creation for CPU_V7R.
 ifdef CONFIG_CPU_V7R
-- 
2.17.1



[PATCH RFC v3 07/11] ti: j721e: Exclude makefile tiboot3.bin target for J721E

2022-06-14 Thread Neha Malcom Francis
Intention of patch is to move the signing and packaging of tiboot3.bin
image for J721E to binman. So patch excludes tiboot3.bin target for
J721E.

The functionality of tools/k3_gen_x509_cert.sh has been replicated in
binman with the etype x509_cert. This can be used for J721E by binman.

Signed-off-by: Neha Malcom Francis 
---
 arch/arm/mach-k3/config.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index ed605adf39..d706d17788 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -46,6 +46,7 @@ INPUTS-y  += sec-cfg.bin
 endif
 endif
 
+ifneq ($(CONFIG_TARGET_J721E_R5_EVM), y)
 # tiboot3.bin is mandated by ROM and ROM only supports R5 boot.
 # So restrict tiboot3.bin creation for CPU_V7R.
 ifdef CONFIG_CPU_V7R
@@ -65,6 +66,8 @@ tiboot3.bin: image_check FORCE
 INPUTS-y   += tiboot3.bin
 endif
 
+endif
+
 ifdef CONFIG_ARM64
 
 ifeq ($(CONFIG_SOC_K3_J721E),)
-- 
2.17.1



[PATCH RFC v3 05/11] ti: etype: x509: Add etype for x509 certificate for K3 devices

2022-06-14 Thread Neha Malcom Francis
K3 devices requires x509 certificate to be added as header of bootloader
binaries that allows ROM to validate the integrity of the image. Etype
that generates a TI x509 certificate is added.

Currently this etype is scaled for J721E. For J721E, tiboot3.bin
requires the x509 certificate binary to be prepended to the R5 SPL.

Signed-off-by: Neha Malcom Francis 
---
 test/py/requirements.txt|   1 +
 tools/binman/entries.rst|  15 ++
 tools/binman/etype/ti_x509_cert.py  | 241 
 tools/binman/ftest.py   |   6 +
 tools/binman/test/232_x509_cert.dts |  18 +++
 5 files changed, 281 insertions(+)
 create mode 100644 tools/binman/etype/ti_x509_cert.py
 create mode 100644 tools/binman/test/232_x509_cert.dts

diff --git a/test/py/requirements.txt b/test/py/requirements.txt
index a91ba64563..add264bdaf 100644
--- a/test/py/requirements.txt
+++ b/test/py/requirements.txt
@@ -11,6 +11,7 @@ packaging==19.2
 pbr==5.4.3
 pluggy==0.13.0
 py==1.10.0
+pycryptodome==3.14.1
 pycryptodomex==3.9.8
 pyelftools==0.27
 pygit2==0.28.2
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index b6915ef12e..e7757b3e06 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1890,6 +1890,21 @@ and kernel are genuine.
 
 
 
+Entry: ti-x509-cert: Texas Instruments x509 certificate for K3 devices
+
+
+Properties / Entry arguments:
+- content: Phandle of binary to sign
+- output: Name of the final output file
+- key_file: File with key inside it. If not provided, script generates 
RSA degenerate key
+- core: Target core ID on which image would be running
+- load: Target load address of the binary in hex
+
+Output files:
+- certificate.bin: Signed certificate binary
+
+
+
 Entry: x86-reset16: x86 16-bit reset code for U-Boot
 
 
diff --git a/tools/binman/etype/ti_x509_cert.py 
b/tools/binman/etype/ti_x509_cert.py
new file mode 100644
index 00..b79946c0b9
--- /dev/null
+++ b/tools/binman/etype/ti_x509_cert.py
@@ -0,0 +1,241 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2018 Google, Inc
+# Written by Simon Glass 
+#
+
+# Support for a TI x509 certificate for signing K3 devices
+
+from subprocess import Popen, PIPE
+from sys import stderr, stdout
+import os
+import tempfile
+
+from Crypto.PublicKey import RSA
+
+from binman.etype.collection import Entry_collection
+from dtoc import fdt_util
+from patman import tools
+
+
+class Entry_ti_x509_cert(Entry_collection):
+"""An entry which contains an x509 certificate binary signed with 1024 bit 
RSA key
+
+Properties / Entry arguments:
+- content: Phandle of binary to generate signature for
+- key_file: File with key inside it. If not provided, script generates 
RSA degenrate key
+- core: Target core ID on which image would be running
+- load: Target load address of the binary in hex
+
+Output files:
+- certificate.bin: Signed certificate binary"""
+
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node)
+self.key_file = fdt_util.GetString(self._node, 'key-file', "")
+self.core = fdt_util.GetInt(self._node, 'core', 0)
+self.load_addr = fdt_util.GetInt(self._node, 'load', 0x41c0)
+self.cert = fdt_util.GetString(self._node, 'cert', 'certificate.bin')
+
+# temporary directory for intermediate files
+self.outdir = tempfile.mkdtemp(prefix='binman.x509.')
+
+def ReadNode(self):
+super().ReadNode()
+if self.key_file == "":
+self.key_int_file = os.path.join(self.outdir, 'eckey.pem')
+self.GenerateDegenKey()
+else:
+self.key_int_file = self.key_file
+
+def ObtainContents(self):
+self.image = self.GetContents(False)
+if self.image is None:
+return False
+self.image_file = os.path.join(self.outdir, 'x509.image')
+with open(self.image_file, 'wb') as f:
+f.write(self.image)
+self.cert_data = self._TICreateCertificateLegacy()
+self.SetContents(self.cert_data)
+return True
+
+def ProcessContents(self):
+# The blob may have changed due to WriteSymbols()
+return super().ProcessContentsUpdate(self.cert_data)
+
+def _TICreateCertificateLegacy(self):
+"""Create certificate for legacy boot flow"""
+
+sha_val = self.GetShaVal(self.image_file)
+bin_size = self.GetFileSize(self.image_file)
+addr = "%08x" % self.load_addr
+if self.core == 16:
+self.cert_type = 1
+else:
+self.cert_type = 2
+self.debug_type = 0
+self.bootcore_opts = 0
+
+self.GenerateTemplate()
+self.GenerateCertificate(bin_size, sha_val, addr)
+
+return tools.read_file(self.cert_file)

[PATCH RFC v3 04/11] ti: etype: dm: Add entry type for TI DM

2022-06-14 Thread Neha Malcom Francis
K3 devices introduces the concept of centralized power, resource and
security management to System Firmware. This is to overcome challenges
by the traditional approach that implements system control functions on
each of the processing units.

The software interface for System Firmware is split into TIFS and DM. DM
(Device Manager) is responsible for resource and power management from
secure and non-secure hosts. This additional binary is necessary for
specific platforms' ROM boot images and is to be packaged into tispl.bin

Add an entry for DM. The entry can be used for the packaging of
tispl.bin by binman along with ATF and TEE.

Signed-off-by: Neha Malcom Francis 
---
 Makefile|  1 +
 tools/binman/entries.rst| 10 ++
 tools/binman/etype/ti_dm.py | 23 +++
 tools/binman/ftest.py   |  7 +++
 tools/binman/test/225_ti_dm.dts | 13 +
 5 files changed, 54 insertions(+)
 create mode 100644 tools/binman/etype/ti_dm.py
 create mode 100644 tools/binman/test/225_ti_dm.dts

diff --git a/Makefile b/Makefile
index d20d264c53..9b29e8e6a2 100644
--- a/Makefile
+++ b/Makefile
@@ -1342,6 +1342,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
$(BINMAN_DEBUG),-D) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
+   -a ti-dm-path=${DM} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 9fc5c48c35..b6915ef12e 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1214,6 +1214,16 @@ devices.
 
 
 
+Entry: ti-dm: Texas Instruments Device Manager (DM) blob
+-
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically dm.bin
+
+This entry holds the device manager responsible for resource and power 
management in K3 devices.
+
+
+
 Entry: section: Entry that contains other entries
 -
 
diff --git a/tools/binman/etype/ti_dm.py b/tools/binman/etype/ti_dm.py
new file mode 100644
index 00..4203fff36e
--- /dev/null
+++ b/tools/binman/etype/ti_dm.py
@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+# Entry type for TI Device Manager
+
+import os
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+
+class Entry_ti_dm(Entry_blob_named_by_arg):
+"""Entry containing a Texas Instruments Device Manager (DM)
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically dm.bin
+
+This entry holds the device manager responsible for resource and power 
management
+in K3 devices.
+"""
+
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'ti-dm')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 671d083c54..3709b68297 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -85,6 +85,7 @@ FSP_S_DATA= b'fsp_s'
 FSP_T_DATA= b'fsp_t'
 ATF_BL31_DATA = b'bl31'
 TEE_OS_DATA   = b'this is some tee OS data'
+TI_DM_DATA= b'tidmtidm'
 ATF_BL2U_DATA = b'bl2u'
 OPENSBI_DATA  = b'opensbi'
 TI_SYSFW_DATA = b'sysfw'
@@ -194,6 +195,7 @@ class TestFunctional(unittest.TestCase):
 TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
 TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
 TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
+TestFunctional._MakeInputFile('dm.bin', TI_DM_DATA)
 TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
 TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
 TestFunctional._MakeInputFile('sysfw.bin', TI_SYSFW_DATA)
@@ -5307,6 +5309,11 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 data = self._DoReadFile('222_tee_os.dts')
 self.assertEqual(TEE_OS_DATA, data[:len(TEE_OS_DATA)])
 
+def testPackTiDm(self):
+"""Test that an image with a TI DM binary can be created"""
+data = self._DoReadFile('225_ti_dm.dts')
+self.assertEqual(TI_DM_DATA, data[:len(TI_DM_DATA)])
+
 def testFitFdtOper(self):
 """Check handling of a specified FIT operation"""
 entry_args = {
diff --git a/tools/binman/test/225_ti_dm.dts b/tools/binman/test/225_ti_dm.dts
new file mode 100644
index 00..3ab754131e
--- /dev/null
+++ b/tools/binman/test/225_ti_dm.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   binman {
+  

[PATCH RFC v3 03/11] ti: etype: sysfw: Add entry type for sysfw

2022-06-14 Thread Neha Malcom Francis
For K3 devices that require a sysfw image, add entry for SYSFW. It can
contain system firmware image that can be packaged into sysfw.itb by
binman.

Signed-off-by: Tarun Sahu 
[n-fran...@ti.com: added tests for addition of etype]
Signed-off-by: Neha Malcom Francis 
---
 Makefile   |  1 +
 tools/binman/entries.rst   | 11 +++
 tools/binman/etype/ti_sysfw.py | 28 
 tools/binman/ftest.py  |  7 +++
 tools/binman/test/232_ti_sysfw.dts | 13 +
 5 files changed, 60 insertions(+)
 create mode 100644 tools/binman/etype/ti_sysfw.py
 create mode 100644 tools/binman/test/232_ti_sysfw.dts

diff --git a/Makefile b/Makefile
index 61927f8918..d20d264c53 100644
--- a/Makefile
+++ b/Makefile
@@ -1345,6 +1345,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
$(BINMAN_DEBUG),-D) \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
+   -a ti-sysfw-path=$(SYSFW) \
-a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
-a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index ae4305c99e..9fc5c48c35 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1203,6 +1203,17 @@ This entry holds firmware for an external 
platform-specific coprocessor.
 
 
 
+Entry: ti-sysfw: Texas Instruments System Firmware (SYSFW) blob
+
+
+Properties / Entry arguments:
+- ti-sysfw-path: Filename of file to read into the entry, typically 
sysfw.bin
+
+This entry contains system firmware necessary for booting of K3 architecture
+devices.
+
+
+
 Entry: section: Entry that contains other entries
 -
 
diff --git a/tools/binman/etype/ti_sysfw.py b/tools/binman/etype/ti_sysfw.py
new file mode 100644
index 00..5b5b307030
--- /dev/null
+++ b/tools/binman/etype/ti_sysfw.py
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+# Entry type module for TI SYSFW binary blob
+#
+
+import os
+import struct
+import sys
+import zlib
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+from dtoc import fdt_util
+from patman import tools
+
+
+class Entry_ti_sysfw(Entry_blob_named_by_arg):
+"""Entry containing Texas Instruments System Firmware (SYSFW) blob
+
+Properties / Entry arguments:
+- ti-sysfw-path: Filename of file to read into the entry, typically 
sysfw.bin
+
+This entry contains system firmware necessary for booting of K3 
architecture devices.
+"""
+
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'ti-sysfw')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index b5cf549703..671d083c54 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -87,6 +87,7 @@ ATF_BL31_DATA = b'bl31'
 TEE_OS_DATA   = b'this is some tee OS data'
 ATF_BL2U_DATA = b'bl2u'
 OPENSBI_DATA  = b'opensbi'
+TI_SYSFW_DATA = b'sysfw'
 SCP_DATA  = b'scp'
 TEST_FDT1_DATA= b'fdt1'
 TEST_FDT2_DATA= b'test-fdt2'
@@ -195,6 +196,7 @@ class TestFunctional(unittest.TestCase):
 TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
 TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
 TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
+TestFunctional._MakeInputFile('sysfw.bin', TI_SYSFW_DATA)
 TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
 
 # Add a few .dtb files for testing
@@ -5529,6 +5531,11 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 """Test an image with a pre-load header with an invalid key"""
 with self.assertRaises(ValueError) as e:
 data = self._DoReadFile('231_pre_load_invalid_key.dts')
+
+def testPackTiSysfw(self):
+"""Test that an image with a SYSFW binary can be created"""
+data = self._DoReadFile('232_ti_sysfw.dts')
+self.assertEqual(TI_SYSFW_DATA, data[:len(TI_SYSFW_DATA)])
 
 def _CheckSafeUniqueNames(self, *images):
 """Check all entries of given images for unsafe unique names"""
diff --git a/tools/binman/test/232_ti_sysfw.dts 
b/tools/binman/test/232_ti_sysfw.dts
new file mode 100644
index 00..9e66cbe77b
--- /dev/null
+++ b/tools/binman/test/232_ti_sysfw.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   binman {
+   ti-sysfw {
+   filename = "sysfw.bin";
+   };
+   };
+};
-- 
2.17.1



[PATCH RFC v3 02/11] ti: tools: config: Add board config class to generate config binaries

2022-06-14 Thread Neha Malcom Francis
For validating config files and generating binary config artifacts, here
board specific config class is added.

Add function cfgBinaryGen() in tibcfg_gen.py. It uses TIBoardConfig
class to load given schema and config files in YAML, validate them and
generate binaries.

Signed-off-by: Tarun Sahu 
[n-fran...@ti.com: prepared patch for upstreaming]
Signed-off-by: Neha Malcom Francis 
---
 test/py/requirements.txt |   1 +
 tools/tibcfg_gen.py  | 114 +++
 2 files changed, 115 insertions(+)
 create mode 100644 tools/tibcfg_gen.py

diff --git a/test/py/requirements.txt b/test/py/requirements.txt
index 33c5c0bbc4..a91ba64563 100644
--- a/test/py/requirements.txt
+++ b/test/py/requirements.txt
@@ -4,6 +4,7 @@ coverage==4.5.4
 extras==1.0.0
 fixtures==3.0.0
 importlib-metadata==0.23
+jsonschema==4.0.0
 linecache2==1.0.0
 more-itertools==7.2.0
 packaging==19.2
diff --git a/tools/tibcfg_gen.py b/tools/tibcfg_gen.py
new file mode 100644
index 00..e5fa2690c8
--- /dev/null
+++ b/tools/tibcfg_gen.py
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+# TI Board Configuration Class for Schema Validation and Binary Generation
+#
+
+import os
+import getopt
+import sys
+
+import yaml
+
+from jsonschema import validate
+
+
+class TIBoardConfig:
+
+""" Texas Instruments Board Configuration File"""
+
+def __init__(self, file, schema, data_rules=""):
+"""Load a YAML configuration file and YAML schema
+
+Validation of the config file against the schema is also done."""
+with open(file, 'r') as f:
+self.file_yaml = yaml.safe_load(f)
+with open(schema, 'r') as sch:
+self.schema_yaml = yaml.safe_load(sch)
+self.data_rules = data_rules
+try:
+validate(self.file_yaml, self.schema_yaml)
+except Exception as e:
+print(e)
+
+def _convert_to_byte_chunk(self, val, data_type):
+"""Convert value into byte array"""
+size = 0
+if(data_type == "#/definitions/u8"):
+size = 1
+elif(data_type == "#/definitions/u16"):
+size = 2
+elif(data_type == "#/definitions/u32"):
+size = 4
+else:
+raise Exception("Data type not present in definitions")
+if type(val) == int:
+br = val.to_bytes(size, byteorder="little")
+return br
+
+def _compile_yaml(self, schema_yaml, file_yaml):
+"""Convert YAML file into byte array based on YAML schema"""
+br = bytearray()
+for key in file_yaml.keys():
+node = file_yaml[key]
+node_schema = schema_yaml['properties'][key]
+node_type = node_schema.get('type')
+if not 'type' in node_schema:
+br += self._convert_to_byte_chunk(node,
+  node_schema.get('$ref'))
+elif node_type == 'object':
+br += self._compile_yaml(node_schema, node)
+elif node_type == 'array':
+for item in node:
+if not isinstance(item, dict):
+br += self._convert_to_byte_chunk(
+item, 
schema_yaml['properties'][key]['items']["$ref"])
+else:
+br += self._compile_yaml(node_schema.get('items'), 
item)
+return br
+
+def generate_binaries(self, out_path=""):
+"""Generate config binary artifacts from the loaded YAML configuration 
file"""
+if not os.path.isdir(out_path):
+os.mkdir(out_path)
+for key in self.file_yaml.keys():
+node = self.file_yaml[key]
+node_schema = self.schema_yaml['properties'][key]
+br = self._compile_yaml(node_schema, node)
+path = os.path.join(out_path, key + ".bin")
+with open(path, 'wb') as cfg:
+cfg.write(br)
+
+def delete_binaries(self, out_path=""):
+"""Delete generated binaries"""
+if os.path.isdir(out_path):
+for key in self.file_yaml.keys():
+path = os.path.join(out_path, key + ".bin")
+if os.path.isfile(path):
+os.remove(path)
+
+
+def cfgBinaryGen():
+"""Generate config binaries from YAML config file and YAML schema
+Arguments:
+- config_yaml: board config file in YAML
+- schema_yaml: schema file in YAML to validate config_yaml against
+- output_dir: output directory where generated binaries can be 
populated
+Pass the arguments along with the filename in the Makefile.
+"""
+opts, args = getopt.getopt(sys.argv[1:], "c:s:o")
+for opt, val in opts:
+if opt == "-c":
+config_yaml = val
+elif opt == "-s":
+schema_yaml = val
+elif opt == "-o":
+ou

[PATCH RFC v3 00/11] Integration of tiboot3.bin, sysfw.itb and

2022-06-14 Thread Neha Malcom Francis
Devices that belong to the K3 architecture require SYSFW which is a FIT
image consisting of a signed system firmware image and board config
binaries.

Board config binaries are needed to bring up SYSFW during U-Boot SPL
startup. The board config data is given in YAML as input. These board
configs contain board-specific information such as resource management,
power management and security.

The following series intends to plumb the system firmware generation
into U-Boot using binman for packaging. Thus it will eliminate the need
for additional custom repositories for SYSFW generation and also moves
towards the community standard build flow. We use binman to package
tiboot3.bin and sysfw.itb for J721E.

These images also require x509 certificates which are created using the
etype ti-x509-cert.

The series also plumbs the generation of tispl.bin which is required for
loading U-Boot in K3 devices. The image is packaged using ATF, OPTEE and
DM (Device Manager).

Please note that the implementation is for J721E GP (General Purpose)
devices.

Also note the introduction of three new etypes: ti-sysfw, ti-dm and
ti-x509-cert.

CI tests on Github have all passed but this is after the inclusion of
test/py/requirements.txt installation in Azure pipeline script for World
Build tests.

v3:
- Reformatted patches to make sure none of the existing board builds and
  functionalities are broken
- x509-cert --> ti-x509-cert
- Avoided deletion of k3_fit_atf.sh and k3_gen_x509_cert.sh to make sure
  no other builds fail
- Made change to Azure pipeline script to include installation of
  test/py/requirements.txt in World Build test

v2:
- Added etype x509-cert for creating x509 Texas Instruments certificate
  binary
- Added packaging of tiboot3.bin
- Packaging of tiboot3.bin and sysfw.itb using new etype x509
- sysfw --> ti-sysfw
- Reformatted and re-arranged patches
- Removed k3_fit_atf.sh and k3_gen_x509_cert.sh as their functionality
  is provided by binman now

Neha Malcom Francis (11):
  j721e_evm: schema: yaml: Add general schema and J721E board config
files
  ti: tools: config: Add board config class to generate config binaries
  ti: etype: sysfw: Add entry type for sysfw
  ti: etype: dm: Add entry type for TI DM
  ti: etype: x509: Add etype for x509 certificate for K3 devices
  ti: sysfw: Add support for packaging sysfw.itb
  ti: j721e: Exclude makefile tiboot3.bin target for J721E
  ti: j721e: Exclude makefile tispl.bin target for J721E
  ti: dtsi: j721e: Use binman to package sysfw.itb and tiboot3.bin
  ti: dtsi: j721e: Use binman to package tispl.bin
  ci: world_build: test: Add requirements.txt

 .azure-pipelines.yml  |1 +
 Makefile  |2 +
 arch/arm/dts/k3-j721e-a72-binman.dtsi |   86 +
 .../k3-j721e-common-proc-board-u-boot.dtsi|1 +
 arch/arm/dts/k3-j721e-r5-binman.dtsi  |   88 +
 .../k3-j721e-r5-common-proc-board-u-boot.dtsi |1 +
 arch/arm/mach-k3/config.mk|   26 +
 board/ti/common/schema.yaml   |  355 ++
 board/ti/j721e/Kconfig|2 +
 board/ti/j721e/config.yaml| 3162 +
 scripts/Makefile.spl  |2 +
 test/py/requirements.txt  |2 +
 tools/binman/entries.rst  |   36 +
 tools/binman/etype/ti_dm.py   |   23 +
 tools/binman/etype/ti_sysfw.py|   28 +
 tools/binman/etype/ti_x509_cert.py|  241 ++
 tools/binman/ftest.py |   20 +
 tools/binman/test/225_ti_dm.dts   |   13 +
 tools/binman/test/232_ti_sysfw.dts|   13 +
 tools/binman/test/232_x509_cert.dts   |   18 +
 tools/tibcfg_gen.py   |  114 +
 21 files changed, 4234 insertions(+)
 create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
 create mode 100644 arch/arm/dts/k3-j721e-r5-binman.dtsi
 create mode 100644 board/ti/common/schema.yaml
 create mode 100644 board/ti/j721e/config.yaml
 create mode 100644 tools/binman/etype/ti_dm.py
 create mode 100644 tools/binman/etype/ti_sysfw.py
 create mode 100644 tools/binman/etype/ti_x509_cert.py
 create mode 100644 tools/binman/test/225_ti_dm.dts
 create mode 100644 tools/binman/test/232_ti_sysfw.dts
 create mode 100644 tools/binman/test/232_x509_cert.dts
 create mode 100644 tools/tibcfg_gen.py

-- 
2.17.1



Re: [PATCH 5/6] ARM: dts: stm32: Add alternate pinmux for SPI2 pins

2022-06-14 Thread Patrice CHOTARD
HI Marek

On 6/13/22 11:55, Marek Vasut wrote:
> Add another mux option for SPI2 pins, this is used on DRC Compact board.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
>  arch/arm/dts/stm32mp15-pinctrl.dtsi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index e0965c5936e..b92a149a186 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -1778,6 +1778,21 @@
>   };
>   };
>  
> + spi2_pins_b: spi2-1 {
> + pins1 {
> + pinmux = , /* SPI1_SCK */
> +  ; /* SPI1_MOSI */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <1>;
> + };
> +
> + pins2 {
> + pinmux = ; /* SPI1_MISO */
> + bias-disable;
> + };
> + };
> +
>   spi4_pins_a: spi4-0 {
>   pins {
>   pinmux = , /* SPI4_SCK */

Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH 4/6] ARM: dts: stm32: Add alternate pinmux for CAN1 pins

2022-06-14 Thread Patrice CHOTARD
Hi Marek

On 6/13/22 11:55, Marek Vasut wrote:
> Add another mux option for CAN1 pins, this is used on DRC Compact board.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
>  arch/arm/dts/stm32mp15-pinctrl.dtsi | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index 6a5b4016f66..e0965c5936e 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -929,6 +929,26 @@
>   };
>   };
>  
> + m_can1_pins_c: m-can1-2 {
> + pins1 {
> + pinmux = ; /* CAN1_TX */
> + slew-rate = <1>;
> + drive-push-pull;
> + bias-disable;
> + };
> + pins2 {
> + pinmux = ; /* CAN1_RX */
> + bias-disable;
> + };
> + };
> +
> + m_can1_sleep_pins_c: m_can1-sleep-2 {
> + pins {
> + pinmux = , /* CAN1_TX */
> +  ; /* CAN1_RX */
> + };
> + };
> +
>   m_can2_pins_a: m-can2-0 {
>   pins1 {
>   pinmux = ; /* CAN2_TX */

Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH v4] imx: add i.MX8MN DDR3L evk board support

2022-06-14 Thread Michael Nazzareno Trimarchi
Hi Heiko

On Wed, Jun 15, 2022 at 8:23 AM Heiko Thiery  wrote:
>
> Hi Marek,
>
> [SNIP]
>
> > > diff --git a/board/freescale/imx8mn_evk/spl.c 
> > > b/board/freescale/imx8mn_evk/spl.c
> > > index 14cb51368f..0d9909a662 100644
> > > --- a/board/freescale/imx8mn_evk/spl.c
> > > +++ b/board/freescale/imx8mn_evk/spl.c
> > > @@ -83,6 +83,15 @@ int power_init_board(void)
> > >  #ifdef CONFIG_IMX8MN_LOW_DRIVE_MODE
> > > /* Set VDD_SOC/VDD_DRAM to 0.8v for low drive mode */
> > > pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS0, 0x10);
> > > +#elif defined(CONFIG_TARGET_IMX8MN_DDR3L_EVK)
> > > +   /* Set VDD_SOC to 0.85v for DDR3L at 1600MTS */
> > > +   pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS0, 0x14);
> > > +
> > > +   /* Disable the BUCK2 */
> > > +   pmic_reg_write(dev, PCA9450_BUCK2CTRL, 0x48);
> > > +
> > > +   /* Set NVCC_DRAM to 1.35v */
> > > +   pmic_reg_write(dev, PCA9450_BUCK6OUT, 0x1E);
> > >  #else
> >
> > All this part is not done by the spl pmic driver?
>
> I saw that you added the PCA9450 driver. Do you know if this
> initialization can be done by the driver when CONFIG_SPL_DM_REGULATOR
> is enabled? If I see this correctly, it can't be done. Is that
> correct?

+&i2c1 {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+   u-boot,dm-spl;
+};
+
+&pinctrl_i2c1 {
+   u-boot,dm-spl;
+};
+
+&pinctrl_pmic {
+   u-boot,dm-spl;
+};
+

Maybe something like this should work. Now question is about should be
done in pre-reloc or not

Michael
>
> --
> Heiko



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


Re: [PATCH 3/6] ARM: dts: stm32: Add alternate pinmux for UART5 pins

2022-06-14 Thread Patrice CHOTARD
Hi Marek

On 6/13/22 11:55, Marek Vasut wrote:
> Add another mux option for UART5 pins, this is used on DRC Compact board.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
>  arch/arm/dts/stm32mp15-pinctrl.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index dc329bf531e..6a5b4016f66 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -1865,6 +1865,19 @@
>   };
>   };
>  
> + uart5_pins_a: uart5-0 {
> + pins1 {
> + pinmux = ; /* UART5_TX */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = ; /* UART5_RX */
> + bias-disable;
> + };
> + };
> +
>   uart7_pins_a: uart7-0 {
>   pins1 {
>   pinmux = ; /* UART7_TX */

Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH 2/6] ARM: dts: stm32: Add alternate pinmux for UART4 pins

2022-06-14 Thread Patrice CHOTARD
Hi Marek

On 6/13/22 11:55, Marek Vasut wrote:
> Add another mux option for UART4 pins, this is used on DRC Compact board.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
>  arch/arm/dts/stm32mp15-pinctrl.dtsi | 30 +
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index 823ef2e2aab..dc329bf531e 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -1835,6 +1835,36 @@
>   };
>   };
>  
> + uart4_pins_d: uart4-3 {
> + pins1 {
> + pinmux = ; /* UART4_TX */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = ; /* UART4_RX */
> + bias-disable;
> + };
> + };
> +
> + uart4_idle_pins_d: uart4-idle-3 {
> + pins1 {
> + pinmux = ; /* UART4_TX */
> + };
> + pins2 {
> + pinmux = ; /* UART4_RX */
> + bias-disable;
> + };
> + };
> +
> + uart4_sleep_pins_d: uart4-sleep-3 {
> + pins {
> + pinmux = , /* UART4_TX */
> +  ; /* UART4_RX */
> + };
> + };
> +
>   uart7_pins_a: uart7-0 {
>   pins1 {
>   pinmux = ; /* UART7_TX */
Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH] stm32mp: stpmic1: remove the debug unit request by debugger

2022-06-14 Thread Patrice CHOTARD
Hi Patrick

On 6/1/22 18:33, Patrick Delaunay wrote:
> Depending on backup register value, U-Boot SPL maintains the debug unit
> powered-on for debugging purpose; only BUCK1 is required for powering
> the debug unit, so revert the setting for all the other power lanes,
> except BUCK3 that has to be always on.
> 
> To be functional this patch requires a modification in the debugger
> ,openocd for example, to update the STM32MP15 backup register when it is
> required to debug SPL after reset. After deeper analysis this behavior
> will be never supported in tools so the associated code, will be never
> used and the associated code can be removed.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/mach-stm32mp/include/mach/stm32.h |  1 -
>  board/st/common/stpmic1.c  | 14 --
>  include/power/stpmic1.h|  3 ---
>  3 files changed, 18 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
> b/arch/arm/mach-stm32mp/include/mach/stm32.h
> index 47e88fc3dc..13cb7db9f0 100644
> --- a/arch/arm/mach-stm32mp/include/mach/stm32.h
> +++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
> @@ -117,7 +117,6 @@ enum boot_device {
>  #define TAMP_BOOT_DEVICE_MASKGENMASK(7, 4)
>  #define TAMP_BOOT_INSTANCE_MASK  GENMASK(3, 0)
>  #define TAMP_BOOT_FORCED_MASKGENMASK(7, 0)
> -#define TAMP_BOOT_DEBUG_ON   BIT(16)
>  
>  enum forced_boot_mode {
>   BOOT_NORMAL = 0x00,
> diff --git a/board/st/common/stpmic1.c b/board/st/common/stpmic1.c
> index 5fb1be2fd3..d52dce4f65 100644
> --- a/board/st/common/stpmic1.c
> +++ b/board/st/common/stpmic1.c
> @@ -202,18 +202,4 @@ void stpmic1_init(u32 voltage_mv)
>   STPMIC1_BUCKS_MRST_CR,
>   STPMIC1_MRST_BUCK(STPMIC1_BUCK3),
>   STPMIC1_MRST_BUCK(STPMIC1_BUCK3));
> -
> - /* Check if debug is enabled to program PMIC according to the bit */
> - if (readl(TAMP_BOOT_CONTEXT) & TAMP_BOOT_DEBUG_ON) {
> - log_info("Keep debug unit ON\n");
> -
> - pmic_clrsetbits(dev, STPMIC1_BUCKS_MRST_CR,
> - STPMIC1_MRST_BUCK_DEBUG,
> - STPMIC1_MRST_BUCK_DEBUG);
> -
> - if (STPMIC1_MRST_LDO_DEBUG)
> - pmic_clrsetbits(dev, STPMIC1_LDOS_MRST_CR,
> - STPMIC1_MRST_LDO_DEBUG,
> - STPMIC1_MRST_LDO_DEBUG);
> - }
>  }
> diff --git a/include/power/stpmic1.h b/include/power/stpmic1.h
> index d3567df326..201b1df762 100644
> --- a/include/power/stpmic1.h
> +++ b/include/power/stpmic1.h
> @@ -23,12 +23,9 @@
>  
>  /* BUCKS_MRST_CR */
>  #define STPMIC1_MRST_BUCK(buck)  BIT(buck)
> -#define STPMIC1_MRST_BUCK_DEBUG  
> (STPMIC1_MRST_BUCK(STPMIC1_BUCK1) | \
> -  STPMIC1_MRST_BUCK(STPMIC1_BUCK3))
>  
>  /* LDOS_MRST_CR */
>  #define STPMIC1_MRST_LDO(ldo)BIT(ldo)
> -#define STPMIC1_MRST_LDO_DEBUG   0
>  
>  /* BUCKx_MAIN_CR (x=1...4) */
>  #define STPMIC1_BUCK_ENA BIT(0)

Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH v5 08/23] FWU: Add boot time checks as highlighted by the FWU specification

2022-06-14 Thread Takahiro Akashi
On Wed, Jun 15, 2022 at 08:34:18AM +0200, Heinrich Schuchardt wrote:
> On 6/9/22 14:29, Sughosh Ganu wrote:
> > The FWU Multi Bank Update specification requires the Update Agent to
> > carry out certain checks at the time of platform boot. The Update
> > Agent is the component which is responsible for updating the firmware
> > components and maintaining and keeping the metadata in sync.
> > 
> > The spec requires that the Update Agent perform the following checks
> > at the time of boot
> > * Sanity check of both the metadata copies maintained by the platform.
> > * Get the boot index passed to U-Boot by the prior stage bootloader
> >and use this value for metadata bookkeeping.
> > * Check if the system is booting in Trial State. If the system boots
> >in the Trial State for more than a specified number of boot counts,
> >change the Active Bank to be booting the platform from.
> > 
> > Add these checks in the board initialisation sequence, invoked after
> > relocation.
> > 
> > Signed-off-by: Sughosh Ganu 
> > ---
> >   common/board_r.c  |   5 ++
> >   include/fwu.h |   3 +
> >   lib/fwu_updates/fwu.c | 170 ++
> >   3 files changed, 178 insertions(+)
> >   create mode 100644 lib/fwu_updates/fwu.c
> > 
> > diff --git a/common/board_r.c b/common/board_r.c
> > index 6f4aca2077..33a600715d 100644
> > --- a/common/board_r.c
> > +++ b/common/board_r.c
> > @@ -15,6 +15,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -797,6 +798,10 @@ static init_fnc_t init_sequence_r[] = {
> >   #if defined(CONFIG_PRAM)
> > initr_mem,
> >   #endif
> > +
> > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > +   fwu_boottime_checks,
> > +#endif
> > run_main_loop,
> >   };
> > 
> > diff --git a/include/fwu.h b/include/fwu.h
> > index 41774ff9e2..8fbd91b463 100644
> > --- a/include/fwu.h
> > +++ b/include/fwu.h
> > @@ -33,6 +33,9 @@ struct fwu_mdata_ops {
> > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> >  0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > 
> > +int fwu_boottime_checks(void);
> > +u8 fwu_update_checks_pass(void);
> > +
> >   int fwu_get_mdata(struct fwu_mdata **mdata);
> >   int fwu_update_mdata(struct fwu_mdata *mdata);
> >   int fwu_get_active_index(u32 *active_idx);
> > diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> > new file mode 100644
> > index 00..af884439fb
> > --- /dev/null
> > +++ b/lib/fwu_updates/fwu.c
> > @@ -0,0 +1,170 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2022, Linaro Limited
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +static u8 trial_state;
> > +static u8 boottime_check;
> > +
> > +static int fwu_trial_state_check(void)
> > +{
> > +   int ret, i;
> > +   efi_status_t status;
> > +   efi_uintn_t var_size;
> > +   u16 trial_state_ctr;
> > +   u32 nimages, active_bank, var_attributes, active_idx;
> > +   struct fwu_mdata *mdata = NULL;
> > +   struct fwu_image_entry *img_entry;
> > +   struct fwu_image_bank_info *img_bank_info;
> > +
> > +   ret = fwu_get_mdata(&mdata);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = 0;
> > +   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
> > +   active_bank = mdata->active_index;
> > +   img_entry = &mdata->img_entry[0];
> > +   for (i = 0; i < nimages; i++) {
> > +   img_bank_info = &img_entry[i].img_bank_info[active_bank];
> > +   if (!img_bank_info->accepted) {
> > +   trial_state = 1;
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (trial_state) {
> > +   var_size = (efi_uintn_t)sizeof(trial_state_ctr);
> > +   log_info("System booting in Trial State\n");
> > +   var_attributes = EFI_VARIABLE_NON_VOLATILE |
> > +   EFI_VARIABLE_BOOTSERVICE_ACCESS;
> > +   status = efi_get_variable_int(L"TrialStateCtr",
> > + &efi_global_variable_guid,
> > + &var_attributes,
> > + &var_size, &trial_state_ctr,
> > + NULL);
> > +   if (status != EFI_SUCCESS) {
> > +   log_err("Unable to read TrialStateCtr variable\n");
> > +   ret = -1;
> > +   goto out;
> > +   }
> > +
> > +   ++trial_state_ctr;
> > +   if (trial_state_ctr > CONFIG_FWU_TRIAL_STATE_CNT) {
> > +   log_info("Trial State count exceeded. Revert back to 
> > previous_active_index\n");
> > +   active_idx = mdata->active_index;
> > +   ret = fwu_revert_boot_index();
> > +   if (ret) {
> > +   log_err("Unable to revert active_index\n");
> > +

Re: [PATCH 1/6] ARM: dts: stm32: Add alternate pinmux for UART3 pins

2022-06-14 Thread Patrice CHOTARD
Hi Marek

On 6/13/22 11:55, Marek Vasut wrote:
> Add another mux option for UART3 pins, this is used on DRC Compact board.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
>  arch/arm/dts/stm32mp15-pinctrl.dtsi | 41 +
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index f0d66d8c6e3..823ef2e2aab 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -2134,6 +2134,47 @@
>   };
>   };
>  
> + usart3_pins_e: usart3-4 {
> + pins1 {
> + pinmux = , /* USART3_TX */
> +  ; /* USART3_RTS */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = , /* USART3_RX */
> +  ; /* 
> USART3_CTS_NSS */
> + bias-pull-up;
> + };
> + };
> +
> + usart3_idle_pins_e: usart3-idle-4 {
> + pins1 {
> + pinmux = , /* USART3_TX 
> */
> +  ; /* 
> USART3_CTS_NSS */
> + };
> + pins2 {
> + pinmux = ; /* USART3_RTS */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins3 {
> + pinmux = ; /* USART3_RX */
> + bias-pull-up;
> + };
> + };
> +
> + usart3_sleep_pins_e: usart3-sleep-4 {
> + pins {
> + pinmux = , /* USART3_TX 
> */
> +  , /* USART3_RTS 
> */
> +  , /* 
> USART3_CTS_NSS */
> +  ; /* USART3_RX 
> */
> + };
> + };
> +
>   usbotg_hs_pins_a: usbotg-hs-0 {
>   pins {
>   pinmux = ; /* OTG_ID */
Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH 1/1] efi_loader: initialize console size late

2022-06-14 Thread AKASHI Takahiro
On Wed, Jun 15, 2022 at 08:27:26AM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 6/15/22 08:16, AKASHI Takahiro wrote:
> > On Tue, Jun 14, 2022 at 08:02:03AM +0200, Heinrich Schuchardt wrote:
> > > From: Heinrich Schuchardt 
> > > 
> > > If CONFIG_VIDEO_DM=n we query the display size from the serial console.
> > > Especially when using a remote console the response can be so late that
> > > it interferes with autoboot.
> > > 
> > > Only query the console size when running an EFI binary.
> > > 
> > > Add debug output showing the determined console size.
> > > 
> > > Reported-by: Fabio Estevam 
> > > Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create 
> > > efi_disk objects from udevice")
> 
> Said patch made CONFIG_EFI_SETUP_EARLY=y the default.

I don't think so.
Any config with this option enabled could cause the issue.

> > 
> > If the key part of this patch is to move query_console_size() from
> > efi_init_early() to efi_init_obj_list(), the to-be-fixed patch is not
> > the one above but
> >  commit a57ad20d07e8 ("efi_loader: split efi_init_obj_list() into 
> > two stages")
> > 
> > Moreover, this is just a warning but once Sughosh's patch,
> >  https://lists.denx.de/pipermail/u-boot/2022-June/485977.html
> > is merged and FWU_MULTI_BANK_UPDATE is enabled, the said phenomenon can
> > be triggered again because efi_init_obj_list(), hence query_console_size(),
> > will be called in board_init_r() before showing the U-Boot prompt.
> 
> Then we should not merge it as is.

I think that your patch is a tentative workaround.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> > 
> > -Takahiro Akashi
> > 
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > >   include/efi_loader.h |  2 ++
> > >   lib/efi_loader/efi_console.c | 20 +---
> > >   lib/efi_loader/efi_setup.c   |  4 
> > >   3 files changed, 19 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > index f6651e2c60..c1e00ebac3 100644
> > > --- a/include/efi_loader.h
> > > +++ b/include/efi_loader.h
> > > @@ -499,6 +499,8 @@ extern struct list_head efi_register_notify_events;
> > >   int efi_init_early(void);
> > >   /* Initialize efi execution environment */
> > >   efi_status_t efi_init_obj_list(void);
> > > +/* Set up console modes */
> > > +void efi_setup_console_size(void);
> > >   /* Install device tree */
> > >   efi_status_t efi_install_fdt(void *fdt);
> > >   /* Run loaded UEFI image */
> > > diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> > > index 60a3fc85ac..3164fd484e 100644
> > > --- a/lib/efi_loader/efi_console.c
> > > +++ b/lib/efi_loader/efi_console.c
> > > @@ -5,6 +5,8 @@
> > >*  Copyright (c) 2016 Alexander Graf
> > >*/
> > > +#define LOG_CATEGORY LOGC_EFI
> > > +
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -12,6 +14,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -58,7 +61,12 @@ const efi_guid_t efi_guid_text_output_protocol =
> > >   #define cESC '\x1b'
> > >   #define ESC "\x1b"
> > > -/* Default to mode 0 */
> > > +/*
> > > + * efi_con_mode - mode information of the Simple Text Output Protocol
> > > + *
> > > + * Use safe settings before efi_setup_console_size() is called.
> > > + * By default enable only the 80x25 mode which must always exist.
> > > + */
> > >   static struct simple_text_output_mode efi_con_mode = {
> > >   .max_mode = 1,
> > >   .mode = 0,
> > > @@ -333,13 +341,13 @@ static int __maybe_unused query_vidconsole(int 
> > > *rows, int *cols)
> > >   }
> > >   /**
> > > - * query_console_size() - update the mode table.
> > > + * efi_setup_console_size() - update the mode table.
> > >*
> > >* By default the only mode available is 80x25. If the console has at 
> > > least 50
> > >* lines, enable mode 80x50. If we can query the console size and it is 
> > > neither
> > >* 80x25 nor 80x50, set it as an additional mode.
> > >*/
> > > -static void query_console_size(void)
> > > +void efi_setup_console_size(void)
> > >   {
> > >   int rows = 25, cols = 80;
> > >   int ret = -ENODEV;
> > > @@ -351,6 +359,8 @@ static void query_console_size(void)
> > >   if (ret)
> > >   return;
> > > + log_debug("Console size %dx%d\n", rows, cols);
> > > +
> > >   /* Test if we can have Mode 1 */
> > >   if (cols >= 80 && rows >= 50) {
> > >   efi_cout_modes[1].present = 1;
> > > @@ -371,7 +381,6 @@ static void query_console_size(void)
> > >   }
> > >   }
> > > -
> > >   /**
> > >* efi_cout_query_mode() - get terminal size for a text mode
> > >*
> > > @@ -1262,9 +1271,6 @@ efi_status_t efi_console_register(void)
> > >   efi_status_t r;
> > >   struct efi_device_path *dp;
> > > - /* Set up mode information */
> > > - query_console_size();
> > > -

Re: [PATCH v5 08/23] FWU: Add boot time checks as highlighted by the FWU specification

2022-06-14 Thread Heinrich Schuchardt

On 6/9/22 14:29, Sughosh Ganu wrote:

The FWU Multi Bank Update specification requires the Update Agent to
carry out certain checks at the time of platform boot. The Update
Agent is the component which is responsible for updating the firmware
components and maintaining and keeping the metadata in sync.

The spec requires that the Update Agent perform the following checks
at the time of boot
* Sanity check of both the metadata copies maintained by the platform.
* Get the boot index passed to U-Boot by the prior stage bootloader
   and use this value for metadata bookkeeping.
* Check if the system is booting in Trial State. If the system boots
   in the Trial State for more than a specified number of boot counts,
   change the Active Bank to be booting the platform from.

Add these checks in the board initialisation sequence, invoked after
relocation.

Signed-off-by: Sughosh Ganu 
---
  common/board_r.c  |   5 ++
  include/fwu.h |   3 +
  lib/fwu_updates/fwu.c | 170 ++
  3 files changed, 178 insertions(+)
  create mode 100644 lib/fwu_updates/fwu.c

diff --git a/common/board_r.c b/common/board_r.c
index 6f4aca2077..33a600715d 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -797,6 +798,10 @@ static init_fnc_t init_sequence_r[] = {
  #if defined(CONFIG_PRAM)
initr_mem,
  #endif
+
+#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
+   fwu_boottime_checks,
+#endif
run_main_loop,
  };

diff --git a/include/fwu.h b/include/fwu.h
index 41774ff9e2..8fbd91b463 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -33,6 +33,9 @@ struct fwu_mdata_ops {
EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)

+int fwu_boottime_checks(void);
+u8 fwu_update_checks_pass(void);
+
  int fwu_get_mdata(struct fwu_mdata **mdata);
  int fwu_update_mdata(struct fwu_mdata *mdata);
  int fwu_get_active_index(u32 *active_idx);
diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
new file mode 100644
index 00..af884439fb
--- /dev/null
+++ b/lib/fwu_updates/fwu.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static u8 trial_state;
+static u8 boottime_check;
+
+static int fwu_trial_state_check(void)
+{
+   int ret, i;
+   efi_status_t status;
+   efi_uintn_t var_size;
+   u16 trial_state_ctr;
+   u32 nimages, active_bank, var_attributes, active_idx;
+   struct fwu_mdata *mdata = NULL;
+   struct fwu_image_entry *img_entry;
+   struct fwu_image_bank_info *img_bank_info;
+
+   ret = fwu_get_mdata(&mdata);
+   if (ret)
+   return ret;
+
+   ret = 0;
+   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
+   active_bank = mdata->active_index;
+   img_entry = &mdata->img_entry[0];
+   for (i = 0; i < nimages; i++) {
+   img_bank_info = &img_entry[i].img_bank_info[active_bank];
+   if (!img_bank_info->accepted) {
+   trial_state = 1;
+   break;
+   }
+   }
+
+   if (trial_state) {
+   var_size = (efi_uintn_t)sizeof(trial_state_ctr);
+   log_info("System booting in Trial State\n");
+   var_attributes = EFI_VARIABLE_NON_VOLATILE |
+   EFI_VARIABLE_BOOTSERVICE_ACCESS;
+   status = efi_get_variable_int(L"TrialStateCtr",
+ &efi_global_variable_guid,
+ &var_attributes,
+ &var_size, &trial_state_ctr,
+ NULL);
+   if (status != EFI_SUCCESS) {
+   log_err("Unable to read TrialStateCtr variable\n");
+   ret = -1;
+   goto out;
+   }
+
+   ++trial_state_ctr;
+   if (trial_state_ctr > CONFIG_FWU_TRIAL_STATE_CNT) {
+   log_info("Trial State count exceeded. Revert back to 
previous_active_index\n");
+   active_idx = mdata->active_index;
+   ret = fwu_revert_boot_index();
+   if (ret) {
+   log_err("Unable to revert active_index\n");
+   goto out;
+   }
+
+   trial_state_ctr = 0;
+   status = efi_set_variable_int(L"TrialStateCtr",
+ &efi_global_variable_guid,
+ var_attributes,
+ 0,
+  

Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox

2022-06-14 Thread Takahiro Akashi
On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote:
> Add a python test script for testing the FWU Multi Bank Update
> functionality on the sandbox platform. The script has test cases for
> updation of the u-boot binary and the u-boot environment image to the
> non active bank.

IIUC, your test doesn't not exercise neither accept-capsule nor
revert capsule.
I think those tests are crucial for verifying the code.

-Takahiro Akashi

> The FWU metadata is being stored on the SPI NOR flash, along with the
> updatable images, and the FWU metadata driver for MTD devices is being
> used for accessing the metadata. Certain FWU boottime checks are
> bypassed due to the unavailability of the EFI variable access very
> early in the boot on the sandbox platform -- the variable access is
> only available once the block disk image has been bound through the
> host interface.
> 
> The FWU Multi Bank feature being enabled on the sandbox64 platform is
> enabling the RAW Firmware Management Protocol(FMP) instance, therefore
> the FIT FMP instance is being removed -- the FIT FMP is already being
> tested on the sandbox flattree variant.
> 
> Signed-off-by: Sughosh Ganu 
> ---
>  arch/sandbox/Kconfig  |   6 +
>  arch/sandbox/dts/test.dts |  45 ++-
>  board/sandbox/sandbox.c   |  49 +++
>  configs/sandbox64_defconfig   |  12 +-
>  include/fwu.h |   2 +
>  lib/fwu_updates/Kconfig   |   2 +-
>  lib/fwu_updates/fwu.c |  18 +-
>  lib/fwu_updates/fwu_mtd.c |  10 +-
>  .../test_capsule_firmware_fit.py  |   1 -
>  .../py/tests/test_fwu_updates/capsule_defs.py |  10 +
>  test/py/tests/test_fwu_updates/conftest.py|  78 
>  .../test_fwu_updates/test_fwu_updates.py  | 367 ++
>  12 files changed, 587 insertions(+), 13 deletions(-)
>  create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py
>  create mode 100644 test/py/tests/test_fwu_updates/conftest.py
>  create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py
> 
> diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> index 5f55c7f28e..2985572083 100644
> --- a/arch/sandbox/Kconfig
> +++ b/arch/sandbox/Kconfig
> @@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
> See `doc/arch/sandbox.rst` for more information.
>  
>  endmenu
> +
> +config FWU_NUM_BANKS
> +   default 2
> +
> +config FWU_NUM_IMAGES_PER_BANK
> + default 2
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 8f93775ff4..f11fa8733f 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -1145,11 +1145,48 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <&pinmux_spi0_pins>;
>  
> - spi.bin@0 {
> + spi0: spi.bin@0 {
>   reg = <0>;
>   compatible = "spansion,m25p16", "jedec,spi-nor";
>   spi-max-frequency = <4000>;
>   sandbox,filename = "spi.bin";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + uuid = "af9e8c96-bec5-48be-9dab-3491c04b1366";
> +
> + partition@0 {
> + label = "Metadata";
> + reg = <0x0 0x2>;
> + };
> +
> + /* FWU Multi bank update partitions */
> + partition@10 {
> + label = "U-Boot-Bank0";
> + reg = <0x10 0x1>;
> + uuid = 
> "a8f61787-5d68-4c9d-9e4a-37bb0df99da7";
> + };
> +
> + partition@12 {
> + label = "U-Boot-ENV-Bank0";
> + reg = <0x12 0x1>;
> + uuid = 
> "ea9d59af-e0e8-4ef5-9b16-4c80ff67524c";
> + };
> +
> + partition@14 {
> + label = "U-Boot-Bank1";
> + reg = <0x14 0x1>;
> + uuid = 
> "52377abf-c4e4-4d0b-aafd-ba081a500847";
> + };
> +
> + partition@16 {
> + label = "U-Boot-ENV-Bank1";
> + reg = <0x16 0x1>;
> + uuid = 
> "4e01d1fa-eebb-437e-9cfe-e7dfbcd04bb3";
> + };
> + };
>   };
>   spi

Re: [PATCH 1/1] efi_loader: initialize console size late

2022-06-14 Thread Heinrich Schuchardt




On 6/15/22 08:16, AKASHI Takahiro wrote:

On Tue, Jun 14, 2022 at 08:02:03AM +0200, Heinrich Schuchardt wrote:

From: Heinrich Schuchardt 

If CONFIG_VIDEO_DM=n we query the display size from the serial console.
Especially when using a remote console the response can be so late that
it interferes with autoboot.

Only query the console size when running an EFI binary.

Add debug output showing the determined console size.

Reported-by: Fabio Estevam 
Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk objects 
from udevice")


Said patch made CONFIG_EFI_SETUP_EARLY=y the default.



If the key part of this patch is to move query_console_size() from
efi_init_early() to efi_init_obj_list(), the to-be-fixed patch is not
the one above but
 commit a57ad20d07e8 ("efi_loader: split efi_init_obj_list() into two 
stages")

Moreover, this is just a warning but once Sughosh's patch,
 https://lists.denx.de/pipermail/u-boot/2022-June/485977.html
is merged and FWU_MULTI_BANK_UPDATE is enabled, the said phenomenon can
be triggered again because efi_init_obj_list(), hence query_console_size(),
will be called in board_init_r() before showing the U-Boot prompt.


Then we should not merge it as is.

Best regards

Heinrich



-Takahiro Akashi


Signed-off-by: Heinrich Schuchardt 
---
  include/efi_loader.h |  2 ++
  lib/efi_loader/efi_console.c | 20 +---
  lib/efi_loader/efi_setup.c   |  4 
  3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index f6651e2c60..c1e00ebac3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -499,6 +499,8 @@ extern struct list_head efi_register_notify_events;
  int efi_init_early(void);
  /* Initialize efi execution environment */
  efi_status_t efi_init_obj_list(void);
+/* Set up console modes */
+void efi_setup_console_size(void);
  /* Install device tree */
  efi_status_t efi_install_fdt(void *fdt);
  /* Run loaded UEFI image */
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 60a3fc85ac..3164fd484e 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -5,6 +5,8 @@
   *  Copyright (c) 2016 Alexander Graf
   */
  
+#define LOG_CATEGORY LOGC_EFI

+
  #include 
  #include 
  #include 
@@ -12,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -58,7 +61,12 @@ const efi_guid_t efi_guid_text_output_protocol =
  #define cESC '\x1b'
  #define ESC "\x1b"
  
-/* Default to mode 0 */

+/*
+ * efi_con_mode - mode information of the Simple Text Output Protocol
+ *
+ * Use safe settings before efi_setup_console_size() is called.
+ * By default enable only the 80x25 mode which must always exist.
+ */
  static struct simple_text_output_mode efi_con_mode = {
.max_mode = 1,
.mode = 0,
@@ -333,13 +341,13 @@ static int __maybe_unused query_vidconsole(int *rows, int 
*cols)
  }
  
  /**

- * query_console_size() - update the mode table.
+ * efi_setup_console_size() - update the mode table.
   *
   * By default the only mode available is 80x25. If the console has at least 50
   * lines, enable mode 80x50. If we can query the console size and it is 
neither
   * 80x25 nor 80x50, set it as an additional mode.
   */
-static void query_console_size(void)
+void efi_setup_console_size(void)
  {
int rows = 25, cols = 80;
int ret = -ENODEV;
@@ -351,6 +359,8 @@ static void query_console_size(void)
if (ret)
return;
  
+	log_debug("Console size %dx%d\n", rows, cols);

+
/* Test if we can have Mode 1 */
if (cols >= 80 && rows >= 50) {
efi_cout_modes[1].present = 1;
@@ -371,7 +381,6 @@ static void query_console_size(void)
}
  }
  
-

  /**
   * efi_cout_query_mode() - get terminal size for a text mode
   *
@@ -1262,9 +1271,6 @@ efi_status_t efi_console_register(void)
efi_status_t r;
struct efi_device_path *dp;
  
-	/* Set up mode information */

-   query_console_size();
-
/* Install protocols on root node */
r = EFI_CALL(efi_install_multiple_protocol_interfaces
 (&efi_root,
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 250eeb2fcd..492ecf4cb1 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -243,6 +243,10 @@ efi_status_t efi_init_obj_list(void)
goto out;
}
  
+	/* Set up console modes */

+   efi_setup_console_size();
+
+   /* Install EFI_RNG_PROTOCOL */
if (IS_ENABLED(CONFIG_EFI_RNG_PROTOCOL)) {
ret = efi_rng_register();
if (ret != EFI_SUCCESS)
--
2.36.1



Re: [PATCH v4] imx: add i.MX8MN DDR3L evk board support

2022-06-14 Thread Heiko Thiery
Hi Marek,

[SNIP]

> > diff --git a/board/freescale/imx8mn_evk/spl.c 
> > b/board/freescale/imx8mn_evk/spl.c
> > index 14cb51368f..0d9909a662 100644
> > --- a/board/freescale/imx8mn_evk/spl.c
> > +++ b/board/freescale/imx8mn_evk/spl.c
> > @@ -83,6 +83,15 @@ int power_init_board(void)
> >  #ifdef CONFIG_IMX8MN_LOW_DRIVE_MODE
> > /* Set VDD_SOC/VDD_DRAM to 0.8v for low drive mode */
> > pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS0, 0x10);
> > +#elif defined(CONFIG_TARGET_IMX8MN_DDR3L_EVK)
> > +   /* Set VDD_SOC to 0.85v for DDR3L at 1600MTS */
> > +   pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS0, 0x14);
> > +
> > +   /* Disable the BUCK2 */
> > +   pmic_reg_write(dev, PCA9450_BUCK2CTRL, 0x48);
> > +
> > +   /* Set NVCC_DRAM to 1.35v */
> > +   pmic_reg_write(dev, PCA9450_BUCK6OUT, 0x1E);
> >  #else
>
> All this part is not done by the spl pmic driver?

I saw that you added the PCA9450 driver. Do you know if this
initialization can be done by the driver when CONFIG_SPL_DM_REGULATOR
is enabled? If I see this correctly, it can't be done. Is that
correct?

-- 
Heiko


Re: [PATCH 1/1] efi_loader: initialize console size late

2022-06-14 Thread AKASHI Takahiro
On Tue, Jun 14, 2022 at 08:02:03AM +0200, Heinrich Schuchardt wrote:
> From: Heinrich Schuchardt 
> 
> If CONFIG_VIDEO_DM=n we query the display size from the serial console.
> Especially when using a remote console the response can be so late that
> it interferes with autoboot.
> 
> Only query the console size when running an EFI binary.
> 
> Add debug output showing the determined console size.
> 
> Reported-by: Fabio Estevam 
> Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk 
> objects from udevice")

If the key part of this patch is to move query_console_size() from
efi_init_early() to efi_init_obj_list(), the to-be-fixed patch is not
the one above but
commit a57ad20d07e8 ("efi_loader: split efi_init_obj_list() into two 
stages")

Moreover, this is just a warning but once Sughosh's patch,
https://lists.denx.de/pipermail/u-boot/2022-June/485977.html
is merged and FWU_MULTI_BANK_UPDATE is enabled, the said phenomenon can
be triggered again because efi_init_obj_list(), hence query_console_size(),
will be called in board_init_r() before showing the U-Boot prompt.

-Takahiro Akashi

> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h |  2 ++
>  lib/efi_loader/efi_console.c | 20 +---
>  lib/efi_loader/efi_setup.c   |  4 
>  3 files changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index f6651e2c60..c1e00ebac3 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -499,6 +499,8 @@ extern struct list_head efi_register_notify_events;
>  int efi_init_early(void);
>  /* Initialize efi execution environment */
>  efi_status_t efi_init_obj_list(void);
> +/* Set up console modes */
> +void efi_setup_console_size(void);
>  /* Install device tree */
>  efi_status_t efi_install_fdt(void *fdt);
>  /* Run loaded UEFI image */
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 60a3fc85ac..3164fd484e 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -5,6 +5,8 @@
>   *  Copyright (c) 2016 Alexander Graf
>   */
>  
> +#define LOG_CATEGORY LOGC_EFI
> +
>  #include 
>  #include 
>  #include 
> @@ -12,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -58,7 +61,12 @@ const efi_guid_t efi_guid_text_output_protocol =
>  #define cESC '\x1b'
>  #define ESC "\x1b"
>  
> -/* Default to mode 0 */
> +/*
> + * efi_con_mode - mode information of the Simple Text Output Protocol
> + *
> + * Use safe settings before efi_setup_console_size() is called.
> + * By default enable only the 80x25 mode which must always exist.
> + */
>  static struct simple_text_output_mode efi_con_mode = {
>   .max_mode = 1,
>   .mode = 0,
> @@ -333,13 +341,13 @@ static int __maybe_unused query_vidconsole(int *rows, 
> int *cols)
>  }
>  
>  /**
> - * query_console_size() - update the mode table.
> + * efi_setup_console_size() - update the mode table.
>   *
>   * By default the only mode available is 80x25. If the console has at least 
> 50
>   * lines, enable mode 80x50. If we can query the console size and it is 
> neither
>   * 80x25 nor 80x50, set it as an additional mode.
>   */
> -static void query_console_size(void)
> +void efi_setup_console_size(void)
>  {
>   int rows = 25, cols = 80;
>   int ret = -ENODEV;
> @@ -351,6 +359,8 @@ static void query_console_size(void)
>   if (ret)
>   return;
>  
> + log_debug("Console size %dx%d\n", rows, cols);
> +
>   /* Test if we can have Mode 1 */
>   if (cols >= 80 && rows >= 50) {
>   efi_cout_modes[1].present = 1;
> @@ -371,7 +381,6 @@ static void query_console_size(void)
>   }
>  }
>  
> -
>  /**
>   * efi_cout_query_mode() - get terminal size for a text mode
>   *
> @@ -1262,9 +1271,6 @@ efi_status_t efi_console_register(void)
>   efi_status_t r;
>   struct efi_device_path *dp;
>  
> - /* Set up mode information */
> - query_console_size();
> -
>   /* Install protocols on root node */
>   r = EFI_CALL(efi_install_multiple_protocol_interfaces
>(&efi_root,
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index 250eeb2fcd..492ecf4cb1 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -243,6 +243,10 @@ efi_status_t efi_init_obj_list(void)
>   goto out;
>   }
>  
> + /* Set up console modes */
> + efi_setup_console_size();
> +
> + /* Install EFI_RNG_PROTOCOL */
>   if (IS_ENABLED(CONFIG_EFI_RNG_PROTOCOL)) {
>   ret = efi_rng_register();
>   if (ret != EFI_SUCCESS)
> -- 
> 2.36.1
> 


Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox

2022-06-14 Thread Takahiro Akashi
On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote:
> Add a python test script for testing the FWU Multi Bank Update
> functionality on the sandbox platform. The script has test cases for
> updation of the u-boot binary and the u-boot environment image to the
> non active bank.
> 
> The FWU metadata is being stored on the SPI NOR flash, along with the
> updatable images, and the FWU metadata driver for MTD devices is being
> used for accessing the metadata. Certain FWU boottime checks are
> bypassed due to the unavailability of the EFI variable access very
> early in the boot on the sandbox platform -- the variable access is
> only available once the block disk image has been bound through the
> host interface.
> 
> The FWU Multi Bank feature being enabled on the sandbox64 platform is
> enabling the RAW Firmware Management Protocol(FMP) instance, therefore
> the FIT FMP instance is being removed -- the FIT FMP is already being
> tested on the sandbox flattree variant.

IMO,
Thinking of the importance of this feature, FIT FMP should also be
tested *with FWU*.

> Signed-off-by: Sughosh Ganu 
> ---
>  arch/sandbox/Kconfig  |   6 +
>  arch/sandbox/dts/test.dts |  45 ++-
>  board/sandbox/sandbox.c   |  49 +++
>  configs/sandbox64_defconfig   |  12 +-
>  include/fwu.h |   2 +
>  lib/fwu_updates/Kconfig   |   2 +-
>  lib/fwu_updates/fwu.c |  18 +-
>  lib/fwu_updates/fwu_mtd.c |  10 +-
>  .../test_capsule_firmware_fit.py  |   1 -
>  .../py/tests/test_fwu_updates/capsule_defs.py |  10 +
>  test/py/tests/test_fwu_updates/conftest.py|  78 
>  .../test_fwu_updates/test_fwu_updates.py  | 367 ++
>  12 files changed, 587 insertions(+), 13 deletions(-)
>  create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py
>  create mode 100644 test/py/tests/test_fwu_updates/conftest.py
>  create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py
> 
> diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> index 5f55c7f28e..2985572083 100644
> --- a/arch/sandbox/Kconfig
> +++ b/arch/sandbox/Kconfig
> @@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
> See `doc/arch/sandbox.rst` for more information.
>  
>  endmenu
> +
> +config FWU_NUM_BANKS
> +   default 2
> +
> +config FWU_NUM_IMAGES_PER_BANK
> + default 2
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 8f93775ff4..f11fa8733f 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -1145,11 +1145,48 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <&pinmux_spi0_pins>;
>  
> - spi.bin@0 {
> + spi0: spi.bin@0 {
>   reg = <0>;
>   compatible = "spansion,m25p16", "jedec,spi-nor";
>   spi-max-frequency = <4000>;
>   sandbox,filename = "spi.bin";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + uuid = "af9e8c96-bec5-48be-9dab-3491c04b1366";
> +
> + partition@0 {
> + label = "Metadata";
> + reg = <0x0 0x2>;
> + };
> +
> + /* FWU Multi bank update partitions */
> + partition@10 {
> + label = "U-Boot-Bank0";
> + reg = <0x10 0x1>;
> + uuid = 
> "a8f61787-5d68-4c9d-9e4a-37bb0df99da7";
> + };
> +
> + partition@12 {
> + label = "U-Boot-ENV-Bank0";
> + reg = <0x12 0x1>;
> + uuid = 
> "ea9d59af-e0e8-4ef5-9b16-4c80ff67524c";
> + };
> +
> + partition@14 {
> + label = "U-Boot-Bank1";
> + reg = <0x14 0x1>;
> + uuid = 
> "52377abf-c4e4-4d0b-aafd-ba081a500847";
> + };
> +
> + partition@16 {
> + label = "U-Boot-ENV-Bank1";
> + reg = <0x16 0x1>;
> + uuid = 
> "4e01d1fa-eebb-437e-9cfe-e7dfbcd04bb3";
> + };
> + };
>   };
>   spi.bin@1 {
>   reg = <1>;
> @@ -1633,6 +1670,

Re: [PATCH v5 11/23] mkeficapsule: Add support for generating empty capsules

2022-06-14 Thread Takahiro Akashi
On Thu, Jun 09, 2022 at 05:59:58PM +0530, Sughosh Ganu wrote:
> The Dependable Boot specification[1] describes the structure of the
> firmware accept and revert capsules. These are empty capsules which
> are used for signalling the acceptance or rejection of the updated
> firmware by the OS. Add support for generating these empty capsules.
> 
> [1] - 
> https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
> 
> Signed-off-by: Sughosh Ganu 
> ---
>  doc/mkeficapsule.1   |  29 ++---
>  tools/eficapsule.h   |   8 +++
>  tools/mkeficapsule.c | 139 +--
>  3 files changed, 151 insertions(+), 25 deletions(-)
> 
> diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
> index 09bdc24295..77ca061efd 100644
> --- a/doc/mkeficapsule.1
> +++ b/doc/mkeficapsule.1
> @@ -8,7 +8,7 @@ mkeficapsule \- Generate EFI capsule file for U-Boot
>  
>  .SH SYNOPSIS
>  .B mkeficapsule
> -.RI [ options "] " image-blob " " capsule-file
> +.RI [ options ] " " [ image-blob ] " " capsule-file
>  
>  .SH "DESCRIPTION"
>  .B mkeficapsule
> @@ -23,8 +23,13 @@ Optionally, a capsule file can be signed with a given 
> private key.
>  In this case, the update will be authenticated by verifying the signature
>  before applying.
>  
> +Additionally, an empty capsule file can be generated for acceptance or
> +rejection of firmware images by a governing component like an Operating
> +System. The empty capsules do not require an image-blob input file.
> +
> +
>  .B mkeficapsule
> -takes any type of image files, including:
> +takes any type of image files when generating non empty capsules, including:
>  .TP
>  .I raw image
>  format is a single binary blob of any type of firmware.
> @@ -36,18 +41,16 @@ multiple binary blobs in a single capsule file.
>  This type of image file can be generated by
>  .BR mkimage .
>  
> -.PP
> -If you want to use other types than above two, you should explicitly
> -specify a guid for the FMP driver.
> -
>  .SH "OPTIONS"
> +
>  .TP
>  .BI "-g\fR,\fB --guid " guid-string
>  Specify guid for image blob type. The format is:
>  ----
>  
>  The first three elements are in little endian, while the rest
> -is in big endian.
> +is in big endian. The option must be specified for all non empty and
> +image acceptance capsules

"image acceptance" -> "firmware acceptance"

I don't still understand why we need a guid for acceptance
while revert doesn't require it.
I believe that firmware update is "all or nothing", isn't it?

If there is a good reason, please describe a possible/expected
scenario.

>  .TP
>  .BI "-i\fR,\fB --index " index
> @@ -57,6 +60,18 @@ Specify an image index
>  .BI "-I\fR,\fB --instance " instance
>  Specify a hardware instance
>  
> +.PP
> +For generation of firmware accept empty capsule
> +.BR --guid
> +is mandatory
> +.TP
> +.BI "-A\fR,\fB --fw-accept "
> +Generate a firmware acceptance empty capsule
> +
> +.TP
> +.BI "-R\fR,\fB --fw-revert "
> +Generate a firmware revert empty capsule
> +
>  .TP
>  .BR -h ", " --help
>  Print a help message
> diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> index d63b831443..072a4b5598 100644
> --- a/tools/eficapsule.h
> +++ b/tools/eficapsule.h
> @@ -41,6 +41,14 @@ typedef struct {
>   EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
>0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
>  
> +#define FW_ACCEPT_OS_GUID \
> + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \
> +  0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8)
> +
> +#define FW_REVERT_OS_GUID \
> + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \
> +  0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0)
> +
>  /* flags */
>  #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET  0x0001
>  
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index 5f74d23b9e..e8eb6b070d 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -29,7 +29,16 @@ static const char *tool_name = "mkeficapsule";
>  efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
>  efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
>  
> -static const char *opts_short = "g:i:I:v:p:c:m:dh";
> +static const char *opts_short = "g:i:I:v:p:c:m:dhAR";
> +
> +static bool empty_capsule;
> +static unsigned char capsule;
> +
> +enum {
> + CAPSULE_NORMAL_BLOB = 0,
> + CAPSULE_ACCEPT,
> + CAPSULE_REVERT,
> +} capsule_type;
>  
>  static struct option options[] = {
>   {"guid", required_argument, NULL, 'g'},
> @@ -39,24 +48,47 @@ static struct option options[] = {
>   {"certificate", required_argument, NULL, 'c'},
>   {"monotonic-count", required_argument, NULL, 'm'},
>   {"dump-sig", no_argument, NULL, 'd'},
> + {"fw-accept", no_argument, NULL, 'A'},
> + {"fw-revert", no_argument, NULL, 'R'},
>   {"help", no_argument, NULL, 'h'},
>   {NULL, 0, NULL, 0},
>  };
>  
>  static void print_usage(void)
>  {
> - fprint

Re: [PATCH v7 0/9] enable menu-driven UEFI variable maintenance

2022-06-14 Thread Takahiro Akashi
On Mon, Jun 13, 2022 at 06:38:44PM +0900, Masahisa Kojima wrote:
> This series add the menu-driven UEFI boot variable maintenance
> and removable media support in bootmenu.
> 
> Different from previous version, thie series adds a new U-Boot
> command "efimenu" to invoke the UEFI boot-related variable
> maintenance menu.

Thanks.
I'd like to give this command a more *specific* name rather than
just "menu" :)
For example, eficontrol or eficonfig.

The followings are my comments mostly from user's perspective (or
user-friendliness). So you may take them as improvements.

* make menuconfig, "provide menu-driven uefi variables maintenance feature"
  Please add the command name, so "efimenu - ..."
* the command can lead to a segmentation fault. I see it on sandbox.
  efi_init_obj_list() must always be called at the beginning.
* If no boot option is defined yet, "Edit/Order/Delete" menu's simply
  return to the top menu. I expect some (error) message here.
* This may happen even at "Add" if there is no block device.
* Boot options without file paths (mostly for removable disks)
  appear in "Change Order" only if "bootmenu" is executed beforehand.
  This looks weird.
* Some menu's have "Quit", others not.
  In some menu's, "Quit" means "quit without change" which is equivalent
  to "Esc". It looks a bit inconsistent.
* Some menu's have "Save", others not.
  For instance, "Change Order" should have explicit "Save" so that user may
  cancel the change.
* "Add"
  - The header line is "Edit Boot Option". -> Add Boot Option
  - Users may want to add an additional device path, especially for initrd.
* "Edit"
  - The header line is "Select Boot Order". -> Select Boot Option
  - If "Description" is selected, I expect the current value is
shown at editing screen.
  - If "File" is selected, I expect I can start with the last component
(i.e. a file path). This might be arguable, though.
  - Users may want to have a short-form path.
  - Users may want to have a file path without a device media path.
Now those variants for device path are acceptable in U-Boot implementation.
* "Change Boot Order"
  - Users may want to remove a boot option (for a removable disk) which
is automatically inserted by "bootmenu" from BootOrder.
(The given boot option may still exist as a variable.)
  - As I said above, "Save" and "Quit" should be shown.
* "Delete"
  - The header line is "Select Boot Order". -> Delete Boot Option

-Takahiro Akashi


> Note that menu-driven UEFI Secure Boot key management patch series
> will follow.
> 
> [Major Changes]
> - rebased to v2022.07-rc4
> - there is detailed changelog in each commit
> 
> Masahisa Kojima (9):
>   efi_loader: expose END device path node
>   efimenu: menu-driven addition of UEFI boot option
>   efimenu: add "Edit Boot Option" menu entry
>   menu: add KEY_PLUS and KEY_MINUS handling
>   efimenu: add "Change Boot Order" menu entry
>   efimenu: add "Delete Boot Option" menu entry
>   bootmenu: add removable media entries
>   doc:bootmenu: add description for UEFI boot support
>   doc:efimenu: add documentation for efimenu command
> 
>  cmd/Kconfig  |7 +
>  cmd/Makefile |1 +
>  cmd/bootmenu.c   |   99 +-
>  cmd/efimenu.c| 1824 ++
>  common/menu.c|6 +
>  doc/usage/cmd/bootmenu.rst   |   74 ++
>  doc/usage/cmd/efimenu.rst|   50 +
>  doc/usage/index.rst  |1 +
>  include/efi_loader.h |   63 ++
>  include/efi_menu.h   |   91 ++
>  include/menu.h   |2 +
>  lib/efi_loader/efi_boottime.c|   52 +-
>  lib/efi_loader/efi_console.c |   78 ++
>  lib/efi_loader/efi_device_path.c |2 +-
>  lib/efi_loader/efi_disk.c|   11 +
>  lib/efi_loader/efi_file.c|   75 +-
>  16 files changed, 2385 insertions(+), 51 deletions(-)
>  create mode 100644 cmd/efimenu.c
>  create mode 100644 doc/usage/cmd/efimenu.rst
>  create mode 100644 include/efi_menu.h
> 
> -- 
> 2.17.1
> 


Re: [PATCH] tools: binman: install btool

2022-06-14 Thread Tom Rini
On Wed, Jun 15, 2022 at 12:34:17AM +0300, Alper Nebi Yasak wrote:
> On 14/06/2022 13:42, Peng Fan (OSS) wrote:
> > From: Peng Fan 
> > 
> > btool is needed after install binman to system.
> > 
> > Signed-off-by: Peng Fan 
> > ---
> 
> Reviewed-by: Alper Nebi Yasak 
> 
> > Tom, Simon, Alper
> >   This is a bug fix, if possible, please pick it up.

I'll put it in my queue, thanks.

-- 
Tom


signature.asc
Description: PGP signature


RE: [PATCH 7/8] binman_sym: guard with CONFIG_IS_ENABLED(BINMAN_SYMBOLS)

2022-06-14 Thread Peng Fan
> Subject: Re: [PATCH 7/8] binman_sym: guard with
> CONFIG_IS_ENABLED(BINMAN_SYMBOLS)
> 
> On 13/06/2022 05:34, Peng Fan (OSS) wrote:
> > 在 2022/6/11 20:44, Alper Nebi Yasak 写道:
> >> CONFIG_IS_ENABLED(BINMAN) doesn't work, but
> IS_ENABLED(CONFIG_BINMAN)
> >> worked for me. I see all 8 symbols in spl/u-boot-spl.sym. I can send
> >> you a git branch if you want?
> >
> > But now with your suggestion, that means all i.MX8M boards should use
> > the i.MX binman symbols, that is not expected. The i.MX driver code is
> > expected to support w/o i.MX binman symbols.
> 
> In my series I'll add a macro like BINMAN_SYMS_OK that is true if binman wrote
> the declared symbols, and false if it didn't. Then you can check 'if
> (BINMAN_SYMS_OK)' to decide if the driver should use the symbols.
> It'll take a day or two for me to test and send. If the macro isn't good 
> enough,
> maybe you can add a new config for the driver's binman symbols.

Thanks for helping, please also share me a git repo.

> 
> (Is there any i.MX8M board that won't have working symbols for ddr_fw files
> after this series?)

I think NO, but I still prefer symbols could be disabled on demand, some NXP
downstream validation boards not have symbols enabled.

Thanks,
Peng.


Re: [PATCH] tools: binman: install btool

2022-06-14 Thread Alper Nebi Yasak
On 14/06/2022 13:42, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> btool is needed after install binman to system.
> 
> Signed-off-by: Peng Fan 
> ---

Reviewed-by: Alper Nebi Yasak 

> Tom, Simon, Alper
>   This is a bug fix, if possible, please pick it up.
> 
>  tools/binman/setup.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/binman/setup.py b/tools/binman/setup.py
> index 5ed94abdaf9..9a9206eb044 100644
> --- a/tools/binman/setup.py
> +++ b/tools/binman/setup.py
> @@ -5,7 +5,7 @@ setup(name='binman',
>version='1.0',
>license='GPL-2.0+',
>scripts=['binman'],
> -  packages=['binman', 'binman.etype'],
> +  packages=['binman', 'binman.etype', 'binman.btool'],
>package_dir={'binman': ''},
>package_data={'binman': ['README.rst', 'entries.rst']},
>classifiers=['Environment :: Console',


Re: [PATCH v2] crypto/fsl: fsl_hash: Fix crash in flush dcache

2022-06-14 Thread Fabio Estevam
Hi Gaurav,

On Thu, Jun 9, 2022 at 9:47 AM Gaurav Jain  wrote:

> +   flush_dcache_range((ulong)ctx->sg_tbl,
> +  (ulong)(ctx->sg_tbl) + (ctx->sg_num * 
> sizeof(struct sg_entry)));
> +   for (i = 0; i < ctx->sg_num; i++) {
> +   sg_entry_len = (sec_in32(&ctx->sg_tbl[i].len_flag) &
> +   SG_ENTRY_LENGTH_MASK);
> +   len += sg_entry_len;
> +   addr = sec_in32(&ctx->sg_tbl[i].addr_hi);
> +   addr = (addr << 32) | sec_in32(&ctx->sg_tbl[i].addr_lo);

This breaks the build:

arm: + ls1021aiot_qspi
1183+drivers/crypto/fsl/fsl_hash.c: In function 'caam_hash_finish':
1184+drivers/crypto/fsl/fsl_hash.c:150:30: error: left shift count >=
width of type [-Werror=shift-count-overflow]
1185+ 150 | addr = (addr << 32) | sec_in32(&ctx->sg_tbl[i].addr_lo);
1186+ | ^~
1187+cc1: all warnings being treated as errors

Please check:
https://source.denx.de/u-boot/custodians/u-boot-imx/-/jobs/448344


Re: [PATCH 7/8] binman_sym: guard with CONFIG_IS_ENABLED(BINMAN_SYMBOLS)

2022-06-14 Thread Alper Nebi Yasak
On 13/06/2022 05:34, Peng Fan (OSS) wrote:
> 在 2022/6/11 20:44, Alper Nebi Yasak 写道:
>> CONFIG_IS_ENABLED(BINMAN) doesn't work, but IS_ENABLED(CONFIG_BINMAN)
>> worked for me. I see all 8 symbols in spl/u-boot-spl.sym. I can send you
>> a git branch if you want?
> 
> But now with your suggestion, that means all i.MX8M boards should use 
> the i.MX binman symbols, that is not
> expected. The i.MX driver code is expected to support w/o i.MX binman 
> symbols.

In my series I'll add a macro like BINMAN_SYMS_OK that is true if binman
wrote the declared symbols, and false if it didn't. Then you can check
'if (BINMAN_SYMS_OK)' to decide if the driver should use the symbols.
It'll take a day or two for me to test and send. If the macro isn't good
enough, maybe you can add a new config for the driver's binman symbols.

(Is there any i.MX8M board that won't have working symbols for ddr_fw
files after this series?)


Re: [PATCH 7/8] binman_sym: guard with CONFIG_IS_ENABLED(BINMAN_SYMBOLS)

2022-06-14 Thread Alper Nebi Yasak
On 13/06/2022 05:31, Peng Fan (OSS) wrote:
>> 在 2022/6/11 0:47, Alper Nebi Yasak 写道:
>>> Looks like I have misunderstood things here a bit. CONFIG_BINMAN enables
>>> you to declare and use symbols. CONFIG_SPL/TPL_BINMAN_SYMBOLS declares
>>> certain symbols ('u_boot_any'). The name is a bit misleading, as if it
>>> enables support for using symbols, and that confused me.
>> I am not sure, but I think CONFIG_SPL/TPL_BINMAN_SYMBOLS are only for
>> certain symbols saying u_boot_any.
> 
> I mean I not think BINMAN_SYMBOLS are only for certtain symbols.

They are right now, your patch changes that.

I wasn't sure about changing it at first, but it makes more sense to me
now. I'll update my series and split things out:

- BINMAN: to run binman after build
- BINMAN_SYMBOLS: to enable binman symbols, binman_sym.h
- BINMAN_UBOOT_SYMBOLS: new config to declare u_boot_any symbols


Re: [PATCH v2] armv8: always use current exception level for TCR_ELx access

2022-06-14 Thread Mark Kettenis
> From: Andre Przywara 
> Date: Tue, 14 Jun 2022 00:11:10 +0100
> 
> Currently get_tcr() takes an "el" parameter, to select the proper
> version of the TCR_ELx system register.
> This is problematic in case of the Apple M1, since it runs with
> HCR_EL2.E2H fixed to 1, so TCR_EL2 is actually using the TCR_EL1 layout,
> and we get the wrong version.
> 
> For U-Boot's purposes the only sensible choice here is the current
> exception level, and indeed most callers treat it like that, so let's
> remove that parameter and read the current EL inside the function.
> This allows us to check for the E2H bit, and pretend it's EL1 in this
> case.
> 
> There are two callers which don't care about the EL, and they pass 0,
> which looks wrong, but is irrelevant in these two cases, since we don't
> use the return value there. So the change cannot affect those two.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Mark Kettenis 
Tested-by: Mark Kettenis 

> ---
> Changelog v1 ... v2:
> - Give bit 34 a name, and also use that in start.S
> 
> Mark, can you please test this? The A53s I have here for a quick test
> are igorant of this patch ...
> 
>  arch/arm/cpu/armv8/cache_v8.c   | 28 +
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c |  4 ++--
>  arch/arm/cpu/armv8/start.S  |  2 +-
>  arch/arm/include/asm/armv8/mmu.h|  4 +++-
>  4 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 3de18c7675b..e4736e56436 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -39,8 +39,28 @@ DECLARE_GLOBAL_DATA_PTR;
>   *off:  FFF
>   */
>  
> -u64 get_tcr(int el, u64 *pips, u64 *pva_bits)
> +static int get_effective_el(void)
>  {
> + int el = current_el();
> +
> + if (el == 2) {
> + u64 hcr_el2;
> +
> + /*
> +  * If we are using the EL2&0 translation regime, the TCR_EL2
> +  * looks like the EL1 version, even though we are in EL2.
> +  */
> + __asm__ ("mrs %0, HCR_EL2\n" : "=r" (hcr_el2));
> + if (hcr_el2 & BIT(HCR_EL2_E2H_BIT))
> + return 1;
> + }
> +
> + return el;
> +}
> +
> +u64 get_tcr(u64 *pips, u64 *pva_bits)
> +{
> + int el = get_effective_el();
>   u64 max_addr = 0;
>   u64 ips, va_bits;
>   u64 tcr;
> @@ -115,7 +135,7 @@ static u64 *find_pte(u64 addr, int level)
>  
>   debug("addr=%llx level=%d\n", addr, level);
>  
> - get_tcr(0, NULL, &va_bits);
> + get_tcr(NULL, &va_bits);
>   if (va_bits < 39)
>   start_level = 1;
>  
> @@ -343,7 +363,7 @@ __weak u64 get_page_table_size(void)
>   u64 va_bits;
>   int start_level = 0;
>  
> - get_tcr(0, NULL, &va_bits);
> + get_tcr(NULL, &va_bits);
>   if (va_bits < 39)
>   start_level = 1;
>  
> @@ -415,7 +435,7 @@ __weak void mmu_setup(void)
>   setup_all_pgtables();
>  
>   el = current_el();
> - set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
> + set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
> MEMORY_ATTRIBUTES);
>  
>   /* enable the mmu */
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index 253008a9c13..c989a43cbeb 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -454,7 +454,7 @@ static inline void early_mmu_setup(void)
>  
>   /* point TTBR to the new table */
>   set_ttbr_tcr_mair(el, gd->arch.tlb_addr,
> -   get_tcr(el, NULL, NULL) &
> +   get_tcr(NULL, NULL) &
> ~(TCR_ORGN_MASK | TCR_IRGN_MASK),
> MEMORY_ATTRIBUTES);
>  
> @@ -609,7 +609,7 @@ static inline void final_mmu_setup(void)
>   invalidate_icache_all();
>  
>   /* point TTBR to the new table */
> - set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
> + set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
> MEMORY_ATTRIBUTES);
>  
>   set_sctlr(get_sctlr() | CR_M);
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index d328e8c08a1..28f0df13f0d 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -125,7 +125,7 @@ pie_fixup_done:
>   msr cptr_el3, xzr   /* Enable FP/SIMD */
>   b   0f
>  2:   mrs x1, hcr_el2
> - tbnzx1, #34, 1f /* HCR_EL2.E2H */
> + tbnzx1, #HCR_EL2_E2H_BIT, 1f/* HCR_EL2.E2H */
>   orr x1, x1, #HCR_EL2_AMO_EL2/* Route SErrors to EL2 */
>   msr hcr_el2, x1
>   set_vbar vbar_el2, x0
> diff --git a/arch/arm/include/asm/armv8/mmu.h 
> b/arch/arm/include/asm/armv8/mmu.h
> index c36b2cf5a58..9f58cedb650 100644
> --- a/arch/arm/include/a

[PATCH v3] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-14 Thread Marek Vasut
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Use uclass_get_device_by_name()
V3: Reinstate the device-internal.h, needed for device_probe()
---
 .../imx8mm_data_modul_edm_sbc.c   |  9 +
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
 3 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..07d9effbbb9 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +105,15 @@ int board_init(void)
 
 int board_late_init(void)
 {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_get_device_by_name(UCLASS_MISC, "usb-hub@2c", &dev);
+   if (!ret)
+   device_probe(dev);
+
return 0;
 }
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
 CONFIG_DM_I2C=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h 
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0"   \
"dmo_preboot="  \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
-   "run dmo_usb_start_hub ; "  \
/* Attempt to start USB and Network console */  \
"run dmo_usb_cdc_acm_start ; "  \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; "   \
"fi ; " \
"fi\0"  \
-   "dmo_usb_start_hub="\
-   "i2c dev 1 ; "  \
-   /* Reset the USB USB */ \
-   "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
-   "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */   \
-   /* Write chunks of descriptor into the USB HUB */   \
-   "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
-   "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
-   "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
-   "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; "   \
-   "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
-   "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
-   "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; "   \
-   "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
-   "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
-   "mw.l 0x7e1010 0x6900 ; "   \
-   "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; "   \
-   "mw.l 0x7e1000 0x0101 ; "   \
-   "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
-- 
2.35.1



[PATCH v2] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-14 Thread Marek Vasut
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Use uclass_get_device_by_name()
---
 .../imx8mm_data_modul_edm_sbc.c   |  8 
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
 3 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..1e20fb46fef 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -104,7 +104,15 @@ int board_init(void)
 
 int board_late_init(void)
 {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_get_device_by_name(UCLASS_MISC, "usb-hub@2c", &dev);
+   if (!ret)
+   device_probe(dev);
+
return 0;
 }
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
 CONFIG_DM_I2C=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h 
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0"   \
"dmo_preboot="  \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
-   "run dmo_usb_start_hub ; "  \
/* Attempt to start USB and Network console */  \
"run dmo_usb_cdc_acm_start ; "  \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; "   \
"fi ; " \
"fi\0"  \
-   "dmo_usb_start_hub="\
-   "i2c dev 1 ; "  \
-   /* Reset the USB USB */ \
-   "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
-   "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */   \
-   /* Write chunks of descriptor into the USB HUB */   \
-   "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
-   "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
-   "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
-   "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; "   \
-   "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
-   "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
-   "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; "   \
-   "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
-   "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
-   "mw.l 0x7e1010 0x6900 ; "   \
-   "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; "   \
-   "mw.l 0x7e1000 0x0101 ; "   \
-   "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
-- 
2.35.1



Re: [PATCH v3 8/8] board: gw_ventana: enable MV88E61XX DSA support

2022-06-14 Thread Vladimir Oltean
Hi Tim,

On Tue, Jun 14, 2022 at 10:00:57AM -0700, Tim Harvey wrote:
> Vladimir,
> 
> I'm not sure if you've had a chance to look at this latest patch
> revision yet. I believe above is what you were describing as the
> correct way to do this (without modifying the Linux driver and
> improving bindings)
> 
> Best Regards,
> 
> Tim

I'm currently on vacation but I'm slowly working through my inbox.
This is certainly one of the reasonable ways of doing things, but it
will require modifying the mv88e6xxx Linux driver to support an "mdios"
subnode (something which nobody should object against, I believe).
I'll follow up with more comments when I get to these patches.

Re: [PATCH 2/2] rockchip: rk3399: enable spl-fifo-mode for sdmmc only when needed

2022-06-14 Thread Jerome Forissier



On 6/9/22 08:23, Jerome Forissier wrote:
> Commit 5c606ca35c42 ("rockchip: rk3399: enable spl-fifo-mode for sdmmc")
> mentions that the RK3399 SoC can't do DMA between SDMMC and SRAM.
> According to the TRM "7.3.2 Embedded SRAM access path" [1], only the
> 8KB SRAM at 0xff3b (INTMEM1) is in this situation. The 192KB SRAM
> can be accessed by both DMA controllers.
> 
> Assuming the only use case for writing from MMC to INTMEM1 is loading
> a FIT image, and with the introduction of a temporary buffer for that
> purpose (CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE, which is required
> anyways to ensure the destination boundaries are enforced), then
> spl-fifo-mode is not needed anymore and DMA can be enabled safely.
> 
> Link: [1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf
> CC: Deepak Das 
> Signed-off-by: Jerome Forissier 
> ---
>  arch/arm/dts/rk3399-u-boot.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 716b9a433a..a1b6d6f007 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -124,8 +124,10 @@
>  &sdmmc {
>   u-boot,dm-pre-reloc;
>  
> +#ifndef CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE

Oops, that should rather be:

+#if (CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE == 0)

>   /* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
>   u-boot,spl-fifo-mode;
> +#endif
>  };
>  
>  &spi1 {


Re: [PATCH] dtoc: Update test_src_scan.py for new tegra compatibles

2022-06-14 Thread Tom Rini
On Tue, Jun 14, 2022 at 02:00:48PM -0400, Tom Rini wrote:

> This test was written to match up with the list of compatibles in
> drivers/i2c/tegra_i2c.c so adding another one requires the test to be
> updated to match.
> 
> Fixes: 0d2105ae5e32 ("arm: tegra: Update some DT compatibles")
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] dtoc: Update test_src_scan.py for new tegra compatibles

2022-06-14 Thread Tom Rini
This test was written to match up with the list of compatibles in
drivers/i2c/tegra_i2c.c so adding another one requires the test to be
updated to match.

Fixes: 0d2105ae5e32 ("arm: tegra: Update some DT compatibles")
Signed-off-by: Tom Rini 
---
 tools/dtoc/test_src_scan.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/dtoc/test_src_scan.py b/tools/dtoc/test_src_scan.py
index bdfa669d816f..f93cd7f5a3a9 100644
--- a/tools/dtoc/test_src_scan.py
+++ b/tools/dtoc/test_src_scan.py
@@ -151,6 +151,7 @@ class TestSrcScan(unittest.TestCase):
 self.assertEqual('UCLASS_I2C', drv.uclass_id)
 self.assertEqual(
 {'nvidia,tegra114-i2c': 'TYPE_114',
+ 'nvidia,tegra124-i2c': 'TYPE_114',
  'nvidia,tegra20-i2c': 'TYPE_STD',
  'nvidia,tegra20-i2c-dvc': 'TYPE_DVC'}, drv.compat)
 self.assertEqual('i2c_bus', drv.priv)
-- 
2.25.1



Re: Pull request, u-boot-tegra/master

2022-06-14 Thread Tom Rini
On Tue, Jun 14, 2022 at 01:24:13PM -0400, Tom Rini wrote:
> On Tue, Jun 14, 2022 at 09:05:11AM -0700, Tom Warren wrote:
> 
> > Tom,
> > 
> > Please pull u-boot-tegra/master into U-Boot/master. Thanks.
> > 
> > The following changes since commit 92a8bc6b419f548230f10a924db2b3ef10a5edad:
> > 
> >   Merge tag 'efi-2022-07-rc5' of
> > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-06-13 09:33:37
> > -0400)
> > 
> > are available in the git repository at:
> > 
> >   https://source.denx.de/u-boot/custodians/u-boot-tegra.git master
> > 
> > for you to fetch changes up to 8f27bf114ef48e681f00fcb38ad48d4ab581d0ca:
> > 
> >   board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt
> > (2022-06-13 15:31:15 -0700)
> > 
> 
> Applied to u-boot/master, thanks!

That said, please put things through CI before sending a PR.  I did a
quick local build test, and found a warning being introduced because of
a missing include.  I fixed that and figured it was enough, which is on
me.  Next up:
commit 0d2105ae5e32ef5c87246054b2638fe50e62448c
Author: Peter Robinson 
Date:   Tue May 3 09:32:54 2022 +0100   
   
arm: tegra: Update some DT compatibles

breaks the dtoc tests:
https://source.denx.de/u-boot/u-boot/-/jobs/448215
and I'm going to fix that momentarily.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] tbs2910: Convert to DM_SERIAL

2022-06-14 Thread Soeren Moch




On 14.06.22 18:27, Fabio Estevam wrote:

On Sat, Mar 19, 2022 at 10:31 AM Fabio Estevam  wrote:


Fabio, will you sync the imx6qdl.dtsi changes to linux?
Or how is this supposed to keep in sync?

Yes, I plan to submit these imx6qdl.dtsi  changes (and similar changes
to the other  i.MX dtsi files too) to the mainline kernel.

I will do it after 5.18-rc1 is out and will keep you on Cc when I submit it.

I missed the last cycle, but just sent the two patches upstream:

http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751353.html

http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751354.html

Yes, I saw your patches.

Thanks,
Soeren


Regards,

Fabio Estevam




Re: [PATCH v3 0/3] usb: add isp1760 hcd support

2022-06-14 Thread Rui Miguel Silva
Hi *,
On Wed, May 25, 2022 at 02:22:48PM +0100, Rui Miguel Silva wrote:
> Add support for the usb isp1760 host controller family, which
> for example is present in MPS3 FPGA board from Arm (isp1763).
> 
> First we move some helper functions and defines to a more
> common place to be shared by several urb users. (patch 1/3)
> 
> Then add the driver itself, is a ported version of the kernel
> actual driver, which I am also the maintainer. (patch 2/3)
> 
> And last, enable it for the corstone1000 platform that uses
> that MPS3 board for its implementation (patch 3/3).
>

Any chance this series get some feedback?

Thanks in advance,

Cheers,
  Rui

> 
> Cheers,
>Rui
> 
> v2[3] -> v3:
> - when you think you have amend commit and fix stay
>   uncommitted.
>   s/[HC_FIELD_MAX] = {};/[HC_FIELD_MAX] = {},/
> v1[0] -> v2:
> - gentle ping
> - merge fix from kernel upstream [1]
> 
> PS: This should go on top of the corstone1000 platform enable
> series [2]
> 
> 0: 
> https://lore.kernel.org/u-boot/20220512142016.2025129-1-rui.si...@linaro.org/
> 1: 
> https://lore.kernel.org/linux-usb/20220516091424.391209-1-linus.wall...@linaro.org/
> 2: 
> https://lore.kernel.org/u-boot/20220511095541.1461937-1-rui.si...@linaro.org/T/#t
> 3: 
> https://lore.kernel.org/u-boot/20220523090119.1212016-1-rui.si...@linaro.org/
> 
> Rui Miguel Silva (3):
>   usb: common: move urb code to common
>   usb: add isp1760 family driver
>   corstone1000: enable isp1763 usb controller and mmc
> 
>  Makefile  |1 +
>  configs/corstone1000_defconfig|3 +
>  drivers/usb/Kconfig   |2 +
>  drivers/usb/common/Makefile   |3 +
>  drivers/usb/common/usb_urb.c  |  160 ++
>  drivers/usb/host/r8a66597-hcd.c   |   30 +-
>  drivers/usb/isp1760/Kconfig   |   12 +
>  drivers/usb/isp1760/Makefile  |6 +
>  drivers/usb/isp1760/isp1760-core.c|  380 +++
>  drivers/usb/isp1760/isp1760-core.h|   96 +
>  drivers/usb/isp1760/isp1760-hcd.c | 2477 +
>  drivers/usb/isp1760/isp1760-hcd.h |   81 +
>  drivers/usb/isp1760/isp1760-if.c  |  125 +
>  drivers/usb/isp1760/isp1760-regs.h|  292 ++
>  drivers/usb/isp1760/isp1760-uboot.c   |   75 +
>  drivers/usb/isp1760/isp1760-uboot.h   |   27 +
>  drivers/usb/musb-new/musb_core.c  |2 +-
>  drivers/usb/musb-new/musb_host.c  |2 +-
>  drivers/usb/musb-new/musb_host.h  |2 +-
>  drivers/usb/musb-new/musb_uboot.c |   38 +-
>  drivers/usb/musb-new/musb_uboot.h |2 +-
>  include/configs/corstone1000.h|6 +
>  .../linux/usb/usb_urb_compat.h|   47 +-
>  include/usb_defs.h|   32 +
>  24 files changed, 3825 insertions(+), 76 deletions(-)
>  create mode 100644 drivers/usb/common/usb_urb.c
>  create mode 100644 drivers/usb/isp1760/Kconfig
>  create mode 100644 drivers/usb/isp1760/Makefile
>  create mode 100644 drivers/usb/isp1760/isp1760-core.c
>  create mode 100644 drivers/usb/isp1760/isp1760-core.h
>  create mode 100644 drivers/usb/isp1760/isp1760-hcd.c
>  create mode 100644 drivers/usb/isp1760/isp1760-hcd.h
>  create mode 100644 drivers/usb/isp1760/isp1760-if.c
>  create mode 100644 drivers/usb/isp1760/isp1760-regs.h
>  create mode 100644 drivers/usb/isp1760/isp1760-uboot.c
>  create mode 100644 drivers/usb/isp1760/isp1760-uboot.h
>  rename drivers/usb/musb-new/usb-compat.h => 
> include/linux/usb/usb_urb_compat.h (59%)
> 
> -- 
> 2.36.1
> 


Re: Pull request, u-boot-tegra/master

2022-06-14 Thread Tom Rini
On Tue, Jun 14, 2022 at 09:05:11AM -0700, Tom Warren wrote:

> Tom,
> 
> Please pull u-boot-tegra/master into U-Boot/master. Thanks.
> 
> The following changes since commit 92a8bc6b419f548230f10a924db2b3ef10a5edad:
> 
>   Merge tag 'efi-2022-07-rc5' of
> https://source.denx.de/u-boot/custodians/u-boot-efi (2022-06-13 09:33:37
> -0400)
> 
> are available in the git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-tegra.git master
> 
> for you to fetch changes up to 8f27bf114ef48e681f00fcb38ad48d4ab581d0ca:
> 
>   board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt
> (2022-06-13 15:31:15 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 8/8] board: gw_ventana: enable MV88E61XX DSA support

2022-06-14 Thread Tim Harvey
On Mon, May 23, 2022 at 11:26 AM Tim Harvey  wrote:
>
> Add MV88E61XX DSA support:
>  - update dt: U-Boot dsa driver requires different device-tree syntax
>than the linux driver in order to link the dsa ports to the mdio bus.
>  - update defconfig
>  - replace mv88e61xx_hw_reset weak override with board_phy_config support
>for mv88e61xx configuration that is outside the scope of the DSA driver
>
> Signed-off-by: Tim Harvey 
> ---
> v3:
>  - move mdio's mdio@0 subnode
> v2: no changes
> ---
>  arch/arm/dts/imx6qdl-gw5904.dtsi| 41 
>  board/gateworks/gw_ventana/gw_ventana.c | 50 +
>  configs/gwventana_gw5904_defconfig  |  7 ++--
>  3 files changed, 62 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm/dts/imx6qdl-gw5904.dtsi 
> b/arch/arm/dts/imx6qdl-gw5904.dtsi
> index 286c7a9924c2..1b2f70d1ccb2 100644
> --- a/arch/arm/dts/imx6qdl-gw5904.dtsi
> +++ b/arch/arm/dts/imx6qdl-gw5904.dtsi
> @@ -219,6 +219,33 @@
> compatible = "marvell,mv88e6085";
> reg = <0>;
>
> +   mdios {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   mdio@0 {
> +   reg = <0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   sw_phy0: ethernet-phy@0 {
> +   reg = <0x0>;
> +   };
> +
> +   sw_phy1: ethernet-phy@1 {
> +   reg = <0x1>;
> +   };
> +
> +   sw_phy2: ethernet-phy@2 {
> +   reg = <0x2>;
> +   };
> +
> +   sw_phy3: ethernet-phy@3 {
> +   reg = <0x3>;
> +   };
> +   };
> +   };
> +

Vladimir,

I'm not sure if you've had a chance to look at this latest patch
revision yet. I believe above is what you were describing as the
correct way to do this (without modifying the Linux driver and
improving bindings)

Best Regards,

Tim

> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -226,27 +253,41 @@
> port@0 {
> reg = <0>;
> label = "lan4";
> +   phy-mode = "internal";
> +   phy-handle = <&sw_phy0>;
> };
>
> port@1 {
> reg = <1>;
> label = "lan3";
> +   phy-mode = "internal";
> +   phy-handle = <&sw_phy1>;
> };
>
> port@2 {
> reg = <2>;
> label = "lan2";
> +   phy-mode = "internal";
> +   phy-handle = <&sw_phy2>;
> };
>
> port@3 {
> reg = <3>;
> label = "lan1";
> +   phy-mode = "internal";
> +   phy-handle = <&sw_phy3>;
> };
>
> port@5 {
> reg = <5>;
> label = "cpu";
> ethernet = <&fec>;
> +   phy-mode = "rgmii-id";
> +
> +   fixed-link {
> +   speed = <1000>;
> +   full-duplex;
> +   };
> };
> };
> };
> diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
> b/board/gateworks/gw_ventana/gw_ventana.c
> index c06630a66b66..bef3f7ef0d2b 100644
> --- a/board/gateworks/gw_ventana/gw_ventana.c
> +++ b/board/gateworks/gw_ventana/gw_ventana.c
> @@ -68,44 +68,30 @@ int board_phy_config(struct phy_device *phydev)
> phy_write(phydev, MDIO_DEVAD_NONE, 14, val);
> }
>
> +   /* Fixed PHY: for GW5904/GW5909 this is Marvell

Re: [PATCH 8/8] gw_ventana: Migrate to using CONFIG_EXTRA_ENV_TEXT

2022-06-14 Thread Tim Harvey
On Tue, Jun 14, 2022 at 9:18 AM Tom Rini  wrote:
>
> On Tue, Jun 14, 2022 at 09:14:03AM -0700, Tim Harvey wrote:
> > On Mon, Jun 13, 2022 at 7:57 PM Tom Rini  wrote:
> > >
> > > Move the environment text over from being set via
> > > CONFIG_EXTRA_ENV_SETTINGS in include/configs/gw_ventana.h and over
> > > to plain text in board/gateworks/gw_ventana/gw_ventana.env.  This lets
> > > us drop CONFIG_EXTRA_ENV_SETTINGS_COMMON as everything resides in a
> > > single environment file now.
> > >
> > > Cc: Tim Harvey 
> > > Signed-off-by: Tom Rini 
> > > ---
> > >  board/gateworks/gw_ventana/gw_ventana.env | 145 +
> > >  include/configs/gw_ventana.h  | 148 --
> > >  2 files changed, 145 insertions(+), 148 deletions(-)
> > >  create mode 100644 board/gateworks/gw_ventana/gw_ventana.env
> > >
> > > diff --git a/board/gateworks/gw_ventana/gw_ventana.env 
> > > b/board/gateworks/gw_ventana/gw_ventana.env
> > > new file mode 100644
> > > index ..9a316c74f215
> > > --- /dev/null
> > > +++ b/board/gateworks/gw_ventana/gw_ventana.env
> > > @@ -0,0 +1,145 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * Copyright (C) 2013 Gateworks Corporation
> > > + */
> > > +
> > > +splashpos=m,m
> > > +splashimage=CONFIG_SYS_LOAD_ADDR
> > > +usb_pgood_delay=2000
> > > +console=ttymxc1
> > > +bootdevs=usb mmc sata flash
> > > +hwconfig=_UNKNOWN_
> > > +
> > > +disk=0
> > > +part=1
> > > +
> > > +fdt_high=0x
> > > +fdt_addr=0x1800
> > > +initrd_high=0x
> > > +fixfdt=fdt addr ${fdt_addr}
> > > +bootdir=boot
> > > +loadfdt=
> > > +   if ${fsload} ${fdt_addr} ${bootdir}/${fdt_file}; then
> > > +   echo Loaded DTB from ${bootdir}/${fdt_file};
> > > +   run fixfdt;
> > > +   elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file1}; then
> > > +   echo Loaded DTB from ${bootdir}/${fdt_file1};
> > > +   run fixfdt;
> > > +   elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file2}; then
> > > +   echo Loaded DTB from ${bootdir}/${fdt_file2};
> > > +   run fixfdt;
> > > +   fi
> > > +
> > > +fs=ext4
> > > +script=6x_bootscript-ventana
> > > +loadscript=
> > > +   if ${fsload} ${loadaddr} ${bootdir}/${script}; then
> > > +   source ${loadaddr};
> > > +   fi
> > > +
> > > +uimage=uImage
> > > +mmc_root=mmcblk0p1
> > > +mmc_boot=
> > > +   setenv fsload "${fs}load mmc ${disk}:${part}";
> > > +   mmc dev ${disk} && mmc rescan &&
> > > +   setenv dtype mmc; run loadscript;
> > > +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > > +   setenv bootargs console=${console},${baudrate}
> > > +   root=/dev/${mmc_root} rootfstype=${fs}
> > > +   rootwait rw ${video} ${extra};
> > > +   if run loadfdt; then
> > > +   bootm ${loadaddr} - ${fdt_addr};
> > > +   else
> > > +   bootm;
> > > +   fi;
> > > +   fi
> > > +
> > > +sata_boot=
> > > +   setenv fsload "${fs}load sata ${disk}:${part}";
> > > +   sata init &&
> > > +   setenv dtype sata; run loadscript;
> > > +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > > +   setenv bootargs console=${console},${baudrate}
> > > +   root=/dev/sda1 rootfstype=${fs}
> > > +   rootwait rw ${video} ${extra};
> > > +   if run loadfdt; then
> > > +   bootm ${loadaddr} - ${fdt_addr};
> > > +   else
> > > +   bootm;
> > > +   fi;
> > > +   fi
> > > +
> > > +usb_boot=
> > > +   setenv fsload "${fs}load usb ${disk}:${part}";
> > > +   usb start && usb dev ${disk} &&
> > > +   setenv dtype usb; run loadscript;
> > > +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > > +   setenv bootargs console=${console},${baudrate}
> > > +   root=/dev/sda1 rootfstype=${fs}
> > > +   rootwait rw ${video} ${extra};
> > > +   if run loadfdt; then
> > > +   bootm ${loadaddr} - ${fdt_addr};
> > > +   else
> > > +   bootm;
> > > +   fi;
> > > +   fi
> > > +
> > > +#ifdef CONFIG_SPI_FLASH
> > > +image_os=ventana/openwrt-imx6-imx6q-gw5400-a-squashfs.bin
> > > +image_uboot=ventana/u-boot_spi.imx
> > > +
> > > +spi_koffset=0x9
> > > +spi_klen=0x20
> > > +
> > > +spi_updateuboot=echo Updating uboot from
> > > +   ${serverip}:${image_uboot}...;
> > > +   tftpboot ${loadaddr} ${image_uboot} &&
> > > +   sf probe && sf erase 0 8 &&
> > > +   sf write ${loadaddr} 400 ${filesize}
> > > +spi_update=echo Updating OS from ${serverip}:${image_os}
> > > +   to ${spi_koffset} ...;
> > > +   tftp ${loadaddr} ${image_os} &&
> > > +   sf probe &&
> > > +   

Re: [PATCH] tbs2910: Convert to DM_SERIAL

2022-06-14 Thread Fabio Estevam
On Sat, Mar 19, 2022 at 10:31 AM Fabio Estevam  wrote:

> > Fabio, will you sync the imx6qdl.dtsi changes to linux?
> > Or how is this supposed to keep in sync?
>
> Yes, I plan to submit these imx6qdl.dtsi  changes (and similar changes
> to the other  i.MX dtsi files too) to the mainline kernel.
>
> I will do it after 5.18-rc1 is out and will keep you on Cc when I submit it.

I missed the last cycle, but just sent the two patches upstream:

http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751353.html

http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751354.html

Regards,

Fabio Estevam


Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address

2022-06-14 Thread Stefan Herbrechtsmeier

Hi Michal,

Am 14.06.2022 um 17:49 schrieb Michal Simek:



On 6/14/22 17:34, Stefan Herbrechtsmeier wrote:

Hi,

Am 14.06.2022 um 15:03 schrieb Michal Simek:

Hi,

On 6/13/22 11:02, Stefan Herbrechtsmeier wrote:

[CAUTION: External Email]

Hi Michal,

Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier:

Hi Michal,

Am 13.06.2022 um 09:20 schrieb Michal Simek:

Hi,

On 6/10/22 18:48, Xavier Drudis Ferran wrote:
El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier 
deia:

Hi Michal,

what is the default entry address for the aft / bl31.bin?

I have a bl31.bin with an entry address of 0x1000 and this is 
inside

the
BSS.



Me too, load address at 0x1000, but for me in SPL text, not BSS.

I have a litle customized, a little old TF-A  for rk3399 / Rock pi 4
loading at address 0 with entry at 0x1000.

But include/configs/rk3399_common.h sets my
CONFIG_SPL_BSS_START_ADDR=0x40, away from harm.
I had problems booting anyway.

Now I can load U-Boot from MMC with these patches
https://lists.denx.de/pipermail/u-boot/2022-June/485497.html

In particular
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000

This is defined in arch/arm/mach-rockchip/Kconfig and says it's
to avoid conflicts with SPL text area, not BSS

But I found other boards with 
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000,

so I thought some low addresses where normal. I don't know.

I had to modify the code loading from SPI because, unlike MMC 
code, it
thought address 0 meant no destination (I can send those patches 
when

I have them cleaner if anyone wants them).

I just realised that I have CONFIG_SPL_TEXT_BASE=0x0.  I'm not 
finding

where that's defined, maybe it's simply because it's not defined
anywhere, so maybe the solution for me would be setting
CONFIG_SPL_TEXT_BASE
to 0x1000 or something. Or maybe it needs to be at 0x0 because
it is bootrom who is loading it, and it won't look where I define 
it?

I can't remember whether I tried this.

Maybe you can try to look at the size of a file bl31_0x.bin
that is generated when you build U-boot with BL31 pointing at your
bl31.elf (check u-boot.its if that's not the name for you).

Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of 
load

property
in entry atf_1 of u-boot.its). This should leave a hole at the 
beginning

of U-Boot to make room for your TF-A, and leave BSS elsewhere.

The sources and build scripts for TF-A are public, so maybe one 
could
look at what's the criteria for putting images at different 
addresses?




I have no idea what rockchip has to do with memory layout on zynqmp.
Anyway SPL must be placed to OCM that's why text base is at 
0xfffc

where OCM starts and which is also default address where a53s starts.

TF-A can be placed to any address but address which I use in SPL flow
is 0xfffe5000. PetaLinux which uses FSBL is using different address
0xfffea000 which is default in TF-A.
In DDR I normally use end of low ddr locations. It means 0x7fxx.

And of course you can't place TFA to location which is used by SPL or
by u-boot or other SW.


Thanks for the information. I will check why our TF-A is linked to the
lower DDR and move it back to the default address.


The TF-A was build with debug flag [1]:

 > By default, the Arm-trusted firmware builds for OCM space at address
 > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, 
so by

 > default with DEBUG=1, it builds for DDR location 0x1000 with build
 > flag DEBUG=1 mentioned while building.

Either the CONFIG_SPL_BSS_START_ADDR or the default location of the 
TF-A

with DEBUG flag should be changed.

[1]
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware 



It is really question what should be default address with DEBUG=1.

I tried this

diff --git a/plat/xilinx/zynqmp/include/platform_def.h 
b/plat/xilinx/zynqmp/include/platform_def.h

index 9c1600a7b7e3..66bbf30a65a4 100644
--- a/plat/xilinx/zynqmp/include/platform_def.h
+++ b/plat/xilinx/zynqmp/include/platform_def.h
@@ -40,8 +40,8 @@
  # define BL31_BASE U(0xfffea000)
  # define BL31_LIMIT    U(0x1)
  #else
-# define BL31_BASE U(0x1000)
-# define BL31_LIMIT    U(0x7)
+# define BL31_BASE U(0xfff5a000)
+# define BL31_LIMIT    U(0x1)
  #endif
  #else
  # define BL31_BASE (ZYNQMP_ATF_MEM_BASE)


And with the latest TF-A this works fine.
No problem to change TF-A code to place it to different addresses. I 
think it should stay in OCM if possible or allocate space at the end 
of of low ddr address. It means any 0x7fxx address should be fine.

With any SPD on we won't be able to fit OCM anyway.


Thanks for your work. I think it should stay in OCM and we should use 
the lower DDR address for BSS.


that sort of mean that you want the change above to be upstream. Do you 
want me to send the patch or do you want to send it patch there?


Would 

Re: [PATCH 8/8] gw_ventana: Migrate to using CONFIG_EXTRA_ENV_TEXT

2022-06-14 Thread Tom Rini
On Tue, Jun 14, 2022 at 09:14:03AM -0700, Tim Harvey wrote:
> On Mon, Jun 13, 2022 at 7:57 PM Tom Rini  wrote:
> >
> > Move the environment text over from being set via
> > CONFIG_EXTRA_ENV_SETTINGS in include/configs/gw_ventana.h and over
> > to plain text in board/gateworks/gw_ventana/gw_ventana.env.  This lets
> > us drop CONFIG_EXTRA_ENV_SETTINGS_COMMON as everything resides in a
> > single environment file now.
> >
> > Cc: Tim Harvey 
> > Signed-off-by: Tom Rini 
> > ---
> >  board/gateworks/gw_ventana/gw_ventana.env | 145 +
> >  include/configs/gw_ventana.h  | 148 --
> >  2 files changed, 145 insertions(+), 148 deletions(-)
> >  create mode 100644 board/gateworks/gw_ventana/gw_ventana.env
> >
> > diff --git a/board/gateworks/gw_ventana/gw_ventana.env 
> > b/board/gateworks/gw_ventana/gw_ventana.env
> > new file mode 100644
> > index ..9a316c74f215
> > --- /dev/null
> > +++ b/board/gateworks/gw_ventana/gw_ventana.env
> > @@ -0,0 +1,145 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2013 Gateworks Corporation
> > + */
> > +
> > +splashpos=m,m
> > +splashimage=CONFIG_SYS_LOAD_ADDR
> > +usb_pgood_delay=2000
> > +console=ttymxc1
> > +bootdevs=usb mmc sata flash
> > +hwconfig=_UNKNOWN_
> > +
> > +disk=0
> > +part=1
> > +
> > +fdt_high=0x
> > +fdt_addr=0x1800
> > +initrd_high=0x
> > +fixfdt=fdt addr ${fdt_addr}
> > +bootdir=boot
> > +loadfdt=
> > +   if ${fsload} ${fdt_addr} ${bootdir}/${fdt_file}; then
> > +   echo Loaded DTB from ${bootdir}/${fdt_file};
> > +   run fixfdt;
> > +   elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file1}; then
> > +   echo Loaded DTB from ${bootdir}/${fdt_file1};
> > +   run fixfdt;
> > +   elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file2}; then
> > +   echo Loaded DTB from ${bootdir}/${fdt_file2};
> > +   run fixfdt;
> > +   fi
> > +
> > +fs=ext4
> > +script=6x_bootscript-ventana
> > +loadscript=
> > +   if ${fsload} ${loadaddr} ${bootdir}/${script}; then
> > +   source ${loadaddr};
> > +   fi
> > +
> > +uimage=uImage
> > +mmc_root=mmcblk0p1
> > +mmc_boot=
> > +   setenv fsload "${fs}load mmc ${disk}:${part}";
> > +   mmc dev ${disk} && mmc rescan &&
> > +   setenv dtype mmc; run loadscript;
> > +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > +   setenv bootargs console=${console},${baudrate}
> > +   root=/dev/${mmc_root} rootfstype=${fs}
> > +   rootwait rw ${video} ${extra};
> > +   if run loadfdt; then
> > +   bootm ${loadaddr} - ${fdt_addr};
> > +   else
> > +   bootm;
> > +   fi;
> > +   fi
> > +
> > +sata_boot=
> > +   setenv fsload "${fs}load sata ${disk}:${part}";
> > +   sata init &&
> > +   setenv dtype sata; run loadscript;
> > +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > +   setenv bootargs console=${console},${baudrate}
> > +   root=/dev/sda1 rootfstype=${fs}
> > +   rootwait rw ${video} ${extra};
> > +   if run loadfdt; then
> > +   bootm ${loadaddr} - ${fdt_addr};
> > +   else
> > +   bootm;
> > +   fi;
> > +   fi
> > +
> > +usb_boot=
> > +   setenv fsload "${fs}load usb ${disk}:${part}";
> > +   usb start && usb dev ${disk} &&
> > +   setenv dtype usb; run loadscript;
> > +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > +   setenv bootargs console=${console},${baudrate}
> > +   root=/dev/sda1 rootfstype=${fs}
> > +   rootwait rw ${video} ${extra};
> > +   if run loadfdt; then
> > +   bootm ${loadaddr} - ${fdt_addr};
> > +   else
> > +   bootm;
> > +   fi;
> > +   fi
> > +
> > +#ifdef CONFIG_SPI_FLASH
> > +image_os=ventana/openwrt-imx6-imx6q-gw5400-a-squashfs.bin
> > +image_uboot=ventana/u-boot_spi.imx
> > +
> > +spi_koffset=0x9
> > +spi_klen=0x20
> > +
> > +spi_updateuboot=echo Updating uboot from
> > +   ${serverip}:${image_uboot}...;
> > +   tftpboot ${loadaddr} ${image_uboot} &&
> > +   sf probe && sf erase 0 8 &&
> > +   sf write ${loadaddr} 400 ${filesize}
> > +spi_update=echo Updating OS from ${serverip}:${image_os}
> > +   to ${spi_koffset} ...;
> > +   tftp ${loadaddr} ${image_os} &&
> > +   sf probe &&
> > +   sf update ${loadaddr} ${spi_koffset} ${filesize}
> > +
> > +flash_boot=
> > +   if sf probe &&
> > +   sf read ${loadaddr} ${spi_koffset} ${spi_klen}; then
> > +   setenv bootargs console=${console},${baudrate}
> > +   root=/dev/mtdblock3
> > + 

Re: [PATCH 8/8] gw_ventana: Migrate to using CONFIG_EXTRA_ENV_TEXT

2022-06-14 Thread Tim Harvey
On Mon, Jun 13, 2022 at 7:57 PM Tom Rini  wrote:
>
> Move the environment text over from being set via
> CONFIG_EXTRA_ENV_SETTINGS in include/configs/gw_ventana.h and over
> to plain text in board/gateworks/gw_ventana/gw_ventana.env.  This lets
> us drop CONFIG_EXTRA_ENV_SETTINGS_COMMON as everything resides in a
> single environment file now.
>
> Cc: Tim Harvey 
> Signed-off-by: Tom Rini 
> ---
>  board/gateworks/gw_ventana/gw_ventana.env | 145 +
>  include/configs/gw_ventana.h  | 148 --
>  2 files changed, 145 insertions(+), 148 deletions(-)
>  create mode 100644 board/gateworks/gw_ventana/gw_ventana.env
>
> diff --git a/board/gateworks/gw_ventana/gw_ventana.env 
> b/board/gateworks/gw_ventana/gw_ventana.env
> new file mode 100644
> index ..9a316c74f215
> --- /dev/null
> +++ b/board/gateworks/gw_ventana/gw_ventana.env
> @@ -0,0 +1,145 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2013 Gateworks Corporation
> + */
> +
> +splashpos=m,m
> +splashimage=CONFIG_SYS_LOAD_ADDR
> +usb_pgood_delay=2000
> +console=ttymxc1
> +bootdevs=usb mmc sata flash
> +hwconfig=_UNKNOWN_
> +
> +disk=0
> +part=1
> +
> +fdt_high=0x
> +fdt_addr=0x1800
> +initrd_high=0x
> +fixfdt=fdt addr ${fdt_addr}
> +bootdir=boot
> +loadfdt=
> +   if ${fsload} ${fdt_addr} ${bootdir}/${fdt_file}; then
> +   echo Loaded DTB from ${bootdir}/${fdt_file};
> +   run fixfdt;
> +   elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file1}; then
> +   echo Loaded DTB from ${bootdir}/${fdt_file1};
> +   run fixfdt;
> +   elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file2}; then
> +   echo Loaded DTB from ${bootdir}/${fdt_file2};
> +   run fixfdt;
> +   fi
> +
> +fs=ext4
> +script=6x_bootscript-ventana
> +loadscript=
> +   if ${fsload} ${loadaddr} ${bootdir}/${script}; then
> +   source ${loadaddr};
> +   fi
> +
> +uimage=uImage
> +mmc_root=mmcblk0p1
> +mmc_boot=
> +   setenv fsload "${fs}load mmc ${disk}:${part}";
> +   mmc dev ${disk} && mmc rescan &&
> +   setenv dtype mmc; run loadscript;
> +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> +   setenv bootargs console=${console},${baudrate}
> +   root=/dev/${mmc_root} rootfstype=${fs}
> +   rootwait rw ${video} ${extra};
> +   if run loadfdt; then
> +   bootm ${loadaddr} - ${fdt_addr};
> +   else
> +   bootm;
> +   fi;
> +   fi
> +
> +sata_boot=
> +   setenv fsload "${fs}load sata ${disk}:${part}";
> +   sata init &&
> +   setenv dtype sata; run loadscript;
> +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> +   setenv bootargs console=${console},${baudrate}
> +   root=/dev/sda1 rootfstype=${fs}
> +   rootwait rw ${video} ${extra};
> +   if run loadfdt; then
> +   bootm ${loadaddr} - ${fdt_addr};
> +   else
> +   bootm;
> +   fi;
> +   fi
> +
> +usb_boot=
> +   setenv fsload "${fs}load usb ${disk}:${part}";
> +   usb start && usb dev ${disk} &&
> +   setenv dtype usb; run loadscript;
> +   if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> +   setenv bootargs console=${console},${baudrate}
> +   root=/dev/sda1 rootfstype=${fs}
> +   rootwait rw ${video} ${extra};
> +   if run loadfdt; then
> +   bootm ${loadaddr} - ${fdt_addr};
> +   else
> +   bootm;
> +   fi;
> +   fi
> +
> +#ifdef CONFIG_SPI_FLASH
> +image_os=ventana/openwrt-imx6-imx6q-gw5400-a-squashfs.bin
> +image_uboot=ventana/u-boot_spi.imx
> +
> +spi_koffset=0x9
> +spi_klen=0x20
> +
> +spi_updateuboot=echo Updating uboot from
> +   ${serverip}:${image_uboot}...;
> +   tftpboot ${loadaddr} ${image_uboot} &&
> +   sf probe && sf erase 0 8 &&
> +   sf write ${loadaddr} 400 ${filesize}
> +spi_update=echo Updating OS from ${serverip}:${image_os}
> +   to ${spi_koffset} ...;
> +   tftp ${loadaddr} ${image_os} &&
> +   sf probe &&
> +   sf update ${loadaddr} ${spi_koffset} ${filesize}
> +
> +flash_boot=
> +   if sf probe &&
> +   sf read ${loadaddr} ${spi_koffset} ${spi_klen}; then
> +   setenv bootargs console=${console},${baudrate}
> +   root=/dev/mtdblock3
> +   rootfstype=squashfs,jffs2
> +   ${video} ${extra};
> +   bootm;
> +   fi
> +#else
> +image_rootfs=openwrt-imx6-ventana-rootfs.ubi
> +nand_update=echo Updating NAND from ${serverip}:${image_rootfs}...;
> +   tftp ${loadaddr} ${image_rootfs} &&
> +   nand erase.part rootfs &&
> +  

Pull request, u-boot-tegra/master

2022-06-14 Thread Tom Warren
Tom,

Please pull u-boot-tegra/master into U-Boot/master. Thanks.

The following changes since commit 92a8bc6b419f548230f10a924db2b3ef10a5edad:

  Merge tag 'efi-2022-07-rc5' of
https://source.denx.de/u-boot/custodians/u-boot-efi (2022-06-13 09:33:37
-0400)

are available in the git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-tegra.git master

for you to fetch changes up to 8f27bf114ef48e681f00fcb38ad48d4ab581d0ca:

  board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt
(2022-06-13 15:31:15 -0700)


Marcel Ziswiler (1):
  board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt

Peter Robinson (3):
  ARM: tegra: XUSB padctl: Add new lines for errors
  pci: tegra: Update error prints with new lines
  arm: tegra: Update some DT compatibles

 arch/arm/mach-tegra/xusb-padctl-common.c | 12 ++--
 board/toradex/apalis-tk1/apalis-tk1.c| 19 +++
 board/toradex/apalis_t30/apalis_t30.c| 20 
 board/toradex/colibri_t20/colibri_t20.c  | 19 +++
 board/toradex/colibri_t30/colibri_t30.c  | 20 
 drivers/i2c/tegra_i2c.c  |  1 +
 drivers/pci/pci_tegra.c  |  4 ++--
 drivers/video/tegra124/dp.c  |  1 +
 8 files changed, 88 insertions(+), 8 deletions(-)


Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address

2022-06-14 Thread Michal Simek




On 6/14/22 17:34, Stefan Herbrechtsmeier wrote:

Hi,

Am 14.06.2022 um 15:03 schrieb Michal Simek:

Hi,

On 6/13/22 11:02, Stefan Herbrechtsmeier wrote:

[CAUTION: External Email]

Hi Michal,

Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier:

Hi Michal,

Am 13.06.2022 um 09:20 schrieb Michal Simek:

Hi,

On 6/10/22 18:48, Xavier Drudis Ferran wrote:

El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia:

Hi Michal,

what is the default entry address for the aft / bl31.bin?

I have a bl31.bin with an entry address of 0x1000 and this is inside
the
BSS.



Me too, load address at 0x1000, but for me in SPL text, not BSS.

I have a litle customized, a little old TF-A  for rk3399 / Rock pi 4
loading at address 0 with entry at 0x1000.

But include/configs/rk3399_common.h sets my
CONFIG_SPL_BSS_START_ADDR=0x40, away from harm.
I had problems booting anyway.

Now I can load U-Boot from MMC with these patches
https://lists.denx.de/pipermail/u-boot/2022-June/485497.html

In particular
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000

This is defined in arch/arm/mach-rockchip/Kconfig and says it's
to avoid conflicts with SPL text area, not BSS

But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000,
so I thought some low addresses where normal. I don't know.

I had to modify the code loading from SPI because, unlike MMC code, it
thought address 0 meant no destination (I can send those patches when
I have them cleaner if anyone wants them).

I just realised that I have CONFIG_SPL_TEXT_BASE=0x0.  I'm not finding
where that's defined, maybe it's simply because it's not defined
anywhere, so maybe the solution for me would be setting
CONFIG_SPL_TEXT_BASE
to 0x1000 or something. Or maybe it needs to be at 0x0 because
it is bootrom who is loading it, and it won't look where I define it?
I can't remember whether I tried this.

Maybe you can try to look at the size of a file bl31_0x.bin
that is generated when you build U-boot with BL31 pointing at your
bl31.elf (check u-boot.its if that's not the name for you).

Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load
property
in entry atf_1 of u-boot.its). This should leave a hole at the beginning
of U-Boot to make room for your TF-A, and leave BSS elsewhere.

The sources and build scripts for TF-A are public, so maybe one could
look at what's the criteria for putting images at different addresses?



I have no idea what rockchip has to do with memory layout on zynqmp.
Anyway SPL must be placed to OCM that's why text base is at 0xfffc
where OCM starts and which is also default address where a53s starts.

TF-A can be placed to any address but address which I use in SPL flow
is 0xfffe5000. PetaLinux which uses FSBL is using different address
0xfffea000 which is default in TF-A.
In DDR I normally use end of low ddr locations. It means 0x7fxx.

And of course you can't place TFA to location which is used by SPL or
by u-boot or other SW.


Thanks for the information. I will check why our TF-A is linked to the
lower DDR and move it back to the default address.


The TF-A was build with debug flag [1]:

 > By default, the Arm-trusted firmware builds for OCM space at address
 > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by
 > default with DEBUG=1, it builds for DDR location 0x1000 with build
 > flag DEBUG=1 mentioned while building.

Either the CONFIG_SPL_BSS_START_ADDR or the default location of the TF-A
with DEBUG flag should be changed.

[1]
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware 



It is really question what should be default address with DEBUG=1.

I tried this

diff --git a/plat/xilinx/zynqmp/include/platform_def.h 
b/plat/xilinx/zynqmp/include/platform_def.h

index 9c1600a7b7e3..66bbf30a65a4 100644
--- a/plat/xilinx/zynqmp/include/platform_def.h
+++ b/plat/xilinx/zynqmp/include/platform_def.h
@@ -40,8 +40,8 @@
  # define BL31_BASE U(0xfffea000)
  # define BL31_LIMIT    U(0x1)
  #else
-# define BL31_BASE U(0x1000)
-# define BL31_LIMIT    U(0x7)
+# define BL31_BASE U(0xfff5a000)
+# define BL31_LIMIT    U(0x1)
  #endif
  #else
  # define BL31_BASE (ZYNQMP_ATF_MEM_BASE)


And with the latest TF-A this works fine.
No problem to change TF-A code to place it to different addresses. I think it 
should stay in OCM if possible or allocate space at the end of of low ddr 
address. It means any 0x7fxx address should be fine.

With any SPD on we won't be able to fit OCM anyway.


Thanks for your work. I think it should stay in OCM and we should use the lower 
DDR address for BSS.


that sort of mean that you want the change above to be upstream. Do you want me 
to send the patch or do you want to send it patch there?


M


Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address

2022-06-14 Thread Stefan Herbrechtsmeier

Hi,

Am 14.06.2022 um 15:03 schrieb Michal Simek:

Hi,

On 6/13/22 11:02, Stefan Herbrechtsmeier wrote:

[CAUTION: External Email]

Hi Michal,

Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier:

Hi Michal,

Am 13.06.2022 um 09:20 schrieb Michal Simek:

Hi,

On 6/10/22 18:48, Xavier Drudis Ferran wrote:

El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia:

Hi Michal,

what is the default entry address for the aft / bl31.bin?

I have a bl31.bin with an entry address of 0x1000 and this is inside
the
BSS.



Me too, load address at 0x1000, but for me in SPL text, not BSS.

I have a litle customized, a little old TF-A  for rk3399 / Rock pi 4
loading at address 0 with entry at 0x1000.

But include/configs/rk3399_common.h sets my
CONFIG_SPL_BSS_START_ADDR=0x40, away from harm.
I had problems booting anyway.

Now I can load U-Boot from MMC with these patches
https://lists.denx.de/pipermail/u-boot/2022-June/485497.html

In particular
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000

This is defined in arch/arm/mach-rockchip/Kconfig and says it's
to avoid conflicts with SPL text area, not BSS

But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000,
so I thought some low addresses where normal. I don't know.

I had to modify the code loading from SPI because, unlike MMC code, it
thought address 0 meant no destination (I can send those patches when
I have them cleaner if anyone wants them).

I just realised that I have CONFIG_SPL_TEXT_BASE=0x0.  I'm not finding
where that's defined, maybe it's simply because it's not defined
anywhere, so maybe the solution for me would be setting
CONFIG_SPL_TEXT_BASE
to 0x1000 or something. Or maybe it needs to be at 0x0 because
it is bootrom who is loading it, and it won't look where I define it?
I can't remember whether I tried this.

Maybe you can try to look at the size of a file bl31_0x.bin
that is generated when you build U-boot with BL31 pointing at your
bl31.elf (check u-boot.its if that's not the name for you).

Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load
property
in entry atf_1 of u-boot.its). This should leave a hole at the 
beginning

of U-Boot to make room for your TF-A, and leave BSS elsewhere.

The sources and build scripts for TF-A are public, so maybe one could
look at what's the criteria for putting images at different addresses?



I have no idea what rockchip has to do with memory layout on zynqmp.
Anyway SPL must be placed to OCM that's why text base is at 0xfffc
where OCM starts and which is also default address where a53s starts.

TF-A can be placed to any address but address which I use in SPL flow
is 0xfffe5000. PetaLinux which uses FSBL is using different address
0xfffea000 which is default in TF-A.
In DDR I normally use end of low ddr locations. It means 0x7fxx.

And of course you can't place TFA to location which is used by SPL or
by u-boot or other SW.


Thanks for the information. I will check why our TF-A is linked to the
lower DDR and move it back to the default address.


The TF-A was build with debug flag [1]:

 > By default, the Arm-trusted firmware builds for OCM space at address
 > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by
 > default with DEBUG=1, it builds for DDR location 0x1000 with build
 > flag DEBUG=1 mentioned while building.

Either the CONFIG_SPL_BSS_START_ADDR or the default location of the TF-A
with DEBUG flag should be changed.

[1]
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware 



It is really question what should be default address with DEBUG=1.

I tried this

diff --git a/plat/xilinx/zynqmp/include/platform_def.h 
b/plat/xilinx/zynqmp/include/platform_def.h

index 9c1600a7b7e3..66bbf30a65a4 100644
--- a/plat/xilinx/zynqmp/include/platform_def.h
+++ b/plat/xilinx/zynqmp/include/platform_def.h
@@ -40,8 +40,8 @@
  # define BL31_BASE U(0xfffea000)
  # define BL31_LIMIT    U(0x1)
  #else
-# define BL31_BASE U(0x1000)
-# define BL31_LIMIT    U(0x7)
+# define BL31_BASE U(0xfff5a000)
+# define BL31_LIMIT    U(0x1)
  #endif
  #else
  # define BL31_BASE (ZYNQMP_ATF_MEM_BASE)


And with the latest TF-A this works fine.
No problem to change TF-A code to place it to different addresses. I 
think it should stay in OCM if possible or allocate space at the end of 
of low ddr address. It means any 0x7fxx address should be fine.

With any SPD on we won't be able to fit OCM anyway.


Thanks for your work. I think it should stay in OCM and we should use 
the lower DDR address for BSS.


Regards
  Stefan


[PATCH 5/5] configs: am62x_evm_r5: Add CONFIG_NR_DRAM_BANKS as done in a53 defconfig

2022-06-14 Thread Georgi Vlaev
Add CONFIG_NR_DRAM_BANKS from am62x_evm_a53_defconfig as this is
needed to calculate the size of DDR that is available.

Signed-off-by: Georgi Vlaev 
---
 configs/am62x_evm_r5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig
index 2e340cd6f416..deafb92fc142 100644
--- a/configs/am62x_evm_r5_defconfig
+++ b/configs/am62x_evm_r5_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_K3=y
 CONFIG_SYS_MALLOC_F_LEN=0x9000
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM625=y
 CONFIG_TARGET_AM625_R5_EVM=y
 CONFIG_DM_GPIO=y
-- 
2.30.2



[PATCH 4/5] board: ti: am62x: Account for DDR size fixups if ECC is enabled

2022-06-14 Thread Georgi Vlaev
Call into k3-ddrss driver to fixup device tree and resize
the available amount of DDR if ECC is enabled.

A second fixup is required from A53 SPL to take the fixup
as done from R5 SPL and apply it to DT passed to A53 U-boot,
which in turn passes this to the OS.

Signed-off-by: Georgi Vlaev 
---
 board/ti/am62x/evm.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index fb5106d1f3c8..d65ee1d69606 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -9,6 +9,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -30,3 +32,54 @@ int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
 }
+
+#if defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_K3_AM64_DDRSS)
+static void fixup_ddr_driver_for_ecc(struct spl_image_info *spl_image)
+{
+   struct udevice *dev;
+   int ret;
+
+   dram_init_banksize();
+
+   ret = uclass_get_device(UCLASS_RAM, 0, &dev);
+   if (ret)
+   panic("Cannot get RAM device for ddr size fixup: %d\n", ret);
+
+   ret = k3_ddrss_ddr_fdt_fixup(dev, spl_image->fdt_addr, gd->bd);
+   if (ret)
+   printf("Error fixing up ddr node for ECC use! %d\n", ret);
+}
+#else
+static void fixup_memory_node(struct spl_image_info *spl_image)
+{
+   u64 start[CONFIG_NR_DRAM_BANKS];
+   u64 size[CONFIG_NR_DRAM_BANKS];
+   int bank;
+   int ret;
+
+   dram_init();
+   dram_init_banksize();
+
+   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+   start[bank] =  gd->bd->bi_dram[bank].start;
+   size[bank] = gd->bd->bi_dram[bank].size;
+   }
+
+   /* dram_init functions use SPL fdt, and we must fixup u-boot fdt */
+   ret = fdt_fixup_memory_banks(spl_image->fdt_addr, start, size,
+CONFIG_NR_DRAM_BANKS);
+   if (ret)
+   printf("Error fixing up memory node! %d\n", ret);
+}
+#endif
+
+void spl_perform_fixups(struct spl_image_info *spl_image)
+{
+#if defined(CONFIG_K3_AM64_DDRSS)
+   fixup_ddr_driver_for_ecc(spl_image);
+#else
+   fixup_memory_node(spl_image);
+#endif
+}
+#endif
-- 
2.30.2



[PATCH 3/5] board: ti: am62x: Use fdt functions for ram and bank init

2022-06-14 Thread Georgi Vlaev
Use the appropriate fdtdec_setup_mem_size_base() call in
dram_init() and fdtdec_setup_bank_size() in dram_bank_init()
to pull these values from DT, where they are already available,
instead of hardcoding them.

Signed-off-by: Georgi Vlaev 
---
 board/ti/am62x/evm.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 4dd5e64299bf..fb5106d1f3c8 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -23,17 +23,10 @@ int board_init(void)
 
 int dram_init(void)
 {
-   gd->ram_size = 0x8000;
-
-   return 0;
+   return fdtdec_setup_mem_size_base();
 }
 
 int dram_init_banksize(void)
 {
-   /* Bank 0 declares the memory available in the DDR low region */
-   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
-   gd->bd->bi_dram[0].size = 0x8000;
-   gd->ram_size = 0x8000;
-
-   return 0;
+   return fdtdec_setup_memory_banksize();
 }
-- 
2.30.2



[PATCH 2/5] arm: dts: k3-am625-*: Mark memory with u-boot,dm-spl

2022-06-14 Thread Georgi Vlaev
Mark the memory node with u-boot,dm-spl so we can use it
from early SPL on both R5 and A53.

Signed-off-by: Georgi Vlaev 
---
 arch/arm/dts/k3-am625-r5-sk.dts  | 1 +
 arch/arm/dts/k3-am625-sk-u-boot.dtsi | 4 
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 2691af40a145..5aab858edd14 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -28,6 +28,7 @@
/* 2G RAM */
reg = <0x 0x8000 0x 0x8000>;
 
+   u-boot,dm-spl;
};
 
reserved-memory {
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index e1971ecdfedb..159fa36bbe9f 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -13,6 +13,10 @@
aliases {
mmc1 = &sdhci1;
};
+
+   memory@8000 {
+   u-boot,dm-spl;
+   };
 };
 
 &cbass_main{
-- 
2.30.2



[PATCH 1/5] arm: mach-k3: common: Use ddr_init in spl_enable_dcache

2022-06-14 Thread Georgi Vlaev
The spl_enable_dcache() function calls dram_init_banksize()
to get the total memory size. Normally the dram_init_banksize()
setups the memory banks, while the total size is reported
by ddr_init(). This worked so far for K3 since we set the
gd->ram_size in dram_init_banksize() as well.

Signed-off-by: Georgi Vlaev 
---
 arch/arm/mach-k3/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index b4b75f4e6c86..70f6444e7988 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -516,7 +516,7 @@ void spl_enable_dcache(void)
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
phys_addr_t ram_top = CONFIG_SYS_SDRAM_BASE;
 
-   dram_init_banksize();
+   dram_init();
 
/* reserve TLB table */
gd->arch.tlb_size = PGTABLE_SIZE;
-- 
2.30.2



[PATCH 0/5] board: ti: am62x: Add support for 1-bit inline DDRSS ECC

2022-06-14 Thread Georgi Vlaev
Hi,

This series enables the 1-bit inline DDR ECC support in the
TI DDRSS bridge for AM62x. The base DDRSS ECC support was
merged for k3-ddrss in a previous series for AM64x [1].

The ECC data is stored together with the data, which will
reduce the total available memory with 1/9th. The k3-ddrss
driver enables the ECC support and primes the full memory
from the R5 SPL, so the the memory size changes must
propagate from the R5 SPL to A53 SPL and then to A53 u-boot.

The patches are similar to those we have for AM64x, with
one exception: "arm: mach-k3: common: Use ddr_init in
spl_enable_dcache". Since we've switched the boards to DT
to fetch the memory configuration, dram_init_banksize()
will no longer set the total memory size in the global data.
And spl_enable_dcache() uses dram_init_banksize() instead
of dram_init(), which actually sets the memory base/size.

Note this doesn't enable the 1-bit ECC on any platform by
default. This can be done by adding the "ti,ecc-enable"
property to the memorycontroller node in k3-am6*-ddr.dtsi.

[1] https://lore.kernel.org/u-boot/20220317170346.31162-1-d-gerl...@ti.com/

The patches depend on the base AM62 support, which was
recently merged in u-boot/next.

Georgi Vlaev (5):
  arm: mach-k3: common: Use ddr_init in spl_enable_dcache
  arm: dts: k3-am625-*: Mark memory with u-boot,dm-spl
  board: ti: am62x: Use fdt functions for ram and bank init
  board: ti: am62x: Account for DDR size fixups if ECC is enabled
  configs: am62x_evm_r5: Add CONFIG_NR_DRAM_BANKS as done in a53
defconfig

 arch/arm/dts/k3-am625-r5-sk.dts  |  1 +
 arch/arm/dts/k3-am625-sk-u-boot.dtsi |  4 ++
 arch/arm/mach-k3/common.c|  2 +-
 board/ti/am62x/evm.c | 62 
 configs/am62x_evm_r5_defconfig   |  1 +
 5 files changed, 61 insertions(+), 9 deletions(-)


base-commit: a87a6fcd20c0e29fe55bfbb6917c4aa1f1bbce74
-- 
2.30.2



Re: [PATCH 1/1] efi_loader: initialize console size late

2022-06-14 Thread Heiko Thiery
Hi,

Am Di., 14. Juni 2022 um 08:02 Uhr schrieb Heinrich Schuchardt
:
>
> From: Heinrich Schuchardt 
>
> If CONFIG_VIDEO_DM=n we query the display size from the serial console.
> Especially when using a remote console the response can be so late that
> it interferes with autoboot.
>
> Only query the console size when running an EFI binary.
>
> Add debug output showing the determined console size.
>
> Reported-by: Fabio Estevam 
> Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk 
> objects from udevice")
> Signed-off-by: Heinrich Schuchardt 

Tested-by: Heiko Thiery 

Tested on an imx8mn-ddr3l-evk board.

Thank you
-- 
Heiko

> ---
>  include/efi_loader.h |  2 ++
>  lib/efi_loader/efi_console.c | 20 +---
>  lib/efi_loader/efi_setup.c   |  4 
>  3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index f6651e2c60..c1e00ebac3 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -499,6 +499,8 @@ extern struct list_head efi_register_notify_events;
>  int efi_init_early(void);
>  /* Initialize efi execution environment */
>  efi_status_t efi_init_obj_list(void);
> +/* Set up console modes */
> +void efi_setup_console_size(void);
>  /* Install device tree */
>  efi_status_t efi_install_fdt(void *fdt);
>  /* Run loaded UEFI image */
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 60a3fc85ac..3164fd484e 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -5,6 +5,8 @@
>   *  Copyright (c) 2016 Alexander Graf
>   */
>
> +#define LOG_CATEGORY LOGC_EFI
> +
>  #include 
>  #include 
>  #include 
> @@ -12,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -58,7 +61,12 @@ const efi_guid_t efi_guid_text_output_protocol =
>  #define cESC '\x1b'
>  #define ESC "\x1b"
>
> -/* Default to mode 0 */
> +/*
> + * efi_con_mode - mode information of the Simple Text Output Protocol
> + *
> + * Use safe settings before efi_setup_console_size() is called.
> + * By default enable only the 80x25 mode which must always exist.
> + */
>  static struct simple_text_output_mode efi_con_mode = {
> .max_mode = 1,
> .mode = 0,
> @@ -333,13 +341,13 @@ static int __maybe_unused query_vidconsole(int *rows, 
> int *cols)
>  }
>
>  /**
> - * query_console_size() - update the mode table.
> + * efi_setup_console_size() - update the mode table.
>   *
>   * By default the only mode available is 80x25. If the console has at least 
> 50
>   * lines, enable mode 80x50. If we can query the console size and it is 
> neither
>   * 80x25 nor 80x50, set it as an additional mode.
>   */
> -static void query_console_size(void)
> +void efi_setup_console_size(void)
>  {
> int rows = 25, cols = 80;
> int ret = -ENODEV;
> @@ -351,6 +359,8 @@ static void query_console_size(void)
> if (ret)
> return;
>
> +   log_debug("Console size %dx%d\n", rows, cols);
> +
> /* Test if we can have Mode 1 */
> if (cols >= 80 && rows >= 50) {
> efi_cout_modes[1].present = 1;
> @@ -371,7 +381,6 @@ static void query_console_size(void)
> }
>  }
>
> -
>  /**
>   * efi_cout_query_mode() - get terminal size for a text mode
>   *
> @@ -1262,9 +1271,6 @@ efi_status_t efi_console_register(void)
> efi_status_t r;
> struct efi_device_path *dp;
>
> -   /* Set up mode information */
> -   query_console_size();
> -
> /* Install protocols on root node */
> r = EFI_CALL(efi_install_multiple_protocol_interfaces
>  (&efi_root,
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index 250eeb2fcd..492ecf4cb1 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -243,6 +243,10 @@ efi_status_t efi_init_obj_list(void)
> goto out;
> }
>
> +   /* Set up console modes */
> +   efi_setup_console_size();
> +
> +   /* Install EFI_RNG_PROTOCOL */
> if (IS_ENABLED(CONFIG_EFI_RNG_PROTOCOL)) {
> ret = efi_rng_register();
> if (ret != EFI_SUCCESS)
> --
> 2.36.1
>


[PATCH] spl: fit: Allocate buffers aligned to cache line size

2022-06-14 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Allocate memory for buffers at a cache-line boundary to avoid
misaligned buffer address for subsequent reads. This avoids an
additional sector-based memory copy in the fat file system driver:

FAT: Misaligned buffer address (...)

Signed-off-by: Stefan Herbrechtsmeier 

---

 common/spl/spl_fit.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 1bbf824684..d61e1556ae 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -429,7 +429,9 @@ static int spl_fit_append_fdt(struct spl_image_info 
*spl_image,
 * depending on how the overlay is stored, so
 * don't fail yet if the allocation failed.
 */
-   tmpbuffer = 
malloc(CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ);
+   size_t size = 
CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ;
+
+   tmpbuffer = malloc_cache_aligned(size);
if (!tmpbuffer)
debug("%s: unable to allocate space for 
overlays\n",
  __func__);
@@ -537,7 +539,7 @@ static void *spl_get_fit_load_buffer(size_t size)
 {
void *buf;
 
-   buf = malloc(size);
+   buf = malloc_cache_aligned(size);
if (!buf) {
pr_err("Could not get FIT buffer of %lu bytes\n", (ulong)size);
pr_err("\tcheck CONFIG_SYS_SPL_MALLOC_SIZE\n");
-- 
2.30.2



Re: [PATCH] board: ti: am335x: eth_cpsw should depend on CONFIG_NET

2022-06-14 Thread Andrew Davis

On 6/14/22 3:44 AM, Corentin LABBE wrote:

The origin of this patch is the breaking of am335x-hs boot
due to commit e41651fffda7 ("dm: Support parent devices with of-platdata")
HS boards have less SRAM for SPL and so this commit increased memory usage 
beyond am335x limit.
This commit added 10 driver binding pass and am335x boot only if one pass is 
done.
SPL try to do more than one pass due to eth_cpsw failing.
Since HS SPL does not need network (and NET is already disabled in config),
the easiest fix is to "remove" eth_cpsw from SPL by testing if NET is enabled.

Signed-off-by: Corentin LABBE 
---



If no one was using this data I wonder if the compiler could have removed
it with LTO enabled.. Something to think on.

Acked-by: Andrew Davis 



  board/ti/am335x/board.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 7c0545892c..2cb5b1cb3f 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -902,7 +902,7 @@ int board_late_init(void)
  #endif
  
  /* CPSW plat */

-#if !CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(NET) && !CONFIG_IS_ENABLED(OF_CONTROL)
  struct cpsw_slave_data slave_data[] = {
{
.slave_reg_ofs  = CPSW_SLAVE0_OFFSET,


Re: [PATCH v3 0/2] usb: dwc3: add a SPL_USB_DWC3_GENERIC option for the dwc3 driver

2022-06-14 Thread Angus Ainslie

Did this fix the CI issues now ?

On 2022-05-30 10:15, Angus Ainslie wrote:

Changes since v2:

Add a second patch to deal with CI failures due to the new options.

Changes since v1:

Updated Kconfig depends

Angus Ainslie (2):
  usb: dwc3: add a SPL_USB_DWC3_GENERIC option for the dwc3 driver
  configs: get rid of build warnings due to SPL_USB_DWC3_GENERIC

 configs/am43xx_evm_defconfig  | 2 ++
 configs/am43xx_evm_usbhost_boot_defconfig | 2 ++
 configs/am43xx_hs_evm_defconfig   | 2 ++
 configs/am57xx_hs_evm_usb_defconfig   | 2 ++
 configs/am65x_evm_a53_defconfig   | 2 ++
 configs/am65x_evm_r5_usbdfu_defconfig | 2 ++
 configs/dra7xx_evm_defconfig  | 2 ++
 configs/dra7xx_hs_evm_defconfig   | 2 ++
 configs/dra7xx_hs_evm_usb_defconfig   | 2 ++
 drivers/usb/dwc3/Kconfig  | 7 +++
 drivers/usb/dwc3/Makefile | 2 +-
 11 files changed, 26 insertions(+), 1 deletion(-)


[PATCH 2/2] misc: usb251xb: Support 8/16 bit device tree values

2022-06-14 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

The device tree binding [1] specify the vendor-id, product-id, device-id
and language-id as 16 bit values and the linux driver reads the boost-up
value as 8 bit value.

[1] 
https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb251xb.txt

Signed-off-by: Stefan Herbrechtsmeier 

---

 drivers/misc/usb251xb.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/misc/usb251xb.c b/drivers/misc/usb251xb.c
index 077edc2504..a78ad1843a 100644
--- a/drivers/misc/usb251xb.c
+++ b/drivers/misc/usb251xb.c
@@ -400,14 +400,14 @@ static int usb251xb_of_to_plat(struct udevice *dev)
}
}
 
-   if (dev_read_u32(dev, "vendor-id", &hub->vendor_id))
-   hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+   hub->vendor_id = dev_read_u16_default(dev, "vendor-id",
+ USB251XB_DEF_VENDOR_ID);
 
-   if (dev_read_u32(dev, "product-id", &hub->product_id))
-   hub->product_id = data->product_id;
+   hub->product_id = dev_read_u16_default(dev, "product-id",
+  data->product_id);
 
-   if (dev_read_u32(dev, "device-id", &hub->device_id))
-   hub->device_id = USB251XB_DEF_DEVICE_ID;
+   hub->device_id = dev_read_u16_default(dev, "device-id",
+ USB251XB_DEF_DEVICE_ID);
 
hub->conf_data1 = USB251XB_DEF_CONFIG_DATA_1;
if (dev_read_bool(dev, "self-powered")) {
@@ -513,11 +513,11 @@ static int usb251xb_of_to_plat(struct udevice *dev)
if (!dev_read_u32(dev, "power-on-time-ms", &property_u32))
hub->power_on_time = min_t(u8, property_u32 / 2, 255);
 
-   if (dev_read_u32(dev, "language-id", &hub->lang_id))
-   hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+   hub->lang_id = dev_read_u16_default(dev, "language-id",
+   USB251XB_DEF_LANGUAGE_ID);
 
-   if (!dev_read_u32(dev, "boost-up", &hub->boost_up))
-   hub->boost_up = USB251XB_DEF_BOOST_UP;
+   hub->boost_up = dev_read_u8_default(dev, "boost-up",
+   USB251XB_DEF_BOOST_UP);
 
cproperty_char = dev_read_string(dev, "manufacturer");
strlcpy(str, cproperty_char ? : USB251XB_DEF_MANUFACTURER_STRING,
-- 
2.30.2



[PATCH 1/2] dm: core: Add functions to read 8/16-bit integers

2022-06-14 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add functions to read 8/16-bit integers like the existing functions for
32/64-bit to simplify read of 8/16-bit integers from device tree
properties.

Signed-off-by: Stefan Herbrechtsmeier 
---

 arch/sandbox/dts/test.dts |  2 ++
 drivers/core/of_access.c  | 38 +++
 drivers/core/ofnode.c | 62 +
 drivers/core/read.c   | 21 +
 include/dm/of_access.h| 32 +++
 include/dm/ofnode.h   | 40 
 include/dm/read.h | 65 +++
 test/dm/test-fdt.c| 19 
 8 files changed, 279 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8f93775ff4..035f5edfa2 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -226,6 +226,8 @@
test5-gpios = <&gpio_a 19>;
 
bool-value;
+   int8-value = /bits/ 8 <0x12>;
+   int16-value = /bits/ 16 <0x1234>;
int-value = <1234>;
uint-value = <(-1234)>;
int64-value = /bits/ 64 <0x>;
diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index c20b19cb50..0efcde3ba5 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -482,6 +482,44 @@ static void *of_find_property_value_of_size(const struct 
device_node *np,
return prop->value;
 }
 
+int of_read_u8(const struct device_node *np, const char *propname, u8 *outp)
+{
+   const u8 *val;
+
+   debug("%s: %s: ", __func__, propname);
+   if (!np)
+   return -EINVAL;
+   val = of_find_property_value_of_size(np, propname, sizeof(*outp));
+   if (IS_ERR(val)) {
+   debug("(not found)\n");
+   return PTR_ERR(val);
+   }
+
+   *outp = *val;
+   debug("%#x (%d)\n", *outp, *outp);
+
+   return 0;
+}
+
+int of_read_u16(const struct device_node *np, const char *propname, u16 *outp)
+{
+   const __be16 *val;
+
+   debug("%s: %s: ", __func__, propname);
+   if (!np)
+   return -EINVAL;
+   val = of_find_property_value_of_size(np, propname, sizeof(*outp));
+   if (IS_ERR(val)) {
+   debug("(not found)\n");
+   return PTR_ERR(val);
+   }
+
+   *outp = be16_to_cpup(val);
+   debug("%#x (%d)\n", *outp, *outp);
+
+   return 0;
+}
+
 int of_read_u32(const struct device_node *np, const char *propname, u32 *outp)
 {
return of_read_u32_index(np, propname, 0, outp);
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index a59832ebbf..ce411b7c35 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -31,6 +31,68 @@ bool ofnode_name_eq(ofnode node, const char *name)
return (strlen(name) == len) && !strncmp(node_name, name, len);
 }
 
+int ofnode_read_u8(ofnode node, const char *propname, u8 *outp)
+{
+   const u8 *cell;
+   int len;
+
+   assert(ofnode_valid(node));
+   debug("%s: %s: ", __func__, propname);
+
+   if (ofnode_is_np(node))
+   return of_read_u8(ofnode_to_np(node), propname, outp);
+
+   cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), propname,
+  &len);
+   if (!cell || len < sizeof(*cell)) {
+   debug("(not found)\n");
+   return -EINVAL;
+   }
+   *outp = *cell;
+   debug("%#x (%d)\n", *outp, *outp);
+
+   return 0;
+}
+
+u8 ofnode_read_u8_default(ofnode node, const char *propname, u8 def)
+{
+   assert(ofnode_valid(node));
+   ofnode_read_u8(node, propname, &def);
+
+   return def;
+}
+
+int ofnode_read_u16(ofnode node, const char *propname, u16 *outp)
+{
+   const fdt16_t *cell;
+   int len;
+
+   assert(ofnode_valid(node));
+   debug("%s: %s: ", __func__, propname);
+
+   if (ofnode_is_np(node))
+   return of_read_u16(ofnode_to_np(node), propname, outp);
+
+   cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), propname,
+  &len);
+   if (!cell || len < sizeof(*cell)) {
+   debug("(not found)\n");
+   return -EINVAL;
+   }
+   *outp = be16_to_cpup(cell);
+   debug("%#x (%d)\n", *outp, *outp);
+
+   return 0;
+}
+
+u16 ofnode_read_u16_default(ofnode node, const char *propname, u16 def)
+{
+   assert(ofnode_valid(node));
+   ofnode_read_u16(node, propname, &def);
+
+   return def;
+}
+
 int ofnode_read_u32(ofnode node, const char *propname, u32 *outp)
 {
return ofnode_read_u32_index(node, propname, 0, outp);
diff --git a/drivers/core/read.c b/drivers/core/read.c
index c73508d276..07ab8ab41c 100644
--- a/drivers/core/read.c
+++ b/drivers/core/read.c
@@ -13,6 +13,27 @@
 #include 
 #include 
 
+int dev_read_u8(const struct udevice *dev, const char *propname, u8 *outp)
+{
+   return ofnode_read_u8(dev_ofnode(dev), propna

Re: [PATCH 2/2] imx: kontron-sl-mx8mm: Remove deprecated phy-mode property

2022-06-14 Thread Frieder Schrempf
Am 14.06.22 um 15:13 schrieb Fabio Estevam:
> Hi Frieder,
> 
> On 14/06/2022 10:03, Frieder Schrempf wrote:
>> From: Frieder Schrempf 
>>
>> This was previously needed, but U-Boot is now capable of parsing
>> the new "phy-connection-type" property that is already used in
>> the main devicetree.
>>
>> Signed-off-by: Frieder Schrempf 
> 
> Should the Subject say "unneeded" instead of "deprecated"?

Maybe that would be more appropriate, yes. I just checked the kernel
bindings and it seems like in contrast to what I memorized, "phy-mode"
is actually not (yet?) marked as deprecated.


Re: [PATCH 2/2] imx: kontron-sl-mx8mm: Remove deprecated phy-mode property

2022-06-14 Thread Fabio Estevam

Hi Frieder,

On 14/06/2022 10:03, Frieder Schrempf wrote:

From: Frieder Schrempf 

This was previously needed, but U-Boot is now capable of parsing
the new "phy-connection-type" property that is already used in
the main devicetree.

Signed-off-by: Frieder Schrempf 


Should the Subject say "unneeded" instead of "deprecated"?

Reviewed-by: Fabio Estevam 


[PATCH 2/2] imx: kontron-sl-mx8mm: Remove deprecated phy-mode property

2022-06-14 Thread Frieder Schrempf
From: Frieder Schrempf 

This was previously needed, but U-Boot is now capable of parsing
the new "phy-connection-type" property that is already used in
the main devicetree.

Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
index 6fdc1968158..2c62f05cec1 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
@@ -41,10 +41,6 @@
u-boot,dm-spl;
 };
 
-&fec1 {
-   phy-mode = "rgmii-rxid";
-};
-
 &i2c1 {
u-boot,dm-spl;
u-boot,dm-pre-reloc;
-- 
2.36.1



[PATCH 1/2] imx: kontron-sl-mx8mm: Sync dts files and fix ethernet

2022-06-14 Thread Frieder Schrempf
From: Frieder Schrempf 

This syncs the devicetree files with the latest Linux kernel (5.19-rc2).
This also fixes the currently broken ethernet support:

Before:

  Net:   Could not get PHY for FEC0: addr 0

After:

  Net:   eth0: ethernet@30be

Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/imx8mm-kontron-n801x-s.dts| 48 +++---
 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi |  6 +--
 2 files changed, 8 insertions(+), 46 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s.dts 
b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
index c796d144e22..23be1ec538b 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-s.dts
+++ b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
@@ -6,7 +6,6 @@
 /dts-v1/;
 
 #include "imx8mm-kontron-n801x-som.dtsi"
-#include 
 
 / {
model = "Kontron i.MX8MM N801X S";
@@ -81,7 +80,6 @@
regulator-name = "vdd-5v";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
-   regulator-always-on;
};
 };
 
@@ -124,38 +122,14 @@
#size-cells = <0>;
 
ethphy: ethernet-phy@0 {
-   compatible = "ethernet-phy-id0007.0570";
reg = <0>;
-   reset-assert-us = <100>;
-   reset-deassert-us = <100>;
+   reset-assert-us = <1>;
+   reset-deassert-us = <15000>;
reset-gpios = <&gpio4 27 GPIO_ACTIVE_LOW>;
-   vsc8531,led-0-mode = ;
-   vsc8531,led-1-mode = ;
-   vsc8531,led-0-combine-disable;
};
};
 };
 
-&gpio4 {
-   dsi_mux_sel: dsi_mux_sel {
-   gpio-hog;
-   gpios = <14 GPIO_ACTIVE_HIGH>;
-   output-high;
-   line-name = "dsi-mux-sel";
-   pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_dsi_sel>;
-   };
-
-   dsi_mux_oe {
-   gpio-hog;
-   gpios = <15 GPIO_ACTIVE_LOW>;
-   output-high;
-   line-name = "dsi-mux-oe";
-   pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_dsi_oe>;
-   };
-};
-
 &i2c4 {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -208,7 +182,7 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   usbnet: usbether@1 {
+   usbnet: ethernet@1 {
compatible = "usb424,ec00";
reg = <1>;
local-mac-address = [ 00 00 00 00 00 00 ];
@@ -237,18 +211,6 @@
>;
};
 
-   pinctrl_dsi_sel: dsiselgrp {
-   fsl,pins = <
-   MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14   0x19
-   >;
-   };
-
-   pinctrl_dsi_oe: dsioegrp {
-   fsl,pins = <
-   MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15   0x19
-   >;
-   };
-
pinctrl_ecspi2: ecspi2grp {
fsl,pins = <
MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO0x82
@@ -362,7 +324,7 @@
>;
};
 
-   pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+   pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
@@ -374,7 +336,7 @@
>;
};
 
-   pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+   pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
index c3418d263eb..8f90eb02550 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
@@ -63,10 +63,10 @@
 &ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
-   cs-gpios = <&gpio5 9 GPIO_ACTIVE_HIGH>;
+   cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
status = "okay";
 
-   spi-flash@0 {
+   flash@0 {
compatible = "mxicy,mx25r1635f", "jedec,spi-nor";
spi-max-frequency = <8000>;
reg = <0>;
@@ -154,7 +154,7 @@
reg_vdd_snvs: LDO2 {
regulator-name = "ldo2";
regulator-min-microvolt = <80>;
-   regulator-max-microvolt = <80>;
+   regulator-max-microvolt = <90>;
regulator-boot-on;
regulator-always-on;
};
-- 
2.36.1



Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address

2022-06-14 Thread Michal Simek

Hi,

On 6/13/22 11:02, Stefan Herbrechtsmeier wrote:

[CAUTION: External Email]

Hi Michal,

Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier:

Hi Michal,

Am 13.06.2022 um 09:20 schrieb Michal Simek:

Hi,

On 6/10/22 18:48, Xavier Drudis Ferran wrote:

El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia:

Hi Michal,

what is the default entry address for the aft / bl31.bin?

I have a bl31.bin with an entry address of 0x1000 and this is inside
the
BSS.



Me too, load address at 0x1000, but for me in SPL text, not BSS.

I have a litle customized, a little old TF-A  for rk3399 / Rock pi 4
loading at address 0 with entry at 0x1000.

But include/configs/rk3399_common.h sets my
CONFIG_SPL_BSS_START_ADDR=0x40, away from harm.
I had problems booting anyway.

Now I can load U-Boot from MMC with these patches
https://lists.denx.de/pipermail/u-boot/2022-June/485497.html

In particular
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000

This is defined in arch/arm/mach-rockchip/Kconfig and says it's
to avoid conflicts with SPL text area, not BSS

But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000,
so I thought some low addresses where normal. I don't know.

I had to modify the code loading from SPI because, unlike MMC code, it
thought address 0 meant no destination (I can send those patches when
I have them cleaner if anyone wants them).

I just realised that I have CONFIG_SPL_TEXT_BASE=0x0.  I'm not finding
where that's defined, maybe it's simply because it's not defined
anywhere, so maybe the solution for me would be setting
CONFIG_SPL_TEXT_BASE
to 0x1000 or something. Or maybe it needs to be at 0x0 because
it is bootrom who is loading it, and it won't look where I define it?
I can't remember whether I tried this.

Maybe you can try to look at the size of a file bl31_0x.bin
that is generated when you build U-boot with BL31 pointing at your
bl31.elf (check u-boot.its if that's not the name for you).

Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load
property
in entry atf_1 of u-boot.its). This should leave a hole at the beginning
of U-Boot to make room for your TF-A, and leave BSS elsewhere.

The sources and build scripts for TF-A are public, so maybe one could
look at what's the criteria for putting images at different addresses?



I have no idea what rockchip has to do with memory layout on zynqmp.
Anyway SPL must be placed to OCM that's why text base is at 0xfffc
where OCM starts and which is also default address where a53s starts.

TF-A can be placed to any address but address which I use in SPL flow
is 0xfffe5000. PetaLinux which uses FSBL is using different address
0xfffea000 which is default in TF-A.
In DDR I normally use end of low ddr locations. It means 0x7fxx.

And of course you can't place TFA to location which is used by SPL or
by u-boot or other SW.


Thanks for the information. I will check why our TF-A is linked to the
lower DDR and move it back to the default address.


The TF-A was build with debug flag [1]:

 > By default, the Arm-trusted firmware builds for OCM space at address
 > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by
 > default with DEBUG=1, it builds for DDR location 0x1000 with build
 > flag DEBUG=1 mentioned while building.

Either the CONFIG_SPL_BSS_START_ADDR or the default location of the TF-A
with DEBUG flag should be changed.

[1]
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware


It is really question what should be default address with DEBUG=1.

I tried this

diff --git a/plat/xilinx/zynqmp/include/platform_def.h 
b/plat/xilinx/zynqmp/include/platform_def.h

index 9c1600a7b7e3..66bbf30a65a4 100644
--- a/plat/xilinx/zynqmp/include/platform_def.h
+++ b/plat/xilinx/zynqmp/include/platform_def.h
@@ -40,8 +40,8 @@
 # define BL31_BASE U(0xfffea000)
 # define BL31_LIMITU(0x1)
 #else
-# define BL31_BASE U(0x1000)
-# define BL31_LIMITU(0x7)
+# define BL31_BASE U(0xfff5a000)
+# define BL31_LIMITU(0x1)
 #endif
 #else
 # define BL31_BASE (ZYNQMP_ATF_MEM_BASE)


And with the latest TF-A this works fine.
No problem to change TF-A code to place it to different addresses. I think it 
should stay in OCM if possible or allocate space at the end of of low ddr 
address. It means any 0x7fxx address should be fine.

With any SPD on we won't be able to fit OCM anyway.

Thanks,
Michal


Re: [PATCH] arm64: dts: imx8mq-kontron-pitx-imx8m-u-boot.dtsi: disable assigned clocks

2022-06-14 Thread Tom Rini
On Tue, Jun 14, 2022 at 06:11:11AM +0200, Heiko Thiery wrote:
> Hi Tom,
> 
> Am Sa., 11. Juni 2022 um 16:56 Uhr schrieb Heiko Thiery
> :
> >
> > Hi Marek,
> >
> > Am Sa., 11. Juni 2022 um 12:15 Uhr schrieb Marek Vasut :
> > >
> > > On 6/11/22 08:09, Heiko Thiery wrote:
> > > > With the move to use DM_CLK the boards uart stops working. The used
> > > > properties are not supported by the imx8mq clock driver. Thus
> > > > the correct baudrate cannot be selected. Remove this properties here and
> > > > the board can start with working uart. Keep it in the main dts because
> > > > linux handles these porperties fine.
> > >
> > > Is this yet another
> > >
> > > 75f080df46f ("Revert "clk: Detect failure to set defaults"")
> > >
> > > kind of failure, where the clock uclass returns error code on something?
> > >
> > > Maybe the clock uclass should rather warn than fail outright, so we
> > > won't need these workarounds in DT files ?
> >
> > I think this is another kind of issue here. I had already tried to
> > solve the problem [1], but had not been able to follow it through to
> > the end.
> >
> > Maybe now is the right time to tackle it again. But due to lack of
> > time i can't say when i will get to it yet.
> >
> > [1] 
> > https://patchwork.ozlabs.org/project/uboot/patch/20220317124127.1783768-1-heiko.thi...@gmail.com/
> 
> Is there a chance that this patch can still come in the next RC?
> Without this change, the board no longer starts correctly.

I've put it in my queue.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] board: ti: am335x: eth_cpsw should depend on CONFIG_NET

2022-06-14 Thread Tom Rini
On Tue, Jun 14, 2022 at 08:44:07AM +, Corentin LABBE wrote:

> The origin of this patch is the breaking of am335x-hs boot
> due to commit e41651fffda7 ("dm: Support parent devices with of-platdata")
> HS boards have less SRAM for SPL and so this commit increased memory usage 
> beyond am335x limit.
> This commit added 10 driver binding pass and am335x boot only if one pass is 
> done.
> SPL try to do more than one pass due to eth_cpsw failing.
> Since HS SPL does not need network (and NET is already disabled in config),
> the easiest fix is to "remove" eth_cpsw from SPL by testing if NET is enabled.
> 
> Signed-off-by: Corentin LABBE 

Fixes: e41651fffda7 ("dm: Support parent devices with of-platdata")
Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4] imx: add i.MX8MN DDR3L evk board support

2022-06-14 Thread Heiko Thiery
Hi Michael,

Am Di., 14. Juni 2022 um 08:56 Uhr schrieb Michael Nazzareno Trimarchi
:
>
> Hi
>
> On Mon, Jun 13, 2022 at 11:10 PM Heiko Thiery  wrote:
> >
> > Add the support for the 8MNANOD3L-EVK board. The board has an i.MX8MNano
> > UltraLite Quad SoC and uses 1GB DDR3L memory.
> >
> > U-Boot SPL 2022.07-rc4-00017-gcf594ebce1 (Jun 13 2022 - 22:40:31 +0200)
> > Normal Boot
> > WDT:   Started watchdog@3028 with servicing (60s timeout)
> > Trying to boot from BOOTROM
> > image offset 0x8000, pagesize 0x200, ivt offset 0x0
> > NOTICE:  BL31: v2.6(release):v2.6-5-g9b1a4d832
> > NOTICE:  BL31: Built : 14:03:53, May 10 2022
> >
> > U-Boot 2022.07-rc4-00017-gcf594ebce1 (Jun 13 2022 - 22:40:31 +0200)
> >
> > CPU:   Freescale i.MX8MNano UltraLite Quad rev1.0 at 1200 MHz
> > Reset cause: WDOG
> > Model: NXP i.MX8MNano DDR3L EVK board
> > DRAM:  1 GiB
> > Core:  142 devices, 19 uclasses, devicetree: separate
> > WDT:   Started watchdog@3028 with servicing (60s timeout)
> > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... OK
> > In:serial@3089
> > Out:   serial@3089
> > Err:   serial@3089
> > Net:   eth0: ethernet@30be
> > Hit any key to stop autoboot:  0
> >
> > Signed-off-by: Heiko Thiery 
> > Reviewed-by: Fabio Estevam 
> > ---
> > v4:
> >  - rebase on current master to fix merge conflicts
> >  - remove config options from defconfig
> >  - enable SPL_DM_SERIAL
> >  - include imx8mn-ddr4-evk-u-boot.dtsi in imx8mn-ddr3l-evk-u-boot.dtsi
> > v3:
> >  - fix config option description in Kconfig (TARGET_IMX8MN_DDR3L_EVK)
> > v2:
> >  - change license formatting (thanks Marcel)
> >
> >  arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi |  34 +
> >  arch/arm/dts/imx8mn-ddr3l-evk.dts | 114 +++
> >  arch/arm/dts/imx8mn-u-boot.dtsi   |  12 +
> >  arch/arm/mach-imx/imx8m/Kconfig   |   7 +
> >  board/freescale/imx8mn_evk/Kconfig|   2 +-
> >  board/freescale/imx8mn_evk/Makefile   |   1 +
> >  board/freescale/imx8mn_evk/ddr3l_timing.c | 943 ++
> >  board/freescale/imx8mn_evk/spl.c  |   9 +
> >  configs/imx8mn_ddr3l_evk_defconfig|  95 +++
> >  include/configs/imx8mn_evk.h  |   4 +
> >  10 files changed, 1220 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/imx8mn-ddr3l-evk.dts
> >  create mode 100644 board/freescale/imx8mn_evk/ddr3l_timing.c
> >  create mode 100644 configs/imx8mn_ddr3l_evk_defconfig
> >
> > diff --git a/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi 
> > b/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> > new file mode 100644
> > index 00..b9192515e5
> > --- /dev/null
> > +++ b/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> > @@ -0,0 +1,34 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +
> > +#include "imx8mn-u-boot.dtsi"
> > +#include "imx8mn-ddr4-evk-u-boot.dtsi"
> > +
> > +
> > +&{/soc@0} {
> > +   u-boot,dm-pre-reloc;
> > +   u-boot,dm-spl;
> > +};
> > +
> > +&clk {
> > +   u-boot,dm-spl;
> > +   u-boot,dm-pre-reloc;
> > +   /delete-property/ assigned-clocks;
> > +   /delete-property/ assigned-clock-parents;
> > +   /delete-property/ assigned-clock-rates;
> > +};
> > +
> > +&i2c1 {
> > +   u-boot,dm-spl;
> > +};
> > +
> > +&{/soc@0/bus@3080/i2c@30a2/pmic@25} {
> > +   u-boot,dm-spl;
> > +};
> > +
> > +&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
> > +   u-boot,dm-spl;
> > +};
> > +
> > +&wdog1 {
> > +   u-boot,dm-spl;
> > +};
> > diff --git a/arch/arm/dts/imx8mn-ddr3l-evk.dts 
> > b/arch/arm/dts/imx8mn-ddr3l-evk.dts
> > new file mode 100644
> > index 00..4cdc03c8f2
> > --- /dev/null
> > +++ b/arch/arm/dts/imx8mn-ddr3l-evk.dts
> > @@ -0,0 +1,114 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +
> > +/dts-v1/;
> > +
> > +#include "imx8mn.dtsi"
> > +#include "imx8mn-evk.dtsi"
> > +#include 
> > +
> > +/ {
> > +   model = "NXP i.MX8MNano DDR3L EVK board";
> > +   compatible = "fsl,imx8mn-ddr3l-evk", "fsl,imx8mn";
> > +};
> > +
> > +&A53_0 {
> > +   cpu-supply = <&buck1>;
> > +};
> > +
> > +&A53_1 {
> > +   cpu-supply = <&buck1>;
> > +};
> > +
> > +&A53_2 {
> > +   cpu-supply = <&buck1>;
> > +};
> > +
> > +&A53_3 {
> > +   cpu-supply = <&buck1>;
> > +};
> > +
> > +&i2c1 {
> > +   pmic: pmic@25 {
> > +   compatible = "nxp,pca9450b";
> > +   reg = <0x25>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_pmic>;
> > +   interrupt-parent = <&gpio1>;
> > +   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> > +
> > +   regulators {
> > +   buck1: BUCK1 {
> > +   regulator-name = "VDD_SOC_0V9";
> > +   regulator-min-microvolt = <85>;
> > +   regulator-max-microvolt = <95>;
> > + 

Re: [PATCH V3 2/2] nvmem: add driver handling U-Boot environment variables

2022-06-14 Thread Sascha Hauer
On Sat, Jun 11, 2022 at 10:46:51PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> U-Boot stores its setup as environment variables. It's a list of
> key-value pairs stored on flash device with a custom header.
> 
> This commit adds an NVMEM driver that:
> 1. Provides NVMEM access to environment vars binary data
> 2. Extracts variables as NVMEM cells
> 
> Current Linux's NVMEM sysfs API allows reading whole NVMEM data block.
> It can be used by user-space tools for reading U-Boot env vars block
> without the hassle of finding its location. Parsing will still need to
> be re-done there.
> 
> Kernel-parsed NVMEM cells can be read however by Linux drivers. This may
> be uesful for Ethernet drivers for reading device MAC address which is
> often stored as U-Boot env variable.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V3: Use of_get_mtd_device_by_node() (thanks Ahmad) & update description
> V2: Drop ARCH_BCM4908 dependency as there are plenty architectures using
> U-Boot bootloader. Thanks Srinivas.
> 
> As noticed by Ahmad a missing NVMEM subsystem feature is user-space
> access to parsed NVMEM cells. That is something I started working on
> some time ago and I'm planning to get back to at some point, please
> check:
> [PATCH 2/2] nvmem: expose NVMEM cells in sysfs
> https://lore.kernel.org/lkml/20211220064730.28806-2-zaj...@gmail.com/
> ---
>  MAINTAINERS|   1 +
>  drivers/nvmem/Kconfig  |  11 ++
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/u-boot-env.c | 231 +
>  4 files changed, 245 insertions(+)
>  create mode 100644 drivers/nvmem/u-boot-env.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 475e28365385..43b427fa76b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20411,6 +20411,7 @@ U-BOOT ENVIRONMENT VARIABLES
>  M:   Rafał Miłecki 
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> +F:   drivers/nvmem/u-boot-env.c
>  
>  UACCE ACCELERATOR FRAMEWORK
>  M:   Zhangfei Gao 
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index d72d879a6d34..5f1b32b953b9 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -344,4 +344,15 @@ config NVMEM_APPLE_EFUSES
> This driver can also be built as a module. If so, the module will
> be called nvmem-apple-efuses.
>  
> +config NVMEM_U_BOOT_ENV
> + tristate "U-Boot environment variables support"
> + depends on OF && MTD
> + select CRC32
> + help
> +   U-Boot stores its setup as environment variables. This driver adds
> +   support for verifying & exporting such data. It also exposes variables
> +   as NVMEM cells so they can be referenced by other drivers.
> +
> +   If compiled as module it will be called nvmem_u-boot-env.
> +
>  endif
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index c710b64f9fe4..399f9972d45b 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -69,3 +69,5 @@ obj-$(CONFIG_NVMEM_APPLE_EFUSES)+= nvmem-apple-efuses.o
>  nvmem-apple-efuses-y := apple-efuses.o
>  obj-$(CONFIG_MICROCHIP_OTPC) += nvmem-microchip-otpc.o
>  nvmem-microchip-otpc-y   := microchip-otpc.o
> +obj-$(CONFIG_NVMEM_U_BOOT_ENV)   += nvmem_u-boot-env.o
> +nvmem_u-boot-env-y   := u-boot-env.o
> diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
> new file mode 100644
> index ..92c2dd11d99f
> --- /dev/null
> +++ b/drivers/nvmem/u-boot-env.c
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Rafał Miłecki 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum u_boot_env_format {
> + U_BOOT_FORMAT_SINGLE,
> + U_BOOT_FORMAT_REDUNDANT,
> +};
> +
> +struct u_boot_env {
> + struct device *dev;
> + enum u_boot_env_format format;
> +
> + /* Parent device */
> + struct mtd_info *mtd;
> + size_t offset;
> + size_t size;
> +
> + /* Cells */
> + struct nvmem_cell_info *cells;
> + int ncells;
> +};
> +
> +struct u_boot_env_image_single {
> + __le32 crc32;
> + uint8_t data[0];
> +} __packed;
> +
> +struct u_boot_env_image_redundant {
> + __le32 crc32;
> + u8 mark;
> + uint8_t data[0];
> +} __packed;
> +
> +static int u_boot_env_read(void *context, unsigned int offset, void *val,
> +size_t bytes)
> +{
> + struct u_boot_env *priv = context;
> + struct device *dev = priv->dev;
> + size_t bytes_read;
> + int err;
> +
> + err = mtd_read(priv->mtd, priv->offset + offset, bytes, &bytes_read, 
> val);
> + if (err && !mtd_is_bitflip(err)) {
> + dev_err(dev, "Failed to read from mtd: %d\n", err);
> + return err;
> + }
> +
> + if (bytes_read != bytes) {
> + dev_err(dev, "Failed to read %zd bytes\n", bytes);
> + r

Re: [PATCH 1/1] efi_loader: initialize console size late

2022-06-14 Thread Fabio Estevam
Hi Heinrich,

On Tue, Jun 14, 2022 at 3:02 AM Heinrich Schuchardt
 wrote:
>
> From: Heinrich Schuchardt 
>
> If CONFIG_VIDEO_DM=n we query the display size from the serial console.
> Especially when using a remote console the response can be so late that
> it interferes with autoboot.
>
> Only query the console size when running an EFI binary.
>
> Add debug output showing the determined console size.
>
> Reported-by: Fabio Estevam 
> Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk 
> objects from udevice")
> Signed-off-by: Heinrich Schuchardt 

This fixes the boot on a kontron-sl-mx8mm board accessed remotely.
The autoboot process is no longer interrupted.

Thanks a lot!

Tested-by: Fabio Estevam 


Re: [PATCH v2] kontron-sl-mx8mm: Add CAAM support

2022-06-14 Thread Frieder Schrempf
Am 09.06.22 um 22:13 schrieb Fabio Estevam:
> Add CAAM support, which is required when enabling HAB secure boot.
> 
> Select CONFIG_SPL_DRIVERS_MISC so that CONFIG_IMX_HAB could
> build successfully, if selected.
> 
> Signed-off-by: Fabio Estevam 

Build-tested on next and partly runtime-tested by verifying that "SEC0:
 RNG instantiated" is printed to the console in SPL and U-Boot proper.

Acked-by: Frieder Schrempf 
Tested-by: Frieder Schrempf 

> ---
> Changes since v1:
> - Do not disable sec_jr0 node in -u-boot.dtsi. This will get disabled
> by the imx8mm.dtsi. Sent a patch upstream doing this. (Andrey)
> 
>  arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi | 16 
>  arch/arm/mach-imx/imx8m/Kconfig   |  3 +++
>  board/kontron/sl-mx8mm/spl.c  |  9 +
>  configs/kontron-sl-mx8mm_defconfig|  1 +
>  4 files changed, 29 insertions(+)
> 
> diff --git a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi 
> b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> index 22d18e6f1c..65ff3988d9 100644
> --- a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> @@ -25,6 +25,22 @@
>   };
>  };
>  
> +&crypto {
> + u-boot,dm-spl;
> +};
> +
> +&sec_jr0 {
> + u-boot,dm-spl;
> +};
> +
> +&sec_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +&sec_jr2 {
> + u-boot,dm-spl;
> +};
> +
>  &fec1 {
>   phy-mode = "rgmii-rxid";
>  };
> diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
> index 61397bf88d..5c59422ecb 100644
> --- a/arch/arm/mach-imx/imx8m/Kconfig
> +++ b/arch/arm/mach-imx/imx8m/Kconfig
> @@ -106,6 +106,9 @@ config TARGET_KONTRON_MX8MM
>   select IMX8MM
>   select SUPPORT_SPL
>   select IMX8M_LPDDR4
> + select FSL_CAAM
> + select ARCH_MISC_INIT
> + select SPL_CRYPTO if SPL
>  
>  config TARGET_IMX8MN_BSH_SMM_S2
>   bool "imx8mn-bsh-smm-s2"
> diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
> index 4ef03c8c17..5a513722c5 100644
> --- a/board/kontron/sl-mx8mm/spl.c
> +++ b/board/kontron/sl-mx8mm/spl.c
> @@ -13,6 +13,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -213,6 +216,12 @@ void spl_board_init(void)
>   struct udevice *dev;
>   int ret;
>  
> + if (IS_ENABLED(CONFIG_FSL_CAAM)) {
> + ret = uclass_get_device_by_driver(UCLASS_MISC, 
> DM_DRIVER_GET(caam_jr), &dev);
> + if (ret)
> + printf("Failed to initialize %s: %d\n", dev->name, ret);
> + }
> +
>   puts("Normal Boot\n");
>  
>   ret = uclass_get_device_by_name(UCLASS_CLK,
> diff --git a/configs/kontron-sl-mx8mm_defconfig 
> b/configs/kontron-sl-mx8mm_defconfig
> index 2e9d52522b..eae9ac0dbe 100644
> --- a/configs/kontron-sl-mx8mm_defconfig
> +++ b/configs/kontron-sl-mx8mm_defconfig
> @@ -16,6 +16,7 @@ CONFIG_SPL_TEXT_BASE=0x7E1000
>  CONFIG_TARGET_KONTRON_MX8MM=y
>  CONFIG_SPL_MMC=y
>  CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_DRIVERS_MISC=y
>  CONFIG_BOOTCOUNT_BOOTLIMIT=3
>  CONFIG_SPL=y
>  CONFIG_SYS_LOAD_ADDR=0x4200


Re: [PATCH V2 07/17] imx: kontron-sl-mx8mm: enable DM_SERIAL

2022-06-14 Thread Frieder Schrempf
Am 11.06.22 um 14:21 schrieb Peng Fan (OSS):
> From: Peng Fan 
> 
> Enable CONFIG_DM_SERIAL. uart and its pinmux was already
> marked with u-boot,dm-spl.
> Move preloader_console_init after spl_init to make sure driver
> model work.
> 
> Signed-off-by: Peng Fan 
> Acked-by: Frieder Schrempf 
> Reviewed-by: Fabio Estevam 

Tested-by: Frieder Schrempf 


Re: [PATCH V2 16/17] imx: imx8mn-kontron-n801x: enable pinctrl_wdog in SPL

2022-06-14 Thread Frieder Schrempf
Am 11.06.22 um 14:21 schrieb Peng Fan (OSS):
> From: Peng Fan 
> 
> Mark pinctrl_wdog as u-boot,dm-spl to clean up board code,
> 
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
> 
> Signed-off-by: Peng Fan 

Thanks for the cleanup!!!

The subject line should probably be:

imx: kontron-sl-mx8mm: enable pinctrl_wdog in SPL

Otherwise:

Reviewed-by: Frieder Schrempf 
Tested-by: Frieder Schrempf 

> ---
>  arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi |  4 
>  board/kontron/sl-mx8mm/spl.c  | 18 --
>  2 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi 
> b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> index 22d18e6f1cf..6882513f161 100644
> --- a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> @@ -126,3 +126,7 @@
>  &wdog1 {
>   u-boot,dm-spl;
>  };
> +
> +&pinctrl_wdog {
> + u-boot,dm-spl;
> +};
> diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
> index a58a75dc958..63361f1d2ab 100644
> --- a/board/kontron/sl-mx8mm/spl.c
> +++ b/board/kontron/sl-mx8mm/spl.c
> @@ -32,7 +32,6 @@ enum {
>  
>  #define GPIO_PAD_CTRL(PAD_CTL_DSE6 | PAD_CTL_ODE | PAD_CTL_PUE | 
> PAD_CTL_PE)
>  #define I2C_PAD_CTRL (PAD_CTL_DSE6 | PAD_CTL_HYS | PAD_CTL_PUE)
> -#define WDOG_PAD_CTRL(PAD_CTL_DSE6 | PAD_CTL_ODE | PAD_CTL_PUE | 
> PAD_CTL_PE)
>  
>  #define TOUCH_RESET_GPIO IMX_GPIO_NR(3, 23)
>  
> @@ -50,10 +49,6 @@ static iomux_v3_cfg_t const touch_gpio[] = {
>   IMX8MM_PAD_SAI5_RXD2_GPIO3_IO23 | MUX_PAD_CTRL(GPIO_PAD_CTRL)
>  };
>  
> -static iomux_v3_cfg_t const wdog_pads[] = {
> - IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_B  | MUX_PAD_CTRL(WDOG_PAD_CTRL),
> -};
> -
>  int spl_board_boot_device(enum boot_device boot_dev_spl)
>  {
>   switch (boot_dev_spl) {
> @@ -216,17 +211,6 @@ void spl_board_init(void)
>   printf("Failed to find clock node. Check device tree\n");
>  }
>  
> -int board_early_init_f(void)
> -{
> - struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR;
> -
> - imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));
> -
> - set_wdog_reset(wdog);
> -
> - return 0;
> -}
> -
>  static int power_init_board(void)
>  {
>   struct udevice *dev;
> @@ -261,8 +245,6 @@ void board_init_f(ulong dummy)
>  
>   init_uart_clk(2);
>  
> - board_early_init_f();
> -
>   timer_init();
>  
>   /* Clear the BSS. */


[PATCH] tools: binman: install btool

2022-06-14 Thread Peng Fan (OSS)
From: Peng Fan 

btool is needed after install binman to system.

Signed-off-by: Peng Fan 
---

Tom, Simon, Alper
  This is a bug fix, if possible, please pick it up.

 tools/binman/setup.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/binman/setup.py b/tools/binman/setup.py
index 5ed94abdaf9..9a9206eb044 100644
--- a/tools/binman/setup.py
+++ b/tools/binman/setup.py
@@ -5,7 +5,7 @@ setup(name='binman',
   version='1.0',
   license='GPL-2.0+',
   scripts=['binman'],
-  packages=['binman', 'binman.etype'],
+  packages=['binman', 'binman.etype', 'binman.btool'],
   package_dir={'binman': ''},
   package_data={'binman': ['README.rst', 'entries.rst']},
   classifiers=['Environment :: Console',
-- 
2.36.0



Re: [PATCH] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-14 Thread Stefan Herbrechtsmeier

Am 14.06.2022 um 10:39 schrieb Marek Vasut:

Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
  .../imx8mm_data_modul_edm_sbc.c   | 10 ++
  configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
  include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
  3 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..56202ca2fc8 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -104,7 +106,15 @@ int board_init(void)
  
  int board_late_init(void)

  {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_find_device_by_name(UCLASS_MISC, "usb-hub@2c", &dev);
+   if (!ret)
+   device_probe(dev);


Maybe you should use uclass_get_device_by_name() from uclass.h.


+
return 0;
  }

"setenv autoload false && "   \


Re: [PATCH V3 2/2] nvmem: add driver handling U-Boot environment variables

2022-06-14 Thread Miquel Raynal
Hello,

> > +static int u_boot_env_probe(struct platform_device *pdev)
> > +{
> > +   struct nvmem_config config = {
> > +   .name = "u-boot-env",
> > +   .reg_read = u_boot_env_read,
> > +   };
> > +   struct device *dev = &pdev->dev;
> > +   struct device_node *np = dev->of_node;
> > +   const struct of_device_id *of_id;
> > +   struct u_boot_env *priv;
> > +   int err;
> > +
> > +   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +   if (!priv)
> > +   return -ENOMEM;
> > +   priv->dev = dev;
> > +
> > +   of_id = of_match_device(u_boot_env_of_match_table, dev);
> > +   if (!of_id)
> > +   return -EINVAL;
> > +   priv->format = (uintptr_t)of_id->data;
> > +
> > +   if (of_property_read_u32(np, "reg", (u32 *)&priv->offset) ||
> > +   of_property_read_u32_index(np, "reg", 1, (u32 *)&priv->size)) {
> > +   dev_err(dev, "Failed to read \"reg\" property\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   priv->mtd = of_get_mtd_device_by_node(np->parent);
> > +   if (IS_ERR(priv->mtd)) {
> > +   dev_err(dev, "Failed to get %pOF MTD: %ld\n", np->parent, 
> > PTR_ERR(priv->mtd));
> > +   return PTR_ERR(priv->mtd);
> > +   }  
> 
> Partitions are mtd devices themselves and the mtd layer directly
> associates these devices to their OF node, so it should be possible
> to do a of_get_mtd_device_by_node(np) which gets you the partition.
> You can use the whole mtd device then and do not have to fiddle with
> reg properties, offsets and sizes in your driver yourself.

Just for the record, there will be one mtd device per partition, but
the "full" mtd device will only exist if the configuration contains
CONFIG_MTD_PARTITIONED_MASTER.

Thanks,
Miquèl


[PATCH] board: ti: am335x: eth_cpsw should depend on CONFIG_NET

2022-06-14 Thread Corentin LABBE
The origin of this patch is the breaking of am335x-hs boot
due to commit e41651fffda7 ("dm: Support parent devices with of-platdata")
HS boards have less SRAM for SPL and so this commit increased memory usage 
beyond am335x limit.
This commit added 10 driver binding pass and am335x boot only if one pass is 
done.
SPL try to do more than one pass due to eth_cpsw failing.
Since HS SPL does not need network (and NET is already disabled in config),
the easiest fix is to "remove" eth_cpsw from SPL by testing if NET is enabled.

Signed-off-by: Corentin LABBE 
---
 board/ti/am335x/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 7c0545892c..2cb5b1cb3f 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -902,7 +902,7 @@ int board_late_init(void)
 #endif
 
 /* CPSW plat */
-#if !CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(NET) && !CONFIG_IS_ENABLED(OF_CONTROL)
 struct cpsw_slave_data slave_data[] = {
{
.slave_reg_ofs  = CPSW_SLAVE0_OFFSET,
-- 
2.25.1



[PATCH] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-14 Thread Marek Vasut
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 .../imx8mm_data_modul_edm_sbc.c   | 10 ++
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
 3 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..56202ca2fc8 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +106,15 @@ int board_init(void)
 
 int board_late_init(void)
 {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_find_device_by_name(UCLASS_MISC, "usb-hub@2c", &dev);
+   if (!ret)
+   device_probe(dev);
+
return 0;
 }
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
 CONFIG_DM_I2C=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h 
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0"   \
"dmo_preboot="  \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
-   "run dmo_usb_start_hub ; "  \
/* Attempt to start USB and Network console */  \
"run dmo_usb_cdc_acm_start ; "  \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; "   \
"fi ; " \
"fi\0"  \
-   "dmo_usb_start_hub="\
-   "i2c dev 1 ; "  \
-   /* Reset the USB USB */ \
-   "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
-   "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */   \
-   /* Write chunks of descriptor into the USB HUB */   \
-   "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
-   "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
-   "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
-   "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; "   \
-   "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
-   "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
-   "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; "   \
-   "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
-   "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
-   "mw.l 0x7e1010 0x6900 ; "   \
-   "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; "   \
-   "mw.l 0x7e1000 0x0101 ; "   \
-   "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
-- 
2.35.1



Re: [PATCH v2 1/3] arm: apple: nvme: Add SART support and RTKit buffer management

2022-06-14 Thread Mark Kettenis
> From: Janne Grunau 
> Date: Tue, 14 Jun 2022 09:09:07 +0200
> 
> The NVMe firmware in the macOS 13 beta blocks or crashes with u-boot's
> current minimal RTKit implementation. It does not provide buffers for
> the firmware's buffer requests. The ANS2 firmware included in macOS 11
> and 12 tolerates this. The firmware included in the first macOS 13 beta
> requires buffers for the crashlog and ioreport endpoints to function.
> 
> In the case of the NVMe the buffers are physical memory. Access to
> physical memory is guarded by what Apple calls SART.
> Import m1n1's SART driver (exclusively used for the NVMe controller).
> Implement buffer management helpers for RTKit. These are generic since
> other devices (none in u-boot so far) require different handling.
> 
> Signed-off-by: Janne Grunau 

Reviewed-by: Mark Kettenis 
Tested-by: Mark Kettenis 

> ---
> 
> Changes in v2:
>  - The generation compatible strings "apple,sart2" "apple,sart3" got
>droppend from the bindings merged for Linux 5.19. Use the SoC
>specific ones instead.
> 
>  arch/arm/include/asm/arch-apple/rtkit.h |  22 ++-
>  arch/arm/include/asm/arch-apple/sart.h  |  22 +++
>  arch/arm/mach-apple/Makefile|   1 +
>  arch/arm/mach-apple/rtkit.c | 159 +---
>  arch/arm/mach-apple/sart.c  | 230 
>  drivers/nvme/nvme_apple.c   |  72 +++-
>  6 files changed, 474 insertions(+), 32 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-apple/sart.h
>  create mode 100644 arch/arm/mach-apple/sart.c
> 
> diff --git a/arch/arm/include/asm/arch-apple/rtkit.h 
> b/arch/arm/include/asm/arch-apple/rtkit.h
> index 51f77f298c09..eff18ddb9d21 100644
> --- a/arch/arm/include/asm/arch-apple/rtkit.h
> +++ b/arch/arm/include/asm/arch-apple/rtkit.h
> @@ -7,5 +7,23 @@
>  #define APPLE_RTKIT_PWR_STATE_QUIESCED   0x10
>  #define APPLE_RTKIT_PWR_STATE_ON 0x20
>  
> -int apple_rtkit_init(struct mbox_chan *);
> -int apple_rtkit_shutdown(struct mbox_chan *, int);
> +struct apple_rtkit_buffer {
> + void *buffer;
> + u64 dva;
> + size_t size;
> + bool is_mapped;
> +};
> +
> +typedef int (*apple_rtkit_shmem_setup)(void *cookie,
> +struct apple_rtkit_buffer *buf);
> +typedef void (*apple_rtkit_shmem_destroy)(void *cookie,
> +   struct apple_rtkit_buffer *buf);
> +
> +struct apple_rtkit;
> +
> +struct apple_rtkit *apple_rtkit_init(struct mbox_chan *chan, void *cookie,
> +  apple_rtkit_shmem_setup shmem_setup,
> +  apple_rtkit_shmem_destroy shmem_destroy);
> +void apple_rtkit_free(struct apple_rtkit *rtk);
> +int apple_rtkit_boot(struct apple_rtkit *rtk);
> +int apple_rtkit_shutdown(struct apple_rtkit *rtk, int pwrstate);
> diff --git a/arch/arm/include/asm/arch-apple/sart.h 
> b/arch/arm/include/asm/arch-apple/sart.h
> new file mode 100644
> index ..b99bdeafc0b3
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-apple/sart.h
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: MIT
> + *
> + * The sart code is copied from m1n1 (https://github.com/AsahiLinux/m1n1) and
> + * licensed as MIT.
> + *
> + * (C) Copyright 2022 The Asahi Linux Contributors
> + */
> +
> +#ifndef SART_H
> +#define SART_H
> +
> +#include 
> +
> +struct apple_sart;
> +
> +struct apple_sart *sart_init(ofnode node);
> +void sart_free(struct apple_sart *sart);
> +
> +bool sart_add_allowed_region(struct apple_sart *sart, void *paddr, size_t 
> sz);
> +bool sart_remove_allowed_region(struct apple_sart *sart, void *paddr, size_t 
> sz);
> +
> +#endif
> diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> index 52f30a777b2c..50b465b9473f 100644
> --- a/arch/arm/mach-apple/Makefile
> +++ b/arch/arm/mach-apple/Makefile
> @@ -3,3 +3,4 @@
>  obj-y += board.o
>  obj-y += lowlevel_init.o
>  obj-y += rtkit.o
> +obj-$(CONFIG_NVME_APPLE) += sart.o
> diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
> index 2dcb8bdd3e44..da7771844230 100644
> --- a/arch/arm/mach-apple/rtkit.c
> +++ b/arch/arm/mach-apple/rtkit.c
> @@ -17,6 +17,7 @@
>  #define APPLE_RTKIT_EP_SYSLOG 2
>  #define APPLE_RTKIT_EP_DEBUG 3
>  #define APPLE_RTKIT_EP_IOREPORT 4
> +#define APPLE_RTKIT_EP_TRACEKIT 10
>  
>  /* Messages for management endpoint. */
>  #define APPLE_RTKIT_MGMT_TYPE GENMASK(59, 52)
> @@ -51,7 +52,102 @@
>  #define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
>  #define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
>  
> -int apple_rtkit_init(struct mbox_chan *chan)
> +struct apple_rtkit {
> + struct mbox_chan *chan;
> + void *cookie;
> + apple_rtkit_shmem_setup shmem_setup;
> + apple_rtkit_shmem_destroy shmem_destroy;
> +
> + struct apple_rtkit_buffer syslog_buffer;
> + struct apple_rtkit_buffer crashlog_buffer;
> + struct apple_rtkit_buffer ioreport_buffer;
> +};
> +
> +struct apple_rtkit *apple_rtkit_ini

Re: [PATCH v2 3/3] arm: apple: Increase RTKit timeouts

2022-06-14 Thread Mark Kettenis
> From: Janne Grunau 
> Date: Tue, 14 Jun 2022 09:09:09 +0200
> 
> Timeouts are not expected to happen and are handled as fatal errors.
> Increase all timeouts to 1 second as defensive measure to avoid relying
> on the timing behaviour of certain firmware versions or configurations.
> 
> Signed-off-by: Janne Grunau 

Reviewed-by: Mark Kettenis 
Tested-by: Mark Kettenis 

> ---
> 
> (no changes since v1)
> 
>  arch/arm/mach-apple/rtkit.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
> index da7771844230..a550b553b663 100644
> --- a/arch/arm/mach-apple/rtkit.c
> +++ b/arch/arm/mach-apple/rtkit.c
> @@ -52,6 +52,8 @@
>  #define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
>  #define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
>  
> +#define TIMEOUT_1SEC_US 100
> +
>  struct apple_rtkit {
>   struct mbox_chan *chan;
>   void *cookie;
> @@ -168,7 +170,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
>   return ret;
>  
>   /* Wait for protocol version negotiation message. */
> - ret = mbox_recv(rtk->chan, &msg, 1);
> + ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
>   if (ret < 0)
>   return ret;
>  
> @@ -210,7 +212,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
>  
>  wait_epmap:
>   /* Wait for endpoint map message. */
> - ret = mbox_recv(rtk->chan, &msg, 1);
> + ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
>   if (ret < 0)
>   return ret;
>  
> @@ -275,7 +277,7 @@ wait_epmap:
>  
>   pwrstate = APPLE_RTKIT_PWR_STATE_SLEEP;
>   while (pwrstate != APPLE_RTKIT_PWR_STATE_ON) {
> - ret = mbox_recv(rtk->chan, &msg, 10);
> + ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
>   if (ret < 0)
>   return ret;
>  
> @@ -330,7 +332,7 @@ int apple_rtkit_shutdown(struct apple_rtkit *rtk, int 
> pwrstate)
>   if (ret < 0)
>   return ret;
>  
> - ret = mbox_recv(rtk->chan, &msg, 10);
> + ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
>   if (ret < 0)
>   return ret;
>  
> -- 
> 2.35.1
> 
> 


Re: [PATCH v2 2/3] MAINTAINERS: Add nvme_apple to Apple SoC section

2022-06-14 Thread Mark Kettenis
> From: Janne Grunau 
> Date: Tue, 14 Jun 2022 09:09:08 +0200
> 
> Signed-off-by: Janne Grunau 

Reviewed-by: Mark Kettenis 

> ---
> 
> (no changes since v1)
> 
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 28e4d3823861..a15ba7abdcd6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -121,6 +121,7 @@ F:arch/arm/include/asm/arch-m1/
>  F:   arch/arm/mach-apple/
>  F:   configs/apple_m1_defconfig
>  F:   drivers/iommu/apple_dart.c
> +F:   drivers/nvme/nvme_apple.c
>  F:   drivers/pinctrl/pinctrl-apple.c
>  F:   drivers/watchdog/apple_wdt.c
>  F:   include/configs/apple.h
> -- 
> 2.35.1
> 
> 


Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

2022-06-14 Thread Marek Vasut

On 6/14/22 09:08, Stefan Herbrechtsmeier wrote:

Am 13.06.2022 um 22:26 schrieb Marek Vasut:

On 6/13/22 19:23, Stefan Herbrechtsmeier wrote:


[snip]


+    if (dev_read_u32(dev, "vendor-id", &hub->vendor_id))
+    hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+
+    if (dev_read_u32(dev, "product-id", &hub->product_id))
+    hub->product_id = data->product_id;
+
+    if (dev_read_u32(dev, "device-id", &hub->device_id))
+    hub->device_id = USB251XB_DEF_DEVICE_ID;
+


[snip]


+    if (dev_read_u32(dev, "language-id", &hub->lang_id))
+    hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+


This doesn't work because the ids are 16 bit [1,2] and the 
dev_read_u32 function checks the size.



+    if (!dev_read_u32(dev, "boost-up", &hub->boost_up))
+    hub->boost_up = USB251XB_DEF_BOOST_UP;


This looks like a 8 bit value [1].


The dev_read_u32() is also capable of reading 0x 16bit value 
from DT.


What kind of problem are you running into exactly ?


Have you test the values from device tree binding documentation:

vendor-id = /bits/ 16 <0x>;
product-id = /bits/ 16 <0x>;

I get an EOVERFLOW error.


No, I only tested foo = <0x>; .

Can you send a fix ?


Should I add a function to the driver or a dev_read_u8/16, 
ofnode_read_u8/16 and friends function?


It seems more like you would have to add the _u8 and _u16 variants into 
common code, alongside the _u32 variant (should be easy) and then use 
them in this driver (should also be easy), so two patches.


[PATCH v2 1/3] arm: apple: nvme: Add SART support and RTKit buffer management

2022-06-14 Thread Janne Grunau
The NVMe firmware in the macOS 13 beta blocks or crashes with u-boot's
current minimal RTKit implementation. It does not provide buffers for
the firmware's buffer requests. The ANS2 firmware included in macOS 11
and 12 tolerates this. The firmware included in the first macOS 13 beta
requires buffers for the crashlog and ioreport endpoints to function.

In the case of the NVMe the buffers are physical memory. Access to
physical memory is guarded by what Apple calls SART.
Import m1n1's SART driver (exclusively used for the NVMe controller).
Implement buffer management helpers for RTKit. These are generic since
other devices (none in u-boot so far) require different handling.

Signed-off-by: Janne Grunau 

---

Changes in v2:
 - The generation compatible strings "apple,sart2" "apple,sart3" got
   droppend from the bindings merged for Linux 5.19. Use the SoC
   specific ones instead.

 arch/arm/include/asm/arch-apple/rtkit.h |  22 ++-
 arch/arm/include/asm/arch-apple/sart.h  |  22 +++
 arch/arm/mach-apple/Makefile|   1 +
 arch/arm/mach-apple/rtkit.c | 159 +---
 arch/arm/mach-apple/sart.c  | 230 
 drivers/nvme/nvme_apple.c   |  72 +++-
 6 files changed, 474 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-apple/sart.h
 create mode 100644 arch/arm/mach-apple/sart.c

diff --git a/arch/arm/include/asm/arch-apple/rtkit.h 
b/arch/arm/include/asm/arch-apple/rtkit.h
index 51f77f298c09..eff18ddb9d21 100644
--- a/arch/arm/include/asm/arch-apple/rtkit.h
+++ b/arch/arm/include/asm/arch-apple/rtkit.h
@@ -7,5 +7,23 @@
 #define APPLE_RTKIT_PWR_STATE_QUIESCED 0x10
 #define APPLE_RTKIT_PWR_STATE_ON   0x20
 
-int apple_rtkit_init(struct mbox_chan *);
-int apple_rtkit_shutdown(struct mbox_chan *, int);
+struct apple_rtkit_buffer {
+   void *buffer;
+   u64 dva;
+   size_t size;
+   bool is_mapped;
+};
+
+typedef int (*apple_rtkit_shmem_setup)(void *cookie,
+  struct apple_rtkit_buffer *buf);
+typedef void (*apple_rtkit_shmem_destroy)(void *cookie,
+ struct apple_rtkit_buffer *buf);
+
+struct apple_rtkit;
+
+struct apple_rtkit *apple_rtkit_init(struct mbox_chan *chan, void *cookie,
+apple_rtkit_shmem_setup shmem_setup,
+apple_rtkit_shmem_destroy shmem_destroy);
+void apple_rtkit_free(struct apple_rtkit *rtk);
+int apple_rtkit_boot(struct apple_rtkit *rtk);
+int apple_rtkit_shutdown(struct apple_rtkit *rtk, int pwrstate);
diff --git a/arch/arm/include/asm/arch-apple/sart.h 
b/arch/arm/include/asm/arch-apple/sart.h
new file mode 100644
index ..b99bdeafc0b3
--- /dev/null
+++ b/arch/arm/include/asm/arch-apple/sart.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: MIT
+ *
+ * The sart code is copied from m1n1 (https://github.com/AsahiLinux/m1n1) and
+ * licensed as MIT.
+ *
+ * (C) Copyright 2022 The Asahi Linux Contributors
+ */
+
+#ifndef SART_H
+#define SART_H
+
+#include 
+
+struct apple_sart;
+
+struct apple_sart *sart_init(ofnode node);
+void sart_free(struct apple_sart *sart);
+
+bool sart_add_allowed_region(struct apple_sart *sart, void *paddr, size_t sz);
+bool sart_remove_allowed_region(struct apple_sart *sart, void *paddr, size_t 
sz);
+
+#endif
diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
index 52f30a777b2c..50b465b9473f 100644
--- a/arch/arm/mach-apple/Makefile
+++ b/arch/arm/mach-apple/Makefile
@@ -3,3 +3,4 @@
 obj-y += board.o
 obj-y += lowlevel_init.o
 obj-y += rtkit.o
+obj-$(CONFIG_NVME_APPLE) += sart.o
diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
index 2dcb8bdd3e44..da7771844230 100644
--- a/arch/arm/mach-apple/rtkit.c
+++ b/arch/arm/mach-apple/rtkit.c
@@ -17,6 +17,7 @@
 #define APPLE_RTKIT_EP_SYSLOG 2
 #define APPLE_RTKIT_EP_DEBUG 3
 #define APPLE_RTKIT_EP_IOREPORT 4
+#define APPLE_RTKIT_EP_TRACEKIT 10
 
 /* Messages for management endpoint. */
 #define APPLE_RTKIT_MGMT_TYPE GENMASK(59, 52)
@@ -51,7 +52,102 @@
 #define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
 #define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
 
-int apple_rtkit_init(struct mbox_chan *chan)
+struct apple_rtkit {
+   struct mbox_chan *chan;
+   void *cookie;
+   apple_rtkit_shmem_setup shmem_setup;
+   apple_rtkit_shmem_destroy shmem_destroy;
+
+   struct apple_rtkit_buffer syslog_buffer;
+   struct apple_rtkit_buffer crashlog_buffer;
+   struct apple_rtkit_buffer ioreport_buffer;
+};
+
+struct apple_rtkit *apple_rtkit_init(struct mbox_chan *chan, void *cookie,
+apple_rtkit_shmem_setup shmem_setup,
+apple_rtkit_shmem_destroy shmem_destroy)
+{
+   struct apple_rtkit *rtk;
+
+   rtk = calloc(sizeof(*rtk), 1);
+   if (!rtk)
+   return NULL;
+
+   rtk->chan = chan;
+   rtk

[PATCH v2 3/3] arm: apple: Increase RTKit timeouts

2022-06-14 Thread Janne Grunau
Timeouts are not expected to happen and are handled as fatal errors.
Increase all timeouts to 1 second as defensive measure to avoid relying
on the timing behaviour of certain firmware versions or configurations.

Signed-off-by: Janne Grunau 
---

(no changes since v1)

 arch/arm/mach-apple/rtkit.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
index da7771844230..a550b553b663 100644
--- a/arch/arm/mach-apple/rtkit.c
+++ b/arch/arm/mach-apple/rtkit.c
@@ -52,6 +52,8 @@
 #define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
 #define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
 
+#define TIMEOUT_1SEC_US 100
+
 struct apple_rtkit {
struct mbox_chan *chan;
void *cookie;
@@ -168,7 +170,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
return ret;
 
/* Wait for protocol version negotiation message. */
-   ret = mbox_recv(rtk->chan, &msg, 1);
+   ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
 
@@ -210,7 +212,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
 
 wait_epmap:
/* Wait for endpoint map message. */
-   ret = mbox_recv(rtk->chan, &msg, 1);
+   ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
 
@@ -275,7 +277,7 @@ wait_epmap:
 
pwrstate = APPLE_RTKIT_PWR_STATE_SLEEP;
while (pwrstate != APPLE_RTKIT_PWR_STATE_ON) {
-   ret = mbox_recv(rtk->chan, &msg, 10);
+   ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
 
@@ -330,7 +332,7 @@ int apple_rtkit_shutdown(struct apple_rtkit *rtk, int 
pwrstate)
if (ret < 0)
return ret;
 
-   ret = mbox_recv(rtk->chan, &msg, 10);
+   ret = mbox_recv(rtk->chan, &msg, TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
 
-- 
2.35.1



[PATCH v2 2/3] MAINTAINERS: Add nvme_apple to Apple SoC section

2022-06-14 Thread Janne Grunau
Signed-off-by: Janne Grunau 

---

(no changes since v1)

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 28e4d3823861..a15ba7abdcd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -121,6 +121,7 @@ F:  arch/arm/include/asm/arch-m1/
 F: arch/arm/mach-apple/
 F: configs/apple_m1_defconfig
 F: drivers/iommu/apple_dart.c
+F: drivers/nvme/nvme_apple.c
 F: drivers/pinctrl/pinctrl-apple.c
 F: drivers/watchdog/apple_wdt.c
 F: include/configs/apple.h
-- 
2.35.1



[PATCH v2 0/3] Improve robustness of NVMe suuport for Apple silicon devices

2022-06-14 Thread Janne Grunau
Hej,

this series has assorted fixes to improve the robustness of the NVMe
support on Apple silicon devices. The main change which prompted this
series is "rm: apple: nvme: Add SART support and RTKit buffer
management". It fixes the RTKit driver required for the NVMe with the
system-wide firmware included in the first macOS 13 beta release.

The increased timeouts in RTKit are a defensive change against future
changes. None of the mailbox receive calls is expected to timeout so
waiting up to 1 second for a fatal error seems acceptable.

cheers Janne

Changes in v2:
 - update sart compatible strings to the SoC specified ones from the
   Linux devicetree bindings

Janne Grunau (3):
  arm: apple: nvme: Add SART support and RTKit buffer management
  MAINTAINERS: Add nvme_apple to Apple SoC section
  arm: apple: Increase RTKit timeouts

 MAINTAINERS |   1 +
 arch/arm/include/asm/arch-apple/rtkit.h |  22 ++-
 arch/arm/include/asm/arch-apple/sart.h  |  22 +++
 arch/arm/mach-apple/Makefile|   1 +
 arch/arm/mach-apple/rtkit.c | 161 ++---
 arch/arm/mach-apple/sart.c  | 230 
 drivers/nvme/nvme_apple.c   |  72 +++-
 7 files changed, 477 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-apple/sart.h
 create mode 100644 arch/arm/mach-apple/sart.c

-- 
2.35.1



Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

2022-06-14 Thread Stefan Herbrechtsmeier

Am 13.06.2022 um 22:26 schrieb Marek Vasut:

On 6/13/22 19:23, Stefan Herbrechtsmeier wrote:


[snip]


+    if (dev_read_u32(dev, "vendor-id", &hub->vendor_id))
+    hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+
+    if (dev_read_u32(dev, "product-id", &hub->product_id))
+    hub->product_id = data->product_id;
+
+    if (dev_read_u32(dev, "device-id", &hub->device_id))
+    hub->device_id = USB251XB_DEF_DEVICE_ID;
+


[snip]


+    if (dev_read_u32(dev, "language-id", &hub->lang_id))
+    hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+


This doesn't work because the ids are 16 bit [1,2] and the 
dev_read_u32 function checks the size.



+    if (!dev_read_u32(dev, "boost-up", &hub->boost_up))
+    hub->boost_up = USB251XB_DEF_BOOST_UP;


This looks like a 8 bit value [1].


The dev_read_u32() is also capable of reading 0x 16bit value from 
DT.


What kind of problem are you running into exactly ?


Have you test the values from device tree binding documentation:

vendor-id = /bits/ 16 <0x>;
product-id = /bits/ 16 <0x>;

I get an EOVERFLOW error.


No, I only tested foo = <0x>; .

Can you send a fix ?


Should I add a function to the driver or a dev_read_u8/16, 
ofnode_read_u8/16 and friends function?