date:20230620

Re: [EXTERNAL] Re: [PATCH 0/2] Mitigate warnings occurred during compilation

2023-06-20 Thread Nikhil M Jain


Hi Tom,

On 19/06/23 18:48, Tom Rini wrote:

On Mon, Jun 19, 2023 at 03:14:01PM +0530, Nikhil M Jain wrote:

This patch series aims at mitigating warnings occurred during
compilation by including required header files and using appropriate
types for variables which are typecasted.

Nikhil M Jain (2):
   board: ti: am62x: evm: Include necessary header files
   common: splash_source: Fix type casting errors.

  board/ti/am62x/evm.c   | 1 +
  common/splash_source.c | 4 ++--
  2 files changed, 3 insertions(+), 2 deletions(-)


What is this on top of, or what changes have been made to stock
defconfigs to make these problems appear?

These errors appear when you enable CONFIG_SPLASH_SOURCE and CONFIG_FIT 
is enabled.


Thanks,
Nikhil

Re: [PATCH 5/7] Makefile: Add a target for building capsules

2023-06-20 Thread Sughosh Ganu

hi Simon,

On Mon, 19 Jun 2023 at 18:07, Simon Glass  wrote:
>
> Hi Sughosh,
>
> On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu  wrote:
> >
> > hi Simon,
> >
> > On Thu, 15 Jun 2023 at 14:44, Simon Glass  wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu  
> > > wrote:
> > > >
> > > > Add a target for building EFI capsules. The capsule parameters are
> > > > specified through a config file, and the path to the config file is
> > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config file is
> > > > not specified, the command only builds tools.
> > > >
> > > > Signed-off-by: Sughosh Ganu 
> > > > ---
> > > >  Makefile | 9 +
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 10bfaa52ad..96db29aa77 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb
> > > >  dts/dt.dtb: u-boot
> > > > $(Q)$(MAKE) $(build)=dts dtbs
> > > >
> > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@
> > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@
> > > > +
> > > > +PHONY += capsule
> > > > +capsule: tools
> > > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"")
> > > > +   $(call cmd,mkeficapsule)
> > > > +endif
> > > > +
> > > >  quiet_cmd_copy = COPY$@
> > > >cmd_copy = cp $< $@
> > > >
> > > > --
> > > > 2.34.1
> > > >
> > >
> > > We should be using binman to build images...you seem to be building
> > > something in parallel with that. Can you please take a look at binman?
> >
> > Again, I had explored using binman for this task. The one issue where
> > I find the above flow better is that I can simply build my payload
> > image(s) followed by 'make capsule' to generate the capsules for
> > earlier generated images. In it's current form, I don't see an easy
> > way to enforce this dependency in binman when I want to build the
> > payload followed by generation of capsules. I did see the mention of
> > encapsulating an entry within another dependent entry, but I think
> > that makes the implementation more complex than it ought to be.
> >
> > I think it is much easier to use the make flow to generate the images
> > followed by capsules, instead of tweaking the binman node to first
> > generate the payload images, followed by enabling the capsule node to
> > build the capsules. If there is an easy way of enforcing this
> > dependency, please let me know. Thanks
>
> Can you share your explorations? I think the capsule should be created
> as part of the build, if enabled. Rather than changing the input
> files, binman should produce new output files.

This is an issue of handling dependencies in binman, and not changing
input files. We do not have support for telling binman "build/generate
this particular image first before you proceed to build the capsules
using the earlier built images". I am not sure if this can be done in
a generic manner in binman, so that irrespective of the image being
generated, it can be specified to build capsules once the capsule
input images have been generated.

>
> We are trying to remove most of the output logic in Makefile. It
> should just be producing input files for binman.

I understand. However, like I mentioned above, as of now, we don't
have a way of handling dependencies in binman, at least in a generic
manner. Once this support gets added, I know that it would be trivial
to add support for building capsules in binman.

-sughosh

Re: [PATCH 1/7] capsule: authenticate: Embed capsule public key in platform's dtb

2023-06-20 Thread Sughosh Ganu

hi Simon,

On Mon, 19 Jun 2023 at 18:07, Simon Glass  wrote:
>
> Hi Sughosh,
>
> On Thu, 15 Jun 2023 at 17:11, Sughosh Ganu  wrote:
> >
> > hi Simon,
> >
> > On Thu, 15 Jun 2023 at 14:44, Simon Glass  wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Tue, 13 Jun 2023 at 11:41, Sughosh Ganu  
> > > wrote:
> > > >
> > > > The EFI capsule authentication logic in u-boot expects the public key
> > > > in the form of an EFI Signature List(ESL) to be provided as part of
> > > > the platform's dtb. Currently, the embedding of the ESL file into the
> > > > dtb needs to be done manually.
> > > >
> > > > Add a script for embedding the ESL used for capsule authentication in
> > > > the platform's dtb, and call this as part of building the dtb(s). This
> > > > brings the embedding of the ESL in the dtb into the u-boot build flow.
> > > >
> > > > The path to the ESL file is specified through the
> > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> > > >
> > > > Signed-off-by: Sughosh Ganu 
> > > > ---
> > > >  lib/efi_loader/Kconfig   | 11 +++
> > > >  scripts/Makefile.lib |  8 
> > > >  scripts/embed_capsule_key.sh | 25 +
> > > >  3 files changed, 44 insertions(+)
> > > >  create mode 100755 scripts/embed_capsule_key.sh
> > > >
> > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > index c5835e6ef6..1326a1d109 100644
> > > > --- a/lib/efi_loader/Kconfig
> > > > +++ b/lib/efi_loader/Kconfig
> > > > @@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX
> > > >   Select the max capsule index value used for capsule report
> > > >   variables. This value is used to create CapsuleMax variable.
> > > >
> > > > +config EFI_CAPSULE_ESL_FILE
> > > > +   string "Path to the EFI Signature List File"
> > > > +   default ""
> > > > +   depends on EFI_CAPSULE_AUTHENTICATE
> > > > +   help
> > > > + Provides the absolute path to the EFI Signature List
> > > > + file which will be embedded in the platform's device
> > > > + tree and used for capsule authentication at the time
> > > > + of capsule update.
> > > > +
> > > > +
> > > >  config EFI_DEVICE_PATH_TO_TEXT
> > > > bool "Device path to text protocol"
> > > > default y
> > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > > > index 7b27224b5d..a4083d0a26 100644
> > > > --- a/scripts/Makefile.lib
> > > > +++ b/scripts/Makefile.lib
> > > > @@ -192,6 +192,8 @@ dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp 
> > > > -nostdinc\
> > > >  -D__ASSEMBLY__ 
> > > >  \
> > > >  -undef -D__DTS__
> > > >
> > > > +export dtc_cpp_flags
> > > > +
> > > >  # Finds the multi-part object the current object will be linked into
> > > >  modname-multi = $(sort $(foreach m,$(multi-used),\
> > > > $(if $(filter $(subst $(obj)/,,$*.o), $($(m:.o=-objs)) 
> > > > $($(m:.o=-y))),$(m:.o=
> > > > @@ -315,6 +317,9 @@ ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y)
> > > >  DTC_FLAGS += -@
> > > >  endif
> > > >
> > > > +quiet_cmd_embedcapsulekey = EMBEDCAPSULEKEY $@
> > > > +cmd_embedcapsulekey = $(srctree)/scripts/embed_capsule_key.sh $@
> > > > +
> > > >  quiet_cmd_dtc = DTC $@
> > > >  # Modified for U-Boot
> > > >  # Bring in any U-Boot-specific include at the end of the file
> > > > @@ -333,6 +338,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> > > >
> > > >  $(obj)/%.dtb: $(src)/%.dts FORCE
> > > > $(call if_changed_dep,dtc)
> > > > +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
> > > > +   $(call cmd,embedcapsulekey,$@)
> > > > +endif
> > > >
> > > >  pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
> > > >  dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
> > > > diff --git a/scripts/embed_capsule_key.sh b/scripts/embed_capsule_key.sh
> > > > new file mode 100755
> > > > index 00..1c2e45f758
> > > > --- /dev/null
> > > > +++ b/scripts/embed_capsule_key.sh
> > > > @@ -0,0 +1,25 @@
> > > > +#! /bin/bash
> > > > +# SPDX-License-Identifier: GPL-2.0+
> > > > +#
> > > > +# Copyright (C) 2023, Linaro Limited
> > > > +#
> > > > +
> > > > +gen_capsule_signature_file() {
> > > > +cat >> $1 << EOF
> > > > +/dts-v1/;
> > > > +/plugin/;
> > > > +
> > > > +&{/} {
> > > > +   signature {
> > > > +   capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > > +   };
> > > > +};
> > > > +EOF
> > > > +}
> > > > +
> > > > +gen_capsule_signature_file signature.$$.dts > /dev/null 2>&1
> > > > +$CPP $dtc_cpp_flags -x assembler-with-cpp -o signature.$$.tmp 
> > > > signature.$$.dts > /dev/null 2>&1
> > > > +dtc -@ -O dtb -o signature.$$.dtbo signature.$$.tmp > /dev/null 2>&1
> > > > +fdtoverlay -i $1 -o temp.$$.dtb -v signature.$$.dtbo > /dev/null 2>&1
> > > > +mv temp.$$.dtb $1 > /dev/null 2>&1
> > > > +rm -f signature.$$.* > /dev/null 2>&1
> > > > --
> > > > 2.34.1
> > > >
> > >
> > > Can you please add this to binman instead?
> >
>

Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION

2023-06-20 Thread Marek Vasut


On 6/20/23 22:40, Detlev Casanova wrote:

On Tuesday, June 20, 2023 4:03:18 P.M. EDT Marek Vasut wrote:

On 6/20/23 19:49, Detlev Casanova wrote:

On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote:

On 6/19/23 20:27, Detlev Casanova wrote:

On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote:

On 6/19/23 16:42, Detlev Casanova wrote:

On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote:

On 6/16/23 17:21, Detlev Casanova wrote:

Expose that information to the command shell to let scripts select
the
correct devicetree name.

Signed-off-by: Detlev Casanova 
---

  drivers/sysinfo/rcar3.c | 46
  -
  1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
index 7b127986da7..89ad46c5422 100644
--- a/drivers/sysinfo/rcar3.c
+++ b/drivers/sysinfo/rcar3.c
@@ -32,6 +32,8 @@

   */
  
  struct sysinfo_rcar_priv {
  
  	char	boardmodel[64];


+   u8  id;
+   charrevision[4];

u8  val;
  
  };


@@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice
*dev,
int id, size_t size, char *>

switch (id) {

case SYSINFO_ID_BOARD_MODEL:
-   strncpy(val, priv->boardmodel, size);
-   val[size - 1] = '\0';
+   strlcpy(val, priv->boardmodel, size);
+   break;
+   case SYSINFO_ID_BOARD_REVISION:
+   strlcpy(val, priv->revision, size);
+   break;
+   default:
+   return -EINVAL;
+   };
+
+   val[size - 1] = '\0';
+   return 0;
+}
+
+static int sysinfo_rcar_get_int(struct udevice *dev, int id, int
*val)
+{
+   struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
+
+   switch (id) {
+   case SYSINFO_ID_BOARD_ID:
+   *val = priv->id;

return 0;


Why not return SYSINFO_ID_BOARD_REVISION as integer here ?


Because the revision (on r-car3 boards at least) is in the format X.Y.
It
could be returned as "(X << 8) | Y" or split in major/minor. But
different
boards will use different revisions and I think that having a str is
easier to deal with in a shell script.


With rcar they are numbers, so lets go with major/minor integers
please.


Ok for this part, but shouldn't the sysinfo command use a common
interface
for all boards ? Or should it also have rev_major/rev_minor arguments ?


I would expect other boards to either report rev_major/rev_minor if
implemented, or errno if those boards don't implement this property.


Another thing on rcar is that the revision is stored as 2 char values.
Would you oppose a change form using a char (e.g. rev_major = '1') to
using u8 values (e.g. rev_major = 1) instead ?


Shouldn't those rev fields just be integer(s) to cover the generic case?


On rcar, they are chars. I don't really see a reason for this except to show
the '?.?' on unknown board ids. But that can be managed in other ways.


Yes I know, I am more concerned about other boards which might not have 
such short revision number, so why not just make the revision fields 
integer which covers very much anything ? Also, if you have those fields 
set to integer, then -EINVAL could be printed as '?' .

Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Marek Vasut


On 6/21/23 04:55, Chong, Teik Heng wrote:

-Original Message-
From: Marek Vasut 
Sent: Wednesday, 21 June, 2023 9:20 AM
To: Chong, Teik Heng ; u-boot@lists.denx.de
Cc: Jagan Teki ; Vignesh R
; Simon ; Kris
; Chee, Tien Fong ; Hea,
Kok Kiang ; Lokanathan, Raaj
; Maniyam, Dinesh
; Ng, Boon Khai ;
Yuslaimi, Alif Zakuan ; Zamri, Muhammad
Hazim Izzat ; Lim, Jit Loon
; Tang, Sieu Mun ;
Patrice CHOTARD ; Patrick DELAUNAY

Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT
register

On 6/21/23 02:57, Chong, Teik Heng wrote:

-Original Message-
From: Marek Vasut 
Sent: Wednesday, 21 June, 2023 5:38 AM
To: Chong, Teik Heng ; u-boot@lists.denx.de
Cc: Jagan Teki ; Vignesh R
; Simon ; Kris
; Chee, Tien Fong ;
Hea, Kok Kiang ; Lokanathan, Raaj
; Maniyam, Dinesh
; Ng, Boon Khai ;
Yuslaimi, Alif Zakuan ; Zamri,
Muhammad Hazim Izzat ; Lim,

Jit

Loon ; Tang, Sieu Mun
; Patrice CHOTARD
; Patrick DELAUNAY

Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in
HPRT register

On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields as if they
were mere RW. This leads to unintended clearing of such fields

Signed-off-by: Teik Heng Chong 

---

V1->V2
- update subject tags to usb:dwc2
---
drivers/usb/host/dwc2.c | 34 --
drivers/usb/host/dwc2.h |  4 
2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index
23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice
*dev,

/* Turn on the vbus power. */
if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(>hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA |

DWC2_HPRT0_PRTCONNDET);

-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG |

DWC2_HPRT0_PRTOVRCURRCHNG);

+   hprt0 = readl(>hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, >hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct

dwc2_priv *priv,

case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER |

USB_TYPE_CLASS:

switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(>hprt0,

DWC2_HPRT0_PRTCONNDET);

+   clrsetbits_le32(>hprt0,

DWC2_HPRT0_W1C_MASK,

+DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct

dwc2_priv *priv,

break;

case USB_PORT_FEAT_RESET:
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA

|

-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0,

DWC2_HPRT0_W1C_MASK,

+DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0,

DWC2_HPRT0_W1C_MASK |

+DWC2_HPRT0_PRTRST);
break;

case USB_PORT_FEAT_POWER:
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA

|

-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0,

DWC2_HPRT0_W1C_MASK,

+DWC2_HPRT0_PRTRST);
break;

case USB_PORT_FEAT_ENABLE:
@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice

*dev, struct dwc2_priv *priv)

dwc_otg_core_host_init(dev, regs);
}

-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |

DWC2_HPRT0_PRTENCHNG |

-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTENA |

DWC2_HPRT0_PRTCONNDET |

-DWC2_HPRT0_PRTENCHNG |

DWC2_HPRT0_PRTOVRCURRCHNG |

-DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK |
+DWC2_HPRT0_PRTRST);

for (i = 0; i < MAX_DEVICE; i++) {
for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7

@@

static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
static void

[PATCH v1 17/17] tools: binman: update binman tool for agilex5

2023-06-20 Thread Jit Loon Lim

From: Sieu Mun Tang 

This is for new platform enablement for agilex5.
Update binman tool for new platform.

Signed-off-by: Sieu Mun Tang 
---
 tools/binman/control.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index 68597c4e77..51e94c9e65 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -7,11 +7,11 @@
 
 from collections import OrderedDict
 import glob
-try:
-import importlib.resources
-except ImportError:
+#try:
+#import importlib.resources
+#except ImportError:
 # for Python 3.6
-import importlib_resources
+#import importlib_resources
 import os
 import pkg_resources
 import re
-- 
2.26.2

[PATCH v1 12/17] drivers: phy: add combo phy driver for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add combo phy driver for new platform.

Signed-off-by: Jit Loon Lim 
---
 drivers/phy/cadence/Kconfig|   9 +
 drivers/phy/cadence/Makefile   |   1 +
 drivers/phy/cadence/phy-cadence-combophy.c | 855 +
 3 files changed, 865 insertions(+)
 create mode 100644 drivers/phy/cadence/phy-cadence-combophy.c

diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
index 549ddbf504..61d1b36be2 100644
--- a/drivers/phy/cadence/Kconfig
+++ b/drivers/phy/cadence/Kconfig
@@ -1,3 +1,12 @@
+config PHY_CADENCE_COMBOPHY
+   tristate "Cadence ComboPhy PHY Driver"
+   depends on MMC_SDHCI_CADENCE
+   help
+ Enable this to support the Cadence ComboPhy PHY driver
+ A single module that encapsulates all functionality required to 
interface
+ to external NAND Flash, eMMC devices, and SD cards for command and 
data
+ transfer.
+
 config PHY_CADENCE_SIERRA
tristate "Cadence Sierra PHY Driver"
depends on DM_RESET
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
index af63b32d9f..3092b9f3b8 100644
--- a/drivers/phy/cadence/Makefile
+++ b/drivers/phy/cadence/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o
 obj-$(CONFIG_$(SPL_)PHY_CADENCE_TORRENT) += phy-cadence-torrent.o
+obj-$(CONFIG_PHY_CADENCE_COMBOPHY) += phy-cadence-combophy.o
diff --git a/drivers/phy/cadence/phy-cadence-combophy.c 
b/drivers/phy/cadence/phy-cadence-combophy.c
new file mode 100644
index 00..c49c45e5a0
--- /dev/null
+++ b/drivers/phy/cadence/phy-cadence-combophy.c
@@ -0,0 +1,855 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence COMBOPHY PHY Driver
+ *
+ * Based on the linux driver provided by Cadence Sierra
+ *
+ * Copyright (c) 2022 - 2023 Intel Corporation
+ * Author: Lee, Kah Jing 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PHY register offsets */
+/* General define */
+#define BIT_ZERO   0
+#define BIT_ONE1
+#define SD_HOST_CLK 2
+
+/* SDIO Card UHS-I modes */
+#define SDIO_MODE_SDR120
+#define SDIO_MODE_SDR251
+#define SDIO_MODE_SDR502
+#define SDIO_MODE_SDR104   3
+#define SDIO_MODE_DDR504
+#define SD_MODE_HS 5
+
+/* eMMC modes */
+#define eMMC_MODE_SDR  0
+#define eMMC_MODE_HS   1
+#define eMMC_MODE_HS2002
+#define eMMC_MODE_HS4003
+/* SW_RESET_REG */
+#define SDHCI_CDNS_HRS00   0x00
+#define SDHCI_CDNS_HRS00_SWR   BIT(0)
+/* PHY access port */
+#define SDHCI_CDNS_HRS04   0x10
+#define SDHCI_CDNS_HRS04_ADDR  GENMASK(5, 0)
+/* PHY data access port */
+#define SDHCI_CDNS_HRS05   0x14
+/* eMMC control registers */
+#define SDHCI_CDNS_HRS06   0x18
+
+#define READ_OP0
+#define WRITE_OP   1
+#define READ_WRITE_OP  2
+#define POLLING_OP 3
+#define READ_PHY_OP4
+#define READ_WRITE_PHY_OP  5
+
+#define PHY_TYPE_NAND  0
+#define PHY_TYPE_SDMMC 1
+#define PHY_REG_LEN15
+/* IO_DELAY_INFO_REG */
+#define SDHCI_CDNS_HRS07   0x1c
+#define SDHCI_CDNS_HRS07_RW_COMPENSATE GENMASK(20, 16)
+#define SDHCI_CDNS_HRS07_IDELAY_VALGENMASK(4, 0)
+/* TODO: check DV dfi_init val=9 */
+#define SDHCI_CDNS_HRS07_RW_COMPENSATE_DATA0x9
+/* TODO: check DV dfi_init val=8; DDR Mode */
+#define SDHCI_CDNS_HRS07_RW_COMPENSATE_DATA_DDR0x8
+#define SDHCI_CDNS_HRS07_IDELAY_VAL_DATA   0x0
+/* PHY reset port */
+#define SDHCI_CDNS_HRS09   0x24
+#define SDHCI_CDNS_HRS09_PHY_SW_RESET  BIT(0)
+#define SDHCI_CDNS_HRS09_PHY_INIT_COMPLETE BIT(1)
+#define SDHCI_CDNS_HRS09_EXTENDED_RD_MODE  BIT(2)
+#define SDHCI_CDNS_HRS09_EXTENDED_WR_MODE  BIT(3)
+#define SDHCI_CDNS_HRS09_RDCMD_EN  BIT(15)
+#define SDHCI_CDNS_HRS09_RDDATA_EN BIT(16)
+
+/* PHY reset port */
+#define SDHCI_CDNS_HRS10   0x28
+#define SDHCI_CDNS_HRS10_HCSDCLKADJGENMASK(19, 16)
+#define SDHCI_CDNS_HRS10_HCSDCLKADJ_DATA   0x0
+/* HCSDCLKADJ DATA; DDR Mode */
+#define SDHCI_CDNS_HRS10_HCSDCLKADJ_DATA_DDR   0x2
+
+/* CMD_DATA_OUTPUT */
+#define SDHCI_CDNS_HRS16   0x40
+#define SDHCI_CDNS_HRS16_WRDATA1_SDCLK_DLY GENMASK(31, 28)
+#define SDHCI_CDNS_HRS16_WRDATA0_SDCLK_DLY GENMASK(27, 24)
+#define SDHCI_CDNS_HRS16_WRCMD1_SDCLK_DLY  GENMASK(23, 20)
+#define SDHCI_CDNS_HRS16_WRCMD0_SDCLK_DLY  GENMASK(19, 16)
+#define

[PATCH v1 16/17] includes: add and update configuration for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add in new configuration that needed to boot new platform.

Signed-off-by: Jit Loon Lim 
---
 arch/arm/mach-socfpga/Kconfig |  55 +
 configs/socfpga_agilex5_defconfig |   2 +
 configs/socfpga_agilex5_legacy_defconfig  |   2 +
 include/configs/socfpga_agilex5_socdk.h   |  12 +
 include/configs/socfpga_soc64_common.h| 214 +-
 include/dt-bindings/clock/agilex5-clock.h |  71 ++
 include/dt-bindings/reset/altr,rst-mgr-agx5.h |  82 +++
 7 files changed, 428 insertions(+), 10 deletions(-)
 create mode 100644 include/configs/socfpga_agilex5_socdk.h
 create mode 100644 include/dt-bindings/clock/agilex5-clock.h
 create mode 100644 include/dt-bindings/reset/altr,rst-mgr-agx5.h

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 562c3796ec..a35928ef47 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -3,6 +3,10 @@ if ARCH_SOCFPGA
 config ERR_PTR_OFFSET
default 0xfffec000 if TARGET_SOCFPGA_GEN5 # Boot ROM range
 
+config MEM_RESERVE_SECURE
+   int
+   default 0
+
 config NR_DRAM_BANKS
default 1
 
@@ -33,6 +37,37 @@ config SPL_STACK_R_ADDR
 config SPL_SYS_MALLOC_F_LEN
default 0x800 if TARGET_SOCFPGA_GEN5
 
+config SYS_CACHELINE_SIZE
+   default 64
+
+config SYS_INIT_RAM_ADDR
+   bool
+   default 0xFFE0 if TARGET_SOCFPGA_AGILEX
+   default 0x0 if TARGET_SOCFPGA_AGILEX5
+   default 0xFFE0 if TARGET_SOCFPGA_N5X
+   default 0xFFE0 if TARGET_SOCFPGA_STRATIX10
+
+config SYS_INIT_RAM_SIZE
+   bool
+   default 0x4 if TARGET_SOCFPGA_AGILEX
+   default 0x8 if TARGET_SOCFPGA_AGILEX5
+   default 0x4 if TARGET_SOCFPGA_N5X
+   default 0x4 if TARGET_SOCFPGA_STRATIX10
+
+config SYS_MAX_NAND_DEVICE
+   default 1
+
+config SYS_NAND_ONFI_DETECTION
+   default 1
+
+config SYS_NAND_U_BOOT_SIZE
+   int
+   default 1048576
+
+config SYS_NAND_U_BOOT_DST
+   bool
+   default CONFIG_TEXT_BASE if TARGET_SOCFPGA_SOC64
+
 config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
default 0xa2
 
@@ -40,6 +75,16 @@ config SYS_MALLOC_F_LEN
default 0x2000 if TARGET_SOCFPGA_ARRIA10
default 0x2000 if TARGET_SOCFPGA_GEN5
 
+config SYS_NS16550_MEM32
+   default y if TARGET_SOCFPGA_SOC64
+
+config SYS_SDRAM_BASE
+   bool
+   default 0x0 if TARGET_SOCFPGA_AGILEX
+   default 0x8000 if TARGET_SOCFPGA_AGILEX5
+   default 0x0 if TARGET_SOCFPGA_N5X
+   default 0x0 if TARGET_SOCFPGA_STRATIX10
+
 config TEXT_BASE
default 0x0140 if TARGET_SOCFPGA_ARRIA10
default 0x0140 if TARGET_SOCFPGA_GEN5
@@ -59,29 +104,35 @@ config TARGET_SOCFPGA_AGILEX
select ARMV8_SET_SMPEN
select BINMAN if SPL_ATF
select CLK
+   select CONFIG_BOOTFILE if SPL_ATF
select FPGA_INTEL_SDM_MAILBOX
select GICV2
select NCORE_CACHE
select SPL_CLK if SPL
+   select SYS_SDRAM_BASE
select TARGET_SOCFPGA_SOC64
 
 config TARGET_SOCFPGA_AGILEX5
bool
select BINMAN if SPL_ATF
select CLK
+   select CONFIG_BOOTFILE if SPL_ATF
select FPGA_INTEL_SDM_MAILBOX
select GICV3
select NCORE_CACHE
select SPL_CLK if SPL
+   select SYS_SDRAM_BASE
select TARGET_SOCFPGA_SOC64
 
 config TARGET_SOCFPGA_AGILEX5_EMU
bool "Enable build that bootable only on Agilex5 Emulator"
+   select TARGET_SOCFPGA_AGILEX5
help
 This is to use for Agilex5 Emulator.
 
 config TARGET_SOCFPGA_AGILEX5_SIMICS
bool "Enable build that bootable only on Agilex5 Simics platform"
+   select TARGET_SOCFPGA_AGILEX5
help
 This is to use for Agilex5 Simics.
 
@@ -127,10 +178,12 @@ config TARGET_SOCFPGA_N5X
select ARMV8_SET_SMPEN
select BINMAN if SPL_ATF
select CLK
+   select CONFIG_BOOTFILE if SPL_ATF
select FPGA_INTEL_SDM_MAILBOX
select NCORE_CACHE
select SPL_ALTERA_SDRAM
select SPL_CLK if SPL
+   select SYS_SDRAM_BASE
select TARGET_SOCFPGA_SOC64
 
 config TARGET_SOCFPGA_N5X_SOCDK
@@ -145,7 +198,9 @@ config TARGET_SOCFPGA_STRATIX10
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
select BINMAN if SPL_ATF
+   select CONFIG_BOOTFILE if SPL_ATF
select FPGA_INTEL_SDM_MAILBOX
+   select SYS_SDRAM_BASE
select TARGET_SOCFPGA_SOC64
 
 choice
diff --git a/configs/socfpga_agilex5_defconfig 
b/configs/socfpga_agilex5_defconfig
index 6a90fa0b27..8e5c7e6f70 100644
--- a/configs/socfpga_agilex5_defconfig
+++ b/configs/socfpga_agilex5_defconfig
@@ -50,6 +50,8 @@ CONFIG_CMD_FAT=y
 CONFIG_DOS_PARTITION=y
 CONFIG_SPL_DOS_PARTITION=y
 CONFIG_SPL_SYS_DISABLE_DCACHE_OPS=y
+CONFIG_USE_BOOTFILE=y
+CONFIG_BOOTFILE="kernel.itb"
 CONFIG_CMD_MTD=y
 CONFIG_CMD_NAND_TRIMFFS=y

[PATCH v1 15/17] drivers: watchdog: update watchdog driver for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Update watchdog timeout timer for new platform.

Signed-off-by: Jit Loon Lim 
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 646663528a..18d2e33e09 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -28,7 +28,7 @@ config WATCHDOG_TIMEOUT_MSECS
int "Watchdog timeout in msec"
default 128000 if ARCH_MX31 || ARCH_MX5 || ARCH_MX6
default 128000 if ARCH_MX7 || ARCH_VF610
-   default 3 if ARCH_SOCFPGA
+   default 1 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
default 5376 if ULP_WATCHDOG
default 15000 if ARCH_BCM283X
-- 
2.26.2

[PATCH v1 14/17] drivers: sysreset: add system driver for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add cold, warm reset logic for new platform.

Signed-off-by: Jit Loon Lim 
---
 drivers/sysreset/Kconfig|  7 
 drivers/sysreset/Makefile   |  1 +
 drivers/sysreset/sysreset_socfpga_agilex5.c | 44 +
 3 files changed, 52 insertions(+)
 create mode 100644 drivers/sysreset/sysreset_socfpga_agilex5.c

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 03f7fdd597..850191eeed 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -137,6 +137,13 @@ config SYSRESET_SOCFPGA_SOC64
  This enables the system reset driver support for Intel SOCFPGA
  SoC64 SoCs.
 
+config SYSRESET_SOCFPGA_AGILEX5
+   bool "Enable support for Intel SOCFPGA AGILEX5 device"
+   depends on ARCH_SOCFPGA && TARGET_SOCFPGA_AGILEX5
+   help
+ This enables the system reset driver support for Intel SOCFPGA
+ AGILEX5 device.
+
 config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 40c876764a..6631a71db6 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
 obj-$(CONFIG_SYSRESET_SBI) += sysreset_sbi.o
 obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
 obj-$(CONFIG_SYSRESET_SOCFPGA_SOC64) += sysreset_socfpga_soc64.o
+obj-$(CONFIG_SYSRESET_SOCFPGA_AGILEX5) += sysreset_socfpga_agilex5.o
 obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
 obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
 obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga_agilex5.c 
b/drivers/sysreset/sysreset_socfpga_agilex5.c
new file mode 100644
index 00..7b05ffd269
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga_agilex5.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Intel Corporation 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int socfpga_sysreset_request(struct udevice *dev,
+   enum sysreset_t type)
+{
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+   const char *reset = env_get("reset");
+
+   if (reset && !strcmp(reset, "warm")) {
+   /* request a warm reset */
+   puts("Do warm reset now...\n");
+
+   /* doing architecture system reset */
+   psci_system_reset2(0, 0);
+   } else {
+   puts("Issuing cold reset REBOOT_HPS\n");
+   psci_system_reset();
+   }
+#endif
+
+   return -EINPROGRESS;
+}
+
+static struct sysreset_ops socfpga_sysreset = {
+   .request = socfpga_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_socfpga) = {
+   .id = UCLASS_SYSRESET,
+   .name   = "socfpga_sysreset",
+   .ops= _sysreset,
+};
-- 
2.26.2

[PATCH v1 13/17] drivers: reset: add reset driver for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add reset driver for new platform.

Signed-off-by: Jit Loon Lim 
---
 drivers/reset/reset-socfpga.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index 6e3f03e248..8b35f0685d 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -24,9 +24,18 @@
 #include 
 #include 
 #include 
-
-#define BANK_INCREMENT 4
-#define NR_BANKS   8
+#include 
+
+#define BANK_INCREMENT 4
+#define NR_BANKS   8
+#define RSTMGR_PER0MODRST_USB31BIT(4)
+#define RSTMGR_PER0MODRST_NAND BIT(5)
+#define RSTMGR_PER0MODRST_DMA  BIT(16)
+#define RSTMGR_PER0MODRST_DMAIFGENMASK(31, 24)
+#define RSTMGR_PER0MODRST_USB31_NAND_DMA_DEASSERT  RSTMGR_PER0MODRST_USB31 
\
+   | 
RSTMGR_PER0MODRST_NAND \
+   | RSTMGR_PER0MODRST_DMA 
\
+   | 
RSTMGR_PER0MODRST_DMAIF
 
 struct socfpga_reset_data {
void __iomem *modrst_base;
@@ -112,9 +121,22 @@ static int socfpga_reset_remove(struct udevice *dev)
 {
struct socfpga_reset_data *data = dev_get_priv(dev);
 
+/*
+ * TODO: This is temporary solution for NAND/DMA/USB3.1 deaasert.
+ * When NAND/DMA/USB3.1 driver is ready, the deassert shall be done
+ * from NAND/DMA/USB3.1 driver.
+ */
+#if defined(CONFIG_TARGET_SOCFPGA_AGILEX5)
+   clrbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_SOC64_PER0MODRST,
+RSTMGR_PER0MODRST_USB31_NAND_DMA_DEASSERT);
+#endif
+
if (socfpga_reset_keep_enabled()) {
puts("Deasserting all peripheral resets\n");
writel(0, data->modrst_base + 4);
+#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+   writel(0, data->modrst_base + 8);
+#endif
}
 
return 0;
-- 
2.26.2

[PATCH v1 11/17] drivers: mmc: add mmc/cadence driver for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add mmc and cadence host driver for new platform.

Signed-off-by: Jit Loon Lim 
---
 drivers/mmc/mmc.c   |  27 +++---
 drivers/mmc/sdhci-cadence.c | 164 
 2 files changed, 160 insertions(+), 31 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1af6af82e6..88c674d44f 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -26,6 +26,7 @@
 #include 
 #include "mmc_private.h"
 
+#define TIMEOUT_TEN_MS  10
 #define DEFAULT_CMD6_TIMEOUT_MS  500
 
 static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
@@ -247,7 +248,7 @@ static int mmc_send_cmd_retry(struct mmc *mmc, struct 
mmc_cmd *cmd,
 static int mmc_send_cmd_quirks(struct mmc *mmc, struct mmc_cmd *cmd,
   struct mmc_data *data, u32 quirk, uint retries)
 {
-   if (IS_ENABLED(CONFIG_MMC_QUIRKS) && mmc->quirks & quirk)
+   if (CONFIG_IS_ENABLED(MMC_QUIRKS) && mmc->quirks & quirk)
return mmc_send_cmd_retry(mmc, cmd, data, retries);
else
return mmc_send_cmd(mmc, cmd, data);
@@ -597,6 +598,11 @@ static int sd_send_op_cond(struct mmc *mmc, bool uhs_en)
int err;
struct mmc_cmd cmd;
 
+   /* lower timeout, to speed up mmc init since both uses same flow */
+   if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_EMU) ||
+   IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS))
+   timeout = TIMEOUT_TEN_MS;
+
while (1) {
cmd.cmdidx = MMC_CMD_APP_CMD;
cmd.resp_type = MMC_RSP_R1;
@@ -635,7 +641,7 @@ static int sd_send_op_cond(struct mmc *mmc, bool uhs_en)
break;
 
if (timeout-- <= 0)
-   return -EOPNOTSUPP;
+   return -ETIMEDOUT;
 
udelay(1000);
}
@@ -2432,9 +2438,6 @@ static int mmc_startup_v4(struct mmc *mmc)
 
mmc->wr_rel_set = ext_csd[EXT_CSD_WR_REL_SET];
 
-   mmc->can_trim =
-   !!(ext_csd[EXT_CSD_SEC_FEATURE] & EXT_CSD_SEC_FEATURE_TRIM_EN);
-
return 0;
 error:
if (mmc->ext_csd) {
@@ -3130,10 +3133,9 @@ int mmc_init_device(int num)
 #endif
 
 #ifdef CONFIG_CMD_BKOPS_ENABLE
-int mmc_set_bkops_enable(struct mmc *mmc, bool autobkops, bool enable)
+int mmc_set_bkops_enable(struct mmc *mmc)
 {
int err;
-   u32 bit = autobkops ? BIT(1) : BIT(0);
ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
 
err = mmc_send_ext_csd(mmc, ext_csd);
@@ -3147,21 +3149,18 @@ int mmc_set_bkops_enable(struct mmc *mmc, bool 
autobkops, bool enable)
return -EMEDIUMTYPE;
}
 
-   if (enable && (ext_csd[EXT_CSD_BKOPS_EN] & bit)) {
+   if (ext_csd[EXT_CSD_BKOPS_EN] & 0x1) {
puts("Background operations already enabled\n");
return 0;
}
 
-   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BKOPS_EN,
-enable ? bit : 0);
+   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BKOPS_EN, 1);
if (err) {
-   printf("Failed to %sable manual background operations\n",
-  enable ? "en" : "dis");
+   puts("Failed to enable manual background operations\n");
return err;
}
 
-   printf("%sabled %s background operations\n",
-  enable ? "En" : "Dis", autobkops ? "auto" : "manual");
+   puts("Enabled manual background operations\n");
 
return 0;
 }
diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index 327a05ad11..4154fd33da 100644
--- a/drivers/mmc/sdhci-cadence.c
+++ b/drivers/mmc/sdhci-cadence.c
@@ -5,7 +5,10 @@
  */
 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -16,10 +19,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+/* General define */
+#define SD_MIN_CLK 40
+
 /* HRS - Host Register Set (specific to Cadence) */
 #define SDHCI_CDNS_HRS04   0x10/* PHY access port */
+#define SDHCI_CDNS_HRS05   0x14/* PHY data access port 
*/
 #define   SDHCI_CDNS_HRS04_ACK BIT(26)
 #define   SDHCI_CDNS_HRS04_RD  BIT(25)
 #define   SDHCI_CDNS_HRS04_WR  BIT(24)
@@ -66,6 +74,16 @@ struct sdhci_cdns_plat {
struct mmc_config cfg;
struct mmc mmc;
void __iomem *hrs_addr;
+   struct udevice *udev;
+   struct phy phy_dev;
+   bool phy_enabled;
+   struct reset_ctl softreset_ctl;
+};
+
+/* socfpga implementation specific driver private data */
+struct sdhci_socfpga_priv_data {
+   struct sdhci_host host;
+   struct phy phy;
 };
 
 struct sdhci_cdns_phy_cfg {
@@ -94,25 +112,45 @@ static int sdhci_cdns_write_phy_reg(struct sdhci_cdns_plat 
*plat,
u32 tmp;
int ret;
 
-   tmp = FIELD_PREP(SDHCI_CDNS_HRS04_WDATA, data) |
-

[PATCH v1 09/17] drivers: clk: altera: add clock support for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add new clock files for new platform.Add

Signed-off-by: Jit Loon Lim 
---
 drivers/clk/altera/Makefile  |   1 +
 drivers/clk/altera/clk-agilex5.c | 736 +++
 drivers/clk/altera/clk-agilex5.h | 263 +++
 3 files changed, 1000 insertions(+)
 create mode 100644 drivers/clk/altera/clk-agilex5.c
 create mode 100644 drivers/clk/altera/clk-agilex5.h

diff --git a/drivers/clk/altera/Makefile b/drivers/clk/altera/Makefile
index 33db092918..61ffa4179a 100644
--- a/drivers/clk/altera/Makefile
+++ b/drivers/clk/altera/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += clk-agilex.o
 obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += clk-arria10.o
 obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-n5x.o
 obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-mem-n5x.o
+obj-$(CONFIG_TARGET_SOCFPGA_AGILEX5) += clk-agilex5.o
diff --git a/drivers/clk/altera/clk-agilex5.c b/drivers/clk/altera/clk-agilex5.c
new file mode 100644
index 00..05ee5f9874
--- /dev/null
+++ b/drivers/clk/altera/clk-agilex5.c
@@ -0,0 +1,736 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019-2023 Intel Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MPIDR_AFF1_OFFSET  8
+#define MPIDR_AFF1_MASK0x3
+#define CORE0  1
+#define CORE1  2
+#define CORE2  3
+#define CORE3  4
+
+struct socfpga_clk_plat {
+   void __iomem *regs;
+};
+
+/*
+ * function to write the bypass register which requires a poll of the
+ * busy bit
+ */
+static void clk_write_bypass_mainpll(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_MAINPLL_BYPASS);
+   cm_wait_for_fsm();
+}
+
+static void clk_write_bypass_perpll(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_PERPLL_BYPASS);
+   cm_wait_for_fsm();
+}
+
+/* function to write the ctrl register which requires a poll of the busy bit */
+static void clk_write_ctrl(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_CTRL);
+   cm_wait_for_fsm();
+}
+
+#define MEMBUS_MAINPLL 0
+#define MEMBUS_PERPLL  1
+#define MEMBUS_TIMEOUT 1000
+
+#define MEMBUS_CLKSLICE_REG0x27
+#define MEMBUS_SYNTHCALFOSC_INIT_CENTERFREQ_REG0xb3
+#define MEMBUS_SYNTHPPM_WATCHDOGTMR_VF01_REG   0xe6
+#define MEMBUS_CALCLKSLICE0_DUTY_LOCOVR_REG0x03
+#define MEMBUS_CALCLKSLICE1_DUTY_LOCOVR_REG0x07
+
+static const struct {
+   u32 reg;
+   u32 val;
+   u32 mask;
+} membus_pll[] = {
+   {
+   MEMBUS_CLKSLICE_REG,
+   /*
+* BIT[7:7]
+* Enable source synchronous mode
+*/
+   BIT(7),
+   BIT(7)
+   },
+   {
+   MEMBUS_SYNTHCALFOSC_INIT_CENTERFREQ_REG,
+   /*
+* BIT[0:0]
+* Sets synthcalfosc_init_centerfreq=1 to limit overshoot
+* frequency during lock
+*/
+   BIT(0),
+   BIT(0)
+   },
+   {
+   MEMBUS_SYNTHPPM_WATCHDOGTMR_VF01_REG,
+   /*
+* BIT[0:0]
+* Sets synthppm_watchdogtmr_vf0=1 to give the pll more time
+* to settle before lock is asserted.
+*/
+   BIT(0),
+   BIT(0)
+   },
+   {
+   MEMBUS_CALCLKSLICE0_DUTY_LOCOVR_REG,
+   /*
+* BIT[6:0]
+* Centering duty cycle for clkslice0 output
+*/
+   0x4a,
+   GENMASK(6, 0)
+   },
+   {
+   MEMBUS_CALCLKSLICE1_DUTY_LOCOVR_REG,
+   /*
+* BIT[6:0]
+* Centering duty cycle for clkslice1 output
+*/
+   0x4a,
+   GENMASK(6, 0)
+   },
+};
+
+static int membus_wait_for_req(struct socfpga_clk_plat *plat, u32 pll,
+  int timeout)
+{
+   int cnt = 0;
+   u32 req_status;
+
+   if (pll == MEMBUS_MAINPLL)
+   req_status = CM_REG_READL(plat, CLKMGR_MAINPLL_MEM);
+   else
+   req_status = CM_REG_READL(plat, CLKMGR_PERPLL_MEM);
+
+   while ((cnt < timeout) && (req_status & CLKMGR_MEM_REQ_SET_MSK)) {
+   if (pll == MEMBUS_MAINPLL)
+   req_status = CM_REG_READL(plat, CLKMGR_MAINPLL_MEM);
+   else
+   req_status = CM_REG_READL(plat, CLKMGR_PERPLL_MEM);
+   cnt++;
+   }
+
+   if (cnt >= timeout)
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+static int membus_write_pll(struct

[PATCH v1 08/17] drivers: ddr: altera: add ddr support for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add new ddr and iossm mailbox files for new platform.Add

Signed-off-by: Jit Loon Lim 
---
 drivers/ddr/altera/Makefile|   5 +-
 drivers/ddr/altera/iossm_mailbox.c | 786 +
 drivers/ddr/altera/iossm_mailbox.h | 141 ++
 drivers/ddr/altera/sdram_agilex5.c | 329 
 drivers/ddr/altera/sdram_soc64.c   |  78 ++-
 drivers/ddr/altera/sdram_soc64.h   |  17 +-
 6 files changed, 1345 insertions(+), 11 deletions(-)
 create mode 100644 drivers/ddr/altera/iossm_mailbox.c
 create mode 100644 drivers/ddr/altera/iossm_mailbox.h
 create mode 100644 drivers/ddr/altera/sdram_agilex5.c

diff --git a/drivers/ddr/altera/Makefile b/drivers/ddr/altera/Makefile
index 9fa5d85a27..fa6c880b39 100644
--- a/drivers/ddr/altera/Makefile
+++ b/drivers/ddr/altera/Makefile
@@ -7,9 +7,10 @@
 # Copyright (C) 2014-2021 Altera Corporation 
 
 ifdef CONFIG_$(SPL_)ALTERA_SDRAM
-obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o
-obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o
+obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_soc32.o sdram_gen5.o sequencer.o
+obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_soc32.o sdram_arria10.o
 obj-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += sdram_soc64.o sdram_s10.o
 obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += sdram_soc64.o sdram_agilex.o
 obj-$(CONFIG_TARGET_SOCFPGA_N5X) += sdram_soc64.o sdram_n5x.o
+obj-$(CONFIG_TARGET_SOCFPGA_AGILEX5) += sdram_soc64.o sdram_agilex5.o 
iossm_mailbox.o
 endif
diff --git a/drivers/ddr/altera/iossm_mailbox.c 
b/drivers/ddr/altera/iossm_mailbox.c
new file mode 100644
index 00..c7ceed7c45
--- /dev/null
+++ b/drivers/ddr/altera/iossm_mailbox.c
@@ -0,0 +1,786 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Intel Corporation 
+ *
+ */
+
+#define DEBUG
+#include 
+#include 
+#include 
+#include "iossm_mailbox.h"
+#include 
+
+/* supported DDR type list */
+static const char *ddr_type_list[7] = {
+   "DDR4", "DDR5", "DDR5_RDIMM", "LPDDR4", "LPDDR5", "QDRIV", 
"UNKNOWN"
+};
+
+/* Mailbox request function
+ * This function will send the request to IOSSM mailbox and wait for response 
return
+ *
+ * @io96b_csr_addr: CSR address for the target IO96B
+ * @ip_type:   IP type for the specified memory interface
+ * @instance_id:IP instance ID for the specified memory interface
+ * @usr_cmd_type:   User desire IOSSM mailbox command type
+ * @usr_cmd_opcode: User desire IOSSM mailbox command opcode
+ * @cmd_param_*:Parameters (if applicable) for the requested IOSSM mailbox 
command
+ * @resp_data_len:  User desire extra response data fields other than
+ * CMD_RESPONSE_DATA_SHORT field on 
CMD_RESPONSE_STATUS
+ * @resp:  Structure contain responses returned from the 
requested IOSSM
+ * mailbox command
+ */
+int io96b_mb_req(phys_addr_t io96b_csr_addr, u32 ip_type, u32 instance_id
+   , u32 usr_cmd_type, u32 usr_cmd_opcode, 
u32 cmd_param_0
+   , u32 cmd_param_1, u32 cmd_param_2, u32 
cmd_param_3
+   , u32 cmd_param_4, u32 cmd_param_5, u32 
cmd_param_6
+   , u32 resp_data_len, struct 
io96b_mb_resp *resp)
+{
+   int i;
+   int ret;
+   u32 cmd_req, cmd_resp;
+
+   /* Initialized zeros for responses*/
+   resp->cmd_resp_status = 0;
+   resp->cmd_resp_data_0 = 0;
+   resp->cmd_resp_data_1 = 0;
+   resp->cmd_resp_data_2 = 0;
+
+   /* Ensure CMD_REQ is cleared before write any command request */
+   ret = wait_for_bit_le32((const void *)(io96b_csr_addr + 
IOSSM_CMD_REQ_OFFSET)
+   , GENMASK(31, 0), 0, TIMEOUT, false);
+
+   if (ret) {
+   printf("%s: CMD_REQ not ready\n", __func__);
+   return -1;
+   }
+
+   /* Write CMD_PARAM_* */
+   for (i = 0; i < 6 ; i++) {
+   switch (i) {
+   case 0:
+   if (cmd_param_0)
+   writel(cmd_param_0, io96b_csr_addr + 
IOSSM_CMD_PARAM_0_OFFSET);
+   break;
+   case 1:
+   if (cmd_param_1)
+   writel(cmd_param_1, io96b_csr_addr + 
IOSSM_CMD_PARAM_1_OFFSET);
+   break;
+   case 2:
+   if (cmd_param_2)
+   writel(cmd_param_2, io96b_csr_addr + 
IOSSM_CMD_PARAM_2_OFFSET);
+   break;
+   case 3:
+   if (cmd_param_3)
+   writel(cmd_param_3, io96b_csr_addr + 
IOSSM_CMD_PARAM_3_OFFSET);
+   break;
+   case 4:
+   if (cmd_param_4)
+   writel(cmd_param_4, io96b_csr_addr + 
IOSSM_CMD_PARAM_4_OFFSET);
+

[PATCH v1 10/17] drivers: misc: update driver misc for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Update secure registers, Kconfig and makefile for new platform.

Signed-off-by: Jit Loon Lim 
---
 drivers/misc/Kconfig  |   9 +++
 drivers/misc/Makefile |   1 +
 drivers/misc/socfpga_secreg.c | 116 ++
 3 files changed, 126 insertions(+)
 create mode 100644 drivers/misc/socfpga_secreg.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 04460f1acb..3b6f5314ff 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -666,4 +666,13 @@ config SL28CPLD
  the base driver which provides common access methods for the
  sub-drivers.
 
+config SPL_SOCFPGA_SEC_REG
+   bool "Enable register setting from device tree in SPL"
+   depends on SPL
+   help
+ Enable register setting from device tree in SPL, which require
+ high privilege access like firewall registers. This also
+ provides user a clean interface and all register settings are
+ centralized in one place, device tree.
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 52aed09602..441c03509f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -88,3 +88,4 @@ obj-$(CONFIG_K3_AVS0) += k3_avs.o
 obj-$(CONFIG_ESM_K3) += k3_esm.o
 obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
 obj-$(CONFIG_SL28CPLD) += sl28cpld.o
+obj-$(CONFIG_SPL_SOCFPGA_SEC_REG) += socfpga_secreg.o
diff --git a/drivers/misc/socfpga_secreg.c b/drivers/misc/socfpga_secreg.c
new file mode 100644
index 00..3f3ba8b0c1
--- /dev/null
+++ b/drivers/misc/socfpga_secreg.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021-2023 Intel Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUMBER_OF_ELEMENTS 3
+
+static int socfpga_secreg_probe(struct udevice *dev)
+{
+   const fdt32_t *list;
+   fdt_addr_t offset, base;
+   fdt_val_t val, read_val, mask, set_mask;
+   int size, i;
+   u32 blk_sz, reg;
+   ofnode node;
+   const char *name = NULL;
+
+   debug("%s(dev=%p)\n", __func__, dev);
+
+   if (!dev_has_ofnode(dev))
+   return 0;
+
+   dev_for_each_subnode(node, dev) {
+   name = ofnode_get_name(node);
+   if (!name)
+   return -EINVAL;
+
+   if (ofnode_read_u32_index(node, "reg", 1, _sz))
+   return -EINVAL;
+
+   base = ofnode_get_addr(node);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   debug("%s(node_offset 0x%lx node_name %s ", __func__,
+ node.of_offset, name);
+   debug("node addr 0x%llx blk sz 0x%x)\n", base, blk_sz);
+
+   list = ofnode_read_prop(node, "intel,offset-settings", );
+   if (!list)
+   return -EINVAL;
+
+   debug("%s(intel,offset-settings property size=%x)\n", __func__,
+ size);
+   size /= sizeof(*list) * NUMBER_OF_ELEMENTS;
+
+   /*
+* First element: offset
+* Second element: val
+* Third element: mask
+*/
+   for (i = 0; i < size; i++) {
+   offset = fdt32_to_cpu(*list++);
+   val = fdt32_to_cpu(*list++);
+
+   /* Reads the masking bit value from the list */
+   mask = fdt32_to_cpu(*list++);
+
+   /*
+* Reads out the offsets, value and masking bits
+* Ex: <0x 0x0230 0x>
+*/
+   debug("%s(intel,offset-settings 0x%llx : 0x%llx : 
0x%llx)\n",
+ __func__, offset, val, mask);
+
+   if (blk_sz < offset + SZ_4) {
+   printf("%s: Overflow as offset 0x%llx or reg",
+  __func__, offset);
+   printf(" write is more than block size 0x%x\n",
+  blk_sz);
+   return -EINVAL;
+   }
+
+   if (mask != 0) {
+   if (mask == 0x) {
+   reg = base + offset;
+   writel(val, (uintptr_t)reg);
+   } else {
+   /* Mask the value with the masking bits 
*/
+   set_mask = val & mask;
+
+   reg = base + offset;
+
+   /* Clears and sets specific bits in the 
register */
+   clrsetbits_le32((uintptr_t)reg, mask, 
set_mask);
+   }
+   }
+
+

[PATCH v1 06/17] configs: add new platform agilex5 defconfig

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add new platform defconfig for new platform.

Signed-off-by: Jit Loon Lim 
---
 configs/socfpga_agilex5_defconfig| 123 +++
 configs/socfpga_agilex5_legacy_defconfig |  85 
 2 files changed, 208 insertions(+)
 create mode 100644 configs/socfpga_agilex5_defconfig
 create mode 100644 configs/socfpga_agilex5_legacy_defconfig

diff --git a/configs/socfpga_agilex5_defconfig 
b/configs/socfpga_agilex5_defconfig
new file mode 100644
index 00..6a90fa0b27
--- /dev/null
+++ b/configs/socfpga_agilex5_defconfig
@@ -0,0 +1,123 @@
+CONFIG_ARM=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
+CONFIG_ARCH_SOCFPGA=y
+CONFIG_TEXT_BASE=0x8020
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex5_socdk"
+# CONFIG_SPL_MMC is not set
+CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS=y
+CONFIG_TARGET_SOCFPGA_AGILEX5_SOCDK=y
+CONFIG_IDENT_STRING="socfpga_agilex5"
+CONFIG_SPL_FS_FAT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8200
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 initrd=0x9000 root=/dev/ram0 rw 
init=/sbin/init ramdisk_size=1000 earlycon panic=-1 nosmp kvm-arm.mode=nvhe"
+CONFIG_LEGACY_IMAGE_FORMAT=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_CRC32=y
+CONFIG_SPL_CACHE=y
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_SYS_PROMPT="SOCFPGA_AGILEX5 # "
+CONFIG_CMD_NVEDIT_SELECT=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_COMBOPHY=y
+CONFIG_DM_MMC=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_CADENCE=y
+CONFIG_CMD_FAT=y
+CONFIG_DOS_PARTITION=y
+CONFIG_SPL_DOS_PARTITION=y
+CONFIG_SPL_SYS_DISABLE_DCACHE_OPS=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_NAND_LOCK_UNLOCK=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_CACHE=y
+CONFIG_MTDIDS_DEFAULT="nand0=ffb9.nand.0"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=ffb9.nand.0:2m(u-boot),-(root)"
+CONFIG_CMD_UBI=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+CONFIG_OF_LIST=""
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_ALTERA_SDRAM=y
+CONFIG_FPGA_INTEL_PR=y
+CONFIG_DWAPB_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_DW=y
+CONFIG_MISC=y
+CONFIG_MMC_DW=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
+CONFIG_SYS_NAND_U_BOOT_OFFS=0x0
+CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND=0x10
+CONFIG_SF_DEFAULT_MODE=0x2003
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_UBI_SILENCE_MSG=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_MII=y
+CONFIG_DM_RESET=y
+CONFIG_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_DESIGNWARE_SPI=y
+CONFIG_NOP_PHY=y
+CONFIG_USB=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_UBIFS_SILENCE_MSG=y
+# CONFIG_SPL_USE_TINY_PRINTF is not set
+CONFIG_PANIC_HANG=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_LOAD_ADDR=0x8200
+CONFIG_WDT=y
+CONFIG_CMD_WDT=y
+CONFIG_DESIGNWARE_WATCHDOG=y
+CONFIG_SPL_WDT=y
+CONFIG_WATCHDOG_AUTOSTART=n
+CONFIG_TIMER=y
+CONFIG_DESIGNWARE_APB_TIMER=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8030
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x8ff0
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_STACK=0xffe3f000
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8fa0
+CONFIG_SYS_SPL_MALLOC_SIZE=0x50
+CONFIG_SPL_BSS_MAX_SIZE=0x10
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/socfpga_agilex5_legacy_defconfig 
b/configs/socfpga_agilex5_legacy_defconfig
new file mode 100644
index 00..cede11c880
--- /dev/null
+++ b/configs/socfpga_agilex5_legacy_defconfig
@@ -0,0 +1,85 @@
+CONFIG_ARM=y
+CONFIG_ARM_SMCCC=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
+CONFIG_ARCH_SOCFPGA=y
+CONFIG_SYS_TEXT_BASE=0x80001000
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+# CONFIG_SPL_DM_SPI is not set
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex5_socdk"
+CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS=y
+CONFIG_TARGET_SOCFPGA_AGILEX5_SOCDK=y
+CONFIG_IDENT_STRING="socfpga_agilex5"
+CONFIG_SPL_FS_FAT=y
+# CONFIG_SPL_SPI is not set
+CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
+CONFIG_SYS_LOAD_ADDR=0x8200
+CONFIG_ARMV8_PSCI=y
+# CONFIG_PSCI_RESET is not set
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y

[PATCH v1 07/17] doc: device-tree-bindings: misc: add secreg text file for agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add new secure register text file for new platform.

Signed-off-by: Jit Loon Lim 
---
 .../misc/socfpga_secreg.txt   | 397 ++
 1 file changed, 397 insertions(+)
 create mode 100644 doc/device-tree-bindings/misc/socfpga_secreg.txt

diff --git a/doc/device-tree-bindings/misc/socfpga_secreg.txt 
b/doc/device-tree-bindings/misc/socfpga_secreg.txt
new file mode 100644
index 00..97640b74d9
--- /dev/null
+++ b/doc/device-tree-bindings/misc/socfpga_secreg.txt
@@ -0,0 +1,397 @@
+* Firewall and privilege register settings in device tree
+
+Required properties:
+
+
+- compatible: should contain "intel,socfpga-secreg"
+- reg: Physical base address and size of block register.
+- intel,offset-settings: 32-bit offset address of block register,
+followed by 32-bit value settings and
+the masking bits, only masking bit
+set to 1 allows modification.
+
+The device tree node which describes secure and privilege register access
+configuration in compile time.
+
+Most of these registers are expected to work except for the case which some
+registers configuration are required for granting access to some other
+registers, for example CCU registers have to be properly configured before
+allowing register configuration access to fpga2sdram firewall as shown in
+below example.
+
+Some registers depend on runtime data for proper configuration are expected
+to be part of driver that generating these data for example configuration for
+soc_noc_fw_ddr_mpu_inst_0_ddr_scr block register depend on DDR size parsed from
+memory device tree node.
+
+Please refer details of tested examples below for both fpga2sdram and QoS
+configuration with default reset value and the comments.
+
+Example:
+
+
+Common configuration for all SoC64 devices:
+Path: arch/arm/dts/socfpga_soc64_u-boot.dtsi
+
+   socfpga_secreg: socfpga-secreg {
+   compatible = "intel,socfpga-secreg";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   u-boot,dm-pre-reloc;
+
+   i_sys_mgr_core@ffd12000 {
+   reg = <0xffd12000 0x0230>;
+   intel,offset-settings =
+   /* Enable non-secure interface to DMA */
+   <0x0020 0xff01 0xff010011>,
+   /* Enable non-secure interface to DMA periph */
+   <0x0024 0x 0x>;
+   u-boot,dm-pre-reloc;
+   };
+
+   noc_fw_l4_per_l4_per_scr@ffd21000 {
+   reg = <0xffd21000 0x0074>;
+   intel,offset-settings =
+   /* Disable L4 periphs firewall */
+   <0x 0x01010001 0x01010001>,
+   <0x0004 0x01010001 0x01010001>,
+   <0x000c 0x01010001 0x01010001>,
+   <0x0010 0x01010001 0x01010001>,
+   <0x001c 0x01010001 0x01010101>,
+   <0x0020 0x01010001 0x01010101>,
+   <0x0024 0x01010001 0x01010101>,
+   <0x0028 0x01010001 0x01010101>,
+   <0x002c 0x01010001 0x01010001>,
+   <0x0030 0x01010001 0x01010001>,
+   <0x0034 0x01010001 0x01010001>,
+   <0x0040 0x01010001 0x01010001>,
+   <0x0044 0x01010001 0x01010101>,
+   <0x0048 0x01010001 0x01010101>,
+   <0x0050 0x01010001 0x01010101>,
+   <0x0054 0x01010001 0x01010101>,
+   <0x0058 0x01010001 0x01010101>,
+   <0x005c 0x01010001 0x01010101>,
+   <0x0060 0x01010001 0x01010101>,
+   <0x0064 0x01010001 0x01010101>,
+   <0x0068 0x01010001 0x01010101>,
+   <0x006c 0x01010001 0x01010101>,
+   <0x0070 0x01010001 0x01010101>;
+   u-boot,dm-pre-reloc;
+   };
+
+   noc_fw_l4_sys_l4_sys_scr@ffd21100 {
+   reg = <0xffd21100 0x0098>;
+   intel,offset-settings =
+   /* Disable L4 system firewall */
+   <0x0008 0x01010001 0x01010001>,
+   <0x000c 0x01010001 0x01010001>,
+   <0x0010 0x01010001 0x01010001>,
+   <0x0014

[PATCH v1 05/17] board: intel: add new platform agilex5 socdk

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add new platform socdk and update maintainer list.

Signed-off-by: Jit Loon Lim 
---
 board/intel/agilex5-socdk/MAINTAINERS | 8 
 board/intel/agilex5-socdk/Makefile| 7 +++
 board/intel/agilex5-socdk/socfpga.c   | 7 +++
 3 files changed, 22 insertions(+)
 create mode 100644 board/intel/agilex5-socdk/MAINTAINERS
 create mode 100644 board/intel/agilex5-socdk/Makefile
 create mode 100644 board/intel/agilex5-socdk/socfpga.c

diff --git a/board/intel/agilex5-socdk/MAINTAINERS 
b/board/intel/agilex5-socdk/MAINTAINERS
new file mode 100644
index 00..f0bb2b796b
--- /dev/null
+++ b/board/intel/agilex5-socdk/MAINTAINERS
@@ -0,0 +1,8 @@
+SOCFPGA BOARD
+M: Tien Fong Chee 
+M: Jit Loon Lim 
+M: Sieu Mun Tang 
+S: Maintained
+F: board/intel/agilex5-socdk/
+F: include/configs/socfpga_agilex5_socdk.h
+F: configs/socfpga_agilex5_defconfig
diff --git a/board/intel/agilex5-socdk/Makefile 
b/board/intel/agilex5-socdk/Makefile
new file mode 100644
index 00..52f7de8880
--- /dev/null
+++ b/board/intel/agilex5-socdk/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2022 Intel Corporation 
+#
+# SPDX-License-Identifier: GPL-2.0
+#
+
+obj-y  := socfpga.o
diff --git a/board/intel/agilex5-socdk/socfpga.c 
b/board/intel/agilex5-socdk/socfpga.c
new file mode 100644
index 00..ae5c04557c
--- /dev/null
+++ b/board/intel/agilex5-socdk/socfpga.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Intel Corporation 
+ *
+ */
+
+#include 
-- 
2.26.2

[PATCH v1 04/17] arch: arm: mach-socfpga: include: mach: add new platform agilex5 mach-socfpga enablement

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add platform related header files to enable new product.

Signed-off-by: Jit Loon Lim 
---
 .../include/mach/base_addr_soc64.h|  43 +-
 .../mach-socfpga/include/mach/clock_manager.h |   5 +-
 .../include/mach/clock_manager_agilex5.h  |  12 ++
 arch/arm/mach-socfpga/include/mach/firewall.h |  42 +-
 .../mach-socfpga/include/mach/handoff_soc64.h |  25 +++-
 .../mach-socfpga/include/mach/mailbox_s10.h   |  32 +++--
 .../include/mach/reset_manager_soc64.h|  33 -
 .../mach-socfpga/include/mach/smmu_agilex5.h  |  30 +
 arch/arm/mach-socfpga/include/mach/smmu_s10.h |  73 ++
 .../include/mach/system_manager_soc64.h   | 126 --
 arch/arm/mach-socfpga/include/mach/timer.h|  30 +
 11 files changed, 419 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_agilex5.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/smmu_agilex5.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/smmu_s10.h

diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
index 3f899fcfa3..4a88770638 100644
--- a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
@@ -1,21 +1,60 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Copyright (C) 2016-2021 Intel Corporation 
+ * Copyright (C) 2016-2023 Intel Corporation 
  */
 
 #ifndef _SOCFPGA_SOC64_BASE_HARDWARE_H_
 #define _SOCFPGA_SOC64_BASE_HARDWARE_H_
 
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)
+#define SOCFPGA_CCU_ADDRESS0x1c00
+#define SOCFPGA_F2SDRAM_MGR_ADDRESS0x18001000
+#define SOCFPGA_SMMU_ADDRESS   0x1600
+#define SOCFPGA_OCRAM_FIREWALL_ADDRESS 0x108cc400
+#define SOCFPGA_MAILBOX_ADDRESS0x10a3
+#define SOCFPGA_UART0_ADDRESS  0x10c02000
+#define SOCFPGA_UART1_ADDRESS  0x10c02100
+#define SOCFPGA_SPTIMER0_ADDRESS   0x10c03000
+#define SOCFPGA_SPTIMER1_ADDRESS   0x10c03100
+#define SOCFPGA_SYSTIMER0_ADDRESS  0x10d0
+#define SOCFPGA_SYSTIMER1_ADDRESS  0x10d00100
+#define SOCFPGA_L4WD0_ADDRESS  0x10d00200
+#define SOCFPGA_L4WD1_ADDRESS  0x10d00300
+#define SOCFPGA_L4WD2_ADDRESS  0x10d00400
+#define SOCFPGA_L4WD3_ADDRESS  0x10d00500
+#define SOCFPGA_L4WD4_ADDRESS  0x10d00600
+#define SOCFPGA_GTIMER_SEC_ADDRESS 0x10d01000
+#define SOCFPGA_GTIMER_NSEC_ADDRESS0x10d02000
+#define SOCFPGA_CLKMGR_ADDRESS 0x10d1
+#define SOCFPGA_RSTMGR_ADDRESS 0x10d11000
+#define SOCFPGA_SYSMGR_ADDRESS 0x10d12000
+#define SOCFPGA_OCRAM_ADDRESS  0x
+#define SOCFPGA_FW_DDR_CCU_DMI0_ADDRESS0x18000800
+#define SOCFPGA_FW_DDR_CCU_DMI1_ADDRESS0x18000A00
+#define SOCFPGA_FW_TBU2NOC_ADDRESS 0x18000C00
+#define SOCFPGA_FIREWALL_L4_PER0xffd21000 /* TODO */
+#define SOCFPGA_FIREWALL_L4_SYS0xffd21100 /* TODO */
+#define SOCFPGA_FIREWALL_SOC2FPGA  0xffd21200 /* TODO */
+#define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300 /* TODO */
+#define SOCFPGA_FIREWALL_TCU   0xffd21400 /* TODO */
+#define SOCFPGA_FIREWALL_PRIV_MEMORYMAP_PRIV   0xffd24800 /* TODO */
+#define SOCFPGA_DMANONSECURE_ADDRESS   0xffda /* TODO */
+#define SOCFPGA_DMASECURE_ADDRESS  0xffda1000 /* TODO */
+#define GICD_BASE  0x1d00
+#define GICR_BASE  0x1d06
+#else
 #define SOCFPGA_CCU_ADDRESS0xf700
 #define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
 #define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xf801
 #define SOCFPGA_SDR_ADDRESS0xf8011000
+#define SOCFPGA_FW_MPFE_SCR_ADDRESS0xf802
 #if IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) || \
IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
 #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020200
 #else
 #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020100
 #endif
+#define SOCFPGA_F2SDRAM_MGR_ADDRESS0xf8024000
 #define SOCFPGA_SMMU_ADDRESS   0xfa00
 #define SOCFPGA_MAILBOX_ADDRESS0xffa3
 #define SOCFPGA_UART0_ADDRESS  0xffc02000
@@ -39,10 +78,12 @@
 #define SOCFPGA_FIREWALL_SOC2FPGA  0xffd21200
 #define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300
 #define SOCFPGA_FIREWALL_TCU   0xffd21400
+#define SOCFPGA_FIREWALL_PRIV_MEMORYMAP_PRIV   0xffd24800
 #define SOCFPGA_DMANONSECURE_ADDRESS   0xffda
 #define SOCFPGA_DMASECURE_ADDRESS  0xffda1000
 #define

[PATCH v1 03/17] arch: arm: mach-socfpga: add new platform agilex5 mach-socfpga enablement

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add platform related files to enable new product.

Signed-off-by: Jit Loon Lim 
---
 arch/arm/mach-socfpga/Kconfig |  37 +++
 arch/arm/mach-socfpga/Makefile|  69 -
 arch/arm/mach-socfpga/board.c |  65 -
 arch/arm/mach-socfpga/clock_manager_agilex5.c |  82 ++
 arch/arm/mach-socfpga/firewall.c  | 107 ---
 arch/arm/mach-socfpga/lowlevel_init_agilex5.S |  61 
 arch/arm/mach-socfpga/lowlevel_init_soc64.S   | 167 ++-
 arch/arm/mach-socfpga/mailbox_s10.c   |  21 ++
 arch/arm/mach-socfpga/misc.c  |  19 +-
 arch/arm/mach-socfpga/misc_soc64.c|  33 ++-
 arch/arm/mach-socfpga/mmu-arm64_s10.c |  43 ++-
 arch/arm/mach-socfpga/reset_manager_s10.c | 271 +++---
 arch/arm/mach-socfpga/secure_reg_helper.c |   4 +-
 arch/arm/mach-socfpga/smmu_agilex5.c  |  34 +++
 arch/arm/mach-socfpga/smmu_s10.c  | 126 
 arch/arm/mach-socfpga/spl_agilex5.c   | 180 
 arch/arm/mach-socfpga/spl_soc64.c | 188 +++-
 arch/arm/mach-socfpga/u-boot-spl-soc64.lds|  93 ++
 arch/arm/mach-socfpga/wrap_handoff_soc64.c|   7 +-
 19 files changed, 1429 insertions(+), 178 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/clock_manager_agilex5.c
 delete mode 100644 arch/arm/mach-socfpga/firewall.c
 create mode 100644 arch/arm/mach-socfpga/lowlevel_init_agilex5.S
 create mode 100644 arch/arm/mach-socfpga/smmu_agilex5.c
 create mode 100644 arch/arm/mach-socfpga/smmu_s10.c
 create mode 100644 arch/arm/mach-socfpga/spl_agilex5.c
 create mode 100644 arch/arm/mach-socfpga/u-boot-spl-soc64.lds

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 503c82d388..562c3796ec 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -44,6 +44,15 @@ config TEXT_BASE
default 0x0140 if TARGET_SOCFPGA_ARRIA10
default 0x0140 if TARGET_SOCFPGA_GEN5
 
+config ARMV8_PSCI_NR_CPUS
+   default 4 if TARGET_SOCFPGA_SOC64
+
+config ARMV8_SECURE_BASE
+   default 0x1000 if TARGET_SOCFPGA_SOC64 && ARMV8_PSCI
+
+config SYS_HAS_ARMV8_SECURE_BASE
+   default y if TARGET_SOCFPGA_SOC64 && ARMV8_PSCI
+
 config TARGET_SOCFPGA_AGILEX
bool
select ARMV8_MULTIENTRY
@@ -51,10 +60,31 @@ config TARGET_SOCFPGA_AGILEX
select BINMAN if SPL_ATF
select CLK
select FPGA_INTEL_SDM_MAILBOX
+   select GICV2
+   select NCORE_CACHE
+   select SPL_CLK if SPL
+   select TARGET_SOCFPGA_SOC64
+
+config TARGET_SOCFPGA_AGILEX5
+   bool
+   select BINMAN if SPL_ATF
+   select CLK
+   select FPGA_INTEL_SDM_MAILBOX
+   select GICV3
select NCORE_CACHE
select SPL_CLK if SPL
select TARGET_SOCFPGA_SOC64
 
+config TARGET_SOCFPGA_AGILEX5_EMU
+   bool "Enable build that bootable only on Agilex5 Emulator"
+   help
+This is to use for Agilex5 Emulator.
+
+config TARGET_SOCFPGA_AGILEX5_SIMICS
+   bool "Enable build that bootable only on Agilex5 Simics platform"
+   help
+This is to use for Agilex5 Simics.
+
 config TARGET_SOCFPGA_ARRIA5
bool
select TARGET_SOCFPGA_GEN5
@@ -126,6 +156,10 @@ config TARGET_SOCFPGA_AGILEX_SOCDK
bool "Intel SOCFPGA SoCDK (Agilex)"
select TARGET_SOCFPGA_AGILEX
 
+config TARGET_SOCFPGA_AGILEX5_SOCDK
+   bool "Intel SOCFPGA SoCDK (Agilex5)"
+   select TARGET_SOCFPGA_AGILEX5
+
 config TARGET_SOCFPGA_ARIES_MCVEVK
bool "Aries MCVEVK (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
@@ -199,6 +233,7 @@ config TARGET_SOCFPGA_TERASIC_SOCKIT
 endchoice
 
 config SYS_BOARD
+   default "agilex5-socdk" if TARGET_SOCFPGA_AGILEX5_SOCDK
default "agilex-socdk" if TARGET_SOCFPGA_AGILEX_SOCDK
default "arria5-socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
default "arria10-socdk" if TARGET_SOCFPGA_ARRIA10_SOCDK
@@ -220,6 +255,7 @@ config SYS_BOARD
default "vining_fpga" if TARGET_SOCFPGA_SOFTING_VINING_FPGA
 
 config SYS_VENDOR
+   default "intel" if TARGET_SOCFPGA_AGILEX5_SOCDK
default "intel" if TARGET_SOCFPGA_AGILEX_SOCDK
default "intel" if TARGET_SOCFPGA_N5X_SOCDK
default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
@@ -242,6 +278,7 @@ config SYS_SOC
default "socfpga"
 
 config SYS_CONFIG_NAME
+   default "socfpga_agilex5_socdk" if TARGET_SOCFPGA_AGILEX5_SOCDK
default "socfpga_agilex_socdk" if TARGET_SOCFPGA_AGILEX_SOCDK
default "socfpga_arria5_secu1" if TARGET_SOCFPGA_ARRIA5_SECU1
default "socfpga_arria5_socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index ec38b64dd4..771e7ce77d 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -35,10 +35,22 @@ obj-y   += mailbox_s10.o
 obj-y  +=

[PATCH v1 02/17] arch: arm: dts: add dts and dtsi for new platform agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5.
Add agilex5 dtsi and dts.
Update checkpatch error for stratix10.

Signed-off-by: Jit Loon Lim 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/socfpga_agilex5-u-boot.dtsi  | 459 +
 arch/arm/dts/socfpga_agilex5.dtsi | 634 ++
 .../arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 131 
 arch/arm/dts/socfpga_agilex5_socdk.dts| 165 +
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi|  38 +-
 arch/arm/dts/socfpga_soc64_u-boot.dtsi| 120 
 arch/arm/dts/socfpga_stratix10.dtsi   |   0
 .../dts/socfpga_stratix10_socdk-u-boot.dtsi   |   0
 arch/arm/dts/socfpga_stratix10_socdk.dts  |   0
 10 files changed, 1534 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm/dts/socfpga_agilex5-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_agilex5.dtsi
 create mode 100644 arch/arm/dts/socfpga_agilex5_socdk-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_agilex5_socdk.dts
 create mode 100644 arch/arm/dts/socfpga_soc64_u-boot.dtsi
 mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10.dtsi
 mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
 mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10_socdk.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..2e4bc556e1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -456,6 +456,7 @@ dtb-$(CONFIG_TARGET_THUNDERX_88XX) += thunderx-88xx.dtb
 
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_agilex_socdk.dtb\
+   socfpga_agilex5_socdk.dtb   \
socfpga_arria5_secu1.dtb\
socfpga_arria5_socdk.dtb\
socfpga_arria10_chameleonv3_270_2.dtb   \
diff --git a/arch/arm/dts/socfpga_agilex5-u-boot.dtsi 
b/arch/arm/dts/socfpga_agilex5-u-boot.dtsi
new file mode 100644
index 00..6a1299901a
--- /dev/null
+++ b/arch/arm/dts/socfpga_agilex5-u-boot.dtsi
@@ -0,0 +1,459 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2019-2022 Intel Corporation 
+ */
+
+#include "socfpga_soc64_u-boot.dtsi"
+#include "socfpga_soc64_fit-u-boot.dtsi"
+
+/{
+   memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   bootph-all;
+   };
+
+   soc {
+   bootph-all;
+
+   socfpga_secreg: socfpga-secreg {
+   compatible = "intel,socfpga-secreg";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   bootph-all;
+
+   /* DSU */
+   i_ccu_caiu0@1c00 {
+   reg = <0x1c00 0x1000>;
+   intel,offset-settings =
+   /* CAIUAMIGR */
+   <0x03c0 0x0003 0x001f>,
+   /* CAIUMIFSR */
+   <0x03c4 0x 0x07070777>,
+   /* DII1_MPFEREGS */
+   <0x0414 0x00018000 0x>,
+   <0x0418 0x 0x00ff>,
+   <0x0410 0xc0e00200 0xc1f03e1f>,
+   /* DII2_GICREGS */
+   <0x0424 0x0001d000 0x>,
+   <0x0428 0x 0x00ff>,
+   <0x0420 0xc0800400 0xc1f03e1f>,
+   /* NCAIU0_LWSOC2FPGA */
+   <0x0444 0x0002 0x>,
+   <0x0448 0x 0x00ff>,
+   <0x0440 0xc116 0xc1f03e1f>,
+   /* NCAIU0_SOC2FPGA_1G */
+   <0x0454 0x0004 0x>,
+   <0x0458 0x 0x00ff>,
+   <0x0450 0xc126 0xc1f03e1f>,
+   /* DMI_SDRAM_2G */
+   <0x0464 0x0008 0x>,
+   <0x0468 0x 0x00ff>,
+   <0x0460 0x8136 0xc1f03e1f>,
+   /* NCAIU0_SOC2FPGA_16G */
+   <0x0474 0x0040 0x>,
+   <0x0478 0x 0x00ff>,
+   <0x0470 0xc166 0xc1f03e1f>,
+   /* DMI_SDRAM_30G */
+

[PATCH v1 01/17] arch: arm: update kconfig for new platform agilex5

2023-06-20 Thread Jit Loon Lim

This is for new platform enablement for agilex5

Signed-off-by: Jit Loon Lim 
---
 arch/arm/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 99264a6478..8e36456fa8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1093,6 +1093,8 @@ config ARCH_SOCFPGA
select SPL_LIBGENERIC_SUPPORT
select SPL_OF_CONTROL
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_SOC64
+   select SPL_DRIVERS_MISC if TARGET_SOCFPGA_SOC64
+   select SPL_SOCFPGA_SEC_REG if TARGET_SOCFPGA_SOC64
select SPL_SERIAL
select SPL_SYSRESET
select SPL_WATCHDOG
@@ -1101,7 +1103,8 @@ config ARCH_SOCFPGA
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
select SYSRESET
select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
-   select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_SOC64
+   select SYSRESET_SOCFPGA_SOC64 if !TARGET_SOCFPGA_AGILEX5 && 
TARGET_SOCFPGA_SOC64
+   imply SYSRESET_SOCFPGA_AGILEX5 if TARGET_SOCFPGA_AGILEX5
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
-- 
2.26.2

[PATCH v1 00/17] Agilex5 Platform Enablement

2023-06-20 Thread Jit Loon Lim

Intel Agilex5 is a midrange FPGAs optimized for applications requiring high 
performance, 
lower power, and smaller form factors and lower logic densities. U-Boot is one 
of the 
bootloader to boot along with ARM trusted Firmware to boot the board up.

*** BLURB HERE ***

Jit Loon Lim (16):
  arch: arm: update kconfig for new platform agilex5
  arch: arm: dts: add dts and dtsi for new platform agilex5
  arch: arm: mach-socfpga: add new platform agilex5 mach-socfpga
enablement
  arch: arm: mach-socfpga: include: mach: add new platform agilex5
mach-socfpga enablement
  board: intel: add new platform agilex5 socdk
  configs: add new platform agilex5 defconfig
  doc: device-tree-bindings: misc: add secreg text file for agilex5
  drivers: ddr: altera: add ddr support for agilex5
  drivers: clk: altera: add clock support for agilex5
  drivers: misc: update driver misc for agilex5
  drivers: mmc: add mmc/cadence driver for agilex5
  drivers: phy: add combo phy driver for agilex5
  drivers: reset: add reset driver for agilex5
  drivers: sysreset: add system driver for agilex5
  drivers: watchdog: update watchdog driver for agilex5
  includes: add and update configuration for agilex5

Sieu Mun Tang (1):
  tools: binman: update binman tool for agilex5

 arch/arm/Kconfig  |   5 +-
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/socfpga_agilex5-u-boot.dtsi  | 459 ++
 arch/arm/dts/socfpga_agilex5.dtsi | 634 +
 .../arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 131 +++
 arch/arm/dts/socfpga_agilex5_socdk.dts| 165 
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi|  38 +-
 arch/arm/dts/socfpga_soc64_u-boot.dtsi| 120 +++
 arch/arm/dts/socfpga_stratix10.dtsi   |   0
 .../dts/socfpga_stratix10_socdk-u-boot.dtsi   |   0
 arch/arm/dts/socfpga_stratix10_socdk.dts  |   0
 arch/arm/mach-socfpga/Kconfig |  92 ++
 arch/arm/mach-socfpga/Makefile|  69 +-
 arch/arm/mach-socfpga/board.c |  65 +-
 arch/arm/mach-socfpga/clock_manager_agilex5.c |  82 ++
 arch/arm/mach-socfpga/firewall.c  | 107 ---
 .../include/mach/base_addr_soc64.h|  43 +-
 .../mach-socfpga/include/mach/clock_manager.h |   5 +-
 .../include/mach/clock_manager_agilex5.h  |  12 +
 arch/arm/mach-socfpga/include/mach/firewall.h |  42 +-
 .../mach-socfpga/include/mach/handoff_soc64.h |  25 +-
 .../mach-socfpga/include/mach/mailbox_s10.h   |  32 +-
 .../include/mach/reset_manager_soc64.h|  33 +-
 .../mach-socfpga/include/mach/smmu_agilex5.h  |  30 +
 arch/arm/mach-socfpga/include/mach/smmu_s10.h |  73 ++
 .../include/mach/system_manager_soc64.h   | 126 ++-
 arch/arm/mach-socfpga/include/mach/timer.h|  30 +
 arch/arm/mach-socfpga/lowlevel_init_agilex5.S |  61 ++
 arch/arm/mach-socfpga/lowlevel_init_soc64.S   | 167 +++-
 arch/arm/mach-socfpga/mailbox_s10.c   |  21 +
 arch/arm/mach-socfpga/misc.c  |  19 +-
 arch/arm/mach-socfpga/misc_soc64.c|  33 +-
 arch/arm/mach-socfpga/mmu-arm64_s10.c |  43 +-
 arch/arm/mach-socfpga/reset_manager_s10.c | 271 +-
 arch/arm/mach-socfpga/secure_reg_helper.c |   4 +-
 arch/arm/mach-socfpga/smmu_agilex5.c  |  34 +
 arch/arm/mach-socfpga/smmu_s10.c  | 126 +++
 arch/arm/mach-socfpga/spl_agilex5.c   | 180 
 arch/arm/mach-socfpga/spl_soc64.c | 188 +++-
 arch/arm/mach-socfpga/u-boot-spl-soc64.lds|  93 ++
 arch/arm/mach-socfpga/wrap_handoff_soc64.c|   7 +-
 board/intel/agilex5-socdk/MAINTAINERS |   8 +
 board/intel/agilex5-socdk/Makefile|   7 +
 board/intel/agilex5-socdk/socfpga.c   |   7 +
 configs/socfpga_agilex5_defconfig | 125 +++
 configs/socfpga_agilex5_legacy_defconfig  |  87 ++
 .../misc/socfpga_secreg.txt   | 397 
 drivers/clk/altera/Makefile   |   1 +
 drivers/clk/altera/clk-agilex5.c  | 736 +++
 drivers/clk/altera/clk-agilex5.h  | 263 ++
 drivers/ddr/altera/Makefile   |   5 +-
 drivers/ddr/altera/iossm_mailbox.c| 786 
 drivers/ddr/altera/iossm_mailbox.h| 141 +++
 drivers/ddr/altera/sdram_agilex5.c| 329 +++
 drivers/ddr/altera/sdram_soc64.c  |  78 +-
 drivers/ddr/altera/sdram_soc64.h  |  17 +-
 drivers/misc/Kconfig  |   9 +
 drivers/misc/Makefile |   1 +
 drivers/misc/socfpga_secreg.c | 116 +++
 drivers/mmc/mmc.c |  27 +-
 drivers/mmc/sdhci-cadence.c   | 164 +++-
 drivers/phy/cadence/Kconfig   |   9 +
 drivers/phy/cadence/Makefile  |   1 +
 drivers/phy/cadence/phy-cadence-combophy.c| 855 ++
 drivers/reset/reset-socfpga.c |  28 +-

[PATCH v3 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread teik . heng . chong

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields
as if they were mere RW. This leads to unintended clearing of such fields

This bug was found during the testing on Simics model. Referring to
specification DesignWare Cores USB 2.0 Hi-Speed On-The-Go (OTG)
Databook (3.30a)"5.3.4.8 Host Port Control and Status Register (HPRT)", the
HPRT.PrtPwr is cleared by this mistake. In the Linux driver (contrary to
U-Boot), HPRT is always read using dwc2_read_hprt0 helper function which
clears W1C bits. So after write back those bits are zeroes.

Signed-off-by: Teik Heng Chong 

---

V2->V3
- update commit message
---
 drivers/usb/host/dwc2.c | 34 --
 drivers/usb/host/dwc2.h |  4 
 2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev,
 
/* Turn on the vbus power. */
if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(>hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(>hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, >hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(>hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
 
case USB_PORT_FEAT_RESET:
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_POWER:
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_ENABLE:
@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
 
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
 
for (i = 0; i < MAX_DEVICE; i++) {
for (j = 0; j < MAX_ENDPOINT; j++) {
@@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
 static void dwc2_uninit_common(struct dwc2_core_regs *regs)
 {
/* Put everything in reset. */
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
 }
 
 #if !CONFIG_IS_ENABLED(DM_USB)
diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -543,6 +543,10 @@ struct dwc2_core_regs {
 #define DWC2_HPRT0_PRTSPD_LOW  (2 << 17)
 #define DWC2_HPRT0_PRTSPD_MASK

RE: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Chong, Teik Heng

> -Original Message-
> From: Marek Vasut 
> Sent: Wednesday, 21 June, 2023 9:20 AM
> To: Chong, Teik Heng ; u-boot@lists.denx.de
> Cc: Jagan Teki ; Vignesh R
> ; Simon ; Kris
> ; Chee, Tien Fong ; Hea,
> Kok Kiang ; Lokanathan, Raaj
> ; Maniyam, Dinesh
> ; Ng, Boon Khai ;
> Yuslaimi, Alif Zakuan ; Zamri, Muhammad
> Hazim Izzat ; Lim, Jit Loon
> ; Tang, Sieu Mun ;
> Patrice CHOTARD ; Patrick DELAUNAY
> 
> Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT
> register
> 
> On 6/21/23 02:57, Chong, Teik Heng wrote:
> > -Original Message-
> > From: Marek Vasut 
> > Sent: Wednesday, 21 June, 2023 5:38 AM
> > To: Chong, Teik Heng ; u-boot@lists.denx.de
> > Cc: Jagan Teki ; Vignesh R
> > ; Simon ; Kris
> > ; Chee, Tien Fong ;
> > Hea, Kok Kiang ; Lokanathan, Raaj
> > ; Maniyam, Dinesh
> > ; Ng, Boon Khai ;
> > Yuslaimi, Alif Zakuan ; Zamri,
> > Muhammad Hazim Izzat ; Lim,
> Jit
> > Loon ; Tang, Sieu Mun
> > ; Patrice CHOTARD
> > ; Patrick DELAUNAY
> > 
> > Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in
> > HPRT register
> >
> > On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:
> >> From: Teik Heng Chong 
> >>
> >> Fix the write to the HPRT register which treat W1C fields as if they
> >> were mere RW. This leads to unintended clearing of such fields
> >>
> >> Signed-off-by: Teik Heng Chong 
> >>
> >> ---
> >>
> >> V1->V2
> >> - update subject tags to usb:dwc2
> >> ---
> >>drivers/usb/host/dwc2.c | 34 --
> >>drivers/usb/host/dwc2.h |  4 
> >>2 files changed, 12 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index
> >> 23060fc369..9818f9be94 100644
> >> --- a/drivers/usb/host/dwc2.c
> >> +++ b/drivers/usb/host/dwc2.c
> >> @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice
> >> *dev,
> >>
> >>/* Turn on the vbus power. */
> >>if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
> >> -  hprt0 = readl(>hprt0);
> >> -  hprt0 &= ~(DWC2_HPRT0_PRTENA |
> DWC2_HPRT0_PRTCONNDET);
> >> -  hprt0 &= ~(DWC2_HPRT0_PRTENCHNG |
> DWC2_HPRT0_PRTOVRCURRCHNG);
> >> +  hprt0 = readl(>hprt0) & ~DWC2_HPRT0_W1C_MASK;
> >>if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
> >>hprt0 |= DWC2_HPRT0_PRTPWR;
> >>writel(hprt0, >hprt0);
> >> @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct
> dwc2_priv *priv,
> >>case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER |
> USB_TYPE_CLASS:
> >>switch (wValue) {
> >>case USB_PORT_FEAT_C_CONNECTION:
> >> -  setbits_le32(>hprt0,
> DWC2_HPRT0_PRTCONNDET);
> >> +  clrsetbits_le32(>hprt0,
> DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTCONNDET);
> >>break;
> >>}
> >>break;
> >> @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct
> dwc2_priv *priv,
> >>break;
> >>
> >>case USB_PORT_FEAT_RESET:
> >> -  clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA
> |
> >> -  DWC2_HPRT0_PRTCONNDET |
> >> -  DWC2_HPRT0_PRTENCHNG |
> >> -  DWC2_HPRT0_PRTOVRCURRCHNG,
> >> -  DWC2_HPRT0_PRTRST);
> >> +  clrsetbits_le32(>hprt0,
> DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTRST);
> >>mdelay(50);
> >> -  clrbits_le32(>hprt0, DWC2_HPRT0_PRTRST);
> >> +  clrbits_le32(>hprt0,
> DWC2_HPRT0_W1C_MASK |
> >> +DWC2_HPRT0_PRTRST);
> >>break;
> >>
> >>case USB_PORT_FEAT_POWER:
> >> -  clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA
> |
> >> -  DWC2_HPRT0_PRTCONNDET |
> >> -  DWC2_HPRT0_PRTENCHNG |
> >> -  DWC2_HPRT0_PRTOVRCURRCHNG,
> >> -  DWC2_HPRT0_PRTRST);
> >> +  clrsetbits_le32(>hprt0,
> DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTRST);
> >>break;
> >>
> >>case USB_PORT_FEAT_ENABLE:
> >> @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice
> *dev, struct dwc2_priv *priv)
> >>dwc_otg_core_host_init(dev, regs);
> >>}
> >>
> >> -  clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
> >> -  DWC2_HPRT0_PRTCONNDET |
> DWC2_HPRT0_PRTENCHNG |
> >> -  DWC2_HPRT0_PRTOVRCURRCHNG,
> >> -  DWC2_HPRT0_PRTRST);
> >> +  clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK,
> >> +DWC2_HPRT0_PRTRST);
> >>mdelay(50);
> >> -  clrbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
> DWC2_HPRT0_PRTCONNDET |
> >> -

Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM

2023-06-20 Thread Rick Chen

> From: Yanhong Wang 
> Sent: Thursday, June 15, 2023 5:37 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo 
> Yu-Chi Liang(梁育齊) ; Joe Hershberger 
> ; Ramon Fried 
> Cc: Yanhong Wang ; Torsten Duwe ; 
> Leyfoon Tan ; samin . guo 
> ; Walker Chen ; Hal 
> Feng 
> Subject: [PATCH v5 10/11] ram: starfive: Read memory size information from 
> EEPROM
>
> StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of DDR 
> capacity includes 2G/4G/8G, a DT can not support multiple capacities, so the 
> capacity size information is recorded to EEPROM, when DDR initialization 
> required capacity size information is read from EEPROM.
>
> If there is no information in EEPROM, it is initialized with the default size 
> defined in DT.
>
> Signed-off-by: Yanhong Wang 
> ---
>  arch/riscv/cpu/jh7110/spl.c | 32 -
>  drivers/ram/starfive/starfive_ddr.c |  2 --
>  2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c index 
> 104f0fe949..72adcefa0e 100644
> --- a/arch/riscv/cpu/jh7110/spl.c
> +++ b/arch/riscv/cpu/jh7110/spl.c
> @@ -3,19 +3,49 @@
>   * Copyright (C) 2022 StarFive Technology Co., Ltd.
>   * Author: Yanhong Wang
>   */
> -
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>
>  #define CSR_U74_FEATURE_DISABLE0x7c1
>  #define L2_LIM_MEM_END 0x81FUL
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static bool check_ddr_size(phys_size_t size) {
> +   switch (size) {
> +   case SZ_2:
> +   case SZ_4:
> +   case SZ_8:
> +   case SZ_16:

In commit message, it describes that "DDR capacity includes 2G/4G/8G".
Is it mismatch here ?

> +   return true;
> +   default:
> +   return false;
> +   }
> +}
> +
>  int spl_soc_init(void)
>  {
> int ret;
> struct udevice *dev;
> +   phys_size_t size;
> +
> +   ret = fdtdec_setup_mem_size_base();
> +   if (ret)
> +   return ret;

It maybe unnecessary to add return above. If it fail to parse memory
node from DT, then there
has no chance to get ddr size from eeprom.

Thanks,
Rick

> +
> +   /* Read the definition of the DDR size from eeprom, and if not,
> +* use the definition in DT
> +*/
> +   size = (get_ddr_size_from_eeprom() >> 16) & 0xFF;
> +   if (check_ddr_size(size))
> +   gd->ram_size = size << 30;
>
> /* DDR init */
> ret = uclass_get_device(UCLASS_RAM, 0, ); diff --git 
> a/drivers/ram/starfive/starfive_ddr.c b/drivers/ram/starfive/starfive_ddr.c
> index 553f2ce6f4..a0a3d6b33d 100644
> --- a/drivers/ram/starfive/starfive_ddr.c
> +++ b/drivers/ram/starfive/starfive_ddr.c
> @@ -72,8 +72,6 @@ static int starfive_ddr_probe(struct udevice *dev)
> u64 rate;
> int ret;
>
> -   /* Read memory base and size from DT */
> -   fdtdec_setup_mem_size_base();
> priv->info.base = gd->ram_base;
> priv->info.size = gd->ram_size;
>
> --
> 2.17.1

Re: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for 1.2A and 1.3B

2023-06-20 Thread Rick Chen

> From: Yanhong Wang 
> Sent: Thursday, June 15, 2023 5:37 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo 
> Yu-Chi Liang(梁育齊) ; Joe Hershberger 
> ; Ramon Fried 
> Cc: Yanhong Wang ; Torsten Duwe ; 
> Leyfoon Tan ; samin . guo 
> ; Walker Chen ; Hal 
> Feng 
> Subject: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for 
> 1.2A and 1.3B
>
> The main difference between StarFive VisionFive 2 1.2A and 1.3B is gmac.
> You can read the PCB version of the current board by 
> get_pcb_revision_from_eeprom(), and then dynamically configure the difference 
> of gmac in spl_perform_fixups() according to different PCB versions, so that 
> one DT and one defconfig can support both 1.2A and 1.3B versions, which is 
> more user-friendly.
>
> Signed-off-by: Yanhong Wang 
> ---
>  board/starfive/visionfive2/spl.c | 157 +++
>  1 file changed, 157 insertions(+)

Reviewed-by: Rick Chen

Re: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux

2023-06-20 Thread Rick Chen

> From: Conor Dooley 
> Sent: Thursday, June 15, 2023 6:13 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; Padmarao Begari ; 
> Conor Dooley 
> Subject: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux
>
> The "notable" disappearances are:
> - the pac193x stanza - there's nothing in mainline linux w.r.t. bindings
>   for this & what is going to appear in mainline linux is going to be
>   incompatible with what is currently in U-Boot.
> - operating points - these operating points should not be set at the
>   soc.dtsi level as they may not be possible depending on the design
>   programmed to the FPGA
> - clock output names - there are defines for the clock indices, these
>   should not be needed
> - the dt maintainers in linux NAKed using defines for IRQ numbers
> - the qspi nand, which is not part of the icicle's default configuration
>   is removed.
>
> Reviewed-by: Padmarao Begari 
> Tested-by: Padmarao Begari 
> Signed-off-by: Conor Dooley 
> ---
>  arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi|  71 +++
>  arch/riscv/dts/mpfs-icicle-kit.dts| 190 +---
>  arch/riscv/dts/mpfs.dtsi  | 442 --
>  .../dt-bindings/clock/microchip-mpfs-clock.h  |  29 +-
>  .../microchip-mpfs-plic.h | 196 
>  .../interrupt-controller/riscv-hart.h |  17 -

Reviewed-by: Rick Chen

Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Marek Vasut


On 6/21/23 02:57, Chong, Teik Heng wrote:

-Original Message-
From: Marek Vasut 
Sent: Wednesday, 21 June, 2023 5:38 AM
To: Chong, Teik Heng ; u-boot@lists.denx.de
Cc: Jagan Teki ; Vignesh R ; Simon ; Kris ; 
Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh 
; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Zamri, Muhammad Hazim Izzat 
; Lim, Jit Loon ; Tang, Sieu Mun ; Patrice CHOTARD 
; Patrick DELAUNAY 
Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT 
register

On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields as if they
were mere RW. This leads to unintended clearing of such fields

Signed-off-by: Teik Heng Chong 

---

V1->V2
- update subject tags to usb:dwc2
---
   drivers/usb/host/dwc2.c | 34 --
   drivers/usb/host/dwc2.h |  4 
   2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index
23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice
*dev,
   
   	/* Turn on the vbus power. */

if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(>hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(>hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, >hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(>hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
   
   		case USB_PORT_FEAT_RESET:

-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK |
+DWC2_HPRT0_PRTRST);
break;
   
   		case USB_PORT_FEAT_POWER:

-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
break;
   
   		case USB_PORT_FEAT_ENABLE:

@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
   
-	clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |

-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
   
   	for (i = 0; i < MAX_DEVICE; i++) {

for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ 
static
int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
   static void dwc2_uninit_common(struct dwc2_core_regs *regs)
   {
/* Put everything in reset. */
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK,
+DWC2_HPRT0_PRTRST);
   }
   
   #if !CONFIG_IS_ENABLED(DM_USB)

diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h index
a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++

RE: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Chong, Teik Heng

-Original Message-
From: Marek Vasut  
Sent: Wednesday, 21 June, 2023 5:38 AM
To: Chong, Teik Heng ; u-boot@lists.denx.de
Cc: Jagan Teki ; Vignesh R ; Simon 
; Kris ; Chee, Tien 
Fong ; Hea, Kok Kiang ; 
Lokanathan, Raaj ; Maniyam, Dinesh 
; Ng, Boon Khai ; Yuslaimi, 
Alif Zakuan ; Zamri, Muhammad Hazim Izzat 
; Lim, Jit Loon ; 
Tang, Sieu Mun ; Patrice CHOTARD 
; Patrick DELAUNAY 
Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT 
register

On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:
> From: Teik Heng Chong 
> 
> Fix the write to the HPRT register which treat W1C fields as if they 
> were mere RW. This leads to unintended clearing of such fields
> 
> Signed-off-by: Teik Heng Chong 
> 
> ---
> 
> V1->V2
> - update subject tags to usb:dwc2
> ---
>   drivers/usb/host/dwc2.c | 34 --
>   drivers/usb/host/dwc2.h |  4 
>   2 files changed, 12 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 
> 23060fc369..9818f9be94 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice 
> *dev,
>   
>   /* Turn on the vbus power. */
>   if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
> - hprt0 = readl(>hprt0);
> - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
> - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
> + hprt0 = readl(>hprt0) & ~DWC2_HPRT0_W1C_MASK;
>   if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
>   hprt0 |= DWC2_HPRT0_PRTPWR;
>   writel(hprt0, >hprt0);
> @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
> *priv,
>   case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
>   switch (wValue) {
>   case USB_PORT_FEAT_C_CONNECTION:
> - setbits_le32(>hprt0, DWC2_HPRT0_PRTCONNDET);
> + clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTCONNDET);
>   break;
>   }
>   break;
> @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
> *priv,
>   break;
>   
>   case USB_PORT_FEAT_RESET:
> - clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET |
> - DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   mdelay(50);
> - clrbits_le32(>hprt0, DWC2_HPRT0_PRTRST);
> + clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | 
> +DWC2_HPRT0_PRTRST);
>   break;
>   
>   case USB_PORT_FEAT_POWER:
> - clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET |
> - DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   break;
>   
>   case USB_PORT_FEAT_ENABLE:
> @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, 
> struct dwc2_priv *priv)
>   dwc_otg_core_host_init(dev, regs);
>   }
>   
> - clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   mdelay(50);
> - clrbits_le32(>hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
> -  DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
> -  DWC2_HPRT0_PRTRST);
> + clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
>   
>   for (i = 0; i < MAX_DEVICE; i++) {
>   for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ 
> static 
> int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
>   static void dwc2_uninit_common(struct dwc2_core_regs *regs)
>   {
>   /* Put everything in reset. */
> - clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
> - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
> - DWC2_HPRT0_PRTOVRCURRCHNG,
> - DWC2_HPRT0_PRTRST);
> + clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
> +DWC2_HPRT0_PRTRST);
>   }
>   
>   #if !CONFIG_IS_ENABLED(DM_USB)
> diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h

[PATCH] arm: mvebu: Enable gpio-fan for Thecus N2350 board

2023-06-20 Thread Tony Dinh

Add gpio-fan in the DTS and enable the GPIO in board file to start the fan
during boot.

Note that this patch depends on
https://patchwork.ozlabs.org/project/uboot/patch/20230606214539.4229-1-mibo...@gmail.com/

Signed-off-by: Tony Dinh 
---

 arch/arm/dts/armada-385-thecus-n2350.dts | 15 +++
 board/thecus/n2350/n2350.c   |  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts 
b/arch/arm/dts/armada-385-thecus-n2350.dts
index 2ad5158c0c..253cf01130 100644
--- a/arch/arm/dts/armada-385-thecus-n2350.dts
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -140,6 +140,16 @@
};
};
 
+   fan {
+   compatible = "gpio-fan";
+   gpios = < 16 GPIO_ACTIVE_HIGH>;
+   gpio-fan,speed-map = <0  0
+   600  1
+   3000 2 >;
+   pinctrl-0 = <_fan>;
+   pinctrl-names = "default";
+   };
+
usb3_0_power: v5-vbus0 {
compatible = "regulator-fixed";
regulator-name = "USB3_0_Power";
@@ -378,6 +388,11 @@
marvell,pins = "mpp17";
marvell,function = "gpio";
};
+
+   pmx_fan: pmx-fan {
+   marvell,pins = "mpp48";
+   marvell,function = "gpio";
+   };
 };
 
  {
diff --git a/board/thecus/n2350/n2350.c b/board/thecus/n2350/n2350.c
index fd8f95f944..05b125fd7f 100644
--- a/board/thecus/n2350/n2350.c
+++ b/board/thecus/n2350/n2350.c
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define N2350_GPP_OUT_ENA_LOW  (~(BIT(20) | BIT(21) | BIT(24)))
 #define N2350_GPP_OUT_ENA_MID  (~(BIT(12) | BIT(13) | BIT(16) | BIT(19) | 
BIT(22)))
 #define N2350_GPP_OUT_VAL_LOW  (BIT(21) | BIT(24))
-#define N2350_GPP_OUT_VAL_MID  (BIT(0) | BIT(12) | BIT(13))
+#define N2350_GPP_OUT_VAL_MID  (BIT(0) | BIT(12) | BIT(13) | BIT(16))
 #define N2350_GPP_POL_LOW  0x0
 #define N2350_GPP_POL_MID  0x0
 
-- 
2.39.2

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Marek Vasut


On 6/20/23 12:43, Xavier Drudis Ferran wrote:

El Tue, Jun 20, 2023 at 11:49:36AM +0200, Marek Vasut deia:


Default, see:
$ git grep CONFIG_BOOTCOMMAND configs/



I'm lost.

I called default what Kconfig used as default.
You seem to call default what's in board specific config files.
Whatever. Fix the wording in the commit message if you like.


All I am really asking for is minimal test case.
That is all I was asking for since the very beginning.

So to answer my own question, this is the minimal test case:

=> usb reset ; bootflow scan ; usb info

Can you please add it to the commit message, collect RB from Simon, add

Reviewed-by: Marek Vasut 
Tested-by: Marek Vasut 

And send V2 so I can pick it for this release ?

Thank you

Re: imx8m optee load address?

2023-06-20 Thread Tim Harvey

On Mon, Jun 19, 2023 at 1:40 PM Tim Harvey  wrote:
>
> On Fri, Jun 16, 2023 at 4:52 PM Tim Harvey  wrote:
> >
> > On Thu, Jun 15, 2023 at 8:31 PM Peng Fan  wrote:
> > >
> > >
> > >
> > > On 6/16/2023 9:56 AM, Tim Harvey wrote:
> > > > Greetings,
> > > >
> > > > I've seen several IMX8M boards include a firmware/optee node in the
> > > > U-Boot dt (git grep optee arch/arm/dts/imx8m*.dtsi) yet but none that
> > > > I see configure binman to actually add the binary in the u-boot.dtsi,
> > > > do anything to keep U-Boot from accessing the OPTEE memory, or
> > > > document how to configure and build OPTEE for imx8m. I would like to
> > > > add such support but I find it odd that OPTEE needs to be built
> > > > differently depending on the dram size.
> > > >
> > > > Prior to switching to binman (v2021.10)
> > > > arch/arm/mach-imx/mkimage_fit_atf.sh [1] would include tee.bin in the
> > > > FIT image if it was found in the current directory and it was expected
> > > > that you provide a proper TEE_LOAD_ADDR via the env (commit
> > > > a9eed6e1b8d8 ("imx: imx8m: introduce script to generate fit image").
> > > >
> > > > According to the IMX OPTEE documentation [2] the size and location of
> > > > OPTEE is hard coded (CFG_TZDRAM_START and CFG_TZDRAM_SIZE) but looking
> > > > at the imx-optee source [3] this is calculated based off of
> > > > CFG_DDR_SIZE (which you can provide via env at build time or just
> > > > provide CFG_TZDRAM_START and CFG_TZDRAM_SIZE via env directly).
> > >
> > > optee does not support PIE, it could only run at the address that built
> > > time defined.
> >
> > Hi Peng,
> >
> > I wasn't thinking about PIE but just building it at a location other
> > than the top of DRAM in order to come up with a generalized location
> > instead of having to customize u-boot.dtsi for different RAM sizes and
> > to workaround the 4GiB boundary issue.
> >
> > If my understanding is correct optee's load address needs to match between:
> > 1. atf: BL32_BASE at build time defines the address in secure memory
> > where BL2 loads the BL32 binary image (tee.bin) (must be aligned on a
> > page-size boundary)
> > 2. optee: CFG_TZDRAM_START at build time (calculated based off of
> > CFG_DDR_SIZE) defines the address it is built to run at. Note you must
> > still define CFG_DDR_SIZE properly as this is passed to
> > imx_tzc_auto_configure()
> > 3. uboot: tee.bin is contained in u-boot.itb FIT image and specifies
> > the address that U-Boot SPL loads tee.bin into
> >
> > I'm really trying to understand the imx8m 4GiB limit issue as that
> > seems to be a huge limiation.
>
> Peng,
>
> I've made good progress and now have a 4GiB imx8mm board working with
> optee (with 1 hack):
>
> >
> > On an imx8mm board with 4GiB of DRAM configured with
> > atf:BL32_BASE=0x13e00
> > optee:CFG_DDR_SIZE=0x1,CFG_TZDRAM_START=0x13e00 and
> > u-boot.dtsi tee.bin load/entry=<0x1 0x3e00> we get this:
> >
> > U-Boot SPL 2023.04-00027-g578c653cbafa (Jun 16 2023 - 09:22:40 -0700)
> > GSCv3   : v58 0xf098 RST:VIN Thermal protection:disabled
> > RTC : 1970-01-01   0:05:40 UTC
> > Model   : GW7201-01-EB
> > Serial  : 852455
> > MFGDate : 11-10-2020
> > PMIC: MP5416 (IMX8MM)
> > DRAM: LPDDR4 4 GiB 3000MT/s 1500MHz
> > WDT:   Started watchdog@3028 with servicing every 1000ms (60s timeout)
> > Trying to boot from eMMC
> > DTB : imx8mm-venice-gw72xx-0x
> > Cannot use 64 bit addresses with SDMA
> > ^^^ This is the imx mmc driver warning that it can't load data into
> > dram across 32bit boundary
> >
> > Authenticate image from DDR location 0x401fcdc0...
> > NOTICE:  Do not release JR0 to NS as it can be used by HAB
> > ERROR:   mmap_add_region_check() failed. error -34
> > ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:793
> > BACKTRACE: START: assert
> > 0: EL3: 0x9289cc
> > 1: EL3: 0x929efc
> > 2: EL3: 0x92469c
> > 3: EL3: 0x9248f4
> > 4: EL3: 0x928850
> > 5: EL3: 0x927594
> > 6: EL3: 0x920128
> > 7: EL3: 0x7eb19c
> > 8: EL3: 0x7f3de0
> > BACKTRACE: END: assert
> >
> > This is where the atf jumps to optee so I can understand why the above
> > doesn't work as U-Boot can't load tee.bin from the FIT to 0x13e00
> > (not sure where it gets loaded... the 64bit address probably wraps).
> > I've also tried setting CFG_CORE_LARGE_PHYS_ADDR=y and
> > CFG_CORE_ARM64_PA_BITS=36 in optee as this is what the imx8mp-evk
> > config with 6GiB does and it ended with the same result but I do
> > notice that doing this changes the link address
>
> The issue above appears to be a result of not setting
> CFG_CORE_LARGE_PHYS_ADDR=y and CFG_CORE_ARM64_PA_BITS=36 in optee when
> CFG_DDR_SIZE exceeds 3GiB.
>
> >
> > The imx8mp-evk has 6GiB of dram on it. Does NXP not have a solution
> > for secure boot on boards with >3GiB of dram?  Is there some support
> > in their downstream U-Boot that I'm maybe missing? Personally I can't
> > even get NXP's lf_v2022.04 u-boot branch to build flash.bin for
> > imx8mp_evk so I can try it out.
>
>

Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

2023-06-20 Thread Sam Edwards


Hi Andre,

On 6/20/23 06:42, Andre Przywara wrote:

So yeah, the request of a "Enter FEL" command came up multiple times, but
so far no one could be bothered to implement this properly. The idea would
be to have a generic command (more like "fel-reset" than efex), and
allow each SoC (family) to implement this differently, as every
SoC requires something a bit different here (32-bit vs. 64-bit, having an
RTC vs not, etc).

If you could post your solution somewhere, we could start this effort.
There was some patch for the H3 already, and it's relatively
straight-forward on the newer SoCs (H616, IIRC), so if at least two
popular, but different SoCs would be supported, we could make sure to have
the right abstractions in place.


I already have a "go_to_fel()" that does the right thing to enter FEL 
from the SPL; I would pretty much just need to introduce the following 
per-SoC(-family) functions:

- bool sunxi_fel_flag_test(void)
- void sunxi_fel_flag_clear(void)
- void sunxi_fel_flag_set(void)

The "fel-reset" command (which is easier to type than what I have, "run 
fel_do_enter") would then call sunxi_fel_flag_set() and initiate a 
reset, and the SPL's early init just has to do sunxi_fel_flag_test() -> 
sunxi_fel_flag_clear() -> go_to_fel(). Seems easy enough.


Could you recommend to me a sufficiently different chip to test my 
abstractions against? Something ARMv8 and *without* RTC? I can then send 
in a series adding FEL support for that. (Also, did that H3 patch 
actually land? I didn't see anything but want to know if I should be 
refactoring my approach to extend what that H3 patch does or not.)



Ah, depending on the BSP kernel is indeed quite bad. I wonder what
features of the kernel you rely on that upstream does not have? Or is it
more about the BMC userland parts that are married to the Allwinner kernel
and its own interfaces?


I don't fully know; getting the kernel back on mainline is, as I said, a 
push for another day. I'm very much making a point of not looking into 
it before the bootloader can be upgraded to something that isn't a 
crashy, hard-to-update, failure-prone mess. (I'm working in "biggest 
fire, first out" order.)


That said, the first such dependent feature that leaps to mind is the 
AWNAND driver's CONFIG_AW_SPINAND_SIMULATE_MULTIPLANE, which logically 
interleaves pages of the NAND in a different ordering vs. what the 
physical NAND (and mainline's spi-nand driver) does. Alas this is a 
feature we're dependent on not because it provides benefits to our users 
(it does not, and in downstream discussions I've been soapboxing about 
how it's likely wearing down people's NANDs) but because the boards are 
flashed at the factory with this flag enabled so we need it set for the 
NAND to be accessible. We've experimented with reflashing the board with 
that flag disabled, but that has so far only resulted in corrupted flash.


Hope is not lost, though, for I have a half-written tool which shows 
some promise in being able to "unscramble the egg" and migrate existing 
NANDs over to the correct layout. That should be sufficient to get 
mainline U-Boot (and Tina Linux with the flag disabled) working, but I 
have no idea about mainline Linux still: this would only peel back one 
layer of the onion, and I don't know whether the next obstacle will be 
easier, harder, or about the same difficulty.


But it does mean that, for now, we're stuck with Tina Linux.


Final DT is a noble goal, but in reality there will always be room for
improvement and additions. So what we typically do is to start with a
simple .dts for the kernel tree, describing the basic peripherals, and
everything that already works and is not subject to debate. If in doubt,
include a node, and we will comment. Could you prepare such a patch?


The peripheral-describing .dts that I have is for Tina Linux, and uses 
incompatible compatibles (ha), includes, dt-bindings, temporary hacks 
while better driver support can be developed, and would otherwise not 
fly upstream. I can send it in *anyway* if for some reason you think 
that's a good idea, but I really don't see that as being anything other 
than a waste of time.


As well, I can't write a fresh .dts for mainline (one more likely to be 
accepted on the list). A mainline kernel has never been booted on this 
board, so I would do no better at this than a kernel contributor 
selected at random. The best I can do now is write something that 
*looks* like the correct .dts.


As I keep saying, that may change in the future. But the answer today is 
still "no, I cannot."



This
should not contradict any DT nodes that U-Boot uses, so it's not a double
effort.


True, in theory it *shouldn't* but in practice, I've found it does.

One way I've been bitten is that the sunxi SPI driver in U-Boot doesn't 
support Quad-SPI, so if the DT says the SPI-NAND is connected with a bus 
width of 4, the SPI-NAND driver requests Quad-SPI transfers, but the SPI 
master driver has no idea

Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread Marek Vasut


On 6/20/23 15:52, teik.heng.ch...@intel.com wrote:

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields
as if they were mere RW. This leads to unintended clearing of such fields

Signed-off-by: Teik Heng Chong 

---

V1->V2
- update subject tags to usb:dwc2
---
  drivers/usb/host/dwc2.c | 34 --
  drivers/usb/host/dwc2.h |  4 
  2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev,
  
  	/* Turn on the vbus power. */

if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(>hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(>hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, >hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(>hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
  
  		case USB_PORT_FEAT_RESET:

-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | 
DWC2_HPRT0_PRTRST);
break;
  
  		case USB_PORT_FEAT_POWER:

-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
break;
  
  		case USB_PORT_FEAT_ENABLE:

@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
  
-	clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |

-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
  
  	for (i = 0; i < MAX_DEVICE; i++) {

for (j = 0; j < MAX_ENDPOINT; j++) {
@@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
  static void dwc2_uninit_common(struct dwc2_core_regs *regs)
  {
/* Put everything in reset. */
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
  }
  
  #if !CONFIG_IS_ENABLED(DM_USB)

diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -543,6 +543,10 @@ struct dwc2_core_regs {
  #define DWC2_HPRT0_PRTSPD_LOW (2 << 17)
  #define DWC2_HPRT0_PRTSPD_MASK(0x3 << 17)
  #define DWC2_HPRT0_PRTSPD_OFFSET  17
+#define DWC2_HPRT0_W1C_MASK(DWC2_HPRT0_PRTCONNDET 
| \
+   DWC2_HPRT0_PRTENA | \
+   DWC2_HPRT0_PRTENCHNG | \
+

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Tom Rini

On Tue, Jun 20, 2023 at 08:36:11AM +0200, Michal Simek wrote:
> 
> 
> On 6/19/23 19:04, Eugen Hristev wrote:
> > On 6/19/23 19:07, Marek Vasut wrote:
> > > On 6/19/23 15:26, Eugen Hristev wrote:
> > > > On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:
> > > > > [ Felipe: Ported from Linux kernel commit
> > > > >   f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
> > > > > 
> > > > > According to Synopsys Databook, we shouldn't be relying on
> > > > > GCTL.CORESOFTRESET bit as that's only for debugging purposes.
> > > > > Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
> > > > > 
> > > > > Host side block will be reset by XHCI driver if necessary. Note that 
> > > > > this
> > > > > reduces amount of time spent on dwc3_probe() by a long margin.
> > > > > 
> > > > > We're still gonna wait for reset to finish for a long time
> > > > > (default to 1ms max), but tests show that the reset polling loop 
> > > > > executed
> > > > > at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
> > > > > times in a row).
> > > > > 
> > > > > Without proper core reset, observing random issues like when the
> > > > > USB(DWC3) is in device mode, the host device is not able to detect the
> > > > > USB device.
> > > > > 
> > > > > Signed-off-by: Venkatesh Yadav Abbarapu 
> > > > > ---
> > > > >   drivers/usb/dwc3/core.c | 50 
> > > > > +++--
> > > > >   1 file changed, 18 insertions(+), 32 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > > > index 49f6a1900b..8702a54efa 100644
> > > > > --- a/drivers/usb/dwc3/core.c
> > > > > +++ b/drivers/usb/dwc3/core.c
> > > > > @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 
> > > > > mode)
> > > > >   static int dwc3_core_soft_reset(struct dwc3 *dwc)
> > > > >   {
> > > > >   u32    reg;
> > > > > +    int    retries = 1000;
> > > > > -    /* Before Resetting PHY, put Core in Reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > > > > -    reg |= DWC3_GCTL_CORESOFTRESET;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > > > > -
> > > > > -    /* Assert USB3 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> > > > > -    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> > > > > -
> > > > > -    /* Assert USB2 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> > > > > -    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> > > > > -
> > > > > -    mdelay(100);
> > > > > -
> > > > > -    /* Clear USB3 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> > > > > -    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> > > > > -
> > > > > -    /* Clear USB2 PHY reset */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> > > > > -    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> > > > > +    /*
> > > > > + * We're resetting only the device side because, if we're in 
> > > > > host mode,
> > > > > + * XHCI driver will reset the host block. If dwc3 was configured 
> > > > > for
> > > > > + * host-only mode, then we can return early.
> > > > > + */
> > > > > +    if (dwc->dr_mode == USB_DR_MODE_HOST)
> > > > > +    return 0;
> > > > > -    mdelay(100);
> > > > > +    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> > > > > +    reg |= DWC3_DCTL_CSFTRST;
> > > > > +    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
> > > > > -    /* After PHYs are stable we can take Core out of reset state */
> > > > > -    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> > > > > -    reg &= ~DWC3_GCTL_CORESOFTRESET;
> > > > > -    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > > > > +    do {
> > > > > +    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> > > > > +    if (!(reg & DWC3_DCTL_CSFTRST))
> > > > > +    return 0;
> > > > > +    udelay(1);
> > > > > +    } while (--retries);
> > > > > -    return 0;
> > > > > +    return -ETIMEDOUT;
> > > > >   }
> > > > >   /*
> > > > 
> > > > Hello Venkatesh, Michal,
> > > > 
> > > > I randomly found this patch while testing the Dwc3 on rockchip
> > > > RK3588 , I noticed that you removed the code that resets the
> > > > PHYs in this patch hence DWC3 is no longer starting in my case.
> > > > Was this intentional with this patch ?
> > > 
> > > All of these patches are NAK until the DWC3 is synchronized with
> > > Linux. Picking random DWC3 patches and ignoring other fixes will
> > > turn the whole driver into an unmaintainable mess and make the sync
> > > that much harder in the future. I spent enormous amount of my spare
> > > time trying to explain to Xilinx how to do that mostly
> > > automatically, but that was all ignored or countered with reason
> > >

Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION

2023-06-20 Thread Detlev Casanova

On Tuesday, June 20, 2023 4:03:18 P.M. EDT Marek Vasut wrote:
> On 6/20/23 19:49, Detlev Casanova wrote:
> > On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote:
> >> On 6/19/23 20:27, Detlev Casanova wrote:
> >>> On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote:
>  On 6/19/23 16:42, Detlev Casanova wrote:
> > On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote:
> >> On 6/16/23 17:21, Detlev Casanova wrote:
> >>> Expose that information to the command shell to let scripts select
> >>> the
> >>> correct devicetree name.
> >>> 
> >>> Signed-off-by: Detlev Casanova 
> >>> ---
> >>> 
> >>>  drivers/sysinfo/rcar3.c | 46
> >>>  -
> >>>  1 file changed, 36 insertions(+), 10 deletions(-)
> >>> 
> >>> diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
> >>> index 7b127986da7..89ad46c5422 100644
> >>> --- a/drivers/sysinfo/rcar3.c
> >>> +++ b/drivers/sysinfo/rcar3.c
> >>> @@ -32,6 +32,8 @@
> >>> 
> >>>   */
> >>>  
> >>>  struct sysinfo_rcar_priv {
> >>>  
> >>>   charboardmodel[64];
> >>> 
> >>> + u8  id;
> >>> + charrevision[4];
> >>> 
> >>>   u8  val;
> >>>  
> >>>  };
> >>> 
> >>> @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice
> >>> *dev,
> >>> int id, size_t size, char *>
> >>> 
> >>>   switch (id) {
> >>> 
> >>>   case SYSINFO_ID_BOARD_MODEL:
> >>> - strncpy(val, priv->boardmodel, size);
> >>> - val[size - 1] = '\0';
> >>> + strlcpy(val, priv->boardmodel, size);
> >>> + break;
> >>> + case SYSINFO_ID_BOARD_REVISION:
> >>> + strlcpy(val, priv->revision, size);
> >>> + break;
> >>> + default:
> >>> + return -EINVAL;
> >>> + };
> >>> +
> >>> + val[size - 1] = '\0';
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int
> >>> *val)
> >>> +{
> >>> + struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
> >>> +
> >>> + switch (id) {
> >>> + case SYSINFO_ID_BOARD_ID:
> >>> + *val = priv->id;
> >>> 
> >>>   return 0;
> >> 
> >> Why not return SYSINFO_ID_BOARD_REVISION as integer here ?
> > 
> > Because the revision (on r-car3 boards at least) is in the format X.Y.
> > It
> > could be returned as "(X << 8) | Y" or split in major/minor. But
> > different
> > boards will use different revisions and I think that having a str is
> > easier to deal with in a shell script.
>  
>  With rcar they are numbers, so lets go with major/minor integers
>  please.
> >>> 
> >>> Ok for this part, but shouldn't the sysinfo command use a common
> >>> interface
> >>> for all boards ? Or should it also have rev_major/rev_minor arguments ?
> >> 
> >> I would expect other boards to either report rev_major/rev_minor if
> >> implemented, or errno if those boards don't implement this property.
> > 
> > Another thing on rcar is that the revision is stored as 2 char values.
> > Would you oppose a change form using a char (e.g. rev_major = '1') to
> > using u8 values (e.g. rev_major = 1) instead ?
> 
> Shouldn't those rev fields just be integer(s) to cover the generic case?

On rcar, they are chars. I don't really see a reason for this except to show 
the '?.?' on unknown board ids. But that can be managed in other ways.

Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION

2023-06-20 Thread Marek Vasut


On 6/20/23 19:49, Detlev Casanova wrote:

On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote:

On 6/19/23 20:27, Detlev Casanova wrote:

On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote:

On 6/19/23 16:42, Detlev Casanova wrote:

On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote:

On 6/16/23 17:21, Detlev Casanova wrote:

Expose that information to the command shell to let scripts select the
correct devicetree name.

Signed-off-by: Detlev Casanova 
---

 drivers/sysinfo/rcar3.c | 46
 -
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
index 7b127986da7..89ad46c5422 100644
--- a/drivers/sysinfo/rcar3.c
+++ b/drivers/sysinfo/rcar3.c
@@ -32,6 +32,8 @@

  */
 
 struct sysinfo_rcar_priv {
 
 	char	boardmodel[64];


+   u8  id;
+   charrevision[4];

u8  val;
 
 };


@@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice
*dev,
int id, size_t size, char *>

switch (id) {

case SYSINFO_ID_BOARD_MODEL:
-   strncpy(val, priv->boardmodel, size);
-   val[size - 1] = '\0';
+   strlcpy(val, priv->boardmodel, size);
+   break;
+   case SYSINFO_ID_BOARD_REVISION:
+   strlcpy(val, priv->revision, size);
+   break;
+   default:
+   return -EINVAL;
+   };
+
+   val[size - 1] = '\0';
+   return 0;
+}
+
+static int sysinfo_rcar_get_int(struct udevice *dev, int id, int
*val)
+{
+   struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
+
+   switch (id) {
+   case SYSINFO_ID_BOARD_ID:
+   *val = priv->id;

return 0;


Why not return SYSINFO_ID_BOARD_REVISION as integer here ?


Because the revision (on r-car3 boards at least) is in the format X.Y.
It
could be returned as "(X << 8) | Y" or split in major/minor. But
different
boards will use different revisions and I think that having a str is
easier to deal with in a shell script.


With rcar they are numbers, so lets go with major/minor integers please.


Ok for this part, but shouldn't the sysinfo command use a common interface
for all boards ? Or should it also have rev_major/rev_minor arguments ?

I would expect other boards to either report rev_major/rev_minor if
implemented, or errno if those boards don't implement this property.


Another thing on rcar is that the revision is stored as 2 char values. Would
you oppose a change form using a char (e.g. rev_major = '1') to using u8
values (e.g. rev_major = 1) instead ?


Shouldn't those rev fields just be integer(s) to cover the generic case?

[PATCH] doc: statistics: Re-generate the last 3 releases

2023-06-20 Thread Tom Rini

With some changes to our mapping files in gitdm, re-generate the last
few releases worth of statistics to correctly reflect contributions. We
only go back this far to try and find a balance between highlighting
contributions and still being reviewable.

Signed-off-by: Tom Rini 
---
 .../statistics/u-boot-stats-v2022.10.rst  | 27 +-
 .../statistics/u-boot-stats-v2023.01.rst  | 52 ++-
 .../statistics/u-boot-stats-v2023.04.rst  | 27 +-
 3 files changed, 54 insertions(+), 52 deletions(-)

diff --git a/doc/develop/statistics/u-boot-stats-v2022.10.rst 
b/doc/develop/statistics/u-boot-stats-v2022.10.rst
index 6fb71d4753e8..7a5fc2edc7c2 100644
--- a/doc/develop/statistics/u-boot-stats-v2022.10.rst
+++ b/doc/develop/statistics/u-boot-stats-v2022.10.rst
@@ -607,20 +607,21 @@ Release Statistics for U-Boot v2022.10
  =
Name  Count
  =
-   (Unknown) 590 (38.8%)
+   (Unknown) 584 (38.4%)
Konsulko Group265 (17.4%)
Google, Inc.  141 (9.3%)
NXP   77 (5.1%)
+   AMD   70 (4.6%)
ST Microelectronics   67 (4.4%)
Linaro60 (3.9%)
Texas Instruments 56 (3.7%)
-   AMD   53 (3.5%)
DENX Software Engineering 45 (3.0%)
Toradex   45 (3.0%)
Weidmüller Interface GmbH & Co. KG41 (2.7%)
-   Xilinx29 (1.9%)
Amarula Solutions 18 (1.2%)
+   Xilinx12 (0.8%)
ARM   11 (0.7%)
+   Collabora Ltd.7 (0.5%)
BayLibre SAS  5 (0.3%)
SUSE  4 (0.3%)
Socionext Inc.3 (0.2%)
@@ -628,7 +629,6 @@ Release Statistics for U-Boot v2022.10
IBM   2 (0.1%)
Siemens   2 (0.1%)
Broadcom  1 (0.1%)
-   Collabora Ltd.1 (0.1%)
Debian.org1 (0.1%)
Marvell   1 (0.1%)
Samsung   1 (0.1%)
@@ -642,7 +642,7 @@ Release Statistics for U-Boot v2022.10
Name  Count
  =
Konsulko Group98915 (47.3%)
-   (Unknown) 36773 (17.6%)
+   (Unknown) 36630 (17.5%)
Toradex   20197 (9.7%)
NXP   11759 (5.6%)
Google, Inc.  8739 (4.2%)
@@ -651,12 +651,13 @@ Release Statistics for U-Boot v2022.10
Texas Instruments 5930 (2.8%)
ST Microelectronics   3803 (1.8%)
DENX Software Engineering 3551 (1.7%)
-   AMD   2343 (1.1%)
+   AMD   2591 (1.2%)
Amarula Solutions 1360 (0.7%)
-   Xilinx1016 (0.5%)
+   Xilinx768 (0.4%)
Broadcom  315 (0.2%)
ARM   298 (0.1%)
BayLibre SAS  197 (0.1%)
+   Collabora Ltd.144 (0.1%)
SUSE  79 (0.0%)
IBM   34 (0.0%)
Bootlin   32 (0.0%)
@@ -665,7 +666,6 @@ Release Statistics for U-Boot v2022.10
Debian.org4 (0.0%)
Marvell   3 (0.0%)
Samsung   2 (0.0%)
-   Collabora Ltd.1 (0.0%)
  =
 
 
@@ -677,13 +677,14 @@ Release Statistics for U-Boot v2022.10
  =
AMD   81 (30.5%)
NXP   51 (19.2%)
-   (Unknown) 33 (12.4%)
+   (Unknown) 28 (10.5%)
Texas Instruments 19 (7.1%)
Linaro16 (6.0%)
ARM   16 (6.0%)
Amarula Solutions 14 (5.3%)
Xilinx13 (4.9%)
Konsulko Group6 (2.3%)
+   Canonical 5 (1.9%)
Toradex   4 (1.5%)
Google, Inc.  4 (1.5%)
Socionext Inc.

Re: [PATCH] rockchip: Pinebook Pro: Fix emmc default configuration

2023-06-20 Thread Vagrant Cascadian

On 2023-05-01, Wolfgang Zarre wrote:
> If u-boot is installed on the internal emmc, then this will
> allow to boot without failure.
>
> Signed-off-by: Wolfgang Zarre 
> Reviewed-by: Kever Yang 

This is marked as accepted in patchwork, but I do not see it in git
yet...

Is this planned to land in 2023.07(-rc5?)?

Thanks!

live well,
  vagrant

>  configs/pinebook-pro-rk3399_defconfig | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/configs/pinebook-pro-rk3399_defconfig 
> b/configs/pinebook-pro-rk3399_defconfig
> index dff4695e37..58a8b91aa6 100644
> --- a/configs/pinebook-pro-rk3399_defconfig
> +++ b/configs/pinebook-pro-rk3399_defconfig
> @@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x0020
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
> +CONFIG_SF_DEFAULT_SPEED=2000
>  CONFIG_ENV_SIZE=0x8000
>  CONFIG_ENV_OFFSET=0x3F8000
>  CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro"
> @@ -18,6 +19,7 @@ CONFIG_DEBUG_UART_CLOCK=2400
>  CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI=y
>  CONFIG_SYS_LOAD_ADDR=0x800800
> +CONFIG_PCI=y
>  CONFIG_DEBUG_UART=y
>  CONFIG_BOOTDELAY=3
>  CONFIG_USE_PREBOOT=y
> @@ -57,17 +59,23 @@ CONFIG_LED=y
>  CONFIG_LED_GPIO=y
>  CONFIG_MISC=y
>  CONFIG_ROCKCHIP_EFUSE=y
> +CONFIG_MMC_IO_VOLTAGE=y
> +CONFIG_SPL_MMC_IO_VOLTAGE=y
> +CONFIG_MMC_UHS_SUPPORT=y
> +CONFIG_SPL_MMC_UHS_SUPPORT=y
> +CONFIG_MMC_HS400_ES_SUPPORT=y
> +CONFIG_SPL_MMC_HS400_ES_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
> +CONFIG_SPL_MMC_HS400_SUPPORT=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_ROCKCHIP=y
>  CONFIG_SF_DEFAULT_BUS=1
> -CONFIG_SF_DEFAULT_SPEED=2000
>  CONFIG_SPI_FLASH_GIGADEVICE=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_NVME_PCI=y
> -CONFIG_PCI=y
>  CONFIG_PHY_ROCKCHIP_INNO_USB2=y
>  CONFIG_PHY_ROCKCHIP_TYPEC=y
>  CONFIG_DM_PMIC_FAN53555=y


signature.asc
Description: PGP signature

[PATCH] mailbox: k3-sec-proxy: Fill non-message tx data fields with 0x0

2023-06-20 Thread Nishanth Menon

Sec proxy data buffer is 60 bytes with the last of the registers
indicating transmission completion. This however poses a bit of a
challenge.

The backing memory for sec_proxy is regular memory, and all sec proxy
does is to trigger a burst of all 60 bytes of data over to the target
thread backing ring accelerator. It doesn't do a memory scrub when
it moves data out in the burst. When we transmit multiple messages,
remnants of previous message is also transmitted which results in
some random data being set in TISCI fields of messages that have been
expanded forward.

The entire concept of backward compatibility hinges on the fact that
the unused message fields remain 0x0 allowing for 0x0 value to be
specially considered when backward compatibility of message extension
is done.

So, instead of just writing the completion register, we continue
to fill the message buffer up with 0x0 (note: for partial message
involving completion, we already do this).

This allows us to scale and introduce ABI changes back also work with
other boot stages that may have left data in the internal memory.

While at this, drop the unused accessor function.

Fixes: f9aa41023bd9 ("mailbox: Introduce K3 Secure Proxy Driver")
Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/k3-sec-proxy.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mailbox/k3-sec-proxy.c b/drivers/mailbox/k3-sec-proxy.c
index a862e55bc391..815808498f2e 100644
--- a/drivers/mailbox/k3-sec-proxy.c
+++ b/drivers/mailbox/k3-sec-proxy.c
@@ -94,11 +94,6 @@ static inline u32 sp_readl(void __iomem *addr, unsigned int 
offset)
return readl(addr + offset);
 }
 
-static inline void sp_writel(void __iomem *addr, unsigned int offset, u32 data)
-{
-   writel(data, addr + offset);
-}
-
 /**
  * k3_sec_proxy_of_xlate() - Translation of phandle to channel
  * @chan:  Mailbox channel
@@ -241,15 +236,20 @@ static int k3_sec_proxy_send(struct mbox_chan *chan, 
const void *data)
/* Ensure all unused data is 0 */
data_trail &= 0x >> (8 * (sizeof(u32) - trail_bytes));
writel(data_trail, data_reg);
-   data_reg++;
+   data_reg += sizeof(u32);
}
 
/*
 * 'data_reg' indicates next register to write. If we did not already
 * write on tx complete reg(last reg), we must do so for transmit
+* In addition, we also need to make sure all intermediate data
+* registers(if any required), are reset to 0 for TISCI backward
+* compatibility to be maintained.
 */
-   if (data_reg <= (spt->data + spm->desc->data_end_offset))
-   sp_writel(spt->data, spm->desc->data_end_offset, 0);
+   while (data_reg <= (spt->data + spm->desc->data_end_offset)) {
+   writel(0x0, data_reg);
+   data_reg += sizeof(u32);
+   }
 
debug("%s: Message successfully sent on thread %ld\n",
  __func__, chan->id);
-- 
2.40.0

Re: [PATCH] usb: eth: lan78xx: Fix logic in lan78xx_read_otp() to avoid a warning

2023-06-20 Thread Tom Rini

On Thu, 04 Jun 2020 16:35:15 -0400, Tom Rini wrote:

> In lan78xx_read_otp() we want to know if sig is LAN78XX_OTP_INDICATOR_1
> or LAN78XX_OTP_INDICATOR_2.  In the case of matching the first one we
> set offset to itself, and clang warns about this.  Rework the logic so
> that if sig is the second indicator we adjust the offset as today and if
> it does not match the first indicator we return -EINVAL
> 
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH] spl: spl-nor: return error if no valid image was loaded

2023-06-20 Thread Tom Rini

On Mon, 30 Jan 2023 10:21:43 +0100, Mario Kicherer wrote:

> If only FIT images are enabled and loading the FIT image fails,
> spl_nor_load_image() should return an error instead of zero.
> 
> Without this patch:
> 
> >>SPL: board_init_r()
> spl_init
> Trying to boot from NOR
> Unsupported OS image.. Jumping nevertheless..
> image entry point: 0x0
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION

2023-06-20 Thread Detlev Casanova

On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote:
> On 6/19/23 20:27, Detlev Casanova wrote:
> > On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote:
> >> On 6/19/23 16:42, Detlev Casanova wrote:
> >>> On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote:
>  On 6/16/23 17:21, Detlev Casanova wrote:
> > Expose that information to the command shell to let scripts select the
> > correct devicetree name.
> > 
> > Signed-off-by: Detlev Casanova 
> > ---
> > 
> > drivers/sysinfo/rcar3.c | 46
> > -
> > 1 file changed, 36 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
> > index 7b127986da7..89ad46c5422 100644
> > --- a/drivers/sysinfo/rcar3.c
> > +++ b/drivers/sysinfo/rcar3.c
> > @@ -32,6 +32,8 @@
> > 
> >  */
> > 
> > struct sysinfo_rcar_priv {
> > 
> > charboardmodel[64];
> > 
> > +   u8  id;
> > +   charrevision[4];
> > 
> > u8  val;
> > 
> > };
> > 
> > @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice
> > *dev,
> > int id, size_t size, char *>
> > 
> > switch (id) {
> > 
> > case SYSINFO_ID_BOARD_MODEL:
> > -   strncpy(val, priv->boardmodel, size);
> > -   val[size - 1] = '\0';
> > +   strlcpy(val, priv->boardmodel, size);
> > +   break;
> > +   case SYSINFO_ID_BOARD_REVISION:
> > +   strlcpy(val, priv->revision, size);
> > +   break;
> > +   default:
> > +   return -EINVAL;
> > +   };
> > +
> > +   val[size - 1] = '\0';
> > +   return 0;
> > +}
> > +
> > +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int
> > *val)
> > +{
> > +   struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
> > +
> > +   switch (id) {
> > +   case SYSINFO_ID_BOARD_ID:
> > +   *val = priv->id;
> > 
> > return 0;
>  
>  Why not return SYSINFO_ID_BOARD_REVISION as integer here ?
> >>> 
> >>> Because the revision (on r-car3 boards at least) is in the format X.Y.
> >>> It
> >>> could be returned as "(X << 8) | Y" or split in major/minor. But
> >>> different
> >>> boards will use different revisions and I think that having a str is
> >>> easier to deal with in a shell script.
> >> 
> >> With rcar they are numbers, so lets go with major/minor integers please.
> > 
> > Ok for this part, but shouldn't the sysinfo command use a common interface
> > for all boards ? Or should it also have rev_major/rev_minor arguments ?
> I would expect other boards to either report rev_major/rev_minor if
> implemented, or errno if those boards don't implement this property.

Another thing on rcar is that the revision is stored as 2 char values. Would 
you oppose a change form using a char (e.g. rev_major = '1') to using u8 
values (e.g. rev_major = 1) instead ?

Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Simon Glass

Hi Jan,

On Tue, 20 Jun 2023 at 18:05, Jan Kiszka  wrote:
>
> On 20.06.23 16:36, Simon Glass wrote:
> > Hi Jan,
> >
> > On Tue, 20 Jun 2023 at 11:37, Jan Kiszka  wrote:
> >>
> >> On 20.06.23 12:11, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
> 
>  On 19.06.23 16:09, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
> >>
> >> On 19.06.23 14:36, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  
> >>> wrote:
> 
>  On 15.06.23 13:46, Jan Kiszka wrote:
> > On 15.06.23 13:38, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 15.06.23 13:19, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 12:09, Jan Kiszka 
>   wrote:
> >
> > On 15.06.23 12:55, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka 
> >>  wrote:
> >>>
> >>> On 12.06.23 23:17, Simon Glass wrote:
>  Hi Jan,
> 
>  On Mon, 5 Jun 2023 at 15:39, Jan Kiszka 
>   wrote:
> >
> > From: Jan Kiszka 
> >
> > Introduce BINMAN_EXTRA_ARGS that can be set per board, 
> > e.g., to inject
> > specific settings. Will be used by IOT2050 first to define 
> > multiple
> > of-lists.
> >
> > Signed-off-by: Jan Kiszka 
> > ---
> > CC: Simon Glass 
> > ---
> >  Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> 
>  I'm really not keen on this, since it means that the 
>  Makefile (or some
>  vars it sets) are again involved in controlling the image 
>  generation.
>  It should really all be in the binman image description / 
>  .dtsi file
> >>>
> >>> binman does not allow me to unrole of-list inside the dts 
> >>> file, does it?
> >>> With such a feature, I wouldn't need any custom -a of-list-X 
> >>> switches
> >>> and, thus, no such EXTRA_ARGS.
> >>
> >> Can you explain a bit more about what you mean by 'unrole'? It 
> >> is just
> >> software, so anything should be possible.
> >
> > To use a DT sequence, I need to specify fit,ftd-list. But I can 
> > say
> >
> > fit,ftd-list = "first.dtb second.dtb"
> >
> > I rather need to go via the EntryArg indirection of the binman 
> > command line.
> 
>  Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are 
>  you
>  wanting to filter that list based on something else?
> 
>  I'm afraid I am really not following this at all.
> >>>
> >>> CONFIG_OF_LIST is not working here as we have two different 
> >>> boards with
> >>> two different lists.
> >>
> >> But we only build one board at a time, don't we?
> >
> > No, this is about building two flash images for two different board
> > generations in the same binman run (see patch 3).
> >
> >>
> >> We could provide a way to select between different lists, but how 
> >> does
> >> Makefile get access to them?
> >
> > See patch 3: known lists, now put into board config.mk.
> >
> 
>  Any better suggestions for this issue? Otherwise, I will have to keep
>  binman args extension for now.
> >>>
> >>> I've dug into this a bit. The use of #defines and macros looks to be
> >>> unnecessary, unless I am missing something.
> >>>
> >>> You can do things like this:
> >>>
> >>> fit_node: fit {
> >>> // base definition of FIT
> >>> };
> >>>
> >>> the later on:
> >>>
> >>> fit_node: {
> >>> #ifdef xxx
> >>>// override a few things
> >>>fit,fdt-list = ...
> >>> #else
> >>>
> >>> #endif
> >>
> >> As I wrote already, I have a solution for that by using a template 
> >> dtsi.
> >>
> >>>
> >>> There is no need to specify the properties all at once. You can update
> >>> a property later on just by referring to its node as above.
> >>
> >> Does not help when the anchor name needs to vary as well. That's where 
> >> I
> >> will use a #define

Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Jan Kiszka

On 20.06.23 16:36, Simon Glass wrote:
> Hi Jan,
> 
> On Tue, 20 Jun 2023 at 11:37, Jan Kiszka  wrote:
>>
>> On 20.06.23 12:11, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:

 On 19.06.23 16:09, Simon Glass wrote:
> Hi Jan,
>
> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
>>
>> On 19.06.23 14:36, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:

 On 15.06.23 13:46, Jan Kiszka wrote:
> On 15.06.23 13:38, Simon Glass wrote:
>> Hi Jan,
>>
>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
>> wrote:
>>>
>>> On 15.06.23 13:19, Simon Glass wrote:
 Hi Jan,

 On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
 wrote:
>
> On 15.06.23 12:55, Simon Glass wrote:
>> Hi Jan,
>>
>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka 
>>  wrote:
>>>
>>> On 12.06.23 23:17, Simon Glass wrote:
 Hi Jan,

 On Mon, 5 Jun 2023 at 15:39, Jan Kiszka 
  wrote:
>
> From: Jan Kiszka 
>
> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., 
> to inject
> specific settings. Will be used by IOT2050 first to define 
> multiple
> of-lists.
>
> Signed-off-by: Jan Kiszka 
> ---
> CC: Simon Glass 
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)

 I'm really not keen on this, since it means that the Makefile 
 (or some
 vars it sets) are again involved in controlling the image 
 generation.
 It should really all be in the binman image description / 
 .dtsi file
>>>
>>> binman does not allow me to unrole of-list inside the dts file, 
>>> does it?
>>> With such a feature, I wouldn't need any custom -a of-list-X 
>>> switches
>>> and, thus, no such EXTRA_ARGS.
>>
>> Can you explain a bit more about what you mean by 'unrole'? It 
>> is just
>> software, so anything should be possible.
>
> To use a DT sequence, I need to specify fit,ftd-list. But I can 
> say
>
> fit,ftd-list = "first.dtb second.dtb"
>
> I rather need to go via the EntryArg indirection of the binman 
> command line.

 Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are 
 you
 wanting to filter that list based on something else?

 I'm afraid I am really not following this at all.
>>>
>>> CONFIG_OF_LIST is not working here as we have two different boards 
>>> with
>>> two different lists.
>>
>> But we only build one board at a time, don't we?
>
> No, this is about building two flash images for two different board
> generations in the same binman run (see patch 3).
>
>>
>> We could provide a way to select between different lists, but how 
>> does
>> Makefile get access to them?
>
> See patch 3: known lists, now put into board config.mk.
>

 Any better suggestions for this issue? Otherwise, I will have to keep
 binman args extension for now.
>>>
>>> I've dug into this a bit. The use of #defines and macros looks to be
>>> unnecessary, unless I am missing something.
>>>
>>> You can do things like this:
>>>
>>> fit_node: fit {
>>> // base definition of FIT
>>> };
>>>
>>> the later on:
>>>
>>> fit_node: {
>>> #ifdef xxx
>>>// override a few things
>>>fit,fdt-list = ...
>>> #else
>>>
>>> #endif
>>
>> As I wrote already, I have a solution for that by using a template dtsi.
>>
>>>
>>> There is no need to specify the properties all at once. You can update
>>> a property later on just by referring to its node as above.
>>
>> Does not help when the anchor name needs to vary as well. That's where I
>> will use a #define to customize the template on include.
>>
>>>
>>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
>>> and all the #define stuff.
>>
>> You still didn't address my question. Should I share my version to make
>> the problem clearer? But I thought I explained this in various shades
>> already.
>
> Yes, if I

Re: [PATCH 3/3] arm: dts: imx8mn: protect the firmware/optee node with ifdef

2023-06-20 Thread Fabio Estevam

On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey  wrote:
>
> There is no need to include the firmware/optee node if the optee
> driver is not enabled.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam

Re: [PATCH 2/3] arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi

2023-06-20 Thread Fabio Estevam

On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey  wrote:
>
> Move the firmware/optee node to the common imx8mp-u-boot.dtsi and
> protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
> without the optee driver enabled.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam

Re: [PATCH 1/3] arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi

2023-06-20 Thread Fabio Estevam

On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey  wrote:
>
> Move the firmware/optee node to the common imx8mm-u-boot.dtsi and
> protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
> without the optee driver enabled.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam

[PATCH 3/3] arm: dts: imx8mn: protect the firmware/optee node with ifdef

2023-06-20 Thread Tim Harvey

There is no need to include the firmware/optee node if the optee
driver is not enabled.

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mn-u-boot.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index cef20dab4688..8191b973b464 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -8,12 +8,14 @@
multiple-images;
};
 
+#ifdef CONFIG_OPTEE
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
+#endif
 
wdt-reboot {
compatible = "wdt-reboot";
-- 
2.25.1

[PATCH 2/3] arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi

2023-06-20 Thread Tim Harvey

Move the firmware/optee node to the common imx8mp-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 6 --
 arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi | 7 ---
 arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mp-u-boot.dtsi  | 9 +
 arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi| 7 ---
 arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi  | 7 ---
 7 files changed, 9 insertions(+), 41 deletions(-)

diff --git a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi 
b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
index 5ca631e9d8c4..bb0f9bd0c8d3 100644
--- a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
@@ -11,13 +11,6 @@
wdt = <>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 &{/soc@0/bus@3080/i2c@30a2/pmic@25} {
diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi 
b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
index 6784ed2e7c92..17965c58ba10 100644
--- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
@@ -11,12 +11,6 @@
wdt = <>;
bootph-pre-ram;
};
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 _usdhc2_vmmc {
diff --git a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi 
b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
index d411cf79e85d..fe20938af536 100644
--- a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
@@ -12,13 +12,6 @@
wdt = <>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
 _usdhc2_vmmc {
diff --git a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi 
b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
index f3fb44046d5c..8f1df232b1b7 100644
--- a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
@@ -12,13 +12,6 @@
wdt = <>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
  {
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
index 18d1728e1d2a..e8fe92485cd1 100644
--- a/arch/arm/dts/imx8mp-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-u-boot.dtsi
@@ -8,6 +8,15 @@
binman: binman {
multiple-images;
};
+
+#ifdef CONFIG_OPTEE
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+#endif
 };
 
  {
diff --git a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
index c3fb040080b6..44ac315a1241 100644
--- a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mp-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
diff --git a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi 
b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
index 9c6c417f7eea..a985645ff8c3 100644
--- a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mp-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
-- 
2.25.1

[PATCH 1/3] arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi

2023-06-20 Thread Tim Harvey

Move the firmware/optee node to the common imx8mm-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 7 ---
 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mm-evk-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi | 7 ---
 arch/arm/dts/imx8mm-phg-u-boot.dtsi   | 7 ---
 arch/arm/dts/imx8mm-u-boot.dtsi   | 9 +
 arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi   | 7 ---
 7 files changed, 9 insertions(+), 42 deletions(-)

diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi 
b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
index 484e31824b85..d12ce6069cc7 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mm-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi 
b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
index 1878c4e13fbe..219504f61105 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mm-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi 
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index 13688ec0d0f2..155670da18d1 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -11,13 +11,6 @@
wdt = <>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
  {
diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
index 65dfd33725ee..1ad9d49a1118 100644
--- a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
@@ -16,13 +16,6 @@
wdt = <>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
  {
diff --git a/arch/arm/dts/imx8mm-phg-u-boot.dtsi 
b/arch/arm/dts/imx8mm-phg-u-boot.dtsi
index 3ced97cfaafa..c9e0b4420500 100644
--- a/arch/arm/dts/imx8mm-phg-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-phg-u-boot.dtsi
@@ -11,13 +11,6 @@
wdt = <>;
bootph-pre-ram;
};
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
 };
 
  {
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 7fd5a05fad3c..c48b5f2ef026 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -7,6 +7,15 @@
binman: binman {
multiple-images;
};
+
+#ifdef CONFIG_OPTEE
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+#endif
 };
 
  {
diff --git a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi 
b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
index 494229e4e62a..f2c7bd919970 100644
--- a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
@@ -6,13 +6,6 @@
 #include "imx8mm-u-boot.dtsi"
 
 / {
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-
wdt-reboot {
compatible = "wdt-reboot";
bootph-pre-ram;
-- 
2.25.1

Re: [PATCH] spl: spl_nor: use panic instead of hang if booting fails

2023-06-20 Thread Tom Rini

On Mon, Jan 30, 2023 at 11:03:03AM +0100, Mario Kicherer wrote:

> On systems without a watchdog, using hang() prevents a system to
> recover from an error. For example, a board could implement a boot
> counter to switch to an alternative load address after some failed
> tries.
> 
> Signed-off-by: Mario Kicherer 
> ---
>  common/spl/spl.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 2855cdd117..d1aa2fb8a9 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -822,11 +822,10 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>   if (ret) {
>   if (CONFIG_IS_ENABLED(SHOW_ERRORS) &&
>   CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT))
> - printf(SPL_TPL_PROMPT "failed to boot from all boot 
> devices (err=%d)\n",
> -ret);
> + panic(SPL_TPL_PROMPT "failed to boot from all boot 
> devices (err=%d)\n",
> +   ret);
>   else
> - puts(SPL_TPL_PROMPT "failed to boot from all boot 
> devices\n");
> - hang();
> + panic_str(SPL_TPL_PROMPT "failed to boot from all boot 
> devices\n");
>   }
>  
>   spl_perform_fixups(_image);

Not all platforms that use SPI in SPL have panic() (and related
functions) available, so this introduces a number of fail to builds.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Add Renesas patch attribution domain mapping

2023-06-20 Thread Tom Rini

On Tue, Jun 20, 2023 at 01:49:43PM +0200, Marek Vasut wrote:

> Add domain mapping for the +renesas mail, so that the patches get
> attributed to to Renesas Electronics correctly.
> 
> Signed-off-by: Marek Vasut 

Applied to gitdm/u-boot, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Rockchip DWC2 issue

2023-06-20 Thread Jagan Teki

Hi,

Has anyone tried to use dwc2 and echi port together with USB disk?
look like this is not working with this combination on any Rockchip
SoC's

Here are the issues that I've reproduced in RK3328 where the disk
connected in EHCI port is detecting but DWC2 is not. Any clue?

=> usb start
starting USB...
Bus usb@ff5c: USB EHCI 1.00
Bus usb@ff5d: USB OHCI 1.0
Bus usb@ff60: generic_phy_get_bulk : no phys property
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@ff58: USB DWC2
scanning bus usb@ff5c for devices... 2 USB Device(s) found
scanning bus usb@ff5d for devices... 1 USB Device(s) found
scanning bus usb@ff60 for devices... 1 USB Device(s) found
scanning bus usb@ff58 for devices... Adding disk for
usb_mass_storage.lun0 failed
(err=-9223372036854775788/0x8014)
device 'usb_mass_storage.lun0' failed to unbind
1 USB Device(s) found
device 'usb_mass_storage.lun0' failed to unbind
   scanning usb for storage devices... 2 Storage Device(s) found
=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
   Generic Teclast CoolFlash 4163831324317134

  1  Hub (12 Mb/s, 0mA)
  U-Boot Root Hub

  1  Hub (5 Gb/s, 0mA)
 U-Boot XHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  U-Boot Root Hub

Thanks,
Jagan.

Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Simon Glass

Hi Jan,

On Tue, 20 Jun 2023 at 11:37, Jan Kiszka  wrote:
>
> On 20.06.23 12:11, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
> >>
> >> On 19.06.23 16:09, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
> 
>  On 19.06.23 14:36, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:
> >>
> >> On 15.06.23 13:46, Jan Kiszka wrote:
> >>> On 15.06.23 13:38, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
>  wrote:
> >
> > On 15.06.23 13:19, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 15.06.23 12:55, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 11:26, Jan Kiszka 
>   wrote:
> >
> > On 12.06.23 23:17, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka 
> >>  wrote:
> >>>
> >>> From: Jan Kiszka 
> >>>
> >>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., 
> >>> to inject
> >>> specific settings. Will be used by IOT2050 first to define 
> >>> multiple
> >>> of-lists.
> >>>
> >>> Signed-off-by: Jan Kiszka 
> >>> ---
> >>> CC: Simon Glass 
> >>> ---
> >>>  Makefile | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>
> >> I'm really not keen on this, since it means that the Makefile 
> >> (or some
> >> vars it sets) are again involved in controlling the image 
> >> generation.
> >> It should really all be in the binman image description / 
> >> .dtsi file
> >
> > binman does not allow me to unrole of-list inside the dts file, 
> > does it?
> > With such a feature, I wouldn't need any custom -a of-list-X 
> > switches
> > and, thus, no such EXTRA_ARGS.
> 
>  Can you explain a bit more about what you mean by 'unrole'? It 
>  is just
>  software, so anything should be possible.
> >>>
> >>> To use a DT sequence, I need to specify fit,ftd-list. But I can 
> >>> say
> >>>
> >>> fit,ftd-list = "first.dtb second.dtb"
> >>>
> >>> I rather need to go via the EntryArg indirection of the binman 
> >>> command line.
> >>
> >> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are 
> >> you
> >> wanting to filter that list based on something else?
> >>
> >> I'm afraid I am really not following this at all.
> >
> > CONFIG_OF_LIST is not working here as we have two different boards 
> > with
> > two different lists.
> 
>  But we only build one board at a time, don't we?
> >>>
> >>> No, this is about building two flash images for two different board
> >>> generations in the same binman run (see patch 3).
> >>>
> 
>  We could provide a way to select between different lists, but how 
>  does
>  Makefile get access to them?
> >>>
> >>> See patch 3: known lists, now put into board config.mk.
> >>>
> >>
> >> Any better suggestions for this issue? Otherwise, I will have to keep
> >> binman args extension for now.
> >
> > I've dug into this a bit. The use of #defines and macros looks to be
> > unnecessary, unless I am missing something.
> >
> > You can do things like this:
> >
> > fit_node: fit {
> > // base definition of FIT
> > };
> >
> > the later on:
> >
> > fit_node: {
> > #ifdef xxx
> >// override a few things
> >fit,fdt-list = ...
> > #else
> >
> > #endif
> 
>  As I wrote already, I have a solution for that by using a template dtsi.
> 
> >
> > There is no need to specify the properties all at once. You can update
> > a property later on just by referring to its node as above.
> 
>  Does not help when the anchor name needs to vary as well. That's where I
>  will use a #define to customize the template on include.
> 
> >
> > I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
> > and all the #define stuff.
> 
>  You still didn't address my question. Should I share my version to make
>  the problem clearer? But I thought I explained this in various shades
>  already.
> >>>
> >>> Yes, if I am looking at the wrong patches, please point

Re: [PATCH v2] board_f: Relocate fdt even if GD_FLG_SKIP_RELOC is set

2023-06-20 Thread Simon Glass

On Tue, 20 Jun 2023 at 11:50, Kunihiko Hayashi
 wrote:
>
> In case of OF_SEPARATE (!OF_EMBED), the devicetree blob is placed
> after _end, and fdt_find_separate() always returns _end. There is
> a .bss section after _end and the section is cleared before relocation.
>
> When GD_FLG_SKIP_RELOC is set, relocation is skipped, so the blob is
> still in .bss section, but will be cleared. As a result, the devicetree
> become invalid.
>
> To avoid this issue, should relocate it regardless of GD_FLG_SKIP_RELOC
> in reloc_fdt().
>
> Signed-off-by: Kunihiko Hayashi 
> ---
>  common/board_f.c | 2 --
>  1 file changed, 2 deletions(-)
>
> Changes since v1:
> - Remove condition for skipping fdt relocation (always relocate)
>

Reviewed-by: Simon Glass

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Simon Glass

On Tue, 20 Jun 2023 at 12:20, Xavier Drudis Ferran  wrote:
>
> El Tue, Jun 20, 2023 at 11:03:57AM +0100, Simon Glass deia:
> > Hi Xavier,
> >
>
> Hi Simon,
>
> > >
> > > It is also possible that one day a device that is not UCLASS_BLK,
> > > UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage
> > > device (just imagine a future system similar to bootstd for firmware
> > > updates, trust material, etc.). Is it likely to have a struct in
> > > parent_priv_ that is not a usb_device ?
> > >
> > > So which is more likely to survive future changes ?
> > >
> > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL
> > >
> > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not 
> > > UCLASS_BLK
> > >   (my patch, overcautious ?)
> > >
> > > - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL)
> > >   (Simon Glass' idea)
> > >
> > > - checking for not  UCLASS_BLK and not UCLASS_BOOTDEV and not 
> > > UCLASS_USB_EMUL
> > >and parent_priv_ not null
> >
> > Really the parent_priv thing is a separate issue, a side effect of
> > something having a UCLASS_USB parent.
> >
>
> I don't think it's a separate issue. If parent_priv is present it
> could be a usb_device (most likely) or not, but if it's null there's
> no way the recursive call can succeed.
>
> > The key point here is that we cannot iterate down into a bootdev
> > device looking for USB devices. So we should use that as the check,
> > since it is the most direct check.
> >
>
> But things keep appearing that have a UCLASS_USB* parent and no
> parent_priv.
> in 2017 Suneel Garapati already fixed the issue of UCLASS_BLK
> being a child of a device. Now it's UCLASS_BOOTDEV, and tomorrow
> may be something else.
>
> The most direct check will miss future cases as the devices tend to
> become more abstract instead of mapping one to one to physical stuff.
>
> >
> > >From my memory, I think you can check for a USB hub instead, but I'm
> > not completely sure.
> >
>
> On second thoughts I didn't find it so easy. There's the root hub,
> UCLASS_USB, I think and a UCLASS_USB_EMUL may also be a hub, so I
> don't know anymore how more elegant that could be, so I left it be.
>
> > I suggest adding a test for the command (see test/dm/acpi.c for an
> > example) since a test is the best way to ensure this doesn't happen
> > again.
> >
>
> Makes sense. But I don't have any more time for that, sorry.
>
> I think we'll have to leave it at this unless someone else has the time.

Reviewed-by: Simon Glass

Re: [PATCH v13 05/10] arm_ffa: introduce armffa command

2023-06-20 Thread Ilias Apalodimas

[...]

>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 43603522fd..0d960731cf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -269,7 +269,9 @@ F:  configs/cortina_presidio-asic-pnand_defconfig
>  ARM FF-A
>  M: Abdellatif El Khlifi 
>  S: Maintained
> +F: cmd/armffa.c
>  F: doc/arch/arm64.ffa.rst
> +F: doc/usage/cmd/armffa.rst
>  F: drivers/firmware/arm-ffa/
>  F: include/arm_ffa.h
>  F: include/sandbox_arm_ffa.h
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 365371fb51..86af7bcc9e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -934,6 +934,16 @@ endmenu
>
>  menu "Device access commands"
>
> +config CMD_ARMFFA
> +   bool "Arm FF-A test command"
> +   depends on ARM_FFA_TRANSPORT
> +   help
> + Provides a test command for the FF-A support
> + supported options:
> +   - Listing the partition(s) info
> +   - Sending a data pattern to the specified partition
> +   - Displaying the arm_ffa device info
> +
>  config CMD_ARMFLASH
> #depends on FLASH_CFI_DRIVER
> bool "armflash"
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 6c37521b4e..7d20a85a46 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -12,6 +12,7 @@ obj-y += panic.o
>  obj-y += version.o
>
>  # command
> +obj-$(CONFIG_CMD_ARMFFA) += armffa.o
>  obj-$(CONFIG_CMD_2048) += 2048.o
>  obj-$(CONFIG_CMD_ACPI) += acpi.o
>  obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
> diff --git a/cmd/armffa.c b/cmd/armffa.c
> new file mode 100644
> index 00..fa268e9cb9
> --- /dev/null
> +++ b/cmd/armffa.c
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022-2023 Arm Limited and/or its affiliates 
> 
> + *
> + * Authors:
> + *   Abdellatif El Khlifi 
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * ffa_get_dev() - Return the FF-A device
> + * @devp:  pointer to the FF-A device
> + *
> + * Search for the FF-A device.
> + *
> + * Return:
> + * 0 on success. Otherwise, failure
> + */
> +int ffa_get_dev(struct udevice **devp)

Why isn't this static?  If it's used in another file we need to move
it to a library suitable file.

> +{
> +   int ret;
> +
> +   ret = uclass_first_device_err(UCLASS_FFA, devp);
> +   if (ret) {
> +   log_err("Cannot find FF-A bus device\n");
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * do_ffa_getpart() - implementation of the getpart subcommand
> + * @cmdtp: Command Table
> + * @flag:  flags
> + * @argc:  number of arguments
> + * @argv:  arguments
> + *
> + * Query the secure partition information which the UUID is provided
> + * as an argument. The function uses the arm_ffa driver
> + * partition_info_get operation which implements FFA_PARTITION_INFO_GET
> + * ABI to retrieve the data. The input UUID string is expected to be in big
> + * endian format.
> + *
> + * Return:
> + *
> + * CMD_RET_SUCCESS: on success, otherwise failure
> + */
> +static int do_ffa_getpart(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> +   u32 count = 0;
> +   int ret;
> +   struct ffa_partition_desc *descs;
> +   u32 i;
> +   struct udevice *dev;
> +
> +   if (argc != 2) {
> +   log_err("Missing argument\n");
> +   return CMD_RET_USAGE;
> +   }
> +
> +   ret = ffa_get_dev();
> +   if (ret)
> +   return CMD_RET_FAILURE;
> +
> +   /* Ask the driver to fill the buffer with the SPs info */
> +
> +   ret = ffa_partition_info_get(dev, argv[1], , );
> +   if (ret) {
> +   log_err("Failure in querying partition(s) info (error code: 
> %d)\n", ret);
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   /* SPs found , show the partition information */
> +   for (i = 0; i < count ; i++) {
> +   log_info("Partition: id = %x , exec_ctxt %x , properties 
> %x\n",
> +descs[i].info.id,
> +descs[i].info.exec_ctxt,
> +descs[i].info.properties);
> +   }
> +
> +   return CMD_RET_SUCCESS;
> +}
> +
> +/**
> + * do_ffa_ping() - implementation of the ping subcommand
> + * @cmdtp: Command Table
> + * @flag:  flags
> + * @argc:  number of arguments
> + * @argv:  arguments
> + *
> + * Send data to the secure partition which the ID is provided

s/which/ in which/

> + * as an argument. Use the arm_ffa driver sync_send_receive operation
> + * which implements FFA_MSG_SEND_DIRECT_{REQ,RESP} ABIs to send/receive data.
> + *
> + * Return:
> + *
> + * CMD_RET_SUCCESS: on success, otherwise failure
> + */
> +int do_ffa_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[])
> +{
> +   struct ffa_send_direct_data msg = {
> +

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Michal Simek





On 6/20/23 16:13, Marek Vasut wrote:

On 6/20/23 15:36, Michal Simek wrote:



On 6/20/23 11:54, Marek Vasut wrote:

On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 +++--
  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in host 
mode,

+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip RK3588 , 
I noticed that you removed the code that resets the PHYs in this patch 
hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with Linux. 
Picking random DWC3 patches and ignoring other fixes will turn the whole 
driver into an unmaintainable mess and make the sync that much harder in 
the future. I spent enormous amount of my spare time trying to explain 
to Xilinx how to do that mostly automatically, but that was all ignored 
or countered with reason after reason why this cannot be done, but as 
far as I can tell, nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their current 
state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch actually 
helps in my case, just that it breaks something else, and I wanted to get 
more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start 
unless I add some manual delays here and there, and I am trying to see why.


It is not just about dwc3. There are other parts which are ported from 
Linux kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.

Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

2023-06-20 Thread Michal Simek





On 6/20/23 16:14, Jassi Brar wrote:

On Tue, 20 Jun 2023 at 05:05, Ilias Apalodimas
 wrote:


Sorry for being late to the party,

+cc Jose who maintains DEN0118

On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote:

Hi Michal,

On Mon, 19 Jun 2023 at 10:02, Michal Simek  wrote:


Hi Jassi,

On 5/31/23 07:28, jaswinder.si...@linaro.org wrote:

From: Jassi Brar 

Introduce support for mtd backed storage for FWU feature and enable it on
Synquacer platform based DeveloperBox.

This revision is rebased onto patchset that trims the FWU api
   
https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/


.


Firstly I can generate 2 images per one bank which should be pretty much regular
capsule update for 2 images. I would expect this should still work.

And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() generated
this description for DFU

mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000 nor0=bank0 raw
23a 400;bank1 raw 282 400

If you look at size in second entry you will see that it is 8000 instead of
8 because it is the same image. That's why curious if you have tested any
scenario like this.


I had, and have, strong doubts about the practicality of 2
images/bank. There aren't enough specification details to explain how
only 1-out-of-N images could be updated. And if we always update all
images in a bank together, we might as well have them as one composite
image. I never got satisfactory clarification from designers and
implementers. So, sorry, I can't defend that scenario with my limited
knowledge.


This is intentionally left out, as we consider it a platform policy.
For example you could update a single bank and copy over the remaining
firmware images from a different ban. There's nothing on the spec that
prohibits you from doing so, but I personally think it's a bad idea.


Me too.


Keep in mind there's a document hosted here[0] which explains the update
flow and documents what we have as code in U-Boot.

As far as individual firmware components go now,  do you have any useful
usecase?


No.  And I don't think current A/B update implementation in u-boot
even has helpers for platforms to implement multiple images per bank.
Which is fine, except we pretend we do by having NUM_IMAGES_PER_BANK
config -- which will always be set to 1 I predict ;)


Actually support is there but it requires one thing to patch. I will send that 
patch when I clean my repo.

And I have tested it on our platform.




  The general guidance of [0] is construct a firmware
image, only update the components you want while leaving the rest on the
same revisions and update the entire firmware.  The reason is that firmware

Updating a single image of another bank is not as easy as it sounds.


exactly.


Firmware components nowadays, whether we like it or not, depend on each other.
Since firmware updates are not so often and fast,  we didn't see any gains from
over complicating the spec and explicitly describe that case, while dealing
with firmware component compatibility at the same time.


Totally.  As I said, I don't believe in the practicality of more than
1 image/bank.
So we are on the same page.




Next part which I want to take a look is practicality of CONFIG_FWU_NUM_BANKS
and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing number of
banks and images for every platform and prevent creating one u-boot which works
on different boards and just use information from mdata.
DEN0118 doesn't show any field with this information but do you think that would
be possible to extract that information from there based on for example reserved
or accepted field?


Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in
'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we
use any bit, we'll be in violation of the spec.


Yes this is unfortunate.  We did have similar concerns on when drafting the
spec,  however we never had a solid usecase to justify this.  Arm and
Linaro and working on a v2 (which we try to make compatible with v1) which
addresses this shortcoming.  Maybe Jose can chime in.



Another way would be to simply decode this information directly from DT 
fwu-mdata node. Because from that node it is clear how many banks and how many 
images that particular bank has.


Thanks,
Michal

Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

2023-06-20 Thread Jassi Brar

On Tue, 20 Jun 2023 at 05:05, Ilias Apalodimas
 wrote:
>
> Sorry for being late to the party,
>
> +cc Jose who maintains DEN0118
>
> On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote:
> > Hi Michal,
> >
> > On Mon, 19 Jun 2023 at 10:02, Michal Simek  wrote:
> > >
> > > Hi Jassi,
> > >
> > > On 5/31/23 07:28, jaswinder.si...@linaro.org wrote:
> > > > From: Jassi Brar 
> > > >
> > > > Introduce support for mtd backed storage for FWU feature and enable it 
> > > > on
> > > > Synquacer platform based DeveloperBox.
> > > >
> > > > This revision is rebased onto patchset that trims the FWU api
> > > >   
> > > > https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/
> > > >
> > .
> >
> > > Firstly I can generate 2 images per one bank which should be pretty much 
> > > regular
> > > capsule update for 2 images. I would expect this should still work.
> > >
> > > And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() 
> > > generated
> > > this description for DFU
> > >
> > > mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000 nor0=bank0 raw
> > > 23a 400;bank1 raw 282 400
> > >
> > > If you look at size in second entry you will see that it is 8000 instead 
> > > of
> > > 8 because it is the same image. That's why curious if you have tested 
> > > any
> > > scenario like this.
> > >
> > I had, and have, strong doubts about the practicality of 2
> > images/bank. There aren't enough specification details to explain how
> > only 1-out-of-N images could be updated. And if we always update all
> > images in a bank together, we might as well have them as one composite
> > image. I never got satisfactory clarification from designers and
> > implementers. So, sorry, I can't defend that scenario with my limited
> > knowledge.
>
> This is intentionally left out, as we consider it a platform policy.
> For example you could update a single bank and copy over the remaining
> firmware images from a different ban. There's nothing on the spec that
> prohibits you from doing so, but I personally think it's a bad idea.
>
Me too.

> Keep in mind there's a document hosted here[0] which explains the update
> flow and documents what we have as code in U-Boot.
>
> As far as individual firmware components go now,  do you have any useful
> usecase?
>
No.  And I don't think current A/B update implementation in u-boot
even has helpers for platforms to implement multiple images per bank.
Which is fine, except we pretend we do by having NUM_IMAGES_PER_BANK
config -- which will always be set to 1 I predict ;)

>  The general guidance of [0] is construct a firmware
> image, only update the components you want while leaving the rest on the
> same revisions and update the entire firmware.  The reason is that firmware
>
> Updating a single image of another bank is not as easy as it sounds.
>
exactly.

> Firmware components nowadays, whether we like it or not, depend on each other.
> Since firmware updates are not so often and fast,  we didn't see any gains 
> from
> over complicating the spec and explicitly describe that case, while dealing
> with firmware component compatibility at the same time.
>
Totally.  As I said, I don't believe in the practicality of more than
1 image/bank.
So we are on the same page.

> >
> > > Next part which I want to take a look is practicality of 
> > > CONFIG_FWU_NUM_BANKS
> > > and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing 
> > > number of
> > > banks and images for every platform and prevent creating one u-boot which 
> > > works
> > > on different boards and just use information from mdata.
> > > DEN0118 doesn't show any field with this information but do you think 
> > > that would
> > > be possible to extract that information from there based on for example 
> > > reserved
> > > or accepted field?
> > >
> > Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in
> > 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we
> > use any bit, we'll be in violation of the spec.
>
> Yes this is unfortunate.  We did have similar concerns on when drafting the
> spec,  however we never had a solid usecase to justify this.  Arm and
> Linaro and working on a v2 (which we try to make compatible with v1) which
> addresses this shortcoming.  Maybe Jose can chime in.
>
OK. If we have, say, reserved[0] as last Image and reserved[1] as last
Bank, we could get rid of the two compile-time configs.

Thanks.

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Marek Vasut


On 6/20/23 15:36, Michal Simek wrote:



On 6/20/23 11:54, Marek Vasut wrote:

On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note 
that this

reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling 
loop executed

at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to 
detect the

USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 


---
  drivers/usb/dwc3/core.c | 50 
+++--

  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, 
u32 mode)

  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're 
in host mode,
+ * XHCI driver will reset the host block. If dwc3 was 
configured for

+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset 
state */

-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip 
RK3588 , I noticed that you removed the code that resets the 
PHYs in this patch hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with 
Linux. Picking random DWC3 patches and ignoring other fixes will 
turn the whole driver into an unmaintainable mess and make the 
sync that much harder in the future. I spent enormous amount of 
my spare time trying to explain to Xilinx how to do that mostly 
automatically, but that was all ignored or countered with reason 
after reason why this cannot be done, but as far as I can tell, 
nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their 
current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch 
actually helps in my case, just that it breaks something else, and 
I wanted to get more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly 
start unless I add some manual delays here and there, and I am 
trying to see why.


It is not just about dwc3. There are other parts which are ported 
from Linux kernel and are out of sync from Linux kernel for quite a 
long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the

Re: [PATCH v13 01/10] arm64: smccc: add support for SMCCCv1.2 x0-x17 registers

2023-06-20 Thread Ilias Apalodimas

Hi Abdellatif,

On Fri, 16 Jun 2023 at 18:28, Abdellatif El Khlifi
 wrote:
>
> add support for x0-x17 registers used by the SMC calls
>
> In SMCCC v1.2 [1] arguments are passed in registers x1-x17.
> Results are returned in x0-x17.
>
> This work is inspired from the following kernel commit:
>
> arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
>
> [1]: 
> https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token=

I did review this one in the past, any reason why that is missing?
Did the file change?

Thanks
/Ilias
>
> Signed-off-by: Abdellatif El Khlifi 
> Reviewed-by: Jens Wiklander 
> Reviewed-by: Simon Glass 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
>
> ---
>
> Changelog:
> ===
>
> v9:
>
> * update the copyright string
>
> v7:
>
> * improve indentation of ARM_SMCCC_1_2_REGS_Xn_OFFS
>
> v4:
>
> * rename the commit title and improve description
>   new commit title: the current
>
> v3:
>
> * port x0-x17 registers support from linux kernel as defined by SMCCCv1.2
>   commit title:
>   arm64: smccc: add Xn registers support used by SMC calls
>
>  arch/arm/cpu/armv8/smccc-call.S | 57 -
>  arch/arm/lib/asm-offsets.c  | 16 +
>  include/linux/arm-smccc.h   | 45 ++
>  3 files changed, 117 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
> index dc92b28777..93f66d3366 100644
> --- a/arch/arm/cpu/armv8/smccc-call.S
> +++ b/arch/arm/cpu/armv8/smccc-call.S
> @@ -1,7 +1,11 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  /*
>   * Copyright (c) 2015, Linaro Limited
> - */
> + * Copyright 2022-2023 Arm Limited and/or its affiliates 
> 
> + *
> + * Authors:
> + *   Abdellatif El Khlifi 
> +*/
>  #include 
>  #include 
>  #include 
> @@ -45,3 +49,54 @@ ENDPROC(__arm_smccc_smc)
>  ENTRY(__arm_smccc_hvc)
> SMCCC   hvc
>  ENDPROC(__arm_smccc_hvc)
> +
> +#ifdef CONFIG_ARM64
> +
> +   .macro SMCCC_1_2 instr
> +   /* Save `res` and free a GPR that won't be clobbered */
> +   stp x1, x19, [sp, #-16]!
> +
> +   /* Ensure `args` won't be clobbered while loading regs in next step */
> +   mov x19, x0
> +
> +   /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */
> +   ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
> +   ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
> +   ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
> +   ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
> +   ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
> +   ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
> +   ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
> +   ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> +   ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
> +
> +   \instr #0
> +
> +   /* Load the `res` from the stack */
> +   ldr x19, [sp]
> +
> +   /* Store the registers x0 - x17 into the result structure */
> +   stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
> +   stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
> +   stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
> +   stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
> +   stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
> +   stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
> +   stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
> +   stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> +   stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
> +
> +   /* Restore original x19 */
> +   ldp xzr, x19, [sp], #16
> +   ret
> +   .endm
> +
> +/*
> + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
> + *   struct arm_smccc_1_2_regs *res);
> + */
> +ENTRY(arm_smccc_1_2_smc)
> +   SMCCC_1_2 smc
> +ENDPROC(arm_smccc_1_2_smc)
> +
> +#endif
> diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c
> index 6de0ce9152..181a8ac4c2 100644
> --- a/arch/arm/lib/asm-offsets.c
> +++ b/arch/arm/lib/asm-offsets.c
> @@ -9,6 +9,11 @@
>   * generate asm statements containing #defines,
>   * compile this file to assembler, and then extract the
>   * #defines from the assembly-language output.
> + *
> + * Copyright 2022-2023 Arm Limited and/or its affiliates 
> 
> + *
> + * Authors:
> + *   Abdellatif El Khlifi 
>   */
>
>  #include 
> @@ -90,6 +95,17 @@ int main(void)
> DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2));
> DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id));
> DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, 
> state));
> +#ifdef CONFIG_ARM64
> +   DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS,  offsetof(struct 
> arm_smccc_1_2_regs, a0));
> +   DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS,  offsetof(struct 
> arm_smccc_1_2_regs, a2));
> +

[PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register

2023-06-20 Thread teik . heng . chong

From: Teik Heng Chong 

Fix the write to the HPRT register which treat W1C fields
as if they were mere RW. This leads to unintended clearing of such fields

Signed-off-by: Teik Heng Chong 

---

V1->V2
- update subject tags to usb:dwc2
---
 drivers/usb/host/dwc2.c | 34 --
 drivers/usb/host/dwc2.h |  4 
 2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..9818f9be94 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev,
 
/* Turn on the vbus power. */
if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST) {
-   hprt0 = readl(>hprt0);
-   hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET);
-   hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG);
+   hprt0 = readl(>hprt0) & ~DWC2_HPRT0_W1C_MASK;
if (!(hprt0 & DWC2_HPRT0_PRTPWR)) {
hprt0 |= DWC2_HPRT0_PRTPWR;
writel(hprt0, >hprt0);
@@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv,
case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS:
switch (wValue) {
case USB_PORT_FEAT_C_CONNECTION:
-   setbits_le32(>hprt0, DWC2_HPRT0_PRTCONNDET);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTCONNDET);
break;
}
break;
@@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv 
*priv,
break;
 
case USB_PORT_FEAT_RESET:
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_POWER:
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET |
-   DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, 
DWC2_HPRT0_PRTRST);
break;
 
case USB_PORT_FEAT_ENABLE:
@@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
dwc_otg_core_host_init(dev, regs);
}
 
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
mdelay(50);
-   clrbits_le32(>hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET |
-DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG |
-DWC2_HPRT0_PRTRST);
+   clrbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST);
 
for (i = 0; i < MAX_DEVICE; i++) {
for (j = 0; j < MAX_ENDPOINT; j++) {
@@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct 
dwc2_priv *priv)
 static void dwc2_uninit_common(struct dwc2_core_regs *regs)
 {
/* Put everything in reset. */
-   clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
-   DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
-   DWC2_HPRT0_PRTOVRCURRCHNG,
-   DWC2_HPRT0_PRTRST);
+   clrsetbits_le32(>hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST);
 }
 
 #if !CONFIG_IS_ENABLED(DM_USB)
diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index a6f562fe60..6f022e33a1 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -543,6 +543,10 @@ struct dwc2_core_regs {
 #define DWC2_HPRT0_PRTSPD_LOW  (2 << 17)
 #define DWC2_HPRT0_PRTSPD_MASK (0x3 << 17)
 #define DWC2_HPRT0_PRTSPD_OFFSET   17
+#define DWC2_HPRT0_W1C_MASK(DWC2_HPRT0_PRTCONNDET 
| \
+   DWC2_HPRT0_PRTENA | \
+   DWC2_HPRT0_PRTENCHNG | \
+

Re: [PATCH v4 0/4] SPL NVMe support

2023-06-20 Thread Tom Rini

On Sat, 03 Jun 2023 19:32:52 +0530, Mayuresh Chitale wrote:

> This patchset adds support to load images of the SPL's next booting
> stage from a NVMe device.
> 
> Changes in v4:
> - Drop patch 4
> - Modify patch 2 to use generic fs.h APIs
> 
> [...]

With one change, which is that the "disk/part.c" in 4/4 were not required for
any platform in tree and also broke testcases, and so was dropped, this has now
been applied to u-boot/next. If you can explain a bit more what the problem you
had was, we can look in to it. I suspect you need to test for not
SPL_ENV_SUPPORT  but ENV_SUPPORT itself.

-- 
Tom

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Michal Simek





On 6/20/23 11:54, Marek Vasut wrote:

On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 +++--
  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in host 
mode,

+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I 
noticed that you removed the code that resets the PHYs in this patch 
hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with Linux. 
Picking random DWC3 patches and ignoring other fixes will turn the whole 
driver into an unmaintainable mess and make the sync that much harder in 
the future. I spent enormous amount of my spare time trying to explain to 
Xilinx how to do that mostly automatically, but that was all ignored or 
countered with reason after reason why this cannot be done, but as far as 
I can tell, nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch actually 
helps in my case, just that it breaks something else, and I wanted to get 
more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start 
unless I add some manual delays here and there, and I am trying to see why.


It is not just about dwc3. There are other parts which are ported from Linux 
kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in an

Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

2023-06-20 Thread Andre Przywara

On Sun, 18 Jun 2023 13:01:33 -0600
Sam Edwards  wrote:

Hi Sam,

thanks for the reply, that's very helpful.

> On 6/14/23 18:07, Andre Przywara wrote:
> > So I finally found some time to address some issues in the series,
> > especially in the first patches (pinctrl rework and preparation).
> > I pushed a branch to https://github.com/apritzel/u-boot/commits/r528-rc
> > I need to do more testing, most importantly regression testing on other
> > SoCs, and will only be able to post something next week, I guess.
> > 
> > If you could briefly list the things that are still missing, I could
> > try to pick some low hanging fruits.  
> 
> Rebasing onto this branch ended up eliminating a good chunk of my local 
> hack commits. I've verified that everything is still working (but have 
> not yet retested NAND SPL).

Great, thanks!

> The remaining local changes I have are two additions to cpu_sunxi_ncat2.h:
> +#define SUNXI_R_CPUCFG_BASE  0x07000400 /* for PSCI */
> +#define SUNXI_RTC_BASE   0x0709 /* for FEL */

Right, I will definitely take the PSCI bit, but not so sure about FEL yet.

> The former can probably be brought into my PSCI series somehow (unless 
> we expect more chips with CPUX blocks which might move those soft entry 
> registers around, then it should be defined in cpu_sunxi_*.h). The 
> latter is to support a reimplementation of Allwinner's `efex` command 
> that I'm using for development (it pokes the magic number 0x5AA5A55A 
> into RTC's GP_DATA_REG[2] and then resets; SPL clears that magic number 
> and then does an early branch to BROM+0x0020 -- exactly what Allwinner's 
> fork does).

So yeah, the request of a "Enter FEL" command came up multiple times, but
so far no one could be bothered to implement this properly. The idea would
be to have a generic command (more like "fel-reset" than efex), and
allow each SoC (family) to implement this differently, as every
SoC requires something a bit different here (32-bit vs. 64-bit, having an
RTC vs not, etc).

If you could post your solution somewhere, we could start this effort.
There was some patch for the H3 already, and it's relatively
straight-forward on the newer SoCs (H616, IIRC), so if at least two
popular, but different SoCs would be supported, we could make sure to have
the right abstractions in place.

> I've also noticed exactly(!) one formatting difference in our clk_d1.c:
> - .num_gates = ARRAY_SIZE(d1_gates),
> + .num_gates  = ARRAY_SIZE(d1_gates),
> 
> Up to you if you prefer to align the = or not, but it does look 
> inconsistent when .gates and .resets are aligned and .num_* aren't - 
> might be a nitpick that comes up in patch review.

Well, this is how it is in all the other clock drivers, so I chose to stay
consistent with them ;-)

> > Interesting, indeed this is left at 0, which I think will result in 288
> > MHz.  
> 
> Correct, at least that's what I was seeing.
> 
> > What is that frequency in your case? Do you know what the BSP
> > programs?  
> 
> 1008 MHz, both.
> 
> > Traditionally we used something conservative that works
> > without cooling and with the default voltage, but I don't know that
> > value for the T113s.  
> 
> For what it's worth, this board has a bare T113-s3 and the current OS 
> does not reclock from 1008 MHz at all, and I don't know of any users of 
> the board having stability issues.
> 
> In my own case, it idles at that clock at around ~35°C.

OK, many thanks, it looks like 1008 MHz it is, then.

> > I think CLK_SUN20I_D1 should be set by default now, so can you check
> > that this is fixed?  
> 
> It is now gone from my defconfig and still working, so indeed this is fixed.
> 
> > Why would we need H6 PSCI support? On the ARMv8 parts we use Trusted
> > Firmware-A (TF-A) to provide PSCI services, which has a much more mature
> > implementation.  
> 
> It's not about the H6 and more about me being unsure whether R528/T113 
> is the first ARMv7-based SoC to use the new CPU management registers. If 
> it's not, and there's another such chip supported in U-Boot that just 
> lacks PSCI, it would make more sense for me to land my PSCI series 
> independently of our work here, and then you can add the R528 case 
> later. It sounds like R528/T113 may be the first such chip needing this 
> new code, though, so this may have to wait until the R528 series lands.
> 
> > How would this conflict, exactly? I don't see any other I2C2
> > definition?  
> 
> Well, no, the other definitions haven't landed in U-Boot yet. But they 
> do exist in the kernel, datasheets, and physical chips themselves:
> 
> PB0/PB1/PB8/PB9/PE4/PE5: i2c2 defined as muxval 4
> PC0/PC1/PD20/PD21/PG6/PG7/PG14/PG15: i2c2 defined as muxval 3
> PE12/PE13: i2c2 defined as muxval 2
> 
> Defining i2c2=2 universally would mean that the pins for i2c2 cannot be 
> changed, since it would conflict with every other definition.

Well, we are well aware that the current pinmux code is limited, but
we figured it does

[PATCH] Add Renesas patch attribution domain mapping

2023-06-20 Thread Marek Vasut

Add domain mapping for the +renesas mail, so that the patches get
attributed to to Renesas Electronics correctly.

Signed-off-by: Marek Vasut 
---
 u-boot-config/domain-map | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map
index f64147e..478696f 100644
--- a/u-boot-config/domain-map
+++ b/u-boot-config/domain-map
@@ -536,3 +536,6 @@ s...@chromium.org   Google, Inc.
 
 # Louis Yung-Chieh Lo 
 # yj...@google.com Google, Inc.
+
+# Marek Vasut
+marek.vasut+rene...@mailbox.orgRenesas Electronics
-- 
2.39.2

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Xavier Drudis Ferran

El Tue, Jun 20, 2023 at 11:03:57AM +0100, Simon Glass deia:
> Hi Xavier,
>

Hi Simon,

> >
> > It is also possible that one day a device that is not UCLASS_BLK,
> > UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage
> > device (just imagine a future system similar to bootstd for firmware
> > updates, trust material, etc.). Is it likely to have a struct in
> > parent_priv_ that is not a usb_device ?
> >
> > So which is more likely to survive future changes ?
> >
> > - checking for parent_priv_ not null and not UCLASS_USB_EMUL
> >
> > - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not 
> > UCLASS_BLK
> >   (my patch, overcautious ?)
> >
> > - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL)
> >   (Simon Glass' idea)
> >
> > - checking for not  UCLASS_BLK and not UCLASS_BOOTDEV and not 
> > UCLASS_USB_EMUL
> >and parent_priv_ not null
> 
> Really the parent_priv thing is a separate issue, a side effect of
> something having a UCLASS_USB parent.
>

I don't think it's a separate issue. If parent_priv is present it
could be a usb_device (most likely) or not, but if it's null there's
no way the recursive call can succeed.

> The key point here is that we cannot iterate down into a bootdev
> device looking for USB devices. So we should use that as the check,
> since it is the most direct check.
>

But things keep appearing that have a UCLASS_USB* parent and no
parent_priv.
in 2017 Suneel Garapati already fixed the issue of UCLASS_BLK
being a child of a device. Now it's UCLASS_BOOTDEV, and tomorrow
may be something else.

The most direct check will miss future cases as the devices tend to
become more abstract instead of mapping one to one to physical stuff.

> 
> >From my memory, I think you can check for a USB hub instead, but I'm
> not completely sure.
>

On second thoughts I didn't find it so easy. There's the root hub,
UCLASS_USB, I think and a UCLASS_USB_EMUL may also be a hub, so I
don't know anymore how more elegant that could be, so I left it be.

> I suggest adding a test for the command (see test/dm/acpi.c for an
> example) since a test is the best way to ensure this doesn't happen
> again.
>

Makes sense. But I don't have any more time for that, sorry.

I think we'll have to leave it at this unless someone else has the time.

Bye.

[PATCH v2] board_f: Relocate fdt even if GD_FLG_SKIP_RELOC is set

2023-06-20 Thread Kunihiko Hayashi

In case of OF_SEPARATE (!OF_EMBED), the devicetree blob is placed
after _end, and fdt_find_separate() always returns _end. There is
a .bss section after _end and the section is cleared before relocation.

When GD_FLG_SKIP_RELOC is set, relocation is skipped, so the blob is
still in .bss section, but will be cleared. As a result, the devicetree
become invalid.

To avoid this issue, should relocate it regardless of GD_FLG_SKIP_RELOC
in reloc_fdt().

Signed-off-by: Kunihiko Hayashi 
---
 common/board_f.c | 2 --
 1 file changed, 2 deletions(-)

Changes since v1:
- Remove condition for skipping fdt relocation (always relocate)

diff --git a/common/board_f.c b/common/board_f.c
index 1688e27071fc..334d04af197b 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -633,8 +633,6 @@ static int init_post(void)
 static int reloc_fdt(void)
 {
if (!IS_ENABLED(CONFIG_OF_EMBED)) {
-   if (gd->flags & GD_FLG_SKIP_RELOC)
-   return 0;
if (gd->new_fdt) {
memcpy(gd->new_fdt, gd->fdt_blob,
   fdt_totalsize(gd->fdt_blob));
-- 
2.25.1

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Xavier Drudis Ferran

El Tue, Jun 20, 2023 at 11:49:36AM +0200, Marek Vasut deia:
> 
> Default, see:
> $ git grep CONFIG_BOOTCOMMAND configs/
>

I'm lost.

I called default what Kconfig used as default.
You seem to call default what's in board specific config files.
Whatever. Fix the wording in the commit message if you like.


> 
> So, what is the minimal test case ?
> I have been asking for that for a while.
>

I sent a minimal test case last week.

https://lists.denx.de/pipermail/u-boot/2023-June/520109.html

You build for a Rock Pi 4 board, boot with usb stick and no boot media
and run usb info and you get a reset.

I won't send it again because I can't guess what you consider minimal.

> 
> I would really like a minimal test case. Empty your env and figure out the
> commands which need to be executed to trigger this. Without any interference
> from other commands/scripting/...
>

I'm sorry but if what I sent isn't enough I don't think I'll have time
to help you any further. Find your minimal test case yourself or
ignore my patch.

> > If it's just that you can't reproduce it, can you try to ?:
> > 
> > - set up a board with no boot media (I tested like this but it might
> >not be needed),
> > 
> > - put usb in boot_targets (if you put only usb there you may not need
> >the previous step):
> >setenv boot_targets usb
> 
> Here you assume distro bootcommand or some such . Can we remove that
> assumption ? (I think yes, and we should)
>

I don't think I'm assuming anything about bootcommand. That's
precisely why I wrote these steps instead of the "just boot a Rock Pi
4" scenario last week.

The commit message talks about bootcmd because it justifies
that the bootflow scan will be called automatically in some cases,
so the bug has more impact that it would otherwise have.

But the bug should appear whether or not you have bootcmd.
The bug should be an interaction between what bootflow scan does
and what usb info or usb tree do.

I'm assuming bootflow reads the boot_targets environment variable to
know where it searches for boot devices, and therefore to which
devices it will attach a UCLASS_BOOTDEV child to some devices, in
particular to usb mass storage devices if any is present, that will
later break usb info/usb tree. Whether bootflow is called from bootcmd
or not should be irrelevant.

If you follow the code from the bootflow command you may find
yourself that the boot_targets variable is involved. I did it
last week or sometime and won't do it again now for you, sorry.
I know I may have misunderstood something, and I'm sorry for the
noise if so.

> > - plug a non-booting usb mass storage device to an usb port,
> > 
> > - run usb reset in case you already had usb initialized at boot, or
> >skip this if usb is not initialized yet. If in doubt, run usb reset.
> > 
> > - run bootflow scan
> > 
> > - run usb info
> > 
> > It should list some devices, but give you a reset just after listing the
> > usb mass storage device without my patch, and it should just list all
> > usb devices and go back to the prompt with my patch.
> 
> Does it crash if you empty your env and run simply
> 
> => usb reset ; bootflow scan ; usb info
> 
> ?

I guess it won't crash if environment var boot_targets is absent or
empty.  Or even if it's full but has no "usb" in it. But I'm not sure
anymore at what time the variable is read, so it might be that
emptying it when bootflow structures are already set up wouldn't
change things, I don't know, I don't remember.

But I won't try it, sorry.

I found a bug, I sent a 4 line patch. Since I didn't justify it
enough I sent followup mails on how to reproduce.
This week I sent a second version, with redundant measures to seek
consensus. It's a 6 line patch or 8 or whatever.
I didn't write bootflow, and I didn't write cmd/usb.c

And I don't have time to keep writing long emails. I'm sorry.  Not
even to count how many lines of text I wrote compared to the 8 lines
of code or whatever. If someone has the bureaucratic skills and
patience to pursue this further, they can do what they want with my
patch (under GPL2 as implied by the sign off). If not, you all can
keep your bugs, I won't try anymore to steal them.

Bye and sorry for any disturbances.

Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Jan Kiszka

On 20.06.23 12:11, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
>>
>> On 19.06.23 16:09, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:

 On 19.06.23 14:36, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:
>>
>> On 15.06.23 13:46, Jan Kiszka wrote:
>>> On 15.06.23 13:38, Simon Glass wrote:
 Hi Jan,

 On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
 wrote:
>
> On 15.06.23 13:19, Simon Glass wrote:
>> Hi Jan,
>>
>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
>> wrote:
>>>
>>> On 15.06.23 12:55, Simon Glass wrote:
 Hi Jan,

 On Thu, 15 Jun 2023 at 11:26, Jan Kiszka  
 wrote:
>
> On 12.06.23 23:17, Simon Glass wrote:
>> Hi Jan,
>>
>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka  
>> wrote:
>>>
>>> From: Jan Kiszka 
>>>
>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to 
>>> inject
>>> specific settings. Will be used by IOT2050 first to define 
>>> multiple
>>> of-lists.
>>>
>>> Signed-off-by: Jan Kiszka 
>>> ---
>>> CC: Simon Glass 
>>> ---
>>>  Makefile | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> I'm really not keen on this, since it means that the Makefile 
>> (or some
>> vars it sets) are again involved in controlling the image 
>> generation.
>> It should really all be in the binman image description / .dtsi 
>> file
>
> binman does not allow me to unrole of-list inside the dts file, 
> does it?
> With such a feature, I wouldn't need any custom -a of-list-X 
> switches
> and, thus, no such EXTRA_ARGS.

 Can you explain a bit more about what you mean by 'unrole'? It is 
 just
 software, so anything should be possible.
>>>
>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say
>>>
>>> fit,ftd-list = "first.dtb second.dtb"
>>>
>>> I rather need to go via the EntryArg indirection of the binman 
>>> command line.
>>
>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you
>> wanting to filter that list based on something else?
>>
>> I'm afraid I am really not following this at all.
>
> CONFIG_OF_LIST is not working here as we have two different boards 
> with
> two different lists.

 But we only build one board at a time, don't we?
>>>
>>> No, this is about building two flash images for two different board
>>> generations in the same binman run (see patch 3).
>>>

 We could provide a way to select between different lists, but how does
 Makefile get access to them?
>>>
>>> See patch 3: known lists, now put into board config.mk.
>>>
>>
>> Any better suggestions for this issue? Otherwise, I will have to keep
>> binman args extension for now.
>
> I've dug into this a bit. The use of #defines and macros looks to be
> unnecessary, unless I am missing something.
>
> You can do things like this:
>
> fit_node: fit {
> // base definition of FIT
> };
>
> the later on:
>
> fit_node: {
> #ifdef xxx
>// override a few things
>fit,fdt-list = ...
> #else
>
> #endif

 As I wrote already, I have a solution for that by using a template dtsi.

>
> There is no need to specify the properties all at once. You can update
> a property later on just by referring to its node as above.

 Does not help when the anchor name needs to vary as well. That's where I
 will use a #define to customize the template on include.

>
> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
> and all the #define stuff.

 You still didn't address my question. Should I share my version to make
 the problem clearer? But I thought I explained this in various shades
 already.
>>>
>>> Yes, if I am looking at the wrong patches, please point me to the
>>> correct series, or push a tree somewhere.
>>>
>>
>> Please have a look at
>> https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e
> 
> OK that looks a lot better to me. We can go with that until we come up
> with something better.
> 
> There has been a long-standing request to support common parts of images.
> 
> I am thinking something

Re: [PATCH] board_f: Relocate fdt if SKIP_RELOC and fdt is in bss

2023-06-20 Thread Kunihiko Hayashi


Hi Simon,

On 2023/06/19 21:36, Simon Glass wrote:

Hi Kunihiko,

On Fri, 16 Jun 2023 at 00:59, Kunihiko Hayashi
 wrote:


Hi Simon,

Thank you for your comment.

On 2023/06/13 6:17, Simon Glass wrote:

Hi Kunihiko,

On Thu, 8 Jun 2023 at 07:53, Kunihiko Hayashi
 wrote:


There are cases that the devicetree blob is placed after _end, such as
fdt_find_separate() returns _end. This is in bss area cleared before
relocation.

When GD_FLG_SKIP_RELOC is set, the blob is still in bss, but will be
cleared. As a result, the devicetree become invalid.

To avoid this issue, should relocate it to the new fdt area using the
latter condition in reloc_fdt().

Signed-off-by: Kunihiko Hayashi 
---
   common/board_f.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 51d2f3c365e9..9a245872d190 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -622,7 +622,8 @@ static int init_post(void)
   static int reloc_fdt(void)
   {
  if (!IS_ENABLED(CONFIG_OF_EMBED)) {
-   if (gd->flags & GD_FLG_SKIP_RELOC)
+   if (gd->flags & GD_FLG_SKIP_RELOC &&
+   gd->fdt_blob != &_end)


!IS_ENABLED(CONFIG_OF_EMBED)  == IS_ENABLED(CONFIG_OF_SEPARATE)

reloc_fdt() is only called by U-Boot (not SP)

So the FDT was found by fdt_find_separate() and gd->fdt_blob == &_end

So, is there any case where:

gd->flags & GD_FLG_SKIP_RELO is true
gd->fdt_blob != &_end is true

?


Yes. But in fact,
if (gd->flags & GD_FLG_SKIP_RELOC is true) and (gd->fdt_blob overlaps .bss
section),
the fdt should be relocated because clear_bss() will clear the fdt after
that.


I misstated my point. I am wondering if  gd(->fdt_blob != &_end) is
ever false? If not, then we can always relocate.


When CONFIG_OF_SEPARATE is true, it seems that (gd->fdt_blob != &_end) is
always false because the fdt file is concatinated to the end of the image file
in Makefile.




I can't think of one.

If that is the case, then you could add a comment to this effect and
unconditionally relocate if !CONFIG_OF_EMBED.


I'm not sure if it is possible to unconditionally relocate the fdt,
I think we need to know if the fdt overlaps .bss section.


What is the down-side of always relocating, and when would the fdt not
overlap the .bss section?


The fdt always overlaps the .bss section, so it should be relocated
even if (gd->flags & GL_FLG_SKIP_RELOC) is true.


Note that OF_EMBED is not to be used in production boards. That is
violated by a few things at present, but IMO always relocating should
be safe.


Yes, I undestand.
I delete the condition in v2, and change to always relocate the fdt
in case of !OF_EMBED.

Thank you,

---
Best Regards
Kunihiko Hayashi

Re: [PATCH v13 05/10] arm_ffa: introduce armffa command

2023-06-20 Thread Simon Glass

On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> Provide armffa command showcasing the use of the U-Boot FF-A support
>
> armffa is a command showcasing how to invoke FF-A operations.
> This provides a guidance to the client developers on how to
> call the FF-A bus interfaces. The command also allows to gather secure
> partitions information and ping these  partitions. The command is also
> helpful in testing the communication with secure partitions.
>
> For more details please refer to the command documentation [1].
>
> [1]: doc/usage/cmd/armffa.rst
>
> Signed-off-by: Abdellatif El Khlifi 
> Reviewed-by: Simon Glass 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> Cc: Heinrich Schuchardt 
>
> ---
>
> Changelog:
> ===
>
> v12:
>
> * add subcommands argument checks
> * usage documentation: update command return codes
> * remove calloc when querying SPs
> * address nits
>
> v11:
>
> * use U_BOOT_CMD_WITH_SUBCMDS
> * address nits
>
> v10:
>
> * use the FF-A driver Uclass operations
> * use uclass_first_device()
> * address nits
>
> v9:
>
> * remove manual FF-A discovery and use DM
> * use DM class APIs to probe and interact with the FF-A bus
> * add doc/usage/cmd/armffa.rst
>
> v8:
>
> * update partition_info_get() second argument to be an SP count
> * pass NULL device pointer to the FF-A bus discovery and operations
>
> v7:
>
> * adapt do_ffa_dev_list() following the recent update on
>   uclass_first_device/uclass_next_device functions (they return void now)
> * set armffa command to use 64-bit direct messaging
>
> v4:
>
> * remove pattern data in do_ffa_msg_send_direct_req
>
> v3:
>
> * use the new driver interfaces (partition_info_get, sync_send_receive)
>   in armffa command
>
> v2:
>
> * replace use of ffa_helper_init_device function by
>  ffa_helper_bus_discover
>
> v1:
>
> * introduce armffa command
>
>  MAINTAINERS  |   2 +
>  cmd/Kconfig  |  10 ++
>  cmd/Makefile |   1 +
>  cmd/armffa.c | 196 +++
>  doc/arch/arm64.ffa.rst   |   7 ++
>  doc/usage/cmd/armffa.rst |  93 +++
>  doc/usage/index.rst  |   1 +
>  drivers/firmware/arm-ffa/Kconfig |   1 +
>  8 files changed, 311 insertions(+)
>  create mode 100644 cmd/armffa.c
>  create mode 100644 doc/usage/cmd/armffa.rst
>

Reviewed-by: Simon Glass

Re: [PATCH v13 09/10] arm_ffa: efi: introduce FF-A MM communication

2023-06-20 Thread Simon Glass

On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> Add MM communication support using FF-A transport
>
> This feature allows accessing MM partitions services through
> EFI MM communication protocol. MM partitions such as StandAlonneMM
> or smm-gateway secure partitions which reside in secure world.
>
> An MM shared buffer and a door bell event are used to exchange
> the data.
>
> The data is used by EFI services such as GetVariable()/SetVariable()
> and copied from the communication buffer to the MM shared buffer.
>
> The secure partition is notified about availability of data in the
> MM shared buffer by an FF-A message (door bell).
>
> On such event, MM SP can read the data and updates the MM shared
> buffer with the response data.
>
> The response data is copied back to the communication buffer and
> consumed by the EFI subsystem.
>
> MM communication protocol supports FF-A 64-bit direct messaging.
>
> Signed-off-by: Abdellatif El Khlifi 
> Signed-off-by: Gowtham Suresh Kumar 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
>
> ---
>
> Changelog:
> ===
>
> v13:
>
> * remove FF-A and Optee ifdefs
>
> v12:
>
> * drop use of calloc when querying SPs
> * address nits
>
> v11:
>
> * rename select_ffa_mm_comms() to select_mm_comms()
> * improve the logic of MM transport selection in mm_communicate()
> * addressing nits
>
> v10:
>
> * use the FF-A driver Uclass operations
> * use uclass_first_device()
> * addressing nits
>
> v9: align how FF-A is used with FF-A discovery through DM
>
> v8:
>
> * isolate the compilation choices between FF-A and OP-TEE
> * update partition_info_get() second argument to be an SP count
> * pass NULL device pointer to the FF-A bus discovery and operations
>
> v7:
>
> * set the MM door bell event to use 64-bit direct messaging
> * issue a compile time error when one of these macros are not found :
>   FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_OFFSET, 
> FFA_SHARED_MM_BUFFER_ADDR
> * make mm_sp_svc_uuid static
> * replace EINVAL with ENOMEM in ffa_discover_mm_sp_id() when calloc() fails
> * improve use of unmap_sysmem() in ffa_mm_communicate()
>
> v6:
>
> * add FF-A runtime discovery at MM communication level
> * drop EFI runtime support for FF-A MM communication
> * revert the changes in include/mm_communication.h for
>   efi_mm_communicate_header and smm_variable_access structures
>
> v4:
>
> * use the new FF-A driver interfaces
> * discover MM partitions at runtime
> * copy FF-A driver private data to EFI runtime section at
>   ExitBootServices()
> * drop use of FFA_ERR_STAT_SUCCESS error code
> * replace EFI_BUFFER_TOO_SMALL with EFI_OUT_OF_RESOURCES
>   in ffa_mm_communicate(). No need for efi_memcpy_runtime() anymore
> * revert the error log in mm_communicate() in case of failure
> * remove packed attribute from efi_mm_communicate_header and
>   smm_variable_communicate_header
>
> v2:
>
> * set default values to 0 for FFA_SHARED_MM_BUFFER_SIZE, 
> FFA_SHARED_MM_BUFFER_ADDR and MM_SP_UUID_DATA and add warnings
>
> v1:
>
> * introduce FF-A MM communication
>
>  include/mm_communication.h|  13 ++
>  lib/efi_loader/Kconfig|  16 +-
>  lib/efi_loader/efi_variable_tee.c | 260 +-
>  3 files changed, 282 insertions(+), 7 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH v13 04/10] arm_ffa: introduce Arm FF-A support

2023-06-20 Thread Simon Glass

On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
>
> The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology.
>
> This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
> on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
> querying the FF-A framework from the secure world.
>
> The driver uses SMC32 calling convention which means using the first
> 32-bit data of the Xn registers.
>
> All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
> which has 64-bit version supported.
>
> Both 32-bit and 64-bit direct messaging are supported which allows both
> 32-bit and 64-bit clients to use the FF-A bus.
>
> FF-A is a discoverable bus and similar to architecture features.
> FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
> by the PSCI driver.
>
> Clients are able to probe then use the FF-A bus by calling the DM class
> searching APIs (e.g: uclass_first_device).
>
> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
>
> The driver exports its operations to be used by upper layers.
>
> Exported operations:
>
> - ffa_partition_info_get
> - ffa_sync_send_receive
> - ffa_rxtx_unmap
>
> Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
> Arm specific methods are implemented in the Arm driver (arm-ffa.c).
>
> For more details please refer to the driver documentation [2].
>
> [1]: https://developer.arm.com/documentation/den0077/latest/
> [2]: doc/arch/arm64.ffa.rst
>
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> Cc: Heinrich Schuchardt 
>
> ---
>
> Changelog:
> ===
>
> v13:
>
> * doc minor change: specify in the readme that the user
>should call ffa_rxtx_unmap() driver operation to unmap
>the RX/TX buffers on demand.
>
> v12:
>
> * remove dscvry_info
> * replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn
>(user drivers can override it)
> * improve FFA_PARTITION_INFO_GET implementation
>(clients no longer need to calloc a buffer)
> * address nits
>
> v11:
>
> * move ffa_try_discovery() from the uclass to the Arm FF-A driver
> * rename ffa_try_discovery() to arm_ffa_discover()
> * pass dev as an argument of arm_ffa_discover()
> * add arm_ prefix to the Arm FF-A driver functions
> * add emul field in struct ffa_discovery_info
> * address nits
>
> v10:
>
> * provide the driver operations through the Uclass
> * move the generic FF-A methods to the Uclass
> * keep Arm specific methods in the Arm driver (arm-ffa.c)
> * rename core.c to arm-ffa.c
> * address nits
>
> v9:
>
> * integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for 
> binding
>
> v8:
>
> * make ffa_get_partitions_info() second argument to be an SP count in both
>   modes
> * update ffa_bus_prvdata_get() to return a pointer rather than a pointer
>   address
> * remove packing from ffa_partition_info and ffa_send_direct_data structures
> * pass the FF-A bus device to the bus operations
>
> v7:
>
> * add support for 32-bit direct messaging
> * rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
> * improve the declaration of error handling mapping
> * stating in doc/arch/arm64.ffa.rst that EFI runtime is not supported
>
> v6:
>
> * drop use of EFI runtime support (We decided with Linaro to add this later)
> * drop discovery from initcalls (discovery will be on demand by FF-A users)
> * set the alignment of the RX/TX buffers to the larger translation granule 
> size
> * move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit
> * update the documentation and move it to doc/arch/arm64.ffa.rst
>
> v4:
>
> * add doc/README.ffa.drv
> * moving the FF-A driver work to drivers/firmware/arm-ffa
> * use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
>   #if defined by #if CONFIG_IS_ENABLED
> * improving error handling by mapping the FF-A errors to standard errors
>   and logs
> * replacing panics with an error log and returning an error code
> * improving features discovery in FFA_FEATURES by introducing
>   rxtx_min_pages private data field
> * add ffa_remove and ffa_unbind functions
> * improve how the driver behaves when bus discovery is done more than
>   once
>
> v3:
>
> * align the interfaces of the U-Boot FF-A driver with those in the linux
>   FF-A driver
> * remove the FF-A helper layer
> * make the U-Boot FF-A driver independent from EFI
> * provide an optional config that enables copying the driver data to EFI
>   runtime section at ExitBootServices service
> * use 64-bit version

Re: [PATCH v13 03/10] lib: uuid: introduce testcase for uuid_str_to_le_bin

2023-06-20 Thread Simon Glass

On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi
 wrote:
>
> provide a test case
>
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Simon Glass 
>
> ---
>
> Changelog:
> ===
>
> v11:
>
> * use ut_asserteq_mem()
>
>  MAINTAINERS   |  5 +
>  test/lib/Makefile |  1 +
>  test/lib/uuid.c   | 41 +
>  3 files changed, 47 insertions(+)
>  create mode 100644 test/lib/uuid.c
>

Reviewed-by: Simon Glass

Re: [PATCH] mkimage: Use PATH_MAX for path length

2023-06-20 Thread Simon Glass

On Mon, 19 Jun 2023 at 17:25,  wrote:
>
> From: Mingli Yu 
>
> Fixed when build xilinx_zynqmp in long directory ( >256):
>   |  
> /buildarea1/testtest/wr_build/wr1023test_secureboot/test1-what/test2-what/test3-what/test4-what/test5-what/test6-what/test7-what/test8-what/test9-what/test10-what/test11-what/test12-what/build/tmp-glibc/work/xilinx_zynqmp-wrs-linux/u-boot-xlnx/1_v2023.01-xilinx-v2023.1+gitAUTOINC+40a08d69e7-r0/build/fitImage-linux:
>  Image file name (uboot-mkimage) too long, can't create tmpfile.
>   | Error: Bad parameters for FIT image type
>
> Signed-off-by: Mingli Yu 
> ---
>  tools/mkimage.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass

Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits

2023-06-20 Thread Simon Glass

Hi Tom, Pali,

On Wed, 14 Jun 2023 at 20:51, Tom Rini  wrote:
>
> On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote:
>
> > These 3 commits broke support for U-Boot Bootmenu on Nokia N900.
> > Issues were reported more than month ago, but nobody reacted to them.
> > So revert these broken commits for now, to fix U-Boot Bootmenu support.
> >
> > With these revered commits, U-Boot Bootmenu from master branch is
> > working fine again on Nokia N900.
> >
> > Pali Rohár (3):
> >   Revert "video: Enable VIDEO_ANSI by default only with EFI"
> >   Revert "menu: Factor out menu-keypress decoding"
> >   Revert "menu: Make use of CLI character processing"
> >
> >  cmd/bootmenu.c|   9 ++--
> >  cmd/eficonfig.c   |  12 ++---
> >  common/cli_getch.c|  12 ++---
> >  common/menu.c | 122 ++
> >  drivers/video/Kconfig |   7 +--
> >  include/cli.h |   4 +-
> >  include/menu.h|  17 +-
> >  7 files changed, 91 insertions(+), 92 deletions(-)
>
> Following up over here, while
> https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/
> addresses some of the issues, but not all (as it clearly isn't working
> in all of the cases Pali has explained), looking in to the VIDEO_ANSI
> part of this too, all three of these reverts are related seemingly to
> something escape-character related.  I'm not taking any of the revert
> commits in just yet, but will by the next -rc if we don't have something
> that fixes all of the issues.

I did send a series [1] with a fix for the nokia_rx51 keyboard driver,
including the previous ansi-code patch. Given that:

- this problem doesn't seem to manifest on other boards
- it does not cause any CI test to fail
- there seem to be bugs in the nokia_rx51 implementation which are a
possible/likely cause
- the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU
- the problem goes away if debugging is added, suggesting it is
related to timing

...I don't think a revert is appropriate.

Pali, can you please take a look and see if you can debug what is
actually going on? Here is my guess:

1. When an arrow key is pressed, cli_ch_process() handles it by being
passed the codes in sequence: \e [ B
2. Calling cli_ch_process() with ichar = 0 causes it to think the
sequence is finished: \e [ \0 B   (this doesn't work since the \0 ends
the sequence)
3. nokia_rx51 keyboard driver is returning '\0' even when key codes
are pending, causing cli_ch_process() to be told that the sequence is
done

It would help to move the keyboard driver into drivers/input/ so it is
easier to find.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=360134

Re: [PATCH 1/3] binman: Allow to define custom arguments

2023-06-20 Thread Simon Glass

Hi Jan,

On Mon, 19 Jun 2023 at 16:09, Jan Kiszka  wrote:
>
> On 19.06.23 16:09, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka  wrote:
> >>
> >> On 19.06.23 14:36, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka  wrote:
> 
>  On 15.06.23 13:46, Jan Kiszka wrote:
> > On 15.06.23 13:38, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 15.06.23 13:19, Simon Glass wrote:
>  Hi Jan,
> 
>  On Thu, 15 Jun 2023 at 12:09, Jan Kiszka  
>  wrote:
> >
> > On 15.06.23 12:55, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka  
> >> wrote:
> >>>
> >>> On 12.06.23 23:17, Simon Glass wrote:
>  Hi Jan,
> 
>  On Mon, 5 Jun 2023 at 15:39, Jan Kiszka  
>  wrote:
> >
> > From: Jan Kiszka 
> >
> > Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to 
> > inject
> > specific settings. Will be used by IOT2050 first to define 
> > multiple
> > of-lists.
> >
> > Signed-off-by: Jan Kiszka 
> > ---
> > CC: Simon Glass 
> > ---
> >  Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> 
>  I'm really not keen on this, since it means that the Makefile 
>  (or some
>  vars it sets) are again involved in controlling the image 
>  generation.
>  It should really all be in the binman image description / .dtsi 
>  file
> >>>
> >>> binman does not allow me to unrole of-list inside the dts file, 
> >>> does it?
> >>> With such a feature, I wouldn't need any custom -a of-list-X 
> >>> switches
> >>> and, thus, no such EXTRA_ARGS.
> >>
> >> Can you explain a bit more about what you mean by 'unrole'? It is 
> >> just
> >> software, so anything should be possible.
> >
> > To use a DT sequence, I need to specify fit,ftd-list. But I can say
> >
> > fit,ftd-list = "first.dtb second.dtb"
> >
> > I rather need to go via the EntryArg indirection of the binman 
> > command line.
> 
>  Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you
>  wanting to filter that list based on something else?
> 
>  I'm afraid I am really not following this at all.
> >>>
> >>> CONFIG_OF_LIST is not working here as we have two different boards 
> >>> with
> >>> two different lists.
> >>
> >> But we only build one board at a time, don't we?
> >
> > No, this is about building two flash images for two different board
> > generations in the same binman run (see patch 3).
> >
> >>
> >> We could provide a way to select between different lists, but how does
> >> Makefile get access to them?
> >
> > See patch 3: known lists, now put into board config.mk.
> >
> 
>  Any better suggestions for this issue? Otherwise, I will have to keep
>  binman args extension for now.
> >>>
> >>> I've dug into this a bit. The use of #defines and macros looks to be
> >>> unnecessary, unless I am missing something.
> >>>
> >>> You can do things like this:
> >>>
> >>> fit_node: fit {
> >>> // base definition of FIT
> >>> };
> >>>
> >>> the later on:
> >>>
> >>> fit_node: {
> >>> #ifdef xxx
> >>>// override a few things
> >>>fit,fdt-list = ...
> >>> #else
> >>>
> >>> #endif
> >>
> >> As I wrote already, I have a solution for that by using a template dtsi.
> >>
> >>>
> >>> There is no need to specify the properties all at once. You can update
> >>> a property later on just by referring to its node as above.
> >>
> >> Does not help when the anchor name needs to vary as well. That's where I
> >> will use a #define to customize the template on include.
> >>
> >>>
> >>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
> >>> and all the #define stuff.
> >>
> >> You still didn't address my question. Should I share my version to make
> >> the problem clearer? But I thought I explained this in various shades
> >> already.
> >
> > Yes, if I am looking at the wrong patches, please point me to the
> > correct series, or push a tree somewhere.
> >
>
> Please have a look at
> https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e

OK that looks a lot better to me. We can go with that until we come up
with something better.

There has been a long-standing request to support common parts of images.

I am thinking something like this:

common_part: common-part {
template;   //

Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

2023-06-20 Thread Ilias Apalodimas

Sorry for being late to the party,

+cc Jose who maintains DEN0118

On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote:
> Hi Michal,
>
> On Mon, 19 Jun 2023 at 10:02, Michal Simek  wrote:
> >
> > Hi Jassi,
> >
> > On 5/31/23 07:28, jaswinder.si...@linaro.org wrote:
> > > From: Jassi Brar 
> > >
> > > Introduce support for mtd backed storage for FWU feature and enable it on
> > > Synquacer platform based DeveloperBox.
> > >
> > > This revision is rebased onto patchset that trims the FWU api
> > >   
> > > https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/
> > >
> .
>
> > Firstly I can generate 2 images per one bank which should be pretty much 
> > regular
> > capsule update for 2 images. I would expect this should still work.
> >
> > And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() 
> > generated
> > this description for DFU
> >
> > mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000 nor0=bank0 raw
> > 23a 400;bank1 raw 282 400
> >
> > If you look at size in second entry you will see that it is 8000 instead of
> > 8 because it is the same image. That's why curious if you have tested 
> > any
> > scenario like this.
> >
> I had, and have, strong doubts about the practicality of 2
> images/bank. There aren't enough specification details to explain how
> only 1-out-of-N images could be updated. And if we always update all
> images in a bank together, we might as well have them as one composite
> image. I never got satisfactory clarification from designers and
> implementers. So, sorry, I can't defend that scenario with my limited
> knowledge.

This is intentionally left out, as we consider it a platform policy.
For example you could update a single bank and copy over the remaining
firmware images from a different ban. There's nothing on the spec that
prohibits you from doing so, but I personally think it's a bad idea.
Keep in mind there's a document hosted here[0] which explains the update
flow and documents what we have as code in U-Boot.

As far as individual firmware components go now,  do you have any useful
usecase?  The general guidance of [0] is construct a firmware
image, only update the components you want while leaving the rest on the
same revisions and update the entire firmware.  The reason is that firmware

Updating a single image of another bank is not as easy as it sounds.
Firmware components nowadays, whether we like it or not, depend on each other.
Since firmware updates are not so often and fast,  we didn't see any gains from
over complicating the spec and explicitly describe that case, while dealing
with firmware component compatibility at the same time.

>
> > Next part which I want to take a look is practicality of 
> > CONFIG_FWU_NUM_BANKS
> > and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing number 
> > of
> > banks and images for every platform and prevent creating one u-boot which 
> > works
> > on different boards and just use information from mdata.
> > DEN0118 doesn't show any field with this information but do you think that 
> > would
> > be possible to extract that information from there based on for example 
> > reserved
> > or accepted field?
> >
> Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in
> 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we
> use any bit, we'll be in violation of the spec.

Yes this is unfortunate.  We did have similar concerns on when drafting the
spec,  however we never had a solid usecase to justify this.  Arm and
Linaro and working on a v2 (which we try to make compatible with v1) which
addresses this shortcoming.  Maybe Jose can chime in.

>
> However, we can do CRC32 calculations by varying NUM_IMAGES_PER_BANK
> and NUM_BANKS and find the value pair for which the crc32 field
> matches!
> For limiting check-loops and finding corrupted metadata, the .config
> can carry upper limits on both the options, say
> MAX_NUM_IMAGES_PER_BANK=5 and MAX_NUM_BANKS=10 for the most special
> scenario. If we find the approach acceptable, I can cook a patch as
> proof-of-concept.
>
> cheers.

[0] 
https://gitlab.com/Linaro/trustedsubstrate/mbfw/uploads/3d0d7d11ca9874dc9115616b418aa330/mbfw.pdf

Thanks
/Ilias

Re: [BUG] bind command leads to invalid state where plaform data is NULL

2023-06-20 Thread Simon Glass

Hi Heinrich,

On Mon, 19 Jun 2023 at 18:51, Heinrich Schuchardt  wrote:
>
> On 6/19/23 14:57, Simon Glass wrote:
> > I suggest a simple device that needs no setup. The original commit[1]
> > suggests using USB - does that worK?
> >
> > Regards,
> > Simon
> >
> > [1] 49c752c93a78 ("cmd: Add bind/unbind commands to bind a device to a
> > driver from the command line")
>
> I see devices listed after bind but I do not see any device that could
> be used after binding it with the bind command.

It might be worth asking the author. If there is any
parent/uclass/device priv/plat then it won't be set up by this
command.

>
> Here is another instance where using the bind command leads to a crash
> (on pine64-lts_defconfig).
>
> Another question:
> Is it correct that two devices have the same name?

It shouldn't cause any problems since we don't normally reference
devices by name. But it could be confusing for the user if there are
two children of the same device with the same name.

>
> => dm tree
>   Class Index  Probed  Driver  Name
> --
>   watchdog  0  [ + ]   sunxi_wdt   |   |-- watchdog@1c20ca0
>   sysreset  0  [   ]   wdt_reboot  |   |   `-- watchdog@1c20ca0
> => unbind sysreset 0
> => bind watchdog 0 wdt_reboot
> => reset
> resetting ...
> "Synchronous Abort" handler, esr 0x9604, far 0xea06ea70
> elr: 4a044054 lr : 4a034c94 (reloc)
> elr: bdf8d054 lr : bdf7dc94
> x0 :  x1 : 
> x2 : bdf7dc6c x3 : ea06ea08
> x4 : b9f1ec78 x5 : b9f2cbd0
> x6 : 0072 x7 : b9f1ed30
> x8 : 0040 x9 : fff0
> x10: 0006 x11: 0001869f
> x12: b9f1eec8 x13: b9f1efd0
> x14:  x15: b9f1e79f
> x16: bdf7dc6c x17: 
> x18: b9f28d90 x19: 0001
> x20: 0001 x21: 
> x22: b9f38680 x23: 0001
> x24: bdff4f54 x25: 
> x26: b9f2d2d0 x27: 
> x28:  x29: b9f1ecd0
>
> Code: a8c27bfd d65f03c0 d65f03c0 f943 (f9403463)
>
> The crash is in do_reset().

Looking at the device, it needs plat data and uses it in
wdt_reboot_of_to_plat().

Regards,
Simon

Re: [PATCH] axi: fix a warning

2023-06-20 Thread Simon Glass

On Mon, 19 Jun 2023 at 21:36, Sergei Antonov  wrote:
>
> Fix an enum/integer mismatch encountered in 'sandbox_defconfig' build.
>
> .../u-boot/drivers/axi/axi-emul-uclass.c:16:5: warning: conflicting types for 
> ‘axi_sandbox_get_emul’ due to enum/integer mismatch; have ‘int(struct udevice 
> *, ulong,  enum axi_size_t,  struct udevice **)’ {aka ‘int(struct udevice *, 
> long unsigned int,  enum axi_size_t,  struct udevice **)’} 
> [-Wenum-int-mismatch]
>16 | int axi_sandbox_get_emul(struct udevice *bus, ulong address,
>   | ^~~~
> In file included from .../u-boot/drivers/axi/axi-emul-uclass.c:14:
> .../u-boot/arch/sandbox/include/asm/axi.h:48:5: note: previous declaration of 
> ‘axi_sandbox_get_emul’ with type ‘int(struct udevice *, ulong,  uint,  struct 
> udevice **)’ {aka ‘int(struct udevice *, long unsigned int,  unsigned int,  
> struct udevice **)’}
>48 | int axi_sandbox_get_emul(struct udevice *bus, ulong address, uint 
> length,
>   | ^~~~
>
> Make function declaration match function definition.
>
> Cc: Mario Six 
> Signed-off-by: Sergei Antonov 
> ---
>  arch/sandbox/include/asm/axi.h | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Simon Glass

Hi Xavier,

On Wed, 14 Jun 2023 at 09:40, Xavier Drudis Ferran  wrote:
>
>
> Thanks for explaining, Simon Glass.
>
> Can someone please stop me if I'm splitting hairs or bikeshedding or
> something ? I guess we agree both checking for null or UCLASS_BOOTDEV
> would work right now but we are looking for what's more future-proof.
>
> El Tue, Jun 13, 2023 at 09:12:30PM +0100, Simon Glass deia:
> > Hi Xavier,
> >
> > On Tue, 13 Jun 2023 at 17:04, Xavier Drudis Ferran  
> > wrote:
> > >
> > > El Tue, Jun 13, 2023 at 03:58:22PM +0100, Simon Glass deia:
> > > >
> > > > Yes that's right. So 'usb info' should ignore UCLASS_BOOTDEV devices.
> > >
> > > That's a possibility, yes. It should work until someone adds another
> > > device there for some other purpose.
> > >
> > > > That is better than checking for the NULL pointer.
> > > >
> > >
> > > Why? What's wrong about checking for null ?
> > > Or maybe checking for both not null and  not UCLASS_BOOTDEV ?
> > >
> > > Not that I care too much, just to understand your reasoning.
> >
> > Well, devices may have something attached there, so it may be
> > non-NULL, but point to a different struct from the expected one.
> >
>
> Yes. That is possible. How likely ?
>
> That "there" is dev_get_parent_priv(). If I understand the driver
> model, those devices shouldn't put things there themselves, it should
> be their parent who puts stuff there for them. And the parent should
> be an usb_device->dev (because of the recursive code). So what other
> struct would such a parent put in a child parent_priv_ ? Yes, whatever
> it wants, but I mean, isn't it likely to assume the child would be
> "adopted" with null as parent_priv_ or a "natural child" with a usb_device
> in parent_priv_ ?
>
> I did a very rough search
>
> grep -rIE 'UCLASS_(BLK|BOOTDEV|USB_EMUL)' . |grep -F .id |cut -f1 -d:  |xargs 
> -n 1 grep -l per_child_auto
> ./drivers/usb/emul/usb-emul-uclass.c
>
> Which seems to suggest only UCLASS_USB_EMUL would have parent_priv_,
> and that would be an usb_device, which the current code does not want
> to recurse anyway. (dev_set_parent_priv() is almost never called).
>
> It is also possible that one day a device that is not UCLASS_BLK,
> UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage
> device (just imagine a future system similar to bootstd for firmware
> updates, trust material, etc.). Is it likely to have a struct in
> parent_priv_ that is not a usb_device ?
>
> So which is more likely to survive future changes ?
>
> - checking for parent_priv_ not null and not UCLASS_USB_EMUL
>
> - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not 
> UCLASS_BLK
>   (my patch, overcautious ?)
>
> - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL)
>   (Simon Glass' idea)
>
> - checking for not  UCLASS_BLK and not UCLASS_BOOTDEV and not UCLASS_USB_EMUL
>and parent_priv_ not null

Really the parent_priv thing is a separate issue, a side effect of
something having a UCLASS_USB parent.

The key point here is that we cannot iterate down into a bootdev
device looking for USB devices. So we should use that as the check,
since it is the most direct check.

>
> > >
> > > Or can we check for recursible devices somehow ?
> > > Maybe flag them or something ?
> > >
> > > Why is better to state all devices are recursible except some UCLASSes
> > > (meaning they can have stuff that needs listed in usb info - or
> > > likewise usb tree -) instead of stating that some closed set are
> > > recursible ?
> > >
> >
> > For USB we can have lots of different types of devices as children, so
> > it would be a pain to enumerate them all. At least that's how I see
> > it.
> >
>
> We can have lots of devices as children, but those do get listed
> before the recursive call.  How many of those can have children that
> we have to list too, i.e.  how many of those do we want to recurse
> into ?
>
> I can only think of usb hubs (maybe some node for multifunction
> devices too ???).  Maybe I'm not understanding how U-Boot works with
> USB devices... but it looks like it would be enough to look for
> UCLASS_USB_HUB, then recursive call, else no recursion. I mean instead of
>
> cmd/usb.c : usb_show_tree_graph() :
>
> if ((device_get_uclass_id(  child  ) != UCLASS_USB_EMUL) &&
> (device_get_uclass_id(  child  ) != UCLASS_BOOTDEV) &&
> (device_get_uclass_id(  child  ) != UCLASS_BLK)) {
> usb_show_tree_graph(udev, pre);
> pre[index] = 0;
> }
>
> we could simply have
>
> if (device_get_uclass_id(  dev->dev  ) == UCLASS_USB_HUB) {
> usb_show_tree_graph(udev, pre);
> pre[index] = 0;
> }
>
> (or put the condition directly before the for loop)
>
> Or can we have an UCLASS_USB_EMUL, UCLASS_BLK or UCLASS_BOOTDEV as
> direct child of an UCLASS_USB_HUB ???
>
> Am I opening any cans of worms ?

>From my

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Marek Vasut


On 6/20/23 11:42, Michal Simek wrote:



On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note 
that this

reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop 
executed

at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to 
detect the

USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 
+++--

  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, 
u32 mode)

  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in 
host mode,
+ * XHCI driver will reset the host block. If dwc3 was 
configured for

+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip 
RK3588 , I noticed that you removed the code that resets the PHYs 
in this patch hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with 
Linux. Picking random DWC3 patches and ignoring other fixes will 
turn the whole driver into an unmaintainable mess and make the sync 
that much harder in the future. I spent enormous amount of my spare 
time trying to explain to Xilinx how to do that mostly 
automatically, but that was all ignored or countered with reason 
after reason why this cannot be done, but as far as I can tell, 
nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their 
current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch 
actually helps in my case, just that it breaks something else, and I 
wanted to get more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly 
start unless I add some manual delays here and there, and I am 
trying to see why.


It is not just about dwc3. There are other parts which are ported 
from Linux kernel and are out of sync from Linux kernel for quite a 
long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in 
an automated manner, but chose to

Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Marek Vasut


On 6/20/23 11:17, Xavier Drudis Ferran wrote:

El Mon, Jun 19, 2023 at 11:49:18PM +0200, Marek Vasut deia:

On 6/19/23 12:12, Xavier Drudis Ferran wrote:

It seems the email addresses are being constantly corrupted in each email.
This time the ML address is wrong and missing an e at the end. There is some
e@ nonexistent address which I have to keep removing.



Yes, that's my fault. I'm sorry. I apologize to you and others.  I
resent my mail with the proper address. Please just look for my mail
with the wrong address and delete it from your mail archive to prevent
further such problems. You can reply to the other mail I sent (June
19th), because it has the same content, just with an added
apology. Sorry again.


That's fine


When DISTRO_DEFAULTS is not set, the default environment has
bootcmd=bootflow


That is not right, on $randomboard I picked the bootcmd is something else.



And how default is your default environment for your $randomboard ?


Default, see:
$ git grep CONFIG_BOOTCOMMAND configs/


Almost half the configs/* redefine CONFIG_BOOTCOMMAND (524/1268)

When DISTRO_DEFAULTS is not set, that makes BOOTSTD_BOOTCOMMAND default to y
and the default for BOOTCMD is not "run distro_boootcmd", but "bootflow scan"
or (for sandbox) "bootflow scan -lb". When there's bootcmd at all.

But this is only the default for the default environment. It can be
overriden and the Kconfig is not exactly simple. An extract:

next branch:

arch/Arm/Kconfig:

config ARCH_ROCKCHIP
[...]
imply BOOTSTD_DEFAULTS
[...]


cmd/Kconfig:

config CMD_BOOTFLOW
 bool "bootflow"
 depends on BOOTSTD
 default y
[...]

config CMD_BOOTFLOW_FULL
 bool "bootflow - extract subcommands"
 depends on BOOTSTD_FULL
 default y
[...]

boot/Kconfig:

config BOOT_DEFAULTS
 bool  # Common defaults for standard boot and distroboot
 imply USE_BOOTCOMMAND
[...]

config BOOTSTD
 bool "Standard boot support"
 default y
[...]

config BOOTSTD_FULL
 bool "Enhanced features for standard boot"
 default y if SANDBOX
 [...]


if BOOTSTD
[...]

config BOOTSTD_DEFAULTS
 bool "Select some common defaults for standard boot"
 depends on BOOTSTD
 imply USE_BOOTCOMMAND
 select BOOT_DEFAULTS
 select BOOTMETH_DISTRO
[...]

config BOOTSTD_BOOTCOMMAND
 bool "Use bootstd to boot"
 default y if !DISTRO_DEFAULTS
[...]
[...]
endif
[...]
config DISTRO_DEFAULTS
 bool "Select defaults suitable for booting general purpose Linux 
distributions"
 select BOOT_DEFAULTS
[...]

config BOOTCOMMAND
 string "bootcmd value"
 depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE
 default "bootflow scan -lb" if BOOTSTD_DEFAULTS && CMD_BOOTFLOW_FULL
 default "bootflow scan" if BOOTSTD_DEFAULTS && !CMD_BOOTFLOW_FULL
 default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && DISTRO_DEFAULTS


Does this happen if you set empty bootcmd ('=> setenv bootcmd 'echo hello'
for example), then 'saveenv' , then 'reset' , then drop into U-Boot shell
and run 'usb reset ; usb info' too ?



I haven't tested it. If bootflow scan is not run it might not happen.


So, what is the minimal test case ?
I have been asking for that for a while.


Someone has to hang the UCLASS_BOOTDEV on the usb mass storage device,
for it to fail. But as far as I know the idea is to make bootflow the
default in more and more cases. You'll always be able to avoid it
running in your board by setting your own environment at runtime or
changing the configuration, yes, but what's the point ?

I thought that failing one scenario was enough to fix things.  When
one finds a bug it tries to help others to reproduce it.  When others
help the bug finder to run other scenarios that don't have the bug,
what's that useful for ?

Note that it won't fail if the boot succeeds, because then you won't
have a shell to run usb info/tree. It won't fail if usb is not in
boot_targets. It won't fail if there's no mass storage device
connected to usb when bootflow scan is run...

But I still think the failing case is worth fixing. Someone may be
wondering why bootflow fails, run usb info and find a reset, when
setting up a new board, or trying to boot from the wrong usb stick
after the system partition has been corrupted, or whatever. It's not
something that breaks any board in production, but it's not something
to leave forever broken. In theory a null pointer dereference might be
used by some attacker, but in this case I don't really see any useful
attack, maybe it's my lack of imagination. So I'm not claiming it's a
severe bug. It's just a normal bug that needs fixing when possible.

Or are you trying to hint that the solution shouldn't be changing
cmd/usb.c but cleaning up the UCLASS_BOOTDEVs after bootflow scan
somehow ?


I would really like a minimal test

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Michal Simek





On 6/20/23 11:23, Marek Vasut wrote:

On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 +++--
  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in host mode,
+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I 
noticed that you removed the code that resets the PHYs in this patch hence 
DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with Linux. 
Picking random DWC3 patches and ignoring other fixes will turn the whole 
driver into an unmaintainable mess and make the sync that much harder in the 
future. I spent enormous amount of my spare time trying to explain to Xilinx 
how to do that mostly automatically, but that was all ignored or countered 
with reason after reason why this cannot be done, but as far as I can tell, 
nobody in Xilinx actually tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch actually 
helps in my case, just that it breaks something else, and I wanted to get 
more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start unless 
I add some manual delays here and there, and I am trying to see why.


It is not just about dwc3. There are other parts which are ported from Linux 
kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in an 
automated manner, but chose to ignore all input and be unhelpful. Too bad.


It is

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Marek Vasut


On 6/20/23 09:03, Xavier Drudis Ferran wrote:

El Tue, Jun 20, 2023 at 02:50:48AM +0200, Marek Vasut deia:

On 6/13/23 08:52, Xavier Drudis Ferran wrote:


U-Boot TPL 2023.07-rc2-00144-g497967f1ee (Jun 12 2023 - 11:15:47)


Next is already at rc4 , what's this rc2 ?


It's a test I did last week (June 12th). What do you think has changed
in next between rc2 and rc4 so that this shouldn't happen now ?


The beginning of the email states:

"
Ok. New test.

This uses yesterday morning's   next   branch.
commit 5b589e139620214f
"

So, that is not the case ?

Also, commit 497967f1ee does not exist in upstream U-Boot, was this some 
patched U-Boot tree ?



My last patch (sent yesterday) was tested with the next branch as of
yesterday morning. But you can test it yourself with any version you like.
Do I have to send the logs of each test I do to the list every time ?


Ideally the claims you make about what you tested and logs from the test 
should match, that would be a good starting point.



I thought Simon Glass reply last week to the mail you quoted already
showed agreement that the issue exists, and the adding of the
UCLASS_BOOTDEV device is per design, so cmd/usb.c needs fixing to deal
with this change.


I am not disputing that. What bothers me is the still missing consistent 
test case, esp. if this is a fix which should be added this late in release.

Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence

2023-06-20 Thread Marek Vasut


On 6/20/23 08:36, Michal Simek wrote:



On 6/19/23 19:04, Eugen Hristev wrote:

On 6/19/23 19:07, Marek Vasut wrote:

On 6/19/23 15:26, Eugen Hristev wrote:

On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:

[ Felipe: Ported from Linux kernel commit
  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]

According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if necessary. Note 
that this

reduces amount of time spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop 
executed

at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/usb/dwc3/core.c | 50 
+++--

  1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 
mode)

  static int dwc3_core_soft_reset(struct dwc3 *dwc)
  {
  u32    reg;
+    int    retries = 1000;
-    /* Before Resetting PHY, put Core in Reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg |= DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-    /* Assert USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Assert USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
-    mdelay(100);
-
-    /* Clear USB3 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-    reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-    /* Clear USB2 PHY reset */
-    reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-    reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-    dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+    /*
+ * We're resetting only the device side because, if we're in 
host mode,
+ * XHCI driver will reset the host block. If dwc3 was 
configured for

+ * host-only mode, then we can return early.
+ */
+    if (dwc->dr_mode == USB_DR_MODE_HOST)
+    return 0;
-    mdelay(100);
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    reg |= DWC3_DCTL_CSFTRST;
+    dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-    /* After PHYs are stable we can take Core out of reset state */
-    reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-    reg &= ~DWC3_GCTL_CORESOFTRESET;
-    dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+    do {
+    reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+    if (!(reg & DWC3_DCTL_CSFTRST))
+    return 0;
+    udelay(1);
+    } while (--retries);
-    return 0;
+    return -ETIMEDOUT;
  }
  /*


Hello Venkatesh, Michal,

I randomly found this patch while testing the Dwc3 on rockchip 
RK3588 , I noticed that you removed the code that resets the PHYs in 
this patch hence DWC3 is no longer starting in my case.

Was this intentional with this patch ?


All of these patches are NAK until the DWC3 is synchronized with 
Linux. Picking random DWC3 patches and ignoring other fixes will turn 
the whole driver into an unmaintainable mess and make the sync that 
much harder in the future. I spent enormous amount of my spare time 
trying to explain to Xilinx how to do that mostly automatically, but 
that was all ignored or countered with reason after reason why this 
cannot be done, but as far as I can tell, nobody in Xilinx actually 
tried the proposal.


Hence, NAK

Hence, no need to worry these patches will be applied in their 
current state.


Hi Marek,

that's fine. No argument from my side.

What I wanted to actually tell/ask , is the fact that this patch 
actually helps in my case, just that it breaks something else, and I 
wanted to get more info from the patch authors.


I am experiencing some situations where dwc3 does not correctly start 
unless I add some manual delays here and there, and I am trying to see 
why.


It is not just about dwc3. There are other parts which are ported from 
Linux kernel and are out of sync from Linux kernel for quite a long time.

Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.


AMD/Xilinx had the opportunity and means to fix that worry, mostly in an 
automated manner, but chose to ignore all input and be unhelpful. Too bad.

Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

2023-06-20 Thread Xavier Drudis Ferran

El Mon, Jun 19, 2023 at 11:49:18PM +0200, Marek Vasut deia:
> On 6/19/23 12:12, Xavier Drudis Ferran wrote:
> 
> It seems the email addresses are being constantly corrupted in each email.
> This time the ML address is wrong and missing an e at the end. There is some
> e@ nonexistent address which I have to keep removing.
>

Yes, that's my fault. I'm sorry. I apologize to you and others.  I
resent my mail with the proper address. Please just look for my mail
with the wrong address and delete it from your mail archive to prevent
further such problems. You can reply to the other mail I sent (June
19th), because it has the same content, just with an added
apology. Sorry again.

> > When DISTRO_DEFAULTS is not set, the default environment has
> > bootcmd=bootflow
> 
> That is not right, on $randomboard I picked the bootcmd is something else.
>

And how default is your default environment for your $randomboard ?

Almost half the configs/* redefine CONFIG_BOOTCOMMAND (524/1268)

When DISTRO_DEFAULTS is not set, that makes BOOTSTD_BOOTCOMMAND default to y
and the default for BOOTCMD is not "run distro_boootcmd", but "bootflow scan"
or (for sandbox) "bootflow scan -lb". When there's bootcmd at all.

But this is only the default for the default environment. It can be
overriden and the Kconfig is not exactly simple. An extract:

next branch:

arch/Arm/Kconfig:

config ARCH_ROCKCHIP
[...]
imply BOOTSTD_DEFAULTS
[...]

cmd/Kconfig:

config CMD_BOOTFLOW
bool "bootflow"
depends on BOOTSTD
default y
[...]

config CMD_BOOTFLOW_FULL
bool "bootflow - extract subcommands"
depends on BOOTSTD_FULL
default y
[...]

boot/Kconfig:

config BOOT_DEFAULTS
bool  # Common defaults for standard boot and distroboot
imply USE_BOOTCOMMAND
[...]

config BOOTSTD
bool "Standard boot support"
default y
[...]

config BOOTSTD_FULL
bool "Enhanced features for standard boot"
default y if SANDBOX
[...]

if BOOTSTD
[...]

config BOOTSTD_DEFAULTS
bool "Select some common defaults for standard boot"
depends on BOOTSTD
imply USE_BOOTCOMMAND
select BOOT_DEFAULTS
select BOOTMETH_DISTRO
[...]

config BOOTSTD_BOOTCOMMAND
bool "Use bootstd to boot"
default y if !DISTRO_DEFAULTS
[...]
[...]
endif
[...]
config DISTRO_DEFAULTS
bool "Select defaults suitable for booting general purpose Linux 
distributions"
select BOOT_DEFAULTS
[...]

config BOOTCOMMAND
string "bootcmd value"
depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE
default "bootflow scan -lb" if BOOTSTD_DEFAULTS && CMD_BOOTFLOW_FULL
default "bootflow scan" if BOOTSTD_DEFAULTS && !CMD_BOOTFLOW_FULL
default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && DISTRO_DEFAULTS
> 
> Does this happen if you set empty bootcmd ('=> setenv bootcmd 'echo hello'
> for example), then 'saveenv' , then 'reset' , then drop into U-Boot shell
> and run 'usb reset ; usb info' too ?
>

I haven't tested it. If bootflow scan is not run it might not happen.
Someone has to hang the UCLASS_BOOTDEV on the usb mass storage device,
for it to fail. But as far as I know the idea is to make bootflow the
default in more and more cases. You'll always be able to avoid it
running in your board by setting your own environment at runtime or
changing the configuration, yes, but what's the point ?

I thought that failing one scenario was enough to fix things.  When
one finds a bug it tries to help others to reproduce it.  When others
help the bug finder to run other scenarios that don't have the bug,
what's that useful for ?

Note that it won't fail if the boot succeeds, because then you won't
have a shell to run usb info/tree. It won't fail if usb is not in
boot_targets. It won't fail if there's no mass storage device
connected to usb when bootflow scan is run...

But I still think the failing case is worth fixing. Someone may be
wondering why bootflow fails, run usb info and find a reset, when
setting up a new board, or trying to boot from the wrong usb stick
after the system partition has been corrupted, or whatever. It's not
something that breaks any board in production, but it's not something
to leave forever broken. In theory a null pointer dereference might be
used by some attacker, but in this case I don't really see any useful
attack, maybe it's my lack of imagination. So I'm not claiming it's a
severe bug. It's just a normal bug that needs fixing when possible.

Or are you trying to hint that the solution shouldn't be changing
cmd/usb.c but cleaning up the UCLASS_BOOTDEVs after bootflow scan
somehow ?

Or I should change the commit message because the point is not so much
what's the default environment or the default default environment, but
simply that bootflow scan is run with an usb mass storage device
connected and no boot content

[PATCH v2 19/19] x86: coral: Adjust various config options

2023-06-20 Thread Simon Glass

Add ms so it is easier to search for tables in memory.

Expand the command-line and print buffers so that we can deal with the
very long ChromeOS command lines. (typically 700 characters).

Enable BOOTSTD_FULL to get the full set of standard-boot options.

Replace the existing manual script with 'bootflow scan', since it can
find and boot the OS.

Finally, expand the malloc() space so we can read large kernels into a
bootflow.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Drop mention of NVMe support

 configs/chromebook_coral_defconfig | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/configs/chromebook_coral_defconfig 
b/configs/chromebook_coral_defconfig
index f5995f22004e..fe61153b93d8 100644
--- a/configs/chromebook_coral_defconfig
+++ b/configs/chromebook_coral_defconfig
@@ -1,5 +1,6 @@
 CONFIG_X86=y
 CONFIG_TEXT_BASE=0x111
+CONFIG_SYS_MALLOC_LEN=0x200
 CONFIG_SYS_MALLOC_F_LEN=0x3d00
 CONFIG_NR_DRAM_BANKS=8
 CONFIG_MAX_CPUS=8
@@ -22,6 +23,7 @@ CONFIG_X86_OFFSET_U_BOOT=0xffd0
 CONFIG_X86_OFFSET_SPL=0xffe8
 CONFIG_INTEL_ACPIGEN=y
 CONFIG_INTEL_GENERIC_WIFI=y
+CONFIG_BOOTSTD_FULL=y
 CONFIG_SYS_MONITOR_BASE=0x0111
 CONFIG_CHROMEOS=y
 CONFIG_BOOTSTAGE=y
@@ -33,8 +35,10 @@ CONFIG_BOOTSTAGE_STASH=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS_SUBST=y
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; read mmc 0:2 10 0 
80; setexpr loader *001004f0; setexpr size *00100518; setexpr blocks $size / 
200; read mmc 0:2 10 80 $blocks; setexpr setup $loader - 1000; setexpr 
cmdline_ptr $loader - 2000; setexpr.s cmdline *$cmdline_ptr; setexpr cmdline 
gsub %U ${uuid}; if part uuid mmc 0:2 uuid; then zboot start 10 0 0 0 
$setup cmdline; zboot load; zboot setup; zboot dump; zboot go;fi"
+CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; bootflow scan -lb"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_LOG=y
+CONFIG_LOGF_FUNC=y
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_LAST_STAGE_INIT=y
 CONFIG_BLOBLIST=y
@@ -52,9 +56,11 @@ CONFIG_SPL_POWER=y
 CONFIG_TPL_SYS_MALLOC_SIMPLE=y
 CONFIG_TPL_POWER=y
 CONFIG_HUSH_PARSER=y
-CONFIG_SYS_PBSIZE=532
+CONFIG_SYS_CBSIZE=1024
+CONFIG_SYS_PBSIZE=1024
 CONFIG_CMD_CPU=y
 CONFIG_CMD_PMC=y
+CONFIG_CMD_MEM_SEARCH=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_PART=y
-- 
2.41.0.162.gfafddb0af9-goog

[PATCH v2 18/19] x86: coreboot: Adjust various config options

2023-06-20 Thread Simon Glass

Drop IDE since this is not widely used anymore. Add NVME since it is
becoming more popular.

Add ms so it is easier to search for tables in memory.

Expand the command-line and print buffers so that we can deal with the
very long ChromeOS command lines. (typically 700 characters).

Enable BOOTSTD_FULL to get the full set up standard-boot options.

Finally, expand the malloc() space so we can read large kernels into a
bootflow.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 configs/coreboot_defconfig | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig
index 058caf008f9a..e650fca572f9 100644
--- a/configs/coreboot_defconfig
+++ b/configs/coreboot_defconfig
@@ -1,5 +1,6 @@
 CONFIG_X86=y
 CONFIG_TEXT_BASE=0x111
+CONFIG_SYS_MALLOC_LEN=0x200
 CONFIG_NR_DRAM_BANKS=8
 CONFIG_ENV_SIZE=0x1000
 CONFIG_DEFAULT_DEVICE_TREE="coreboot"
@@ -8,12 +9,11 @@ CONFIG_VENDOR_COREBOOT=y
 CONFIG_TARGET_COREBOOT=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
+CONFIG_BOOTSTD_FULL=y
 CONFIG_SYS_MONITOR_BASE=0x0111
 CONFIG_SHOW_BOOT_PROGRESS=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100"
 CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_LOG=y
@@ -23,9 +23,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_LAST_STAGE_INIT=y
 CONFIG_PCI_INIT_R=y
 CONFIG_HUSH_PARSER=y
-CONFIG_SYS_PBSIZE=532
-CONFIG_CMD_MEM_SEARCH=y
-CONFIG_CMD_IDE=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
 CONFIG_CMD_USB=y
@@ -53,13 +50,8 @@ CONFIG_USE_ROOTPATH=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 # CONFIG_ACPIGEN is not set
-CONFIG_SYS_IDE_MAXDEVICE=4
-CONFIG_SYS_ATA_DATA_OFFSET=0
-CONFIG_SYS_ATA_REG_OFFSET=0
-CONFIG_SYS_ATA_ALT_OFFSET=0
-CONFIG_ATAPI=y
-CONFIG_LBA48=y
-CONFIG_SYS_64BIT_LBA=y
+CONFIG_MISC=y
+CONFIG_NVMEM=y
 CONFIG_NVME_PCI=y
 # CONFIG_PCI_PNP is not set
 CONFIG_SOUND=y
-- 
2.41.0.162.gfafddb0af9-goog

[PATCH v2 17/19] bootstd: Add a simple bootmeth for ChromiumOS

2023-06-20 Thread Simon Glass

It is possible to boot x86-based ChromeOS machines by parsing a table and
locating the kernel and command line. Add a bootmeth for this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 boot/Kconfig |  11 ++
 boot/Makefile|   1 +
 boot/bootmeth_cros.c | 212 +++
 configs/tools-only_defconfig |   1 +
 4 files changed, 225 insertions(+)
 create mode 100644 boot/bootmeth_cros.c

diff --git a/boot/Kconfig b/boot/Kconfig
index eea5ed6040ff..98eb2ca94c8e 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -463,6 +463,17 @@ config BOOTMETH_GLOBAL
  EFI bootmgr, since they take full control over which bootdevs are
  selected to boot.
 
+config BOOTMETH_CROS
+   bool "Bootdev support for Chromium OS"
+   depends on X86 || SANDBOX
+   default y
+   help
+ Enables support for booting Chromium OS using bootdevs. This uses the
+ kernel A slot and obtains the kernel command line from the parameters
+ provided there.
+
+ Note that only x86 devices are supported at present.
+
 config BOOTMETH_EXTLINUX
bool "Bootdev support for extlinux boot"
select PXE_UTILS
diff --git a/boot/Makefile b/boot/Makefile
index f94c31d922de..6e4cdbd4ce28 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootstd-uclass.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EXTLINUX) += bootmeth_extlinux.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EXTLINUX_PXE) += bootmeth_pxe.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o
+obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_CROS) += bootmeth_cros.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o
 ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
new file mode 100644
index ..aa19ae097f56
--- /dev/null
+++ b/boot/bootmeth_cros.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootmethod for ChromiumOS
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass 
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_X86
+#include 
+#endif
+#include 
+
+enum {
+   /* Offsets in the kernel-partition header */
+   KERN_START  = 0x4f0,
+   KERN_SIZE   = 0x518,
+
+   SETUP_OFFSET= 0x1000,   /* bytes before base */
+   CMDLINE_OFFSET  = 0x2000,   /* bytes before base */
+   OFFSET_BASE = 0x10, /* assumed kernel load-address */
+};
+
+static int cros_check(struct udevice *dev, struct bootflow_iter *iter)
+{
+   /* This only works on block and network devices */
+   if (bootflow_iter_check_blk(iter))
+   return log_msg_ret("blk", -ENOTSUPP);
+
+   return 0;
+}
+
+static int copy_cmdline(const char *from, const char *uuid, char **bufp)
+{
+   const int maxlen = 2048;
+   char buf[maxlen];
+   char *cmd, *to, *end;
+   int len;
+
+   /* Allow space for cmdline + UUID */
+   len = strnlen(from, sizeof(buf));
+   if (len >= maxlen)
+   return -E2BIG;
+
+   log_debug("uuid %d %s\n", uuid ? (int)strlen(uuid) : 0, uuid);
+   for (to = buf, end = buf + maxlen - UUID_STR_LEN - 1; *from; from++) {
+   if (to >= end)
+   return -E2BIG;
+   if (from[0] == '%' && from[1] == 'U' && uuid &&
+   strlen(uuid) == UUID_STR_LEN) {
+   strcpy(to, uuid);
+   to += UUID_STR_LEN;
+   from++;
+   } else {
+   *to++ = *from;
+   }
+   }
+   *to = '\0';
+   len = to - buf;
+   cmd = strdup(buf);
+   if (!cmd)
+   return -ENOMEM;
+   free(*bufp);
+   *bufp = cmd;
+
+   return 0;
+}
+
+static int cros_read_bootflow(struct udevice *dev, struct bootflow *bflow)
+{
+   struct blk_desc *desc = dev_get_uclass_plat(bflow->blk);
+   ulong base, start, size, setup, cmdline, num_blks, kern_base;
+   struct disk_partition info;
+   const char *uuid = NULL;
+   void *buf, *hdr;
+   int ret;
+
+   log_debug("starting, part=%d\n", bflow->part);
+
+   /* We consider the whole disk, not any one partition */
+   if (bflow->part)
+   return log_msg_ret("max", -ENOENT);
+
+   /* Check partition 2 */
+   ret = part_get_info(desc, 2, );
+   if (ret)
+   return log_msg_ret("part", ret);
+
+   /* Make a buffer for the header information */
+   num_blks = SZ_4K >> desc->log2blksz;
+   log_debug("Reading header, blk=%s, start=%lx, blocks=%lx\n",
+ bflow->blk->name, (ulong)info.start, num_blks);
+   hdr = memalign(SZ_1K, SZ_4K);
+   if (!hdr)
+   return

[PATCH v2 14/19] bootstd: Support automatically setting Linux parameters

2023-06-20 Thread Simon Glass

Some Linux parameters can be set automatically by U-Boot, if it knows the
device being used. For example, since U-Boot knows the serial console
being used, it can add parameters for earlycon and console.

Add support for this.

Note that this is an experimental feature and we will see how useful it
turns out to be. It is very handy for ChromeOS, since otherwise it is very
difficult to manually determine the UART address or port number,
particularly in a script.

Provide an example of how this is used with ChromeOS.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 boot/bootflow.c| 33 +
 cmd/bootflow.c |  5 ++-
 doc/usage/cmd/bootflow.rst | 75 +-
 include/bootflow.h | 12 ++
 4 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/boot/bootflow.c b/boot/bootflow.c
index 8c649e8e66ca..81b5829d5b37 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -854,3 +855,35 @@ int bootflow_cmdline_get_arg(struct bootflow *bflow, const 
char *arg,
 
return ret;
 }
+
+int bootflow_cmdline_auto(struct bootflow *bflow, const char *arg)
+{
+   struct serial_device_info info;
+   char buf[50];
+   int ret;
+
+   ret = serial_getinfo(gd->cur_serial_dev, );
+   if (ret)
+   return ret;
+
+   *buf = '\0';
+   if (!strcmp("earlycon", arg)) {
+   snprintf(buf, sizeof(buf),
+"uart8250,mmio32,%#lx,%dn8", info.addr,
+info.baudrate);
+   } else if (!strcmp("console", arg)) {
+   snprintf(buf, sizeof(buf),
+"ttyS0,%dn8", info.baudrate);
+   }
+
+   if (!*buf) {
+   printf("Unknown param '%s\n", arg);
+   return -ENOENT;
+   }
+
+   ret = bootflow_cmdline_set_arg(bflow, arg, buf, true);
+   if (ret)
+   return ret;
+
+   return 0;
+}
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index ab00e4a19e14..c0aa4f84fe8d 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -474,6 +474,9 @@ static int do_bootflow_cmdline(struct cmd_tbl *cmdtp, int 
flag, int argc,
if (ret >= 0)
printf("%.*s\n", ret, val);
break;
+   case 'a':   /* auto */
+   ret = bootflow_cmdline_auto(bflow, arg);
+   break;
}
switch (ret) {
case -E2BIG:
@@ -508,7 +511,7 @@ static char bootflow_help_text[] =
"bootflow info [-d] - show info on current bootflow (-d 
dump bootflow)\n"
"bootflow boot  - boot current bootflow (or first 
available if none selected)\n"
"bootflow menu [-t] - show a menu of available bootflows\n"
-   "bootflow cmdline [set|get|clear|delete]  [] - update 
cmdline";
+   "bootflow cmdline [set|get|clear|delete|auto]  [] - 
update cmdline";
 #else
"scan - boot first available bootflow\n";
 #endif
diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst
index 07af789e6702..a8af1f8f6030 100644
--- a/doc/usage/cmd/bootflow.rst
+++ b/doc/usage/cmd/bootflow.rst
@@ -13,7 +13,7 @@ Synopis
 bootflow select []
 bootflow info [-d]
 bootflow boot
-bootflow cmdline [set|get|clear|delete]  []
+bootflow cmdline [set|get|clear|delete|auto]  []
 
 Description
 ---
@@ -218,6 +218,16 @@ To delete a parameter entirely, use::
 
 bootflow cmdline delete 
 
+Automatic parameters are available in a very few cases. You can use these to
+add parmeters where the value is known by U-Boot. For example::
+
+bootflow cmdline auto earlycon
+bootflow cmdline auto console
+
+can be used to set the early console (or console) to a suitable value so that
+output appears on the serial port. This is only supported by the 16550 serial
+driver so far.
+
 Example
 ---
 
@@ -450,6 +460,69 @@ Here is am example using the -e flag to see all errors::
 (21 bootflows, 2 valid)
 U-Boot>
 
+Here is an example of booting ChromeOS, adjusting the console beforehand. Note 
that
+the cmdline is word-wrapped here and some parts of the command line are 
elided::
+
+=> bootfl list
+Showing all bootflows
+Seq  Method   State   UclassPart  Name  
Filename
+---  ---  --        

+0  cros ready   nvme 0  5.10.153-20434-g98da1eb2c 
+1  efi  ready   nvme c  nvme#0.blk#1.bootdev.part 
efi/boot/bootia32.efi
+2  efi  ready   usb_mass_2  usb_mass_storage.lun0.boo 
efi/boot/bootia32.efi
+---  ---  --        

+(3 bootflows, 3 valid)
+=> bootfl sel 0
+=> bootfl inf
+Name:  5.10.153-20434-g98da1eb2cf9d

[PATCH v2 16/19] x86: zimage: Export the function to obtain the cmdline

2023-06-20 Thread Simon Glass

Allow reading the command line from a zimage, so that it can be recorded
in the bootflow.

Reviewed-by: Bin Meng 
Signed-off-by: Simon Glass 
---

(no changes since v1)

 arch/x86/include/asm/zimage.h | 10 ++
 arch/x86/lib/zimage.c | 11 ---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 966d7224eb18..9ad74dc0b946 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -89,4 +89,14 @@ void zimage_dump(struct boot_params *base_ptr);
 int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
ulong base, char *cmdline);
 
+/*
+ * zimage_get_kernel_version() - Get the version string from a kernel
+ *
+ * @params: boot_params pointer
+ * @kernel_base: base address of kernel
+ * Return: Kernel version as a NUL-terminated string
+ */
+const char *zimage_get_kernel_version(struct boot_params *params,
+ void *kernel_base);
+
 #endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 540d4d888bc7..062e3d3e3151 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -181,7 +181,7 @@ static int setup_device_tree(struct setup_header *hdr, 
const void *fdt_blob)
return 0;
 }
 
-static const char *get_kernel_version(struct boot_params *params,
+const char *zimage_get_kernel_version(struct boot_params *params,
  void *kernel_base)
 {
struct setup_header *hdr = >hdr;
@@ -189,10 +189,14 @@ static const char *get_kernel_version(struct boot_params 
*params,
const char *s, *end;
 
bootproto = get_boot_protocol(hdr, false);
+   log_debug("bootproto %x, hdr->setup_sects %x\n", bootproto,
+ hdr->setup_sects);
if (bootproto < 0x0200 || hdr->setup_sects < 15)
return NULL;
 
/* sanity-check the kernel version in case it is missing */
+   log_debug("hdr->kernel_version %x, str at %p\n", hdr->kernel_version,
+ kernel_base + hdr->kernel_version + 0x200);
for (s = kernel_base + hdr->kernel_version + 0x200, end = s + 0x100; *s;
 s++) {
if (!isprint(*s))
@@ -239,7 +243,7 @@ struct boot_params *load_zimage(char *image, unsigned long 
kernel_size,
log_debug("Using boot protocol version %x.%02x\n",
  (bootproto & 0xff00) >> 8, bootproto & 0xff);
 
-   version = get_kernel_version(params, image);
+   version = zimage_get_kernel_version(params, image);
if (version)
printf("Linux kernel version %s\n", version);
else
@@ -728,7 +732,8 @@ void zimage_dump(struct boot_params *base_ptr)
print_num("Real mode switch", hdr->realmode_swtch);
print_num("Start sys seg", hdr->start_sys_seg);
print_num("Kernel version", hdr->kernel_version);
-   version = get_kernel_version(base_ptr, (void *)state.bzimage_addr);
+   version = zimage_get_kernel_version(base_ptr,
+   (void *)state.bzimage_addr);
if (version)
printf("   @%p: %s\n", version, version);
print_num("Type of loader", hdr->type_of_loader);
-- 
2.41.0.162.gfafddb0af9-goog

[PATCH v2 15/19] x86: Add a function to boot a zimage

2023-06-20 Thread Simon Glass

Add a direct interface to booting a zimage, so that bootstd can call it
without going through the command-line interface.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 arch/x86/include/asm/zimage.h | 17 
 arch/x86/lib/zimage.c | 82 ++-
 2 files changed, 88 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 000b38ea8993..966d7224eb18 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -72,4 +72,21 @@ int setup_zimage(struct boot_params *setup_base, char 
*cmd_line, int auto_boot,
  */
 void zimage_dump(struct boot_params *base_ptr);
 
+/**
+ * zboot_start() - Boot a zimage
+ *
+ * Boot a zimage, given the component parts
+ *
+ * @addr: Address where the bzImage is moved before booting, either
+ * BZIMAGE_LOAD_ADDR or ZIMAGE_LOAD_ADDR
+ * @base: Pointer to the boot parameters, typically at address
+ * DEFAULT_SETUP_BASE
+ * @initrd: Address of the initial ramdisk, or 0 if none
+ * @initrd_size: Size of the initial ramdisk, or 0 if none
+ * @cmdline: Command line to use for booting
+ * Return: -EFAULT on error (normally it does not return)
+ */
+int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+   ulong base, char *cmdline);
+
 #endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index e5ea5129c1e9..540d4d888bc7 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -442,8 +443,7 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, 
int argc,
return 0;
 }
 
-static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
-char *const argv[])
+static int zboot_load(void)
 {
struct boot_params *base_ptr;
 
@@ -460,31 +460,51 @@ static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, 
int argc,
   _address);
if (!base_ptr) {
puts("## Kernel loading failed ...\n");
-   return CMD_RET_FAILURE;
+   return -EINVAL;
}
}
state.base_ptr = base_ptr;
-   if (env_set_hex("zbootbase", (ulong)base_ptr) ||
+
+   return 0;
+}
+
+static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
+{
+   if (zboot_load())
+   return CMD_RET_FAILURE;
+
+   if (env_set_hex("zbootbase", map_to_sysmem(state.base_ptr)) ||
env_set_hex("zbootaddr", state.load_address))
return CMD_RET_FAILURE;
 
return 0;
 }
 
+static int zboot_setup(void)
+{
+   struct boot_params *base_ptr = state.base_ptr;
+   int ret;
+
+   ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET,
+  0, state.initrd_addr, state.initrd_size,
+  (ulong)state.cmdline);
+   if (ret)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
  char *const argv[])
 {
struct boot_params *base_ptr = state.base_ptr;
-   int ret;
 
if (!base_ptr) {
printf("base is not set: use 'zboot load' first\n");
return CMD_RET_FAILURE;
}
-   ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET,
-  0, state.initrd_addr, state.initrd_size,
-  (ulong)state.cmdline);
-   if (ret) {
+   if (zboot_setup()) {
puts("Setting up boot parameters failed ...\n");
return CMD_RET_FAILURE;
}
@@ -501,8 +521,7 @@ static int do_zboot_info(struct cmd_tbl *cmdtp, int flag, 
int argc,
return 0;
 }
 
-static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
-  char *const argv[])
+static int zboot_go(void)
 {
struct boot_params *params = state.base_ptr;
struct setup_header *hdr = >hdr;
@@ -522,11 +541,52 @@ static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, 
int argc,
 
/* we assume that the kernel is in place */
ret = boot_linux_kernel((ulong)state.base_ptr, entry, image_64bit);
+
+   return ret;
+}
+
+static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[])
+{
+   int ret;
+
+   ret = zboot_go();
printf("Kernel returned! (err=%d)\n", ret);
 
return CMD_RET_FAILURE;
 }
 
+int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+   ulong base, char *cmdline)
+{
+   int ret;
+
+   memset(, '\0', sizeof(state));
+
+   if (base) {
+   state.base_ptr = map_sysmem(base, 0);
+   state.load_address = addr;
+   } else {
+

[PATCH v2 10/19] bootstd: Add a function to update a command line

2023-06-20 Thread Simon Glass

The Linux command line consists of a number of words with optional values.
At present U-Boot allows this to be changed using the bootargs environment
variable.

But this is quite painful, since the command line can be very long.

Add a function which can adjust a single field in the command line, so
that it is easier to make changes before booting.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add comment for copy_in()
- Avoid multiplication on a boolean
- Add a comment as to why @len is needed

 boot/bootflow.c  | 190 +++
 include/bootflow.h   |  40 +
 test/boot/bootflow.c | 154 +++
 3 files changed, 384 insertions(+)

diff --git a/boot/bootflow.c b/boot/bootflow.c
index 62b7f45ab278..26f26aee38a3 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -611,3 +611,193 @@ static int on_bootargs(const char *name, const char 
*value, enum env_op op,
 U_BOOT_ENV_CALLBACK(bootargs, on_bootargs);
 #endif
 
+/**
+ * copy_in() - Copy a string into a cmdline buffer
+ *
+ * @buf: Buffer to copy into
+ * @end: End of buffer (pointer to char after the end)
+ * @arg: String to copy from
+ * @len: Number of chars to copy from @arg (note that this is not usually the
+ * sane as strlen(arg) since the string may contain following arguments)
+ * @new_val: Value to put after arg, or BOOTFLOWCL_EMPTY to use an empty value
+ * with no '=' sign
+ * Returns: Number of chars written to @buf
+ */
+static int copy_in(char *buf, char *end, const char *arg, int len,
+  const char *new_val)
+{
+   char *to = buf;
+
+   /* copy the arg name */
+   if (to + len >= end)
+   return -E2BIG;
+   memcpy(to, arg, len);
+   to += len;
+
+   if (new_val == BOOTFLOWCL_EMPTY) {
+   /* no value */
+   } else {
+   bool need_quote = strchr(new_val, ' ');
+   len = strlen(new_val);
+
+   /* need space for value, equals sign and maybe two quotes */
+   if (to + 1 + (need_quote ? 2 : 0) + len >= end)
+   return -E2BIG;
+   *to++ = '=';
+   if (need_quote)
+   *to++ = '"';
+   memcpy(to, new_val, len);
+   to += len;
+   if (need_quote)
+   *to++ = '"';
+   }
+
+   return to - buf;
+}
+
+int cmdline_set_arg(char *buf, int maxlen, const char *cmdline,
+   const char *set_arg, const char *new_val, int *posp)
+{
+   bool found_arg = false;
+   const char *from;
+   char *to, *end;
+   int set_arg_len;
+   char empty = '\0';
+   int ret;
+
+   from = cmdline ?: 
+
+   /* check if the value has quotes inside */
+   if (new_val && new_val != BOOTFLOWCL_EMPTY && strchr(new_val, '"'))
+   return -EBADF;
+
+   set_arg_len = strlen(set_arg);
+   for (to = buf, end = buf + maxlen; *from;) {
+   const char *val, *arg_end, *val_end, *p;
+   bool in_quote;
+
+   if (to >= end)
+   return -E2BIG;
+   while (*from == ' ')
+   from++;
+   if (!*from)
+   break;
+
+   /* find the end of this arg */
+   val = NULL;
+   arg_end = NULL;
+   val_end = NULL;
+   in_quote = false;
+   for (p = from;; p++) {
+   if (in_quote) {
+   if (!*p)
+   return -EINVAL;
+   if (*p == '"')
+   in_quote = false;
+   continue;
+   }
+   if (*p == '=') {
+   arg_end = p;
+   val = p + 1;
+   } else if (*p == '"') {
+   in_quote = true;
+   } else if (!*p || *p == ' ') {
+   val_end = p;
+   if (!arg_end)
+   arg_end = p;
+   break;
+   }
+   }
+   /*
+* At this point val_end points to the end of the value, or the
+* last char after the arg name, if there is no label.
+* arg_end is the char after the arg name
+* val points to the value, or NULL if there is none
+* char after the value.
+*
+*fred=1234
+*^   ^^   ^
+*  from  ||   |
+*   / \\
+*arg_end  val   val_end
+*/
+   log_debug("from %s arg_end %ld val %ld val_end %ld\n", from,
+ (long)(arg_end -

[PATCH v2 12/19] x86: qemu: Create a little more room for U-Boot

2023-06-20 Thread Simon Glass

We want to enable some of the more interesting bootstd features. Move SPL
up to create some room for the larger U-Boot binary. Also disable
microcode since this is not needed

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add new patch to create a little more room for U-Boot on qemu-x86_64

 configs/qemu-x86_64_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 870332a1e625..45df1e46fa38 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -6,13 +6,14 @@ CONFIG_ENV_SIZE=0x4
 CONFIG_MAX_CPUS=2
 CONFIG_SPL_DM_SPI=y
 CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
-CONFIG_SPL_TEXT_BASE=0xfffd
+CONFIG_SPL_TEXT_BASE=0xfffd8000
 CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000
 CONFIG_DEBUG_UART_BASE=0x3f8
 CONFIG_DEBUG_UART_CLOCK=1843200
 CONFIG_X86_RUN_64BIT=y
 CONFIG_TARGET_QEMU_X86_64=y
 CONFIG_DEBUG_UART=y
+# CONFIG_HAVE_MICROCODE is not set
 CONFIG_SMP=y
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
-- 
2.41.0.162.gfafddb0af9-goog

[PATCH v2 13/19] x86: qemu: Switch to standard boot

2023-06-20 Thread Simon Glass

Drop use of the distro boot script and use standard boot instead.

Moving to a text-based environment would be desirable also, but requires
additional work.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add new patch to switch x86 qemu to standard boot

 configs/qemu-x86_64_defconfig | 2 +-
 configs/qemu-x86_defconfig| 2 +-
 include/configs/qemu-x86.h| 8 
 3 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 45df1e46fa38..3e0970d70e29 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -22,7 +22,7 @@ CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_BOOTSTD_FULL=y
 CONFIG_SYS_MONITOR_BASE=0x0111
-CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SHOW_BOOT_PROGRESS=y
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index fcf429f77115..79ca5cd54c87 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -9,7 +9,7 @@ CONFIG_SMP=y
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
 CONFIG_FIT=y
-CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SHOW_BOOT_PROGRESS=y
diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h
index 33263a46a407..3e5235291a28 100644
--- a/include/configs/qemu-x86.h
+++ b/include/configs/qemu-x86.h
@@ -12,14 +12,6 @@
 
 #include 
 
-#define BOOT_TARGET_DEVICES(func) \
-   func(USB, usb, 0) \
-   func(SCSI, scsi, 0) \
-   func(VIRTIO, virtio, 0) \
-   func(IDE, ide, 0) \
-   func(DHCP, dhcp, na)
-
-#include 
 #include 
 
 #define CFG_STD_DEVICES_SETTINGS   "stdin=serial,i8042-kbd\0" \
-- 
2.41.0.162.gfafddb0af9-goog

1 2 >

1 - 100 of 119 matches

Mail list logo