Re: [PATCH 09/13] doc: board: ti: am64x: Fix build step numbering

[Heinrich Schuchardt]

On 8/22/23 18:41, Nishanth Menon wrote:

Fix up build step numbering.

Fixes: 4bf49bade124 ("doc: board: ti: am64: Add boot flow diagram")
Signed-off-by: Nishanth Menon


This patch is only applicable to the next branch (2024.01).

Reviewed-by: Heinrich Schuchardt 

Re: [PATCH 04/13] doc: board: ti: am64x: provide image alt text

[Heinrich Schuchardt]

On 8/22/23 18:40, Nishanth Menon wrote:

Provide alternative text for image.

Fixes: 4bf49bade124 ("doc: board: ti: am64: Add boot flow diagram")
Reported-by: Heinrich Schuchardt
Signed-off-by: Nishanth Menon


This patch is only applicable to the next branch (2024.01).

Reviewed-by: Heinrich Schuchardt 

Re: [PATCH 2/2] net: phy: Change "PHY not found" message to debug()

[Siddharth Vadapalli]

On 22/08/23 17:43, Roger Quadros wrote:
> Some boards (e.g. Beagleplay) need multiple attempts to detect the PHY
> and the multiple "PHY not found" prints are not nice.

I tried grepping for calls to "phy_connect" across the drivers present in
drivers/net. Most of them simply return -ENODEV on failure. The ones
which add prints indicating failure, don't use debug(). For this reason,
I believe that the drivers which don't have any prints in case of
failure might be relying on the printf() within phy_connect() to indicate
failure. Therefore, if the printf() is being changed to debug() in
phy_connect(), maybe all the drivers which currently return -ENODEV,
should have a print added to them as a part of this patch.

> 
> Change them to debug().
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/net/phy/phy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index ae21acb059..3a524bcd81 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -928,7 +928,7 @@ struct phy_device *phy_connect(struct mii_dev *bus, int 
> addr,
>   if (phydev)
>   phy_connect_dev(phydev, dev, interface);
>   else
> - printf("Could not get PHY for %s: addr %d\n", bus->name, addr);
> + debug("Could not get PHY for %s: addr %d\n", bus->name, addr);
>   return phydev;
>  }
>  

-- 
Regards,
Siddharth.

Re: [PATCH 1/2] net: ti: am65-cpsw-nuss: Workaround for buggy PHY/Board

[Siddharth Vadapalli]

Roger,

On 22/08/23 17:43, Roger Quadros wrote:
> Beagleplay has a buggy Ethernet PHY implementation for the Gigabit
> PHY in the sense that it is non responsive over MDIO immediately
> after power-up/reset.
> 
> We need to either try multiple times or wait sufficiently long enough
> (couple of 10s of ms?) before the PHY begins to respond correctly.

Based on the datasheet at:
https://datasheet.lcsc.com/lcsc/1912111437_Realtek-Semicon-RTL8211F-CG_C187932.pdf
in the section 7.17. PHY Reset (Hardware Reset), it is stated that
software has to wait for at least 50 ms before accessing the PHY
registers. Is this why the for-loop in the code below tries for at most
5 times with a delay of 10 ms before the next try? If yes, then isn't it
better to move the delay into the realtek PHY driver at
drivers/net/phy/realtek.c
Shouldn't it be the PHY driver which ensures that any reads/writes to the PHY
registers are valid? It can ensure this by having a one time 50ms delay for the
very first access to the PHY registers.

> 
> One theory is that the PHY is configured to operate on MDIO address 0
> which it treats as a special broadcast address.
> 
> Datasheet states:
> "PHYAD (config pins) sets the PHY address for the device.
> The RTL8211F(I)/RTL8211FD(I) supports PHY addresses from 0x01 to 0x07.
> Note 1: An MDIO command with PHY address=0 is a broadcast from the MAC;
> each PHY device should respond."
> 
> This issue is not seen with the other PHY (different make) on the board
> which is configured for address 0x1.
> 
> As a woraround we try to probe the PHY multiple times instead of giving
> up on the first attempt.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/net/ti/am65-cpsw-nuss.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 51a8167d14..4f8a2f9b93 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "cpsw_mdio.h"
>  
> @@ -678,14 +679,22 @@ static int am65_cpsw_phy_init(struct udevice *dev)
>   struct am65_cpsw_priv *priv = dev_get_priv(dev);
>   struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
>   struct eth_pdata *pdata = dev_get_plat(dev);
> - struct phy_device *phydev;
>   u32 supported = PHY_GBIT_FEATURES;
> + struct phy_device *phydev;
> + int tries;
>   int ret;
>  
> - phydev = phy_connect(cpsw_common->bus,
> -  priv->phy_addr,
> -  priv->dev,
> -  pdata->phy_interface);
> + /* Some boards (e.g. beagleplay) don't work on first go */
> + for (tries = 1; tries <= 5; tries++) {
> + phydev = phy_connect(cpsw_common->bus,
> +  priv->phy_addr,
> +  priv->dev,
> +  pdata->phy_interface);
> + if (phydev)
> + break;
> +
> + mdelay(10);
> + }
>  
>   if (!phydev) {
>   dev_err(dev, "phy_connect() failed\n");

-- 
Regards,
Siddharth.

[PATCH v5 3/3] riscv: cpu: jh7110: Imply SPL_SYS_MALLOC_CLEAR_ON_INIT

[Shengyu Qu]

Starfive JH7110 needs to clear L2 LIM to zero before use or ECC error
would be triggered. Currently, we use DDR ram for SPL malloc arena on
Visionfive 2 board in defconfig, but it's also possible to use L2 LIM as
SPL malloc arena. To avoid triggering ECC error in this scenario, we
imply SPL_SYS_MALLOC_CLEAR_ON_INIT as default.

Signed-off-by: Bo Gan 
Signed-off-by: Shengyu Qu 
---
 arch/riscv/cpu/jh7110/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/cpu/jh7110/Kconfig b/arch/riscv/cpu/jh7110/Kconfig
index 8469ee7de5..e5549a01b8 100644
--- a/arch/riscv/cpu/jh7110/Kconfig
+++ b/arch/riscv/cpu/jh7110/Kconfig
@@ -28,3 +28,4 @@ config STARFIVE_JH7110
imply SPL_LOAD_FIT
imply SPL_OPENSBI
imply SPL_RISCV_ACLINT
+   imply SPL_SYS_MALLOC_CLEAR_ON_INIT
-- 
2.38.1.windows.1

[PATCH v5 2/3] dlmalloc: Add support for SPL_SYS_MALLOC_CLEAR_ON_INIT

[Shengyu Qu]

To support SPL_SYS_MALLOC_CLEAR_ON_INIT, we have to modify
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
to #if CONFIG_IS_ENABLED(SYS_MALLOC_CLEAR_ON_INIT)

Signed-off-by: Bo Gan 
Signed-off-by: Shengyu Qu 
---
 common/dlmalloc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 0f9b7262d5..dcecdb8623 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -631,7 +631,7 @@ void mem_malloc_init(ulong start, ulong size)
 
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
  mem_malloc_end);
-#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
+#if CONFIG_IS_ENABLED(SYS_MALLOC_CLEAR_ON_INIT)
memset((void *)mem_malloc_start, 0x0, size);
 #endif
malloc_bin_reloc();
@@ -2153,7 +2153,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
 
   /* check if expand_top called, in which case don't need to clear */
-#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
+#if CONFIG_IS_ENABLED(SYS_MALLOC_CLEAR_ON_INIT)
 #if MORECORE_CLEARS
   mchunkptr oldtop = top;
   INTERNAL_SIZE_T oldtopsize = chunksize(top);
@@ -2184,7 +2184,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
 csz = chunksize(p);
 
