Re: [PATCH] pci: Fix configuring io/memory base and limit registers of PCI bridges

2021-09-19 Thread Stefan Roese 

Added Bin to cc.

On 10.09.21 13:33, Pali Rohár wrote:

Lower 4 bits of PCI_MEMORY_BASE and PCI_MEMORY_LIMIT registers are reserved
and should be zero. So do not set them to non-zero value.

Lower 4 bits of PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT registers
contain information if 64-bit memory addressing is supported. So preserve
this information when overwriting these registers.

Lower 4 bits of PCI_IO_BASE and PCI_IO_LIMIT register contain information
if 32-bit io addressing is supported. So preserve this information and do
not try to configure 32-bit io addressing (via PCI_IO_BASE_UPPER16 and
PCI_IO_LIMIT_UPPER16 registers) when it is unsupported.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/pci/pci_auto.c | 39 +--
  1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index b128a05dd380..7b6e629cae70 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -165,6 +165,7 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
struct pci_region *pci_prefetch;
struct pci_region *pci_io;
u16 cmdstat, prefechable_64;
+   u8 io_32;
struct udevice *ctlr = pci_get_controller(dev);
struct pci_controller *ctlr_hose = dev_get_uclass_priv(ctlr);
  
@@ -175,6 +176,8 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, int sub_bus)

dm_pci_read_config16(dev, PCI_COMMAND, );
dm_pci_read_config16(dev, PCI_PREF_MEMORY_BASE, _64);
prefechable_64 &= PCI_PREF_RANGE_TYPE_MASK;
+   dm_pci_read_config8(dev, PCI_IO_LIMIT, _32);
+   io_32 &= PCI_IO_RANGE_TYPE_MASK;
  
  	/* Configure bus number registers */

dm_pci_write_config8(dev, PCI_PRIMARY_BUS,
@@ -191,7 +194,8 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
 * I/O space
 */
dm_pci_write_config16(dev, PCI_MEMORY_BASE,
- (pci_mem->bus_lower & 0xfff0) >> 16);
+ ((pci_mem->bus_lower & 0xfff0) >> 16) 
&
+ PCI_MEMORY_RANGE_MASK);
  
  		cmdstat |= PCI_COMMAND_MEMORY;

}
@@ -205,7 +209,8 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
 * I/O space
 */
dm_pci_write_config16(dev, PCI_PREF_MEMORY_BASE,
-   (pci_prefetch->bus_lower & 0xfff0) >> 16);
+   (((pci_prefetch->bus_lower & 0xfff0) >> 16) 
&
+   PCI_PREF_RANGE_MASK) | prefechable_64);
if (prefechable_64 == PCI_PREF_RANGE_TYPE_64)
  #ifdef CONFIG_SYS_PCI_64BIT
dm_pci_write_config32(dev, PCI_PREF_BASE_UPPER32,
@@ -217,8 +222,10 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
cmdstat |= PCI_COMMAND_MEMORY;
} else {
/* We don't support prefetchable memory for now, so disable */
-   dm_pci_write_config16(dev, PCI_PREF_MEMORY_BASE, 0x1000);
-   dm_pci_write_config16(dev, PCI_PREF_MEMORY_LIMIT, 0x0);
+   dm_pci_write_config16(dev, PCI_PREF_MEMORY_BASE, 0x1000 |
+   prefechable_64);
+   dm_pci_write_config16(dev, PCI_PREF_MEMORY_LIMIT, 0x0 |
+   prefechable_64);
if (prefechable_64 == PCI_PREF_RANGE_TYPE_64) {
dm_pci_write_config16(dev, PCI_PREF_BASE_UPPER32, 0x0);
dm_pci_write_config16(dev, PCI_PREF_LIMIT_UPPER32, 0x0);
@@ -230,8 +237,10 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
pciauto_region_align(pci_io, 0x1000);
  
  		dm_pci_write_config8(dev, PCI_IO_BASE,

-(pci_io->bus_lower & 0xf000) >> 8);
-   dm_pci_write_config16(dev, PCI_IO_BASE_UPPER16,
+(((pci_io->bus_lower & 0xf000) >> 8) &
+PCI_IO_RANGE_MASK) | io_32);
+   if (io_32 == PCI_IO_RANGE_TYPE_32)
+   dm_pci_write_config16(dev, PCI_IO_BASE_UPPER16,
  (pci_io->bus_lower & 0x) >> 16);
  
  		cmdstat |= PCI_COMMAND_IO;

@@ -261,7 +270,8 @@ void dm_pciauto_postscan_setup_bridge(struct udevice *dev, 
int sub_bus)
pciauto_region_align(pci_mem, 0x10);
  
  		dm_pci_write_config16(dev, PCI_MEMORY_LIMIT,

- (pci_mem->bus_lower - 1) >> 16);
+ ((pci_mem->bus_lower - 1) >> 16) &
+ PCI_MEMORY_RANGE_MASK);
}
  
  	if (pci_prefetch) {

@@ -275,7

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

2021-09-19 Thread Stefan Roese 

On 11.09.21 21:11, Sean Anderson wrote:

reset_*_bulk expects a real pointer.

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


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---

  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;
}




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

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

2021-09-19 Thread Stefan Roese 

On 20.09.21 01:07, Sean Anderson wrote:

Is it possible to get this in 2020.10?


Let me check, if I can find my time machine somewhere. ;)

But yes, v2021.10 should be possible. I'm just back from vacation and
will look into the new patches very soon.

Thanks,
Stefan

Meng's patch breaks boards which 
use this watchdog.


--Sean

On 9/11/21 3:11 PM, Sean Anderson wrote:

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 int    clk_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;
  }




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH] arm: orion5x: edminiv2: change maintainer

2021-09-19 Thread Stefan Roese 

On 15.09.21 15:01, Simon Guinot wrote:

Since Albert Aribaud is not maintaining anymore the LaCie Ethernet Disk
mini V2 board, then I am taking over.

Signed-off-by: Simon Guinot 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/LaCie/edminiv2/MAINTAINERS | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/LaCie/edminiv2/MAINTAINERS b/board/LaCie/edminiv2/MAINTAINERS
index e0591f4b80e1..055afd0e766f 100644
--- a/board/LaCie/edminiv2/MAINTAINERS
+++ b/board/LaCie/edminiv2/MAINTAINERS
@@ -1,5 +1,5 @@
  EDMINIV2 BOARD
-M: Albert ARIBAUD 
+M: Simon Guinot 
  S:Maintained
  F:board/LaCie/edminiv2/
  F:include/configs/edminiv2.h




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH 10/11] sandbox: mmc: Support a backing file

2021-09-19 Thread Simon Glass 
Hi Tom,

On Sat, 18 Sept 2021 at 10:31, Simon Glass  wrote:
>
> Hi Tom,
>
> On Sat, 18 Sept 2021 at 07:16, Tom Rini  wrote:
> >
> > On Sat, Sep 18, 2021 at 03:34:54AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 16 Sept 2021 at 12:40, Tom Rini  wrote:
> > > >
> > > > On Wed, Aug 18, 2021 at 09:40:32PM -0600, Simon Glass wrote:
> > > >
> > > > > Provide a way for sandbox MMC to present data from a backing file. 
> > > > > This
> > > > > allows a filesystem to be created on the host and easily served via an
> > > > > emulated mmc device.
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > > > Reviewed-by: Jaehoon Chung 
> > > > > ---
> > > > >
> > > > >  doc/device-tree-bindings/mmc/sandbox,mmc.txt | 18 
> > > > >  drivers/mmc/sandbox_mmc.c| 46 
> > > > > 
> > > > >  2 files changed, 55 insertions(+), 9 deletions(-)
> > > > >  create mode 100644 doc/device-tree-bindings/mmc/sandbox,mmc.txt
> > > >
> > > > As is, this breaks how I've always run pytests on sandbox.
> > >
> > > How does it break it? Do you get an error? The feature is supposed to
> > > be optional.
> >
> > Without doing anything to enable it, a few of the mmc unit tests failed.
> > I don't have the logs handy right now (I made that sometimes bad
> > decision to test 2 series at once, and now I'm waiting a bit more on
> > final feedback on the changes the timestamp cleanup needed before I push
> > that + the rest of this series).
>
> Oh dear, I will take a look and see what is going on there.

The problem seems to me something going wrong with malloc(). I'm not
really sure what but I have seen it before. Basically the mallinfo
struct becomes corrupted somehow and from there everything goes
haywire. It actually happens today in normal operation, but somehow it
doesn't cause problems. I looked at it a while back and did not make
progress.

Anyway I will see if I can dig into it again.

Regards,
Simon

Re: [PATCH 5/5] doc: board: apple: Add Apple M1 documentation

2021-09-19 Thread Simon Glass 
On Sat, 18 Sept 2021 at 07:56, Mark Kettenis  wrote:
>
> Provide preliminary instructions on how to get U-Boot to run on
> Apple Silicon Macs.
>
> Signed-off-by: Mark Kettenis 
> ---
>  doc/board/apple/index.rst |  9 +++
>  doc/board/apple/m1.rst| 56 +++
>  doc/board/index.rst   |  1 +
>  3 files changed, 66 insertions(+)
>  create mode 100644 doc/board/apple/index.rst
>  create mode 100644 doc/board/apple/m1.rst

Reviewed-by: Simon Glass

Re: [PATCH 4/5] arm: dts: apple: Add preliminary device trees

2021-09-19 Thread Simon Glass 
On Sat, 18 Sept 2021 at 07:56, Mark Kettenis  wrote:
>
> Add preliminary device trees for the Apple M1 mini (2020) and
> Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> the Apple M1 SoC are still being formalized and these device
> trees will be synchronized with the Linux kernel as needed.
>
> These device trees are provided as a reference only as U-Boot
> uses the device tree passed by the m1n1 bootloader.
>
> Signed-off-by: Mark Kettenis 
> ---
>  arch/arm/dts/t8103-j274.dts   | 135 +
>  arch/arm/dts/t8103-j293.dts   |  97 
>  arch/arm/dts/t8103.dtsi   | 506 ++
>  .../interrupt-controller/apple-aic.h  |  15 +
>  include/dt-bindings/pinctrl/apple.h   |  13 +
>  include/dt-bindings/spmi/spmi.h   |  10 +
>  6 files changed, 776 insertions(+)
>  create mode 100644 arch/arm/dts/t8103-j274.dts
>  create mode 100644 arch/arm/dts/t8103-j293.dts
>  create mode 100644 arch/arm/dts/t8103.dtsi
>  create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h
>  create mode 100644 include/dt-bindings/pinctrl/apple.h
>  create mode 100644 include/dt-bindings/spmi/spmi.h

Reviewed-by: Simon Glass

Re: [PATCH 3/5] misc: Add Apple DART driver

2021-09-19 Thread Simon Glass 
Hi Mark,

On Sat, 18 Sept 2021 at 07:55, Mark Kettenis  wrote:
>
> The DART is an IOMMU that is used on Apple's M1 SoC.  This driver
> supports the DART in bypass mode as well as in a mode where it
> creates a 1:1 mapping of a subset of RAM as not all DARTs support
> bypass mode.  The USB3 ports integrated on the SoC use a DART
> that supports bypass mode.  The 1:1 mapping will be used in the
> future to support other devices such as the PCIe host bridge
> of the M1 SoC.
>
> Signed-off-by: Mark Kettenis 
> ---
>  drivers/misc/Kconfig  |   7 ++
>  drivers/misc/Makefile |   1 +
>  drivers/misc/apple_dart.c | 171 ++
>  3 files changed, 179 insertions(+)
>  create mode 100644 drivers/misc/apple_dart.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 997b713221..d70b060e74 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -38,6 +38,13 @@ config ALTERA_SYSID
>   Select this to enable a sysid for Altera devices. Please find
>   details on the "Embedded Peripherals IP User Guide" of Altera.
>
> +config APPLE_DART
> +   bool "Apple DART support"
> +   depends on MISC && ARCH_APPLE
> +   default y
> +   help
> + Enable support for the DART on Apple SoCs.

Should have at least 3 lines. E.g. what does DART stand for, what does
it do and what does the driver support?

> +
>  config ATSHA204A
> bool "Support for Atmel ATSHA204A module"
> depends on MISC
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index b64cd2a4de..f666cd392d 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -29,6 +29,7 @@ endif
>  endif
>  obj-$(CONFIG_ALI152X) += ali512x.o
>  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
> +obj-$(CONFIG_APPLE_DART) += apple_dart.o
>  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
>  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
>  obj-$(CONFIG_DS4510)  += ds4510.o
> diff --git a/drivers/misc/apple_dart.c b/drivers/misc/apple_dart.c
> new file mode 100644
> index 00..f619a624d0
> --- /dev/null
> +++ b/drivers/misc/apple_dart.c
> @@ -0,0 +1,171 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021 Mark Kettenis 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DART_PARAMS2   0x0004
> +#define  DART_PARAMS2_BYPASS_SUPPORT   BIT(0)
> +#define DART_TLB_OP0x0020
> +#define  DART_TLB_OP_OPMASK(0xfff << 20)
> +#define  DART_TLB_OP_FLUSH (0x001 << 20)
> +#define  DART_TLB_OP_BUSY  BIT(2)
> +#define DART_TLB_OP_SIDMASK0x0034
> +#define DART_ERROR_STATUS  0x0040
> +#define DART_TCR(sid)  (0x0100 + 4 * (sid))
> +#define  DART_TCR_TRANSLATE_ENABLE BIT(7)
> +#define  DART_TCR_BYPASS_DART  BIT(8)
> +#define  DART_TCR_BYPASS_DAPF  BIT(12)
> +#define DART_TTBR(sid, idx)(0x0200 + 16 * (sid) + 4 * (idx))
> +#define  DART_TTBR_VALID   BIT(31)
> +#define  DART_TTBR_SHIFT   12
> +
> +struct apple_dart_priv {

How about s/apple_dart/dart/ ?

It makes the code easier to read.

> +   struct clk_bulk clks;
> +   void *base;
> +};
> +
> +dma_addr_t apple_dart_bus_start;
> +phys_addr_t apple_dart_phys_start;
> +phys_size_t apple_dart_size = SZ_512M;

Try to avoid variables in drivers. Can these go in a priv struct?

> +
> +static void apple_dart_flush_tlb(struct apple_dart_priv *priv)

comments on these functions

