[PATCH 9/9] board: sifive: Fix -Wint-to-pointer-cast warning

2021-09-11 Thread Bin Meng
The following warning is seen in unleashed.c in a 32-bit build:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Cast with uintptr_t.

Signed-off-by: Bin Meng 
---

 board/sifive/unleashed/unleashed.c | 2 +-
 board/sifive/unmatched/unmatched.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/sifive/unleashed/unleashed.c 
b/board/sifive/unleashed/unleashed.c
index 33baeda986..e7d2332d8c 100644
--- a/board/sifive/unleashed/unleashed.c
+++ b/board/sifive/unleashed/unleashed.c
@@ -118,7 +118,7 @@ void *board_fdt_blob_setup(void)
 {
if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
if (gd->arch.firmware_fdt_addr)
-   return (ulong *)gd->arch.firmware_fdt_addr;
+   return (ulong *)(uintptr_t)gd->arch.firmware_fdt_addr;
}
 
return (ulong *)&_end;
diff --git a/board/sifive/unmatched/unmatched.c 
b/board/sifive/unmatched/unmatched.c
index 8773b660fa..93c452c57f 100644
--- a/board/sifive/unmatched/unmatched.c
+++ b/board/sifive/unmatched/unmatched.c
@@ -15,7 +15,7 @@ void *board_fdt_blob_setup(void)
 {
if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
if (gd->arch.firmware_fdt_addr)
-   return (ulong *)gd->arch.firmware_fdt_addr;
+   return (ulong *)(uintptr_t)gd->arch.firmware_fdt_addr;
}
 
return (ulong *)&_end;
-- 
2.25.1



[PATCH 6/9] dm: Provide dev_read_addr_index_ptr() wrapper

2021-09-11 Thread Bin Meng
Like dev_read_addr_ptr(), provide a wrapper for the indexed version.

Signed-off-by: Bin Meng 
---

 include/dm/read.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/dm/read.h b/include/dm/read.h
index 5bf3405614..890bf3d847 100644
--- a/include/dm/read.h
+++ b/include/dm/read.h
@@ -180,6 +180,18 @@ int dev_read_size(const struct udevice *dev, const char 
*propname);
  */
 fdt_addr_t dev_read_addr_index(const struct udevice *dev, int index);
 
+/**
+ * dev_read_addr_index_ptr() - Get the indexed reg property of a device
+ * as a pointer
+ *
+ * @dev: Device to read from
+ * @index: the 'reg' property can hold a list of  pairs
+ *and @index is used to select which one is required
+ *
+ * @return pointer or NULL if not found
+ */
+void *dev_read_addr_index_ptr(const struct udevice *dev, int index);
+
 /**
  * dev_read_addr_size_index() - Get the indexed reg property of a device
  *
@@ -805,6 +817,12 @@ static inline fdt_addr_t dev_read_addr_index(const struct 
udevice *dev,
return devfdt_get_addr_index(dev, index);
 }
 
+static inline void *dev_read_addr_index_ptr(const struct udevice *dev,
+   int index)
+{
+   return devfdt_get_addr_index_ptr(dev, index);
+}
+
 static inline fdt_addr_t dev_read_addr_size_index(const struct udevice *dev,
  int index,
  fdt_size_t *size)
-- 
2.25.1



[PATCH 8/9] ram: sifive: Fix -Wint-to-pointer-cast warnings

2021-09-11 Thread Bin Meng
The following warning is seen in sifive_ddr.c in a 32-bit build:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Change to use dev_read_addr_index_ptr().

Signed-off-by: Bin Meng 
---

 drivers/ram/sifive/sifive_ddr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/ram/sifive/sifive_ddr.c b/drivers/ram/sifive/sifive_ddr.c
index ba18466033..4bd69a62be 100644
--- a/drivers/ram/sifive/sifive_ddr.c
+++ b/drivers/ram/sifive/sifive_ddr.c
@@ -313,7 +313,7 @@ static int sifive_ddr_setup(struct udevice *dev)
sifive_ddr_phy_fixup(denali_phy);
 
/* check size */
-   priv->info.size = get_ram_size((long *)priv->info.base,
+   priv->info.size = get_ram_size((long *)(uintptr_t)priv->info.base,
   ddr_size);
 
debug("%s : %lx\n", __func__, (uintptr_t)priv->info.size);
@@ -369,9 +369,9 @@ static int sifive_ddr_probe(struct udevice *dev)
return ret;
}
 
-   priv->ctl = (struct sifive_ddrctl *)dev_read_addr_index(dev, 0);
-   priv->phy = (struct sifive_ddrphy *)dev_read_addr_index(dev, 1);
-   priv->physical_filter_ctrl = (u32 *)dev_read_addr_index(dev, 2);
+   priv->ctl = (struct sifive_ddrctl *)dev_read_addr_index_ptr(dev, 0);
+   priv->phy = (struct sifive_ddrphy *)dev_read_addr_index_ptr(dev, 1);
+   priv->physical_filter_ctrl = (u32 *)dev_read_addr_index_ptr(dev, 2);
 
return sifive_ddr_setup(dev);
 #endif
-- 
2.25.1



[PATCH 7/9] net: macb: Fix -Wint-to-pointer-cast warnings

2021-09-11 Thread Bin Meng
The following warning is seen in macb.c in a 32-bit build:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Change to use dev_read_addr_index_ptr(), or cast with uintptr_t.

Signed-off-by: Bin Meng 
---

 drivers/net/macb.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 57ea45e2dc..fe14027b31 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -574,14 +574,9 @@ static int macb_phy_find(struct macb_device *macb, const 
char *name)
 #ifdef CONFIG_DM_ETH
 static int macb_sifive_clk_init(struct udevice *dev, ulong rate)
 {
-   fdt_addr_t addr;
void *gemgxl_regs;
 
-   addr = dev_read_addr_index(dev, 1);
-   if (addr == FDT_ADDR_T_NONE)
-   return -ENODEV;
-
-   gemgxl_regs = (void __iomem *)addr;
+   gemgxl_regs = dev_read_addr_index_ptr(dev, 1);
if (!gemgxl_regs)
return -ENODEV;
 
@@ -1383,7 +1378,7 @@ static int macb_eth_probe(struct udevice *dev)
macb->phy_addr = ofnode_read_u32_default(phandle_args.node,
 "reg", -1);
 
-   macb->regs = (void *)pdata->iobase;
+   macb->regs = (void *)(uintptr_t)pdata->iobase;
 
macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678);
 
@@ -1444,7 +1439,7 @@ static int macb_eth_of_to_plat(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_plat(dev);
 
-   pdata->iobase = (phys_addr_t)dev_remap_addr(dev);
+   pdata->iobase = (uintptr_t)dev_remap_addr(dev);
if (!pdata->iobase)
return -EINVAL;
 
-- 
2.25.1



[PATCH 5/9] dm: core: Add a new API devfdt_get_addr_index_ptr()

2021-09-11 Thread Bin Meng
At present there is only devfdt_get_addr_ptr() which only returns
the first  pair in the 'reg' property. Add a new API
devfdt_get_addr_index_ptr() to return the indexed pointer.

Signed-off-by: Bin Meng 
---

 drivers/core/fdtaddr.c | 11 ---
 include/dm/fdtaddr.h   | 12 
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index 4ffbd6b2eb..8dbb06ab03 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -93,6 +93,13 @@ fdt_addr_t devfdt_get_addr_index(const struct udevice *dev, 
int index)
 #endif
 }
 
