date:20231106


Hi Nishanth,

On 04/11/23 12:51, Nishanth Menon wrote:

Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.

Signed-off-by: Nishanth Menon 
---
  configs/j7200_evm_a72_defconfig | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 889358afc316..b7bc9ad178f6 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -29,10 +29,11 @@ CONFIG_SPL_SPI=y
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_SPL_LOAD_FIT=y
  CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
-CONFIG_DISTRO_DEFAULTS=y
  CONFIG_OF_BOARD_SETUP=y
  CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
+CONFIG_BOOTSTD_FULL=y
+CONFIG_BOOTSTD_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
  CONFIG_LOGLEVEL=7
  CONFIG_SPL_MAX_SIZE=0xc
  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y


Reviewed-by: Neha Malcom Francis 

--
Thanking You
Neha Malcom Francis

Re: [PATCH V2 10/12] configs: j7200: Remove HBMC_AM654 config


Hi Nishanth,

On 04/11/23 12:51, Nishanth Menon wrote:

Kernel commit 1b77265626a4 ("arm64: dts: ti: k3-j7200-mcu-wakeup: Add
HyperBus node") was merged to kernel without its dependent patch [1].
Similar fix is needed in U-Boot, and hbmc currently breaks boot. Till
this gets fixed in U-Boot, disable the config by default so that the
hbmc probe that happens in board/ti/j721e/evm.c will not take place
and lead to boot failure.

This is similar to the approach in commit 5b2671594b80 ("configs:
j721e: Remove HBMC_AM654 config"), introduced to j7200 evm platform.

[1] https://lore.kernel.org/all/20230424184810.29453-1-...@ti.com/

Signed-off-by: Nishanth Menon 
---
  configs/j7200_evm_a72_defconfig | 1 -
  configs/j7200_evm_r5_defconfig  | 1 -
  2 files changed, 2 deletions(-)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index cb4a141675da..889358afc316 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -138,7 +138,6 @@ CONFIG_CFI_FLASH=y
  CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
  CONFIG_FLASH_CFI_MTD=y
  CONFIG_SYS_FLASH_CFI=y
-CONFIG_HBMC_AM654=y
  CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
  CONFIG_DM_SPI_FLASH=y
  CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig
index d25dd8134b63..6452c60345fd 100644
--- a/configs/j7200_evm_r5_defconfig
+++ b/configs/j7200_evm_r5_defconfig
@@ -114,7 +114,6 @@ CONFIG_CFI_FLASH=y
  CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
  CONFIG_FLASH_CFI_MTD=y
  CONFIG_SYS_FLASH_CFI=y
-CONFIG_HBMC_AM654=y
  CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
  CONFIG_DM_SPI_FLASH=y
  CONFIG_SPI_FLASH_SFDP_SUPPORT=y


Reviewed-by: Neha Malcom Francis 

--
Thanking You
Neha Malcom Francis

Re: [PATCH V2 05/12] configs: j721e_evm_a72_defconfig: Switch to bootstd


Hi Nishanth

On 04/11/23 12:51, Nishanth Menon wrote:

Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.

Signed-off-by: Nishanth Menon 
---
  configs/j721e_evm_a72_defconfig | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 99e0e168ebf7..98ac7ca59789 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -29,10 +29,11 @@ CONFIG_SPL_SPI=y
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_SPL_LOAD_FIT=y
  CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
-CONFIG_DISTRO_DEFAULTS=y
  CONFIG_OF_BOARD_SETUP=y
  CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
+CONFIG_BOOTSTD_FULL=y
+CONFIG_BOOTSTD_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
  CONFIG_LOGLEVEL=7
  CONFIG_SPL_MAX_SIZE=0xc
  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y


Reviewed-by: Neha Malcom Francis 

--
Thanking You
Neha Malcom Francis

Re: [PATCH V2 04/12] board: ti: j721e: j721e.env: Add explicit boot_targets


Hi Nishanth,

On 04/11/23 12:51, Nishanth Menon wrote:

Add explicit boot_targets to indicate the specific boot sequence to
follow.

Signed-off-by: Nishanth Menon 
---
  board/ti/j721e/j721e.env | 1 +
  1 file changed, 1 insertion(+)

diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index 8cc8232fc131..cb27bf5e2b24 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -31,6 +31,7 @@ addr_mcur5f0_0load=0x8900
  name_mcur5f0_0fw=/lib/firmware/j7200-mcu-r5f0_0-fw
  #endif
  
+boot_targets=mmc1 mmc0 usb pxe dhcp

  boot=mmc
  mmcdev=1
  bootpart=1:2


Reviewed-by: Neha Malcom Francis 

--
Thanking You
Neha Malcom Francis

Re: [PATCH V2 03/12] board: ti: j721e: evm: Switch to using IS_ENABLED


Hi Nishanth,

On 04/11/23 12:51, Nishanth Menon wrote:

Switch to using IS_ENABLED() for inline function usage.

Signed-off-by: Nishanth Menon 
---
  board/ti/j721e/evm.c | 83 ++--
  1 file changed, 42 insertions(+), 41 deletions(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 8f0996c32ee6..17640ae79665 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -300,53 +300,54 @@ static int probe_daughtercards(void)
printf("Detected: %s rev %s\n", ep.name, ep.version);
daughter_card_detect_flags[i] = true;
  
-#ifndef CONFIG_SPL_BUILD

-   int j;
-   /*
-* Populate any MAC addresses from daughtercard into the U-Boot
-* environment, starting with a card-specific offset so we can
-* have multiple ext_cards contribute to the MAC pool in a well-
-* defined manner.
-*/
-   for (j = 0; j < mac_addr_cnt; j++) {
-   if (!is_valid_ethaddr((u8 *)mac_addr[j]))
-   continue;
-
-   eth_env_set_enetaddr_by_index("eth",
- ext_cards[i].eth_offset + 
j,
- (uchar *)mac_addr[j]);
+   if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+   int j;
+   /*
+* Populate any MAC addresses from daughtercard into 
the U-Boot
+* environment, starting with a card-specific offset so 
we can
+* have multiple ext_cards contribute to the MAC pool 
in a well-
+* defined manner.
+*/
+   for (j = 0; j < mac_addr_cnt; j++) {
+   if (!is_valid_ethaddr((u8 *)mac_addr[j]))
+   continue;
+
+   eth_env_set_enetaddr_by_index("eth",
+ 
ext_cards[i].eth_offset + j,
+ (uchar 
*)mac_addr[j]);
+   }
}
-#endif
}
-#ifndef CONFIG_SPL_BUILD
-   char name_overlays[1024] = { 0 };
  
-	for (i = 0; i < ARRAY_SIZE(ext_cards); i++) {

-   if (!daughter_card_detect_flags[i])
-   continue;
+   if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+   char name_overlays[1024] = { 0 };
  
-		/* Skip if no overlays are to be added */

-   if (!strlen(ext_cards[i].dtbo_name))
-   continue;
+   for (i = 0; i < ARRAY_SIZE(ext_cards); i++) {
+   if (!daughter_card_detect_flags[i])
+   continue;
  
-		/*

-* Make sure we are not running out of buffer space by checking
-* if we can fit the new overlay, a trailing space to be used
-* as a separator, plus the terminating zero.
-*/
-   if (strlen(name_overlays) + strlen(ext_cards[i].dtbo_name) + 2 >
-   sizeof(name_overlays))
-   return -ENOMEM;
-
-   /* Append to our list of overlays */
-   strcat(name_overlays, ext_cards[i].dtbo_name);
-   strcat(name_overlays, " ");
-   }
+   /* Skip if no overlays are to be added */
+   if (!strlen(ext_cards[i].dtbo_name))
+   continue;
  
-	/* Apply device tree overlay(s) to the U-Boot environment, if any */

-   if (strlen(name_overlays))
-   return env_set("name_overlays", name_overlays);
-#endif
+   /*
+* Make sure we are not running out of buffer space by 
checking
+* if we can fit the new overlay, a trailing space to 
be used
+* as a separator, plus the terminating zero.
+*/
+   if (strlen(name_overlays) + strlen(ext_cards[i].dtbo_name) 
+ 2 >
+   sizeof(name_overlays))
+   return -ENOMEM;
+
+   /* Append to our list of overlays */
+   strcat(name_overlays, ext_cards[i].dtbo_name);
+   strcat(name_overlays, " ");
+   }
+
+   /* Apply device tree overlay(s) to the U-Boot environment, if 
any */
+   if (strlen(name_overlays))
+   return env_set("name_overlays", name_overlays);
+   }
  
  	return 0;

  }


Reviewed-by: Neha Malcom Francis 

--
Thanking You
Neha Malcom Francis

Re: [PATCH V2 02/12] board: ti: j721e: evm: Drop board check for ESM


Hi Nishanth,

On 04/11/23 12:51, Nishanth Menon wrote:

When config is enabled, the esm dt probe makes sense. Simplify by
dropping board specific checks.

Signed-off-by: Nishanth Menon 
---
  board/ti/j721e/evm.c | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index aa22f1653fec..8f0996c32ee6 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -523,10 +523,8 @@ err_free_gpio:
  
  void spl_board_init(void)

  {
-#if defined(CONFIG_ESM_K3) || defined(CONFIG_ESM_PMIC)
struct udevice *dev;
int ret;
-#endif
  
  	if ((IS_ENABLED(CONFIG_TARGET_J721E_A72_EVM) ||

 IS_ENABLED(CONFIG_TARGET_J7200_A72_EVM)) &&
@@ -535,24 +533,20 @@ void spl_board_init(void)
probe_daughtercards();
}
  
-#ifdef CONFIG_ESM_K3

-   if (board_ti_k3_is("J721EX-PM2-SOM")) {
+   if (IS_ENABLED(CONFIG_ESM_K3)) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
  DM_DRIVER_GET(k3_esm), );
if (ret)
printf("ESM init failed: %d\n", ret);
}
-#endif
  
-#ifdef CONFIG_ESM_PMIC

-   if (board_ti_k3_is("J721EX-PM2-SOM")) {
+   if (IS_ENABLED(CONFIG_ESM_PMIC)) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
  DM_DRIVER_GET(pmic_esm),
  );
if (ret)
printf("ESM PMIC init failed: %d\n", ret);
}
-#endif


Add empty line here?


