Re: [PATCH 0/6] mtd: nand: sunxi: Convert to devicetree and the driver model

[Michael Nazzareno Trimarchi]

Hi Samuel

On Thu, Jul 14, 2022 at 5:15 AM Samuel Holland  wrote:
>
> This series converts the sunxi NAND driver to get its resources (clocks,
> resets, pins) from the devicetree, and probe using the driver model.
>
> In addition to the immediate cleanup, this allows backporting more
> patches (bugfixes, newer SoC support) from the Linux driver.
>
>
> Samuel Holland (6):
>   clk: sunxi: Add NAND clocks and resets
>   pinctrl: sunxi: Add NAND pinmuxes
>   mtd: nand: sunxi: Remove an unnecessary check
>   mtd: nand: sunxi: Convert from fdtdec to ofnode
>   mtd: nand: sunxi: Convert to the driver model
>   mtd: nand: sunxi: Pass the device to the init function
>
>  board/sunxi/board.c   |   5 +-
>  drivers/clk/sunxi/clk_a10.c   |   2 +
>  drivers/clk/sunxi/clk_a10s.c  |   2 +
>  drivers/clk/sunxi/clk_a23.c   |   3 +
>  drivers/clk/sunxi/clk_a31.c   |   6 +
>  drivers/clk/sunxi/clk_a64.c   |   3 +
>  drivers/clk/sunxi/clk_a80.c   |   8 ++
>  drivers/clk/sunxi/clk_a83t.c  |   3 +
>  drivers/clk/sunxi/clk_h3.c|   3 +
>  drivers/clk/sunxi/clk_h6.c|   6 +
>  drivers/clk/sunxi/clk_h616.c  |   6 +
>  drivers/clk/sunxi/clk_r40.c   |   3 +
>  drivers/mtd/nand/raw/sunxi_nand.c | 173 --
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c |  13 ++
>  include/fdtdec.h  |   1 -
>  lib/fdtdec.c  |   1 -
>  16 files changed, 138 insertions(+), 100 deletions(-)
>

Was in our roadmap and thank you for it. We are looking for sunxi
boards that have nand, can you please point where we can find them?

We are still in the process of setting up our account, anyway we will
review it quickly.

Michael

> --
> 2.35.1
>

Re: [PATCH v6 02/13] FWU: Add FWU metadata structure and driver for accessing metadata

[Sughosh Ganu]

hi Patrick,

On Wed, 13 Jul 2022 at 18:42, Patrick DELAUNAY
 wrote:
>
> Hi,
>
> On 7/4/22 07:16, Sughosh Ganu wrote:
> > In the FWU Multi Bank Update feature, the information about the
> > updatable images is stored as part of the metadata, which is stored on
> > a dedicated partition. Add the metadata structure, and a driver model
> > uclass which provides functions to access the metadata. These are
> > generic API's, and implementations can be added based on parameters
> > like how the metadata partition is accessed and what type of storage
> > device houses the metadata.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> > Changes since V5:
> > * Change the parameter to the function fwu_plat_get_alt_num to pass
> >the FWU udevice pointer instead of passing the metadata device
> >directly.
> >
> >   drivers/Kconfig  |   2 +
> >   drivers/Makefile |   1 +
> >   drivers/fwu-mdata/Kconfig|   7 +
> >   drivers/fwu-mdata/Makefile   |   6 +
> >   drivers/fwu-mdata/fwu-mdata-uclass.c | 458 +++
> >   include/dm/uclass-id.h   |   1 +
> >   include/fwu.h|  49 +++
> >   include/fwu_mdata.h  |  67 
> >   8 files changed, 591 insertions(+)
> >   create mode 100644 drivers/fwu-mdata/Kconfig
> >   create mode 100644 drivers/fwu-mdata/Makefile
> >   create mode 100644 drivers/fwu-mdata/fwu-mdata-uclass.c
> >   create mode 100644 include/fwu.h
> >   create mode 100644 include/fwu_mdata.h
> >
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index b26ca8cf70..adc6079ecf 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
> >
> >   source "drivers/fpga/Kconfig"
> >
> > +source "drivers/fwu-mdata/Kconfig"
> > +
> >   source "drivers/gpio/Kconfig"
> >
> >   source "drivers/hwspinlock/Kconfig"
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 67c8af7442..901150bb35 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -83,6 +83,7 @@ obj-y += cache/
> >   obj-$(CONFIG_CPU) += cpu/
> >   obj-y += crypto/
> >   obj-$(CONFIG_FASTBOOT) += fastboot/
> > +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
> >   obj-y += misc/
> >   obj-$(CONFIG_MMC) += mmc/
> >   obj-$(CONFIG_NVME) += nvme/
> > diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> > new file mode 100644
> > index 00..d6a21c8e19
> > --- /dev/null
> > +++ b/drivers/fwu-mdata/Kconfig
> > @@ -0,0 +1,7 @@
> > +config DM_FWU_MDATA
> > + bool "Driver support for accessing FWU Metadata"
> > + depends on DM
> > + help
> > +   Enable support for accessing FWU Metadata partitions. The
> > +   FWU Metadata partitions reside on the same storage device
> > +   which contains the other FWU updatable firmware images.
> > diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> > new file mode 100644
> > index 00..e53a8c9983
> > --- /dev/null
> > +++ b/drivers/fwu-mdata/Makefile
> > @@ -0,0 +1,6 @@
> > +# SPDX-License-Identifier: GPL-2.0-or-later
> > +#
> > +# Copyright (c) 2022, Linaro Limited
> > +#
> > +
> > +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
> > diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
> > b/drivers/fwu-mdata/fwu-mdata-uclass.c
> > new file mode 100644
> > index 00..2092fcfc23
> > --- /dev/null
> > +++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
> > @@ -0,0 +1,458 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2022, Linaro Limited
> > + */
> > +
>
> #define LOG_CATEGORY UCLASS_FWU_MDATA

Will add. Thanks.

-sughosh

>
>
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define IMAGE_ACCEPT_SET BIT(0)
> > +#define IMAGE_ACCEPT_CLEAR   BIT(1)
> > +
> > +static int fwu_get_dev_ops(struct udevice **dev,
> > +const struct fwu_mdata_ops **ops)
> > +{
> > + int ret;
> > +
> > + ret = uclass_get_device(UCLASS_FWU_MDATA, 0, dev);
> > + if (ret) {
> > + log_debug("Cannot find fwu device\n");
> > + return ret;
> > + }
> > +
> > + if ((*ops = device_get_ops(*dev)) == NULL) {
> > + log_debug("Cannot get fwu device ops\n");
> > + return -ENOSYS;
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> (...)
>
> with this minor update
>
> Reviewed-by: Patrick Delaunay 
>
> Thanks
> Patrick
>

Re: [PATCH v6 03/13] FWU: Add FWU metadata access driver for GPT partitioned block devices

[Sughosh Ganu]

hi Patrick,

On Wed, 13 Jul 2022 at 18:47, Patrick DELAUNAY
 wrote:
>
> Hi,
>
> On 7/4/22 07:16, Sughosh Ganu wrote:
> > In the FWU Multi Bank Update feature, the information about the
> > updatable images is stored as part of the metadata, on a separate
> > partition. Add a driver for reading from and writing to the metadata
> > when the updatable images and the metadata are stored on a block
> > device which is formated with GPT based partition scheme.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> > Changes since V5:
> > * Changed the logic to store the GPT partitioned block device through
> >a priv structure as suggested by Patrick
> > * Used dev_read_prop() to get the phandle_p instead of
> >ofnode_get_property() used earlier as suggested by Patrick
> > * Make relevant functions static as suggested by Etienne
> >
> >   drivers/fwu-mdata/Kconfig |   9 +
> >   drivers/fwu-mdata/Makefile|   1 +
> >   drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 408 ++
> >   include/fwu.h |   5 +
> >   4 files changed, 423 insertions(+)
> >   create mode 100644 drivers/fwu-mdata/fwu_mdata_gpt_blk.c
> >
> > diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> > index d6a21c8e19..d5edef19d6 100644
> > --- a/drivers/fwu-mdata/Kconfig
> > +++ b/drivers/fwu-mdata/Kconfig
> > @@ -5,3 +5,12 @@ config DM_FWU_MDATA
> > Enable support for accessing FWU Metadata partitions. The
> > FWU Metadata partitions reside on the same storage device
> > which contains the other FWU updatable firmware images.
> > +
> > +config FWU_MDATA_GPT_BLK
> > + bool "FWU Metadata access for GPT partitioned Block devices"
> > + select PARTITION_TYPE_GUID
> > + select PARTITION_UUIDS
> > + depends on DM && HAVE_BLOCK_DEVICE && EFI_PARTITION
> > + help
> > +   Enable support for accessing FWU Metadata on GPT partitioned
> > +   block devices.
> > diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> > index e53a8c9983..313049f67a 100644
> > --- a/drivers/fwu-mdata/Makefile
> > +++ b/drivers/fwu-mdata/Makefile
> > @@ -4,3 +4,4 @@
> >   #
> >
> >   obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
> > +obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o
> > diff --git a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c 
> > b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
> > new file mode 100644
> > index 00..d904c9492d
> > --- /dev/null
> > +++ b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
> > @@ -0,0 +1,408 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2022, Linaro Limited
> > + */
>
> #define LOG_CATEGORY UCLASS_FWU_MDATA

I think you had mentioned this in your earlier review as well. Sorry,
I missed out on this. Will add in the next version.

>
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define PRIMARY_PART BIT(0)
> > +#define SECONDARY_PART   BIT(1)
> > +#define BOTH_PARTS   (PRIMARY_PART | SECONDARY_PART)
> > +
> > +#define MDATA_READ   BIT(0)
> > +#define MDATA_WRITE  BIT(1)
> > +
>
> (...)
>
>
> > +
> > +static const struct fwu_mdata_ops fwu_gpt_blk_ops = {
> > + .mdata_check = fwu_gpt_mdata_check,
> > + .get_mdata = fwu_gpt_get_mdata,
> > + .update_mdata = fwu_gpt_update_mdata,
> > +};UCLASS_FWU_MDATA
> >
> > +
> > +static const struct udevice_id fwu_mdata_ids[] = {
> > + { .compatible = "u-boot,fwu-mdata-gpt" },
> > + { }
> > +};
> > +
> > +U_BOOT_DRIVER(fwu_mdata_gpt_blk) = {
> > + .name   = "fwu-mdata-gpt-blk",
> > + .id = UCLASS_FWU_MDATA,
> > + .of_match   = fwu_mdata_ids,
> > + .ops= _gpt_blk_ops,
> > + .probe  = fwu_mdata_gpt_blk_probe,
> > + .priv_auto  = sizeof(struct fwu_mdata_gpt_blk_priv),
> > +};
> > diff --git a/include/fwu.h b/include/fwu.h
> > index e03cfff800..8259c75d12 100644
> > --- a/include/fwu.h
> > +++ b/include/fwu.h
> > @@ -14,6 +14,10 @@
> >   struct fwu_mdata;
> >   struct udevice;
> >
> > +struct fwu_mdata_gpt_blk_priv {
> > + struct udevice *blk_dev;
> > +};
> > +
>
> NITS: really needed in .h file => private, only used by driver in .c ?

I have put it here since this gets accessed in the board file as well
to retrieve the block device which has the fwu metadata and the
firmware images in fwu_plat_get_alt_num().

>
>
> >   /**
> >* @mdata_check: check the validity of the FWU metadata partitions
> >* @get_mdata() - Get a FWU metadata copy
> > @@ -39,6 +43,7 @@ int fwu_get_active_index(u32 *active_idx);
> >   int fwu_update_active_index(u32 active_idx);
> >   int fwu_get_image_alt_num(efi_guid_t *image_type_id, u32 update_bank,
> > int *alt_num);
> > +int fwu_verify_mdata(struct fwu_mdata 

[PATCH 5/6] mtd: nand: sunxi: Convert to the driver model

[Samuel Holland]

Clocks, resets, and pinmuxes are now handled by the driver model, so the
only thing the "board" code needs to do is load the driver. This matches
the pattern used by other DM raw NAND drivers (there is no NAND uclass).

The actual board code is now only needed in SPL.

Signed-off-by: Samuel Holland 
---

 board/sunxi/board.c   |  5 +-
 drivers/mtd/nand/raw/sunxi_nand.c | 81 ++-
 2 files changed, 49 insertions(+), 37 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 21a2407e062f..ea0f33ed31db 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -315,7 +315,7 @@ int dram_init(void)
return 0;
 }
 
-#if defined(CONFIG_NAND_SUNXI)
+#if defined(CONFIG_NAND_SUNXI) && defined(CONFIG_SPL_BUILD)
 static void nand_pinmux_setup(void)
 {
unsigned int pin;
@@ -351,9 +351,6 @@ void board_nand_init(void)
 {
nand_pinmux_setup();
nand_clock_setup();
-#ifndef CONFIG_SPL_BUILD
-   sunxi_nand_init();
-#endif
 }
 #endif
 
diff --git a/drivers/mtd/nand/raw/sunxi_nand.c 
b/drivers/mtd/nand/raw/sunxi_nand.c
index 7185efbebfdd..dda51a39b065 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -24,11 +24,13 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -260,7 +262,7 @@ static inline struct sunxi_nand_chip *to_sunxi_nand(struct 
nand_chip *nand)
  * NAND Controller structure: stores sunxi NAND controller information
  *
  * @controller:base controller structure
- * @dev:   parent device (used to print error messages)
+ * @dev:   DM device (used to print error messages)
  * @regs:  NAND controller registers
  * @ahb_clk:   NAND Controller AHB clock
  * @mod_clk:   NAND Controller mod clock
@@ -273,7 +275,7 @@ static inline struct sunxi_nand_chip *to_sunxi_nand(struct 
nand_chip *nand)
  */
 struct sunxi_nfc {
struct nand_hw_control controller;
-   struct device *dev;
+   struct udevice *dev;
void __iomem *regs;
struct clk *ahb_clk;
struct clk *mod_clk;
@@ -1772,54 +1774,67 @@ static void sunxi_nand_chips_cleanup(struct sunxi_nfc 
*nfc)
 }
 #endif /* __UBOOT__ */
 
-void sunxi_nand_init(void)
+static int sunxi_nand_probe(struct udevice *dev)
 {
-   struct sunxi_nfc *nfc;
-   phys_addr_t regs;
-   ofnode node;
+   struct sunxi_nfc *nfc = dev_get_priv(dev);
+   struct reset_ctl_bulk rst_bulk;
+   struct clk_bulk clk_bulk;
int ret;
 
-   nfc = kzalloc(sizeof(*nfc), GFP_KERNEL);
-   if (!nfc)
-   return;
-
+   nfc->dev = dev;
spin_lock_init(>controller.lock);
init_waitqueue_head(>controller.wq);
INIT_LIST_HEAD(>chips);
 
-   node = ofnode_by_compatible(ofnode_null(), "allwinner,sun4i-a10-nand");
-   if (!ofnode_valid(node)) {
-   pr_err("unable to find nfc node in device tree\n");
-   goto err;
-   }
-
-   if (!ofnode_is_enabled(node)) {
-   pr_err("nfc disabled in device tree\n");
-   goto err;
-   }
+   nfc->regs = dev_read_addr_ptr(dev);
+   if (!nfc->regs)
+   return -EINVAL;
 
-   regs = ofnode_get_addr(node);
-   if (regs == FDT_ADDR_T_NONE) {
-   pr_err("unable to find nfc address in device tree\n");
-   goto err;
-   }
+   ret = reset_get_bulk(dev, _bulk);
+   if (!ret)
+   reset_deassert_bulk(_bulk);
 
-   nfc->regs = (void *)regs;
+   ret = clk_get_bulk(dev, _bulk);
+   if (!ret)
+   clk_enable_bulk(_bulk);
 
ret = sunxi_nfc_rst(nfc);
if (ret)
-   goto err;
+   return ret;
 
-   ret = sunxi_nand_chips_init(node, nfc);
+   ret = sunxi_nand_chips_init(dev_ofnode(dev), nfc);
if (ret) {
-   dev_err(nfc->dev, "failed to init nand chips\n");
-   goto err;
+   dev_err(dev, "failed to init nand chips\n");
+   return ret;
}
 
-   return;
+   return 0;
+}
 
-err:
-   kfree(nfc);
+static const struct udevice_id sunxi_nand_ids[] = {
+   {
+   .compatible = "allwinner,sun4i-a10-nand",
+   },
+   { }
+};
+
+U_BOOT_DRIVER(sunxi_nand) = {
+   .name   = "sunxi_nand",
+   .id = UCLASS_MTD,
+   .of_match   = sunxi_nand_ids,
+   .probe  = sunxi_nand_probe,
+   .priv_auto  = sizeof(struct sunxi_nfc),
+};
+
+void board_nand_init(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get_device_by_driver(UCLASS_MTD,
+ DM_DRIVER_GET(sunxi_nand), );
+   if (ret && ret != -ENODEV)
+   pr_err("Failed to initialize sunxi NAND controller: %d\n", ret);
 }
 
 

[PATCH 6/6] mtd: nand: sunxi: Pass the device to the init function

[Samuel Holland]

This more closely matches the U-Boot driver to the Linux version.

Signed-off-by: Samuel Holland 
---

 drivers/mtd/nand/raw/sunxi_nand.c | 39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/nand/raw/sunxi_nand.c 
b/drivers/mtd/nand/raw/sunxi_nand.c
index dda51a39b065..c0fa1e310c66 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -1604,7 +1604,8 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd, 
struct nand_ecc_ctrl *ecc)
return 0;
 }
 
-static int sunxi_nand_chip_init(ofnode np, struct sunxi_nfc *nfc, int devnum)
+static int sunxi_nand_chip_init(struct udevice *dev, struct sunxi_nfc *nfc,
+   ofnode np, int devnum)
 {
const struct nand_sdr_timings *timings;
struct sunxi_nand_chip *chip;
@@ -1620,7 +1621,7 @@ static int sunxi_nand_chip_init(ofnode np, struct 
sunxi_nfc *nfc, int devnum)
 
nsels /= sizeof(u32);
if (!nsels || nsels > 8) {
-   dev_err(nfc->dev, "invalid reg property size\n");
+   dev_err(dev, "invalid reg property size\n");
return -EINVAL;
}
 
@@ -1628,7 +1629,7 @@ static int sunxi_nand_chip_init(ofnode np, struct 
sunxi_nfc *nfc, int devnum)
   (nsels * sizeof(struct sunxi_nand_chip_sel)),
   GFP_KERNEL);
if (!chip) {
-   dev_err(nfc->dev, "could not allocate chip\n");
+   dev_err(dev, "could not allocate chip\n");
return -ENOMEM;
}
 