+void *devfdt_get_addr_index_ptr(const struct udevice *dev, int index)
+{
+   fdt_addr_t addr = devfdt_get_addr_index(dev, index);
+
+   return (addr == FDT_ADDR_T_NONE) ? NULL : (void *)(uintptr_t)addr;
+}
+
 fdt_addr_t devfdt_get_addr_size_index(const struct udevice *dev, int index,
  fdt_size_t *size)
 {
@@ -155,9 +162,7 @@ fdt_addr_t devfdt_get_addr(const struct udevice *dev)
 
 void *devfdt_get_addr_ptr(const struct udevice *dev)
 {
-   fdt_addr_t addr = devfdt_get_addr_index(dev, 0);
-
-   return (addr == FDT_ADDR_T_NONE) ? NULL : (void *)(uintptr_t)addr;
+   return devfdt_get_addr_index_ptr(dev, 0);
 }
 
 void *devfdt_remap_addr_index(const struct udevice *dev, int index)
diff --git a/include/dm/fdtaddr.h b/include/dm/fdtaddr.h
index a4fda581a7..d2c1994291 100644
--- a/include/dm/fdtaddr.h
+++ b/include/dm/fdtaddr.h
@@ -92,6 +92,18 @@ void *devfdt_map_physmem(const struct udevice *dev, unsigned 
long size);
  */
 fdt_addr_t devfdt_get_addr_index(const struct udevice *dev, int index);
 
+/**
+ * devfdt_get_addr_index_ptr() - Return indexed pointer to the address of the
+ *   reg property of a device
+ *
+ * @dev: Pointer to a device
+ * @index: the 'reg' property can hold a list of  pairs
+ *and @index is used to select which one is required
+ *
+ * @return Pointer to addr, or NULL if there is no such property
+ */
+void *devfdt_get_addr_index_ptr(const struct udevice *dev, int index);
+
 /**
  * devfdt_get_addr_size_index() - Get the indexed reg property of a device
  *
-- 
2.25.1



[PATCH 4/9] i2c: ocores: Fix -Wint-to-pointer-cast warning

2021-09-11 Thread Bin Meng
The following warning is seen in ocores_i2c.c in a 32-bit build:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Change to use dev_read_addr_ptr().

Signed-off-by: Bin Meng 
---

 drivers/i2c/ocores_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/ocores_i2c.c b/drivers/i2c/ocores_i2c.c
index f129ec3818..3b19ba78fa 100644
--- a/drivers/i2c/ocores_i2c.c
+++ b/drivers/i2c/ocores_i2c.c
@@ -516,7 +516,7 @@ static int ocores_i2c_probe(struct udevice *dev)
u32 clock_frequency_khz;
int ret;
 
-   bus->base = (void __iomem *)devfdt_get_addr(dev);
+   bus->base = dev_read_addr_ptr(dev);
 
if (dev_read_u32(dev, "reg-shift", >reg_shift)) {
/* no 'reg-shift', check for deprecated 'regstep' */
-- 
2.25.1



[PATCH 3/9] gpio: sifive: Fix -Wint-to-pointer-cast warning

2021-09-11 Thread Bin Meng
dev_read_addr() returns a value of type fdt_addr_t which is a 64-bit
address and plat->base is a pointer. In a 32-bit build, this causes the
following warning seen when building sifive-gpio.c:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Change to use dev_read_addr_ptr().

Signed-off-by: Bin Meng 
---

 drivers/gpio/sifive-gpio.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/sifive-gpio.c b/drivers/gpio/sifive-gpio.c
index abd1f629b9..151f484e8f 100644
--- a/drivers/gpio/sifive-gpio.c
+++ b/drivers/gpio/sifive-gpio.c
@@ -157,13 +157,11 @@ static const struct dm_gpio_ops sifive_gpio_ops = {
 static int sifive_gpio_of_to_plat(struct udevice *dev)
 {
struct sifive_gpio_plat *plat = dev_get_plat(dev);
-   fdt_addr_t addr;
 
-   addr = dev_read_addr(dev);
-   if (addr == FDT_ADDR_T_NONE)
+   plat->base = dev_read_addr_ptr(dev);
+   if (!plat->base)
return -EINVAL;
 
-   plat->base = (void *)addr;
return 0;
 }
 
-- 
2.25.1



[PATCH 2/9] clk: sifive: Fix -Wint-to-pointer-cast warning

2021-09-11 Thread Bin Meng
dev_read_addr() returns a value of type fdt_addr_t which is a 64-bit
address and pd->va is a pointer. In a 32-bit build, this causes the
following warning seen when building sifive-prci.c:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Change to use dev_read_addr_ptr().

Signed-off-by: Bin Meng 
---

 drivers/clk/sifive/sifive-prci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sifive/sifive-prci.c b/drivers/clk/sifive/sifive-prci.c
index cd1acb9442..52ae268e0c 100644
--- a/drivers/clk/sifive/sifive-prci.c
+++ b/drivers/clk/sifive/sifive-prci.c
@@ -653,9 +653,9 @@ static int sifive_prci_probe(struct udevice *dev)
struct prci_clk_desc *data =
(struct prci_clk_desc *)dev_get_driver_data(dev);
 
-   pd->va = (void *)dev_read_addr(dev);
-   if (IS_ERR(pd->va))
-   return PTR_ERR(pd->va);
+   pd->va = dev_read_addr_ptr(dev);
+   if (!pd->va)
+   return -EINVAL;
 
err = clk_get_by_index(dev, 0, >parent_hfclk);
if (err)
-- 
2.25.1



[PATCH 1/9] cache: sifive: Fix -Wint-to-pointer-cast warning

2021-09-11 Thread Bin Meng
The following warning is seen in cache-sifive-ccache.c in a 32-bit build:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Fix by casting it with uintptr_t.

Signed-off-by: Bin Meng 
---

 drivers/cache/cache-sifive-ccache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cache/cache-sifive-ccache.c 
b/drivers/cache/cache-sifive-ccache.c
index 76c0ab26ae..c8766f6242 100644
--- a/drivers/cache/cache-sifive-ccache.c
+++ b/drivers/cache/cache-sifive-ccache.c
@@ -38,7 +38,7 @@ static int sifive_ccache_get_info(struct udevice *dev, struct 
cache_info *info)
 {
struct sifive_ccache *priv = dev_get_priv(dev);
 
-   info->base = (phys_addr_t)priv->base;
+   info->base = (uintptr_t)priv->base;
 
return 0;
 }
-- 
2.25.1



Re: [PATCH v5 3/4] sysreset: provide SBI based sysreset driver

2021-09-11 Thread Sean Anderson

On 9/10/21 10:15 AM, Heinrich Schuchardt wrote:

Provide sysreset driver using the SBI system reset extension.

Signed-off-by: Heinrich Schuchardt 
---
v5:
* don't add __efi_runtime
* use '=' not ':' in array initialization with enum indices
v4:
* remove the UEFI SystemReset() implementation
* simplify the code using an array to translate reset types
* remove a superfluos check to determine if the device was probed
---
  MAINTAINERS |  1 +
  arch/riscv/cpu/cpu.c| 13 -
  arch/riscv/include/asm/sbi.h|  1 +
  arch/riscv/lib/sbi.c| 12 
  drivers/sysreset/Kconfig| 12 
  drivers/sysreset/Makefile   |  1 +
  drivers/sysreset/sysreset_sbi.c | 51 +
  7 files changed, 90 insertions(+), 1 deletion(-)
  create mode 100644 drivers/sysreset/sysreset_sbi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4cf0c33c5d..88d7aa2bc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1017,6 +1017,7 @@ T:git 
https://source.denx.de/u-boot/custodians/u-boot-riscv.git
  F:arch/riscv/
  F:cmd/riscv/
  F:doc/usage/sbi.rst
+F: drivers/sysreset/sysreset_sbi.c
  F:drivers/timer/andes_plmt_timer.c
  F:drivers/timer/sifive_clint_timer.c
  F:tools/prelink-riscv.c
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index c894ac10b5..8e49b6d736 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -6,6 +6,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -138,7 +139,17 @@ int arch_cpu_init_dm(void)
  
  int arch_early_init_r(void)

  {
-   return riscv_cpu_probe();
+   int ret;
+
+   ret = riscv_cpu_probe();
+   if (ret)
+   return ret;
+
+   if (IS_ENABLED(CONFIG_SYSRESET_SBI))
+   device_bind_driver(gd->dm_root, "sbi-sysreset",
+  "sbi-sysreset", NULL);
+
+   return 0;
  }
  
  /**

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 34a115afc3..5030892b47 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -153,5 +153,6 @@ void sbi_set_timer(uint64_t stime_value);
  long sbi_get_spec_version(void);
  int sbi_get_impl_id(void);
  int sbi_probe_extension(int ext);
+void sbi_srst_reset(unsigned long type, unsigned long reason);
  
  #endif

diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c
index 77845a73ca..2b53896b8a 100644
--- a/arch/riscv/lib/sbi.c
+++ b/arch/riscv/lib/sbi.c
@@ -108,6 +108,18 @@ int sbi_probe_extension(int extid)
return -ENOTSUPP;
  }
  
+/**

+ * sbi_srst_reset() - invoke system reset extension
+ *
+ * @type:  type of reset
+ * @reason:reason for reset
+ */
+void sbi_srst_reset(unsigned long type, unsigned long reason)
+{
+   sbi_ecall(SBI_EXT_SRST, SBI_EXT_SRST_RESET, type, reason,
+ 0, 0, 0, 0);
+}
+
  #ifdef CONFIG_SBI_V01
  
  /**

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index ac77ffbc8b..43a948cfcd 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -85,6 +85,18 @@ config SYSRESET_PSCI
  Enable PSCI SYSTEM_RESET function call.  To use this, PSCI firmware
  must be running on your system.
  
+config SYSRESET_SBI

+   bool "Enable support for SBI System Reset"
+   depends on RISCV_SMODE && SBI_V02
+   select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
+   help
+ Enable system reset and poweroff via the SBI system reset extension.
+ The extension was introduced in version 0.3 of the SBI specification.
+
+ If the SBI implementation provides the extension, is board specific.
+ The RISC-V platform specification mandates the extension for rich
+ operating system platforms.
+
  config SYSRESET_SOCFPGA
bool "Enable support for Intel SOCFPGA family"
depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_GEN5 || 
TARGET_SOCFPGA_ARRIA10)
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index de81c399d7..8e00be0779 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_SYSRESET_MPC83XX) += sysreset_mpc83xx.o
  obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
  obj-$(CONFIG_SYSRESET_OCTEON) += sysreset_octeon.o
  obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_SBI) += sysreset_sbi.o
  obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
  obj-$(CONFIG_SYSRESET_SOCFPGA_SOC64) += sysreset_socfpga_soc64.o
  obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
diff --git a/drivers/sysreset/sysreset_sbi.c b/drivers/sysreset/sysreset_sbi.c
new file mode 100644
index 00..5e8090d62b
--- /dev/null
+++ b/drivers/sysreset/sysreset_sbi.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021, Heinrich Schuchardt 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+

Re: [PATCH] ARM: dts: imx8mm-verdin: Set PHY mode to RGMII-ID

2021-09-11 Thread Marek Vasut

On 9/12/21 12:53 AM, Marcel Ziswiler wrote:

Hi Marek

On Sun, 2021-09-12 at 00:43 +0200, Marek Vasut wrote:

Since c6df0e2ffdc ("net: phy: micrel: add support for DLL setup on ksz9131")
the Micrel PHY driver correctly configures the delay register. The Verdin PHY
is RGMII-ID, so reflect that in DT, otherwise the ethernet no longer works.


Yes, however, one should also get rid of the proprietary PHY setup in our board 
setup.

Remember, I already did send this as part of my target refresh series:

https://marc.info/?l=u-boot=162990456210415


ACK, that patch of yours is a better patch too.


Re: [PATCH] ARM: dts: imx8mm-verdin: Set PHY mode to RGMII-ID

2021-09-11 Thread Marcel Ziswiler
Hi Marek

On Sun, 2021-09-12 at 00:43 +0200, Marek Vasut wrote:
> Since c6df0e2ffdc ("net: phy: micrel: add support for DLL setup on ksz9131")
> the Micrel PHY driver correctly configures the delay register. The Verdin PHY
> is RGMII-ID, so reflect that in DT, otherwise the ethernet no longer works.

Yes, however, one should also get rid of the proprietary PHY setup in our board 
setup.

Remember, I already did send this as part of my target refresh series:

https://marc.info/?l=u-boot=162990456210415

> Signed-off-by: Marek Vasut 
> Cc: Marcel Ziswiler 
> Cc: Max Krummenacher 
> Cc: Oleksandr Suvorov 
> ---
>  arch/arm/dts/imx8mm-verdin.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
> index fb0756d6e19..ac2a4b69d3c 100644
> --- a/arch/arm/dts/imx8mm-verdin.dts
> +++ b/arch/arm/dts/imx8mm-verdin.dts
> @@ -160,7 +160,7 @@
>   {
> fsl,magic-packet;
> phy-handle = <>;
> -   phy-mode = "rgmii";
> +   phy-mode = "rgmii-id";
> phy-supply = <_ethphy>;
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <_fec1>;

Cheers

Marcel


[PATCH] ARM: dts: imx8mm-verdin: Set PHY mode to RGMII-ID

2021-09-11 Thread Marek Vasut
Since c6df0e2ffdc ("net: phy: micrel: add support for DLL setup on ksz9131")
the Micrel PHY driver correctly configures the delay register. The Verdin PHY
is RGMII-ID, so reflect that in DT, otherwise the ethernet no longer works.

Signed-off-by: Marek Vasut 
Cc: Marcel Ziswiler 
Cc: Max Krummenacher 
Cc: Oleksandr Suvorov 
---
 arch/arm/dts/imx8mm-verdin.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
index fb0756d6e19..ac2a4b69d3c 100644
--- a/arch/arm/dts/imx8mm-verdin.dts
+++ b/arch/arm/dts/imx8mm-verdin.dts
@@ -160,7 +160,7 @@
  {
fsl,magic-packet;
phy-handle = <>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-supply = <_ethphy>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <_fec1>;
-- 
2.33.0



[PATCH 3/3] ARM: imx: mx5: Add altbootcmd and resets to M53Menlo

2021-09-11 Thread Marek Vasut
Bulletproof the default boot command with reset statements in case
any command in the chain would fail. In case a failure were to happen,
the board will reset, increment boot counter and retry the procedure.
In case the failures persist and the boot counter reaches the bootlimit,
U-Boot starts altbootcmd instead of the default bootcmd boot command.

The altbootcmd swaps the default boot partition for the other boot
partition, which is an identical copy or an older copy, and tries
booting from that one instead.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 include/configs/m53menlo.h | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/include/configs/m53menlo.h b/include/configs/m53menlo.h
index bd117daf063..9bec05bf0bd 100644
--- a/include/configs/m53menlo.h
+++ b/include/configs/m53menlo.h
@@ -184,6 +184,13 @@
"splashfile=boot/usplash.bmp.gz\0"  \
"splashimage=0x8800\0"  \
"splashpos=m,m\0"   \
+   "altbootcmd="   \
+   "if test ${mmcpart} -eq 1 ; then "  \
+   "setenv mmcpart 2 ; "   \
+   "else " \
+   "setenv mmcpart 1 ; "   \
+   "fi ; " \
+   "boot\0"\
"stdout=serial,vidconsole\0"\
"stderr=serial,vidconsole\0"\
"addcons="  \
@@ -198,14 +205,14 @@
"setenv bootargs ${bootargs} ${miscargs}\0" \
"addargs=run addcons addmisc addmtd\0"  \
"mmcload="  \
-   "mmc rescan ; load mmc ${mmcdev}:${mmcpart} "   \
-   "${kernel_addr_r} ${bootfile}\0"\
+   "mmc rescan || reset ; load mmc ${mmcdev}:${mmcpart} "  \
+   "${kernel_addr_r} ${bootfile} || reset\0"   \
"miscargs=nohlt panic=1\0"  \
"mmcargs=setenv bootargs root=/dev/mmcblk0p${mmcpart} rw "  \
"rootwait\0"\
"mmc_mmc="  \
-   "run mmcload mmcargs addargs ; "\
-   "bootm ${kernel_addr_r}\0"  \
+   "run mmcload mmcargs addargs || reset ; "   \
+   "bootm ${kernel_addr_r} ; reset\0"  \
"netload=tftp ${kernel_addr_r} ${hostname}/${bootfile}\0"   \
"net_nfs="  \
"run netload nfsargs addip addargs ; "  \
-- 
2.33.0



[PATCH 2/3] ARM: imx: mx5: Enable Thumb2 build on MX53 Menlo board

2021-09-11 Thread Marek Vasut
Build U-Boot in Thumb2 mode for M53Menlo board, this makes better
use of the CPU since the instruction density is higher.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 configs/m53menlo_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
index 97605b2711b..0656cd86816 100644
--- a/configs/m53menlo_defconfig
+++ b/configs/m53menlo_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_MX5=y
 CONFIG_SYS_TEXT_BASE=0x7100
 CONFIG_SPL_GPIO=y
-- 
2.33.0



[PATCH 1/3] ARM: imx: mx5: Enable BMODE command on MX53 Menlo board

2021-09-11 Thread Marek Vasut
The board can do primary/secondary boot switching, enable the bmode command.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 board/menlo/m53menlo/m53menlo.c | 5 +
 configs/m53menlo_defconfig  | 1 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/board/menlo/m53menlo/m53menlo.c b/board/menlo/m53menlo/m53menlo.c
index 2b331b32df5..9545e633a3d 100644
--- a/board/menlo/m53menlo/m53menlo.c
+++ b/board/menlo/m53menlo/m53menlo.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -334,6 +335,10 @@ int splash_screen_prepare(void)
 
 int board_late_init(void)
 {
+#ifdef CONFIG_CMD_BMODE
+   add_board_boot_modes(NULL);
+#endif
+
 #if defined(CONFIG_VIDEO_IPUV3)
struct udevice *dev;
int xpos, ypos, ret;
diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
index 505dd078b0c..97605b2711b 100644
--- a/configs/m53menlo_defconfig
+++ b/configs/m53menlo_defconfig
@@ -18,7 +18,6 @@ CONFIG_SYS_BOOTCOUNT_ADDR=0x53FA401C
 CONFIG_SPL=y
 CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
 CONFIG_ENV_OFFSET_REDUND=0x18
-# CONFIG_CMD_BMODE is not set
 CONFIG_FIT=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/menlo/m53menlo/imximage.cfg"
-- 
2.33.0



[PATCH 3/3] gpio: Factor out DT flag translation

2021-09-11 Thread Samuel Holland
The generic GPIO flags binding is shared across many drivers, some of
which need their own xlate function. Factor out the flag translation
code from gpio_xlate_offs_flags so it does not need to be duplicated.

Signed-off-by: Samuel Holland 
---

 drivers/gpio/gpio-uclass.c | 50 ++
 include/asm-generic/gpio.h |  8 ++
 2 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 6f2b1adfdec..b88b4290a45 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -185,6 +185,34 @@ int gpio_lookup_name(const char *name, struct udevice 
**devp,
return 0;
 }
 
+unsigned long gpio_flags_xlate(uint32_t arg)
+{
+   unsigned long flags = 0;
+
+   if (arg & GPIO_ACTIVE_LOW)
+   flags |= GPIOD_ACTIVE_LOW;
+
+   /*
+* need to test 2 bits for gpio output binding:
+* OPEN_DRAIN (0x6) = SINGLE_ENDED (0x2) | LINE_OPEN_DRAIN (0x4)
+* OPEN_SOURCE (0x2) = SINGLE_ENDED (0x2) | LINE_OPEN_SOURCE (0x0)
+*/
+   if (arg & GPIO_SINGLE_ENDED) {
+   if (arg & GPIO_LINE_OPEN_DRAIN)
+   flags |= GPIOD_OPEN_DRAIN;
+   else
+   flags |= GPIOD_OPEN_SOURCE;
+   }
+
+   if (arg & GPIO_PULL_UP)
+   flags |= GPIOD_PULL_UP;
+
+   if (arg & GPIO_PULL_DOWN)
+   flags |= GPIOD_PULL_DOWN;
+
+   return flags;
+}
+
 int gpio_xlate_offs_flags(struct udevice *dev, struct gpio_desc *desc,
  struct ofnode_phandle_args *args)
 {
@@ -200,27 +228,7 @@ int gpio_xlate_offs_flags(struct udevice *dev, struct 
gpio_desc *desc,
if (args->args_count < 2)
return 0;
 
-   desc->flags = 0;
-   if (args->args[1] & GPIO_ACTIVE_LOW)
-   desc->flags |= GPIOD_ACTIVE_LOW;
-
-   /*
-* need to test 2 bits for gpio output binding:
-* OPEN_DRAIN (0x6) = SINGLE_ENDED (0x2) | LINE_OPEN_DRAIN (0x4)
-* OPEN_SOURCE (0x2) = SINGLE_ENDED (0x2) | LINE_OPEN_SOURCE (0x0)
-*/
-   if (args->args[1] & GPIO_SINGLE_ENDED) {
-   if (args->args[1] & GPIO_LINE_OPEN_DRAIN)
-   desc->flags |= GPIOD_OPEN_DRAIN;
-   else
-   desc->flags |= GPIOD_OPEN_SOURCE;
-   }
-
-   if (args->args[1] & GPIO_PULL_UP)
-   desc->flags |= GPIOD_PULL_UP;
-
-   if (args->args[1] & GPIO_PULL_DOWN)
-   desc->flags |= GPIOD_PULL_DOWN;
+   desc->flags = gpio_flags_xlate(args->args[1]);
 
return 0;
 }
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index e33cde7abdd..911b11bc389 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -221,6 +221,14 @@ int gpio_requestf(unsigned gpio, const char *fmt, ...)
 
 struct fdtdec_phandle_args;
 
+/**
+ * gpio_flags_xlate() - convert DT flags to internal flags
+ *
+ * This routine converts the GPIO_* flags from the generic DT binding to the
+ * GPIOD_* flags used internally. It can be called from driver xlate functions.
+ */
+unsigned long gpio_flags_xlate(uint32_t arg);
+
 /**
  * gpio_xlate_offs_flags() - implementation for common use of dm_gpio_ops.xlate
  *
-- 
2.31.1



[PATCH 1/3] gpio: Verify validity of pin offsets when looking up names

2021-09-11 Thread Samuel Holland
Translation of a pin name to a device+offset should fail if the offset
is larger than the number of pins in the GPIO bank.

Signed-off-by: Samuel Holland 
---

 drivers/gpio/gpio-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 8c7dbe3..57e87960ee4 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -140,7 +140,8 @@ int dm_gpio_lookup_name(const char *name, struct gpio_desc 
*desc)
 
if (!strncasecmp(name, uc_priv->bank_name, len)) {
if (!strict_strtoul(name + len, 10, ))
-   break;
+   if (offset < uc_priv->gpio_count)
+   break;
}
 
/*
-- 
2.31.1



[PATCH 2/3] gpio: Verify validity of pin offsets from device trees

2021-09-11 Thread Samuel Holland
Translation of an OF GPIO specifier should fail if the pin offset is
larger than the number of pins in the GPIO bank.

Signed-off-by: Samuel Holland 
---

 drivers/gpio/gpio-uclass.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 57e87960ee4..6f2b1adfdec 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -188,10 +188,14 @@ int gpio_lookup_name(const char *name, struct udevice 
**devp,
 int gpio_xlate_offs_flags(struct udevice *dev, struct gpio_desc *desc,
  struct ofnode_phandle_args *args)
 {
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+
if (args->args_count < 1)
return -EINVAL;
 
desc->offset = args->args[0];
+   if (desc->offset >= uc_priv->gpio_count)
+   return -EINVAL;
 
if (args->args_count < 2)
return 0;
-- 
2.31.1



[PATCH 0/3] gpio: uclass enhancements for DM_GPIO drivers

2021-09-11 Thread Samuel Holland
This series makes a couple of enhancements to the generic GPIO code that
simplified updating some DM_GPIO drivers.

Patches 1-2 add bounds checking when looking up GPIOs by name and from
the device tree. After this, all functions that fill out a gpio_desc
ensure the offset field is in bounds, so each driver doesn't need
separate bounds checking in its ops functions.

Patch 3 allows the GPIO flag translation code to be shared by drivers
that use the same flags, but cannot use gpio_xlate_offs_flags directly.
For example, the sunxi GPIO binding has 3 cells because it separates the
bank and pin numbers.


Samuel Holland (3):
  gpio: Verify validity of pin offsets when looking up names
  gpio: Verify validity of pin offsets from device trees
  gpio: Factor out DT flag translation

 drivers/gpio/gpio-uclass.c | 55 +++---
 include/asm-generic/gpio.h |  8 ++
 2 files changed, 42 insertions(+), 21 deletions(-)

-- 
2.31.1



Re: Problem with U-boot | Configuration Signature not being checked while booting

2021-09-11 Thread Moiz Imtiaz
Completely agreed, that a fully secure boot on pi won't be achievable
because the Root of Trust (ROT) cant be established from the BOTROM/EEPROM.
Plus Pi doesn't have any High Assurance Boot (HAB).  But given the
scenerio, whatever we can achieve i.e if we can verify the kernel, the
device tree, from the bootloader, (u-boot)  that would be great.

Currently the issue with Pi4 is that , signature verification is not being
done with u-boot, so wondering if that can be made possible.

>But that applies to the scenario where the public key is stored in the
> device tree embedded in u-boot itself as well

Just for the sake of knowledge, Isn't this the case with all u-boot, that
the public key is stored in the device tree (control FDT) and is embedded
in the u-boot.

On Sun, 12 Sep 2021, 02:34 Tom Rini,  wrote:

> On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
> > > Date: Sat, 11 Sep 2021 17:05:45 -0400
> > > From: Tom Rini 
> > >
> > > On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > > > > From: Moiz Imtiaz 
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot,
> but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there
> isn't any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> > > > > add the dtb and other dts dtsi
> > > > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> > > > > from the raspberry pi Linux and compile them with
> CONFIG_OF_SEPARATE and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
> U-Boot and
> > > > > it would just give a blank screen*. I wonder why there isn't any
> device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> supported by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device
> tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > In this case, doesn't the Pi firmware pass along apply overlays and
> > > construct the device tree it's going to pass along, so in this case you
> > > would want to make an "overlay" for the Pi firmware to apply and pass
> > > along to U-Boot, that includes the required information?
> >
> > yes, that might work.  The overlay can be specified in the config.txt
> file.
> >
> > I think truly verified boot is impossible on the Pi though, as u-boot
> > and the overlay file will need to be stored on the uSD card of the Pi.
> > But that applies to the scenario where the public key is stored in the
> > device tree embedded in u-boot itself as well.
>
> Yes, a more general problem is that some platforms are really only
> proof-of-concept useful.  If you can't start with the ROM, you're going
> to be limited.
>
>
> --
> Tom
>


[PATCH 3/3] sunxi: gpio: Remove bank-specific size macros

2021-09-11 Thread Samuel Holland
Since the beginning, all banks have had space for 32 pins, even when
not all pins were implemented. Let's use a single constant for the GPIO
bank size here, like the GPIO driver is already doing.

Signed-off-by: Samuel Holland 
---

 arch/arm/include/asm/arch-sunxi/gpio.h | 14 ++
 drivers/gpio/sunxi_gpio.c  |  2 --
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index c93c051a19f..cd5e85988b1 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -93,20 +93,10 @@ struct sunxi_gpio_reg {
 #define GPIO_PULL_OFFSET(pin)  pin) & 0x1f) & 0xf) << 1)
 
 /* GPIO bank sizes */
-#define SUNXI_GPIO_A_NR32
-#define SUNXI_GPIO_B_NR32
-#define SUNXI_GPIO_C_NR32
-#define SUNXI_GPIO_D_NR32
-#define SUNXI_GPIO_E_NR32
-#define SUNXI_GPIO_F_NR32
-#define SUNXI_GPIO_G_NR32
-#define SUNXI_GPIO_H_NR32
-#define SUNXI_GPIO_I_NR32
-#define SUNXI_GPIO_L_NR32
-#define SUNXI_GPIO_M_NR32
+#define SUNXI_GPIOS_PER_BANK   32
 
 #define SUNXI_GPIO_NEXT(__gpio) \
-   ((__gpio##_START) + (__gpio##_NR) + 0)
+   ((__gpio##_START) + SUNXI_GPIOS_PER_BANK)
 
 enum sunxi_gpio_number {
SUNXI_GPIO_A_START = 0,
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 7ce3ef73b46..ed26eb011f4 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -19,8 +19,6 @@
 #include 
 #include 
 
-#define SUNXI_GPIOS_PER_BANK   SUNXI_GPIO_A_NR
-
 struct sunxi_gpio_plat {
struct sunxi_gpio *regs;
const char *bank_name;  /* Name of bank, e.g. "B" */
-- 
2.31.1



[PATCH 2/3] sunxi: gpio: Remove name_to_gpio macro

2021-09-11 Thread Samuel Holland
This clarifies which callers must be updated to complete the DM_GPIO
conversion.

The only remaining caller of name_to_gpio in generic code is inside the
!DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so
that code cannot be reached. And after this commit, there are only two
remaining implementations of name_to_gpio.

Signed-off-by: Samuel Holland 
---

 arch/arm/include/asm/arch-sunxi/gpio.h |  1 -
 drivers/spi/spi-sunxi.c|  2 +-
 drivers/video/Kconfig  | 10 +-
 drivers/video/hitachi_tx18d42vm_lcd.c  |  6 +++---
 drivers/video/sunxi/sunxi_display.c| 10 +-
 5 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 2969a530ae1..c93c051a19f 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -244,7 +244,6 @@ int sunxi_gpio_set_drv(u32 pin, u32 val);
 int sunxi_gpio_set_pull(u32 pin, u32 val);
 int sunxi_name_to_gpio_bank(const char *name);
 int sunxi_name_to_gpio(const char *name);
-#define name_to_gpio(name) sunxi_name_to_gpio(name)
 
 #if !defined CONFIG_SPL_BUILD && defined CONFIG_AXP_GPIO
 int axp_gpio_init(void);
diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
index 4ca5d3a93ac..bc2f544e863 100644
--- a/drivers/spi/spi-sunxi.c
+++ b/drivers/spi/spi-sunxi.c
@@ -245,7 +245,7 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
break;
}
 
-   pin = name_to_gpio(pin_name);
+   pin = sunxi_name_to_gpio(pin_name);
if (pin < 0)
break;
 
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b1f8a9c1e62..b0c52a500df 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -452,7 +452,7 @@ config VIDEO_LCD_SSD2828_RESET
default ""
---help---
The reset pin of SSD2828 chip. This takes a string in the format
-   understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
+   understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
H.
 
 config VIDEO_LCD_TDO_TL070WSH30
bool "TDO TL070WSH30 DSI LCD panel support"
@@ -477,7 +477,7 @@ config VIDEO_LCD_SPI_CS
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
-   understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
+   understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
H.
 
 config VIDEO_LCD_SPI_SCLK
string "SPI SCLK pin for LCD related config job"
@@ -487,7 +487,7 @@ config VIDEO_LCD_SPI_SCLK
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
-   understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
+   understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
H.
 
 config VIDEO_LCD_SPI_MOSI
string "SPI MOSI pin for LCD related config job"
@@ -497,7 +497,7 @@ config VIDEO_LCD_SPI_MOSI
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
-   understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
+   understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
H.
 
 config VIDEO_LCD_SPI_MISO
string "SPI MISO pin for LCD related config job (optional)"
@@ -509,7 +509,7 @@ config VIDEO_LCD_SPI_MISO
different hardware setups. If wired up, this pin may provide additional
useful functionality. Such as bi-directional communication with the
hardware and LCD panel id retrieval (if the panel can report it). The
-   option takes a string in the format understood by 'name_to_gpio'
+   option takes a string in the format understood by 'sunxi_name_to_gpio'
function, e.g. PH1 for pin 1 of port H.
 
 source "drivers/video/meson/Kconfig"
diff --git a/drivers/video/hitachi_tx18d42vm_lcd.c 
b/drivers/video/hitachi_tx18d42vm_lcd.c
index c6c8df6a96e..87c4d27438a 100644
--- a/drivers/video/hitachi_tx18d42vm_lcd.c
+++ b/drivers/video/hitachi_tx18d42vm_lcd.c
@@ -49,9 +49,9 @@ int hitachi_tx18d42vm_init(void)
};
int i, cs, clk, mosi, ret = 0;
 
-   cs = name_to_gpio(CONFIG_VIDEO_LCD_SPI_CS);
-   clk = name_to_gpio(CONFIG_VIDEO_LCD_SPI_SCLK);
-   mosi = name_to_gpio(CONFIG_VIDEO_LCD_SPI_MOSI);
+   cs = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_CS);
+   clk = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_SCLK);
+   

[PATCH 1/3] sunxi: Clean up inclusions of asm/arch/gpio.h

2021-09-11 Thread Samuel Holland
As part of migrating to DM_GPIO and DM_PINCTRL, eventually we will
remove the asm/arch/gpio.h header. In preparation, clean up the various
files that include it.

Some files did not contain any GPIO code at all, so this header was
completely unused.

A few files contained only legacy platform-specific GPIO code for
setting up pin muxes. They were left unchanged, as that code will be
completely removed by the DM_PINCTRL migration.

The remaining files contain some combination of DM_GPIO and legacy GPIO
code. For those, switch to including asm/gpio.h (if it wasn't included
already). Right now, this header provides both sets of functions,
because ARCH_SUNXI selects GPIO_EXTRA_HEADER. This will still be the
right header to include once the DM_GPIO migration is complete and
GPIO_EXTRA_HEADER is no longer needed.

Signed-off-by: Samuel Holland 
---

 arch/arm/mach-sunxi/board.c | 1 -
 arch/arm/mach-sunxi/clock.c | 1 -
 arch/arm/mach-sunxi/clock_sun4i.c   | 1 -
 board/sunxi/board.c | 1 -
 board/sunxi/gmac.c  | 1 -
 drivers/gpio/axp_gpio.c | 1 -
 drivers/gpio/sunxi_gpio.c   | 1 -
 drivers/mmc/sunxi_mmc.c | 3 +--
 drivers/net/sun8i_emac.c| 5 +
 drivers/power/axp809.c  | 1 -
 drivers/power/axp818.c  | 1 -
 drivers/usb/musb-new/sunxi.c| 2 --
 drivers/video/sunxi/sunxi_display.c | 1 -
 drivers/video/sunxi/sunxi_lcd.c | 1 -
 14 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index d9b04f75fc4..373cb56db49 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock.c b/arch/arm/mach-sunxi/clock.c
index f591affebf7..de7e8752988 100644
--- a/arch/arm/mach-sunxi/clock.c
+++ b/arch/arm/mach-sunxi/clock.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock_sun4i.c 
b/arch/arm/mach-sunxi/clock_sun4i.c
index 57ee018eaa2..471609764d2 100644
--- a/arch/arm/mach-sunxi/clock_sun4i.c
+++ b/arch/arm/mach-sunxi/clock_sun4i.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #ifdef CONFIG_SPL_BUILD
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2b7d655678d..dcd7f0b4375 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
index d8fdf7728e0..1fa54ed72de 100644
--- a/board/sunxi/gmac.c
+++ b/board/sunxi/gmac.c
@@ -4,7 +4,6 @@
 #include 
 #include 
 #include 
-#include 
 
 void eth_init_board(void)
 {
diff --git a/drivers/gpio/axp_gpio.c b/drivers/gpio/axp_gpio.c
index 73058cf40b4..35585dc8ac9 100644
--- a/drivers/gpio/axp_gpio.c
+++ b/drivers/gpio/axp_gpio.c
@@ -6,7 +6,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 24cb604e3e3..7ce3ef73b46 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 178b8cf106d..c62b5f5a6f9 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -15,12 +15,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 
 #ifndef CCM_MMC_CTRL_MODE_SEL_NEW
diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index d7553fe1634..46786d9f764 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -14,9 +14,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -31,9 +31,6 @@
 #include 
 #include 
 #include 
-#if CONFIG_IS_ENABLED(DM_GPIO)
-#include 
-#endif
 
 #define MDIO_CMD_MII_BUSY  BIT(0)
 #define MDIO_CMD_MII_WRITE BIT(1)
diff --git a/drivers/power/axp809.c b/drivers/power/axp809.c
index 6323492b66d..0396502cdb5 100644
--- a/drivers/power/axp809.c
+++ b/drivers/power/axp809.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/power/axp818.c b/drivers/power/axp818.c
index 0531707c8aa..2dc736467bb 100644
--- a/drivers/power/axp818.c
+++ b/drivers/power/axp818.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index fea4105f3d1..7e62e3fe6ea 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -25,8 +25,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/sunxi/sunxi_display.c 

[PATCH 0/3] sunxi: Cleanup to prepare for DM_GPIO/DM_PINCTRL

2021-09-11 Thread Samuel Holland
I have a patch series in progresss to migrate sunxi to a DM_PINCTRL
driver and convert the remaining legacy GPIO users (outside of SPL).

This is one of several small independent sets of preparatory patches
I will be sending in order to minimize the size of the main series
(which has >100 patches at this point).


Samuel Holland (3):
  sunxi: Clean up inclusions of asm/arch/gpio.h
  sunxi: gpio: Remove name_to_gpio macro
  sunxi: gpio: Remove bank-specific size macros

 arch/arm/include/asm/arch-sunxi/gpio.h | 15 ++-
 arch/arm/mach-sunxi/board.c|  1 -
 arch/arm/mach-sunxi/clock.c|  1 -
 arch/arm/mach-sunxi/clock_sun4i.c  |  1 -
 board/sunxi/board.c|  1 -
 board/sunxi/gmac.c |  1 -
 drivers/gpio/axp_gpio.c|  1 -
 drivers/gpio/sunxi_gpio.c  |  3 ---
 drivers/mmc/sunxi_mmc.c|  3 +--
 drivers/net/sun8i_emac.c   |  5 +
 drivers/power/axp809.c |  1 -
 drivers/power/axp818.c |  1 -
 drivers/spi/spi-sunxi.c|  2 +-
 drivers/usb/musb-new/sunxi.c   |  2 --
 drivers/video/Kconfig  | 10 +-
 drivers/video/hitachi_tx18d42vm_lcd.c  |  6 +++---
 drivers/video/sunxi/sunxi_display.c| 11 +--
 drivers/video/sunxi/sunxi_lcd.c|  1 -
 18 files changed, 18 insertions(+), 48 deletions(-)

-- 
2.31.1



Re: Problem with U-boot | Configuration Signature not being checked while booting

2021-09-11 Thread Tom Rini
On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
> > Date: Sat, 11 Sep 2021 17:05:45 -0400
> > From: Tom Rini 
> > 
> > On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > > > From: Moiz Imtiaz 
> > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > 
> > > > Hi Simon,
> > > > 
> > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > 
> > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > instead one provided by the earlier-stage firmware?
> > > > 
> > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried 
> > > > to
> > > > add the dtb and other dts dtsi
> > > > files
> > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot 
> > > > and
> > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > RPI4?
> > > 
> > > The issue with the rpi4 is that the addresses of devices move around
> > > based on the version of the Raspberry Pi firmware you're using.  And
> > > possibly on the amount of memory on the board as well.  So U-Boot
> > > pretty much has to use the device tree passed by the firmware since
> > > the device tree in the U-Boot tree would be wrong for many
> > > combinations of firmware and hardware.
> > > 
> > > Simon, this sort of thing is exactly the reason why I think the idea
> > > of having all U-Boot configuration information in a single device tree
> > > with the hardware description doesn't work everywhere.
> > 
> > In this case, doesn't the Pi firmware pass along apply overlays and
> > construct the device tree it's going to pass along, so in this case you
> > would want to make an "overlay" for the Pi firmware to apply and pass
> > along to U-Boot, that includes the required information?
> 
> yes, that might work.  The overlay can be specified in the config.txt file.
> 
> I think truly verified boot is impossible on the Pi though, as u-boot
> and the overlay file will need to be stored on the uSD card of the Pi.
> But that applies to the scenario where the public key is stored in the
> device tree embedded in u-boot itself as well.

Yes, a more general problem is that some platforms are really only
proof-of-concept useful.  If you can't start with the ROM, you're going
to be limited.


-- 
Tom


signature.asc
Description: PGP signature


Re: Problem with U-boot | Configuration Signature not being checked while booting

2021-09-11 Thread Mark Kettenis
> Date: Sat, 11 Sep 2021 17:05:45 -0400
> From: Tom Rini 
> 
> On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > > From: Moiz Imtiaz 
> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > 
> > > Hi Simon,
> > > 
> > > Thanks for the reply.  I already followed the steps mentioned in
> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > 
> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > instead one provided by the earlier-stage firmware?
> > > 
> > > Not sure, but seems like this is the case. I checked and there isn't any
> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > add the dtb and other dts dtsi
> > > files
> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > it would just give a blank screen*. I wonder why there isn't any device
> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > RPI4?
> > 
> > The issue with the rpi4 is that the addresses of devices move around
> > based on the version of the Raspberry Pi firmware you're using.  And
> > possibly on the amount of memory on the board as well.  So U-Boot
> > pretty much has to use the device tree passed by the firmware since
> > the device tree in the U-Boot tree would be wrong for many
> > combinations of firmware and hardware.
> > 
> > Simon, this sort of thing is exactly the reason why I think the idea
> > of having all U-Boot configuration information in a single device tree
> > with the hardware description doesn't work everywhere.
> 
> In this case, doesn't the Pi firmware pass along apply overlays and
> construct the device tree it's going to pass along, so in this case you
> would want to make an "overlay" for the Pi firmware to apply and pass
> along to U-Boot, that includes the required information?

yes, that might work.  The overlay can be specified in the config.txt file.

I think truly verified boot is impossible on the Pi though, as u-boot
and the overlay file will need to be stored on the uSD card of the Pi.
But that applies to the scenario where the public key is stored in the
device tree embedded in u-boot itself as well.


[PATCH] cmd: mmc: Support mmc hwpartition user enh start -

2021-09-11 Thread Marek Vasut
Add option to extend the hardware partition to the maximum size by
using the '-' dash sign instead of $cnt parameter. This is useful
in case we want to switch the entire eMMC user area into pSLC mode,
especially in case the device may be populated with different size
eMMCs. With this change, we do not have to calculate the number of
blocks of the user area manually.

To switch the pSLC mode for user area, use e.g. the following.
WARNING: This is a one-time irreversible change.
=> mmc hwpartition user enh 0 - wrrel on complete

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Jaehoon Chung 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 cmd/mmc.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index c67ad762422..b6bb951347d 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -560,7 +560,32 @@ static int do_mmc_list(struct cmd_tbl *cmdtp, int flag,
 }
 
 #if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
-static int parse_hwpart_user(struct mmc_hwpart_conf *pconf,
+static void parse_hwpart_user_enh_size(struct mmc *mmc,
+  struct mmc_hwpart_conf *pconf,
+  char *argv)
+{
+   int ret;
+
+   pconf->user.enh_size = 0;
+
+   if (!strcmp(argv, "-")) { /* The rest of eMMC */
+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+   ret = mmc_send_ext_csd(mmc, ext_csd);
+   if (ret)
+   return;
+   pconf->user.enh_size =
+   ((ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT+2] << 16) +
+   (ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT+1] << 8) +
+   ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT]) * 1024 *
+   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] *
+   ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
+   pconf->user.enh_size -= pconf->user.enh_start;
+   } else {
+   pconf->user.enh_size = dectoul(argv, NULL);
+   }
+}
+
+static int parse_hwpart_user(struct mmc *mmc, struct mmc_hwpart_conf *pconf,
 int argc, char *const argv[])
 {
int i = 0;
@@ -573,8 +598,7 @@ static int parse_hwpart_user(struct mmc_hwpart_conf *pconf,
return -1;
pconf->user.enh_start =
dectoul(argv[i + 1], NULL);
-   pconf->user.enh_size =
-   dectoul(argv[i + 2], NULL);
+   parse_hwpart_user_enh_size(mmc, pconf, argv[i + 2]);
i += 3;
} else if (!strcmp(argv[i], "wrrel")) {
if (i + 1 >= argc)
@@ -646,7 +670,7 @@ static int do_mmc_hwpartition(struct cmd_tbl *cmdtp, int 
flag,
while (i < argc) {
if (!strcmp(argv[i], "user")) {
i++;
-   r = parse_hwpart_user(, argc-i, [i]);
+   r = parse_hwpart_user(mmc, , argc-i, [i]);
if (r < 0)
return CMD_RET_USAGE;
i += r;
-- 
2.33.0



Re: Problem with U-boot | Configuration Signature not being checked while booting

2021-09-11 Thread Tom Rini
On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > From: Moiz Imtiaz 
> > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > 
> > Hi Simon,
> > 
> > Thanks for the reply.  I already followed the steps mentioned in
> > "doc/uImage.FIT/beaglebone_vboot.txt".
> > 
> > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > instead one provided by the earlier-stage firmware?
> > 
> > Not sure, but seems like this is the case. I checked and there isn't any
> > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > add the dtb and other dts dtsi
> > files
> > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > it would just give a blank screen*. I wonder why there isn't any device
> > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > RPI4?
> 
> The issue with the rpi4 is that the addresses of devices move around
> based on the version of the Raspberry Pi firmware you're using.  And
> possibly on the amount of memory on the board as well.  So U-Boot
> pretty much has to use the device tree passed by the firmware since
> the device tree in the U-Boot tree would be wrong for many
> combinations of firmware and hardware.
> 
> Simon, this sort of thing is exactly the reason why I think the idea
> of having all U-Boot configuration information in a single device tree
> with the hardware description doesn't work everywhere.

In this case, doesn't the Pi firmware pass along apply overlays and
construct the device tree it's going to pass along, so in this case you
would want to make an "overlay" for the Pi firmware to apply and pass
along to U-Boot, that includes the required information?

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] clk: sunxi: Extend DM_RESET selection to SPL

2021-09-11 Thread Samuel Holland
The sunxi clock driver exposes a reset controller, so it selects the
reset controller framework. Ensure that dependency is also satisfied
when building the driver for the SPL.

Signed-off-by: Samuel Holland 
---

 drivers/clk/sunxi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index bf084fa7a84..43c321692cf 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -2,6 +2,7 @@ config CLK_SUNXI
bool "Clock support for Allwinner SoCs"
depends on CLK && ARCH_SUNXI
select DM_RESET
+   select SPL_DM_RESET if SPL_CLK
default y
help
  This enables support for common clock driver API on Allwinner
-- 
2.31.1



Re: Problem with U-boot | Configuration Signature not being checked while booting

2021-09-11 Thread Mark Kettenis
> From: Moiz Imtiaz 
> Date: Sat, 11 Sep 2021 23:19:05 +0500
> 
> Hi Simon,
> 
> Thanks for the reply.  I already followed the steps mentioned in
> "doc/uImage.FIT/beaglebone_vboot.txt".
> 
> >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> instead one provided by the earlier-stage firmware?
> 
> Not sure, but seems like this is the case. I checked and there isn't any
> dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> add the dtb and other dts dtsi
> files
> from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> it would just give a blank screen*. I wonder why there isn't any device
> tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> RPI4?

The issue with the rpi4 is that the addresses of devices move around
based on the version of the Raspberry Pi firmware you're using.  And
possibly on the amount of memory on the board as well.  So U-Boot
pretty much has to use the device tree passed by the firmware since
the device tree in the U-Boot tree would be wrong for many
combinations of firmware and hardware.

Simon, this sort of thing is exactly the reason why I think the idea
of having all U-Boot configuration information in a single device tree
with the hardware description doesn't work everywhere.


[PATCH] wdt: dw: Fix passing NULL pointer to reset functions

2021-09-11 Thread Sean Anderson
reset_*_bulk expects a real pointer.

Fixes: 4f7abafe1c ("driver: watchdog: reset watchdog in designware_wdt_stop() 
function")
Signed-off-by: Sean Anderson 
---

 drivers/watchdog/designware_wdt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
index afed81e6c6..cfec29bd15 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -22,7 +22,7 @@
 struct designware_wdt_priv {
void __iomem*base;
unsigned intclk_khz;
-   struct reset_ctl_bulk *resets;
+   struct reset_ctl_bulk resets;
 };
 
 /*
@@ -99,11 +99,11 @@ static int designware_wdt_stop(struct udevice *dev)
 if (CONFIG_IS_ENABLED(DM_RESET)) {
int ret;
 
-   ret = reset_assert_bulk(priv->resets);
+   ret = reset_assert_bulk(>resets);
if (ret)
return ret;
 
-   ret = reset_deassert_bulk(priv->resets);
+   ret = reset_deassert_bulk(>resets);
if (ret)
return ret;
}
@@ -156,11 +156,11 @@ static int designware_wdt_probe(struct udevice *dev)
 #endif
 
if (CONFIG_IS_ENABLED(DM_RESET)) {
-   ret = reset_get_bulk(dev, priv->resets);
+   ret = reset_get_bulk(dev, >resets);
if (ret)
goto err;
 
-   ret = reset_deassert_bulk(priv->resets);
+   ret = reset_deassert_bulk(>resets);
if (ret)
goto err;
}
-- 
2.33.0



Re: Watchdog auto-start and TIMER_EARLY broken in RISC-V U-Boot

2021-09-11 Thread Sean Anderson

On 9/11/21 2:37 PM, Samuel Holland wrote:

On 9/11/21 1:31 PM, Sean Anderson wrote:

+CC Heinrich

Did you ever try booting with WDT on k210?

On 9/11/21 12:43 PM, Samuel Holland wrote:

Hello,

I am porting U-Boot to the Allwinner D1 SoC, and I ran into an issue
where the board fails to boot if I enable watchdog auto-start.

The call to get_timer() -> get_ticks() panics because no timer is
available. And since panic_finish() calls udelay(), this causes infinite
recursion of trying and failing to get the timer.

The issue is that the RISC-V architectural timer driver is bound in
arch_early_init_r, which is only called _after_ the first instance of
INIT_FUNC_WATCHDOG_RESET in the initcall list.

Below is a boot log where I commented out the calls to get_timer() and
time_after_eq() in watchdog_reset() in order to illustrate the problem.

I modified the log to add the initcall symbol names for clarity.


U-Boot 2021.10-rc2-00278-ge2be1a426d6-dirty (Jan 01 1970 - 00:00:00
+)

DRAM:  512 MiB
initcall: 5ff63916
initcall: 5ff6391a
initcall: 4a012a4e (initr_reloc_global_data)
initcall: 4a012a88 (initr_barrier)
initcall: 4a012a1c (initr_malloc)
Pre-reloc malloc() used 0x720 bytes (1 KB)
initcall: 4a01290e (log_init)
initcall: 4a012a94 (initr_bootstage)
initcall: 4a012a8c (initr_of_live)
initcall: 4a012a06 (initr_dm)
Binding device root_driver to driver root_driver
Probing device root_driver with driver root_driver
Binding device osc24M_clk to driver fixed_clock
Binding device soc to driver simple_bus
Binding device pinctrl@200 to driver sunxi-pinctrl
Binding device pinctrl@200 to driver gpio_sunxi
Binding device PA to driver gpio_sunxi
Binding device PB to driver gpio_sunxi
Binding device PC to driver gpio_sunxi
Binding device PD to driver gpio_sunxi
Binding device PE to driver gpio_sunxi
Binding device PF to driver gpio_sunxi
Binding device PG to driver gpio_sunxi
Binding device i2c0-pb10-pins to driver pinconfig
Binding device i2c2-pb0-pins to driver pinconfig
Binding device mmc0-pins to driver pinconfig
Binding device mmc1-pins to driver pinconfig
Binding device rgmii-pe-pins to driver pinconfig
Binding device spi0-pins to driver pinconfig
Binding device spi1-pd-pins to driver pinconfig
Binding device uart0-pb8-pins to driver pinconfig
Binding device uart1-pg6-pins to driver pinconfig
Binding device uart1-pg8-rts-cts-pins to driver pinconfig
Binding device i2s2-pb-pins to driver pinconfig
Binding device i2s2-pb3-din-pin to driver pinconfig
Binding device i2s2-pb4-dout-pin to driver pinconfig
Binding device ledc-pc0-pin to driver pinconfig
Binding device pwm0-pd16-pin to driver pinconfig
Binding device pwm2-pd18-pin to driver pinconfig
Binding device pwm7-pd22-pin to driver pinconfig
Binding device spdif-pd22-pin to driver pinconfig
Binding device clock-controller@2001000 to driver sun50i_d1_ccu
Binding device reset to driver sunxi_reset
Binding device serial@250 to driver ns16550_serial
Binding device serial@2500400 to driver ns16550_serial
Binding device i2c@2502000 to driver i2c_mvtwsi
Binding device i2c@2502800 to driver i2c_mvtwsi
Binding device mmc@402 to driver sunxi_mmc
Binding device m...@402.blk to driver mmc_blk
Binding device mmc@4021000 to driver sunxi_mmc
Binding device m...@4021000.blk to driver mmc_blk
Binding device usb@410 to driver sunxi-musb
Binding device phy@4100400 to driver sun4i_usb_phy
Binding device usb@4101000 to driver ehci_generic
Binding device usb@4101400 to driver ohci_generic
Binding device usb@420 to driver ehci_generic
Binding device usb@4200400 to driver ohci_generic
Binding device ethernet@450 to driver eth_sun8i_emac
Binding device watchdog@6011000 to driver sunxi_wdt
initcall: 4a001914 (board_init)
initcall: 4a04d814 (efi_memory_init)
initcall: 4a012a9c (initr_binman)
initcall: 4a012a90 (initr_dm_devices)


Here's where dm_timer_init() would be called if CONFIG_TIMER_EARLY was
enabled, but that still doesn't help because the timer is not bound yet.
In fact, CONFIG_TIMER_EARLY actually makes the situation worse, because
the board hangs if dm_timer_init() fails:

initcall sequence 5ffdac78 failed at call 4a012a06
(err=-19)
### ERROR ### Please RESET the board ###


I'm not sure what's going on here. Why does dm_timer_init get called
from initr_dm?


dm_timer_init gets called from initr_dm_devices (not initr_dm) if


Ah, 4a012a06 earlier referred to initr_dm.


CONFIG_TIMER_EARLY is enabled.


Hmm. It looks like this came up before and was addressed by 84b2416b6a
("board_r: move initr_watchdog to be called after initr_serial"). That
commit suggests just moving watchdog init later.

Perhaps it would be better to introduce a generic "bind_timer"
initcall?

We could also do something like

diff --git i/lib/time.c w/lib/time.c
index 38a9758292..3fccffc010 100644
--- i/lib/time.c
+++ w/lib/time.c
@@ -86,15 +86,15 @@ 

Re: Watchdog auto-start and TIMER_EARLY broken in RISC-V U-Boot

2021-09-11 Thread Samuel Holland
On 9/11/21 1:31 PM, Sean Anderson wrote:
> +CC Heinrich
> 
> Did you ever try booting with WDT on k210?
> 
> On 9/11/21 12:43 PM, Samuel Holland wrote:
>> Hello,
>>
>> I am porting U-Boot to the Allwinner D1 SoC, and I ran into an issue
>> where the board fails to boot if I enable watchdog auto-start.
>>
>> The call to get_timer() -> get_ticks() panics because no timer is
>> available. And since panic_finish() calls udelay(), this causes infinite
>> recursion of trying and failing to get the timer.
>>
>> The issue is that the RISC-V architectural timer driver is bound in
>> arch_early_init_r, which is only called _after_ the first instance of
>> INIT_FUNC_WATCHDOG_RESET in the initcall list.
>>
>> Below is a boot log where I commented out the calls to get_timer() and
>> time_after_eq() in watchdog_reset() in order to illustrate the problem.
>>
>> I modified the log to add the initcall symbol names for clarity.
>>
>>> U-Boot 2021.10-rc2-00278-ge2be1a426d6-dirty (Jan 01 1970 - 00:00:00
>>> +)
>>>
>>> DRAM:  512 MiB
>>> initcall: 5ff63916
>>> initcall: 5ff6391a
>>> initcall: 4a012a4e (initr_reloc_global_data)
>>> initcall: 4a012a88 (initr_barrier)
>>> initcall: 4a012a1c (initr_malloc)
>>> Pre-reloc malloc() used 0x720 bytes (1 KB)
>>> initcall: 4a01290e (log_init)
>>> initcall: 4a012a94 (initr_bootstage)
>>> initcall: 4a012a8c (initr_of_live)
>>> initcall: 4a012a06 (initr_dm)
>>> Binding device root_driver to driver root_driver
>>> Probing device root_driver with driver root_driver
>>> Binding device osc24M_clk to driver fixed_clock
>>> Binding device soc to driver simple_bus
>>> Binding device pinctrl@200 to driver sunxi-pinctrl
>>> Binding device pinctrl@200 to driver gpio_sunxi
>>> Binding device PA to driver gpio_sunxi
>>> Binding device PB to driver gpio_sunxi
>>> Binding device PC to driver gpio_sunxi
>>> Binding device PD to driver gpio_sunxi
>>> Binding device PE to driver gpio_sunxi
>>> Binding device PF to driver gpio_sunxi
>>> Binding device PG to driver gpio_sunxi
>>> Binding device i2c0-pb10-pins to driver pinconfig
>>> Binding device i2c2-pb0-pins to driver pinconfig
>>> Binding device mmc0-pins to driver pinconfig
>>> Binding device mmc1-pins to driver pinconfig
>>> Binding device rgmii-pe-pins to driver pinconfig
>>> Binding device spi0-pins to driver pinconfig
>>> Binding device spi1-pd-pins to driver pinconfig
>>> Binding device uart0-pb8-pins to driver pinconfig
>>> Binding device uart1-pg6-pins to driver pinconfig
>>> Binding device uart1-pg8-rts-cts-pins to driver pinconfig
>>> Binding device i2s2-pb-pins to driver pinconfig
>>> Binding device i2s2-pb3-din-pin to driver pinconfig
>>> Binding device i2s2-pb4-dout-pin to driver pinconfig
>>> Binding device ledc-pc0-pin to driver pinconfig
>>> Binding device pwm0-pd16-pin to driver pinconfig
>>> Binding device pwm2-pd18-pin to driver pinconfig
>>> Binding device pwm7-pd22-pin to driver pinconfig
>>> Binding device spdif-pd22-pin to driver pinconfig
>>> Binding device clock-controller@2001000 to driver sun50i_d1_ccu
>>> Binding device reset to driver sunxi_reset
>>> Binding device serial@250 to driver ns16550_serial
>>> Binding device serial@2500400 to driver ns16550_serial
>>> Binding device i2c@2502000 to driver i2c_mvtwsi
>>> Binding device i2c@2502800 to driver i2c_mvtwsi
>>> Binding device mmc@402 to driver sunxi_mmc
>>> Binding device m...@402.blk to driver mmc_blk
>>> Binding device mmc@4021000 to driver sunxi_mmc
>>> Binding device m...@4021000.blk to driver mmc_blk
>>> Binding device usb@410 to driver sunxi-musb
>>> Binding device phy@4100400 to driver sun4i_usb_phy
>>> Binding device usb@4101000 to driver ehci_generic
>>> Binding device usb@4101400 to driver ohci_generic
>>> Binding device usb@420 to driver ehci_generic
>>> Binding device usb@4200400 to driver ohci_generic
>>> Binding device ethernet@450 to driver eth_sun8i_emac
>>> Binding device watchdog@6011000 to driver sunxi_wdt
>>> initcall: 4a001914 (board_init)
>>> initcall: 4a04d814 (efi_memory_init)
>>> initcall: 4a012a9c (initr_binman)
>>> initcall: 4a012a90 (initr_dm_devices)
>>
>> Here's where dm_timer_init() would be called if CONFIG_TIMER_EARLY was
>> enabled, but that still doesn't help because the timer is not bound yet.
>> In fact, CONFIG_TIMER_EARLY actually makes the situation worse, because
>> the board hangs if dm_timer_init() fails:
>>
>> initcall sequence 5ffdac78 failed at call 4a012a06
>> (err=-19)
>> ### ERROR ### Please RESET the board ###
> 
> I'm not sure what's going on here. Why does dm_timer_init get called
> from initr_dm?

dm_timer_init gets called from initr_dm_devices (not initr_dm) if
CONFIG_TIMER_EARLY is enabled.

> Why does it fail?

It fails because at this point there are no devices bound for the timer
uclass, so uclass_first_device_err returns -ENODEV.

Regards,
Samuel

> --Sean
> 
>>> 

Re: Watchdog auto-start and TIMER_EARLY broken in RISC-V U-Boot

2021-09-11 Thread Sean Anderson

+CC Heinrich

Did you ever try booting with WDT on k210?

On 9/11/21 12:43 PM, Samuel Holland wrote:

Hello,

I am porting U-Boot to the Allwinner D1 SoC, and I ran into an issue
where the board fails to boot if I enable watchdog auto-start.

The call to get_timer() -> get_ticks() panics because no timer is
available. And since panic_finish() calls udelay(), this causes infinite
recursion of trying and failing to get the timer.

The issue is that the RISC-V architectural timer driver is bound in
arch_early_init_r, which is only called _after_ the first instance of
INIT_FUNC_WATCHDOG_RESET in the initcall list.

Below is a boot log where I commented out the calls to get_timer() and
time_after_eq() in watchdog_reset() in order to illustrate the problem.

I modified the log to add the initcall symbol names for clarity.


U-Boot 2021.10-rc2-00278-ge2be1a426d6-dirty (Jan 01 1970 - 00:00:00 +)

DRAM:  512 MiB
initcall: 5ff63916
initcall: 5ff6391a
initcall: 4a012a4e (initr_reloc_global_data)
initcall: 4a012a88 (initr_barrier)
initcall: 4a012a1c (initr_malloc)
Pre-reloc malloc() used 0x720 bytes (1 KB)
initcall: 4a01290e (log_init)
initcall: 4a012a94 (initr_bootstage)
initcall: 4a012a8c (initr_of_live)
initcall: 4a012a06 (initr_dm)
Binding device root_driver to driver root_driver
Probing device root_driver with driver root_driver
Binding device osc24M_clk to driver fixed_clock
Binding device soc to driver simple_bus
Binding device pinctrl@200 to driver sunxi-pinctrl
Binding device pinctrl@200 to driver gpio_sunxi
Binding device PA to driver gpio_sunxi
Binding device PB to driver gpio_sunxi
Binding device PC to driver gpio_sunxi
Binding device PD to driver gpio_sunxi
Binding device PE to driver gpio_sunxi
Binding device PF to driver gpio_sunxi
Binding device PG to driver gpio_sunxi
Binding device i2c0-pb10-pins to driver pinconfig
Binding device i2c2-pb0-pins to driver pinconfig
Binding device mmc0-pins to driver pinconfig
Binding device mmc1-pins to driver pinconfig
Binding device rgmii-pe-pins to driver pinconfig
Binding device spi0-pins to driver pinconfig
Binding device spi1-pd-pins to driver pinconfig
Binding device uart0-pb8-pins to driver pinconfig
Binding device uart1-pg6-pins to driver pinconfig
Binding device uart1-pg8-rts-cts-pins to driver pinconfig
Binding device i2s2-pb-pins to driver pinconfig
Binding device i2s2-pb3-din-pin to driver pinconfig
Binding device i2s2-pb4-dout-pin to driver pinconfig
Binding device ledc-pc0-pin to driver pinconfig
Binding device pwm0-pd16-pin to driver pinconfig
Binding device pwm2-pd18-pin to driver pinconfig
Binding device pwm7-pd22-pin to driver pinconfig
Binding device spdif-pd22-pin to driver pinconfig
Binding device clock-controller@2001000 to driver sun50i_d1_ccu
Binding device reset to driver sunxi_reset
Binding device serial@250 to driver ns16550_serial
Binding device serial@2500400 to driver ns16550_serial
Binding device i2c@2502000 to driver i2c_mvtwsi
Binding device i2c@2502800 to driver i2c_mvtwsi
Binding device mmc@402 to driver sunxi_mmc
Binding device m...@402.blk to driver mmc_blk
Binding device mmc@4021000 to driver sunxi_mmc
Binding device m...@4021000.blk to driver mmc_blk
Binding device usb@410 to driver sunxi-musb
Binding device phy@4100400 to driver sun4i_usb_phy
Binding device usb@4101000 to driver ehci_generic
Binding device usb@4101400 to driver ohci_generic
Binding device usb@420 to driver ehci_generic
Binding device usb@4200400 to driver ohci_generic
Binding device ethernet@450 to driver eth_sun8i_emac
Binding device watchdog@6011000 to driver sunxi_wdt
initcall: 4a001914 (board_init)
initcall: 4a04d814 (efi_memory_init)
initcall: 4a012a9c (initr_binman)
initcall: 4a012a90 (initr_dm_devices)


Here's where dm_timer_init() would be called if CONFIG_TIMER_EARLY was
enabled, but that still doesn't help because the timer is not bound yet.
In fact, CONFIG_TIMER_EARLY actually makes the situation worse, because
the board hangs if dm_timer_init() fails:

initcall sequence 5ffdac78 failed at call 4a012a06 (err=-19)
### ERROR ### Please RESET the board ###


I'm not sure what's going on here. Why does dm_timer_init get called from 
initr_dm?
Why does it fail?

--Sean


initcall: 4a01c4f4 (stdio_init_tables)
initcall: 4a039ff8 (serial_initialize)
Probing device pinctrl@200 with driver sunxi-pinctrl
Probing device soc with driver simple_bus
Probing device clock-controller@2001000 with driver sun50i_d1_ccu
Probing device osc24M_clk with driver fixed_clock
Probing device uart0-pb8-pins with driver pinconfig
Probing device serial@250 with driver ns16550_serial
Probing device reset with driver sunxi_reset
initcall: 4a0129ea (initr_announce)
Now running in RAM - U-Boot at: 5ff51000
initcall: 4a0367ce (initr_watchdog)
Probing device watchdog@6011000 with driver 

[PATCH v3 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2

2021-09-11 Thread Andy Shevchenko
On Intel Tangier the SDHCI #2 provides SD card connection.
Add GPIO card detection for it.

Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
Signed-off-by: Andy Shevchenko 
Acked-by: Bin Meng 
---
v3: basically returned to the content of v2 (pull bias back to none)
since there is nothing special about the signal which is supposed
to be triggered by both edges

 .../asm/arch-tangier/acpi/southcluster.asl| 32 +++
 1 file changed, 32 insertions(+)

diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index 01077293bb91..41facdde6a3d 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -97,6 +97,38 @@ Device (PCI0)
 }
 }
 
+Device (SDHB)
+{
+Name (_ADR, 0x00010002)
+Name (_DEP, Package ()
+{
+GPIO
+})
+
+Name (RBUF, ResourceTemplate()
+{
+GpioInt(Edge, ActiveBoth, SharedAndWake, PullNone, 1,
+"\\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 77 }
+})
+
+Method (_CRS, 0, Serialized)
+{
+Return (RBUF)
+}
+
+Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package () { "cd-gpios", Package () { ^SDHB, 0, 0, 0 } },
+}
+})
+
+Method (_STA)
+{
+Return (STA_VISIBLE)
+}
+}
+
 Device (SDHC)
 {
 Name (_ADR, 0x00010003)
-- 
2.33.0



Re: Problem with U-boot | Configuration Signature not being checked while booting

2021-09-11 Thread Moiz Imtiaz
Hi Simon,

Thanks for the reply.  I already followed the steps mentioned in
"doc/uImage.FIT/beaglebone_vboot.txt".

>I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?

Not sure, but seems like this is the case. I checked and there isn't any
dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
add the dtb and other dts dtsi
files
from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
it would just give a blank screen*. I wonder why there isn't any device
tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
RPI4?

and if I tried CONFIG_OF_BOARD (the default rpi_4 configuration), it will
take us back to the initial problem, signature not being checked.

> Can you check that the required 'signature' node is present? You can use
the 'fdt' command in U-Boot to look at it.
I tried the "fdt checksign" but it didn't return anything. Screenshot
inlined, image.itb is the fit image. If I am not doing it wrong, or some
other commands needs to be executed, please let me know.

[image: image.png]

Just for reference, I am inlining the steps I followed:
1. clone the master branch of u-boot.
2. Add FIT, RSA & SIGNATURE support to rpi_4_defconfig
3. Build with 64-bit architecture. (CROSS_COMPILE=aarch64-linux-gnu-)
4. Build U-boot  ($make -j8)
5. copy device tree and make a clone by appending pubkey to it.
$ cp bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b-pubkey.dtb
6. generate the keys and make .its file and sign it with the following
command:
mkdir keys
openssl genrsa -F4 -out keys/dev.key 2048
 openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
mkimage -f image.its -K bcm2711-rpi-4-b-pubkey.dtb -k keys -r image.itb
7. rebuild uboot with control FDT (bcm2711-rpi-4-b-pubkey.dtb)
$make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8
8. Copy u-boot.bin and image.itb to boot partition.

But since I had CONFIG_OF_BOARD set, I am assuming it didn't add control
FDT into u-boot.bin as byte size for both binaries (u-boot.bin &
u-boot-nodtb.bin) was the same. I tried to concatenate them with cat but
while booting, U-Boot still didn't read the Control FDT.

Can anyone please help with enabling verified boot (signature check)
support for Raspberry Pi4. It's a very mainstream board and support for it
would be great to have. I am willing to contribute, whatever I can.

Best,
Moiz Imtiaz

On Fri, Sep 10, 2021 at 9:37 AM Simon Glass  wrote:

> +Tom Rini
>
> Hi Moiz,
>
> On Thu, 9 Sept 2021 at 14:21, Moiz Imtiaz  wrote:
> >
> > Hope you are doing well and everything is going good at your end. I am
> using Raspi 4B and Compute Model 4 and trying to configure U-boot with
> Verified boot support, but while booting the signing of the configuration
> is not being checked. I am using the latest master branch from GitHub.
> >
> > We have checked the signature verification via the "fit_check_sign"
> utility that comes with u-boot and it does verify the configuration of the
> signature so, I am sure that the image is signed properly and the Control
> FDT is good as well.
> >
> >
> >
> > but while booting, it doesn't check the signature of the configuration.
> It should be showing "Verifying Hash Integrity ... sha1,rsa2048:dev+ OK"
> >
> >
> > I believe that maybe I am not adding Control FDT in the U-boot binary
> properly. Following is the command that I am using to add control FDT to
> U-boot.
> >
> > $ make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8
> > I have also tried
> > $ make DEV_TREE_BIN=bcm2711-rpi-4-b-pubkey.dtb -j8
> >
> > The bytes size of the u-boot.bin and u-boot-nodtb.bin after using both
> the above commands is the same.
> >
> > Attached is the FIT source file,  rpi_4_defconfig and the control FDT
> file. Also, the following has been added in configs/rpi_4_defconfig.
> >
> > CONFIG_OF_CONTROL=y
> > CONFIG_FIT=y
> > CONFIG_FIT_SIGNATURE=y
> > CONFIG_RSA=y
> >
> > Can you please help me with how to add Control FDT to the U-boot.bin
> binary or what can be the reason that it isn't checking the signature of
> the configuration while booting? Any kind of help would be really
> appreciated.
>
> There is an example of this flow in the sandbox vboot test. There is
> also an example for Beaglebone Black in
> doc/uImage.FIT/beaglebone_vboot.txt
>
> I wonder if rpi is not using the devicetree compiled with U-Boot, but
> instead one provided by the earlier-stage firmware? Can you check that
> the required 'signature' node is present? You can use the 'fdt'
> command in U-Boot to look at it.
>
> Looking at rpi_4 it uses CONFIG_OF_BOARD which means it has its own
> special way of getting the devicetree into U-Boot. The older boards
> use CONFIG_OF_EMBED which is actually not even allowed in production
> boards
>
> Also you may need the -r argument to mkimage to 

Re: [PATCH] Dockerfile: Update to latest "focal" tag

2021-09-11 Thread Tom Rini
On Sat, Sep 11, 2021 at 10:37:06AM -0400, Tom Rini wrote:

> Signed-off-by: Tom Rini 
> Reviewed-by: Bin Meng 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] CI: Update to latest container images

2021-09-11 Thread Tom Rini
On Sat, Sep 11, 2021 at 12:07:08PM -0400, Tom Rini wrote:

> - Current Ubuntu/Focal tag
> - QEMU 6.1.0
> - genimage tool added
> 
> Signed-off-by: Tom Rini 
> Reviewed-by: Bin Meng 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 4/4] azure/gitlab: Add tests for SiFive Unleashed board

2021-09-11 Thread Tom Rini
On Thu, Aug 26, 2021 at 11:33:35PM +0800, Bin Meng wrote:

> This adds CI tests for SiFive Unleashed board.
> 
> QEMU supports booting exact the same images as used on the real
> hardware out of the box, that U-Boot SPL loads U-Boot proper
> from either an SD card or the SPI NOR flash, hence we can easily
> set up CI to cover these 2 boot flows of SiFive Unleashed board.
> 
> With this, now we can have regression testing of mmc-spi-slot and
> sifive spi drivers, as well as mmc and spi-nor subsystems.
> 
> Signed-off-by: Bin Meng 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 3/4] riscv: sifive: unleashed: Add genimage config files

2021-09-11 Thread Tom Rini
On Thu, Aug 26, 2021 at 11:33:34PM +0800, Bin Meng wrote:

> This adds genimage [1] config files for generating SD card and spi-nor
> images, which can be programmed to an SD card or SPI flash and boot
> from there.
> 
> The same images will be used for U-Boot CI testing for this board.
> 
> [1] https://github.com/pengutronix/genimage
> 
> Signed-off-by: Bin Meng 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/4] tools: docker: Build and install genimage

2021-09-11 Thread Tom Rini
On Thu, Aug 26, 2021 at 11:33:33PM +0800, Bin Meng wrote:

> genimage [1] is a tool to create flash/disk images. This is required
> by some targets, e.g.: sifive_unleashed, to generate sdcard or spi-nor
> images for real hardware, as well as U-Boot CI testing.
> 
> [1] https://github.com/pengutronix/genimage
> 
> Signed-off-by: Bin Meng 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/4] tools: docker: Bump up QEMU version to 6.1.0

2021-09-11 Thread Tom Rini
On Thu, Aug 26, 2021 at 11:33:32PM +0800, Bin Meng wrote:

> At present U-Boot CI testing is still using QEMU 4.2.0 which is
> pretty old. Let's bump up to QEMU 6.1.0.
> 
> ninja-build is added as the prerequisite required by QEMU 6.1.0.
> 
> Note there is a bug in QEMU 6.1.0 Xilinx Zynq UART emulation codes.
> A quick fix [1] was posted on QEMU mailing list but it it too late
> for 6.1.0 release. Let's manually apply the bug fix on top of the
> v6.1.0 release tag at the time being.
> 
> [1] 
> http://patchwork.ozlabs.org/project/qemu-devel/patch/20210823020813.25192-2-bmeng...@gmail.com/
> 
> Signed-off-by: Bin Meng 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] sunxi: call fdt_fixup_ethernet again to set macaddr for more aliases

2021-09-11 Thread Jernej Skrabec
From: Icenowy Zheng 

Sometimes some ethernet aliases do not exist in U-Boot DT but they
exist in the DT used to boot the system (for example, modified via DT
overlays). In this situation setup_environment is called again in
ft_board_setup() to generate macaddr environment variable for them.
However now the call to fdt_fixup_ethernet() is moved before the call
of ft_board_setup().

Call fdt_fixup_ethernet() again to add MAC addresses for the extra
ethernet aliases.

Signed-off-by: Icenowy Zheng 
[updated commit message]
Signed-off-by: Jernej Skrabec 
---

Hi all,

this is effectively resend of:
https://patchwork.ozlabs.org/project/uboot/patch/20171027093439.12414-1-icen...@aosc.io/

On at least one board, namely BananaPi M2 Zero, adding ethernet connector is
pretty popular after market modification. Since this is not something that is
already present on the board, ethernet node will never be part of upstream DT.
Thus, the only sensible solution is to use DT overlay, which adds node to DT
(maintaining patches is tedious). However, when overlays are used, U-Boot
misses injecting MAC address, as described in commit message.

Please reconsider this patch for inclusion in upstream.

Best regards,
Jernej

 board/sunxi/board.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 1a46100e408d..97554d4642ed 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -997,10 +997,12 @@ int ft_board_setup(void *blob, struct bd_info *bd)
int __maybe_unused r;
 
/*
-* Call setup_environment again in case the boot fdt has
-* ethernet aliases the u-boot copy does not have.
+* Call setup_environment and fdt_fixup_ethernet again
+* in case the boot fdt has ethernet aliases the u-boot
+* copy does not have.
 */
setup_environment(blob);
+   fdt_fixup_ethernet(blob);
 
bluetooth_dt_fixup(blob);
 
-- 
2.33.0



[PATCH v2 4/4] clk: k210: Try harder to get the best config

2021-09-11 Thread Sean Anderson
In some cases, the best config cannot be used because the VCO would be
out-of-spec. In these cases, we may need to try a worse combination of r/od
in order to find the best representable config. This also adds a few test
cases to catch this and other (possible) unlikely errors.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/clk_kendryte.c | 24 
 test/dm/k210_pll.c |  4 
 2 files changed, 28 insertions(+)

diff --git a/drivers/clk/clk_kendryte.c b/drivers/clk/clk_kendryte.c
index 69691c4a04..97efda5b6f 100644
--- a/drivers/clk/clk_kendryte.c
+++ b/drivers/clk/clk_kendryte.c
@@ -816,6 +816,30 @@ again:
i--;
}
 
+   /*
+* Try looking back to see if there is a worse ratio
+* that we could try anyway
+*/
+   while (i > 0) {
+   i--;
+   new_r = UNPACK_R(factors[i]);
+   new_od = UNPACK_OD(factors[i]);
+   /*
+* Don't loop over factors for the same product
+* to avoid getting stuck because of the above
+* clause
+*/
+   if (r * od != new_r * new_od) {
+   if (new_r * new_od > last_r * last_od) {
+   r = new_r;
+   od = new_od;
+   swapped = false;
+   goto again;
+   }
+   break;
+   }
+   }
+
/* We ran out of things to try */
continue;
}
diff --git a/test/dm/k210_pll.c b/test/dm/k210_pll.c
index 5574ac96fa..f55379f336 100644
--- a/test/dm/k210_pll.c
+++ b/test/dm/k210_pll.c
@@ -84,6 +84,10 @@ static int dm_test_k210_pll(struct unit_test_state *uts)
compare(4, 2600);
compare(2700, 2600);
compare(2600, 2700);
+   compare(1330 * 64, 1330);
+   compare(2125, 2125 * 70);
+   compare(2125, 175000);
+   compare(175000, 175000);
 
return 0;
 }
-- 
2.33.0



[PATCH v2 3/4] test: dm: k210: Reduce duplication in test cases

2021-09-11 Thread Sean Anderson
Having to copy-paste the same 3 lines makes adding new test cases
error-prone. Use a macro.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 test/dm/k210_pll.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/test/dm/k210_pll.c b/test/dm/k210_pll.c
index 54764f269c..5574ac96fa 100644
--- a/test/dm/k210_pll.c
+++ b/test/dm/k210_pll.c
@@ -69,27 +69,21 @@ static int dm_test_k210_pll(struct unit_test_state *uts)
  ));
ut_asserteq(-EINVAL, k210_pll_calc_config(15, 2000,
  ));
+   ut_asserteq(-EINVAL, k210_pll_calc_config(175000, 1330,
+ ));
 
/* Verify we get the same output with brute-force */
-   ut_assertok(dm_test_k210_pll_calc_config(39000, 2600, ));
-   ut_assertok(k210_pll_calc_config(39000, 2600, ));
-   ut_assertok(dm_test_k210_pll_compare(, ));
+#define compare(rate, rate_in) do { \
+   ut_assertok(dm_test_k210_pll_calc_config(rate, rate_in, )); \
+   ut_assertok(k210_pll_calc_config(rate, rate_in, )); \
+   ut_assertok(dm_test_k210_pll_compare(, )); \
+} while (0)
 
-   ut_assertok(dm_test_k210_pll_calc_config(2600, 39000, ));
-   ut_assertok(k210_pll_calc_config(2600, 39000, ));
-   ut_assertok(dm_test_k210_pll_compare(, ));
-
-   ut_assertok(dm_test_k210_pll_calc_config(4, 2600, ));
-   ut_assertok(k210_pll_calc_config(4, 2600, ));
-   ut_assertok(dm_test_k210_pll_compare(, ));
-
-   ut_assertok(dm_test_k210_pll_calc_config(2700, 2600, ));
-   ut_assertok(k210_pll_calc_config(2700, 2600, ));
-   ut_assertok(dm_test_k210_pll_compare(, ));
-
-   ut_assertok(dm_test_k210_pll_calc_config(2600, 2700, ));
-   ut_assertok(k210_pll_calc_config(2600, 2700, ));
-   ut_assertok(dm_test_k210_pll_compare(, ));
+   compare(39000, 2600);
+   compare(2600, 39000);
+   compare(4, 2600);
+   compare(2700, 2600);
+   compare(2600, 2700);
 
return 0;
 }