> +{
> +   u32 status;
> +
> +   writel(0x, priv->base + DART_TLB_OP_SIDMASK);
> +   writel(DART_TLB_OP_FLUSH, priv->base + DART_TLB_OP);
> +
> +   for (;;) {
> +   status = readl(priv->base + DART_TLB_OP);
> +   if ((status & DART_TLB_OP_OPMASK) == 0)
> +   break;
> +   if ((status & DART_TLB_OP_BUSY) == 0)
> +   break;
> +   }
> +}
> +
> +static int apple_dart_clk_init(struct udevice *dev,
> +  struct apple_dart_priv *priv)
> +{
> +   int ret;
> +
> +   ret = clk_get_bulk(dev, >clks);
> +   if (ret == -ENOSYS || ret == -ENOENT)

Does -ENOSYS not indicate an error? If it doesn't, I think a comment
would help here.

> +   return 0;
> +   if (ret)
> +   return ret;
> +
> +   ret = clk_enable_bulk(>clks);
> +   if (ret) {
> +   clk_release_bulk(>clks);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +static int apple_dart_bind(struct udevice *dev)
> +{
> +   void *base;
> +   int sid, i;
> +
> +   base = dev_read_addr_ptr(dev);
> +   if (!base)
> +   return -EINVAL;
> +
> +   u32 params2 = readl(base + DART_PARAMS2);
> +   if (params2 & DART_PARAMS2_BYPASS_SUPPORT) {
> +   for (sid = 0; sid < 16; sid++) {
> +   writel(DART_TCR_BYPASS_DART | DART_TCR_BYPASS_DAPF,
> +  base +

Re: [PATCH 2/5] serial: s5p: Add Apple M1 support

2021-09-19 Thread Simon Glass 
Hi Mark,

On Sat, 18 Sept 2021 at 07:55, Mark Kettenis  wrote:
>
> Apple M1 SoCs include an S5L UART which is a variant of the S5P
> UART.  Add support for this variant and enable it by default
> on Apple SoCs.
>
> Signed-off-by: Mark Kettenis 
> ---
>  arch/arm/include/asm/arch-m1/clk.h  | 11 
>  arch/arm/include/asm/arch-m1/uart.h | 41 +
>  arch/arm/mach-apple/board.c |  5 
>  drivers/serial/Kconfig  |  2 +-
>  drivers/serial/serial_s5p.c | 22 
>  5 files changed, 80 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-m1/clk.h
>  create mode 100644 arch/arm/include/asm/arch-m1/uart.h
>
> diff --git a/arch/arm/include/asm/arch-m1/clk.h 
> b/arch/arm/include/asm/arch-m1/clk.h
> new file mode 100644
> index 00..f4326d0c0f
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-m1/clk.h
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021 Mark Kettenis 
> + */
> +
> +#ifndef __ASM_ARM_ARCH_CLK_H_
> +#define __ASM_ARM_ARCH_CLK_H_
> +
> +unsigned long get_uart_clk(int dev_index);

comment? But this should be in a clock driver, unless you are trying
to get a debug UART up ASAP with minimal code?

> +
> +#endif
> diff --git a/arch/arm/include/asm/arch-m1/uart.h 
> b/arch/arm/include/asm/arch-m1/uart.h
> new file mode 100644
> index 00..d2a17a221e
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-m1/uart.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * (C) Copyright 2009 Samsung Electronics
> + * Minkyu Kang 
> + * Heungjun Kim 
> + */
> +
> +#ifndef __ASM_ARCH_UART_H_
> +#define __ASM_ARCH_UART_H_
> +
> +#ifndef __ASSEMBLY__
> +/* baudrate rest value */
> +union br_rest {
> +   unsigned short  slot;   /* udivslot */
> +   unsigned char   value;  /* ufracval */
> +};
> +
> +struct s5p_uart {
> +   unsigned intulcon;
> +   unsigned intucon;
> +   unsigned intufcon;
> +   unsigned intumcon;
> +   unsigned intutrstat;
> +   unsigned intuerstat;
> +   unsigned intufstat;
> +   unsigned intumstat;
> +   unsigned intutxh;
> +   unsigned inturxh;
> +   unsigned intubrdiv;
> +   union br_rest   rest;
> +   unsigned char   res3[0x3fd0];
> +};
> +
> +static inline int s5p_uart_divslot(void)
> +{
> +   return 0;
> +}
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index 0c8b35292e..8bc5c2f69e 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -156,3 +156,8 @@ ulong board_get_usable_ram_top(ulong total_size)
>  */
> return 0x98000;
>  }
> +
> +unsigned long get_uart_clk(int dev_index)
> +{
> +   return 2400;

Should add to devicetree for the driver

> +}
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index 93348c0929..c3ac773929 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -719,7 +719,7 @@ config ROCKCHIP_SERIAL
>
>  config S5P_SERIAL
> bool "Support for Samsung S5P UART"
> -   depends on ARCH_EXYNOS || ARCH_S5PC1XX
> +   depends on ARCH_APPLE || ARCH_EXYNOS || ARCH_S5PC1XX
> default y
> help
>   Select this to enable Samsung S5P UART support.
> diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
> index 6d09952a5d..eb770d9b62 100644
> --- a/drivers/serial/serial_s5p.c
> +++ b/drivers/serial/serial_s5p.c
> @@ -21,12 +21,21 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +#ifdef CONFIG_ARCH_APPLE

This should use the compatible string to decide which variant it is,
then the checks happen at runtime. We should never have arch-specific
#ifdefs in drivers.

> +#define RX_FIFO_COUNT_SHIFT0
> +#define RX_FIFO_COUNT_MASK (0xf << RX_FIFO_COUNT_SHIFT)
> +#define RX_FIFO_FULL   (1 << 8)
> +#define TX_FIFO_COUNT_SHIFT4
> +#define TX_FIFO_COUNT_MASK (0xf << TX_FIFO_COUNT_SHIFT)
> +#define TX_FIFO_FULL   (1 << 9)
> +#else
>  #define RX_FIFO_COUNT_SHIFT0
>  #define RX_FIFO_COUNT_MASK (0xff << RX_FIFO_COUNT_SHIFT)
>  #define RX_FIFO_FULL   (1 << 8)
>  #define TX_FIFO_COUNT_SHIFT16
>  #define TX_FIFO_COUNT_MASK (0xff << TX_FIFO_COUNT_SHIFT)
>  #define TX_FIFO_FULL   (1 << 24)
> +#endif
>
>  /* Information about a serial port */
>  struct s5p_serial_plat {
> @@ -83,7 +92,11 @@ static void __maybe_unused s5p_serial_baud(struct s5p_uart 
> *uart, uint uclk,
> if (s5p_uart_divslot())
> writew(udivslot[val % 16], >rest.slot);
> else
> +#ifdef CONFIG_ARCH_APPLE
> +   writel(val % 16, >rest.value);
> +#else
> writeb(val % 16, >rest.value);
> +#endif
>  }
>
>  #ifndef CONFIG_SPL_BUILD
> @@ -148,7 +161,11 @@ static int s5p_serial_getc(struct udevice *dev)
> return -EAGAIN;
>
>

Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

2021-09-19 Thread Simon Glass 
Hi Mark,

On Sat, 18 Sept 2021 at 07:55, Mark Kettenis  wrote:
>
> Add support for Apple's M1 SoC that is used in "Apple Silicon"
> Macs.  This builds a basic U-Boot that can be used as a payload
> for the m1n1 boot loader being developed by the Asahi Linux
> project.
>
> Signed-off-by: Mark Kettenis 
> ---
>  arch/arm/Kconfig|  22 
>  arch/arm/Makefile   |   1 +
>  arch/arm/mach-apple/Kconfig |  18 
>  arch/arm/mach-apple/Makefile|   4 +
>  arch/arm/mach-apple/board.c | 158 
>  arch/arm/mach-apple/lowlevel_init.S |  16 +++
>  configs/apple_m1_defconfig  |  14 +++
>  include/configs/apple.h |  38 +++
>  8 files changed, 271 insertions(+)
>  create mode 100644 arch/arm/mach-apple/Kconfig
>  create mode 100644 arch/arm/mach-apple/Makefile
>  create mode 100644 arch/arm/mach-apple/board.c
>  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
>  create mode 100644 configs/apple_m1_defconfig
>  create mode 100644 include/configs/apple.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5bd3284cd..7cdea1f615 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -895,6 +895,26 @@ config ARCH_NEXELL
> select DM
> select GPIO_EXTRA_HEADER
>
> +config ARCH_APPLE
> +   bool "Apple SoCs"
> +   select ARM64
> +   select LINUX_KERNEL_IMAGE_HEADER
> +   select POSITION_INDEPENDENT
> +   select BLK
> +   select DM
> +   select DM_KEYBOARD
> +   select DM_SERIAL
> +   select DM_USB
> +   select DM_VIDEO
> +   select CMD_USB
> +   select MISC
> +   select OF_CONTROL
> +   select OF_BOARD
> +   select USB
> +   imply CMD_DM
> +   imply CMD_GPT
> +   imply DISTRO_DEFAULTS

Suggest sorting these

> +
>  config ARCH_OWL
> bool "Actions Semi OWL SoCs"
> select DM
> @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
>   image headers.
>  endif
>
> +source "arch/arm/mach-apple/Kconfig"
> +
>  source "arch/arm/mach-aspeed/Kconfig"
>
>  source "arch/arm/mach-at91/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c68e598a67..44178c204b 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
>
>  # Machine directory name.  This list is sorted alphanumerically
>  # by CONFIG_* macro name.
> +machine-$(CONFIG_ARCH_APPLE)   += apple
>  machine-$(CONFIG_ARCH_ASPEED)  += aspeed
>  machine-$(CONFIG_ARCH_AT91)+= at91
>  machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> new file mode 100644
> index 00..66cab91b2a
> --- /dev/null
> +++ b/arch/arm/mach-apple/Kconfig
> @@ -0,0 +1,18 @@
> +if ARCH_APPLE
> +
> +config SYS_TEXT_BASE
> +   default 0x
> +
> +config SYS_CONFIG_NAME
> +   default "apple"
> +
> +config SYS_SOC
> +   default "m1"
> +
> +config SYS_MALLOC_LEN
> +   default 0x400
> +
> +config SYS_MALLOC_F_LEN
> +   default 0x4000
> +
> +endif
> diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> new file mode 100644
> index 00..e74a8c9df1
> --- /dev/null
> +++ b/arch/arm/mach-apple/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +obj-y += board.o
> +obj-y += lowlevel_init.o
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> new file mode 100644
> index 00..0c8b35292e
> --- /dev/null
> +++ b/arch/arm/mach-apple/board.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2021 Mark Kettenis 
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static struct mm_region apple_mem_map[] = {
> +   {
> +   /* I/O */
> +   .virt = 0x2,
> +   .phys = 0x2,
> +   .size = 8UL * SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +PTE_BLOCK_NON_SHARE |
> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x5,
> +   .phys = 0x5,
> +   .size = 2UL * SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +PTE_BLOCK_NON_SHARE |
> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x68000,
> +   .phys = 0x68000,
> +   .size = SZ_512M,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +PTE_BLOCK_NON_SHARE |
> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* PCIE */
> +   .virt = 0x6a000,
> +   .phys = 0x6a000,
> +

[PATCH v6 10/11] vpl: Add Kconfig options for VPL

2021-09-19 Thread Simon Glass 
Add VPL versions of commonly used Kconfig options.

Signed-off-by: Simon Glass 
---

(no changes since v5)

Changes in v5:
- Rebase this patch on mainline (for GPIO and MISC Kconfig renames)

Changes in v4:
- Add options for blk, core, misc and tpl also
- Add VPL_SIZE_LIMIT

 Kconfig  |  10 ++
 common/Kconfig   |  67 +
 common/spl/Kconfig   | 202 +++
 drivers/block/Kconfig|  12 +++
 drivers/clk/Kconfig  |  10 ++
 drivers/core/Kconfig |  33 +++
 drivers/core/Makefile|   2 +-
 drivers/gpio/Kconfig |  11 +++
 drivers/i2c/Kconfig  |  11 +++
 drivers/misc/Kconfig |  28 ++
 drivers/pinctrl/Kconfig  |  18 +++-
 drivers/rtc/Kconfig  |   9 ++
 drivers/serial/Kconfig   |  20 
 drivers/sysreset/Kconfig |  10 ++
 drivers/timer/Kconfig|  10 ++
 drivers/tpm/Kconfig  |  30 ++
 dts/Kconfig  |   9 ++
 lib/Kconfig  |  62 
 18 files changed, 551 insertions(+), 3 deletions(-)

diff --git a/Kconfig b/Kconfig
index a6c42b902f7..60af7da0e78 100644
--- a/Kconfig
+++ b/Kconfig
@@ -279,6 +279,16 @@ config TPL_SYS_MALLOC_F_LEN
  particular needs this to operate, so that it can allocate the
  initial serial device and any others that are needed.
 
+config VPL_SYS_MALLOC_F_LEN
+   hex "Size of malloc() pool in VPL before relocation"
+   depends on SYS_MALLOC_F && VPL
+   default SYS_MALLOC_F_LEN
+   help
+ Before relocation, memory is very limited on many platforms. Still,
+ we can provide a small malloc() pool if needed. Driver model in
+ particular needs this to operate, so that it can allocate the
+ initial serial device and any others that are needed.
+
 menuconfig EXPERT
bool "Configure standard U-Boot features (expert users)"
default y
diff --git a/common/Kconfig b/common/Kconfig
index f87fb5b426e..88b82c1c5e7 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -81,6 +81,15 @@ config TPL_LOGLEVEL
int
default LOGLEVEL
 
+config VPL_LOGLEVEL
+   int "loglevel for VPL"
+   default LOGLEVEL
+   help
+ All Messages with a loglevel smaller than the console loglevel will
+ be compiled in to VPL. See LOGLEVEL for a list of available log
+ levels. Setting this to a value above 4 may increase the code size
+ significantly.
+
 config SILENT_CONSOLE
bool "Support a silent console"
help
@@ -254,6 +263,15 @@ config LOG
 
 if LOG
 
+config VPL_LOG
+   bool "Enable logging support in VPL"
+   depends on LOG
+   help
+ This enables support for logging of status and debug messages. These
+ can be displayed on the console, recorded in a memory buffer, or
+ discarded if not needed. Logging supports various categories and
+ levels of severity.
+
 config LOG_MAX_LEVEL
int "Maximum log level to record"
default 6
@@ -423,6 +441,47 @@ config TPL_LOG_CONSOLE
 
 endif
 
+config VPL_LOG
+   bool "Enable logging support in VPL"
+   depends on LOG
+   help
+ This enables support for logging of status and debug messages. These
+ can be displayed on the console, recorded in a memory buffer, or
+ discarded if not needed. Logging supports various categories and
+ levels of severity.
+
+if VPL_LOG
+
+config VPL_LOG_MAX_LEVEL
+   int "Maximum log level to record in VPL"
+   default 3
+   help
+ This selects the maximum log level that will be recorded. Any value
+ higher than this will be ignored. If possible log statements below
+ this level will be discarded at build time. Levels:
+
+   0 - emergency
+   1 - alert
+   2 - critical
+   3 - error
+   4 - warning
+   5 - note
+   6 - info
+   7 - debug
+   8 - debug content
+   9 - debug hardware I/O
+
+config VPL_LOG_CONSOLE
+   bool "Allow log output to the console in VPL"
+   default y
+   help
+ Enables a log driver which writes log records to the console.
+ Generally the console is the serial port or LCD display. Only the
+ log message is shown - other details like level, category, file and
+ line number are omitted.
+
+endif
+
 config LOG_ERROR_RETURN
bool "Log all functions which return an error"
help
@@ -718,6 +777,14 @@ config TPL_BLOBLIST
  This enables a bloblist in TPL. The bloblist is set up in TPL and
  passed to SPL and U-Boot proper.
 
+config VPL_BLOBLIST
+   bool "Support for a bloblist in VPL"
+   depends on BLOBLIST && VPL_LIBGENERIC_SUPPORT && VPL_LIBCOMMON_SUPPORT
+   default y if VPL
+   help
+ This enables a bloblist in VPL. The bloblist is set up in VPL and
+ passed to SPL and U-Boot proper.
+
 config BLOBLIST_SIZE
hex "Size of bloblist"

[PATCH v6 08/11] binman: Add VPL support

2021-09-19 Thread Simon Glass 
Add support for U-Boot's Verifying Program Loader phase.

Signed-off-by: Simon Glass 
---

Changes in v6:
- Fix the missing SPDX tag on test/204...

 tools/binman/etype/u_boot_vpl.py   |  42 
 tools/binman/etype/u_boot_vpl_bss_pad.py   |  44 +
 tools/binman/etype/u_boot_vpl_dtb.py   |  28 ++
 tools/binman/etype/u_boot_vpl_expanded.py  |  45 +
 tools/binman/etype/u_boot_vpl_nodtb.py |  42 
 tools/binman/ftest.py  | 109 +
 tools/binman/state.py  |   3 +-
 tools/binman/test/082_fdt_update_all.dts   |   2 +
 tools/binman/test/201_u_boot_vpl.dts   |  11 +++
 tools/binman/test/202_u_boot_vpl_nodtb.dts |  13 +++
 tools/binman/test/203_fdt_incl_vpl.dts |  13 +++
 tools/binman/test/204_vpl_bss_pad.dts  |  19 
 12 files changed, 349 insertions(+), 22 deletions(-)
 create mode 100644 tools/binman/etype/u_boot_vpl.py
 create mode 100644 tools/binman/etype/u_boot_vpl_bss_pad.py
 create mode 100644 tools/binman/etype/u_boot_vpl_dtb.py
 create mode 100644 tools/binman/etype/u_boot_vpl_expanded.py
 create mode 100644 tools/binman/etype/u_boot_vpl_nodtb.py
 create mode 100644 tools/binman/test/201_u_boot_vpl.dts
 create mode 100644 tools/binman/test/202_u_boot_vpl_nodtb.dts
 create mode 100644 tools/binman/test/203_fdt_incl_vpl.dts
 create mode 100644 tools/binman/test/204_vpl_bss_pad.dts

diff --git a/tools/binman/etype/u_boot_vpl.py b/tools/binman/etype/u_boot_vpl.py
new file mode 100644
index 000..9daaca4f6fd
--- /dev/null
+++ b/tools/binman/etype/u_boot_vpl.py
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2016 Google, Inc
+# Written by Simon Glass 
+#
+# Entry-type module for vpl/u-boot-vpl.bin
+#
+
+from binman import elf
+from binman.entry import Entry
+from binman.etype.blob import Entry_blob
+
+class Entry_u_boot_vpl(Entry_blob):
+"""U-Boot VPL binary
+
+Properties / Entry arguments:
+- filename: Filename of u-boot-vpl.bin (default 'vpl/u-boot-vpl.bin')
+
+This is the U-Boot VPL (Verifying Program Loader) binary. This is a small
+binary which loads before SPL, typically into on-chip SRAM. It is
+responsible for locating, loading and jumping to SPL, the next-stage
+loader. Note that VPL is not relocatable so must be loaded to the correct
+address in SRAM, or written to run from the correct address if direct
+flash execution is possible (e.g. on x86 devices).
+
+SPL can access binman symbols at runtime. See:
+
+'Access to binman entry offsets at run time (symbols)'
+
+in the binman README for more information.
+
+The ELF file 'vpl/u-boot-vpl' must also be available for this to work, 
since
+binman uses that to look up symbols to write into the VPL binary.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node)
+self.elf_fname = 'vpl/u-boot-vpl'
+
+def GetDefaultFilename(self):
+return 'vpl/u-boot-vpl.bin'
+
+def WriteSymbols(self, section):
+elf.LookupAndWriteSymbols(self.elf_fname, self, section.GetImage())
diff --git a/tools/binman/etype/u_boot_vpl_bss_pad.py 
b/tools/binman/etype/u_boot_vpl_bss_pad.py
new file mode 100644
index 000..073833b3d0d
--- /dev/null
+++ b/tools/binman/etype/u_boot_vpl_bss_pad.py
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2021 Google LLC
+# Written by Simon Glass 
+#
+# Entry-type module for BSS padding for vpl/u-boot-vpl.bin. This padding
+# can be added after the VPL binary to ensure that anything concatenated
+# to it will appear to VPL to be at the end of BSS rather than the start.
+#
+
+from binman import elf
+from binman.entry import Entry
+from binman.etype.blob import Entry_blob
+from patman import tools
+
+class Entry_u_boot_vpl_bss_pad(Entry_blob):
+"""U-Boot VPL binary padded with a BSS region
+
+Properties / Entry arguments:
+None
+
+This holds the padding added after the VPL binary to cover the BSS (Block
+Started by Symbol) region. This region holds the various variables used by
+VPL. It is set to 0 by VPL when it starts up. If you want to append data to
+the VPL image (such as a device tree file), you must pad out the BSS region
+to avoid the data overlapping with U-Boot variables. This entry is useful 
in
+that case. It automatically pads out the entry size to cover both the code,
+data and BSS.
+
+The contents of this entry will a certain number of zero bytes, determined
+by __bss_size
+
+The ELF file 'vpl/u-boot-vpl' must also be available for this to work, 
since
+binman uses that to look up the BSS address.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node)
+
+def ObtainContents(self):
+fname = tools.GetInputFilename('vpl/u-boot-vpl')
+bss_size = elf.GetSymbolAddress(fname, '__bss_size')
+if not

[PATCH v6 11/11] sandbox: Add a build for VPL

2021-09-19 Thread Simon Glass 
Add an initial VPL build for sandbox. This includes the flow:

   TPL (with of-platdata) -> VPL -> SPL -> U-Boot

To run it:

   ./tpl/u-boot-tpl -D

The -D is needed to get the default device tree, which includes the serial
console info.

Add a Makefile check for OF_HOSTFILE which is the option that enables
devicetree control on sandbox.

Signed-off-by: Simon Glass 
---

Changes in v6:
- Add docs for sandbox_vpl build
- Drop TPL_HASH_SUPPORT patch since we only have SPL_HASH now

Changes in v4:
- Add a sandbox_vpl build
- Update cover letter

 Makefile  |   2 +-
 arch/sandbox/Kconfig  |   8 ++
 arch/sandbox/cpu/spl.c|  12 +-
 arch/sandbox/dts/sandbox.dtsi |  10 +-
 board/sandbox/MAINTAINERS |   7 +
 configs/sandbox_vpl_defconfig | 249 ++
 doc/arch/sandbox.rst  |  13 ++
 lib/Kconfig   |   2 +-
 8 files changed, 294 insertions(+), 9 deletions(-)
 create mode 100644 configs/sandbox_vpl_defconfig

diff --git a/Makefile b/Makefile
index 21656df049b..9f1e03856b3 100644
--- a/Makefile
+++ b/Makefile
@@ -1192,7 +1192,7 @@ u-boot.bin: u-boot-fit-dtb.bin FORCE
 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
 
-else ifeq ($(CONFIG_OF_SEPARATE),y)
+else ifeq ($(CONFIG_OF_SEPARATE)$(CONFIG_OF_HOSTFILE),y)
 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
 
diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
index f83282d9d56..e504b08b951 100644
--- a/arch/sandbox/Kconfig
+++ b/arch/sandbox/Kconfig
@@ -29,6 +29,14 @@ config SANDBOX_SPL
bool "Enable SPL for sandbox"
select SUPPORT_SPL
 
+config SANDBOX_TPL
+   bool "Enable TPL for sandbox"
+   select SUPPORT_TPL
+
+config SANDBOX_VPL
+   bool "Enable VPL for sandbox"
+   select SUPPORT_VPL
+
 config SYS_CONFIG_NAME
default "sandbox_spl" if SANDBOX_SPL
default "sandbox" if !SANDBOX_SPL
diff --git a/arch/sandbox/cpu/spl.c b/arch/sandbox/cpu/spl.c
index 650bdb0a701..2f1c06903c8 100644
--- a/arch/sandbox/cpu/spl.c
+++ b/arch/sandbox/cpu/spl.c
@@ -31,13 +31,21 @@ int sandbox_find_next_phase(char *fname, int maxlen, bool 
use_img)
return 0;
 }
 
-/* SPL / TPL init function */
+/* SPL / TPL / VPL init function */
 void board_init_f(ulong flag)
 {
struct sandbox_state *state = state_get_current();
+   int ret;
 
gd->arch.ram_buf = state->ram_buf;
gd->ram_size = state->ram_size;
+
+   ret = spl_early_init();
+   if (ret) {
+   debug("spl_early_init() failed: %d\n", ret);
+   hang();
+   }
+   preloader_console_init();
 }
 
 u32 spl_boot_device(void)
@@ -74,8 +82,6 @@ void spl_board_init(void)
 {
struct sandbox_state *state = state_get_current();
 
-   preloader_console_init();
-
if (state->run_unittests) {
struct unit_test *tests = UNIT_TEST_ALL_START();
const int count = UNIT_TEST_ALL_COUNT();
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 200fcab6a41..b49fdc6d8ab 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -226,7 +226,7 @@
};
 
spl-test {
-   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
compatible = "sandbox,spl-test";
boolval;
intval = <1>;
@@ -240,7 +240,7 @@
};
 
spl-test2 {
-   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
compatible = "sandbox,spl-test";
intval = <3>;
intarray = <5>;
@@ -252,14 +252,14 @@
};
 
spl-test3 {
-   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
compatible = "sandbox,spl-test";
stringarray = "one";
maybe-empty-int = <1>;
};
 
spl-test5 {
-   u-boot,dm-tpl;
+   u-boot,dm-vpl;
compatible = "sandbox,spl-test";
stringarray = "tpl";
};
@@ -306,6 +306,8 @@
/* Needs to be available prior to relocation */
uart0: serial {
u-boot,dm-spl;
+   u-boot,dm-tpl;
+   u-boot,dm-vpl;
compatible = "sandbox,serial";
sandbox,text-colour = "cyan";
pinctrl-names = "default";
diff --git a/board/sandbox/MAINTAINERS b/board/sandbox/MAINTAINERS
index d32561cd1d0..9f5073bf287 100644
--- a/board/sandbox/MAINTAINERS
+++ b/board/sandbox/MAINTAINERS
@@ -33,3 +33,10 @@ S:   Maintained
 F: board/sandbox/
 F: include/configs/sandbox.h
 F: configs/sandbox_flattree_defconfig
+
+SANDBOX VPL BOARD
+M: Simon Glass 
+S: Maintained
+F: board/sandbox/
+F: include/configs/sandbox_spl.h
+F: configs/sandbox_vpl_defconfig
diff --git a/configs/sandbox_vpl_defconfig b/configs/sandbox_vpl_defconfig
new file mode 100644
index

[PATCH v6 07/11] Makefile: Tidy up the TPL build rules

2021-09-19 Thread Simon Glass 
These should follow the same pattern as SPL, for consistency. Fix them.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index ff5b9c3a68e..fefa75ef64b 100644
--- a/Makefile
+++ b/Makefile
@@ -2010,10 +2010,13 @@ spl/u-boot-spl.sfp: spl/u-boot-spl
 spl/boot.bin: spl/u-boot-spl
@:
 
-tpl/u-boot-tpl.bin: tools prepare $(if $(CONFIG_TPL_OF_CONTROL),dts/dt.dtb)
-   $(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all
+tpl/u-boot-tpl.bin: tpl/u-boot-tpl
+   @:
$(TPL_SIZE_CHECK)
 
+tpl/u-boot-tpl: tools prepare $(if $(CONFIG_TPL_OF_CONTROL),dts/dt.dtb)
+   $(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all
+
 TAG_SUBDIRS := $(patsubst %,$(srctree)/%,$(u-boot-dirs) include)
 
 FIND := find
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v6 09/11] Introduce Verifying Program Loader (VPL)

2021-09-19 Thread Simon Glass 
Add support for VPL, a new phase of U-Boot. This runs after TPL. It is
responsible for selecting which SPL binary to run, based on a
verified-boot process.

Signed-off-by: Simon Glass 
---

(no changes since v4)

Changes in v4:
- Update spl_phase_prefix() for VPL
- Tidy up some of the Makefile rules

Changes in v3:
- Move VPL Kconfig options to a separate patch
- Add full build support for VPL
- Add a VPL size check (Kconfig option in next patch)

Changes in v2:
- Add some more VPL Kconfig options

 Makefile  | 14 ++
 common/spl/Kconfig| 15 ++-
 common/spl/spl.c  | 25 ++---
 doc/develop/spl.rst   |  7 ++-
 drivers/Makefile  |  2 ++
 include/bootstage.h   |  2 ++
 include/linux/kconfig.h   |  3 +++
 include/spl.h | 22 +++---
 scripts/Kbuild.include|  4 
 scripts/Makefile.autoconf | 12 
 scripts/Makefile.build|  4 
 scripts/Makefile.lib  |  5 +
 scripts/Makefile.spl  | 35 ++-
 13 files changed, 133 insertions(+), 17 deletions(-)

diff --git a/Makefile b/Makefile
index fefa75ef64b..21656df049b 100644
--- a/Makefile
+++ b/Makefile
@@ -912,6 +912,12 @@ else
 TPL_SIZE_CHECK =
 endif
 
+ifneq ($(CONFIG_VPL_SIZE_LIMIT),0x0)
+VPL_SIZE_CHECK = @$(call size_check,$@,$(CONFIG_VPL_SIZE_LIMIT))
+else
+VPL_SIZE_CHECK =
+endif
+
 # Statically apply RELA-style relocations (currently arm64 only)
 # This is useful for arm64 where static relocation needs to be performed on
 # the raw binary, but certain simulators only accept an ELF file (but don't
@@ -952,6 +958,7 @@ INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
 endif
 endif
 INPUTS-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
+INPUTS-$(CONFIG_VPL) += vpl/u-boot-vpl.bin
 INPUTS-$(CONFIG_OF_SEPARATE) += u-boot.dtb
 INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
 ifeq ($(CONFIG_SPL_FRAMEWORK),y)
@@ -2017,6 +2024,13 @@ tpl/u-boot-tpl.bin: tpl/u-boot-tpl
 tpl/u-boot-tpl: tools prepare $(if $(CONFIG_TPL_OF_CONTROL),dts/dt.dtb)
$(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all
 
+vpl/u-boot-vpl.bin: vpl/u-boot-vpl
+   @:
+   $(VPL_SIZE_CHECK)
+
+vpl/u-boot-vpl: tools prepare $(if $(CONFIG_TPL_OF_CONTROL),dts/dt.dtb)
+   $(Q)$(MAKE) obj=vpl -f $(srctree)/scripts/Makefile.spl all
+
 TAG_SUBDIRS := $(patsubst %,$(srctree)/%,$(u-boot-dirs) include)
 
 FIND := find
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 29a46c47877..babbcbe9423 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1,4 +1,4 @@
-menu "SPL / TPL"
+menu "SPL / TPL / VPL"
 
 config SUPPORT_SPL
bool
@@ -6,6 +6,9 @@ config SUPPORT_SPL
 config SUPPORT_TPL
bool
 
+config SUPPORT_VPL
+   bool
+
 config SPL_DFU_NO_RESET
bool
 
@@ -290,6 +293,16 @@ config SPL_READ_ONLY
  writeable memory) of anything it wants to modify, such as
  device-private data.
 
+config TPL_SEPARATE_BSS
+   bool "BSS section is in a different memory region from text"
+   default y if SPL_SEPARATE_BSS
+   help
+ Some platforms need a large BSS region in TPL and can provide this
+ because RAM is already set up. In this case BSS can be moved to RAM.
+ This option should then be enabled so that the correct device tree
+ location is used. Normally we put the device tree at the end of BSS
+ but with this option enabled, it goes at _image_binary_end.
+
 config SPL_BANNER_PRINT
bool "Enable output of the SPL banner 'U-Boot SPL ...'"
default y
diff --git a/common/spl/spl.c b/common/spl/spl.c
index d55d3c28485..812126900ac 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -55,6 +55,11 @@ binman_sym_declare(ulong, spl, image_pos);
 binman_sym_declare(ulong, spl, size);
 #endif
 
+#ifdef CONFIG_VPL
+binman_sym_declare(ulong, vpl, image_pos);
+binman_sym_declare(ulong, vpl, size);
+#endif
+
 /* Define board data structure */
 static struct bd_info bdata __attribute__ ((section(".data")));
 
@@ -139,21 +144,33 @@ void spl_fixup_fdt(void *fdt_blob)
 
 ulong spl_get_image_pos(void)
 {
-   return spl_phase() == PHASE_TPL ?
+#ifdef CONFIG_VPL
+   if (spl_next_phase() == PHASE_VPL)
+   return binman_sym(ulong, vpl, image_pos);
+#endif
+   return spl_next_phase() == PHASE_SPL ?
binman_sym(ulong, spl, image_pos) :
binman_sym(ulong, u_boot_any, image_pos);
 }
 
 ulong spl_get_image_size(void)
 {
-   return spl_phase() == PHASE_TPL ?
+#ifdef CONFIG_VPL
+   if (spl_next_phase() == PHASE_VPL)
+   return binman_sym(ulong, vpl, size);
+#endif
+   return spl_next_phase() == PHASE_SPL ?
binman_sym(ulong, spl, size) :
binman_sym(ulong, u_boot_any, size);
 }
 
 ulong spl_get_image_text_base(void)
 {
-   return spl_phase() == PHASE_TPL ? CONFIG_SPL_TEXT_BASE :
+#ifdef CONFIG_VPL
+   if (spl_next_phase() ==

[PATCH v6 04/11] bloblist: Correct Kconfig dependencies

2021-09-19 Thread Simon Glass 
This feature is not available in SPL unless common/ and lib/ are built.
Update the Kconfig to avoid build errors.

Signed-off-by: Simon Glass 
---

(no changes since v4)

Changes in v4:
- Add new patch to correct bloblist Kconfig dependencies

 common/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index ee14d3ad5bf..f87fb5b426e 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -703,7 +703,7 @@ config BLOBLIST
 
 config SPL_BLOBLIST
bool "Support for a bloblist in SPL"
-   depends on BLOBLIST
+   depends on BLOBLIST && SPL_LIBGENERIC_SUPPORT && SPL_LIBCOMMON_SUPPORT
default y if SPL
help
  This enables a bloblist in SPL. If this is the first part of U-Boot
@@ -712,7 +712,7 @@ config SPL_BLOBLIST
 
 config TPL_BLOBLIST
bool "Support for a bloblist in TPL"
-   depends on BLOBLIST
+   depends on BLOBLIST && TPL_LIBGENERIC_SUPPORT && TPL_LIBCOMMON_SUPPORT
default y if TPL
help
  This enables a bloblist in TPL. The bloblist is set up in TPL and
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v6 05/11] avb: Don't build in SPL

2021-09-19 Thread Simon Glass 
This feature is not used in SPL at present. Update the Makefile to avoid
it being built.

Signed-off-by: Simon Glass 
---

(no changes since v4)

Changes in v4:
- Add new patch to avoid building avb in SPL

 common/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/Makefile b/common/Makefile
index ae0430c35fe..03c4a5e0e87 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -134,7 +134,7 @@ obj-y += s_record.o
 obj-$(CONFIG_CMD_LOADB) += xyzModem.o
 obj-$(CONFIG_$(SPL_TPL_)YMODEM_SUPPORT) += xyzModem.o
 
-obj-$(CONFIG_AVB_VERIFY) += avb_verify.o
+obj-$(CONFIG_$(SPL_TPL_)AVB_VERIFY) += avb_verify.o
 obj-$(CONFIG_$(SPL_TPL_)STACKPROTECTOR) += stackprot.o
 obj-$(CONFIG_SCP03) += scp03.o
 
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v6 06/11] Makefile: Simplify devicetree rules for SPL/TPL

2021-09-19 Thread Simon Glass 
The current logic checks several options to decide whether SPL/TPL need
the U-Boot devicetree to be built. In fact we can check OF_CONTROL, which
is enabled in all cases that matter.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 Makefile | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 6837487911a..ff5b9c3a68e 100644
--- a/Makefile
+++ b/Makefile
@@ -1995,9 +1995,7 @@ spl/u-boot-spl-dtb.bin: spl/u-boot-spl
 spl/u-boot-spl-dtb.hex: spl/u-boot-spl
@:
 
-spl/u-boot-spl: tools prepare \
-   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb) \
-   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
+spl/u-boot-spl: tools prepare $(if $(CONFIG_SPL_OF_CONTROL),dts/dt.dtb)
$(Q)$(MAKE) obj=spl -f $(srctree)/scripts/Makefile.spl all
 
 spl/sunxi-spl.bin: spl/u-boot-spl
@@ -2012,8 +2010,7 @@ spl/u-boot-spl.sfp: spl/u-boot-spl
 spl/boot.bin: spl/u-boot-spl
@:
 
-tpl/u-boot-tpl.bin: tools prepare \
-   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb)
+tpl/u-boot-tpl.bin: tools prepare $(if $(CONFIG_TPL_OF_CONTROL),dts/dt.dtb)
$(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all
$(TPL_SIZE_CHECK)
 
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v6 03/11] test: Tidy up test building with SPL

2021-09-19 Thread Simon Glass 
We can in principle add tests to any SPL build, e.g. TPL or VPL. Update
the build rules to handle this.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 Makefile | 2 +-
 scripts/Makefile.spl | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 3014788e14e..6837487911a 100644
--- a/Makefile
+++ b/Makefile
@@ -847,7 +847,7 @@ libs-y += drivers/usb/ulpi/
 ifdef CONFIG_POST
 libs-y += post/
 endif
-libs-$(CONFIG_UNIT_TEST) += test/
+libs-$(CONFIG_$(SPL_TPL_)UNIT_TEST) += test/
 libs-$(CONFIG_UT_ENV) += test/env/
 libs-$(CONFIG_UT_OPTEE) += test/optee/
 libs-$(CONFIG_UT_OVERLAY) += test/overlay/
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 25a3e7fa52e..44d3daaee64 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -109,7 +109,7 @@ libs-y += dts/
 libs-y += fs/
 libs-$(CONFIG_SPL_POST_MEM_SUPPORT) += post/drivers/
 libs-$(CONFIG_SPL_NET_SUPPORT) += net/
-libs-$(CONFIG_SPL_UNIT_TEST) += test/
+libs-$(CONFIG_$(SPL_TPL_)UNIT_TEST) += test/
 
 head-y := $(addprefix $(obj)/,$(head-y))
 libs-y := $(addprefix $(obj)/,$(libs-y))
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v6 02/11] doc: Expand SPL docs to explain the phase and config

2021-09-19 Thread Simon Glass 
Add a bit more information about how to use SPL.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 doc/develop/spl.rst | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst
index c7d08d22bf2..0fb1e1d9784 100644
--- a/doc/develop/spl.rst
+++ b/doc/develop/spl.rst
@@ -66,6 +66,40 @@ CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
 CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
 CONFIG_SPL_WATCHDOG (drivers/watchdog/libwatchdog.o)
 
+Adding SPL-specific code
+
+
+To check whether a feature is enabled, use CONFIG_IS_ENABLED()::
+
+  if (CONFIG_IS_ENABLED(CLK))
+  ...
+
+This checks CONFIG_CLK for the main build, CONFIG_SPL_CLK for the SPL build,
+CONFIG_TPL_CLK for the TPL build, etc.
+
+U-Boot Phases
+-
+
+U-Boot boots through the following phases:
+
+TPL
+   Very early init, as tiny as possible. This loads SPL.
+
+SPL
+   Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also
+   load other firmware components.
+
+U-Boot
+   U-Boot proper, containing the command line and boot logic.
+
+
+Checking the boot phase
+---
+
+Use `spl_phase()` to find the current U-Boot phase, e.g. `PHASE_SPL`. You can
+also find the previous and next phase and get the phase name.
+
+
 Device tree
 ---
 The U-Boot device tree is filtered by the fdtgrep tools during the build
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v6 00/11] vpl: Introduce a verifying program loader

2021-09-19 Thread Simon Glass 
U-Boot provides a verified-boot feature based around FIT, but there is
no standard way of implementing it for a board. At present the various
required pieces must be built up separately, to produce a working
implementation. In particular, there is no built-in support for selecting
A/B boot or recovery mode.

This series introduces VPL, a verified program loader phase for U-Boot.
Its purpose is to run the verified-boot process and decide which SPL
binary should be run. It is critical that this decision happens before
SPL runs, since SPL sets up SDRAM and we need to be able to update the
SDRAM-init code in the field.

Adding VPL into the boot flow provides a standard way of implementing
verified boot. This series includes the phase itself, some useful Kconfig
options and a sandbox_vpl build for sandbox.

Changes in v6:
- Fix the missing SPDX tag on test/204...
- Add docs for sandbox_vpl build
- Drop TPL_HASH_SUPPORT patch since we only have SPL_HASH now

Changes in v5:
- Rebase this patch on mainline (for GPIO and MISC Kconfig renames)

Changes in v4:
- Add new patch to correct bloblist Kconfig dependencies
- Add new patch to avoid building avb in SPL
- Update spl_phase_prefix() for VPL
- Tidy up some of the Makefile rules
- Add options for blk, core, misc and tpl also
- Add VPL_SIZE_LIMIT
- Add a sandbox_vpl build
- Update cover letter

Changes in v3:
- Move VPL Kconfig options to a separate patch
- Add full build support for VPL
- Add a VPL size check (Kconfig option in next patch)

Changes in v2:
- Add some more VPL Kconfig options

Simon Glass (11):
  doc: Convert SPL documentation to ReST
  doc: Expand SPL docs to explain the phase and config
  test: Tidy up test building with SPL
  bloblist: Correct Kconfig dependencies
  avb: Don't build in SPL
  Makefile: Simplify devicetree rules for SPL/TPL
  Makefile: Tidy up the TPL build rules
  binman: Add VPL support
  Introduce Verifying Program Loader (VPL)
  vpl: Add Kconfig options for VPL
  sandbox: Add a build for VPL

 Kconfig|  10 +
 Makefile   |  30 ++-
 arch/sandbox/Kconfig   |   8 +
 arch/sandbox/cpu/spl.c |  12 +-
 arch/sandbox/dts/sandbox.dtsi  |  10 +-
 board/sandbox/MAINTAINERS  |   7 +
 common/Kconfig |  71 +-
 common/Makefile|   2 +-
 common/spl/Kconfig | 217 +-
 common/spl/spl.c   |  25 ++-
 configs/sandbox_vpl_defconfig  | 249 +
 doc/arch/sandbox.rst   |  13 ++
 doc/develop/index.rst  |   1 +
 doc/{README.SPL => develop/spl.rst}|  75 +--
 drivers/Makefile   |   2 +
 drivers/block/Kconfig  |  12 +
 drivers/clk/Kconfig|  10 +
 drivers/core/Kconfig   |  33 +++
 drivers/core/Makefile  |   2 +-
 drivers/gpio/Kconfig   |  11 +
 drivers/i2c/Kconfig|  11 +
 drivers/misc/Kconfig   |  28 +++
 drivers/pinctrl/Kconfig|  18 +-
 drivers/rtc/Kconfig|   9 +
 drivers/serial/Kconfig |  20 ++
 drivers/sysreset/Kconfig   |  10 +
 drivers/timer/Kconfig  |  10 +
 drivers/tpm/Kconfig|  30 +++
 dts/Kconfig|   9 +
 include/bootstage.h|   2 +
 include/linux/kconfig.h|   3 +
 include/spl.h  |  22 +-
 lib/Kconfig|  64 +-
 scripts/Kbuild.include |   4 +
 scripts/Makefile.autoconf  |  12 +
 scripts/Makefile.build |   4 +
 scripts/Makefile.lib   |   5 +
 scripts/Makefile.spl   |  37 ++-
 tools/binman/etype/u_boot_vpl.py   |  42 
 tools/binman/etype/u_boot_vpl_bss_pad.py   |  44 
 tools/binman/etype/u_boot_vpl_dtb.py   |  28 +++
 tools/binman/etype/u_boot_vpl_expanded.py  |  45 
 tools/binman/etype/u_boot_vpl_nodtb.py |  42 
 tools/binman/ftest.py  | 109 +++--
 tools/binman/state.py  |   3 +-
 tools/binman/test/082_fdt_update_all.dts   |   2 +
 tools/binman/test/201_u_boot_vpl.dts   |  11 +
 tools/binman/test/202_u_boot_vpl_nodtb.dts |  13 ++
 tools/binman/test/203_fdt_incl_vpl.dts |  13 ++
 tools/binman/test/204_vpl_bss_pad.dts  |  19 ++
 50 files changed, 1391 insertions(+), 78 deletions(-)
 create mode 100644 configs/sandbox_vpl_defconfig
 rename doc/{README.SPL => develop/spl.rst} (69%)
 create mode 100644 tools/binman/etype/u_boot_vpl.py
 create mode 100644 tools/binman/etype/u_boot_vpl_bss_pad.py
 create mode 100644

[PATCH v6 01/11] doc: Convert SPL documentation to ReST

2021-09-19 Thread Simon Glass 
Move this documentation over to .rst format.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 doc/develop/index.rst   |  1 +
 doc/{README.SPL => develop/spl.rst} | 36 +++--
 2 files changed, 20 insertions(+), 17 deletions(-)
 rename doc/{README.SPL => develop/spl.rst} (86%)

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 2a32645cfd2..48134549fa2 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -18,6 +18,7 @@ Implementation
logging
makefiles
menus
+   spl
uefi/index
version
 
diff --git a/doc/README.SPL b/doc/develop/spl.rst
similarity index 86%
rename from doc/README.SPL
rename to doc/develop/spl.rst
index 0448835f5f1..c7d08d22bf2 100644
--- a/doc/README.SPL
+++ b/doc/develop/spl.rst
@@ -20,19 +20,19 @@ u-boot-spl.map.
 A config option named CONFIG_SPL_BUILD is enabled by Kconfig for SPL.
 Source files can therefore be compiled for SPL with different settings.
 
-For example:
+For example::
 
-ifeq ($(CONFIG_SPL_BUILD),y)
-obj-y += board_spl.o
-else
-obj-y += board.o
-endif
+   ifeq ($(CONFIG_SPL_BUILD),y)
+   obj-y += board_spl.o
+   else
+   obj-y += board.o
+   endif
 
-obj-$(CONFIG_SPL_BUILD) += foo.o
+   obj-$(CONFIG_SPL_BUILD) += foo.o
 
-#ifdef CONFIG_SPL_BUILD
-   foo();
-#endif
+   #ifdef CONFIG_SPL_BUILD
+   foo();
+   #endif
 
 
 The building of SPL images can be enabled by CONFIG_SPL option in Kconfig.
@@ -71,11 +71,13 @@ Device tree
 The U-Boot device tree is filtered by the fdtgrep tools during the build
 process to generate a much smaller device tree used in SPL (spl/u-boot-spl.dtb)
 with:
+
 - the mandatory nodes (/alias, /chosen, /config)
 - the nodes with one pre-relocation property:
   'u-boot,dm-pre-reloc' or 'u-boot,dm-spl'
 
 fdtgrep is also used to remove:
+
 - the properties defined in CONFIG_OF_SPL_REMOVE_PROPS
 - all the pre-relocation properties
   ('u-boot,dm-pre-reloc', 'u-boot,dm-spl' and 'u-boot,dm-tpl')
@@ -98,14 +100,14 @@ stack usage at various points in run sequence of SPL.  The 
-fstack-usage option
 to gcc will produce '.su' files (such as arch/arm/cpu/armv7/syslib.su) that
 will give stack usage information and cflow can construct program flow.
 
-Must have gcc 4.6 or later, which supports -fstack-usage
+Must have gcc 4.6 or later, which supports -fstack-usage:
 
-1) Build normally
-2) Perform the following shell command to generate a list of C files used in
-SPL:
-$ find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list
-3) Execute cflow:
-$ cflow --main=board_init_r `cat used-spl.list` 2>&1 | $PAGER
+#. Build normally
+#. Perform the following shell command to generate a list of C files used in
+   SPL:
+#. `find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > 
used-spl.list`
+#. Execute cflow:
+   `$ cflow --main=board_init_r $(cat used-spl.list) 2>&1 | $PAGER`
 
 cflow will spit out a number of warnings as it does not parse
 the config files and picks functions based on #ifdef.  Parsing the '.i'
-- 
2.33.0.464.g1972c5931b-goog

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

2021-09-19 Thread Sean Anderson 

Is it possible to get this in 2020.10? Meng's patch breaks boards which use 
this watchdog.

--Sean

On 9/11/21 3:11 PM, Sean Anderson wrote:

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;
}

Re: [PATCH] usb: xhci-dwc3: Add support for USB 3.1 controllers

2021-09-19 Thread Marek Vasut 

On 9/19/21 10:40 AM, Bin Meng wrote:

Hi Marek,

On Thu, Sep 16, 2021 at 10:08 PM Bin Meng  wrote:


On Thu, Sep 16, 2021 at 10:00 PM Mark Kettenis  wrote:


This adds support for the DWC_sub31 controllers such as those
found on Apple's M1 SoC.  This version of the controller
seems to work fine with the existing driver.

Signed-off-by: Mark Kettenis 
---
  drivers/usb/host/xhci-dwc3.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)



Reviewed-by: Bin Meng 


I see this is assigned to me on patchwork. Would you like this to go
via the x86 tree?


Since it's just one patch, I suspect Tom can just pick it directly.

Re: [PATCH v4 2/2] doc: Add documentation about devicetree usage

2021-09-19 Thread Simon Glass 
Hi François,

On Sun, 19 Sept 2021 at 16:16, François Ozog 
wrote:

> Hi Simon
>
> The DT use is connected to the issues we said we will invest time.
> So in the same spirit that we are reverting EFI patch, I would appreciate
> you defer this patch series after the forthcoming discussions.
>

That's fine with me, but note that this patch is for the next release,
anyway.

Regards,
Simon


> Cheers
>
> FF
>
> Le dim. 19 sept. 2021 à 23:51, Simon Glass  a écrit :
>
>> At present some of the ideas and techniques behind devicetree in U-Boot
>> are assumed, implied or unsaid. Add some documentation to cover how
>> devicetree is build, how it can be modified and the rules about using
>> the various CONFIG_OF_... options.
>>
>> Signed-off-by: Simon Glass 
>> Reviewed-by: Marcel Ziswiler 
>> ---
>> This patch attracted quite a bit of discussion here:
>>
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/
>>
>> I have not included the text suggested by François. While I agree that
>> it would be useful to have an introduction in this space, I do not agree
>> that we should have two devicetrees or that U-Boot should not have its own
>> things in the devicetree, so it is not clear to me what we should actually
>> write.
>>
>> The 'Devicetree Control in U-Boot' docs were recently merged and these
>> provide some base info, for now.
>>
>> (no changes since v3)
>>
>> Changes in v3:
>> - Clarify the 'bug' refered to at the top
>> - Reword 'This means that there' paragraph to explain U-Boot-specific
>> things
>> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
>>
>> Changes in v2:
>> - Fix typos per Sean (thank you!) and a few others
>> - Add a 'Use of U-Boot /config node' section
>> - Drop mention of dm-verity since that actually uses the kernel cmdline
>> - Explain that OF_BOARD will still work after these changes (in
>>   'Once this bug is fixed...' paragraph)
>> - Expand a bit on the reason why the 'Current situation' is bad
>> - Clarify in a second place that Linux and U-Boot use the same devicetree
>>   in 'To be clear, while U-Boot...'
>> - Expand on why we should have rules for other projects in
>>   'Devicetree in another project'
>> - Add a comment as to why devicetree in U-Boot is not 'bad design'
>> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
>> - Rewrite 'Devicetree generated on-the-fly in another project' to cover
>>   points raised on v1
>> - Add 'Why does U-Boot have its nodes and properties?'
>> - Add 'Why not have two devicetrees?'
>>
>>  doc/develop/devicetree/dt_update.rst | 569 +++
>>  doc/develop/devicetree/index.rst |   1 +
>>  2 files changed, 570 insertions(+)
>>  create mode 100644 doc/develop/devicetree/dt_update.rst
>>
>> diff --git a/doc/develop/devicetree/dt_update.rst
>> b/doc/develop/devicetree/dt_update.rst
>> new file mode 100644
>> index 000..f2ad317573a
>> --- /dev/null
>> +++ b/doc/develop/devicetree/dt_update.rst
>> @@ -0,0 +1,569 @@
>> +.. SPDX-License-Identifier: GPL-2.0+
>> +
>> +Updating the devicetree
>> +===
>> +
>> +U-Boot uses devicetree for runtime configuration and storing required
>> blobs or
>> +any other information it needs to operate. It is possible to update the
>> +devicetree separately from actually building U-Boot. This provides a
>> good degree
>> +of control and flexibility for firmware that uses U-Boot in conjunction
>> with
>> +other project.
>> +
>> +There are many reasons why it is useful to modify the devicetree after
>> building
>> +it:
>> +
>> +- Configuration can be changed, e.g. which UART to use
>> +- A serial number can be added
>> +- Public keys can be added to allow image verification
>> +- Console output can be changed (e.g. to select serial or vidconsole)
>> +
>> +This section describes how to work with devicetree to accomplish your
>> goals.
>> +
>> +See also :doc:`../devicetree/control` for a basic summary of the
>> available
>> +features.
>> +
>> +
>> +Devicetree source
>> +-
>> +
>> +Every board in U-Boot must include a devicetree sufficient to build and
>> boot
>> +that board on suitable hardware (or emulation). This is specified using
>> the
>> +`CONFIG DEFAULT_DEVICE_TREE` option.
>> +
>> +
>> +Current situation (September 2021)
>> +~~
>> +
>> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be
>> empty,
>> +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has
>> +unfortunately created an enormous amount of confusion and some wasted
>> effort.
>> +This was not intended. Since these two options do essentially the same
>> thing,
>> +they will be combined in a future release. Also, support for an empty
>> +`CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
>> +
>> +Some of the problems created are:
>> +
>> +- It is not obvious that the devicetree is coming from another project
>> +
>> +- There is no way to see even

Re: [PATCH v4 2/2] doc: Add documentation about devicetree usage

2021-09-19 Thread François Ozog 
Hi Simon

The DT use is connected to the issues we said we will invest time.
So in the same spirit that we are reverting EFI patch, I would appreciate
you defer this patch series after the forthcoming discussions.

Cheers

FF

Le dim. 19 sept. 2021 à 23:51, Simon Glass  a écrit :

> At present some of the ideas and techniques behind devicetree in U-Boot
> are assumed, implied or unsaid. Add some documentation to cover how
> devicetree is build, how it can be modified and the rules about using
> the various CONFIG_OF_... options.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Marcel Ziswiler 
> ---
> This patch attracted quite a bit of discussion here:
>
>
> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/
>
> I have not included the text suggested by François. While I agree that
> it would be useful to have an introduction in this space, I do not agree
> that we should have two devicetrees or that U-Boot should not have its own
> things in the devicetree, so it is not clear to me what we should actually
> write.
>
> The 'Devicetree Control in U-Boot' docs were recently merged and these
> provide some base info, for now.
>
> (no changes since v3)
>
> Changes in v3:
> - Clarify the 'bug' refered to at the top
> - Reword 'This means that there' paragraph to explain U-Boot-specific
> things
> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
>
> Changes in v2:
> - Fix typos per Sean (thank you!) and a few others
> - Add a 'Use of U-Boot /config node' section
> - Drop mention of dm-verity since that actually uses the kernel cmdline
> - Explain that OF_BOARD will still work after these changes (in
>   'Once this bug is fixed...' paragraph)
> - Expand a bit on the reason why the 'Current situation' is bad
> - Clarify in a second place that Linux and U-Boot use the same devicetree
>   in 'To be clear, while U-Boot...'
> - Expand on why we should have rules for other projects in
>   'Devicetree in another project'
> - Add a comment as to why devicetree in U-Boot is not 'bad design'
> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
> - Rewrite 'Devicetree generated on-the-fly in another project' to cover
>   points raised on v1
> - Add 'Why does U-Boot have its nodes and properties?'
> - Add 'Why not have two devicetrees?'
>
>  doc/develop/devicetree/dt_update.rst | 569 +++
>  doc/develop/devicetree/index.rst |   1 +
>  2 files changed, 570 insertions(+)
>  create mode 100644 doc/develop/devicetree/dt_update.rst
>
> diff --git a/doc/develop/devicetree/dt_update.rst
> b/doc/develop/devicetree/dt_update.rst
> new file mode 100644
> index 000..f2ad317573a
> --- /dev/null
> +++ b/doc/develop/devicetree/dt_update.rst
> @@ -0,0 +1,569 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Updating the devicetree
> +===
> +
> +U-Boot uses devicetree for runtime configuration and storing required
> blobs or
> +any other information it needs to operate. It is possible to update the
> +devicetree separately from actually building U-Boot. This provides a good
> degree
> +of control and flexibility for firmware that uses U-Boot in conjunction
> with
> +other project.
> +
> +There are many reasons why it is useful to modify the devicetree after
> building
> +it:
> +
> +- Configuration can be changed, e.g. which UART to use
> +- A serial number can be added
> +- Public keys can be added to allow image verification
> +- Console output can be changed (e.g. to select serial or vidconsole)
> +
> +This section describes how to work with devicetree to accomplish your
> goals.
> +
> +See also :doc:`../devicetree/control` for a basic summary of the available
> +features.
> +
> +
> +Devicetree source
> +-
> +
> +Every board in U-Boot must include a devicetree sufficient to build and
> boot
> +that board on suitable hardware (or emulation). This is specified using
> the
> +`CONFIG DEFAULT_DEVICE_TREE` option.
> +
> +
> +Current situation (September 2021)
> +~~
> +
> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be
> empty,
> +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has
> +unfortunately created an enormous amount of confusion and some wasted
> effort.
> +This was not intended. Since these two options do essentially the same
> thing,
> +they will be combined in a future release. Also, support for an empty
> +`CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
> +
> +Some of the problems created are:
> +
> +- It is not obvious that the devicetree is coming from another project
> +
> +- There is no way to see even a sample devicetree for these platform in
> U-Boot,
> +  so it is hard to know what is going on, e.g. which devices are typically
> +  present
> +
> +- The other project may not provide a way to support U-Boot's
> requirements for
> +  devicetree, such as the /config node. Note: On the U-Boot mailing
>

[PATCH v4 2/2] doc: Add documentation about devicetree usage

2021-09-19 Thread Simon Glass 
At present some of the ideas and techniques behind devicetree in U-Boot
are assumed, implied or unsaid. Add some documentation to cover how
devicetree is build, how it can be modified and the rules about using
the various CONFIG_OF_... options.

Signed-off-by: Simon Glass 
Reviewed-by: Marcel Ziswiler 
---
This patch attracted quite a bit of discussion here:

https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/

I have not included the text suggested by François. While I agree that
it would be useful to have an introduction in this space, I do not agree
that we should have two devicetrees or that U-Boot should not have its own
things in the devicetree, so it is not clear to me what we should actually
write.

The 'Devicetree Control in U-Boot' docs were recently merged and these
provide some base info, for now.

(no changes since v3)

Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs

Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in
  'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree
  in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in
  'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover
  points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'

 doc/develop/devicetree/dt_update.rst | 569 +++
 doc/develop/devicetree/index.rst |   1 +
 2 files changed, 570 insertions(+)
 create mode 100644 doc/develop/devicetree/dt_update.rst

diff --git a/doc/develop/devicetree/dt_update.rst 
b/doc/develop/devicetree/dt_update.rst
new file mode 100644
index 000..f2ad317573a
--- /dev/null
+++ b/doc/develop/devicetree/dt_update.rst
@@ -0,0 +1,569 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Updating the devicetree
+===
+
+U-Boot uses devicetree for runtime configuration and storing required blobs or
+any other information it needs to operate. It is possible to update the
+devicetree separately from actually building U-Boot. This provides a good 
degree
+of control and flexibility for firmware that uses U-Boot in conjunction with
+other project.
+
+There are many reasons why it is useful to modify the devicetree after building
+it:
+
+- Configuration can be changed, e.g. which UART to use
+- A serial number can be added
+- Public keys can be added to allow image verification
+- Console output can be changed (e.g. to select serial or vidconsole)
+
+This section describes how to work with devicetree to accomplish your goals.
+
+See also :doc:`../devicetree/control` for a basic summary of the available
+features.
+
+
+Devicetree source
+-
+
+Every board in U-Boot must include a devicetree sufficient to build and boot
+that board on suitable hardware (or emulation). This is specified using the
+`CONFIG DEFAULT_DEVICE_TREE` option.
+
+
+Current situation (September 2021)
+~~
+
+As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty,
+e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has
+unfortunately created an enormous amount of confusion and some wasted effort.
+This was not intended. Since these two options do essentially the same thing,
+they will be combined in a future release. Also, support for an empty
+`CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon.
+
+Some of the problems created are:
+
+- It is not obvious that the devicetree is coming from another project
+
+- There is no way to see even a sample devicetree for these platform in U-Boot,
+  so it is hard to know what is going on, e.g. which devices are typically
+  present
+
+- The other project may not provide a way to support U-Boot's requirements for
+  devicetree, such as the /config node. Note: On the U-Boot mailing linst, this
+  was only discovered after weeks of discussion and confusion
+
+- For QEMU specifically, consulting two QEMU source files is required, for 
which
+  there are no references in U-Boot documentation. The code is generating a
+  devicetree, but it is not clear what controls affect this generation.
+
+Specifically on the changes in U-Boot:
+
+- `CONFIG_OF_BOARD` was added in rpi_patch_ for Raspberry Pi, which does have
+  an in-tree devicetree, but this feature has since been used for boards that
+  don't
+-

[PATCH v4 1/2] doc: Add mention of the /config binding

2021-09-19 Thread Simon Glass 
The devicetree binding files are in their own directory and use a simple
text format. Add a link for the binding for the /config node, since it
is otherwise hard to find.

Suggested-by: Heinrich Schuchardt 
Signed-off-by: Simon Glass 
---

Changes in v4:
- Add a patch to refer to the /config binding from docs

 doc/develop/config_binding.rst | 10 ++
 doc/develop/index.rst  |  1 +
 2 files changed, 11 insertions(+)
 create mode 100644 doc/develop/config_binding.rst

diff --git a/doc/develop/config_binding.rst b/doc/develop/config_binding.rst
new file mode 100644
index 000..c90e99c7baa
--- /dev/null
+++ b/doc/develop/config_binding.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot configuration node
+=
+
+U-Boot supports a number of runtime configuration options which can be selected
+in the devicetree.
+
+These are documented in
+:download:`The /config node <../../doc/device-tree-bindings/config.txt>`.
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 2a32645cfd2..24056b10fdd 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -12,6 +12,7 @@ Implementation
bloblist
ci_testing
commands
+   config_binding
devicetree/index
driver-model/index
global_data
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 0/2] doc: Clarify how U-Boot makes use of devicetree

2021-09-19 Thread Simon Glass 
This series includes a documentation update to clarify how U-Boot makes
use of devicetree and its requirements when working with other firmware
projects.

Once agreed it should provide more clarity in this area, which seems to
have devolved into a confusing mire recently.

My goal here is to sort out this area one and for all, clearly documenting
the use cases and implications of them. I hope that the end result of this
(substantial) effort will be a shared understanding of how to move
forward in U-Boot and hopefully some ideas for firmware in general.

It also cleans up the config binding since this has got a bit out-of-date.

Changes in v4:
- Add a patch to refer to the /config binding from docs

Changes in v3:
- Clarify the 'bug' refered to at the top
- Reword 'This means that there' paragraph to explain U-Boot-specific things
- Move to doc/develop/devicetree now that OF_CONTROL is in the docs

Changes in v2:
- Fix typos per Sean (thank you!) and a few others
- Add a 'Use of U-Boot /config node' section
- Drop mention of dm-verity since that actually uses the kernel cmdline
- Explain that OF_BOARD will still work after these changes (in
  'Once this bug is fixed...' paragraph)
- Expand a bit on the reason why the 'Current situation' is bad
- Clarify in a second place that Linux and U-Boot use the same devicetree
  in 'To be clear, while U-Boot...'
- Expand on why we should have rules for other projects in
  'Devicetree in another project'
- Add a comment as to why devicetree in U-Boot is not 'bad design'
- Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
- Rewrite 'Devicetree generated on-the-fly in another project' to cover
  points raised on v1
- Add 'Why does U-Boot have its nodes and properties?'
- Add 'Why not have two devicetrees?'

Simon Glass (2):
  doc: Add mention of the /config binding
  doc: Add documentation about devicetree usage

 doc/develop/config_binding.rst   |  10 +
 doc/develop/devicetree/dt_update.rst | 569 +++
 doc/develop/devicetree/index.rst |   1 +
 doc/develop/index.rst|   1 +
 4 files changed, 581 insertions(+)
 create mode 100644 doc/develop/config_binding.rst
 create mode 100644 doc/develop/devicetree/dt_update.rst

-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 4/5] sf: doc: Add documentation for the 'sf' command