-#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
+#if CONFIG_IS_ENABLED(SYS_MALLOC_CLEAR_ON_INIT)
 #if MORECORE_CLEARS
 if (p == oldtop && csz > oldtopsize)
 {
-- 
2.38.1.windows.1

[PATCH v5 1/3] Kconfig: Add SPL_SYS_MALLOC_CLEAR_ON_INIT

[Shengyu Qu]

Add SPL version of SYS_MALLOC_CLEAR_ON_INIT, this would help devices
that need to clear ram before use to work correctly.

Signed-off-by: Bo Gan 
Signed-off-by: Shengyu Qu 
---
 Kconfig | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Kconfig b/Kconfig
index 91170bf8d2..588acbaf9b 100644
--- a/Kconfig
+++ b/Kconfig
@@ -372,6 +372,17 @@ if EXPERT
  When disabling this, please check if malloc calls, maybe
  should be replaced by calloc - if one expects zeroed memory.
 
+   config SPL_SYS_MALLOC_CLEAR_ON_INIT
+   bool "Init with zeros the memory reserved for malloc (slow) in SPL"
+   depends on SPL
+   default SYS_MALLOC_CLEAR_ON_INIT
+   help
+ Same as SYS_MALLOC_CLEAR_ON_INIT, but for SPL. It's possible to
+ Enable it without SYS_MALLOC_CLEAR_ON_INIT. It's useful for boards
+ that must have particular memory regions zero'ed before first use.
+ If SYS_SPL_MALLOC_START is configured to be in such region, this
+ option should be enabled.
+
 config SYS_MALLOC_DEFAULT_TO_INIT
bool "Default malloc to init while reserving the memory for it"
help
-- 
2.38.1.windows.1

[PATCH v5 0/3] arch: riscv: jh7110: Correctly zero L2 LIM

[Shengyu Qu]

This series is the fifth version of Bo Gan's L2 LIM series.

Background information:
 JH7110 SPL runs in L2 LIM (2M in size mapped at 0x800). It
 consists of 16 0x2 sized regions, each one can be used as
 either L2 cache way or SRAM (not both). From top to bottom, there're
 ways 0-15. The way 0 is always enabled, at most 0x1e can be used.

In SPL, we don't enable any cache ways, thus all 15 (except way 0)
ways can be used. However, due to HW requirement, we must zero the
LIM before use. This is because ECC is applied to LIM, and if not
cleared first, the ECC part is invalid, which can trigger ECC errors
when reading/writing data.

There are several issues currently. We clear L2 LIM from __bss_end
to 0x81F in `harts_early_init`. This is wrong because:

 1. Each hart (in the middle of a function call) overwriting its own
stack and other harts' stacks.
(data-race and data-corruption)
 2. Lottery winner hart can be doing `board_init_f_init_reserve`,
while other harts're in the middle of zeroing L2 LIM.
(data-race)

To fix this, we split the job, such that there's one and only one
owner of zeroing a specific region (No data-race). A new SPL config
option `SPL_ZERO_MEM_BEFORE_USE` is introduced. Allowing The zeroing
to happen in the same code path. (much easier to reason about).

Besides, currently we use DDR ram for SPL malloc arena on Visionfive 2
board in defconfig, but it's also possible to use L2 LIM as SPL malloc
arena. To avoid triggering ECC error in this scenario, we add support
SYS_MALLOC_CLEAR_ON_INIT in SPL, and imply SPL_SYS_MALLOC_CLEAR_ON_INIT
on JH7110 as default.

Changes since v1:
 - Separate single patch into several patches

Changes since v2:
 - Fix typo (ZERO_MEM_BEFORE_USE to SPL_ZERO_MEM_BEFORE_USE)

Changes since v3:
 - Revert v3's fix since original implementation is actually right

Changes since v4:
 - Add support for SPL_SYS_MALLOC_CLEAR_ON_INIT
 - Remove already merged patches

Shengyu Qu (3):
  Kconfig: Add SPL_SYS_MALLOC_CLEAR_ON_INIT
  dlmalloc: Add support for SPL_SYS_MALLOC_CLEAR_ON_INIT
  riscv: cpu: jh7110: Imply SPL_SYS_MALLOC_CLEAR_ON_INIT

 Kconfig   | 11 +++
 arch/riscv/cpu/jh7110/Kconfig |  1 +
 common/dlmalloc.c |  6 +++---
 3 files changed, 15 insertions(+), 3 deletions(-)

-- 
2.38.1.windows.1

Re: [PATCH V4 1/8] env_default: Allow CONFIG_EXTRA_ENV_TEXT to override CFG_EXTRA_ENV_SETTINGS

[Simon Glass]

Hi Nishanth,

On Tue, 22 Aug 2023 at 17:34, Nishanth Menon  wrote:
>
> On 17:16-20230822, Simon Glass wrote:
> > Hi Nishanth,
> >
> > On Tue, 22 Aug 2023 at 12:41, Nishanth Menon  wrote:
> > >
> > > CFG_EXTRA_ENV_SETTINGS is set in common board config files, This allows
> > > for majority of the settings to be set in a common manner. However, the
> > > minor variations between various board can be addressed by the board.env
> > > files. The board.env files are converted into CONFIG_EXTRA_ENV_TEXT.
> > >
> > > However, this creates a minor problem. For example:
> > > distro_bootcmd.h and used by ti_armv7_common.h uses it as:
> > >  #define BOOT_TARGET_DEVICES(func) \
> > > func(MMC, mmc, 0) \
> > > func(MMC, mmc, 1)
> >
> > OK, but we should be using bootstd for new boards.
>
> Agreed, and I think I am using bootstd[1] unless I am missing something
> completely.

Then why do you have BOOT_TARGET_DEVICES() ?

>
> we still have a problem with EXTRA_ENV_SETTINGS and ENV_TEXT. This patch
> helps enforce priority of ENV_TEXT.
>
> But overall, I agree that we need to move off from EXTRA_ENV to text..
> probably in stages, I guess.

OK good

>
> > >
> > > Which in turn generates:
> > > boot_targets=mmc0 mmc1
> > >
> > > And this probably works fine for most boards, However when the
> > > boot_targets need to be reversed, the preferred behavior would have been
> > > to define it in board.env file as:
> > > boot_targets=mmc1 mmc0
> > >
> > > By changing the order of the inclusion, we allow for the
> > > CONFIG_EXTRA_ENV_TEXT to have a higher priority in the definition.
> > >
> > > Signed-off-by: Nishanth Menon 
> > > ---
> > > Cc: Simon Glass 
> > >
> > > New patch
> > >
> > >  include/env_default.h | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/include/env_default.h b/include/env_default.h
> > > index b16c22d5a28c..714dfa9e845e 100644
> > > --- a/include/env_default.h
> > > +++ b/include/env_default.h
> > > @@ -112,12 +112,12 @@ const char default_environment[] = {
> > >  #ifdef CONFIG_MTDPARTS_DEFAULT
> > > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"
> > >  #endif
> > > +#ifdef CFG_EXTRA_ENV_SETTINGS
> > > +   CFG_EXTRA_ENV_SETTINGS
> > > +#endif
> > >  #ifdef CONFIG_EXTRA_ENV_TEXT
> > > /* This is created in the Makefile */
> > > CONFIG_EXTRA_ENV_TEXT
> > > -#endif
> > > -#ifdef CFG_EXTRA_ENV_SETTINGS
> > > -   CFG_EXTRA_ENV_SETTINGS
> > >  #endif
> >
> > and text environment
>
> Could you clarify what I am missing?

I'm not sure about that. I have no objection to this patch.

>
> [1] https://u-boot.readthedocs.io/en/latest/develop/bootstd.html
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
> 849D 1736 249D

Regards,
Simon

[PATCH v2] cmd: dm: allow for selecting uclass and device

[AKASHI Takahiro]

The output from "dm tree" or "dm uclass" is a bit annoying
if the number of devices available on the system is huge.
(This is especially true on sandbox when I debug some DM code.)

With this patch, we can specify the uclass name or the device
name that we are interested in in order to limit the output.

For instance,

=> dm uclass usb
uclass 121: usb
0 usb@1 @ 0bcff8b0, seq 1

uclass 124: usb

=> dm tree usb:usb@1
 Class Index  Probed  DriverName
---
 usb   0  [   ]   usb_sandbox   usb@1
 usb_hub   0  [   ]   usb_hub   `-- hub
 usb_emul  0  [   ]   usb_sandbox_hub   `-- hub-emul
 usb_emul  1  [   ]   usb_sandbox_flash |-- flash-stick@0
 usb_emul  2  [   ]   usb_sandbox_flash |-- flash-stick@1
 usb_emul  3  [   ]   usb_sandbox_flash |-- flash-stick@2
 usb_emul  4  [   ]   usb_sandbox_keyb  `-- keyb@3

If you want forward-matching against a uclass or udevice name,
you can specify "-e" option.

=> dm uclass -e usb
uclass 15: usb_emul
0 hub-emul @ 0bcffb00, seq 0
1 flash-stick@0 @ 0bcffc30, seq 1
2 flash-stick@1 @ 0bcffdc0, seq 2
3 flash-stick@2 @ 0bcfff50, seq 3
4 keyb@3 @ 0bd000e0, seq 4

uclass 64: usb_mass_storage

uclass 121: usb
0 usb@1 @ 0bcff8b0, seq 1

uclass 122: usb_dev_generic

uclass 123: usb_hub
0 hub @ 0bcff9b0, seq 0

uclass 124: usb

=> dm tree -e usb
 Class Index  Probed  DriverName
---
 usb   0  [   ]   usb_sandbox   usb@1
 usb_hub   0  [   ]   usb_hub   `-- hub
 usb_emul  0  [   ]   usb_sandbox_hub   `-- hub-emul
 usb_emul  1  [   ]   usb_sandbox_flash |-- flash-stick@0
 usb_emul  2  [   ]   usb_sandbox_flash |-- flash-stick@1
 usb_emul  3  [   ]   usb_sandbox_flash |-- flash-stick@2
 usb_emul  4  [   ]   usb_sandbox_keyb  `-- keyb@3

Signed-off-by: AKASHI Takahiro 
---
v2
- allow for forward-matching against the name
- update command doc
---
 cmd/dm.c |  48 ++
 doc/usage/cmd/dm.rst |  30 ++-
 drivers/core/dump.c  | 116 ---
 include/dm/util.h|  15 --
 4 files changed, 165 insertions(+), 44 deletions(-)

diff --git a/cmd/dm.c b/cmd/dm.c
index 3263547cbec6..1aa86aab9c1c 100644
--- a/cmd/dm.c
+++ b/cmd/dm.c
@@ -59,11 +59,26 @@ static int do_dm_dump_static_driver_info(struct cmd_tbl 
*cmdtp, int flag,
 static int do_dm_dump_tree(struct cmd_tbl *cmdtp, int flag, int argc,
   char *const argv[])
 {
-   bool sort;
-
-   sort = argc > 1 && !strcmp(argv[1], "-s");
-
-   dm_dump_tree(sort);
+   bool extended = false, sort = false;
+   char *device = NULL;
+
+   for (; argc > 1; argc--, argv++) {
+   if (argv[1][0] != '-')
+   break;
+
+   if (!strcmp(argv[1], "-e")) {
+   extended = true;
+   } else if (!strcmp(argv[1], "-s")) {
+   sort = true;
+   } else {
+   printf("Unknown parameter: %s\n", argv[1]);
+   return 0;
+   }
+   }
+   if (argc > 1)
+   device = argv[1];
+
+   dm_dump_tree(device, extended, sort);
 
return 0;
 }
@@ -71,7 +86,20 @@ static int do_dm_dump_tree(struct cmd_tbl *cmdtp, int flag, 
int argc,
 static int do_dm_dump_uclass(struct cmd_tbl *cmdtp, int flag, int argc,
 char *const argv[])
 {
-   dm_dump_uclass();
+   bool extended = false;
+   char *uclass = NULL;
+
+   if (argc > 1) {
+   if (!strcmp(argv[1], "-e")) {
+   extended = true;
+   argc--;
+   argv++;
+   }
+   if (argc > 1)
+   uclass = argv[1];
+   }
+
+   dm_dump_uclass(uclass, extended);
 
return 0;
 }
@@ -91,8 +119,8 @@ static char dm_help_text[] =
"dm drivers   Dump list of drivers with uclass and instances\n"
DM_MEM_HELP
"dm staticDump list of drivers with static platform data\n"
-   "dm tree [-s] Dump tree of driver model devices (-s=sort)\n"
-   "dm uclassDump list of instances for each uclass"
+   "dm tree [-s][-e][name]   Dump tree of driver model devices (-s=sort)\n"
+   "dm uclass [-e][name] Dump list of instances for each uclass"
;
 #endif
 
@@ -102,5 +130,5 @@ U_BOOT_CMD_WITH_SUBCMDS(dm, "Driver model low level 
access", dm_help_text,
U_BOOT_SUBCMD_MKENT(drivers, 1, 1, do_dm_dump_drivers),
DM_MEM
U_BOOT_SUBCMD_MKENT(static, 1, 1, do_dm_dump_static_driver_info),
-   U_BOOT_SUBCMD_MKENT(tree, 2, 1, do_dm_dump_tree),
-   

[PATCH v2 4/5] drivers/mtd/nvmxip: Move sandbox_set_enable_memio() to test

[Marek Vasut]

The sandbox_set_enable_memio() should only ever be set during
sandbox testing, not within driver itself, move it back to test/ .

Signed-off-by: Marek Vasut 
---
Cc: Abdellatif El Khlifi 
Cc: Simon Glass 
---
V2: New patch
---
 drivers/mtd/nvmxip/nvmxip-uclass.c | 4 
 test/dm/nvmxip.c   | 2 ++
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nvmxip/nvmxip-uclass.c 
b/drivers/mtd/nvmxip/nvmxip-uclass.c
index 36eb056c213..9a316d1de39 100644
--- a/drivers/mtd/nvmxip/nvmxip-uclass.c
+++ b/drivers/mtd/nvmxip/nvmxip-uclass.c
@@ -29,10 +29,6 @@ int nvmxip_probe(struct udevice *udev)
char bdev_name[NVMXIP_BLKDEV_NAME_SZ + 1];
int devnum;
 
-#if CONFIG_IS_ENABLED(SANDBOX64)
-   sandbox_set_enable_memio(true);
-#endif
-
devnum = uclass_id_count(UCLASS_NVMXIP);
snprintf(bdev_name, NVMXIP_BLKDEV_NAME_SZ, "blk#%d", devnum);
 
diff --git a/test/dm/nvmxip.c b/test/dm/nvmxip.c
index 89bf481f616..f0ad47d4efe 100644
--- a/test/dm/nvmxip.c
+++ b/test/dm/nvmxip.c
@@ -103,6 +103,8 @@ static int dm_test_nvmxip(struct unit_test_state *uts)
void *buffer = NULL;
unsigned long flashsz;
 
+   sandbox_set_enable_memio(true);
+
/* set the flash content first for both devices */
dm_nvmxip_flash_sanity(uts, 0, NULL);
dm_nvmxip_flash_sanity(uts, 1, NULL);
-- 
2.40.1

[PATCH v2 5/5] configs: sandbox: Enable NVMXIP QSPI driver

[Marek Vasut]

Enable NVMXIP QSPI driver on sandbox, since it is already enabled
on sandbox64.

Signed-off-by: Marek Vasut 
---
Cc: Abdellatif El Khlifi 
Cc: Simon Glass 
---
V2: No change
---
 configs/sandbox_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index a57ab23d9a2..e1203714c60 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -226,6 +226,7 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_NVMXIP_QSPI=y
 CONFIG_MULTIPLEXER=y
 CONFIG_MUX_MMIO=y
 CONFIG_NVME_PCI=y
-- 
2.40.1

[PATCH v2 3/5] drivers/mtd/nvmxip: Print phys_addr_t without warnings on both 32bit and 64bit systems

[Marek Vasut]

Cast the address such that it can be printed without warnings
on both 32bit and 64bit systems. This really should use some
better print formatter, but for the lack of it, do it this way.

Signed-off-by: Marek Vasut 
---
Cc: Abdellatif El Khlifi 
Cc: Simon Glass 
---
V2: New patch
---
 drivers/mtd/nvmxip/nvmxip_qspi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nvmxip/nvmxip_qspi.c b/drivers/mtd/nvmxip/nvmxip_qspi.c
index 1bf0d311fe3..4d7471118a4 100644
--- a/drivers/mtd/nvmxip/nvmxip_qspi.c
+++ b/drivers/mtd/nvmxip/nvmxip_qspi.c
@@ -50,8 +50,8 @@ static int nvmxip_qspi_of_to_plat(struct udevice *dev)
return -EINVAL;
}
 
-   log_debug("[%s]: XIP device base addr: 0x%llx , lba_shift: %d , lbas: 
%lu\n",
- dev->name, plat->phys_base, plat->lba_shift, plat->lba);
+   log_debug("[%s]: XIP device base addr: 0x%p , lba_shift: %d , lbas: 
%lu\n",
+ dev->name, (void *)(uintptr_t)plat->phys_base, 
plat->lba_shift, plat->lba);
 
return 0;
 }
-- 
2.40.1

[PATCH v2 2/5] drivers/mtd/nvmxip: Rework the read accessor to support 32bit systems

[Marek Vasut]

Get rid of nvmxip_mmio_rawread() and just implement the readl()/readq()
reader loop within nvmxip_blk_read(). Cast the destination buffer as
needed and increment the read by either 4 or 8 bytes depending on if
this is systemd with 32bit or 64bit physical address.

Signed-off-by: Marek Vasut 
---
Cc: Abdellatif El Khlifi 
Cc: Simon Glass 
---
V2: No change
---
 drivers/mtd/nvmxip/nvmxip.c | 38 -
 1 file changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/mtd/nvmxip/nvmxip.c b/drivers/mtd/nvmxip/nvmxip.c
index a359e3b4822..0bd98d64275 100644
--- a/drivers/mtd/nvmxip/nvmxip.c
+++ b/drivers/mtd/nvmxip/nvmxip.c
@@ -15,23 +15,6 @@
 #include 
 #include "nvmxip.h"
 
-/**
- * nvmxip_mmio_rawread() - read from the XIP flash
- * @address:   address of the data
- * @value: pointer to where storing the value read
- *
- * Read raw data from the XIP flash.
- *
- * Return:
- *
- * Always return 0.
- */
-static int nvmxip_mmio_rawread(const phys_addr_t address, u64 *value)
-{
-   *value = readq(address);
-   return 0;
-}
-
 /**
  * nvmxip_blk_read() - block device read operation
  * @dev:   the block device
@@ -49,15 +32,14 @@ static ulong nvmxip_blk_read(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcn
 {
struct nvmxip_plat *plat = dev_get_plat(dev->parent);
struct blk_desc *desc = dev_get_uclass_plat(dev);
-   /* number of the u64 words to read */
-   u32 qwords = (blkcnt * desc->blksz) / sizeof(u64);
+   /* number of bytes to read */
+   u32 size = blkcnt * desc->blksz;
/* physical address of the first block to read */
phys_addr_t blkaddr = plat->phys_base + blknr * desc->blksz;
-   u64 *virt_blkaddr;
-   u64 *pdst = buffer;
+   void *virt_blkaddr;
uint qdata_idx;
 
-   if (!pdst)
+   if (!buffer)
return -EINVAL;
 
log_debug("[%s]: reading from blknr: %lu , blkcnt: %lu\n", dev->name, 
blknr, blkcnt);
@@ -66,12 +48,16 @@ static ulong nvmxip_blk_read(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcn
 
/* assumption: the data is virtually contiguous */
 
-   for (qdata_idx = 0 ; qdata_idx < qwords ; qdata_idx++)
-   nvmxip_mmio_rawread((phys_addr_t)(virt_blkaddr + qdata_idx), 
pdst++);
-
+#if IS_ENABLED(CONFIG_PHYS_64BIT)
+   for (qdata_idx = 0 ; qdata_idx < size; qdata_idx += sizeof(u64))
+   *(u64 *)(buffer + qdata_idx) = readq(virt_blkaddr + qdata_idx);
+#else
+   for (qdata_idx = 0 ; qdata_idx < size; qdata_idx += sizeof(u32))
+   *(u32 *)(buffer + qdata_idx) = readl(virt_blkaddr + qdata_idx);
+#endif
log_debug("[%s]: src[0]: 0x%llx , dst[0]: 0x%llx , src[-1]: 0x%llx 
, dst[-1]: 0x%llx\n",
  dev->name,
- *virt_blkaddr,
+ *(u64 *)virt_blkaddr,
  *(u64 *)buffer,
  *(u64 *)((u8 *)virt_blkaddr + desc->blksz * blkcnt - 
sizeof(u64)),
  *(u64 *)((u8 *)buffer + desc->blksz * blkcnt - sizeof(u64)));
-- 
2.40.1

[PATCH v2 1/5] drivers/mtd/nvmxip: Trigger post bind as probe on driver level

[Marek Vasut]

Perform all the block device creation only once, after the driver itself
successfully bound. Do not do this in uclass post bind, as this might be
triggered multiple times. For example the ut_dm_host test triggers this
and triggers a memory leak that way, since there are now multiple block
devices created using the blk_create_devicef() .

To retain the old probe-on-boot behavior, set DM_FLAG_PROBE_AFTER_BIND
flag in uclass post_bind callback, so the driver model would probe the
driver at the right time.

Rename the function as well, to match similar functions in
other block-related subsystems, like the mmc one.

Signed-off-by: Marek Vasut 
---
Cc: Abdellatif El Khlifi 
Cc: Simon Glass 
---
V2: New patch
---
 drivers/mtd/nvmxip/nvmxip-uclass.c | 18 +++---
 drivers/mtd/nvmxip/nvmxip_qspi.c   |  1 +
 include/nvmxip.h   | 12 
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nvmxip/nvmxip-uclass.c 
b/drivers/mtd/nvmxip/nvmxip-uclass.c
index 6d8eb177b50..36eb056c213 100644
--- a/drivers/mtd/nvmxip/nvmxip-uclass.c
+++ b/drivers/mtd/nvmxip/nvmxip-uclass.c
@@ -22,17 +22,7 @@
 
 #define DEFAULT_LBA_SZ BIT(DEFAULT_LBA_SHIFT)
 
-/**
- * nvmxip_post_bind() - post binding treatments
- * @dev:   the NVMXIP device
- *
- * Create and probe a child block device.
- *
- * Return:
- *
- * 0 on success. Otherwise, failure
- */
-static int nvmxip_post_bind(struct udevice *udev)
+int nvmxip_probe(struct udevice *udev)
 {
int ret;
struct udevice *bdev = NULL;
@@ -67,6 +57,12 @@ static int nvmxip_post_bind(struct udevice *udev)
return 0;
 }
 
+static int nvmxip_post_bind(struct udevice *udev)
+{
+   dev_or_flags(udev, DM_FLAG_PROBE_AFTER_BIND);
+   return 0;
+}
+
 UCLASS_DRIVER(nvmxip) = {
.name  = "nvmxip",
.id= UCLASS_NVMXIP,
diff --git a/drivers/mtd/nvmxip/nvmxip_qspi.c b/drivers/mtd/nvmxip/nvmxip_qspi.c
index 7221fd1cb46..1bf0d311fe3 100644
--- a/drivers/mtd/nvmxip/nvmxip_qspi.c
+++ b/drivers/mtd/nvmxip/nvmxip_qspi.c
@@ -66,5 +66,6 @@ U_BOOT_DRIVER(nvmxip_qspi) = {
.id = UCLASS_NVMXIP,
.of_match = nvmxip_qspi_ids,
.of_to_plat = nvmxip_qspi_of_to_plat,
+   .probe = nvmxip_probe,
.plat_auto = sizeof(struct nvmxip_plat),
 };
diff --git a/include/nvmxip.h b/include/nvmxip.h
index f4ef37725d2..726fffeb3e8 100644
--- a/include/nvmxip.h
+++ b/include/nvmxip.h
@@ -29,4 +29,16 @@ struct nvmxip_plat {
lbaint_t lba;
 };
 
+/**
+ * nvmxip_bind() - post binding treatments
+ * @dev:   the NVMXIP device
+ *
+ * Create and probe a child block device.
+ *
+ * Return:
+ *
+ * 0 on success. Otherwise, failure
+ */
+int nvmxip_probe(struct udevice *udev);
+
 #endif /* __DRIVER_NVMXIP_H__ */
-- 
2.40.1

[PATCH] configs: sandbox64: Enable legacy image format support

[Marek Vasut]

Align the sandbox64 defconfig with sandbox defconfig. Enable missing
legacy image format support. This fixes ut_bootstd_bootflow_cmd_menu
test.

Suggested-by: Jonas Karlman 
Signed-off-by: Marek Vasut 
---
Cc: Mario Six 
Cc: Simon Glass 
---
 configs/sandbox64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 55a01b7eb9d..b97380544a3 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -13,6 +13,7 @@ CONFIG_SYS_MEMTEST_END=0x00101000
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
-- 
2.40.1

[PATCH] fwu: Initialize global fwu library state during CI test

[Marek Vasut]

The current CI test worked by sheer luck, the g_dev global pointer
in the fwu library was never initialized and the test equally well
failed on sandbox64. Trigger the main loop in sandbox tests too to
initialize that global state, and move the sandbox specific exit
from fwu_boottime_checks after g_dev is initialized.

Signed-off-by: Marek Vasut 
---
Cc: Etienne Carriere 
Cc: Ilias Apalodimas 
Cc: Jassi Brar 
Cc: Masahisa Kojima 
Cc: Michal Simek 
Cc: Patrick Delaunay 
Cc: Simon Glass 
Cc: Sughosh Ganu 
---
 lib/fwu_updates/fwu.c | 12 ++--
 test/dm/fwu_mdata.c   | 12 
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
index 4d0c8b84b9d..22bdc78df59 100644
--- a/lib/fwu_updates/fwu.c
+++ b/lib/fwu_updates/fwu.c
@@ -623,18 +623,18 @@ static int fwu_boottime_checks(void *ctx, struct event 
*event)
int ret;
u32 boot_idx, active_idx;
 
-   /* Don't have boot time checks on sandbox */
-   if (IS_ENABLED(CONFIG_SANDBOX)) {
-   boottime_check = 1;
-   return 0;
-   }
-
ret = uclass_first_device_err(UCLASS_FWU_MDATA, _dev);
if (ret) {
log_debug("Cannot find fwu device\n");
return ret;
}
 
+   /* Don't have boot time checks on sandbox */
+   if (IS_ENABLED(CONFIG_SANDBOX)) {
+   boottime_check = 1;
+   return 0;
+   }
+
ret = fwu_get_mdata(NULL);
if (ret) {
log_debug("Unable to read meta-data\n");
diff --git a/test/dm/fwu_mdata.c b/test/dm/fwu_mdata.c
index 8b5c83ef4e2..52018f610fe 100644
--- a/test/dm/fwu_mdata.c
+++ b/test/dm/fwu_mdata.c
@@ -93,6 +93,12 @@ static int dm_test_fwu_mdata_read(struct unit_test_state 
*uts)
struct udevice *dev;
struct fwu_mdata mdata = { 0 };
 
+   /*
+* Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
+* to populate g_dev global pointer in that library.
+*/
+   event_notify_null(EVT_MAIN_LOOP);
+
ut_assertok(uclass_first_device_err(UCLASS_FWU_MDATA, ));
ut_assertok(setup_blk_device(uts));
ut_assertok(populate_mmc_disk_image(uts));
@@ -112,6 +118,12 @@ static int dm_test_fwu_mdata_write(struct unit_test_state 
*uts)
struct udevice *dev;
struct fwu_mdata mdata = { 0 };
 
+   /*
+* Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
+* to populate g_dev global pointer in that library.
+*/
+   event_notify_null(EVT_MAIN_LOOP);
+
ut_assertok(setup_blk_device(uts));
ut_assertok(populate_mmc_disk_image(uts));
ut_assertok(write_mmc_blk_device(uts));
-- 
2.40.1

Re: [PATCH] cmd: dm: allow for selecting uclass and device

[AKASHI Takahiro]

Hi Simon,

On Mon, Aug 21, 2023 at 09:22:54PM -0600, Simon Glass wrote:
> Hi AKASHI,
> 
> On Mon, 21 Aug 2023 at 20:46, AKASHI Takahiro
>  wrote:
> >
> > The output from "dm tree" or "dm uclass" is a bit annoying
> > if the number of devices available on the system is huge.
> > (This is especially true on sandbox when I debug some DM code.)
> >
> > With this patch, we can specify the uclass or the device
> > that we are interested in in order to limit the output.
> >
> > For instance,
> >
> > => dm uclass usb
> > uclass 121: usb
> > 0 usb@1 @ 0bd008b0, seq 1
> >
> > => dm tree usb:usb@1
> 
> Perhaps this should just provide a substring to search for and it can
> find everything with a uclass name or device name that contains the
> string?

Well, I wanted to implement the feature with minimum effort,
using the existing API, like uclass_find_device_by_name().

Well, I'll try.

> Otherwise, can you drop the usb. part ? Is it needed?
> 
> >  Class Index  Probed  DriverName
> > ---
> >  usb   0  [   ]   usb_sandbox   usb@1
> >  usb_hub   0  [   ]   usb_hub   `-- hub
> >  usb_emul  0  [   ]   usb_sandbox_hub   `-- hub-emul
> >  usb_emul  1  [   ]   usb_sandbox_flash |-- flash-stick@0
> >  usb_emul  2  [   ]   usb_sandbox_flash |-- flash-stick@1
> >  usb_emul  3  [   ]   usb_sandbox_flash |-- flash-stick@2
> >  usb_emul  4  [   ]   usb_sandbox_keyb  `-- keyb@3
> >
> > Please note that, at "dm tree", the uclass name (usb) as well as
> > the device name (usb@1) is required.
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/dm.c| 30 
> >  drivers/core/dump.c | 48 +++--
> >  include/dm/util.h   | 13 
> >  3 files changed, 73 insertions(+), 18 deletions(-)
> 
> Thanks, I've been wanting this for ages.

Me, too :)

> Can you please add doc/ as well?

Yes.

> >
> > diff --git a/cmd/dm.c b/cmd/dm.c
> > index 3263547cbec6..99268df2f87a 100644
> > --- a/cmd/dm.c
> > +++ b/cmd/dm.c
> > @@ -59,11 +59,20 @@ static int do_dm_dump_static_driver_info(struct cmd_tbl 
> > *cmdtp, int flag,
> >  static int do_dm_dump_tree(struct cmd_tbl *cmdtp, int flag, int argc,
> >char *const argv[])
> >  {
> > -   bool sort;
> > +   bool sort = false;
> > +   char *device = NULL;
> >
> > -   sort = argc > 1 && !strcmp(argv[1], "-s");
> > +   if (argc > 1) {
> > +   if (!strcmp(argv[1], "-s")) {
> > +   sort = true;
> > +   argc--;
> > +   argv++;
> > +   }
> > +   if (argc > 1)
> > +   device = argv[1];
> > +   }
> >
> > -   dm_dump_tree(sort);
> > +   dm_dump_tree(device, sort);
> >
> > return 0;
> >  }
> > @@ -71,7 +80,12 @@ static int do_dm_dump_tree(struct cmd_tbl *cmdtp, int 
> > flag, int argc,
> >  static int do_dm_dump_uclass(struct cmd_tbl *cmdtp, int flag, int argc,
> >  char *const argv[])
> >  {
> > -   dm_dump_uclass();
> > +   char *uclass = NULL;
> > +
> > +   if (argc > 1)
> > +   uclass = argv[1];
> > +
> > +   dm_dump_uclass(uclass);
> >
> > return 0;
> >  }
> > @@ -91,8 +105,8 @@ static char dm_help_text[] =
> > "dm drivers   Dump list of drivers with uclass and instances\n"
> > DM_MEM_HELP
> > "dm staticDump list of drivers with static platform data\n"
> > -   "dm tree [-s] Dump tree of driver model devices (-s=sort)\n"
> > -   "dm uclassDump list of instances for each uclass"
> > +   "dm tree [-s][name] Dump tree of driver model devices (-s=sort)\n"
> > +   "dm uclass [name] Dump list of instances for each uclass"
> > ;
> >  #endif
> >
> > @@ -102,5 +116,5 @@ U_BOOT_CMD_WITH_SUBCMDS(dm, "Driver model low level 
> > access", dm_help_text,
> > U_BOOT_SUBCMD_MKENT(drivers, 1, 1, do_dm_dump_drivers),
> > DM_MEM
> > U_BOOT_SUBCMD_MKENT(static, 1, 1, do_dm_dump_static_driver_info),
> > -   U_BOOT_SUBCMD_MKENT(tree, 2, 1, do_dm_dump_tree),
> > -   U_BOOT_SUBCMD_MKENT(uclass, 1, 1, do_dm_dump_uclass));
> > +   U_BOOT_SUBCMD_MKENT(tree, 3, 1, do_dm_dump_tree),
> > +   U_BOOT_SUBCMD_MKENT(uclass, 2, 1, do_dm_dump_uclass));
> > diff --git a/drivers/core/dump.c b/drivers/core/dump.c
> > index 3e77832a3a00..855d6ca002b7 100644
> > --- a/drivers/core/dump.c
> > +++ b/drivers/core/dump.c
> > @@ -85,11 +85,35 @@ static void show_devices(struct udevice *dev, int 
> > depth, int last_flag,
> > }
> >  }
> >
> > -void dm_dump_tree(bool sort)
> > +void dm_dump_tree(char *uclass, bool sort)
> >  {
> > struct udevice *root;
> >
> > -   root = dm_root();
> > +   if (uclass) {
> > +

Re: [PATCH V4 1/8] env_default: Allow CONFIG_EXTRA_ENV_TEXT to override CFG_EXTRA_ENV_SETTINGS

[Nishanth Menon]

On 17:16-20230822, Simon Glass wrote:
> Hi Nishanth,
> 
> On Tue, 22 Aug 2023 at 12:41, Nishanth Menon  wrote:
> >
> > CFG_EXTRA_ENV_SETTINGS is set in common board config files, This allows
> > for majority of the settings to be set in a common manner. However, the
> > minor variations between various board can be addressed by the board.env
> > files. The board.env files are converted into CONFIG_EXTRA_ENV_TEXT.
> >
> > However, this creates a minor problem. For example:
> > distro_bootcmd.h and used by ti_armv7_common.h uses it as:
> >  #define BOOT_TARGET_DEVICES(func) \
> > func(MMC, mmc, 0) \
> > func(MMC, mmc, 1)
> 
> OK, but we should be using bootstd for new boards.

Agreed, and I think I am using bootstd[1] unless I am missing something
completely.

we still have a problem with EXTRA_ENV_SETTINGS and ENV_TEXT. This patch
helps enforce priority of ENV_TEXT.

But overall, I agree that we need to move off from EXTRA_ENV to text..
probably in stages, I guess.

> >
> > Which in turn generates:
> > boot_targets=mmc0 mmc1
> >
> > And this probably works fine for most boards, However when the
> > boot_targets need to be reversed, the preferred behavior would have been
> > to define it in board.env file as:
> > boot_targets=mmc1 mmc0
> >
> > By changing the order of the inclusion, we allow for the
> > CONFIG_EXTRA_ENV_TEXT to have a higher priority in the definition.
> >
> > Signed-off-by: Nishanth Menon 
> > ---
> > Cc: Simon Glass 
> >
> > New patch
> >
> >  include/env_default.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/env_default.h b/include/env_default.h
> > index b16c22d5a28c..714dfa9e845e 100644
> > --- a/include/env_default.h
> > +++ b/include/env_default.h
> > @@ -112,12 +112,12 @@ const char default_environment[] = {
> >  #ifdef CONFIG_MTDPARTS_DEFAULT
> > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"
> >  #endif
> > +#ifdef CFG_EXTRA_ENV_SETTINGS
> > +   CFG_EXTRA_ENV_SETTINGS
> > +#endif
> >  #ifdef CONFIG_EXTRA_ENV_TEXT
> > /* This is created in the Makefile */
> > CONFIG_EXTRA_ENV_TEXT
> > -#endif
> > -#ifdef CFG_EXTRA_ENV_SETTINGS
> > -   CFG_EXTRA_ENV_SETTINGS
> >  #endif
> 
> and text environment

Could you clarify what I am missing?

[1] https://u-boot.readthedocs.io/en/latest/develop/bootstd.html
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH 2/2] doc: Highlight the most relevant u-boot talks

[Simon Glass]

On Tue, 22 Aug 2023 at 12:54, Paul Barker  wrote:
>
> The list of u-boot talks on elinux.org is quite long, so let's highlight
> the talks which are likely most relevant for newcomers.
>
> Signed-off-by: Paul Barker 
> ---
>  doc/learn/talks.rst | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH V4 1/8] env_default: Allow CONFIG_EXTRA_ENV_TEXT to override CFG_EXTRA_ENV_SETTINGS

[Simon Glass]

Hi Nishanth,

On Tue, 22 Aug 2023 at 12:41, Nishanth Menon  wrote:
>
> CFG_EXTRA_ENV_SETTINGS is set in common board config files, This allows
> for majority of the settings to be set in a common manner. However, the
> minor variations between various board can be addressed by the board.env
> files. The board.env files are converted into CONFIG_EXTRA_ENV_TEXT.
>
> However, this creates a minor problem. For example:
> distro_bootcmd.h and used by ti_armv7_common.h uses it as:
>  #define BOOT_TARGET_DEVICES(func) \
> func(MMC, mmc, 0) \
> func(MMC, mmc, 1)

OK, but we should be using bootstd for new boards.

>
> Which in turn generates:
> boot_targets=mmc0 mmc1
>
> And this probably works fine for most boards, However when the
> boot_targets need to be reversed, the preferred behavior would have been
> to define it in board.env file as:
> boot_targets=mmc1 mmc0
>
> By changing the order of the inclusion, we allow for the
> CONFIG_EXTRA_ENV_TEXT to have a higher priority in the definition.
>
> Signed-off-by: Nishanth Menon 
> ---
> Cc: Simon Glass 
>
> New patch
>
>  include/env_default.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/env_default.h b/include/env_default.h
> index b16c22d5a28c..714dfa9e845e 100644
> --- a/include/env_default.h
> +++ b/include/env_default.h
> @@ -112,12 +112,12 @@ const char default_environment[] = {
>  #ifdef CONFIG_MTDPARTS_DEFAULT
> "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"
>  #endif
> +#ifdef CFG_EXTRA_ENV_SETTINGS
> +   CFG_EXTRA_ENV_SETTINGS
> +#endif
>  #ifdef CONFIG_EXTRA_ENV_TEXT
> /* This is created in the Makefile */
> CONFIG_EXTRA_ENV_TEXT
> -#endif
> -#ifdef CFG_EXTRA_ENV_SETTINGS
> -   CFG_EXTRA_ENV_SETTINGS
>  #endif

and text environment

> "\0"
>  #else /* CONFIG_USE_DEFAULT_ENV_FILE */
> --
> 2.40.0
>

Regards,
SImon

[PATCH v1] board: toradex: verdin-imx8mm: enable usb sdp spl recovery support

[Marcel Ziswiler]

From: Marcel Ziswiler 

Enable USB SDP SPL aka serial downloader recovery mode support.

While at it also enable fastboot support which may be used to
subsequently load further stages like a Toradex Easy Installer FIT
image.

Signed-off-by: Marcel Ziswiler 

---

 .../dts/imx8mm-verdin-wifi-dev-u-boot.dtsi| 17 
 configs/verdin-imx8mm_defconfig   | 20 +++
 2 files changed, 37 insertions(+)

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 2b268f55cb9..b06ce3fa034 100644
--- a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi
@@ -34,6 +34,10 @@
bootph-pre-ram;
 };
 
+ {
+   bootph-pre-ram;
+};
+
 _uboot {
offset = <0x5fc00>;
 };
@@ -124,6 +128,19 @@
bootph-pre-ram;
 };
 
+ {
+   bootph-pre-ram;
+};
+
+/* Verdin USB_1 */
+ {
+   bootph-pre-ram;
+};
+
+ {
+   bootph-pre-ram;
+};
+
  {
bootph-pre-ram;
 };
diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
index 09e14c6f8c4..2fbde394577 100644
--- a/configs/verdin-imx8mm_defconfig
+++ b/configs/verdin-imx8mm_defconfig
@@ -69,6 +69,8 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_READ=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_USB_SDP=y
+CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
@@ -97,6 +99,12 @@ CONFIG_SPL_CLK_COMPOSITE_CCF=y
 CONFIG_CLK_COMPOSITE_CCF=y
 CONFIG_SPL_CLK_IMX8MM=y
 CONFIG_CLK_IMX8MM=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x4280
+CONFIG_FASTBOOT_BUF_SIZE=0x4000
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_UUU_SUPPORT=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_GPIO_HOG=y
 CONFIG_SPL_GPIO_HOG=y
 CONFIG_MXC_GPIO=y
@@ -120,6 +128,8 @@ CONFIG_PHY_FIXED=y
 CONFIG_DM_MDIO=y
 CONFIG_FEC_MXC=y
 CONFIG_MII=y
+CONFIG_SPL_PHY=y
+CONFIG_SPL_NOP_PHY=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_IMX8M=y
@@ -139,8 +149,18 @@ CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_TMU=y
 CONFIG_USB=y
+CONFIG_SPL_USB_HOST=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_MXC_USB_OTG_HACTIVE=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_GADGET=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Toradex"
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
+CONFIG_USB_GADGET_PRODUCT_NUM=0x4000
+CONFIG_CI_UDC=y
+CONFIG_SDP_LOADADDR=0x4040
+CONFIG_SPL_USB_SDP_SUPPORT=y
 CONFIG_IMX_WATCHDOG=y
 CONFIG_HEXDUMP=y
-- 
2.36.1

Re: [PATCH 2/2] serial: sh: Tidy up pre-processor directive indentation

[Marek Vasut]

On 8/22/23 20:10, Paul Barker wrote:

Let's make the indentation of pre-processor macros and conditionals in
serial_sh.h consistent before we add to the confusion with a new SoC.


What exactly is this patch doing, adding spaces to ifdeffery ?

I would be tempted to say, can we clean up the ifdeffery instead ?
It is some hideous mess.

Re: [PATCH 1/2] serial: sh: Fix compile error when lacking HSCIF support

[Marek Vasut]

On 8/22/23 20:10, Paul Barker wrote:

If we attempt to compile serial_sh.c for a system which lacks HSCIF
support (e.g. R8A7740), we see the following compilation error:

 In file included from drivers/serial/serial_sh.c:20:
 drivers/serial/serial_sh.c: In function ‘sh_serial_init_generic’:
 drivers/serial/serial_sh.h:429:35: warning: implicit declaration of 
function ‘sci_HSSRR_out’; did you mean ‘sci_SCSCR_out’? 
[-Wimplicit-function-declaration]
   429 | #define sci_out(port, reg, value) sci_##reg##_out(port, value)
   |   ^~~~
 drivers/serial/serial_sh.c:62:17: note: in expansion of macro ‘sci_out’
62 | sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8);
   | ^~~

To fix this, only try to support access to the HSSRR register for SoCs
where it actually exists.

Fixes: bbe36e29ca2c ('serial: sh: Add HSCIF support for R-Car SoC')
Signed-off-by: Paul Barker 
Cc: Hai Pham 
Cc: Marek Vasut 
Cc: Simon Glass 
---
  drivers/serial/serial_sh.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 20cda5dbe272..cd9bcf4f0a25 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -58,8 +58,10 @@ static void sh_serial_init_generic(struct uart_port *port)
sci_out(port, SCSPTR, 0x0003);
  #endif
  
+#if defined(CONFIG_RCAR_GEN2) || defined(CONFIG_RCAR_GEN3) || defined(CONFIG_RCAR_GEN4)


You can use CONFIG_RCAR_64 instead of GEN3+GEN4 test.

Also, can does

#if IS_ENABLED(CONFIG_RCAR_GEN2) || IS_ENABLED(CONFIG_RCAR_64)

work ?

Re: [PATCH] arm: dts: j7200: dtb sync with Linux 6.5-rc1

[Nishanth Menon]

On 13:57-20230822, Reid Tonking wrote:
> Sync j7200 device tree files with Linux 6.5-rc1

I understand this is a major step forward, but a still:

There is more work to do:
a) split the dev-data.c fixup as the first patch
b) See comments in 
https://lore.kernel.org/u-boot/20230816114445.c4c7rgdp5arhmiaq@polyester/

[...]

> diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
> b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> index f25c7136c9..a00e85e366 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
> + * Copyright (C) 2020-2023 Texas Instruments Incorporated - 
> https://www.ti.com/
>   */
>  
>  #include "k3-j7200-binman.dtsi"
> @@ -8,7 +8,7 @@
>  / {
>   chosen {
>   stdout-path = "serial2:115200n8";

Drop this

> - tick-timer = 
> + tick-timer = _timer0;
>   };
>  
>   aliases {

You dont need the aliases - these come in from board.dts

> @@ -28,16 +28,12 @@
>   bootph-pre-ram;
>  };
>  
> -_mcu_wakeup {
> +_esm{

space before the {

>   bootph-pre-ram;
> +};
>  
> - timer1: timer@4040 {
> - compatible = "ti,omap5430-timer";
> - reg = <0x0 0x4040 0x0 0x80>;
> - ti,timer-alwon;
> - clock-frequency = <25000>;
> - bootph-pre-ram;
> - };
> +_mcu_wakeup {
> + bootph-pre-ram;
>  
>   chipid@4314 {
>   bootph-pre-ram;

};
End it here.

> @@ -45,8 +41,6 @@
>  
>   mcu_navss: bus@2838 {

Dont duplicate the entire node.
_navss {
bootph-pre-ram;
};

_ringacc {
bootph-pre-ram;
};
NOTE: you only need to override reg-names and reg in R5.dtsi not u-boot.dtsi.

_udmap {
bootph-pre-ram;
};

>   bootph-pre-ram;
> - #address-cells = <2>;
> - #size-cells = <2>;
>  
>   ringacc@2b80 {
>   reg =   <0x0 0x2b80 0x0 0x40>,
And clean this up.
>  
>  _i2c0 {
>   bootph-pre-ram;
> +
> + lp876441: lp876441@4c {

NAK. Why is this new stuff coming in -> should'nt be here.

> + bootph-pre-ram;
> +
> + regulators: regulators {
> + bootph-pre-ram;
> +
> + buck1_reg: buck1 {
> + bootph-pre-ram;
> + };
> + };
> + };
>  };
>  
>  _i2c0 {
>   bootph-pre-ram;
> +
> + exp1: gpio@20 {

Again - just do it using the reference
 {
bootph-pre-ram;
};

And this pattern repeats itself..

> + bootph-pre-ram;
> + };
> +
> + exp2: gpio@22 {

This as well.


hbmc -> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi: flash@0,0 weird
that does'nt throw a dtbs_check warning

WARNING: u-boot,mux-autoprobe -> this is'nt supported.

Also _r5fss0 -> ti,cluster-mode=<0> -> Drop that.

There is a bit debate about dr_mode = "peripheral";
https://lore.kernel.org/u-boot/fc205109-fd3d-ea79-abcc-f1638115d...@kernel.org/#r

Depending on where it ends up...

[...]

> diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts 
> b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> index e62f9218e8..bd4be7215f 100644
> --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts

[...]

> +_timer0 {
> + /delete-property/ power-domains;
> + ti,timer-alwon;
> + clock-frequency = <2500>;
> + bootph-pre-ram;

you already caught this - just pre-ram and clock-frequency.

>  };
>  
>  _mcu_wakeup {
> - mcu_secproxy: secproxy@2a38 {
> + secure_proxy_mcu: mailbox@2a48 {

Move this out.

>   bootph-pre-ram;
> - compatible = "ti,am654-secure-proxy";
> - reg = <0x0 0x2a38 0x0 0x8>,
> -   <0x0 0x2a40 0x0 0x8>,
> -   <0x0 0x2a48 0x0 0x8>;
> - reg-names = "rt", "scfg", "target_data";
> - #mbox-cells = <1>;
> + status = "okay";
>   };
>  
>   sysctrler: sysctrler {
> - bootph-pre-ram;
>   compatible = "ti,am654-system-controller";
> - mboxes= <_secproxy 4>, <_secproxy 5>;
> + mboxes= <_proxy_mcu 4>,
> + 

[PATCH v3 2/2] memory: Add ECC property

[Simon Glass]

Some memories provides ECC correction. For software which wants to check
memory, it is helpful to see which regions provide this feature.

Add this as a property of the /memory nodes, since it presumably follows
the hardware-level memory system.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Add new patch to update the /memory nodes

 dtschema/schemas/memory.yaml | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/dtschema/schemas/memory.yaml b/dtschema/schemas/memory.yaml
index 1d74410..981af04 100644
--- a/dtschema/schemas/memory.yaml
+++ b/dtschema/schemas/memory.yaml
@@ -34,7 +34,14 @@ patternProperties:
 description:
   For the purpose of identification, each NUMA node is associated with
   a unique token known as a node id.
-
+  attr:
+$ref: /schemas/types.yaml#/definitions/string-array
+description: |
+  Attributes possessed by this memory region:
+
+"single-bit-ecc" - supports single-bit ECC
+"multi-bit-ecc" - supports multiple-bit ECC
+"no-ecc" - non-ECC memory
 
 required:
   - device_type
-- 
2.42.0.rc1.204.g551eb34607-goog

[PATCH v3 1/2] schemas: Add a schema for memory map

[Simon Glass]

The Devicetree specification skips over handling of a logical view of
the memory map, pointing users to the UEFI specification.

It is common to split firmware into 'Platform Init', which does the
initial hardware setup and a "Payload" which selects the OS to be booted.
Thus an handover interface is required between these two pieces.

Where UEFI boot-time services are not available, but UEFI firmware is
present on either side of this interface, information about memory usage
and attributes must be presented to the "Payload" in some form.

This aims to provide an initial schema for this mapping.

Note that this is separate from the existing /memory and /reserved-memory
nodes, since it is mostly concerned with what the memory is used for. It
may cover only a small fraction of available memory.

For now, no attempt is made to create an exhaustive binding, so there are
some example types listed. This can be completed once this has passed
initial review.

This binding does not include a binding for the memory 'attribute'
property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be useful
to have that as well, but perhaps not as a bit mask.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Reword commit message again
- cc a lot more people, from the FFI patch
- Split out the attributes into the /memory nodes

Changes in v2:
- Reword commit message

 dtschema/schemas/memory-map.yaml | 61 
 1 file changed, 61 insertions(+)
 create mode 100644 dtschema/schemas/memory-map.yaml

diff --git a/dtschema/schemas/memory-map.yaml b/dtschema/schemas/memory-map.yaml
new file mode 100644
index 000..4b06583
--- /dev/null
+++ b/dtschema/schemas/memory-map.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: BSD-2-Clause
+# Copyright 2023 Google LLC
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-map.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: /memory-map nodes
+description: |
+  Common properties always required in /memory-map nodes. These nodes are
+  intended to resolve the nonchalant clause 3.4.1 ("/memory node and UEFI")
+  in the Devicetree Specification.
+
+maintainers:
+  - Simon Glass 
+
+properties:
+  $nodename:
+const: 'memory-map'
+
+patternProperties:
+  "^([a-z][a-z0-9\\-]+@[0-9a-f]+)?$":
+type: object
+additionalProperties: false
+
+properties:
+  reg:
+minItems: 1
+maxItems: 1024
+
+  usage:
+$ref: /schemas/types.yaml#/definitions/string
+description: |
+  Describes the usage of the memory region, e.g.:
+
+"acpi-reclaim", "acpi-nvs", "bootcode", "bootdata", "bootdata",
+"runtime-code", "runtime-data".
+
+See enum EFI_MEMORY_TYPE in "Unified Extensible Firmware Interface
+(UEFI) Specification" for all the types. For now there are not
+listed here.
+
+required:
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+memory-map {
+acpi@f {
+reg = <0xf 0x4000>;
+usage = "acpi-reclaim";
+};
+
+runtime@1230 {
+reg = <0x1230 0x28000>;
+usage = "runtime-code";
+};
+};
+...
-- 
2.42.0.rc1.204.g551eb34607-goog

Re: [PATCH v2] schemas: Add a schema for memory map

[Simon Glass]

Hi Rob,

On Tue, 22 Aug 2023 at 12:53, Rob Herring  wrote:
>
> On Mon, Aug 21, 2023 at 2:48 PM Simon Glass  wrote:
> >
> > The Devicespec specification skips over handling of a logical view of
> > the memory map, pointing users to the UEFI specification.
>
> It's more that the DT spec defines what is not used with UEFI. If UEFI
> covers more than the DT Spec defined, then we should look at that.
>
> I would look some into (IBM) PowerPC for any prior art in this area.
> Unfortunately, not publicly documented other than any users.

OK, but I'm not sure what you are looking for here. The DT (as
currently specified) is an incomplete description of memory, for
EFI-type firmware. I recall the ePAPR thing, but not much else. Any
pointers?

>
> > It is common to split firmware into 'Platform Init', which does the
> > initial hardware setup and a "Payload" which selects the OS to be booted.
> > Thus an handover interface is required between these two pieces.
> >
> > Where UEFI boot-time services are not available, but UEFI firmware is
> > present on either side of this interface, information about memory usage
> > and attributes must be presented to the "Payload" in some form.
> >
> > This aims to provide an initial schema for this mapping.
> >
> > Note that this is separate from the existing /memory and /reserved-memory
> > nodes, since it is mostly concerned with what the memory is used for. It
> > may cover only a small fraction of available memory, although it could be
> > used to signal which area of memory has ECC.
> >
> > For now, no attempt is made to create an exhaustive binding, so there are
> > some example types lists. This can be completed once this has passed
> > initial review.
>
> I don't have much interest in picking this up unless there's some
> wider agreement. From the previously referenced discussion[1], it
> didn't seem like there was. But none of those folk are Cc'ed here.

Yes, Ron pointed me to that...although it isn't quite the same thing.
That is implementing a way to pass SMBIOS and ACPI tables through to
Linux, right? But it does mention memory types, so I'll send a new
version with those people on cc, in case they don't look at linux-acpi
much.

But note, this is for *firmware* (on both sides of the interface).
Whether it is useful for Linux is another question. But in any case,
we should avoid having things in the DT which Linux cannot validate /
parse.

>
> > ---
> >
> > Changes in v2:
> > - Reword commit message
> >
> >  dtschema/schemas/memory-map.yaml | 51 
> >  1 file changed, 51 insertions(+)
> >  create mode 100644 dtschema/schemas/memory-map.yaml
> >
> > diff --git a/dtschema/schemas/memory-map.yaml 
> > b/dtschema/schemas/memory-map.yaml
> > new file mode 100644
> > index 000..97e531e
> > --- /dev/null
> > +++ b/dtschema/schemas/memory-map.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: BSD-2-Clause
> > +# Copyright 2023 Google LLC
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/memory-map.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: /memory-map nodes
> > +description: |
> > +  Common properties always required in /memory-map nodes. These nodes are
> > +  intended to resolve the nonchalant clause 3.4.1 ("/memory node and UEFI")
> > +  in the Devicetree Specification.
> > +
> > +maintainers:
> > +  - Simon Glass 
> > +
> > +properties:
> > +  $nodename:
> > +const: '/'
>
> This goes in the root node?

I suppose I'm just confused about how the schema is described. I think
it is better to have a /memory-map node with subnodes of that for each
region.

>
> > +  usage:
> > +$ref: /schemas/types.yaml#/definitions/string
> > +description: |
> > +  Describes the usage of the memory region, e.g.:
> > +
> > +"acpi-reclaim", "acpi-nvs", "bootcode", "bootdata", "bootdata",
> > +"runtime-code", "runtime-data"
>
> Can't these be covered by reserved-memory? The client is free to
> reclaim any regions if it knows what they are.

I don't see that in the schema, but given what you say, it is
definitely an option.

If the reserved-memory node hiding somewhere?

>
> > +  attr:
> > +$ref: /schemas/types.yaml#/definitions/string-array
> > +description: |
> > +  Attributes possessed by this memory region:
> > +
> > +"single-bit-ecc" - supports single-bit ECC
> > +"multi-bit-ecc" - supports multiple-bit ECC
> > +"no-ecc" - non-ECC memory
>
> Isn't this pretty much a property of a memory region as a whole. IOW,
> couldn't it just go into /memory node(s)?

Yes I think so. I wasn't sure if adding it there would break things,
but it seems not.

>
> > +
> > +patternProperties:
> > +  "^([a-z][a-z0-9\\-]+@[0-9a-f]+)?$":
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > +  reg:
> > +minItems: 1
> > +maxItems: 1024
> > +
> > +required:
> > +  - reg
> > +
> > 

Re: [PATCH] arm: dts: j7200: dtb sync with Linux 6.5-rc1

[reidt]

On 13:57-20230822, Reid Tonking wrote:

[...]

> diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts 
> b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> index e62f9218e8..bd4be7215f 100644
> --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> @@ -41,44 +31,34 @@
>   ti,sci-host-id = <10>;
>   bootph-pre-ram;
>   };
> -
> - clk_200mhz: dummy_clock_200mhz {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <2>;
> - bootph-pre-ram;
> - };
> -
> - clk_19_2mhz: dummy_clock_19_2mhz {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <1920>;
> - bootph-pre-ram;
> - };
>  };
>  
>   {
>   power-domains = <_pds 8 TI_SCI_PD_SHARED>,
>   <_pds 90 TI_SCI_PD_SHARED>;
>   clocks = <_clks 8 5>, <_clks 30 9>;
> + bootph-pre-ram;
> +};
> +
> +_timer0 {
> + /delete-property/ power-domains;
> + ti,timer-alwon;
> + clock-frequency = <2500>;
> + bootph-pre-ram;
>  };

This needs to be..
$mcu_timer0 {
clock-frequency = <2500>;
bootph-pre-ram;
};

This fix was accidently left out of the commit, so it'll be changed for
v2. The change to dev-data.c allows this.

-Reid

Please pull u-boot-dm

[Simon Glass]

Hi Tom.

https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/17476


The following changes since commit 976fb2ffa3875a7bed9866bf5cf939a81c423ef8:

  Prepare v2023.10-rc3 (2023-08-21 16:19:59 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-pull-22aug23

for you to fetch changes up to 1c55d62fb9ccc107cb4fefa9bb04cb16395ca84c:

  riscv: cpu: make riscv_cpu_probe to EVT_DM_POST_INIT_R callback
(2023-08-22 08:07:54 -0600)


RISC-V fix for CPU init


Chanho Park (2):
  dm: event: add EVT_DM_POST_INIT_R event type
  riscv: cpu: make riscv_cpu_probe to EVT_DM_POST_INIT_R callback

 arch/riscv/cpu/cpu.c | 11 +++
 common/event.c   |  1 +
 drivers/core/root.c  |  6 --
 include/event.h  |  1 +
 4 files changed, 9 insertions(+), 10 deletions(-)

Regards,
Simon

[PATCH] arm: dts: j7200: dtb sync with Linux 6.5-rc1

[Reid Tonking]

Sync j7200 device tree files with Linux 6.5-rc1

- k3-j7200-r5-common-proc-board.dts now inherits from
  k3-j7200-common-proc-board.dts instead of k3-j7200-som-p0.dtsi. This
  allows us to trim down the r5 file considerably by using existing
  properties.

- remove pimux nodes from r5 file

- remove duplicate nodes & node properties from r5/u-boot files

- mcu_timer0 now used instead of timer1

  mcu_timer0 device id added to dev-data.c file in order to work

- remove cpsw node

  This node is no longer required since the compatible is now fixed

- remove dummy_clock_19_2_mhz

  This node wasn't being used anyhere, so it was removed.

- remove dummy_clock_200mhz

  main_sdhci0 & main_sdhci1 no longer need dummy clock for eMMC/SD

- fix secure proxy node

  mcu_secproxy changed to used secure_prxy_mcu which is already
  defined in k3-j7200-mcu-wakeup.dtsi

Signed-off-by: Reid Tonking 
---
based on: 976fb2ffa3 Prepare v2023.10-rc3
boot test: https://gist.github.com/Glockn/1d7a61adac8f3f56c49afffe683704b7

 .../k3-j7200-common-proc-board-u-boot.dtsi| 109 ++--
 arch/arm/dts/k3-j7200-common-proc-board.dts   | 170 --
 arch/arm/dts/k3-j7200-main.dtsi   | 512 +-
 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 265 -
 .../arm/dts/k3-j7200-r5-common-proc-board.dts | 289 +-
 arch/arm/dts/k3-j7200-som-p0.dtsi | 153 --
 arch/arm/dts/k3-j7200-thermal.dtsi|  47 ++
 arch/arm/dts/k3-j7200.dtsi|  30 +-
 arch/arm/mach-k3/j7200/dev-data.c |   1 +
 9 files changed, 1134 insertions(+), 442 deletions(-)
 create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi

diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index f25c7136c9..a00e85e366 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2023 Texas Instruments Incorporated - https://www.ti.com/
  */
 
 #include "k3-j7200-binman.dtsi"
@@ -8,7 +8,7 @@
 / {
chosen {
stdout-path = "serial2:115200n8";
-   tick-timer = 
+   tick-timer = _timer0;
};
 
aliases {
@@ -28,16 +28,12 @@
bootph-pre-ram;
 };
 
-_mcu_wakeup {
+_esm{
bootph-pre-ram;
+};
 
-   timer1: timer@4040 {
-   compatible = "ti,omap5430-timer";
-   reg = <0x0 0x4040 0x0 0x80>;
-   ti,timer-alwon;
-   clock-frequency = <25000>;
-   bootph-pre-ram;
-   };
+_mcu_wakeup {
+   bootph-pre-ram;
 
chipid@4314 {
bootph-pre-ram;
@@ -45,8 +41,6 @@
 
mcu_navss: bus@2838 {
bootph-pre-ram;
-   #address-cells = <2>;
-   #size-cells = <2>;
 
ringacc@2b80 {
reg =   <0x0 0x2b80 0x0 0x40>,
@@ -78,10 +72,6 @@
 
  {
bootph-pre-ram;
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-pre-ram;
-   };
 };
 
 _pds {
@@ -100,6 +90,10 @@
bootph-pre-ram;
 };
 
+_pmx2 {
+   bootph-pre-ram;
+};
+
 _pmx0 {
bootph-pre-ram;
 };
@@ -108,6 +102,10 @@
bootph-pre-ram;
 };
 
+_uart2 {
+   bootph-pre-ram;
+};
+
 _uart0 {
bootph-pre-ram;
 };
@@ -122,52 +120,77 @@
 
 _i2c0 {
bootph-pre-ram;
+
+   lp876441: lp876441@4c {
+   bootph-pre-ram;
+
+   regulators: regulators {
+   bootph-pre-ram;
+
+   buck1_reg: buck1 {
+   bootph-pre-ram;
+   };
+   };
+   };
 };
 
 _i2c0 {
bootph-pre-ram;
+
+   exp1: gpio@20 {
+   bootph-pre-ram;
+   };
+
+   exp2: gpio@22 {
+   bootph-pre-ram;
+   };
 };
 
-_i2c0_pins_default {
+_cpsw {
bootph-pre-ram;
 };
 
- {
+_uart0 {
bootph-pre-ram;
 };
 
-_cpsw {
-   reg = <0x0 0x4600 0x0 0x20>,
- <0x0 0x40f00200 0x0 0x8>;
-   reg-names = "cpsw_nuss", "mac_efuse";
-   /delete-property/ ranges;
-
-   cpsw-phy-sel@40f04040 {
-   compatible = "ti,am654-cpsw-phy-sel";
-   reg= <0x0 0x40f04040 0x0 0x4>;
-   reg-names = "gmii-sel";
-   };
+_i2c0 {
+   bootph-pre-ram;
 };
 
-_usbss0_pins_default {
+_uart0 {
bootph-pre-ram;
 };
 
- {
+ {
bootph-pre-ram;
-   ti,usb2-only;
 };
 
- {
-   dr_mode = "peripheral";
+_uart0_pins_default {
bootph-pre-ram;
 };
 
-_fss0_hpb0_pins_default {
+_mmc1_pins_default {
bootph-pre-ram;
 };
 
- {
+_i2c0_pins_default {
+   bootph-pre-ram;
+};
+
+_i2c0_pins_default {
+   bootph-pre-ram;
+};
+

Re: [PATCHv6 07/14] net/lwip: implement ping cmd

[Simon Glass]

Hi Maxim,

On Fri, 18 Aug 2023 at 03:27, Maxim Uvarov  wrote:
>
>
>
> On Fri, 18 Aug 2023 at 09:10, Simon Glass  wrote:
>>
>> Hi Maxim,
>>
>> On Wed, 16 Aug 2023 at 14:15, Maxim Uvarov  wrote:
>> >
>> >
>> >
>> > On Wed, 16 Aug 2023 at 20:39, Simon Glass  wrote:
>> >>
>> >> Hi Maxim,
>> >>
>> >> On Wed, 16 Aug 2023 at 03:09, Maxim Uvarov  
>> >> wrote:
>> >> >
>> >> > On Wed, 16 Aug 2023 at 14:42, Ilias Apalodimas 
>> >> > 
>> >> > wrote:
>> >> >
>> >> > > On Mon, Aug 14, 2023 at 07:32:46PM +0600, Maxim Uvarov wrote:
>> >> > > >  * can return immediately if previous request was cached or it might
>> >> > > require
>> >> > > > @@ -38,3 +39,28 @@ int ulwip_dhcp(void);
>> >> > > >  * !0 if error
>> >> > > >  */
>> >> > > >  int ulwip_wget(ulong addr, char *url);
>> >> > > > +
>> >> > > > +/**
>> >> > > > + * ulwip_tftp() - load file with tftp
>> >> > > > + *
>> >> > > > + * Load file with tftp to specific address
>> >> > > > + *
>> >> > > > + * @param addr - address to store downloaded file
>> >> > > > + * @param filename - file name on remote tftp server to download
>> >> > >
>> >> > > Please fix function comments properly
>> >> > >
>> >> > > > + *
>> >> > > > + *
>> >> > > > + * @return 0 if success, !0 if error
>> >> > > > + */
>> >> > > > +int ulwip_tftp(ulong addr, const char *filename);
>> >> > > > +
>> >> > > > +/*
>> >> > > > +* This function creates the ping for  address provided in 
>> >> > > > parameters.
>> >> > > > +* After this function you need to invoke the polling
>> >> > > > +* loop to process network communication.
>> >> > > > +*
>> >> > > > +*
>> >> > > > +* @ping_addr  start address to download result
>> >> > > > +* Return: 0 for success
>> >> > > > +* !0 if error
>> >> > > > +*/
>> >> > > > +int ulwip_ping(char *ping_addr);
>> >> > > > diff --git a/net/lwip/Makefile b/net/lwip/Makefile
>> >> > > > index 4c6df94807..8b3e843426 100644
>> >> > > > --- a/net/lwip/Makefile
>> >> > > > +++ b/net/lwip/Makefile
>> >> > > > @@ -67,5 +67,6 @@ obj-$(CONFIG_NET) += port/sys-arch.o
>> >> > > >
>> >> > > >  obj-$(CONFIG_CMD_DHCP) += apps/dhcp/lwip-dhcp.o
>> >> > > >  obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
>> >> > > > +obj-$(CONFIG_CMD_PING) += apps/ping/
>> >> > > >  obj-$(CONFIG_CMD_TFTPBOOT) += apps/tftp/
>> >> > > >  obj-$(CONFIG_CMD_WGET) += apps/http/
>> >> > > > diff --git a/net/lwip/apps/ping/Makefile 
>> >> > > > b/net/lwip/apps/ping/Makefile
>> >> > > > new file mode 100644
>> >> > > > index 00..dc63feb7b5
>> >> > > > --- /dev/null
>> >> > > > +++ b/net/lwip/apps/ping/Makefile
>> >> > > > @@ -0,0 +1,11 @@
>> >> > > > +ccflags-y += -I$(srctree)/net/lwip/port/include
>> >> > > > +ccflags-y += -I$(srctree)/net/lwip/lwip-external/src/include
>> >> > > -I$(srctree)/net/lwip
>> >> > > > +ccflags-y += -I$(obj)
>> >> > > > +
>> >> > > > +.PHONY: $(obj)/ping.c
>> >> > > > +$(obj)/ping.o: $(obj)/ping.c
>> >> > > > +$(obj)/ping.c:
>> >> > > > + cp $(srctree)/net/lwip/lwip-external/contrib/apps/ping/ping.c
>> >> > > $(obj)/ping.c
>> >> > > > +
>> >> > > > +obj-$(CONFIG_CMD_PING) += ping.o
>> >> > > > +obj-$(CONFIG_CMD_PING) += lwip_ping.o
>> >> > > > diff --git a/net/lwip/apps/ping/lwip_ping.c
>> >> > > b/net/lwip/apps/ping/lwip_ping.c
>> >> > > > new file mode 100644
>> >> > > > index 00..611fcaf591
>> >> > > > --- /dev/null
>> >> > > > +++ b/net/lwip/apps/ping/lwip_ping.c
>> >> > > > @@ -0,0 +1,37 @@
>> >> > > > +// SPDX-License-Identifier: GPL-2.0
>> >> > > > +
>> >> > > > +/*
>> >> > > > + * (C) Copyright 2023 Linaro Ltd. 
>> >> > > > + */
>> >> > > > +
>> >> > > > +#include "lwip/opt.h"
>> >> > > > +#include "lwip/ip_addr.h"
>> >> > > > +#include "ping.h"
>> >> > > > +#include "lwip_ping.h"
>> >> > > > +
>> >> > > > +static ip_addr_t ip_target;
>> >> > > > +
>> >> > > > +static int ulwip_ping_tmo(void)
>> >> > > > +{
>> >> > > > +
>> >> > > > + log_err("ping failed; host %s is not alive\n",
>> >> > > ipaddr_ntoa(_target));
>> >> > > > + return 1;
>> >> > > > +}
>> >> > > > +
>> >> > > > +int ulwip_ping(char *ping_addr)
>> >> > > > +{
>> >> > > > + int err;
>> >> > > > +
>> >> > > > + err = ipaddr_aton(ping_addr, _target);
>> >> > > > + if (!err) {
>> >> > > > + log_err("wrong ping addr string \"%s\" \n", 
>> >> > > > ping_addr);
>> >> > >
>> >> > > Invalid ip address is enough
>> >> > >
>> >> > > > + return -1;
>> >> > > > + }
>> >> > > > +
>> >> > > > + ulwip_set_tmo(ulwip_ping_tmo);
>> >> > > > +
>> >> > > > + ping_init(_target);
>> >> > > > + ping_send_now();
>> >> > > > +
>> >> > > > + return 0;
>> >> > > > +}
>> >> > > > diff --git a/net/lwip/apps/ping/lwip_ping.h
>> >> > > b/net/lwip/apps/ping/lwip_ping.h
>> >> > > > new file mode 100644
>> >> > > > index 00..0374f07d9e
>> >> > > > --- /dev/null
>> >> > > > +++ b/net/lwip/apps/ping/lwip_ping.h
>> >> > > > @@ -0,0 +1,15 @@
>> >> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
>> >> > > > +
>> >> > > > +/*
>> >> > > > + * (C) 

Re: [PATCH v2 4/7] qfw: Add flag to allow probing before relocation

[Simon Glass]

Hi Alper,

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:
>
> QEMU firmware config drivers need to be probed to bind the ramfb device.
> The ramfb driver needs to be bound before relocation to properly reserve
> video memory for it, otherwise it cannot be probed after relocation. Add
> the flag to probe QEMU firmware config drivers before relocation so that
> ramfb can work as an initial vidconsole.
>
> Signed-off-by: Alper Nebi Yasak 
> ---
> Alternatively, I guess I could default VIDEO_PCI_DEFAULT_FB_SIZE to a
> higher size with "if VIDEO_RAMFB". But it exists because "PCI drivers
> cannot be bound before relocation unless they are mentioned in the
> devicetree" and qfw is in the QEMU-generated devicetree unlike those, so
> I assumed this would be the preferred way.
>
> Changes in v2:
> - Add patch "qfw: Add flag to allow probing before relocation"
>
>  drivers/misc/qfw.c | 1 +
>  drivers/misc/qfw_mmio.c| 1 +
>  drivers/misc/qfw_pio.c | 1 +
>  drivers/misc/qfw_sandbox.c | 1 +
>  4 files changed, 4 insertions(+)
>
> diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
> index 4e4260982cce..265f45290011 100644
> --- a/drivers/misc/qfw.c
> +++ b/drivers/misc/qfw.c
> @@ -414,6 +414,7 @@ UCLASS_DRIVER(qfw) = {
> .name   = "qfw",
> .post_bind  = qfw_post_bind,
> .per_device_auto= sizeof(struct qfw_dev),
> +   .flags = DM_FLAG_PRE_RELOC,
>  };

Should we add this to the DT instead?

In the case where it isn't present it can return -EPERM.

Regards,
Simon

Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default

[Simon Glass]

Hi Alper,

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:
>
> From: Alexander Graf 
>
> Now that we have everything in place to support ramfb, let's wire it up
> by default in the ARM QEMU targets. That way, you can easily use a
> graphical console by just passing -device ramfb to the QEMU command line.
>
> Signed-off-by: Alexander Graf 
> [Alper: Rebase on bochs changes, add pre-reloc init, error handling]
> Co-developed-by: Alper Nebi Yasak 
> Signed-off-by: Alper Nebi Yasak 
> ---
>
> Changes in v2:
> - Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
> - Drop env changes from ARM (necessary but in prerequisite series)
> - Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
> - Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
> - Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU
>
>  arch/arm/Kconfig|  3 +++
>  board/emulation/qemu-arm/qemu-arm.c | 41 +
>  2 files changed, 44 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 1fd3ccd1607f..7afe26ac804f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1046,6 +1046,9 @@ config ARCH_QEMU
> imply USB_XHCI_PCI
> imply USB_KEYBOARD
> imply CMD_USB
> +   imply VIDEO_RAMFB
> +   imply BOARD_EARLY_INIT_F
> +   imply BOARD_EARLY_INIT_R
>
>  config ARCH_RMOBILE
> bool "Renesas ARM SoCs"
> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> b/board/emulation/qemu-arm/qemu-arm.c
> index 942f1fff5717..23ef31cb7feb 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
>  struct mm_region *mem_map = qemu_arm64_mem_map;
>  #endif
>
> +int board_early_init_f(void)
> +{
> +   struct udevice *dev;
> +   int ret;
> +
> +   /*
> +* Make sure we enumerate the QEMU Firmware device to bind ramfb
> +* so video_reserve() can reserve memory for it.
> +*/
> +   if (IS_ENABLED(CONFIG_QFW)) {
> +   ret = qfw_get_dev();
> +   if (ret) {
> +   log_err("Failed to get QEMU FW device: %d\n", ret);

We should only present an error if the device is present but
failed...so if the user doesn't provide the flag, all should be well.

> +   return ret;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
> +int board_early_init_r(void)
> +{
> +   struct udevice *dev;
> +   int ret;
> +
> +   /*
> +* Make sure we enumerate the QEMU Firmware device to find ramfb
> +* before console_init.
> +*/
> +   if (IS_ENABLED(CONFIG_QFW)) {
> +   ret = qfw_get_dev();
> +   if (ret) {
> +   log_err("Failed to get QEMU FW device: %d\n", ret);
> +   return ret;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
>  int board_init(void)
>  {
> return 0;
> --
> 2.40.1
>

The glue here feels like a bit of a hack...we should rely on normal DT
mechanisms here.

Regards,
Simon

Re: [PATCHv7 02/15] net/lwip: integrate lwIP library

[Simon Glass]

Hi Maxim,

On Tue, 22 Aug 2023 at 03:38, Maxim Uvarov  wrote:
>
> Define Makefile and Kconfig to build lwIP inside the U-Boot. We compile
> lwIP the same as the main code, plus we can do optimization for size at
> compile time with disabling not needed debug asserts, or not used protocols.
> So we can tune lwIP configuration specially for U-Boot environments.
>
> Signed-off-by: Maxim Uvarov 
> ---
>  net/Kconfig   |  3 +++
>  net/Makefile  |  1 +
>  net/lwip/Kconfig  | 55 +++
>  net/lwip/Makefile | 66 +++
>  net/net.c | 20 ++
>  5 files changed, 145 insertions(+)
>  create mode 100644 net/lwip/Kconfig
>  create mode 100644 net/lwip/Makefile
>
> diff --git a/net/Kconfig b/net/Kconfig
> index 4215889127..34c1e43c87 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -5,9 +5,12 @@
>  menuconfig NET
> bool "Networking support"
> default y
> +   imply LWIP
>
>  if NET
>
> +source net/lwip/Kconfig
> +
>  config ARP_TIMEOUT
> int "Milliseconds before trying ARP again"
> default 5000
> diff --git a/net/Makefile b/net/Makefile
> index 3e2d061338..61930c244e 100644
> --- a/net/Makefile
> +++ b/net/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_CMD_WOL)  += wol.o
>  obj-$(CONFIG_PROT_UDP) += udp.o
>  obj-$(CONFIG_PROT_TCP) += tcp.o
>  obj-$(CONFIG_CMD_WGET) += wget.o
> +obj-$(CONFIG_LWIP) += lwip/
>
>  # Disable this warning as it is triggered by:
>  # sprintf(buf, index ? "foo%d" : "foo", index)
> diff --git a/net/lwip/Kconfig b/net/lwip/Kconfig
> new file mode 100644
> index 00..f07e26f7d9
> --- /dev/null
> +++ b/net/lwip/Kconfig
> @@ -0,0 +1,55 @@
> +menu "LWIP"
> +config LWIP
> +   bool "Support LWIP library"
> +   help
> +  Enable the lwIP library code with
> +  all dependencies (commands are implemented with lwIP
> +  library. This option is automatically enabled if CONFIG_NET=y.
> + lwIP library (https://git.savannah.nongnu.org/git/lwip.git) provides
> +  network stack and application code for U-Boot commands.
> + Please see doc/develop/net_lwip.rst for more details.
> +
> +menu "LWIP options"
> +
> +config LWIP_LIB_DEBUG
> +   bool "enable debug"
> +   default n
> +
> +config LWIP_LIB_NOASSERT
> +   bool "disable asserts"
> +   default y
> +   help
> +   Disabling asserts reduces binary size by 16k.
> +
> +config LWIP_LIB_TCP
> +bool "tcp"
> +default y
> +   help
> +  Compile lwIP with TCP protocol support.
> +
> +config LWIP_LIB_UDP
> +bool "udp"
> +default y
> +   help
> +  Compile lwIP with UDP protocol support (needed for TFTP).
> +
> +config LWIP_LIB_DNS
> +bool "dns"
> +default y
> +   help
> +  Compile lwIP with DNS protocol support.
> +
> +config LWIP_LIB_DHCP
> +bool "dhcp"
> +default y
> +   help
> +  Compile lwIP with DHCP protocol support.
> +
> +config LWIP_LIB_LOOPBACK
> +bool "loopback"
> +help
> +  Increases size by 1k.
> +  Compile lwIP with loopback interface support.
> +endmenu
> +
> +endmenu
> diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> new file mode 100644
> index 00..d1161bea78
> --- /dev/null
> +++ b/net/lwip/Makefile
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# (C) Copyright 2023 Linaro Ltd. 
> +
> +LWIPDIR=lwip-external/src
> +
> +ccflags-y += -I$(srctree)/net/lwip/port/include
> +ccflags-y += -I$(srctree)/net/lwip/lwip-external/src/include 
> -I$(srctree)/net/lwip
> +
> +obj-$(CONFIG_NET) += $(LWIPDIR)/core/init.o \
> +   $(LWIPDIR)/core/def.o \

Can we drop the LWIPDIR things? It should use the directory anyway

> +   $(LWIPDIR)/core/dns.o \
> +   $(LWIPDIR)/core/inet_chksum.o \
> +   $(LWIPDIR)/core/ip.o \
> +   $(LWIPDIR)/core/mem.o \
> +   $(LWIPDIR)/core/memp.o \
> +   $(LWIPDIR)/core/netif.o \
> +   $(LWIPDIR)/core/pbuf.o \
> +   $(LWIPDIR)/core/raw.o \
> +   $(LWIPDIR)/core/stats.o \
> +   $(LWIPDIR)/core/sys.o \
> +   $(LWIPDIR)/core/altcp.o \
> +   $(LWIPDIR)/core/altcp_alloc.o \
> +   $(LWIPDIR)/core/altcp_tcp.o \
> +   $(LWIPDIR)/core/tcp.o \
> +   $(LWIPDIR)/core/tcp_in.o \
> +   $(LWIPDIR)/core/tcp_out.o \
> +   $(LWIPDIR)/core/timeouts.o \
> +   $(LWIPDIR)/core/udp.o
> +
> +# IPv4
> +obj-$(CONFIG_NET) += $(LWIPDIR)/core/ipv4/acd.o \
> +$(LWIPDIR)/core/ipv4/autoip.o \
> +$(LWIPDIR)/core/ipv4/dhcp.o \
> +$(LWIPDIR)/core/ipv4/etharp.o \
> +$(LWIPDIR)/core/ipv4/icmp.o \
> +$(LWIPDIR)/core/ipv4/igmp.o \
> +$(LWIPDIR)/core/ipv4/ip4_frag.o \
> +$(LWIPDIR)/core/ipv4/ip4.o \
> +$(LWIPDIR)/core/ipv4/ip4_addr.o
> +# IPv6
> +obj-$(CONFIG_NET) += $(LWIPDIR)/core/ipv6/dhcp6.o \
> +$(LWIPDIR)/core/ipv6/ethip6.o \
> +

Re: [PATCHv7 01/15] net/lwip: add doc/develop/net_lwip.rst

[Simon Glass]

Hi Maxim,

On Tue, 22 Aug 2023 at 03:38, Maxim Uvarov  wrote:
>
> Add initial documentation of lwIP network IP stack integration
> to the U-Boot (net_lwip.rst).
>
> Signed-off-by: Maxim Uvarov 
> Reviewed-by: Simon Glass 
> ---
>  doc/develop/index.rst|  1 +
>  doc/develop/net_lwip.rst | 76 
>  2 files changed, 77 insertions(+)
>  create mode 100644 doc/develop/net_lwip.rst
>
> diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> index 5b230d0321..4764990f25 100644
> --- a/doc/develop/index.rst
> +++ b/doc/develop/index.rst
> @@ -48,6 +48,7 @@ Implementation
> spl
> falcon
> uefi/index
> +   net_lwip
> vbe
> version
>
> diff --git a/doc/develop/net_lwip.rst b/doc/develop/net_lwip.rst
> new file mode 100644
> index 00..cd85de92a1
> --- /dev/null
> +++ b/doc/develop/net_lwip.rst
> @@ -0,0 +1,76 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +LWIP IP stack intergation for U-Boot

spelling

> +
> +
> +Intro
> +-
> +
> +LWIP is a library implementing network protocols, which is commonly used
> +on embedded devices.
> +
> +https://savannah.nongnu.org/projects/lwip/
> +
> +LwIP  license:
> +LwIP is licensed under a BSD-style license: 
> http://lwip.wikia.com/wiki/License.
> +
> +Main features include:
> +
> +* Protocols: IP, IPv6, ICMP, ND, MLD, UDP, TCP, IGMP, ARP, PPPoS, PPPoE
> +
> +* DHCP client, DNS client (incl. mDNS hostname resolver),
> +  AutoIP/APIPA (Zeroconf), SNMP agent (v1, v2c, v3, private MIB support
> +  & MIB compiler)
> +
> +* APIs: specialized APIs for enhanced performance, optional Berkeley-alike
> +  socket API
> +
> +* Extended features: IP forwarding over multiple network interfaces, TCP
> +  congestion control, RTT estimation and fast recovery/fast retransmit
> +
> +* Addon applications: HTTP(S) server, SNTP client, SMTP(S) client, ping,
> +  NetBIOS nameserver, mDNS responder, MQTT client, TFTP server
> +
> +U-Boot implementation details
> +-
> +
> +1. In general we can build lwIP as a library and link it against U-Boot or
> +   compile it in the U-Boot tree in the same way as other U-Boot files. There
> +   are few reasons why second variant was selected: lwIP is very customizable
> +   with defines for features, memory size, types of allocation, some internal
> +   types and platform specific code. It turned out easier to enable/disable
> +   debug which is also done with defines, and is needed periodically.
> +
> +2. lwIP has 2 APIs - raw mode and sequential (as lwIP names it, or socket API
> +   as we name it in Linux). For now only raw API is supported.
> +
> +In raw IP mode a callback function for RX path is registered and will be 
> called
> +when packet is passed to the IP stack and is ready for the application.
> +
> +One example is the unmodified working ping example from lwip sources which
> +registered the callback:
> +
> +.. code-block:: c
> +
> +ping_pcb = raw_new(IP_PROTO_ICMP);
> +raw_recv(ping_pcb, ping_recv, NULL); <- ping_recv is app callback.
> +raw_bind(ping_pcb, IP_ADDR_ANY)
> +
> +3.  Input and output
> +
> +RX packet path is injected to U-Boot eth_rx() polling loop and TX patch is in
> +eth_send() accordingly. That way we can leave the driver code unmodified and
> +consume packets once they are ready. So we do not touch any drivers code and
> +just eat packets when they are ready.
> +
> +U-Boot lwIP Applications
> +
> +
> +.. kernel-doc:: include/net/lwip.h
> +   :internal:
> +
> +lwIP API to control polling loop
> +
> +
> +.. kernel-doc:: include/net/ulwip.h
> +   :internal:
> --
> 2.30.2
>

Regards,
Simon

Re: [PATCHv7 05/15] net/lwip: implement tftp cmd

[Simon Glass]

Hi Maxim,

On Tue, 22 Aug 2023 at 03:39, Maxim Uvarov  wrote:
>
> U-Boot recently got support for an alternative network stack using LWIP.
> Replace tftp command with the LWIP variant while keeping the output and
> error messages identical.
>
> Signed-off-by: Maxim Uvarov 
> ---
>  include/net/lwip.h |  14 +++-
>  net/lwip/Makefile  |   1 +
>  net/lwip/apps/tftp/Makefile|  16 +
>  net/lwip/apps/tftp/lwip-tftp.c | 124 +
>  4 files changed, 154 insertions(+), 1 deletion(-)
>  create mode 100644 net/lwip/apps/tftp/Makefile
>  create mode 100644 net/lwip/apps/tftp/lwip-tftp.c
>
> diff --git a/include/net/lwip.h b/include/net/lwip.h
> index 240ebba354..14a65470ee 100644
> --- a/include/net/lwip.h
> +++ b/include/net/lwip.h
> @@ -28,4 +28,16 @@ int ulwip_dns(char *name, char *varname);
>   * Returns: 0 if success
>   * Other value < 0, if error
>  */
> -int ulwip_dhcp(void);
> +
> +/**
> + * ulwip_tftp() - load file with tftp
> + *
> + * Load file with tftp to specific address
> + *
> + * @addr: Address to store downloaded file
> + * @filename: File name on remote tftp server to download
> + *
> + *
> + * Returns:  0 if success, !0 if error
> + */
> +int ulwip_tftp(ulong addr, const char *filename);

Does this load it, or initiate the load? When will this function return?

Please check your return values too. I believe they should all return
errno values, so -ve on error, rather than !0

> diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> index 59323fb325..0337d82cf5 100644
> --- a/net/lwip/Makefile
> +++ b/net/lwip/Makefile
> @@ -67,3 +67,4 @@ obj-$(CONFIG_NET) += port/sys-arch.o
>
>  obj-$(CONFIG_CMD_DHCP) += apps/dhcp/lwip-dhcp.o
>  obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
> +obj-$(CONFIG_CMD_TFTPBOOT) += apps/tftp/

We should separate the CMD configs from the functionality, i.e. I
should be able to have CONFIG_TFTPBOOT but not CONFIG_CMD_TFTPBOOT.
For standard boot, we need to be able to boot without CONFIG_CMDLINE
enabled.

This merging of CMD and functionality CONFIG options has historically
been a problem in U-Boot, but it is mostly tidied up now.

> diff --git a/net/lwip/apps/tftp/Makefile b/net/lwip/apps/tftp/Makefile
> new file mode 100644
> index 00..0e50fcad45
> --- /dev/null
> +++ b/net/lwip/apps/tftp/Makefile
> @@ -0,0 +1,16 @@
> +
> +ccflags-y += -I$(srctree)/net/lwip/port/include
> +ccflags-y += -I$(srctree)/net/lwip/lwip-external/src/include 
> -I$(srctree)/net/lwip
> +ccflags-y += -I$(obj)

Should we move this to

> +
> +$(obj)/tftp.o: $(obj)/tftp.c
> +.PHONY: $(obj)/tftp.c
> +$(obj)/tftp.c:
> +   cp $(srctree)/net/lwip/lwip-external/src/apps/tftp/tftp.c 
> $(obj)/tftp.c
> +   cp 
> $(srctree)/net/lwip/lwip-external/src/include/lwip/apps/tftp_client.h 
> $(obj)/tftp_client.h
> +   cp 
> $(srctree)/net/lwip/lwip-external/src/include/lwip/apps/tftp_common.h 
> $(obj)/tftp_common.h
> +   cp 
> $(srctree)/net/lwip/lwip-external/contrib/examples/tftp/tftp_example.h 
> $(obj)/tftp_example.h

What is going on here?

> +
> +obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
> +obj-$(CONFIG_CMD_TFTPBOOT) += lwip-tftp.o
> +
> diff --git a/net/lwip/apps/tftp/lwip-tftp.c b/net/lwip/apps/tftp/lwip-tftp.c
> new file mode 100644
> index 00..e6e4883de8
> --- /dev/null
> +++ b/net/lwip/apps/tftp/lwip-tftp.c
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * (C) Copyright 2023 Linaro Ltd. 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "lwip/apps/tftp_client.h"
> +#include "lwip/apps/tftp_server.h"

Can we add a -I to the top-level Makefile so we can use #include
 ?

> +#include 
> +
> +#include 

Should go up  the top

> +
> +#include 
> +
> +static ulong daddr;
> +static ulong size;

Again please see if you can keep your state together rather than
sprinkling it around static vars.

> +
> +static void *tftp_open(const char *fname, const char *mode, u8_t is_write)
> +{
> +   LWIP_UNUSED_ARG(mode);
> +   return NULL;
> +}
> +
> +static void tftp_close(void *handle)
> +{
> +   log_info("\ndone\n");
> +   log_info("Bytes transferred = %ld (0x%lx hex)\n", size, size);
> +
> +   bootstage_mark_name(BOOTSTAGE_KERNELREAD_STOP, "tftp_done");
> +   env_set_ulong("filesize", size);

Error check...

> +   ulwip_exit(0);
> +}
> +
> +static int tftp_read(void *handle, void *buf, int bytes)
> +{
> +   return 0;
> +}
> +
> +static int tftp_write(void *handle, struct pbuf *p)
> +{
> +   struct pbuf *q;
> +
> +   for (q = p; q != NULL; q = q->next) {
> +   memcpy((void *)daddr, q->payload, q->len);
> +   daddr += q->len;
> +   size += q->len;
> +   log_info("#");
> +   }
> +
> +   return 0;
> +}
> +
> +static void tftp_error(void *handle, int err, const char *msg, int size)
> +{
> +   char message[100];
> +
> +   LWIP_UNUSED_ARG(handle);



> +
> +   memset(message, 0, 

Re: [PATCHv7 04/15] net/lwip: implement dhcp cmd

[Simon Glass]

Hi Maxim,

On Tue, 22 Aug 2023 at 03:39, Maxim Uvarov  wrote:
>
> U-Boot recently got support for an alternative network stack using LWIP.
> Replace dhcp command with the LWIP variant while keeping the output and
> error messages identical.
>
> Signed-off-by: Maxim Uvarov 
> ---
>  include/net/lwip.h | 12 +++
>  net/lwip/Makefile  |  1 +
>  net/lwip/apps/dhcp/lwip-dhcp.c | 62 ++
>  3 files changed, 75 insertions(+)
>  create mode 100644 net/lwip/apps/dhcp/lwip-dhcp.c
>
> diff --git a/include/net/lwip.h b/include/net/lwip.h
> index cda896d062..240ebba354 100644
> --- a/include/net/lwip.h
> +++ b/include/net/lwip.h
> @@ -17,3 +17,15 @@ int do_lwip_dns(struct cmd_tbl *cmdtp, int flag, int argc,
>   * Other value < 0, if error
>   */
>  int ulwip_dns(char *name, char *varname);
> +
> +/**
> + * ulwip_dhcp() -  create the DHCP request to obtain IP address.
> + *
> + * This function creates the DHCP request to obtain IP address. If DHCP 
> server
> + * returns file name, this file will be downloaded with tftp.  After this
> + * function you need to invoke the polling loop to process network 
> communication.
> + *
> + * Returns: 0 if success
> + * Other value < 0, if error

So this is an errno value from errno.h ?

> +*/
> +int ulwip_dhcp(void);
> diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> index 6d2c00605b..59323fb325 100644
> --- a/net/lwip/Makefile
> +++ b/net/lwip/Makefile
> @@ -65,4 +65,5 @@ obj-$(CONFIG_NET) += $(LWIPDIR)/netif/ethernet.o
>  obj-$(CONFIG_NET) += port/if.o
>  obj-$(CONFIG_NET) += port/sys-arch.o
>
> +obj-$(CONFIG_CMD_DHCP) += apps/dhcp/lwip-dhcp.o
>  obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
> diff --git a/net/lwip/apps/dhcp/lwip-dhcp.c b/net/lwip/apps/dhcp/lwip-dhcp.c
> new file mode 100644
> index 00..cce1e367f9
> --- /dev/null
> +++ b/net/lwip/apps/dhcp/lwip-dhcp.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * (C) Copyright 2023 Linaro Ltd. 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static struct dhcp dhcp;

Can we keep the state in the uclass?

> +
> +static int ulwip_dhcp_tmo(void)
> +{
> +   switch (dhcp.state) {
> +   case DHCP_STATE_BOUND:
> +   env_set("bootfile", dhcp.boot_file_name);
> +   env_set("ipaddr", ip4addr_ntoa(_ip_addr));
> +   env_set("netmask", ip4addr_ntoa(_sn_mask));
> +   env_set("serverip", ip4addr_ntoa(_ip_addr));

Please check errors throughout your patches.

> +   printf("DHCP client bound to address %s\n", 
> ip4addr_ntoa(_ip_addr));
> +   break;
> +   default:
> +   return -1;
> +   }
> +
> +   return 0;
> +}
> +
> +int ulwip_dhcp(void)
> +{
> +   int err;
> +   struct netif *netif;
> +   int eth_idx;
> +
> +   eth_idx = eth_get_dev_index();
> +   if (eth_idx < 0) {
> +   log_err("no eth idx\n");
> +   return -1;

That is -EPERM...please use a suitable error, perhaps -ENOENT?

> +   }
> +
> +   netif = netif_get_by_index(eth_idx + 1);
> +   if (!netif)
> +   return -1;
> +
> +   ulwip_set_tmo(ulwip_dhcp_tmo);
> +
> +   if (!netif_get_client_data(netif, LWIP_NETIF_CLIENT_DATA_INDEX_DHCP))
> +   dhcp_set_struct(netif, );
> +
> +   err = dhcp_start(netif);
> +   if (err)
> +   log_err("dhcp_start error %d\n", err);

Ideally the caller would print the errors. We try to have commands do
that, since then it allows silent running for things which want it. It
also helps with code size.

> +
> +   return err;
> +}
> --
> 2.30.2
>

Regards,
Simon

Re: [PATCHv7 03/15] net/lwip: implement dns cmd

[Simon Glass]

Hi Maxim,

On Tue, 22 Aug 2023 at 03:39, Maxim Uvarov  wrote:
>
> U-Boot recently got support for an alternative network stack using LWIP.
> Replace dns command with the LWIP variant while keeping the output and
> error messages identical.
>
> Signed-off-by: Maxim Uvarov 
> ---
>  include/net/lwip.h   | 19 +++
>  net/lwip/Makefile|  2 ++
>  net/lwip/apps/dns/lwip-dns.c | 46 
>  3 files changed, 67 insertions(+)
>  create mode 100644 include/net/lwip.h
>  create mode 100644 net/lwip/apps/dns/lwip-dns.c
>
> diff --git a/include/net/lwip.h b/include/net/lwip.h
> new file mode 100644
> index 00..cda896d062
> --- /dev/null
> +++ b/include/net/lwip.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +int do_lwip_dns(struct cmd_tbl *cmdtp, int flag, int argc,
> +   char *const argv[]);

Please make sure you comment all exported functions, including the return value.

> +
> +/**
> + * ulwip_dns() - creates the DNS request to resolve a domain host name
> + *
> + * This function creates the DNS request to resolve a domain host name. 
> Function
> + * can return immediately if previous request was cached or it might require
> + * entering the polling loop for a request to a remote server.
> + *
> + * @name:dns name to resolve
> + * @varname: (optional) U-Boot variable name to store the result
> + * Returns: ERR_OK(0) for fetching entry from the cache
> + * ERR_INPROGRESS(-5) success, can go to the polling loop
> + * Other value < 0, if error
> + */
> +int ulwip_dns(char *name, char *varname);
> diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> index d1161bea78..6d2c00605b 100644
> --- a/net/lwip/Makefile
> +++ b/net/lwip/Makefile
> @@ -64,3 +64,5 @@ obj-$(CONFIG_NET) += $(LWIPDIR)/netif/ethernet.o
>
>  obj-$(CONFIG_NET) += port/if.o
>  obj-$(CONFIG_NET) += port/sys-arch.o
> +
> +obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
> diff --git a/net/lwip/apps/dns/lwip-dns.c b/net/lwip/apps/dns/lwip-dns.c
> new file mode 100644
> index 00..6e205c1153
> --- /dev/null
> +++ b/net/lwip/apps/dns/lwip-dns.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * (C) Copyright 2023 Linaro Ltd. 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +static void dns_found_cb(const char *name, const ip_addr_t *ipaddr, void 
> *callback_arg)
> +{
> +   char *varname = (char *)callback_arg;
> +
> +   if (varname)
> +   env_set(varname, ip4addr_ntoa(ipaddr));
> +
> +   log_info("resolved %s to %s\n",  name, ip4addr_ntoa(ipaddr));
> +   ulwip_exit(0);
> +}
> +
> +int ulwip_dns(char *name, char *varname)
> +{
> +   int err;
> +   ip_addr_t ipaddr; /* not used */
> +   ip_addr_t dns1;
> +   ip_addr_t dns2;
> +
> +   ipaddr_aton(env_get("dnsip"), );
> +   ipaddr_aton(env_get("dnsip2"), );

What if the env_get() fails? Won't that return NULL?

> +
> +   dns_init();
> +   dns_setserver(0, );
> +   dns_setserver(1, );

Can either of these fail?

Please be very attentive to error-checking.

> +
> +   err = dns_gethostbyname(name, , dns_found_cb, varname);
> +   if (err == ERR_OK)

Is that 0? If so, then if (err) is better

> +   dns_found_cb(name, , varname);
> +
> +   return err;

I am not sure what that is, but will review it when you add the header comments.

> +}
> --
> 2.30.2
>

Regards,
Simon

Re: [PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver

[Simon Glass]

Hi Alexey,

On Tue, 22 Aug 2023 at 06:59, Alexey Romanov
 wrote:
>
> Hi,
>
> On Tue, Aug 22, 2023 at 10:24:23AM +0200, neil.armstr...@linaro.org wrote:
> > On 21/08/2023 21:11, Simon Glass wrote:
> > > Hi Neil,
> > >
> > > On Mon, 21 Aug 2023 at 03:16, neil.armstr...@linaro.org
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 16/07/2023 01:40, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, 13 Jul 2023 at 23:30, AKASHI Takahiro
> > > > >  wrote:
> > > > > >
> > > > > > On Tue, Jul 11, 2023 at 01:13:29PM -0600, Simon Glass wrote:
> > > > > > > +AKASHI Takahiro
> > > > > >
> > > > > > Me?
> > > > >
> > > > > Yes, I'm asking for your help to try to clean this stuff up.
> > > >
> > > > The thread is long and hard to answer directly, but as AKASHI
> > > > said there's no point to add a SMC class since it's only the message
> > > > passing instruction, and there's no point using remoteproc since the
> > > > firmware runs on a separate secure state of the same CPU.
> > > >
> > > > And I don't see how we can actually define a finite set of ops because
> > > > none of the secure firmware interfaces has even similar functions.
> > > >
> > > > So a new UCLASS for each firmware interface should be added, not sure
> > > > this is scalable or required since those firmwares are mainly SoC or
> > > > vendor specific, except the PSCI or other ARM specific interfaces of 
> > > > course.
> > > >
> > > > So I think UCLASS_FIRMWARE is good enough since it avoids using 
> > > > UCLASS_MISC,
> > > > but it should be probably documented somewhere that the ops are 
> > > > implementation
> > > > defined.
> > >
> > > Yes it needs docs...but what exactly is the 'firmware' uclass? I
> > > assumed it was for loading firmware into a device, but it seems that
> > > it is something else?
> >
> > Nop, it's based on the same "firmware" naming as Linux, which is an 
> > interface
> > with a system control firmware like PSCI, SCPI... not to interact with 
> > loadable
> > co-processors.
> >
> > Systems do have multiple interfaces implemented like PSCI, SCPI, OPTEE and 
> > other
> > vendor specific ones like Alexey is changing, all via the same instruction 
> > call.
> >
> > >
> > > Perhaps we should have a UCLASS_SVC (supervisor call) or something
> > > like that, rather than continuing with firmware?
>
> You propose to create UCLASS with an interface consisting of functions
> of something like: ->smc_call(), ->hvc_call()? In this case, it seems
> ARM specific.

Yes, but we have a lot of arch-specific interfaces.

>
> Or UCLASS with only one callback, different for different archs, which
> will call the hypervisor or something like that. In my understanding,
> this add-on are redundant.

OK.

>
> I still think UCLASS firmware is the best fit for my Secure Monitor
> implementation at the moment.

How about you create a UCLASS_MESON_SM then?

I don't really like the idea of a uclass with no standard API. One
goal is to help people understand things and can't see that helping.

>
> >
> > I have no opinion on that, I don't think the call type is significant here.
> >
> > Neil
> >
> > >
> > > [..]
> > >
> > > Regards,
> > > Simon
> >
>
> --
> Thank you,
> Alexey

Regards,
Simon

Re: [PATCH 1/1] lib: parameter check in hash_calculate

[Simon Glass]

On Tue, 22 Aug 2023 at 02:43, Heinrich Schuchardt
 wrote:
>
> If hash_calculate is invoked with region_count = 0, it will try to hash
> INT_MAX regions. We should check this parameter.
>
> * Avoid a comparison with different signedness.
> * Check that region_count is at least 1.
> * Avoid a superfluous assignment.
>
> Fixes: b37b46f042cc ("rsa: Use checksum algorithms from struct hash_algo")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/hash-checksum.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v2 7/7] x86: qemu: Enable ramfb by default

[Simon Glass]

Hi Alper,

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:
>
> Now that we have everything in place to support ramfb, let's wire it up
> by default in the x86 QEMU targets. That way, we can use ramfb graphical
> console instead of the default by passing -vga none -device ramfb to the
> QEMU command line.
>
> Also increase SYS_MALLOC_F_LEN for QEMU x86_64 to be the same as its SPL
> counterpart, because we're running out of alloc space in pre-reloc stage
> with ramfb enabled.
>
> Signed-off-by: Alper Nebi Yasak 
> ---
> This also suffers from the same issue with distros as the Bochs display
> driver [1], where it results in a hang after GRUB menu selection before
> the kernel can display anything. Couldn't reproduce on arm*/riscv*.

Yes I see that problem too. I wonder how we can debug it?

>
> But just having it enabled doesn't seem to cause problems unless you run
> QEMU with -device ramfb, so this (unlike the Bochs video driver) can
> actually be co-enabled with VIDEO_VESA.

Indeed...which makes me wonder if we can do something similar with
Bochs, so that (from the cmdline) it is possible to chose ramfb, bochs
or vesa?

>
> [1] https://lore.kernel.org/u-boot/20230724145210.304917-4-...@chromium.org/
>
> Changes in v2:
> - Add patch "x86: qemu: Enable ramfb by default"
>
>  arch/x86/cpu/qemu/Kconfig   |  4 +++
>  board/emulation/qemu-x86/qemu-x86.c | 47 +
>  configs/qemu-x86_64_defconfig   |  4 +--
>  configs/qemu-x86_defconfig  |  1 -
>  4 files changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig
> index f8f2f6473088..e0a57ac2d687 100644
> --- a/arch/x86/cpu/qemu/Kconfig
> +++ b/arch/x86/cpu/qemu/Kconfig
> @@ -13,6 +13,10 @@ config QEMU
> imply USB
> imply USB_EHCI_HCD
> imply VIDEO_VESA
> +   imply VIDEO_RAMFB
> +   imply BOARD_EARLY_INIT_F
> +   imply BOARD_EARLY_INIT_R
> +   imply CMD_QFW
>
>  if QEMU
>
> diff --git a/board/emulation/qemu-x86/qemu-x86.c 
> b/board/emulation/qemu-x86/qemu-x86.c
> index e69de29bb2d1..3a8a580cc591 100644
> --- a/board/emulation/qemu-x86/qemu-x86.c
> +++ b/board/emulation/qemu-x86/qemu-x86.c
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int board_early_init_f(void)
> +{
> +   struct udevice *dev;
> +   int ret;
> +
> +   /*
> +* Make sure we enumerate the QEMU Firmware device to bind ramfb
> +* so video_reserve() can reserve memory for it.
> +*/
> +   if (IS_ENABLED(CONFIG_QFW)) {
> +   ret = qfw_get_dev();
> +   if (ret) {
> +   log_err("Failed to get QEMU FW device: %d\n", ret);
> +   return ret;
> +   }
> +   }
> +
> +   return 0;

Same point about DT here.

> +}
> +
> +int board_early_init_r(void)
> +{
> +   struct udevice *dev;
> +   int ret;
> +
> +   /*
> +* Make sure we enumerate the QEMU Firmware device to find ramfb
> +* before console_init.
> +*/
> +   if (IS_ENABLED(CONFIG_QFW)) {
> +   ret = qfw_get_dev();
> +   if (ret) {
> +   log_err("Failed to get QEMU FW device: %d\n", ret);
> +   return ret;
> +   }
> +   }
> +
> +   return 0;
> +}
> diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
> index c6f30674a8fc..c9ad6eebd35c 100644
> --- a/configs/qemu-x86_64_defconfig
> +++ b/configs/qemu-x86_64_defconfig
> @@ -1,13 +1,12 @@
>  CONFIG_X86=y
>  CONFIG_TEXT_BASE=0x111
> -CONFIG_SYS_MALLOC_F_LEN=0x1000
> +CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_NR_DRAM_BANKS=8
>  CONFIG_ENV_SIZE=0x4
>  CONFIG_MAX_CPUS=2
>  CONFIG_SPL_DM_SPI=y
>  CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
>  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
> @@ -59,7 +58,6 @@ CONFIG_CMD_USB=y
>  CONFIG_BOOTP_BOOTFILESIZE=y
>  CONFIG_CMD_EFIDEBUG=y
>  CONFIG_CMD_TIME=y
> -CONFIG_CMD_QFW=y

What is happening here? Why disable it?

>  CONFIG_CMD_BOOTSTAGE=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_ENV_OVERWRITE=y
> diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
> index 24682a5387df..8a2311720f02 100644
> --- a/configs/qemu-x86_defconfig
> +++ b/configs/qemu-x86_defconfig
> @@ -37,7 +37,6 @@ CONFIG_CMD_USB=y
>  CONFIG_BOOTP_BOOTFILESIZE=y
>  CONFIG_CMD_EFIDEBUG=y
>  CONFIG_CMD_TIME=y
> -CONFIG_CMD_QFW=y
>  CONFIG_CMD_BOOTSTAGE=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_MAC_PARTITION=y
> --
> 2.40.1
>

Regards,
Simon

Re: [PATCH v5 00/13] Add video damage tracking

[Simon Glass]

Hi Alex,

On Tue, 22 Aug 2023 at 01:47, Alexander Graf  wrote:
>
>
> On 22.08.23 01:03, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 21 Aug 2023 at 16:40, Alexander Graf  wrote:
> >>
> >> On 22.08.23 00:10, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 21 Aug 2023 at 14:20, Alexander Graf  wrote:
>  On 21.08.23 21:57, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 21 Aug 2023 at 13:33, Alexander Graf  wrote:
> >> On 21.08.23 21:11, Simon Glass wrote:
> >>> Hi Alper,
> >>>
> >>> On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak 
> >>>  wrote:
>  This is a rebase of Alexander Graf's video damage tracking series, 
>  with
>  some tests and other changes. The original cover letter is as 
>  follows:
> 
> > This patch set speeds up graphics output on ARM by a factor of 60x.
> >
> > On most ARM SBCs, we keep the frame buffer in DRAM and map it as 
> > cached,
> > but need it accessible by the display controller which reads 
> > directly
> > from a later point of consistency. Hence, we flush the frame buffer 
> > to
> > DRAM on every change. The full frame buffer.
> >>> It should not, see below.
> >>>
> > Unfortunately, with the advent of 4k displays, we are seeing frame 
> > buffers
> > that can take a while to flush out. This was reported by Da Xue 
> > with grub,
> > which happily print 1000s of spaces on the screen to draw a menu. 
> > Every
> > printed space triggers a cache flush.
> >>> That is a bug somewhere in EFI.
> >> Unfortunately not :). You may call it a bug in grub: It literally 
> >> prints
> >> over space characters for every character in its menu that it wants
> >> cleared. On every text screen draw.
> >>
> >> This wouldn't be a big issue if we only flush the reactangle that gets
> >> modified. But without this patch set, we're flushing the full DRAM
> >> buffer on every u-boot text console character write, which means for
> >> every character (as that's the only API UEFI has).
> >>
> >> As a nice side effect, we speed up the normal U-Boot text console as
> >> well with this patch set, because even "normal" text prints that write
> >> for example a single line of text on the screen today flush the full
> >> frame buffer to DRAM.
> > No, I mean that it is a bug that U-Boot (apparently) flushes the cache
> > after every character. It doesn't do that for normal character output
> > and I don't think it makes sense to do it for EFI either.
>  I see. Let's trace the calls:
> 
>  efi_cout_output_string()
>  -> fputs()
>  -> vidconsole_puts()
>  -> video_sync()
>  -> flush_dcache_range()
> 
>  Unfortunately grub abstracts character backends down to the "print
>  character" level, so it calls UEFI's sopisticated "output_string"
>  callback with single characters at a time, which means we do a full
>  dcache flush for every character that we print:
> 
>  https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/efi/console.c#n165
> 
> 
> > This patch set implements the easiest mitigation against this 
> > problem:
> > Damage tracking. We remember the lowest common denominator region 
> > that was
> > touched since the last video_sync() call and only flush that. The 
> > most
> > typical writer to the frame buffer is the video console, which 
> > always
> > writes rectangles of characters on the screen and syncs afterwards.
> >
> > With this patch set applied, we reduce drawing a large grub menu 
> > (with
> > serial console attached for size information) on an RK3399-ROC 
> > system
> > at 1440p from 55 seconds to less than 1 second.
> >
> > Version 2 also implements VIDEO_COPY using this mechanism, reducing 
> > its
> > overhead compared to before as well. So even x86 systems should be 
> > faster
> > with this now :).
> >
> >
> > Alternatives considered:
> >
> >   1) Lazy sync - Sandbox does this. It only calls 
> > video_sync(true) ever
> >  so often. We are missing timers to do this generically.
> >
> >   2) Double buffering - We could try to identify whether 
> > anything changed
> >  at all and only draw to the FB if it did. That would 
> > require
> >  maintaining a second buffer that we need to scan.
> >
> >   3) Text buffer - Maintain a buffer of all text printed on the 
> > screen with
> >  respective location. Don't write if the old and new 
> > character are
> >  

Re: [PATCH v2 6/7] riscv: qemu: Enable ramfb by default

[Simon Glass]

Hi Alper,

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:
>
> From: Alexander Graf 
>
> Now that we have everything in place to support ramfb, let's wire it up
> by default in the RISC-V QEMU targets. That way, you can easily use a
> graphical console by just passing -device ramfb to the QEMU command line.
>
> Signed-off-by: Alexander Graf 
> [Alper: Rebase on bochs changes, add pre-reloc init and error handling]
> Co-developed-by: Alper Nebi Yasak 
> Signed-off-by: Alper Nebi Yasak 
> ---
>
> Changes in v2:
> - Drop imply VIDEO, env changes from RISC-V patch (in u-boot/next)
> - Drop imply SYS_CONSOLE_IS_IN_ENV from RISC-V patch (def. y if VIDEO)
> - Probe QFW in RISC-V QEMU board_early_init_f to bind ramfb pre-reloc
> - Add IS_ENABLED(CONFIG_QFW) check and error handling to RISC-V QEMU
>
>  board/emulation/qemu-riscv/Kconfig  |  5 +++
>  board/emulation/qemu-riscv/qemu-riscv.c | 41 +
>  2 files changed, 46 insertions(+)

Again, please investigate DT mechanism which will work for all archs.

Regards,
Simon

Re: [PATCH 1/1] cmd: setexpr: fix printf_str()

[Simon Glass]

On Tue, 22 Aug 2023 at 04:21, Heinrich Schuchardt
 wrote:
>
> If vsnprintf() returns a negative number, (i >= remaining) will
> possibly be true:
>
> 'i' is of type signed int and 'remaining' is of the unsigned type size_t.
> The C language will convert i to an unsigned type before the comparison.
>
> This can result in the wrong error type being indicated.
>
> Checking for negative i should be done first.
>
> Fixes: f4f8d8bb1abc ("cmd: setexpr: add format string handling")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/printf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH v2 3/7] qfw: Spawn ramfb device if its file is present

[Simon Glass]

Hi Alper,

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:
>
> From: Alexander Graf 
>
> Now that we have a ramfb device driver, let's add the necessary glueing
> magic to also spawn it when we find its qfw file node.

So then how do we select which video driver is used? I think we should
have this in the DT so there is some control.

>
> Signed-off-by: Alexander Graf 
> [Alper: Use if IS_ENABLED() instead of #ifdef]
> Signed-off-by: Alper Nebi Yasak 
> ---
>
> Changes in v2:
> - Use if (IS_ENABLED(CONFIG_VIDEO_RAMFB)) instead of #ifdef
>
>  drivers/misc/qfw.c | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
> index 7c01bf23d53b..4e4260982cce 100644
> --- a/drivers/misc/qfw.c
> +++ b/drivers/misc/qfw.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -307,6 +308,27 @@ void qfw_read_entry(struct udevice *dev, u16 entry, u32 
> size, void *address)
> qfw_read_entry_io(qdev, entry, size, address);
>  }
>
> +static void qfw_bind_ramfb(struct udevice *dev)
> +{
> +   struct fw_file *file;
> +   int ret;
> +
> +   if (!IS_ENABLED(CONFIG_VIDEO_RAMFB))
> +   return;

Needs an error-code return

> +
> +   ret = qfw_read_firmware_list(dev);
> +   if (ret)
> +   return;
> +
> +   file = qfw_find_file(dev, "etc/ramfb");
> +   if (!file) {
> +   /* No ramfb available. */
> +   return;
> +   }
> +
> +   device_bind_driver(dev, "ramfb", "qfw-ramfb", NULL);

check error

> +}
> +
>  int qfw_register(struct udevice *dev)
>  {
> struct qfw_dev *qdev = dev_get_uclass_priv(dev);
> @@ -323,6 +345,8 @@ int qfw_register(struct udevice *dev)
> if (dma_enabled & FW_CFG_DMA_ENABLED)
> qdev->dma_present = true;
>
> +   qfw_bind_ramfb(dev);
> +
> return 0;
>  }
>
> --
> 2.40.1
>

Regards,
Simon

Re: [PATCH v2 2/7] ramfb: Add driver for ramfb display

[Simon Glass]

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:
>
> From: Alexander Graf 
>
> QEMU implements multiple ways to expose graphics output to the virt
> machine, but most of them are incompatible with hardware virtualization.
>
> The one that does work reliably is ramfb. It's a very simple mechanism
> in which the guest reserves a memory region for the frame buffer and then
> notifies the host about its location and properties. The host then just
> displays the contents of the frame buffer on screen.
>
> This patch implements a trivial version of a ramfb driver - hard coded
> to a single resolution set in Kconfig.
>
> Signed-off-by: Alexander Graf 
> [Alper: Deduplicate depends on DM_VIDEO, drop MAINTAINERS, decouple from
> EFI_LOADER, add .bind(), kconfigurable resolution, struct in .h]
> Co-developed-by: Alper Nebi Yasak 
> Signed-off-by: Alper Nebi Yasak 
> ---
>
> Changes in v2:
> - Remove extra "depends on DM_VIDEO" already in "if VIDEO"
> - Drop drivers/video/MAINTAINERS file
> - Decouple framebuffer allocation from EFI_LOADER
> - Add .bind() method for ramfb driver
> - Make resolution configurable with kconfig
> - Move struct to qfw.h and add comments for members
> - Use RAMFB_* definitions instead of DEFAULT_*
>
>  drivers/video/Kconfig  | 30 +
>  drivers/video/Makefile |  1 +
>  drivers/video/ramfb.c  | 97 ++
>  include/qfw.h  | 10 +
>  4 files changed, 138 insertions(+)
>  create mode 100644 drivers/video/ramfb.c

Reviewed-by: Simon Glass 

[PATCH 2/2] doc: Highlight the most relevant u-boot talks

[Paul Barker]

The list of u-boot talks on elinux.org is quite long, so let's highlight
the talks which are likely most relevant for newcomers.

Signed-off-by: Paul Barker 
---
 doc/learn/talks.rst | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/doc/learn/talks.rst b/doc/learn/talks.rst
index 33bac483e178..0bb44aeabe55 100644
--- a/doc/learn/talks.rst
+++ b/doc/learn/talks.rst
@@ -3,9 +3,18 @@
 U-Boot Talks
 
 
-U-Boot is a topic at various conferences each year. These talkes might help you
-learn a bit about U-Boot.
+U-Boot is a topic at various conferences each year. These talks might help you
+learn a bit about U-Boot:
 
-See elinux_talks_ for a list.
+* `Tutorial: Introduction to the Embedded Boot Loader U-boot - Behan Webster,
+  Converse in Code `__
+  from Embedded Linux Conference 2020
+  (`slides 
`__).
+
+* `Recent Advances in U-Boot - Simon Glass, Google Inc.
+  `__
+  from Embedded Linux Conference 2023.
+
+See elinux_talks_ for a more comprehensive list.
 
 .. _elinux_talks: https://elinux.org/Boot_Loaders#U-Boot
-- 
2.34.1

[PATCH 1/2] doc: Explicitly list build dependencies for docs

[Paul Barker]

Highlight the packages which need to be installed in order to build the
docs.

Signed-off-by: Paul Barker 
---
 doc/build/documentation.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/doc/build/documentation.rst b/doc/build/documentation.rst
index 011cd34a57c0..20b0fefa2d88 100644
--- a/doc/build/documentation.rst
+++ b/doc/build/documentation.rst
@@ -5,6 +5,17 @@ Building documentation
 
 The U-Boot documentation is based on the Sphinx documentation generator.
 
+In addition to the Python packages listed in ``doc/sphinx/requirements.txt``,
+the following dependencies are needed to build the documentation:
+
+* fontconfig
+
+* graphviz
+
+* imagemagick
+
+* texinfo (if building the `Infodoc documentation`_)
+
 HTML documentation
 --
 
-- 
2.34.1

Re: [PATCH v2] schemas: Add a schema for memory map

[Rob Herring]

On Mon, Aug 21, 2023 at 2:48 PM Simon Glass  wrote:
>
> The Devicespec specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.

It's more that the DT spec defines what is not used with UEFI. If UEFI
covers more than the DT Spec defined, then we should look at that.

I would look some into (IBM) PowerPC for any prior art in this area.
Unfortunately, not publicly documented other than any users.

> It is common to split firmware into 'Platform Init', which does the
> initial hardware setup and a "Payload" which selects the OS to be booted.
> Thus an handover interface is required between these two pieces.
>
> Where UEFI boot-time services are not available, but UEFI firmware is
> present on either side of this interface, information about memory usage
> and attributes must be presented to the "Payload" in some form.
>
> This aims to provide an initial schema for this mapping.
>
> Note that this is separate from the existing /memory and /reserved-memory
> nodes, since it is mostly concerned with what the memory is used for. It
> may cover only a small fraction of available memory, although it could be
> used to signal which area of memory has ECC.
>
> For now, no attempt is made to create an exhaustive binding, so there are
> some example types lists. This can be completed once this has passed
> initial review.

I don't have much interest in picking this up unless there's some
wider agreement. From the previously referenced discussion[1], it
didn't seem like there was. But none of those folk are Cc'ed here.

> ---
>
> Changes in v2:
> - Reword commit message
>
>  dtschema/schemas/memory-map.yaml | 51 
>  1 file changed, 51 insertions(+)
>  create mode 100644 dtschema/schemas/memory-map.yaml
>
> diff --git a/dtschema/schemas/memory-map.yaml 
> b/dtschema/schemas/memory-map.yaml
> new file mode 100644
> index 000..97e531e
> --- /dev/null
> +++ b/dtschema/schemas/memory-map.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: BSD-2-Clause
> +# Copyright 2023 Google LLC
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-map.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: /memory-map nodes
> +description: |
> +  Common properties always required in /memory-map nodes. These nodes are
> +  intended to resolve the nonchalant clause 3.4.1 ("/memory node and UEFI")
> +  in the Devicetree Specification.
> +
> +maintainers:
> +  - Simon Glass 
> +
> +properties:
> +  $nodename:
> +const: '/'

This goes in the root node?

> +  usage:
> +$ref: /schemas/types.yaml#/definitions/string
> +description: |
> +  Describes the usage of the memory region, e.g.:
> +
> +"acpi-reclaim", "acpi-nvs", "bootcode", "bootdata", "bootdata",
> +"runtime-code", "runtime-data"

Can't these be covered by reserved-memory? The client is free to
reclaim any regions if it knows what they are.

> +  attr:
> +$ref: /schemas/types.yaml#/definitions/string-array
> +description: |
> +  Attributes possessed by this memory region:
> +
> +"single-bit-ecc" - supports single-bit ECC
> +"multi-bit-ecc" - supports multiple-bit ECC
> +"no-ecc" - non-ECC memory

Isn't this pretty much a property of a memory region as a whole. IOW,
couldn't it just go into /memory node(s)?

> +
> +patternProperties:
> +  "^([a-z][a-z0-9\\-]+@[0-9a-f]+)?$":
> +type: object
> +additionalProperties: false
> +
> +properties:
> +  reg:
> +minItems: 1
> +maxItems: 1024
> +
> +required:
> +  - reg
> +
> +additionalProperties: true
> +
> +...
> --
> 2.42.0.rc1.204.g551eb34607-goog

[1] 
https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyun...@bytedance.com/

[PATCH] doc: board: ti: k3: Fix up OpenOCD references and debug info

[Nishanth Menon]

From: Jonathan Humphreys 

Fix minor path and config macro name updates to sync with latest
OpenOCD and U-Boot configurations.

Fixes: effe50854a69 ("doc: board: ti: k3: Add a guide to debugging with 
OpenOCD")
Signed-off-by: Jonathan Humphreys 
Signed-off-by: Nishanth Menon 
---
Cc: Heinrich Schuchardt 

 doc/board/ti/k3.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index 83fb0f121bb9..f9336b3a3622 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -601,7 +601,7 @@ correctly to ensure a sane system.
   $ cd openocd
   # Copy the udev rules to the correct system location
   $ sudo cp ./contrib/60-openocd.rules \
-  ./src/JTAG/drivers/libjaylink/contrib/99-libjaylink.rules \
+  ./src/jtag/drivers/libjaylink/contrib/99-libjaylink.rules \
   /etc/udev/rules.d/
   # Get Udev to load the new rules up
   $ sudo udevadm control --reload-rules
@@ -792,7 +792,7 @@ Code modification
   In this example, we will debug ``board_init_f`` inside
   ``arch/arm/mach-k3/{soc}_init.c``. Since some sections of U-Boot
   will be executed multiple times during the bootup process of K3
-  devices, we will need to include either ``CONFIG_CPU_ARM64`` or
+  devices, we will need to include either ``CONFIG_ARM64`` or
   ``CONFIG_CPU_V7R`` to catch the CPU at the desired place during the
   bootup process (Main or Wakeup domains). For example, modify the
   file as follows (depending on need):
@@ -810,7 +810,7 @@ Code modification
   }
   ...
   /* Code to run on the ARMV8 (Main Domain) */
-  if (IS_ENABLED(CONFIG_CPU_ARM64)) {
+  if (IS_ENABLED(CONFIG_ARM64)) {
   volatile int x = 1;
   while(x) {};
   }
-- 
2.40.0

[PATCH V4 6/8] arm: dts: Add k3-am625-beagleplay

[Nishanth Menon]

From: Robert Nelson 

BeagleBoard.org BeaglePlay is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM625
SoC that allows you to create connected devices that work even at long
distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L.
Expansion is provided over open standards based mikroBUS, Grove and
QWIIC headers among other interfaces.

This board family can be identified by the 24c32 eeprom:

[aa 55 33 ee 01 37 00 10  2e 00 42 45 41 47 4c 45  |.U3..7BEAGLE|]
[50 4c 41 59 2d 41 30 2d  00 00 30 32 30 30 37 38  |PLAY-A0-..020078|]

https://beagleplay.org/
https://git.beagleboard.org/beagleplay/beagleplay

baseline of base device tree is v6.5-rc1.

Reviewed-by: Tom Rini 
Signed-off-by: Robert Nelson 
Co-developed-by: Nishanth Menon 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* Added LEDs to u-boot.dtsi boot phase properties and default to be on.
* Dropped the slowing down of emmc and sd
* Retaining Tom's reviewed-by unless there is a concern.

V3: https://lore.kernel.org/all/20230815164440.2713726-3...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-3...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-5...@ti.com/
 arch/arm/dts/Makefile |2 +
 .../dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi | 2195 +
 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi  |  196 ++
 arch/arm/dts/k3-am625-beagleplay.dts  |  758 ++
 arch/arm/dts/k3-am625-r5-beagleplay.dts   |   87 +
 board/ti/am62x/MAINTAINERS|7 +
 6 files changed, 3245 insertions(+)
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay.dts
 create mode 100644 arch/arm/dts/k3-am625-r5-beagleplay.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85fd5b1157b1..bd61a3527082 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1334,6 +1334,8 @@ dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
 
 dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
  k3-am625-r5-sk.dtb \
+ k3-am625-beagleplay.dtb \
+ k3-am625-r5-beagleplay.dtb \
  k3-am625-verdin-wifi-dev.dtb \
  k3-am625-verdin-r5.dtb
 
diff --git a/arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi 
b/arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
new file mode 100644
index ..3d7a41c27d7e
--- /dev/null
+++ b/arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
@@ -0,0 +1,2195 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * https://beagleboard.org/play
+ *
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
+ *
+ * This file was generated with the
+ * AM62x SysConfig DDR Subsystem Register Configuration Tool v0.09.06
+ * Thu Feb 09 2023 11:57:18 GMT-0600 (Central Standard Time)
+ * DDR Part number: K4AAG165WA-BCWE K4A4G165WF-BCTD
+ * DDR Type: DDR4
+ * Frequency = 800MHz (1600MTs)
+ * Density: 16Gb
+ * Number of Ranks: 1
+ */
+
+#define DDRSS_PLL_FHS_CNT 6
+#define DDRSS_PLL_FREQUENCY_1 4
+#define DDRSS_PLL_FREQUENCY_2 4
+
+#define DDRSS_CTL_0_DATA 0x0A00
+#define DDRSS_CTL_1_DATA 0x
+#define DDRSS_CTL_2_DATA 0x
+#define DDRSS_CTL_3_DATA 0x
+#define DDRSS_CTL_4_DATA 0x
+#define DDRSS_CTL_5_DATA 0x
+#define DDRSS_CTL_6_DATA 0x
+#define DDRSS_CTL_7_DATA 0x000890B8
+#define DDRSS_CTL_8_DATA 0x
+#define DDRSS_CTL_9_DATA 0x
+#define DDRSS_CTL_10_DATA 0x
+#define DDRSS_CTL_11_DATA 0x000890B8
+#define DDRSS_CTL_12_DATA 0x
+#define DDRSS_CTL_13_DATA 0x
+#define DDRSS_CTL_14_DATA 0x
+#define DDRSS_CTL_15_DATA 0x000890B8
+#define DDRSS_CTL_16_DATA 0x
+#define DDRSS_CTL_17_DATA 0x
+#define DDRSS_CTL_18_DATA 0x
+#define DDRSS_CTL_19_DATA 0x01010100
+#define DDRSS_CTL_20_DATA 0x01000100
+#define DDRSS_CTL_21_DATA 0x01000110
+#define DDRSS_CTL_22_DATA 0x02010002
+#define DDRSS_CTL_23_DATA 0x00027100
+#define DDRSS_CTL_24_DATA 0x00061A80
+#define DDRSS_CTL_25_DATA 0x04000400
+#define DDRSS_CTL_26_DATA 0x0400
+#define DDRSS_CTL_27_DATA 0x
+#define DDRSS_CTL_28_DATA 0x
+#define DDRSS_CTL_29_DATA 0x
+#define DDRSS_CTL_30_DATA 0x
+#define DDRSS_CTL_31_DATA 0x
+#define DDRSS_CTL_32_DATA 0x
+#define DDRSS_CTL_33_DATA 0x
+#define DDRSS_CTL_34_DATA 0x
+#define DDRSS_CTL_35_DATA 0x
+#define DDRSS_CTL_36_DATA 0x
+#define DDRSS_CTL_37_DATA 0x
+#define DDRSS_CTL_38_DATA 0x0400091C
+#define DDRSS_CTL_39_DATA 0x1C1C1C1C
+#define DDRSS_CTL_40_DATA 0x0400091C
+#define DDRSS_CTL_41_DATA 0x1C1C1C1C
+#define DDRSS_CTL_42_DATA 

[PATCH V4 8/8] doc: board: ti: Add BeaglePlay documentation

[Nishanth Menon]

Add base documentation for BeaglePlay

Signed-off-by: Nishanth Menon 
---
Cc: Heinrich Schuchardt 

Changes Since V3:
* Updated documentation to give a more clear overview of MMC partitions
  and flashing information.
* Added OpenOCD debug documentation
* Added LED status information and indication of various boot stages

V3: https://lore.kernel.org/all/20230815164440.2713726-5...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-5...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-7...@ti.com/

 doc/board/ti/am62x_beagleplay.rst| 256 ++
 doc/board/ti/img/beagleplay_emmc.svg | 697 +++
 doc/board/ti/k3.rst  |   1 +
 3 files changed, 954 insertions(+)
 create mode 100644 doc/board/ti/am62x_beagleplay.rst
 create mode 100644 doc/board/ti/img/beagleplay_emmc.svg

diff --git a/doc/board/ti/am62x_beagleplay.rst 
b/doc/board/ti/am62x_beagleplay.rst
new file mode 100644
index ..5adb7b4c9ace
--- /dev/null
+++ b/doc/board/ti/am62x_beagleplay.rst
@@ -0,0 +1,256 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Nishanth Menon 
+
+AM62x Beagleboard.org Beagleplay
+
+
+Introduction:
+-
+
+BeagleBoard.org BeaglePlay is an easy to use, affordable open source
+hardware single board computer based on the Texas Instruments AM625
+SoC that allows you to create connected devices that work even at long
+distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L.
+Expansion is provided over open standards based mikroBUS, Grove and
+QWIIC headers among other interfaces.
+
+Further information can be found at:
+
+* Product Page: https://beagleplay.org/
+* Hardware documentation: https://git.beagleboard.org/beagleplay/beagleplay
+
+Boot Flow:
+--
+Below is the pictorial representation of boot flow:
+
+.. image:: img/boot_diagram_k3_current.svg
+  :alt: Boot flow diagram
+
+- On this platform, 'TI Foundational Security' (TIFS) functions as the
+  security enclave master while 'Device Manager' (DM), also known as the
+  'TISCI server' in "TI terminology", offers all the essential services.
+  The A53/M4F (Aux core) sends requests to TIFS/DM to accomplish these
+  services, as illustrated in the diagram above.
+
+Sources:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_boot_sources
+:end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure:
+
+0. Setup the environment variables:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_desc
+:end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_board_env_vars_desc
+:end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_defn
+:end-before: .. k3_rst_include_end_common_env_vars_defn
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config"
+ $ export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config"
+ $ export TFA_BOARD=lite
+ $ # we dont use any extra TFA parameters
+ $ unset TFA_EXTRA_ARGS
+ $ export OPTEE_PLATFORM=k3-am62x
+ $ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
+
+.. include::  am62x_sk.rst
+:start-after: .. am62x_evm_rst_include_start_build_steps
+:end-before: .. am62x_evm_rst_include_end_build_steps
+
+Target Images
+--
+Copy the below images to an SD card and boot:
+
+* tiboot3-am62x-gp-evm.bin from R5 build as tiboot3.bin
+* tispl.bin_unsigned from Cortex-A build as tispl.bin
+* u-boot.img_unsigned from Cortex-A build as uboot.img
+
+Image formats:
+--
+
+- tiboot3.bin
+
+.. image:: img/multi_cert_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
+
+- tispl.bin
+
+.. image:: img/dm_tispl.bin.svg
+  :alt: tispl.bin image format
+
+Flash to eMMC
+-
+
+The eMMC layout selected is user-friendly for developers. The
+boot hardware partition of the eMMC only contains the fixed-size
+tiboot3.bin image. This is because the contents of the boot partitions
+need to run from the SoC's internal SRAM, which remains a fixed size
+constant. The other components of the boot sequence, such as tispl.bin
+and u-boot.img, are located in the /BOOT partition in the User Defined
+Area (UDA) hardware partition of the eMMC. These components can vary
+significantly in size, so readjusting the boot partition offsets is
+not practical.
+
+.. image:: img/beagleplay_emmc.svg
+  :alt: eMMC partitions and boot file organization for BeaglePlay
+
+The following are the steps from Linux shell to program eMMC:
+
+.. code-block:: bash
+
+  # # Enable Boot0 boot
+  # mmc bootpart enable 1 2 /dev/mmcblk0
+  # mmc bootbus set single_backward x1 x8 /dev/mmcblk0
+  # mmc hwreset enable /dev/mmcblk0
+
+  # # Clear eMMC boot0
+  # echo 

[PATCH V4 4/8] drivers: mmc: am654_sdhci: Update OTAP/ITAP delay

[Nishanth Menon]

From: Nitin Yadav 

U-Boot is fail to boot class U1 UHS SD cards (such as microcenter)
due to incorrect OTAP and ITAP delay select values. Update OTAP and
ITAP delay select values based on recommeded RIOT values to fix boot
issue.

Signed-off-by: Nitin Yadav 
Signed-off-by: Nishanth Menon 
---
Picked up from TI u-boot
New patch in the series

 drivers/mmc/am654_sdhci.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index fd667aeafdaa..d0b51c0707d4 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -442,12 +442,18 @@ static int j721e_4bit_sdhci_set_ios_post(struct 
sdhci_host *host)
 {
struct udevice *dev = host->mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
-   u32 otap_del_sel, mask, val;
+   u32 otap_del_sel, itap_del_sel, mask, val;
 
otap_del_sel = plat->otap_del_sel[host->mmc->selected_mode];
-   mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
-   val = (1 << OTAPDLYENA_SHIFT) | (otap_del_sel << OTAPDLYSEL_SHIFT);
+   itap_del_sel = plat->itap_del_sel[host->mmc->selected_mode];
+   mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK | ITAPDLYSEL_MASK |
+   ITAPDLYENA_MASK;
+   val = (1 << OTAPDLYENA_SHIFT) | (otap_del_sel << OTAPDLYSEL_SHIFT) |
+   (1 << ITAPDLYENA_SHIFT) | (itap_del_sel << ITAPDLYSEL_SHIFT);
+   regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
+  1 << ITAPCHGWIN_SHIFT);
regmap_update_bits(plat->base, PHY_CTRL4, mask, val);
+   regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK, 0);
 
regmap_update_bits(plat->base, PHY_CTRL5, CLKBUFSEL_MASK,
   plat->clkbuf_sel);
@@ -501,7 +507,7 @@ static int sdhci_am654_get_otap_delay(struct udevice *dev,
 * Remove the corresponding capability if an otap-del-sel
 * value is not found
 */
-   for (i = MMC_HS; i <= MMC_HS_400; i++) {
+   for (i = MMC_LEGACY; i <= MMC_HS_400; i++) {
ret = dev_read_u32(dev, td[i].otap_binding,
   >otap_del_sel[i]);
if (ret) {
-- 
2.40.0

[PATCH V4 5/8] arm: dts: k3-am625-sk-binman: Add labels for unsigned binary

[Nishanth Menon]

Add labels for unsigned binary to permit over-ride.

Signed-off-by: Nishanth Menon 
---
Cc: Simon Glass 

Changes since V3: None

V3: https://lore.kernel.org/all/20230815164440.2713726-2...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-2...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-3...@ti.com/
 arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi 
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index a35d6418c25f..41277bf4bfdb 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -389,7 +389,7 @@
type = "flat_dt";
arch = "arm";
compression = "none";
-   blob {
+   spl_am625_sk_dtb_unsigned: blob {
filename = SPL_AM625_SK_DTB;
};
};
@@ -438,7 +438,7 @@
type = "flat_dt";
arch = "arm";
compression = "none";
-   blob {
+   am625_sk_dtb_unsigned: blob {
filename = AM625_SK_DTB;
};
hash {
-- 
2.40.0

[PATCH V4 0/8] board: ti: Add support for BeaglePlay

[Nishanth Menon]

Hi,

Add support for BeaglePlay - rev 4

Full series: https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v4.2

Caveats:
* networking: pending 
https://lore.kernel.org/all/20230822121350.51324-1-rog...@kernel.org/
* 32kclk and usb: pending:
  https://lore.kernel.org/u-boot/20230725185253.2123433-4...@ti.com/
  OR 
https://github.com/nmenon/fix-k3-dt-u-boot/commit/853b29d63c1ca642be316f1afb0fb778610dec46
  being properly resolved (NOTE: without this patch, wlan is broken in
  Linux as the 32kclk from SoC is incorrectly supplied to wlan as 25MHz)
* There seems to be a bug in Linux kernel with sdhci that seems to
  depend on u-boot initialization of sdhci for functionality.

Changes since V3:
* GPIO, LEDs, PMIC enabled at u-boot level.
* eMMC boot fixed in a manner not to break existing SK and other EVM
  solutions. UDA FS solution similar to commit 5019170970ad
  ("arch: arm: mach-k3: j721e: add support for UDA FS") introduced.
* env file for beagleplay introduced to keep things consistent with the
  behavior expected on BeaglePlay
* Documentation updates to fixup alt, references, added OpenOCD debug
  info etc.
* New patch to ensure env files have priority over header included env
  variables.

Bootlog:
emmc with no SD: https://gist.github.com/nmenon/5755228ff424c55245f4534548827ab9
emmc with SD: https://gist.github.com/nmenon/8571dba9e942e77e48e52fe59cf71aac
SD boot: https://gist.github.com/nmenon/1cc850c37469fe7c86b26842fe0910f8

Baseline: 7e6e40c57233 (origin/next) Merge tag 'v2023.10-rc3' into next

V3: https://lore.kernel.org/all/20230815164440.2713726-1...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-1...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-1...@ti.com/

Nishanth Menon (6):
  env_default: Allow CONFIG_EXTRA_ENV_TEXT to override
CFG_EXTRA_ENV_SETTINGS
  configs: am62x_evm*: Enable EMMC_BOOT configuration
  arm: mach-k3: am625: Add support for UDA FS
  arm: dts: k3-am625-sk-binman: Add labels for unsigned binary
  board: ti: am62x: Add am62x_beagleplay_* defconfigs and env file
  doc: board: ti: Add BeaglePlay documentation

Nitin Yadav (1):
  drivers: mmc: am654_sdhci: Update OTAP/ITAP delay

Robert Nelson (1):
  arm: dts: Add k3-am625-beagleplay

 arch/arm/dts/Makefile |2 +
 .../dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi | 2195 +
 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi  |  196 ++
 arch/arm/dts/k3-am625-beagleplay.dts  |  758 ++
 arch/arm/dts/k3-am625-r5-beagleplay.dts   |   87 +
 arch/arm/dts/k3-am625-sk-binman.dtsi  |4 +-
 arch/arm/mach-k3/am625_init.c |6 +
 board/ti/am62x/MAINTAINERS|7 +
 board/ti/am62x/beagleplay.env |   23 +
 board/ti/am62x/beagleplay_a53.config  |   55 +
 board/ti/am62x/beagleplay_r5.config   |   15 +
 configs/am62x_evm_a53_defconfig   |1 +
 configs/am62x_evm_r5_defconfig|1 +
 doc/board/ti/am62x_beagleplay.rst |  256 ++
 doc/board/ti/img/beagleplay_emmc.svg  |  697 ++
 doc/board/ti/k3.rst   |1 +
 drivers/mmc/am654_sdhci.c |   14 +-
 include/env_default.h |6 +-
 18 files changed, 4315 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay.dts
 create mode 100644 arch/arm/dts/k3-am625-r5-beagleplay.dts
 create mode 100644 board/ti/am62x/beagleplay.env
 create mode 100644 board/ti/am62x/beagleplay_a53.config
 create mode 100644 board/ti/am62x/beagleplay_r5.config
 create mode 100644 doc/board/ti/am62x_beagleplay.rst
 create mode 100644 doc/board/ti/img/beagleplay_emmc.svg

-- 
2.40.0

[PATCH V4 1/8] env_default: Allow CONFIG_EXTRA_ENV_TEXT to override CFG_EXTRA_ENV_SETTINGS

[Nishanth Menon]

CFG_EXTRA_ENV_SETTINGS is set in common board config files, This allows
for majority of the settings to be set in a common manner. However, the
minor variations between various board can be addressed by the board.env
files. The board.env files are converted into CONFIG_EXTRA_ENV_TEXT.

However, this creates a minor problem. For example:
distro_bootcmd.h and used by ti_armv7_common.h uses it as:
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
func(MMC, mmc, 1)

Which in turn generates:
boot_targets=mmc0 mmc1

And this probably works fine for most boards, However when the
boot_targets need to be reversed, the preferred behavior would have been
to define it in board.env file as:
boot_targets=mmc1 mmc0

By changing the order of the inclusion, we allow for the
CONFIG_EXTRA_ENV_TEXT to have a higher priority in the definition.

Signed-off-by: Nishanth Menon 
---
Cc: Simon Glass 

New patch

 include/env_default.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/env_default.h b/include/env_default.h
index b16c22d5a28c..714dfa9e845e 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -112,12 +112,12 @@ const char default_environment[] = {
 #ifdef CONFIG_MTDPARTS_DEFAULT
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"
 #endif
+#ifdef CFG_EXTRA_ENV_SETTINGS
+   CFG_EXTRA_ENV_SETTINGS
+#endif
 #ifdef CONFIG_EXTRA_ENV_TEXT
/* This is created in the Makefile */
CONFIG_EXTRA_ENV_TEXT
-#endif
-#ifdef CFG_EXTRA_ENV_SETTINGS
-   CFG_EXTRA_ENV_SETTINGS
 #endif
"\0"
 #else /* CONFIG_USE_DEFAULT_ENV_FILE */
-- 
2.40.0

[PATCH V4 3/8] arm: mach-k3: am625: Add support for UDA FS

[Nishanth Menon]

While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.

In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.

So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.

If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.

Signed-off-by: Nishanth Menon 
---
New patch
 arch/arm/mach-k3/am625_init.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 0e5d44269ebf..ad61030a56fa 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -228,7 +228,13 @@ u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 
boot_device)
 
switch (bootmode) {
case BOOT_DEVICE_EMMC:
+#if CONFIG_IS_ENABLED(SUPPORT_EMMC_BOOT)
+   return (spl_mmc_emmc_boot_partition(mmc) ? MMCSD_MODE_EMMCBOOT 
: MMCSD_MODE_FS);
+#elif defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
+   return MMCSD_MODE_FS;
+#else
return MMCSD_MODE_EMMCBOOT;
+#endif
case BOOT_DEVICE_MMC:
if (bootmode_cfg & MAIN_DEVSTAT_PRIMARY_MMC_FS_RAW_MASK)
return MMCSD_MODE_RAW;
-- 
2.40.0

[PATCH V4 7/8] board: ti: am62x: Add am62x_beagleplay_* defconfigs and env file

[Nishanth Menon]

Add defconfig fragments for am625 based beagleplay and corresponding
customized environment file for beagleplay.

Signed-off-by: Nishanth Menon 
---
Changes:
* new env file to override boot targets, led sequence etc.
* config files updates for GPIO, I2C etc for A53.
* Speed up of A53 mmc support.

V3: https://lore.kernel.org/all/20230815164440.2713726-4...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-4...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-6...@ti.com/
 board/ti/am62x/beagleplay.env| 23 
 board/ti/am62x/beagleplay_a53.config | 55 
 board/ti/am62x/beagleplay_r5.config  | 15 
 3 files changed, 93 insertions(+)
 create mode 100644 board/ti/am62x/beagleplay.env
 create mode 100644 board/ti/am62x/beagleplay_a53.config
 create mode 100644 board/ti/am62x/beagleplay_r5.config

diff --git a/board/ti/am62x/beagleplay.env b/board/ti/am62x/beagleplay.env
new file mode 100644
index ..8f39fb214333
--- /dev/null
+++ b/board/ti/am62x/beagleplay.env
@@ -0,0 +1,23 @@
+#include 
+#include 
+
+default_device_tree=ti/k3-am625-beagleplay.dtb
+findfdt=
+   setenv name_fdt ${default_device_tree};
+   setenv fdtfile ${name_fdt}
+name_kern=Image
+console=ttyS2,115200n8
+args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
+   ${mtdparts}
+run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+set_led_state_fail_load= led led-0 off; led led-1 on;
+   led led-2 off; led led-3 on; led led-4 off
+set_led_state_start_load=led led-0 on; led led-1 off;
+   led led-2 on; led led-3 off; led led-4 on
+boot=mmc
+mmcdev=1
+bootpart=1:1
+bootdir=/boot
+boot_targets=mmc1 mmc0 usb pxe
+bootmeths=extlinux efi
+rd_spec=-
diff --git a/board/ti/am62x/beagleplay_a53.config 
b/board/ti/am62x/beagleplay_a53.config
new file mode 100644
index ..967f794446dd
--- /dev/null
+++ b/board/ti/am62x/beagleplay_a53.config
@@ -0,0 +1,55 @@
+# Defconfig fragment to apply on top of am62x_evm_a53_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-beagleplay"
+CONFIG_OF_LIST="k3-am625-beagleplay"
+CONFIG_SPL_OF_LIST="k3-am625-beagleplay"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot; run 
distro_bootcmd;run set_led_state_fail_load"
+CONFIG_EXT4_WRITE=y
+CONFIG_LZO=y
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
+CONFIG_AUTOBOOT_DELAY_STR="d"
+CONFIG_AUTOBOOT_STOP_STR=" "
+# Use the Beagleplay env file
+CONFIG_ENV_SOURCE_FILE="beagleplay"
+# Do not use emmc boot - we will use FS only
+CONFIG_SUPPORT_EMMC_BOOT=n
+CONFIG_MMC_IO_VOLTAGE=y
+# CONFIG_SPL_MMC_IO_VOLTAGE is not set
+CONFIG_MMC_UHS_SUPPORT=y
+# CONFIG_SPL_MMC_UHS_SUPPORT is not set
+CONFIG_MMC_HS200_SUPPORT=y
+# CONFIG_SPL_MMC_HS200_SUPPORT is not set
+# Enable GPIO control
+CONFIG_DM_GPIO=y
+CONFIG_SPL_GPIO=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPIO_READ=y
+# Enable LEDs
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_SPL_LED=y
+CONFIG_SPL_LED_GPIO=y
+# Enable I2C bus
+CONFIG_SPL_I2C=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_CMD_I2C=y
+# Regulator
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_DM_REGULATOR_TPS65219=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_TPS65219=y
+CONFIG_CMD_PMIC=y
+# Uses Realtek phy rather than TI phy
+CONFIG_PHY_TI_DP83867=n
+CONFIG_PHY_REALTEK=y
+# No SPI flash on Beagleplay
+CONFIG_SPI=n
+CONFIG_SPI_FLASH=n
+CONFIG_SPL_DM_SPI_FLASH=n
+CONFIG_SPL_SPI_FLASH_SUPPORT=n
diff --git a/board/ti/am62x/beagleplay_r5.config 
b/board/ti/am62x/beagleplay_r5.config
new file mode 100644
index ..4ee0375a2a1d
--- /dev/null
+++ b/board/ti/am62x/beagleplay_r5.config
@@ -0,0 +1,15 @@
+# Defconfig fragment to apply on top of:
+# am62x_evm_r5_defconfig
+#
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-beagleplay"
+CONFIG_OF_LIST="k3-am625-r5-beagleplay"
+CONFIG_SPL_OF_LIST="k3-am625-r5-beagleplay"
+# Do spl board init
+CONFIG_SPL_BOARD_INIT=y
+# Do not use emmc boot - we will use FS only
+CONFIG_SUPPORT_EMMC_BOOT=n
+# No SPI flash on Beagleplay
+CONFIG_SPI=n
+CONFIG_SPI_FLASH=n
+CONFIG_SPL_DM_SPI_FLASH=n
+CONFIG_SPL_SPI_FLASH_SUPPORT=n
-- 
2.40.0

[PATCH V4 2/8] configs: am62x_evm*: Enable EMMC_BOOT configuration

[Nishanth Menon]

Enable EMMC boot support for AM62x evm base configuration.

Signed-off-by: Nishanth Menon 
---
New patch

 configs/am62x_evm_a53_defconfig | 1 +
 configs/am62x_evm_r5_defconfig  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index d55caabe22c9..824a99b9b6cc 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -69,6 +69,7 @@ CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
 CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
+CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_SPL_MMC_SDHCI_ADMA=y
diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig
index 3c5f36729842..489ee943fe31 100644
--- a/configs/am62x_evm_r5_defconfig
+++ b/configs/am62x_evm_r5_defconfig
@@ -92,6 +92,7 @@ CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
 CONFIG_SPL_MISC=y
 CONFIG_ESM_K3=y
+CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_SPL_MMC_SDHCI_ADMA=y
-- 
2.40.0

Re: [PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver

[Alexey Romanov]

Hi,

On Tue, Aug 22, 2023 at 10:24:23AM +0200, neil.armstr...@linaro.org wrote:
> On 21/08/2023 21:11, Simon Glass wrote:
> > Hi Neil,
> > 
> > On Mon, 21 Aug 2023 at 03:16, neil.armstr...@linaro.org
> >  wrote:
> > > 
> > > Hi,
> > > 
> > > On 16/07/2023 01:40, Simon Glass wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 13 Jul 2023 at 23:30, AKASHI Takahiro
> > > >  wrote:
> > > > > 
> > > > > On Tue, Jul 11, 2023 at 01:13:29PM -0600, Simon Glass wrote:
> > > > > > +AKASHI Takahiro
> > > > > 
> > > > > Me?
> > > > 
> > > > Yes, I'm asking for your help to try to clean this stuff up.
> > > 
> > > The thread is long and hard to answer directly, but as AKASHI
> > > said there's no point to add a SMC class since it's only the message
> > > passing instruction, and there's no point using remoteproc since the
> > > firmware runs on a separate secure state of the same CPU.
> > > 
> > > And I don't see how we can actually define a finite set of ops because
> > > none of the secure firmware interfaces has even similar functions.
> > > 
> > > So a new UCLASS for each firmware interface should be added, not sure
> > > this is scalable or required since those firmwares are mainly SoC or
> > > vendor specific, except the PSCI or other ARM specific interfaces of 
> > > course.
> > > 
> > > So I think UCLASS_FIRMWARE is good enough since it avoids using 
> > > UCLASS_MISC,
> > > but it should be probably documented somewhere that the ops are 
> > > implementation
> > > defined.
> > 
> > Yes it needs docs...but what exactly is the 'firmware' uclass? I
> > assumed it was for loading firmware into a device, but it seems that
> > it is something else?
> 
> Nop, it's based on the same "firmware" naming as Linux, which is an interface
> with a system control firmware like PSCI, SCPI... not to interact with 
> loadable
> co-processors.
> 
> Systems do have multiple interfaces implemented like PSCI, SCPI, OPTEE and 
> other
> vendor specific ones like Alexey is changing, all via the same instruction 
> call.
> 
> > 
> > Perhaps we should have a UCLASS_SVC (supervisor call) or something
> > like that, rather than continuing with firmware?

You propose to create UCLASS with an interface consisting of functions
of something like: ->smc_call(), ->hvc_call()? In this case, it seems
ARM specific.

Or UCLASS with only one callback, different for different archs, which
will call the hypervisor or something like that. In my understanding, 
this add-on are redundant.

I still think UCLASS firmware is the best fit for my Secure Monitor
implementation at the moment.

> 
> I have no opinion on that, I don't think the call type is significant here.
> 
> Neil
> 
> > 
> > [..]
> > 
> > Regards,
> > Simon
> 

-- 
Thank you,
Alexey

[PATCH 2/2] serial: sh: Tidy up pre-processor directive indentation

[Paul Barker]

Let's make the indentation of pre-processor macros and conditionals in
serial_sh.h consistent before we add to the confusion with a new SoC.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
---
 drivers/serial/serial_sh.h | 84 +++---
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/serial/serial_sh.h b/drivers/serial/serial_sh.h
index 149ec1fe7397..3109c5a946b9 100644
--- a/drivers/serial/serial_sh.h
+++ b/drivers/serial/serial_sh.h
@@ -116,9 +116,9 @@ struct uart_port {
defined(CONFIG_CPU_SH7751R) || \
defined(CONFIG_CPU_SH7763)  || \
defined(CONFIG_CPU_SH7780)
-#define SCI_CTRL_FLAGS_REIE 0x08 /* 7750 SCIF */
+# define SCI_CTRL_FLAGS_REIE 0x08 /* 7750 SCIF */
 #else
-#define SCI_CTRL_FLAGS_REIE 0
+# define SCI_CTRL_FLAGS_REIE 0
 #endif
 /* SCI_CTRL_FLAGS_MPIE 0x08  * 7707 SCI, 7708 SCI, 7709 SCI, 7750 
SCI */
 /* SCI_CTRL_FLAGS_TEIE 0x04  * 7707 SCI, 7708 SCI, 7709 SCI, 7750 
SCI */
@@ -174,7 +174,7 @@ struct uart_port {
 #endif
 
 #ifndef SCIF_ORER
-#define SCIF_ORER  0x
+# define SCIF_ORER 0x
 #endif
 
 #define SCxSR_TEND(port)\
@@ -282,45 +282,45 @@ static inline void sci_##name##_out(struct uart_port 
*port,\
}
 
 #if defined(CONFIG_R8A7740)
-#if defined(CONFIG_CPU_SH7721) || \
+# if defined(CONFIG_CPU_SH7721) || \
defined(CONFIG_SH73A0)
-#define SCIF_FNS(name, scif_offset, scif_size) \
+#  define SCIF_FNS(name, scif_offset, scif_size) \
CPU_SCIF_FNS(name, scif_offset, scif_size)
-#elif defined(CONFIG_R8A7740)
-#define SCIx_FNS(name, sh4_scifa_offset, sh4_scifa_size,\
+# elif defined(CONFIG_R8A7740)
+#  define SCIx_FNS(name, sh4_scifa_offset, sh4_scifa_size,\
sh4_scifb_offset, sh4_scifb_size) \
CPU_SCIx_FNS(name, sh4_scifa_offset, sh4_scifa_size,\
sh4_scifb_offset, sh4_scifb_size)
-#define SCIF_FNS(name, scif_offset, scif_size) \
+#  define SCIF_FNS(name, scif_offset, scif_size) \
CPU_SCIF_FNS(name, scif_offset, scif_size)
-#else
-#define SCIx_FNS(name, sh3_sci_offset, sh3_sci_size,\
+# else
+#  define SCIx_FNS(name, sh3_sci_offset, sh3_sci_size,\
sh4_sci_offset, sh4_sci_size, \
sh3_scif_offset, sh3_scif_size,\
sh4_scif_offset, sh4_scif_size, \
h8_sci_offset, h8_sci_size) \
CPU_SCIx_FNS(name, sh3_sci_offset, sh3_sci_size,\
sh3_scif_offset, sh3_scif_size)
-#define SCIF_FNS(name, sh3_scif_offset, sh3_scif_size,\
+#  define SCIF_FNS(name, sh3_scif_offset, sh3_scif_size,\
sh4_scif_offset, sh4_scif_size) \
CPU_SCIF_FNS(name, sh3_scif_offset, sh3_scif_size)
-#endif
+# endif
 #elif defined(CONFIG_CPU_SH7723)
-   #define SCIx_FNS(name, sh4_scifa_offset, sh4_scifa_size,\
-   sh4_scif_offset, sh4_scif_size) \
-   CPU_SCIx_FNS(name, sh4_scifa_offset, sh4_scifa_size,\
-   sh4_scif_offset, sh4_scif_size)
-   #define SCIF_FNS(name, sh4_scif_offset, sh4_scif_size) \
-   CPU_SCIF_FNS(name, sh4_scif_offset, sh4_scif_size)
+# define SCIx_FNS(name, sh4_scifa_offset, sh4_scifa_size,\
+   sh4_scif_offset, sh4_scif_size) \
+   CPU_SCIx_FNS(name, sh4_scifa_offset, sh4_scifa_size,\
+   sh4_scif_offset, sh4_scif_size)
+# define SCIF_FNS(name, sh4_scif_offset, sh4_scif_size) \
+   CPU_SCIF_FNS(name, sh4_scif_offset, sh4_scif_size)
 #else
-#define SCIx_FNS(name, sh3_sci_offset, sh3_sci_size,\
+# define SCIx_FNS(name, sh3_sci_offset, sh3_sci_size,\
sh4_sci_offset, sh4_sci_size, \
sh3_scif_offset, sh3_scif_size,\
sh4_scif_offset, sh4_scif_size, \
h8_sci_offset, h8_sci_size) \
CPU_SCIx_FNS(name, sh4_sci_offset, sh4_sci_size,\
sh4_scif_offset, sh4_scif_size)
-#define SCIF_FNS(name, sh3_scif_offset, sh3_scif_size, \
+# define SCIF_FNS(name, sh3_scif_offset, sh3_scif_size, \
sh4_scif_offset, sh4_scif_size) \
CPU_SCIF_FNS(name, sh4_scif_offset, sh4_scif_size)
 #endif
@@ -382,11 +382,11 @@ SCIF_FNS(SCSPTR, 0,  0, 0x20, 16)
 SCIF_FNS(DL, 0,  0, 0x30, 16)
 SCIF_FNS(CKS,0,  0, 0x34, 16)
 SCIF_FNS(HSSRR,  0,  0, 0x40, 16) /* HSCIF only */
-#if defined(CFG_SCIF_A)
+# if defined(CFG_SCIF_A)
 SCIF_FNS(SCLSR,  0,  0, 0x14, 16)
-#else
+# else
 SCIF_FNS(SCLSR,  0,  0, 0x24, 16)
-#endif
+# endif
 #else
 /*  reg  SCI/SH3   SCI/SH4  SCIF/SH3   SCIF/SH4  SCI/H8*/
 /*  name off  sz   off  sz   off  sz   off  sz   off  sz*/
@@ -397,13 +397,13 @@ SCIx_FNS(SCxTDR, 0x06,  8, 0x0c,  8, 0x06,  8, 0x0C,  8, 

[PATCH 1/2] serial: sh: Fix compile error when lacking HSCIF support

[Paul Barker]

If we attempt to compile serial_sh.c for a system which lacks HSCIF
support (e.g. R8A7740), we see the following compilation error:

In file included from drivers/serial/serial_sh.c:20:
drivers/serial/serial_sh.c: In function ‘sh_serial_init_generic’:
drivers/serial/serial_sh.h:429:35: warning: implicit declaration of 
function ‘sci_HSSRR_out’; did you mean ‘sci_SCSCR_out’? 
[-Wimplicit-function-declaration]
  429 | #define sci_out(port, reg, value) sci_##reg##_out(port, value)
  |   ^~~~
drivers/serial/serial_sh.c:62:17: note: in expansion of macro ‘sci_out’
   62 | sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8);
  | ^~~

To fix this, only try to support access to the HSSRR register for SoCs
where it actually exists.

Fixes: bbe36e29ca2c ('serial: sh: Add HSCIF support for R-Car SoC')
Signed-off-by: Paul Barker 
Cc: Hai Pham 
Cc: Marek Vasut 
Cc: Simon Glass 
---
 drivers/serial/serial_sh.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 20cda5dbe272..cd9bcf4f0a25 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -58,8 +58,10 @@ static void sh_serial_init_generic(struct uart_port *port)
sci_out(port, SCSPTR, 0x0003);
 #endif
 
+#if defined(CONFIG_RCAR_GEN2) || defined(CONFIG_RCAR_GEN3) || 
defined(CONFIG_RCAR_GEN4)
if (port->type == PORT_HSCIF)
sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8);
+#endif
 }
 
 static void
-- 
2.34.1

[PATCH 0/2] Renesas SCIF driver fix & tidy up

[Paul Barker]

I'll shortly be sending an initial patch set adding support for the Renesas
RZ/G2L SMARC evaluation board and R9A07G044L SoC. Before dropping those patches
I've got a compilation fix and a header tidy up for the SCIF driver.

Paul Barker (2):
  serial: sh: Fix compile error when lacking HSCIF support
  serial: sh: Tidy up pre-processor directive indentation

 drivers/serial/serial_sh.c |  2 +
 drivers/serial/serial_sh.h | 84 +++---
 2 files changed, 44 insertions(+), 42 deletions(-)

-- 
2.34.1

[PATCH v11 15/15] doc: capsule: Document the new mechanism to embed ESL file into dtb

[Sughosh Ganu]

Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the U-Boot build.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Ilias Apalodimas 
---
Changes since V10: None

 doc/develop/uefi/uefi.rst | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index f27cabbcce..68f9b332d1 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -562,20 +562,11 @@ and used by the steps highlighted below.
 ...
 }
 
-You can do step-4 manually with
-
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
+You can perform step-4 through the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. This symbol points to the esl file
+generated in step-2. Once the symbol has been populated with the path
+to the esl file, it will automatically get embedded into the
+platform's dtb as part of U-Boot build.
 
 Anti-rollback Protection
 
-- 
2.34.1

[PATCH v11 14/15] test: capsule: Remove logic to add public key ESL

[Sughosh Ganu]

The public key EFI Signature List(ESL) needed for capsule
authentication is now embedded into the platform's DTB as part of the
build. Remove the superfluous logic from the test setup.

Signed-off-by: Sughosh Ganu 
---
Changes since V10: None

 test/py/tests/test_efi_capsule/conftest.py   | 14 --
 test/py/tests/test_efi_capsule/signature.dts | 10 --
 2 files changed, 4 insertions(+), 20 deletions(-)
 delete mode 100644 test/py/tests/test_efi_capsule/signature.dts

diff --git a/test/py/tests/test_efi_capsule/conftest.py 
b/test/py/tests/test_efi_capsule/conftest.py
index 9160f294e6..dd41da9284 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -51,21 +51,15 @@ def efi_capsule_data(request, u_boot_config):
 check_call('cp %s/capsule_pub_key_bad.crt %s/SIGNER2.crt'
% (key_dir, data_dir), shell=True)
 
-# Update dtb adding capsule certificate
-check_call('cd %s; '
-   'cp %s/test/py/tests/test_efi_capsule/signature.dts .'
-   % (data_dir, u_boot_config.source_dir), shell=True)
-check_call('cd %s; '
-   'dtc -@ -I dts -O dtb -o signature.dtbo signature.dts; '
-   'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
-'-o test_sig.dtb signature.dtbo'
-   % (data_dir, u_boot_config.build_dir), shell=True)
-
 # Update dtb to add the version information
 check_call('cd %s; '
'cp %s/test/py/tests/test_efi_capsule/version.dts .'
% (data_dir, u_boot_config.source_dir), shell=True)
+
 if capsule_auth_enabled:
+check_call('cd %s; '
+   'cp %s/arch/sandbox/dts/test.dtb test_sig.dtb'
+   % (data_dir, u_boot_config.build_dir), shell=True)
 check_call('cd %s; '
'dtc -@ -I dts -O dtb -o version.dtbo version.dts; '
'fdtoverlay -i test_sig.dtb '
diff --git a/test/py/tests/test_efi_capsule/signature.dts 
b/test/py/tests/test_efi_capsule/signature.dts
deleted file mode 100644
index 078cfc76c9..00
--- a/test/py/tests/test_efi_capsule/signature.dts
+++ /dev/null
@@ -1,10 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-
-/dts-v1/;
-/plugin/;
-
-&{/} {
-   signature {
-   capsule-key = /incbin/("SIGNER.esl");
-   };
-};
-- 
2.34.1

[PATCH v11 13/15] sandbox: capsule: Add path to the public key ESL file

[Sughosh Ganu]

Add the path to the public key EFI Signature List(ESL) file for the
sandbox variants which enable capsule authentication. This ESL file
gets embedded into the platform's device-tree as part of the build.

Signed-off-by: Sughosh Ganu 
---
Changes since V10: None

 configs/sandbox_defconfig  | 1 +
 configs/sandbox_flattree_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 1cd1c2ed7c..9f349d482b 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -340,6 +340,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
 CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="board/sandbox/capsule_pub_esl_good.esl"
 CONFIG_EFI_SECURE_BOOT=y
 CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index 8aa295686d..2a24b38cfb 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -227,6 +227,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
 CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="board/sandbox/capsule_pub_esl_good.esl"
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
-- 
2.34.1

[PATCH v11 12/15] scripts/Makefile.lib: Embed capsule public key in platform's dtb

[Sughosh Ganu]

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 target for generating a dtsi file which contains the signature
node with the ESL file included as a property under the signature
node. Include the dtsi file in the dtb. 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 
Reviewed-by: Tom Rini 
Reviewed-by: Ilias Apalodimas 
---
Changes since V10: None

 lib/efi_loader/Kconfig |  8 
 lib/efi_loader/capsule_esl.dtsi.in | 11 +++
 scripts/Makefile.lib   | 15 +++
 3 files changed, 34 insertions(+)
 create mode 100644 lib/efi_loader/capsule_esl.dtsi.in

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 9989e3f384..d20aaab6db 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -272,6 +272,14 @@ 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"
+   depends on EFI_CAPSULE_AUTHENTICATE
+   help
+ Provides the 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/lib/efi_loader/capsule_esl.dtsi.in 
b/lib/efi_loader/capsule_esl.dtsi.in
new file mode 100644
index 00..61a9f2b25e
--- /dev/null
+++ b/lib/efi_loader/capsule_esl.dtsi.in
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * Devicetree file with the public key EFI Signature List(ESL)
+ * node. This file is used to generate the dtsi file to be
+ * included into the DTB.
+*/
+/ {
+   signature {
+   capsule-key = /incbin/("ESL_BIN_FILE");
+   };
+};
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 8c5e25c31c..3cec46bb15 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -334,6 +334,21 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
; \
sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp > 
$(depfile)
 
+quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@
+cmd_capsule_esl_gen = \
+   $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):" 
$(capsule_esl_input_file) > $@)
+
+$(obj)/.capsule_esl.dtsi:
+   $(call cmd_capsule_esl_gen)
+
+capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
+capsule_esl_dtsi = .capsule_esl.dtsi
+capsule_esl_path=$(abspath $(srctree)/$(subst 
$(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
+
+ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+dtsi_include_list += $(capsule_esl_dtsi)
+endif
+
 dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
$(quote),,$(dtsi_include_list)))
 
 $(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
-- 
2.34.1

[PATCH v11 11/15] scripts/Makefile.lib: Add dtsi include files as deps for building DTB

[Sughosh Ganu]

At the time of building the DTB, some dtsi files can be selected for
inclusion. Have these dtsi files as dependencies for the DTB
target. This also ensures generation or updating the dtsi files if
need be.

Signed-off-by: Sughosh Ganu 
Acked-by: Ilias Apalodimas 
Reviewed-by: Tom Rini 
---
Changes since V10: None

 scripts/Makefile.lib | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 368b5a3e28..8c5e25c31c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -334,7 +334,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
; \
sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp > 
$(depfile)
 
-$(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
+dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
$(quote),,$(dtsi_include_list)))
+
+$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
$(call if_changed_dep,dtc)
 
 pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
-- 
2.34.1

[PATCH v11 10/15] scripts/Makefile.lib: Collate all dtsi files for inclusion

[Sughosh Ganu]

At the time of building a device-tree file, all the *u-boot.dtsi files
are looked for, in a particular order, and the first file found is
included. Then, the list of files specified in the
CONFIG_DEVICE_TREE_INCLUDES symbol are included.

Combine these files that are to be included into a variable, and then
include all these files in one go.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Tom Rini 
Acked-by: Ilias Apalodimas 
---
Changes since V10: None

 scripts/Makefile.lib | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index f5ab7af0f4..368b5a3e28 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -179,10 +179,13 @@ ifdef DEVICE_TREE_DEBUG
 u_boot_dtsi_options_debug = $(warning $(u_boot_dtsi_options_raw))
 endif
 
-# We use the first match
-u_boot_dtsi = $(strip $(u_boot_dtsi_options_debug) \
+# We use the first match to be included
+dtsi_include_list = $(strip $(u_boot_dtsi_options_debug) \
$(notdir $(firstword $(u_boot_dtsi_options
 
+# The CONFIG_DEVICE_TREE_INCLUDES also need to be included
+dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
+
 # Modified for U-Boot
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc\
 $(UBOOTINCLUDE) \
@@ -320,8 +323,8 @@ quiet_cmd_dtc = DTC $@
 # Bring in any U-Boot-specific include at the end of the file
 # And finally any custom .dtsi fragments specified with 
CONFIG_DEVICE_TREE_INCLUDES
 cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
-   (cat $<; $(if $(u_boot_dtsi),echo '$(pound)include "$(u_boot_dtsi)"')) 
> $(pre-tmp); \
-   $(foreach f,$(subst $(quote),,$(CONFIG_DEVICE_TREE_INCLUDES)), \
+   (cat $< > $(pre-tmp)); \
+   $(foreach f,$(subst $(quote),,$(dtsi_include_list)), \
  echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
$(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) 
$(pre-tmp) ; \
$(DTC) -O dtb -o $@ -b 0 \
-- 
2.34.1

[PATCH v11 09/15] sandbox: trace: Increase trace buffer size

[Sughosh Ganu]

When running the trace test on the sandbox platform, the current size
of 16MiB is no longer large enough for capturing the entire trace
history, and results in truncation. Use a size of 32MiB for the trace
buffer on the sandbox platform while running the trace test.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V10: None

 .azure-pipelines.yml| 2 +-
 .gitlab-ci.yml  | 2 +-
 test/py/tests/test_trace.py | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 0be317b388..d4591234c4 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -275,7 +275,7 @@ stages:
   TEST_PY_BD: "sandbox"
   BUILD_ENV: "FTRACE=1 NO_LTO=1"
   TEST_PY_TEST_SPEC: "trace"
-  OVERRIDE: "-a CONFIG_TRACE=y -a CONFIG_TRACE_EARLY=y -a 
CONFIG_TRACE_EARLY_SIZE=0x0100"
+  OVERRIDE: "-a CONFIG_TRACE=y -a CONFIG_TRACE_EARLY=y -a 
CONFIG_TRACE_EARLY_SIZE=0x0100 -a CONFIG_TRACE_BUFFER_SIZE=0x0200"
 coreboot:
   TEST_PY_BD: "coreboot"
   TEST_PY_ID: "--id qemu"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5750d82023..cef42aca8c 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -315,7 +315,7 @@ sandbox trace_test.py:
 TEST_PY_BD: "sandbox"
 BUILD_ENV: "FTRACE=1 NO_LTO=1"
 TEST_PY_TEST_SPEC: "trace"
-OVERRIDE: "-a CONFIG_TRACE=y -a CONFIG_TRACE_EARLY=y -a 
CONFIG_TRACE_EARLY_SIZE=0x0100"
+OVERRIDE: "-a CONFIG_TRACE=y -a CONFIG_TRACE_EARLY=y -a 
CONFIG_TRACE_EARLY_SIZE=0x0100 -a CONFIG_TRACE_BUFFER_SIZE=0x0200"
   <<: *buildman_and_testpy_dfn
 
 evb-ast2500 test.py:
diff --git a/test/py/tests/test_trace.py b/test/py/tests/test_trace.py
index ac3e95925e..ad2250920d 100644
--- a/test/py/tests/test_trace.py
+++ b/test/py/tests/test_trace.py
@@ -61,7 +61,7 @@ def collect_trace(cons):
 
 # Read out the trace data
 addr = 0x0200
-size = 0x0100
+size = 0x0200
 out = cons.run_command(f'trace calls {addr:x} {size:x}')
 print(out)
 fname = os.path.join(TMPDIR, 'trace')
-- 
2.34.1

[PATCH v11 08/15] doc: Add documentation to highlight capsule generation related updates

[Sughosh Ganu]

The EFI capsules can now be generated as part of U-Boot build, through
binman. Highlight these changes in the documentation.

Signed-off-by: Sughosh Ganu 
Acked-by: Heinrich Schuchardt 
---
Changes since V10:
* Add an example binman capsule node which shows how a capsule can be
  generated through binman.

 doc/develop/uefi/uefi.rst | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index a7a41f2fac..f27cabbcce 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -318,6 +318,9 @@ Run the following command
   --guid  \
   
 
+Capsule with firmware version
+*
+
 The UEFI specification does not define the firmware versioning mechanism.
 EDK II reference implementation inserts the FMP Payload Header right before
 the payload. It coutains the fw_version and lowest supported version,
@@ -345,6 +348,43 @@ add --fw-version option in mkeficapsule tool.
 If the --fw-version option is not set, FMP Payload Header is not inserted
 and fw_version is set as 0.
 
+Capsule Generation through binman
+*
+
+Support has also been added to generate capsules during U-Boot build
+through binman. This requires the platform's DTB to be populated with
+the capsule entry nodes for binman. The capsules then can be generated
+by specifying the capsule parameters as properties in the capsule
+entry node.
+
+Check the test/py/tests/test_efi_capsule/capsule_gen_binman.dts file
+as reference for how a typical binman node for capsule generation
+looks like. For generating capsules as part of the platform's build, a
+capsule node would then have to be included into the platform's
+devicetree.
+
+A typical binman node for generating a capsule would look like::
+
+   capsule {
+   filename = "u-boot.capsule";
+   efi-capsule {
+   image-index = <0x1>;
+   image-guid = "09d7cf52-0720-4710-91d1-08469b7fe9c8";
+
+   u-boot {
+   };
+   };
+   };
+
+In the above example, a capsule file named u-boot.capsule will be
+generated with u-boot.bin as it's input payload. The capsule
+generation parameters like image-index and image-guid are being
+specified as properties. Similarly, other properties like the private
+and public key certificate can be specified for generating signed
+capsules. Refer :ref:`etype_efi_capsule` for documentation about the
+efi-capsule binman entry type, which describes all the properties that
+can be specified.
+
 Performing the update
 *
 
-- 
2.34.1

[PATCH v11 07/15] test: capsule: Generate EFI capsules through binman

[Sughosh Ganu]

Support has been added for generating the EFI capsules through
binman. Make changes in the EFI capsule update testing feature to
generate capsules through binman.

Signed-off-by: Sughosh Ganu 
---
Changes since V10:
* Remove the sandbox_capsule.dtsi file.
* Remove addition of multiple-images property from sandbox.dts and
  test.dts as the capsule generation is moved to the test.
* Add the capsule_gen_binman.dts with binman nodes for capsule
  generation.
* Call the binman tool as part of the capsule test setup for
  generation of capsules.

 include/sandbox_efi_capsule.h |  21 ++
 .../test_efi_capsule/capsule_gen_binman.dts   | 321 ++
 test/py/tests/test_efi_capsule/conftest.py| 163 ++---
 .../tests/test_efi_capsule/uboot_bin_env.its  |  36 --
 4 files changed, 367 insertions(+), 174 deletions(-)
 create mode 100644 include/sandbox_efi_capsule.h
 create mode 100644 test/py/tests/test_efi_capsule/capsule_gen_binman.dts
 delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its

diff --git a/include/sandbox_efi_capsule.h b/include/sandbox_efi_capsule.h
new file mode 100644
index 00..3e288e8a84
--- /dev/null
+++ b/include/sandbox_efi_capsule.h
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#if !defined(_SANDBOX_EFI_CAPSULE_H_)
+#define _SANDBOX_EFI_CAPSULE_H_
+
+#define SANDBOX_UBOOT_IMAGE_GUID   "09d7cf52-0720-4710-91d1-08469b7fe9c8"
+#define SANDBOX_UBOOT_ENV_IMAGE_GUID   "5a7021f5-fef2-48b4-aaba-832e777418c0"
+#define SANDBOX_FIT_IMAGE_GUID "3673b45d-6a7c-46f3-9e60-adabb03f7937"
+#define SANDBOX_INCORRECT_GUID "058b7d83-50d5-4c47-a195-60d86ad341c4"
+
+#define UBOOT_FIT_IMAGE"u-boot_bin_env.itb"
+
+#define CAPSULE_PRIV_KEY   "capsule_priv_key_good.key"
+#define CAPSULE_PUB_KEY"capsule_pub_key_good.crt"
+#define CAPSULE_INVAL_KEY  "capsule_priv_key_bad.key"
+#define CAPSULE_INVAL_PUB_KEY  "capsule_pub_key_bad.crt"
+
+#endif /* _SANDBOX_EFI_CAPSULE_H_ */
diff --git a/test/py/tests/test_efi_capsule/capsule_gen_binman.dts 
b/test/py/tests/test_efi_capsule/capsule_gen_binman.dts
new file mode 100644
index 00..e8a1858509
--- /dev/null
+++ b/test/py/tests/test_efi_capsule/capsule_gen_binman.dts
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Devicetree for capsule generation through binman
+ */
+
+/dts-v1/;
+
+#include 
+
+/ {
+   binman: binman {
+   multiple-images;
+   };
+};
+
+ {
+   itb {
+   filename = UBOOT_FIT_IMAGE;
+
+   fit {
+   description = "Automatic U-Boot environment update";
+   #address-cells = <2>;
+
+   images {
+   u-boot-bin {
+   description = "U-Boot binary on SPI 
Flash";
+   compression = "none";
+   type = "firmware";
+   arch = "sandbox";
+   load = <0>;
+   text {
+   text = "u-boot:New";
+   };
+
+   hash-1 {
+   algo = "sha1";
+   };
+   };
+   u-boot-env {
+   description = "U-Boot environment on 
SPI Flash";
+   compression = "none";
+   type = "firmware";
+   arch = "sandbox";
+   load = <0>;
+   text {
+   text = "u-boot-env:New";
+   };
+
+   hash-1 {
+   algo = "sha1";
+   };
+   };
+   };
+   };
+   };
+
+   capsule1 {
+   filename = "Test01";
+   efi-capsule {
+   image-index = <0x1>;
+   image-guid = SANDBOX_UBOOT_IMAGE_GUID;
+
+   text {
+   text = "u-boot:New";
+   };
+   };
+   };
+
+   capsule2 {
+   filename = "Test02";
+   efi-capsule {
+   image-index = <0x2>;
+   image-guid = SANDBOX_UBOOT_ENV_IMAGE_GUID;
+
+   text {
+   text = "u-boot-env:New";
+   };
+   };
+   };
+
+ 

[PATCH v11 06/15] binman: capsule: Add support for generating EFI capsules

[Sughosh Ganu]

Add support in binman for generating EFI capsules. The capsule
parameters can be specified through the capsule binman entry. Also add
test cases in binman for testing capsule generation.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V10: None

 tools/binman/entries.rst  |  64 
 tools/binman/etype/efi_capsule.py | 143 ++
 tools/binman/ftest.py | 118 +++
 tools/binman/test/311_capsule.dts |  21 +++
 tools/binman/test/312_capsule_signed.dts  |  23 +++
 tools/binman/test/313_capsule_version.dts |  22 +++
 tools/binman/test/314_capsule_signed_ver.dts  |  24 +++
 tools/binman/test/315_capsule_oemflags.dts|  22 +++
 tools/binman/test/316_capsule_missing_key.dts |  22 +++
 .../binman/test/317_capsule_missing_index.dts |  20 +++
 .../binman/test/318_capsule_missing_guid.dts  |  19 +++
 11 files changed, 498 insertions(+)
 create mode 100644 tools/binman/etype/efi_capsule.py
 create mode 100644 tools/binman/test/311_capsule.dts
 create mode 100644 tools/binman/test/312_capsule_signed.dts
 create mode 100644 tools/binman/test/313_capsule_version.dts
 create mode 100644 tools/binman/test/314_capsule_signed_ver.dts
 create mode 100644 tools/binman/test/315_capsule_oemflags.dts
 create mode 100644 tools/binman/test/316_capsule_missing_key.dts
 create mode 100644 tools/binman/test/317_capsule_missing_index.dts
 create mode 100644 tools/binman/test/318_capsule_missing_guid.dts

diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index e7dfe6b2a3..801bd94674 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -468,6 +468,70 @@ updating the EC on startup via software sync.
 
 
 
+.. _etype_efi_capsule:
+
+Entry: capsule: Entry for generating EFI Capsule files
+--
+
+The parameters needed for generation of the capsules can be provided
+as properties in the entry.
+
+Properties / Entry arguments:
+- image-index: Unique number for identifying corresponding
+  payload image. Number between 1 and descriptor count, i.e.
+  the total number of firmware images that can be updated. Mandatory
+  property.
+- image-guid: Image GUID which will be used for identifying the
+  updatable image on the board. Mandatory property.
+- hardware-instance: Optional number for identifying unique
+  hardware instance of a device in the system. Default value of 0
+  for images where value is not to be used.
+- fw-version: Value of image version that can be put on the capsule
+  through the Firmware Management Protocol(FMP) header.
+- monotonic-count: Count used when signing an image.
+- private-key: Path to PEM formatted .key private key file. Mandatory
+  property for generating signed capsules.
+- public-key-cert: Path to PEM formatted .crt public key certificate
+  file. Mandatory property for generating signed capsules.
+- oem-flags - OEM flags to be passed through capsule header.
+
+Since this is a subclass of Entry_section, all properties of the parent
+class also apply here. Except for the properties stated as mandatory, the
+rest of the properties are optional.
+
+For more details on the description of the capsule format, and the capsule
+update functionality, refer Section 8.5 and Chapter 23 in the `UEFI
+specification`_.
+
+The capsule parameters like image index and image GUID are passed as
+properties in the entry. The payload to be used in the capsule is to be
+provided as a subnode of the capsule entry.
+
+A typical capsule entry node would then look something like this::
+
+capsule {
+type = "efi-capsule";
+image-index = <0x1>;
+/* Image GUID for testing capsule update */
+image-guid = SANDBOX_UBOOT_IMAGE_GUID;
+hardware-instance = <0x0>;
+private-key = "path/to/the/private/key";
+public-key-cert = "path/to/the/public-key-cert";
+oem-flags = <0x8000>;
+
+u-boot {
+};
+};
+
+In the above example, the capsule payload is the U-Boot image. The
+capsule entry would read the contents of the payload and put them
+into the capsule. Any external file can also be specified as the
+payload using the blob-ext subnode.
+
+.. _`UEFI specification`: 
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf
+
+
+
 .. _etype_encrypted:
 
 Entry: encrypted: Externally built encrypted binary blob
diff --git a/tools/binman/etype/efi_capsule.py 
b/tools/binman/etype/efi_capsule.py
new file mode 100644
index 00..006eb630ad
--- /dev/null
+++ b/tools/binman/etype/efi_capsule.py
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2023 Linaro Limited
+#
+# Entry-type module for producing a EFI capsule
+#
+
+import os
+
+from binman.entry import Entry
+from binman.etype.section import 

[PATCH v11 05/15] btool: mkeficapsule: Add a bintool for EFI capsule generation

[Sughosh Ganu]

Add a bintool for generating EFI capsules. This calls the mkeficapsule
tool which generates the capsules.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V10: None

 tools/binman/btool/mkeficapsule.py | 101 +
 1 file changed, 101 insertions(+)
 create mode 100644 tools/binman/btool/mkeficapsule.py

diff --git a/tools/binman/btool/mkeficapsule.py 
b/tools/binman/btool/mkeficapsule.py
new file mode 100644
index 00..61179747ff
--- /dev/null
+++ b/tools/binman/btool/mkeficapsule.py
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Linaro Limited
+#
+"""Bintool implementation for mkeficapsule tool
+
+mkeficapsule is a tool used for generating EFI capsules.
+
+The following are the commandline options to be provided
+to the tool
+Usage: mkeficapsule [options]  
+Options:
+   -g, --guid guid for image blob type
+   -i, --index  update image index
+   -I, --instanceupdate hardware instance
+   -v, --fw-version   firmware version
+   -p, --private-key   private key file
+   -c, --certificate  signer's certificate file
+   -m, --monotonic-count  monotonic count
+   -d, --dump_sig  dump signature (*.p7)
+   -A, --fw-accept  firmware accept capsule, requires GUID, no image blob
+   -R, --fw-revert  firmware revert capsule, takes no GUID, no image blob
+   -o, --capoemflag Capsule OEM Flag, an integer between 0x and 0x
+   -h, --help  print a help message
+"""
+
+from binman import bintool
+
+class Bintoolmkeficapsule(bintool.Bintool):
+"""Handles the 'mkeficapsule' tool
+
+This bintool is used for generating the EFI capsules. The
+capsule generation parameters can either be specified through
+commandline, or through a config file.
+"""
+def __init__(self, name):
+super().__init__(name, 'mkeficapsule tool for generating capsules')
+
+def generate_capsule(self, image_index, image_guid, hardware_instance,
+ payload, output_fname, priv_key, pub_key,
+ monotonic_count=0, version=0, oemflags=0):
+"""Generate a capsule through commandline-provided parameters
+
+Args:
+image_index (int): Unique number for identifying payload image
+image_guid (str): GUID used for identifying the image
+hardware_instance (int): Optional unique hardware instance of
+a device in the system. 0 if not being used
+payload (str): Path to the input payload image
+output_fname (str): Path to the output capsule file
+priv_key (str): Path to the private key
+pub_key(str): Path to the public key
+monotonic_count (int): Count used when signing an image
+version (int): Image version (Optional)
+oemflags (int): Optional 16 bit OEM flags
+
+Returns:
+str: Tool output
+"""
+args = [
+f'--index={image_index}',
+f'--guid={image_guid}',
+f'--instance={hardware_instance}'
+]
+
+if version:
+args += [f'--fw-version={version}']
+if oemflags:
+args += [f'--capoemflag={oemflags}']
+if priv_key and pub_key:
+args += [
+f'--monotonic-count={monotonic_count}',
+f'--private-key={priv_key}',
+f'--certificate={pub_key}'
+]
+
+args += [
+payload,
+output_fname
+]
+
+return self.run_cmd(*args)
+
+def fetch(self, method):
+"""Fetch handler for mkeficapsule
+
+This builds the tool from source
+
+Returns:
+tuple:
+str: Filename of fetched file to copy to a suitable directory
+str: Name of temp directory to remove, or None
+"""
+if method != bintool.FETCH_BUILD:
+return None
+
+cmd = ['tools-only_defconfig', 'tools']
+result = self.build_from_git(
+'https://source.denx.de/u-boot/u-boot.git',
+cmd,
+'tools/mkeficapsule')
+return result
-- 
2.34.1

[PATCH v11 04/15] sandbox: capsule: Enable EFI capsule module on sandbox variants

[Sughosh Ganu]

Enable the EFI capsule update code on all sandbox variants. This was
already enabled on the sandbox, sandbox64 and sandbox_flattree
variants. The rest of the variants also have the EFI capsule update
module  enabled now. With this commit, the mkeficapsule tool also gets
enabled on all variants.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V10: None

 configs/sandbox_noinst_defconfig | 2 ++
 configs/sandbox_spl_defconfig| 2 ++
 configs/sandbox_vpl_defconfig| 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/sandbox_noinst_defconfig b/configs/sandbox_noinst_defconfig
index 2c6aab6c85..e202ffccd2 100644
--- a/configs/sandbox_noinst_defconfig
+++ b/configs/sandbox_noinst_defconfig
@@ -237,6 +237,8 @@ CONFIG_TPM=y
 CONFIG_LZ4=y
 CONFIG_ZSTD=y
 CONFIG_ERRNO_STR=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
 CONFIG_UNIT_TEST=y
 CONFIG_SPL_UNIT_TEST=y
 CONFIG_UT_TIME=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 8d50162b27..25a21b8493 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -245,6 +245,8 @@ CONFIG_LZ4=y
 CONFIG_ZSTD=y
 CONFIG_ERRNO_STR=y
 CONFIG_SPL_HEXDUMP=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
 CONFIG_UNIT_TEST=y
 CONFIG_SPL_UNIT_TEST=y
 CONFIG_UT_TIME=y
diff --git a/configs/sandbox_vpl_defconfig b/configs/sandbox_vpl_defconfig
index f3a0fd19a9..a9a7136ce7 100644
--- a/configs/sandbox_vpl_defconfig
+++ b/configs/sandbox_vpl_defconfig
@@ -256,6 +256,8 @@ CONFIG_LZ4=y
 CONFIG_ZSTD=y
 # CONFIG_VPL_LZMA is not set
 CONFIG_ERRNO_STR=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
 CONFIG_UNIT_TEST=y
 CONFIG_SPL_UNIT_TEST=y
 CONFIG_UT_TIME=y
-- 
2.34.1

[PATCH v11 03/15] sandbox: capsule: Add keys and certificates needed for capsule update testing

[Sughosh Ganu]

Add the private keys and public key certificates which are to be used
for capsule authentication while testing the EFI capsule update
functionality. There are two pairs of private and public keys, good
and bad. The good key pair will be used for signing capsules, whilst
the bad key pair is to be used as malicious keys for testing
authentication failure cases. The capsule_pub_key_good.crt is also
converted to an EFI Signature List(ESL) file, SIGNER.esl, which is
embedded in the platform's device-tree for capsule authentication.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V10: None

 board/sandbox/capsule_priv_key_bad.key  |  28 
 board/sandbox/capsule_priv_key_good.key |  28 
 board/sandbox/capsule_pub_esl_good.esl  | Bin 0 -> 831 bytes
 board/sandbox/capsule_pub_key_bad.crt   |  19 
 board/sandbox/capsule_pub_key_good.crt  |  19 
 5 files changed, 94 insertions(+)
 create mode 100644 board/sandbox/capsule_priv_key_bad.key
 create mode 100644 board/sandbox/capsule_priv_key_good.key
 create mode 100644 board/sandbox/capsule_pub_esl_good.esl
 create mode 100644 board/sandbox/capsule_pub_key_bad.crt
 create mode 100644 board/sandbox/capsule_pub_key_good.crt

diff --git a/board/sandbox/capsule_priv_key_bad.key 
b/board/sandbox/capsule_priv_key_bad.key
new file mode 100644
index 00..2324f69ebd
--- /dev/null
+++ b/board/sandbox/capsule_priv_key_bad.key
@@ -0,0 +1,28 @@
+-BEGIN PRIVATE KEY-
+MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCmPw1pGd2xNW0p
+lesRXkkek3uwUB06Nt61tnZvpMkBKt4IokqGWz1tZls+Z2CqvwOfcsPZ27cPRYSu
+xRnM3YdL4MG6SePV7i/YSNw3rq8CP8zLGtCbNIfsfsNfPQEtPBpw6+7pMJKhjqpV
+2U2UQzZEiX4qlnhLpyv2JNJag27yf0feLdJi7HnJ9xdvcXpA1DSGm4y+DDhgYeI8
+DEteEu6s0TYQfnOZSQOeJi+1/Qz0S594uFJB37MyGh/mB15ILb8gva4nA3ayHOBK
+0dd+HSiUCGYrLYO7aj+nfzQj9N1qTlzCnC1603bMczU5pkwcODg6xP0Sn11J6RYy
+y0c0qzJLAgMBAAECggEABDY2MLoew3IkBltrParAWAUUcFLi95jw92q6BkOHEJg8
+2qia1yCitPUtPodMLmOKF5x4EdgXg5sv2O8MGbWP1VtUKXGh3QJcnRnNmsZ1hXJC
+RBcrei2aVLsqf0V2Mg3+GuG8PW3vLWHyZ/Sd6afeuXEYm2Bzrw9J5rfd3dBVKm7f
+HBvIyy1ATO/2cbUaEaCLOyhxLhssTI2TIK5SjlsjFLxiQXEi6RyGfBxUCriKZykS
+krMdvYh7Tf0uYcv0STmQ5s5Rd+RhRIGCVAdsNBxxJjgBAgqqa/B+kWbcc6o2D41n
+yWjErUaBBx3t0A7oT4K4DSTYwMNDVY3fhdd+szsocQKBgQDjnm8LG4UO6OQDm6iX
+0vTQTItoAz5TU6GEjHTCfVEqiupD4LKfHhSXwp2hRyzxXO5oNTU9MQCzYd7Npes0
+oVk4Tjo3YDacNPgxqKjODu/Q+tkTH15ydzGr674+YXHfCA1uT5GKOiiF0H1FZgMa
+Dk0s+3uWX34vbL4QCu97bUhBewKBgQC6+Z0J9sClgWvvjkglJN3XhRnAacp+WgX7
+bkpgSboXIIsqeqhd1WCLeV7L1pcZgifYBMPojf5LTBqBedL1q3RuqiqQWD/bSIYN
+Oc9KCdTjksS8Zo+w+s5zDObDhW9y13H2mKwDqilYBrT4fiA62wPMf1SjEF+RSC6K
+ZrQzHO1xcQKBgAILsXnLFIYOx8XUh05eAf9BQNt9c/jxvnjffkklMS6Nsw9LHK/b
+aFn40MvbROcia64aFFFpeFUkYwk8HYIKlS+xXEqVHciHnVds6Z94eOVK69qFJKco
+tRSTeNE8tPZJLz23j1pLrYOOXSHbidmZGU53MCQo1Yx9kLO6NW7Ji6WzAoGBALP4
+lEoE80Xbn3NEdvkZ1VcfzLvCmKCqMlvjuz+Xd8HPF2VaDznSq01VFAQMmAB7obJy
+U8hC9OSxakn6Yy8JS9dBgBrUdxKxaibM4FQZxosOuMPHzMPDhniDkJPemnnmGtIL
+/nbAkW8jdYpCjO9Z5PwwC92xYuvKmNGrLgSM8ZhhAoGAfgSZTpASXubM18E3ecfw
+5z333wf9qEQgZj7i9MzByFZudyHUhv/FPW1ocUJf36Wu1dfofZg3noSL6oakrm2v
+dFDo4PoyCStuF0w9SSzpIld01ZG0t7XqphY0DmshCXIXsqr7Vb4WrbBI7KX+b3Um
+BzmROfaSud97NjQ/RA26OZk=
+-END PRIVATE KEY-
diff --git a/board/sandbox/capsule_priv_key_good.key 
b/board/sandbox/capsule_priv_key_good.key
new file mode 100644
index 00..9a37f59796
--- /dev/null
+++ b/board/sandbox/capsule_priv_key_good.key
@@ -0,0 +1,28 @@
+-BEGIN PRIVATE KEY-
+MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCwBfaV0P1jRzS6
+13U1T+4VbuMVsxFXhwHJY5z5Fx6v+cWBf3K1ruK+7cEnW55ZHXvNE2JCkjMvISKm
+hI/DLJWIPnAus8tFdU/R2u5oJbKI+b6GbuamO/CG9HsXZ58lOC6r2ckjixxovsA9
+SFshccdIv2YrwiVsWeyFpH+rB3/+cFbrgdWpaUc1367GkU/ZCnSRDBvVvzRRI1a4
+y2NogFqbZHXHENpzWNJ3TTXhf9dwM5HFGkmX7SA43Dtazae6CB4EaUKzLYWj3+ae
+AQbdvBrupKZQz1PUKn7X6+BGaLujHthvibYppNegPvqbJ1xBbv59CQK+lRULwC05
+NYw5+sIxAgMBAAECggEAHn8h/knjpMAw/BAZP//VrYP1Nwy7u/Dpl9U43JUrXWzG
+Uc3dd2nR4id6GBIRCLqJePnbQ9JlqMwyXyxHZhbC34SF1imTVbjh9+dY99VULdQr
+NMphDrsCzLbt3pu24HFv8Jk+dniDFwi5cMSo+U3nq4xxrLIp3rBjwLHD5sNZYyEU
+9xZnj7ziTn5X8da8iRxNpyzz2kQeVemJ0ahr/IkX718bkakSFMesGkln06vH7rAs
+069SeqOPrFEbWYXI5iMktLugl3JZpzasRE48j0M42PuProgvT7jb8B35ZF7kn0jT
+MqTIHglsJRWcSY0fAb2lHSAvd2vLLVunxr9PDWZvGQKBgQDVzVTuvo1CrVrQLy+B
+tpy2k5mjR3qxAOcoWTnKcMErLe8imWWaxukODenP4XqQIX4Sl+X3BXxOqun0Klap
+FEsI7TWSHf0eULFtFj0SCgqfRR+V/nblP05eO2nFXgr5YdNa1bWf/aMHplBo4q9e
+bbAr4InUB7IGWL2cWjhOhWuJbQKBgQDSw81cBM+vGPUYH/wlxlTVgZCo2Dg2NHjt
+LUBqvOZNr21j2F+w8t1vKmqwhkqpc5HIi3pHjEA5gZLTRtmf4GQyo973I6MGn4bS
+eayOd6/+FkAi9DUD+WaF7yctJqeevav6KF2UCiz78OtCAU5Y9jFFJpuOANIztI7m
+t7ZCUpMFVQKBgFnAsP7oj3SGQbFTnaXeeztKCx04TJExx9hwXIpXe0AdMF5d9wFa
+r0tvG9Bg34rSBJLZoXhpnR2JMl2FyIuCMV219t84J6IqTdF1nH2OKZdi9TeKc28Z
+fFSirGxmZkT6hDeFr5FScLYtY2QkhWomseY5hKK1+E4hwrd4SFruN46hAoGBAJgh
+nzTBgEtqH1enlrCJhSiLmihV0dVGcNb559pjuXTvoG0GfKPT2gPowRPkCzZe5ia0
+jrHgSWd44MtCA8nEBW8MG9+VyJH6Si3Yh7ZaLB2iX+8bCL1yow8f/c44bZtGW0F5

[PATCH v11 02/15] nuvoton: npcm845-evb: Add a newline at the end of file

[Sughosh Ganu]

Add a newline at the end of the dts, without which the build fails
when including a dtsi file.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
Reviewed-by: Ilias Apalodimas 
---
Changes since V10: None

 arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/nuvoton-npcm845-evb.dts 
b/arch/arm/dts/nuvoton-npcm845-evb.dts
index 3cab7807e3..a93666cb41 100644
--- a/arch/arm/dts/nuvoton-npcm845-evb.dts
+++ b/arch/arm/dts/nuvoton-npcm845-evb.dts
@@ -354,4 +354,4 @@
_pins
_pins
>;
-};
\ No newline at end of file
+};
-- 
2.34.1

[PATCH v11 01/15] binman: bintool: Build a tool from a list of commands

[Sughosh Ganu]

Add support to build a tool from source with a list of commands. This
is useful when a tool can be built with multiple commands instead of a
single command.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V10: None

 tools/binman/bintool.py | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 0b0f56dbbb..3c4ad1adbb 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -328,7 +328,7 @@ class Bintool:
 return result.stdout
 
 @classmethod
-def build_from_git(cls, git_repo, make_target, bintool_path, flags=None):
+def build_from_git(cls, git_repo, make_targets, bintool_path, flags=None):
 """Build a bintool from a git repo
 
 This clones the repo in a temporary directory, builds it with 'make',
@@ -336,7 +336,8 @@ class Bintool:
 
 Args:
 git_repo (str): URL of git repo
-make_target (str): Target to pass to 'make' to build the tool
+make_targets (list of str): List of targets to pass to 'make' to 
build
+the tool
 bintool_path (str): Relative path of the tool in the repo, after
 build is complete
 flags (list of str): Flags or variables to pass to make, or None
@@ -350,12 +351,14 @@ class Bintool:
 tmpdir = tempfile.mkdtemp(prefix='binmanf.')
 print(f"- clone git repo '{git_repo}' to '{tmpdir}'")
 tools.run('git', 'clone', '--depth', '1', git_repo, tmpdir)
-print(f"- build target '{make_target}'")
-cmd = ['make', '-C', tmpdir, '-j', f'{multiprocessing.cpu_count()}',
-   make_target]
-if flags:
-cmd += flags
-tools.run(*cmd)
+for target in make_targets:
+print(f"- build target '{target}'")
+cmd = ['make', '-C', tmpdir, '-j', 
f'{multiprocessing.cpu_count()}',
+   target]
+if flags:
+cmd += flags
+tools.run(*cmd)
+
 fname = os.path.join(tmpdir, bintool_path)
 if not os.path.exists(fname):
 print(f"- File '{fname}' was not produced")
-- 
2.34.1

[PATCH v11 00/15] Integrate EFI capsule tasks into U-Boot's build flow

[Sughosh Ganu]

This patchset aims to bring two capsule related tasks under the U-Boot
build flow.

The first task is related to generation of capsules. The capsules can
be generated as part of U-Boot build, and this is being achieved
through binman, by adding a capsule entry type. The capsules can be
generated by specifying the capsule parameters as properties under the
capsule entry node.

The other task is the embedding of the public key into the platform's
DTB. The public key is in the form of an EFI Signature List(ESL) file
and is used for capsule authentication. This is being achieved by
adding the signature node containing the capsule public key in the
platform's DTB.

Corresponding changes have also been made to the test setup of the EFI
capsule update feature. The ESL public key file was embedded into the
sandbox platform's test.dtb as part of the test setup, post U-Boot
build. This is now no longer needed as the embedding of the ESL
happens as part of the build.

Secondly, the capsules needed for testing the EFI capsule update
feature were being generated through the invocation of the
mkeficapsule tool. This setup has also been changed to introduce
generation of these capsules through binman.

The document has been updated to reflect the above changes.

Changes since V10:

This series clubs two changes together. 1) Capsule generation through
binman, 2) Embedding the capsule public key ESL into the platform's
DTB [1]. This has been done based on feedback from Tom Rini on IRC.

The capsule generation was being done for all sandbox variant
builds till the V10 version. This is now changed so that the capsules
are only generated as part of the EFI capsule update feature
testing. This has been done based on feedback from Tom Rini [2]. These
changes are part of patch 7. 

* Remove the sandbox_capsule.dtsi file.
* Remove addition of multiple-images property from sandbox.dts and
  test.dts as the capsule generation is moved to the test.
* Add the capsule_gen_binman.dts with binman nodes for capsule
  generation.
* Call the binman tool as part of the capsule test setup for
  generation of capsules.
* Add an example binman capsule node which shows how a capsule can be
  generated through binman.

[1] - https://lists.denx.de/pipermail/u-boot/2023-August/527810.html
[2] - https://lists.denx.de/pipermail/u-boot/2023-August/526987.html

Sughosh Ganu (15):
  binman: bintool: Build a tool from a list of commands
  nuvoton: npcm845-evb: Add a newline at the end of file
  sandbox: capsule: Add keys and certificates needed for capsule update
testing
  sandbox: capsule: Enable EFI capsule module on sandbox variants
  btool: mkeficapsule: Add a bintool for EFI capsule generation
  binman: capsule: Add support for generating EFI capsules
  test: capsule: Generate EFI capsules through binman
  doc: Add documentation to highlight capsule generation related updates
  sandbox: trace: Increase trace buffer size
  scripts/Makefile.lib: Collate all dtsi files for inclusion
  scripts/Makefile.lib: Add dtsi include files as deps for building DTB
  scripts/Makefile.lib: Embed capsule public key in platform's dtb
  sandbox: capsule: Add path to the public key ESL file
  test: capsule: Remove logic to add public key ESL
  doc: capsule: Document the new mechanism to embed ESL file into dtb

 .azure-pipelines.yml  |   2 +-
 .gitlab-ci.yml|   2 +-
 arch/arm/dts/nuvoton-npcm845-evb.dts  |   2 +-
 board/sandbox/capsule_priv_key_bad.key|  28 ++
 board/sandbox/capsule_priv_key_good.key   |  28 ++
 board/sandbox/capsule_pub_esl_good.esl| Bin 0 -> 831 bytes
 board/sandbox/capsule_pub_key_bad.crt |  19 ++
 board/sandbox/capsule_pub_key_good.crt|  19 ++
 configs/sandbox_defconfig |   1 +
 configs/sandbox_flattree_defconfig|   1 +
 configs/sandbox_noinst_defconfig  |   2 +
 configs/sandbox_spl_defconfig |   2 +
 configs/sandbox_vpl_defconfig |   2 +
 doc/develop/uefi/uefi.rst |  59 +++-
 include/sandbox_efi_capsule.h |  21 ++
 lib/efi_loader/Kconfig|   8 +
 lib/efi_loader/capsule_esl.dtsi.in|  11 +
 scripts/Makefile.lib  |  30 +-
 .../test_efi_capsule/capsule_gen_binman.dts   | 321 ++
 test/py/tests/test_efi_capsule/conftest.py| 175 ++
 test/py/tests/test_efi_capsule/signature.dts  |  10 -
 .../tests/test_efi_capsule/uboot_bin_env.its  |  36 --
 test/py/tests/test_trace.py   |   2 +-
 tools/binman/bintool.py   |  19 +-
 tools/binman/btool/mkeficapsule.py| 101 ++
 tools/binman/entries.rst  |  64 
 tools/binman/etype/efi_capsule.py | 143 
 tools/binman/ftest.py | 118 +++
 tools/binman/test/311_capsule.dts |  21 ++
 

Re: RPi Zero 2 W usb keyboard support?

[Filip Žaludek]

Hi Peter,

On 8/22/23 13:00, Peter Robinson wrote:

Hi,


Hi,
    is supposed usb keyboard to work in u-boot 2023.04 on RPi Zero 2 W?
Configured as rpi_arm64_defconfig, no usb devices found but subsequent
kernel works as expected.


[pi02]
kernel=u-boot.bin
otg_mode=0
dtoverlay=dwc2,dr_mode=host





Hello,
   I see, increasing usb_pgood_delay makes the trick.


I wonder if it's device specific, my Logitech wireless keyboard is
detected with the defaults:

U-Boot>
USB device tree:
   1  Hub (480 Mb/s, 0mA)
   |   U-Boot Root Hub
   |
   +-2  Human Interface (12 Mb/s, 98mA)
    Logitech USB Receiver




Yes, seems to be device specific, it is also sensitive to OTG adaptor used..


Notes: (no usb_pgood_delay adjustments)
Linux 5.15.0:
* all the adaptors vs keyboards works
U-boot 2023.04: (+works, -does not)
* k1_a1- k1_a2+    // workaround usb_pgood_delay=1000
* k2_a1- k2_a2-    // 'usb tree' detected but does not work
* k3_a1+ k3_a2+


Keyboards:
k1/
Bus 001 Device 003: ID 17ef:6099 Lenovo Lenovo Traditional USB Keyboard,    bcdUSB 1.10, bcdDevice 1.10, 
bcdHID 1.10

k2/
Bus 001 Device 002: ID 03f0:0024 HP, Inc KU-0316 Keyboard,  bcdUSB 2.00, bcdDevice 1.30, 
bcdHID 1.11

k3/
Bus 001 Device 002: ID 04f2:0116 Chicony Electronics Co., Ltd KU-2971/KU-0325 Keyboard, bcdUSB 1.10, bcdDevice 3.00, 
bcdHID 1.10



OTG Adaptors:
a1/
The PiHut, USB to microUSB OTG Shim
https://urldefense.com/v3/__https://rpishop.cz/datove-redukce/4365-prevodnik-usb-na-microusb-otg-shim.html__;!!ACWV5N9M2RV99hQ!JIFzwzVvSSXpR2n_vV5USgKPkbrvI1VtCWDO4eKbLaT4RVHAtvawPy76faXmhOJ33tUlx9_TtwkHgiewJKqAUapuqEk$
 a2/
USB 2.0 Hi-Speed 0,2m OTG adaptér
https://urldefense.com/v3/__https://rpishop.cz/datove-redukce/580-usb-20-hi-speed-02m-otg-adapter.html__;!!ACWV5N9M2RV99hQ!JIFzwzVvSSXpR2n_vV5USgKPkbrvI1VtCWDO4eKbLaT4RVHAtvawPy76faXmhOJ33tUlx9_TtwkHgiewJKqAYbCSmmM$




Sorry, I get lost with so many devices. To conclude my experiments..
All the permutations works in Linux 5.15.0, testing is OTG adapter agnostic.
USB 2.0 keyboard does not work.
Some of USB 1.1 keyboards work out of the box, some with usb_pgood_delay=1000 
workaround.


Filip

[PATCH RESEND v2 0/2] net: add support for HiSilicon Fast Ethernet Controller driver

[Yang Xiwen via B4 Relay]

This core is found on many HiSilicon chips. This patchset adds support
for it and the integrated MDIO bus.

The driver code comes from linux kernel driver, downstream u-boot driver
and the datasheet. It's already tested on a Hi3798MV200 based STB.

Note that currently this driver can't be used for Hi3798MV200 since the
clock driver is missing. I will implement and submit the clock driver
and the framework in a later patchset.

Signed-off-by: Yang Xiwen 
---
Changes in v2:
- hisi_femac: clear previous irq before sending
- Link to v1: 
https://lore.kernel.org/r/20230725-wip-hisi_femac-trunk-v1-0-88469a170...@outlook.com

---
Yang Xiwen (2):
  net: add hifemac Ethernet driver for HiSilicon platform
  net: add hifemac_mdio MDIO bus driver for HiSilicon platform

 drivers/net/Kconfig|  17 ++
 drivers/net/Makefile   |   2 +
 drivers/net/hifemac.c  | 481 +
 drivers/net/hifemac_mdio.c | 116 +++
 4 files changed, 616 insertions(+)
---
base-commit: 580eb31199be8a822e62f20965854a242f895d03
change-id: 20230724-wip-hisi_femac-trunk-1f57f0986f0c

Best regards,
-- 
Yang Xiwen 

[PATCH RESEND v2 1/2] net: add hifemac Ethernet driver for HiSilicon platform

[Yang Xiwen via B4 Relay]

From: Yang Xiwen 

It adds the driver for HIFEMAC Ethernet controller found on HiSilicon
SoCs like Hi3798MV200.  It's based on the mainstream linux driver, but
quite a lot of code gets rewritten and cleaned up to adopt u-boot driver
model.

Signed-off-by: Yang Xiwen 
---
 drivers/net/Kconfig   |   9 +
 drivers/net/Makefile  |   1 +
 drivers/net/hifemac.c | 481 ++
 3 files changed, 491 insertions(+)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 39eee98ca7..bc1d6e3905 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -886,6 +886,15 @@ config MEDIATEK_ETH
  This Driver support MediaTek Ethernet GMAC
  Say Y to enable support for the MediaTek Ethernet GMAC.
 
+config HIFEMAC_ETH
+   bool "HiSilicon Fast Ethernet Controller"
+   select DM_CLK
+   select DM_RESET
+   select PHYLIB
+   help
+ This driver supports HIFEMAC Ethernet controller found on
+ HiSilicon SoCs.
+
 config HIGMACV300_ETH
bool "HiSilicon Gigabit Ethernet Controller"
select DM_RESET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 46a40e2ed9..de6bf1d014 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_FSL_PFE) += pfe_eth/
 obj-$(CONFIG_FTGMAC100) += ftgmac100.o
 obj-$(CONFIG_FTMAC100) += ftmac100.o
 obj-$(CONFIG_GMAC_ROCKCHIP) += gmac_rockchip.o
+obj-$(CONFIG_HIFEMAC_ETH) += hifemac.o
 obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
 obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
 obj-$(CONFIG_KSZ9477) += ksz9477.o
diff --git a/drivers/net/hifemac.c b/drivers/net/hifemac.c
new file mode 100644
index 00..b61a29e636
--- /dev/null
+++ b/drivers/net/hifemac.c
@@ -0,0 +1,481 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hisilicon Fast Ethernet MAC Driver
+ * Adapted from linux
+ *
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ * Copyright (c) 2023 Yang Xiwen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* MAC control register list */
+#define MAC_PORTSEL0x0200
+#define MAC_PORTSEL_STAT_CPU   BIT(0)
+#define MAC_PORTSEL_RMII   BIT(1)
+#define MAC_PORTSET0x0208
+#define MAC_PORTSET_DUPLEX_FULLBIT(0)
+#define MAC_PORTSET_LINKED BIT(1)
+#define MAC_PORTSET_SPEED_100M BIT(2)
+#define MAC_SET0x0210
+#define MAX_FRAME_SIZE 1600
+#define MAX_FRAME_SIZE_MASKGENMASK(10, 0)
+#define BIT_PAUSE_EN   BIT(18)
+#define RX_COALESCE_SET0x0340
+#define RX_COALESCED_FRAME_OFFSET  24
+#define RX_COALESCED_FRAMES8
+#define RX_COALESCED_TIMER 0x74
+#define QLEN_SET   0x0344
+#define RX_DEPTH_OFFSET8
+#define MAX_HW_FIFO_DEPTH  64
+#define HW_TX_FIFO_DEPTH   1
+#define MAX_HW_RX_FIFO_DEPTH   (MAX_HW_FIFO_DEPTH - HW_TX_FIFO_DEPTH)
+#define HW_RX_FIFO_DEPTH   min(PKTBUFSRX, MAX_HW_RX_FIFO_DEPTH)
+#define IQFRM_DES  0x0354
+#define RX_FRAME_LEN_MASK  GENMASK(11, 0)
+#define RX_FRAME_IN_INDEX_MASK GENMASK(17, 12)
+#define IQ_ADDR0x0358
+#define EQ_ADDR0x0360
+#define EQFRM_LEN  0x0364
+#define ADDRQ_STAT 0x036C
+#define TX_CNT_INUSE_MASK  GENMASK(5, 0)
+#define BIT_TX_READY   BIT(24)
+#define BIT_RX_READY   BIT(25)
+/* global control register list */
+#define GLB_HOSTMAC_L320x
+#define GLB_HOSTMAC_H160x0004
+#define GLB_SOFT_RESET 0x0008
+#define SOFT_RESET_ALL BIT(0)
+#define GLB_FWCTRL 0x0010
+#define FWCTRL_VLAN_ENABLE BIT(0)
+#define FWCTRL_FW2CPU_ENA  BIT(5)
+#define FWCTRL_FWALL2CPU   BIT(7)
+#define GLB_MACTCTRL   0x0014
+#define MACTCTRL_UNI2CPU   BIT(1)
+#define MACTCTRL_MULTI2CPU BIT(3)
+#define MACTCTRL_BROAD2CPU BIT(5)
+#define MACTCTRL_MACT_ENA  BIT(7)
+#define GLB_IRQ_STAT   0x0030
+#define GLB_IRQ_ENA0x0034
+#define IRQ_ENA_PORT0_MASK GENMASK(7, 0)
+#define IRQ_ENA_PORT0  BIT(18)
+#define IRQ_ENA_ALLBIT(19)
+#define GLB_IRQ_RAW0x0038
+#define IRQ_INT_RX_RDY BIT(0)
+#define IRQ_INT_TX_PER_PACKET  BIT(1)
+#define IRQ_INT_TX_FIFO_EMPTY  BIT(6)
+#define IRQ_INT_MULTI_RXRDYBIT(7)
+#define DEF_INT_MASK   (IRQ_INT_MULTI_RXRDY | \
+   IRQ_INT_TX_PER_PACKET | \
+  

[PATCH RESEND v2 2/2] net: add hifemac_mdio MDIO bus driver for HiSilicon platform

[Yang Xiwen via B4 Relay]

From: Yang Xiwen 

It adds the driver for the internal MDIO bus of HIFEMAC Ethernet
controller.  It's based on the mainstream linux driver.

Signed-off-by: Yang Xiwen 
---
 drivers/net/Kconfig|   8 
 drivers/net/Makefile   |   1 +
 drivers/net/hifemac_mdio.c | 116 +
 3 files changed, 125 insertions(+)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index bc1d6e3905..5c5bfb1263 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -895,6 +895,14 @@ config HIFEMAC_ETH
  This driver supports HIFEMAC Ethernet controller found on
  HiSilicon SoCs.
 
+config HIFEMAC_MDIO
+   bool "HiSilicon Fast Ethernet Controller MDIO interface"
+   depends on DM_MDIO
+   select DM_CLK
+   help
+ This driver supports the internal MDIO interface of HIFEMAC
+ Ethernet controller.
+
 config HIGMACV300_ETH
bool "HiSilicon Gigabit Ethernet Controller"
select DM_RESET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index de6bf1d014..b2d3da6934 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_FTGMAC100) += ftgmac100.o
 obj-$(CONFIG_FTMAC100) += ftmac100.o
 obj-$(CONFIG_GMAC_ROCKCHIP) += gmac_rockchip.o
 obj-$(CONFIG_HIFEMAC_ETH) += hifemac.o
+obj-$(CONFIG_HIFEMAC_MDIO) += hifemac_mdio.o
 obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
 obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
 obj-$(CONFIG_KSZ9477) += ksz9477.o
diff --git a/drivers/net/hifemac_mdio.c b/drivers/net/hifemac_mdio.c
new file mode 100644
index 00..343c5f3a38
--- /dev/null
+++ b/drivers/net/hifemac_mdio.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hisilicon Fast Ethernet MDIO Bus Driver
+ *
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MDIO_RWCTRL0x00
+#define MDIO_RO_DATA   0x04
+#define MDIO_WRITE BIT(13)
+#define MDIO_RW_FINISH BIT(15)
+#define BIT_PHY_ADDR_OFFSET8
+#define BIT_WR_DATA_OFFSET 16
+
+struct hisi_femac_mdio_data {
+   struct clk *clk;
+   void __iomem *membase;
+};
+
+static int hisi_femac_mdio_wait_ready(struct hisi_femac_mdio_data *data)
+{
+   u32 val;
+
+   return readl_poll_timeout(data->membase + MDIO_RWCTRL,
+ val, val & MDIO_RW_FINISH, 1);
+}
+
+static int hisi_femac_mdio_read(struct udevice *dev, int addr, int devad, int 
reg)
+{
+   struct hisi_femac_mdio_data *data = dev_get_priv(dev);
+   int ret;
+
+   ret = hisi_femac_mdio_wait_ready(data);
+   if (ret)
+   return ret;
+
+   writel((addr << BIT_PHY_ADDR_OFFSET) | reg,
+  data->membase + MDIO_RWCTRL);
+
+   ret = hisi_femac_mdio_wait_ready(data);
+   if (ret)
+   return ret;
+
+   return readl(data->membase + MDIO_RO_DATA) & 0x;
+}
+
+static int hisi_femac_mdio_write(struct udevice *dev, int addr, int devad, int 
reg, u16 val)
+{
+   struct hisi_femac_mdio_data *data = dev_get_priv(dev);
+   int ret;
+
+   ret = hisi_femac_mdio_wait_ready(data);
+   if (ret)
+   return ret;
+
+   writel(MDIO_WRITE | (val << BIT_WR_DATA_OFFSET) |
+  (addr << BIT_PHY_ADDR_OFFSET) | reg,
+  data->membase + MDIO_RWCTRL);
+
+   return hisi_femac_mdio_wait_ready(data);
+}
+
+static int hisi_femac_mdio_of_to_plat(struct udevice *dev)
+{
+   struct hisi_femac_mdio_data *data = dev_get_priv(dev);
+   int ret;
+
+   data->membase = dev_remap_addr(dev);
+   if (IS_ERR(data->membase)) {
+   ret = PTR_ERR(data->membase);
+   return log_msg_ret("Failed to remap base addr", ret);
+   }
+
+   // clk is optional
+   data->clk = devm_clk_get_optional(dev, NULL);
+
+   return 0;
+}
+
+static int hisi_femac_mdio_probe(struct udevice *dev)
+{
+   struct hisi_femac_mdio_data *data = dev_get_priv(dev);
+   int ret;
+
+   ret = clk_prepare_enable(data->clk);
+   if (ret)
+   return log_msg_ret("Failed to enable clk", ret);
+
+   return 0;
+}
+
+static const struct mdio_ops hisi_femac_mdio_ops = {
+   .read = hisi_femac_mdio_read,
+   .write = hisi_femac_mdio_write,
+};
+
+static const struct udevice_id hisi_femac_mdio_dt_ids[] = {
+   { .compatible = "hisilicon,hisi-femac-mdio" },
+   { }
+};
+
+U_BOOT_DRIVER(hisi_femac_mdio_driver) = {
+   .name = "hisi-femac-mdio",
+   .id = UCLASS_MDIO,
+   .of_match = hisi_femac_mdio_dt_ids,
+   .of_to_plat = hisi_femac_mdio_of_to_plat,
+   .probe = hisi_femac_mdio_probe,
+   .ops = _femac_mdio_ops,
+   .priv_auto = sizeof(struct hisi_femac_mdio_data),
+};

-- 
2.34.1

Re: [PATCH 17/17] board: usb: Replace legacy usb_gadget_handle_interrupts()

[Mattijs Korpershoek]

On sam., août 19, 2023 at 16:24, Marek Vasut  wrote:

> The usb_gadget_handle_interrupts() is no longer used anywhere,
> replace the remaining uses with dm_usb_gadget_handle_interrupts()
> which takes udevice as a parameter.
>
> Some of the UDC drivers currently ignore the index parameter altogether,
> those also ignore the udevice and have to be reworked. Other like the
> dwc3_uboot_handle_interrupt() had to be switched from index to udevice
> look up to avoid breakage.
>
> Signed-off-by: Marek Vasut 
> ---
> NOTE: Next step, get rid of dwc3_uboot_init()/dwc3_uboot_exit()
> ---
> Cc: Angus Ainslie 
> Cc: Dmitrii Merkurev 
> Cc: Eddie Cai 
> Cc: Kever Yang 
> Cc: Lukasz Majewski 
> Cc: Miquel Raynal 
> Cc: Mattijs Korpershoek 
> Cc: Nishanth Menon 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Cc: ker...@puri.sm
> ---
>  arch/arm/mach-rockchip/board.c  |  4 ++--
>  board/purism/librem5/spl.c  |  4 ++--
>  board/samsung/common/exynos5-dt.c   |  4 ++--
>  board/st/stih410-b2260/board.c  |  4 ++--
>  board/ti/am43xx/board.c |  6 +++---
>  drivers/usb/dwc3/core.c |  6 +++---
>  drivers/usb/dwc3/dwc3-omap.c|  8 
>  drivers/usb/gadget/at91_udc.c   |  2 +-
>  drivers/usb/gadget/atmel_usba_udc.c |  3 +--
>  drivers/usb/gadget/ci_udc.c |  4 ++--
>  drivers/usb/gadget/dwc2_udc_otg.c   | 12 ++--
>  drivers/usb/gadget/udc/udc-uclass.c | 12 
>  drivers/usb/host/usb-sandbox.c  |  5 -
>  drivers/usb/musb-new/musb_uboot.c   |  2 +-
>  include/dwc3-omap-uboot.h   |  2 +-
>  include/dwc3-uboot.h|  2 +-
>  include/linux/usb/gadget.h  |  2 +-
>  17 files changed, 28 insertions(+), 54 deletions(-)

Tested that I could reflash the vim3 bootloader (on mmc2boot0)

Reviewed-by: Mattijs Korpershoek 
Tested-by: Mattijs Korpershoek  # on khadas vim3

>
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index 8d7b39ba157..57f08e0be0e 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -299,9 +299,9 @@ static struct dwc3_device dwc3_device_data = {
>   .hsphy_mode = USBPHY_INTERFACE_MODE_UTMIW,
>  };
>  
> -int usb_gadget_handle_interrupts(int index)
> +int dm_usb_gadget_handle_interrupts(struct udevice *dev)
>  {
> - dwc3_uboot_handle_interrupt(0);
> + dwc3_uboot_handle_interrupt(dev);
>   return 0;
>  }
>  
> diff --git a/board/purism/librem5/spl.c b/board/purism/librem5/spl.c
> index 90f1fcf415f..581f0929662 100644
> --- a/board/purism/librem5/spl.c
> +++ b/board/purism/librem5/spl.c
> @@ -418,9 +418,9 @@ out:
>   return rv;
>  }
>  
> -int usb_gadget_handle_interrupts(int index)
> +int dm_usb_gadget_handle_interrupts(struct udevice *dev)
>  {
> - dwc3_uboot_handle_interrupt(0);
> + dwc3_uboot_handle_interrupt(dev);
>   return 0;
>  }
>  
> diff --git a/board/samsung/common/exynos5-dt.c 
> b/board/samsung/common/exynos5-dt.c
> index cde77d79a0f..726b7f0667a 100644
> --- a/board/samsung/common/exynos5-dt.c
> +++ b/board/samsung/common/exynos5-dt.c
> @@ -126,9 +126,9 @@ static struct dwc3_device dwc3_device_data = {
>   .index = 0,
>  };
>  
> -int usb_gadget_handle_interrupts(int index)
> +int dm_usb_gadget_handle_interrupts(struct udevice *dev)
>  {
> - dwc3_uboot_handle_interrupt(0);
> + dwc3_uboot_handle_interrupt(dev);
>   return 0;
>  }
>  
> diff --git a/board/st/stih410-b2260/board.c b/board/st/stih410-b2260/board.c
> index cd3a7dc51a2..e21cbc270e9 100644
> --- a/board/st/stih410-b2260/board.c
> +++ b/board/st/stih410-b2260/board.c
> @@ -50,9 +50,9 @@ static struct dwc3_device dwc3_device_data = {
>   .index = 0,
>  };
>  
> -int usb_gadget_handle_interrupts(int index)
> +int dm_usb_gadget_handle_interrupts(struct udevice *dev)
>  {
> - dwc3_uboot_handle_interrupt(index);
> + dwc3_uboot_handle_interrupt(dev);
>   return 0;
>  }
>  
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index 87e552a4701..58bfe7cd455 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -760,13 +760,13 @@ static struct ti_usb_phy_device usb_phy2_device = {
>   .index = 1,
>  };
>  
> -int usb_gadget_handle_interrupts(int index)
> +int dm_usb_gadget_handle_interrupts(struct udevice *dev)
>  {
>   u32 status;
>  
> - status = dwc3_omap_uboot_interrupt_status(index);
> + status = dwc3_omap_uboot_interrupt_status(dev);
>   if (status)
> - dwc3_uboot_handle_interrupt(index);
> + dwc3_uboot_handle_interrupt(dev);
>  
>   return 0;
>  }
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 49f6a1900b0..7ca9d09824e 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -986,18 +986,18 @@ void dwc3_uboot_exit(int index)
>  
>  /**
>   * dwc3_uboot_handle_interrupt - handle dwc3 core interrupt
> - * @index: index 

Re: [PATCH 16/17] dm: usb: udc: Drop legacy udevice handler functions

[Mattijs Korpershoek]

On sam., août 19, 2023 at 16:24, Marek Vasut  wrote:

> Remove legacy functions limited by the dev_array array,
> those are no longer used anywhere, all the code uses
> plain udevice based access now.
>
> The usb_gadget_handle_interrupts() is doing udevice look up
> until all call sites use dm_usb_gadget_handle_interrupts().
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Angus Ainslie 
> Cc: Dmitrii Merkurev 
> Cc: Eddie Cai 
> Cc: Kever Yang 
> Cc: Lukasz Majewski 
> Cc: Miquel Raynal 
> Cc: Mattijs Korpershoek 
> Cc: Nishanth Menon 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Cc: ker...@puri.sm
> ---
>  drivers/usb/gadget/udc/udc-uclass.c | 44 -
>  include/linux/usb/gadget.h  | 17 ---
>  2 files changed, 6 insertions(+), 55 deletions(-)

Reviewed-by: Mattijs Korpershoek 

>
> diff --git a/drivers/usb/gadget/udc/udc-uclass.c 
> b/drivers/usb/gadget/udc/udc-uclass.c
> index b4271b4be9f..7f54a3b00cb 100644
> --- a/drivers/usb/gadget/udc/udc-uclass.c
> +++ b/drivers/usb/gadget/udc/udc-uclass.c
> @@ -12,9 +12,6 @@
>  #include 
>  
>  #if CONFIG_IS_ENABLED(DM_USB_GADGET)
> -#define MAX_UDC_DEVICES 4
> -static struct udevice *dev_array[MAX_UDC_DEVICES];
> -
>  int udc_device_get_by_index(int index, struct udevice **udev)
>  {
>   struct udevice *dev = NULL;
> @@ -45,45 +42,16 @@ int udc_device_put(struct udevice *udev)
>  #endif
>  }
>  
> -int usb_gadget_initialize(int index)
> -{
> - int ret;
> - struct udevice *dev = NULL;
> -
> - if (index < 0 || index >= ARRAY_SIZE(dev_array))
> - return -EINVAL;
> - if (dev_array[index])
> - return 0;
> - ret = udc_device_get_by_index(index, );
> - if (!dev || ret) {
> - pr_err("No USB device found\n");
> - return -ENODEV;
> - }
> - dev_array[index] = dev;
> - return 0;
> -}
> -
> -int usb_gadget_release(int index)
> +int usb_gadget_handle_interrupts(int index)
>  {
> -#if CONFIG_IS_ENABLED(DM_DEVICE_REMOVE)
> + struct udevice *udc;
>   int ret;
> - if (index < 0 || index >= ARRAY_SIZE(dev_array))
> - return -EINVAL;
>  
> - ret = device_remove(dev_array[index]);
> - if (!ret)
> - dev_array[index] = NULL;
> - return ret;
> -#else
> - return -ENOSYS;
> -#endif
> -}
> + ret = udc_device_get_by_index(index, );
> + if (ret)
> + return ret;
>  
> -int usb_gadget_handle_interrupts(int index)
> -{
> - if (index < 0 || index >= ARRAY_SIZE(dev_array))
> - return -EINVAL;
> - return dm_usb_gadget_handle_interrupts(dev_array[index]);
> + return dm_usb_gadget_handle_interrupts(udc);
>  }
>  #else
>  /* Backwards hardware compatibility -- switch to DM_USB_GADGET */
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 5e9a6513d5b..54875d2716e 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -1023,21 +1023,4 @@ int udc_device_get_by_index(int index, struct udevice 
> **udev);
>   */
>  int udc_device_put(struct udevice *udev);
>  
> -#if CONFIG_IS_ENABLED(DM_USB_GADGET)
> -int usb_gadget_initialize(int index);
> -int usb_gadget_release(int index);
> -int dm_usb_gadget_handle_interrupts(struct udevice *dev);
> -#else
> -#include 
> -static inline int usb_gadget_initialize(int index)
> -{
> - return board_usb_init(index, USB_INIT_DEVICE);
> -}
> -
> -static inline int usb_gadget_release(int index)
> -{
> - return board_usb_cleanup(index, USB_INIT_DEVICE);
> -}
> -#endif
> -
>  #endif   /* __LINUX_USB_GADGET_H */
> -- 
> 2.40.1

Re: [PATCH] spl: watchdog: introduce SPL_HW_WATCHDOG

[Oleksandr Suvorov]

On Tue, Aug 22, 2023 at 7:28 PM Fabio Estevam  wrote:
>
> Hi Oleksandr,
>
> On Tue, Aug 22, 2023 at 12:53 PM Oleksandr Suvorov
>  wrote:
>
> > ddr-1d-imem-fw {
> > -   filename = "lpddr4_pmu_train_1d_imem_202006.bin";
> > +   filename = "lpddr4_pmu_train_1d_imem.bin";
> > type = "blob-ext";
> > align-end = <4>;
> > };
> >
> > ddr-1d-dmem-fw {
> > -   filename = "lpddr4_pmu_train_1d_dmem_202006.bin";
> > +   filename = "lpddr4_pmu_train_1d_dmem.bin";
> > type = "blob-ext";
> > align-end = <4>;
> > };
> >
> > ddr-2d-imem-fw {
> > -   filename = "lpddr4_pmu_train_2d_imem_202006.bin";
> > +   filename = "lpddr4_pmu_train_2d_imem.bin";
>
> Unrelated changes?

Oops, yes, sorry, I'll resend the fixed version soon.

-- 
Best regards
Oleksandr

Oleksandr Suvorov
cryo...@gmail.com

Re: [PATCH 12/17] sdp: Use plain udevice for UDC controller interaction

[Mattijs Korpershoek]

On sam., août 19, 2023 at 16:24, Marek Vasut  wrote:

> Convert to plain udevice interaction with UDC controller
> device, avoid the use of UDC uclass dev_array .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Angus Ainslie 
> Cc: Dmitrii Merkurev 
> Cc: Eddie Cai 
> Cc: Kever Yang 
> Cc: Lukasz Majewski 
> Cc: Miquel Raynal 
> Cc: Mattijs Korpershoek 
> Cc: Nishanth Menon 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Cc: ker...@puri.sm
> ---
>  cmd/usb_gadget_sdp.c   | 11 +++
>  common/spl/spl_sdp.c   | 13 -
>  drivers/usb/gadget/f_sdp.c | 10 +-
>  include/sdp.h  |  6 +++---
>  4 files changed, 23 insertions(+), 17 deletions(-)

Reviewed-by: Mattijs Korpershoek 

>
> diff --git a/cmd/usb_gadget_sdp.c b/cmd/usb_gadget_sdp.c
> index 784d1b49768..748aa0a7488 100644
> --- a/cmd/usb_gadget_sdp.c
> +++ b/cmd/usb_gadget_sdp.c
> @@ -15,13 +15,16 @@
>  static int do_sdp(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[])
>  {
>   int controller_index;
> + struct udevice *udc;
>   int ret;
>  
>   if (argc < 2)
>   return CMD_RET_USAGE;
>  
>   controller_index = simple_strtoul(argv[1], NULL, 0);
> - usb_gadget_initialize(controller_index);
> + ret = udc_device_get_by_index(controller_index, );
> + if (ret)
> + return ret;
>  
>   g_dnl_clear_detach();
>   ret = g_dnl_register("usb_dnl_sdp");
> @@ -30,20 +33,20 @@ static int do_sdp(struct cmd_tbl *cmdtp, int flag, int 
> argc, char *const argv[])
>   goto exit_register;
>   }
>  
> - ret = sdp_init(controller_index);
> + ret = sdp_init(udc);
>   if (ret) {
>   pr_err("SDP init failed: %d\n", ret);
>   goto exit;
>   }
>  
>   /* This command typically does not return but jumps to an image */
> - sdp_handle(controller_index);
> + sdp_handle(udc);
>   pr_err("SDP ended\n");
>  
>  exit:
>   g_dnl_unregister();
>  exit_register:
> - usb_gadget_release(controller_index);
> + udc_device_put(udc);
>  
>   return CMD_RET_FAILURE;
>  }
> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
> index f6b99c1af5a..83585cf82d3 100644
> --- a/common/spl/spl_sdp.c
> +++ b/common/spl/spl_sdp.c
> @@ -14,10 +14,13 @@
>  static int spl_sdp_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
>  {
> - int ret;
>   const int controller_index = CONFIG_SPL_SDP_USB_DEV;
> + struct udevice *udc;
> + int ret;
>  
> - usb_gadget_initialize(controller_index);
> + ret = udc_device_get_by_index(controller_index, );
> + if (ret)
> + return ret;
>  
>   board_usb_init(controller_index, USB_INIT_DEVICE);
>  
> @@ -28,7 +31,7 @@ static int spl_sdp_load_image(struct spl_image_info 
> *spl_image,
>   goto err_detach;
>   }
>  
> - ret = sdp_init(controller_index);
> + ret = sdp_init(udc);
>   if (ret) {
>   pr_err("SDP init failed: %d\n", ret);
>   goto err_detach;
> @@ -39,11 +42,11 @@ static int spl_sdp_load_image(struct spl_image_info 
> *spl_image,
>* or it loads a FIT image and returns it to be handled by the SPL
>* code.
>*/
> - ret = spl_sdp_handle(controller_index, spl_image, bootdev);
> + ret = spl_sdp_handle(udc, spl_image, bootdev);
>   debug("SDP ended\n");
>  
>  err_detach:
> - usb_gadget_release(controller_index);
> + udc_device_put(udc);
>   return ret;
>  }
>  SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD, spl_sdp_load_image);
> diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
> index 4da5a160a09..37f6281abfb 100644
> --- a/drivers/usb/gadget/f_sdp.c
> +++ b/drivers/usb/gadget/f_sdp.c
> @@ -702,7 +702,7 @@ static int sdp_bind_config(struct usb_configuration *c)
>   return status;
>  }
>  
> -int sdp_init(int controller_index)
> +int sdp_init(struct udevice *udc)
>  {
>   printf("SDP: initialize...\n");
>   while (!sdp_func->configuration_done) {
> @@ -712,7 +712,7 @@ int sdp_init(int controller_index)
>   }
>  
>   schedule();
> - usb_gadget_handle_interrupts(controller_index);
> + dm_usb_gadget_handle_interrupts(udc);
>   }
>  
>   return 0;
> @@ -911,9 +911,9 @@ static void sdp_handle_out_ep(void)
>  }
>  
>  #ifndef CONFIG_SPL_BUILD
> -int sdp_handle(int controller_index)
> +int sdp_handle(struct udevice *udc)
>  #else
> -int spl_sdp_handle(int controller_index, struct spl_image_info *spl_image,
> +int spl_sdp_handle(struct udevice *udc, struct spl_image_info *spl_image,
>  struct spl_boot_device *bootdev)
>  #endif
>  {
> @@ -929,7 +929,7 @@ int spl_sdp_handle(int controller_index, struct 
> spl_image_info *spl_image,
>   return 0;
>  
>   schedule();
> - 

Re: [PATCH 11/17] spl: sdp: Detach the controller on error

[Mattijs Korpershoek]

On sam., août 19, 2023 at 16:24, Marek Vasut  wrote:

> In case anything errors out during the SDP transfer, detach
> the controller instead of bailing out right away. This way,
> the controller can be reattached on next attempt.
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Angus Ainslie 
> Cc: Dmitrii Merkurev 
> Cc: Eddie Cai 
> Cc: Kever Yang 
> Cc: Lukasz Majewski 
> Cc: Miquel Raynal 
> Cc: Mattijs Korpershoek 
> Cc: Nishanth Menon 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Cc: ker...@puri.sm
> ---

Reviewed-by: Mattijs Korpershoek 

Nitpick/question below

>  common/spl/spl_sdp.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
> index cc4fb4f7cca..f6b99c1af5a 100644
> --- a/common/spl/spl_sdp.c
> +++ b/common/spl/spl_sdp.c
> @@ -25,13 +25,13 @@ static int spl_sdp_load_image(struct spl_image_info 
> *spl_image,
>   ret = g_dnl_register("usb_dnl_sdp");
>   if (ret) {
>   pr_err("SDP dnl register failed: %d\n", ret);
> - return ret;
> + goto err_detach;
>   }
>  
>   ret = sdp_init(controller_index);
>   if (ret) {
>   pr_err("SDP init failed: %d\n", ret);
> - return -ENODEV;
> + goto err_detach;

Shouldn't we call g_dnl_unregister(); here since g_dnl_register() was
sucessfully called before?

This would match what's done in common/dfu.c

>   }
>  
>   /*
> @@ -42,6 +42,7 @@ static int spl_sdp_load_image(struct spl_image_info 
> *spl_image,
>   ret = spl_sdp_handle(controller_index, spl_image, bootdev);
>   debug("SDP ended\n");
>  
> +err_detach:
>   usb_gadget_release(controller_index);
>   return ret;
>  }
> -- 
> 2.40.1

[PATCH 12/13] doc: board: ti: j721e: Fix build step numbering

[Nishanth Menon]

Fix up build step numbering.

Fixes: c727b81d6530 ("doc: board: ti: k3: Reuse build instructions")
Signed-off-by: Nishanth Menon 
---
 doc/board/ti/j721e_evm.rst | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst
index a4c464707c6a..cadaac017811 100644
--- a/doc/board/ti/j721e_evm.rst
+++ b/doc/board/ti/j721e_evm.rst
@@ -97,13 +97,13 @@ Set the variables corresponding to this platform:
 
 3. U-Boot:
 
-* 4.1 R5:
+* 3.1 R5:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_spl_r5
 :end-before: .. k3_rst_include_end_build_steps_spl_r5
 
-* 4.2 A72:
+* 3.2 A72:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_uboot
@@ -118,18 +118,18 @@ files.
 
  - GP
 
-* tiboot3-j721e-gp-evm.bin, sysfw-j721e-gp-evm.itb from step 4.1
-* tispl.bin_unsigned, u-boot.img_unsigned from step 4.2
+* tiboot3-j721e-gp-evm.bin, sysfw-j721e-gp-evm.itb from step 3.1
+* tispl.bin_unsigned, u-boot.img_unsigned from step 3.2
 
  - HS-FS
 
-* tiboot3-j721e_sr2-hs-fs-evm.bin, sysfw-j721e_sr2-hs-fs-evm.itb from 
step 4.1
-* tispl.bin, u-boot.img from step 4.2
+* tiboot3-j721e_sr2-hs-fs-evm.bin, sysfw-j721e_sr2-hs-fs-evm.itb from 
step 3.1
+* tispl.bin, u-boot.img from step 3.2
 
  - HS-SE
 
-* tiboot3-j721e_sr2-hs-evm.bin, sysfw-j721e_sr2-hs-evm.itb from step 
4.1
-* tispl.bin, u-boot.img from step 4.2
+* tiboot3-j721e_sr2-hs-evm.bin, sysfw-j721e_sr2-hs-evm.itb from step 
3.1
+* tispl.bin, u-boot.img from step 3.2
 
 Image formats:
 --
-- 
2.40.0

[PATCH 13/13] doc: board: ti: k3: Elaborate on various firmware

[Nishanth Menon]

Add elaboration text for the various firmware involved for system
management.

Signed-off-by: Nishanth Menon 
---
 doc/board/ti/k3.rst | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index e7c8d37dd269..83fb0f121bb9 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -124,11 +124,30 @@ online
   | **source:** https://github.com/OP-TEE/optee_os.git
   | **branch:** master
 
-* **TI Firmware (TIFS, DM, DSMC)**
+* **TI Firmware (TIFS, DM, SYSFW)**
 
   | **source:** https://git.ti.com/git/processor-firmware/ti-linux-firmware.git
   | **branch:** ti-linux-firmware
 
+.. note::
+
+  The TI Firmware required for functionality of the system can be
+  one of the following combination (see platform specific boot diagram for
+  further information as to which component runs on which processor):
+
+  * **TIFS** - TI Foundational Security Firmware - Consists of purely firmware
+meant to run on the security enclave.
+  * **DM** - Device Management firmware also called TI System Control Interface
+server (TISCI Server) - This component purely plays the role of managing
+device resources such as power, clock, interrupts, dma etc. This firmware
+runs on a dedicated or multi-use microcontroller outside the security
+enclave.
+
+ OR
+
+  * **SYSFW** - System firmware - consists of both TIFS and DM both running on
+the security enclave.
+
 .. k3_rst_include_end_boot_sources
 
 Build Procedure
-- 
2.40.0

[PATCH 11/13] doc: board: ti: j7200: Fix build step numbering

[Nishanth Menon]

Fix up build step numbering.

Fixes: c727b81d6530 ("doc: board: ti: k3: Reuse build instructions")
Signed-off-by: Nishanth Menon 
---
 doc/board/ti/j7200_evm.rst | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/board/ti/j7200_evm.rst b/doc/board/ti/j7200_evm.rst
index 2bf680cda2c7..bcf8dc1c5f0d 100644
--- a/doc/board/ti/j7200_evm.rst
+++ b/doc/board/ti/j7200_evm.rst
@@ -92,13 +92,13 @@ Set the variables corresponding to this platform:
 
 3. U-Boot:
 
-* 4.1 R5:
+* 3.1 R5:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_spl_r5
 :end-before: .. k3_rst_include_end_build_steps_spl_r5
 
-* 4.2 A72:
+* 3.2 A72:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_uboot
@@ -112,18 +112,18 @@ variant (GP, HS-FS, HS-SE) requires a different source 
for these files.
 
  - GP
 
-* tiboot3-j7200-gp-evm.bin from step 4.1
-* tispl.bin_unsigned, u-boot.img_unsigned from step 4.2
+* tiboot3-j7200-gp-evm.bin from step 3.1
+* tispl.bin_unsigned, u-boot.img_unsigned from step 3.2
 
  - HS-FS
 
-* tiboot3-j7200_sr2-hs-fs-evm.bin from step 4.1
-* tispl.bin, u-boot.img from step 4.2
+* tiboot3-j7200_sr2-hs-fs-evm.bin from step 3.1
+* tispl.bin, u-boot.img from step 3.2
 
  - HS-SE
 
-* tiboot3-j7200_sr2-hs-evm.bin from step 4.1
-* tispl.bin, u-boot.img from step 4.2
+* tiboot3-j7200_sr2-hs-evm.bin from step 3.1
+* tispl.bin, u-boot.img from step 3.2
 
 Image formats:
 --
-- 
2.40.0

[PATCH 08/13] doc: board: ti: am62x: Fix build step numbering

[Nishanth Menon]

Fix up build step numbering.

Fixes: c727b81d6530 ("doc: board: ti: k3: Reuse build instructions")
Signed-off-by: Nishanth Menon 
---
 doc/board/ti/am62x_sk.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst
index 42b37f9c76fd..d7437c6d22f7 100644
--- a/doc/board/ti/am62x_sk.rst
+++ b/doc/board/ti/am62x_sk.rst
@@ -103,13 +103,13 @@ Set the variables corresponding to this platform:
 
 3. U-Boot:
 
-* 4.1 R5:
+* 3.1 R5:
 
 .. include::  ../ti/k3.rst
 :start-after: .. k3_rst_include_start_build_steps_spl_r5
 :end-before: .. k3_rst_include_end_build_steps_spl_r5
 
-* 4.2 A53:
+* 3.2 A53:
 
 .. include::  ../ti/k3.rst
 :start-after: .. k3_rst_include_start_build_steps_uboot
-- 
2.40.0

[PATCH 05/13] doc: board: ti: am65x: provide image alt text

[Nishanth Menon]

From: Heinrich Schuchardt 

Provide alternative text for image.

Fixes: fd358121bdb8 ("doc: board: ti: am65x: Update with boot flow diagram")
Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Nishanth Menon 
---
Changes:
* Added missing updates of alt tag
* Fixed up a few text info
* now based on next

V1: 
https://lore.kernel.org/r/20230819030531.31051-1-heinrich.schucha...@canonical.com
 doc/board/ti/am65x_evm.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/board/ti/am65x_evm.rst b/doc/board/ti/am65x_evm.rst
index 5f3c46cf9f9e..10e30f45cfd9 100644
--- a/doc/board/ti/am65x_evm.rst
+++ b/doc/board/ti/am65x_evm.rst
@@ -46,6 +46,7 @@ applications. This should happen before running Linux.
 instead use Falcon boot flow to reduce boot time.
 
 .. image:: img/boot_diagram_am65.svg
+  :alt: Boot flow diagram
 
 - Here DMSC acts as master and provides all the critical services. R5/A53
   requests DMSC to get these services done as shown in the above diagram.
@@ -136,14 +137,17 @@ Image formats:
 - tiboot3.bin
 
 .. image:: img/no_multi_cert_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
 
 - tispl.bin
 
 .. image:: img/nodm_tispl.bin.svg
+  :alt: tispl.bin image format
 
 - sysfw.itb
 
 .. image:: img/sysfw.itb.svg
+  :alt: sysfw.itb image format
 
 eMMC:
 -
@@ -185,6 +189,7 @@ used:
 eMMC layout:
 
 .. image:: img/emmc_am65x_evm_boot0.svg
+  :alt: emmc boot partition layout
 
 Kernel image and DT are expected to be present in the /boot folder of rootfs.
 To boot kernel from eMMC, use the following commands:
@@ -220,6 +225,7 @@ addresses.
 Flash layout for OSPI:
 
 .. image:: img/ospi_sysfw.svg
+  :alt: OSPI flash partition layout
 
 Kernel Image and DT are expected to be present in the /boot folder of UBIFS
 ospi.rootfs just like in SD card case. U-Boot looks for UBI volume named
-- 
2.40.0

[PATCH 10/13] doc: board: ti: am65x: Fix build step numbering

[Nishanth Menon]

Fix up build step numbering.

Fixes: c727b81d6530 ("doc: board: ti: k3: Reuse build instructions")
Signed-off-by: Nishanth Menon 
---
 doc/board/ti/am65x_evm.rst | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/board/ti/am65x_evm.rst b/doc/board/ti/am65x_evm.rst
index 10e30f45cfd9..7cebb1ca62d3 100644
--- a/doc/board/ti/am65x_evm.rst
+++ b/doc/board/ti/am65x_evm.rst
@@ -103,13 +103,13 @@ Set the variables corresponding to this platform:
 
 3. U-Boot:
 
-* 4.1 R5:
+* 3.1 R5:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_spl_r5
 :end-before: .. k3_rst_include_end_build_steps_spl_r5
 
-* 4.2 A53:
+* 3.2 A53:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_uboot
@@ -123,13 +123,13 @@ Each SoC variant (GP and HS) requires a different source 
for these files.
 
 - GP
 
-* tiboot3-am65x_sr2-gp-evm.bin, sysfw-am65x_sr2-gp-evm.itb from step 
4.1
-* tispl.bin_unsigned, u-boot.img_unsigned from step 4.2
+* tiboot3-am65x_sr2-gp-evm.bin, sysfw-am65x_sr2-gp-evm.itb from step 
3.1
+* tispl.bin_unsigned, u-boot.img_unsigned from step 3.2
 
 - HS
 
-* tiboot3-am65x_sr2-hs-evm.bin, sysfw-am65x_sr2-hs-evm.itb from step 
4.1
-* tispl.bin, u-boot.img from step 4.2
+* tiboot3-am65x_sr2-hs-evm.bin, sysfw-am65x_sr2-hs-evm.itb from step 
3.1
+* tispl.bin, u-boot.img from step 3.2
 
 Image formats:
 --
-- 
2.40.0

[PATCH 09/13] doc: board: ti: am64x: Fix build step numbering

[Nishanth Menon]

Fix up build step numbering.

Fixes: 4bf49bade124 ("doc: board: ti: am64: Add boot flow diagram")
Signed-off-by: Nishanth Menon 
---
 doc/board/ti/am64x_evm.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/board/ti/am64x_evm.rst b/doc/board/ti/am64x_evm.rst
index 01e536dac9d7..db27461cb14d 100644
--- a/doc/board/ti/am64x_evm.rst
+++ b/doc/board/ti/am64x_evm.rst
@@ -93,13 +93,13 @@ Set the variables corresponding to this platform:
 
 3. U-Boot:
 
-* 4.1 R5:
+* 3.1 R5:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_spl_r5
 :end-before: .. k3_rst_include_end_build_steps_spl_r5
 
-* 4.2 A53:
+* 3.2 A53:
 
 .. include::  k3.rst
 :start-after: .. k3_rst_include_start_build_steps_uboot
-- 
2.40.0

[PATCH 01/13] doc: board: ti: k3: image alt texts

[Nishanth Menon]

From: Heinrich Schuchardt 

Provide alternative texts for images.

Fixes: 6e8fa0611f19 ("board: ti: k3: Convert boot flow ascii flow to svg")
Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Nishanth Menon 
---

Changes since v1:
* Minor expansion of WKUP domain, main domain.

V1: 
https://lore.kernel.org/r/20230819024948.30103-1-heinrich.schucha...@canonical.com

 doc/board/ti/k3.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index 5f9bd4dfcbe9..843e66eb2e60 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -48,6 +48,7 @@ including a 32bit U-Boot SPL, (called the wakup SPL) that ROM 
will jump
 to after it has finished loading everything into internal SRAM.
 
 .. image:: img/boot_flow_01.svg
+  :alt: Boot flow up to wakeup domain SPL
 
 The wakeup SPL, running on a wakeup domain core, will initialize DDR and
 any peripherals needed load the larger binaries inside the `tispl.bin`
@@ -57,6 +58,7 @@ starting with Trusted Firmware-A (TF-A), before moving on to 
start
 OP-TEE and the main domain's U-Boot SPL.
 
 .. image:: img/boot_flow_02.svg
+  :alt: Boot flow up to main domain SPL
 
 The main domain's SPL, running on a 64bit application core, has
 virtually unlimited space (billions of bytes now that DDR is working) to
@@ -65,6 +67,7 @@ which loads more firmware into the micro-controller & wakeup 
domains and
 finally prepare the main domain to run Linux.
 
 .. image:: img/boot_flow_03.svg
+  :alt: Complete boot flow up to Linux
 
 This is the typical boot flow for all K3 based SoCs, however this flow
 offers quite a lot in the terms of flexibility, especially on High
-- 
2.40.0

[PATCH 04/13] doc: board: ti: am64x: provide image alt text

[Nishanth Menon]

Provide alternative text for image.

Fixes: 4bf49bade124 ("doc: board: ti: am64: Add boot flow diagram")
Reported-by: Heinrich Schuchardt 
Signed-off-by: Nishanth Menon 
---
new
 doc/board/ti/am64x_evm.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/board/ti/am64x_evm.rst b/doc/board/ti/am64x_evm.rst
index 8d3795eb3264..01e536dac9d7 100644
--- a/doc/board/ti/am64x_evm.rst
+++ b/doc/board/ti/am64x_evm.rst
@@ -36,6 +36,7 @@ Boot Flow:
 Below is the pictorial representation of boot flow:
 
 .. image:: img/boot_diagram_am64.svg
+  :alt: Boot flow diagram
 
 - Here TIFS acts as master and provides all the critical services. R5/A53
   requests TIFS to get these services done as shown in the above diagram.
@@ -131,10 +132,12 @@ Image formats:
 - tiboot3.bin
 
 .. image:: img/multi_cert_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
 
 - tispl.bin
 
 .. image:: img/nodm_tispl.bin.svg
+  :alt: tispl.bin image format
 
 Switch Setting for Boot Mode
 
-- 
2.40.0

[PATCH 06/13] doc: board: ti: j7200: provide image alt text

[Nishanth Menon]

Provide alternative text for image.

Fixes: f4ade09a1e76 ("doc: board: ti: j7200: Convert the image format to svg")
Reported-by: Heinrich Schuchardt 
Signed-off-by: Nishanth Menon 
---
new

 doc/board/ti/j7200_evm.rst | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/board/ti/j7200_evm.rst b/doc/board/ti/j7200_evm.rst
index 2e60e22ba151..2bf680cda2c7 100644
--- a/doc/board/ti/j7200_evm.rst
+++ b/doc/board/ti/j7200_evm.rst
@@ -35,6 +35,7 @@ Boot Flow:
 Below is the pictorial representation of boot flow:
 
 .. image:: img/boot_diagram_k3_current.svg
+  :alt: Boot flow diagram
 
 - Here DMSC acts as master and provides all the critical services. R5/A72
   requests DMSC to get these services done as shown in the above diagram.
@@ -130,12 +131,12 @@ Image formats:
 - tiboot3.bin
 
 .. image:: img/j7200_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
 
 - tispl.bin
 
 .. image:: img/dm_tispl.bin.svg
-
-
+  :alt: tispl.bin image format
 
 Switch Setting for Boot Mode
 
@@ -191,6 +192,7 @@ Size of u-boot.img is taken 4MB for refernece,
 But this is subject to change depending upon atf, optee size
 
 .. image:: img/emmc_j7200_evm_boot01.svg
+  :alt: Traditional eMMC boot partition layout
 
 In case of UDA FS mode booting, following is layout.
 
@@ -198,6 +200,7 @@ All boot images tiboot3.bin, tispl and u-boot should be 
written to
 fat formatted UDA FS as file.
 
 .. image:: img/emmc_j7200_evm_udafs.svg
+  :alt: eMMC UDA boot partition layout
 
 In case of booting from eMMC, write above images into raw or UDA FS.
 and set mmc partconf accordingly.
-- 
2.40.0

[PATCH 02/13] doc: board: ti: k3: Fixup alt text for openocd sequence

[Nishanth Menon]

Fix up OpenOCD setup sequence

Fixes: effe50854a69 ("doc: board: ti: k3: Add a guide to debugging with 
OpenOCD")
Reported-by: Heinrich Schuchardt 
Signed-off-by: Nishanth Menon 
---
New in the series.
 doc/board/ti/k3.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index 843e66eb2e60..e7c8d37dd269 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -489,6 +489,7 @@ generation device.
 The overall structure of this setup is in the following figure.
 
 .. image:: img/openocd-overview.svg
+  :alt: Overview of OpenOCD setup.
 
 .. note::
 
-- 
2.40.0