-- 
2.33.0



[PATCH v2 2/4] k210: clk: Refactor out_of_spec tests

2021-09-11 Thread Sean Anderson
Everything here sits in a while (true) loop. However, this introduces a
couple of layers of indentation. We can simplify the code by introducing a
single goto instead of using continue/break. This will also make adding
loops in the next patch easier.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/clk_kendryte.c | 105 ++---
 1 file changed, 52 insertions(+), 53 deletions(-)

diff --git a/drivers/clk/clk_kendryte.c b/drivers/clk/clk_kendryte.c
index 2caa21aec9..69691c4a04 100644
--- a/drivers/clk/clk_kendryte.c
+++ b/drivers/clk/clk_kendryte.c
@@ -709,6 +709,10 @@ TEST_STATIC int k210_pll_calc_config(u32 rate, u32 rate_in,
 * Whether we swapped r and od while enforcing frequency limits
 */
bool swapped = false;
+   /*
+* Whether the intermediate frequencies are out-of-spec
+*/
+   bool out_of_spec;
u64 last_od = od;
u64 last_r = r;
 
@@ -767,76 +771,71 @@ TEST_STATIC int k210_pll_calc_config(u32 rate, u32 
rate_in,
 * aren't in spec, try swapping r and od. If everything is
 * in-spec, calculate the relative error.
 */
-   while (true) {
+again:
+   out_of_spec = false;
+   if (r > max_r) {
+   out_of_spec = true;
+   } else {
/*
-* Whether the intermediate frequencies are out-of-spec
+* There is no way to only divide once; we need
+* to examine the frequency with and without the
+* effect of od.
 */
-   bool out_of_spec = false;
+   u64 vco = DIV_ROUND_CLOSEST_ULL(rate_in * f, r);
 
-   if (r > max_r) {
+   if (vco > 175000 || vco < 34000)
out_of_spec = true;
-   } else {
-   /*
-* There is no way to only divide once; we need
-* to examine the frequency with and without the
-* effect of od.
-*/
-   u64 vco = DIV_ROUND_CLOSEST_ULL(rate_in * f, r);
+   }
 
-   if (vco > 175000 || vco < 34000)
-   out_of_spec = true;
+   if (out_of_spec) {
+   u64 new_r, new_od;
+
+   if (!swapped) {
+   u64 tmp = r;
+
+   r = od;
+   od = tmp;
+   swapped = true;
+   goto again;
}
 
-   if (out_of_spec) {
-   if (!swapped) {
-   u64 tmp = r;
-
-   r = od;
-   od = tmp;
-   swapped = true;
-   continue;
-   } else {
-   /*
-* Try looking ahead to see if there are
-* additional factors for the same
-* product.
-*/
-   if (i + 1 < ARRAY_SIZE(factors)) {
-   u64 new_r, new_od;
-
-   i++;
-   new_r = UNPACK_R(factors[i]);
-   new_od = UNPACK_OD(factors[i]);
-   if (r * od == new_r * new_od) {
-   r = new_r;
-   od = new_od;
-   swapped = false;
-   continue;
-   }
-   i--;
-   }
-   break;
+   /*
+* Try looking ahead to see if there are additional
+* factors for the same product.
+*/
+   if (i + 1 < ARRAY_SIZE(factors)) {
+   i++;
+   new_r = UNPACK_R(factors[i]);
+   new_od = UNPACK_OD(factors[i]);
+

[PATCH v2 1/4] clk: k210: Fix checking if ulongs are less than 0

2021-09-11 Thread Sean Anderson
The PLL functions take ulong arguments for rate, but still check if that
rate is negative (which is never true). The correct way to handle this is
to use IS_ERR_VALUE (like is already done in k210_clk_set_rate). While
we're at it, we can move the error checking up into the caller of the pll
set/get rate functions.  This also protects our other calculations from
using bogus values for rate.

Fixes: 609bd60b94 ("clk: k210: Rewrite to remove CCF")
Reported-by: Coverity Scan 
Signed-off-by: Sean Anderson 
---

Changes in v2:
- Reworked patch to use IS_ERR_VALUE instead of changing arguments to long

 drivers/clk/clk_kendryte.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk_kendryte.c b/drivers/clk/clk_kendryte.c
index 3148756968..2caa21aec9 100644
--- a/drivers/clk/clk_kendryte.c
+++ b/drivers/clk/clk_kendryte.c
@@ -849,9 +849,6 @@ static ulong k210_pll_set_rate(struct k210_clk_priv *priv, 
int id, ulong rate,
u32 reg;
ulong calc_rate;
 
-   if (rate_in < 0)
-   return rate_in;
-
err = k210_pll_calc_config(rate, rate_in, );
if (err)
return err;
@@ -895,7 +892,7 @@ static ulong k210_pll_get_rate(struct k210_clk_priv *priv, 
int id,
u64 r, f, od;
u32 reg = readl(priv->base + k210_plls[id].off);
 
-   if (rate_in < 0 || (reg & K210_PLL_BYPASS))
+   if (reg & K210_PLL_BYPASS)
return rate_in;
 
if (!(reg & K210_PLL_PWRD))
@@ -1029,6 +1026,8 @@ static ulong do_k210_clk_get_rate(struct k210_clk_priv 
*priv, int id)
 
parent = k210_clk_get_parent(priv, id);
parent_rate = do_k210_clk_get_rate(priv, parent);
+   if (IS_ERR_VALUE(parent_rate))
+   return parent_rate;
 
if (k210_clks[id].flags & K210_CLKF_PLL)
return k210_pll_get_rate(priv, k210_clks[id].pll, parent_rate);
@@ -1099,6 +1098,8 @@ static ulong k210_clk_set_rate(struct clk *clk, unsigned 
long rate)
 
parent = k210_clk_get_parent(priv, clk->id);
rate_in = do_k210_clk_get_rate(priv, parent);
+   if (IS_ERR_VALUE(rate_in))
+   return rate_in;
 
log_debug("id=%ld rate=%lu rate_in=%lu\n", clk->id, rate, rate_in);
 
-- 
2.33.0



Watchdog auto-start and TIMER_EARLY broken in RISC-V U-Boot

2021-09-11 Thread Samuel Holland
Hello,

I am porting U-Boot to the Allwinner D1 SoC, and I ran into an issue
where the board fails to boot if I enable watchdog auto-start.

The call to get_timer() -> get_ticks() panics because no timer is
available. And since panic_finish() calls udelay(), this causes infinite
recursion of trying and failing to get the timer.

The issue is that the RISC-V architectural timer driver is bound in
arch_early_init_r, which is only called _after_ the first instance of
INIT_FUNC_WATCHDOG_RESET in the initcall list.

Below is a boot log where I commented out the calls to get_timer() and
time_after_eq() in watchdog_reset() in order to illustrate the problem.

I modified the log to add the initcall symbol names for clarity.

> U-Boot 2021.10-rc2-00278-ge2be1a426d6-dirty (Jan 01 1970 - 00:00:00 +)
> 
> DRAM:  512 MiB
> initcall: 5ff63916
> initcall: 5ff6391a
> initcall: 4a012a4e (initr_reloc_global_data)
> initcall: 4a012a88 (initr_barrier)
> initcall: 4a012a1c (initr_malloc)
> Pre-reloc malloc() used 0x720 bytes (1 KB)
> initcall: 4a01290e (log_init)
> initcall: 4a012a94 (initr_bootstage)
> initcall: 4a012a8c (initr_of_live)
> initcall: 4a012a06 (initr_dm)
> Binding device root_driver to driver root_driver
> Probing device root_driver with driver root_driver
> Binding device osc24M_clk to driver fixed_clock
> Binding device soc to driver simple_bus
> Binding device pinctrl@200 to driver sunxi-pinctrl
> Binding device pinctrl@200 to driver gpio_sunxi
> Binding device PA to driver gpio_sunxi
> Binding device PB to driver gpio_sunxi
> Binding device PC to driver gpio_sunxi
> Binding device PD to driver gpio_sunxi
> Binding device PE to driver gpio_sunxi
> Binding device PF to driver gpio_sunxi
> Binding device PG to driver gpio_sunxi
> Binding device i2c0-pb10-pins to driver pinconfig
> Binding device i2c2-pb0-pins to driver pinconfig
> Binding device mmc0-pins to driver pinconfig
> Binding device mmc1-pins to driver pinconfig
> Binding device rgmii-pe-pins to driver pinconfig
> Binding device spi0-pins to driver pinconfig
> Binding device spi1-pd-pins to driver pinconfig
> Binding device uart0-pb8-pins to driver pinconfig
> Binding device uart1-pg6-pins to driver pinconfig
> Binding device uart1-pg8-rts-cts-pins to driver pinconfig
> Binding device i2s2-pb-pins to driver pinconfig
> Binding device i2s2-pb3-din-pin to driver pinconfig
> Binding device i2s2-pb4-dout-pin to driver pinconfig
> Binding device ledc-pc0-pin to driver pinconfig
> Binding device pwm0-pd16-pin to driver pinconfig
> Binding device pwm2-pd18-pin to driver pinconfig
> Binding device pwm7-pd22-pin to driver pinconfig
> Binding device spdif-pd22-pin to driver pinconfig
> Binding device clock-controller@2001000 to driver sun50i_d1_ccu
> Binding device reset to driver sunxi_reset
> Binding device serial@250 to driver ns16550_serial
> Binding device serial@2500400 to driver ns16550_serial
> Binding device i2c@2502000 to driver i2c_mvtwsi
> Binding device i2c@2502800 to driver i2c_mvtwsi
> Binding device mmc@402 to driver sunxi_mmc
> Binding device m...@402.blk to driver mmc_blk
> Binding device mmc@4021000 to driver sunxi_mmc
> Binding device m...@4021000.blk to driver mmc_blk
> Binding device usb@410 to driver sunxi-musb
> Binding device phy@4100400 to driver sun4i_usb_phy
> Binding device usb@4101000 to driver ehci_generic
> Binding device usb@4101400 to driver ohci_generic
> Binding device usb@420 to driver ehci_generic
> Binding device usb@4200400 to driver ohci_generic
> Binding device ethernet@450 to driver eth_sun8i_emac
> Binding device watchdog@6011000 to driver sunxi_wdt
> initcall: 4a001914 (board_init)
> initcall: 4a04d814 (efi_memory_init)
> initcall: 4a012a9c (initr_binman)
> initcall: 4a012a90 (initr_dm_devices)

Here's where dm_timer_init() would be called if CONFIG_TIMER_EARLY was
enabled, but that still doesn't help because the timer is not bound yet.
In fact, CONFIG_TIMER_EARLY actually makes the situation worse, because
the board hangs if dm_timer_init() fails:

initcall sequence 5ffdac78 failed at call 4a012a06 (err=-19)
### ERROR ### Please RESET the board ###

> initcall: 4a01c4f4 (stdio_init_tables)
> initcall: 4a039ff8 (serial_initialize)
> Probing device pinctrl@200 with driver sunxi-pinctrl
> Probing device soc with driver simple_bus
> Probing device clock-controller@2001000 with driver sun50i_d1_ccu
> Probing device osc24M_clk with driver fixed_clock
> Probing device uart0-pb8-pins with driver pinconfig
> Probing device serial@250 with driver ns16550_serial
> Probing device reset with driver sunxi_reset
> initcall: 4a0129ea (initr_announce)
> Now running in RAM - U-Boot at: 5ff51000
> initcall: 4a0367ce (initr_watchdog)
> Probing device watchdog@6011000 with driver sunxi_wdt
> WDT:   Started with servicing (16s timeout)
> 

Re: [PATCH] CI: Update to latest container images

2021-09-11 Thread Bin Meng
On Sun, Sep 12, 2021 at 12:07 AM Tom Rini  wrote:
>
> - Current Ubuntu/Focal tag
> - QEMU 6.1.0
> - genimage tool added
>
> Signed-off-by: Tom Rini 
> ---
>  .azure-pipelines.yml | 2 +-
>  .gitlab-ci.yml   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


[PATCH] CI: Update to latest container images

2021-09-11 Thread Tom Rini
- Current Ubuntu/Focal tag
- QEMU 6.1.0
- genimage tool added

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml | 2 +-
 .gitlab-ci.yml   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 2e9c1fb4fd98..55a984f5d822 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -2,7 +2,7 @@ variables:
   windows_vm: vs2017-win2016
   ubuntu_vm: ubuntu-18.04
   macos_vm: macOS-10.15
-  ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20210723-04Aug2021
+  ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20210827-11Sep2021
   # Add '-u 0' options for Azure pipelines, otherwise we get "permission
   # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer",
   # since our $(ci_runner_image) user is not root.
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 599de6e506bf..cfe519bb2a3b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,7 +2,7 @@
 
 # Grab our configured image.  The source for this is found at:
 # https://source.denx.de/u-boot/gitlab-ci-runner
-image: trini/u-boot-gitlab-ci-runner:focal-20210723-04Aug2021
+image: trini/u-boot-gitlab-ci-runner:focal-20210827-11Sep2021
 
 # We run some tests in different order, to catch some failures quicker.
 stages:
-- 
2.17.1



Re: [PATCH] Dockerfile: Update to latest "focal" tag

2021-09-11 Thread Bin Meng
On Sat, Sep 11, 2021 at 10:37 PM Tom Rini  wrote:
>
> Signed-off-by: Tom Rini 
> ---
>  tools/docker/Dockerfile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


[PATCH] Dockerfile: Update to latest "focal" tag

2021-09-11 Thread Tom Rini
Signed-off-by: Tom Rini 
---
 tools/docker/Dockerfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index 0195456dfeca..42d4b0c91ac8 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -2,7 +2,7 @@
 # This Dockerfile is used to build an image containing basic stuff to be used
 # to build U-Boot and run our test suites.
 
-FROM ubuntu:focal-20210723
+FROM ubuntu:focal-20210827
 MAINTAINER Tom Rini 
 LABEL Description=" This image is for building U-Boot inside a container"
 
-- 
2.17.1



Re: [PATCH v2 1/4] tools: docker: Bump up QEMU version to 6.1.0

2021-09-11 Thread Tom Rini
On Sat, Sep 11, 2021 at 10:33:07PM +0800, Bin Meng wrote:
> On Fri, Aug 27, 2021 at 10:54 AM Tom Rini  wrote:
> >
> > On Thu, Aug 26, 2021 at 11:33:32PM +0800, Bin Meng wrote:
> >
> > > At present U-Boot CI testing is still using QEMU 4.2.0 which is
> > > pretty old. Let's bump up to QEMU 6.1.0.
> > >
> > > ninja-build is added as the prerequisite required by QEMU 6.1.0.
> > >
> > > Note there is a bug in QEMU 6.1.0 Xilinx Zynq UART emulation codes.
> > > A quick fix [1] was posted on QEMU mailing list but it it too late
> > > for 6.1.0 release. Let's manually apply the bug fix on top of the
> > > v6.1.0 release tag at the time being.
> > >
> > > [1] 
> > > http://patchwork.ozlabs.org/project/qemu-devel/patch/20210823020813.25192-2-bmeng...@gmail.com/
> > >
> > > Signed-off-by: Bin Meng 
> > >
> >
> > Reviewed-by: Tom Rini 
> 
> Ping?

On my TODO list, sorry for the delay.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/4] tools: docker: Bump up QEMU version to 6.1.0

2021-09-11 Thread Bin Meng
On Fri, Aug 27, 2021 at 10:54 AM Tom Rini  wrote:
>
> On Thu, Aug 26, 2021 at 11:33:32PM +0800, Bin Meng wrote:
>
> > At present U-Boot CI testing is still using QEMU 4.2.0 which is
> > pretty old. Let's bump up to QEMU 6.1.0.
> >
> > ninja-build is added as the prerequisite required by QEMU 6.1.0.
> >
> > Note there is a bug in QEMU 6.1.0 Xilinx Zynq UART emulation codes.
> > A quick fix [1] was posted on QEMU mailing list but it it too late
> > for 6.1.0 release. Let's manually apply the bug fix on top of the
> > v6.1.0 release tag at the time being.
> >
> > [1] 
> > http://patchwork.ozlabs.org/project/qemu-devel/patch/20210823020813.25192-2-bmeng...@gmail.com/
> >
> > Signed-off-by: Bin Meng 
> >
>
> Reviewed-by: Tom Rini 
>

Ping?


[PATCH v2] board: sifive: Fix a potential build warning in board_fdt_blob_setup()

2021-09-11 Thread Bin Meng
Commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in u-boot 
proper")
added a board-specific implementation of board_fdt_blob_setup() which
takes a pointer as the return value, but it does not return anything
if CONFIG_OF_SEPARATE is not enabled. This will cause a build warning
seen when testing booting S-mode U-Boot directly from QEMU, per the
instructions in [1]:

  board/sifive/unleashed/unleashed.c: In function ‘board_fdt_blob_setup’:
  board/sifive/unleashed/unleashed.c:125:1: warning: control reaches end of 
non-void function [-Wreturn-type]

Return &_end as the default case.

[1] 
https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot

Signed-off-by: Bin Meng 

---

Changes in v2:
- Correct the commit title

 board/sifive/unleashed/unleashed.c | 4 ++--
 board/sifive/unmatched/unmatched.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/sifive/unleashed/unleashed.c 
b/board/sifive/unleashed/unleashed.c
index 8cd514df30..33baeda986 100644
--- a/board/sifive/unleashed/unleashed.c
+++ b/board/sifive/unleashed/unleashed.c
@@ -119,9 +119,9 @@ void *board_fdt_blob_setup(void)
if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
if (gd->arch.firmware_fdt_addr)
return (ulong *)gd->arch.firmware_fdt_addr;
-   else
-   return (ulong *)&_end;
}
+
+   return (ulong *)&_end;
 }
 
 int board_init(void)
diff --git a/board/sifive/unmatched/unmatched.c 
b/board/sifive/unmatched/unmatched.c
index d90b252bae..8773b660fa 100644
--- a/board/sifive/unmatched/unmatched.c
+++ b/board/sifive/unmatched/unmatched.c
@@ -16,9 +16,9 @@ void *board_fdt_blob_setup(void)
if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
if (gd->arch.firmware_fdt_addr)
return (ulong *)gd->arch.firmware_fdt_addr;
-   else
-   return (ulong *)&_end;
}
+
+   return (ulong *)&_end;
 }
 
 int board_init(void)
-- 
2.25.1



Re: [PATCH] board: sifive: overwrite board_fdt_blob_setup in u-boot proper

2021-09-11 Thread Bin Meng
On Sat, Sep 11, 2021 at 10:27 PM Bin Meng  wrote:
>
> Commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in u-boot 
> proper")
> added a board-specific implementation of board_fdt_blob_setup() which
> takes a pointer as the return value, but it does not return anything
> if CONFIG_OF_SEPARATE is not enabled. This will cause a build warning
> seen when testing booting S-mode U-Boot directly from QEMU, per the
> instructions in [1]:
>
>   board/sifive/unleashed/unleashed.c: In function ‘board_fdt_blob_setup’:
>   board/sifive/unleashed/unleashed.c:125:1: warning: control reaches end of 
> non-void function [-Wreturn-type]
>
> Return &_end as the default case.
>
> [1] 
> https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
>
> Signed-off-by: Bin Meng 
> ---
>
>  board/sifive/unleashed/unleashed.c | 4 ++--
>  board/sifive/unmatched/unmatched.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>

Oops, wrong commit title, please ignore.

Regards,
Bin


[PATCH] board: sifive: overwrite board_fdt_blob_setup in u-boot proper

2021-09-11 Thread Bin Meng
Commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in u-boot 
proper")
added a board-specific implementation of board_fdt_blob_setup() which
takes a pointer as the return value, but it does not return anything
if CONFIG_OF_SEPARATE is not enabled. This will cause a build warning
seen when testing booting S-mode U-Boot directly from QEMU, per the
instructions in [1]:

  board/sifive/unleashed/unleashed.c: In function ‘board_fdt_blob_setup’:
  board/sifive/unleashed/unleashed.c:125:1: warning: control reaches end of 
non-void function [-Wreturn-type]

Return &_end as the default case.

[1] 
https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot

Signed-off-by: Bin Meng 
---

 board/sifive/unleashed/unleashed.c | 4 ++--
 board/sifive/unmatched/unmatched.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/sifive/unleashed/unleashed.c 
b/board/sifive/unleashed/unleashed.c
index 8cd514df30..33baeda986 100644
--- a/board/sifive/unleashed/unleashed.c
+++ b/board/sifive/unleashed/unleashed.c
@@ -119,9 +119,9 @@ void *board_fdt_blob_setup(void)
if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
if (gd->arch.firmware_fdt_addr)
return (ulong *)gd->arch.firmware_fdt_addr;
-   else
-   return (ulong *)&_end;
}
+
+   return (ulong *)&_end;
 }
 
 int board_init(void)
diff --git a/board/sifive/unmatched/unmatched.c 
b/board/sifive/unmatched/unmatched.c
index d90b252bae..8773b660fa 100644
--- a/board/sifive/unmatched/unmatched.c
+++ b/board/sifive/unmatched/unmatched.c
@@ -16,9 +16,9 @@ void *board_fdt_blob_setup(void)
if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
if (gd->arch.firmware_fdt_addr)
return (ulong *)gd->arch.firmware_fdt_addr;
-   else
-   return (ulong *)&_end;
}
+
+   return (ulong *)&_end;
 }
 
 int board_init(void)
-- 
2.25.1



Re: [PATCH 3/4] efi_loader: simplify efi_sigstore_parse_sigdb()

2021-09-11 Thread Ilias Apalodimas
On Sat, Sep 11, 2021 at 09:28:31AM +0200, Heinrich Schuchardt wrote:
> Simplify efi_sigstore_parse_sigdb() by using existing functions.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_signature.c | 35 ++
>  1 file changed, 6 insertions(+), 29 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c
> index bdd09881fc..b741905a99 100644
> --- a/lib/efi_loader/efi_signature.c
> +++ b/lib/efi_loader/efi_signature.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -740,44 +741,20 @@ err:
>   */
>  struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name)
>  {
> - struct efi_signature_store *sigstore = NULL;
>   const efi_guid_t *vendor;
>   void *db;
>   efi_uintn_t db_size;
> - efi_status_t ret;
> 
> - if (!u16_strcmp(name, L"PK") || !u16_strcmp(name, L"KEK")) {
> - vendor = _global_variable_guid;
> - } else if (!u16_strcmp(name, L"db") || !u16_strcmp(name, L"dbx")) {
> - vendor = _guid_image_security_database;
> - } else {
> + vendor = efi_auth_var_get_guid(name);
> + if (!vendor) {
>   EFI_PRINT("unknown signature database, %ls\n", name);
>   return NULL;
>   }

efi_auth_var_get_guid() will return _global_variable_guid if the
GUID for the variable name isn't found.

> 
> - /* retrieve variable data */
> - db_size = 0;
> - ret = EFI_CALL(efi_get_variable(name, vendor, NULL, _size, NULL));
> - if (ret == EFI_NOT_FOUND) {
> - EFI_PRINT("variable, %ls, not found\n", name);
> - sigstore = calloc(sizeof(*sigstore), 1);
> - return sigstore;
> - } else if (ret != EFI_BUFFER_TOO_SMALL) {
> - EFI_PRINT("Getting variable, %ls, failed\n", name);
> - return NULL;
> - }
> -
> - db = malloc(db_size);
> + db = efi_get_var(name, vendor, _size);
>   if (!db) {
> - EFI_PRINT("Out of memory\n");
> - return NULL;
> - }
> -
> - ret = EFI_CALL(efi_get_variable(name, vendor, NULL, _size, db));
> - if (ret != EFI_SUCCESS) {
> - EFI_PRINT("Getting variable, %ls, failed\n", name);
> - free(db);
> - return NULL;
> + EFI_PRINT("variable, %ls, not found\n", name);
> + return calloc(sizeof(struct efi_signature_store), 1);
>   }
> 
>   return efi_build_signature_store(db, db_size);
> --
> 2.30.2
> 


Re: [PATCH 2/4] efi_loader: function to get GUID for variable name

2021-09-11 Thread Ilias Apalodimas
On Sat, 11 Sept 2021 at 17:13, Ilias Apalodimas
 wrote:
>
> On Sat, Sep 11, 2021 at 09:28:30AM +0200, Heinrich Schuchardt wrote:
> > In multiple places we need the default GUID used for variables like
> > 'PK', 'KEK', 'db'. Provide a function for it.
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  include/efi_variable.h  | 8 
> >  lib/efi_loader/efi_var_common.c | 9 +
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/include/efi_variable.h b/include/efi_variable.h
> > index 8f666b2309..03a3ecb235 100644
> > --- a/include/efi_variable.h
> > +++ b/include/efi_variable.h
> > @@ -256,6 +256,14 @@ efi_status_t efi_init_secure_state(void);
> >  enum efi_auth_var_type efi_auth_var_get_type(const u16 *name,
> >const efi_guid_t *guid);
> >
> > +/**
> > + * efi_auth_var_get_guid() - get the predefined GUID for a variable name
> > + *
> > + * @name:name of UEFI variable
> > + * Return:   guid of UEFI variable
> > + */
> > +const efi_guid_t *efi_auth_var_get_guid(const u16 *name);
> > +
> >  /**
> >   * efi_get_next_variable_name_mem() - Runtime common code across efi 
> > variable
> >   *implementations for GetNextVariable()
> > diff --git a/lib/efi_loader/efi_var_common.c 
> > b/lib/efi_loader/efi_var_common.c
> > index e179932124..3cbb7c96c2 100644
> > --- a/lib/efi_loader/efi_var_common.c
> > +++ b/lib/efi_loader/efi_var_common.c
> > @@ -385,6 +385,15 @@ enum efi_auth_var_type efi_auth_var_get_type(const u16 
> > *name,
> >   return EFI_AUTH_VAR_NONE;
> >  }
> >
> > +const efi_guid_t *efi_auth_var_get_guid(const u16 *name)
> > +{
> > + for (size_t i = 0; i < ARRAY_SIZE(name_type); ++i) {
> > + if (!u16_strcmp(name, name_type[i].name))
> > + return name_type[i].guid;
> > + }
> > + return _global_variable_guid;

Actually looking at the following patch, shouldn't this be NULL?

> > +}
> > +
> >  /**
> >   * efi_get_var() - read value of an EFI variable
> >   *
> > --
> > 2.30.2
> >
>
> Reviewed-by: Ilias Apalodimas 


Re: [PATCH 2/4] efi_loader: function to get GUID for variable name

2021-09-11 Thread Ilias Apalodimas
On Sat, Sep 11, 2021 at 09:28:30AM +0200, Heinrich Schuchardt wrote:
> In multiple places we need the default GUID used for variables like
> 'PK', 'KEK', 'db'. Provide a function for it.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_variable.h  | 8 
>  lib/efi_loader/efi_var_common.c | 9 +
>  2 files changed, 17 insertions(+)
> 
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> index 8f666b2309..03a3ecb235 100644
> --- a/include/efi_variable.h
> +++ b/include/efi_variable.h
> @@ -256,6 +256,14 @@ efi_status_t efi_init_secure_state(void);
>  enum efi_auth_var_type efi_auth_var_get_type(const u16 *name,
>const efi_guid_t *guid);
> 
> +/**
> + * efi_auth_var_get_guid() - get the predefined GUID for a variable name
> + *
> + * @name:name of UEFI variable
> + * Return:   guid of UEFI variable
> + */
> +const efi_guid_t *efi_auth_var_get_guid(const u16 *name);
> +
>  /**
>   * efi_get_next_variable_name_mem() - Runtime common code across efi variable
>   *implementations for GetNextVariable()
> diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
> index e179932124..3cbb7c96c2 100644
> --- a/lib/efi_loader/efi_var_common.c
> +++ b/lib/efi_loader/efi_var_common.c
> @@ -385,6 +385,15 @@ enum efi_auth_var_type efi_auth_var_get_type(const u16 
> *name,
>   return EFI_AUTH_VAR_NONE;
>  }
> 
> +const efi_guid_t *efi_auth_var_get_guid(const u16 *name)
> +{
> + for (size_t i = 0; i < ARRAY_SIZE(name_type); ++i) {
> + if (!u16_strcmp(name, name_type[i].name))
> + return name_type[i].guid;
> + }
> + return _global_variable_guid;
> +}
> +
>  /**
>   * efi_get_var() - read value of an EFI variable
>   *
> --
> 2.30.2
> 

Reviewed-by: Ilias Apalodimas 


Re: [PATCH 1/4] efi_loader: treat UEFI variable name as const

2021-09-11 Thread Ilias Apalodimas
Hi Heinrich,

On Sat, Sep 11, 2021 at 09:28:29AM +0200, Heinrich Schuchardt wrote:
> Adjust several internal functions to treat UEFI variable names as const.

It's obvious what the patch does, but is there a reason ? I think that's a
better fit for the commit log. 

Cheers
/Ilias
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  |  2 +-
>  include/efi_variable.h| 16 ++--
>  lib/efi_loader/efi_tcg2.c |  2 +-
>  lib/efi_loader/efi_var_common.c   |  5 +++--
>  lib/efi_loader/efi_var_mem.c  |  7 ---
>  lib/efi_loader/efi_variable.c |  9 +
>  lib/efi_loader/efi_variable_tee.c | 16 ++--
>  7 files changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index c440962fe5..125052d002 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -816,7 +816,7 @@ efi_status_t EFIAPI efi_query_variable_info(
>   u64 *remaining_variable_storage_size,
>   u64 *maximum_variable_size);
> 
> -void *efi_get_var(u16 *name, const efi_guid_t *vendor, efi_uintn_t *size);
> +void *efi_get_var(const u16 *name, const efi_guid_t *vendor, efi_uintn_t 
> *size);
> 
>  /*
>   * See section 3.1.3 in the v2.7 UEFI spec for more details on
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> index 0440d356bc..8f666b2309 100644
> --- a/include/efi_variable.h
> +++ b/include/efi_variable.h
> @@ -32,7 +32,8 @@ enum efi_auth_var_type {
>   * @timep:   authentication time (seconds since start of epoch)
>   * Return:   status code
>   */
> -efi_status_t efi_get_variable_int(u16 *variable_name, const efi_guid_t 
> *vendor,
> +efi_status_t efi_get_variable_int(const u16 *variable_name,
> +   const efi_guid_t *vendor,
> u32 *attributes, efi_uintn_t *data_size,
> void *data, u64 *timep);
> 
> @@ -47,7 +48,8 @@ efi_status_t efi_get_variable_int(u16 *variable_name, const 
> efi_guid_t *vendor,
>   * @ro_check:check the read only read only bit in attributes
>   * Return:   status code
>   */
> -efi_status_t efi_set_variable_int(u16 *variable_name, const efi_guid_t 
> *vendor,
> +efi_status_t efi_set_variable_int(const u16 *variable_name,
> +   const efi_guid_t *vendor,
> u32 attributes, efi_uintn_t data_size,
> const void *data, bool ro_check);
> 
> @@ -224,7 +226,7 @@ void efi_var_mem_del(struct efi_var_entry *var);
>   * @time:time of authentication (as seconds since start of epoch)
>   * Result:   status code
>   */
> -efi_status_t efi_var_mem_ins(u16 *variable_name,
> +efi_status_t efi_var_mem_ins(const u16 *variable_name,
>const efi_guid_t *vendor, u32 attributes,
>const efi_uintn_t size1, const void *data1,
>const efi_uintn_t size2, const void *data2,
> @@ -251,7 +253,8 @@ efi_status_t efi_init_secure_state(void);
>   * @guid:guid of UEFI variable
>   * Return:   identifier for authentication related variables
>   */
> -enum efi_auth_var_type efi_auth_var_get_type(u16 *name, const efi_guid_t 
> *guid);
> +enum efi_auth_var_type efi_auth_var_get_type(const u16 *name,
> +  const efi_guid_t *guid);
> 
>  /**
>   * efi_get_next_variable_name_mem() - Runtime common code across efi variable
> @@ -280,8 +283,9 @@ efi_get_next_variable_name_mem(efi_uintn_t 
> *variable_name_size, u16 *variable_na
>   * Return:   status code
>   */
>  efi_status_t __efi_runtime
> -efi_get_variable_mem(u16 *variable_name, const efi_guid_t *vendor, u32 
> *attributes,
> -  efi_uintn_t *data_size, void *data, u64 *timep);
> +efi_get_variable_mem(const u16 *variable_name, const efi_guid_t *vendor,
> +  u32 *attributes, efi_uintn_t *data_size, void *data,
> +  u64 *timep);
> 
>  /**
>   * efi_get_variable_runtime() - runtime implementation of GetVariable()
> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> index 401acf3d4f..beb224f66a 100644
> --- a/lib/efi_loader/efi_tcg2.c
> +++ b/lib/efi_loader/efi_tcg2.c
> @@ -1359,7 +1359,7 @@ static efi_status_t efi_append_scrtm_version(struct 
> udevice *dev)
>   * Return:   status code
>   */
>  static efi_status_t tcg2_measure_variable(struct udevice *dev, u32 pcr_index,
> -   u32 event_type, u16 *var_name,
> +   u32 event_type, const u16 *var_name,
> const efi_guid_t *guid,
> efi_uintn_t data_size, u8 *data)
>  {
> diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
> index a00bbf1620..e179932124 100644
> --- 

[PATCH 1/3] doc: ti: Convert am335x_evm README to rST

2021-09-11 Thread Tom Rini
Convert the existing documentation to rST, keeping to just making
formatting changes to start with.

Signed-off-by: Tom Rini 
---
 .../README => doc/board/ti/am335x_evm.rst | 150 ++
 doc/board/ti/index.rst|   1 +
 2 files changed, 87 insertions(+), 64 deletions(-)
 rename board/ti/am335x/README => doc/board/ti/am335x_evm.rst (67%)

diff --git a/board/ti/am335x/README b/doc/board/ti/am335x_evm.rst
similarity index 67%
rename from board/ti/am335x/README
rename to doc/board/ti/am335x_evm.rst
index 19e0eccbac93..51c11a3e51f8 100644
--- a/board/ti/am335x/README
+++ b/doc/board/ti/am335x_evm.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Tom Rini 
+
 Summary
 ===
 
@@ -5,17 +8,17 @@ This document covers various features of the 'am335x_evm' 
build, and some of
 the related build targets (am335x_evm_uartN, etc).
 
 Hardware
-
+
 
 The binary produced by this board supports, based on parsing of the EEPROM
 documented in TI's reference designs:
-- AM335x GP EVM
-- AM335x EVM SK
-- Beaglebone White
-- Beaglebone Black
+* AM335x GP EVM
+* AM335x EVM SK
+* Beaglebone White
+* Beaglebone Black
 
 Customization
-=
+-
 
 Given that all of the above boards are reference platforms (and the
 Beaglebone platforms are OSHA), it is likely that this platform code and
@@ -24,12 +27,12 @@ worth noting that aside from things such as NAND or MMC 
only being
 required if a custom platform makes use of these blocks, the following
 are required, depending on design:
 
-- GPIO is only required if DDR3 power is controlled in a way similar to
-  EVM SK
-- SPI is only required for SPI flash, or exposing the SPI bus.
+* GPIO is only required if DDR3 power is controlled in a way similar to EVM SK
+* SPI is only required for SPI flash, or exposing the SPI bus.
 
 The following blocks are required:
-- I2C, to talk with the PMIC and ensure that we do not run afoul of
+
+* I2C, to talk with the PMIC and ensure that we do not run afoul of
   errata 1.0.24.
 
 When removing options as part of customization,
@@ -41,7 +44,7 @@ the IP blocks, so both areas will need their choices updated 
to reflect
 the custom design.
 
 NAND
-
+
 
 The AM335x GP EVM ships with a 256MiB NAND available in most profiles.  In
 this example to program the NAND we assume that an SD card has been
@@ -58,6 +61,9 @@ Step-1: Building u-boot for NAND boot
CONFIG_NAND_OMAP_ECCSCHEME  (refer doc/README.nand)
 
 Step-2: Flashing NAND via MMC/SD
+
+.. code-block:: text
+
# select BOOTSEL to MMC/SD boot and boot from MMC/SD card
U-Boot # mmc rescan
# erase flash
@@ -84,7 +90,7 @@ Step-3: Set BOOTSEL pin to select NAND boot, and POR the 
device.
The device should boot from images flashed on NAND device.
 
 NOR
-===
+---
 
 The Beaglebone White can be equipped with a "memory cape" that in turn can
 have a NOR module plugged into it.  In this case it is then possible to
@@ -100,14 +106,16 @@ prepended.  In the following example we use a size of 
512KiB (0x8)
 as that is how much space we set aside before the environment, as per
 the config file.
 
-U-Boot # mmc rescan
-U-Boot # load mmc 0 ${loadaddr} u-boot.bin
-U-Boot # protect off 0800 +8
-U-Boot # erase 0800 +8
-U-Boot # cp.b ${loadaddr} 0800 ${filesize}
+.. code-block:: text
+
+   U-Boot # mmc rescan
+   U-Boot # load mmc 0 ${loadaddr} u-boot.bin
+   U-Boot # protect off 0800 +8
+   U-Boot # erase 0800 +8
+   U-Boot # cp.b ${loadaddr} 0800 ${filesize}
 
 Falcon Mode
-===
+---
 
 The default build includes "Falcon Mode" (see doc/README.falcon) via NAND,
 eMMC (or raw SD cards) and FAT SD cards.  Our default behavior currently is
@@ -119,18 +127,20 @@ boards with multiple boot methods, recovery should not be 
an issue in this
 worst-case however.
 
 Falcon Mode: eMMC
-=
+-
 
 The recommended layout in this case is:
 
-MMC BLOCKS  || LOCATION IN BYTES
-0x - 0x007F : MBR or GPT table   : 0x00 - 0x02
-0x0080 - 0x00FF : ARGS or FDT file   : 0x01 - 0x02
-0x0100 - 0x01FF : SPL.backup1 (first copy used)  : 0x02 - 0x04
-0x0200 - 0x02FF : SPL.backup2 (second copy used) : 0x04 - 0x06
-0x0300 - 0x06FF : U-Boot : 0x06 - 0x0e
-0x0700 - 0x08FF : U-Boot Env + Redundant : 0x0e - 0x12
-0x0900 - 0x28FF : Kernel : 0x12 - 0x52
+.. code-block:: text
+
+   MMC BLOCKS  || LOCATION IN BYTES
+   0x - 0x007F : MBR or GPT table   : 0x00 - 0x02
+   0x0080 - 0x00FF : ARGS or FDT file   : 0x01 - 0x02
+   0x0100 - 0x01FF : SPL.backup1 (first copy used)  : 0x02 - 0x04
+   0x0200 - 0x02FF : 

[PATCH 3/3] am335x: Enable SPL_OF_CONTROL

2021-09-11 Thread Tom Rini
It has long been known that we need to enable SPL_OF_CONTROL on this
platform, as some included drivers do not function correctly without it,
but were also stuck due to size constraints.  Resolve this problem by:

- Updating the generic board.c file to use CONFIG_IS_ENABLED(USB_ETHER)
  to distinguish between SPL and full U-Boot.
- Disable SPL_ETH support as the CPSW driver (and related PHY/etc) are
  were we need SPL_OF_CONTROL support, but cannot due to size constraints.
- Update the documentation on how to enable this mode and recommend what
  to remove in order to fit within size constraints.

Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 arch/arm/mach-omap2/am33xx/board.c |  2 +-
 configs/am335x_evm_defconfig   |  2 +-
 doc/board/ti/am335x_evm.rst| 10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/board.c 
b/arch/arm/mach-omap2/am33xx/board.c
index d390f2e1f3e8..db268b1381e7 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -338,7 +338,7 @@ int arch_misc_init(void)
if (ret || !dev)
return ret;
 
-#if defined(CONFIG_DM_ETH) && defined(CONFIG_USB_ETHER)
+#if defined(CONFIG_DM_ETH) && CONFIG_IS_ENABLED(USB_ETHER)
ret = usb_ether_init();
if (ret) {
pr_err("USB ether init failed\n");
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index ef8de5999e0d..d497ca8d96ba 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -14,7 +14,6 @@ CONFIG_LOGLEVEL=3
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_ARCH_MISC_INIT=y
 CONFIG_SPL_FIT_IMAGE_TINY=y
-CONFIG_SPL_ETH=y
 # CONFIG_SPL_FS_EXT4 is not set
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_MUSB_NEW=y
@@ -37,6 +36,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="am335x-evm am335x-bone am335x-sancloud-bbe am335x-boneblack 
am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
 CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst
index a90f32da7aea..55315e0ad79b 100644
--- a/doc/board/ti/am335x_evm.rst
+++ b/doc/board/ti/am335x_evm.rst
@@ -86,6 +86,16 @@ Step-2: Flashing NAND via MMC/SD
 Step-3: Set BOOTSEL pin to select NAND boot, and POR the device.
The device should boot from images flashed on NAND device.
 
+Ethernet Boot
+-
+
+The AM335x SoC supports booting from CPSW ethernet.  This feature is not
+enabled in U-Boot by default.  In order to support this ``CONFIG_SPL_ETH``
+needs to be enabled and in order to have U-Boot fit within size constraints you
+will need to disable some other functionality.  Disabling
+``CONFIG_SPL_USB_GADGET`` and ``CONFIG_SPL_MUSB_NEW`` is recommended as this is
+used to provide SPL support via USB networking instead, which is unlikely to be
+used in the same design.
 
 Falcon Mode
 ---
-- 
2.17.1



[PATCH 2/3] doc: ti: am335x_evm: Minor general updates

2021-09-11 Thread Tom Rini
- At this point there are a large number of Beaglebone boards, refer to
  them as a family rather than a growing list.
- Reword customization as we're largely Kconfig-oriented now.
- Remove the NOR section as the relevant defconfigs have long been
  removed and the general support was not updated.

Signed-off-by: Tom Rini 
---
 doc/board/ti/am335x_evm.rst | 43 +++--
 1 file changed, 8 insertions(+), 35 deletions(-)

diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst
index 51c11a3e51f8..a90f32da7aea 100644
--- a/doc/board/ti/am335x_evm.rst
+++ b/doc/board/ti/am335x_evm.rst
@@ -4,8 +4,9 @@
 Summary
 ===
 
-This document covers various features of the 'am335x_evm' build, and some of
-the related build targets (am335x_evm_uartN, etc).
+This document covers various features of the `am335x_evm` default
+configuration, some of the related defconfigs, and how to enable hardware
+features not present by default in the defconfigs.
 
 Hardware
 
@@ -14,8 +15,7 @@ The binary produced by this board supports, based on parsing 
of the EEPROM
 documented in TI's reference designs:
 * AM335x GP EVM
 * AM335x EVM SK
-* Beaglebone White
-* Beaglebone Black
+* The Beaglebone family of designs
 
 Customization
 -
@@ -35,13 +35,10 @@ The following blocks are required:
 * I2C, to talk with the PMIC and ensure that we do not run afoul of
   errata 1.0.24.
 
-When removing options as part of customization,
-CONFIG_EXTRA_ENV_SETTINGS will need additional care to update for your
-needs and to remove no longer relevant options as in some cases we
-define additional text blocks (such as for NAND or DFU strings).  Also
-note that all of the SPL options are grouped together, rather than with
-the IP blocks, so both areas will need their choices updated to reflect
-the custom design.
+When removing options as part of customization, note that you will likely need
+to look at both `include/configs/am335x_evm.h`,
+`include/configs/ti_am335x_common.h` and `include/configs/am335x_evm.h` as the
+migration to Kconfig is not yet complete.
 
 NAND
 
@@ -89,30 +86,6 @@ Step-2: Flashing NAND via MMC/SD
 Step-3: Set BOOTSEL pin to select NAND boot, and POR the device.
The device should boot from images flashed on NAND device.
 
-NOR

-
-The Beaglebone White can be equipped with a "memory cape" that in turn can
-have a NOR module plugged into it.  In this case it is then possible to
-program and boot from NOR.  Note that due to how U-Boot is designed we
-must build a specific version of U-Boot that knows we have NOR flash.  This
-build is named 'am335x_evm_nor'.  Further, we have a 'am335x_evm_norboot'
-build that will assume that the environment is on NOR rather than NAND.  In
-the following example we assume that and SD card has been populated with
-MLO and u-boot.img from a 'am335x_evm_nor' build and also contains the
-'u-boot.bin' from a 'am335x_evm_norboot' build.  When booting from NOR, a
-binary must be written to the start of NOR, with no header or similar
-prepended.  In the following example we use a size of 512KiB (0x8)
-as that is how much space we set aside before the environment, as per
-the config file.
-
-.. code-block:: text
-
-   U-Boot # mmc rescan
-   U-Boot # load mmc 0 ${loadaddr} u-boot.bin
-   U-Boot # protect off 0800 +8
-   U-Boot # erase 0800 +8
-   U-Boot # cp.b ${loadaddr} 0800 ${filesize}
 
 Falcon Mode
 ---
-- 
2.17.1



Re: [PATCH v2 3/3] configs: j72*_evm: Define the buffer sizes for dfu

2021-09-11 Thread Tom Rini
On Thu, Aug 26, 2021 at 09:28:59PM +0530, Aswath Govindraju wrote:

> On J721e R5 SPL, dfu buffer for loading sysfw.itb image gets allocated
> before DRAM gets initialized. So, the buffer gets allocated in MCU L3
> RAM. The current buffer size to be allocated is 256KB  and the available
> total heap memory is 0x7 (448KB). This leads to NOMEM errors during
> allocation.
> 
> In other cases when constraints such as above are not present fix the size
> of buffers to the sector size in OSPI for proper functioning.
> 
> Also, if CONFIG_SYS_DFU_DATA_BUF_SIZE is defined and
> CONFIG_SYS_DFU_MAX_FILE_SIZE is not defined then the max file size for dfu
> transfer is defined as CONFIG_SYS_DFU_DATA_BUF_SIZE.
> 
> Fix these by setting appropriate buffer sizes in their respective defconfig
> files and defining the max file size as 8 MB which is the default dfu
> buffer size.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/3] environment: ti: k3_dfu: Increase the size allocated for bootloader images in dfu_alt_info_ram

2021-09-11 Thread Tom Rini
On Thu, Aug 26, 2021 at 09:28:58PM +0530, Aswath Govindraju wrote:

> The size of u-boot.img is above 1MB and that of tispl.bin is close to 1MB,
> in case of j721e. Therefore, increase the sizes allocated for tispl.bin and
> u-boot.img to 2 MB and 4 MB respectively, in dfu_alt_info_ram environment
> variable.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/3] arm: dts: k3-j721e-r5-*.dts: Fix clock-names property in the usb0 instance

2021-09-11 Thread Tom Rini
On Thu, Aug 26, 2021 at 09:28:57PM +0530, Aswath Govindraju wrote:

> In the cdns3 usb driver, the clock name looked for is ref. Therefore, fix
> the clock-names property in usb0 instance for proper initialization of
> cdns3 usb gadget driver.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] ARM: dts: Fix node status to "okay" on TI boards

2021-09-11 Thread Tom Rini
On Tue, Aug 24, 2021 at 02:07:27PM +0300, Roger Quadros wrote:

> As per Device Tree Specification [1], the status parameter of nodes can
> be "okay", "disabled", etc. "ok" is not a valid parameter.
> 
> U-boot Driver Model does not recognize status="ok" either and treats
> the node as disabled.
> 
> [1] 
> https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
> 
> Signed-off-by: Roger Quadros 
> Reviewed-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] tools: k3_fit_atf: Fix DM binary FIT load addresses

2021-09-11 Thread Tom Rini
On Sat, Aug 14, 2021 at 01:49:01AM -0500, Suman Anna wrote:

> The DM binary runs on the MCU R5F Core0 after R5 SPL on J721E and J7200
> SoCs. The binary is built alongside the TFA, OPTEE and A72 SPL binaries
> and included in the tispl.bin FIT image. The R5 SPL loads the DM binary
> at 0xA000 address, based on the value used in the FIT image build
> script. The DM binary though is an ELF image and not a regular binary
> file, and so is processed further to load the actual program segments
> using the U-Boot's standard ELF loader library.
> 
> The DM binary does leverage a certain portion of DDR for its program
> segments, and typically reserves 16 MB of DDR at 0xA000 with the
> 1st MB used for IPC between Linux and the remote processor, and
> remaining memory for firmware segments. This can cause an incomplete
> loading of the program segments if the DM binary is larger than 1 MB,
> due to overlap of the initial loaded binary and the actual program
> segments.
> 
> Fix this by using the address 0x8900, which matches the current
> "addr_mcur5f0_0load" env variable used by R5 SPL before the DM firmware
> inclusion into the tispl.bin.
> 
> Fixes: df5363a67f35 ("tools: k3_fit_atf: add DM binary to the FIT image")
> Signed-off-by: Suman Anna 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm: dts: k3-am642-evm-u-boot: Add u-boot, dm-spl tag in the pinmux node of mmc1

2021-09-11 Thread Tom Rini
On Mon, Aug 09, 2021 at 10:32:23PM +0530, Aswath Govindraju wrote:

> Add u-boot,dm-spl tag in the pinmux device tree node, required for MMCSD1
> subsystem.
> 
> Fixes: b6059ddc45b9 ("arm: dts: k3-am642: Add r5 specific dt support")
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] am33xx: Fix USB for am335x boards

2021-09-11 Thread Tom Rini
On Sat, Aug 07, 2021 at 02:17:38PM +0300, Matwey V. Kornilov wrote:

> USB nodes were mistakenly disabled in
> 
> commit 942853dd96df ("arm: dts: Resync BeagleBone device trees")
> 
> This commit is to fix the following issue:
> 
> starting USB...
> No working controllers found
> USB is stopped. Please issue 'usb start' first.
> starting USB...
> No working controllers found
> 
> Reference: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85
> Fixes: 942853dd96df ("arm: dts: Resync BeagleBone device trees")
> Signed-off-by: Matwey V. Kornilov 
> Reviewed-by: Paul Barker 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/3] include: configs: am64x_evm: Add env variables for booting to kernel using USB MSC device

2021-09-11 Thread Tom Rini
On Wed, Aug 04, 2021 at 06:42:46PM +0530, Aswath Govindraju wrote:

> Add env variables for booting to kernel from USB MSC device. The second
> partition in the USB MSC device needs to formatted as ext4 file system with
> kernel and dtb images, present in the /boot folder.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/3] environment: ti: mmc.h: Make the finduuid generic for usage across different device types

2021-09-11 Thread Tom Rini
On Wed, Aug 04, 2021 at 06:42:45PM +0530, Aswath Govindraju wrote:

> Make finduuid generic by making it dependent on the boot variable. For
> example, this can now be used for finding the uuid of partitions in usb
> device too.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/3] board: ti: am64x: Add support for fixing dr_mode while booting from USB

2021-09-11 Thread Tom Rini
On Wed, Aug 04, 2021 at 06:42:44PM +0530, Aswath Govindraju wrote:

> Fix the dr_mode in the U-Boot device tree blob, by reading the mode field
> from the USB Boot Configuration fields. The dr_mode will only be fixed when
> booting from USB.
> 
> Signed-off-by: Aswath Govindraju 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] ARM: omap3: evm: Enable booting 'fitImage' with DEFAULT_FIT_TI_ARGS