2021-09-19 Thread Simon Glass 
This command is fairly complicated so documentation is useful.
Unfortunately I an not sure how the MTD side of things works and cannot
find information about that.

Signed-off-by: Simon Glass 

Acked-by: Pratyush Yadav 
---

Changes in v4:
- Split out the 'const' change into a separate patch
- Show the 'sf probe' output in the examples

Changes in v2:
- Many fixes as suggested by Heinrich

 doc/usage/index.rst |   1 +
 doc/usage/sf.rst| 245 
 2 files changed, 246 insertions(+)
 create mode 100644 doc/usage/sf.rst

diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 356f2a56181..9a7b12b7c54 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -43,6 +43,7 @@ Shell commands
qfw
reset
sbi
+   sf
scp03
setexpr
size
diff --git a/doc/usage/sf.rst b/doc/usage/sf.rst
new file mode 100644
index 000..71bd1be5175
--- /dev/null
+++ b/doc/usage/sf.rst
@@ -0,0 +1,245 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+sf command
+==
+
+Synopis
+---
+
+::
+
+sf probe [[[:]] [ []]]
+sf read  | 
+sf write  | 
+sf erase | 
+sf update  | 
+sf protect lock|unlock  
+sf test | 
+
+Description
+---
+
+The *sf* command is used to access SPI flash, supporting read/write/erase and
+a few other functions.
+
+Probe
+-
+
+The flash must first be probed with *sf probe* before any of the other
+subcommands can be used. All of the parameters are optional:
+
+bus
+   SPI bus number containing the SPI-flash chip, e.g. 0. If you don't know
+   the number, you can use 'dm uclass' to see all the spi devices,
+   and check the value for 'seq' for each one (here 0 and 2)::
+
+  uclass 89: spi
+  0 spi@0 @ 05484960, seq 0
+  1 spi@1 @ 05484b40, seq 2
+
+cs
+   SPI chip-select to use for the chip. This is often 0 and can be omitted,
+   but in some cases multiple slaves are attached to a SPI controller,
+   selected by a chip-select line for each one.
+
+hz
+   Speed of the SPI bus in hertz. This normally defaults to 10, i.e.
+   100KHz, which is very slow. Note that if the device exists in the
+   device tree, there might be a speed provided there, in which case this
+   setting is ignored.
+
+mode
+   SPI mode to use:
+
+   =  
+   Mode   Meaning
+   =  
+   0  CPOL=0, CPHA=0
+   1  CPOL=0, CPHA=1
+   2  CPOL=1, CPHA=0
+   3  CPOL=1, CPHA=1
+   =  
+
+   Clock phase (CPHA) 0 means that data is transferred (sampled) on the
+   first clock edge; 1 means the second.
+
+   Clock polarity (CPOL) controls the idle state of the clock, 0 for low,
+   1 for high.
+   The active state is the opposite of idle.
+
+   You may find this `SPI documentation`_ useful.
+
+Parameters for other subcommands (described below) are as follows:
+
+addr
+   Memory address to start transfer
+
+offset
+   Flash offset to start transfer
+
+partition
+   If the parameter is not numeric, it is assumed to be a partition
+   description in the format , which is not
+   covered here. This requires CONFIG_CMD_MTDPARTS.
+
+len
+   Number of bytes to transfer
+
+Read
+
+
+Use *sf read* to read from SPI flash to memory. The read will fail if an
+attempt is made to read past the end of the flash.
+
+
+Write
+~
+
+Use *sf write* to write from memory to SPI flash. The SPI flash should be
+erased first, since otherwise the result is undefined.
+
+The write will fail if an attempt is made to read past the end of the flash.
+
+
+Erase
+~
+
+Use *sf erase* to erase a region of SPI flash. The erase will fail if any part
+of the region to be erased is protected or lies past the end of the flash. It
+may also fail if the start offset or length are not aligned to an erase region
+(e.g. 256 bytes).
+
+
+Update
+~~
+
+Use *sf update* to automatically erase and update a region of SPI flash from
+memory. This works a sector at a time (typical 4KB or 64KB). For each
+sector it first checks if the sector already has the right data. If so it is
+skipped. If not, the sector is erased and the new data written. Note that if
+the length is not a multiple of the erase size, the space after the data in
+the last sector will be erased. If the offset does not start at the beginning
+of an erase block, the operation will fail.
+
+Speed statistics are shown including the number of bytes that were already
+correct.
+
+
+Protect
+~~~
+
+SPI-flash chips often have a protection feature where the chip is split up into
+regions which can be locked or unlocked. With *sf protect* it is possible to
+change these settings, if supported by the driver.
+
+lock|unlock
+   Selects whether to lock or unlock the sectors
+
+
+   Start sector number to lock/unlock. This may be the byte offset or some
+   other value,