if ((IS_ENABLED(CONFIG_TARGET_J7200_A72_EVM) || 
IS_ENABLED(CONFIG_TARGET_J721E_A72_EVM)) &&
IS_ENABLED(CONFIG_HBMC_AM654)) {
struct udevice *dev;


Reviewed-by: Neha Malcom Francis 

--
Thanking You
Neha Malcom Francis

Re: [PATCH V2 01/12] board: ti: j721e: evm: Drop unused headers


Hi Nishanth,

On 04/11/23 12:51, Nishanth Menon wrote:

Drop headers that are no longer necessary for build

Signed-off-by: Nishanth Menon 
---
  board/ti/j721e/evm.c | 8 
  1 file changed, 8 deletions(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index d4f7c1d9f938..aa22f1653fec 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -8,21 +8,13 @@
   */
  
  #include 

-#include 
-#include 
  #include 
  #include 
-#include 
-#include 
  #include 
  #include 
-#include 
  #include 
-#include 
  #include 
  #include 
-#include 
-#include 
  
  #include "../common/board_detect.h"
  


Reviewed-by: Neha Malcom Francis 

--
Thanking You
Neha Malcom Francis

RE: [PATCH v2 1/2] driver: power: add support for TPS65224

2023-11-06 Thread Jaehoon Chung




> -Original Message-
> From: U-Boot  On Behalf Of Jaehoon Chung
> Sent: Tuesday, November 7, 2023 3:42 PM
> To: 'Bhargav Raviprakash' ; u-boot@lists.denx.de
> Subject: RE: [PATCH v2 1/2] driver: power: add support for TPS65224
> 
> Hi Bhargav,
> 
> > -Original Message-
> > From: Bhargav Raviprakash 
> > Sent: Monday, November 6, 2023 11:07 PM
> > To: u-boot@lists.denx.de
> > Cc: jh80.ch...@samsung.com; Bhargav Raviprakash 
> > Subject: [PATCH v2 1/2] driver: power: add support for TPS65224
> >
> > Added support for PMIC TPS65224. Includes driver for pmic,
> > and disabling Watchdog.
> >
> > Signed-off-by: Bhargav Raviprakash 
> > ---
> >  drivers/power/pmic/Kconfig|   6 ++
> >  drivers/power/pmic/Makefile   |   1 +
> >  drivers/power/pmic/tps65224.c | 141 ++
> >  include/power/tps65224.h  |  57 ++
> >  4 files changed, 205 insertions(+)
> >  create mode 100644 drivers/power/pmic/tps65224.c
> >  create mode 100644 include/power/tps65224.h
> >
> > diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> > index 4a6f0ce093..b06bd31823 100644
> > --- a/drivers/power/pmic/Kconfig
> > +++ b/drivers/power/pmic/Kconfig
> > @@ -378,6 +378,12 @@ config PMIC_TPS65941
> > The TPS65941 is a PMIC containing a bunch of SMPS & LDOs.
> > This driver binds the pmic children.
> >
> > +config PMIC_TPS65224
> > +   bool "Enable driver for Texas Instruments TPS65224 PMIC"
> > +   help
> > +   The TPS65224 is a PMIC containing a bunch of SMPS & LDOs.
> > +   This driver binds the pmic children.
> > +
> >  config PMIC_TPS65219
> > bool "Enable driver for Texas Instruments TPS65219 PMIC"
> > depends on DM_PMIC
> > diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> > index 0b3b3d62d0..cec16e57d3 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -33,6 +33,7 @@ obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
> >  obj-$(CONFIG_PMIC_TPS65217) += pmic_tps65217.o
> >  obj-$(CONFIG_PMIC_TPS65219) += tps65219.o
> >  obj-$(CONFIG_PMIC_TPS65941) += tps65941.o
> > +obj-$(CONFIG_PMIC_TPS65224) += tps65224.o
> 
> Ordering this. Maybe it can be located at tps65941.o.
> 
> >  obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
> >
> >  ifeq ($(CONFIG_$(SPL_)POWER_LEGACY),y)
> > diff --git a/drivers/power/pmic/tps65224.c b/drivers/power/pmic/tps65224.c
> > new file mode 100644
> > index 00..33395f6edf
> > --- /dev/null
> > +++ b/drivers/power/pmic/tps65224.c
> > @@ -0,0 +1,141 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2023 Texas Instruments Incorporated, 
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static const struct pmic_child_info pmic_children_info[] = {
> > +   { .prefix = "ldo", .driver = TPS65224_LDO_DRIVER },
> > +   { .prefix = "buck", .driver = TPS65224_BUCK_DRIVER },
> > +   { },
> > +};
> > +
> > +static int tps65224_write(struct udevice *dev, uint reg, const uint8_t 
> > *buff,
> > + int len)
> > +{
> > +   if (dm_i2c_write(dev, reg, buff, len)) {
> > +   pr_err("write error to device: %p register: %#x!\n", dev, reg);
> > +   return -EIO;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int tps65224_read(struct udevice *dev, uint reg, uint8_t *buff, int 
> > len)
> > +{
> > +   if (dm_i2c_read(dev, reg, buff, len)) {
> > +   pr_err("read error from device: %p register: %#x!\n", dev, reg);
> > +   return -EIO;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int tps65224_bind(struct udevice *dev)
> > +{
> > +   ofnode regulators_node;
> > +   int children;
> > +
> > +   if (dev->driver_data == TPS65224_WD)
> > +   return 0;
> > +
> > +   regulators_node = dev_read_subnode(dev, "regulators");
> > +   if (!ofnode_valid(regulators_node)) {
> > +   debug("%s: %s regulators subnode not found!\n", __func__,
> > + dev->name);
> > +   return -ENXIO;
> > +   }
> > +
> > +   debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
> > +
> > +   children = pmic_bind_children(dev, regulators_node, pmic_children_info);
> > +   if (!children)
> > +   printf("%s: %s - no child found\n", __func__, dev->name);
> > +
> > +   /* Probe all the child devices */
> > +   return dm_scan_fdt_dev(dev);
> > +}
> > +
> > +static int stop_watchdog(struct udevice *wd_i2c_dev)
> > +{
> > +   int ret;
> > +
> > +   /* Maintain WD long window */
> > +   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
> > +   if (ret < 0) {
> > +   debug("failed to read i2c reg (%d)\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   ret &= ~TPS65224_WD_PWRHOLD_MASK;
> > +   ret |= TPS65224_WD_PWRHOLD_MASK;
> 
> Is it a right behavior? After cleared its bit, set again?
> Any reason to do this?

Just mis-reading. Discard above

RE: [PATCH v2 1/2] driver: power: add support for TPS65224

2023-11-06 Thread Jaehoon Chung

Hi Bhargav,

> -Original Message-
> From: Bhargav Raviprakash 
> Sent: Monday, November 6, 2023 11:07 PM
> To: u-boot@lists.denx.de
> Cc: jh80.ch...@samsung.com; Bhargav Raviprakash 
> Subject: [PATCH v2 1/2] driver: power: add support for TPS65224
> 
> Added support for PMIC TPS65224. Includes driver for pmic,
> and disabling Watchdog.
> 
> Signed-off-by: Bhargav Raviprakash 
> ---
>  drivers/power/pmic/Kconfig|   6 ++
>  drivers/power/pmic/Makefile   |   1 +
>  drivers/power/pmic/tps65224.c | 141 ++
>  include/power/tps65224.h  |  57 ++
>  4 files changed, 205 insertions(+)
>  create mode 100644 drivers/power/pmic/tps65224.c
>  create mode 100644 include/power/tps65224.h
> 
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 4a6f0ce093..b06bd31823 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -378,6 +378,12 @@ config PMIC_TPS65941
>   The TPS65941 is a PMIC containing a bunch of SMPS & LDOs.
>   This driver binds the pmic children.
> 
> +config PMIC_TPS65224
> + bool "Enable driver for Texas Instruments TPS65224 PMIC"
> + help
> + The TPS65224 is a PMIC containing a bunch of SMPS & LDOs.
> + This driver binds the pmic children.
> +
>  config PMIC_TPS65219
>   bool "Enable driver for Texas Instruments TPS65219 PMIC"
>   depends on DM_PMIC
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 0b3b3d62d0..cec16e57d3 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
>  obj-$(CONFIG_PMIC_TPS65217) += pmic_tps65217.o
>  obj-$(CONFIG_PMIC_TPS65219) += tps65219.o
>  obj-$(CONFIG_PMIC_TPS65941) += tps65941.o
> +obj-$(CONFIG_PMIC_TPS65224) += tps65224.o

Ordering this. Maybe it can be located at tps65941.o.

>  obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
> 
>  ifeq ($(CONFIG_$(SPL_)POWER_LEGACY),y)
> diff --git a/drivers/power/pmic/tps65224.c b/drivers/power/pmic/tps65224.c
> new file mode 100644
> index 00..33395f6edf
> --- /dev/null
> +++ b/drivers/power/pmic/tps65224.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2023 Texas Instruments Incorporated, 
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> + { .prefix = "ldo", .driver = TPS65224_LDO_DRIVER },
> + { .prefix = "buck", .driver = TPS65224_BUCK_DRIVER },
> + { },
> +};
> +
> +static int tps65224_write(struct udevice *dev, uint reg, const uint8_t *buff,
> +   int len)
> +{
> + if (dm_i2c_write(dev, reg, buff, len)) {
> + pr_err("write error to device: %p register: %#x!\n", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int tps65224_read(struct udevice *dev, uint reg, uint8_t *buff, int 
> len)
> +{
> + if (dm_i2c_read(dev, reg, buff, len)) {
> + pr_err("read error from device: %p register: %#x!\n", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int tps65224_bind(struct udevice *dev)
> +{
> + ofnode regulators_node;
> + int children;
> +
> + if (dev->driver_data == TPS65224_WD)
> + return 0;
> +
> + regulators_node = dev_read_subnode(dev, "regulators");
> + if (!ofnode_valid(regulators_node)) {
> + debug("%s: %s regulators subnode not found!\n", __func__,
> +   dev->name);
> + return -ENXIO;
> + }
> +
> + debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
> +
> + children = pmic_bind_children(dev, regulators_node, pmic_children_info);
> + if (!children)
> + printf("%s: %s - no child found\n", __func__, dev->name);
> +
> + /* Probe all the child devices */
> + return dm_scan_fdt_dev(dev);
> +}
> +
> +static int stop_watchdog(struct udevice *wd_i2c_dev)
> +{
> + int ret;
> +
> + /* Maintain WD long window */
> + ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
> + if (ret < 0) {
> + debug("failed to read i2c reg (%d)\n", ret);
> + return ret;
> + }
> +
> + ret &= ~TPS65224_WD_PWRHOLD_MASK;
> + ret |= TPS65224_WD_PWRHOLD_MASK;

Is it a right behavior? After cleared its bit, set again?
Any reason to do this?

How about using val and ret as variable to clarify?


> + ret = dm_i2c_reg_write(wd_i2c_dev, TPS65224_WD_MODE_REG, ret);
> + if (ret) {
> + debug("%s: %s write WD_PWRHOLD fail!\n", __func__, 
> wd_i2c_dev->name);
> + return ret;
> + }
> +
> + ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
> + if (ret < 0) {
> + debug("failed to read back i2c reg (%d)\n", ret);
> + return ret;
> + }
> +

RE: [PATCH] mmc: sdhci-cadence: Add support for Cadence sdmmc v6

2023-11-06 Thread KuanLim . Lee

Hi Jaehoon,

On 11/1/23 08:20, Jaehoon Chung wrote:
> From: Jaehoon Chung 
> Hi
> 
> On 10/3/23 16:22, Kuan Lim Lee wrote:
> > From: Kuan Lim Lee 
> >
> > Cadence SDMMC v6 controller has a lot of changes on initialize
> > compared to v4 controller. PHY is needed by v6 controller.
> >
> > Signed-off-by: Kuan Lim Lee 
> > Reviewed-by: Alex Soo 
> > Reviewed-by: Wei Liang Lim 
> 
> I didn't see their Reviewed-by tag in mailing list.
They are my colleagues who collaborated develop code with me.
I think I should them in Signed-off-by, and put your name in Reviewed-by

> 
> > ---
> >  drivers/mmc/Kconfig  |  13 ++
> >  drivers/mmc/Makefile |   1 +
> >  drivers/mmc/sdhci-cadence.c  |  63 ++-
> >  drivers/mmc/sdhci-cadence.h  |  68 +++
> >  drivers/mmc/sdhci-cadence6-phy.c | 302
> > +++
> >  5 files changed, 396 insertions(+), 51 deletions(-)  create mode
> > 100644 drivers/mmc/sdhci-cadence.h  create mode 100644
> > drivers/mmc/sdhci-cadence6-phy.c
> >
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
> > de01b9687b..cec881d862 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -573,6 +573,19 @@ config MMC_SDHCI_CADENCE
> >
> >   If unsure, say N.
> >
> > +config MMC_SDHCI_CADENCE_V6
> > +   bool "SDHCI support for the Cadence SD/SDIO/eMMC controller &
> driver version 6"
> > +   depends on BLK && DM_MMC
> > +   depends on MMC_SDHCI
> > +   depends on OF_CONTROL
> > +   select MMC_SDHCI_CADENCE
> > +   help
> > + This selects the Cadence SD/SDIO/eMMC driver version 6.
> > +
> > + If you have a controller with this interface, say Y here.
> > +
> > + If unsure, say N.
> > +
> >  config MMC_SDHCI_AM654
> > bool "SDHCI Controller on TI's Am654 devices"
> > depends on ARCH_K3
> > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index
> > 2c65c4765a..cdcce55b8b 100644
> > --- a/drivers/mmc/Makefile
> > +++ b/drivers/mmc/Makefile
> > @@ -61,6 +61,7 @@ obj-$(CONFIG_MMC_SDHCI_ATMEL) +=
> atmel_sdhci.o
> >  obj-$(CONFIG_MMC_SDHCI_BCM2835)+= bcm2835_sdhci.o
> >  obj-$(CONFIG_MMC_SDHCI_BCMSTB) += bcmstb_sdhci.o
> >  obj-$(CONFIG_MMC_SDHCI_CADENCE)+= sdhci-cadence.o
> > +obj-$(CONFIG_MMC_SDHCI_CADENCE_V6) += sdhci-cadence6-phy.o
> >  obj-$(CONFIG_MMC_SDHCI_AM654)  += am654_sdhci.o
> >  obj-$(CONFIG_MMC_SDHCI_IPROC)  += iproc_sdhci.o
> >  obj-$(CONFIG_MMC_SDHCI_KONA)   += kona_sdhci.o
> > diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
> > index 327a05ad11..d7a270e74c 100644
> > --- a/drivers/mmc/sdhci-cadence.c
> > +++ b/drivers/mmc/sdhci-cadence.c
> > @@ -17,56 +17,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -
> > -/* HRS - Host Register Set (specific to Cadence) */
> > -#define SDHCI_CDNS_HRS04   0x10/* PHY access port */
> > -#define   SDHCI_CDNS_HRS04_ACK BIT(26)
> > -#define   SDHCI_CDNS_HRS04_RD  BIT(25)
> > -#define   SDHCI_CDNS_HRS04_WR  BIT(24)
> > -#define   SDHCI_CDNS_HRS04_RDATA   GENMASK(23, 16)
> > -#define   SDHCI_CDNS_HRS04_WDATA   GENMASK(15, 8)
> > -#define   SDHCI_CDNS_HRS04_ADDRGENMASK(5, 0)
> > -
> > -#define SDHCI_CDNS_HRS06   0x18/* eMMC control */
> > -#define   SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
> > -#define   SDHCI_CDNS_HRS06_TUNEGENMASK(13, 8)
> > -#define   SDHCI_CDNS_HRS06_MODEGENMASK(2, 0)
> > -#define   SDHCI_CDNS_HRS06_MODE_SD 0x0
> > -#define   SDHCI_CDNS_HRS06_MODE_MMC_SDR0x2
> > -#define   SDHCI_CDNS_HRS06_MODE_MMC_DDR0x3
> > -#define   SDHCI_CDNS_HRS06_MODE_MMC_HS200  0x4
> > -#define   SDHCI_CDNS_HRS06_MODE_MMC_HS400  0x5
> > -#define   SDHCI_CDNS_HRS06_MODE_MMC_HS400ES0x6
> > -
> > -/* SRS - Slot Register Set (SDHCI-compatible) */
> > -#define SDHCI_CDNS_SRS_BASE0x200
> > -
> > -/* PHY */
> > -#define SDHCI_CDNS_PHY_DLY_SD_HS   0x00
> > -#define SDHCI_CDNS_PHY_DLY_SD_DEFAULT  0x01
> > -#define SDHCI_CDNS_PHY_DLY_UHS_SDR12   0x02
> > -#define SDHCI_CDNS_PHY_DLY_UHS_SDR25   0x03
> > -#define SDHCI_CDNS_PHY_DLY_UHS_SDR50   0x04
> > -#define SDHCI_CDNS_PHY_DLY_UHS_DDR50   0x05
> > -#define SDHCI_CDNS_PHY_DLY_EMMC_LEGACY 0x06
> > -#define SDHCI_CDNS_PHY_DLY_EMMC_SDR0x07
> > -#define SDHCI_CDNS_PHY_DLY_EMMC_DDR0x08
> > -#define SDHCI_CDNS_PHY_DLY_SDCLK   0x0b
> > -#define SDHCI_CDNS_PHY_DLY_HSMMC   0x0c
> > -#define SDHCI_CDNS_PHY_DLY_STROBE  0x0d
> > -
> > -/*
> > - * The tuned val register is 6 bit-wide, but not the whole of the
> > range is
> > - * available.  The range 0-42 seems to be available (then 43 wraps
> > around to 0)
> > - * but I am not quite sure if it is official.  Use only 0 to 39 for safety.
> > - */
> > -#define SDHCI_CDNS_MAX_TUNING_LOOP 40
> > -
> >

Re: [PATCH V2 2/4] board: beagle: Add BeagleBone AI-64 support


Hi Andrew,

On 06/11/23 22:34, Andrew Davis wrote:

On 11/4/23 3:11 AM, Nishanth Menon wrote:

Add base support for BeagleBone AI-64 board support.

Further information at  https://beagleboard.org/ai-64

Signed-off-by: Nishanth Menon 
---
  arch/arm/mach-k3/Kconfig  |    1 +
  board/beagle/beagleboneai64/Kconfig   |   59 +
  board/beagle/beagleboneai64/Makefile  |   10 +
  board/beagle/beagleboneai64/beagleboneai64.c  |   30 +
  .../beagle/beagleboneai64/beagleboneai64.env  |   19 +
  board/beagle/beagleboneai64/board-cfg.yaml    |   36 +
  board/beagle/beagleboneai64/pm-cfg.yaml   |   12 +
  board/beagle/beagleboneai64/rm-cfg.yaml   | 3174 +


95% of this patch is just copy/pasting the board-config yaml files. Same
for other K3-based boards. I'd expect in practice these files to be near
completely common between boards using the same SoC. Would be nice to
inlcude a default .yaml from aarch/arm/mach-k3/ and only override
the couple options one wants changed for their board.

Neha,

Is the above something you would be able to help with? I'm a bit out of my
element with all this board config schema stuff..



Right, apart from the rm-cfg files, everything else is very similar even across 
SoCs. I think we can take action to have a default YAML for each SoC.



Thanks,
Andrew


  board/beagle/beagleboneai64/sec-cfg.yaml  |  380 ++
  9 files changed, 3721 insertions(+)
  create mode 100644 board/beagle/beagleboneai64/Kconfig
  create mode 100644 board/beagle/beagleboneai64/Makefile
  create mode 100644 board/beagle/beagleboneai64/beagleboneai64.c
  create mode 100644 board/beagle/beagleboneai64/beagleboneai64.env
  create mode 100644 board/beagle/beagleboneai64/board-cfg.yaml
  create mode 100644 board/beagle/beagleboneai64/pm-cfg.yaml
  create mode 100644 board/beagle/beagleboneai64/rm-cfg.yaml
  create mode 100644 board/beagle/beagleboneai64/sec-cfg.yaml



[...]

--
Thanking You
Neha Malcom Francis

Re: [PATCH V2 2/2] arm: mach-k3: Move TI dummy keys out of board folder

2023-11-06 Thread Manorit Chawdhry

On 11:11-20231106, Andrew Davis wrote:
> On 11/3/23 9:45 PM, Nishanth Menon wrote:
> > This file is used to emulate customer keys on TI development board
> > ecosystems, move it out of board/ directory and into mach-k3. And
> > change the relative paths to absolute paths in the binman paths.
> > 
> > While at it, drop the reference in verdin-binman file which is
> > redundant.
> > 
> > Signed-off-by: Nishanth Menon 
> > ---
> 
> Moving custMpk.pem looks good. But I don't know how .crt and .key
> are actually used right now, I'd guess they already get pulled in
> during FIT signing using relative paths so this might be okay.
> 
> Good to get an ACK from +Manorit to be sure though.
> 

I think the current yocto builds are not using the keys so should be
okay. I wasn't able to get the u-boot keys and ended up using the keys
in core-secdev. Might be a future action to actually use these keys,
they currently just help in Upstream and people don't have to go to
core-secdev for getting these.

Acked-by: Manorit Chawdhry 

Regards,
Manorit

> Andrew
> 
> > New patch in series.
> > 
> >   arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 
> >   arch/arm/dts/k3-binman.dtsi   | 2 +-
> >   {board/ti => arch/arm/mach-k3}/keys/custMpk.crt   | 0
> >   {board/ti => arch/arm/mach-k3}/keys/custMpk.key   | 0
> >   {board/ti => arch/arm/mach-k3}/keys/custMpk.pem   | 0
> >   5 files changed, 1 insertion(+), 5 deletions(-)
> >   rename {board/ti => arch/arm/mach-k3}/keys/custMpk.crt (100%)
> >   rename {board/ti => arch/arm/mach-k3}/keys/custMpk.key (100%)
> >   rename {board/ti => arch/arm/mach-k3}/keys/custMpk.pem (100%)
> > 
> > diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi 
> > b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
> > index ea22bfb9bad6..58fde95adf67 100644
> > --- a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
> > +++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
> > @@ -5,10 +5,6 @@
> >   #include "k3-binman.dtsi"
> > -_pem {
> > -   filename = "../../ti/keys/custMpk.pem";
> > -};
> > -
> >   #ifdef CONFIG_TARGET_VERDIN_AM62_R5
> >{
> > diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
> > index b941726e6246..8d4b0b2454f6 100644
> > --- a/arch/arm/dts/k3-binman.dtsi
> > +++ b/arch/arm/dts/k3-binman.dtsi
> > @@ -13,7 +13,7 @@
> > custMpk {
> > filename = "custMpk.pem";
> > custmpk_pem: blob-ext {
> > -   filename = "../keys/custMpk.pem";
> > +   filename = "arch/arm/mach-k3/keys/custMpk.pem";
> > };
> > };
> > diff --git a/board/ti/keys/custMpk.crt b/arch/arm/mach-k3/keys/custMpk.crt
> > similarity index 100%
> > rename from board/ti/keys/custMpk.crt
> > rename to arch/arm/mach-k3/keys/custMpk.crt
> > diff --git a/board/ti/keys/custMpk.key b/arch/arm/mach-k3/keys/custMpk.key
> > similarity index 100%
> > rename from board/ti/keys/custMpk.key
> > rename to arch/arm/mach-k3/keys/custMpk.key
> > diff --git a/board/ti/keys/custMpk.pem b/arch/arm/mach-k3/keys/custMpk.pem
> > similarity index 100%
> > rename from board/ti/keys/custMpk.pem
> > rename to arch/arm/mach-k3/keys/custMpk.pem

Re: [PATCH v2 3/5] pinctrl: qcom: make compatible with linux DTs

2023-11-06 Thread Sumit Garg

On Mon, 6 Nov 2023 at 20:59, Caleb Connolly  wrote:
>
> The pinctrl and GPIO drivers are currently heavily incompatible with
> upstream. Most Qualcomm pinctrl blocks feature "tiles" of pins, each at
> it's own address. Introduce support for these by allowing the soc driver
> to specify per-pin register offsets similarly to the Linux driver.
>
> Adjust the GPIO driver to handle these too, and finally enable support
> for all pins with the same numbering as used in Linux.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/dts/dragonboard845c-uboot.dtsi  |  2 +-
>  arch/arm/dts/sdm845.dtsi | 16 ++
>  arch/arm/dts/starqltechn-uboot.dtsi  |  5 +---
>  arch/arm/dts/starqltechn.dts | 16 +-
>  arch/arm/mach-snapdragon/include/mach/gpio.h | 28 ++---
>  drivers/gpio/msm_gpio.c  | 36 --
>  drivers/pinctrl/qcom/pinctrl-apq8016.c   |  2 +-
>  drivers/pinctrl/qcom/pinctrl-apq8096.c   |  2 +-
>  drivers/pinctrl/qcom/pinctrl-ipq4019.c   |  2 +-
>  drivers/pinctrl/qcom/pinctrl-qcom.c  | 31 ---
>  drivers/pinctrl/qcom/pinctrl-qcom.h  |  5 +++-
>  drivers/pinctrl/qcom/pinctrl-qcs404.c|  2 +-
>  drivers/pinctrl/qcom/pinctrl-sdm845.c| 45 
> ++--
>  13 files changed, 130 insertions(+), 62 deletions(-)
>
> diff --git a/arch/arm/dts/dragonboard845c-uboot.dtsi 
> b/arch/arm/dts/dragonboard845c-uboot.dtsi
> index 7106db8a7348..7728f4f4a3e5 100644
> --- a/arch/arm/dts/dragonboard845c-uboot.dtsi
> +++ b/arch/arm/dts/dragonboard845c-uboot.dtsi
> @@ -19,7 +19,7 @@
> bootph-all;
> };
>
> -   pinctrl_north@390 {
> +   pinctrl@340 {
> bootph-all;
> };
> };
> diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
> index 3b86b9328fc6..4798ace0ff8b 100644
> --- a/arch/arm/dts/sdm845.dtsi
> +++ b/arch/arm/dts/sdm845.dtsi
> @@ -26,23 +26,13 @@
> #power-domain-cells = <1>;
> };
>
> -   gpio_north: gpio_north@390 {
> -   #gpio-cells = <2>;
> +   tlmm: pinctrl@340 {
> compatible = "qcom,sdm845-pinctrl";
> -   reg = <0x390 0x40>;
> -   gpio-count = <150>;
> -   gpio-controller;
> -   gpio-ranges = <_north 0 0 150>;
> -   gpio-bank-name = "soc_north.";
> -   };
> -
> -   tlmm_north: pinctrl_north@390 {
> -   compatible = "qcom,sdm845-pinctrl";
> -   reg = <0x390 0x40>;
> +   reg = <0x340 0xc0>;
> gpio-count = <150>;
> gpio-controller;
> #gpio-cells = <2>;
> -   gpio-ranges = <_north 0 0 150>;
> +   gpio-ranges = < 0 0 150>;
>
> /* DEBUG UART */
> qup_uart9: qup-uart9-default {
> diff --git a/arch/arm/dts/starqltechn-uboot.dtsi 
> b/arch/arm/dts/starqltechn-uboot.dtsi
> index d81a22ffe492..034d5c1c07ed 100644
> --- a/arch/arm/dts/starqltechn-uboot.dtsi
> +++ b/arch/arm/dts/starqltechn-uboot.dtsi
> @@ -19,10 +19,7 @@
> clock-controller@10 {
> bootph-all;
> };
> -   gpio_north@390 {
> -   bootph-all;
> -   };
> -   pinctrl_north@390 {
> +   pinctrl@340 {
> bootph-all;
> };
> };
> diff --git a/arch/arm/dts/starqltechn.dts b/arch/arm/dts/starqltechn.dts
> index eec51d165f98..5b6372bee79a 100644
> --- a/arch/arm/dts/starqltechn.dts
> +++ b/arch/arm/dts/starqltechn.dts
> @@ -65,15 +65,15 @@
> serial@a84000 {
> status = "okay";
> };
> +   };
> +};
>
> -   pinctrl_north@390 {
> -   muic_i2c: muic_i2c {
> -   pins = "GPIO_33", "GPIO_34";
> -   drive-strength = <0x2>;
> -   function = "gpio";
> -   bias-disable;
> -   };
> -   };
> + {
> +   muic_i2c: muic-i2c-n {
> +   pins = "GPIO_33", "GPIO_34";
> +   drive-strength = <0x2>;
> +   function = "gpio";
> +   bias-disable;
> };
>  };
>
> diff --git a/arch/arm/mach-snapdragon/include/mach/gpio.h 
> b/arch/arm/mach-snapdragon/include/mach/gpio.h
> index bbc2bc16175d..8dac62f870b9 100644
> --- a/arch/arm/mach-snapdragon/include/mach/gpio.h
> +++ b/arch/arm/mach-snapdragon/include/mach/gpio.h
> @@ -1,8 +1,28 @@
>  /*

Re: [PATCH v3] rockchip: include: asm: fix entering download mode rk3066




On 2023/10/28 02:35, Johan Jonker wrote:

Keep track of the re-entries with help of the lr register.
This binary can be re-used and called from various BROM functions.
Only when it's called from the part that handles SPI, NAND or EMMC
hardware it needs to early return to BROM ones.
In download mode when it handles data on USB OTG and UART0
this section must be skipped.

Unlike newer Rockchip SoC models the rk3066 BROM code does not have built-in
support to enter download mode on return to BROM. This binary must check
the boot mode register for the BOOT_BROM_DOWNLOAD flag and reset if it's set.
It then returns to BROM to the end of the function that reads boot blocks.
>From there the BROM code goes into a download mode and waits for data
on USB OTG and UART0.

Signed-off-by: Johan Jonker 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Note:
   Normal U-boot flow is OK.
   In download mode this binary hangs after return to BROM for unknown reasons.
   Replace CODE471_OPTION with 30_LPDDR2_300MHz_DD.bin for now.

Changed V3:
   Kconfig option for rk3066 only
   Restyle

Changed V2:
   Move file to rk3066 specific location
   Replace retry_counter by LR check
   Add DNL mode return address
   Restyle
   Reword
---
  arch/arm/include/asm/arch-rk3066/boot0.h | 77 +++-
  arch/arm/mach-rockchip/Kconfig   |  2 +-
  arch/arm/mach-rockchip/rk3066/Kconfig|  8 +++
  3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rk3066/boot0.h 
b/arch/arm/include/asm/arch-rk3066/boot0.h
index 28c0fb9a4c6b..6bf3828c84e9 100644
--- a/arch/arm/include/asm/arch-rk3066/boot0.h
+++ b/arch/arm/include/asm/arch-rk3066/boot0.h
@@ -3,6 +3,81 @@
  #ifndef __ASM_ARCH_BOOT0_H__
  #define __ASM_ARCH_BOOT0_H__

-#include 
+#include 

+/*
+ * Execution starts on the instruction following this 4-byte header
+ * (containing the magic 'RK30'). This magic constant will be written into
+ * the final image by the rkimage tool, but we need to reserve space for it 
here.
+ */
+#ifdef CONFIG_SPL_BUILD
+   b   1f  /* if overwritten, entry-address is at the next word */
+1:
+#endif
+
+#if CONFIG_IS_ENABLED(ROCKCHIP_EARLYRETURN_TO_BROM)
+/*
+ * Keep track of the re-entries with help of the lr register.
+ * This binary can be re-used and called from various BROM functions.
+ * Only when it's called from the part that handles SPI, NAND or EMMC
+ * hardware it needs to early return to BROM ones.
+ * In download mode when it handles data on USB OTG and UART0
+ * this section must be skipped.
+ */
+   ldr r3, =CONFIG_ROCKCHIP_BOOT_LR_REG
+   cmp lr, r3  /* if (LR != CONFIG_ROCKCHIP_BOOT_LR_REG)   
 */
+   bne reset   /* goto reset;  
 */
+/*
+ * Unlike newer Rockchip SoC models the rk3066 BROM code does not have built-in
+ * support to enter download mode on return to BROM. This binary must check
+ * the boot mode register for the BOOT_BROM_DOWNLOAD flag and reset if it's 
set.
+ * It then returns to BROM to the end of the function that reads boot blocks.
+ * From there the BROM code goes into a download mode and waits for data
+ * on USB OTG and UART0.
+ */
+   ldr r2, =BOOT_BROM_DOWNLOAD
+   ldr r3, =CONFIG_ROCKCHIP_BOOT_MODE_REG
+   ldr r0, [r3]/* if (readl(CONFIG_ROCKCHIP_BOOT_MODE_REG) !=  
 */
+   cmp r0, r2  /* BOOT_BROM_DOWNLOAD) {
 */
+   bne early_return/* goto early_return;   
 */
+   /* } else { 
 */
+   mov r0, #0
+   str r0, [r3]/* writel(0, 
CONFIG_ROCKCHIP_BOOT_MODE_REG); */
+
+   ldr r3, =CONFIG_ROCKCHIP_BOOT_RETURN_REG
+   bx  r3  /* return to 
CONFIG_ROCKCHIP_BOOT_RETURN_REG;*/
+   /* }
 */
+early_return:
+   bx  lr  /* return to LR in BROM 
 */
+
+SAVE_SP_ADDR:
+   .word 0
+
+   .globl save_boot_params
+save_boot_params:
+   push{r1-r12, lr}
+   ldr r0, =SAVE_SP_ADDR
+   str sp, [r0]
+   b   save_boot_params_ret
+
+   .globl back_to_bootrom
+back_to_bootrom:
+   ldr r0, =SAVE_SP_ADDR
+   ldr sp, [r0]
+   mov r0, #0
+   pop {r1-r12, pc}
+#endif
+
+#if (defined(CONFIG_SPL_BUILD))
+/* U-Boot proper of armv7 does not need this */
+   b reset
+#endif
+
+/*
+ * For armv7, the addr '_start' will be used as vector start address
+ * and is written to the VBAR register, which needs to aligned to 0x20.
+ */
+   .align(5), 0x0
+_start:
+   ARM_VECTORS
  #endif
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index c43c185c17c5..6c56324f66bc 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -401,7 +401,7 @@

Re: [PATCH] rockchip: dts: fix bootph tags for rv1126




On 2023/10/30 21:12, Tim Lunn wrote:

RV1126 fails to boot on 2024.01-rc1.

Commit 9e64428 changed the behaviour of bootph-pre-ram, to limit
nodes to spl phase. This caused rv1126 boards to fail to boot
with the current dts.

This patch updates the pmu/grf nodes to bootph-all tags as they are
needed in all phases. This fixes the boot issue on rv1126 boards.

Signed-off-by: Tim Lunn 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rv1126-u-boot.dtsi | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/rv1126-u-boot.dtsi b/arch/arm/dts/rv1126-u-boot.dtsi
index 5e348278f2..918c307743 100644
--- a/arch/arm/dts/rv1126-u-boot.dtsi
+++ b/arch/arm/dts/rv1126-u-boot.dtsi
@@ -26,15 +26,15 @@
  };
  
   {

-   bootph-pre-ram;
+   bootph-all;
  };
  
   {

-   bootph-pre-ram;
+   bootph-all;
  };
  
   {

-   bootph-pre-ram;
+   bootph-all;
  };
  
   {

Re: [PATCH 2/2] rockchip: rv1126: Read cpuid from otp and set ethaddr




On 2023/10/31 10:07, Tim Lunn wrote:

Provide configuration to read cpuid and generate a persistant
MAC address in ethaddr

Signed-off-by: Tim Lunn 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rv1126-u-boot.dtsi | 12 
  arch/arm/mach-rockchip/Kconfig  |  2 ++
  2 files changed, 14 insertions(+)

diff --git a/arch/arm/dts/rv1126-u-boot.dtsi b/arch/arm/dts/rv1126-u-boot.dtsi
index 5e348278f2..811a3cee98 100644
--- a/arch/arm/dts/rv1126-u-boot.dtsi
+++ b/arch/arm/dts/rv1126-u-boot.dtsi
@@ -15,6 +15,18 @@
compatible = "rockchip,rv1126-dmc";
bootph-all;
};
+
+   otp: otp@ff5c {
+   compatible = "rockchip,rv1126-otp";
+   reg = <0xff5c 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "okay";
+
+   cpu_id: id@7 {
+   reg = <0x07 0x10>;
+   };
+   };
  };
  
   {

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index a6c69c300d..5e993383cf 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -359,6 +359,8 @@ config ROCKCHIP_RV1126
select BOARD_LATE_INIT
imply ROCKCHIP_COMMON_BOARD
imply OF_LIBFDT_OVERLAY
+   imply ROCKCHIP_OTP
+   imply MISC_INIT_R
imply TPL_DM
imply TPL_LIBCOMMON_SUPPORT
imply TPL_LIBGENERIC_SUPPORT

Re: [PATCH 1/2] rockchip: otp: Add support for RV1126




On 2023/10/31 10:07, Tim Lunn wrote:

Extend the otp driver to read rv1126 otp. This driver code was
adapted from the Rockchip BSP stack.

Signed-off-by: Tim Lunn 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/misc/rockchip-otp.c | 76 +
  1 file changed, 76 insertions(+)

diff --git a/drivers/misc/rockchip-otp.c b/drivers/misc/rockchip-otp.c
index 4814e0e501..4f757083a1 100644
--- a/drivers/misc/rockchip-otp.c
+++ b/drivers/misc/rockchip-otp.c
@@ -61,11 +61,20 @@
  #define RK3588_OTPC_INT_ST0x0084
  #define RK3588_RD_DONEBIT(1)
  
+#define RV1126_OTP_NVM_CEB		0x00

+#define RV1126_OTP_NVM_RSTB0x04
+#define RV1126_OTP_NVM_ST  0x18
+#define RV1126_OTP_NVM_RADDR   0x1C
+#define RV1126_OTP_NVM_RSTART  0x20
+#define RV1126_OTP_NVM_RDATA   0x24
+#define RV1126_OTP_READ_ST 0x30
+
  struct rockchip_otp_plat {
void __iomem *base;
  };
  
  struct rockchip_otp_data {

+   int (*init)(struct udevice *dev);
int (*read)(struct udevice *dev, int offset, void *buf, int size);
int offset;
int size;
@@ -232,6 +241,48 @@ static int rockchip_rk3588_otp_read(struct udevice *dev, 
int offset,
return 0;
  }
  
+static int rockchip_rv1126_otp_init(struct udevice *dev)

+{
+   struct rockchip_otp_plat *otp = dev_get_plat(dev);
+   int ret;
+
+   writel(0x0, otp->base + RV1126_OTP_NVM_CEB);
+   ret = rockchip_otp_poll_timeout(otp, 0x1, RV1126_OTP_NVM_ST);
+
+   if (ret)
+   return ret;
+
+   writel(0x1, otp->base + RV1126_OTP_NVM_RSTB);
+   ret = rockchip_otp_poll_timeout(otp, 0x4, RV1126_OTP_NVM_ST);
+
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int rockchip_rv1126_otp_read(struct udevice *dev, int offset, void *buf,
+   int size)
+{
+   struct rockchip_otp_plat *otp = dev_get_plat(dev);
+   u32 status = 0;
+   u8 *buffer = buf;
+   int ret = 0;
+
+   while (size--) {
+   writel(offset++, otp->base + RV1126_OTP_NVM_RADDR);
+   writel(0x1, otp->base + RV1126_OTP_NVM_RSTART);
+   ret = readl_poll_timeout(otp->base + RV1126_OTP_READ_ST,
+status, !status, OTPC_TIMEOUT);
+   if (ret)
+   return ret;
+
+   *buffer++ = (u8)(readl(otp->base + RV1126_OTP_NVM_RDATA) & 
0xFF);
+   }
+
+   return 0;
+}
+
  static int rockchip_otp_read(struct udevice *dev, int offset,
 void *buf, int size)
  {
@@ -286,6 +337,20 @@ static int rockchip_otp_of_to_plat(struct udevice *dev)
return 0;
  }
  
+static int rockchip_otp_probe(struct udevice *dev)

+{
+   struct rockchip_otp_data *data;
+
+   data = (struct rockchip_otp_data *)dev_get_driver_data(dev);
+   if (!data)
+   return -EINVAL;
+
+   if (data->init)
+   return data->init(dev);
+
+   return 0;
+}
+
  static const struct rockchip_otp_data px30_data = {
.read = rockchip_px30_otp_read,
.size = 0x40,
@@ -304,6 +369,12 @@ static const struct rockchip_otp_data rk3588_data = {
.block_size = 4,
  };
  
+static const struct rockchip_otp_data rv1126_data = {

+   .init = rockchip_rv1126_otp_init,
+   .read = rockchip_rv1126_otp_read,
+   .size = 0x40,
+};
+
  static const struct udevice_id rockchip_otp_ids[] = {
{
.compatible = "rockchip,px30-otp",
@@ -321,6 +392,10 @@ static const struct udevice_id rockchip_otp_ids[] = {
.compatible = "rockchip,rk3588-otp",
.data = (ulong)_data,
},
+   {
+   .compatible = "rockchip,rv1126-otp",
+   .data = (ulong)_data,
+   },
{}
  };
  
@@ -331,4 +406,5 @@ U_BOOT_DRIVER(rockchip_otp) = {

.of_to_plat = rockchip_otp_of_to_plat,
.plat_auto = sizeof(struct rockchip_otp_plat),
.ops = _otp_ops,
+   .probe = rockchip_otp_probe,
  };

Re: [PATCH v2 2/2] rockchip: ringneck-px30: enable SPL_BOARD_INIT




On 2023/11/3 17:28, Quentin Schulz wrote:

From: Quentin Schulz 

Now that Ringneck requires some board-specific code (namely resetting
the MCU companion controller) to be run during SPL stage, let's enable
SPL_BOARD_INIT.

Cc: Quentin Schulz 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  configs/ringneck-px30_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig
index b4666d0e90f..420c9cd1e89 100644
--- a/configs/ringneck-px30_defconfig
+++ b/configs/ringneck-px30_defconfig
@@ -38,6 +38,7 @@ CONFIG_SPL_PAD_TO=0x0
  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
  CONFIG_SPL_BSS_START_ADDR=0x400
  CONFIG_SPL_BSS_MAX_SIZE=0x4000
+CONFIG_SPL_BOARD_INIT=y
  CONFIG_SPL_BOOTROM_SUPPORT=y
  # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set

Re: [PATCH v2 1/2] rockchip: ringneck-px30: always reset STM32 companion controller on boot




On 2023/11/3 17:28, Quentin Schulz wrote:

From: Quentin Schulz 

It's happened that glitches on the STM32_RST and STM32_BOOT lines have
put the STM32 companion microcontroller into DFU mode making it not boot
its FW, rendering it useless for the user.

Considering that the STM32 companion microcontroller is always reset on
a reboot or power cycle, resetting it once again in U-Boot SPL isn't
going to hurt it any more.

For ATtiny companion microcontroller, the situation is a bit different
because a reboot or power cycle doesn't reset it. Additionally, since it
can only be reset with a UPDI reset on the STM32_RST line, and that is
virtually impossible to mistakenly trigger, the ATtiny is unlikely to be
in unwanted reset or enter reset because U-Boot toggles STM32_RST line.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  .../ringneck_px30/ringneck-px30.c  | 53 ++
  1 file changed, 53 insertions(+)

diff --git a/board/theobroma-systems/ringneck_px30/ringneck-px30.c 
b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
index bb1bb4acf5c..537ce0d1d11 100644
--- a/board/theobroma-systems/ringneck_px30/ringneck-px30.c
+++ b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
@@ -16,12 +16,14 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -169,3 +171,54 @@ int misc_init_r(void)
  
  	return 0;

  }
+
+#define STM32_RST  100 /* GPIO3_A4 */
+#define STM32_BOOT 101 /* GPIO3_A5 */
+
+void spl_board_init(void)
+{
+   /*
+* Glitches on STM32_BOOT and STM32_RST lines during poweroff or power
+* on may put the STM32 companion microcontroller into DFU mode, let's
+* always reset it into normal mode instead.
+* Toggling the STM32_RST line is safe to do with the ATtiny companion
+* microcontroller variant because it will not trigger an MCU reset
+* since only a UPDI reset command will. Since a UPDI reset is difficult
+* to mistakenly trigger, glitches to the lines are theoretically also
+* incapable of triggering an actual ATtiny reset.
+*/
+   int ret;
+
+   ret = gpio_request(STM32_RST, "STM32_RST");
+   if (ret) {
+   debug("Failed to request STM32_RST\n");
+   return;
+   }
+
+   ret = gpio_request(STM32_BOOT, "STM32_BOOT");
+   if (ret) {
+   debug("Failed to request STM32_BOOT\n");
+   return;
+   }
+
+   /* Rely on HW pull-down for inactive level */
+   ret = gpio_direction_input(STM32_BOOT);
+   if (ret) {
+   debug("Failed to configure STM32_BOOT as input\n");
+   return;
+   }
+
+   ret = gpio_direction_output(STM32_RST, 0);
+   if (ret) {
+   debug("Failed to configure STM32_RST as output low\n");
+   return;
+   }
+
+   mdelay(1);
+
+   ret = gpio_direction_output(STM32_RST, 1);
+   if (ret) {
+   debug("Failed to configure STM32_RST as output high\n");
+   return;
+   }
+}

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

Hi Tom,

On Mon, 6 Nov 2023 at 13:46, Tom Rini  wrote:
>
> On Mon, Nov 06, 2023 at 01:38:39PM -0700, Simon Glass wrote:
> > Hi Andre,
> >
> > On Mon, 6 Nov 2023 at 10:26, Andre Przywara  wrote:
> > >
> > > On Sat, 4 Nov 2023 19:45:06 +
> > > Simon Glass  wrote:
> > >
> > > Hi,
> > >
> > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara  
> > > > wrote:
> > > > >
> > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > Simon Glass  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > Hi Heinrich,
> > > > > >
> > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > >  wrote:
> > > > > > >
> > > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > Heinrich Schuchardt  wrote:
> > > > > > > >
> > > > > > > > Hi Heinrich,
> > > > > > > >
> > > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed 
> > > > > > > >> CSR. It
> > > > > > > >> provides an interface to a physical entropy source.
> > > > > > > >>
> > > > > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > > > >
> > > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > > respective Arm
> > > > > > > > functionality:
> > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > >
> > > > > > > > And I see that you seem to use the same mechanism to probe and 
> > > > > > > > init the
> > > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > > > > implemented.
> > > > > > > > One downside of this approach is that the driver is always 
> > > > > > > > loaded (and
> > > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > > available.
> > > > > > > > That doesn't seem too much of a problem on the first glance, 
> > > > > > > > but it
> > > > > > > > occupies a device number, and any subsequent other DM_RNG 
> > > > > > > > devices
> > > > > > > > (like virtio-rng) typically get higher device numbers. So 
> > > > > > > > without
> > > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > > VExpress64# rng 0
> > > > > > > > No RNG device
> > > > > >
> > > > > > Why do we get this? If the device is not there, the bind() function
> > > > > > can return -ENODEV
> > > > > >
> > > > > > I see this in U-Boot:
> > > > > >
> > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > >
> > > > > > We should not use this.
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > Use the devicetree.
> > > > >
> > > > > No, this is definitely not something for the DT, at least not on ARM.
> > > > > It's perfectly discoverable via the architected CPU ID registers.
> > > > > Similar to PCI and USB devices, which we don't probe via the DT as 
> > > > > well.
> > > > >
> > > > > It's arguably not proper "driver" material per se, as I've argued 
> > > > > before, but
> > > > > it's the simplest solution and fits in nicely otherwise.
> > > > >
> > > > > I was wondering if it might be something for UCLASS_CPU, something 
> > > > > like
> > > > > a "CPU feature bus": to let devices register on one on the many CPU
> > > > > features (instead of compatible strings), then only bind() those
> > > > > drivers it the respective bit is set.
> > > > >
> > > > > Does that make sense? Would that be doable without boiling the ocean?
> > > > > As I don't know if we see many users apart from this.
> > > >
> > > > I have seen this so many times, where people want to avoid putting
> > > > things in the DT and then are surprised that everything is difficult,
> > > > broken and confusing. Why not just follow the rules? It is not just
> > > > about whether we can avoid it, etc. It is about how devices fit
> > > > together cohesively in the system, and how U-Boot operates.
> > >
> > > A devicetree is only for peripherals *that cannot be located by probing*.
> >
> > I have to stop you there. It absolutely is not limited to that.
>
> It is limited to that if we're going to keep using the device trees that
> Linux uses. Full stop. There's not really wiggle room there either.

That is really the problem, I agree.

But I would be happy with a u-boot.dtsi file to resolve this, while we
wait. I believe a binding makes sense in this case.

Regards,
Simon

Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow

Hi Tony,

On Mon, 6 Nov 2023 at 23:41, Tony Dinh  wrote:
>
> Hi Simon,
>
> On Mon, Nov 6, 2023 at 12:51 PM Tony Dinh  wrote:
> >
> > On Mon, Nov 6, 2023 at 11:51 AM Tom Rini  wrote:
> > >
> > > On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
> > > > Hi Simon,
> > > >
> > > > On Mon, Nov 6, 2023 at 9:25 AM Simon Glass  wrote:
> > > > >
> > > > > Hi Tony,
> > > > >
> > > > > On Wed, 4 Oct 2023 at 21:23, Tony Dinh  wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh  wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Tony,
> > > > > > > >
> > > > > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tony,
> > > > > > > > > >
> > > > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > Here is an observation during testing the bootflow 
> > > > > > > > > > > command.
> > > > > > > > > > >
> > > > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow 
> > > > > > > > > > > will remove that existing
> > > > > > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI 
> > > > > > > > > > > bootflow again, and it was
> > > > > > > > > > > back to normal. Perhaps there is some kind of indexing 
> > > > > > > > > > > problem?
> > > > > > > > > >
> > > > > > > > > > Yes that's right. The 'botflow scan' command is not 
> > > > > > > > > > additive. The
> > > > > > > > > > first thing it does is removing existing bootflows.
> > > > > > > > >
> > > > > > > > > Thanks for clarifying that. I assumed it is additive, because 
> > > > > > > > > the
> > > > > > > > > existing USB bootflow was not removed when I did a "bootflow 
> > > > > > > > > scan
> > > > > > > > > scsi" immediately after (see the end of the log).
> > > > > > > >
> > > > > > > > Yes, but I'm not sure what is going on there. Perhaps it is a 
> > > > > > > > bug?
> > > > > > > > When you scan SCSI it should not also scan USB.
> > > > > > >
> > > > > > > Yes, it looks like a bug. I think I can see the problem and am 
> > > > > > > working
> > > > > > > on a patch.
> > > > > >
> > > > > > Just to let you know, I'm out of time to work on this topic. I will
> > > > > > revisit it some other time, if you have not already tracked it down.
> > > > >
> > > > > If you are able to use 'bootflow scan -l' in each case, then I might
> > > > > be able to see what it is scanning USB, when you are asking for SCSI.
> > > > > I also wonder if this bug may have been fixed due to other changes?
> > > >
> > > > I'm wondering about that, too. I will rerun the test with the master
> > > > branch with debug trace. If we cannot see it, I'll do it again when
> > > > other bootstd patches are merged. Right now I am not sure which of
> > > > your bootstd patches I should apply to the tree for testing, do you
> > > > have a list for that?
> > >
> > > Right now the only outstanding bootstd patch I know of is your recent
> > > one, as I was waiting for Simon's review (which he did today) before
> > > merging and applying.
> >
> > Thanks Tom! I'll run the test in my tree as is then.
>
> The good news: apparently one of your recent bootstd patches has fixed
> this problem! I think your bootstd mmc scanning patch is probably
> where it was fixed.
>
> I tested with rc2 plus my recent patch (not yet merged to master) in the tree:
> https://patchwork.ozlabs.org/project/uboot/patch/20231102185116.21708-1-mibo...@gmail.com/
>
> For future reference, I've included the log here after the break.
>
> All the best,
> Tony
>
> 
> 
>
> U-Boot 2024.01-rc2-tld-1-2-g148117d278 (Nov 06 2023 - 13:36:33 -0800)
> Thecus N2350
>
> SoC:   MV88F6820-A0 at 1066 MHz
> DRAM:  1 GiB (533 MHz, 32-bit, ECC not enabled)
> Core:  65 devices, 23 uclasses, devicetree: separate
> NAND:  512 MiB
> MMC:
> Loading Environment from SPIFlash... SF: Detected mx25l3205d with page
> size 256 Bytes, erase size 4 KiB, total 4 MiB
> *** Warning - bad CRC, using default environment
>
> Model: Thecus N2350
> Net:
> Warning: ethernet@7 (eth0) using random MAC address - 2e:49:f0:ba:d8:b8
> eth0: ethernet@7
> Hit any key to stop autoboot:  0
> N2350 > setenv def -a
> N2350 > bootdev l
> Seq  Probed  Status  UclassName
> ---  --  --    --
>   0   [   ]  OK  ethernet  ethernet@7.bootdev
> ---  --  --    --
> (1 bootdev)
>
> N2350 > bootflow scan usb
> Bus usb@58000: USB EHCI 1.00
> Bus usb3@f: MVEBU XHCI INIT controller @ 0xf10f4000
> Register 2000120 NbrPorts 2
> Starting the controller
>

Re: [PATCH 1/4] bootm: Allow ignoring the load address with kernel_noload

Hi Tom,

On Mon, 6 Nov 2023 at 13:15, Tom Rini  wrote:
>
> On Mon, Nov 06, 2023 at 12:58:46PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> >
> > On Mon, 6 Nov 2023 at 11:30, Tom Rini  wrote:
> > >
> > > On Mon, Nov 06, 2023 at 10:25:00AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 5 Nov 2023 at 14:19, Tom Rini  wrote:
> > > > >
> > > > > On Sun, Nov 05, 2023 at 01:03:51PM -0700, Simon Glass wrote:
> > > > >
> > > > > > This image type is supposed to ignore the load address. But at 
> > > > > > present
> > > > > > it fails if the load address is missing. If it is zero, the image is
> > > > > > loaded at address 0, which may not work on all boards.
> > > > > >
> > > > > > Make use of the kernel_addr_r environment variable, instead, since 
> > > > > > this
> > > > > > seems to be a more reliable final address for the kernel.
> > > > > >
> > > > > > Another option would be to create a new Kconfig for this, or to use 
> > > > > > a
> > > > > > region of memory known to be free, e.g. calculated from the DRAM 
> > > > > > banks.
> > > > > > But in any case we should try to avoid conflicting with the
> > > > > > kernel_addr_r variable. So the approach in this patch seems 
> > > > > > reasonable
> > > > > > to me.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > >
> > > > > How are you creating the image in question here? A noload FIT is
> > > > > supposed to just supposed to go from where it is. Where do things fall
> > > > > down later?
> > > >
> > > > The image is Image.gz built by Linux, for example. So compression =
> > > > "gzip" which means that it has to be decompressed.
> > > >
> > > > Things fall down as soon as U-Boot looks at the image, since it
> > > > doesn't have the ARM64 magic.
> > >
> > > Can you provide logs and env? "booti" is supposed to handle this case
> > > already, and if it's not we should figure out when / why it broke.
> >
> > Do you mean booti handles compression? Yes, I can see that in the code.
>
> Yes, you use "booti" with an Image.gz.
>
> > But in my case I am using bootm, since it is a FIT.
>
> Shouldn't this be handled by the normal compression = "foo" logic? And in
> turn is that what's not working? If so, the commit messages aren't
> clear.

We are on the wrong commit here. See this one:

https://patchwork.ozlabs.org/project/uboot/patch/20231105130351.2.Ie34b75c75347a1c04bffa780220afe9011b0e2bb@changeid/

Perhaps this is supposed to work some other way, but to me it seems
quite broken at present.

Regards,
Simon

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

Hi Andre,

On Mon, 6 Nov 2023 at 21:55, Andre Przywara  wrote:
>
> On Mon, 6 Nov 2023 13:38:39 -0700
> Simon Glass  wrote:
>
> Hi Simon,
>
> > On Mon, 6 Nov 2023 at 10:26, Andre Przywara  wrote:
> > >
> > > On Sat, 4 Nov 2023 19:45:06 +
> > > Simon Glass  wrote:
> > >
> > > Hi,
> > >
> > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara  
> > > > wrote:
> > > > >
> > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > Simon Glass  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > Hi Heinrich,
> > > > > >
> > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > >  wrote:
> > > > > > >
> > > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > Heinrich Schuchardt  wrote:
> > > > > > > >
> > > > > > > > Hi Heinrich,
> > > > > > > >
> > > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed 
> > > > > > > >> CSR. It
> > > > > > > >> provides an interface to a physical entropy source.
> > > > > > > >>
> > > > > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > > > >
> > > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > > respective Arm
> > > > > > > > functionality:
> > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > >
> > > > > > > > And I see that you seem to use the same mechanism to probe and 
> > > > > > > > init the
> > > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > > > > implemented.
> > > > > > > > One downside of this approach is that the driver is always 
> > > > > > > > loaded (and
> > > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > > available.
> > > > > > > > That doesn't seem too much of a problem on the first glance, 
> > > > > > > > but it
> > > > > > > > occupies a device number, and any subsequent other DM_RNG 
> > > > > > > > devices
> > > > > > > > (like virtio-rng) typically get higher device numbers. So 
> > > > > > > > without
> > > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > > VExpress64# rng 0
> > > > > > > > No RNG device
> > > > > >
> > > > > > Why do we get this? If the device is not there, the bind() function
> > > > > > can return -ENODEV
> > > > > >
> > > > > > I see this in U-Boot:
> > > > > >
> > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > >
> > > > > > We should not use this.
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > Use the devicetree.
> > > > >
> > > > > No, this is definitely not something for the DT, at least not on ARM.
> > > > > It's perfectly discoverable via the architected CPU ID registers.
> > > > > Similar to PCI and USB devices, which we don't probe via the DT as 
> > > > > well.
> > > > >
> > > > > It's arguably not proper "driver" material per se, as I've argued 
> > > > > before, but
> > > > > it's the simplest solution and fits in nicely otherwise.
> > > > >
> > > > > I was wondering if it might be something for UCLASS_CPU, something 
> > > > > like
> > > > > a "CPU feature bus": to let devices register on one on the many CPU
> > > > > features (instead of compatible strings), then only bind() those
> > > > > drivers it the respective bit is set.
> > > > >
> > > > > Does that make sense? Would that be doable without boiling the ocean?
> > > > > As I don't know if we see many users apart from this.
> > > >
> > > > I have seen this so many times, where people want to avoid putting
> > > > things in the DT and then are surprised that everything is difficult,
> > > > broken and confusing. Why not just follow the rules? It is not just
> > > > about whether we can avoid it, etc. It is about how devices fit
> > > > together cohesively in the system, and how U-Boot operates.
> > >
> > > A devicetree is only for peripherals *that cannot be located by probing*.
> >
> > I have to stop you there. It absolutely is not limited to that.
>
> I am very sorry, but I - (and seemingly everyone else in the kernel DT
> community?) - seem to disagree here.

Really? Where is that even coming from? Certainly not the DT spec.


>
> > > Which are traditionally most peripherals in non-server Arm SoCs. While I
> > > do love the DT, the best DT node is the one you don't need.
> >
> > We need it in U-Boot, at least.
> >
> > I'll send a patch with a warning on U_BOOT_DRVINFO() as it seems that
> > some people did not see the header-file comment.
>
> Fair enough.
>
> > Let's just stop this discussion and instead talk about the binding we need.
>
> Alright, if that is your decision, I will send a patch to revert
> that "driver". There will never be a binding for a CPU instruction
> discoverable by the architected CPU ID register.

That statement just mystifies me. Why not just send a binding? Even
the people that complain that DT should only describe hardware will be
happy with it.

The code you sent

Re: [PATCH 5/4] mkimage: update man page and -h output

2023-11-06 Thread Sean Anderson


On 10/13/23 14:30, Rasmus Villemoes wrote:

On 12/10/2023 04.17, Sean Anderson wrote:


I was hoping you would respond to my most-recent email regarding this
series.
In particular:

| Why does mkimage have to do this? Can't you just use truncate or, in a
| binman context, align-size?


In both cases, that just affects the size of the file, but does not
affect the totalsize field in the fdt header.


Use `dtc -a` then.


Wrt. binman, just as I was somewhat misled by the short mkimage -h
output into thinking that this already worked as I expected, binman's
fit,align documentation can also be read that way - and the
_implementation_ certainly currently unconditionally translates a
fit,align property into a -B argument to mkimage. So if we don't want
mkimage to support a -B by itself, binman documentation and code would
probably need another patch to reject that as well.


Yeah, that's a good idea.

--Sean

[PATCH] usb: gadget: f_mass_storage: Stop ums on START-STOP UNIT SCSI command

2023-11-06 Thread Marek Vasut

Exit the UMS handler loop in case START-STOP UNIT SCSI command is
received. This is sent e.g. by the util-linux eject(1) command and
indicates to the device that it is supposed to spin down the media
and enter low power state.

This effectively adds support for exitting the 'ums' command from
host using 'eject /dev/sdN' that is on par with 'dfu-util -e' .

Signed-off-by: Marek Vasut 
---
Cc: Lukasz Majewski 
Cc: Mattijs Korpershoek 
---
 drivers/usb/gadget/f_mass_storage.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/gadget/f_mass_storage.c 
b/drivers/usb/gadget/f_mass_storage.c
index 1d17331cb03..c725aed3f62 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -327,6 +327,7 @@ struct fsg_common {
unsigned intshort_packet_received:1;
unsigned intbad_lun_okay:1;
unsigned intrunning:1;
+   unsigned inteject:1;
 
int thread_wakeup_needed;
struct completion   thread_notifier;
@@ -669,6 +670,10 @@ static int sleep_thread(struct fsg_common *common)
}
 
if (k == 10) {
+   /* Handle START-STOP UNIT */
+   if (common->eject)
+   return -EPIPE;
+
/* Handle CTRL+C */
if (ctrlc())
return -EPIPE;
@@ -1325,6 +1330,8 @@ static int do_start_stop(struct fsg_common *common)
return -EINVAL;
}
 
+   common->eject = 1;
+
return 0;
 }
 
-- 
2.42.0

[PATCH] firmware: scmi: correct a validity check against power domain id

2023-11-06 Thread AKASHI Takahiro

A power domain id on sandbox should be in the range from zero to
ARRAY_SIZE(scmi_pwdom) - 1. Correct the validity check logic.

Signed-off-by: AKASHI Takahiro 
Fixes: CID 467401
Fixes: CID 467405
---
 drivers/firmware/scmi/sandbox-scmi_agent.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c 
b/drivers/firmware/scmi/sandbox-scmi_agent.c
index 9f5f497e0a6c..d13180962662 100644
--- a/drivers/firmware/scmi/sandbox-scmi_agent.c
+++ b/drivers/firmware/scmi/sandbox-scmi_agent.c
@@ -576,7 +576,7 @@ static int sandbox_scmi_pwd_attribs(struct udevice *dev, 
struct scmi_msg *msg)
domain_id = *(u32 *)msg->in_msg;
out = (struct scmi_pwd_attrs_out *)msg->out_msg;
 
-   if (domain_id > ARRAY_SIZE(scmi_pwdom)) {
+   if (domain_id >= ARRAY_SIZE(scmi_pwdom)) {
out->status = SCMI_NOT_FOUND;
 
return 0;
@@ -613,7 +613,7 @@ static int sandbox_scmi_pwd_state_set(struct udevice *dev, 
struct scmi_msg *msg)
in = (struct scmi_pwd_state_set_in *)msg->in_msg;
status = (s32 *)msg->out_msg;
 
-   if (in->domain_id > ARRAY_SIZE(scmi_pwdom)) {
+   if (in->domain_id >= ARRAY_SIZE(scmi_pwdom)) {
*status = SCMI_NOT_FOUND;
 
return 0;
@@ -653,7 +653,7 @@ static int sandbox_scmi_pwd_state_get(struct udevice *dev, 
struct scmi_msg *msg)
domain_id = *(u32 *)msg->in_msg;
out = (struct scmi_pwd_state_get_out *)msg->out_msg;
 
-   if (domain_id > ARRAY_SIZE(scmi_pwdom)) {
+   if (domain_id >= ARRAY_SIZE(scmi_pwdom)) {
out->status = SCMI_NOT_FOUND;
 
return 0;
@@ -686,7 +686,7 @@ static int sandbox_scmi_pwd_name_get(struct udevice *dev, 
struct scmi_msg *msg)
domain_id = *(u32 *)msg->in_msg;
out = (struct scmi_pwd_name_get_out *)msg->out_msg;
 
-   if (domain_id > ARRAY_SIZE(scmi_pwdom)) {
+   if (domain_id >= ARRAY_SIZE(scmi_pwdom)) {
out->status = SCMI_NOT_FOUND;
 
return 0;
-- 
2.34.1

Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow

2023-11-06 Thread Tony Dinh

Hi Simon,

On Mon, Nov 6, 2023 at 12:51 PM Tony Dinh  wrote:
>
> On Mon, Nov 6, 2023 at 11:51 AM Tom Rini  wrote:
> >
> > On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
> > > Hi Simon,
> > >
> > > On Mon, Nov 6, 2023 at 9:25 AM Simon Glass  wrote:
> > > >
> > > > Hi Tony,
> > > >
> > > > On Wed, 4 Oct 2023 at 21:23, Tony Dinh  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh  wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Tony,
> > > > > > >
> > > > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Tony,
> > > > > > > > >
> > > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > Here is an observation during testing the bootflow command.
> > > > > > > > > >
> > > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will 
> > > > > > > > > > remove that existing
> > > > > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI 
> > > > > > > > > > bootflow again, and it was
> > > > > > > > > > back to normal. Perhaps there is some kind of indexing 
> > > > > > > > > > problem?
> > > > > > > > >
> > > > > > > > > Yes that's right. The 'botflow scan' command is not additive. 
> > > > > > > > > The
> > > > > > > > > first thing it does is removing existing bootflows.
> > > > > > > >
> > > > > > > > Thanks for clarifying that. I assumed it is additive, because 
> > > > > > > > the
> > > > > > > > existing USB bootflow was not removed when I did a "bootflow 
> > > > > > > > scan
> > > > > > > > scsi" immediately after (see the end of the log).
> > > > > > >
> > > > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug?
> > > > > > > When you scan SCSI it should not also scan USB.
> > > > > >
> > > > > > Yes, it looks like a bug. I think I can see the problem and am 
> > > > > > working
> > > > > > on a patch.
> > > > >
> > > > > Just to let you know, I'm out of time to work on this topic. I will
> > > > > revisit it some other time, if you have not already tracked it down.
> > > >
> > > > If you are able to use 'bootflow scan -l' in each case, then I might
> > > > be able to see what it is scanning USB, when you are asking for SCSI.
> > > > I also wonder if this bug may have been fixed due to other changes?
> > >
> > > I'm wondering about that, too. I will rerun the test with the master
> > > branch with debug trace. If we cannot see it, I'll do it again when
> > > other bootstd patches are merged. Right now I am not sure which of
> > > your bootstd patches I should apply to the tree for testing, do you
> > > have a list for that?
> >
> > Right now the only outstanding bootstd patch I know of is your recent
> > one, as I was waiting for Simon's review (which he did today) before
> > merging and applying.
>
> Thanks Tom! I'll run the test in my tree as is then.

The good news: apparently one of your recent bootstd patches has fixed
this problem! I think your bootstd mmc scanning patch is probably
where it was fixed.

I tested with rc2 plus my recent patch (not yet merged to master) in the tree:
https://patchwork.ozlabs.org/project/uboot/patch/20231102185116.21708-1-mibo...@gmail.com/

For future reference, I've included the log here after the break.

All the best,
Tony




U-Boot 2024.01-rc2-tld-1-2-g148117d278 (Nov 06 2023 - 13:36:33 -0800)
Thecus N2350

SoC:   MV88F6820-A0 at 1066 MHz
DRAM:  1 GiB (533 MHz, 32-bit, ECC not enabled)
Core:  65 devices, 23 uclasses, devicetree: separate
NAND:  512 MiB
MMC:
Loading Environment from SPIFlash... SF: Detected mx25l3205d with page
size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

Model: Thecus N2350
Net:
Warning: ethernet@7 (eth0) using random MAC address - 2e:49:f0:ba:d8:b8
eth0: ethernet@7
Hit any key to stop autoboot:  0
N2350 > setenv def -a
N2350 > bootdev l
Seq  Probed  Status  UclassName
---  --  --    --
  0   [   ]  OK  ethernet  ethernet@7.bootdev
---  --  --    --
(1 bootdev)

N2350 > bootflow scan usb
Bus usb@58000: USB EHCI 1.00
Bus usb3@f: MVEBU XHCI INIT controller @ 0xf10f4000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@58000 for devices... 1 USB Device(s) found
scanning bus usb3@f for devices... 1 USB Device(s) found
scanning bus usb3@f8000 for devices... 2 USB Device(s) found
** File not found /boot/boot.bmp **

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-06 Thread Andre Przywara

On Mon, 6 Nov 2023 13:38:39 -0700
Simon Glass  wrote:

Hi Simon,

> On Mon, 6 Nov 2023 at 10:26, Andre Przywara  wrote:
> >
> > On Sat, 4 Nov 2023 19:45:06 +
> > Simon Glass  wrote:
> >
> > Hi,
> >  
> > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara  
> > > wrote:  
> > > >
> > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > Simon Glass  wrote:
> > > >
> > > > Hi Simon,
> > > >  
> > > > > Hi Heinrich,
> > > > >
> > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > >  wrote:  
> > > > > >
> > > > > > On 11/1/23 19:05, Andre Przywara wrote:  
> > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > Heinrich Schuchardt  wrote:
> > > > > > >
> > > > > > > Hi Heinrich,
> > > > > > >  
> > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed 
> > > > > > >> CSR. It
> > > > > > >> provides an interface to a physical entropy source.
> > > > > > >>
> > > > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > > > >> mseccfg.sseed being set in the SBI firmware.  
> > > > > > >
> > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > respective Arm
> > > > > > > functionality:
> > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > >
> > > > > > > And I see that you seem to use the same mechanism to probe and 
> > > > > > > init the
> > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > > > implemented.
> > > > > > > One downside of this approach is that the driver is always loaded 
> > > > > > > (and
> > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > available.
> > > > > > > That doesn't seem too much of a problem on the first glance, but 
> > > > > > > it
> > > > > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > > > > (like virtio-rng) typically get higher device numbers. So without
> > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > VExpress64# rng 0
> > > > > > > No RNG device  
> > > > >
> > > > > Why do we get this? If the device is not there, the bind() function
> > > > > can return -ENODEV
> > > > >
> > > > > I see this in U-Boot:
> > > > >
> > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > >
> > > > > We should not use this.  
> > > >
> > > > Agreed.
> > > >  
> > > > > Use the devicetree.  
> > > >
> > > > No, this is definitely not something for the DT, at least not on ARM.
> > > > It's perfectly discoverable via the architected CPU ID registers.
> > > > Similar to PCI and USB devices, which we don't probe via the DT as well.
> > > >
> > > > It's arguably not proper "driver" material per se, as I've argued 
> > > > before, but
> > > > it's the simplest solution and fits in nicely otherwise.
> > > >
> > > > I was wondering if it might be something for UCLASS_CPU, something like
> > > > a "CPU feature bus": to let devices register on one on the many CPU
> > > > features (instead of compatible strings), then only bind() those
> > > > drivers it the respective bit is set.
> > > >
> > > > Does that make sense? Would that be doable without boiling the ocean?
> > > > As I don't know if we see many users apart from this.  
> > >
> > > I have seen this so many times, where people want to avoid putting
> > > things in the DT and then are surprised that everything is difficult,
> > > broken and confusing. Why not just follow the rules? It is not just
> > > about whether we can avoid it, etc. It is about how devices fit
> > > together cohesively in the system, and how U-Boot operates.  
> >
> > A devicetree is only for peripherals *that cannot be located by probing*.  
> 
> I have to stop you there. It absolutely is not limited to that.

I am very sorry, but I - (and seemingly everyone else in the kernel DT
community?) - seem to disagree here.

> > Which are traditionally most peripherals in non-server Arm SoCs. While I
> > do love the DT, the best DT node is the one you don't need.  
> 
> We need it in U-Boot, at least.
> 
> I'll send a patch with a warning on U_BOOT_DRVINFO() as it seems that
> some people did not see the header-file comment.

Fair enough.

> Let's just stop this discussion and instead talk about the binding we need.

Alright, if that is your decision, I will send a patch to revert
that "driver". There will never be a binding for a CPU instruction
discoverable by the architected CPU ID register.
I had some gripes with that "driver" in the first place, but it was so
temptingly simple and fit in so nicely, for instance into the UEFI
entropy service without even touching that code, that I couldn't resist
to just try it. And it actually solved a nasty problem for us, where
the kernel boot was stuck for minutes waiting for enough entropy to ...
let a script create a random filename ;-)
But we also have virtio-rng, so are not limited to the instructions.

But well, I guess I will just bite the bullet and go along the proper
route and create some RNG

Re: Need advise with u-boot on SH-7785LCR

2023-11-06 Thread Marek Vasut


On 11/6/23 21:42, Simon Glass wrote:

+Marek Vasut 
+Vagrant Cascadian 


On Mon, 6 Nov 2023 at 10:33, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:


Hi Simon!

On Mon, 2023-11-06 at 10:24 -0700, Simon Glass wrote:

So, I assume, I should just be able to write u-boot.bin to

/dev/mtdblock0?


Maybe, but you will likely brick the device if you have no other way
to write to flash.


The flash memory is actually on a daughter board that can be easily
replaced
and I have multiple of these daughter boards. It turns out that just
writing
the image to /dev/mtdblock0 works and I can boot the board into the freshly
flashed u-boot version.

However, the u-boot version 2019.01 built from git won't work while the old
2014.01 version that I copied onto disk from /dev/mtdblock0 does work when
flashing it to a second daughter board.

So, flashing works indeed like this and I can successfully start u-boot
after
flashing it into /dev/mtdblock0. Now I just need to figure out what the
difference
between 2014.01 and 2019.01 is and why the latter doesn't work.


In U-Boot, parallel NOR flash is flashed by cp.b into the parallel NOR 
memory mapped address , there are hooks which do the NOR writing.

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote:
> On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel  wrote:
> >
> > пн, 6 лист. 2023 р. о 15:13 Peter Robinson  пише:
> > >
> > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel  
> > > wrote:
> > > >
> > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson  пише:
> > > > >
> > > > > Hi Svyatoslav,
> > > > >
> > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > to convert boards which I maintain to use DM drivers instead of 
> > > > > > board hacks.
> > > > > >
> > > > > > Svyatoslav Ryhel (5):
> > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > >
> > > > > Is there a reason why the two above devices don't appear to have their
> > > > > .dts files in the upstream kernel?
> > > > >
> > > >
> > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > existential enemies or as dirt at least. I was trying to work with
> > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > lg_x3.
> > >
> > > The usual policy for acceptance into U-Boot is to have upstream review
> > > in the kernel first.
> > >
> >
> > May you point to a policy which clearly and explicitly states this as
> > a mandatory condition?
> 
> There have been a number of devices rejected in the past until their
> DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> to clarify the exact policy.

Well, here is where it's tricky. I brought this up for one of the
Broadcom MIPS platforms a week or two back, and Linus Walleij's point
(and I'm paraphrasing) is there's not really an upstream for it to go.

What we cannot have is device tree bindings[1] that aren't upstream or
worse yet conflict with the official bindings.

So the general way to resolve that is have device tree file be drop-in
from the linux kernel, and what additions we must have be done via
-u-boot.dtsi files. And in turn, some SoCs are better about keeping in
sync with the kernel than other SoCs are.

Now, upstream being actively hostile to dts files, especially for older
platforms? That's unfortunate. So long as we aren't violating the rules
about bindings, the intention is that we don't have device trees that
are either (a) massively out of sync with the kernel[2] or (b) kept
intentionally mismatched from the kernel.

-- 
Tom

[1]: There are both examples like binman that Simon is working on at
least but this is more exception than intentional rule.
[2]: Per our other conversions, I know the tegra ones are in this
unfortunate state in general

signature.asc
Description: PGP signature

[PATCH 5/5] pmic: qcom: dont use dev_read_addr to get USID

Linux DTs stuff a value indicating if the USID is a USID or a GSID in the
reg property, the Linux SPMI driver then reads the two address cells
separately. U-boot's dev_read_addr() doesn't know how to handle this, so
use ofnode_read_u32_index() to get just the USID.

The Qcom pmic driver doesn't have support for GSID handling, so just
ignore the second value for now.

Signed-off-by: Caleb Connolly 
---
 drivers/power/pmic/pmic_qcom.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/power/pmic/pmic_qcom.c b/drivers/power/pmic/pmic_qcom.c
index ad8daf43f06f..f2ac6494811d 100644
--- a/drivers/power/pmic/pmic_qcom.c
+++ b/drivers/power/pmic/pmic_qcom.c
@@ -66,12 +66,19 @@ static const struct udevice_id pmic_qcom_ids[] = {
 static int pmic_qcom_probe(struct udevice *dev)
 {
struct pmic_qcom_priv *priv = dev_get_priv(dev);
+   int ret;
 
-   priv->usid = dev_read_addr(dev);
-
-   if (priv->usid == FDT_ADDR_T_NONE)
+   /*
+* dev_read_addr() can't be used here because the reg property actually
+* contains two discrete values, not a single 64-bit address.
+* The address is the first value.
+*/
+   ret = ofnode_read_u32_index(dev_ofnode(dev), "reg", 0, >usid);
+   if (ret < 0)
return -EINVAL;
 
+   debug("usid: %d\n", priv->usid);
+
return 0;
 }
 

-- 
2.42.0

[PATCH 4/5] spmi: msm: fix register range names

The core and chnl register ranges were swapped on SDM845. Fix it, and
fetch the register ranges by name instead of by index.

Drop the cosmetic "version" variable and clean up the debug logging.

Signed-off-by: Caleb Connolly 
---
 arch/arm/dts/sdm845.dtsi |  2 +-
 drivers/spmi/spmi-msm.c  | 46 ++
 2 files changed, 19 insertions(+), 29 deletions(-)

diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
index 4798ace0ff8b..98f3744027bb 100644
--- a/arch/arm/dts/sdm845.dtsi
+++ b/arch/arm/dts/sdm845.dtsi
@@ -63,7 +63,7 @@
reg = <0xc44 0x1100>,
  <0xc60 0x200>,
  <0xe60 0x10>;
-   reg-names = "cnfg", "core", "obsrvr";
+   reg-names = "core", "chnls", "obsrvr";
#address-cells = <0x1>;
#size-cells = <0x1>;
 
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index 27a035c0a595..f8834e60c266 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -70,7 +70,7 @@ enum pmic_arb_channel {
 
 struct msm_spmi_priv {
phys_addr_t arb_chnl;  /* ARB channel mapping base */
-   phys_addr_t spmi_core; /* SPMI core */
+   phys_addr_t spmi_chnls; /* SPMI core */
phys_addr_t spmi_obs;  /* SPMI observer */
/* SPMI channel map */
uint8_t channel_map[SPMI_MAX_SLAVES][SPMI_MAX_PERIPH];
@@ -95,10 +95,10 @@ static int msm_spmi_write(struct udevice *dev, int usid, 
int pid, int off,
 
/* Disable IRQ mode for the current channel*/
writel(0x0,
-  priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);
+  priv->spmi_chnls + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);
 
/* Write single byte */
-   writel(val, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_WDATA);
+   writel(val, priv->spmi_chnls + SPMI_CH_OFFSET(channel) + 
SPMI_REG_WDATA);
 
/* Prepare write command */
reg |= SPMI_CMD_EXT_REG_WRITE_LONG << SPMI_CMD_OPCODE_SHIFT;
@@ -113,12 +113,12 @@ static int msm_spmi_write(struct udevice *dev, int usid, 
int pid, int off,
ch_offset = SPMI_CH_OFFSET(channel);
 
/* Send write command */
-   writel(reg, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CMD0);
+   writel(reg, priv->spmi_chnls + SPMI_CH_OFFSET(channel) + SPMI_REG_CMD0);
 
/* Wait till CMD DONE status */
reg = 0;
while (!reg) {
-   reg = readl(priv->spmi_core + SPMI_CH_OFFSET(channel) +
+   reg = readl(priv->spmi_chnls + SPMI_CH_OFFSET(channel) +
SPMI_REG_STATUS);
}
 
@@ -186,47 +186,37 @@ static struct dm_spmi_ops msm_spmi_ops = {
 static int msm_spmi_probe(struct udevice *dev)
 {
struct msm_spmi_priv *priv = dev_get_priv(dev);
-   phys_addr_t config_addr;
+   phys_addr_t core_addr;
u32 hw_ver;
-   u32 version;
int i;
-   int err;
 
-   config_addr = dev_read_addr_index(dev, 0);
-   priv->spmi_core = dev_read_addr_index(dev, 1);
-   priv->spmi_obs = dev_read_addr_index(dev, 2);
+   core_addr = dev_read_addr_name(dev, "core");
+   priv->spmi_chnls = dev_read_addr_name(dev, "chnls");
+   priv->spmi_obs = dev_read_addr_name(dev, "obsrvr");
 
-   hw_ver = readl(config_addr + PMIC_ARB_VERSION);
+   hw_ver = readl(core_addr + PMIC_ARB_VERSION);
 
if (hw_ver < PMIC_ARB_VERSION_V3_MIN) {
priv->arb_ver = V2;
-   version = 2;
-   priv->arb_chnl = config_addr + APID_MAP_OFFSET_V1_V2_V3;
+   priv->arb_chnl = core_addr + APID_MAP_OFFSET_V1_V2_V3;
} else if (hw_ver < PMIC_ARB_VERSION_V5_MIN) {
priv->arb_ver = V3;
-   version = 3;
-   priv->arb_chnl = config_addr + APID_MAP_OFFSET_V1_V2_V3;
+   priv->arb_chnl = core_addr + APID_MAP_OFFSET_V1_V2_V3;
} else {
priv->arb_ver = V5;
-   version = 5;
-   priv->arb_chnl = config_addr + APID_MAP_OFFSET_V5;
-
-   if (err) {
-   dev_err(dev, "could not read APID->PPID mapping table, 
rc= %d\n", err);
-   return -1;
-   }
+   priv->arb_chnl = core_addr + APID_MAP_OFFSET_V5;
}
 
-   dev_dbg(dev, "PMIC Arb Version-%d (0x%x)\n", version, hw_ver);
+   dev_dbg(dev, "PMIC Arb Version-%d (%#x)\n", hw_ver >> 28, hw_ver);
 
if (priv->arb_chnl == FDT_ADDR_T_NONE ||
-   priv->spmi_core == FDT_ADDR_T_NONE ||
+   priv->spmi_chnls == FDT_ADDR_T_NONE ||
priv->spmi_obs == FDT_ADDR_T_NONE)
return -EINVAL;
 
-   dev_dbg(dev, "priv->arb_chnl address (%llu)\n", priv->arb_chnl);
-   dev_dbg(dev, "priv->spmi_core address (%llu)\n", priv->spmi_core);
-   dev_dbg(dev,

[PATCH 3/5] gpio: qcom_pmic: fix support for upstream DT

Linux devicetrees use the "gpio-ranges" property, add support for
parsing it instead of "gpio-count" so that upstream DTs can be used with
U-Boot.

Signed-off-by: Caleb Connolly 
---
 drivers/gpio/qcom_pmic_gpio.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 3dbc02d83198..e6405881c637 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -247,11 +247,37 @@ static int qcom_gpio_probe(struct udevice *dev)
return 0;
 }
 
+/*
+ * Parse basic GPIO count specified via the gpio-ranges property
+ * as specified in Linux devicetrees
+ * Returns < 0 on error, otherwise gpio count
+ */
+static int qcom_gpio_of_parse_ranges(struct udevice *dev)
+{
+   int ret;
+   struct ofnode_phandle_args args;
+
+   ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), "gpio-ranges",
+NULL, 3, 0, );
+   if (ret)
+   return log_msg_ret("gpio-ranges", ret);
+
+   return args.args[2];
+}
+
 static int qcom_gpio_of_to_plat(struct udevice *dev)
 {
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   int ret;
 
uc_priv->gpio_count = dev_read_u32_default(dev, "gpio-count", 0);
+   if (!uc_priv->gpio_count) {
+   ret = qcom_gpio_of_parse_ranges(dev);
+   if (ret > 0)
+   uc_priv->gpio_count = ret;
+   else
+   printf("gpio-ranges error: %d\n", ret);
+   }
uc_priv->bank_name = dev_read_string(dev, "gpio-bank-name");
if (uc_priv->bank_name == NULL)
uc_priv->bank_name = "qcom_pmic";

-- 
2.42.0

[PATCH 2/5] gpio: qcom_pmic: rework pwrkey driver into a button driver

The power and resin keys were implemented as GPIOs here, but their only
use would be as buttons. Avoid the additional layer of introspection and
rework this driver into a button driver.

While we're here, replace the "qcom,pm8998-pwrkey" compatible with
"qcom,pm8941-pwrkey" to match upstream (Linux).

The dragonboard410c and 820c boards are adjusted to benefit from this
change too, simplify their custom board init code.

Signed-off-by: Caleb Connolly 
---
 arch/arm/dts/dragonboard410c-uboot.dtsi  |  11 +-
 arch/arm/dts/dragonboard820c-uboot.dtsi  |   9 +-
 arch/arm/dts/dragonboard820c.dts |   3 -
 board/qualcomm/dragonboard410c/dragonboard410c.c |  29 ++--
 board/qualcomm/dragonboard820c/dragonboard820c.c |  29 ++--
 drivers/gpio/Kconfig |   3 +-
 drivers/gpio/qcom_pmic_gpio.c| 161 +++
 7 files changed, 139 insertions(+), 106 deletions(-)

diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
b/arch/arm/dts/dragonboard410c-uboot.dtsi
index 3b0bd0ed0a1b..c96f1fcc8930 100644
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
@@ -5,6 +5,9 @@
  * (C) Copyright 2015 Mateusz Kulikowski 
  */
 
+#include 
+#include 
+
 / {
 
smem {
@@ -46,10 +49,14 @@
 
 _pon {
key_vol_down {
-   gpios = <_pon 1 0>;
+   interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
+   linux,code = ;
+   label = "key_vol_down";
};
 
key_power {
-   gpios = <_pon 0 0>;
+   interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+   linux,code = ;
+   label = "key_power";
};
 };
diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi 
b/arch/arm/dts/dragonboard820c-uboot.dtsi
index 457728a43ecb..ed8ac0e5cf1a 100644
--- a/arch/arm/dts/dragonboard820c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard820c-uboot.dtsi
@@ -5,6 +5,9 @@
  * (C) Copyright 2017 Jorge Ramirez-Ortiz 
  */
 
+#include 
+#include 
+
 / {
smem {
bootph-all;
@@ -33,12 +36,14 @@
 
 _pon {
key_vol_down {
-   gpios = <_pon 1 0>;
+   interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
+   linux,code = ;
label = "key_vol_down";
};
 
key_power {
-   gpios = <_pon 0 0>;
+   interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+   linux,code = ;
label = "key_power";
};
 };
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index ad201d48749c..7db0cc9d64cc 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -112,9 +112,6 @@
pm8994_pon: pm8994_pon@800 {
compatible = "qcom,pm8994-pwrkey";
reg = <0x800 0x96>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   gpio-bank-name="pm8994_key.";
};
 
pm8994_gpios: pm8994_gpios@c000 {
diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.c 
b/board/qualcomm/dragonboard410c/dragonboard410c.c
index 371b3262f8c5..1d6cabfb9c41 100644
--- a/board/qualcomm/dragonboard410c/dragonboard410c.c
+++ b/board/qualcomm/dragonboard410c/dragonboard410c.c
@@ -5,6 +5,7 @@
  * (C) Copyright 2015 Mateusz Kulikowski 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -108,30 +109,18 @@ int board_usb_init(int index, enum usb_init_type init)
 /* Check for vol- button - if pressed - stop autoboot */
 int misc_init_r(void)
 {
-   struct udevice *pon;
-   struct gpio_desc resin;
-   int node, ret;
+   struct udevice *btn;
+   int ret;
+   enum button_state_t state;
 
-   ret = uclass_get_device_by_name(UCLASS_GPIO, "pm8916_pon@800", );
+   ret = button_get_by_label("key_vol_down", );
if (ret < 0) {
-   printf("Failed to find PMIC pon node. Check device tree\n");
-   return 0;
+   printf("Couldn't find power button!\n");
+   return ret;
}
 
-   node = fdt_subnode_offset(gd->fdt_blob, dev_of_offset(pon),
- "key_vol_down");
-   if (node < 0) {
-   printf("Failed to find key_vol_down node. Check device tree\n");
-   return 0;
-   }
-
-   if (gpio_request_by_name_nodev(offset_to_ofnode(node), "gpios", 0,
-  , 0)) {
-   printf("Failed to request key_vol_down button.\n");
-   return 0;
-   }
-
-   if (dm_gpio_get_value()) {
+   state = button_get_state(btn);
+   if (state == BUTTON_ON) {
env_set("preboot", "setenv preboot; fastboot 0");
printf("key_vol_down pressed -

[PATCH 1/5] gpio: qcom_pmic: fix silent dev_read_addr downcast

priv->pid is uint32_t, but dev_read_addr() returns a uint64_t on arm64,
with the upper bits being used for error codes. Do error checking before
downcasting to u32 to prevent errors being silently ignored.

Signed-off-by: Caleb Connolly 
---
 drivers/gpio/qcom_pmic_gpio.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 65feb453ebc3..e5841f502953 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -221,11 +221,14 @@ static int qcom_gpio_probe(struct udevice *dev)
 {
struct qcom_gpio_bank *priv = dev_get_priv(dev);
int reg;
+   u64 pid;
 
-   priv->pid = dev_read_addr(dev);
-   if (priv->pid == FDT_ADDR_T_NONE)
+   pid = dev_read_addr(dev);
+   if (pid == FDT_ADDR_T_NONE)
return log_msg_ret("bad address", -EINVAL);
 
+   priv->pid = pid;
+
/* Do a sanity check */
reg = pmic_reg_read(dev->parent, priv->pid + REG_TYPE);
if (reg != REG_TYPE_VAL)
@@ -328,11 +331,14 @@ static int qcom_pwrkey_probe(struct udevice *dev)
 {
struct qcom_gpio_bank *priv = dev_get_priv(dev);
int reg;
+   u64 pid;
 
-   priv->pid = dev_read_addr(dev);
-   if (priv->pid == FDT_ADDR_T_NONE)
+   pid = dev_read_addr(dev);
+   if (pid == FDT_ADDR_T_NONE)
return log_msg_ret("bad address", -EINVAL);
 
+   priv->pid = pid;
+
/* Do a sanity check */
reg = pmic_reg_read(dev->parent, priv->pid + REG_TYPE);
if (reg != 0x1)

-- 
2.42.0

[PATCH 0/5] Qualcomm PMIC fixes

This series addresses some long-standing issues with the SPMI arb
driver, the PMIC, and the PMIC GPIO. It fixes compatibility with
upstream Linux devicetrees, and simplifies pwrkey/resin support by
rewriting the pon driver to be a button driver rather than a GPIO
driver.

Existing users (the db410c and 820c) are adjusted to use the new button
driver in their board init code.

This series is based on the pinctrl [1] and clock [2] cleanup series.
There may be some DTS conflicts applying it standalone.

[1]: 
https://lore.kernel.org/u-boot/20231106-b4-qcom-pinctrl-v2-0-406e8d868...@linaro.org/
[2]: 
https://lore.kernel.org/u-boot/20231103-b4-qcom-clk-v3-0-8d2d460ec...@linaro.org/

---
Caleb Connolly (5):
  gpio: qcom_pmic: fix silent dev_read_addr downcast
  gpio: qcom_pmic: rework pwrkey driver into a button driver
  gpio: qcom_pmic: fix support for upstream DT
  spmi: msm: fix register range names
  pmic: qcom: dont use dev_read_addr to get USID

 arch/arm/dts/dragonboard410c-uboot.dtsi  |  11 +-
 arch/arm/dts/dragonboard820c-uboot.dtsi  |   9 +-
 arch/arm/dts/dragonboard820c.dts |   3 -
 arch/arm/dts/sdm845.dtsi |   2 +-
 board/qualcomm/dragonboard410c/dragonboard410c.c |  29 ++--
 board/qualcomm/dragonboard820c/dragonboard820c.c |  29 ++--
 drivers/gpio/Kconfig |   3 +-
 drivers/gpio/qcom_pmic_gpio.c| 193 ---
 drivers/power/pmic/pmic_qcom.c   |  13 +-
 drivers/spmi/spmi-msm.c  |  46 +++---
 10 files changed, 200 insertions(+), 138 deletions(-)
---
base-commit: 13995976aba2b9a63917f3c43b3cd3eaeccc4606

// Caleb (they/them)

Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow

2023-11-06 Thread Tony Dinh

On Mon, Nov 6, 2023 at 11:51 AM Tom Rini  wrote:
>
> On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
> > Hi Simon,
> >
> > On Mon, Nov 6, 2023 at 9:25 AM Simon Glass  wrote:
> > >
> > > Hi Tony,
> > >
> > > On Wed, 4 Oct 2023 at 21:23, Tony Dinh  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass  wrote:
> > > > > >
> > > > > > Hi Tony,
> > > > > >
> > > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh  wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Tony,
> > > > > > > >
> > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > Here is an observation during testing the bootflow command.
> > > > > > > > >
> > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will 
> > > > > > > > > remove that existing
> > > > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow 
> > > > > > > > > again, and it was
> > > > > > > > > back to normal. Perhaps there is some kind of indexing 
> > > > > > > > > problem?
> > > > > > > >
> > > > > > > > Yes that's right. The 'botflow scan' command is not additive. 
> > > > > > > > The
> > > > > > > > first thing it does is removing existing bootflows.
> > > > > > >
> > > > > > > Thanks for clarifying that. I assumed it is additive, because the
> > > > > > > existing USB bootflow was not removed when I did a "bootflow scan
> > > > > > > scsi" immediately after (see the end of the log).
> > > > > >
> > > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug?
> > > > > > When you scan SCSI it should not also scan USB.
> > > > >
> > > > > Yes, it looks like a bug. I think I can see the problem and am working
> > > > > on a patch.
> > > >
> > > > Just to let you know, I'm out of time to work on this topic. I will
> > > > revisit it some other time, if you have not already tracked it down.
> > >
> > > If you are able to use 'bootflow scan -l' in each case, then I might
> > > be able to see what it is scanning USB, when you are asking for SCSI.
> > > I also wonder if this bug may have been fixed due to other changes?
> >
> > I'm wondering about that, too. I will rerun the test with the master
> > branch with debug trace. If we cannot see it, I'll do it again when
> > other bootstd patches are merged. Right now I am not sure which of
> > your bootstd patches I should apply to the tree for testing, do you
> > have a list for that?
>
> Right now the only outstanding bootstd patch I know of is your recent
> one, as I was waiting for Simon's review (which he did today) before
> merging and applying.

Thanks Tom! I'll run the test in my tree as is then.

All the best,
Tony

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

On Mon, Nov 06, 2023 at 01:38:39PM -0700, Simon Glass wrote:
> Hi Andre,
> 
> On Mon, 6 Nov 2023 at 10:26, Andre Przywara  wrote:
> >
> > On Sat, 4 Nov 2023 19:45:06 +
> > Simon Glass  wrote:
> >
> > Hi,
> >
> > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara  
> > > wrote:
> > > >
> > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > Simon Glass  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Heinrich,
> > > > >
> > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > >  wrote:
> > > > > >
> > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > Heinrich Schuchardt  wrote:
> > > > > > >
> > > > > > > Hi Heinrich,
> > > > > > >
> > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed 
> > > > > > >> CSR. It
> > > > > > >> provides an interface to a physical entropy source.
> > > > > > >>
> > > > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > > >
> > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > respective Arm
> > > > > > > functionality:
> > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > >
> > > > > > > And I see that you seem to use the same mechanism to probe and 
> > > > > > > init the
> > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > > > implemented.
> > > > > > > One downside of this approach is that the driver is always loaded 
> > > > > > > (and
> > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > available.
> > > > > > > That doesn't seem too much of a problem on the first glance, but 
> > > > > > > it
> > > > > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > > > > (like virtio-rng) typically get higher device numbers. So without
> > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > VExpress64# rng 0
> > > > > > > No RNG device
> > > > >
> > > > > Why do we get this? If the device is not there, the bind() function
> > > > > can return -ENODEV
> > > > >
> > > > > I see this in U-Boot:
> > > > >
> > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > >
> > > > > We should not use this.
> > > >
> > > > Agreed.
> > > >
> > > > > Use the devicetree.
> > > >
> > > > No, this is definitely not something for the DT, at least not on ARM.
> > > > It's perfectly discoverable via the architected CPU ID registers.
> > > > Similar to PCI and USB devices, which we don't probe via the DT as well.
> > > >
> > > > It's arguably not proper "driver" material per se, as I've argued 
> > > > before, but
> > > > it's the simplest solution and fits in nicely otherwise.
> > > >
> > > > I was wondering if it might be something for UCLASS_CPU, something like
> > > > a "CPU feature bus": to let devices register on one on the many CPU
> > > > features (instead of compatible strings), then only bind() those
> > > > drivers it the respective bit is set.
> > > >
> > > > Does that make sense? Would that be doable without boiling the ocean?
> > > > As I don't know if we see many users apart from this.
> > >
> > > I have seen this so many times, where people want to avoid putting
> > > things in the DT and then are surprised that everything is difficult,
> > > broken and confusing. Why not just follow the rules? It is not just
> > > about whether we can avoid it, etc. It is about how devices fit
> > > together cohesively in the system, and how U-Boot operates.
> >
> > A devicetree is only for peripherals *that cannot be located by probing*.
> 
> I have to stop you there. It absolutely is not limited to that.

It is limited to that if we're going to keep using the device trees that
Linux uses. Full stop. There's not really wiggle room there either.

-- 
Tom


signature.asc
Description: PGP signature

Re: Need advise with u-boot on SH-7785LCR

+Marek Vasut 
+Vagrant Cascadian 


On Mon, 6 Nov 2023 at 10:33, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi Simon!
>
> On Mon, 2023-11-06 at 10:24 -0700, Simon Glass wrote:
> > > So, I assume, I should just be able to write u-boot.bin to
> /dev/mtdblock0?
> >
> > Maybe, but you will likely brick the device if you have no other way
> > to write to flash.
>
> The flash memory is actually on a daughter board that can be easily
> replaced
> and I have multiple of these daughter boards. It turns out that just
> writing
> the image to /dev/mtdblock0 works and I can boot the board into the freshly
> flashed u-boot version.
>
> However, the u-boot version 2019.01 built from git won't work while the old
> 2014.01 version that I copied onto disk from /dev/mtdblock0 does work when
> flashing it to a second daughter board.
>
> So, flashing works indeed like this and I can successfully start u-boot
> after
> flashing it into /dev/mtdblock0. Now I just need to figure out what the
> difference
> between 2014.01 and 2019.01 is and why the latter doesn't work.
>
> I have uploaded both versions here:
>
> > https://people.debian.org/~glaubitz/u-boot-sh7785lcr/
>
> Maybe someone with more experience can spot anything obvious like incorrect
> address offsets etc.
>
> PS: I'm actually called Adrian, despite the long name ;-).
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

Hi Andre,

On Mon, 6 Nov 2023 at 10:26, Andre Przywara  wrote:
>
> On Sat, 4 Nov 2023 19:45:06 +
> Simon Glass  wrote:
>
> Hi,
>
> > On Sat, 4 Nov 2023 at 17:13, Andre Przywara  wrote:
> > >
> > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > Simon Glass  wrote:
> > >
> > > Hi Simon,
> > >
> > > > Hi Heinrich,
> > > >
> > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > >  wrote:
> > > > >
> > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > Heinrich Schuchardt  wrote:
> > > > > >
> > > > > > Hi Heinrich,
> > > > > >
> > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. 
> > > > > >> It
> > > > > >> provides an interface to a physical entropy source.
> > > > > >>
> > > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > >
> > > > > > As you might have seen, I added a similar driver for the respective 
> > > > > > Arm
> > > > > > functionality:
> > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > >
> > > > > > And I see that you seem to use the same mechanism to probe and init 
> > > > > > the
> > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > > implemented.
> > > > > > One downside of this approach is that the driver is always loaded 
> > > > > > (and
> > > > > > visible in the DM tree), even with the feature not being available.
> > > > > > That doesn't seem too much of a problem on the first glance, but it
> > > > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > > > (like virtio-rng) typically get higher device numbers. So without
> > > > > > the feature, but with virtio-rng, I get:
> > > > > > VExpress64# rng 0
> > > > > > No RNG device
> > > >
> > > > Why do we get this? If the device is not there, the bind() function
> > > > can return -ENODEV
> > > >
> > > > I see this in U-Boot:
> > > >
> > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > >
> > > > We should not use this.
> > >
> > > Agreed.
> > >
> > > > Use the devicetree.
> > >
> > > No, this is definitely not something for the DT, at least not on ARM.
> > > It's perfectly discoverable via the architected CPU ID registers.
> > > Similar to PCI and USB devices, which we don't probe via the DT as well.
> > >
> > > It's arguably not proper "driver" material per se, as I've argued before, 
> > > but
> > > it's the simplest solution and fits in nicely otherwise.
> > >
> > > I was wondering if it might be something for UCLASS_CPU, something like
> > > a "CPU feature bus": to let devices register on one on the many CPU
> > > features (instead of compatible strings), then only bind() those
> > > drivers it the respective bit is set.
> > >
> > > Does that make sense? Would that be doable without boiling the ocean?
> > > As I don't know if we see many users apart from this.
> >
> > I have seen this so many times, where people want to avoid putting
> > things in the DT and then are surprised that everything is difficult,
> > broken and confusing. Why not just follow the rules? It is not just
> > about whether we can avoid it, etc. It is about how devices fit
> > together cohesively in the system, and how U-Boot operates.
>
> A devicetree is only for peripherals *that cannot be located by probing*.

I have to stop you there. It absolutely is not limited to that.

> Which are traditionally most peripherals in non-server Arm SoCs. While I
> do love the DT, the best DT node is the one you don't need.

We need it in U-Boot, at least.

I'll send a patch with a warning on U_BOOT_DRVINFO() as it seems that
some people did not see the header-file comment.

Let's just stop this discussion and instead talk about the binding we need.

>
> But as Heinrich also said: those instructions are not peripherals, they
> are part of an instruction set extensions, the same story as with x86's
> RDRAND instruction. We don't have those in ACPI or so as well, because
> CPUID has you covered. The same on ARM, ID_AA64ISAR0_EL1 is readable on
> every chip (outside of EL0), and tells you whether you have the RNDR
> register or not. IIUC RISC-V is slightly different here, since not all ISA
> extensions are covered by CSRs, hence some of them indeed listed in the DT.
>
> So a proper solution(TM) would be to split this up in architectural
> *instructions* and proper TRNG *devices*, maybe wrapping this up in some
> function that tests both. This is roughly what the kernel does, somewhat
> abstracted by the concept of "entropy sources", which could be TRNG
> devices, CPU instructions, interrupt jitter or even "instruction execution
> jitter"[1], with the latter two definitely not being devices really at all.
>
> But I don't know if U-Boot wants to go through the hassle of this whole
> framework, as we tend to implement things much easier. But a simple
> get_cpu_random() function, implemented per architecture, and

[tom.r...@gmail.com: Fwd: New Defects reported by Coverity Scan for Das U-Boot]

Hey all,

Here's the latest report. I _think_ I passed the right options to
get_maintainer.pl such that it would only look far enough back in git to
find the likely authors (along with listed maintainers of the files).

-- Forwarded message -
From: 
Date: Mon, Nov 6, 2023 at 2:58 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To: 


Hi,

Please find the latest report on new defect(s) introduced to Das
U-Boot found with Coverity Scan.

13 new defect(s) introduced to Das U-Boot found with Coverity Scan.
5 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 13 of 13 defect(s)


** CID 467411:  Memory - corruptions  (OVERRUN)



*** CID 467411:  Memory - corruptions  (OVERRUN)
/lib/efi_loader/efi_tcg2.c: 1395 in efi_tcg2_measure_efi_app_invocation()
1389
1390ret = tcg2_measure_gpt_data(dev, handle);
1391if (ret != EFI_SUCCESS)
1392goto out;
1393
1394for (pcr_index = 0; pcr_index <= 7; pcr_index++) {
>>> CID 467411:  Memory - corruptions  (OVERRUN)
>>> Overrunning buffer pointed to by "(u8 *)" of 4 bytes by passing 
>>> it to a function which accesses it at byte offset 63.
1395ret = measure_event(dev, pcr_index, EV_SEPARATOR,
1396sizeof(event), (u8 *));
1397if (ret != EFI_SUCCESS)
1398goto out;
1399}
1400

** CID 467410:(TAINTED_SCALAR)



*** CID 467410:(TAINTED_SCALAR)
/lib/efi_loader/efi_tcg2.c: 1385 in efi_tcg2_measure_efi_app_invocation()
1379(u8 *)EFI_CALLING_EFI_APPLICATION);
1380if (ret != EFI_SUCCESS)
1381goto out;
1382
1383entry = (struct smbios_entry *)find_smbios_table();
1384if (entry) {
>>> CID 467410:(TAINTED_SCALAR)
>>> Passing tainted expression "entry->struct_table_length" to 
>>> "tcg2_measure_smbios", which uses it as an offset.
1385ret = tcg2_measure_smbios(dev, entry);
1386if (ret != EFI_SUCCESS)
1387goto out;
1388}
1389
1390ret = tcg2_measure_gpt_data(dev, handle);
/lib/efi_loader/efi_tcg2.c: 1385 in efi_tcg2_measure_efi_app_invocation()
1379(u8 *)EFI_CALLING_EFI_APPLICATION);
1380if (ret != EFI_SUCCESS)
1381goto out;
1382
1383entry = (struct smbios_entry *)find_smbios_table();
1384if (entry) {
>>> CID 467410:(TAINTED_SCALAR)
>>> Passing tainted expression "entry->struct_count" to 
>>> "tcg2_measure_smbios", which uses it as a loop boundary.
1385ret = tcg2_measure_smbios(dev, entry);
1386if (ret != EFI_SUCCESS)
1387goto out;
1388}
1389
1390ret = tcg2_measure_gpt_data(dev, handle);

** CID 467409:  Uninitialized variables  (UNINIT)



*** CID 467409:  Uninitialized variables  (UNINIT)
/test/boot/measurement.c: 48 in measure()
42  for (i = 0; i < size; ++i) {
43  kernel[i] = 0xf0 | (i & 0xf);
44  initrd[i] = (i & 0xf0) | 0xf;
45  images.ft_addr[i] = i & 0xff;
46  }
47
>>> CID 467409:  Uninitialized variables  (UNINIT)
>>> Using uninitialized value "images.os.os" when calling "bootm_measure".
48  ut_assertok(bootm_measure());
49
50  free(images.ft_addr);
51  free(initrd);
52  free(kernel);
53

** CID 467408:  Insecure data handling  (TAINTED_SCALAR)



*** CID 467408:  Insecure data handling  (TAINTED_SCALAR)
/boot/bootm.c: 826 in do_bootm_states()
820 env_set_hex("initrd_end", images->initrd_end);
821 }
822 }
823 #endif
824 #if CONFIG_IS_ENABLED(OF_LIBFDT) && defined(CONFIG_LMB)
825 if (!ret && (states & BOOTM_STATE_FDT)) {
>>> CID 467408:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted expression "*images->ft_addr" to 
>>> "boot_fdt_add_mem_rsv_regions", which uses it as an offset.
826 boot_fdt_add_mem_rsv_regions(>lmb,
images->ft_addr);
827 ret = boot_relocate_fdt(>lmb, >ft_addr,
828 >ft_len);
829 }
830 #endif
831

** CID 467407:  Uninitialized variables  (UNINIT)
/drivers/scsi/scsi.c: 612 in

Re: [PATCH 1/4] bootm: Allow ignoring the load address with kernel_noload

On Mon, Nov 06, 2023 at 12:58:46PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> 
> On Mon, 6 Nov 2023 at 11:30, Tom Rini  wrote:
> >
> > On Mon, Nov 06, 2023 at 10:25:00AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 5 Nov 2023 at 14:19, Tom Rini  wrote:
> > > >
> > > > On Sun, Nov 05, 2023 at 01:03:51PM -0700, Simon Glass wrote:
> > > >
> > > > > This image type is supposed to ignore the load address. But at present
> > > > > it fails if the load address is missing. If it is zero, the image is
> > > > > loaded at address 0, which may not work on all boards.
> > > > >
> > > > > Make use of the kernel_addr_r environment variable, instead, since 
> > > > > this
> > > > > seems to be a more reliable final address for the kernel.
> > > > >
> > > > > Another option would be to create a new Kconfig for this, or to use a
> > > > > region of memory known to be free, e.g. calculated from the DRAM 
> > > > > banks.
> > > > > But in any case we should try to avoid conflicting with the
> > > > > kernel_addr_r variable. So the approach in this patch seems reasonable
> > > > > to me.
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > >
> > > > How are you creating the image in question here? A noload FIT is
> > > > supposed to just supposed to go from where it is. Where do things fall
> > > > down later?
> > >
> > > The image is Image.gz built by Linux, for example. So compression =
> > > "gzip" which means that it has to be decompressed.
> > >
> > > Things fall down as soon as U-Boot looks at the image, since it
> > > doesn't have the ARM64 magic.
> >
> > Can you provide logs and env? "booti" is supposed to handle this case
> > already, and if it's not we should figure out when / why it broke.
> 
> Do you mean booti handles compression? Yes, I can see that in the code.

Yes, you use "booti" with an Image.gz.

> But in my case I am using bootm, since it is a FIT.

Shouldn't this be handled by the normal compression = "foo" logic? And in
turn is that what's not working? If so, the commit messages aren't
clear.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

On Mon, Nov 06, 2023 at 05:26:01PM +, Andre Przywara wrote:
> On Sat, 4 Nov 2023 19:45:06 +
> Simon Glass  wrote:
> 
> Hi,
> 
> > On Sat, 4 Nov 2023 at 17:13, Andre Przywara  wrote:
> > >
> > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > Simon Glass  wrote:
> > >
> > > Hi Simon,
> > >  
> > > > Hi Heinrich,
> > > >
> > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > >  wrote:  
> > > > >
> > > > > On 11/1/23 19:05, Andre Przywara wrote:  
> > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > Heinrich Schuchardt  wrote:
> > > > > >
> > > > > > Hi Heinrich,
> > > > > >  
> > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. 
> > > > > >> It
> > > > > >> provides an interface to a physical entropy source.
> > > > > >>
> > > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > > >> mseccfg.sseed being set in the SBI firmware.  
> > > > > >
> > > > > > As you might have seen, I added a similar driver for the respective 
> > > > > > Arm
> > > > > > functionality:
> > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > >
> > > > > > And I see that you seem to use the same mechanism to probe and init 
> > > > > > the
> > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > > implemented.
> > > > > > One downside of this approach is that the driver is always loaded 
> > > > > > (and
> > > > > > visible in the DM tree), even with the feature not being available.
> > > > > > That doesn't seem too much of a problem on the first glance, but it
> > > > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > > > (like virtio-rng) typically get higher device numbers. So without
> > > > > > the feature, but with virtio-rng, I get:
> > > > > > VExpress64# rng 0
> > > > > > No RNG device  
> > > >
> > > > Why do we get this? If the device is not there, the bind() function
> > > > can return -ENODEV
> > > >
> > > > I see this in U-Boot:
> > > >
> > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > >
> > > > We should not use this.  
> > >
> > > Agreed.
> > >  
> > > > Use the devicetree.  
> > >
> > > No, this is definitely not something for the DT, at least not on ARM.
> > > It's perfectly discoverable via the architected CPU ID registers.
> > > Similar to PCI and USB devices, which we don't probe via the DT as well.
> > >
> > > It's arguably not proper "driver" material per se, as I've argued before, 
> > > but
> > > it's the simplest solution and fits in nicely otherwise.
> > >
> > > I was wondering if it might be something for UCLASS_CPU, something like
> > > a "CPU feature bus": to let devices register on one on the many CPU
> > > features (instead of compatible strings), then only bind() those
> > > drivers it the respective bit is set.
> > >
> > > Does that make sense? Would that be doable without boiling the ocean?
> > > As I don't know if we see many users apart from this.  
> > 
> > I have seen this so many times, where people want to avoid putting
> > things in the DT and then are surprised that everything is difficult,
> > broken and confusing. Why not just follow the rules? It is not just
> > about whether we can avoid it, etc. It is about how devices fit
> > together cohesively in the system, and how U-Boot operates.
> 
> A devicetree is only for peripherals *that cannot be located by probing*.
> Which are traditionally most peripherals in non-server Arm SoCs. While I
> do love the DT, the best DT node is the one you don't need.

In general, yes, this. And we keep banging against this too. If we can
figure it out at run time, without needing device tree, we should be
doing that, not adding a device tree node/property.

A device tree check is not our only run-time "does this exist" check.

> But as Heinrich also said: those instructions are not peripherals, they
> are part of an instruction set extensions, the same story as with x86's
> RDRAND instruction. We don't have those in ACPI or so as well, because
> CPUID has you covered. The same on ARM, ID_AA64ISAR0_EL1 is readable on
> every chip (outside of EL0), and tells you whether you have the RNDR
> register or not. IIUC RISC-V is slightly different here, since not all ISA
> extensions are covered by CSRs, hence some of them indeed listed in the DT.
> 
> So a proper solution(TM) would be to split this up in architectural
> *instructions* and proper TRNG *devices*, maybe wrapping this up in some
> function that tests both. This is roughly what the kernel does, somewhat
> abstracted by the concept of "entropy sources", which could be TRNG
> devices, CPU instructions, interrupt jitter or even "instruction execution
> jitter"[1], with the latter two definitely not being devices really at all.
> 
> But I don't know if U-Boot wants to go through the hassle of this whole
> framework, as we tend to implement things much easier. But a simple
> get_cpu_random() function, implemented per architecture, and with

Re: [PATCH] mmc: renesas-sdhi: Disable clock after tuning reset when possible

2023-11-06 Thread Paul Barker

On Sun, Nov 05, 2023 at 11:42:45PM +0100, Marek Vasut wrote:
> Currently the renesas_sdhi_reset_tuning() unconditionally leaves SDHI
> clock enabled after the tuning reset. This is not always necessary.
> 
> After the driver performed tuning reset at the end of probe function,
> or in the unlikely case that tuning failed during regular operation,
> the SDHI clock can be disabled after the tuning reset. The following
> set_ios call would reconfigure the clock as needed.
> 
> In case of regular set_ios call which requires a tuning reset, keep
> the clock enabled or disabled according to the mmc->clk_disable state.
> 
> With this in place, the controllers which have not been accessed via
> block subsystem after boot are left in quiescent state. However, if an
> MMC device is used e.g. for environment storage, that controller would
> be accessed during the environment load and left active, including its
> clock which would still be generated. This is due to the design of the
> MMC subsystem, which does not deinit a controller after it was started
> once, the controller is only deinited in case of mmc rescan, or before
> OS boot.
> 
> Signed-off-by: Marek Vasut 
> ---
> Note: To address the part where MMC device has been inited once and
>   is never deinited until rescan or OS boot, it would likely be
>   necessary to implement something like runtime PM, possibly
>   based on the cyclic framework. Basically, keep track of when
>   the MMC was accessed last, and if certain time elapsed, deinit
>   the MMC. This could also be used to handle card detect polling
>   at the same time.
> ---
> Cc: Jaehoon Chung 
> Cc: Nobuhiro Iwamatsu 
> Cc: Paul Barker 
> Cc: Peng Fan 
> ---
>  drivers/mmc/renesas-sdhi.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 8cd501c5f7c..97aaf1e4ec3 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -318,7 +318,7 @@ static unsigned int renesas_sdhi_init_tuning(struct 
> tmio_sd_priv *priv)
>   RENESAS_SDHI_SCC_DTCNTL_TAPNUM_MASK;
>  }
>  
> -static void renesas_sdhi_reset_tuning(struct tmio_sd_priv *priv)
> +static void renesas_sdhi_reset_tuning(struct tmio_sd_priv *priv, bool 
> clk_disable)
>  {
>   u32 reg;
>  
> @@ -350,6 +350,12 @@ static void renesas_sdhi_reset_tuning(struct 
> tmio_sd_priv *priv)
>   reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
>   reg &= ~RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
>   tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
> +
> + if (clk_disable) {
> + reg = tmio_sd_readl(priv, TMIO_SD_CLKCTL);
> + reg &= ~TMIO_SD_CLKCTL_SCLKEN;
> + tmio_sd_writel(priv, reg, TMIO_SD_CLKCTL);
> + }
>  }
>  
>  static int renesas_sdhi_hs400(struct udevice *dev)
> @@ -629,7 +635,7 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint 
> opcode)
>  out:
>   if (ret < 0) {
>   dev_warn(dev, "Tuning procedure failed\n");
> - renesas_sdhi_reset_tuning(priv);
> + renesas_sdhi_reset_tuning(priv, true);
>   }
>  
>   return ret;
> @@ -668,7 +674,7 @@ static int renesas_sdhi_set_ios(struct udevice *dev)
>   (mmc->selected_mode != UHS_SDR104) &&
>   (mmc->selected_mode != MMC_HS_200) &&
>   (mmc->selected_mode != MMC_HS_400)) {
> - renesas_sdhi_reset_tuning(priv);
> + renesas_sdhi_reset_tuning(priv, mmc->clk_disable);
>   }
>  #endif
>  
> @@ -1095,7 +1101,7 @@ static int renesas_sdhi_probe(struct udevice *dev)
>  CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
>  CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
>   if (priv->caps & TMIO_SD_CAP_RCAR_UHS)
> - renesas_sdhi_reset_tuning(priv);
> + renesas_sdhi_reset_tuning(priv, true);
>  #endif
>   return 0;

Reviewed-by: Paul Barker 
Tested-by: Paul Barker 
  (on RZ/G2L SMARC EVK)

Thanks,
Paul


signature.asc
Description: PGP signature

Re: [PATCH 1/4] bootm: Allow ignoring the load address with kernel_noload

Hi Tom,


On Mon, 6 Nov 2023 at 11:30, Tom Rini  wrote:
>
> On Mon, Nov 06, 2023 at 10:25:00AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 5 Nov 2023 at 14:19, Tom Rini  wrote:
> > >
> > > On Sun, Nov 05, 2023 at 01:03:51PM -0700, Simon Glass wrote:
> > >
> > > > This image type is supposed to ignore the load address. But at present
> > > > it fails if the load address is missing. If it is zero, the image is
> > > > loaded at address 0, which may not work on all boards.
> > > >
> > > > Make use of the kernel_addr_r environment variable, instead, since this
> > > > seems to be a more reliable final address for the kernel.
> > > >
> > > > Another option would be to create a new Kconfig for this, or to use a
> > > > region of memory known to be free, e.g. calculated from the DRAM banks.
> > > > But in any case we should try to avoid conflicting with the
> > > > kernel_addr_r variable. So the approach in this patch seems reasonable
> > > > to me.
> > > >
> > > > Signed-off-by: Simon Glass 
> > >
> > > How are you creating the image in question here? A noload FIT is
> > > supposed to just supposed to go from where it is. Where do things fall
> > > down later?
> >
> > The image is Image.gz built by Linux, for example. So compression =
> > "gzip" which means that it has to be decompressed.
> >
> > Things fall down as soon as U-Boot looks at the image, since it
> > doesn't have the ARM64 magic.
>
> Can you provide logs and env? "booti" is supposed to handle this case
> already, and if it's not we should figure out when / why it broke.

Do you mean booti handles compression? Yes, I can see that in the code.

But in my case I am using bootm, since it is a FIT.

Regards,
Simon

Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow

On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
> Hi Simon,
> 
> On Mon, Nov 6, 2023 at 9:25 AM Simon Glass  wrote:
> >
> > Hi Tony,
> >
> > On Wed, 4 Oct 2023 at 21:23, Tony Dinh  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass  wrote:
> > > > >
> > > > > Hi Tony,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh  wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Tony,
> > > > > > >
> > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > Here is an observation during testing the bootflow command.
> > > > > > > >
> > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will 
> > > > > > > > remove that existing
> > > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow 
> > > > > > > > again, and it was
> > > > > > > > back to normal. Perhaps there is some kind of indexing problem?
> > > > > > >
> > > > > > > Yes that's right. The 'botflow scan' command is not additive. The
> > > > > > > first thing it does is removing existing bootflows.
> > > > > >
> > > > > > Thanks for clarifying that. I assumed it is additive, because the
> > > > > > existing USB bootflow was not removed when I did a "bootflow scan
> > > > > > scsi" immediately after (see the end of the log).
> > > > >
> > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug?
> > > > > When you scan SCSI it should not also scan USB.
> > > >
> > > > Yes, it looks like a bug. I think I can see the problem and am working
> > > > on a patch.
> > >
> > > Just to let you know, I'm out of time to work on this topic. I will
> > > revisit it some other time, if you have not already tracked it down.
> >
> > If you are able to use 'bootflow scan -l' in each case, then I might
> > be able to see what it is scanning USB, when you are asking for SCSI.
> > I also wonder if this bug may have been fixed due to other changes?
> 
> I'm wondering about that, too. I will rerun the test with the master
> branch with debug trace. If we cannot see it, I'll do it again when
> other bootstd patches are merged. Right now I am not sure which of
> your bootstd patches I should apply to the tree for testing, do you
> have a list for that?

Right now the only outstanding bootstd patch I know of is your recent
one, as I was waiting for Simon's review (which he did today) before
merging and applying.

-- 
Tom


signature.asc
Description: PGP signature

[ANN] U-Boot v2024.01-rc2 released

Hey all,

It's release day and here is -rc2. Looking at my own queue I think I've
got everything out that's not for -next, but there might be a few fixes
I've overlooked and will give things a harder read once I've merged
other things in to -next and the page is just more readable to me.

Speaking of, the next branch is now open and set to -rc2.

In terms of a changelog, 
git log --merges v2024.01-rc1..v2024.01-rc2
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

I hope to remain on schedule and that means the rest of the rcs every
other Monday, and with final release on January 8th, 2024.  Thanks all!

-- 
Tom


signature.asc
Description: PGP signature

Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow

2023-11-06 Thread Tony Dinh

Hi Simon,

On Mon, Nov 6, 2023 at 9:25 AM Simon Glass  wrote:
>
> Hi Tony,
>
> On Wed, 4 Oct 2023 at 21:23, Tony Dinh  wrote:
> >
> > Hi Simon,
> >
> > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass  wrote:
> > > >
> > > > Hi Tony,
> > > >
> > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass  wrote:
> > > > > >
> > > > > > Hi Tony,
> > > > > >
> > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh  wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Here is an observation during testing the bootflow command.
> > > > > > >
> > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will 
> > > > > > > remove that existing
> > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow 
> > > > > > > again, and it was
> > > > > > > back to normal. Perhaps there is some kind of indexing problem?
> > > > > >
> > > > > > Yes that's right. The 'botflow scan' command is not additive. The
> > > > > > first thing it does is removing existing bootflows.
> > > > >
> > > > > Thanks for clarifying that. I assumed it is additive, because the
> > > > > existing USB bootflow was not removed when I did a "bootflow scan
> > > > > scsi" immediately after (see the end of the log).
> > > >
> > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug?
> > > > When you scan SCSI it should not also scan USB.
> > >
> > > Yes, it looks like a bug. I think I can see the problem and am working
> > > on a patch.
> >
> > Just to let you know, I'm out of time to work on this topic. I will
> > revisit it some other time, if you have not already tracked it down.
>
> If you are able to use 'bootflow scan -l' in each case, then I might
> be able to see what it is scanning USB, when you are asking for SCSI.
> I also wonder if this bug may have been fixed due to other changes?

I'm wondering about that, too. I will rerun the test with the master
branch with debug trace. If we cannot see it, I'll do it again when
other bootstd patches are merged. Right now I am not sure which of
your bootstd patches I should apply to the tree for testing, do you
have a list for that?

All the best,
Tony

>
> Regards,
> Simon

Re: [PATCH 1/4] bootm: Allow ignoring the load address with kernel_noload

On Mon, Nov 06, 2023 at 10:25:00AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 5 Nov 2023 at 14:19, Tom Rini  wrote:
> >
> > On Sun, Nov 05, 2023 at 01:03:51PM -0700, Simon Glass wrote:
> >
> > > This image type is supposed to ignore the load address. But at present
> > > it fails if the load address is missing. If it is zero, the image is
> > > loaded at address 0, which may not work on all boards.
> > >
> > > Make use of the kernel_addr_r environment variable, instead, since this
> > > seems to be a more reliable final address for the kernel.
> > >
> > > Another option would be to create a new Kconfig for this, or to use a
> > > region of memory known to be free, e.g. calculated from the DRAM banks.
> > > But in any case we should try to avoid conflicting with the
> > > kernel_addr_r variable. So the approach in this patch seems reasonable
> > > to me.
> > >
> > > Signed-off-by: Simon Glass 
> >
> > How are you creating the image in question here? A noload FIT is
> > supposed to just supposed to go from where it is. Where do things fall
> > down later?
> 
> The image is Image.gz built by Linux, for example. So compression =
> "gzip" which means that it has to be decompressed.
> 
> Things fall down as soon as U-Boot looks at the image, since it
> doesn't have the ARM64 magic.

Can you provide logs and env? "booti" is supposed to handle this case
already, and if it's not we should figure out when / why it broke.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] powerpc: mpc8xx: Remove usage of common.h

2023-11-06 Thread Christophe Leroy

Remove inclusion of common.h and add relevant
includes when necessary.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/cpu/mpc8xx/cache.c  | 1 -
 arch/powerpc/cpu/mpc8xx/cpu.c| 1 -
 arch/powerpc/cpu/mpc8xx/cpu_init.c   | 1 -
 arch/powerpc/cpu/mpc8xx/fdt.c| 1 -
 arch/powerpc/cpu/mpc8xx/immap.c  | 2 +-
 arch/powerpc/cpu/mpc8xx/interrupts.c | 2 +-
 arch/powerpc/cpu/mpc8xx/speed.c  | 2 +-
 arch/powerpc/cpu/mpc8xx/traps.c  | 2 +-
 8 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xx/cache.c b/arch/powerpc/cpu/mpc8xx/cache.c
index 41559009ca..525c87f37c 100644
--- a/arch/powerpc/cpu/mpc8xx/cache.c
+++ b/arch/powerpc/cpu/mpc8xx/cache.c
@@ -4,7 +4,6 @@
  * Christophe Leroy, CS Systemes d'Information, christophe.le...@c-s.fr
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/cpu/mpc8xx/cpu.c b/arch/powerpc/cpu/mpc8xx/cpu.c
index 56383cecde..b9afd312ec 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu.c
@@ -16,7 +16,6 @@
  * Wolfgang Denk 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/cpu/mpc8xx/cpu_init.c 
b/arch/powerpc/cpu/mpc8xx/cpu_init.c
index feef792ee7..aac4203a6e 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu_init.c
@@ -4,7 +4,6 @@
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  */
 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/cpu/mpc8xx/fdt.c b/arch/powerpc/cpu/mpc8xx/fdt.c
index b4a26efe30..b204a3d751 100644
--- a/arch/powerpc/cpu/mpc8xx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xx/fdt.c
@@ -5,7 +5,6 @@
  * Code copied & edited from Freescale mpc85xx stuff.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/cpu/mpc8xx/immap.c b/arch/powerpc/cpu/mpc8xx/immap.c
index 40793c26e1..8c85fc180b 100644
--- a/arch/powerpc/cpu/mpc8xx/immap.c
+++ b/arch/powerpc/cpu/mpc8xx/immap.c
@@ -8,7 +8,6 @@
  * MPC8xx Internal Memory Map Functions
  */
 
-#include 
 #include 
 #include 
 
@@ -16,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/arch/powerpc/cpu/mpc8xx/interrupts.c 
b/arch/powerpc/cpu/mpc8xx/interrupts.c
index eef1951f2f..babef07ffb 100644
--- a/arch/powerpc/cpu/mpc8xx/interrupts.c
+++ b/arch/powerpc/cpu/mpc8xx/interrupts.c
@@ -4,7 +4,7 @@
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/cpu/mpc8xx/speed.c b/arch/powerpc/cpu/mpc8xx/speed.c
index 1a882a3882..baf81381b3 100644
--- a/arch/powerpc/cpu/mpc8xx/speed.c
+++ b/arch/powerpc/cpu/mpc8xx/speed.c
@@ -4,12 +4,12 @@
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/arch/powerpc/cpu/mpc8xx/traps.c b/arch/powerpc/cpu/mpc8xx/traps.c
index 56794b08a1..5220c560e5 100644
--- a/arch/powerpc/cpu/mpc8xx/traps.c
+++ b/arch/powerpc/cpu/mpc8xx/traps.c
@@ -15,7 +15,7 @@
  * This file handles the architecture-dependent parts of hardware exceptions
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.41.0

[PATCH] board: cssi: Remove usage of common.h

2023-11-06 Thread Christophe Leroy

Remove inclusion of common.h and add relevant
includes when necessary.

Signed-off-by: Christophe Leroy 
---
 board/cssi/cmpc885/cmpc885.c | 1 -
 board/cssi/cmpc885/nand.c| 1 -
 board/cssi/cmpc885/sdram.c   | 3 ++-
 board/cssi/cmpcpro/cmpcpro.c | 1 -
 board/cssi/mcr3000/mcr3000.c | 1 -
 board/cssi/mcr3000/nand.c| 1 -
 6 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/board/cssi/cmpc885/cmpc885.c b/board/cssi/cmpc885/cmpc885.c
index 5e6aa8b8cf..e11cfafaa5 100644
--- a/board/cssi/cmpc885/cmpc885.c
+++ b/board/cssi/cmpc885/cmpc885.c
@@ -9,7 +9,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/board/cssi/cmpc885/nand.c b/board/cssi/cmpc885/nand.c
index 38100046df..b8989f226b 100644
--- a/board/cssi/cmpc885/nand.c
+++ b/board/cssi/cmpc885/nand.c
@@ -7,7 +7,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/board/cssi/cmpc885/sdram.c b/board/cssi/cmpc885/sdram.c
index 7349b85ed2..11a50c3a52 100644
--- a/board/cssi/cmpc885/sdram.c
+++ b/board/cssi/cmpc885/sdram.c
@@ -4,13 +4,14 @@
  * Charles Frey 
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/cssi/cmpcpro/cmpcpro.c b/board/cssi/cmpcpro/cmpcpro.c
index 8a30c48e35..ef30412456 100644
--- a/board/cssi/cmpcpro/cmpcpro.c
+++ b/board/cssi/cmpcpro/cmpcpro.c
@@ -4,7 +4,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/board/cssi/mcr3000/mcr3000.c b/board/cssi/mcr3000/mcr3000.c
index 3514f67490..8857c9e42c 100644
--- a/board/cssi/mcr3000/mcr3000.c
+++ b/board/cssi/mcr3000/mcr3000.c
@@ -7,7 +7,6 @@
  * Board specific routines for the MCR3000 board
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/board/cssi/mcr3000/nand.c b/board/cssi/mcr3000/nand.c
index 11aca4ff73..5b01d30fef 100644
--- a/board/cssi/mcr3000/nand.c
+++ b/board/cssi/mcr3000/nand.c
@@ -6,7 +6,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.41.0

Re: [PATCH] rockchip: rk3588-rock-5b: Enable CONFIG_PCI_INIT_R to support EFI networking

2023-11-06 Thread Jonas Karlman

Hi Martin,

On 2023-11-04 14:04, Martin Roukala (né Peres) wrote:
> When u-boot chainloads an EFI bootloader such as iPXE, we want to have
> already initialized the PCI subsystem so that network driver is loaded
> and ready to use by the bootloader.

This change slows down boot from emmc/sd-card where scanning for pci
devices typically is unnecessary.

If pci must be initialized and scanned before an EFI app is started to
find pci network controllers, then pci should probably be initialized by
the efi bootmeth, not by enabling CONFIG_PCI_INIT_R for a single board.

Regards,
Jonas

> 
> Fixes: 191ece249a96 ("rockchip: rk3588-rock-5b: Enable support for PCIe SATA 
> cards")
> Signed-off-by: Martin Roukala (né Peres) 
> ---
>  configs/rock5b-rk3588_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
> index 0595325e81..938137c851 100644
> --- a/configs/rock5b-rk3588_defconfig
> +++ b/configs/rock5b-rk3588_defconfig
> @@ -36,6 +36,7 @@ CONFIG_OF_BOARD_SETUP=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_PCI_INIT_R=y
>  CONFIG_SPL_MAX_SIZE=0x4
>  CONFIG_SPL_PAD_TO=0x7f8000
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y

Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets

On 11/6/23 11:47 AM, Simon Glass wrote:

Hi Andrew,

On Mon, 6 Nov 2023 at 10:27, Andrew Davis wrote:

On 11/6/23 9:31 AM, Tom Rini wrote:

On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:

Hi Simon,

On 11:22-20231005, Simon Glass wrote:

Hi Nishanth,

On Thu, 5 Oct 2023 at 11:16, Nishanth Menon wrote:

On 12:10-20231005, Nishanth Menon wrote:

On 12:36-20231005, Tom Rini wrote:

On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:

On 10/4/23 8:54 AM, Nishanth Menon wrote:

On 08:48-20231004, Andrew Davis wrote:

On 10/4/23 8:23 AM, Roger Quadros wrote:

ti_mmc is not a valid boot_target for standard boot flow so

Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from FIT images with overlays?

envboot takes care of uEnv.txt file (see
https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/)

Early remote proc loading and FIT image is a question for stdboot itself.

If stdboot is missing these features then we shouldn't switch until it
has them. I'm all for switching to this, but only if it is complete.

Depends on what you mean? Did you mean an option to run scripts
(exists) or an option to do what TI needs done, via
boot/bootmeth_something.c ? If the latter, someone from TI needs to
figure out what that should be and do (but plumbing-wise everything it
needs should exist).

Andrew is generalizing here (on the wrong patch though).

On am62x platforms, there is nothing regressing with this series. The
challenge is early remote_proc loading which is done for J7* platforms.

How that is initiated as part of bootmethods is something of a gap.

The other gap has been support for uEnv.txt -> which we can workaround
at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan
-lb" in defconfig (This series from Roger already does that - hence I am
saying that Andrew is complaining on the wrong series).

Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and
uEnv.txt remoteproc loads and the various standard bootmethods should
"just work".

I forgot to add: FIT image authenticated boot flow. That is really what
ti_mmc distroboot method was trying to solve.

Maybe Simon or someone know how the stdboot flow handles authenticated
kernel image and dtb boot flow with FIT image?

Yes you can use FIT configuration verification and things should work as normal.

Could you give any reference documentation for this?

I suspect you should start with doc/usage/fit/beaglebone_vboot.rst

From that doc:

```
Boot the board using the commands below::

setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro
rootfstype=ext4 rootwait
ext2load mmc 0:2 8200 /boot/image.fit
bootm 8200
```

This is very much not stdboot :( This doc has some good and current info on
building
a secure FIT image, but much of it is showing its age. Stdboot is still missing

* ability to limit boot mode search to only one image (FIT)

What does this mean? Can you please be more specific or give an example?

Sure, for instance with secure boot we only want to search for FIT images
and if for each media this fails we do not want to fall back to other
image types or boot modes (like UART boot or net boot which would bypass
the signature checks).

Something similar is needed for searching for EFI compatible boot across
each enabled boot media first, before trying other methods on each media.
Basically breadth-first search on each media type not depth-first.

* fetching and applying FIT overlay/config strings

Re overlays, is this the 'extension' command? What are config strings?

When we have DT overlays in our FIT image, we build a string to pass to
bootm to apply all the selected overlays[0]. If there is now another
mechanism for this please let me know (building this string today is messy).

https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/ti_common.env?ref_type=heads#L18

* remote proc loading

What command can do this?

https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/ti_common.env?ref_type=heads#L28

* uEnv.txt processing

What command can do this?

run envboot;

https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/mmc.env?ref_type=heads#L20

Last two can be solved by adding to CONFIG_BOOTCOMMAND before calling `bootflow
scan`
as suggested above. Until we figure out the first two I don't see us ready to
switch.

I'm happy to help figure this out.

Thanks, we are eager to standardize our boot flows and stdboot seems like the
right way forward, very happy to have your guidance on these last few items :)

Andrew

Regards,
SImon

Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets

Hi Andrew,

On Mon, 6 Nov 2023 at 10:27, Andrew Davis  wrote:
>
> On 11/6/23 9:31 AM, Tom Rini wrote:
> > On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:
> >> Hi Simon,
> >>
> >> On 11:22-20231005, Simon Glass wrote:
> >>> Hi Nishanth,
> >>>
> >>> On Thu, 5 Oct 2023 at 11:16, Nishanth Menon  wrote:
> 
>  On 12:10-20231005, Nishanth Menon wrote:
> > On 12:36-20231005, Tom Rini wrote:
> >> On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:
> >>> On 10/4/23 8:54 AM, Nishanth Menon wrote:
>  On 08:48-20231004, Andrew Davis wrote:
> > On 10/4/23 8:23 AM, Roger Quadros wrote:
> >> ti_mmc is not a valid boot_target for standard boot flow so
> >
> > Is there some way to make it into a valid boot_target? Otherwise
> > how do we use uEnv.txt files, or boot from FIT images with overlays?
> 
>  envboot takes care of uEnv.txt file (see
>  https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/)
> 
>  Early remote proc loading and FIT image is a question for stdboot 
>  itself.
> 
> >>>
> >>> If stdboot is missing these features then we shouldn't switch until it
> >>> has them. I'm all for switching to this, but only if it is complete.
> >>
> >> Depends on what you mean?  Did you mean an option to run scripts
> >> (exists) or an option to do what TI needs done, via
> >> boot/bootmeth_something.c ?  If the latter, someone from TI needs to
> >> figure out what that should be and do (but plumbing-wise everything it
> >> needs should exist).
> >
> > Andrew is generalizing here (on the wrong patch though).
> >
> > On am62x platforms, there is nothing regressing with this series. The
> > challenge is early remote_proc loading which is done for J7* platforms.
> >
> > How that is initiated as part of bootmethods is something of a gap.
> >
> > The other gap has been support for uEnv.txt -> which we can workaround
> > at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan
> > -lb" in defconfig (This series from Roger already does that - hence I am
> > saying that Andrew is complaining on the wrong series).
> >
> > Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and
> > uEnv.txt remoteproc loads and the various standard bootmethods should
> > "just work".
> 
> 
>  I forgot to add: FIT image authenticated boot flow. That is really what
>  ti_mmc distroboot method was trying to solve.
> 
>  Maybe Simon or someone know how the stdboot flow handles authenticated
>  kernel image and dtb boot flow with FIT image?
> >>>
> >>> Yes you can use FIT configuration verification and things should work as 
> >>> normal.
> >>>
> >>
> >> Could you give any reference documentation for this?
> >
> > I suspect you should start with doc/usage/fit/beaglebone_vboot.rst
> >
>
>  From that doc:
>
> ```
> Boot the board using the commands below::
>
>  setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro 
> rootfstype=ext4 rootwait
>  ext2load mmc 0:2 8200 /boot/image.fit
>  bootm 8200
> ```
>
> This is very much not stdboot :( This doc has some good and current info on 
> building
> a secure FIT image, but much of it is showing its age. Stdboot is still 
> missing
>
>   * ability to limit boot mode search to only one image (FIT)

What does this mean? Can you please be more specific or give an example?

>   * fetching and applying FIT overlay/config strings

Re overlays, is this the 'extension' command? What are config strings?

>   * remote proc loading

What command can do this?

>   * uEnv.txt processing

What command can do this?

>
> Last two can be solved by adding to CONFIG_BOOTCOMMAND before calling 
> `bootflow scan`
> as suggested above. Until we figure out the first two I don't see us ready to 
> switch.

I'm happy to help figure this out.

Regards,
SImon

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-06 Thread Andre Przywara

On Mon, 6 Nov 2023 11:46:27 -0500
Tom Rini  wrote:

Hi Tom,

> On Sat, Nov 04, 2023 at 05:12:12PM +, Andre Przywara wrote:
> > On Fri, 3 Nov 2023 13:38:58 -0600
> > Simon Glass  wrote:
> > 
> > Hi Simon,
> >   
> > > Hi Heinrich,
> > > 
> > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > >  wrote:  
> > > >
> > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > Heinrich Schuchardt  wrote:
> > > > >
> > > > > Hi Heinrich,
> > > > >
> > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. It
> > > > >> provides an interface to a physical entropy source.
> > > > >>
> > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > >
> > > > > As you might have seen, I added a similar driver for the respective 
> > > > > Arm
> > > > > functionality:
> > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > >
> > > > > And I see that you seem to use the same mechanism to probe and init 
> > > > > the
> > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > implemented.
> > > > > One downside of this approach is that the driver is always loaded (and
> > > > > visible in the DM tree), even with the feature not being available.
> > > > > That doesn't seem too much of a problem on the first glance, but it
> > > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > > (like virtio-rng) typically get higher device numbers. So without
> > > > > the feature, but with virtio-rng, I get:
> > > > > VExpress64# rng 0
> > > > > No RNG device
> > > 
> > > Why do we get this? If the device is not there, the bind() function
> > > can return -ENODEV
> > > 
> > > I see this in U-Boot:
> > > 
> > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > 
> > > We should not use this.  
> > 
> > Agreed.
> >   
> > > Use the devicetree.  
> > 
> > No, this is definitely not something for the DT, at least not on ARM.
> > It's perfectly discoverable via the architected CPU ID registers.
> > Similar to PCI and USB devices, which we don't probe via the DT as well.
> > 
> > It's arguably not proper "driver" material per se, as I've argued before, 
> > but
> > it's the simplest solution and fits in nicely otherwise.
> > 
> > I was wondering if it might be something for UCLASS_CPU, something like
> > a "CPU feature bus": to let devices register on one on the many CPU
> > features (instead of compatible strings), then only bind() those
> > drivers it the respective bit is set.
> > 
> > Does that make sense? Would that be doable without boiling the ocean?
> > As I don't know if we see many users apart from this.  
> 
> I think we have a similar problem with how we're doing with DM_TIMER and
> armv7-a/armv7-m/armv8[1]. We shouldn't need the drivers in drivers/timer/
> to cover platforms where SYS_ARCH_TIMER is (or should be!) enabled. But
> in turn, the code under arch/arm/cpu/*/*timer.c doesn't implement the
> uclass side of things, only the regular API. This is because there's
> nothing to probe even because we don't support the kind of multi-arch
> binary where it'd be possible to not have the feature.

Well, normally we indeed build a U-Boot image for one particular board,
and chips typically don't gain new hardware features over night while
sitting on the shelf.
But then we also support software models (QEMU, Arm FVP) and "more
flexible" hardware (like FPGA platforms), where the CPU features are
indeed in flux. In QEMU it's as easy as "-cpu max", and people use that to
test new architecture features. 

For the arch timer it's a slightly different story, since every halfway
recent chip has it, but still we try to detect it at places, as it's easy
enough to do.

So I do believe there is some place for auto-detection, even in U-Boot.

Cheers,
Andre.

Re: Need advise with u-boot on SH-7785LCR

2023-11-06 Thread John Paul Adrian Glaubitz

Hi Simon!

On Mon, 2023-11-06 at 10:24 -0700, Simon Glass wrote:
> > So, I assume, I should just be able to write u-boot.bin to /dev/mtdblock0?
> 
> Maybe, but you will likely brick the device if you have no other way
> to write to flash.

The flash memory is actually on a daughter board that can be easily replaced
and I have multiple of these daughter boards. It turns out that just writing
the image to /dev/mtdblock0 works and I can boot the board into the freshly
flashed u-boot version.

However, the u-boot version 2019.01 built from git won't work while the old
2014.01 version that I copied onto disk from /dev/mtdblock0 does work when
flashing it to a second daughter board.

So, flashing works indeed like this and I can successfully start u-boot after
flashing it into /dev/mtdblock0. Now I just need to figure out what the 
difference
between 2014.01 and 2019.01 is and why the latter doesn't work.

I have uploaded both versions here:

> https://people.debian.org/~glaubitz/u-boot-sh7785lcr/

Maybe someone with more experience can spot anything obvious like incorrect
address offsets etc.

PS: I'm actually called Adrian, despite the long name ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets


On 11/6/23 9:31 AM, Tom Rini wrote:

On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:

Hi Simon,

On 11:22-20231005, Simon Glass wrote:

Hi Nishanth,

On Thu, 5 Oct 2023 at 11:16, Nishanth Menon  wrote:


On 12:10-20231005, Nishanth Menon wrote:

On 12:36-20231005, Tom Rini wrote:

On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:

On 10/4/23 8:54 AM, Nishanth Menon wrote:

On 08:48-20231004, Andrew Davis wrote:

On 10/4/23 8:23 AM, Roger Quadros wrote:

ti_mmc is not a valid boot_target for standard boot flow so


Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from FIT images with overlays?


envboot takes care of uEnv.txt file (see
https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/)

Early remote proc loading and FIT image is a question for stdboot itself.



If stdboot is missing these features then we shouldn't switch until it
has them. I'm all for switching to this, but only if it is complete.


Depends on what you mean?  Did you mean an option to run scripts
(exists) or an option to do what TI needs done, via
boot/bootmeth_something.c ?  If the latter, someone from TI needs to
figure out what that should be and do (but plumbing-wise everything it
needs should exist).


Andrew is generalizing here (on the wrong patch though).

On am62x platforms, there is nothing regressing with this series. The
challenge is early remote_proc loading which is done for J7* platforms.

How that is initiated as part of bootmethods is something of a gap.

The other gap has been support for uEnv.txt -> which we can workaround
at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan
-lb" in defconfig (This series from Roger already does that - hence I am
saying that Andrew is complaining on the wrong series).

Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and
uEnv.txt remoteproc loads and the various standard bootmethods should
"just work".



I forgot to add: FIT image authenticated boot flow. That is really what
ti_mmc distroboot method was trying to solve.

Maybe Simon or someone know how the stdboot flow handles authenticated
kernel image and dtb boot flow with FIT image?


Yes you can use FIT configuration verification and things should work as normal.



Could you give any reference documentation for this?


I suspect you should start with doc/usage/fit/beaglebone_vboot.rst



From that doc:

```
Boot the board using the commands below::

setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro 
rootfstype=ext4 rootwait
ext2load mmc 0:2 8200 /boot/image.fit
bootm 8200
```

This is very much not stdboot :( This doc has some good and current info on 
building
a secure FIT image, but much of it is showing its age. Stdboot is still missing

 * ability to limit boot mode search to only one image (FIT)
 * fetching and applying FIT overlay/config strings
 * remote proc loading
 * uEnv.txt processing

Last two can be solved by adding to CONFIG_BOOTCOMMAND before calling `bootflow 
scan`
as suggested above. Until we figure out the first two I don't see us ready to 
switch.

Andrew

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-06 Thread Andre Przywara

On Sat, 4 Nov 2023 19:45:06 +
Simon Glass  wrote:

Hi,

> On Sat, 4 Nov 2023 at 17:13, Andre Przywara  wrote:
> >
> > On Fri, 3 Nov 2023 13:38:58 -0600
> > Simon Glass  wrote:
> >
> > Hi Simon,
> >  
> > > Hi Heinrich,
> > >
> > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > >  wrote:  
> > > >
> > > > On 11/1/23 19:05, Andre Przywara wrote:  
> > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > Heinrich Schuchardt  wrote:
> > > > >
> > > > > Hi Heinrich,
> > > > >  
> > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. It
> > > > >> provides an interface to a physical entropy source.
> > > > >>
> > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > >> mseccfg.sseed being set in the SBI firmware.  
> > > > >
> > > > > As you might have seen, I added a similar driver for the respective 
> > > > > Arm
> > > > > functionality:
> > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > >
> > > > > And I see that you seem to use the same mechanism to probe and init 
> > > > > the
> > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > implemented.
> > > > > One downside of this approach is that the driver is always loaded (and
> > > > > visible in the DM tree), even with the feature not being available.
> > > > > That doesn't seem too much of a problem on the first glance, but it
> > > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > > (like virtio-rng) typically get higher device numbers. So without
> > > > > the feature, but with virtio-rng, I get:
> > > > > VExpress64# rng 0
> > > > > No RNG device  
> > >
> > > Why do we get this? If the device is not there, the bind() function
> > > can return -ENODEV
> > >
> > > I see this in U-Boot:
> > >
> > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > >
> > > We should not use this.  
> >
> > Agreed.
> >  
> > > Use the devicetree.  
> >
> > No, this is definitely not something for the DT, at least not on ARM.
> > It's perfectly discoverable via the architected CPU ID registers.
> > Similar to PCI and USB devices, which we don't probe via the DT as well.
> >
> > It's arguably not proper "driver" material per se, as I've argued before, 
> > but
> > it's the simplest solution and fits in nicely otherwise.
> >
> > I was wondering if it might be something for UCLASS_CPU, something like
> > a "CPU feature bus": to let devices register on one on the many CPU
> > features (instead of compatible strings), then only bind() those
> > drivers it the respective bit is set.
> >
> > Does that make sense? Would that be doable without boiling the ocean?
> > As I don't know if we see many users apart from this.  
> 
> I have seen this so many times, where people want to avoid putting
> things in the DT and then are surprised that everything is difficult,
> broken and confusing. Why not just follow the rules? It is not just
> about whether we can avoid it, etc. It is about how devices fit
> together cohesively in the system, and how U-Boot operates.

A devicetree is only for peripherals *that cannot be located by probing*.
Which are traditionally most peripherals in non-server Arm SoCs. While I
do love the DT, the best DT node is the one you don't need.

But as Heinrich also said: those instructions are not peripherals, they
are part of an instruction set extensions, the same story as with x86's
RDRAND instruction. We don't have those in ACPI or so as well, because
CPUID has you covered. The same on ARM, ID_AA64ISAR0_EL1 is readable on
every chip (outside of EL0), and tells you whether you have the RNDR
register or not. IIUC RISC-V is slightly different here, since not all ISA
extensions are covered by CSRs, hence some of them indeed listed in the DT.

So a proper solution(TM) would be to split this up in architectural
*instructions* and proper TRNG *devices*, maybe wrapping this up in some
function that tests both. This is roughly what the kernel does, somewhat
abstracted by the concept of "entropy sources", which could be TRNG
devices, CPU instructions, interrupt jitter or even "instruction execution
jitter"[1], with the latter two definitely not being devices really at all.

But I don't know if U-Boot wants to go through the hassle of this whole
framework, as we tend to implement things much easier. But a simple
get_cpu_random() function, implemented per architecture, and with some
kind of success flag, should be easy enough to do. Then either the users
(UEFI?) explicitly call this before trying UCLASS_RNG, or we wrap this for
every RNG user.

Cheers,
Andre

> > > > > VExpress64# rng 1
> > > > > : f3 88 b6 d4 24 da 49 ca 49 f7 9e 66 5f 12 07 b2  
> > > > > $.I.I..f_...  
> > > >
> > > >
> > > > Essentially in any case were you have multiple drivers for the same
> > > > device using uclass_get_device(, 0, ) and uclass_find_first_device()
> > > > will only give you the first bound device and not the first successfully
>

Re: [PATCH v2] bootstd: Skip over bad device during bootflows scanning

On Thu, 2 Nov 2023 at 12:51, Tony Dinh  wrote:
>
> During bootstd scanning for bootdevs, if bootdev_hunt_drv() encounters
> a device not found error (e.g. ENOENT), let it return a successful status
> so that bootstd will continue scanning the next devices, not stopping
> prematurely.
>
> Background:
>
> During scanning for bootflows, it's possible for bootstd to encounter a
> faulty device controller. Also when the same u-boot is used for another
> variant of the same board, some device controller such as SATA might
> not exist.
>
> I've found this issue while converting the Marvell Sheevaplug board to
> use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
> USB only, but the later variant comes with USB, MMC, and eSATA ports. We
> have been using the same u-boot (starting with CONFIG_IDE and later with DM
> CONFIG_SATA) for both variants. This worked well with the old
> envs-scripting booting scheme.
>
> Signed-off-by: Tony Dinh 
> ---
>
> Changes in v2:
> - Restore bootdev_next_prio() to the original.
> - Add a check in bootdev_hunt_drv(). If its descendant bootdev hunt driver
> function returns -ENOENT, set the hunt status to successful (this is the
> case where the device does not exist, or a bad device controller).
> - Update bootdev_hunter_func() docs to indicate that a return
> status -ENOENT is not an error, just a "device not found" status.
> - Set status of sata_rescan() to -ENOENT when the SATA device is not found.
>
>  boot/bootdev-uclass.c | 2 +-
>  drivers/ata/sata.c| 2 +-
>  include/bootdev.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH v2 1/2] driver: power: add support for TPS65224

Hi Bhargav,

On Mon, 6 Nov 2023 at 10:11, Bhargav Raviprakash  wrote:
>
> Added support for PMIC TPS65224. Includes driver for pmic,
> and disabling Watchdog.
>
> Signed-off-by: Bhargav Raviprakash 
> ---
>  drivers/power/pmic/Kconfig|   6 ++
>  drivers/power/pmic/Makefile   |   1 +
>  drivers/power/pmic/tps65224.c | 141 ++
>  include/power/tps65224.h  |  57 ++
>  4 files changed, 205 insertions(+)
>  create mode 100644 drivers/power/pmic/tps65224.c
>  create mode 100644 include/power/tps65224.h
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 4a6f0ce093..b06bd31823 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -378,6 +378,12 @@ config PMIC_TPS65941
> The TPS65941 is a PMIC containing a bunch of SMPS & LDOs.
> This driver binds the pmic children.
>
> +config PMIC_TPS65224
> +   bool "Enable driver for Texas Instruments TPS65224 PMIC"
> +   help
> +   The TPS65224 is a PMIC containing a bunch of SMPS & LDOs.
> +   This driver binds the pmic children.
> +
>  config PMIC_TPS65219
> bool "Enable driver for Texas Instruments TPS65219 PMIC"
> depends on DM_PMIC
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 0b3b3d62d0..cec16e57d3 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
>  obj-$(CONFIG_PMIC_TPS65217) += pmic_tps65217.o
>  obj-$(CONFIG_PMIC_TPS65219) += tps65219.o
>  obj-$(CONFIG_PMIC_TPS65941) += tps65941.o
> +obj-$(CONFIG_PMIC_TPS65224) += tps65224.o
>  obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
>
>  ifeq ($(CONFIG_$(SPL_)POWER_LEGACY),y)
> diff --git a/drivers/power/pmic/tps65224.c b/drivers/power/pmic/tps65224.c
> new file mode 100644
> index 00..33395f6edf
> --- /dev/null
> +++ b/drivers/power/pmic/tps65224.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2023 Texas Instruments Incorporated, 
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> +   { .prefix = "ldo", .driver = TPS65224_LDO_DRIVER },
> +   { .prefix = "buck", .driver = TPS65224_BUCK_DRIVER },
> +   { },
> +};
> +
> +static int tps65224_write(struct udevice *dev, uint reg, const uint8_t *buff,
> + int len)
> +{
> +   if (dm_i2c_write(dev, reg, buff, len)) {
> +   pr_err("write error to device: %p register: %#x!\n", dev, 
> reg);
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
> +static int tps65224_read(struct udevice *dev, uint reg, uint8_t *buff, int 
> len)
> +{
> +   if (dm_i2c_read(dev, reg, buff, len)) {
> +   pr_err("read error from device: %p register: %#x!\n", dev, 
> reg);
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
> +static int tps65224_bind(struct udevice *dev)
> +{
> +   ofnode regulators_node;
> +   int children;
> +
> +   if (dev->driver_data == TPS65224_WD)
> +   return 0;
> +
> +   regulators_node = dev_read_subnode(dev, "regulators");
> +   if (!ofnode_valid(regulators_node)) {
> +   debug("%s: %s regulators subnode not found!\n", __func__,
> + dev->name);
> +   return -ENXIO;
> +   }
> +
> +   debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
> +
> +   children = pmic_bind_children(dev, regulators_node, 
> pmic_children_info);
> +   if (!children)
> +   printf("%s: %s - no child found\n", __func__, dev->name);
> +
> +   /* Probe all the child devices */

bind, not probe

> +   return dm_scan_fdt_dev(dev);
> +}
> +
> +static int stop_watchdog(struct udevice *wd_i2c_dev)
> +{
> +   int ret;
> +
> +   /* Maintain WD long window */
> +   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
> +   if (ret < 0) {
> +   debug("failed to read i2c reg (%d)\n", ret);
> +   return ret;
> +   }
> +
> +   ret &= ~TPS65224_WD_PWRHOLD_MASK;
> +   ret |= TPS65224_WD_PWRHOLD_MASK;
> +   ret = dm_i2c_reg_write(wd_i2c_dev, TPS65224_WD_MODE_REG, ret);
> +   if (ret) {
> +   debug("%s: %s write WD_PWRHOLD fail!\n", __func__, 
> wd_i2c_dev->name);
> +   return ret;
> +   }
> +
> +   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
> +   if (ret < 0) {
> +   debug("failed to read back i2c reg (%d)\n", ret);
> +   return ret;
> +   }
> +
> +   /* Disable WD */
> +   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_THR_CFG);
> +   if (ret < 0) {
> +   debug("failed to read i2c reg (%d)\n", ret);
> +   return ret;
> +   }
> +
> +   ret &=

Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow

Hi Tony,

On Wed, 4 Oct 2023 at 21:23, Tony Dinh  wrote:
>
> Hi Simon,
>
> On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh  wrote:
> >
> > Hi Simon,
> >
> > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass  wrote:
> > >
> > > Hi Tony,
> > >
> > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass  wrote:
> > > > >
> > > > > Hi Tony,
> > > > >
> > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh  wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > Here is an observation during testing the bootflow command.
> > > > > >
> > > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove 
> > > > > > that existing
> > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, 
> > > > > > and it was
> > > > > > back to normal. Perhaps there is some kind of indexing problem?
> > > > >
> > > > > Yes that's right. The 'botflow scan' command is not additive. The
> > > > > first thing it does is removing existing bootflows.
> > > >
> > > > Thanks for clarifying that. I assumed it is additive, because the
> > > > existing USB bootflow was not removed when I did a "bootflow scan
> > > > scsi" immediately after (see the end of the log).
> > >
> > > Yes, but I'm not sure what is going on there. Perhaps it is a bug?
> > > When you scan SCSI it should not also scan USB.
> >
> > Yes, it looks like a bug. I think I can see the problem and am working
> > on a patch.
>
> Just to let you know, I'm out of time to work on this topic. I will
> revisit it some other time, if you have not already tracked it down.

If you are able to use 'bootflow scan -l' in each case, then I might
be able to see what it is scanning USB, when you are asking for SCSI.
I also wonder if this bug may have been fixed due to other changes?

Regards,
Simon

Re: [PATCH 2/4] bootm: Move arm64-image processing later

Hi Tom,

On Sun, 5 Nov 2023 at 14:20, Tom Rini  wrote:
>
> On Sun, Nov 05, 2023 at 01:03:52PM -0700, Simon Glass wrote:
>
> > If the image is compressed, then the existing check fails, since the
> > header is wrong.
> >
> > Move the check later in the boot process, after the kernel is
> > decompressed. This allows use of bootm with compressed kernels, while
> > still permitting an uncompressed kernel to be used.
> >
> > Signed-off-by: Simon Glass 
>
> How are we getting in to this case exactly?

By using a compressed ARM64 image, e.g. Image.gz

Regards,
Simon

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

Hi Tom,

On Mon, 6 Nov 2023 at 09:46, Tom Rini  wrote:
>
> On Sat, Nov 04, 2023 at 05:12:12PM +, Andre Przywara wrote:
> > On Fri, 3 Nov 2023 13:38:58 -0600
> > Simon Glass  wrote:
> >
> > Hi Simon,
> >
> > > Hi Heinrich,
> > >
> > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > >  wrote:
> > > >
> > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > Heinrich Schuchardt  wrote:
> > > > >
> > > > > Hi Heinrich,
> > > > >
> > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. It
> > > > >> provides an interface to a physical entropy source.
> > > > >>
> > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > >
> > > > > As you might have seen, I added a similar driver for the respective 
> > > > > Arm
> > > > > functionality:
> > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > >
> > > > > And I see that you seem to use the same mechanism to probe and init 
> > > > > the
> > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > > implemented.
> > > > > One downside of this approach is that the driver is always loaded (and
> > > > > visible in the DM tree), even with the feature not being available.
> > > > > That doesn't seem too much of a problem on the first glance, but it
> > > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > > (like virtio-rng) typically get higher device numbers. So without
> > > > > the feature, but with virtio-rng, I get:
> > > > > VExpress64# rng 0
> > > > > No RNG device
> > >
> > > Why do we get this? If the device is not there, the bind() function
> > > can return -ENODEV
> > >
> > > I see this in U-Boot:
> > >
> > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > >
> > > We should not use this.
> >
> > Agreed.
> >
> > > Use the devicetree.
> >
> > No, this is definitely not something for the DT, at least not on ARM.
> > It's perfectly discoverable via the architected CPU ID registers.
> > Similar to PCI and USB devices, which we don't probe via the DT as well.
> >
> > It's arguably not proper "driver" material per se, as I've argued before, 
> > but
> > it's the simplest solution and fits in nicely otherwise.
> >
> > I was wondering if it might be something for UCLASS_CPU, something like
> > a "CPU feature bus": to let devices register on one on the many CPU
> > features (instead of compatible strings), then only bind() those
> > drivers it the respective bit is set.
> >
> > Does that make sense? Would that be doable without boiling the ocean?
> > As I don't know if we see many users apart from this.
>
> I think we have a similar problem with how we're doing with DM_TIMER and
> armv7-a/armv7-m/armv8[1]. We shouldn't need the drivers in drivers/timer/
> to cover platforms where SYS_ARCH_TIMER is (or should be!) enabled. But
> in turn, the code under arch/arm/cpu/*/*timer.c doesn't implement the
> uclass side of things, only the regular API. This is because there's
> nothing to probe even because we don't support the kind of multi-arch
> binary where it'd be possible to not have the feature.

The difference here is that there is only one timer device, at least
in hardware I have used.

I am leaning towards NAKing this and any future use of
U_BOOT_DRVINFO(), in favour of a proper DT binding. It's time we
stopped making this so hard. I'll reply on the other thread.

Regards,
Simon



>
> --
> Tom
>
> [1]: We do have the problem of armv7-r not having this feature so things
> like say TI K3 platforms need the platform driver on the Cortex-R host.
> A similar issue is the pre-ARMv7 i.MX platforms.

Re: [PATCH 1/1] rng: detect RISC-V Zkr RNG device in bind method

Hi Heinrich,

On Sun, 5 Nov 2023 at 14:54, Heinrich Schuchardt
 wrote:
>
> On 11/5/23 18:25, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sun, 5 Nov 2023 at 03:47, Heinrich Schuchardt
> >  wrote:
> >>
> >> On 11/4/23 21:42, Simon Glass wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Sat, 4 Nov 2023 at 06:51, Heinrich Schuchardt
> >>>  wrote:
> 
>  The existence of devices should be checked in the bind method and not in
>  the probe method. Adjust the RISC-V Zkr RNG driver accordingly.
> 
>  Use ENOENT (and not ENODEV) to signal that the device is not available.
> 
>  Fixes: ceec977ba1a9 ("rng: Provide a RNG based on the RISC-V Zkr ISA 
>  extension")
>  Reported-by: Andre Przywara 
>  Signed-off-by: Heinrich Schuchardt 
>  ---
> drivers/rng/riscv_zkr_rng.c | 34 ++
> 1 file changed, 26 insertions(+), 8 deletions(-)
> >>>
> >>> This device should be in the DT, so you have some control over which
> >>> RNG is used.
> >>
> >> The device-tree provided by QEMU does not contain such a device as Zkr
> >> is an ISA extension and not a device. This device-tree is not under the
> >> control of the U-Boot project.
> >
> > Why do you bring up QEMU? I would expect that it follows the norma dt
> > bindings, so it should not be any different from real hardware?
>
> Yes Simon, QEMU follows the normal bindings. If you want to change
> these, please, contribute to the RISC-V working groups or to the Linux
> kernel project.

Rick, can you help with this? I am thinking of something like this as
a top-level node:

rng {
compatible = "riscv,zkr";
};

>
> >
> > Anyway, you could add it. It is just a binding. I believe RISC-V has
> > all sorts of isa options which result in different machine features.
> >
> > What are you going to do when you want to choose between the ISA RNG
> > and a TPM one?
>
> First of all there are different configurations switches for both
> drivers. But of course you can enable both. They will be different
> U-Boot devices. The rng command has a parameter to choose a RNG device
> by device number. This is not different to having two USB drives.

Did you see the other discussion about this? Without a propert driver,
there is no way to choose which RNG device is used.

Also the comment is very clear:

/**
 * struct driver_info - Information required to instantiate a device
 *
 * NOTE: Avoid using this except in extreme circumstances, where device tree
 * is not feasible (e.g. serial driver in SPL where <8KB of SRAM is
 * available). U-Boot's driver model uses device tree for configuration.

Do we need a build-time warning so people don't forget this?

Regards,
Simon

Re: [PATCH 1/4] bootm: Allow ignoring the load address with kernel_noload

Hi Tom,

On Sun, 5 Nov 2023 at 14:19, Tom Rini  wrote:
>
> On Sun, Nov 05, 2023 at 01:03:51PM -0700, Simon Glass wrote:
>
> > This image type is supposed to ignore the load address. But at present
> > it fails if the load address is missing. If it is zero, the image is
> > loaded at address 0, which may not work on all boards.
> >
> > Make use of the kernel_addr_r environment variable, instead, since this
> > seems to be a more reliable final address for the kernel.
> >
> > Another option would be to create a new Kconfig for this, or to use a
> > region of memory known to be free, e.g. calculated from the DRAM banks.
> > But in any case we should try to avoid conflicting with the
> > kernel_addr_r variable. So the approach in this patch seems reasonable
> > to me.
> >
> > Signed-off-by: Simon Glass 
>
> How are you creating the image in question here? A noload FIT is
> supposed to just supposed to go from where it is. Where do things fall
> down later?

The image is Image.gz built by Linux, for example. So compression =
"gzip" which means that it has to be decompressed.

Things fall down as soon as U-Boot looks at the image, since it
doesn't have the ARM64 magic.

Regards,
Simon

Re: Need advise with u-boot on SH-7785LCR

Hi John,

On Mon, 6 Nov 2023 at 15:00, John Paul Adrian Glaubitz
 wrote:
>
> Hi Simon,
>
> On Sun, 2023-11-05 at 16:29 +, Simon Glass wrote:
> > No, sorry I don't have any idea about that. You could check the
> > MAINTAINERS files in U-Boot and Linux for other people, perhaps, or
> > check commit / blame logs?
>
> It seems that the flash memory is mapped to block devices by the kernel:
>
> root@tirpitz:~> dmesg|grep -i flash
> [1.592000] physmap-flash physmap-flash.0: physmap platform flash device: 
> [mem 0x-0x03ff]
> [1.604000] physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank. 
> Manufacturer ID 0x01 Chip ID 0x002201
> [1.632000] Creating 4 MTD partitions on "physmap-flash.0":
> root@tirpitz:~> ls -l /dev/mtdblock*
> brw-rw 1 root disk 31, 0 Sep 30 12:35 /dev/mtdblock0
> brw-rw 1 root disk 31, 1 Sep 30 12:35 /dev/mtdblock1
> brw-rw 1 root disk 31, 2 Sep 30 12:35 /dev/mtdblock2
> brw-rw 1 root disk 31, 3 Sep 30 12:35 /dev/mtdblock3
> root@tirpitz:~>
>
> So, I assume, I should just be able to write u-boot.bin to /dev/mtdblock0?

Maybe, but you will likely brick the device if you have no other way
to write to flash.

Regards,
Simon


>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH V2 2/2] arm: mach-k3: Move TI dummy keys out of board folder


On 11/3/23 9:45 PM, Nishanth Menon wrote:

This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.

While at it, drop the reference in verdin-binman file which is
redundant.

Signed-off-by: Nishanth Menon 
---


Moving custMpk.pem looks good. But I don't know how .crt and .key
are actually used right now, I'd guess they already get pulled in
during FIT signing using relative paths so this might be okay.

Good to get an ACK from +Manorit to be sure though.

Andrew


New patch in series.

  arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 
  arch/arm/dts/k3-binman.dtsi   | 2 +-
  {board/ti => arch/arm/mach-k3}/keys/custMpk.crt   | 0
  {board/ti => arch/arm/mach-k3}/keys/custMpk.key   | 0
  {board/ti => arch/arm/mach-k3}/keys/custMpk.pem   | 0
  5 files changed, 1 insertion(+), 5 deletions(-)
  rename {board/ti => arch/arm/mach-k3}/keys/custMpk.crt (100%)
  rename {board/ti => arch/arm/mach-k3}/keys/custMpk.key (100%)
  rename {board/ti => arch/arm/mach-k3}/keys/custMpk.pem (100%)

diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi 
b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
index ea22bfb9bad6..58fde95adf67 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
@@ -5,10 +5,6 @@
  
  #include "k3-binman.dtsi"
  
-_pem {

-   filename = "../../ti/keys/custMpk.pem";
-};
-
  #ifdef CONFIG_TARGET_VERDIN_AM62_R5
  
   {

diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index b941726e6246..8d4b0b2454f6 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -13,7 +13,7 @@
custMpk {
filename = "custMpk.pem";
custmpk_pem: blob-ext {
-   filename = "../keys/custMpk.pem";
+   filename = "arch/arm/mach-k3/keys/custMpk.pem";
};
};
  
diff --git a/board/ti/keys/custMpk.crt b/arch/arm/mach-k3/keys/custMpk.crt

similarity index 100%
rename from board/ti/keys/custMpk.crt
rename to arch/arm/mach-k3/keys/custMpk.crt
diff --git a/board/ti/keys/custMpk.key b/arch/arm/mach-k3/keys/custMpk.key
similarity index 100%
rename from board/ti/keys/custMpk.key
rename to arch/arm/mach-k3/keys/custMpk.key
diff --git a/board/ti/keys/custMpk.pem b/arch/arm/mach-k3/keys/custMpk.pem
similarity index 100%
rename from board/ti/keys/custMpk.pem
rename to arch/arm/mach-k3/keys/custMpk.pem

[PATCH] mips: implement __udivdi3

2023-11-06 Thread Sachsensolar GmbH

From: Linus Walleij 

Squashfs wasn't compiling because the lldiv() directives
turn into __udivdi3 and we are using private libgcc.

After this squashfs compiles for MIPS.

Signed-off-by: Linus Walleij 
Signed-off-by: Daniel Schwierzeck 

---
Linus, this is the updated and optimized version of your initial patch.
Sorry for the long delay ;)

 arch/mips/lib/Makefile  |  2 +-
 arch/mips/lib/udivdi3.c | 17 +
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/lib/udivdi3.c

diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 9ee1fcb5c7..1621cc9a1f 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -14,4 +14,4 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-$(CONFIG_CMD_GO) += boot.o
 obj-$(CONFIG_SPL_BUILD) += spl.o
 
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o udivdi3.o
diff --git a/arch/mips/lib/udivdi3.c b/arch/mips/lib/udivdi3.c
new file mode 100644
index 00..4d780117cf
--- /dev/null
+++ b/arch/mips/lib/udivdi3.c
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include "libgcc.h"
+
+#if BITS_PER_LONG == 32
+
+#include 
+
+long long __udivdi3(long long u, word_type b)
+{
+   long long ret = u;
+
+   __div64_32(, b);
+   return ret;
+}
+
+#endif /* BITS_PER_LONG == 32 */
-- 
2.41.0

[PATCH] mips: fix change_k0_cca()

2023-11-06 Thread Sachsensolar GmbH

From: Daniel Schwierzeck 

The intention of change_k0_cca() is to read the C0.Config register into
register $t0, update $t0 with the new cache coherency mode passed in $a0
and write back $t0 to C0.Config. With MIPS32 R2 or later instruction
sets, this can be achieved with a single instruction with INS. The
source and destination register of the INS instruction is passed as
first parameter. In case of change_k0_cca() it is register $t0. But
for writing back the updated value to C0.Config, the incorrect $a0
register is used. This is only correct in the MIPS32 R1 code path.

Fix the `mtc0` instruction to write back the value of the $t0 register.
Fix the MIPS32 R1 code path to also store the updated value in $t0.

Reported by user ddqxy138 on Github.
https://github.com/u-boot/u-boot/commit/b838586086af3278bcaead3720c7a18813cf4619

Signed-off-by: Daniel Schwierzeck 

---

 arch/mips/lib/cache_init.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S
index 602741c65d..d64209d76a 100644
--- a/arch/mips/lib/cache_init.S
+++ b/arch/mips/lib/cache_init.S
@@ -431,9 +431,9 @@ LEAF(change_k0_cca)
 #else
xor a0, a0, t0
andia0, a0, CONF_CM_CMASK
-   xor a0, a0, t0
+   xor t0, a0, t0
 #endif
-   mtc0a0, CP0_CONFIG
+   mtc0t0, CP0_CONFIG
 
jr.hb   ra
END(change_k0_cca)
-- 
2.41.0

Re: [PATCH V2 2/4] board: beagle: Add BeagleBone AI-64 support


On 11/4/23 3:11 AM, Nishanth Menon wrote:

Add base support for BeagleBone AI-64 board support.

Further information at  https://beagleboard.org/ai-64

Signed-off-by: Nishanth Menon 
---
  arch/arm/mach-k3/Kconfig  |1 +
  board/beagle/beagleboneai64/Kconfig   |   59 +
  board/beagle/beagleboneai64/Makefile  |   10 +
  board/beagle/beagleboneai64/beagleboneai64.c  |   30 +
  .../beagle/beagleboneai64/beagleboneai64.env  |   19 +
  board/beagle/beagleboneai64/board-cfg.yaml|   36 +
  board/beagle/beagleboneai64/pm-cfg.yaml   |   12 +
  board/beagle/beagleboneai64/rm-cfg.yaml   | 3174 +


95% of this patch is just copy/pasting the board-config yaml files. Same
for other K3-based boards. I'd expect in practice these files to be near
completely common between boards using the same SoC. Would be nice to
inlcude a default .yaml from aarch/arm/mach-k3/ and only override
the couple options one wants changed for their board.

Neha,

Is the above something you would be able to help with? I'm a bit out of my
element with all this board config schema stuff..

Thanks,
Andrew


  board/beagle/beagleboneai64/sec-cfg.yaml  |  380 ++
  9 files changed, 3721 insertions(+)
  create mode 100644 board/beagle/beagleboneai64/Kconfig
  create mode 100644 board/beagle/beagleboneai64/Makefile
  create mode 100644 board/beagle/beagleboneai64/beagleboneai64.c
  create mode 100644 board/beagle/beagleboneai64/beagleboneai64.env
  create mode 100644 board/beagle/beagleboneai64/board-cfg.yaml
  create mode 100644 board/beagle/beagleboneai64/pm-cfg.yaml
  create mode 100644 board/beagle/beagleboneai64/rm-cfg.yaml
  create mode 100644 board/beagle/beagleboneai64/sec-cfg.yaml

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 666394b5cfde..ee17e8484fc4 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -201,4 +201,5 @@ source "board/siemens/iot2050/Kconfig"
  source "board/ti/j721s2/Kconfig"
  source "board/toradex/verdin-am62/Kconfig"
  source "board/beagle/beagleplay/Kconfig"
+source "board/beagle/beagleboneai64/Kconfig"
  endif
diff --git a/board/beagle/beagleboneai64/Kconfig 
b/board/beagle/beagleboneai64/Kconfig
new file mode 100644
index ..7cfccf9baf01
--- /dev/null
+++ b/board/beagle/beagleboneai64/Kconfig
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+# Copyright (C) 2022-2023 Jason Kridner, BeagleBoard.org Foundation
+# Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
+#
+
+choice
+   prompt "BeagleBoard.org J721E/TDA4VM based BeagleBone AI-64 board"
+   optional
+
+config TARGET_J721E_A72_BEAGLEBONEAI64
+   bool "BeagleBoard.org J721E BeagleBone AI-64 running on A72"
+   select ARM64
+   select SYS_DISABLE_DCACHE_OPS
+   select BINMAN
+
+config TARGET_J721E_R5_BEAGLEBONEAI64
+   bool "BeagleBoard.org J721E BeagleBone AI-64 running on R5"
+   select CPU_V7R
+   select SYS_THUMB_BUILD
+   select K3_LOAD_SYSFW
+   select RAM
+   select SPL_RAM
+   select K3_DDRSS
+   select BINMAN
+   imply SYS_K3_SPL_ATF
+
+endchoice
+
+if TARGET_J721E_A72_BEAGLEBONEAI64
+
+config SYS_BOARD
+   default "beagleboneai64"
+
+config SYS_VENDOR
+   default "beagle"
+
+config SYS_CONFIG_NAME
+   default "j721e_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
+
+if TARGET_J721E_R5_BEAGLEBONEAI64
+
+config SYS_BOARD
+   default "beagleboneai64"
+
+config SYS_VENDOR
+   default "beagle"
+
+config SYS_CONFIG_NAME
+   default "j721e_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
diff --git a/board/beagle/beagleboneai64/Makefile 
b/board/beagle/beagleboneai64/Makefile
new file mode 100644
index ..f2a2526ae75e
--- /dev/null
+++ b/board/beagle/beagleboneai64/Makefile
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# https://beagleboard.org/ai-64
+#
+# Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+# Copyright (C) 2022-2023 Jason Kridner, BeagleBoard.org Foundation
+# Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
+#
+
+obj-y  += beagleboneai64.o
diff --git a/board/beagle/beagleboneai64/beagleboneai64.c 
b/board/beagle/beagleboneai64/beagleboneai64.c
new file mode 100644
index ..c8c1c78ae5a2
--- /dev/null
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * https://beagleboard.org/ai-64
+ *
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2023 Jason Kridner, BeagleBoard.org Foundation
+ * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   return fdtdec_setup_mem_size_base();

[PATCH v2 2/2] driver: power: regulator: add support for TPS65224 regulator

2023-11-06 Thread Bhargav Raviprakash

Added support for PMIC TPS65224 regulators. Includes driver for
buck and ldo.

Signed-off-by: Bhargav Raviprakash 
---
 drivers/power/regulator/Kconfig  |  10 +
 drivers/power/regulator/Makefile |   1 +
 drivers/power/regulator/tps65224_regulator.c | 495 +++
 include/power/tps65224.h |   6 +-
 4 files changed, 510 insertions(+), 2 deletions(-)
 create mode 100644 drivers/power/regulator/tps65224_regulator.c

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index eb5aa38c1c..cb86025a22 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -408,6 +408,16 @@ config DM_REGULATOR_TPS65941
be configured in multi phase modes & 4 LDOs. The driver implements
get/set api for value and enable.
 
+config DM_REGULATOR_TPS65224
+   bool "Enable driver for TPS65224 PMIC regulators"
+depends on PMIC_TPS65224
+   help
+   This enables implementation of driver-model regulator uclass
+   features for REGULATOR TPS65224 and the family of TPS65224 PMICs.
+   TPS65224 series of PMICs have 4 single phase BUCKs that can also
+   be configured in multi phase modes & 3 LDOs. The driver implements
+   get/set api for value and enable.
+
 config DM_REGULATOR_SCMI
bool "Enable driver for SCMI voltage domain regulators"
depends on DM_REGULATOR
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index d9e0cd5949..d4b9b7233f 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_DM_REGULATOR_TPS65910) += tps65910_regulator.o
 obj-$(CONFIG_DM_REGULATOR_TPS62360) += tps62360_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_STPMIC1) += stpmic1.o
 obj-$(CONFIG_DM_REGULATOR_TPS65941) += tps65941_regulator.o
+obj-$(CONFIG_DM_REGULATOR_TPS65224) += tps65224_regulator.o
 obj-$(CONFIG_DM_REGULATOR_SCMI) += scmi_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_ANATOP) += anatop_regulator.o
 obj-$(CONFIG_DM_REGULATOR_TPS65219) += tps65219_regulator.o
diff --git a/drivers/power/regulator/tps65224_regulator.c 
b/drivers/power/regulator/tps65224_regulator.c
new file mode 100644
index 00..0431556331
--- /dev/null
+++ b/drivers/power/regulator/tps65224_regulator.c
@@ -0,0 +1,495 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023 Texas Instruments Incorporated, 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TPS65224_BUCK234_50mV_OFFSET_START_VOLT 120
+#define TPS65224_BUCK234_25mV_OFFSET_START_VOLT  50
+#define TPS65224_BUCK234_50mV_OFFSET_START_VSET 0x1B
+#define TPS65224_BUCK234_25mV_OFFSET_START_VSET 0x00
+
+#define TPS65224_BUCK1_20mV_OFFSET_START_VOLT_1 166
+#define TPS65224_BUCK1_10mV_OFFSET_START_VOLT   110
+#define TPS65224_BUCK1_5mV_OFFSET_START_VOLT 60
+#define TPS65224_BUCK1_20mV_OFFSET_START_VOLT_0  50
+#define TPS65224_BUCK1_20mV_OFFSET_START_VSET_1 0xAB
+#define TPS65224_BUCK1_10mV_OFFSET_START_VSET   0x73
+#define TPS65224_BUCK1_5mV_OFFSET_START_VSET0x0F
+#define TPS65224_BUCK1_20mV_OFFSET_START_VSET_0 0x0A
+
+static const char tps65224_buck_ctrl[TPS65224_BUCK_NUM] = {0x4, 0x6, 0x8, 0xA};
+static const char tps65224_buck_vout[TPS65224_BUCK_NUM] = {0xE, 0x10, 0x12, 
0x14};
+static const char tps65224_ldo_ctrl[TPS65224_BUCK_NUM] = {0x1D, 0x1E, 0x1F};
+static const char tps65224_ldo_vout[TPS65224_BUCK_NUM] = {0x23, 0x24, 0x25};
+
+static int tps65224_buck_enable(struct udevice *dev, int op, bool *enable)
+{
+   int ret;
+   unsigned int adr;
+   struct dm_regulator_uclass_plat *uc_pdata;
+
+   uc_pdata = dev_get_uclass_plat(dev);
+   adr = uc_pdata->ctrl_reg;
+
+   ret = pmic_reg_read(dev->parent, adr);
+   if (ret < 0)
+   return ret;
+
+   if (op == PMIC_OP_GET) {
+   ret &= TPS65224_BUCK_MODE_MASK;
+
+   if (ret)
+   *enable = true;
+   else
+   *enable = false;
+
+   return 0;
+   } else if (op == PMIC_OP_SET) {
+   if (*enable)
+   ret |= TPS65224_BUCK_MODE_MASK;
+   else
+   ret &= ~TPS65224_BUCK_MODE_MASK;
+   ret = pmic_reg_write(dev->parent, adr, ret);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int tps65224_buck_volt2val(int idx, int uV)
+{
+   if (uV > TPS65224_BUCK_VOLT_MAX)
+   return -EINVAL;
+
+   if (idx > 0) {
+   if (uV >= TPS65224_BUCK234_50mV_OFFSET_START_VOLT)
+   return (uV - TPS65224_BUCK234_50mV_OFFSET_START_VOLT) / 
5 +
+   TPS65224_BUCK234_50mV_OFFSET_START_VSET;
+   else if (uV >= TPS65224_BUCK234_25mV_OFFSET_START_VOLT)
+   return (uV -

[PATCH v2 1/2] driver: power: add support for TPS65224

2023-11-06 Thread Bhargav Raviprakash

Added support for PMIC TPS65224. Includes driver for pmic,
and disabling Watchdog.

Signed-off-by: Bhargav Raviprakash 
---
 drivers/power/pmic/Kconfig|   6 ++
 drivers/power/pmic/Makefile   |   1 +
 drivers/power/pmic/tps65224.c | 141 ++
 include/power/tps65224.h  |  57 ++
 4 files changed, 205 insertions(+)
 create mode 100644 drivers/power/pmic/tps65224.c
 create mode 100644 include/power/tps65224.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 4a6f0ce093..b06bd31823 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -378,6 +378,12 @@ config PMIC_TPS65941
The TPS65941 is a PMIC containing a bunch of SMPS & LDOs.
This driver binds the pmic children.
 
+config PMIC_TPS65224
+   bool "Enable driver for Texas Instruments TPS65224 PMIC"
+   help
+   The TPS65224 is a PMIC containing a bunch of SMPS & LDOs.
+   This driver binds the pmic children.
+
 config PMIC_TPS65219
bool "Enable driver for Texas Instruments TPS65219 PMIC"
depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 0b3b3d62d0..cec16e57d3 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
 obj-$(CONFIG_PMIC_TPS65217) += pmic_tps65217.o
 obj-$(CONFIG_PMIC_TPS65219) += tps65219.o
 obj-$(CONFIG_PMIC_TPS65941) += tps65941.o
+obj-$(CONFIG_PMIC_TPS65224) += tps65224.o
 obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
 
 ifeq ($(CONFIG_$(SPL_)POWER_LEGACY),y)
diff --git a/drivers/power/pmic/tps65224.c b/drivers/power/pmic/tps65224.c
new file mode 100644
index 00..33395f6edf
--- /dev/null
+++ b/drivers/power/pmic/tps65224.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023 Texas Instruments Incorporated, 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct pmic_child_info pmic_children_info[] = {
+   { .prefix = "ldo", .driver = TPS65224_LDO_DRIVER },
+   { .prefix = "buck", .driver = TPS65224_BUCK_DRIVER },
+   { },
+};
+
+static int tps65224_write(struct udevice *dev, uint reg, const uint8_t *buff,
+ int len)
+{
+   if (dm_i2c_write(dev, reg, buff, len)) {
+   pr_err("write error to device: %p register: %#x!\n", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int tps65224_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   if (dm_i2c_read(dev, reg, buff, len)) {
+   pr_err("read error from device: %p register: %#x!\n", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int tps65224_bind(struct udevice *dev)
+{
+   ofnode regulators_node;
+   int children;
+
+   if (dev->driver_data == TPS65224_WD)
+   return 0;
+
+   regulators_node = dev_read_subnode(dev, "regulators");
+   if (!ofnode_valid(regulators_node)) {
+   debug("%s: %s regulators subnode not found!\n", __func__,
+ dev->name);
+   return -ENXIO;
+   }
+
+   debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
+
+   children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+   if (!children)
+   printf("%s: %s - no child found\n", __func__, dev->name);
+
+   /* Probe all the child devices */
+   return dm_scan_fdt_dev(dev);
+}
+
+static int stop_watchdog(struct udevice *wd_i2c_dev)
+{
+   int ret;
+
+   /* Maintain WD long window */
+   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
+   if (ret < 0) {
+   debug("failed to read i2c reg (%d)\n", ret);
+   return ret;
+   }
+
+   ret &= ~TPS65224_WD_PWRHOLD_MASK;
+   ret |= TPS65224_WD_PWRHOLD_MASK;
+   ret = dm_i2c_reg_write(wd_i2c_dev, TPS65224_WD_MODE_REG, ret);
+   if (ret) {
+   debug("%s: %s write WD_PWRHOLD fail!\n", __func__, 
wd_i2c_dev->name);
+   return ret;
+   }
+
+   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
+   if (ret < 0) {
+   debug("failed to read back i2c reg (%d)\n", ret);
+   return ret;
+   }
+
+   /* Disable WD */
+   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_THR_CFG);
+   if (ret < 0) {
+   debug("failed to read i2c reg (%d)\n", ret);
+   return ret;
+   }
+
+   ret &= ~TPS65224_WD_EN_MASK;
+   ret = dm_i2c_reg_write(wd_i2c_dev, TPS65224_WD_THR_CFG, ret);
+   if (ret) {
+   debug("%s: %s write WD_EN fail!\n", __func__, wd_i2c_dev->name);
+   return ret;
+   }
+
+   ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_THR_CFG);
+   if (ret < 0) {
+   debug("failed to read back i2c reg (%d)\n", ret);
+

[PATCH v2 0/2] TPS65224 PMIC Driver

2023-11-06 Thread Bhargav Raviprakash

TPS65224 is a Power Management IC which provides regulators and others
features like GPIOs, RTC, watchdog, ADC, ESMs (Error Signal Monitor),
and PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC
can communicate through the I2C.

Add support for TPS65224 PMIC in U-boot. This includes driver for
PMIC and regulator.

The driver was tested on Ti's custom AM62A EVM using U-boot's
pmic list, regulator list, regulator enable, regulator disable and
regulator value commands. Regulator output voltages were verified.

Logs from running the above commands,
 => pmic list
 | Name| Parent name   | Parent uclass @ seq
 | pmic@48 | i2c@490   | i2c @ 0 | status: 0
 | watchdog@12 | i2c@2000  | i2c @ 1 | status: 0
 => reg list
 | Device  | regulator-name| Parent
 | buck12  | buck12| pmic@48
 | buck3   | buck3 | pmic@48
 | buck4   | buck4 | pmic@48
 | ldo1| ldo1  | pmic@48
 | ldo2| ldo2  | pmic@48
 | ldo3| ldo3  | pmic@48
 => regulator dev buck12
 dev: buck12 @ buck12
 => regulator enable
 => regulator value 150
 => regulator disable

Changes since v1:
 - corrected coyright lines changed to 2023 in all files
 - Added #define macros for some of the magic numbers, constants
   and offsets to improve readability

Bhargav Raviprakash (2):
  driver: power: add support for TPS65224
  driver: power: regulator: add support for TPS65224 regulator

 drivers/power/pmic/Kconfig   |   6 +
 drivers/power/pmic/Makefile  |   1 +
 drivers/power/pmic/tps65224.c| 141 ++
 drivers/power/regulator/Kconfig  |  10 +
 drivers/power/regulator/Makefile |   1 +
 drivers/power/regulator/tps65224_regulator.c | 495 +++
 include/power/tps65224.h |  59 +++
 7 files changed, 713 insertions(+)
 create mode 100644 drivers/power/pmic/tps65224.c
 create mode 100644 drivers/power/regulator/tps65224_regulator.c
 create mode 100644 include/power/tps65224.h

-- 
2.25.1

Re: [PATCH V2 1/2] arm: mach-k3: Move K3 degenerate keys out of board folder


On 11/3/23 9:45 PM, Nishanth Menon wrote:

This file is common for all of K3, move it out of board/ directory and
into mach-k3. And change the relative paths to absolute paths in the
binman paths.

While at it, drop the reference in verdin-binman file which is
redundant.

Signed-off-by: Nishanth Menon 
---


Reviewed-by: Andrew Davis 


Changes from V1:
* Dropped the override from verdin dtsi

V1: https://lore.kernel.org/all/20231103224453.3264313-1...@ti.com/

  arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 
  arch/arm/dts/k3-binman.dtsi   | 2 +-
  {board/ti => arch/arm/mach-k3}/keys/ti-degenerate-key.pem | 0
  3 files changed, 1 insertion(+), 5 deletions(-)
  rename {board/ti => arch/arm/mach-k3}/keys/ti-degenerate-key.pem (100%)

diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi 
b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
index b489d8afbe36..ea22bfb9bad6 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
@@ -9,10 +9,6 @@
filename = "../../ti/keys/custMpk.pem";
  };
  
-_pem {

-   filename = "../../ti/keys/ti-degenerate-key.pem";
-};
-
  #ifdef CONFIG_TARGET_VERDIN_AM62_R5
  
   {

diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 0212d44ee3b2..b941726e6246 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -20,7 +20,7 @@
ti-degenerate-key {
filename = "ti-degenerate-key.pem";
dkey_pem: blob-ext {
-   filename = "../keys/ti-degenerate-key.pem";
+   filename = 
"arch/arm/mach-k3/keys/ti-degenerate-key.pem";
};
};
  };
diff --git a/board/ti/keys/ti-degenerate-key.pem 
b/arch/arm/mach-k3/keys/ti-degenerate-key.pem
similarity index 100%
rename from board/ti/keys/ti-degenerate-key.pem
rename to arch/arm/mach-k3/keys/ti-degenerate-key.pem

[PATCH] m68k: remove unused mcf54xx devicetree

2023-11-06 Thread Angelo Dureghello

Remove unused devicetree, can be re-added later, in case
some board would use it.

Signed-off-by: Angelo Dureghello 
---
 arch/m68k/dts/mcf54xx.dtsi | 72 --
 1 file changed, 72 deletions(-)
 delete mode 100644 arch/m68k/dts/mcf54xx.dtsi

diff --git a/arch/m68k/dts/mcf54xx.dtsi b/arch/m68k/dts/mcf54xx.dtsi
deleted file mode 100644
index e9cebb9f74..00
--- a/arch/m68k/dts/mcf54xx.dtsi
+++ /dev/null
@@ -1,72 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2018 Angelo Dureghello 
- */
-
-/ {
-   compatible = "fsl,mcf54x5";
-
-   aliases {
-   /* TO DO, clarify on serial, this SoC seems to have SPC and
-* no UARTS.
-*/
-   spi0 = 
-   fec0 = 
-   fec1 = 
-   };
-
-   soc {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   mbar: mbar@8000 {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x 0x8000 0x1>;
-   reg = <0x8000 0x1>;
-
-   dspi0: dspi@8a00 {
-   compatible = "fsl,mcf-dspi";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x8a00 0x100>;
-   spi-max-frequency = <5000>;
-   num-cs = <4>;
-   spi-mode = <0>;
-   status = "disabled";
-   };
-
-   fec0: ethernet@9000 {
-   compatible = "fsl,mcf-dma-fec";
-   reg = <0x9000 0x800>;
-   mii-base = <0>;
-   max-speed = <100>;
-   timeout-loop = <5>;
-   rx-task = <0>;
-   tx-task = <1>;
-   rx-piority = <6>;
-   tx-piority = <7>;
-   rx-init = <16>;
-   tx-init = <17>;
-   status = "disabled";
-   };
-
-   fec1: ethernet@9800 {
-   compatible = "fsl,mcf-dma-fec";
-   reg = <0x9800 0x800>;
-   mii-base = <1>;
-   max-speed = <100>;
-   timeout-loop = <5>;
-   rx-task = <2>;
-   tx-task = <3>;
-   rx-piority = <6>;
-   tx-piority = <7>;
-   rx-init = <30>;
-   tx-init = <31>;
-   status = "disabled";
-   };
-   };
-   };
-};
-- 
2.42.0

Re: [PATCH V2 08/12] arm: mach-k3: arm64-mmu: Refactor to be independent of board


On 11/4/23 2:21 AM, Nishanth Menon wrote:

Refactor J721E J7200 definition to make this independent of board
macros.

Signed-off-by: Nishanth Menon 
---
  arch/arm/mach-k3/arm64-mmu.c | 50 ++--
  1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index f8087d2421e7..8cb6614035a5 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -68,12 +68,11 @@ struct mm_region *mem_map = am654_mem_map;
  
  #ifdef CONFIG_SOC_K3_J721E
  
-#ifdef CONFIG_TARGET_J721E_A72_EVM

-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 6)
+#ifdef CONFIG_SOC_K3_J721E_J7200
+#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
  
  /* ToDo: Add 64bit IO */

-struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j7200_mem_map[NR_MMU_REGIONS] = {


Git diff seems to have gotten confused with your re-ordering, makes
this hard to review what you are actually changing here..

Also you reminded me of a patch I forgot to send from long ago, just
sent it, should make this patch a little more simple if it goes in
first.

Andrew


{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -90,13 +89,13 @@ struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
-   .size = 0x1bc0UL,
+   .size = 0x0480UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
 PTE_BLOCK_NON_SHARE
}, {
-   .virt = 0xbbc0UL,
-   .phys = 0xbbc0UL,
-   .size = 0x4440UL,
+   .virt = 0xa480UL,
+   .phys = 0xa480UL,
+   .size = 0x5b80UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -112,26 +111,21 @@ struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   }, {
-   .virt = 0x4d8000UL,
-   .phys = 0x4d8000UL,
-   .size = 0x000200UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_INNER_SHARE
}, {
/* List terminator */
0,
}
  };
  
-struct mm_region *mem_map = j721e_mem_map;

-#endif /* CONFIG_TARGET_J721E_A72_EVM */
+struct mm_region *mem_map = j7200_mem_map;
  
-#ifdef CONFIG_TARGET_J7200_A72_EVM

-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
+#else /* CONFIG_SOC_K3_J721E_J7200 */
+
+/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
+#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 6)
  
  /* ToDo: Add 64bit IO */

-struct mm_region j7200_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -148,13 +142,13 @@ struct mm_region j7200_mem_map[NR_MMU_REGIONS] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
-   .size = 0x0480UL,
+   .size = 0x1bc0UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
 PTE_BLOCK_NON_SHARE
}, {
-   .virt = 0xa480UL,
-   .phys = 0xa480UL,
-   .size = 0x5b80UL,
+   .virt = 0xbbc0UL,
+   .phys = 0xbbc0UL,
+   .size = 0x4440UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -170,14 +164,20 @@ struct mm_region j7200_mem_map[NR_MMU_REGIONS] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   .virt = 0x4d8000UL,
+   .phys = 0x4d8000UL,
+   .size = 0x000200UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
+PTE_BLOCK_INNER_SHARE
}, {
/* List terminator */
0,
}
  };
  
-struct mm_region *mem_map = j7200_mem_map;

-#endif /* CONFIG_TARGET_J7200_A72_EVM */
+struct mm_region *mem_map = j721e_mem_map;
+#endif /* CONFIG_SOC_K3_J721E_J7200 */
  
  #endif /* CONFIG_SOC_K3_J721E */

[PATCH] mips: fix change_k0_cca()

2023-11-06 Thread Daniel Schwierzeck

The intention of change_k0_cca() is to read the C0.Config register into
register $t0, update $t0 with the new cache coherency mode passed in $a0
and write back $t0 to C0.Config. With MIPS32 R2 or later instruction
sets, this can be achieved with a single instruction with INS. The
source and destination register of the INS instruction is passed as
first parameter. In case of change_k0_cca() it is register $t0. But
for writing back the updated value to C0.Config, the incorrect $a0
register is used. This is only correct in the MIPS32 R1 code path.

Fix the `mtc0` instruction to write back the value of the $t0 register.
Fix the MIPS32 R1 code path to also store the updated value in $t0.

Reported by user ddqxy138 on Github.
https://github.com/u-boot/u-boot/commit/b838586086af3278bcaead3720c7a18813cf4619

Signed-off-by: Daniel Schwierzeck 

---

 arch/mips/lib/cache_init.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S
index 602741c65d..d64209d76a 100644
--- a/arch/mips/lib/cache_init.S
+++ b/arch/mips/lib/cache_init.S
@@ -431,9 +431,9 @@ LEAF(change_k0_cca)
 #else
xor a0, a0, t0
andia0, a0, CONF_CM_CMASK
-   xor a0, a0, t0
+   xor t0, a0, t0
 #endif
-   mtc0a0, CP0_CONFIG
+   mtc0t0, CP0_CONFIG
 
jr.hb   ra
END(change_k0_cca)
-- 
2.41.0

[PATCH] arm: mach-k3: Let the compiler size the mem_map lists

NR_MMU_REGIONS is a copy/paste from another platform that extends
this list later. We do not do that, so let the list be the size
of the initializer list.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/arm64-mmu.c | 34 ++
 1 file changed, 6 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index f8087d2421e..471295fa7eb 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -14,11 +14,7 @@
 #include 
 
 #ifdef CONFIG_SOC_K3_AM654
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
-
-/* ToDo: Add 64bit IO */
-struct mm_region am654_mem_map[NR_MMU_REGIONS] = {
+struct mm_region am654_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -69,11 +65,7 @@ struct mm_region *mem_map = am654_mem_map;
 #ifdef CONFIG_SOC_K3_J721E
 
 #ifdef CONFIG_TARGET_J721E_A72_EVM
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 6)
-
-/* ToDo: Add 64bit IO */
-struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j721e_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -128,10 +120,7 @@ struct mm_region *mem_map = j721e_mem_map;
 #endif /* CONFIG_TARGET_J721E_A72_EVM */
 
 #ifdef CONFIG_TARGET_J7200_A72_EVM
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
-
-/* ToDo: Add 64bit IO */
-struct mm_region j7200_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j7200_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -182,10 +171,7 @@ struct mm_region *mem_map = j7200_mem_map;
 #endif /* CONFIG_SOC_K3_J721E */
 
 #ifdef CONFIG_SOC_K3_J721S2
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
-
-/* ToDo: Add 64bit IO */
-struct mm_region j721s2_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j721s2_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -224,11 +210,7 @@ struct mm_region *mem_map = j721s2_mem_map;
 
 #if defined(CONFIG_SOC_K3_AM625) || defined(CONFIG_SOC_K3_AM62A7)
 
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 4)
-
-/* ToDo: Add 64bit IO */
-struct mm_region am62_mem_map[NR_MMU_REGIONS] = {
+struct mm_region am62_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -273,11 +255,7 @@ struct mm_region *mem_map = am62_mem_map;
 
 #ifdef CONFIG_SOC_K3_AM642
 
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 4)
-
-/* ToDo: Add 64bit IO */
-struct mm_region am64_mem_map[NR_MMU_REGIONS] = {
+struct mm_region am64_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
-- 
2.39.2

[PATCH] mips: implement __udivdi3

2023-11-06 Thread Daniel Schwierzeck

From: Linus Walleij 

Squashfs wasn't compiling because the lldiv() directives
turn into __udivdi3 and we are using private libgcc.

After this squashfs compiles for MIPS.

Signed-off-by: Linus Walleij 
Signed-off-by: Daniel Schwierzeck 

---
Linus, this is the updated and optimized version of your initial patch.
Sorry for the long delay ;)

 arch/mips/lib/Makefile  |  2 +-
 arch/mips/lib/udivdi3.c | 17 +
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/lib/udivdi3.c

diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 9ee1fcb5c7..1621cc9a1f 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -14,4 +14,4 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-$(CONFIG_CMD_GO) += boot.o
 obj-$(CONFIG_SPL_BUILD) += spl.o
 
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o udivdi3.o
diff --git a/arch/mips/lib/udivdi3.c b/arch/mips/lib/udivdi3.c
new file mode 100644
index 00..4d780117cf
--- /dev/null
+++ b/arch/mips/lib/udivdi3.c
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include "libgcc.h"
+
+#if BITS_PER_LONG == 32
+
+#include 
+
+long long __udivdi3(long long u, word_type b)
+{
+   long long ret = u;
+
+   __div64_32(, b);
+   return ret;
+}
+
+#endif /* BITS_PER_LONG == 32 */
-- 
2.41.0

Re: [PATCH 01/20] m68k: Remove CONFIG_FSLDMAFEC

2023-11-06 Thread Angelo Dureghello


Hi Tom,

sure, i remove the unused dtsi,
patch will follow.

Regards,
angelo

On 06/11/23 5:32 PM, Tom Rini wrote:

On Sat, Nov 04, 2023 at 09:58:07PM +0100, Angelo Dureghello wrote:

Hi Tom,

Reviewed by: Angelo Dureghello 


Thanks for the cleanup, m68k boards build fine.

fsl_mcdmafec driver is still referenced in arch/m68k/dts/mcf54xx.dtsi,
(from compatible field) but no board is including it.
You can remove the dtsi too if you want.


Thanks for the review.  I'd appreciate it if you went and did the rest
of the cleaning of unused code around here as I'm not familiar with it,
I just found this one as part of looking for common.h usage.

Re: [PATCH V2 06/12] arm: mach-k3: Kconfig: Introduce a symbol to indicate J7200

2023-11-06 Thread Nishanth Menon

On 10:45-20231106, Andrew Davis wrote:
> On 11/4/23 2:21 AM, Nishanth Menon wrote:
> > J7200 shares quite a few characteristics with J721E. However a few sets
> > are different. Introduce a Kconfig to differentiate the two to allow for
> > new boards to be introduced in a seamless manner.
> > 
> > Signed-off-by: Nishanth Menon 
> > ---
> >   arch/arm/mach-k3/Kconfig | 5 +
> >   1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > index 9168bf842dca..57e2dd966eb8 100644
> > --- a/arch/arm/mach-k3/Kconfig
> > +++ b/arch/arm/mach-k3/Kconfig
> > @@ -24,6 +24,11 @@ config SOC_K3_AM62A7
> >   endchoice
> > +if SOC_K3_J721E
> > +config SOC_K3_J721E_J7200
> 
> I'm sure you know how messy this is :(
> 
> We wanted to treat J7200 as a proper subset device of J721e but we
> also know that didn't happen. These two SoCs ended up more different
> than expected and although still very similar I believe continuing
> to try to support both under one name is not the right solution.
> 
> We will split out J7200 from J721e in TF-A[0] for similar reasons,
> might be time to do the same in u-boot.

Yes, I am aware. A follow on series to cleanup J7200 will be appreciated.


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

On Sat, Nov 04, 2023 at 05:12:12PM +, Andre Przywara wrote:
> On Fri, 3 Nov 2023 13:38:58 -0600
> Simon Glass  wrote:
> 
> Hi Simon,
> 
> > Hi Heinrich,
> > 
> > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> >  wrote:
> > >
> > > On 11/1/23 19:05, Andre Przywara wrote:  
> > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > Heinrich Schuchardt  wrote:
> > > >
> > > > Hi Heinrich,
> > > >  
> > > >> The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. It
> > > >> provides an interface to a physical entropy source.
> > > >>
> > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > >> mseccfg.sseed being set in the SBI firmware.  
> > > >
> > > > As you might have seen, I added a similar driver for the respective Arm
> > > > functionality:
> > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > >
> > > > And I see that you seem to use the same mechanism to probe and init the
> > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is not
> > > > implemented.
> > > > One downside of this approach is that the driver is always loaded (and
> > > > visible in the DM tree), even with the feature not being available.
> > > > That doesn't seem too much of a problem on the first glance, but it
> > > > occupies a device number, and any subsequent other DM_RNG devices
> > > > (like virtio-rng) typically get higher device numbers. So without
> > > > the feature, but with virtio-rng, I get:
> > > > VExpress64# rng 0
> > > > No RNG device  
> > 
> > Why do we get this? If the device is not there, the bind() function
> > can return -ENODEV
> > 
> > I see this in U-Boot:
> > 
> > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > 
> > We should not use this.
> 
> Agreed.
> 
> > Use the devicetree.
> 
> No, this is definitely not something for the DT, at least not on ARM.
> It's perfectly discoverable via the architected CPU ID registers.
> Similar to PCI and USB devices, which we don't probe via the DT as well.
> 
> It's arguably not proper "driver" material per se, as I've argued before, but
> it's the simplest solution and fits in nicely otherwise.
> 
> I was wondering if it might be something for UCLASS_CPU, something like
> a "CPU feature bus": to let devices register on one on the many CPU
> features (instead of compatible strings), then only bind() those
> drivers it the respective bit is set.
> 
> Does that make sense? Would that be doable without boiling the ocean?
> As I don't know if we see many users apart from this.

I think we have a similar problem with how we're doing with DM_TIMER and
armv7-a/armv7-m/armv8[1]. We shouldn't need the drivers in drivers/timer/
to cover platforms where SYS_ARCH_TIMER is (or should be!) enabled. But
in turn, the code under arch/arm/cpu/*/*timer.c doesn't implement the
uclass side of things, only the regular API. This is because there's
nothing to probe even because we don't support the kind of multi-arch
binary where it'd be possible to not have the feature.

-- 
Tom

[1]: We do have the problem of armv7-r not having this feature so things
like say TI K3 platforms need the platform driver on the Cortex-R host.
A similar issue is the pre-ARMv7 i.MX platforms.


signature.asc
Description: PGP signature

Re: [PATCH V2 06/12] arm: mach-k3: Kconfig: Introduce a symbol to indicate J7200


On 11/4/23 2:21 AM, Nishanth Menon wrote:

J7200 shares quite a few characteristics with J721E. However a few sets
are different. Introduce a Kconfig to differentiate the two to allow for
new boards to be introduced in a seamless manner.

Signed-off-by: Nishanth Menon 
---
  arch/arm/mach-k3/Kconfig | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 9168bf842dca..57e2dd966eb8 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -24,6 +24,11 @@ config SOC_K3_AM62A7
  
  endchoice
  
+if SOC_K3_J721E

+config SOC_K3_J721E_J7200


I'm sure you know how messy this is :(

We wanted to treat J7200 as a proper subset device of J721e but we
also know that didn't happen. These two SoCs ended up more different
than expected and although still very similar I believe continuing
to try to support both under one name is not the right solution.

We will split out J7200 from J721e in TF-A[0] for similar reasons,
might be time to do the same in u-boot.

Andrew

[0] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23970


+   bool "TI's K3 based J7200 SoC variant Family Support"
+endif
+
  config SYS_SOC
default "k3"

Re: [GIT PULL] Please pull u-boot-amlogic-20231106

On Mon, Nov 06, 2023 at 03:34:31PM +0100, Neil Armstrong wrote:

> Hi Tom,
> 
> A little set of fix for:
> - also enable DFU RAM boot for libretech-ac, since it uses a different config 
> header
> - SM probe fix
> - A1 USB missing clocks
> 
> The CI job is at 
> https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/18452
> 
> Thanks,
> Neil
> 
> The following changes since commit a4c83bda17196bf5d1ce640844595aaeced6465e:
> 
>   Merge branch '2023-11-03-assorted-tegra-improvements' (2023-11-04 09:55:39 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-amlogic.git 
> tags/u-boot-amlogic-20231106
> 
> for you to fetch changes up to c550e81171940932664a85bda315a6a073aae23c:
> 
>   ARM: configs: libretech-ac: enable USB_DFU like in meson64.h (2023-11-06 
> 09:46:05 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: designware: add DMA offset awareness

On Wed, Oct 25, 2023 at 11:08:44AM +0300, Baruch Siach wrote:

> Older DesignWare Ethernet MAC versions that this driver supports can
> only work with 32-bit DMA source/destination addresses. Some platforms
> have no physical RAM at the lowest 4GB address space. For these
> platforms the driver must translate DMA addresses to/from physical
> memory addresses.
> 
> Call translation routines so that properly configured platforms can use
> the DesignWare Ethernet MAC. For platforms using device-tree this
> usually means adding dma-ranges property to the bus the device node is
> in.
> 
> Signed-off-by: Baruch Siach 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: e1000: Drop e1000_eth_ids[]

On Wed, Oct 11, 2023 at 06:58:25PM +0800, Bin Meng wrote:

> e1000_eth_ids holds compatible strings for e1000 devices, but it
> is meaningless as e1000 is a PCI device and there is no such
> compatible string assigned to e1000 by the DT bindings community.
> 
> Drop it.
> 
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: Add option for tracing packets

On Sat, Oct 07, 2023 at 09:53:12PM -0400, Sean Anderson wrote:

> Add an option to trace all packets send/received. This can be helpful when
> debugging protocol issues, as the packets can then be imported into
> wireshark [1] and analyzed further.
> 
> [1] https://www.wireshark.org/docs/wsug_html_chunked/ChIOImportSection.html
> 
> Signed-off-by: Sean Anderson 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: phy: TI DP83869 fix invalid clock delay configuration

On Fri, Oct 06, 2023 at 02:24:39PM +0200, Frank de Brabander wrote:

> Setting the clock delay from the device tree settings
> rx-internal-delay-ps and tx-internal-delay-ps was broken:
> 
>  - The expected value in the device tree is suppose to be a
>delay in picoseconds, but the driver only allowed an array index.
>  - Driver converted this array index to the actual delay in
>picoseconds and tried to apply this in the device register. This
>however is not a valid register value. The actual logic here was
>reversed, it converted an register representation of the delay to
>the device tree delay in picoseconds.
> 
> Only when the internal delays were NOT configured in the device tree
> and they default value of 7 (=2000ps) was used, a valid value was
> loaded in the register.
> 
> Signed-off-by: Frank de Brabander 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 2/2] warp7: Convert to watchdog driver model

2023-11-06 Thread Fabio Estevam

From: Fabio Estevam 

Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.

Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.

Signed-off-by: Fabio Estevam 
---
 arch/arm/dts/imx7s-warp-u-boot.dtsi | 10 ++
 configs/warp7_defconfig |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/dts/imx7s-warp-u-boot.dtsi 
b/arch/arm/dts/imx7s-warp-u-boot.dtsi
index 4f44598c9a27..98784fd7a2ef 100644
--- a/arch/arm/dts/imx7s-warp-u-boot.dtsi
+++ b/arch/arm/dts/imx7s-warp-u-boot.dtsi
@@ -7,6 +7,12 @@
chosen {
stdout-path = 
};
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   bootph-pre-ram;
+   };
 };
 
  {
@@ -24,3 +30,7 @@
  {
bootph-all;
 };
+
+ {
+   bootph-pre-ram;
+};
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 26d992d3c2d8..4ceb0a4f2917 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -67,6 +67,8 @@ CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_IMX_THERMAL=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
@@ -80,5 +82,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
 CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OPTEE_TZDRAM_SIZE=0x300
 CONFIG_BOOTM_OPTEE=y
-- 
2.34.1

[PATCH 1/2] imx7s-warp-u-boot: Fix aliases and chosen nodes indentation

2023-11-06 Thread Fabio Estevam

From: Fabio Estevam 

The aliases and chosen nodes are currently indented using spaces.

Fix them to use the standard tab indentation.

Signed-off-by: Fabio Estevam 
---
 arch/arm/dts/imx7s-warp-u-boot.dtsi | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/imx7s-warp-u-boot.dtsi 
b/arch/arm/dts/imx7s-warp-u-boot.dtsi
index 49b992dcccaf..4f44598c9a27 100644
--- a/arch/arm/dts/imx7s-warp-u-boot.dtsi
+++ b/arch/arm/dts/imx7s-warp-u-boot.dtsi
@@ -1,12 +1,12 @@
 / {
-aliases {
-mmc0 = 
-usb0 = 
-};
+   aliases {
+   mmc0 = 
+   usb0 = 
+   };
 
-chosen {
-stdout-path = 
-};
+   chosen {
+   stdout-path = 
+   };
 };
 
  {
-- 
2.34.1

Re: [PATCH v2] net: eth-uclass: Setup ROM source only when ROM reading passes

On Fri, Sep 15, 2023 at 04:10:06PM +0200, Michal Simek wrote:

> There is no reason to setup ROM source if read_rom_hwaddr hook doesn't
> exist or reading mac address fails. It is ending up with confusion about
> mac address source.
> 
> It is nicely visible if you put mac address to DT as
> local-mac-address = [ff ff ff ff ff ff];
> but also save ethaddr to variables
> setenv -f ethaddr 02:18:31:7e:3e:01
> 
> Before this patch U-Boot prints that source is ROM
> Address in ROM is ff:ff:ff:ff:ff:ff
> Address in environment is 02:18:31:7e:3e:01
> 
> After that source is DT:
> Address in DT is  ff:ff:ff:ff:ff:ff
> Address in environment is 02:18:31:7e:3e:01
> 
> Signed-off-by: Michal Simek 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

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

On Wed, Aug 23, 2023 at 01:03:43AM +0800, Yang Xiwen via B4 Relay wrote:

> From: Yang Xiwen 
> 
> It adds the driver for the internal MDIO bus of HIFEMAC Ethernet
> controller.  It's based on the mainstream linux driver.
> 
> Signed-off-by: Yang Xiwen 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

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

On Wed, Aug 23, 2023 at 01:03:42AM +0800, Yang Xiwen via B4 Relay wrote:

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

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] net: mv88e6xxx: add Clause 45 support

On Tue, Aug 08, 2023 at 06:05:16PM +0200, Robert Marko wrote:

> Marvell LinkStreet switches support Clause 45 MDIO on the internal bus.
> 
> C45 read or writes require the register address to be written first to
> the SMI PHY Data register, and then a special C45 Write Address Register
> OP is used on the SMI PHY Register before making a C45 Read Data Register
> OP and being able to actually read the register.
> 
> Signed-off-by: Robert Marko 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] net: mv88e6xxx: use generic bitfield macros for MDIO

On Tue, Aug 08, 2023 at 06:05:15PM +0200, Robert Marko wrote:

> Driver is currently defining the mask and bit shifting itself,
> there is no need for that as U-Boot has generic bitfield macros that help
> us achieve the same result but in a cleaner way.
> 
> Signed-off-by: Robert Marko 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: ftgmac100: Add reset control

On Thu, Jul 27, 2023 at 09:58:14AM +0800, Dylan Hung wrote:

> Add optional reset control, especially for the Aspeed SOC. For the
> hardware without a reset line, the reset assertion/deassertion will be
> skipped.
> 
> Signed-off-by: Dylan Hung 
> Reviewed-by: Ryan Chen 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: dw_eth_qos: Add 64-bit addressing