2021-09-11 Thread Tom Rini
On Mon, Aug 02, 2021 at 03:46:19AM +, Derald D. Woods wrote:

> This commit uses the existing DEFAULT_MMC_TI_ARGS and
> DEFAULT_FIT_TI_ARGS defintions to replace the 'mmc*' environment
> variables in the configuration. The check for the 'boot_fit' is handled
> like the 'am335x_*' boards with 'CONFIG_BOOTCOMMAND'.
> 
> Signed-off-by: Derald D. Woods 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm: am335x: Enable SPL_OF_CONTROL on some configs

2021-09-11 Thread Tom Rini
On Sat, Jul 31, 2021 at 07:21:58PM -0400, Tom Rini wrote:

> Both am335x_boneblack_vboot and am335x_evm_spiboot require
> SPL_OF_CONTROL to function but are currently missing this option.  Add
> it.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 4/4] configs: enable SYSRESET_SBI on qemu-riscvXX_smode_defconfig

2021-09-11 Thread Bin Meng
On Fri, Sep 10, 2021 at 10:15 PM Heinrich Schuchardt
 wrote:
>
> There should be a platform compiled with the new driver.
>
> If you want to test the SBI sysreset driver, disable
> CONFIG_SYSRESET_SYSCON. In OpenSBI sifive_test_system_reset() will be
> called.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v5:
> new patch
> ---
>  configs/qemu-riscv32_smode_defconfig | 1 +
>  configs/qemu-riscv64_smode_defconfig | 1 +
>  2 files changed, 2 insertions(+)
>