[PATCH v4 5/5] sf: Provide a command to access memory-mapped SPI

2021-09-19 Thread Simon Glass 
Add a new 'sf mmap' function to show the address of a SPI offset, if the
hardware supports it. This is useful on x86 systems.

Signed-off-by: Simon Glass 
---

(no changes since v3)

Changes in v3:
- Add configuration and return value also

 arch/Kconfig |  2 ++
 cmd/Kconfig  |  8 ++
 cmd/sf.c | 35 +++
 doc/usage/sf.rst | 63 
 4 files changed, 108 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 8f8daadcf92..406e5a6c627 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -136,6 +136,7 @@ config SANDBOX
imply CMD_LZMADEC
imply CMD_SATA
imply CMD_SF
+   imply CMD_SF_MMAP
imply CMD_SF_TEST
imply CRC32_VERIFY
imply FAT_WRITE
@@ -200,6 +201,7 @@ config X86
imply CMD_IRQ
imply CMD_PCI
imply CMD_SF
+   imply CMD_SF_MMAP
imply CMD_SF_TEST
imply CMD_ZBOOT
imply DM_ETH
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3a857b3f6e2..44485f1588c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1273,6 +1273,14 @@ config CMD_SF
help
  SPI Flash support
 
+config CMD_SF_MMAP
+   bool "sf mmap - Access memory-mapped SPI flash"
+   depends on CMD_SF
+   help
+ On some systems part of the SPI flash is mapped into mmemory. This
+ command provides a way to map a SPI-flash offset to a memory address,
+ so that the contents can be browsed using 'md', for example.
+
 config CMD_SF_TEST
bool "sf test - Allow testing of SPI flash"
depends on CMD_SF
diff --git a/cmd/sf.c b/cmd/sf.c
index 72246d912fe..c78cd7e6342 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -384,6 +384,36 @@ static int do_spi_protect(int argc, char *const argv[])
return ret == 0 ? 0 : 1;
 }
 