@@ -1638,19 +1639,19 @@ static int sunxi_nand_chip_init(ofnode np, struct 
sunxi_nfc *nfc, int devnum)
for (i = 0; i < nsels; i++) {
ret = ofnode_read_u32_index(np, "reg", i, );
if (ret) {
-   dev_err(nfc->dev, "could not retrieve reg property: 
%d\n",
+   dev_err(dev, "could not retrieve reg property: %d\n",
ret);
return ret;
}
 
if (tmp > NFC_MAX_CS) {
-   dev_err(nfc->dev,
+   dev_err(dev,
"invalid reg value: %u (max CS = 7)\n", tmp);
return -EINVAL;
}
 
if (test_and_set_bit(tmp, >assigned_cs)) {
-   dev_err(nfc->dev, "CS %d already assigned\n", tmp);
+   dev_err(dev, "CS %d already assigned\n", tmp);
return -EINVAL;
}
 
@@ -1661,9 +1662,9 @@ static int sunxi_nand_chip_init(ofnode np, struct 
sunxi_nfc *nfc, int devnum)
chip->sels[i].rb.type = RB_NATIVE;
chip->sels[i].rb.info.nativeid = tmp;
} else {
-   ret = gpio_request_by_name_nodev(np, "rb-gpios", i,
-
>sels[i].rb.info.gpio,
-GPIOD_IS_IN);
+   ret = gpio_request_by_name(dev, "rb-gpios", i,
+  >sels[i].rb.info.gpio,
+  GPIOD_IS_IN);
if (ret)
chip->sels[i].rb.type = RB_GPIO;
else
@@ -1674,7 +1675,7 @@ static int sunxi_nand_chip_init(ofnode np, struct 
sunxi_nfc *nfc, int devnum)
timings = onfi_async_timing_mode_to_sdr_timings(0);
if (IS_ERR(timings)) {
ret = PTR_ERR(timings);
-   dev_err(nfc->dev,
+   dev_err(dev,
"could not retrieve timings for ONFI mode 0: %d\n",
ret);
return ret;
@@ -1682,7 +1683,7 @@ static int sunxi_nand_chip_init(ofnode np, struct 
sunxi_nfc *nfc, int devnum)
 
ret = sunxi_nand_chip_set_timings(nfc, chip, timings);
if (ret) {
-   dev_err(nfc->dev, "could not configure chip timings: %d\n", 
ret);
+   dev_err(dev, "could not configure chip timings: %d\n", ret);
return ret;
}
 
@@ -1717,25 +1718,25 @@ static int sunxi_nand_chip_init(ofnode np, struct 
sunxi_nfc *nfc, int devnum)
 
ret = sunxi_nand_chip_init_timings(nfc, chip);
if (ret) {
-   dev_err(nfc->dev, "could not configure chip timings: %d\n", 
ret);
+   dev_err(dev, "could not configure chip timings: %d\n", ret);
return ret;
}
 
ret = sunxi_nand_ecc_init(mtd, >ecc);
if (ret) {
-   dev_err(nfc->dev, "ECC init failed: %d\n", ret);
+   dev_err(dev, "ECC init failed: %d\n", ret);
return ret;
}
 
ret = nand_scan_tail(mtd);
if (ret) {
-   dev_err(nfc->dev, "nand_scan_tail failed: %d\n", ret);
+   dev_err(dev, 

[PATCH 4/6] mtd: nand: sunxi: Convert from fdtdec to ofnode

[Samuel Holland]

As a first step toward converting this driver to the driver model, use
the ofnode abstraction to replace direct references to the FDT blob.

Using ofnode_read_u32_index removes an extra pair of loops and makes the
allwinner,rb property optional, matching the devicetree binding.

Signed-off-by: Samuel Holland 
---

 drivers/mtd/nand/raw/sunxi_nand.c | 73 +++
 include/fdtdec.h  |  1 -
 lib/fdtdec.c  |  1 -
 3 files changed, 26 insertions(+), 49 deletions(-)

diff --git a/drivers/mtd/nand/raw/sunxi_nand.c 
b/drivers/mtd/nand/raw/sunxi_nand.c
index 0f10edfdb208..7185efbebfdd 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -25,11 +25,10 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -45,8 +44,6 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 #define NFC_REG_CTL0x
 #define NFC_REG_ST 0x0004
 #define NFC_REG_INT0x0008
@@ -1605,19 +1602,18 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd, 
struct nand_ecc_ctrl *ecc)
return 0;
 }
 
-static int sunxi_nand_chip_init(int node, struct sunxi_nfc *nfc, int devnum)
+static int sunxi_nand_chip_init(ofnode np, struct sunxi_nfc *nfc, int devnum)
 {
const struct nand_sdr_timings *timings;
-   const void *blob = gd->fdt_blob;
struct sunxi_nand_chip *chip;
struct mtd_info *mtd;
struct nand_chip *nand;
int nsels;
int ret;
int i;
-   u32 cs[8], rb[8];
+   u32 tmp;
 
-   if (!fdt_getprop(blob, node, "reg", ))
+   if (!ofnode_get_property(np, "reg", ))
return -EINVAL;
 
nsels /= sizeof(u32);
@@ -1638,25 +1634,12 @@ static int sunxi_nand_chip_init(int node, struct 
sunxi_nfc *nfc, int devnum)
chip->selected = -1;
 
for (i = 0; i < nsels; i++) {
-   cs[i] = -1;
-   rb[i] = -1;
-   }
-
-   ret = fdtdec_get_int_array(gd->fdt_blob, node, "reg", cs, nsels);
-   if (ret) {
-   dev_err(nfc->dev, "could not retrieve reg property: %d\n", ret);
-   return ret;
-   }
-
-   ret = fdtdec_get_int_array(gd->fdt_blob, node, "allwinner,rb", rb,
-  nsels);
-   if (ret) {
-   dev_err(nfc->dev, "could not retrieve reg property: %d\n", ret);
-   return ret;
-   }
-
-   for (i = 0; i < nsels; i++) {
-   int tmp = cs[i];
+   ret = ofnode_read_u32_index(np, "reg", i, );
+   if (ret) {
+   dev_err(nfc->dev, "could not retrieve reg property: 
%d\n",
+   ret);
+   return ret;
+   }
 
if (tmp > NFC_MAX_CS) {
dev_err(nfc->dev,
@@ -1671,15 +1654,14 @@ static int sunxi_nand_chip_init(int node, struct 
sunxi_nfc *nfc, int devnum)
 
chip->sels[i].cs = tmp;
 
-   tmp = rb[i];
-   if (tmp >= 0 && tmp < 2) {
+   if (!ofnode_read_u32_index(np, "allwinner,rb", i, ) &&
+   tmp < 2) {
chip->sels[i].rb.type = RB_NATIVE;
chip->sels[i].rb.info.nativeid = tmp;
} else {
-   ret = gpio_request_by_name_nodev(offset_to_ofnode(node),
-   "rb-gpios", i,
-   >sels[i].rb.info.gpio,
-   GPIOD_IS_IN);
+   ret = gpio_request_by_name_nodev(np, "rb-gpios", i,
+
>sels[i].rb.info.gpio,
+GPIOD_IS_IN);
if (ret)
chip->sels[i].rb.type = RB_GPIO;
else
@@ -1711,7 +1693,7 @@ static int sunxi_nand_chip_init(int node, struct 
sunxi_nfc *nfc, int devnum)
 * in the DT.
 */
nand->ecc.mode = NAND_ECC_HW;
-   nand->flash_node = offset_to_ofnode(node);
+   nand->flash_node = np;
nand->select_chip = sunxi_nfc_select_chip;
nand->cmd_ctrl = sunxi_nfc_cmd_ctrl;
nand->read_buf = sunxi_nfc_read_buf;
@@ -1760,15 +1742,13 @@ static int sunxi_nand_chip_init(int node, struct 
sunxi_nfc *nfc, int devnum)
return 0;
 }
 
-static int sunxi_nand_chips_init(int node, struct sunxi_nfc *nfc)
+static int sunxi_nand_chips_init(ofnode node, struct sunxi_nfc *nfc)
 {
-   const void *blob = gd->fdt_blob;
-   int nand_node;
+   ofnode nand_np;
int ret, i = 0;
 
-   for (nand_node = fdt_first_subnode(blob, node); nand_node >= 0;
-nand_node = fdt_next_subnode(blob, nand_node)) {
-   ret = sunxi_nand_chip_init(nand_node, nfc, i++);
+   

[PATCH 3/6] mtd: nand: sunxi: Remove an unnecessary check

[Samuel Holland]

Each chip is required to have a unique CS number ("reg" property) in the
range 0-7, so there is no need to separately count the number of chips.

Signed-off-by: Samuel Holland 
---

 drivers/mtd/nand/raw/sunxi_nand.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/mtd/nand/raw/sunxi_nand.c 
b/drivers/mtd/nand/raw/sunxi_nand.c
index c378f08f6805..0f10edfdb208 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -1766,16 +1766,6 @@ static int sunxi_nand_chips_init(int node, struct 
sunxi_nfc *nfc)
int nand_node;
int ret, i = 0;
 
-   for (nand_node = fdt_first_subnode(blob, node); nand_node >= 0;
-nand_node = fdt_next_subnode(blob, nand_node))
-   i++;
-
-   if (i > 8) {
-   dev_err(nfc->dev, "too many NAND chips: %d (max = 8)\n", i);
-   return -EINVAL;
-   }
-
-   i = 0;
for (nand_node = fdt_first_subnode(blob, node); nand_node >= 0;
 nand_node = fdt_next_subnode(blob, nand_node)) {
ret = sunxi_nand_chip_init(nand_node, nfc, i++);
-- 
2.35.1

[PATCH 0/6] mtd: nand: sunxi: Convert to devicetree and the driver model

[Samuel Holland]

This series converts the sunxi NAND driver to get its resources (clocks,
resets, pins) from the devicetree, and probe using the driver model.

In addition to the immediate cleanup, this allows backporting more
patches (bugfixes, newer SoC support) from the Linux driver.


Samuel Holland (6):
  clk: sunxi: Add NAND clocks and resets
  pinctrl: sunxi: Add NAND pinmuxes
  mtd: nand: sunxi: Remove an unnecessary check
  mtd: nand: sunxi: Convert from fdtdec to ofnode
  mtd: nand: sunxi: Convert to the driver model
  mtd: nand: sunxi: Pass the device to the init function

 board/sunxi/board.c   |   5 +-
 drivers/clk/sunxi/clk_a10.c   |   2 +
 drivers/clk/sunxi/clk_a10s.c  |   2 +
 drivers/clk/sunxi/clk_a23.c   |   3 +
 drivers/clk/sunxi/clk_a31.c   |   6 +
 drivers/clk/sunxi/clk_a64.c   |   3 +
 drivers/clk/sunxi/clk_a80.c   |   8 ++
 drivers/clk/sunxi/clk_a83t.c  |   3 +
 drivers/clk/sunxi/clk_h3.c|   3 +
 drivers/clk/sunxi/clk_h6.c|   6 +
 drivers/clk/sunxi/clk_h616.c  |   6 +
 drivers/clk/sunxi/clk_r40.c   |   3 +
 drivers/mtd/nand/raw/sunxi_nand.c | 173 --
 drivers/pinctrl/sunxi/pinctrl-sunxi.c |  13 ++
 include/fdtdec.h  |   1 -
 lib/fdtdec.c  |   1 -
 16 files changed, 138 insertions(+), 100 deletions(-)

-- 
2.35.1

[PATCH 2/6] pinctrl: sunxi: Add NAND pinmuxes

[Samuel Holland]

NAND is always at function 2 on port C.

Pin lists and mux values were taken from the Linux drivers.

Signed-off-by: Samuel Holland 
---

 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 9ce2bc1b3afb..b10e3e7b0690 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -268,6 +268,7 @@ static const struct sunxi_pinctrl_function 
sun4i_a10_pinctrl_functions[] = {
 #endif
{ "mmc2",   3 },/* PC6-PC15 */
{ "mmc3",   2 },/* PI4-PI9 */
+   { "nand0",  2 },/* PC0-PC24 */
{ "spi0",   3 },/* PC0-PC2, PC23 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  4 },/* PF2-PF4 */
@@ -292,6 +293,7 @@ static const struct sunxi_pinctrl_function 
sun5i_a13_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG3-PG8 */
{ "mmc2",   3 },/* PC6-PC15 */
+   { "nand0",  2 },/* PC0-PC19 */
{ "spi0",   3 },/* PC0-PC3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  4 },/* PF2-PF4 */
@@ -318,6 +320,7 @@ static const struct sunxi_pinctrl_function 
sun6i_a31_pinctrl_functions[] = {
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC6-PC15, PC24 */
{ "mmc3",   4 },/* PC6-PC15, PC24 */
+   { "nand0",  2 },/* PC0-PC26 */
{ "spi0",   3 },/* PC0-PC2, PC27 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  3 },/* PF2-PF4 */
@@ -361,6 +364,7 @@ static const struct sunxi_pinctrl_function 
sun7i_a20_pinctrl_functions[] = {
{ "mmc1",   4 },/* PG0-PG5 */
 #endif
{ "mmc2",   3 },/* PC5-PC15, PC24 */
+   { "nand0",  2 },/* PC0-PC24 */
{ "spi0",   3 },/* PC0-PC2, PC23 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  4 },/* PF2-PF4 */
@@ -384,6 +388,7 @@ static const struct sunxi_pinctrl_function 
sun8i_a23_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC5-PC16 */
+   { "nand0",  2 },/* PC0-PC16 */
{ "spi0",   3 },/* PC0-PC3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  3 },/* PF2-PF4 */
@@ -421,6 +426,7 @@ static const struct sunxi_pinctrl_function 
sun8i_a33_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC5-PC16 */
+   { "nand0",  2 },/* PC0-PC16 */
{ "spi0",   3 },/* PC0-PC3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  3 },/* PF2-PF4 */
@@ -447,6 +453,7 @@ static const struct sunxi_pinctrl_function 
sun8i_a83t_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC5-PC16 */
+   { "nand0",  2 },/* PC0-PC18 */
{ "spi0",   3 },/* PC0-PC3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  3 },/* PF2-PF4 */
@@ -487,6 +494,7 @@ static const struct sunxi_pinctrl_function 
sun8i_h3_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC5-PC16 */
+   { "nand0",  2 },/* PC0-PC16 */
{ "spi0",   3 },/* PC0-PC3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  3 },/* PF2-PF4 */
@@ -553,6 +561,7 @@ static const struct sunxi_pinctrl_function 
sun9i_a80_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC6-PC16 */
+   { "nand0",  2 },/* PC0-PC18 */
{ "spi0",   3 },/* PC0-PC2, PC19 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  4 },/* PF2-PF4 */
@@ -592,6 +601,7 @@ static const struct sunxi_pinctrl_function 
sun50i_a64_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC1-PC16 */
+   { "nand0",  2 },/* PC0-PC16 */
{ "pwm",2 },/* PD22 */
{ "spi0",   4 },/* PC0-PC3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
@@ -633,6 +643,7 @@ static const struct sunxi_pinctrl_function 
sun50i_h5_pinctrl_functions[] = {
{ "mmc0",   2 },/* PF0-PF5 */
{ "mmc1",   2 },/* PG0-PG5 */
{ "mmc2",   3 },/* PC1-PC16 */
+   { "nand0",  2 },/* PC0-PC16 */
{ "spi0",   3 },/* PC0-PC3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
{ "uart0",  3 },/* PF2-PF4 */
@@ -659,6 +670,7 @@ static const struct 

[PATCH 1/6] clk: sunxi: Add NAND clocks and resets

[Samuel Holland]

Currently NAND clock setup is done in board code, both in SPL and in
U-Boot proper. Add the NAND clocks/resets here so they can be used by
the "full" NAND driver once it is converted to the driver model.

The bit locations are copied from the Linux CCU drivers.

Signed-off-by: Samuel Holland 
---

 drivers/clk/sunxi/clk_a10.c  | 2 ++
 drivers/clk/sunxi/clk_a10s.c | 2 ++
 drivers/clk/sunxi/clk_a23.c  | 3 +++
 drivers/clk/sunxi/clk_a31.c  | 6 ++
 drivers/clk/sunxi/clk_a64.c  | 3 +++
 drivers/clk/sunxi/clk_a80.c  | 8 
 drivers/clk/sunxi/clk_a83t.c | 3 +++
 drivers/clk/sunxi/clk_h3.c   | 3 +++
 drivers/clk/sunxi/clk_h6.c   | 6 ++
 drivers/clk/sunxi/clk_h616.c | 6 ++
 drivers/clk/sunxi/clk_r40.c  | 3 +++
 11 files changed, 45 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index db92848aafde..69c46da841e9 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -23,6 +23,7 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
[CLK_AHB_MMC3]  = GATE(0x060, BIT(11)),
+   [CLK_AHB_NAND]  = GATE(0x060, BIT(13)),
[CLK_AHB_EMAC]  = GATE(0x060, BIT(17)),
[CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
[CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
@@ -47,6 +48,7 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
[CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
 
+   [CLK_NAND]  = GATE(0x080, BIT(31)),
[CLK_SPI0]  = GATE(0x0a0, BIT(31)),
[CLK_SPI1]  = GATE(0x0a4, BIT(31)),
[CLK_SPI2]  = GATE(0x0a8, BIT(31)),
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
index 0c6564ef3b62..6abccea3aa9e 100644
--- a/drivers/clk/sunxi/clk_a10s.c
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -20,6 +20,7 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_AHB_NAND]  = GATE(0x060, BIT(13)),
[CLK_AHB_EMAC]  = GATE(0x060, BIT(17)),
[CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
[CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
@@ -35,6 +36,7 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
[CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
 
+   [CLK_NAND]  = GATE(0x080, BIT(31)),
[CLK_SPI0]  = GATE(0x0a0, BIT(31)),
[CLK_SPI1]  = GATE(0x0a4, BIT(31)),
[CLK_SPI2]  = GATE(0x0a8, BIT(31)),
diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
index 0280fb51e2db..342af83b158d 100644
--- a/drivers/clk/sunxi/clk_a23.c
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -17,6 +17,7 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
[CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
[CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_BUS_NAND]  = GATE(0x060, BIT(13)),
[CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
[CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
@@ -34,6 +35,7 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
[CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
 
+   [CLK_NAND]  = GATE(0x080, BIT(31)),
[CLK_SPI0]  = GATE(0x0a0, BIT(31)),
[CLK_SPI1]  = GATE(0x0a4, BIT(31)),
 
@@ -52,6 +54,7 @@ static struct ccu_reset a23_resets[] = {
[RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
[RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
[RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
+   [RST_BUS_NAND]  = RESET(0x2c0, BIT(13)),
[RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
[RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
[RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index 26d25f324080..703ddc01dad0 100644
--- a/drivers/clk/sunxi/clk_a31.c
+++ b/drivers/clk/sunxi/clk_a31.c
@@ -18,6 +18,8 @@ static struct ccu_clk_gate a31_gates[] = {
[CLK_AHB1_MMC1] = GATE(0x060, BIT(9)),
[CLK_AHB1_MMC2] = GATE(0x060, BIT(10)),
[CLK_AHB1_MMC3] = GATE(0x060, BIT(11)),
+   [CLK_AHB1_NAND1]= GATE(0x060, BIT(12)),
+   [CLK_AHB1_NAND0]= GATE(0x060, BIT(13)),
[CLK_AHB1_EMAC] = GATE(0x060, BIT(17)),
[CLK_AHB1_SPI0] = GATE(0x060, BIT(20)),
[CLK_AHB1_SPI1] = GATE(0x060, BIT(21)),
@@ -43,6 +45,8 @@ static struct ccu_clk_gate 

Re: [PATCH v8 2/9] eficonfig: menu-driven addition of UEFI boot option

[Takahiro Akashi]

Heinrich,

On Sun, Jul 10, 2022 at 11:03:43AM +0200, Heinrich Schuchardt wrote:
> On 6/19/22 06:56, Masahisa Kojima wrote:
> > This commit add the "eficonfig" command.
> > The "eficonfig" command implements the menu-driven UEFI boot option
> > maintenance feature. This commit implements the addition of
> > new boot option. User can select the block device volume having
> > efi_simple_file_system_protocol and select the file corresponding
> > to the Boot variable. User can also enter the description and
> > optional_data of the BOOT variable in utf8.
> > 
> > This commit adds "include/efi_config.h", it contains the common
> > definition to be used from other menus such as UEFI Secure Boot
> > key management.
> > 
> > Signed-off-by: Masahisa Kojima 
> > ---
> > Changes in v8:
> > - command name is change from "efimenu" to "eficonfig"
> > - function and struct prefixes is changed to "eficonfig"
> > - fix menu header string
> > 
> > Changes in v7:
> > - add "efimenu" command and uefi variable maintenance code
> >moved into cmd/efimenu.c
> > - create include/efimenu.h to define the common definition for
> >the other menu such as UEFI Secure Boot key management
> > - update boot option edit UI, user can select description, file,
> >and optional_data to edit in the same menu like following.
> > 
> >** Edit Boot Option **
> > 
> >   Description: debian
> >   File: virtio 0:1/EFI\debian\grubaa64.efi
> >   Optional Data: test
> >   Save
> >   Quit
> > 
> > - remove exit parameter from efimenu_process_common()
> > - menu title type is changed from u16 to char
> > - efimenu_process_common() add menu title string
> > - reduce printf/puts function call for displaying the menu
> > - efi_console_get_u16_string() accept 0 length to allow
> >optional_data is empty
> > - efi_console_get_u16_string() the "size" parameter name is changes to 
> > "count"
> > - efimenu is now designed to maintain the UEFI variables, remove autoboot 
> > related code
> > - remove one empty line before "Quit" entry
> > - efimenu_init() processes only the first time
> > 
> > Changes in v6:
> > - fix typos
> > - modify volume name to match U-Boot syntax
> > - compile in CONFIG_EFI_LOADER=n and CONFIG_CMD_BOOTEFI_BOOTMGR=n
> > - simplify u16_strncmp() usage
> > - support "a\b.efi" file path, use link list to handle filepath
> > - modify length check condition
> > - UEFI related menu items only appears with CONFIG_AUTOBOOT_MENU_SHOW=y
> > 
> > Changes in v5:
> > - remove forward declarations
> > - add const qualifier for menu items
> > - fix the possible unaligned access for directory info access
> > - split into three commit 1)add boot option 2) delete boot option 3)change 
> > boot order
> >This commit is 1)add boot option.
> > - fix file name buffer allocation size, it should be 
> > EFI_BOOTMENU_FILE_PATH_MAX * sizeof(u16)
> > - fix wrong size checking for file selection
> > 
> > Chanes in v4:
> > - UEFI boot option maintenance menu is integrated into bootmenu
> > - display the simplified volume name(e.g. usb0:1, nvme1:2) for the
> >volume selection
> > - instead of extending lib/efi_loader/efi_bootmgr.c, newly create
> >lib/efi_loader/efi_bootmenu_maintenance.c and implement boot
> >variable maintenance into it.
> > 
> > Changes in RFC v3:
> >   not included in v3 series
> > 
> > Changes in RFC v2:
> > - enable utf8 user input for boot option name
> > - create lib/efi_loader/efi_console.c::efi_console_get_u16_string() for
> >utf8 user input handling
> > - use u16_strlcat instead of u16_strcat
> > - remove the EFI_CALLs, and newly create or expose the following
> >xxx_int() functions.
> >  efi_locate_handle_buffer_int(), efi_open_volume_int(),
> >  efi_file_open_int(), efi_file_close_int(), efi_file_read_int() and
> >  efi_file_setpos_int().
> >Note that EFI_CALLs still exist for EFI_DEVICE_PATH_TO_TEXT_PROTOCOL
> >and EFI_SIMPLE_TEXT_INPUT/OUTPUT_PROTOCOL
> > - use efi_search_protocol() instead of calling locate_protocol() to get
> >the device_path_to_text_protocol interface.
> > - remove unnecessary puts(ANSI_CLEAR_LINE), this patch is still depends on
> >puts(ANSI_CLEAR_CONSOLE)
> > - skip SetVariable() if the bootorder is not changed
> > 
> >   cmd/Kconfig   |7 +
> >   cmd/Makefile  |1 +
> >   cmd/eficonfig.c   | 1270 +
> >   include/efi_config.h  |   91 +++
> >   include/efi_loader.h  |   40 ++
> >   lib/efi_loader/efi_boottime.c |   52 +-
> >   lib/efi_loader/efi_console.c  |   78 ++
> >   lib/efi_loader/efi_disk.c |   11 +
> >   lib/efi_loader/efi_file.c |   75 +-
> >   9 files changed, 1578 insertions(+), 47 deletions(-)
> >   create mode 100644 cmd/eficonfig.c
> >   create mode 100644 include/efi_config.h
> > 
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 09193b61b9..bb7f1d0463 100644
> > --- a/cmd/Kconfig
> > +++ 

Re: [PATCH 0/3] fs/fat: fix handling of full disk

[AKASHI Takahiro]

On Tue, Jul 12, 2022 at 10:33:11PM +, Heinrich Schuchardt wrote:
> Currently we have two functions with redundant coding to find an empty
> cluster:
> 
> * find_empty_cluster() seeks from the beginning of the FAT table
> * determine_fatent() seeks after a given entry
> 
> Both do not detect the end of the FAT table correctly and return an invalid
> cluster number if no empty entry if found.
> 
> Correctly determine empty FAT entries and full disk correctly.

I hope that you add a test for this specific corner case.

Thanks,
-Takahiro Akashi


> Carve out a function for creating directory entries to avoid code
> duplication.
> 
> Heinrich Schuchardt (3):
>   fs: fat: finding an empty FAT cluster
>   fs: fat: determine_fatent() error handling
>   fs: fat: carve out fat_create_dir_entry()
> 
>  fs/fat/fat_write.c | 161 ++---
>  1 file changed, 79 insertions(+), 82 deletions(-)
> 
> --
> 2.30.2
> 

Re: [PATCH 3/3] fs: fat: carve out fat_create_dir_entry()

[AKASHI Takahiro]

On Tue, Jul 12, 2022 at 10:33:14PM +, Heinrich Schuchardt wrote:
> fat_mkdir() and file_fat_write_at() use identical code to create a new
> directory entry. Carve out a new function fat_create_dir_entry() to avoid
> this code duplication.

Why not merge your patch[1] here as you're going to newly introduce 
fat_create_dir_entry()?

[1] https://lists.denx.de/pipermail/u-boot/2022-July/488693.html

-Takahiro Akashi


> Signed-off-by: Heinrich Schuchardt 
> ---
>  fs/fat/fat_write.c | 93 --
>  1 file changed, 40 insertions(+), 53 deletions(-)
> 
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 57522f96a8..a25b2283d4 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -1314,6 +1314,43 @@ static int normalize_longname(char *l_filename, const 
> char *filename)
>   return 0;
>  }
> 
> +/**
> + * fat_create_dir_entry() - create directory entry
> + *
> + * @itr: directory iterator
> + * @basename:name of file or directory to be created
> + * @size:file size
> + * @attr:file or directory attributes
> + * Return:   0 for success, -EIO on error
> + */
> +static int fat_create_dir_entry(fat_itr *itr, const char *basename,
> + loff_t size, u8 attr)
> +{
> + /* Create a new file */
> + char shortname[SHORT_NAME_SIZE];
> + int ndent;
> + int ret;
> +
> + /* Check if long name is needed */
> + ndent = set_name(itr, basename, shortname);
> + if (ndent < 0)
> + return ndent;
> + ret = fat_find_empty_dentries(itr, ndent);
> + if (ret)
> + return ret;
> + if (ndent > 1) {
> + /* Set long name entries */
> + ret = fill_dir_slot(itr, basename, shortname);
> + if (ret)
> + return ret;
> + }
> +
> + /* Set short name entry */
> + fill_dentry(itr->fsdata, itr->dent, shortname, 0, size, attr);
> +
> + return 0;
> +}
> +
>  int file_fat_write_at(const char *filename, loff_t pos, void *buffer,
> loff_t size, loff_t *actwrite)
>  {
> @@ -1383,8 +1420,6 @@ int file_fat_write_at(const char *filename, loff_t pos, 
> void *buffer,
>   retdent->size = cpu_to_le32(pos + size);
>   } else {
>   /* Create a new file */
> - char shortname[SHORT_NAME_SIZE];
> - int ndent;
> 
>   if (pos) {
>   /* No hole allowed */
> @@ -1392,25 +1427,7 @@ int file_fat_write_at(const char *filename, loff_t 
> pos, void *buffer,
>   goto exit;
>   }
> 
> - /* Check if long name is needed */
> - ndent = set_name(itr, basename, shortname);
> - if (ndent < 0) {
> - ret = ndent;
> - goto exit;
> - }
> - ret = fat_find_empty_dentries(itr, ndent);
> - if (ret)
> - goto exit;
> - if (ndent > 1) {
> - /* Set long name entries */
> - ret = fill_dir_slot(itr, basename, shortname);
> - if (ret)
> - goto exit;
> - }
> -
> - /* Set short name entry */
> - fill_dentry(itr->fsdata, itr->dent, shortname, 0, size,
> - ATTR_ARCH);
> + ret = fat_create_dir_entry(itr, basename, size, ATTR_ARCH);
> 
>   retdent = itr->dent;
>   }
> @@ -1693,38 +1710,8 @@ int fat_mkdir(const char *dirname)
>   ret = -EEXIST;
>   goto exit;
>   } else {
> - char shortname[SHORT_NAME_SIZE];
> - int ndent;
> -
> - if (itr->is_root) {
> - /* root dir cannot have "." or ".." */
> - if (!strcmp(l_dirname, ".") ||
> - !strcmp(l_dirname, "..")) {
> - ret = -EINVAL;
> - goto exit;
> - }
> - }
> -
> - /* Check if long name is needed */
> - ndent = set_name(itr, basename, shortname);
> - if (ndent < 0) {
> - ret = ndent;
> - goto exit;
> - }
> - ret = fat_find_empty_dentries(itr, ndent);
> - if (ret)
> - goto exit;
> - if (ndent > 1) {
> - /* Set long name entries */
> - ret = fill_dir_slot(itr, basename, shortname);
> - if (ret)
> - goto exit;
> - }
> -
> - /* Set attribute as archive for regular file */
> - fill_dentry(itr->fsdata, itr->dent, shortname, 0, 0,
> - ATTR_DIR | ATTR_ARCH);
> -
> + ret = fat_create_dir_entry(itr, basename, 0,
> +ATTR_DIR | 

Re: [PATCH 1/3] fs: fat: finding an empty FAT cluster

[AKASHI Takahiro]

Thank you for fixing this.

On Tue, Jul 12, 2022 at 10:33:12PM +, Heinrich Schuchardt wrote:
> Currently we have two functions with redundant coding to find an empty
> cluster:
> 
> * find_empty_cluster() seeks from the beginning of the FAT table
> * determine_fatent() seeks after a given entry
> 
> Both do not detect the end of the FAT table correctly and return an invalid
> cluster number if no empty entry if found.
> 
> find_empty_cluster() is replaced by an invocation of determine_fatent().
> 
> determine_fatent() is changed to seek in a second round from the beginning
> of the FAT table and to return an error code if no free entry is found.
> With this patch we will always find an empty cluster if it exists.

nitpick: empty -> free for consistent uses across this patch

> Further patches are needed to handle the disk full error gracefully.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  fs/fat/fat_write.c | 56 --
>  1 file changed, 29 insertions(+), 27 deletions(-)
> 
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 8ff2f6def0..a137e14f41 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -536,22 +536,41 @@ static int set_fatent_value(fsdata *mydata, __u32 
> entry, __u32 entry_value)
>   return 0;
>  }
> 
> -/*
> - * Determine the next free cluster after 'entry' in a FAT (12/16/32) table
> - * and link it to 'entry'. EOC marker is not set on returned entry.
> +/**
> + * determine_fatent() - get next free FAT cluster
> + *
> + * The parameter @entry indicates the current cluster. To reduce 
> fragementation
> + * the function first searches for a free cluster after the current cluster.
> + * If none is found, the search is repeated from the beginning of the FAT 
> table.
> + *
> + * If @entry is set, the new FAT entry is appended to the given one.
> + * If @entry is zero, only the number of the first free cluster is returned.
> + *
> + * @entry:   current entry
> + * Return:   next free cluster or negative error
>   */
> -static __u32 determine_fatent(fsdata *mydata, __u32 entry)
> +static int determine_fatent(fsdata *mydata, __u32 entry)
>  {
> - __u32 next_fat, next_entry = entry + 1;
> + __u32 next_fat, next_entry = entry;
> + int second_round = 0;
> 
>   while (1) {
> + ++next_entry;
> + if (CHECK_CLUST(next_entry, mydata->fatsize)) {
> + if (!second_round) {
> + second_round = 1;
> + next_entry = 3;
> + } else {
> + return -ENOSPC;
> + }
> + }

The logic is fine, but in case of entry != 0 and second_round
and if disk is full, fat entries after "entry" can unnecessarily be
checked twice. So,

next_entry = entry + 1;
while (1) {
if (next_entry == entry)
return -ENOSPC;
if (CHECK_CLUST(...)) {
if (!entry)
return -ENOSPC;
next_entry = 3;
continue;
}
...

next_entry++;
}

should work better.

-Takahiro Akashi

>   next_fat = get_fatent(mydata, next_entry);
> - if (next_fat == 0) {
> + if (!next_fat) {
>   /* found free entry, link to entry */
> - set_fatent_value(mydata, entry, next_entry);
> + if (entry)
> + set_fatent_value(mydata, entry, next_entry);
>   break;
>   }
> - next_entry++;
>   }
>   debug("FAT%d: entry: %08x, entry_value: %04x\n",
>  mydata->fatsize, entry, next_entry);
> @@ -794,23 +813,6 @@ get_set_cluster(fsdata *mydata, __u32 clustnum, loff_t 
> pos, __u8 *buffer,
>   return 0;
>  }
> 
> -/*
> - * Find the first empty cluster
> - */
> -static int find_empty_cluster(fsdata *mydata)
> -{
> - __u32 fat_val, entry = 3;
> -
> - while (1) {
> - fat_val = get_fatent(mydata, entry);
> - if (fat_val == 0)
> - break;
> - entry++;
> - }
> -
> - return entry;
> -}
> -
>  /**
>   * new_dir_table() - allocate a cluster for additional directory entries
>   *
> @@ -824,7 +826,7 @@ static int new_dir_table(fat_itr *itr)
>   int dir_oldclust = itr->clust;
>   unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
> 
> - dir_newclust = find_empty_cluster(mydata);
> + dir_newclust = determine_fatent(mydata, 0);
> 
>   /*
>* Flush before updating FAT to ensure valid directory structure
> @@ -1066,7 +1068,7 @@ set_clusters:
> 
>   /* Assure that curclust is valid */
>   if (!curclust) {
> - curclust = find_empty_cluster(mydata);
> + curclust = determine_fatent(mydata, 

Re: [PATCH v2] mmc: fsl_esdhc_spl: Add support for loading proper U-Boot from unaligned location

[Pali Rohár]

On Tuesday 28 June 2022 20:14:36 Pali Rohár wrote:
> On Thursday 23 June 2022 15:31:14 Pali Rohár wrote:
> > On Monday 20 June 2022 12:54:26 Pali Rohár wrote:
> > > This allows to concatenate SPL and proper U-Boot without extra alignment.
> > > 
> > > Signed-off-by: Pali Rohár 
> > > ---
> > > Changes in v2:
> > > * Rebased on top of the U-Boot next branch, commit 
> > > 98c4828740f4944462b7d9608b95d5b73850c7b0
> > 
> > PING?
> 
> PING?

PING?

> > > ---
> > >  drivers/mmc/fsl_esdhc_spl.c | 27 +++
> > >  1 file changed, 23 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/mmc/fsl_esdhc_spl.c b/drivers/mmc/fsl_esdhc_spl.c
> > > index 760f13d24018..54bf8152ca7a 100644
> > > --- a/drivers/mmc/fsl_esdhc_spl.c
> > > +++ b/drivers/mmc/fsl_esdhc_spl.c
> > > @@ -58,10 +58,10 @@ void __noreturn mmc_boot(void)
> > >  {
> > >   __attribute__((noreturn)) void (*uboot)(void);
> > >   uint blk_start, blk_cnt, err;
> > > + u32 blk_off;
> > >  #ifndef CONFIG_FSL_CORENET
> > >   uchar *tmp_buf;
> > >   u32 blklen;
> > > - u32 blk_off;
> > >   uchar val;
> > >  #ifndef CONFIG_SPL_FSL_PBL
> > >   u32 val32;
> > > @@ -155,10 +155,21 @@ again:
> > >   * Load U-Boot image from mmc into RAM
> > >   */
> > >   code_len = CONFIG_SYS_MMC_U_BOOT_SIZE;
> > > - blk_start = ALIGN(offset, mmc->read_bl_len) / mmc->read_bl_len;
> > > - blk_cnt = ALIGN(code_len, mmc->read_bl_len) / mmc->read_bl_len;
> > > + blk_start = offset / mmc->read_bl_len;
> > > + blk_off = offset % mmc->read_bl_len;
> > > + blk_cnt = ALIGN(code_len, mmc->read_bl_len) / mmc->read_bl_len + 1;
> > > + if (blk_off) {
> > > + err = mmc->block_dev.block_read(>block_dev,
> > > + blk_start, 1, tmp_buf);
> > > + if (err != 1) {
> > > + puts("spl: mmc read failed!!\n");
> > > + hang();
> > > + }
> > > + blk_start++;
> > > + }
> > >   err = mmc->block_dev.block_read(>block_dev, blk_start, blk_cnt,
> > > - (uchar *)CONFIG_SYS_MMC_U_BOOT_DST);
> > > + (uchar *)CONFIG_SYS_MMC_U_BOOT_DST +
> > > + (blk_off ? (mmc->read_bl_len - blk_off) 
> > > : 0));
> > >   if (err != blk_cnt) {
> > >   puts("spl: mmc read failed!!\n");
> > >  #ifndef CONFIG_FSL_CORENET
> > > @@ -166,6 +177,14 @@ again:
> > >  #endif
> > >   hang();
> > >   }
> > > + /*
> > > +  * SDHC DMA may erase bytes at dst + bl_len - blk_off - 8
> > > +  * due to unaligned access. So copy leading bytes from tmp_buf
> > > +  * after SDHC DMA transfer.
> > > +  */
> > > + if (blk_off)
> > > + memcpy((uchar *)CONFIG_SYS_MMC_U_BOOT_DST,
> > > +tmp_buf + blk_off, mmc->read_bl_len - blk_off);
> > >  
> > >   /*
> > >   * Clean d-cache and invalidate i-cache, to
> > > -- 
> > > 2.20.1
> > > 

Re: [PATCH 1/2] powerpc: mpc85xx: Add support for generating QorIQ pre-PBL eSDHC boot sector

[Pali Rohár]

On Tuesday 28 June 2022 20:07:48 Pali Rohár wrote:
> On Thursday 23 June 2022 19:17:55 Pali Rohár wrote:
> > On Saturday 04 June 2022 15:02:38 Pali Rohár wrote:
> > > On Wednesday 18 May 2022 12:53:20 Pali Rohár wrote:
> > > > On Wednesday 11 May 2022 22:59:28 Pali Rohár wrote:
> > > > > On Monday 25 April 2022 14:36:14 Pali Rohár wrote:
> > > > > > On Monday 25 April 2022 05:25:34 Priyanka Jain (OSS) wrote:
> > > > > > > >-Original Message-
> > > > > > > >From: U-Boot  On Behalf Of Pali 
> > > > > > > >Rohár
> > > > > > > >Sent: Tuesday, April 5, 2022 7:11 PM
> > > > > > > >To: Priyanka Jain ; Qiang Zhao 
> > > > > > > >;
> > > > > > > >Shengzhou Liu ; Alexander Graf 
> > > > > > > >;
> > > > > > > >Bin Meng ; Wolfgang Denk ; 
> > > > > > > >Sinan
> > > > > > > >Akman 
> > > > > > > >Cc: u-boot@lists.denx.de
> > > > > > > >Subject: [PATCH 1/2] powerpc: mpc85xx: Add support for 
> > > > > > > >generating QorIQ pre-
> > > > > > > >PBL eSDHC boot sector
> > > > > > > >
> > > > > > > >QorIQ U-Boot binary for SD card booting compiled during build 
> > > > > > > >process (either u-
> > > > > > > >boot.bin or u-boot-with-spl.bin) cannot be directly loaded by 
> > > > > > > >QorIQ pre-PBL
> > > > > > > >BootROM. Compiled U-Boot binary first needs to be processed by 
> > > > > > > >Freescale
> > > > > > > >boot_format tool as described in doc/README.mpc85xx-sd-spi-boot
> > > > > > > >
> > > > > > > >BootROM requires that image on SD card must contain special boot 
> > > > > > > >sector.
> > > > > > > >Implement support for generating this special boot sector 
> > > > > > > >directly in U-Boot start
> > > > > > > >code. Boot sector needs to be at the beginning of the image, so 
> > > > > > > >when compiling
> > > > > > > >only proper U-Boot without SPL then it needs to be in proper 
> > > > > > > >U-Boot. When
> > > > > > > >compiling SPL with proper U-Boot then it needs to be only in SPL.
> > > > > > > >
> > > > > > > >Support can be enabled by a new config option
> > > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > >Via other two additional options 
> > > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR_START and
> > > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR_DATA it is possible to tune how 
> > > > > > > >final U-Boot
> > > > > > > >image could be stored on the SD card.
> > > > > > > >
> > > > > > > >Signed-off-by: Pali Rohár 
> > > > > > > >---
> > > > > > > 
> > > > > > > Kindly rebase the series to master.
> > > > > > > 
> > > > > > > Regards
> > > > > > > Priyanka
> > > > > > 
> > > > > > Hello! Both patches still applies cleanly on master, just they 
> > > > > > depend
> > > > > > on another patch series (powerpc: mpc85xx: Fix and cleanup mpc85xx 
> > > > > > code)
> > > > > > which I mentioned in cover letter and therefore needs V2 patch of
> > > > > > "powerpc: mpc85xx: Set TEXT_BASE addresses to real base values" 
> > > > > > which I
> > > > > > sent recently.
> > > > > 
> > > > > I sent a new version v2 of this patch, see email:
> > > > > [PATCH v2] powerpc: mpc85xx: Add support for generating QorIQ pre-PBL 
> > > > > eSDHC boot sector
> > > > 
> > > > Priyanka: PING
> > > 
> > > PING?
> > 
> > PING?
> 
> PING?
> 
> V2 now and still applies cleanly on top of next branch
> https://patchwork.ozlabs.org/project/uboot/patch/20220511185731.3000-1-p...@kernel.org/

PING?

> And why v2 has "Changes Requested" state in above patchwork?
> 
> I do not see any comment for v2 on mailing list nor on patchwork.
> So what is requested from me?

RE: [PATCH] spl: sdp: Pass the USB index to board_usb_init()

[Peng Fan]

> Subject: [PATCH] spl: sdp: Pass the USB index to board_usb_init()
> 
> From: Fabio Estevam 
> 
> board_usb_init() should receive the controller_index as its first parameter
> instead of having it hardcoded as 0.
> 
> All in-tree users have CONFIG_SPL_SDP_USB_DEV as 0, so this error should
> not affect any board.
> 
> Fix it by passing controller_index as the parameter of board_usb_init().
> 
> Signed-off-by: Fabio Estevam 

Acked-by: Peng Fan 

> ---
>  common/spl/spl_sdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c index
> 36c31aff099a..cc4fb4f7cca2 100644
> --- a/common/spl/spl_sdp.c
> +++ b/common/spl/spl_sdp.c
> @@ -19,7 +19,7 @@ static int spl_sdp_load_image(struct spl_image_info
> *spl_image,
> 
>   usb_gadget_initialize(controller_index);
> 
> - board_usb_init(0, USB_INIT_DEVICE);
> + board_usb_init(controller_index, USB_INIT_DEVICE);
> 
>   g_dnl_clear_detach();
>   ret = g_dnl_register("usb_dnl_sdp");
> --
> 2.25.1

[PATCH] spl: sdp: Pass the USB index to board_usb_init()

[Fabio Estevam]

From: Fabio Estevam 

board_usb_init() should receive the controller_index as its
first parameter instead of having it hardcoded as 0.

All in-tree users have CONFIG_SPL_SDP_USB_DEV as 0, so this error
should not affect any board.

Fix it by passing controller_index as the parameter of board_usb_init().

Signed-off-by: Fabio Estevam 
---
 common/spl/spl_sdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index 36c31aff099a..cc4fb4f7cca2 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -19,7 +19,7 @@ static int spl_sdp_load_image(struct spl_image_info 
*spl_image,
 
usb_gadget_initialize(controller_index);
 
-   board_usb_init(0, USB_INIT_DEVICE);
+   board_usb_init(controller_index, USB_INIT_DEVICE);
 
g_dnl_clear_detach();
ret = g_dnl_register("usb_dnl_sdp");
-- 
2.25.1

Pull request for efi-2022-10-rc1

[Heinrich Schuchardt]

Dear Tom,

The following changes since commit 36b661dc919da318c163a45f4a220d2e3d9db608:

  Merge branch 'next' (2022-07-11 14:58:57 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2022-10-rc1

for you to fetch changes up to a093d72e628a798238269eb77850d57ee50198bb:

  MAINTAINERS: add Ilias Apalodimas to EFI PAYLOAD as co-maintainer
(2022-07-13 20:11:10 +0200)

Gitlab CI showed no issue:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/12738


Pull request for efi-2022-10-rc1

Documentation:

* rework the mkimage.1 man-page
* add a statistics page for v2022.07
* update environment description

UEFI:

* add Ilias Apalodimas as co-maintainer
* fix a memory leak in efi_set_bootdev()
* suppress a build warning


Heinrich Schuchardt (3):
  efi_loader: memory leak in efi_set_bootdev()
  efi_loader: suppress executable stack warning
  MAINTAINERS: add Ilias Apalodimas to EFI PAYLOAD as co-maintainer

Masahisa Kojima (1):
  efi_loader: expose END device path node

Sean Anderson (14):
  doc: mkimage: Use standard style for synopsis
  doc: mkimage: Use empty request instead of blank lines
  doc: mkimage: Reformat examples
  doc: mkimage: Regularize option documentation
  doc: mkimage: Use subsection macro
  doc: mkimage: Rearrange/remove some options
  doc: mkimage: Use correct capitalization for NAME
  doc: mkimage: Edit options for style and consistency
  doc: mkimage: Add BUGS section
  doc: mkimage: Add SEE ALSO section
  doc: mkimage: Remove AUTHORS section
  mkimage: Add long options
  doc: mkimage: Further document -o and -R
  doc: Add man page for dumpimage

Tom Rini (3):
  doc: environment: Drop u-boot_addr_r
  doc: environment: Expand on fdt_addr, initrd_addr and loadaddr
  doc: Add statistics page for v2022.07

 MAINTAINERS  |1 +
 cmd/bootefi.c|4 +-
 doc/develop/statistics/u-boot-stats-v2022.07.rst |  805 +
 doc/dumpimage.1  |  103 +++
 doc/mkimage.1| 1003
--
 doc/usage/environment.rst|   16 +-
 include/efi_loader.h |3 +
 lib/efi_loader/efi_device_path.c |2 +-
 scripts/Makefile.lib |4 +-
 tools/mkimage.c  |   45 +-
 10 files changed, 1693 insertions(+), 293 deletions(-)
 create mode 100644 doc/develop/statistics/u-boot-stats-v2022.07.rst
 create mode 100644 doc/dumpimage.1

Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

[Stephan Gerhold]

Hi Sumit,

On Tue, Jul 12, 2022 at 12:42:12PM +0530, Sumit Garg wrote:
> Add support for Qualcomm QCS404 SoC based evaluation board.
> 
> Features:
> - Qualcomm Snapdragon QCS404 SoC
> - 1GiB RAM
> - 8GiB eMMC, uSD slot
> 
> U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> For detailed build and boot instructions, refer to
> doc/board/qualcomm/qcs404.rst.
> 
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/Makefile|  1 +
>  arch/arm/dts/qcs404-evb-uboot.dtsi   | 24 +++
>  arch/arm/dts/qcs404-evb.dts  | 81 
>  arch/arm/mach-snapdragon/Kconfig | 11 
>  arch/arm/mach-snapdragon/Makefile|  2 +
>  arch/arm/mach-snapdragon/sysmap-qcs404.c | 31 +
>  board/qualcomm/qcs404-evb/Kconfig| 15 +
>  board/qualcomm/qcs404-evb/MAINTAINERS|  6 ++
>  board/qualcomm/qcs404-evb/Makefile   |  6 ++
>  board/qualcomm/qcs404-evb/qcs404-evb.c   | 33 ++
>  board/qualcomm/qcs404-evb/qcs404-evb.its | 64 +++
>  configs/qcs404evb_defconfig  | 39 
>  doc/board/qualcomm/index.rst |  1 +
>  doc/board/qualcomm/qcs404.rst| 79 +++
>  include/configs/qcs404-evb.h | 27 
>  15 files changed, 420 insertions(+)
>  create mode 100644 arch/arm/dts/qcs404-evb-uboot.dtsi
>  create mode 100644 arch/arm/dts/qcs404-evb.dts
>  create mode 100644 arch/arm/mach-snapdragon/sysmap-qcs404.c
>  create mode 100644 board/qualcomm/qcs404-evb/Kconfig
>  create mode 100644 board/qualcomm/qcs404-evb/MAINTAINERS
>  create mode 100644 board/qualcomm/qcs404-evb/Makefile
>  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.c
>  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.its
>  create mode 100644 configs/qcs404evb_defconfig
>  create mode 100644 doc/board/qualcomm/qcs404.rst
>  create mode 100644 include/configs/qcs404-evb.h
> 
> [...]
> diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
> new file mode 100644
> index 00..4f0ae20bdb
> --- /dev/null
> +++ b/arch/arm/dts/qcs404-evb.dts
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm QCS404 based evaluation board device tree source
> + *
> + * (C) Copyright 2022 Sumit Garg 
> + */
> +
> +/dts-v1/;
> +
> +#include "skeleton64.dtsi"
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS404 EVB";
> + compatible = "qcom,qcs404-evb", "qcom,qcs404";
> + #address-cells = <0x2>;
> + #size-cells = <0x2>;
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + aliases {
> + serial0 = _uart;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0x8000 0 0x4000>;
> + };
> +
> + soc {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0x0 0x0 0x0 0x>;
> + compatible = "simple-bus";
> +
> + pinctrl_north@130 {
> + compatible = "qcom,tlmm-qcs404";
> + reg = <0x130 0x20>;
> +
> + blsp1_uart2: uart {
> + pins = "GPIO_17", "GPIO_18";
> + function = "blsp_uart2";
> + };
> + };
> +

I know you're just following the example of the existing Qualcomm boards
here but I think we should really avoid adding any more custom device
trees that are inconsistent with the official (upstream) Linux bindings.

Many other boards in U-Boot have moved to using the upstream Linux DTs
as-is (with some additions in -u-boot.dtsi) and I think we should do the
same for the Qualcomm boards. Judging from Tom's comments on other
patches (e.g. [1]), this might even be a requirement now?

The SPMI fix I just sent for DB410c/DB820c [2] is a good example why it
is important to have bindings consistent with Linux. Looking at your
patch reminded me that I never sent this fix (thanks!).

Can you check how hard it would be to reuse the upstream QCS404 DT?

Thanks!
Stephan

[1]: https://lore.kernel.org/u-boot/20220601152800.GJ25375@bill-the-cat/
[2]: https://lore.kernel.org/u-boot/20220713191711.4155-1-step...@gerhold.net/

[PATCH] arm: dts: db410c/db820c: Fix SPMI addresses

[Stephan Gerhold]

The Qualcomm device trees in U-Boot are currently not consistent with
the upstream DTs used in the Linux kernel. While some bindings are
similar to the official specification in the Linux kernel, several
nodes have subtle differences, e.g. the "compatible"s or the exact
specification of memory registers.

This means that some of the Qualcomm-related U-Boot drivers are not
compatible with the Linux DT (and vice versa).

The SPMI node is one such example: the "core" region starts at
0x0200f000 in the upstream Linux MSM8916 DT, but in U-Boot it starts at
0x0200f800. The end result is normally the same, since the Linux SPMI
driver simply adds the 0x800 internally.

However, commit f5a2d6b4b03a ("spmi: msm: add arbiter version 5
support") imported this behavior into the U-Boot driver, without
adjusting the DB410c/DB820c device trees. This means that the 0x800
offset is now added twice, breaking all SPMI read/write operations:

  Failed to find PMIC pon node. Check device tree
  Failed to find pm8916_gpios@c000 node.
  USB init failed: -6
  starting USB...
  Bus ehci@78d9000: Failed to find pm8916_gpios@c000 node.
  probe failed, error -6
  No working controllers found

While the mistake is strictly speaking in the spmi-msm driver, fix the
issue by making the SPMI nodes in the DB410c/DB820c consistent with the
upstream Linux DT instead.

Ideally we should even go a step further by fixing the remaining uses
of custom bindings in the U-Boot drivers and moving to using the Linux
DTs as-is. This would likely avoid such mistakes in the future and
would also make the porting process much easier.

Cc: Dzmitry Sankouski 
Fixes: f5a2d6b4b03a ("spmi: msm: add arbiter version 5 support")
Signed-off-by: Stephan Gerhold 
---
Sorry for sending this literally a few days after the U-Boot release.
This change has been sitting in my local U-Boot clone for a couple of
months already (it's broken at least since v2022.01) but I got caught
up in other work and completely forgot about it. I guess no one else
is actively testing U-Boot on DB410c/DB820c. :/
---
 arch/arm/dts/dragonboard410c.dts |  9 +++--
 arch/arm/dts/dragonboard820c.dts | 11 +++
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 7e56140df2..50523712cb 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -137,9 +137,14 @@
};
};
 
-   spmi@200f000 {
+   spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
-   reg = <0x200f800 0x200 0x240 0x40 0x2c0 
0x40>;
+   reg = <0x0200f000 0x001000>,
+ <0x0240 0x40>,
+ <0x02c0 0x40>,
+ <0x0380 0x20>,
+ <0x0200a000 0x002100>;
+   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
#address-cells = <0x1>;
#size-cells = <0x1>;
pmic0: pm8916@0 {
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 1114ddd7d3..b72a2471cf 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -93,11 +93,14 @@
clock-frequency = <2>;
 };
 
-   spmi@400f000 {
+   spmi_bus: spmi@400f000 {
compatible = "qcom,spmi-pmic-arb";
-   reg = <0x400f800 0x200>,
- <0x440 0x40>,
- <0x4c0 0x40>;
+   reg = <0x0400f000 0x1000>,
+ <0x0440 0x80>,
+ <0x04c0 0x80>,
+ <0x0580 0x20>,
+ <0x0400a000 0x002100>;
+   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
#address-cells = <0x1>;
#size-cells = <0x1>;
 
-- 
2.37.0

Re: [PATCH] board: ti: am65x: Do not disable SA2UL in DT

[Tom Rini]

On Wed, Jul 13, 2022 at 11:12:48AM -0500, Andrew Davis wrote:

> This is no longer needed as the SA2UL can now be shared with Linux.
> Leave the SA2UL DT node enabled.
> 
> Signed-off-by: Andrew Davis 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 10/19] buildman: Incorporate the genboardscfg.py tool

[Tom Rini]

On Wed, Jul 13, 2022 at 09:28:06AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 12 Jul 2022 at 15:38, Tom Rini  wrote:
> >
> > On Mon, Jul 11, 2022 at 07:04:04PM -0600, Simon Glass wrote:
> > > Bring this tool into buildman, so we don't have to run it separately. The
> > > board.cfg file is still produced as part of the build, to save time when
> > > doing another build in the same working directory. If it is out of date
> > > with respect to the Kconfig, it is updated.
> > >
> > > Time to regenerate on a recent single-thread machine is 4.6s (1.3s on a
> > > 32-thread machine), so we do need some sort of cache if we want buildman
> > > to be useful on incremental builds. We could use Python's pickle format
> > > but:
> > >
> > > - it seems useful to allow boards.cfg to be regenerated, at least for a
> > >   while, in case other tools use it
> > > - it is possible to grep the file easily, e.g. to find boards which use
> > >   a particular SoC (similar to 'buildman -nv '
> >
> > While I don't think other tools still use boards.cfg, this will make it
> > easier to find out that I'm wrong.  Perhaps once the CONFIG to Kconfig
> > migration is done we can move to just pickle'ing the data or similar
> > since I find the main use of what was in boards.cfg can be figured out
> > with some other git grep'ing, and in turn that's mainly for me when
> > trying to convert stuff.  Thanks for doing this.
> 
> Yes. I'm excited to hear that Kconfig migration might be done - any
> forecast as to when?

Not yet.  I'm auditing CONFIG_SYS_* now, with a notion to move
everything that's not really configurable just out of CONFIG namespace
as the starting point.  That'll drop us down to ~500 to migrate, which
feels a bit less daunting.

> One thing we could to is provide an option for buildman to spit out
> the various fields that go into boards.cfg

Right.  So I might not have said this before, but one reason I wanted
buildman to natively know kconfiglib and have everything was that while
we can do a lot of good matching on what to build, it would be amazingly
good to be able to say "build every platform with NVME_PCI set" (and if
it's not too hard hex/int options with a specific value).

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] sunxi: configs: streamline include/configs/sun*.h wrappers

[Tom Rini]

On Wed, Jul 13, 2022 at 04:58:57PM +0100, Andre Przywara wrote:
> For mostly historic reasons we had configuration headers for each
> Allwinner CPU "family". These days they are mostly just including one
> common header, with the rest being somewhat empty.
> There were attempts to remove them, and to just use the one common header
> to begin with, but this has implications to the build system, which me
> might not be ready for, yet.
> 
> To document this behaviour, and to avoid something sneaking in over
> time, make those files all the same (minus the CPU family name and
> the copyrights), and add a comment explaining that.
> This makes it easier to just remove those files later on, when needed
> and possible.
> 
> Signed-off-by: Andre Przywara 
>
> ---
> Hi Tom,
> 
> this is mostly to just confirm and document what we already established
> earlier: that those files are redundant, and are just needed to match
> CONFIG_SYS_CONFIG_NAME. In case we don't need or want that anymore, we
> can just remove them, without needing to think too hard about it.

Right, we need this for CONFIG_SYS_CONFIG_NAME and in turn being able to
break up the build for Azure, and manual build testing still.

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: PRAM and reserved memory for Linux

[Tom Rini]

On Wed, Jul 13, 2022 at 04:13:27PM +, Joakim Tjernlund wrote:
> On Wed, 2022-07-13 at 10:21 -0400, Tom Rini wrote:
> > On Wed, Jul 13, 2022 at 10:08:38AM +, Joakim Tjernlund wrote:
> > 
> > > I added CONFIG_PRAM 4 and a reserved-memory DTS node for the same space 
> > > but
> > > now u-boot complains when booting:
> > >   ERROR: reserving fdt memory region failed (addr=703ff000 size=1000)
> > > The error is caused by arch_lmb_reserve() in arm which seem
> > > to reserve command line and board info ? 
> > > 
> > > If I remove the reserved-memory DTS node I don't get a reserved area in 
> > > Linux,
> > > don't quite understand how PRAM is supposed to work?
> > 
> > The first likely problem is that CONFIG_PRAM stuff isn't often used
> > these days so might be glitchy / buggy, as you've found here.  Next, I
> > bet that area in arch_lmb_reserve() is about ATAGS/related and should be
> > guarded with CONFIG_SUPPORT_PASSING_ATAGS.
> > 
> 
> The  arch_lmb_reserve() comment reads(lots of archs has similar code):
>   /*
>* Booting a (Linux) kernel image
>*
>* Allocate space for command line and board info - the
>* address should be as high as possible within the reach of
>* the kernel (see CONFIG_SYS_BOOTMAPSZ settings), but in unused
>* memory, which means far enough below the current stack
>* pointer.
> 
> You still think this cmdline/board info is just for the old ATAGS ?
> I have an older boot and it des not have CONFIG_SUPPORT_PASSING_ATAGS but
> CMDLINE_TAG etc. is here though.

Yes it is, and SUPPORT_PASSING_ATAGS is somewhat new in that I added it
when converting CMDLINE_TAG, etc, to Kconfig and making it be easier to
say "this platform is new enough to never ever need this".

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v6 3/7] tpm: Add the RNG child device

[Tom Rini]

On Wed, Jul 13, 2022 at 09:28:16AM -0600, Simon Glass wrote:
> Hi Rob,
> 
> On Tue, 12 Jul 2022 at 08:11, Rob Herring  wrote:
> >
> > On Tue, Jul 12, 2022 at 5:04 AM Simon Glass  wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Fri, 8 Jul 2022 at 02:24, Ilias Apalodimas
> > >  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > [...]
> > > >
> > > > > > +
> > > > > >  UCLASS_DRIVER(tpm) = {
> > > > > > -   .id = UCLASS_TPM,
> > > > > > -   .name   = "tpm",
> > > > > > -   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > > > +   .id = UCLASS_TPM,
> > > > > > +   .name   = "tpm",
> > > > > > +   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > > >  #if CONFIG_IS_ENABLED(OF_REAL)
> > > > > > -   .post_bind  = dm_scan_fdt_dev,
> > > > > > +   .post_bind  = dm_scan_fdt_dev,
> > > > > >  #endif
> > > > > > +   .post_probe = tpm_uclass_post_probe,
> > > > > > .per_device_auto= sizeof(struct tpm_chip_priv),
> > > > > >  };
> > > > > > --
> > > > > > 2.25.1
> > > > > >
> > > > >
> > > > > The driver needs a compatible string so it can be in the device tree.
> > > >
> > > > Why?  I've tried to hint this on the previous iteration of the patch.
> > > > The RNG here is not a *device*.  The TPM is the device and you are
> > > > guaranteed to have an RNG.  The way to get a random number is send a
> > > > special command to the TPM. So all that we should do here is leverage
> > > > the fact that the TPM is already in the device tree.
> > > >
> > > > And fwiw we should stick to try to stick to what the DT spec defines
> > > > as much as possible.  I personally don't see this as a special usecase
> > > > were deviating from the spec is justified.
> > >
> > > This is not a deviation from a spec. What spec? Also, I don't want to
> > > get into another discussion about what a device is. We can disagree on
> > > that if you like.
> > >
> > > One reason is that U-Boot generally requires compatible strings, e.g.
> > > with of-platdata. But also we can refer to the rand device from
> > > elsewhere in the tree. I know that Linux does lots of ad-hoc device
> > > creation and doesn't really have the concept of a uclass consistently
> > > applied, but this is U-Boot.
> >
> > You are letting client/OS details define your binding. Doing so
> > doesn't result in OS agnostic bindings. Sure, it would be nice if DT
> > nodes and drivers were always a nice clean 1:1 ratio, but h/w is messy
> > sometimes and DT is not an abstraction layer. The general guidance on
> > whether there are child nodes for sub-blocks is do they have their own
> > resources in DT or are the sub-blocks reusable on multiple devices.
> > Neither of those are the case here.
> >
> > Besides, we already have TPM device bindings defined. Requiring
> > binding changes when adding a new client/OS feature is not good
> > practice either.
> 
> I'm not sure what to do with this, but in general the practice of
> implied subnodes is not friendly to U-Boot. Yet it seems like a common
> feature of the bindings at present, for example GPIOs.
> 
> The device tree is how U-Boot determines which random-number generator
> to use for a particular function. For example, for VBE, if we need to
> generate some random numbers we'd like to specify which device creates
> them. It can't just be 'use the TPM if you find one'. I'm not sure how
> that works in Linux?

Why can't it be "use the TPM if you find one" since a TPM is a superset
of an RNG?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 7/7] process.rst: Modernize the "Workflow of a Custodian" section

[Tom Rini]

On Wed, Jul 13, 2022 at 07:46:28PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > The "Workflow of a Custodian" section on the wiki had not been changed
> > in quite some time to reflect how the process has been functioning for
> > some time.  First, update some links to point to modern and current
> > sources of information.
> > 
> > Second, and more overarching, reword much of the section.  This expands
> > on the expectations of both custodians and developers when it comes to
> > rebasing patches.  Rework the final points to be clearer that Custodians
> > are expected to do their best to test the changes and ask for help when
> > needed, as well as that pull requests are expected in a timely manner.
> > 
> > Cc: Claudius Heine 
> > Cc: Martin Bonner 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - New patch
[snip]
> > -#. Once tests are passed, some agreed time limit expires, the custodian
> > -   requests that the changes in their public git repository be merged into 
> > the
> > -   main tree. If necessary, the custodian may have to adapt their changes 
> > to
> > -   allow for a clean merge.
> > -   Todo: define a reasonable time limit. 3 weeks?
> > +#. Custodians are expected to submit a timely pull request of their git
> > +   repository to the main repository.  It is strongly encouraged that a CI 
> > run
> > +   have been complete prior to submission, but not required.
> 
> A run is singular.

Oops, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 6/7] process.rst: Perform minor cleanups

[Tom Rini]

On Wed, Jul 13, 2022 at 07:43:25PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
[snip]
> > @@ -155,7 +156,7 @@ like this:
> > 
> >  #. Applies cleanly to the source tree
> > 
> > -   #. passes a ``MAKEALL`` compile test without creating new warnings
> > +   #. Passes :doc:`ci_testing` as this checks for new warnings and other 
> > issues.
> 
> %s/ci/CI/

No?  This is a reference so it renders using the document title.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 5/7] designprinciples.rst: Perform minor cleanups

[Tom Rini]

On Wed, Jul 13, 2022 at 07:40:03PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > - Remove some missed wiki markup, and escape a "\n" correctly.
> > - Use gender-neutral language to refer to the user, consistently.
> > 
> > Cc: Claudius Heine 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - None
> > ---
> >   doc/develop/designprinciples.rst | 24 
> >   1 file changed, 12 insertions(+), 12 deletions(-)
> > 
> > diff --git a/doc/develop/designprinciples.rst 
> > b/doc/develop/designprinciples.rst
> > index 43aeb5dacf5f..e5e12dca79f5 100644
> > --- a/doc/develop/designprinciples.rst
> > +++ b/doc/develop/designprinciples.rst
> > @@ -28,15 +28,15 @@ millions...
> > 
> >   A usable and useful configuration of U-Boot, including a basic
> >   interactive command interpreter, support for download over Ethernet
> > -and the capability to program the flash shall fit in no more than 128 !KiB.
> > +and the capability to program the flash shall fit in no more than 128 KiB.
> > 
> >   Keep it Fast
> >   
> > 
> >   The end user is not interested in running U-Boot. In most embedded
> > -systems he is not even aware that U-Boot exists. The user wants to
> > +systems they are not even aware that U-Boot exists. The user wants to
> 
> "The end user" is singular.

First person singular they is normal usage.  Talk to me on IRC if you
want me to dig up one of the essays on the extensive history of first
person singular they :)

> >   run some application code, and that as soon as possible after switching
> > -on his device.
> > +on their device.
> > 
> >   It is therefore essential that U-Boot is as fast as possible,
> >   especially that it loads and boots the operating system as fast as 
> > possible.
> > @@ -63,7 +63,7 @@ Keep it Simple
> >   ^^
> > 
> >   U-Boot is a boot loader, but it is also a tool used for board
> > -bring-up, for production testing, and for other activities
> > +bring-up, for production testing, and for other activities.
> > 
> >   Keep it Portable
> >   
> > @@ -96,13 +96,13 @@ Keep it Configurable
> >   Section "Keep it Small" already explains about the size restrictions
> >   for U-Boot on one side. On the other side, U-Boot is a powerful tool
> >   with many, many extremely useful features. The maintainer or user of
> > -each board will have to decide which features are important to him and
> > -what shall be included with his specific board configuration to meet
> > -his current requirements and restrictions.
> > +each board will have to decide which features are important to them and
> > +what shall be included with their specific board configuration to meet
> > +their current requirements and restrictions.
> > 
> >   Please make sure that it is easy to add or remove features from a
> >   board configuration, so everybody can make the best use of U-Boot on
> > -his system.
> > +their system.
> > 
> >   If a feature is not included, it should not have any residual code
> >   bloating the build.
> > @@ -126,7 +126,7 @@ debug is all the more important to many of us.
> >   * All initialization steps shall print some "begin doing this" message 
> > before
> > they actually start, and some "done" message when they complete. For 
> > example,
> > RAM initialization and size detection may print a "RAM: " before they 
> > start,
> > -  and "256 MB\n" when done.  The purpose of this is that you can always see
> > +  and "256 MB\\n" when done.  The purpose of this is that you can always 
> > see
> 
> %s/MB/MiB/

Plenty of memory related notices, even in the docs, use "MB".  Lets just
put this on the pile to adjust later.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/7] doc: Migrate DesignPrinciples wiki page to Sphinx

[Tom Rini]

On Wed, Jul 13, 2022 at 07:22:33PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > Move the current DesignPrinciples wiki page to
> > doc/develop/designprinciples.rst.  The changes here are for formatting
> > or slight rewording so that it reads well when linking to other Sphinx
> > documents.
> > 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Assorted wiki -> Sphinx style corrections and a few typo fixes, per
> >Heinrich
> > ---
> >   doc/develop/designprinciples.rst | 205 +++
> >   doc/develop/index.rst|   1 +
> >   2 files changed, 206 insertions(+)
> >   create mode 100644 doc/develop/designprinciples.rst
> > 
> > diff --git a/doc/develop/designprinciples.rst 
> > b/doc/develop/designprinciples.rst
> > new file mode 100644
> > index ..43aeb5dacf5f
> > --- /dev/null
> > +++ b/doc/develop/designprinciples.rst
> > @@ -0,0 +1,205 @@
> > +.. SPDX-License-Identifier: GPL-2.0+:
> > +
> > +U-Boot Design Principles
> > +
> > +
> > +The 10 Golden Rules of U-Boot design
> > +
> > +
> > +Keep it Small
> > +^
> > +
> > +U-Boot is a Boot Loader, i.e. its primary purpose in the shipping
> > +system is to load some operating system.
> > +That means that U-Boot is
> > +necessary to perform a certain task, but it's nothing you want to
> > +throw any significant resources at. Typically U-Boot is stored in
> > +relatively small NOR flash memory, which is expensive
> > +compared to the much larger NAND devices often used to store the
> > +operating system and the application.
> > +
> > +At the moment, U-Boot supports boards with just 128 KiB ROM or with
> > +256 KiB NOR flash. We should not easily ignore such configurations -
> > +they may be the exception in among all the other supported boards,
> > +but if a design uses such a resource-constrained hardware setup it is
> > +usually because costs are critical, i. e. because the number of
> > +manufactured boards might be tens or hundreds of thousands or even
> > +millions...
> > +
> > +A usable and useful configuration of U-Boot, including a basic
> > +interactive command interpreter, support for download over Ethernet
> > +and the capability to program the flash shall fit in no more than 128 !KiB.
> > +
> > +Keep it Fast
> > +
> > +
> > +The end user is not interested in running U-Boot. In most embedded
> > +systems he is not even aware that U-Boot exists. The user wants to
> > +run some application code, and that as soon as possible after switching
> > +on his device.
> > +
> > +It is therefore essential that U-Boot is as fast as possible,
> > +especially that it loads and boots the operating system as fast as 
> > possible.
> > +
> > +To achieve this, the following design principles shall be followed:
> > +
> > +* Enable caches as soon and whenever possible
> > +
> > +* Initialize devices only when they are needed within U-Boot, i.e. don't
> > +  initialize the Ethernet interface(s) unless U-Boot performs a download 
> > over
> > +  Ethernet; don't  initialize any IDE or USB devices unless U-Boot actually
> > +  tries to load files from these, etc.  (and don't forget to shut down 
> > these
> > +  devices after using them  - otherwise nasty things may happen when you 
> > try to
> > +  boot your OS).
> > +
> > +Also, building of U-Boot shall be as fast as possible.
> > +This makes it easier to run a build for all supported configurations
> > +or at least for all configurations of a specific architecture,
> > +which is essential for quality assurance.
> > +If building is cumbersome and slow, most people will omit
> > +this important step.
> > +
> > +Keep it Simple
> > +^^
> > +
> > +U-Boot is a boot loader, but it is also a tool used for board
> > +bring-up, for production testing, and for other activities
> > +
> > +Keep it Portable
> > +
> > +
> > +U-Boot is a boot loader, but it is also a tool used for board
> > +bring-up, for production testing, and for other activities that are
> > +very closely related to hardware development. So far, it has been
> > +ported to several hundreds of different boards on about 30 different
> > +processor families - please make sure that any code you add can be
> > +used on as many different platforms as possible.
> > +
> > +Avoid assembly language whenever possible - only the reset code with
> > +basic CPU initialization, maybe a static DRAM initialization and the C
> > +stack setup should be in assembly.
> > +All further initializations should be done in C using assembly/C
> > +subroutines or inline macros. These functions represent some
> > +kind of HAL functionality and should be defined consistently on all
> > +architectures. E.g. Basic MMU and cache control, stack pointer 
> > manipulation.
> 
> %s/\. E\.g\./, e.g./
> 
> %s/Basic/basic/

It should probably read "on all architectures, e.g. basic 

Re: [PATCH 7/7] process.rst: Modernize the "Workflow of a Custodian" section

[Heinrich Schuchardt]

On 7/11/22 19:14, Tom Rini wrote:

The "Workflow of a Custodian" section on the wiki had not been changed
in quite some time to reflect how the process has been functioning for
some time.  First, update some links to point to modern and current
sources of information.

Second, and more overarching, reword much of the section.  This expands
on the expectations of both custodians and developers when it comes to
rebasing patches.  Rework the final points to be clearer that Custodians
are expected to do their best to test the changes and ask for help when
needed, as well as that pull requests are expected in a timely manner.

Cc: Claudius Heine 
Cc: Martin Bonner 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- New patch
---
  doc/develop/process.rst | 88 -
  1 file changed, 42 insertions(+), 46 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index d0c46b58f3e9..56c9d274be71 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -132,16 +132,20 @@ Work flow of a Custodian
  The normal flow of work in the U-Boot development process will look
  like this:

-#. A developer submits a patch via e-mail to the u-boot-users mailing list.
-   U-Boot has adopted the `Linux kernel signoff policy 
`_, so the 
submitter must
-   include a ``Signed-off-by:`` line.
+#. A developer submits a patch via e-mail to the u-boot mailing list.  In
+   U-Boot, we make use of the `Developer Certificate of Origin
+   `_ that is common in other projects such
+   as the Linux kernel.  Following this and adding a ``Signed-off-by:`` line
+   that contains the developer's name and email address is required.

-#. Everybody who can is invited to review and test the changes.  Reviews should
-   reply on the mailing list with ``Acked-by`` lines.
+#. Everybody who can is invited to review and test the changes.  Typically, we
+   follow the same guidelines as the Linux kernel for `Acked-by
+   
`_
+   as well as `Reviewed-by
+   
`_
+   and similar additional tags.

-#. The responsible custodian
-
-   #. inspects this patch, especially for:
+#. The responsible custodian inspects this patch, especially for:

 #. :doc:`codingstyle`

@@ -152,50 +156,42 @@ like this:
* The patch does not introduce new problems, especially it does not 
break
  other boards or architectures

-   #. U-Boot Philosophy
+   #. U-Boot Philosophy, as documented in :doc:`designprinciples`.

-   #. Applies cleanly to the source tree
+   #. Applies cleanly to the source tree.  The custodian is expected to put in
+  a "best effort" if a patch does not apply cleanly, but can be made to 
apply
+  still.  It is up to the custodian to decide how recent of a commit the
+  patch must be against.  It is acceptable to request patches against the
+  last officially released version of U-Boot or newer.  Of course a
+  custodian can also accept patches against older code.  It can be
+  difficult to find the correct balance between putting too much work on
+  the custodian or too much work on an individual submitting a patch when
+  something does not apply cleanly.

 #. Passes :doc:`ci_testing` as this checks for new warnings and other 
issues.

-#. Notes:
-
-  #. In some cases more than one custodian may be affected or feel responsible.
- To avoid duplicated efforts, the custodian who starts processing the
- patch should send a short ACK to the mailing list.
-
-  #. We should create some tool to automatically do this.
-
-  #. This is well documented in :doc:`designprinciples`.
-
-  #. The custodian decides themselves how recent the code must be.  It is
- acceptable to request patches against the last officially released
- version of U-Boot or newer.  Of course a custodian can also accept
- patches against older code.
-
-  #. Commits should show original author in the ``author`` field and include 
all
-  sign off/ack lines.
-
-#. The custodian decides to accept or to reject the patch.
-
-#. If accepted, the custodian adds the patch to their public git repository and
-   notifies the mailing list. This note should include:
+#. Note that in some cases more than one custodian may feel responsible for a
+   particular change.  To avoid duplicated efforts, the custodian who starts
+   processing the patch should follow up to the email saying they intend to
+   pick it up.

-   * a short description of the changes
+#. Commits must show original author in the ``author`` field and include all of
+   the ``Signed-off-by``, ``Reviewed-by``, etc, tags that have been 

Re: [PATCH 4/7] doc: Migrate Process wiki page to Sphinx

[Tom Rini]

On Wed, Jul 13, 2022 at 07:36:02PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
[snip]
> > +Work flow of a Custodian
> > +
> > +
> > +The normal flow of work in the U-Boot development process will look
> > +like this:
> > +
> > +#. A developer submits a patch via e-mail to the u-boot-users mailing list.
> > +   U-Boot has adopted the `Linux kernel signoff policy 
> > `_, so the 
> > submitter must
> > +   include a ``Signed-off-by:`` line.
> > +
> > +#. Everybody who can is invited to review and test the changes.  Reviews 
> > should
> > +   reply on the mailing list with ``Acked-by`` lines.
> > +
> > +#. The responsible custodian
> > +
> > +   #. inspects this patch, especially for:
> 
> This should not be a bullet point.
> 
> > +
> > +   #. :doc:`codingstyle`
> > +
> > +   #. Basic logic:
> > +
> > +  * The patch fixes a real problem.
> > +
> > +  * The patch does not introduce new problems, especially it does not 
> > break
> > +other boards or architectures
> > +
> > +   #. U-Boot Philosophy
> > +
> > +   #. Applies cleanly to the source tree
> > +
> > +   #. passes a ``MAKEALL`` compile test without creating new warnings
> > +
> > +#. Notes:
> > +
> > +  #. In some cases more than one custodian may be affected or feel 
> > responsible.
> > + To avoid duplicated efforts, the custodian who starts processing the
> > + patch should send a short ACK to the mailing list.
> > +
> > +  #. We should create some tool to automatically do this.
> > +
> > +  #. This is well documented in :doc:`designprinciples`.
> > +
> > +  #. The custodian decides himself how recent the code must be.  It is
> > + acceptable to request patches against the last officially released
> > + version of U-Boot or newer.  Of course a custodian can also accept
> > + patches against older code.
> 
> This paragraph is unclear. How about:
> 
> Patches should be based on the git HEAD. If merge conflicts arise, the
> custodian decides to either rebase the patch himself or to request the
> submitter for a rebased patch.
> 
> > +
> > +  #. Commits should show original author in the ``author`` field and 
> > include all
> > +  sign off/ack lines.
> 
> Sign-off, Acked-by, Reviewed-by lines.

Please comment on the later patch where I re-write this section a good
deal.  To repeat, I do not want to make significant changes to these
documents in the same commit that imports them from the wiki.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 6/7] process.rst: Perform minor cleanups

[Heinrich Schuchardt]

On 7/11/22 19:14, Tom Rini wrote:

- Use gender-neutral language to refer to the user, consistently.
- Reword a few places so that they read more naturally.
- Make the long standing practice around "Twilight Time" more clear,
   hopefully.
- Replace a reference to MAKEALL with a reference to CI testing as
   that's the current requirement.

Cc: Claudius Heine 
Cc: Martin Bonner 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Further tweak the wording, per Martin
---
  doc/develop/process.rst | 33 +
  1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 534da4a2a704..d0c46b58f3e9 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -46,21 +46,22 @@ Twilight Time
  -

  Usually patches do not get accepted as they are - the peer review that takes
-place will usually require changes and resubmits of the patches before they
+place will usually require changes and resubmissions of the patches before they
  are considered to be ripe for inclusion into mainline.

-Also, the review often happens not immediately after a patch was submitted,
+Also the review often happens not immediately after a patch was submitted,
  but only when somebody (usually the responsible custodian) finds time to do
  this.

-In the result, the final version of such patches gets submitted after the
+The result is that the final version of such patches gets submitted after the
  merge window has been closed.

  It is current practice in U-Boot that such patches are eligible to go into the
  upcoming release.

-In the result, the release of the ``"-rc1"`` version does not immediately 
follow
-the closing of the Merge Window.
+The result is that the release of the ``"-rc1"`` version and formal closing of
+the Merge Window does not preclude patches that were already posted from being
+merged for the upcoming release.

  Stabilization Period
  
@@ -75,13 +76,13 @@ Sometimes it is not clear if a patch contains a bug fix or 
not.
  For example, changes that remove dead code, unused macros etc. or
  that contain Coding Style fixes are not strict bug fixes.

-In such situations it is up to the responsible custodian to decide if he
-applies such patches even when the Merge Window is closed.
+In such situations it is up to the responsible custodian to decide if they


The custodian is singular.


+apply such patches even when the Merge Window is closed.

  Exception: at the end of the Stabilization Period only strict bug
  fixes my be applied.

-Sometimes patches miss the the Merge Window slightly - say by few
+Sometimes patches miss the Merge Window slightly - say by a few
  hours or even a day. Patch acceptance is not as critical as a
  financial transaction, or such. So if there is such a slight delay,
  the custodian is free to turn a blind eye and accept it anyway. The
@@ -110,7 +111,7 @@ Custodians
  --

  The Custodians take responsibility for some area of the U-Boot code.  The
-in-tree ``MAINTAINERS`` files list who is reponsible for which areas.
+in-tree ``MAINTAINERS`` files list who is responsible for which areas.

  It is their responsibility to pick up patches from the mailing list
  that fall into their responsibility, and to process these.
@@ -155,7 +156,7 @@ like this:

 #. Applies cleanly to the source tree

-   #. passes a ``MAKEALL`` compile test without creating new warnings
+   #. Passes :doc:`ci_testing` as this checks for new warnings and other 
issues.


%s/ci/CI/



  #. Notes:

@@ -167,7 +168,7 @@ like this:

#. This is well documented in :doc:`designprinciples`.

-  #. The custodian decides himself how recent the code must be.  It is
+  #. The custodian decides themselves how recent the code must be.  It is


The custodian is singular.


   acceptable to request patches against the last officially released
   version of U-Boot or newer.  Of course a custodian can also accept
   patches against older code.
@@ -177,7 +178,7 @@ like this:

  #. The custodian decides to accept or to reject the patch.

-#. If accepted, the custodian adds the patch to his public git repository and
+#. If accepted, the custodian adds the patch to their public git repository and
 notifies the mailing list. This note should include:

 * a short description of the changes
@@ -186,15 +187,15 @@ like this:

 * suggested tests

-   Although the custodian is supposed to perform his own tests
-   it is a well-known and accepted fact that he needs help from
+   Although the custodian is supposed to perform their own tests


ditto


+   it is a well-known and accepted fact that they needs help from
 other developers who - for example - have access to the required
 hardware or tool chains.
 The custodian request help for tests and feedback from
 specific maintainers and U-Boot users.

  #. Once tests are passed, some agreed time 

Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

[Tom Rini]

On Wed, Jul 13, 2022 at 07:06:56PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
> > The changes here are for formatting or slight rewording so that it reads
> > well when linking to other Sphinx documents.
> > 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Assorted wiki -> Sphinx style corrections and a few typo fixes, per
> >Heinrich
> > ---
> >   doc/develop/codingstyle.rst | 255 
> >   doc/develop/index.rst   |   8 ++
> >   2 files changed, 263 insertions(+)
> >   create mode 100644 doc/develop/codingstyle.rst
> > 
> > diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> > new file mode 100644
> > index ..bbeca42e656b
> > --- /dev/null
> > +++ b/doc/develop/codingstyle.rst
> > @@ -0,0 +1,255 @@
> > +.. SPDX-License-Identifier: GPL-2.0+:
> > +
> > +U-Boot Coding Style
> > +===
> > +
> > +The following Coding Style requirements shall be mandatory for all code 
> > contributed to
> > +the U-Boot project.
> > +
> > +Exceptions are only allowed if code from other projects is integrated with 
> > no
> > +or only minimal changes.
> > +
> > +The following rules apply:
> > +
> > +* All contributions to U-Boot should conform to the `Linux kernel
> > +  coding style 
> > `_
> > +  and the `Lindent script 
> > `_.
> > +  * The exception for net files to the `multi-line comment
> > +  
> > `_
> > +  applies only to Linux, not to U-Boot. Only large hunks which are copied
> > +  unchanged from Linux may retain that comment format.
> > +
> > +* Use patman to send your patches (``tools/patman/patman -H`` for full
> > +  instructions). With a few tags in your commits this will check your 
> > patches
> > +  and take care of emailing them.
> > +
> > +* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
> > +  more information, read :doc:`checkpatch`. Note that this should be done
> > +  *before* posting on the mailing list!
> > +
> > +* Source files originating from different projects (for example the MTD
> > +  subsystem or the hush shell code from the BusyBox project) may, after
> > +  careful consideration, be exempted from these rules. For such files, the
> > +  original coding style may be kept to ease subsequent migration to newer
> > +  versions of those sources.
> > +
> > +* Please note that U-Boot is implemented in C (and to some small parts in
> > +  Assembler); no C++ is used, so please do not use C++ style comments (//) 
> > in
> > +  your code.
> > +
> > +  * The sole exception here is for SPDX tags in some files (checkpatch.pl 
> > will warn you).
> > +
> > +* Please also stick to the following formatting rules:
> > +
> > +  * Remove any trailing white space
> > +
> > +  * Use TAB characters for indentation and vertical alignment, not spaces
> 
> This only holds true for C and assembler code.
> For Python we use 4 spaces per indent.
> 
> > +
> > +  * Make sure NOT to use DOS ``\r\n`` line feeds
> 
> %s/DOS/Windows/ - The documentation is not dedicated to veterans.
> %s/line feeds/line ends/ - a line feed is always 0x0a.
> 
> \r\n are escape codes in C. On a Windows machine these will be rendered
> as CR CR LF.
> 
> Please, use CR LF instead of \r\n.
> 
> > +
> > +  * Do not add more than 2 consecutive empty lines to source files
> > +
> > +  * Do not add trailing empty lines to source files
> > +
> > +  * Using the option ``git config --global color.diff auto`` will help to
> > +visually see whitespace problems in ``diff`` output from ``git``.
> > +
> > +  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
> > +feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The 
> > Right
> > +Thing (tm)
> 
> No clue why 'The Right Thing' should be a trademark here.
> Please, remove this bogus.

The phrase "The Right Thing (tm)" is I guess an old joke, as it implies
it will probably work, but still might mess up from time to time.  I'd
rather keep it.

> > +
> > +Submissions of new code or patches that do not conform to these 
> > requirements
> > +shall be rejected with a request to reformat the changes.
> > +
> > +U-Boot Code Documentation
> > +-
> > +
> > +U-Boot adopted the kernel-doc annotation style, this is the only exception 
> > from
> > +multi-line comment rule of Coding Style. While not mandatory, adding
> 
> Do you mean the extra asterisk?

Yes.

> > +documentation is strongly advised. The Linux kernel `kernel-doc
> > +`_
> > +documentation applies with no changes.
> > +
> > +Use structures for 

Re: [PATCH 5/7] designprinciples.rst: Perform minor cleanups

[Heinrich Schuchardt]

On 7/11/22 19:14, Tom Rini wrote:

- Remove some missed wiki markup, and escape a "\n" correctly.
- Use gender-neutral language to refer to the user, consistently.

Cc: Claudius Heine 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- None
---
  doc/develop/designprinciples.rst | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
index 43aeb5dacf5f..e5e12dca79f5 100644
--- a/doc/develop/designprinciples.rst
+++ b/doc/develop/designprinciples.rst
@@ -28,15 +28,15 @@ millions...

  A usable and useful configuration of U-Boot, including a basic
  interactive command interpreter, support for download over Ethernet
-and the capability to program the flash shall fit in no more than 128 !KiB.
+and the capability to program the flash shall fit in no more than 128 KiB.

  Keep it Fast
  

  The end user is not interested in running U-Boot. In most embedded
-systems he is not even aware that U-Boot exists. The user wants to
+systems they are not even aware that U-Boot exists. The user wants to


"The end user" is singular.


  run some application code, and that as soon as possible after switching
-on his device.
+on their device.

  It is therefore essential that U-Boot is as fast as possible,
  especially that it loads and boots the operating system as fast as possible.
@@ -63,7 +63,7 @@ Keep it Simple
  ^^

  U-Boot is a boot loader, but it is also a tool used for board
-bring-up, for production testing, and for other activities
+bring-up, for production testing, and for other activities.

  Keep it Portable
  
@@ -96,13 +96,13 @@ Keep it Configurable
  Section "Keep it Small" already explains about the size restrictions
  for U-Boot on one side. On the other side, U-Boot is a powerful tool
  with many, many extremely useful features. The maintainer or user of
-each board will have to decide which features are important to him and
-what shall be included with his specific board configuration to meet
-his current requirements and restrictions.
+each board will have to decide which features are important to them and
+what shall be included with their specific board configuration to meet
+their current requirements and restrictions.

  Please make sure that it is easy to add or remove features from a
  board configuration, so everybody can make the best use of U-Boot on
-his system.
+their system.

  If a feature is not included, it should not have any residual code
  bloating the build.
@@ -126,7 +126,7 @@ debug is all the more important to many of us.
  * All initialization steps shall print some "begin doing this" message before
they actually start, and some "done" message when they complete. For 
example,
RAM initialization and size detection may print a "RAM: " before they start,
-  and "256 MB\n" when done.  The purpose of this is that you can always see
+  and "256 MB\\n" when done.  The purpose of this is that you can always see


%s/MB/MiB/


which initialization step was running if there should be any problem.  This
is important not only during software development, but also for the service
people dealing with broken hardware in the field.
@@ -143,8 +143,8 @@ Please always keep in mind that there are at least three 
different
  groups of users for U-Boot, with completely different expectations
  and requirements:

-* The end user of an embedded device just wants to run some application; he
-  does not even want to know that U-Boot exists and only rarely interacts with
+* The end user of an embedded device just wants to run some application; they


Please, don't mix singular and plural.


+  do not even want to know that U-Boot exists and only rarely interacts with
it (for example to perform a reset to factory default settings etc.)

  * System designers and engineers working on the development of the application
@@ -157,7 +157,7 @@ and requirements:
their hardware is easy for them.

  * Make it easy to test. Add debug code (but don't re-invent the wheel - use
-  existing macros like debug() or debugX()).
+  existing macros like debug()).


%s/debug()/log_debug()/

Best regards

Heinrich



  Please always keep in mind that U-Boot tries to meet all these
  different requirements.

Re: [PATCH 4/7] doc: Migrate Process wiki page to Sphinx

[Heinrich Schuchardt]

On 7/11/22 19:14, Tom Rini wrote:

Move the current Process wiki page to doc/develop/process.rst.  The
changes here are for formatting or slight rewording so that it reads
well when linking to other Sphinx documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
   Heinrich
---
  doc/develop/index.rst   |   1 +
  doc/develop/process.rst | 200 
  2 files changed, 201 insertions(+)
  create mode 100644 doc/develop/process.rst

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index c0f4f0ba413a..eab00a55382a 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -11,6 +11,7 @@ General

 codingstyle
 designprinciples
+   process

  Implementation
  --
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
new file mode 100644
index ..534da4a2a704
--- /dev/null
+++ b/doc/develop/process.rst
@@ -0,0 +1,200 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Development Process
+==
+
+Management Summary
+--
+
+* Development happens in Release Cycles of 3 months.
+
+* The first 2 weeks are called Merge Window, which is followed by a
+  Stabilization Period.
+
+* Patches with new code get only accepted while the Merge Window is open.
+
+* A patch that is generally in good shape and that was submitted while the
+  Merge Window was open is eligible to go into the upcoming release, even if
+  changes and resubmits are needed.
+
+* During the Stabilization Period, only patches that contain bug fixes get
+  applied.
+
+Phases of the Development Process
+-
+
+U-Boot development takes place in `Release Cycles
+`_.  A Release Cycle lasts
+normally for three months.
+
+The first two weeks of each Release Cycle are called *Merge Window*.
+
+It is followed by a *Stabilization Period*.
+
+The end of a Release Cycle is marked by the release of a new U-Boot version.
+
+Merge Window
+
+
+The Merge Window is the period when new patches get submitted
+(and hopefully accepted) for inclusion into U-Boot mainline.
+
+This is the only time when new code (like support for new processors or new
+boards, or other new features or reorganization of code) is accepted.
+
+Twilight Time
+-
+
+Usually patches do not get accepted as they are - the peer review that takes
+place will usually require changes and resubmits of the patches before they
+are considered to be ripe for inclusion into mainline.
+
+Also, the review often happens not immediately after a patch was submitted,
+but only when somebody (usually the responsible custodian) finds time to do
+this.
+
+In the result, the final version of such patches gets submitted after the
+merge window has been closed.
+
+It is current practice in U-Boot that such patches are eligible to go into the
+upcoming release.
+
+In the result, the release of the ``"-rc1"`` version does not immediately 
follow
+the closing of the Merge Window.
+
+Stabilization Period
+
+
+During the Stabilization Period only patches containing bug fixes get
+applied.
+
+Corner Cases
+
+
+Sometimes it is not clear if a patch contains a bug fix or not.
+For example, changes that remove dead code, unused macros etc. or
+that contain Coding Style fixes are not strict bug fixes.
+
+In such situations it is up to the responsible custodian to decide if he
+applies such patches even when the Merge Window is closed.
+
+Exception: at the end of the Stabilization Period only strict bug
+fixes my be applied.
+
+Sometimes patches miss the the Merge Window slightly - say by few
+hours or even a day. Patch acceptance is not as critical as a
+financial transaction, or such. So if there is such a slight delay,
+the custodian is free to turn a blind eye and accept it anyway. The
+idea of the development process is to make it foreseeable,
+but not to slow down development.
+
+It makes more sense if an engineer spends another day on testing and
+cleanup and submits the patch a couple of hours late, instead of
+submitting a green patch which will waste efforts from several people
+during several rounds of review and reposts.
+
+Differences to the Linux Development Process
+
+
+* In Linux, top-level maintainers will collect patches in their trees and send
+  pull requests to Linus as soon as the merge window opens.
+  So far, most U-Boot custodians do not work like that; they send pull requests
+  only at (or even after) the end of the merge window.
+
+* In Linux, the closing of the merge window is marked by the release of the
+  next ``"-rc1"``
+  In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
+  the) patches that were submitted during the merge window have been applied.
+
+Custodians
+--
+
+The 

Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

[Tom Rini]

On Wed, Jul 13, 2022 at 07:06:56PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
> > The changes here are for formatting or slight rewording so that it reads
> > well when linking to other Sphinx documents.
> > 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Assorted wiki -> Sphinx style corrections and a few typo fixes, per
> >Heinrich
> > ---
> >   doc/develop/codingstyle.rst | 255 
> >   doc/develop/index.rst   |   8 ++
> >   2 files changed, 263 insertions(+)
> >   create mode 100644 doc/develop/codingstyle.rst
> > 
> > diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> > new file mode 100644
> > index ..bbeca42e656b
> > --- /dev/null
> > +++ b/doc/develop/codingstyle.rst
> > @@ -0,0 +1,255 @@
> > +.. SPDX-License-Identifier: GPL-2.0+:
> > +
> > +U-Boot Coding Style
> > +===
> > +
> > +The following Coding Style requirements shall be mandatory for all code 
> > contributed to
> > +the U-Boot project.
> > +
> > +Exceptions are only allowed if code from other projects is integrated with 
> > no
> > +or only minimal changes.
> > +
> > +The following rules apply:
> > +
> > +* All contributions to U-Boot should conform to the `Linux kernel
> > +  coding style 
> > `_
> > +  and the `Lindent script 
> > `_.
> > +  * The exception for net files to the `multi-line comment
> > +  
> > `_
> > +  applies only to Linux, not to U-Boot. Only large hunks which are copied
> > +  unchanged from Linux may retain that comment format.
> > +
> > +* Use patman to send your patches (``tools/patman/patman -H`` for full
> > +  instructions). With a few tags in your commits this will check your 
> > patches
> > +  and take care of emailing them.
> > +
> > +* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
> > +  more information, read :doc:`checkpatch`. Note that this should be done
> > +  *before* posting on the mailing list!
> > +
> > +* Source files originating from different projects (for example the MTD
> > +  subsystem or the hush shell code from the BusyBox project) may, after
> > +  careful consideration, be exempted from these rules. For such files, the
> > +  original coding style may be kept to ease subsequent migration to newer
> > +  versions of those sources.
> > +
> > +* Please note that U-Boot is implemented in C (and to some small parts in
> > +  Assembler); no C++ is used, so please do not use C++ style comments (//) 
> > in
> > +  your code.
> > +
> > +  * The sole exception here is for SPDX tags in some files (checkpatch.pl 
> > will warn you).
> > +
> > +* Please also stick to the following formatting rules:
> > +
> > +  * Remove any trailing white space
> > +
> > +  * Use TAB characters for indentation and vertical alignment, not spaces
> 
> This only holds true for C and assembler code.
> For Python we use 4 spaces per indent.
> 
> > +
> > +  * Make sure NOT to use DOS ``\r\n`` line feeds
> 
> %s/DOS/Windows/ - The documentation is not dedicated to veterans.
> %s/line feeds/line ends/ - a line feed is always 0x0a.
> 
> \r\n are escape codes in C. On a Windows machine these will be rendered
> as CR CR LF.
> 
> Please, use CR LF instead of \r\n.
> 
> > +
> > +  * Do not add more than 2 consecutive empty lines to source files
> > +
> > +  * Do not add trailing empty lines to source files
> > +
> > +  * Using the option ``git config --global color.diff auto`` will help to
> > +visually see whitespace problems in ``diff`` output from ``git``.
> > +
> > +  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
> > +feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The 
> > Right
> > +Thing (tm)
> 
> No clue why 'The Right Thing' should be a trademark here.
> Please, remove this bogus.
> 
> > +
> > +Submissions of new code or patches that do not conform to these 
> > requirements
> > +shall be rejected with a request to reformat the changes.
> > +
> > +U-Boot Code Documentation
> > +-
> > +
> > +U-Boot adopted the kernel-doc annotation style, this is the only exception 
> > from
> > +multi-line comment rule of Coding Style. While not mandatory, adding
> 
> Do you mean the extra asterisk?
> 
> > +documentation is strongly advised. The Linux kernel `kernel-doc
> > +`_
> > +documentation applies with no changes.
> > +
> > +Use structures for I/O access
> > +-
> > +
> > +U-Boot typically uses a C structure to map out the registers in an I/O 
> > region,
> > +rather than 

Re: [PATCH 2/7] doc: Migrate DesignPrinciples wiki page to Sphinx

[Heinrich Schuchardt]

On 7/11/22 19:14, Tom Rini wrote:

Move the current DesignPrinciples wiki page to
doc/develop/designprinciples.rst.  The changes here are for formatting
or slight rewording so that it reads well when linking to other Sphinx
documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
   Heinrich
---
  doc/develop/designprinciples.rst | 205 +++
  doc/develop/index.rst|   1 +
  2 files changed, 206 insertions(+)
  create mode 100644 doc/develop/designprinciples.rst

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
new file mode 100644
index ..43aeb5dacf5f
--- /dev/null
+++ b/doc/develop/designprinciples.rst
@@ -0,0 +1,205 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Design Principles
+
+
+The 10 Golden Rules of U-Boot design
+
+
+Keep it Small
+^
+
+U-Boot is a Boot Loader, i.e. its primary purpose in the shipping
+system is to load some operating system.
+That means that U-Boot is
+necessary to perform a certain task, but it's nothing you want to
+throw any significant resources at. Typically U-Boot is stored in
+relatively small NOR flash memory, which is expensive
+compared to the much larger NAND devices often used to store the
+operating system and the application.
+
+At the moment, U-Boot supports boards with just 128 KiB ROM or with
+256 KiB NOR flash. We should not easily ignore such configurations -
+they may be the exception in among all the other supported boards,
+but if a design uses such a resource-constrained hardware setup it is
+usually because costs are critical, i. e. because the number of
+manufactured boards might be tens or hundreds of thousands or even
+millions...
+
+A usable and useful configuration of U-Boot, including a basic
+interactive command interpreter, support for download over Ethernet
+and the capability to program the flash shall fit in no more than 128 !KiB.
+
+Keep it Fast
+
+
+The end user is not interested in running U-Boot. In most embedded
+systems he is not even aware that U-Boot exists. The user wants to
+run some application code, and that as soon as possible after switching
+on his device.
+
+It is therefore essential that U-Boot is as fast as possible,
+especially that it loads and boots the operating system as fast as possible.
+
+To achieve this, the following design principles shall be followed:
+
+* Enable caches as soon and whenever possible
+
+* Initialize devices only when they are needed within U-Boot, i.e. don't
+  initialize the Ethernet interface(s) unless U-Boot performs a download over
+  Ethernet; don't  initialize any IDE or USB devices unless U-Boot actually
+  tries to load files from these, etc.  (and don't forget to shut down these
+  devices after using them  - otherwise nasty things may happen when you try to
+  boot your OS).
+
+Also, building of U-Boot shall be as fast as possible.
+This makes it easier to run a build for all supported configurations
+or at least for all configurations of a specific architecture,
+which is essential for quality assurance.
+If building is cumbersome and slow, most people will omit
+this important step.
+
+Keep it Simple
+^^
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities
+
+Keep it Portable
+
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities that are
+very closely related to hardware development. So far, it has been
+ported to several hundreds of different boards on about 30 different
+processor families - please make sure that any code you add can be
+used on as many different platforms as possible.
+
+Avoid assembly language whenever possible - only the reset code with
+basic CPU initialization, maybe a static DRAM initialization and the C
+stack setup should be in assembly.
+All further initializations should be done in C using assembly/C
+subroutines or inline macros. These functions represent some
+kind of HAL functionality and should be defined consistently on all
+architectures. E.g. Basic MMU and cache control, stack pointer manipulation.


%s/\. E\.g\./, e.g./

%s/Basic/basic/


+Non-existing functions should expand into empty macros or error codes.
+
+Don't make assumptions over the environment where U-Boot is running.


%s/over/about/


+It may be communicating with a human operator on directly attached
+serial console, but it may be through a GSM modem as well, or driven
+by some automatic test or control system. So don't output any fancy
+control character sequences or similar.
+
+Keep it Configurable
+
+
+Section "Keep it Small" already explains about the size restrictions
+for U-Boot on one side. On the other side, U-Boot is a 

Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

[Heinrich Schuchardt]

On 7/11/22 19:14, Tom Rini wrote:

Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
The changes here are for formatting or slight rewording so that it reads
well when linking to other Sphinx documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
   Heinrich
---
  doc/develop/codingstyle.rst | 255 
  doc/develop/index.rst   |   8 ++
  2 files changed, 263 insertions(+)
  create mode 100644 doc/develop/codingstyle.rst

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
new file mode 100644
index ..bbeca42e656b
--- /dev/null
+++ b/doc/develop/codingstyle.rst
@@ -0,0 +1,255 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Coding Style
+===
+
+The following Coding Style requirements shall be mandatory for all code 
contributed to
+the U-Boot project.
+
+Exceptions are only allowed if code from other projects is integrated with no
+or only minimal changes.
+
+The following rules apply:
+
+* All contributions to U-Boot should conform to the `Linux kernel
+  coding style 
`_
+  and the `Lindent script 
`_.
+  * The exception for net files to the `multi-line comment
+  
`_
+  applies only to Linux, not to U-Boot. Only large hunks which are copied
+  unchanged from Linux may retain that comment format.
+
+* Use patman to send your patches (``tools/patman/patman -H`` for full
+  instructions). With a few tags in your commits this will check your patches
+  and take care of emailing them.
+
+* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
+  more information, read :doc:`checkpatch`. Note that this should be done
+  *before* posting on the mailing list!
+
+* Source files originating from different projects (for example the MTD
+  subsystem or the hush shell code from the BusyBox project) may, after
+  careful consideration, be exempted from these rules. For such files, the
+  original coding style may be kept to ease subsequent migration to newer
+  versions of those sources.
+
+* Please note that U-Boot is implemented in C (and to some small parts in
+  Assembler); no C++ is used, so please do not use C++ style comments (//) in
+  your code.
+
+  * The sole exception here is for SPDX tags in some files (checkpatch.pl will 
warn you).
+
+* Please also stick to the following formatting rules:
+
+  * Remove any trailing white space
+
+  * Use TAB characters for indentation and vertical alignment, not spaces


This only holds true for C and assembler code.
For Python we use 4 spaces per indent.


+
+  * Make sure NOT to use DOS ``\r\n`` line feeds


%s/DOS/Windows/ - The documentation is not dedicated to veterans.
%s/line feeds/line ends/ - a line feed is always 0x0a.

\r\n are escape codes in C. On a Windows machine these will be rendered
as CR CR LF.

Please, use CR LF instead of \r\n.


+
+  * Do not add more than 2 consecutive empty lines to source files
+
+  * Do not add trailing empty lines to source files
+
+  * Using the option ``git config --global color.diff auto`` will help to
+visually see whitespace problems in ``diff`` output from ``git``.
+
+  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
+feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The Right
+Thing (tm)


No clue why 'The Right Thing' should be a trademark here.
Please, remove this bogus.


+
+Submissions of new code or patches that do not conform to these requirements
+shall be rejected with a request to reformat the changes.
+
+U-Boot Code Documentation
+-
+
+U-Boot adopted the kernel-doc annotation style, this is the only exception from
+multi-line comment rule of Coding Style. While not mandatory, adding


Do you mean the extra asterisk?


+documentation is strongly advised. The Linux kernel `kernel-doc
+`_
+documentation applies with no changes.
+
+Use structures for I/O access
+-
+
+U-Boot typically uses a C structure to map out the registers in an I/O region,
+rather than offsets. The reasons for this are:
+
+* It dissociates the register location (offset) from the register type, which
+  means the developer has to make sure the type is right for each access,
+  whereas with the struct method, this is checked by the compiler;
+
+* It avoids actually writing all offsets, which is (more) error- prone;


%s/error- prone/error-prone/


+
+* It allows for better compile time sanity-checking of values we write to 
registers.
+
+Some reasons why you might not use C structures:
+
+* Where the registers appear at different 

[PATCH] dm: fix mis-word in SPL_DM description

[Oleksandr Suvorov]

Replace logically correct word in the description.

Fixes: 91a91ff804d ("dm: Add Kconfig options for driver model SPL support")
Signed-off-by: Oleksandr Suvorov 
---

 drivers/core/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 8eb0070d222..007dc6a1de3 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -18,7 +18,7 @@ config SPL_DM
  consider using CONFIG_SPL_SYS_MALLOC_SIMPLE. In that case you
  must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
  In most cases driver model will only allocate a few uclasses
- and devices in SPL, so 1KB should be enable. See
+ and devices in SPL, so 1KB should be enough. See
  CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
 
 config TPL_DM
-- 
2.36.1

[PATCH 3/3] sunxi: remove CONFIG_MMC?_CD_PIN

[Andre Przywara]

For legacy reasons we were defining the card detect GPIO for all sunxi
boards in each board's defconfig.
There is actually no need for a card-detect check in the SPL code (which
consequently has been removed already), and also in U-Boot proper we
have DM code to query the CD GPIO name from the device tree.

That means we don't have any user of that information left, so can
remove the definitions from the defconfigs.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Kconfig  | 27 
 configs/A10-OLinuXino-Lime_defconfig |  1 -
 configs/A10s-OLinuXino-M_defconfig   |  2 --
 configs/A13-OLinuXinoM_defconfig |  1 -
 configs/A13-OLinuXino_defconfig  |  1 -
 configs/A20-OLinuXino-Lime2-eMMC_defconfig   |  1 -
 configs/A20-OLinuXino-Lime2_defconfig|  1 -
 configs/A20-OLinuXino-Lime_defconfig |  1 -
 configs/A20-OLinuXino_MICRO-eMMC_defconfig   |  1 -
 configs/A20-OLinuXino_MICRO_defconfig|  2 --
 configs/A20-Olimex-SOM-EVB_defconfig |  2 --
 configs/A20-Olimex-SOM204-EVB-eMMC_defconfig |  1 -
 configs/A20-Olimex-SOM204-EVB_defconfig  |  1 -
 configs/A33-OLinuXino_defconfig  |  1 -
 configs/Ainol_AW1_defconfig  |  1 -
 configs/Ampe_A76_defconfig   |  1 -
 configs/Bananapi_M2_Ultra_defconfig  |  1 -
 configs/Bananapi_m2m_defconfig   |  1 -
 configs/Cubieboard2_defconfig|  1 -
 configs/Cubieboard4_defconfig|  1 -
 configs/Cubieboard_defconfig |  1 -
 configs/Cubietruck_defconfig |  1 -
 configs/Empire_electronix_d709_defconfig |  1 -
 configs/Empire_electronix_m712_defconfig |  1 -
 configs/Itead_Ibox_A20_defconfig |  1 -
 configs/Lamobo_R1_defconfig  |  1 -
 configs/Mele_M3_defconfig|  1 -
 configs/Mele_M5_defconfig|  1 -
 configs/Merrii_A80_Optimus_defconfig |  1 -
 configs/Orangepi_mini_defconfig  |  2 --
 configs/Sinlinx_SinA31s_defconfig|  1 -
 configs/Sinlinx_SinA33_defconfig |  1 -
 configs/Sunchip_CX-A99_defconfig |  1 -
 configs/UTOO_P66_defconfig   |  1 -
 configs/Wobo_i5_defconfig|  1 -
 configs/Yones_Toptech_BD1078_defconfig   |  2 --
 configs/Yones_Toptech_BS1078_V2_defconfig|  1 -
 configs/bananapi_m2_berry_defconfig  |  1 -
 configs/bananapi_m2_zero_defconfig   |  1 -
 configs/bananapi_m64_defconfig   |  1 -
 configs/beelink_gs1_defconfig|  1 -
 configs/colorfly_e708_q1_defconfig   |  1 -
 configs/difrnce_dit4350_defconfig|  1 -
 configs/dserve_dsrv9703c_defconfig   |  1 -
 configs/gt90h_v4_defconfig   |  1 -
 configs/iNet_3F_defconfig|  1 -
 configs/iNet_3W_defconfig|  1 -
 configs/iNet_D978_rev2_defconfig |  1 -
 configs/icnova-a20-swac_defconfig|  1 -
 configs/inet86dz_defconfig   |  1 -
 configs/inet98v_rev2_defconfig   |  1 -
 configs/inet_q972_defconfig  |  1 -
 configs/nanopi_m1_plus_defconfig |  1 -
 configs/oceanic_5205_5inmfd_defconfig|  1 -
 configs/orangepi_3_defconfig |  1 -
 configs/orangepi_lite2_defconfig |  1 -
 configs/orangepi_one_plus_defconfig  |  1 -
 configs/orangepi_zero2_defconfig |  1 -
 configs/orangepi_zero_plus2_defconfig|  1 -
 configs/orangepi_zero_plus2_h3_defconfig |  1 -
 configs/parrot_r16_defconfig |  1 -
 configs/pine64-lts_defconfig |  1 -
 configs/pine_h64_defconfig   |  1 -
 configs/polaroid_mid2407pxe03_defconfig  |  1 -
 configs/polaroid_mid2809pxe04_defconfig  |  1 -
 configs/q8_a13_tablet_defconfig  |  1 -
 configs/q8_a23_tablet_800x480_defconfig  |  1 -
 configs/q8_a33_tablet_1024x600_defconfig |  1 -
 configs/q8_a33_tablet_800x480_defconfig  |  1 -
 configs/sopine_baseboard_defconfig   |  1 -
 configs/tanix_tx6_defconfig  |  1 -
 71 files changed, 102 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 71a7f8dcee..5378eed154 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -638,33 +638,6 @@ config MACPWR
  Set the pin used to power the MAC. This takes a string in the format
  understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
 
-config MMC0_CD_PIN
-   string "Card detect pin for mmc0"
-   default "PF6" if MACH_SUN8I_A83T || MACH_SUNXI_H3_H5 || MACH_SUN50I
-   default ""
-   ---help---
-   Set the card detect pin for mmc0, leave empty to not use cd. This
-   takes a string in the format understood by sunxi_name_to_gpio, e.g.
-   PH1 for pin 1 of 

[PATCH 2/3] sunxi: mmc: group non-DM specific functions

[Andre Przywara]

As the SPL code for sunxi boards does not use the driver model, we have
two mmc_ops structures, one for DM, one for non-DM. The actual hardware
access code is shared, with the respective callback functions using that
common code.

To make this more obvious and easier to read, reorder the functions to
group them: we first have the common code, then the non-DM bits, and
the proper DM implementation at the end.
Also document this structure in the comment at the beginning of the file.

No functional change intended.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 117 +---
 1 file changed, 61 insertions(+), 56 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index b2f7e2d142..ad0fb4ad08 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -5,6 +5,12 @@
  * Aaron 
  *
  * MMC driver for allwinner sunxi platform.
+ *
+ * This driver is used by the (ARM) SPL with the legacy MMC interface, and
+ * by U-Boot proper using the full DM interface. The actual hardware access
+ * code is common, and comes first in this file.
+ * The legacy MMC interface implementation comes next, followed by the
+ * proper DM_MMC implementation at the end.
  */
 
 #include 
@@ -40,48 +46,6 @@ struct sunxi_mmc_priv {
struct mmc_config cfg;
 };
 
-#if !CONFIG_IS_ENABLED(DM_MMC)
-/* support 4 mmc hosts */
-struct sunxi_mmc_priv mmc_host[4];
-
-static int mmc_resource_init(int sdc_no)
-{
-   struct sunxi_mmc_priv *priv = _host[sdc_no];
-   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-
-   debug("init mmc %d resource\n", sdc_no);
-
-   switch (sdc_no) {
-   case 0:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC0_BASE;
-   priv->mclkreg = >sd0_clk_cfg;
-   break;
-   case 1:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC1_BASE;
-   priv->mclkreg = >sd1_clk_cfg;
-   break;
-#ifdef SUNXI_MMC2_BASE
-   case 2:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
-   priv->mclkreg = >sd2_clk_cfg;
-   break;
-#endif
-#ifdef SUNXI_MMC3_BASE
-   case 3:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
-   priv->mclkreg = >sd3_clk_cfg;
-   break;
-#endif
-   default:
-   printf("Wrong mmc number %d\n", sdc_no);
-   return -1;
-   }
-   priv->mmc_no = sdc_no;
-
-   return 0;
-}
-#endif
-
 /*
  * All A64 and later MMC controllers feature auto-calibration. This would
  * normally be detected via the compatible string, but we need something
@@ -269,19 +233,6 @@ static int sunxi_mmc_set_ios_common(struct sunxi_mmc_priv 
*priv,
return 0;
 }
 
-#if !CONFIG_IS_ENABLED(DM_MMC)
-static int sunxi_mmc_core_init(struct mmc *mmc)
-{
-   struct sunxi_mmc_priv *priv = mmc->priv;
-
-   /* Reset controller */
-   writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl);
-   udelay(1000);
-
-   return 0;
-}
-#endif
-
 static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv *priv, struct mmc *mmc,
 struct mmc_data *data)
 {
@@ -486,7 +437,60 @@ out:
return error;
 }
 
+/* non-DM code here is used by the (ARM) SPL only */
+
 #if !CONFIG_IS_ENABLED(DM_MMC)
+/* support 4 mmc hosts */
+struct sunxi_mmc_priv mmc_host[4];
+
+static int mmc_resource_init(int sdc_no)
+{
+   struct sunxi_mmc_priv *priv = _host[sdc_no];
+   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+   debug("init mmc %d resource\n", sdc_no);
+
+   switch (sdc_no) {
+   case 0:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC0_BASE;
+   priv->mclkreg = >sd0_clk_cfg;
+   break;
+   case 1:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC1_BASE;
+   priv->mclkreg = >sd1_clk_cfg;
+   break;
+#ifdef SUNXI_MMC2_BASE
+   case 2:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
+   priv->mclkreg = >sd2_clk_cfg;
+   break;
+#endif
+#ifdef SUNXI_MMC3_BASE
+   case 3:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
+   priv->mclkreg = >sd3_clk_cfg;
+   break;
+#endif
+   default:
+   printf("Wrong mmc number %d\n", sdc_no);
+   return -1;
+   }
+   priv->mmc_no = sdc_no;
+
+   return 0;
+}
+
+static int sunxi_mmc_core_init(struct mmc *mmc)
+{
+   struct sunxi_mmc_priv *priv = mmc->priv;
+
+   /* Reset controller */
+   writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl);
+   udelay(1000);
+
+   return 0;
+}
+
 static int sunxi_mmc_set_ios_legacy(struct mmc *mmc)
 {
struct sunxi_mmc_priv *priv = mmc->priv;
@@ -562,7 +566,8 @@ struct mmc *sunxi_mmc_init(int sdc_no)
 
return mmc_create(cfg, priv);
 }
-#else
+
+#else /* CONFIG_DM_MMC code below, as used by U-Boot 

[PATCH 1/3] sunxi: mmc: ignore card detect in SPL

[Andre Przywara]

The sunxi MMC code does not use the DM in the SPL, as we don't have a
device tree available that early, also no space for it.
This also means we cannot access the card-detect GPIO information from
there, so we have Kconfig symbols called CONFIG_MMCx_CD_PIN, which each
board has to define. This is a burden, also requires extra GPIO code in
the SPL.
As the SPL is the natural successor of the BootROM (from which we are
loaded), we can actually ignore the CD pin completely, as this is what
the BootROM does as well: CD GPIOs are board specific, but the BootROM
is not, so accesses the MMC devices anyway.

Remove the card detect code from the non-DM implementation of the sunxi
MMC driver, to get rid of this unneeded code.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 37 ++---
 1 file changed, 2 insertions(+), 35 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 1bb7b6d0e9..b2f7e2d142 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -44,22 +44,10 @@ struct sunxi_mmc_priv {
 /* support 4 mmc hosts */
 struct sunxi_mmc_priv mmc_host[4];
 
-static int sunxi_mmc_getcd_gpio(int sdc_no)
-{
-   switch (sdc_no) {
-   case 0: return sunxi_name_to_gpio(CONFIG_MMC0_CD_PIN);
-   case 1: return sunxi_name_to_gpio(CONFIG_MMC1_CD_PIN);
-   case 2: return sunxi_name_to_gpio(CONFIG_MMC2_CD_PIN);
-   case 3: return sunxi_name_to_gpio(CONFIG_MMC3_CD_PIN);
-   }
-   return -EINVAL;
-}
-
 static int mmc_resource_init(int sdc_no)
 {
struct sunxi_mmc_priv *priv = _host[sdc_no];
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-   int cd_pin, ret = 0;
 
debug("init mmc %d resource\n", sdc_no);
 
@@ -90,16 +78,7 @@ static int mmc_resource_init(int sdc_no)
}
priv->mmc_no = sdc_no;
 
-   cd_pin = sunxi_mmc_getcd_gpio(sdc_no);
-   if (cd_pin >= 0) {
-   ret = gpio_request(cd_pin, "mmc_cd");
-   if (!ret) {
-   sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
-   ret = gpio_direction_input(cd_pin);
-   }
-   }
-
-   return ret;
+   return 0;
 }
 #endif
 
@@ -523,23 +502,11 @@ static int sunxi_mmc_send_cmd_legacy(struct mmc *mmc, 
struct mmc_cmd *cmd,
return sunxi_mmc_send_cmd_common(priv, mmc, cmd, data);
 }
 
-static int sunxi_mmc_getcd_legacy(struct mmc *mmc)
-{
-   struct sunxi_mmc_priv *priv = mmc->priv;
-   int cd_pin;
-
-   cd_pin = sunxi_mmc_getcd_gpio(priv->mmc_no);
-   if (cd_pin < 0)
-   return 1;
-
-   return !gpio_get_value(cd_pin);
-}
-
+/* .get_cd is not needed by the SPL */
 static const struct mmc_ops sunxi_mmc_ops = {
.send_cmd   = sunxi_mmc_send_cmd_legacy,
.set_ios= sunxi_mmc_set_ios_legacy,
.init   = sunxi_mmc_core_init,
-   .getcd  = sunxi_mmc_getcd_legacy,
 };
 
 struct mmc *sunxi_mmc_init(int sdc_no)
-- 
2.25.1

[PATCH 0/3] sunxi: remove CONFIG_MMC?_CD_PIN

[Andre Przywara]

Since the dawn of time we had CONFIG_MMC?_CD_PIN defines for each
Allwinner board, which held the name for the respective MMC card
detect GPIO. These days we don't use that in U-Boot proper anymore
(and rely on DT for that, instead), so it's just for the SPL loading.
However the card detect is actually not needed there:
- We continue loading from the same boot media that the BootROM booted
  us from, so when we get to load from MMC, there is surely a card in
  the slot.
- The BROM already spoiled all efforts by unconditionally accessing the
  MMC bus, regardless of any card presence or not. We can't do more harm
  by doing the same.

This series removes the code checking the CD pin, and also the definition
from Kconfig and all defconfigs. On top there is a cleanup for the MMC
driver, which explains the reason for still also implementing the legacy
MMC interface.

Please have a look and test!

Thanks,
Andre

Andre Przywara (3):
  sunxi: mmc: ignore card detect in SPL
  sunxi: mmc: group non-DM specific functions
  sunxi: remove CONFIG_MMC?_CD_PIN

 arch/arm/mach-sunxi/Kconfig  |  27 
 configs/A10-OLinuXino-Lime_defconfig |   1 -
 configs/A10s-OLinuXino-M_defconfig   |   2 -
 configs/A13-OLinuXinoM_defconfig |   1 -
 configs/A13-OLinuXino_defconfig  |   1 -
 configs/A20-OLinuXino-Lime2-eMMC_defconfig   |   1 -
 configs/A20-OLinuXino-Lime2_defconfig|   1 -
 configs/A20-OLinuXino-Lime_defconfig |   1 -
 configs/A20-OLinuXino_MICRO-eMMC_defconfig   |   1 -
 configs/A20-OLinuXino_MICRO_defconfig|   2 -
 configs/A20-Olimex-SOM-EVB_defconfig |   2 -
 configs/A20-Olimex-SOM204-EVB-eMMC_defconfig |   1 -
 configs/A20-Olimex-SOM204-EVB_defconfig  |   1 -
 configs/A33-OLinuXino_defconfig  |   1 -
 configs/Ainol_AW1_defconfig  |   1 -
 configs/Ampe_A76_defconfig   |   1 -
 configs/Bananapi_M2_Ultra_defconfig  |   1 -
 configs/Bananapi_m2m_defconfig   |   1 -
 configs/Cubieboard2_defconfig|   1 -
 configs/Cubieboard4_defconfig|   1 -
 configs/Cubieboard_defconfig |   1 -
 configs/Cubietruck_defconfig |   1 -
 configs/Empire_electronix_d709_defconfig |   1 -
 configs/Empire_electronix_m712_defconfig |   1 -
 configs/Itead_Ibox_A20_defconfig |   1 -
 configs/Lamobo_R1_defconfig  |   1 -
 configs/Mele_M3_defconfig|   1 -
 configs/Mele_M5_defconfig|   1 -
 configs/Merrii_A80_Optimus_defconfig |   1 -
 configs/Orangepi_mini_defconfig  |   2 -
 configs/Sinlinx_SinA31s_defconfig|   1 -
 configs/Sinlinx_SinA33_defconfig |   1 -
 configs/Sunchip_CX-A99_defconfig |   1 -
 configs/UTOO_P66_defconfig   |   1 -
 configs/Wobo_i5_defconfig|   1 -
 configs/Yones_Toptech_BD1078_defconfig   |   2 -
 configs/Yones_Toptech_BS1078_V2_defconfig|   1 -
 configs/bananapi_m2_berry_defconfig  |   1 -
 configs/bananapi_m2_zero_defconfig   |   1 -
 configs/bananapi_m64_defconfig   |   1 -
 configs/beelink_gs1_defconfig|   1 -
 configs/colorfly_e708_q1_defconfig   |   1 -
 configs/difrnce_dit4350_defconfig|   1 -
 configs/dserve_dsrv9703c_defconfig   |   1 -
 configs/gt90h_v4_defconfig   |   1 -
 configs/iNet_3F_defconfig|   1 -
 configs/iNet_3W_defconfig|   1 -
 configs/iNet_D978_rev2_defconfig |   1 -
 configs/icnova-a20-swac_defconfig|   1 -
 configs/inet86dz_defconfig   |   1 -
 configs/inet98v_rev2_defconfig   |   1 -
 configs/inet_q972_defconfig  |   1 -
 configs/nanopi_m1_plus_defconfig |   1 -
 configs/oceanic_5205_5inmfd_defconfig|   1 -
 configs/orangepi_3_defconfig |   1 -
 configs/orangepi_lite2_defconfig |   1 -
 configs/orangepi_one_plus_defconfig  |   1 -
 configs/orangepi_zero2_defconfig |   1 -
 configs/orangepi_zero_plus2_defconfig|   1 -
 configs/orangepi_zero_plus2_h3_defconfig |   1 -
 configs/parrot_r16_defconfig |   1 -
 configs/pine64-lts_defconfig |   1 -
 configs/pine_h64_defconfig   |   1 -
 configs/polaroid_mid2407pxe03_defconfig  |   1 -
 configs/polaroid_mid2809pxe04_defconfig  |   1 -
 configs/q8_a13_tablet_defconfig  |   1 -
 configs/q8_a23_tablet_800x480_defconfig  |   1 -
 configs/q8_a33_tablet_1024x600_defconfig |   1 -
 configs/q8_a33_tablet_800x480_defconfig  |   1 -
 configs/sopine_baseboard_defconfig   |   1 -
 configs/tanix_tx6_defconfig  |   1 -
 drivers/mmc/sunxi_mmc.c  | 152 ---
 72 files changed, 62 

Re: PRAM and reserved memory for Linux

[Joakim Tjernlund]

On Wed, 2022-07-13 at 10:21 -0400, Tom Rini wrote:
> On Wed, Jul 13, 2022 at 10:08:38AM +, Joakim Tjernlund wrote:
> 
> > I added CONFIG_PRAM 4 and a reserved-memory DTS node for the same space but
> > now u-boot complains when booting:
> >   ERROR: reserving fdt memory region failed (addr=703ff000 size=1000)
> > The error is caused by arch_lmb_reserve() in arm which seem
> > to reserve command line and board info ? 
> > 
> > If I remove the reserved-memory DTS node I don't get a reserved area in 
> > Linux,
> > don't quite understand how PRAM is supposed to work?
> 
> The first likely problem is that CONFIG_PRAM stuff isn't often used
> these days so might be glitchy / buggy, as you've found here.  Next, I
> bet that area in arch_lmb_reserve() is about ATAGS/related and should be
> guarded with CONFIG_SUPPORT_PASSING_ATAGS.
> 

The  arch_lmb_reserve() comment reads(lots of archs has similar code):
/*
 * Booting a (Linux) kernel image
 *
 * Allocate space for command line and board info - the
 * address should be as high as possible within the reach of
 * the kernel (see CONFIG_SYS_BOOTMAPSZ settings), but in unused
 * memory, which means far enough below the current stack
 * pointer.

You still think this cmdline/board info is just for the old ATAGS ?
I have an older boot and it des not have CONFIG_SUPPORT_PASSING_ATAGS but
CMDLINE_TAG etc. is here though.

 Jocke

[PATCH] board: ti: am65x: Do not disable SA2UL in DT

[Andrew Davis]

This is no longer needed as the SA2UL can now be shared with Linux.
Leave the SA2UL DT node enabled.

Signed-off-by: Andrew Davis 
---
 board/ti/am65x/evm.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 7182a8cad1..8a0a506a3e 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -115,16 +115,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return ret;
}
 
-#if defined(CONFIG_TI_SECURE_DEVICE)
-   /* Make Crypto HW reserved for secure world use */
-   ret = fdt_disable_node(blob, "/bus@10/crypto@4e0");
-   if (ret < 0)
-   ret = fdt_disable_node(blob,
-  "/interconnect@10/crypto@4E0");
-   if (ret)
-   printf("%s: disabling SA2UL failed %d\n", __func__, ret);
-#endif
-
return 0;
 }
 #endif
-- 
2.36.1

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

[Stefan Herbrechtsmeier]

Hi Simon,

Am 13.07.2022 um 17:28 schrieb Simon Glass:

Hi Stefan,

On Tue, 12 Jul 2022 at 12:31, Stefan Herbrechtsmeier
 wrote:


Hi Simon,

Am 12.07.2022 um 12:58 schrieb Simon Glass:

Hi Stefan,

On Tue, 14 Jun 2022 at 07:22, Stefan Herbrechtsmeier
 wrote:


From: Stefan Herbrechtsmeier 

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

Signed-off-by: Stefan Herbrechtsmeier 
---

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


This looks good but is very expensive in terms of code size. Can you
update your u8 and u16 functions to reuse the existing u32 function
and just convert the value?


The u32 function requires a 32 bit value inside the device tree because
it checks the size and maybe swap the bytes.

The u8 and u16 function requires only a 8 and 16 bit value inside the
device tree.


Yes that's true. What is the use case for these functions?


The usb251xb driver requires this functions [1]. The usb251xb device 
tree binding [2] defines the ids as 16 bit values and the Linux driver 
use 8 bit for an unspecified property. Without this changes the driver 
doesn't satisfy the specification and is incompatible to the Linux driver.


[1] https://lists.denx.de/pipermail/u-boot/2022-June/486424.html
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/usb/usb251xb.txt


Regards
  Stefan

[PATCH] sunxi: configs: streamline include/configs/sun*.h wrappers

[Andre Przywara]

For mostly historic reasons we had configuration headers for each
Allwinner CPU "family". These days they are mostly just including one
common header, with the rest being somewhat empty.
There were attempts to remove them, and to just use the one common header
to begin with, but this has implications to the build system, which me
might not be ready for, yet.

To document this behaviour, and to avoid something sneaking in over
time, make those files all the same (minus the CPU family name and
the copyrights), and add a comment explaining that.
This makes it easier to just remove those files later on, when needed
and possible.

Signed-off-by: Andre Przywara 
---
Hi Tom,

this is mostly to just confirm and document what we already established
earlier: that those files are redundant, and are just needed to match
CONFIG_SYS_CONFIG_NAME. In case we don't need or want that anymore, we
can just remove them, without needing to think too hard about it.

Cheers,
Andre

 include/configs/sun4i.h  | 10 ++
 include/configs/sun50i.h | 19 ++-
 include/configs/sun5i.h  | 10 ++
 include/configs/sun6i.h  |  7 ++-
 include/configs/sun7i.h  |  6 ++
 include/configs/sun8i.h  | 13 ++---
 include/configs/sun9i.h  | 11 ++-
 include/configs/suniv.h  |  7 ++-
 8 files changed, 16 insertions(+), 67 deletions(-)

diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h
index 0e1baa91bb..70d451f224 100644
--- a/include/configs/sun4i.h
+++ b/include/configs/sun4i.h
@@ -2,18 +2,12 @@
 /*
  * (C) Copyright 2012-2013 Henrik Nordstrom 
  *
- * Configuration settings for the Allwinner A10 (sun4i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A10 (sun4i) CPU
+ * based devices separately. Please do not add anything in here.
  */
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * A10 specific configuration
- */
-
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun50i.h b/include/configs/sun50i.h
index bc2e3a3d00..dfcb321d42 100644
--- a/include/configs/sun50i.h
+++ b/include/configs/sun50i.h
@@ -1,26 +1,11 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Configuration settings for the Allwinner A64 (sun50i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A64 (and later) sun50i
+ * CPU based devices separately. Please do not add anything in here.
  */
-
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * A64 specific configuration
- */
-
-#ifndef CONFIG_SUN50I_GEN_H6
-#define GICD_BASE  0x1c81000
-#define GICC_BASE  0x1c82000
-#else
-#define GICD_BASE  0x3021000
-#define GICC_BASE  0x3022000
-#endif
-
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h
index ada18de753..3017307854 100644
--- a/include/configs/sun5i.h
+++ b/include/configs/sun5i.h
@@ -2,18 +2,12 @@
 /*
  * (C) Copyright 2012-2013 Henrik Nordstrom 
  *
- * Configuration settings for the Allwinner A13 (sun5i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A13 (sun5i) CPU
+ * based devices separately. Please do not add anything in here.
  */
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * High Level Configuration Options
- */
-
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun6i.h b/include/configs/sun6i.h
index 0b1fedda10..cbe04ac3c2 100644
--- a/include/configs/sun6i.h
+++ b/include/configs/sun6i.h
@@ -4,15 +4,12 @@
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  * (C) Copyright 2013 Maxime Ripard 
  *
- * Configuration settings for the Allwinner A31 (sun6i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A31 (sun6i) CPU
+ * based devices separately. Please do not add anything in here.
  */
-
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h
index bc2779fa26..ad24ab98b5 100644
--- a/include/configs/sun7i.h
+++ b/include/configs/sun7i.h
@@ -3,14 +3,12 @@
  * (C) Copyright 2012-2013 Henrik Nordstrom 
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  *
- * Configuration settings for the Allwinner A20 (sun7i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A20 (sun7i) CPU
+ * based devices separately. Please do not add anything in here.
  */
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
index 106139d090..b6cd8d39a8 100644
--- a/include/configs/sun8i.h
+++ b/include/configs/sun8i.h
@@ -2,21 +2,12 @@
 /*
  * (C) Copyright 2014 Chen-Yu Tsai 
  *
- * Configuration 

Re: [PATCH 3/3] fdt: introduce apply_all command

[Simon Glass]

Hi Andre,

On Wed, 13 Jul 2022 at 07:18, Andre Przywara  wrote:
>
> On Tue, 12 Jul 2022 04:58:35 -0600
> Simon Glass  wrote:
>
> Hi Simon,
>
> many thanks for having a look!
>
> > On Tue, 5 Jul 2022 at 11:14, Andre Przywara  wrote:
> > >
> > > Explicitly specifying the exact filenames of devicetree overlays files
> > > on a U-Boot command line can be quite tedious for users, especially
> > > when it should be made persistent for every boot.
> > >
> > > To simplify the task of applying (custom) DT overlays, introduce a
> > > "fdt apply-all" subcommand, that iterates a given directory in any
> > > supported filesystem, and tries to apply every .dtbo file found it
> > > there.
> > >
> > > This allows users to simply drop a DT overlay file into a magic
> > > directory, and it will be applied on the next boot automatically,
> > > by the virtue of just a generic U-Boot command call.
> > >
> > > Signed-off-by: Andre Przywara 
> > > ---
> > >  cmd/fdt.c | 89 ++-
> > >  1 file changed, 88 insertions(+), 1 deletion(-)
> >
> > This looks OK, but can you please add a test (see test/dm/acpi.c for
> > example) and doc/usage/cmd file?
>
> Is that supposed to run inside the sandbox? I briefly tested this there,
> only to realise that the sandbox' hostfs does not support the directory
> operations (fs_opendir_unsupported). I haven't thought about it too much,
> nor do I have much experience with U-Boot's test framework, but this sounds
> like a problem?

Yes that is a problem, although it would not be too hard to implement, I think.

Also I sent a little series to add a test for 'fdt addr' which might
make it easier for you.

>
> > Also, apply_all is a bit annoying as we try to allow command
> > completion and abbreviations to work. Given that the args are
> > different I don't think a -d (for dir) flag makes sense.
> >
> > Perhaps 'fdt fsapply' ?
>
> Yeah, I wasn't happy with that name either, but couldn't come up with a
> better name. "fsapply" seems to be a nice alternative, I will go with that!

OK good.

Regards,
Simon

Re: [PATCH] cmd: fdt: Add support for reading stringlist property values

[Simon Glass]

Hi Marek,

On Wed, 13 Jul 2022 at 09:30, Marek Vasut  wrote:
>
> On 7/13/22 17:28, Simon Glass wrote:
> > Hi Marek,
> >
> > On Tue, 12 Jul 2022 at 05:47, Marek Vasut  wrote:
> >>
> >> On 7/12/22 12:58, Simon Glass wrote:
> >>> Hi Marek,
> >>>
> >>> On Fri, 8 Jul 2022 at 15:50, Marek Vasut  wrote:
> 
>  The fdt command currently handles stringlists as strings in 'fdt get 
>  value'
>  subcommand. Since strings in FDT stringlists are separated by '\0', only
>  the first value gets inserted into the environment variable passed to the
>  'fdt get value' command.
> 
>  Example, consider the following DT snippet:
> 
>  / { compatible = "foo", "bar" };
> 
>  The following command only reports the first string in stringlist:
>  => fdt get value var / compatible ; print var
>  foo
> 
>  It is not possible to assign list of null-terminated strings into U-Boot
>  environment variable. Add optional 'index' parameter to the subcommand
>  'fdt get value[]' which lets user specify 
>  which
>  string within the stringlist should be assigned into the 'var' variable.
>  The default value of 'index' is 0 in case it is not present. This way the
>  'fdt' command API does not change and existing scripts are not broken.
> 
>  The following command now reports the Nth string in stringlist, counting
>  from zero:
>  => fdt get value var / compatible 1 ; print var
>  bar
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Heinrich Schuchardt 
>  Cc: Simon Glass 
>  Cc: Tom Rini 
>  ---
> cmd/fdt.c | 34 --
> 1 file changed, 28 insertions(+), 6 deletions(-)
> >>>
> >>> Can you please add docs and a test?
> >>
> >> I was expecting this kind of question ... there is no test for the FDT
> >> command.
> >>
> >>> I am happy to do a starting point for a test if you like.
> >>
> >> You can implement the test for this while at it.
> >
> > I sent a starting point for you, both docs and test.
>
> Thank you.
>
> Do I understand your remark correctly that you're blocking this
> particular patch from going in until there is a test ?

I'm not blocking anything, but turning it around the other way, how
about having a crack at a test? You can try out 'ut fdt' to see the
current tests (using the patches I sent).

Regards,
Simon

Re: [PATCH] cmd: fdt: Add support for reading stringlist property values

[Marek Vasut]

On 7/13/22 17:28, Simon Glass wrote:

Hi Marek,

On Tue, 12 Jul 2022 at 05:47, Marek Vasut  wrote:


On 7/12/22 12:58, Simon Glass wrote:

Hi Marek,

On Fri, 8 Jul 2022 at 15:50, Marek Vasut  wrote:


The fdt command currently handles stringlists as strings in 'fdt get value'
subcommand. Since strings in FDT stringlists are separated by '\0', only
the first value gets inserted into the environment variable passed to the
'fdt get value' command.

Example, consider the following DT snippet:

/ { compatible = "foo", "bar" };

The following command only reports the first string in stringlist:
=> fdt get value var / compatible ; print var
foo

It is not possible to assign list of null-terminated strings into U-Boot
environment variable. Add optional 'index' parameter to the subcommand
'fdt get value[]' which lets user specify which
string within the stringlist should be assigned into the 'var' variable.
The default value of 'index' is 0 in case it is not present. This way the
'fdt' command API does not change and existing scripts are not broken.

The following command now reports the Nth string in stringlist, counting
from zero:
=> fdt get value var / compatible 1 ; print var
bar

Signed-off-by: Marek Vasut 
Cc: Heinrich Schuchardt 
Cc: Simon Glass 
Cc: Tom Rini 
---
   cmd/fdt.c | 34 --
   1 file changed, 28 insertions(+), 6 deletions(-)


Can you please add docs and a test?


I was expecting this kind of question ... there is no test for the FDT
command.


I am happy to do a starting point for a test if you like.


You can implement the test for this while at it.


I sent a starting point for you, both docs and test.


Thank you.

Do I understand your remark correctly that you're blocking this 
particular patch from going in until there is a test ?

Re: [PATCH v6 3/7] tpm: Add the RNG child device

[Simon Glass]

Hi Rob,

On Tue, 12 Jul 2022 at 08:11, Rob Herring  wrote:
>
> On Tue, Jul 12, 2022 at 5:04 AM Simon Glass  wrote:
> >
> > Hi Ilias,
> >
> > On Fri, 8 Jul 2022 at 02:24, Ilias Apalodimas
> >  wrote:
> > >
> > > Hi Simon,
> > >
> > > [...]
> > >
> > > > > +
> > > > >  UCLASS_DRIVER(tpm) = {
> > > > > -   .id = UCLASS_TPM,
> > > > > -   .name   = "tpm",
> > > > > -   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > > +   .id = UCLASS_TPM,
> > > > > +   .name   = "tpm",
> > > > > +   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > >  #if CONFIG_IS_ENABLED(OF_REAL)
> > > > > -   .post_bind  = dm_scan_fdt_dev,
> > > > > +   .post_bind  = dm_scan_fdt_dev,
> > > > >  #endif
> > > > > +   .post_probe = tpm_uclass_post_probe,
> > > > > .per_device_auto= sizeof(struct tpm_chip_priv),
> > > > >  };
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > > The driver needs a compatible string so it can be in the device tree.
> > >
> > > Why?  I've tried to hint this on the previous iteration of the patch.
> > > The RNG here is not a *device*.  The TPM is the device and you are
> > > guaranteed to have an RNG.  The way to get a random number is send a
> > > special command to the TPM. So all that we should do here is leverage
> > > the fact that the TPM is already in the device tree.
> > >
> > > And fwiw we should stick to try to stick to what the DT spec defines
> > > as much as possible.  I personally don't see this as a special usecase
> > > were deviating from the spec is justified.
> >
> > This is not a deviation from a spec. What spec? Also, I don't want to
> > get into another discussion about what a device is. We can disagree on
> > that if you like.
> >
> > One reason is that U-Boot generally requires compatible strings, e.g.
> > with of-platdata. But also we can refer to the rand device from
> > elsewhere in the tree. I know that Linux does lots of ad-hoc device
> > creation and doesn't really have the concept of a uclass consistently
> > applied, but this is U-Boot.
>
> You are letting client/OS details define your binding. Doing so
> doesn't result in OS agnostic bindings. Sure, it would be nice if DT
> nodes and drivers were always a nice clean 1:1 ratio, but h/w is messy
> sometimes and DT is not an abstraction layer. The general guidance on
> whether there are child nodes for sub-blocks is do they have their own
> resources in DT or are the sub-blocks reusable on multiple devices.
> Neither of those are the case here.
>
> Besides, we already have TPM device bindings defined. Requiring
> binding changes when adding a new client/OS feature is not good
> practice either.

I'm not sure what to do with this, but in general the practice of
implied subnodes is not friendly to U-Boot. Yet it seems like a common
feature of the bindings at present, for example GPIOs.

The device tree is how U-Boot determines which random-number generator
to use for a particular function. For example, for VBE, if we need to
generate some random numbers we'd like to specify which device creates
them. It can't just be 'use the TPM if you find one'. I'm not sure how
that works in Linux?

Regards,
SImon

Re: [PATCH] console: Add option to keep it silent until env is loaded

[Simon Glass]

Hi Harald,

On Tue, 12 Jul 2022 at 05:58, Harald Seiler  wrote:
>
> Hi Simon,
>
> On Tue, 2022-07-12 at 04:58 -0600, Simon Glass wrote:
> > Hi Harald,
> >
> > On Wed, 6 Jul 2022 at 05:19, Harald Seiler  wrote:
> > >
> > > Add a config-option which forces the console to stay silent until the
> > > proper environment is loaded from flash.
> > >
> > > This is important when the default environment does not silence the
> > > console but no output must be printed when 'silent' is set in the flash
> > > environment.
> > >
> > > After the environment from flash is loaded, the console will be
> > > silenced/unsilenced depending on it.  If PRE_CONSOLE_BUFFER is also
> > > used, the buffer will now be flushed if the console should not be
> > > silenced.
> > >
> > > Signed-off-by: Harald Seiler 
> > > ---
> > >  common/Kconfig   | 10 ++
> > >  common/console.c |  5 +
> > >  2 files changed, 15 insertions(+)
> >
> > This seems OK to me. You might want to implement the silent-console
> > device tree property in console_update_silent() too, which was dropped
> > in the conversion to driver model.
>
> This looks interesting, I'll have to look into it.
>
> Do you know if there's any effort towards supporting such a flag in the
> kernel as well?  I had to remove the serial console property from my DT
> and instead pass console info via cmdline to make the silent console
> work.  A "pure DT" solution of any sort would have been nicer of
> course...

The console's 'silent' flag is propagated to Linux by dropping the
'console=' text from the bootargs. See fixup_silent_linux().

Regards,
Simon


>
> --
> Harald

Re: [PATCH] binman: Increase default fitImage data section resize step from 1k to 64k

[Simon Glass]

On Tue, 12 Jul 2022 at 11:41, Marek Vasut  wrote:
>
> Currently the fitImage data area is resized in 1 kiB steps. This works
> when bundling smaller images below some 1 MiB, but when bundling large
> images into the fitImage, this make binman spend extreme amount of time
> and CPU just spinning in pylibfdt FdtSw.check_space() until the size
> grows enough for the large image to fit into the data area. Increase
> the default step to 64 kiB, which is a reasonable compromise -- the
> U-Boot blobs are somewhere in the 64kiB...1MiB range, DT blob are just
> short of 64 kiB, and so are the other blobs. This reduces binman runtime
> with 32 MiB blob from 2.3 minutes to 5 seconds.
>
> The following can be used to trigger the problem if rand.bin is some 32 MiB.
> "
> / {
>   itb {
> fit {
>   images {
> test {
>   compression = "none";
>   description = "none";
>   type = "flat_dt";
>
>   blob {
> filename = "rand.bin";
> type = "blob-ext";
>   };
> };
>   };
> };
>   };
>
>   configurations {
> binman_configuration: config {
>   loadables = "test";
> };
>   };
> };
> "
>
> Signed-off-by: Marek Vasut 
> Cc: Alper Nebi Yasak 
> Cc: Simon Glass 
> ---
>  tools/binman/etype/fit.py | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

I wonder if pylibfdt should become a bit smarter and increase by the
correct amount?


>
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index 12306623af6..ad43fce18ec 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -658,6 +658,7 @@ class Entry_fit(Entry_section):
>  # Build a new tree with all nodes and properties starting from the
>  # entry node
>  fsw = libfdt.FdtSw()
> +fsw.INC_SIZE = 65536
>  fsw.finish_reservemap()
>  to_remove = []
>  loadables = []
> --
> 2.35.1
>

Re: [PATCH 4/4] vpl: fix reference in comment to non-existing SPL_SERIAL_SUPPORT

[Simon Glass]

On Tue, 12 Jul 2022 at 09:45, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Since commit 2a7360666871 ("serial: Rename SERIAL_SUPPORT to SERIAL")
> SPL_SERIAL_SUPPORT is named SPL_SERIAL. So let's update the comment to
> point to the correct Kconfig option in the comment of VPL_SERIAL.
>
> Fixes: 747093dd408 ("vpl: Add Kconfig options for VPL")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  common/spl/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Re: [gitdm v2] reports.py: Add very basic rST output

[Simon Glass]

On Tue, 12 Jul 2022 at 15:14, Tom Rini  wrote:
>
> Add a -R option to gitdm to allow for reStructuredText output and add
> some very simple table generation.  We assume that whatever uses this
> output will be including it in other documents and we only concern
> ourselves with making tables.  Give ourselves 36 characters to fill in
> the nae field, as this tends to be long enough and can be corrected
> manually in the cases where it's slightly too short still.
>
> Cc: Heinrich Schuchardt 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - Rework how we declare a table, per Heinrich
> ---
>  gitdm  |  5 -
>  reports.py | 22 ++
>  2 files changed, 26 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH 1/4] gpio: fix incorrect depends on for SPL_GPIO_HOG

[Simon Glass]

On Tue, 12 Jul 2022 at 09:44, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Since commit 83061dbd1c89 ("Rename GPIO_SUPPORT to GPIO"),
> SPL_GPIO_SUPPORT has been renamed to SPL_GPIO, meaning that SPL_GPIO_HOG
> can never be enabled.
>
> Let's fix this by using the proper name for the Kconfig option.
>
> Fixes: 1d99e673c752 ("gpio: Enable hogging support in SPL")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/gpio/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH] cmd: fdt: Add support for reading stringlist property values

[Simon Glass]

Hi Marek,

On Tue, 12 Jul 2022 at 05:47, Marek Vasut  wrote:
>
> On 7/12/22 12:58, Simon Glass wrote:
> > Hi Marek,
> >
> > On Fri, 8 Jul 2022 at 15:50, Marek Vasut  wrote:
> >>
> >> The fdt command currently handles stringlists as strings in 'fdt get value'
> >> subcommand. Since strings in FDT stringlists are separated by '\0', only
> >> the first value gets inserted into the environment variable passed to the
> >> 'fdt get value' command.
> >>
> >> Example, consider the following DT snippet:
> >>
> >> / { compatible = "foo", "bar" };
> >>
> >> The following command only reports the first string in stringlist:
> >> => fdt get value var / compatible ; print var
> >> foo
> >>
> >> It is not possible to assign list of null-terminated strings into U-Boot
> >> environment variable. Add optional 'index' parameter to the subcommand
> >> 'fdt get value[]' which lets user specify which
> >> string within the stringlist should be assigned into the 'var' variable.
> >> The default value of 'index' is 0 in case it is not present. This way the
> >> 'fdt' command API does not change and existing scripts are not broken.
> >>
> >> The following command now reports the Nth string in stringlist, counting
> >> from zero:
> >> => fdt get value var / compatible 1 ; print var
> >> bar
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Heinrich Schuchardt 
> >> Cc: Simon Glass 
> >> Cc: Tom Rini 
> >> ---
> >>   cmd/fdt.c | 34 --
> >>   1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > Can you please add docs and a test?
>
> I was expecting this kind of question ... there is no test for the FDT
> command.
>
> > I am happy to do a starting point for a test if you like.
>
> You can implement the test for this while at it.

I sent a starting point for you, both docs and test.

Regards,
Simon

Re: [PATCH 10/19] buildman: Incorporate the genboardscfg.py tool

[Simon Glass]

Hi Tom,

On Tue, 12 Jul 2022 at 15:38, Tom Rini  wrote:
>
> On Mon, Jul 11, 2022 at 07:04:04PM -0600, Simon Glass wrote:
> > Bring this tool into buildman, so we don't have to run it separately. The
> > board.cfg file is still produced as part of the build, to save time when
> > doing another build in the same working directory. If it is out of date
> > with respect to the Kconfig, it is updated.
> >
> > Time to regenerate on a recent single-thread machine is 4.6s (1.3s on a
> > 32-thread machine), so we do need some sort of cache if we want buildman
> > to be useful on incremental builds. We could use Python's pickle format
> > but:
> >
> > - it seems useful to allow boards.cfg to be regenerated, at least for a
> >   while, in case other tools use it
> > - it is possible to grep the file easily, e.g. to find boards which use
> >   a particular SoC (similar to 'buildman -nv '
>
> While I don't think other tools still use boards.cfg, this will make it
> easier to find out that I'm wrong.  Perhaps once the CONFIG to Kconfig
> migration is done we can move to just pickle'ing the data or similar
> since I find the main use of what was in boards.cfg can be figured out
> with some other git grep'ing, and in turn that's mainly for me when
> trying to convert stuff.  Thanks for doing this.

Yes. I'm excited to hear that Kconfig migration might be done - any
forecast as to when?

One thing we could to is provide an option for buildman to spit out
the various fields that go into boards.cfg

Regards,
SImon

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

[Simon Glass]

Hi Stefan,

On Tue, 12 Jul 2022 at 12:31, Stefan Herbrechtsmeier
 wrote:
>
> Hi Simon,
>
> Am 12.07.2022 um 12:58 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Tue, 14 Jun 2022 at 07:22, Stefan Herbrechtsmeier
> >  wrote:
> >>
> >> From: Stefan Herbrechtsmeier 
> >>
> >> Add functions to read 8/16-bit integers like the existing functions for
> >> 32/64-bit to simplify read of 8/16-bit integers from device tree
> >> properties.
> >>
> >> Signed-off-by: Stefan Herbrechtsmeier 
> >> 
> >> ---
> >>
> >>   arch/sandbox/dts/test.dts |  2 ++
> >>   drivers/core/of_access.c  | 38 +++
> >>   drivers/core/ofnode.c | 62 +
> >>   drivers/core/read.c   | 21 +
> >>   include/dm/of_access.h| 32 +++
> >>   include/dm/ofnode.h   | 40 
> >>   include/dm/read.h | 65 +++
> >>   test/dm/test-fdt.c| 19 
> >>   8 files changed, 279 insertions(+)
> >
> > This looks good but is very expensive in terms of code size. Can you
> > update your u8 and u16 functions to reuse the existing u32 function
> > and just convert the value?
>
> The u32 function requires a 32 bit value inside the device tree because
> it checks the size and maybe swap the bytes.
>
> The u8 and u16 function requires only a 8 and 16 bit value inside the
> device tree.

Yes that's true. What is the use case for these functions?

Reviewed-by: Simon Glass 

Regards,
Simon

[PATCH 2/3] sunxi: h616: lower SPL stack address to avoid BROM data

[Andre Przywara]

When using the USB OTG FEL mode on the Allwinner H616, the BootROM
stores some data at the end of SRAM C. This is also the location where
we place the initial SPL stack, so it will overwrite this data.
We still need the BROM code after running the SPL, so should leave that
area alone.
Interestingly this does not seem to have an adverse effect, I guess on
the "way out" (when we return to FEL after the SPL has run), this data
is not needed by the BROM, for just the trailing end of the USB operation.
However this is still wrong, and we should not clobber BROM data.

Lower the SPL stack address to be situated right below the swap buffers
we use in sunxi-fel: that should be out of the way of everyone else.

Signed-off-by: Andre Przywara 
---
 include/configs/sunxi-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 0f0ef4f64b..d36b59daf7 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -105,7 +105,7 @@
 #endif /* !CONFIG_ARM64 */
 #elif CONFIG_SUNXI_SRAM_ADDRESS == 0x2
 #ifdef CONFIG_MACH_SUN50I_H616
-#define LOW_LEVEL_SRAM_STACK   0x58000
+#define LOW_LEVEL_SRAM_STACK   0x52a00 /* below FEL buffers */
 #else
 /* end of SRAM A2 on H6 for now */
 #define LOW_LEVEL_SRAM_STACK   0x00118000
-- 
2.25.1

[PATCH 3/3] sunxi: fel: drop redundant "control register" save/restore

[Andre Przywara]

For some reasons shrouded in mystery, the code saving the FEL state was
saving the SCTLR register twice, with the second copy trying to justify
itself by using its ancient "control register" alias name.

Drop the redundant second copy, both from the fel_stash data structure,
and also the code saving and restoring it.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv7/sunxi/fel_utils.S | 4 
 arch/arm/mach-sunxi/board.c  | 1 -
 2 files changed, 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/fel_utils.S 
b/arch/arm/cpu/armv7/sunxi/fel_utils.S
index b2310751d9..78bb1657fc 100644
--- a/arch/arm/cpu/armv7/sunxi/fel_utils.S
+++ b/arch/arm/cpu/armv7/sunxi/fel_utils.S
@@ -20,8 +20,6 @@ ENTRY(save_boot_params)
str lr, [r0, #12]
mrc p15, 0, lr, c12, c0, 0  @ Read VBAR
str lr, [r0, #16]
-   mrc p15, 0, lr, c1, c0, 0   @ Read CP15 Control Register
-   str lr, [r0, #20]
b   save_boot_params_ret
 ENDPROC(save_boot_params)
 
@@ -29,8 +27,6 @@ ENTRY(return_to_fel)
mov sp, r0
mov lr, r1
ldr r0, =fel_stash
-   ldr r1, [r0, #20]
-   mcr p15, 0, r1, c1, c0, 0   @ Write CP15 Control Register
ldr r1, [r0, #16]
mcr p15, 0, r1, c12, c0, 0  @ Write VBAR
ldr r1, [r0, #12]
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 8f7c894286..385eac7a61 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -35,7 +35,6 @@ struct fel_stash {
uint32_t cpsr;
uint32_t sctlr;
uint32_t vbar;
-   uint32_t cr;
 };
 
 struct fel_stash fel_stash __section(".data");
-- 
2.25.1

[PATCH 1/3] sunxi: armv8: fel: load only 32-bit values

[Andre Przywara]

Both the values and the MMIO addresses that we need during the 64-bit FEL
restore are smaller than 2^32, so we don't need to do any 64-bit loads.

Change the loads to only load 32 bits worth of data, that saves us some
bytes for storing the values.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv8/fel_utils.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
index 5266515f14..2fe38a1a04 100644
--- a/arch/arm/cpu/armv8/fel_utils.S
+++ b/arch/arm/cpu/armv8/fel_utils.S
@@ -39,15 +39,15 @@ ENTRY(return_to_fel)
adr x1, fel_stash_addr  // to find the fel_stash address in AA32
str w2, [x1]
 
-   ldr x0, =0xfa50392f // CPU hotplug magic
+   ldr w0, =0xfa50392f // CPU hotplug magic
 #ifdef CONFIG_MACH_SUN50I_H616
-   ldr x2, =(SUNXI_R_CPUCFG_BASE + 0x1c0)
+   ldr w2, =(SUNXI_R_CPUCFG_BASE + 0x1c0)
str w0, [x2], #0x4
 #elif CONFIG_MACH_SUN50I_H6
-   ldr x2, =(SUNXI_RTC_BASE + 0x1b8)   // BOOT_CPU_HP_FLAG_REG
+   ldr w2, =(SUNXI_RTC_BASE + 0x1b8)   // BOOT_CPU_HP_FLAG_REG
str w0, [x2], #0x4
 #else
-   ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
+   ldr w2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
str w0, [x2, #0x8]
 #endif
adr x0, back_in_32
-- 
2.25.1

[PATCH 0/3] sunxi: FEL boot fixes

[Andre Przywara]

While investigating a FEL boot failure on the OrangePi Zero 2 board
(with an H616 SoC), I stared at our FEL code and found some issues,
which this series fixes.

Unfortunately those didn't fix the H616 problem, but they are worth
having anyway.

For the records on the FEL failure: with certain H616 DRAM parameters,
newer GCCs (starting with GCC 11, GCC 10 is fine) generate an SPL binary
that doesn't properly return to the BootROM after the SPL code has
finished. This does not occur on other H616 boards using different DRAM
parameters. Staring at the disassemblies from the different compiler
versions for a while didn't show anything obvious, the best theory so
far is that it's due to a subtle timing issue in the DRAM initialisation
code. Inserting a "udelay(0);" at the beginning of
mctl_phy_read_calibration() seems to avoid the problem, but is obviously
not a proper fix. I will keep looking.

However the issues addressed in this series should be fixed, regardless.

Cheers,
Andre

Andre Przywara (3):
  sunxi: armv8: fel: load only 32-bit values
  sunxi: h616: lower SPL stack address to avoid BROM data
  sunxi: fel: drop redundant "control register" save/restore

 arch/arm/cpu/armv7/sunxi/fel_utils.S | 4 
 arch/arm/cpu/armv8/fel_utils.S   | 8 
 arch/arm/mach-sunxi/board.c  | 1 -
 include/configs/sunxi-common.h   | 2 +-
 4 files changed, 5 insertions(+), 10 deletions(-)

-- 
2.25.1

Re: PRAM and reserved memory for Linux

[Tom Rini]

On Wed, Jul 13, 2022 at 10:08:38AM +, Joakim Tjernlund wrote:

> I added CONFIG_PRAM 4 and a reserved-memory DTS node for the same space but
> now u-boot complains when booting:
>   ERROR: reserving fdt memory region failed (addr=703ff000 size=1000)
> The error is caused by arch_lmb_reserve() in arm which seem
> to reserve command line and board info ? 
> 
> If I remove the reserved-memory DTS node I don't get a reserved area in Linux,
> don't quite understand how PRAM is supposed to work?

The first likely problem is that CONFIG_PRAM stuff isn't often used
these days so might be glitchy / buggy, as you've found here.  Next, I
bet that area in arch_lmb_reserve() is about ATAGS/related and should be
guarded with CONFIG_SUPPORT_PASSING_ATAGS.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

[Tom Rini]

On Wed, Jul 13, 2022 at 03:20:46PM +0200, Alexander Dahl wrote:
> Hello Michal,
> 
> On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:
[snip]
> > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > index 76719517f5..53d91676e0 100644
> > > --- a/drivers/fpga/Kconfig
> > > +++ b/drivers/fpga/Kconfig
> > > @@ -91,4 +91,8 @@ config FPGA_ZYNQPL
> > > Enable FPGA driver for loading bitstream in BIT and BIN format
> > > on Xilinx Zynq devices.
> > > +config SYS_FPGA_CHECK_CTRLC
> > > + bool "Allow Control-C to interrupt FPGA configuration"
> > > + depends on FPGA
> > 
> > Please write help message.
> 
> Okay, I'll have to invent a new message here, if the prompt is not
> self explaining enough.  Since this is not conversion, but adding a
> new message we did not have before, should this go into a separate
> patch?

If you understand things well enough to add a line or two under "help",
that would be appreciated.  It may be a little redundant soundiing, and
if it's not long enough checkpatch might still complain (but can be
ignored).

> > And can you please remove this code from drivers/fpga/virtex2.c
> > 
> >  48 /*
> >  49  * Don't allow config cycle to be interrupted
> >  50  */
> >  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  53 #endif
> > 
> > it doesn't make any sense.
> 
> I have no hardware to test this and this is out of scope of the
> conversion patch itself.

This kind of code logic needs to be enforced in Kconfig instead with
depends lines.  We can make sure it's size-neutral.

> > And with 2/2 please also remove
> > drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK
> > 
> > Thanks,
> > Michal
> 
> I may be able to add an additional patch or two, but those are all
> FPGAs I have no experience with and I can not test those.  This would
> be more or less guessing based on code reading.  I can try next week,
> not able to do this currently.

Thanks.  It's OK to just check the logic by inspection, one of the tests
I end up running is making sure the code size doesn't change so that'll
catch bad migrations.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

[Tom Rini]

On Wed, Jul 13, 2022 at 03:11:09PM +0200, Alexander Dahl wrote:
> Hei hei,
> 
> On Wed, Jul 13, 2022 at 02:50:14PM +0200, Michal Simek wrote:
> > 
> > 
> > On 7/13/22 14:33, Alexander Dahl wrote:
> > > From: Alexander Dahl 
> > 
> > 
> > WARNING: please write a paragraph that describes the config symbol fully
> > 
> > We don't allow patches with empty commit message.
> 
> In general I would agree.  However several of Tom's patches addressing
> kconfig migration have a commit message like this:
> 
>   This converts the following to Kconfig: FOO_BAR
> 
> This is redundant to the subject saying exactly the same.  I can add
> this if you want, but I saw no sense in it.

Yes, the moveconfig.py tool adds that and it's a little redundant
sometimes, but is (a) a starting point for the times when the conversion
required a little extra work or (b) lists all the symbols when you
migrate more than one at a time.

> > > Signed-off-by: Alexander Dahl 
> > > ---
> > >   README   | 4 
> > >   configs/astro_mcf5373l_defconfig | 1 +
> > >   drivers/fpga/Kconfig | 6 ++
> > >   include/configs/astro_mcf5373l.h | 1 -
> > >   scripts/config_whitelist.txt | 1 -
> > 
> > Tom can confirm this but IIRC you don't need to remove this from this file.
> > Tom is doing sync up time to time. It is enough to do conversion only.
> 
> This was done by the script ./tools/moveconfig.py where I just hit
> enter with defaults presented.  The other Kconfig patches change
> defconfig, but not whitelist.  Seems a little inconsistent to me.  But
> I can remove that part, sure.

So, I usually run "-yC" with moveconfig.py as that gives the commit
message.  It's not a problem, really, to touch
scripts/config_whitelist.txt it just also can conflict easily.  Omitting
it makes it easier to "git am", fixing up / dropping that hunk if it
conflicts later is also fine.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] armv8: mach-k3: correct define checking for AM625/AM642 memory maps

[Tom Rini]

On Wed, Jul 13, 2022 at 04:49:36AM -0700, Matt Ranostay wrote:

> Using CONFIG_IS_ENABLED breaks accessing memory map structure when
> doing a A53 SPL build for AM625 and AM642 platforms. This is due to
> 'abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y''
> in which there is no CONFIG_SPL_SOC_K3_AM625/CONFIG_SPL_SOC_K3_AM642
> defined in the configuration.
> 
> For the A53 SPL builds on these platform to access the memory mapping
> which it will need for enabling the mmu/cache it must use #if defined(X)
> checks and not CONFIG_IS_ENABLED.
> 
> Cc: Suman Anna 
> Cc: Neha Francis 
> Signed-off-by: Matt Ranostay 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

[Michal Simek]

On 7/13/22 16:07, Alexander Dahl wrote:

Hello Michal,

On Wed, Jul 13, 2022 at 03:20:44PM +0200, Alexander Dahl wrote:

Hello Michal,

On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:



On 7/13/22 14:32, Alexander Dahl wrote:

From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.


2?
board/astro/mcf5373l/fpga.c
drivers/fpga/ACEX1K.c
drivers/fpga/virtex2.c


These are one board and two drivers.  What is your question?

Greets
Alex


I'm sorry, this was misleading.  I added some more comments below and
forgot to remove this line indicating end of message.  Considering
your answer I guess you stopped reading here?


yes I did.








Signed-off-by: Alexander Dahl 
---
   README   | 3 ---
   drivers/fpga/Kconfig | 4 
   2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/README b/README
index ff0df3797d..8c31e5c0e3 100644
--- a/README
+++ b/README
@@ -1346,9 +1346,6 @@ The following options need to be configured:
If defined, a function that provides delays in the FPGA
configuration driver.
-   CONFIG_SYS_FPGA_CHECK_CTRLC
-   Allow Control-C to interrupt FPGA configuration
-
CONFIG_SYS_FPGA_CHECK_ERROR
Check for configuration errors during FPGA bitfile
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 76719517f5..53d91676e0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -91,4 +91,8 @@ config FPGA_ZYNQPL
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Xilinx Zynq devices.
+config SYS_FPGA_CHECK_CTRLC
+   bool "Allow Control-C to interrupt FPGA configuration"
+   depends on FPGA


Please write help message.


Okay, I'll have to invent a new message here, if the prompt is not
self explaining enough.  Since this is not conversion, but adding a
new message we did not have before, should this go into a separate
patch?


I can't see any reason to have it in separate patch.
And maybe CTRL+C is better then Control-C






+
   endmenu



And can you please remove this code from drivers/fpga/virtex2.c

  48 /*
  49  * Don't allow config cycle to be interrupted
  50  */
  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
  53 #endif

it doesn't make any sense.


I have no hardware to test this and this is out of scope of the
conversion patch itself.


likely none has virtex2 around to test it. When you are converting that symbol 
it is good to fix this. Separate patch is fine to get rid of this.





And with 2/2 please also remove
drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK

Thanks,
Michal


I may be able to add an additional patch or two, but those are all
FPGAs I have no experience with and I can not test those.  This would
be more or less guessing based on code reading.  I can try next week,
not able to do this currently.

Thanks for your review.


I'll look into all this next week again.


None really has spartan2/virtex2 hw around. I personally started with Spartan3 
but didn't power it up for a lot of years. It is just about that there is no 
reason to undefine something if we have Kconfig symbol for it. Just enable it or 
disable it. That's it. No need to test it on any HW.


Thanks,
Michal

Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

[Alexander Dahl]

Hello Michal,

On Wed, Jul 13, 2022 at 03:20:44PM +0200, Alexander Dahl wrote:
> Hello Michal,
> 
> On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:
> > 
> > 
> > On 7/13/22 14:32, Alexander Dahl wrote:
> > > From: Alexander Dahl 
> > > 
> > > After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
> > > whitelist") downstream builds failed for boards setting this in
> > > include/configs/…
> > > 
> > > Two FPGA drivers consider this definition.
> > 
> > 2?
> > board/astro/mcf5373l/fpga.c
> > drivers/fpga/ACEX1K.c
> > drivers/fpga/virtex2.c
> 
> These are one board and two drivers.  What is your question?
> 
> Greets
> Alex

I'm sorry, this was misleading.  I added some more comments below and
forgot to remove this line indicating end of message.  Considering
your answer I guess you stopped reading here? 

> 
> > 
> > > 
> > > Signed-off-by: Alexander Dahl 
> > > ---
> > >   README   | 3 ---
> > >   drivers/fpga/Kconfig | 4 
> > >   2 files changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/README b/README
> > > index ff0df3797d..8c31e5c0e3 100644
> > > --- a/README
> > > +++ b/README
> > > @@ -1346,9 +1346,6 @@ The following options need to be configured:
> > >   If defined, a function that provides delays in the FPGA
> > >   configuration driver.
> > > - CONFIG_SYS_FPGA_CHECK_CTRLC
> > > - Allow Control-C to interrupt FPGA configuration
> > > -
> > >   CONFIG_SYS_FPGA_CHECK_ERROR
> > >   Check for configuration errors during FPGA bitfile
> > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > index 76719517f5..53d91676e0 100644
> > > --- a/drivers/fpga/Kconfig
> > > +++ b/drivers/fpga/Kconfig
> > > @@ -91,4 +91,8 @@ config FPGA_ZYNQPL
> > > Enable FPGA driver for loading bitstream in BIT and BIN format
> > > on Xilinx Zynq devices.
> > > +config SYS_FPGA_CHECK_CTRLC
> > > + bool "Allow Control-C to interrupt FPGA configuration"
> > > + depends on FPGA
> > 
> > Please write help message.
> 
> Okay, I'll have to invent a new message here, if the prompt is not
> self explaining enough.  Since this is not conversion, but adding a
> new message we did not have before, should this go into a separate
> patch?
> 
> > 
> > > +
> > >   endmenu
> > 
> > 
> > And can you please remove this code from drivers/fpga/virtex2.c
> > 
> >  48 /*
> >  49  * Don't allow config cycle to be interrupted
> >  50  */
> >  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  53 #endif
> > 
> > it doesn't make any sense.
> 
> I have no hardware to test this and this is out of scope of the
> conversion patch itself.
> 
> > 
> > And with 2/2 please also remove
> > drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK
> > 
> > Thanks,
> > Michal
> 
> I may be able to add an additional patch or two, but those are all
> FPGAs I have no experience with and I can not test those.  This would
> be more or less guessing based on code reading.  I can try next week,
> not able to do this currently.
> 
> Thanks for your review.

I'll look into all this next week again.

Greets
Alex

> 
> Greets
> Alex
> 
> -- 
> /"\ ASCII RIBBON | »With the first link, the chain is forged. The first
> \ / CAMPAIGN | speech censured, the first thought forbidden, the
>  X  AGAINST  | first freedom denied, chains us all irrevocably.«
> / \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)



-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature

[PATCH 3/3] net: emaclite: fix handling for IP packets with specific lengths

[Samuel Obuch]

The maximum length is capped similarly to the emaclite_send function.
Avoid integer underflow for values of ip->ip_len < 30, the minimum
length of an IP packet is 21 bytes.

Signed-off-by: Samuel Obuch 
---
 drivers/net/xilinx_emaclite.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index de7a2dee0b..21c450ec46 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -518,6 +518,8 @@ try_again:
length = ntohs(ip->ip_len);
length += ETHER_HDR_SIZE + ETH_FCS_LEN;
debug("IP Packet %x\n", length);
+   if (length > PKTSIZE)
+   length = PKTSIZE;
break;
default:
debug("Other Packet\n");
@@ -526,7 +528,7 @@ try_again:
}
 
/* Read the rest of the packet which is longer then first read */
-   if (length != first_read)
+   if (length > first_read)
xemaclite_alignedread(addr + first_read,
  etherrxbuff + first_read,
  length - first_read);
-- 
2.31.1

[PATCH 2/3] net: emaclite: fix xemaclite_alignedread/write functions

[Samuel Obuch]

Use __raw_read* and __raw_write* functions to ensure read/write
is passed to the memory-mapped regions, as non-volatile accesses
may get optimised out.

Signed-off-by: Samuel Obuch 
---
 drivers/net/xilinx_emaclite.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 5cd88e04fe..de7a2dee0b 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -113,12 +113,12 @@ static void xemaclite_alignedread(u32 *srcptr, void 
*destptr, u32 bytecount)
/* Word aligned buffer, no correction needed. */
to32ptr = (u32 *) destptr;
while (bytecount > 3) {
-   *to32ptr++ = *from32ptr++;
+   *to32ptr++ = __raw_readl(from32ptr++);
bytecount -= 4;
}
to8ptr = (u8 *) to32ptr;
 
-   alignbuffer = *from32ptr++;
+   alignbuffer = __raw_readl(from32ptr++);
from8ptr = (u8 *) 
 
for (i = 0; i < bytecount; i++)
@@ -136,8 +136,7 @@ static void xemaclite_alignedwrite(void *srcptr, u32 
*destptr, u32 bytecount)
 
from32ptr = (u32 *) srcptr;
while (bytecount > 3) {
-
-   *to32ptr++ = *from32ptr++;
+   __raw_writel(*from32ptr++, to32ptr++);
bytecount -= 4;
}
 
@@ -148,7 +147,7 @@ static void xemaclite_alignedwrite(void *srcptr, u32 
*destptr, u32 bytecount)
for (i = 0; i < bytecount; i++)
*to8ptr++ = *from8ptr++;
 
-   *to32ptr++ = alignbuffer;
+   __raw_writel(alignbuffer, to32ptr++);
 }
 
 static int wait_for_bit(const char *func, u32 *reg, const u32 mask,
-- 
2.31.1

[PATCH 1/3] net: emaclite: fix broken build

[Samuel Obuch]

Function ioremap_nocache seems to be defined only for mips and microblaze
architectures. Therefore, the function call in the emaclite driver causes
this driver to be unusable with other architectures, for example riscv.

Signed-off-by: Samuel Obuch 
---
 drivers/net/xilinx_emaclite.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 6c9f1f7c27..5cd88e04fe 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -615,8 +615,12 @@ static int emaclite_of_to_plat(struct udevice *dev)
int offset = 0;
 
pdata->iobase = dev_read_addr(dev);
+#if defined(CONFIG_MICROBLAZE) || defined(CONFIG_MIPS)
emaclite->regs = (struct emaclite_regs *)ioremap_nocache(pdata->iobase,
 0x1);
+#else
+   emaclite->regs = (struct emaclite_regs *)pdata->iobase;
+#endif
 
emaclite->phyaddr = -1;
 
-- 
2.31.1

net: emaclite: Fixes, enable driver for other archs

[Samuel Obuch]

These patches solve a few issues with the driver observed on a RISC-V platform.

Re: [PULL] Pull request for u-boot next / v2022.10 = u-boot-stm32-20220712

[Tom Rini]

On Wed, Jul 13, 2022 at 09:57:48AM +0200, Patrick DELAUNAY wrote:

> I Tom,
> 
> Please pull the STM32 related fixes for u-boot/next, v2022.10:
> u-boot-stm32-20220712
> 
> - Alignment with Linux kernel device tree v5.19 for stm32mp15 and stm32mp13
> - Add OP-TEE nodes for stm32mp13x, aligned with upstreamed OP-TEE
> - Introduce of_to_plat ops in stm32_sdmmc2 driver
> - Activate more features in stm32mp13 defconfig and support of STM32MP13x
> Rev.Y
> - Drop fastboot and stm32prog trigger gpios on STM32MP15x DHCOM board
> 
> CI status:
> https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/12721
> 
> Thanks,
> Patrick
> 
> git request-pull origin/next
> https://source.denx.de/u-boot/custodians/u-boot-stm.git/
> u-boot-stm32-20220712
> 
> 
> The following changes since commit 05a4859637567b13219efd6f1707fb236648b1b7:
> 
>   Merge branch '2022-07-08-Kconfig-migrations' into next (2022-07-08
> 18:03:08 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-stm.git/
> tags/u-boot-stm32-20220712
> 
> for you to fetch changes up to 48d9eaf6826a1816c5f9839a564ea6338da609a7:
> 
>   arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
> (2022-07-12 11:48:15 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: dts: k3-am64-ddr fix typo causing DDR4 register corruption

[Tom Rini]

On Tue, Jul 12, 2022 at 07:59:04PM -0500, Anand Gadiyar wrote:

> The entry for DDRSS_PI_321_DATA was accidentally repeated leading to the
> last few PI registers being incorrectly programmed.
> 
> Fix this.
> 
> Reported-by: Bin Liu 
> Signed-off-by: Vignesh Raghavendra 
> Signed-off-by: Anand Gadiyar 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

[Michal Simek]

On 7/13/22 15:20, Alexander Dahl wrote:

Hello Michal,

On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:



On 7/13/22 14:32, Alexander Dahl wrote:

From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.


2?
board/astro/mcf5373l/fpga.c
drivers/fpga/ACEX1K.c
drivers/fpga/virtex2.c


These are one board and two drivers.  What is your question?


The first one looks like spartan3 fpga driver in board folder (incorrect 
location). It means I consider this as 3 fpga drivers not 2.


But at the end of day just remove that sentence and that's it. Everybody sees 
what you have changed.


Thanks,
Michal

Re: [PATCH v6 07/13] FWU: STM32MP1: Add support to read boot index from backup register

[Patrick DELAUNAY]

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

The FWU Multi Bank Update feature allows the platform to boot the
firmware images from one of the partitions(banks). The first stage
bootloader(fsbl) passes the value of the boot index, i.e. the bank
from which the firmware images were booted from to U-Boot. On the
STM32MP157C-DK2 board, this value is passed through one of the SoC's
backup register. Add a function to read the boot index value from the
backup register.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrick Delaunay 
---
Changes since V5:
* Shuffled the location of the TAMP_FWU_* macros as suggested by
   Patrick

  arch/arm/mach-stm32mp/include/mach/stm32.h | 5 +
  board/st/stm32mp1/stm32mp1.c   | 8 
  include/fwu.h  | 1 +
  3 files changed, 14 insertions(+)




Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH v6 06/13] FWU: stm32mp1: Add helper functions for accessing FWU metadata

[Patrick DELAUNAY]

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

Add helper functions needed for accessing the FWU metadata which
contains information on the updatable images. These functions have
been added for the STM32MP157C-DK2 board which has the updatable
images on the uSD card, formatted as GPT partitions.

Signed-off-by: Sughosh Ganu 
---
Changes since V5:
* Change the mechanism to get the block device descriptor in
   fwu_plat_get_alt_num() due to introduction of struct
   fwu_mdata_gpt_blk_priv in the earlier patch.

  board/st/stm32mp1/stm32mp1.c | 40 
  include/fwu.h|  3 ++
  lib/fwu_updates/Makefile |  6 +++
  lib/fwu_updates/fwu_gpt.c| 88 
  4 files changed, 137 insertions(+)
  create mode 100644 lib/fwu_updates/Makefile
  create mode 100644 lib/fwu_updates/fwu_gpt.c



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH v6 05/13] stm32mp1: dk2: Add image information for capsule updates

[Patrick DELAUNAY]

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

Enabling capsule update functionality on the platform requires
populating information on the images that are to be updated using the
functionality. Do so for the DK2 board.

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

  board/st/stm32mp1/stm32mp1.c   | 19 +++
  include/configs/stm32mp15_common.h |  4 
  2 files changed, 23 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 07b1a63db7..c6bb7562f6 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -92,6 +93,16 @@ DECLARE_GLOBAL_DATA_PTR;
  #define USB_START_LOW_THRESHOLD_UV123
  #define USB_START_HIGH_THRESHOLD_UV   215
  
+#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)

+struct efi_fw_image fw_images[1];
+
+struct efi_capsule_update_info update_info = {
+   .images = fw_images,
+};
+
+u8 num_image_type_guids = ARRAY_SIZE(fw_images);
+#endif /* EFI_HAVE_CAPSULE_SUPPORT */
+
  int board_early_init_f(void)
  {
/* nothing to do, only used in SPL */
@@ -675,6 +686,14 @@ int board_init(void)
  
  	setup_led(LEDST_ON);
  
+#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)

+   if (board_is_dk2()) {
+   efi_guid_t image_type_guid = STM32MP1_DK2_FIP_IMAGE_GUID;


STM32MP15_DK2_FIP_IMAGE_GUID


+   guidcpy(_images[0].image_type_id, _type_guid);
+   fw_images[0].fw_name = u"STM32MP1-DK2-FIP";


fw_images[0].fw_name = u"STM32MP15-DK2-FIP";


+   fw_images[0].image_index = 5;
+   }
+#endif
return 0;
  }
  
diff --git a/include/configs/stm32mp15_common.h b/include/configs/stm32mp15_common.h

index 6b40cdb017..6a1ae9788d 100644
--- a/include/configs/stm32mp15_common.h
+++ b/include/configs/stm32mp15_common.h
@@ -54,6 +54,10 @@
  #define CONFIG_SYS_AUTOLOAD   "no"
  #endif
  
+#define STM32MP1_DK2_FIP_IMAGE_GUID \

+   EFI_GUID(0x19d5df83, 0x11b0, 0x457b, 0xbe, 0x2c, \
+0x75, 0x59, 0xc1, 0x31, 0x42, 0xa5)
+


#define STM32MP15_DK2_FIP_IMAGE_GUID \



  
/*/
  #ifdef CONFIG_DISTRO_DEFAULTS
  
/*/



with the modification s/STM32MP1/STM32MP15/

to avoid confusion with STM32MP13


Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

[Alexander Dahl]

Hello Michal,

On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:
> 
> 
> On 7/13/22 14:32, Alexander Dahl wrote:
> > From: Alexander Dahl 
> > 
> > After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
> > whitelist") downstream builds failed for boards setting this in
> > include/configs/…
> > 
> > Two FPGA drivers consider this definition.
> 
> 2?
> board/astro/mcf5373l/fpga.c
> drivers/fpga/ACEX1K.c
> drivers/fpga/virtex2.c

These are one board and two drivers.  What is your question?

Greets
Alex

> 
> > 
> > Signed-off-by: Alexander Dahl 
> > ---
> >   README   | 3 ---
> >   drivers/fpga/Kconfig | 4 
> >   2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/README b/README
> > index ff0df3797d..8c31e5c0e3 100644
> > --- a/README
> > +++ b/README
> > @@ -1346,9 +1346,6 @@ The following options need to be configured:
> > If defined, a function that provides delays in the FPGA
> > configuration driver.
> > -   CONFIG_SYS_FPGA_CHECK_CTRLC
> > -   Allow Control-C to interrupt FPGA configuration
> > -
> > CONFIG_SYS_FPGA_CHECK_ERROR
> > Check for configuration errors during FPGA bitfile
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index 76719517f5..53d91676e0 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -91,4 +91,8 @@ config FPGA_ZYNQPL
> >   Enable FPGA driver for loading bitstream in BIT and BIN format
> >   on Xilinx Zynq devices.
> > +config SYS_FPGA_CHECK_CTRLC
> > +   bool "Allow Control-C to interrupt FPGA configuration"
> > +   depends on FPGA
> 
> Please write help message.

Okay, I'll have to invent a new message here, if the prompt is not
self explaining enough.  Since this is not conversion, but adding a
new message we did not have before, should this go into a separate
patch?

> 
> > +
> >   endmenu
> 
> 
> And can you please remove this code from drivers/fpga/virtex2.c
> 
>  48 /*
>  49  * Don't allow config cycle to be interrupted
>  50  */
>  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
>  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
>  53 #endif
> 
> it doesn't make any sense.

I have no hardware to test this and this is out of scope of the
conversion patch itself.

> 
> And with 2/2 please also remove
> drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
> drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
> drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK
> 
> Thanks,
> Michal

I may be able to add an additional patch or two, but those are all
FPGAs I have no experience with and I can not test those.  This would
be more or less guessing based on code reading.  I can try next week,
not able to do this currently.

Thanks for your review.

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature

Re: [PATCH 3/3] fdt: introduce apply_all command

[Andre Przywara]

On Tue, 12 Jul 2022 04:58:35 -0600
Simon Glass  wrote:

Hi Simon,

many thanks for having a look!

> On Tue, 5 Jul 2022 at 11:14, Andre Przywara  wrote:
> >
> > Explicitly specifying the exact filenames of devicetree overlays files
> > on a U-Boot command line can be quite tedious for users, especially
> > when it should be made persistent for every boot.
> >
> > To simplify the task of applying (custom) DT overlays, introduce a
> > "fdt apply-all" subcommand, that iterates a given directory in any
> > supported filesystem, and tries to apply every .dtbo file found it
> > there.
> >
> > This allows users to simply drop a DT overlay file into a magic
> > directory, and it will be applied on the next boot automatically,
> > by the virtue of just a generic U-Boot command call.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  cmd/fdt.c | 89 ++-
> >  1 file changed, 88 insertions(+), 1 deletion(-)  
> 
> This looks OK, but can you please add a test (see test/dm/acpi.c for
> example) and doc/usage/cmd file?

Is that supposed to run inside the sandbox? I briefly tested this there,
only to realise that the sandbox' hostfs does not support the directory
operations (fs_opendir_unsupported). I haven't thought about it too much,
nor do I have much experience with U-Boot's test framework, but this sounds
like a problem?

> Also, apply_all is a bit annoying as we try to allow command
> completion and abbreviations to work. Given that the args are
> different I don't think a -d (for dir) flag makes sense.
> 
> Perhaps 'fdt fsapply' ?

Yeah, I wasn't happy with that name either, but couldn't come up with a
better name. "fsapply" seems to be a nice alternative, I will go with that!

Cheers,
Andre

> 
> Regards,
> Simon
> 
> 
> >
> > diff --git a/cmd/fdt.c b/cmd/fdt.c
> > index d6878c96f1..dc80e13c3d 100644
> > --- a/cmd/fdt.c
> > +++ b/cmd/fdt.c
> > @@ -12,12 +12,14 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define MAX_LEVEL  32  /* how deeply nested we will go */
> >  #define SCRATCHPAD 1024/* bytes of scratchpad memory */
> > @@ -107,6 +109,81 @@ static int fdt_get_header_value(int argc, char *const 
> > argv[])
> > return CMD_RET_FAILURE;
> >  }
> >
> > +#ifdef CONFIG_OF_LIBFDT_OVERLAY
> > +static int apply_all_overlays(const char *ifname, const char *dev_part_str,
> > + const char *dirname)
> > +{
> > +   unsigned long addr;
> > +   struct fdt_header *dtbo;
> > +   const char *addr_str;
> > +   struct fs_dir_stream *dirs;
> > +   struct fs_dirent *dent;
> > +   char fname[256], *name_beg;
> > +   int ret;
> > +
> > +   addr_str = env_get("fdtoverlay_addr_r");
> > +   if (!addr_str) {
> > +   printf("Invalid fdtoverlay_addr_r for loading overlays\n");
> > +   return CMD_RET_FAILURE;
> > +   }
> > +   addr = hextoul(addr_str, NULL);
> > +
> > +   ret = fs_set_blk_dev(ifname, dev_part_str, FS_TYPE_ANY);
> > +   if (ret)
> > +   return CMD_RET_FAILURE;
> > +
> > +   if (!dirname)
> > +   dirname = "/";
> > +   dirs = fs_opendir(dirname);
> > +   if (!dirs) {
> > +   printf("Cannot find directory \"%s\"\n", dirname);
> > +   return CMD_RET_FAILURE;
> > +   }
> > +
> > +   strcpy(fname, dirname);
> > +   name_beg = strchr(fname, 0);
> > +   if (name_beg[-1] != '/')
> > +   *name_beg++ = '/';
> > +
> > +   dtbo = map_sysmem(addr, 0);
> > +   while ((dent = fs_readdir(dirs))) {
> > +   loff_t size = 0;
> > +
> > +   if (dent->type == FS_DT_DIR)
> > +   continue;
> > +
> > +   if (strcmp(dent->name + strlen(dent->name) - 5, ".dtbo"))
> > +   continue;
> > +
> > +   printf("%s: ", dent->name);
> > +   strcpy(name_beg, dent->name);
> > +   fs_set_blk_dev(ifname, dev_part_str, FS_TYPE_ANY);
> > +   if (dent->size > SZ_2M)
> > +   size = SZ_2M;
> > +   else
> > +   size = dent->size;
> > +   ret = fs_read(fname, addr, 0, size, );
> > +   if (ret) {
> > +   printf("  errno: %d\n", ret);
> > +   continue;
> > +   }
> > +   if (!fdt_valid()) {
> > +   /* fdt_valid() clears the pointer upon failure */
> > +   dtbo = map_sysmem(addr, 0);
> > +   continue;
> > +   }
> > +
> > +   if (fdt_overlay_apply_verbose(working_fdt, dtbo) == 0)
> > +   printf("applied\n");
> > +   }
> > +   unmap_sysmem(dtbo);
> > +
> > +   fs_closedir(dirs);
> > +
> > 

Re: [PATCH v6 03/13] FWU: Add FWU metadata access driver for GPT partitioned block devices

[Patrick DELAUNAY]

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, on a separate
partition. Add a driver for reading from and writing to the metadata
when the updatable images and the metadata are stored on a block
device which is formated with GPT based partition scheme.

Signed-off-by: Sughosh Ganu 
---
Changes since V5:
* Changed the logic to store the GPT partitioned block device through
   a priv structure as suggested by Patrick
* Used dev_read_prop() to get the phandle_p instead of
   ofnode_get_property() used earlier as suggested by Patrick
* Make relevant functions static as suggested by Etienne

  drivers/fwu-mdata/Kconfig |   9 +
  drivers/fwu-mdata/Makefile|   1 +
  drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 408 ++
  include/fwu.h |   5 +
  4 files changed, 423 insertions(+)
  create mode 100644 drivers/fwu-mdata/fwu_mdata_gpt_blk.c

diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
index d6a21c8e19..d5edef19d6 100644
--- a/drivers/fwu-mdata/Kconfig
+++ b/drivers/fwu-mdata/Kconfig
@@ -5,3 +5,12 @@ config DM_FWU_MDATA
  Enable support for accessing FWU Metadata partitions. The
  FWU Metadata partitions reside on the same storage device
  which contains the other FWU updatable firmware images.
+
+config FWU_MDATA_GPT_BLK
+   bool "FWU Metadata access for GPT partitioned Block devices"
+   select PARTITION_TYPE_GUID
+   select PARTITION_UUIDS
+   depends on DM && HAVE_BLOCK_DEVICE && EFI_PARTITION
+   help
+ Enable support for accessing FWU Metadata on GPT partitioned
+ block devices.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
index e53a8c9983..313049f67a 100644
--- a/drivers/fwu-mdata/Makefile
+++ b/drivers/fwu-mdata/Makefile
@@ -4,3 +4,4 @@
  #
  
  obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o

+obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o
diff --git a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c 
b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
new file mode 100644
index 00..d904c9492d
--- /dev/null
+++ b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */


#define LOG_CATEGORY UCLASS_FWU_MDATA


+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define PRIMARY_PART   BIT(0)
+#define SECONDARY_PART BIT(1)
+#define BOTH_PARTS (PRIMARY_PART | SECONDARY_PART)
+
+#define MDATA_READ BIT(0)
+#define MDATA_WRITEBIT(1)
+


(...)



+
+static const struct fwu_mdata_ops fwu_gpt_blk_ops = {
+   .mdata_check = fwu_gpt_mdata_check,
+   .get_mdata = fwu_gpt_get_mdata,
+   .update_mdata = fwu_gpt_update_mdata,
+};UCLASS_FWU_MDATA

+
+static const struct udevice_id fwu_mdata_ids[] = {
+   { .compatible = "u-boot,fwu-mdata-gpt" },
+   { }
+};
+
+U_BOOT_DRIVER(fwu_mdata_gpt_blk) = {
+   .name   = "fwu-mdata-gpt-blk",
+   .id = UCLASS_FWU_MDATA,
+   .of_match   = fwu_mdata_ids,
+   .ops= _gpt_blk_ops,
+   .probe  = fwu_mdata_gpt_blk_probe,
+   .priv_auto  = sizeof(struct fwu_mdata_gpt_blk_priv),
+};
diff --git a/include/fwu.h b/include/fwu.h
index e03cfff800..8259c75d12 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -14,6 +14,10 @@
  struct fwu_mdata;
  struct udevice;
  
+struct fwu_mdata_gpt_blk_priv {

+   struct udevice *blk_dev;
+};
+


NITS: really needed in .h file => private, only used by driver in .c ?



  /**
   * @mdata_check: check the validity of the FWU metadata partitions
   * @get_mdata() - Get a FWU metadata copy
@@ -39,6 +43,7 @@ int fwu_get_active_index(u32 *active_idx);
  int fwu_update_active_index(u32 active_idx);
  int fwu_get_image_alt_num(efi_guid_t *image_type_id, u32 update_bank,
  int *alt_num);
+int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part);
  int fwu_mdata_check(void);
  int fwu_revert_boot_index(void);
  int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);



with the minor modification (LOG_CATEGORY)


Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH v6 02/13] FWU: Add FWU metadata structure and driver for accessing metadata

[Patrick DELAUNAY]

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, which is stored on
a dedicated partition. Add the metadata structure, and a driver model
uclass which provides functions to access the metadata. These are
generic API's, and implementations can be added based on parameters
like how the metadata partition is accessed and what type of storage
device houses the metadata.

Signed-off-by: Sughosh Ganu 
---
Changes since V5:
* Change the parameter to the function fwu_plat_get_alt_num to pass
   the FWU udevice pointer instead of passing the metadata device
   directly.

  drivers/Kconfig  |   2 +
  drivers/Makefile |   1 +
  drivers/fwu-mdata/Kconfig|   7 +
  drivers/fwu-mdata/Makefile   |   6 +
  drivers/fwu-mdata/fwu-mdata-uclass.c | 458 +++
  include/dm/uclass-id.h   |   1 +
  include/fwu.h|  49 +++
  include/fwu_mdata.h  |  67 
  8 files changed, 591 insertions(+)
  create mode 100644 drivers/fwu-mdata/Kconfig
  create mode 100644 drivers/fwu-mdata/Makefile
  create mode 100644 drivers/fwu-mdata/fwu-mdata-uclass.c
  create mode 100644 include/fwu.h
  create mode 100644 include/fwu_mdata.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index b26ca8cf70..adc6079ecf 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
  
  source "drivers/fpga/Kconfig"
  
+source "drivers/fwu-mdata/Kconfig"

+
  source "drivers/gpio/Kconfig"
  
  source "drivers/hwspinlock/Kconfig"

diff --git a/drivers/Makefile b/drivers/Makefile
index 67c8af7442..901150bb35 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -83,6 +83,7 @@ obj-y += cache/
  obj-$(CONFIG_CPU) += cpu/
  obj-y += crypto/
  obj-$(CONFIG_FASTBOOT) += fastboot/
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
  obj-y += misc/
  obj-$(CONFIG_MMC) += mmc/
  obj-$(CONFIG_NVME) += nvme/
diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
new file mode 100644
index 00..d6a21c8e19
--- /dev/null
+++ b/drivers/fwu-mdata/Kconfig
@@ -0,0 +1,7 @@
+config DM_FWU_MDATA
+   bool "Driver support for accessing FWU Metadata"
+   depends on DM
+   help
+ Enable support for accessing FWU Metadata partitions. The
+ FWU Metadata partitions reside on the same storage device
+ which contains the other FWU updatable firmware images.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
new file mode 100644
index 00..e53a8c9983
--- /dev/null
+++ b/drivers/fwu-mdata/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (c) 2022, Linaro Limited
+#
+
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
b/drivers/fwu-mdata/fwu-mdata-uclass.c
new file mode 100644
index 00..2092fcfc23
--- /dev/null
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */
+


#define LOG_CATEGORY UCLASS_FWU_MDATA



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define IMAGE_ACCEPT_SET   BIT(0)
+#define IMAGE_ACCEPT_CLEAR BIT(1)
+
+static int fwu_get_dev_ops(struct udevice **dev,
+  const struct fwu_mdata_ops **ops)
+{
+   int ret;
+
+   ret = uclass_get_device(UCLASS_FWU_MDATA, 0, dev);
+   if (ret) {
+   log_debug("Cannot find fwu device\n");
+   return ret;
+   }
+
+   if ((*ops = device_get_ops(*dev)) == NULL) {
+   log_debug("Cannot get fwu device ops\n");
+   return -ENOSYS;
+   }
+
+   return 0;
+}
+


(...)

with this minor update

Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

[Alexander Dahl]

Hei hei,

On Wed, Jul 13, 2022 at 02:50:14PM +0200, Michal Simek wrote:
> 
> 
> On 7/13/22 14:33, Alexander Dahl wrote:
> > From: Alexander Dahl 
> 
> 
> WARNING: please write a paragraph that describes the config symbol fully
> 
> We don't allow patches with empty commit message.

In general I would agree.  However several of Tom's patches addressing
kconfig migration have a commit message like this:

  This converts the following to Kconfig: FOO_BAR

This is redundant to the subject saying exactly the same.  I can add
this if you want, but I saw no sense in it.

> 
> 
> > 
> > Signed-off-by: Alexander Dahl 
> > ---
> >   README   | 4 
> >   configs/astro_mcf5373l_defconfig | 1 +
> >   drivers/fpga/Kconfig | 6 ++
> >   include/configs/astro_mcf5373l.h | 1 -
> >   scripts/config_whitelist.txt | 1 -
> 
> Tom can confirm this but IIRC you don't need to remove this from this file.
> Tom is doing sync up time to time. It is enough to do conversion only.

This was done by the script ./tools/moveconfig.py where I just hit
enter with defaults presented.  The other Kconfig patches change
defconfig, but not whitelist.  Seems a little inconsistent to me.  But
I can remove that part, sure.

Greets
Alex

> 
> M

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

[Michal Simek]

On 7/13/22 14:32, Alexander Dahl wrote:

From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.


2?
board/astro/mcf5373l/fpga.c
drivers/fpga/ACEX1K.c
drivers/fpga/virtex2.c



Signed-off-by: Alexander Dahl 
---
  README   | 3 ---
  drivers/fpga/Kconfig | 4 
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/README b/README
index ff0df3797d..8c31e5c0e3 100644
--- a/README
+++ b/README
@@ -1346,9 +1346,6 @@ The following options need to be configured:
If defined, a function that provides delays in the FPGA
configuration driver.
  
-		CONFIG_SYS_FPGA_CHECK_CTRLC

-   Allow Control-C to interrupt FPGA configuration
-
CONFIG_SYS_FPGA_CHECK_ERROR
  
  		Check for configuration errors during FPGA bitfile

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 76719517f5..53d91676e0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -91,4 +91,8 @@ config FPGA_ZYNQPL
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Xilinx Zynq devices.
  
+config SYS_FPGA_CHECK_CTRLC

+   bool "Allow Control-C to interrupt FPGA configuration"
+   depends on FPGA


Please write help message.


+
  endmenu



And can you please remove this code from drivers/fpga/virtex2.c

 48 /*
 49  * Don't allow config cycle to be interrupted
 50  */
 51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
 52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
 53 #endif

it doesn't make any sense.

And with 2/2 please also remove
drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK

Thanks,
Michal

Re: [PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

[Michal Simek]

On 7/13/22 14:33, Alexander Dahl wrote:

From: Alexander Dahl 



WARNING: please write a paragraph that describes the config symbol fully

We don't allow patches with empty commit message.




Signed-off-by: Alexander Dahl 
---
  README   | 4 
  configs/astro_mcf5373l_defconfig | 1 +
  drivers/fpga/Kconfig | 6 ++
  include/configs/astro_mcf5373l.h | 1 -
  scripts/config_whitelist.txt | 1 -


Tom can confirm this but IIRC you don't need to remove this from this file.
Tom is doing sync up time to time. It is enough to do conversion only.

M

[PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

[Alexander Dahl]

From: Alexander Dahl 

Signed-off-by: Alexander Dahl 
---
 README   | 4 
 configs/astro_mcf5373l_defconfig | 1 +
 drivers/fpga/Kconfig | 6 ++
 include/configs/astro_mcf5373l.h | 1 -
 scripts/config_whitelist.txt | 1 -
 5 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/README b/README
index 8c31e5c0e3..2c4bde0b32 100644
--- a/README
+++ b/README
@@ -1330,10 +1330,6 @@ The following options need to be configured:
Enables support for FPGA family.
(SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX)
 
-   CONFIG_SYS_FPGA_PROG_FEEDBACK
-
-   Enable printing of hash marks during FPGA configuration.
-
CONFIG_SYS_FPGA_CHECK_BUSY
 
Enable checks on FPGA configuration interface busy
diff --git a/configs/astro_mcf5373l_defconfig b/configs/astro_mcf5373l_defconfig
index 3a44c7e8ec..9f5cb8702c 100644
--- a/configs/astro_mcf5373l_defconfig
+++ b/configs/astro_mcf5373l_defconfig
@@ -33,6 +33,7 @@ CONFIG_FPGA_ALTERA=y
 CONFIG_FPGA_CYCLON2=y
 CONFIG_FPGA_XILINX=y
 CONFIG_FPGA_SPARTAN3=y
+CONFIG_SYS_FPGA_PROG_FEEDBACK=y
 CONFIG_SYS_I2C_LEGACY=y
 CONFIG_SYS_I2C_FSL=y
 CONFIG_SYS_FSL_I2C_OFFSET=0x58000
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 53d91676e0..e152ea14dc 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -95,4 +95,10 @@ config SYS_FPGA_CHECK_CTRLC
bool "Allow Control-C to interrupt FPGA configuration"
depends on FPGA
 
+config SYS_FPGA_PROG_FEEDBACK
+   bool "Progress output during FPGA configuration"
+   depends on FPGA
+   help
+ Enable printing of hash marks during FPGA configuration.
+
 endmenu
diff --git a/include/configs/astro_mcf5373l.h b/include/configs/astro_mcf5373l.h
index a8265e961a..da4d49741d 100644
--- a/include/configs/astro_mcf5373l.h
+++ b/include/configs/astro_mcf5373l.h
@@ -131,7 +131,6 @@
  * it needs non-blocking CFI routines.
  */
 
-#define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_WAIT   1000
 
 /* End of user parameters to be customized */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index efc2f3bcf7..fc07c5d257 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -743,7 +743,6 @@ CONFIG_SYS_FPGA_FTIM0
 CONFIG_SYS_FPGA_FTIM1
 CONFIG_SYS_FPGA_FTIM2
 CONFIG_SYS_FPGA_FTIM3
-CONFIG_SYS_FPGA_PROG_FEEDBACK
 CONFIG_SYS_FPGA_SIZE
 CONFIG_SYS_FPGA_WAIT
 CONFIG_SYS_FSL_BMAN_ADDR
-- 
2.30.2

[PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

[Alexander Dahl]

From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.

Signed-off-by: Alexander Dahl 
---
 README   | 3 ---
 drivers/fpga/Kconfig | 4 
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/README b/README
index ff0df3797d..8c31e5c0e3 100644
--- a/README
+++ b/README
@@ -1346,9 +1346,6 @@ The following options need to be configured:
If defined, a function that provides delays in the FPGA
configuration driver.
 
-   CONFIG_SYS_FPGA_CHECK_CTRLC
-   Allow Control-C to interrupt FPGA configuration
-
CONFIG_SYS_FPGA_CHECK_ERROR
 
Check for configuration errors during FPGA bitfile
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 76719517f5..53d91676e0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -91,4 +91,8 @@ config FPGA_ZYNQPL
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Xilinx Zynq devices.
 
+config SYS_FPGA_CHECK_CTRLC
+   bool "Allow Control-C to interrupt FPGA configuration"
+   depends on FPGA
+
 endmenu
-- 
2.30.2

[PATCH v2 0/2] fpga: Convert some options to Kconfig

[Alexander Dahl]

Hei hei,

rebased this on recent master.  One patch dropped.  See changelog below.

Greets
Alex

(implicit) v1 -> v2:
  - dropped patch 3, same kconfig symbol addressed with commit
60d45642fe0673514aced37e6cc95d4f0fe02a19 ("fpga: Remove
CONFIG_FPGA_COUNT")

Cc: Wolfgang Wegner 
Cc: Michal Simek 
Cc: Simon Glass 
Cc: Stefan Roese 
Cc: Patrick Delaunay 
Cc: "Marek Behún" 

Alexander Dahl (2):
  fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig
  fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

 README   |  7 ---
 configs/astro_mcf5373l_defconfig |  1 +
 drivers/fpga/Kconfig | 10 ++
 include/configs/astro_mcf5373l.h |  1 -
 scripts/config_whitelist.txt |  1 -
 5 files changed, 11 insertions(+), 9 deletions(-)


base-commit: 36b661dc919da318c163a45f4a220d2e3d9db608
-- 
2.30.2

[PATCH 2/3] fdt: Start a test for the fdt command

[Simon Glass]

Add a basic test of the 'fdt addr' command, to kick things off.

This includes a new convenience function to run a command from a printf()
string.

Signed-off-by: Simon Glass 
---

 common/cli.c  |  15 +
 include/command.h |  10 +++
 include/test/suites.h |   1 +
 test/cmd/Makefile |   1 +
 test/cmd/fdt.c| 142 ++
 test/cmd_ut.c |   6 ++
 6 files changed, 175 insertions(+)
 create mode 100644 test/cmd/fdt.c

diff --git a/common/cli.c b/common/cli.c
index a7e3d84b68f..a47d6a3f2b4 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -126,6 +126,21 @@ int run_command_list(const char *cmd, int len, int flag)
return rcode;
 }
 
+int run_commandf(const char *fmt, ...)
+{
+   va_list args;
+   char cmd[128];
+   int i, ret;
+
+   va_start(args, fmt);
+   i = vsnprintf(cmd, sizeof(cmd), fmt, args);
+   va_end(args);
+
+   ret = run_command(cmd, 0);
+
+   return ret;
+}
+
 //
 
 #if defined(CONFIG_CMD_RUN)
diff --git a/include/command.h b/include/command.h
index 0cf12fde396..44c91f655d4 100644
--- a/include/command.h
+++ b/include/command.h
@@ -257,6 +257,16 @@ int board_run_command(const char *cmdline);
 int run_command(const char *cmd, int flag);
 int run_command_repeatable(const char *cmd, int flag);
 
+/**
+ * run_commandf() - Run a command created by a format string
+ *
+ * The command cannot be larger than 127 characters
+ *
+ * @fmt: printf() format string
+ * @...: Arguments to use (flag is always 0)
+ */
+int run_commandf(const char *fmt, ...);
+
 /**
  * Run a list of commands separated by ; or even \0
  *
diff --git a/include/test/suites.h b/include/test/suites.h
index ddb8827fdb1..44025ccecd6 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -38,6 +38,7 @@ int do_ut_compression(struct cmd_tbl *cmdtp, int flag, int 
argc,
  char *const argv[]);
 int do_ut_dm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_env(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
+int do_ut_fdt(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
diff --git a/test/cmd/Makefile b/test/cmd/Makefile
index 4b2d7df0d2e..c331757425e 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_CONSOLE_RECORD) += test_echo.o
 endif
 obj-y += mem.o
 obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
+obj-$(CONFIG_CMD_FDT) += fdt.o
 obj-$(CONFIG_CMD_LOADM) += loadm.o
 obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o
 obj-$(CONFIG_CMD_PINMUX) += pinmux.o
diff --git a/test/cmd/fdt.c b/test/cmd/fdt.c
new file mode 100644
index 000..100a7ef5ebf
--- /dev/null
+++ b/test/cmd/fdt.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Tests for fdt command
+ *
+ * Copyright 2022 Google LLCmap_to_sysmem(fdt));
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Declare a new fdt test */
+#define FDT_TEST(_name, _flags)UNIT_TEST(_name, _flags, fdt_test)
+
+/**
+ * make_test_fdt() - Create an FDT with just a root node
+ *
+ * The size is set to the minimum needed
+ *
+ * @uts: Test state
+ * @fdt: Place to write FDT
+ * @size: Maximum size of space for fdt
+ */
+static int make_test_fdt(struct unit_test_state *uts, void *fdt, int size)
+{
+   ut_assertok(fdt_create(fdt, size));
+   ut_assertok(fdt_finish_reservemap(fdt));
+   ut_assert(fdt_begin_node(fdt, "") >= 0);
+   ut_assertok(fdt_end_node(fdt));
+   ut_assertok(fdt_finish(fdt));
+
+   return 0;
+}
+
+/* Test 'fdt addr' getting/setting address */
+static int fdt_test_addr(struct unit_test_state *uts)
+{
+   const void *fdt_blob, *new_fdt;
+   char fdt[256];
+   ulong addr;
+   int ret;
+
+   ut_assertok(console_record_reset_enable());
+   ut_assertok(run_command("fdt addr -c", 0));
+   ut_assert_nextline("Control fdt: %08lx",
+  (ulong)map_to_sysmem(gd->fdt_blob));
+   ut_assertok(ut_check_console_end(uts));
+
+   /* The working fdt is not set, so this should fail */
+   set_working_fdt_addr(0);
+   ut_asserteq(CMD_RET_FAILURE, run_command("fdt addr", 0));
+   ut_assert_nextline("libfdt fdt_check_header(): FDT_ERR_BADMAGIC");
+   ut_assertok(ut_check_console_end(uts));
+
+   /* Set up a working FDT and try again */
+   ut_assertok(make_test_fdt(uts, fdt, sizeof(fdt)));
+   addr = map_to_sysmem(fdt);
+   set_working_fdt_addr(addr);
+   ut_assertok(run_command("fdt addr", 0));
+   ut_assert_nextline("Working fdt: %08lx", (ulong)map_to_sysmem(fdt));
+   

[PATCH 3/3] doc: Make a start on docs for fdt command

[Simon Glass]

Add some information about the 'fdt addr' subcommand, to get things
started.

Signed-off-by: Simon Glass 
---

 doc/usage/cmd/fdt.rst | 69 +++
 doc/usage/index.rst   |  1 +
 2 files changed, 70 insertions(+)
 create mode 100644 doc/usage/cmd/fdt.rst

diff --git a/doc/usage/cmd/fdt.rst b/doc/usage/cmd/fdt.rst
new file mode 100644
index 000..07fed732e45
--- /dev/null
+++ b/doc/usage/cmd/fdt.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+fdt command
+===
+
+Synopis
+---
+
+::
+
+fdt addr [-cq] [addr [len]]
+
+Description
+---
+
+The fdt command provides access to flat device tree blobs in memory. It has
+many subcommands, some of which are not documented here.
+
+Flags:
+
+-c
+Select the control FDT (otherwise the working FDT is used).
+-q
+Don't display errors
+
+The control FDT is the one used by U-Boot itself to control various features,
+including driver model. This should only be changed if you really know what you
+are doing, since once U-Boot starts it maintains pointers into the FDT from the
+various driver model data structures.
+
+The working FDT is the one passed to the Operating System when booting. This
+can be freely modified, so far as U-Boot is concerned, since it does not affect
+U-Boot's operation.
+
+fdt addr
+
+
+With no arguments, this shows the address of the current working or control
+FDT.
+
+If the `addr` argument is provided, then this sets the address of the working 
or
+control FDT to the provided address.
+
+If the `len` argument is provided, then the device tree is expanded to that
+size. This can be used to make space for more nodes and properties. It is
+assumed that there is enough space in memory for this expansion.
+
+Example
+---
+
+Get the control address and copy that FDT to free memory::
+
+=> fdt addr -c
+Control fdt: 0aff9fd0
+=> cp.b 0aff9fd0 1 1
+=> md 1 4
+0001: edfe0dd0 5b3d 7800 7c27  ..=[...x..'|
+
+The second word shows the size of the FDT. Now set the working FDT to that
+address and expand it to 0xf000 in size::
+
+=> fdt addr 1 f000
+=> md 1 4
+0001: edfe0dd0 00f0 7800 7c27  ...x..'|
+
+Return value
+
+
+The return value $? indicates whether the command succeeded.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 8b98629d6bf..16a3db5c000 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -43,6 +43,7 @@ Shell commands
cmd/false
cmd/fatinfo
cmd/fatload
+   cmd/fdt
cmd/for
cmd/load
cmd/loadm
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 1/3] addrmap: Support on sandbox

[Simon Glass]

Update this feature so that it works on sandbox, using a basic identity
mapping. This allows us to run the 'ut addrmap' test.

Also fix up the test to use the correct macros to access the linker
list, so that the 'ut addrmap' command actually works.

Signed-off-by: Simon Glass 
---

 board/sandbox/sandbox.c   | 9 +
 configs/sandbox_defconfig | 1 +
 include/addr_map.h| 2 ++
 lib/addr_map.c| 5 +++--
 test/cmd/addrmap.c| 5 ++---
 5 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index e054f300c4a..ca9a2ca5b17 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -155,3 +156,11 @@ int board_late_init(void)
return 0;
 }
 #endif
+
+int init_addr_map(void)
+{
+   if (IS_ENABLED(CONFIG_ADDR_MAP))
+   addrmap_set_entry(0, 0, CONFIG_SYS_SDRAM_SIZE, 0);
+
+   return 0;
+}
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 572cf8edd8b..55c014e1c45 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -313,6 +313,7 @@ CONFIG_WDT_GPIO=y
 CONFIG_WDT_SANDBOX=y
 CONFIG_FS_CBFS=y
 CONFIG_FS_CRAMFS=y
+CONFIG_ADDR_MAP=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ECDSA=y
 CONFIG_ECDSA_VERIFY=y
diff --git a/include/addr_map.h b/include/addr_map.h
index 55d3a6a165a..db3712b5d30 100644
--- a/include/addr_map.h
+++ b/include/addr_map.h
@@ -14,7 +14,9 @@ struct addrmap {
unsigned long vaddr;
 };
 
+#ifdef CONFIG_ADDR_MAP
 extern struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
+#endif
 
 phys_addr_t addrmap_virt_to_phys(void *vaddr);
 void *addrmap_phys_to_virt(phys_addr_t paddr);
diff --git a/lib/addr_map.c b/lib/addr_map.c
index fb2ef400078..9b3e0a544e4 100644
--- a/lib/addr_map.c
+++ b/lib/addr_map.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
 
@@ -18,7 +19,7 @@ phys_addr_t addrmap_virt_to_phys(void * vaddr)
if (address_map[i].size == 0)
continue;
 
-   addr = (u64)((u32)vaddr);
+   addr = map_to_sysmem(vaddr);
base = (u64)(address_map[i].vaddr);
upper = (u64)(address_map[i].size) + base - 1;
 
@@ -48,7 +49,7 @@ void *addrmap_phys_to_virt(phys_addr_t paddr)
 
offset = address_map[i].paddr - address_map[i].vaddr;
 
-   return (void *)(unsigned long)(paddr - offset);
+   return map_sysmem(paddr - offset, 0);
}
}
 
diff --git a/test/cmd/addrmap.c b/test/cmd/addrmap.c
index fb744485bbf..1eb5955db17 100644
--- a/test/cmd/addrmap.c
+++ b/test/cmd/addrmap.c
@@ -29,9 +29,8 @@ ADDRMAP_TEST(addrmap_test_basic, UT_TESTF_CONSOLE_REC);
 
 int do_ut_addrmap(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
argv[])
 {
-   struct unit_test *tests = ll_entry_start(struct unit_test,
-addrmap_test);
-   const int n_ents = ll_entry_count(struct unit_test, addrmap_test);
+   struct unit_test *tests = UNIT_TEST_SUITE_START(addrmap_test);
+   const int n_ents = UNIT_TEST_SUITE_COUNT(addrmap_test);
 
return cmd_ut_category("cmd_addrmap", "cmd_addrmap_", tests, n_ents,
   argc, argv);
-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH 0/3] Test and docs for fdt command

[Simon Glass]

This was required by Marek to provide a starting point for documentation
and a test for a new subcommand.


Simon Glass (3):
  addrmap: Support on sandbox
  fdt: Start a test for the fdt command
  doc: Make a start on docs for fdt command

 board/sandbox/sandbox.c   |   9 +++
 common/cli.c  |  15 
 configs/sandbox_defconfig |   1 +
 doc/usage/cmd/fdt.rst |  69 ++
 doc/usage/index.rst   |   1 +
 include/addr_map.h|   2 +
 include/command.h |  10 +++
 include/test/suites.h |   1 +
 lib/addr_map.c|   5 +-
 test/cmd/Makefile |   1 +
 test/cmd/addrmap.c|   5 +-
 test/cmd/fdt.c| 142 ++
 test/cmd_ut.c |   6 ++
 13 files changed, 262 insertions(+), 5 deletions(-)
 create mode 100644 doc/usage/cmd/fdt.rst
 create mode 100644 test/cmd/fdt.c

-- 
2.37.0.144.g8ac04bfd2-goog

[PATCH] armv8: mach-k3: correct define checking for AM625/AM642 memory maps

[Matt Ranostay]

Using CONFIG_IS_ENABLED breaks accessing memory map structure when
doing a A53 SPL build for AM625 and AM642 platforms. This is due to
'abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y''
in which there is no CONFIG_SPL_SOC_K3_AM625/CONFIG_SPL_SOC_K3_AM642
defined in the configuration.

For the A53 SPL builds on these platform to access the memory mapping
which it will need for enabling the mmu/cache it must use #if defined(X)
checks and not CONFIG_IS_ENABLED.

Cc: Suman Anna 
Cc: Neha Francis 
Signed-off-by: Matt Ranostay 
---
 arch/arm/mach-k3/arm64-mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 12cb89335ad..c43c07ce7fa 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -222,7 +222,7 @@ struct mm_region *mem_map = j721s2_mem_map;
 
 #endif /* CONFIG_SOC_K3_J721S2 */
 
-#if (CONFIG_IS_ENABLED(SOC_K3_AM642) || CONFIG_IS_ENABLED(SOC_K3_AM625))
+#if defined(CONFIG_SOC_K3_AM642) || defined(CONFIG_SOC_K3_AM625)
 /* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
 #define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
 
-- 
2.36.1

Re: [v3 1/4] doc: Add statistics page for v2022.07

[Heinrich Schuchardt]

On 7/12/22 23:34, Tom Rini wrote:

Our statistics pages have always been generated by gitdm.  After
patching gitdm to generate an acceptable Sphinx output for tables,
include that and some other basic formatting here.

Cc: Heinrich Schuchardt
Signed-off-by: Tom Rini
---


Reviewed-by: Heinrich Schuchardt 

Re: [PATCH] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM

[Patrick Delaunay]

On Thu, 30 Jun 2022 16:19:48 +0200, Johann Neuhauser wrote:
> PA13 and PA14 are used for USB power control and can't be used
> to enforce fastboot or stm32prog mode by pressing a button.
> 
> Defining CONFIG_FASTBOOT/CONFIG_CMD_STM32PROG without this patch applied
> results in fastboot/stm32prog always starting, because PA13/PA14 are always
> low during boot. So drop the wrong trigger gpios definitions.
> 
> [...]

Applied to stm32/master, thanks!

[1/1] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
  commit: 48d9eaf6826a1816c5f9839a564ea6338da609a7

Best regards,
-- 
Patrick Delaunay 

Re: [PATCH v2 1/3] mmc: stm32_sdmmc2: cosmetic: rename stm32_sdmmc_bind

[Patrick Delaunay]

On Thu, 30 Jun 2022 10:01:45 +0200, Patrick Delaunay wrote:
> Rename stm32_sdmmc_bind to stm32_sdmmc2_bind as all other functions
> in SDMMCv2 driver
> 
> series-changes: 2
> - fix typo in commit message (/oter function/other functions/)
> 
> 
> [...]

Applied to stm32/master, thanks!

[1/3] mmc: stm32_sdmmc2: cosmetic: rename stm32_sdmmc_bind
  commit: 5f1e6b639b47eea5177b1128c384da76dce2dbe6
[2/3] mmc: stm32_sdmmc2: remove privdata
  commit: efd77dbca304d6cceb40675365485d84cce40ccd
[3/3] mmc: stm32_sdmmc2: introduce of_to_plat ops
  commit: cb8edb996bf20be09b88b2b17520beec433067cd

Best regards,
-- 
Patrick Delaunay 

Re: [PATCH 1/4] ARM: dts: stm32mp15: alignment with v5.19

[Patrick Delaunay]

On Tue, 5 Jul 2022 16:55:54 +0200, Patrick Delaunay wrote:
> Device tree alignment with Linux kernel v5.19-rc1
> 
> - ARM: dts: stm32: Add alternate pinmux for ethernet0 pins
> - ARM: dts: stm32: Add alternate pinmux for mco2 pins
> - ARM: dts: stm32: fix pinctrl node name warnings (MPU soc)
> - ARM: dts: stm32: stm32mp15-pinctrl: add spi1-1 pinmux group
> - dt-bindings: clock: add IDs for SCMI clocks on stm32mp15
> - dt-bindings: reset: add IDs for SCMI reset domains on stm32mp15
> - dt-bindings: clock: stm32mp15: rename CK_SCMI define
> - dt-bindings: reset: stm32mp15: rename RST_SCMI define
> - dt-bindings: reset: add MCU HOLD BOOT ID for SCMI reset domains
>   on stm32mp15
> - dt-bindings: clk: cleanup comments
> - ARM: dts: align SPI NOR node name with dtschema
> - ARM: dts: stm32: enable optee firmware and SCMI support on STM32MP15
> - ARM: dts: stm32: Add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)
> - ARM: dts: stm32: move SCMI related nodes in a dedicated file for
>   stm32mp15
> 
> [...]

Applied to stm32/master, thanks!

[1/4] ARM: dts: stm32mp15: alignment with v5.19
  commit: 69ef98b209e7e392d4a31d99cb4fa249f8a58ac0
[2/4] clk: stm32: add support compatible st, stm32mp1-rcc-secure
  commit: 43872790d8eeb2055aebc13b09fba3dbb2f8dcaf
[3/4] configs: stm32mp15: increase malloc size for pre-reloc
  commit: 7f4de655c0ff460c1a4ee6ea00208327ab54e22d
[4/4] ARM: dts: stm32: add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)
  commit: 68d396bfd68bbf695b3b3c92e60b8bdf8b77

Best regards,
-- 
Patrick Delaunay 

Re: [PATCH v2 01/10] i2c: stm32: add support for the st, stm32mp13 SOC

[Patrick Delaunay]

On Thu, 30 Jun 2022 10:20:14 +0200, Patrick Delaunay wrote:
> The stm32mp13 soc differs from the stm32mp15 in terms of
> clear register offset for controlling the FMP (Fast Mode Plus).
> 
> 

Applied to stm32/master, thanks!

[01/10] i2c: stm32: add support for the st,stm32mp13 SOC
commit: d4d01d0e9998ab1c000ae0d578d33801b31cb845
[02/10] rng: stm32mp1_rng: add conditional reset feature for STM32MP13x
commit: 12e11aae2d96d4c437c4c068e440ab4b7f08ceb0
[03/10] stm32mp: add support of STM32MP13x Rev.Y
commit: 50b371fd68afb3650fc285bca6ae88d639418a16
[04/10] ARM: dts: stm32mp13: alignment with v5.19
commit: 12d5a0626cf11acc3c9a59c91d87657eef726fdc
[05/10] ARM: dts: stm32mp13: activate led on STM32MP13F-DK
commit: 6d647676ead2caecade3a7145302e98bfbc436f9
[06/10] configs: stm32mp13: Add support for baudrates higher than 115200
commit: eb67e63da4468195276c889a1866b43821128b25
[07/10] configs: stm32mp13: activate RNG support
commit: 72d7a302f634029ef2874d864c294fd9bfc48739
[08/10] configs: stm32mp13: activate RTC support
commit: 420f37a91faefcda64355805fbcb662cd0aac8e1
[09/10] configs: stm32mp13: activate I2C support
commit: 33129f6130dc125582e09a03ec78afe53a1b27f3
[10/10] configs: stm32mp13: activate some command
commit: 257d001cb5a3e3e3a582fddb37478dedb1764811

Best regards,
-- 
Patrick Delaunay