Should also turn it on for the SPL version.

Regards,
Bin


Re: [PATCH v5 3/4] sysreset: provide SBI based sysreset driver

2021-09-11 Thread Bin Meng
On Fri, Sep 10, 2021 at 10:15 PM Heinrich Schuchardt
 wrote:
>
> Provide sysreset driver using the SBI system reset extension.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v5:
> * don't add __efi_runtime
> * use '=' not ':' in array initialization with enum indices
> v4:
> * remove the UEFI SystemReset() implementation
> * simplify the code using an array to translate reset types
> * remove a superfluos check to determine if the device was probed
> ---
>  MAINTAINERS |  1 +
>  arch/riscv/cpu/cpu.c| 13 -
>  arch/riscv/include/asm/sbi.h|  1 +
>  arch/riscv/lib/sbi.c| 12 
>  drivers/sysreset/Kconfig| 12 
>  drivers/sysreset/Makefile   |  1 +
>  drivers/sysreset/sysreset_sbi.c | 51 +
>  7 files changed, 90 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/sysreset/sysreset_sbi.c
>

Reviewed-by: Bin Meng 


Re: [PATCH v3 1/3] doc: Tidy up the bindings for the config/ node

2021-09-11 Thread Heinrich Schuchardt

On 9/9/21 10:10 PM, Simon Glass wrote:

Sort these and add a type so it is clear how to set the value. Add a note
about usage to the top. Correct the 'no-keyboard' binding which is missing
a prefix.

Signed-off-by: Simon Glass 
Reviewed-by: Marcel Ziswiler 
---
Note that some uses a u-boot prefix and some don't. Once [1] is applied
we may want to update this to always use the prefix, or never. Another
option would be to call the node u-boot,config. and drop the prefix. This
has the advantage of complying with the devicetree spec, at little cost.

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20210807132413.3513724-2-...@chromium.org/

Changes in v3:
- Add missing period

Changes in v2:
- Add a new patch to tidy up the /config bindings

  doc/device-tree-bindings/config.txt | 46 -


This text file is not integrated into the HTML documentation.

Either rename it to something like u-boot-bindings.rst and add it in an
appropriate place. Or use :download:`title ` to link to the
text file.

This all can be done in a future patch.

I will take this patch as is into my next pull request as has been
assigned to me.

Best regards

Heinrich


  1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/doc/device-tree-bindings/config.txt 
b/doc/device-tree-bindings/config.txt
index 6cdc16da5b5..f704eb695f5 100644
--- a/doc/device-tree-bindings/config.txt
+++ b/doc/device-tree-bindings/config.txt
@@ -5,15 +5,15 @@ A number of run-time configuration options are provided in 
the /config node
  of the control device tree. You can access these using 
fdtdec_get_config_int(),
  fdtdec_get_config_bool() and fdtdec_get_config_string().

-Available options are:
-
-silent-console
-   If present and non-zero, the console is silenced by default on boot.
+These options are designed to affect the operation of U-Boot at runtime.
+Runtime-configuration items can help avoid proliferation of different builds
+with only minor changes, e.g. enabling and disabling console output. Items
+here should be those that can usefully be set by the build system after U-Boot
+is built.

-no-keyboard
-   Tells U-Boot not to expect an attached keyboard with a VGA console
+Available options are:

-u-boot,efi-partition-entries-offset
+u-boot,efi-partition-entries-offset (int)
If present, this provides an offset (in bytes, from the start of a
device) that should be skipped over before the partition entries.
This is used by the EFI/GPT partition implementation when a device
@@ -21,17 +21,8 @@ u-boot,efi-partition-entries-offset

This setting will override any values configured via Kconfig.

-u-boot,mmc-env-partition
-   if present, the environment shall be placed at the last
-   CONFIG_ENV_SIZE blocks of the partition on the
-   CONFIG_SYS_MMC_ENV_DEV.
-
-   if u-boot,mmc-env-offset* is present, this setting will take
-   precedence. In that case, only if the partition is not found,
-   mmc-env-offset* will be tried.
-
-u-boot,mmc-env-offset
-u-boot,mmc-env-offset-redundant
+u-boot,mmc-env-offset (int)
+u-boot,mmc-env-offset-redundant (int)
If present, the values of the 'u-boot,mmc-env-offset' and/or
of the u-boot,mmc-env-offset-redundant' properties overrides
CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND, respectively,
@@ -42,12 +33,27 @@ u-boot,mmc-env-offset-redundant
will point at the beginning of a LBA and values that are not
LBA-aligned will be rounded up to the next LBA address.

-u-boot,spl-payload-offset
+u-boot,mmc-env-partition (int)
+   if present, the environment shall be placed at the last
+   CONFIG_ENV_SIZE blocks of the partition on the
+   CONFIG_SYS_MMC_ENV_DEV.
+
+   if u-boot,mmc-env-offset* is present, this setting will take
+   precedence. In that case, only if the partition is not found,
+   mmc-env-offset* will be tried.
+
+u-boot,no-keyboard (bool)
+   Tells U-Boot not to expect an attached keyboard with a VGA console.
+
+silent-console (int)
+   If present and non-zero, the console is silenced by default on boot.
+
+u-boot,spl-payload-offset (int)
If present (and SPL is controlled by the device-tree), this allows
to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value
from the device-tree.

-sysreset-gpio
+sysreset-gpio (string)
If present (and supported by the specific board), indicates a
GPIO that can be set to trigger a system reset.  It is assumed
that such a system reset will effect a complete platform reset,





Re: [PATCH] efi_loader: boot_service_capability_min should be capitalized

2021-09-11 Thread Heinrich Schuchardt

On 9/6/21 5:04 AM, Masahisa Kojima wrote:

boot_service_capability_min is constant, it should be capitalized.

Signed-off-by: Masahisa Kojima 


Reviewed-by: Heinrich Schuchardt 


[PATCH 2/4] efi_loader: function to get GUID for variable name

2021-09-11 Thread Heinrich Schuchardt
In multiple places we need the default GUID used for variables like
'PK', 'KEK', 'db'. Provide a function for it.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_variable.h  | 8 
 lib/efi_loader/efi_var_common.c | 9 +
 2 files changed, 17 insertions(+)

diff --git a/include/efi_variable.h b/include/efi_variable.h
index 8f666b2309..03a3ecb235 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -256,6 +256,14 @@ efi_status_t efi_init_secure_state(void);
 enum efi_auth_var_type efi_auth_var_get_type(const u16 *name,
 const efi_guid_t *guid);

+/**
+ * efi_auth_var_get_guid() - get the predefined GUID for a variable name
+ *
+ * @name:  name of UEFI variable
+ * Return: guid of UEFI variable
+ */
+const efi_guid_t *efi_auth_var_get_guid(const u16 *name);
+
 /**
  * efi_get_next_variable_name_mem() - Runtime common code across efi variable
  *implementations for GetNextVariable()
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index e179932124..3cbb7c96c2 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -385,6 +385,15 @@ enum efi_auth_var_type efi_auth_var_get_type(const u16 
*name,
return EFI_AUTH_VAR_NONE;
 }

+const efi_guid_t *efi_auth_var_get_guid(const u16 *name)
+{
+   for (size_t i = 0; i < ARRAY_SIZE(name_type); ++i) {
+   if (!u16_strcmp(name, name_type[i].name))
+   return name_type[i].guid;
+   }
+   return _global_variable_guid;
+}
+
 /**
  * efi_get_var() - read value of an EFI variable
  *
--
2.30.2



[PATCH 4/4] efi_loader: simplify tcg2_measure_secure_boot_variable()

2021-09-11 Thread Heinrich Schuchardt
Don't duplicate GUIDs.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_tcg2.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index beb224f66a..eb2c0a413c 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -79,17 +80,12 @@ static const struct digest_info hash_algo_list[] = {
},
 };

-struct variable_info {
-   u16 *name;
-   const efi_guid_t*guid;
-};
-
-static struct variable_info secure_variables[] = {
-   {L"SecureBoot", _global_variable_guid},
-   {L"PK", _global_variable_guid},
-   {L"KEK", _global_variable_guid},
-   {L"db", _guid_image_security_database},
-   {L"dbx", _guid_image_security_database},
+static const u16 *secure_variables[] = {
+   u"SecureBoot",
+   u"PK",
+   u"KEK",
+   u"db",
+   u"dbx",
 };

 #define MAX_HASH_COUNT ARRAY_SIZE(hash_algo_list)
@@ -1587,19 +1583,20 @@ static efi_status_t 
tcg2_measure_secure_boot_variable(struct udevice *dev)

count = ARRAY_SIZE(secure_variables);
for (i = 0; i < count; i++) {
+   const efi_guid_t *guid;
+
+   guid = efi_auth_var_get_guid(secure_variables[i]);
+
/*
 * According to the TCG2 PC Client PFP spec, "SecureBoot",
 * "PK", "KEK", "db" and "dbx" variables must be measured
 * even if they are empty.
 */
-   data = efi_get_var(secure_variables[i].name,
-  secure_variables[i].guid,
-  _size);
+   data = efi_get_var(secure_variables[i], guid, _size);

ret = tcg2_measure_variable(dev, 7,
EV_EFI_VARIABLE_DRIVER_CONFIG,
-   secure_variables[i].name,
-   secure_variables[i].guid,
+   secure_variables[i], guid,
data_size, data);
free(data);
if (ret != EFI_SUCCESS)
--
2.30.2



[PATCH 3/4] efi_loader: simplify efi_sigstore_parse_sigdb()

2021-09-11 Thread Heinrich Schuchardt
Simplify efi_sigstore_parse_sigdb() by using existing functions.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_signature.c | 35 ++
 1 file changed, 6 insertions(+), 29 deletions(-)

diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c
index bdd09881fc..b741905a99 100644
--- a/lib/efi_loader/efi_signature.c
+++ b/lib/efi_loader/efi_signature.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -740,44 +741,20 @@ err:
  */
 struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name)
 {
-   struct efi_signature_store *sigstore = NULL;
const efi_guid_t *vendor;
void *db;
efi_uintn_t db_size;
-   efi_status_t ret;

-   if (!u16_strcmp(name, L"PK") || !u16_strcmp(name, L"KEK")) {
-   vendor = _global_variable_guid;
-   } else if (!u16_strcmp(name, L"db") || !u16_strcmp(name, L"dbx")) {
-   vendor = _guid_image_security_database;
-   } else {
+   vendor = efi_auth_var_get_guid(name);
+   if (!vendor) {
EFI_PRINT("unknown signature database, %ls\n", name);
return NULL;
}

-   /* retrieve variable data */
-   db_size = 0;
-   ret = EFI_CALL(efi_get_variable(name, vendor, NULL, _size, NULL));
-   if (ret == EFI_NOT_FOUND) {
-   EFI_PRINT("variable, %ls, not found\n", name);
-   sigstore = calloc(sizeof(*sigstore), 1);
-   return sigstore;
-   } else if (ret != EFI_BUFFER_TOO_SMALL) {
-   EFI_PRINT("Getting variable, %ls, failed\n", name);
-   return NULL;
-   }
-
-   db = malloc(db_size);
+   db = efi_get_var(name, vendor, _size);
if (!db) {
-   EFI_PRINT("Out of memory\n");
-   return NULL;
-   }
-
-   ret = EFI_CALL(efi_get_variable(name, vendor, NULL, _size, db));
-   if (ret != EFI_SUCCESS) {
-   EFI_PRINT("Getting variable, %ls, failed\n", name);
-   free(db);
-   return NULL;
+   EFI_PRINT("variable, %ls, not found\n", name);
+   return calloc(sizeof(struct efi_signature_store), 1);
}

return efi_build_signature_store(db, db_size);
--
2.30.2



[PATCH 1/4] efi_loader: treat UEFI variable name as const

2021-09-11 Thread Heinrich Schuchardt
Adjust several internal functions to treat UEFI variable names as const.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h  |  2 +-
 include/efi_variable.h| 16 ++--
 lib/efi_loader/efi_tcg2.c |  2 +-
 lib/efi_loader/efi_var_common.c   |  5 +++--
 lib/efi_loader/efi_var_mem.c  |  7 ---
 lib/efi_loader/efi_variable.c |  9 +
 lib/efi_loader/efi_variable_tee.c | 16 ++--
 7 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index c440962fe5..125052d002 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -816,7 +816,7 @@ efi_status_t EFIAPI efi_query_variable_info(
u64 *remaining_variable_storage_size,
u64 *maximum_variable_size);

-void *efi_get_var(u16 *name, const efi_guid_t *vendor, efi_uintn_t *size);
+void *efi_get_var(const u16 *name, const efi_guid_t *vendor, efi_uintn_t 
*size);

 /*
  * See section 3.1.3 in the v2.7 UEFI spec for more details on
diff --git a/include/efi_variable.h b/include/efi_variable.h
index 0440d356bc..8f666b2309 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -32,7 +32,8 @@ enum efi_auth_var_type {
  * @timep: authentication time (seconds since start of epoch)
  * Return: status code
  */
-efi_status_t efi_get_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+efi_status_t efi_get_variable_int(const u16 *variable_name,
+ const efi_guid_t *vendor,
  u32 *attributes, efi_uintn_t *data_size,
  void *data, u64 *timep);

@@ -47,7 +48,8 @@ efi_status_t efi_get_variable_int(u16 *variable_name, const 
efi_guid_t *vendor,
  * @ro_check:  check the read only read only bit in attributes
  * Return: status code
  */
-efi_status_t efi_set_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+efi_status_t efi_set_variable_int(const u16 *variable_name,
+ const efi_guid_t *vendor,
  u32 attributes, efi_uintn_t data_size,
  const void *data, bool ro_check);

@@ -224,7 +226,7 @@ void efi_var_mem_del(struct efi_var_entry *var);
  * @time:  time of authentication (as seconds since start of epoch)
  * Result: status code
  */
-efi_status_t efi_var_mem_ins(u16 *variable_name,
+efi_status_t efi_var_mem_ins(const u16 *variable_name,
 const efi_guid_t *vendor, u32 attributes,
 const efi_uintn_t size1, const void *data1,
 const efi_uintn_t size2, const void *data2,
@@ -251,7 +253,8 @@ efi_status_t efi_init_secure_state(void);
  * @guid:  guid of UEFI variable
  * Return: identifier for authentication related variables
  */
-enum efi_auth_var_type efi_auth_var_get_type(u16 *name, const efi_guid_t 
*guid);
+enum efi_auth_var_type efi_auth_var_get_type(const u16 *name,
+const efi_guid_t *guid);

 /**
  * efi_get_next_variable_name_mem() - Runtime common code across efi variable
@@ -280,8 +283,9 @@ efi_get_next_variable_name_mem(efi_uintn_t 
*variable_name_size, u16 *variable_na
  * Return: status code
  */
 efi_status_t __efi_runtime
-efi_get_variable_mem(u16 *variable_name, const efi_guid_t *vendor, u32 
*attributes,
-efi_uintn_t *data_size, void *data, u64 *timep);
+efi_get_variable_mem(const u16 *variable_name, const efi_guid_t *vendor,
+u32 *attributes, efi_uintn_t *data_size, void *data,
+u64 *timep);

 /**
  * efi_get_variable_runtime() - runtime implementation of GetVariable()
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 401acf3d4f..beb224f66a 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1359,7 +1359,7 @@ static efi_status_t efi_append_scrtm_version(struct 
udevice *dev)
  * Return: status code
  */
 static efi_status_t tcg2_measure_variable(struct udevice *dev, u32 pcr_index,
- u32 event_type, u16 *var_name,
+ u32 event_type, const u16 *var_name,
  const efi_guid_t *guid,
  efi_uintn_t data_size, u8 *data)
 {
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index a00bbf1620..e179932124 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -374,7 +374,8 @@ bool efi_secure_boot_enabled(void)
return efi_secure_boot;
 }

-enum efi_auth_var_type efi_auth_var_get_type(u16 *name, const efi_guid_t *guid)
+enum efi_auth_var_type efi_auth_var_get_type(const u16 *name,
+const efi_guid_t 

[PATCH 0/4] efi_loader: centralize known vendor GUIDs

2021-09-11 Thread Heinrich Schuchardt
The UEFI specification defines which vendor GUIDs should be used for
predefined variables like 'PK'. Currently we have multiple places
where this relationship is stored.

With this patch series a function for retrieving the GUID is provided
and existing code is adjusted to used it.

Heinrich Schuchardt (4):
  efi_loader: treat UEFI variable name as const
  efi_loader: function to get GUID for variable name
  efi_loader: simplify efi_sigstore_parse_sigdb()
  efi_loader: simplify tcg2_measure_secure_boot_variable()

 include/efi_loader.h  |  2 +-
 include/efi_variable.h| 24 +++--
 lib/efi_loader/efi_signature.c| 35 ++-
 lib/efi_loader/efi_tcg2.c | 31 +--
 lib/efi_loader/efi_var_common.c   | 14 +++--
 lib/efi_loader/efi_var_mem.c  |  7 ---
 lib/efi_loader/efi_variable.c |  9 
 lib/efi_loader/efi_variable_tee.c | 16 --
 8 files changed, 70 insertions(+), 68 deletions(-)

--
2.30.2