+static int do_spi_flash_mmap(int argc, char *const argv[])
+{
+   loff_t offset, len, maxsize;
+   uint map_offset, map_size;
+   ulong map_base;
+   int dev = 0;
+   int ret;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   ret = mtd_arg_off_size(argc - 1, [1], , , ,
+  , MTD_DEV_TYPE_NOR, flash->size);
+   if (ret)
+   return ret;
+
+   ret = dm_spi_get_mmap(flash->dev, _base, _size, _offset);
+   if (ret) {
+   printf("Mapping not available (err=%d)\n", ret);
+   return CMD_RET_FAILURE;
+   }
+   if (offset < 0 || offset + len > map_size) {
+   printf("Offset out of range (map size %x)\n", map_size);
+   return CMD_RET_FAILURE;
+   }
+   printf("%lx\n", map_base + (ulong)offset);
+
+   return 0;
+}
+
 enum {
STAGE_ERASE,
STAGE_CHECK,
@@ -580,6 +610,8 @@ static int do_spi_flash(struct cmd_tbl *cmdtp, int flag, 
int argc,
ret = do_spi_flash_erase(argc, argv);
else if (strcmp(cmd, "protect") == 0)
ret = do_spi_protect(argc, argv);
+   else if (IS_ENABLED(CONFIG_CMD_SF_MMAP) && !strcmp(cmd, "mmap"))
+   ret = do_spi_flash_mmap(argc, argv);
else if (IS_ENABLED(CONFIG_CMD_SF_TEST) && !strcmp(cmd, "test"))
ret = do_spi_flash_test(argc, argv);
else
@@ -611,6 +643,9 @@ static const char long_help[] =
" or to start of mtd 
`partition'\n"
"sf protect lock/unlock sector len  - protect/unprotect 'len' bytes 
starting\n"
" at address 'sector'"
+#ifdef CONFIG_CMD_SF_MMAP
+   "\nsf mmap offset len   - get memory address of SPI-flash 
offset\n"
+#endif
 #ifdef CONFIG_CMD_SF_TEST
"\nsf test offset len   - run a very basic destructive test"
 #endif
diff --git a/doc/usage/sf.rst b/doc/usage/sf.rst
index 71bd1be5175..93fb8409370 100644
--- a/doc/usage/sf.rst
+++ b/doc/usage/sf.rst
@@ -14,6 +14,7 @@ Synopis
 sf erase | 
 sf update  | 
 sf protect lock|unlock  
+sf mmap | 
 sf test | 
 
 Description
@@ -143,6 +144,16 @@ lock|unlock
Number of bytes to lock/unlock
 
 
+Memory-mapped flash
+---
+
+On some systems part of the SPI flash is mapped into mmemory. With *sf mmap*
+you can map a SPI-flash offset to a memory address, so that the contents can be
+browsed using 'md', for example.
+
+The command will fail if this is not supported by the hardware or driver.
+
+
 Test
 
 
@@ -240,6 +251,58 @@ This second example is running on coral, an x86 
Chromebook::
2 write: 227 ticks, 2255 KiB/s 18.040 Mbps
3 read: 189 ticks, 2708 KiB/s 21.664 Mbps
 
+   # On coral, SPI flash offset 0 corresponds to address ff081000 in memory
+   => sf mmap 0 1000
+   device 0 offset 0x0, size 0x1000
+   ff081000
+
+   # See below for how this address was obtained
+   => sf mmap e8 11e18
+   device 0 offset 0xe8, size 0x11e18
+   fff01000
+   => md fff01000
+   fff01000: b2e8e089 8930 30b4e8c4

[PATCH v4 3/5] sf: Tidy up code to avoid #ifdef

2021-09-19 Thread Simon Glass 
Update this code to use IS_ENABLED() instead.

Signed-off-by: Simon Glass 

Reviewed-by: Pratyush Yadav 
---

(no changes since v1)

 cmd/sf.c | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/cmd/sf.c b/cmd/sf.c
index 15361a4bddf..72246d912fe 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -384,7 +384,6 @@ static int do_spi_protect(int argc, char *const argv[])
return ret == 0 ? 0 : 1;
 }
 
-#ifdef CONFIG_CMD_SF_TEST
 enum {
STAGE_ERASE,
STAGE_CHECK,
@@ -548,7 +547,6 @@ static int do_spi_flash_test(int argc, char *const argv[])
 
return 0;
 }
-#endif /* CONFIG_CMD_SF_TEST */
 
 static int do_spi_flash(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
@@ -582,10 +580,8 @@ static int do_spi_flash(struct cmd_tbl *cmdtp, int flag, 
int argc,
ret = do_spi_flash_erase(argc, argv);
else if (strcmp(cmd, "protect") == 0)
ret = do_spi_protect(argc, argv);
-#ifdef CONFIG_CMD_SF_TEST
-   else if (!strcmp(cmd, "test"))
+   else if (IS_ENABLED(CONFIG_CMD_SF_TEST) && !strcmp(cmd, "test"))
ret = do_spi_flash_test(argc, argv);
-#endif
else
ret = -1;
 
@@ -597,16 +593,8 @@ usage:
return CMD_RET_USAGE;
 }
 
-#ifdef CONFIG_CMD_SF_TEST
-#define SF_TEST_HELP "\nsf test offset len " \
-   "- run a very basic destructive test"
-#else
-#define SF_TEST_HELP
-#endif
-
-U_BOOT_CMD(
-   sf, 5,  1,  do_spi_flash,
-   "SPI flash sub-system",
+#ifdef CONFIG_SYS_LONGHELP
+static const char long_help[] =
"probe [[bus:]cs] [hz] [mode]   - init flash device on given SPI bus\n"
" and chip select\n"
"sf read addr offset|partition len  - read `len' bytes starting 
at\n"
@@ -622,6 +610,14 @@ U_BOOT_CMD(
" at `addr' to flash at 
`offset'\n"
" or to start of mtd 
`partition'\n"
"sf protect lock/unlock sector len  - protect/unprotect 'len' bytes 
starting\n"
-   " at address 'sector'\n"
-   SF_TEST_HELP
+   " at address 'sector'"
+#ifdef CONFIG_CMD_SF_TEST
+   "\nsf test offset len   - run a very basic destructive test"
+#endif
+#endif /* CONFIG_SYS_LONGHELP */
+   ;
+
+U_BOOT_CMD(
+   sf, 5,  1,  do_spi_flash,
+   "SPI flash sub-system", long_help
 );
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 2/5] sf: Use const for the stage name

2021-09-19 Thread Simon Glass 
This is not updated at runtime so should be marked const. Update the code
accordingly.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 cmd/sf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/sf.c b/cmd/sf.c
index eac27ed2d77..15361a4bddf 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -394,7 +394,7 @@ enum {
STAGE_COUNT,
 };
 
-static char *stage_name[STAGE_COUNT] = {
+static const char *stage_name[STAGE_COUNT] = {
"erase",
"check",
"write",
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 1/5] command: Use a constant pointer for the help

2021-09-19 Thread Simon Glass 
This text should never change during execution, so it makes sense to
use a const char * so that it can be declared as const in the code.
Update struct cmd_tbl with a const char * pointer for 'help'.

We cannot make usage const because of the bmode command, used on mx53ppd
for example.

Signed-off-by: Simon Glass 
---

(no changes since v2)

Changes in v2:
- Explain why 'usage' cannot be const

 include/command.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/command.h b/include/command.h
index 137cfbc3231..f8e07a591c6 100644
--- a/include/command.h
+++ b/include/command.h
@@ -45,7 +45,7 @@ struct cmd_tbl {
   char *const argv[]);
char*usage; /* Usage message(short) */
 #ifdef CONFIG_SYS_LONGHELP
-   char*help;  /* Help  message(long)  */
+   const char  *help;  /* Help  message(long)  */
 #endif
 #ifdef CONFIG_AUTO_COMPLETE
/* do auto completion on the arguments */
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 0/5] sf: Add documentation and an 'sf mmap' command

2021-09-19 Thread Simon Glass 
This little series adds documentation and a few other tidy-ups to the
'sf' command.

It also provides a way to access memory-mapped SPI via the command line.

Changes in v4:
- Split out the 'const' change into a separate patch
- Show the 'sf probe' output in the examples

Changes in v3:
- Add configuration and return value also

Changes in v2:
- Explain why 'usage' cannot be const
- Many fixes as suggested by Heinrich

Simon Glass (5):
  command: Use a constant pointer for the help
  sf: Use const for the stage name
  sf: Tidy up code to avoid #ifdef
  sf: doc: Add documentation for the 'sf' command
  sf: Provide a command to access memory-mapped SPI

 arch/Kconfig|   2 +
 cmd/Kconfig |   8 ++
 cmd/sf.c|  67 +++---
 doc/usage/index.rst |   1 +
 doc/usage/sf.rst| 308 
 include/command.h   |   2 +-
 6 files changed, 369 insertions(+), 19 deletions(-)
 create mode 100644 doc/usage/sf.rst

-- 
2.33.0.464.g1972c5931b-goog

[RESEND PATCH v2 3/4] test: Allow tpm2 tests to run in parallel

2021-09-19 Thread Simon Glass 
These tests currently run in a particular sequence, with some of them
depending on the actions of earlier tests.

Add a check for sandbox and reset to a known state at the start of each
test, so that all tests can run in parallel.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 test/py/tests/test_tpm2.py | 52 +-
 1 file changed, 46 insertions(+), 6 deletions(-)

diff --git a/test/py/tests/test_tpm2.py b/test/py/tests/test_tpm2.py
index ac04f7191ec..64cf8cc5959 100644
--- a/test/py/tests/test_tpm2.py
+++ b/test/py/tests/test_tpm2.py
@@ -40,10 +40,14 @@ def force_init(u_boot_console, force=False):
 u_boot_console.run_command('tpm2 clear TPM2_RH_PLATFORM')
 u_boot_console.run_command('echo --- end of init ---')
 
+def is_sandbox(cons):
+# Array slice removes leading/trailing quotes.
+sys_arch = cons.config.buildconfig.get('config_sys_arch', 
'"sandbox"')[1:-1]
+return sys_arch == 'sandbox'
+
 @pytest.mark.buildconfigspec('cmd_tpm_v2')
 def test_tpm2_init(u_boot_console):
 """Init the software stack to use TPMv2 commands."""
-
 u_boot_console.run_command('tpm2 init')
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
@@ -54,17 +58,43 @@ def test_tpm2_startup(u_boot_console):
 
 Initiate the TPM internal state machine.
 """
+u_boot_console.run_command('tpm2 startup TPM2_SU_CLEAR')
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+def tpm2_sandbox_init(u_boot_console):
+"""Put sandbox back into a known state so we can run a test
+
+This allows all tests to run in parallel, since no test depends on another.
+"""
+u_boot_console.restart_uboot()
+u_boot_console.run_command('tpm2 init')
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
 
 u_boot_console.run_command('tpm2 startup TPM2_SU_CLEAR')
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
+u_boot_console.run_command('tpm2 self_test full')
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
 @pytest.mark.buildconfigspec('cmd_tpm_v2')
-def test_tpm2_self_test_full(u_boot_console):
+def test_tpm2_sandbox_self_test_full(u_boot_console):
 """Execute a TPM2_SelfTest (full) command.
 
 Ask the TPM to perform all self tests to also enable full capabilities.
 """
+if is_sandbox(u_boot_console):
+u_boot_console.restart_uboot()
+u_boot_console.run_command('tpm2 init')
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
+
+u_boot_console.run_command('tpm2 startup TPM2_SU_CLEAR')
+output = u_boot_console.run_command('echo $?')
+assert output.endswith('0')
 
 u_boot_console.run_command('tpm2 self_test full')
 output = u_boot_console.run_command('echo $?')
@@ -77,7 +107,8 @@ def test_tpm2_continue_self_test(u_boot_console):
 Ask the TPM to finish its self tests (alternative to the full test) in 
order
 to enter a fully operational state.
 """
-
+if is_sandbox(u_boot_console):
+tpm2_sandbox_init(u_boot_console)
 u_boot_console.run_command('tpm2 self_test continue')
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
@@ -94,6 +125,8 @@ def test_tpm2_clear(u_boot_console):
 not have a password set, otherwise this test will fail. ENDORSEMENT and
 PLATFORM hierarchies are also available.
 """
+if is_sandbox(u_boot_console):
+tpm2_sandbox_init(u_boot_console)
 
 u_boot_console.run_command('tpm2 clear TPM2_RH_LOCKOUT')
 output = u_boot_console.run_command('echo $?')
@@ -112,7 +145,8 @@ def test_tpm2_change_auth(u_boot_console):
 Use the LOCKOUT hierarchy for this. ENDORSEMENT and PLATFORM hierarchies 
are
 also available.
 """
-
+if is_sandbox(u_boot_console):
+tpm2_sandbox_init(u_boot_console)
 force_init(u_boot_console)
 
 u_boot_console.run_command('tpm2 change_auth TPM2_RH_LOCKOUT unicorn')
@@ -136,6 +170,8 @@ def test_tpm2_get_capability(u_boot_console):
 There is no expected default values because it would depend on the chip
 used. We can still save them in order to check they have changed later.
 """
+if is_sandbox(u_boot_console):
+tpm2_sandbox_init(u_boot_console)
 
 force_init(u_boot_console)
 ram = u_boot_utils.find_ram_base(u_boot_console)
@@ -158,7 +194,8 @@ def test_tpm2_dam_parameters(u_boot_console):
 the authentication, otherwise the lockout will be engaged after the first
 failed authentication attempt.
 """
-
+if is_sandbox(u_boot_console):
+tpm2_sandbox_init(u_boot_console)
 force_init(u_boot_console)
 ram = u_boot_utils.find_ram_base(u_boot_console)
 
@@ -181,6 +218,8 @@ def test_tpm2_pcr_read(u_boot_console):
 
 Perform a PCR read of the 0th PCR. Must be zero.
 """

[RESEND PATCH v2 4/4] doc: test: Explain how to run pytests in parallel

2021-09-19 Thread Simon Glass 
Add documentation for this so people can try it out. At present it does
not fully work.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add documentation for how to run parallel tests

 doc/develop/py_testing.rst | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst
index c4cecc0a01b..4f1e1f66e76 100644
--- a/doc/develop/py_testing.rst
+++ b/doc/develop/py_testing.rst
@@ -103,6 +103,36 @@ will be written to `${build_dir}/test-log.html`. This is 
best viewed in a web
 browser, but may be read directly as plain text, perhaps with the aid of the
 `html2text` utility.
 
+Running tests in parallel
+~
+
+Note: This does not fully work yet and is documented only so you can try to
+fix the problems.
+
+First install support for parallel tests::
+
+pip3 install pytest-xdist
+
+Then build sandbox in a suitable build directory. It is not possible to use
+the --build flag with xdist.
+
+Finally, run the tests in parallel using the -n flag::
+
+# build sandbox first, in a suitable build directory. It is not possible
+# to use the --build flag with -n
+test/py/test.py -B sandbox --build-dir /tmp/b/sandbox -q -k 'not slow' -n32
+
+At least the following non-slow tests are known to fail:
+
+- test_fit_ecdsa
+- test_bind_unbind_with_uclass
+- ut_dm_spi_flash
+- test_gpt_rename_partition
+- test_gpt_swap_partitions
+- test_pinmux_status
+- test_sqfs_load
+
+
 Testing under a debugger
 
 
-- 
2.33.0.464.g1972c5931b-goog

[RESEND PATCH v2 2/4] test: Allow hush tests to run in parallel

2021-09-19 Thread Simon Glass 
The -z tests don't really need to be part of the main set. Separate them
out so we can drop the test setup/cleans functions and thus run all tests
in parallel.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 test/py/tests/test_hush_if_test.py | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/test/py/tests/test_hush_if_test.py 
b/test/py/tests/test_hush_if_test.py
index d117921a6ac..37c1608bb22 100644
--- a/test/py/tests/test_hush_if_test.py
+++ b/test/py/tests/test_hush_if_test.py
@@ -119,11 +119,6 @@ subtests = (
 ('test ! ! aaa != aaa -o ! ! bbb = bbb', True),
 ('test ! ! aaa = aaa -o ! ! bbb != bbb', True),
 ('test ! ! aaa = aaa -o ! ! bbb = bbb', True),
-
-# -z operator.
-
-('test -z "$ut_var_nonexistent"', True),
-('test -z "$ut_var_exists"', False),
 )
 
 def exec_hush_if(u_boot_console, expr, result):
@@ -141,12 +136,6 @@ def exec_hush_if(u_boot_console, expr, result):
 response = u_boot_console.run_command(cmd)
 assert response.strip() == str(result).lower()
 
-def test_hush_if_test_setup(u_boot_console):
-"""Set up environment variables used during the "if" tests."""
-
-u_boot_console.run_command('setenv ut_var_nonexistent')
-u_boot_console.run_command('setenv ut_var_exists 1')
-
 @pytest.mark.buildconfigspec('cmd_echo')
 @pytest.mark.parametrize('expr,result', subtests)
 def test_hush_if_test(u_boot_console, expr, result):
@@ -154,9 +143,12 @@ def test_hush_if_test(u_boot_console, expr, result):
 
 exec_hush_if(u_boot_console, expr, result)
 
-def test_hush_if_test_teardown(u_boot_console):
-"""Clean up environment variables used during the "if" tests."""
-
+def test_hush_z(u_boot_console):
+"""Test the -z operator"""
+u_boot_console.run_command('setenv ut_var_nonexistent')
+u_boot_console.run_command('setenv ut_var_exists 1')
+exec_hush_if(u_boot_console, 'test -z "$ut_var_nonexistent"', True)
+exec_hush_if(u_boot_console, 'test -z "$ut_var_exists"', False)
 u_boot_console.run_command('setenv ut_var_exists')
 
 # We might test this on real filesystems via UMS, DFU, 'save', etc.
-- 
2.33.0.464.g1972c5931b-goog

[RESEND PATCH v2 1/4] test: Allow vboot tests to run in parallel

2021-09-19 Thread Simon Glass 
Update the tests to use separate working directories, so we can run them
in parallel. It also makes it possible to see the individual output files
after the tests have completed.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 test/py/tests/test_vboot.py | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
index 6dff6779d17..095e00cce36 100644
--- a/test/py/tests/test_vboot.py
+++ b/test/py/tests/test_vboot.py
@@ -24,6 +24,7 @@ For configuration verification:
 Tests run with both SHA1 and SHA256 hashing.
 """
 
+import os
 import shutil
 import struct
 import pytest
@@ -34,16 +35,16 @@ import vboot_evil
 # Only run the full suite on a few combinations, since it doesn't add any more
 # test coverage.
 TESTDATA = [
-['sha1', '', None, False, True],
-['sha1', '', '-E -p 0x1', False, False],
-['sha1', '-pss', None, False, False],
-['sha1', '-pss', '-E -p 0x1', False, False],
-['sha256', '', None, False, False],
-['sha256', '', '-E -p 0x1', False, False],
-['sha256', '-pss', None, False, False],
-['sha256', '-pss', '-E -p 0x1', False, False],
-['sha256', '-pss', None, True, False],
-['sha256', '-pss', '-E -p 0x1', True, True],
+['sha1-basic', 'sha1', '', None, False, True],
+['sha1-pad', 'sha1', '', '-E -p 0x1', False, False],
+['sha1-pss', 'sha1', '-pss', None, False, False],
+['sha1-pss-pad', 'sha1', '-pss', '-E -p 0x1', False, False],
+['sha256-basic', 'sha256', '', None, False, False],
+['sha256-pad', 'sha256', '', '-E -p 0x1', False, False],
+['sha256-pss', 'sha256', '-pss', None, False, False],
+['sha256-pss-pad', 'sha256', '-pss', '-E -p 0x1', False, False],
+['sha256-pss-required', 'sha256', '-pss', None, True, False],
+['sha256-pss-pad-required', 'sha256', '-pss', '-E -p 0x1', True, True],
 ]
 
 @pytest.mark.boardspec('sandbox')
@@ -52,9 +53,9 @@ TESTDATA = [
 @pytest.mark.requiredtool('fdtget')
 @pytest.mark.requiredtool('fdtput')
 @pytest.mark.requiredtool('openssl')
-@pytest.mark.parametrize("sha_algo,padding,sign_options,required,full_test",
+@pytest.mark.parametrize("name,sha_algo,padding,sign_options,required,full_test",
  TESTDATA)
-def test_vboot(u_boot_console, sha_algo, padding, sign_options, required,
+def test_vboot(u_boot_console, name, sha_algo, padding, sign_options, required,
full_test):
 """Test verified boot signing with mkimage and verification with 'bootm'.
 
@@ -365,7 +366,9 @@ def test_vboot(u_boot_console, sha_algo, padding, 
sign_options, required,
 run_bootm(sha_algo, 'multi required key', '', False)
 
 cons = u_boot_console
-tmpdir = cons.config.result_dir + '/'
+tmpdir = os.path.join(cons.config.result_dir, name) + '/'
+if not os.path.exists(tmpdir):
+os.mkdir(tmpdir)
 datadir = cons.config.source_dir + '/test/py/tests/vboot/'
 fit = '%stest.fit' % tmpdir
 mkimage = cons.config.build_dir + '/tools/mkimage'
-- 
2.33.0.464.g1972c5931b-goog

[RESEND PATCH v2 0/4] test: Try to deal with some co-dependent tests

2021-09-19 Thread Simon Glass 
Tests are supposed to be independent. With driver model tests, the
environment is reset before each test, which ensures that.

With Python tests there is no reset of the board between tests, since we
want to run all the tests as quickly as possible and without needing the
external scripts running constantly.

In principle the Python tests can be independent if they each put the
world back the way they found it, but it turns out that some are not.
This means that some tests cannot be run unless another test is run
first. It also means that tests cannot be run in parallel, e.g. on
sandbox.

This series fixes some of them. Those that remain:

   test_gpt_swap_partitions - not sure?
   test_pinmux_status - not sure?
   test_sqfs_load - cannot be run more than once!
   test_bind_unbind_with_uclass - relies on previous test

The last one would be much better done as a C test, so it doesn't have
to deal with the changing driver tree. There isn't a lot of value in
running the test on a real board, since sandbox should find any bugs
in driver model or the 'bind' command.

If the above can be resolved we can enable parallel tests. On my test
machine (32 threads) it reduces the time from 38 seconds to 7.5s

To use this feature, see the documentaiton added, or:

   pip3 install pytest-xdist

   test/py/test.py -B sandbox --build-dir /tmp/xx -q -k 'not slow' -n32

Changes in v2:
- Add documentation for how to run parallel tests

Simon Glass (4):
  test: Allow vboot tests to run in parallel
  test: Allow hush tests to run in parallel
  test: Allow tpm2 tests to run in parallel
  doc: test: Explain how to run pytests in parallel

 doc/develop/py_testing.rst | 30 +
 test/py/tests/test_hush_if_test.py | 20 
 test/py/tests/test_tpm2.py | 52 ++
 test/py/tests/test_vboot.py| 29 +
 4 files changed, 98 insertions(+), 33 deletions(-)

-- 
2.33.0.464.g1972c5931b-goog

Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

2021-09-19 Thread Mark Kettenis 
> From: Bin Meng 
> Date: Sun, 19 Sep 2021 09:17:07 +0800
> 
> Hi Mark,
> 
> On Sun, Sep 19, 2021 at 9:04 AM Bin Meng  wrote:
> >
> > Hi Mark,
> >
> > On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis  wrote:
> > >
> > > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > > Macs.  This builds a basic U-Boot that can be used as a payload
> > > for the m1n1 boot loader being developed by the Asahi Linux
> > > project.
> > >
> > > Signed-off-by: Mark Kettenis 
> > > ---
> > >  arch/arm/Kconfig|  22 
> > >  arch/arm/Makefile   |   1 +
> > >  arch/arm/mach-apple/Kconfig |  18 
> > >  arch/arm/mach-apple/Makefile|   4 +
> > >  arch/arm/mach-apple/board.c | 158 
> > >  arch/arm/mach-apple/lowlevel_init.S |  16 +++
> > >  configs/apple_m1_defconfig  |  14 +++
> > >  include/configs/apple.h |  38 +++
> > >  8 files changed, 271 insertions(+)
> > >  create mode 100644 arch/arm/mach-apple/Kconfig
> > >  create mode 100644 arch/arm/mach-apple/Makefile
> > >  create mode 100644 arch/arm/mach-apple/board.c
> > >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> > >  create mode 100644 configs/apple_m1_defconfig
> > >  create mode 100644 include/configs/apple.h
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index b5bd3284cd..7cdea1f615 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -895,6 +895,26 @@ config ARCH_NEXELL
> > > select DM
> > > select GPIO_EXTRA_HEADER
> > >
> > > +config ARCH_APPLE
> > > +   bool "Apple SoCs"
> > > +   select ARM64
> > > +   select LINUX_KERNEL_IMAGE_HEADER
> > > +   select POSITION_INDEPENDENT
> > > +   select BLK
> > > +   select DM
> > > +   select DM_KEYBOARD
> > > +   select DM_SERIAL
> > > +   select DM_USB
> > > +   select DM_VIDEO
> > > +   select CMD_USB
> > > +   select MISC
> > > +   select OF_CONTROL
> > > +   select OF_BOARD
> > > +   select USB
> > > +   imply CMD_DM
> > > +   imply CMD_GPT
> > > +   imply DISTRO_DEFAULTS
> > > +
> > >  config ARCH_OWL
> > > bool "Actions Semi OWL SoCs"
> > > select DM
> > > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
> > >   image headers.
> > >  endif
> > >
> > > +source "arch/arm/mach-apple/Kconfig"
> > > +
> > >  source "arch/arm/mach-aspeed/Kconfig"
> > >
> > >  source "arch/arm/mach-at91/Kconfig"
> > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > index c68e598a67..44178c204b 100644
> > > --- a/arch/arm/Makefile
> > > +++ b/arch/arm/Makefile
> > > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
> > >
> > >  # Machine directory name.  This list is sorted alphanumerically
> > >  # by CONFIG_* macro name.
> > > +machine-$(CONFIG_ARCH_APPLE)   += apple
> > >  machine-$(CONFIG_ARCH_ASPEED)  += aspeed
> > >  machine-$(CONFIG_ARCH_AT91)+= at91
> > >  machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> > > diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> > > new file mode 100644
> > > index 00..66cab91b2a
> > > --- /dev/null
> > > +++ b/arch/arm/mach-apple/Kconfig
> > > @@ -0,0 +1,18 @@
> > > +if ARCH_APPLE
> > > +
> > > +config SYS_TEXT_BASE
> > > +   default 0x
> > > +
> > > +config SYS_CONFIG_NAME
> > > +   default "apple"
> > > +
> > > +config SYS_SOC
> > > +   default "m1"
> > > +
> > > +config SYS_MALLOC_LEN
> > > +   default 0x400
> > > +
> > > +config SYS_MALLOC_F_LEN
> > > +   default 0x4000
> > > +
> > > +endif
> > > diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> > > new file mode 100644
> > > index 00..e74a8c9df1
> > > --- /dev/null
> > > +++ b/arch/arm/mach-apple/Makefile
> > > @@ -0,0 +1,4 @@
> > > +# SPDX-License-Identifier: GPL-2.0+
> > > +
> > > +obj-y += board.o
> > > +obj-y += lowlevel_init.o
> > > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > > new file mode 100644
> > > index 00..0c8b35292e
> > > --- /dev/null
> > > +++ b/arch/arm/mach-apple/board.c
> > > @@ -0,0 +1,158 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * (C) Copyright 2021 Mark Kettenis 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > > +static struct mm_region apple_mem_map[] = {
> > > +   {
> > > +   /* I/O */
> > > +   .virt = 0x2,
> > > +   .phys = 0x2,
> > > +   .size = 8UL * SZ_1G,
> > > +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > > +PTE_BLOCK_NON_SHARE |
> > > +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > > +   }, {
> > > +   /* I/O */
> > > +   .virt = 0x5,
> > > +

Re: [PATCH 2/5] serial: s5p: Add Apple M1 support

2021-09-19 Thread Mark Kettenis 
> From: Bin Meng 
> Date: Sun, 19 Sep 2021 09:11:06 +0800
> 
> Hi Mark,
> 
> On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis  wrote:
> >
> > Apple M1 SoCs include an S5L UART which is a variant of the S5P
> > UART.  Add support for this variant and enable it by default
> > on Apple SoCs.
> >
> > Signed-off-by: Mark Kettenis 
> > ---
> >  arch/arm/include/asm/arch-m1/clk.h  | 11 
> >  arch/arm/include/asm/arch-m1/uart.h | 41 +
> >  arch/arm/mach-apple/board.c |  5 
> >  drivers/serial/Kconfig  |  2 +-
> >  drivers/serial/serial_s5p.c | 22 
> >  5 files changed, 80 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/include/asm/arch-m1/clk.h
> >  create mode 100644 arch/arm/include/asm/arch-m1/uart.h
> >
> > diff --git a/arch/arm/include/asm/arch-m1/clk.h 
> > b/arch/arm/include/asm/arch-m1/clk.h
> > new file mode 100644
> > index 00..f4326d0c0f
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-m1/clk.h
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2021 Mark Kettenis 
> > + */
> > +
> > +#ifndef __ASM_ARM_ARCH_CLK_H_
> > +#define __ASM_ARM_ARCH_CLK_H_
> > +
> > +unsigned long get_uart_clk(int dev_index);
> > +
> > +#endif
> > diff --git a/arch/arm/include/asm/arch-m1/uart.h 
> > b/arch/arm/include/asm/arch-m1/uart.h
> > new file mode 100644
> > index 00..d2a17a221e
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-m1/uart.h
> > @@ -0,0 +1,41 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * (C) Copyright 2009 Samsung Electronics
> > + * Minkyu Kang 
> > + * Heungjun Kim 
> > + */
> > +
> > +#ifndef __ASM_ARCH_UART_H_
> > +#define __ASM_ARCH_UART_H_
> > +
> > +#ifndef __ASSEMBLY__
> > +/* baudrate rest value */
> > +union br_rest {
> > +   unsigned short  slot;   /* udivslot */
> > +   unsigned char   value;  /* ufracval */
> > +};
> > +
> > +struct s5p_uart {
> > +   unsigned intulcon;
> > +   unsigned intucon;
> > +   unsigned intufcon;
> > +   unsigned intumcon;
> > +   unsigned intutrstat;
> > +   unsigned intuerstat;
> > +   unsigned intufstat;
> > +   unsigned intumstat;
> > +   unsigned intutxh;
> > +   unsigned inturxh;
> > +   unsigned intubrdiv;
> > +   union br_rest   rest;
> > +   unsigned char   res3[0x3fd0];
> > +};
> 
> This does not look correct. This should be declared in the s5p UART
> driver header instead of SoC's

Well, this is the status quo for this driver.  There are several
variations of the hardware with slightly different register layouts
and the header file trick is how that is handled.

> > +
> > +static inline int s5p_uart_divslot(void)
> > +{
> > +   return 0;
> > +}
> > +
> > +#endif /* __ASSEMBLY__ */
> > +
> > +#endif
> > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > index 0c8b35292e..8bc5c2f69e 100644
> > --- a/arch/arm/mach-apple/board.c
> > +++ b/arch/arm/mach-apple/board.c
> > @@ -156,3 +156,8 @@ ulong board_get_usable_ram_top(ulong total_size)
> >  */
> > return 0x98000;
> >  }
> > +
> > +unsigned long get_uart_clk(int dev_index)
> > +{
> > +   return 2400;
> > +}
> > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > index 93348c0929..c3ac773929 100644
> > --- a/drivers/serial/Kconfig
> > +++ b/drivers/serial/Kconfig
> > @@ -719,7 +719,7 @@ config ROCKCHIP_SERIAL
> >
> >  config S5P_SERIAL
> > bool "Support for Samsung S5P UART"
> > -   depends on ARCH_EXYNOS || ARCH_S5PC1XX
> > +   depends on ARCH_APPLE || ARCH_EXYNOS || ARCH_S5PC1XX
> > default y
> > help
> >   Select this to enable Samsung S5P UART support.
> > diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
> > index 6d09952a5d..eb770d9b62 100644
> > --- a/drivers/serial/serial_s5p.c
> > +++ b/drivers/serial/serial_s5p.c
> > @@ -21,12 +21,21 @@
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > +#ifdef CONFIG_ARCH_APPLE
> > +#define RX_FIFO_COUNT_SHIFT0
> > +#define RX_FIFO_COUNT_MASK (0xf << RX_FIFO_COUNT_SHIFT)
> > +#define RX_FIFO_FULL   (1 << 8)
> > +#define TX_FIFO_COUNT_SHIFT4
> > +#define TX_FIFO_COUNT_MASK (0xf << TX_FIFO_COUNT_SHIFT)
> > +#define TX_FIFO_FULL   (1 << 9)
> 
> So different bit positions for RX/TX FIFIO register but still it is
> s5p compatible, strange ...

Yeah, the Apple hardware is based on an older variant of the s5p that
had a smaller FIFO.  The size of the FIFO was increased somewhere
along the way and the bits were moved...

> > +#else
> >  #define RX_FIFO_COUNT_SHIFT0
> >  #define RX_FIFO_COUNT_MASK (0xff << RX_FIFO_COUNT_SHIFT)
> >  #define RX_FIFO_FULL   (1 << 8)
> >  #define TX_FIFO_COUNT_SHIFT16
> >  #define TX_FIFO_COUNT_MASK (0xff << TX_FIFO_COUNT_SHIFT)
> >  #define TX_FIFO_FULL   (1 << 24)
> >

Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

2021-09-19 Thread Mark Kettenis 
> From: Bin Meng 
> Date: Sun, 19 Sep 2021 09:04:56 +0800

Hi Bin,

Thanks for taking a look.

> Hi Mark,
> 
> On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis  wrote:
> >
> > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > Macs.  This builds a basic U-Boot that can be used as a payload
> > for the m1n1 boot loader being developed by the Asahi Linux
> > project.
> >
> > Signed-off-by: Mark Kettenis 
> > ---
> >  arch/arm/Kconfig|  22 
> >  arch/arm/Makefile   |   1 +
> >  arch/arm/mach-apple/Kconfig |  18 
> >  arch/arm/mach-apple/Makefile|   4 +
> >  arch/arm/mach-apple/board.c | 158 
> >  arch/arm/mach-apple/lowlevel_init.S |  16 +++
> >  configs/apple_m1_defconfig  |  14 +++
> >  include/configs/apple.h |  38 +++
> >  8 files changed, 271 insertions(+)
> >  create mode 100644 arch/arm/mach-apple/Kconfig
> >  create mode 100644 arch/arm/mach-apple/Makefile
> >  create mode 100644 arch/arm/mach-apple/board.c
> >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> >  create mode 100644 configs/apple_m1_defconfig
> >  create mode 100644 include/configs/apple.h
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index b5bd3284cd..7cdea1f615 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -895,6 +895,26 @@ config ARCH_NEXELL
> > select DM
> > select GPIO_EXTRA_HEADER
> >
> > +config ARCH_APPLE
> > +   bool "Apple SoCs"
> > +   select ARM64
> > +   select LINUX_KERNEL_IMAGE_HEADER
> > +   select POSITION_INDEPENDENT
> > +   select BLK
> > +   select DM
> > +   select DM_KEYBOARD
> > +   select DM_SERIAL
> > +   select DM_USB
> > +   select DM_VIDEO
> > +   select CMD_USB
> > +   select MISC
> > +   select OF_CONTROL
> > +   select OF_BOARD
> > +   select USB
> > +   imply CMD_DM
> > +   imply CMD_GPT
> > +   imply DISTRO_DEFAULTS
> > +
> >  config ARCH_OWL
> > bool "Actions Semi OWL SoCs"
> > select DM
> > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
> >   image headers.
> >  endif
> >
> > +source "arch/arm/mach-apple/Kconfig"
> > +
> >  source "arch/arm/mach-aspeed/Kconfig"
> >
> >  source "arch/arm/mach-at91/Kconfig"
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index c68e598a67..44178c204b 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
> >
> >  # Machine directory name.  This list is sorted alphanumerically
> >  # by CONFIG_* macro name.
> > +machine-$(CONFIG_ARCH_APPLE)   += apple
> >  machine-$(CONFIG_ARCH_ASPEED)  += aspeed
> >  machine-$(CONFIG_ARCH_AT91)+= at91
> >  machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> > diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> > new file mode 100644
> > index 00..66cab91b2a
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/Kconfig
> > @@ -0,0 +1,18 @@
> > +if ARCH_APPLE
> > +
> > +config SYS_TEXT_BASE
> > +   default 0x
> > +
> > +config SYS_CONFIG_NAME
> > +   default "apple"
> > +
> > +config SYS_SOC
> > +   default "m1"
> > +
> > +config SYS_MALLOC_LEN
> > +   default 0x400
> > +
> > +config SYS_MALLOC_F_LEN
> > +   default 0x4000
> > +
> > +endif
> > diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> > new file mode 100644
> > index 00..e74a8c9df1
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +obj-y += board.o
> > +obj-y += lowlevel_init.o
> > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > new file mode 100644
> > index 00..0c8b35292e
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/board.c
> > @@ -0,0 +1,158 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2021 Mark Kettenis 
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static struct mm_region apple_mem_map[] = {
> > +   {
> > +   /* I/O */
> > +   .virt = 0x2,
> > +   .phys = 0x2,
> > +   .size = 8UL * SZ_1G,
> > +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +PTE_BLOCK_NON_SHARE |
> > +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > +   }, {
> > +   /* I/O */
> > +   .virt = 0x5,
> > +   .phys = 0x5,
> > +   .size = 2UL * SZ_1G,
> > +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +PTE_BLOCK_NON_SHARE |
> > +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > +   }, {
> > +   /* I/O */
> > +   .virt =

[PATCH v4 2/5] doc: Move environment documentation to rST

2021-09-19 Thread Simon Glass 
Move this from the README to rST format.

Drop i2cfast since it is obviously obsolete and breaks the formatting.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Add new patch to move environment documentation to rST

 README| 328 
 doc/usage/environment.rst | 382 ++
 doc/usage/index.rst   |   1 +
 3 files changed, 383 insertions(+), 328 deletions(-)
 create mode 100644 doc/usage/environment.rst

diff --git a/README b/README
index a3f81e4aed0..31eaf2f5f81 100644
--- a/README
+++ b/README
@@ -3180,334 +3180,6 @@ TODO.
 For now: just type "help ".
 
 
-Environment Variables:
-==
-
-U-Boot supports user configuration using Environment Variables which
-can be made persistent by saving to Flash memory.
-
-Environment Variables are set using "setenv", printed using
-"printenv", and saved to Flash using "saveenv". Using "setenv"
-without a value can be used to delete a variable from the
-environment. As long as you don't save the environment you are
-working with an in-memory copy. In case the Flash area containing the
-environment is erased by accident, a default environment is provided.
-
-Some configuration options can be set using Environment Variables.
-
-List of environment variables (most likely not complete):
-
-  baudrate - see CONFIG_BAUDRATE
-
-  bootdelay- see CONFIG_BOOTDELAY
-
-  bootcmd  - see CONFIG_BOOTCOMMAND
-
-  bootargs - Boot arguments when booting an RTOS image
-
-  bootfile - Name of the image to load with TFTP
-
-  bootm_low- Memory range available for image processing in the bootm
- command can be restricted. This variable is given as
- a hexadecimal number and defines lowest address allowed
- for use by the bootm command. See also "bootm_size"
- environment variable. Address defined by "bootm_low" is
- also the base of the initial memory mapping for the Linux
- kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and
- bootm_mapsize.
-
-  bootm_mapsize - Size of the initial memory mapping for the Linux kernel.
- This variable is given as a hexadecimal number and it
- defines the size of the memory region starting at base
- address bootm_low that is accessible by the Linux kernel
- during early boot.  If unset, CONFIG_SYS_BOOTMAPSZ is used
- as the default value if it is defined, and bootm_size is
- used otherwise.
-
-  bootm_size   - Memory range available for image processing in the bootm
- command can be restricted. This variable is given as
- a hexadecimal number and defines the size of the region
- allowed for use by the bootm command. See also "bootm_low"
- environment variable.
-
-  bootstopkeysha256, bootdelaykey, bootstopkey - See README.autoboot
-
-  updatefile   - Location of the software update file on a TFTP server, used
- by the automatic software update feature. Please refer to
- documentation in doc/README.update for more details.
-
-  autoload - if set to "no" (any string beginning with 'n'),
- "bootp" will just load perform a lookup of the
- configuration from the BOOTP server, but not try to
- load any image using TFTP
-
-  autostart- if set to "yes", an image loaded using the "bootp",
- "rarpboot", "tftpboot" or "diskboot" commands will
- be automatically started (by internally calling
- "bootm")
-
- If set to "no", a standalone image passed to the
- "bootm" command will be copied to the load address
- (and eventually uncompressed), but NOT be started.
- This can be used to load and uncompress arbitrary
- data.
-
-  fdt_high - if set this restricts the maximum address that the
- flattened device tree will be copied into upon boot.
- For example, if you have a system with 1 GB memory
- at physical address 0x1000, while Linux kernel
- only recognizes the first 704 MB as low memory, you
- may need to set fdt_high as 0x3C00 to have the
- device tree blob be copied to the maximum address
- of the 704 MB low memory, so that Linux kernel can
- access it during the boot procedure.
-
- If this is set to the special value 0x then
- the fdt will not be copied at all on boot.  For this
- to work it must reside in writable memory, have
- sufficient padding on the end of it for u-boot to
- add the information it needs into it, and the memory

[PATCH v4 5/5] sandbox: Use a text-based environment

2021-09-19 Thread Simon Glass 
Use a text file for the environment instead of the #define settings.

Signed-off-by: Simon Glass 
---

(no changes since v3)

Changes in v3:
- Add new patch to use a text-based environment for sandbox

 board/sandbox/env/sandbox.env | 25 +
 include/configs/sandbox.h | 29 -
 2 files changed, 25 insertions(+), 29 deletions(-)
 create mode 100644 board/sandbox/env/sandbox.env

diff --git a/board/sandbox/env/sandbox.env b/board/sandbox/env/sandbox.env
new file mode 100644
index 000..0f8d95b8db0
--- /dev/null
+++ b/board/sandbox/env/sandbox.env
@@ -0,0 +1,25 @@
+stdin=serial
+#ifdef CONFIG_SANDBOX_SDL
+stdin+=,cros-ec-keyb,usbkbd
+#endif
+stdout=serial,vidconsole
+stderr=serial,vidconsole
+
+ethaddr=00:00:11:22:33:44
+eth2addr=00:00:11:22:33:48
+eth3addr=00:00:11:22:33:45
+eth4addr=00:00:11:22:33:48
+eth5addr=00:00:11:22:33:46
+eth6addr=00:00:11:22:33:47
+ipaddr=1.2.3.4
+
+/*
+ * These are used for distro boot which is not supported. But once bootmethod
+ * is provided these will be used again.
+ */
+bootm_size=0x1000
+kernel_addr_r=0x100
+fdt_addr_r=0xc0
+ramdisk_addr_r=0x200
+scriptaddr=0x1000
+pxefile_addr_r=0x2000
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index fb5109b6b96..7468722e285 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -70,37 +70,8 @@
 #define CONFIG_LCD_BMP_RLE8
 
 #define CONFIG_KEYBOARD
-
-#define SANDBOX_SERIAL_SETTINGS
"stdin=serial,cros-ec-keyb,usbkbd\0" \
-   "stdout=serial,vidconsole\0" \
-   "stderr=serial,vidconsole\0"
-#else
-#define SANDBOX_SERIAL_SETTINGS"stdin=serial\0" \
-   "stdout=serial,vidconsole\0" \
-   "stderr=serial,vidconsole\0"
 #endif
 
-#define SANDBOX_ETH_SETTINGS   "ethaddr=00:00:11:22:33:44\0" \
-   "eth2addr=00:00:11:22:33:48\0" \
-   "eth3addr=00:00:11:22:33:45\0" \
-   "eth4addr=00:00:11:22:33:48\0" \
-   "eth5addr=00:00:11:22:33:46\0" \
-   "eth6addr=00:00:11:22:33:47\0" \
-   "ipaddr=1.2.3.4\0"
-
-#define MEM_LAYOUT_ENV_SETTINGS \
-   "bootm_size=0x1000\0" \
-   "kernel_addr_r=0x100\0" \
-   "fdt_addr_r=0xc0\0" \
-   "ramdisk_addr_r=0x200\0" \
-   "scriptaddr=0x1000\0" \
-   "pxefile_addr_r=0x2000\0"
-
-#define CONFIG_EXTRA_ENV_SETTINGS \
-   SANDBOX_SERIAL_SETTINGS \
-   SANDBOX_ETH_SETTINGS \
-   MEM_LAYOUT_ENV_SETTINGS
-
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_SYS_IDE_MAXBUS  1
 #define CONFIG_SYS_ATA_IDE0_OFFSET 0
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 3/5] env: Allow U-Boot scripts to be placed in a .env file

2021-09-19 Thread Simon Glass 
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in a board//env
directory called .env (or common.env if you want the same
environment for all boards).

The environment variables should be of the form "var=value". Values can
extend to multiple lines. See the README under 'Environment Variables:'
for more information and an example.

Comments are not permitted in the environment with this commit.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Move this from being part of configuring U-Boot to part of building it
- Don't put the environment in autoconf.mk as it is not needed
- Add documentation in rST format instead of README
- Drop mention of import/export
- Update awk script to ignore blank lines, as generated by clang

Changes in v3:
- Adjust Makefile to generate the .inc and .h files in separate fules
- Add more detail in the README about the format of .env files
- Improve the comment about " in the awk script
- Correctly terminate environment files with \n

Changes in v2:
- Move .env file from include/configs to board/
- Use awk script to process environment since it is much easier on the brain
- Add information and updated example script to README
- Add dependency rule so that the environment is rebuilt when it changes

 Makefile  | 34 ++-
 config.mk |  2 ++
 doc/usage/environment.rst | 41 
 env/embedded.c|  1 +
 include/env_default.h |  8 +++
 scripts/env2string.awk| 49 +++
 6 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 scripts/env2string.awk

diff --git a/Makefile b/Makefile
index 3014788e14e..9e44af2ccb1 100644
--- a/Makefile
+++ b/Makefile
@@ -513,6 +513,7 @@ version_h := include/generated/version_autogenerated.h
 timestamp_h := include/generated/timestamp_autogenerated.h
 defaultenv_h := include/generated/defaultenv_autogenerated.h
 dt_h := include/generated/dt.h
+env_h := include/generated/environment.h
 
 no-dot-config-targets := clean clobber mrproper distclean \
 help %docs check% coccicheck \
@@ -1802,6 +1803,37 @@ quiet_cmd_sym ?= SYM $@
 u-boot.sym: u-boot FORCE
$(call if_changed,sym)
 
+# We expect '.env' but failing that will use 'common.env'
+ENV_DIR := $(if $(VENDOR),$(VENDOR)/env,$(BOARD)/env)
+ENV_FILE_BOARD := $(srctree)/board/${ENV_DIR}/$(BOARD).env
+ENV_FILE_COMMON := $(srctree)/board/${ENV_DIR}/common.env
+ENV_FILE := $(if $(wildcard 
$(ENV_FILE_BOARD)),$(ENV_FILE_BOARD),$(ENV_FILE_COMMON))
+
+# Run the environment text file through the preprocessor
+quiet_cmd_gen_envp = ENVP$@
+  cmd_gen_envp = \
+   if [ -f "$(ENV_FILE)" ]; then \
+   cat $(ENV_FILE) >$@; \
+   else \
+   echo -n >$@ ; \
+   fi
+
+# Regenerate the environment if it changes
+# We use 'wildcard' since the file is not required to exist (at present), in
+# which case we don't want this dependency, but instead should create an empty
+# file
+include/generated/environment.in: \
+   $(if $(wildcard $(ENV_FILE)),$(wildcard $(ENV_FILE)),FORCE)
+   $(call cmd,gen_envp)
+
+quiet_cmd_gen_envt = ENVT$@
+  cmd_gen_envt = \
+   echo -n "\#define CONFIG_EXTRA_ENV_TEXT " >$@; \
+   awk -f $(srctree)/scripts/env2string.awk $< >>$@
+
+$(env_h): include/generated/environment.in
+   $(call cmd,gen_envt)
+
 # The actual objects are generated when descending,
 # make sure no implicit rule kicks in
 $(sort $(u-boot-init) $(u-boot-main)): $(u-boot-dirs) ;
@@ -1857,7 +1889,7 @@ endif
 # prepare2 creates a makefile if using a separate output directory
 prepare2: prepare3 outputmakefile cfg
 
-prepare1: prepare2 $(version_h) $(timestamp_h) $(dt_h) \
+prepare1: prepare2 $(version_h) $(timestamp_h) $(dt_h) $(env_h) \
include/config/auto.conf
 ifeq ($(wildcard $(LDSCRIPT)),)
@echo >&2 "  Could not find linker script."
diff --git a/config.mk b/config.mk
index 7bb1fd4ed1b..2595aed218b 100644
--- a/config.mk
+++ b/config.mk
@@ -50,8 +50,10 @@ endif
 ifneq ($(BOARD),)
 ifdef  VENDOR
 BOARDDIR = $(VENDOR)/$(BOARD)
+ENVDIR=${vendor}/env
 else
 BOARDDIR = $(BOARD)
+ENVDIR=${board}/env
 endif
 endif
 ifdef  BOARD
diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index be785a8f717..81130d17f85 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -14,6 +14,47 @@ environment. As long as you don't save the environment you 
are
 working with an in-memory copy. In case the Flash area containing the
 environment is erased

[PATCH v4 0/5] env: Allow environment in text files

2021-09-19 Thread Simon Glass 
One barrier to completing the 7-year-long Kconfig migration is that
the default environment is implemented using ad-hoc CONFIG options.
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS.

It is not really feasible to move the environment to Kconfig as it is
hundreds of lines of text in some cases.

Even considering the current situation, it is painful to add large
amounts of text to the config-header file and dealing with quoting and
newlines is harder than it should be. It would be better if we could just
type the script into a text file and have it included by U-Boot.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in a board//env
directory called .env (or common.env if you want the same
environment for all boards).

The environment variables should be of the form "var=value". Values can
extend to multiple lines. This series converts the existing environment
documentation to rST and updates it to explain how to use this.

Note: this series was originally sent eight years ago:

https://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git-send-email-...@chromium.org/

It has been updated to work with Kconfig, etc. Some review comments in
that patch were infeasible so I have not addressed them. I would like
this series to be considered independently, on its merits.

Rather than deal with the complexity of rewriting the distro-boot
script, this is disabled for sandbox. The forthcoming bootmethod approach
should provide the same functionality without needing the complex
scripting in the environment.

Migration needs more thought, although it can be done later. It may be
possible to do migrate automatically, using buildman to extract the
built-in environmnent from the ELF file.

This would produce a pretty ugly conversion though, since it would drop
all the intermediate variables used to create the environment.

Better would be to parse the config.h file, figure out the components of
CONFIG_EXTRA_ENV_SETTINGS then output these as separate pieces in the
file. It is not clear how easy that would be, nor whether the result would
be very pretty. Also the __stringify() macro needs to be handled somehow.

This series is available at u-boot-dm/env-working

Comments welcome.

Changes in v4:
- Add new patch to move environment documentation to rST
- Move this from being part of configuring U-Boot to part of building it
- Don't put the environment in autoconf.mk as it is not needed
- Add documentation in rST format instead of README
- Drop mention of import/export
- Update awk script to ignore blank lines, as generated by clang
- Add documentation in rST format instead of README

Changes in v3:
- Adjust Makefile to generate the .inc and .h files in separate fules
- Add more detail in the README about the format of .env files
- Improve the comment about " in the awk script
- Correctly terminate environment files with \n
- Define __UBOOT_CONFIG__ when collecting environment files
- Add new patch to use a text-based environment for sandbox

Changes in v2:
- Move .env file from include/configs to board/
- Use awk script to process environment since it is much easier on the brain
- Add information and updated example script to README
- Add dependency rule so that the environment is rebuilt when it changes
- Add separate patch to enable C preprocessor for environment files
- Enable var+=value form to simplify composing variables in multiple steps

Simon Glass (5):
  sandbox: Drop distro_boot
  doc: Move environment documentation to rST
  env: Allow U-Boot scripts to be placed in a .env file
  env: Allow environment files to use the C preprocessor
  sandbox: Use a text-based environment

 Makefile  |  39 ++-
 README| 328 --
 board/sandbox/env/sandbox.env |  25 ++
 config.mk |   2 +
 doc/usage/environment.rst | 431 ++
 doc/usage/index.rst   |   1 +
 env/embedded.c|   1 +
 include/configs/sandbox.h |  40 
 include/env_default.h |   8 +
 scripts/env2string.awk|  55 +
 10 files changed, 561 insertions(+), 369 deletions(-)
 create mode 100644 board/sandbox/env/sandbox.env
 create mode 100644 doc/usage/environment.rst
 create mode 100644 scripts/env2string.awk

-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 4/5] env: Allow environment files to use the C preprocessor

2021-09-19 Thread Simon Glass 
In many cases environment variables need access to the U-Boot CONFIG
variables to select different options. Enable this so that the environment
scripts can be as useful as the ones currently in the board config files.

Also support += to allow variables to be appended to. This is needed when
using the preprocessor.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Add documentation in rST format instead of README

Changes in v3:
- Define __UBOOT_CONFIG__ when collecting environment files

Changes in v2:
- Add separate patch to enable C preprocessor for environment files
- Enable var+=value form to simplify composing variables in multiple steps

 Makefile  | 7 ++-
 doc/usage/environment.rst | 8 
 scripts/env2string.awk| 6 ++
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 9e44af2ccb1..6315de93506 100644
--- a/Makefile
+++ b/Makefile
@@ -1813,7 +1813,12 @@ ENV_FILE := $(if $(wildcard 
$(ENV_FILE_BOARD)),$(ENV_FILE_BOARD),$(ENV_FILE_COMM
 quiet_cmd_gen_envp = ENVP$@
   cmd_gen_envp = \
if [ -f "$(ENV_FILE)" ]; then \
-   cat $(ENV_FILE) >$@; \
+   $(CPP) -P $(CFLAGS) -x assembler-with-cpp -D__ASSEMBLY__ \
+   -D__UBOOT_CONFIG__ \
+   -I . -I include \
+   -I $(srctree)/include -include include/config.h \
+   -I$(srctree)/arch/$(ARCH)/include \
+   $(ENV_FILE) -o $@; \
else \
echo -n >$@ ; \
fi
diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 81130d17f85..5df55cdfa8f 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -31,6 +31,14 @@ and has an equals sign immediately afterwards. Spaces before 
the = are not
 permitted. It is a good idea to indent your scripts so that only the 'var='
 appears at the start of a line.
 
+To add additional text to a variable you can use var+=value. This text is
+merged into the variable during the make process and made available as a
+single value to U-Boot.
+
+This file can include C-style comments. Blank lines and multi-line
+variables are supported, and you can use normal C preprocessor directives
+and CONFIG defines from your board config also.
+
 For example, for snapper9260 you would create a text file called
 `board/bluewater/env/snapper9260.env` containing the environment text.
 
diff --git a/scripts/env2string.awk b/scripts/env2string.awk
index f442d3b7c44..9851925d877 100644
--- a/scripts/env2string.awk
+++ b/scripts/env2string.awk
@@ -29,6 +29,12 @@ NF {
}
var = arr[1]
env = arr[2]
+
+   # Deal with +=
+   if (match(var, "(.*)[+]$", var_arr)) {
+   var = var_arr[1]
+   env = vars[var] env
+   }
} else {
# Change newline to \n
env = env "\\n" $0;
-- 
2.33.0.464.g1972c5931b-goog

[PATCH v4 1/5] sandbox: Drop distro_boot

2021-09-19 Thread Simon Glass 
This is a complicated set of #defines and it is painful to convert to a
text file. We can (once pending patches are applied) provide the same
functionality with bootmethod. Drop this for sandbox to allow conversion
to a text-file environment.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 include/configs/sandbox.h | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 8eeccdd4264..fb5109b6b96 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -55,16 +55,6 @@
 #define CONFIG_SYS_BAUDRATE_TABLE  {4800, 9600, 19200, 38400, 57600,\
115200}
 
-#define BOOT_TARGET_DEVICES(func) \
-   func(HOST, host, 1) \
-   func(HOST, host, 0)
-
-#ifdef __ASSEMBLY__
-#define BOOTENV
-#else
-#include 
-#endif
-
 #define CONFIG_KEEP_SERVERADDR
 #define CONFIG_UDP_CHECKSUM
 #define CONFIG_TIMESTAMP
@@ -109,7 +99,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
SANDBOX_SERIAL_SETTINGS \
SANDBOX_ETH_SETTINGS \
-   BOOTENV \
MEM_LAYOUT_ENV_SETTINGS
 
 #ifndef CONFIG_SPL_BUILD
-- 
2.33.0.464.g1972c5931b-goog

Re: Please pull u-boot-dm

2021-09-19 Thread Tom Rini 
On Sat, Sep 18, 2021 at 05:34:38AM -0600, Simon Glass wrote:

> Hi Tom,
> 
> This is a revert of the EFI patches as mentioned on the mailing list.
> I believe this is the best way forward and avoids the current, flawed
> approach from getting into an official release and making it difficult
> to back out.
> 
> 
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/9154
> 
> 
> 
> The following changes since commit d0b8c9a231d6e5fba881960c9fcfcc444f1812f9:
> 
>   Merge branch '2021-09-17-TI-platform-updates' (2021-09-17 18:51:57 -0400)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-dm.git tags/dm-pull-18sep21
> 
> for you to fetch changes up to 47a25e81d35c8d801cae9089de90c9ffea083409:
> 
>   Revert "efi_capsule: Move signature from DTB to .rodata" (2021-09-18
> 03:47:50 -0600)
> 
> 
> Revert the public-key-embedded-in-executable patches so this does not form
> part of an official release before it is agreed.
> 
> 

As the general consensus is that everyone involved here is committed to
spending the time to come up with a technical solution to the problem
that everyone can agree on, I've applied this PR to master.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v2 3/3] ARM: amlogic: add JetHub D1/H1 docs

2021-09-19 Thread Vyacheslav Bocharov 
Fix doc/board/amlogic/index.rst:
- Add S905W to S905X column.
- Add JetHub devices to the corresponding columns.
- Fix tabs to spaces for table alignment

Add doc/board/amlogic files:
- jethub-j100.rst
- jethub-j80.rst

Signed-off-by: Vyacheslav Bocharov 
Reviewed-by: Neil Armstrong 
---
 doc/board/amlogic/index.rst   | 128 +++---
 doc/board/amlogic/jethub-j100.rst | 108 +
 doc/board/amlogic/jethub-j80.rst  |  97 ++
 3 files changed, 270 insertions(+), 63 deletions(-)
 create mode 100644 doc/board/amlogic/jethub-j100.rst
 create mode 100644 doc/board/amlogic/jethub-j80.rst

diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 2913ab281a..c18f1b7e71 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -10,69 +10,69 @@ An up-do-date matrix is also available on: 
http://linux-meson.com
 
 This matrix concerns the actual source code version.
 
-+---+---+-+--+++-+--+
-|  | S905  | S905X   | S912 | 
A113X  | S905X2 | S922X   | S905X3   |
-|  |   | S805X   | S905D|  
  | S905D2 | A311D   | S905D3   |
-|  |   | |  |  
  | S905Y2 | |  |
-+===+===+=+==+++=+==+
-| Boards   | Odroid-C2 | P212| Khadas 
VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
-|  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
-|  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || GT-King/Pro | Odroid-C4|
-|  | P201  | LibreTech-AC v2 |  |  
  || GSKing-X| Odroid-HC4   |
-|   |   | |  | 
   || | BananaPi-M5  |
-+---+---+-+--+++-+--+
-| UART | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Pinctrl/GPIO | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Clock Control| **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| PWM  | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Reset Control| **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Infrared Decoder | No| No  | No   | 
No | No | No  | No   |
-+---+---+-+--+++-+--+
-| Ethernet | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Multi-core   | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Fuse access  | **Yes**   | **Yes** |**Yes**   
|**Yes** |**Yes** |**Yes**  | **Yes**  |
-+---+---+-+--+++-+--+
-| SPI (FC) | **Yes**   | **Yes** | **Yes**  | 
**Yes**|**Yes**

[PATCH v2 2/3] ARM: amlogic: add JetHub D1/H1 device support

2021-09-19 Thread Vyacheslav Bocharov 
Add support for new home automation devices.

JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation controller 
with the following features:
- DIN Rail Mounting case
- Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 512Mb/1GB DDR3
- 8/16GB eMMC flash
- 1 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
Bluetooth 4.2.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- 2 x gpio LEDS
- GPIO user Button
- 1 x 1-Wire
- 2 x RS-485
- 4 x dry contact digital GPIO inputs
- 3 x relay GPIO outputs
- DC source with a voltage of 9 to 56 V / Passive POE

JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation controller 
with the following features:
- Square plastic case
- Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 1GB DDR3
- 8/16GB eMMC flash
- 2 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- MicroSD 2.x/3.x/4.x DS/HS cards.
- 1 x gpio LED
- ADC user Button
- DC source 5V microUSB with serial console

Patches from:
- JetHub H1
  https://lore.kernel.org/r/20210915085715.1134940-4-ad...@lexina.in
  https://git.kernel.org/amlogic/c/abfaae24ecf3e7f00508b60fa05e2b6789b8f607
- JetHub D1
  https://lore.kernel.org/r/20210915085715.1134940-5-ad...@lexina.in
  https://git.kernel.org/amlogic/c/8e279fb2903990cc6296ec56b3b80b2f854b6c79

Signed-off-by: Vyacheslav Bocharov 
Reviewed-by: Neil Armstrong 
---
 arch/arm/dts/Makefile |   2 +
 .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
 .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
 board/amlogic/jethub-j80/MAINTAINERS  |   6 +
 board/amlogic/jethub-j80/Makefile |   6 +
 board/amlogic/jethub-j80/jethub-j80.c |  68 
 configs/jethub_j100_defconfig |  55 +++
 configs/jethub_j80_defconfig  |  63 +++
 8 files changed, 802 insertions(+)
 create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
 create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
 create mode 100644 board/amlogic/jethub-j80/Makefile
 create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
 create mode 100644 configs/jethub_j100_defconfig
 create mode 100644 configs/jethub_j80_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f0160d2dc0..d1893a9812 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,10 +169,12 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxl-s905x-libretech-cc-v2.dtb \
meson-gxl-s905x-khadas-vim.dtb \
meson-gxl-s905d-libretech-pc.dtb \
+   meson-gxl-s905w-jethome-jethub-j80.dtb \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
meson-gxm-wetek-core2.dtb \
meson-axg-s400.dtb \
+   meson-axg-jethome-jethub-j100.dtb \
meson-g12a-u200.dtb \
meson-g12a-sei510.dtb \
meson-g12b-gtking.dtb \
diff --git a/arch/arm/dts/meson-axg-jethome-jethub-j100.dts 
b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
new file mode 100644
index 00..5783732dc6
--- /dev/null
+++ b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Vyacheslav Bocharov 
+ * Copyright (c) 2020 JetHome
+ * Author: Aleksandr Kazantsev 
+ * Author: Alexey Shevelkin 
+ * Author: Vyacheslav Bocharov 
+ */
+
+/dts-v1/;
+
+#include "meson-axg.dtsi"
+#include 
+#include 
+
+/ {
+   compatible = "jethome,jethub-j100", "amlogic,a113d", 
"amlogic,meson-axg";
+   model = "JetHome JetHub J100";
+   aliases {
+   serial0 = _AO;   /* Console */
+   serial1 = _AO_B; /* External UART (Wireless Module) */
+   ethernet0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   /* 1024MB RAM */
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+
+   reserved-memory {
+   linux,cma {
+   size = <0x0 0x40>;
+   };
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   vcc_5v: regulator-vcc_5v {
+   compatible = "regulator-fixed";
+

[PATCH v2 0/3] ARM: meson: add support for JetHub D1/H1

2021-09-19 Thread Vyacheslav Bocharov 
Add support for new home automation devices manufactured by JetHome.
Patches prepared for use with the "ARM: meson: Sync Amlogic DT from Linux 5.14" 
patch series by Neil Armstrong

JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation controller 
with the following features:
- DIN Rail Mounting case
- Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 512Mb/1GB DDR3
- 8/16GB eMMC flash
- 1 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
Bluetooth 4.2.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- 2 x gpio LEDS
- GPIO user Button
- 1 x 1-Wire
- 2 x RS-485
- 4 x dry contact digital GPIO inputs
- 3 x relay GPIO outputs
- DC source with a voltage of 9 to 56 V / Passive POE

JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation controller 
with the following features:
- Square plastic case
- Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 1GB DDR3
- 8/16GB eMMC flash
- 2 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- MicroSD 2.x/3.x/4.x DS/HS cards.
- 1 x gpio LED
- ADC user Button
- DC source 5V microUSB with serial console

Changes from v1:
- fix BOOT_TARGET_DEVICES in jethub.h (patch 1/3)
- add lore URLs to description (patch 2/3)

Signed-off-by: Vyacheslav Bocharov 

Vyacheslav Bocharov (3):
  ARM: amlogic: add JetHub common config header
  ARM: amlogic: add JetHub D1/H1 device support
  ARM: amlogic: add JetHub D1/H1 docs

 arch/arm/dts/Makefile |   2 +
 .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
 .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
 board/amlogic/jethub-j80/MAINTAINERS  |   6 +
 board/amlogic/jethub-j80/Makefile |   6 +
 board/amlogic/jethub-j80/jethub-j80.c |  68 
 configs/jethub_j100_defconfig |  55 +++
 configs/jethub_j80_defconfig  |  63 +++
 doc/board/amlogic/index.rst   | 128 ---
 doc/board/amlogic/jethub-j100.rst | 108 ++
 doc/board/amlogic/jethub-j80.rst  |  97 +
 include/configs/jethub.h  |  40 ++
 12 files changed, 1112 insertions(+), 63 deletions(-)
 create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
 create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
 create mode 100644 board/amlogic/jethub-j80/Makefile
 create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
 create mode 100644 configs/jethub_j100_defconfig
 create mode 100644 configs/jethub_j80_defconfig
 create mode 100644 doc/board/amlogic/jethub-j100.rst
 create mode 100644 doc/board/amlogic/jethub-j80.rst
 create mode 100644 include/configs/jethub.h

-- 
2.30.2

[PATCH v2 1/3] ARM: amlogic: add JetHub common config header

2021-09-19 Thread Vyacheslav Bocharov 
JetHub devices uses its own boot sequence with "rescue" button

Signed-off-by: Vyacheslav Bocharov 
---
 include/configs/jethub.h | 40 
 1 file changed, 40 insertions(+)
 create mode 100644 include/configs/jethub.h

diff --git a/include/configs/jethub.h b/include/configs/jethub.h
new file mode 100644
index 00..35f85095ac
--- /dev/null
+++ b/include/configs/jethub.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Configuration for JetHome devices
+ * Copyright (C) 2021 Vyacheslav Bocharov
+ * Author: Vyacheslav Bocharov 
+ */
+
+#ifndef __JETHUB_CONFIG_H
+#define __JETHUB_CONFIG_H
+
+#if defined(CONFIG_MESON_AXG)
+#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
+   "bootcmd_rescue=" \
+   "if gpio input 10; then " \
+   "run bootcmd_usb0;" \
+   "fi;\0"
+#else
+#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
+   "bootcmd_rescue=" \
+   "if test \"${userbutton}\" = \"true\"; then " \
+   "run bootcmd_mmc0; " \
+   "fi;\0"
+#endif
+
+#define BOOTENV_DEV_NAME_RESCUE(devtypeu, devtypel, instance) \
+   "rescue "
+
+#ifndef BOOT_TARGET_DEVICES
+#define BOOT_TARGET_DEVICES(func) \
+   func(RESCUE, rescue, na) \
+   func(MMC, mmc, 1) \
+   func(MMC, mmc, 0) \
+   BOOT_TARGET_DEVICES_USB(func) \
+   func(PXE, pxe, na) \
+   func(DHCP, dhcp, na)
+#endif
+
+#include 
+
+#endif /* __JETHUB_CONFIG_H */
-- 
2.30.2

[PATCH] board: fsl_validate: Fix Double free Issue

2021-09-19 Thread Kshitiz Varshney 
Remove Double free issue from calc_img_key_hash() and
calc_esbchdr_esbc_hash() function.
Verified the secure boot changes using lx2162aqds board.

Signed-off-by: Kshitiz Varshney 
---
 board/freescale/common/fsl_validate.c | 28 ++-
 drivers/crypto/fsl/fsl_hash.c | 14 +++---
 2 files changed, 13 insertions(+), 29 deletions(-)

diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 5cec0131f2..9a22fb8054 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -499,12 +499,8 @@ static int calc_img_key_hash(struct fsl_secboot_img_priv 
*img)
return ret;
 
ret = algo->hash_init(algo, );
-   if (ret) {
-   if (ctx)
-   free(ctx);
+   if (ret)
return ret;
-   }
-
/* Update hash for ESBC key */
 #ifdef CONFIG_KEY_REVOCATION
if (check_srk(img)) {
@@ -519,15 +515,12 @@ static int calc_img_key_hash(struct fsl_secboot_img_priv 
*img)
img->img_key, img->key_len, 1);
if (ret)
return ret;
-
/* Copy hash at destination buffer */
ret = algo->hash_finish(algo, ctx, hash_val, algo->digest_size);
if (ret) {
-   if (ctx)
-   free(ctx);
+   free(ctx);
return ret;
}
-
for (i = 0; i < SHA256_BYTES; i++)
img->img_key_hash[i] = hash_val[i];
 
@@ -554,18 +547,14 @@ static int calc_esbchdr_esbc_hash(struct 
fsl_secboot_img_priv *img)
 
ret = algo->hash_init(algo, );
/* Copy hash at destination buffer */
-   if (ret) {
-   free(ctx);
+   if (ret)
return ret;
-   }
 
/* Update hash for CSF Header */
ret = algo->hash_update(algo, ctx,
(u8 *)>hdr, sizeof(struct fsl_secboot_img_hdr), 0);
-   if (ret) {
-   free(ctx);
+   if (ret)
return ret;
-   }
 
/* Update the hash with that of srk table if srk flag is 1
 * If IE Table is selected, key is not added in the hash
@@ -592,22 +581,17 @@ static int calc_esbchdr_esbc_hash(struct 
fsl_secboot_img_priv *img)
key_hash = 1;
}
 #endif
-   if (ret) {
-   free(ctx);
+   if (ret)
return ret;
-   }
if (!key_hash) {
free(ctx);
return ERROR_KEY_TABLE_NOT_FOUND;
}
-
/* Update hash for actual Image */
ret = algo->hash_update(algo, ctx,
(u8 *)(*(img->img_addr_ptr)), img->img_size, 1);
-   if (ret) {
-   free(ctx);
+   if (ret)
return ret;
-   }
 
/* Copy hash at destination buffer */
ret = algo->hash_finish(algo, ctx, hash_val, algo->digest_size);
diff --git a/drivers/crypto/fsl/fsl_hash.c b/drivers/crypto/fsl/fsl_hash.c
index 61f953e8a6..43daf1cbe3 100644
--- a/drivers/crypto/fsl/fsl_hash.c
+++ b/drivers/crypto/fsl/fsl_hash.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2014 Freescale Semiconductor, Inc.
- *
+ * Copyright 2021 NXP
  */
 
 #include 
@@ -120,8 +120,8 @@ static int caam_hash_update(void *hash_ctx, const void *buf,
  * Perform progressive hashing on the given buffer and copy hash at
  * destination buffer
  *
- * The context is freed after completion of hash operation.
- *
+ * The context is freed after successful completion of hash operation.
+ * In case of failure, context is not freed.
  * @hash_ctx: Pointer to the context for hashing
  * @dest_buf: Pointer to the destination buffer where hash is to be copied
  * @size: Size of the buffer being hashed
@@ -136,7 +136,6 @@ static int caam_hash_finish(void *hash_ctx, void *dest_buf,
int i = 0, ret = 0;
 
if (size < driver_hash[caam_algo].digestsize) {
-   free(ctx);
return -EINVAL;
}
 
@@ -152,11 +151,12 @@ static int caam_hash_finish(void *hash_ctx, void 
*dest_buf,
 
ret = run_descriptor_jr(ctx->sha_desc);
 
-   if (ret)
+   if (ret) {
debug("Error %x\n", ret);
-   else
+   return ret;
+   } else {
memcpy(dest_buf, ctx->hash, sizeof(ctx->hash));
-
+   }
free(ctx);
return ret;
 }
-- 
2.25.1

Re: [PATCH 3/3] ARM: amlogic: add JetHub D1/H1 docs

2021-09-19 Thread Neil Armstrong 
Hi,

Le 19/09/2021 à 10:18, Vyacheslav Bocharov a écrit :
> Fix doc/board/amlogic/index.rst:
> - Add S905W to S905X column.
> - Add JetHub devices to the corresponding columns.
> - Fix tabs to spaces for table alignment
> 
> Add doc/board/amlogic files:
> - jethub-j100.rst
> - jethub-j80.rst
> 
> Signed-off-by: Vyacheslav Bocharov 
> ---
>  doc/board/amlogic/index.rst   | 128 +++---
>  doc/board/amlogic/jethub-j100.rst | 108 +
>  doc/board/amlogic/jethub-j80.rst  |  97 ++
>  3 files changed, 270 insertions(+), 63 deletions(-)
>  create mode 100644 doc/board/amlogic/jethub-j100.rst
>  create mode 100644 doc/board/amlogic/jethub-j80.rst
> 
> diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
> index 2913ab281a..c18f1b7e71 100644
> --- a/doc/board/amlogic/index.rst
> +++ b/doc/board/amlogic/index.rst
> @@ -10,69 +10,69 @@ An up-do-date matrix is also available on: 
> http://linux-meson.com
>  
>  This matrix concerns the actual source code version.
>  
> -+---+---+-+--+++-+--+
> -|| S905  | S905X   | S912
>  | A113X  | S905X2 | S922X   | S905X3   |
> -||   | S805X   | S905D|  
>   | S905D2 | A311D   | S905D3   |
> -||   | |  |  
>   | S905Y2 | |  |
> -+===+===+=+==+++=+==+
> -| Boards | Odroid-C2 | P212| Khadas 
> VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
> -|| Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
>   | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
> -|| P200  | LibreTech-CC v1 | WeTek Core2  |  
>   || GT-King/Pro | Odroid-C4|
> -|| P201  | LibreTech-AC v2 |  |  
>   || GSKing-X| Odroid-HC4   |
> -|   |   | |  
> ||| | BananaPi-M5  |
> -+---+---+-+--+++-+--+
> -| UART   | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Pinctrl/GPIO   | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Clock Control  | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| PWM| **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Reset Control  | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Infrared Decoder   | No| No  | No  
>  | No | No | No  | No   |
> -+---+---+-+--+++-+--+
> -| Ethernet   | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Multi-core | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Fuse access| **Yes**   | **Yes** |**Yes**  
>  |**Yes** |**Yes** |**Yes**  | **Yes**  |
>

Re: [PATCH 2/3] ARM: amlogic: add JetHub D1/H1 device support

2021-09-19 Thread Neil Armstrong 
Hi,

Le 19/09/2021 à 10:18, Vyacheslav Bocharov a écrit :
> Add support for new home automation devices.
> 
> JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation 
> controller with the following features:
> - DIN Rail Mounting case
> - Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
> - no video out
> - 512Mb/1GB DDR3
> - 8/16GB eMMC flash
> - 1 x USB 2.0
> - 1 x 10/100Mbps ethernet
> - WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
> Bluetooth 4.2.
> - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
> Zigbee 3.0 support.
> - 2 x gpio LEDS
> - GPIO user Button
> - 1 x 1-Wire
> - 2 x RS-485
> - 4 x dry contact digital GPIO inputs
> - 3 x relay GPIO outputs
> - DC source with a voltage of 9 to 56 V / Passive POE
> 
> JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation 
> controller with the following features:
> - Square plastic case
> - Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
> - no video out
> - 1GB DDR3
> - 8/16GB eMMC flash
> - 2 x USB 2.0
> - 1 x 10/100Mbps ethernet
> - WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
> - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
> Zigbee 3.0 support.
> - MicroSD 2.x/3.x/4.x DS/HS cards.
> - 1 x gpio LED
> - ADC user Button
> - DC source 5V microUSB with serial console
> 
> Patches from:
> - JetHub H1
>   https://git.kernel.org/amlogic/c/abfaae24ecf3e7f00508b60fa05e2b6789b8f607
> - JetHub D1
>   https://git.kernel.org/amlogic/c/8e279fb2903990cc6296ec56b3b80b2f854b6c79

Could you also add the lore URLs:
https://lore.kernel.org/r/20210915085715.1134940-4-ad...@lexina.in
and
https://lore.kernel.org/r/20210915085715.1134940-5-ad...@lexina.in

> 
> Signed-off-by: Vyacheslav Bocharov 
> ---
>  arch/arm/dts/Makefile |   2 +
>  .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
>  .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
>  board/amlogic/jethub-j80/MAINTAINERS  |   6 +
>  board/amlogic/jethub-j80/Makefile |   6 +
>  board/amlogic/jethub-j80/jethub-j80.c |  68 
>  configs/jethub_j100_defconfig |  55 +++
>  configs/jethub_j80_defconfig  |  63 +++
>  8 files changed, 802 insertions(+)
>  create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
>  create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
>  create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
>  create mode 100644 board/amlogic/jethub-j80/Makefile
>  create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
>  create mode 100644 configs/jethub_j100_defconfig
>  create mode 100644 configs/jethub_j80_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f0160d2dc0..d1893a9812 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -169,10 +169,12 @@ dtb-$(CONFIG_ARCH_MESON) += \
>   meson-gxl-s905x-libretech-cc-v2.dtb \
>   meson-gxl-s905x-khadas-vim.dtb \
>   meson-gxl-s905d-libretech-pc.dtb \
> + meson-gxl-s905w-jethome-jethub-j80.dtb \
>   meson-gxm-khadas-vim2.dtb \
>   meson-gxm-s912-libretech-pc.dtb \
>   meson-gxm-wetek-core2.dtb \
>   meson-axg-s400.dtb \
> + meson-axg-jethome-jethub-j100.dtb \
>   meson-g12a-u200.dtb \
>   meson-g12a-sei510.dtb \
>   meson-g12b-gtking.dtb \
> diff --git a/arch/arm/dts/meson-axg-jethome-jethub-j100.dts 
> b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
> new file mode 100644
> index 00..5783732dc6
> --- /dev/null
> +++ b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
> @@ -0,0 +1,361 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Vyacheslav Bocharov 
> + * Copyright (c) 2020 JetHome
> + * Author: Aleksandr Kazantsev 
> + * Author: Alexey Shevelkin 
> + * Author: Vyacheslav Bocharov 
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-axg.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + compatible = "jethome,jethub-j100", "amlogic,a113d", 
> "amlogic,meson-axg";
> + model = "JetHome JetHub J100";
> + aliases {
> + serial0 = _AO;   /* Console */
> + serial1 = _AO_B; /* External UART (Wireless Module) */
> + ethernet0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + /* 1024MB RAM */
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x4000>;
> + };
> +
> + reserved-memory {
> + linux,cma {
> + size = <0x0 0x40>;
> + };
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_3v3: regulator-vcc_3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3";
> +

Re: [PATCH 1/3] ARM: amlogic: add JetHub common config header

2021-09-19 Thread Neil Armstrong 
Hi,

Le 19/09/2021 à 10:18, Vyacheslav Bocharov a écrit :
> JetHub devices uses its own boot sequence with "rescue" button.
> Add custom config header file that corrects boot order.
> 
> Signed-off-by: Vyacheslav Bocharov 
> ---
>  include/configs/jethub.h | 40 
>  1 file changed, 40 insertions(+)
>  create mode 100644 include/configs/jethub.h
> 
> diff --git a/include/configs/jethub.h b/include/configs/jethub.h
> new file mode 100644
> index 00..09264f91a5
> --- /dev/null
> +++ b/include/configs/jethub.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Configuration for JetHome devices
> + * Copyright (C) 2021 Vyacheslav Bocharov
> + * Author: Vyacheslav Bocharov 
> + */
> +
> +#ifndef __JETHUB_CONFIG_H
> +#define __JETHUB_CONFIG_H
> +
> +#if defined(CONFIG_MESON_AXG)
> +#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
> + "bootcmd_rescue=" \
> + "if gpio input 10; then " \
> + "run bootcmd_usb0;" \
> + "fi;\0"
> +#else
> +#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
> + "bootcmd_rescue=" \
> + "if test \"${userbutton}\" = \"true\"; then " \
> + "run bootcmd_mmc0; " \
> + "fi;\0"
> +#endif
> +
> +#define BOOTENV_DEV_NAME_RESCUE(devtypeu, devtypel, instance) \
> + "rescue "
> +
> +#ifndef BOOT_TARGET_DEVICES
> +#define BOOT_TARGET_DEVICES(func) \
> + func(RESCUE, mmc, 1) \

This should be:
func(RESCUE, rescue, na) \

> + func(MMC, mmc, 1) \
> + func(MMC, mmc, 0) \
> + BOOT_TARGET_DEVICES_USB(func) \
> + func(PXE, pxe, na) \
> + func(DHCP, dhcp, na)
> +#endif
> +
> +#include 
> +
> +#endif /* __JETHUB_CONFIG_H */
> 

Neil

Re: [PATCH] usb: xhci-dwc3: Add support for USB 3.1 controllers

2021-09-19 Thread Bin Meng 
Hi Marek,

On Thu, Sep 16, 2021 at 10:08 PM Bin Meng  wrote:
>
> On Thu, Sep 16, 2021 at 10:00 PM Mark Kettenis  wrote:
> >
> > This adds support for the DWC_sub31 controllers such as those
> > found on Apple's M1 SoC.  This version of the controller
> > seems to work fine with the existing driver.
> >
> > Signed-off-by: Mark Kettenis 
> > ---
> >  drivers/usb/host/xhci-dwc3.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

I see this is assigned to me on patchwork. Would you like this to go
via the x86 tree?

Regards,
Bin

[PATCH 2/3] ARM: amlogic: add JetHub D1/H1 device support

2021-09-19 Thread Vyacheslav Bocharov 
Add support for new home automation devices.

JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation controller 
with the following features:
- DIN Rail Mounting case
- Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 512Mb/1GB DDR3
- 8/16GB eMMC flash
- 1 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
Bluetooth 4.2.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- 2 x gpio LEDS
- GPIO user Button
- 1 x 1-Wire
- 2 x RS-485
- 4 x dry contact digital GPIO inputs
- 3 x relay GPIO outputs
- DC source with a voltage of 9 to 56 V / Passive POE

JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation controller 
with the following features:
- Square plastic case
- Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 1GB DDR3
- 8/16GB eMMC flash
- 2 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- MicroSD 2.x/3.x/4.x DS/HS cards.
- 1 x gpio LED
- ADC user Button
- DC source 5V microUSB with serial console

Patches from:
- JetHub H1
  https://git.kernel.org/amlogic/c/abfaae24ecf3e7f00508b60fa05e2b6789b8f607
- JetHub D1
  https://git.kernel.org/amlogic/c/8e279fb2903990cc6296ec56b3b80b2f854b6c79

Signed-off-by: Vyacheslav Bocharov 
---
 arch/arm/dts/Makefile |   2 +
 .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
 .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
 board/amlogic/jethub-j80/MAINTAINERS  |   6 +
 board/amlogic/jethub-j80/Makefile |   6 +
 board/amlogic/jethub-j80/jethub-j80.c |  68 
 configs/jethub_j100_defconfig |  55 +++
 configs/jethub_j80_defconfig  |  63 +++
 8 files changed, 802 insertions(+)
 create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
 create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
 create mode 100644 board/amlogic/jethub-j80/Makefile
 create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
 create mode 100644 configs/jethub_j100_defconfig
 create mode 100644 configs/jethub_j80_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f0160d2dc0..d1893a9812 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,10 +169,12 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxl-s905x-libretech-cc-v2.dtb \
meson-gxl-s905x-khadas-vim.dtb \
meson-gxl-s905d-libretech-pc.dtb \
+   meson-gxl-s905w-jethome-jethub-j80.dtb \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
meson-gxm-wetek-core2.dtb \
meson-axg-s400.dtb \
+   meson-axg-jethome-jethub-j100.dtb \
meson-g12a-u200.dtb \
meson-g12a-sei510.dtb \
meson-g12b-gtking.dtb \
diff --git a/arch/arm/dts/meson-axg-jethome-jethub-j100.dts 
b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
new file mode 100644
index 00..5783732dc6
--- /dev/null
+++ b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Vyacheslav Bocharov 
+ * Copyright (c) 2020 JetHome
+ * Author: Aleksandr Kazantsev 
+ * Author: Alexey Shevelkin 
+ * Author: Vyacheslav Bocharov 
+ */
+
+/dts-v1/;
+
+#include "meson-axg.dtsi"
+#include 
+#include 
+
+/ {
+   compatible = "jethome,jethub-j100", "amlogic,a113d", 
"amlogic,meson-axg";
+   model = "JetHome JetHub J100";
+   aliases {
+   serial0 = _AO;   /* Console */
+   serial1 = _AO_B; /* External UART (Wireless Module) */
+   ethernet0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   /* 1024MB RAM */
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+
+   reserved-memory {
+   linux,cma {
+   size = <0x0 0x40>;
+   };
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   vcc_5v: regulator-vcc_5v {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+

[PATCH 3/3] ARM: amlogic: add JetHub D1/H1 docs

2021-09-19 Thread Vyacheslav Bocharov 
Fix doc/board/amlogic/index.rst:
- Add S905W to S905X column.
- Add JetHub devices to the corresponding columns.
- Fix tabs to spaces for table alignment

Add doc/board/amlogic files:
- jethub-j100.rst
- jethub-j80.rst

Signed-off-by: Vyacheslav Bocharov 
---
 doc/board/amlogic/index.rst   | 128 +++---
 doc/board/amlogic/jethub-j100.rst | 108 +
 doc/board/amlogic/jethub-j80.rst  |  97 ++
 3 files changed, 270 insertions(+), 63 deletions(-)
 create mode 100644 doc/board/amlogic/jethub-j100.rst
 create mode 100644 doc/board/amlogic/jethub-j80.rst

diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 2913ab281a..c18f1b7e71 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -10,69 +10,69 @@ An up-do-date matrix is also available on: 
http://linux-meson.com
 
 This matrix concerns the actual source code version.
 
-+---+---+-+--+++-+--+
-|  | S905  | S905X   | S912 | 
A113X  | S905X2 | S922X   | S905X3   |
-|  |   | S805X   | S905D|  
  | S905D2 | A311D   | S905D3   |
-|  |   | |  |  
  | S905Y2 | |  |
-+===+===+=+==+++=+==+
-| Boards   | Odroid-C2 | P212| Khadas 
VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
-|  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
-|  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || GT-King/Pro | Odroid-C4|
-|  | P201  | LibreTech-AC v2 |  |  
  || GSKing-X| Odroid-HC4   |
-|   |   | |  | 
   || | BananaPi-M5  |
-+---+---+-+--+++-+--+
-| UART | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Pinctrl/GPIO | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Clock Control| **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| PWM  | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Reset Control| **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Infrared Decoder | No| No  | No   | 
No | No | No  | No   |
-+---+---+-+--+++-+--+
-| Ethernet | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Multi-core   | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Fuse access  | **Yes**   | **Yes** |**Yes**   
|**Yes** |**Yes** |**Yes**  | **Yes**  |
-+---+---+-+--+++-+--+
-| SPI (FC) | **Yes**   | **Yes** | **Yes**  | 
**Yes**|**Yes** | **Yes** | No

[PATCH 0/3] ARM: meson: add support for JetHub D1/H1

2021-09-19 Thread Vyacheslav Bocharov 
Add support for new home automation devices manufactured by JetHome.
Patches prepared for use with the "ARM: meson: Sync Amlogic DT from Linux 5.14" 
patch series by Neil Armstrong

JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation controller 
with the following features:
- DIN Rail Mounting case
- Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 512Mb/1GB DDR3
- 8/16GB eMMC flash
- 1 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
Bluetooth 4.2.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- 2 x gpio LEDS
- GPIO user Button
- 1 x 1-Wire
- 2 x RS-485
- 4 x dry contact digital GPIO inputs
- 3 x relay GPIO outputs
- DC source with a voltage of 9 to 56 V / Passive POE

JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation controller 
with the following features:
- Square plastic case
- Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 1GB DDR3
- 8/16GB eMMC flash
- 2 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- MicroSD 2.x/3.x/4.x DS/HS cards.
- 1 x gpio LED
- ADC user Button
- DC source 5V microUSB with serial console

Signed-off-by: Vyacheslav Bocharov 

Vyacheslav Bocharov (3):
  ARM: amlogic: add JetHub common config header
  ARM: amlogic: add JetHub D1/H1 device support
  ARM: amlogic: add JetHub D1/H1 docs

 arch/arm/dts/Makefile |   2 +
 .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
 .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
 board/amlogic/jethub-j80/MAINTAINERS  |   6 +
 board/amlogic/jethub-j80/Makefile |   6 +
 board/amlogic/jethub-j80/jethub-j80.c |  68 
 configs/jethub_j100_defconfig |  55 +++
 configs/jethub_j80_defconfig  |  63 +++
 doc/board/amlogic/index.rst   | 128 ---
 doc/board/amlogic/jethub-j100.rst | 108 ++
 doc/board/amlogic/jethub-j80.rst  |  97 +
 include/configs/jethub.h  |  40 ++
 12 files changed, 1112 insertions(+), 63 deletions(-)
 create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
 create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
 create mode 100644 board/amlogic/jethub-j80/Makefile
 create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
 create mode 100644 configs/jethub_j100_defconfig
 create mode 100644 configs/jethub_j80_defconfig
 create mode 100644 doc/board/amlogic/jethub-j100.rst
 create mode 100644 doc/board/amlogic/jethub-j80.rst
 create mode 100644 include/configs/jethub.h

-- 
2.30.2

[PATCH 1/3] ARM: amlogic: add JetHub common config header

2021-09-19 Thread Vyacheslav Bocharov 
JetHub devices uses its own boot sequence with "rescue" button.
Add custom config header file that corrects boot order.

Signed-off-by: Vyacheslav Bocharov 
---
 include/configs/jethub.h | 40 
 1 file changed, 40 insertions(+)
 create mode 100644 include/configs/jethub.h

diff --git a/include/configs/jethub.h b/include/configs/jethub.h
new file mode 100644
index 00..09264f91a5
--- /dev/null
+++ b/include/configs/jethub.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Configuration for JetHome devices
+ * Copyright (C) 2021 Vyacheslav Bocharov
+ * Author: Vyacheslav Bocharov 
+ */
+
+#ifndef __JETHUB_CONFIG_H
+#define __JETHUB_CONFIG_H
+
+#if defined(CONFIG_MESON_AXG)
+#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
+   "bootcmd_rescue=" \
+   "if gpio input 10; then " \
+   "run bootcmd_usb0;" \
+   "fi;\0"
+#else
+#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
+   "bootcmd_rescue=" \
+   "if test \"${userbutton}\" = \"true\"; then " \
+   "run bootcmd_mmc0; " \
+   "fi;\0"
+#endif
+
+#define BOOTENV_DEV_NAME_RESCUE(devtypeu, devtypel, instance) \
+   "rescue "
+
+#ifndef BOOT_TARGET_DEVICES
+#define BOOT_TARGET_DEVICES(func) \
+   func(RESCUE, mmc, 1) \
+   func(MMC, mmc, 1) \
+   func(MMC, mmc, 0) \
+   BOOT_TARGET_DEVICES_USB(func) \
+   func(PXE, pxe, na) \
+   func(DHCP, dhcp, na)
+#endif
+
+#include 
+
+#endif /* __JETHUB_CONFIG_H */
-- 
2.30.2

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

2021-09-19 Thread Bin Meng 
On Sun, Sep 12, 2021 at 2:27 AM Andy Shevchenko
 wrote:
>
> 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(+)
>

applied to u-boot-x86, thanks!

Re: [PATCH v1 1/1] x86: edison: Mark eMMC non-removable

2021-09-19 Thread Bin Meng 
On Fri, Sep 10, 2021 at 7:35 PM Bin Meng  wrote:
>
> On Fri, Sep 10, 2021 at 3:59 PM Andy Shevchenko
>  wrote:
> >
> > eMMC is non-removable on Intel Edison board. Fix the DTS accordingly.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/dts/edison.dts | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!

Re: [PATCH 2/2] net: tsec: read the phy-mode property as fallback to phy-connection-type

2021-09-19 Thread Bin Meng 
On Sat, Sep 18, 2021 at 8:47 PM Vladimir Oltean  wrote:
>
> The two should be equivalent, but at the moment some platforms
> (ls1021a-tsn.dts) use phy-mode only, which is not parsed.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/tsec.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng

Re: [PATCH 1/2] net: tsec: only call tsec_get_interface as fallback to DT-specified PHY mode

2021-09-19 Thread Bin Meng 
On Sat, Sep 18, 2021 at 8:47 PM Vladimir Oltean  wrote:
>
> Currently the init_phy function may overwrite the priv->interface
> property, since it calls tsec_get_interface which tries to determine it
> dynamically based on default register values in ECNTRL.
>
> Let's do that only if phy-connection-type happens to not be defined in
> the device tree.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/tsec.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng