date:20220718

El Fri, Jul 15, 2022 at 05:15:52PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> While technically not a bug, let's have some consistency in paths
> returned by u-boot,spl-boot-order look-up and the one saved in
> u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices
> node paths.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---


Tested on a Rock-Pi-4B and didn't see any regression.
Tested-by: Xavier Drudis Ferran 
Reviewed-by: Xavier Drudis Ferran 


>  arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index f280cb1dbf..7147dc09f5 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -182,7 +182,7 @@ const char *spl_decode_boot_device(u32 boot_device)
>   } spl_boot_devices_tbl[] = {
>   { BOOT_DEVICE_MMC2, "/mmc@fe32" },
>   { BOOT_DEVICE_MMC1, "/mmc@fe33" },
> - { BOOT_DEVICE_SPI, "/spi@ff1d" },
> + { BOOT_DEVICE_SPI, "/spi@ff1d/flash@0" },
>   };
>  
>   for (i = 0; i < ARRAY_SIZE(spl_boot_devices_tbl); ++i)
> -- 
> 2.36.1
>

Re: [SPAM] [PATCH 1/2] rockchip: rk3399: fix incorrect boot-device in u-boot, spl-boot-device

El Fri, Jul 15, 2022 at 05:15:51PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> On RK3399, mmc0 is eMMC and mmc1 is SD card, c.f. console:
> MMC:   mmc@fe32: 1, mmc@fe33: 0
> 
> In arch/arm/mach-rockchip/spl-boot-order.c:board_boot_order, the
> boot_device (BOOT_DEVICE_*) value is gotten from spl_node_to_boot_device
> function. Said function returns BOOT_DEVICE_MMC1 for mmc0 (eMMC) and
> BOOT_DEVICE_MMC2 for mmc1 (SD card).
> 
> Since the SD card controller is at mmc@fe32, it should be associated
> with BOOT_DEVICE_MMC2 and not BOOT_DEVICE_MMC1. Same applies to eMMC.
> 
> Let's fix that by swapping the two BOOT_DEVICEs.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 

There's a thread here on what the proper naming would be
https://lists.denx.de/pipermail/u-boot/2022-July/489155.html

I agree it's not been consistent, and I'd do it like in this patch,
but I don't feel strongly about any option nor pretend to stop any
discussion.

Tested on a Rock-Pi-4B and didn't see any regression.
Tested-by: Xavier Drudis Ferran 



> ---
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 691d69dc59..f280cb1dbf 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -180,8 +180,8 @@ const char *spl_decode_boot_device(u32 boot_device)
>   u32 boot_device;
>   const char *ofpath;
>   } spl_boot_devices_tbl[] = {
> - { BOOT_DEVICE_MMC1, "/mmc@fe32" },
> - { BOOT_DEVICE_MMC2, "/mmc@fe33" },
> + { BOOT_DEVICE_MMC2, "/mmc@fe32" },
> + { BOOT_DEVICE_MMC1, "/mmc@fe33" },
>   { BOOT_DEVICE_SPI, "/spi@ff1d" },
>   };
>  
> -- 
> 2.36.1
>

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

On Mon, Jul 18, 2022 at 10:31:56AM -0500, Jassi Brar wrote:
> Hi Ilias,
> 
> On Mon, 18 Jul 2022 at 10:16, Ilias Apalodimas
>  wrote:
> >
> > Hi Jassi
> >
> > On Mon, 18 Jul 2022 at 18:08, Jassi Brar  wrote:
> > >
> > > On Mon, 18 Jul 2022 at 09:47, Ilias Apalodimas
> > >  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > On Mon, 18 Jul 2022 at 17:43, Jassi Brar  
> > > > wrote:
> > > > >
> > > > > On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > > > > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > > > > From: Masami Hiramatsu 
> > > > > > >
> > > > > 
> > > > >
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > > > > > +{
> > > > > > > + int ret = 0;
> > > > > > > +
> > > > > > > + if (!plat_spi_flash)
> > > > > > > + ret = __plat_sf_get_flash();
> > > > > > > +
> > > > > > > + *flash = plat_spi_flash;
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > > > > > +{
> > > > > > > + struct spi_flash *flash;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > > > > > + if (!*data)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + ret = spi_flash_read(flash, offs, size, *data);
> > > > > > > + if (ret < 0) {
> > > > > > > + free(*data);
> > > > > > > + *data = NULL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > > > > > +{
> > > > > > > + struct spi_flash *flash;
> > > > > > > + u32 sect_size, nsect;
> > > > > > > + void *buf;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + sect_size = flash->mtd.erasesize;
> > > > > > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > > > > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> > > > > >
> > > > > > What it is interesting here that framework itself is using mtd 
> > > > > > infrastructure
> > > > > > but this platform driver is calling spi functions directly.
> > > > > > It looks a little bit nonstandard way. What's the reason for it?
> > > > > >
> > > > > Yup, this whole sf shebang is unnecessary, and removed for next 
> > > > > revision.
> > > > >
> > > > > > > +
> > > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > > +
> > > > > > > +struct __packed devbox_metadata {
> > > > > > > + u32 boot_index;
> > > > > > > + u32 boot_count;
> > > > > >
> > > > > > There is the whole bootcount infrastructure for this. I think it 
> > > > > > would be much
> > > > > > better to use that framework instead of creating parallel one.
> > > > > >
> > > > > Yes, this goes too.
> > > >
> > > > Is bootcount really suited for this case?
> > > > AFAIK bootcount either requires device specific registers (which won't
> > > > reset on reboots), or an environment you can write data to.
> > > > But what if a user wants to disable writing the env variables and the
> > > > device doesn't have a set of registers we can use?
> > > >
> > > Maybe it should be moved in 'struct fwu_mdata' ?
> >
> > I was mostly thinking on moving this count as another 'bootcount'
> > method.  So in case the user has disabled writing evn variables but he
> > is booting with EFI he can use that.
>
> Sorry, not sure I understand IIUIC there has to be some persistent 
> storage.

No, there just has to be "somewhere" to do the counting.  We've got a
DDR backed driver, for example.  So yes, I think we should try and use
the bootcount framework here.

-- 
Tom


signature.asc
Description: PGP signature

Re: [SPAM] [RFC PATCH 2/2] rockchip: rk3399: remove duplicate call to regulators_enable_boot_on

El Fri, Jul 15, 2022 at 05:14:26PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> An earlier commit makes the common SPL code call
> regulators_enable_boot_on and regulators_enable_boot_off before
> iterating over possible boot media for U-Boot proper. There is therefore
> no need to do this in the rk3399-specific code, so let's remove it.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>

Tested on a Rock-Pi-4B and didn't see any regression.
Tested-by: Xavier Drudis Ferran 


 
> - This patch depends on
>   https://lore.kernel.org/u-boot/20220715150949.952853-1-foss+ub...@0leil.net/
>   and
>   https://lore.kernel.org/u-boot/20220715150949.952853-2-foss+ub...@0leil.net/
> 
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index db8a6cb83a..691d69dc59 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -277,15 +277,5 @@ void spl_board_init(void)
>   if (cru->glb_rst_st != 0)
>   rk3399_force_power_on_reset();
>   }
> -
> - if (IS_ENABLED(CONFIG_SPL_DM_REGULATOR)) {
> - /*
> -  * Turning the eMMC and SPI back on (if disabled via the Qseven
> -  * BIOS_ENABLE) signal is done through a always-on regulator).
> -  */
> - if (regulators_enable_boot_on(false))
> - debug("%s: Cannot enable boot on regulator\n",
> -   __func__);
> - }
>  }
>  #endif
> -- 
> 2.36.1
>

Re: [SPAM] [RFC PATCH 1/2] spl: enable regulator-boot-on and disable regulator-force-boot-off

El Fri, Jul 15, 2022 at 05:14:25PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> This makes sure regulators that need to be turned on or off at boot are
> turned on or off in the SPL.
> 
> This may be required for the SPL to do some operations, such as finding
> possible loading media for U-Boot proper.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>

Tested on a Rock-Pi-4B and didn't see any regression.
Tested-by: Xavier Drudis Ferran 
 
>  - RFC because only tested on Puma Haikou RK3399
> 
>  common/spl/spl.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index c8c463f80b..762e9918c7 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -37,6 +37,9 @@
>  #include 
>  #include 
>  #include 
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
> +#include 
> +#endif
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -766,6 +769,15 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>   if (CONFIG_IS_ENABLED(GPIO_HOG))
>   gpio_hog_probe_all();
>  
> + if (CONFIG_IS_ENABLED(DM_REGULATOR)) {
> + if (regulators_enable_boot_on(false))
> + debug("%s: Cannot enable boot on regulator\n",
> +   __func__);
> + if (regulators_enable_boot_off(false))
> + debug("%s: Cannot enable boot off regulator\n",
> +   __func__);
> + }
> +
>  #if CONFIG_IS_ENABLED(BOARD_INIT)
>   spl_board_init();
>  #endif
> -- 
> 2.36.1
>

Re: [SPAM] [PATCH v2 1/2] rockchip: rk3399: fix incorrect ifdef check on SPL_DM_REGULATOR

El Fri, Jul 15, 2022 at 05:09:48PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> The check to perform is on CONFIG_SPL_DM_REGULATOR and not
> SPL_DM_REGULATOR. Also switch to in-code check instead of ifdefs.
>

Tested it on a Rock-Pi-4 with the patch below on top.
So with the small correction: 

Tested-by: Xavier Drudis Ferran 
 
> Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
> 
> v2:
>  - use IS_ENABLED checks,
> 
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index de11a3fa30..920da22307 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -275,13 +275,14 @@ void spl_board_init(void)
>   rk3399_force_power_on_reset();
>  #endif
>  
> -#if defined(SPL_DM_REGULATOR)
> - /*
> -  * Turning the eMMC and SPI back on (if disabled via the Qseven
> -  * BIOS_ENABLE) signal is done through a always-on regulator).
> -  */
> - if (regulators_enable_boot_on(false))
> - debug("%s: Cannot enable boot on regulator\n", __func__);
> -#endif
> + if (IS_ENABLED(CONFIG_SPL_DM_REGULATOR)) {
> + /*
> +  * Turning the eMMC and SPI back on (if disabled via the Qseven
> +  * BIOS_ENABLE) signal is done through a always-on regulator).
> +  */
> + if (regulators_enable_boot_on(false))
> + debug("%s: Cannot enable boot on regulator\n",
> +   __func__);
> + }
>  }
>  #endif
> -- 
> 2.36.1
> 

The small correction:

---
 common/spl/spl.c  | 2 --
 include/power/regulator.h | 5 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 70c11aa275..6ab997279d 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -39,9 +39,7 @@
 #include 
 #include 
 #include 
-#if CONFIG_IS_ENABLED(DM_REGULATOR)
 #include 
-#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 DECLARE_BINMAN_MAGIC_SYM;
diff --git a/include/power/regulator.h b/include/power/regulator.h
index ff1bfc2435..4bce61dd9f 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -631,6 +631,11 @@ static inline int regulators_enable_boot_on(bool verbose)
return -ENOSYS;
 }
 
+static inline int regulators_enable_boot_off(bool verbose)
+{
+   return -ENOSYS;
+}
+
 static inline int regulator_autoset(struct udevice *dev)
 {
return -ENOSYS;
-- 
2.20.1

Re: [SPAM] [PATCH v2 2/2] rockchip: rk3399: fix incorrect ifdef check on SPL_GPIO

El Fri, Jul 15, 2022 at 05:09:49PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> The check to perform is on CONFIG_SPL_GPIO and not SPL_GPIO.
> Because this was never compiled in, it missed an include of cru.h that
> was not detected before. Let's include it too.
> 
> Also switch to IS_ENABLED ifdef and in-code check.
> 
> Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>

I've tested this on a Rock-Pi-4B, but with the patch below on top 
and I haven't seen any regression. So, with this small correction: 

Tested-by: Xavier Drudis Ferran 
 
> v2:
>  - use IS_ENABLED checks,
> 
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 45 ++
>  1 file changed, 24 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 920da22307..db8a6cb83a 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -221,7 +221,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
>  "u-boot,spl-boot-device", boot_ofpath);
>  }
>  
> -#if defined(SPL_GPIO)
> +#if IS_ENABLED(CONFIG_SPL_GPIO)
> +
> +#include 
>  static void rk3399_force_power_on_reset(void)
>  {
>   ofnode node;
> @@ -253,27 +255,28 @@ void spl_board_init(void)
>  {
>   led_setup();
>  
> -#if defined(SPL_GPIO)
> - struct rockchip_cru *cru = rockchip_get_cru();
> + if (IS_ENABLED(CONFIG_SPL_GPIO)) {
> + struct rockchip_cru *cru = rockchip_get_cru();
>  
> - /*
> -  * The RK3399 resets only 'almost all logic' (see also in the TRM
> -  * "3.9.4 Global software reset"), when issuing a software reset.
> -  * This may cause issues during boot-up for some configurations of
> -  * the application software stack.
> -  *
> -  * To work around this, we test whether the last reset reason was
> -  * a power-on reset and (if not) issue an overtemp-reset to reset
> -  * the entire module.
> -  *
> -  * While this was previously fixed by modifying the various places
> -  * that could generate a software reset (e.g. U-Boot's sysreset
> -  * driver, the ATF or Linux), we now have it here to ensure that
> -  * we no longer have to track this through the various components.
> -  */
> - if (cru->glb_rst_st != 0)
> - rk3399_force_power_on_reset();
> -#endif
> + /*
> +  * The RK3399 resets only 'almost all logic' (see also in the
> +  * TRM "3.9.4 Global software reset"), when issuing a software
> +  * reset. This may cause issues during boot-up for some
> +  * configurations of the application software stack.
> +  *
> +  * To work around this, we test whether the last reset reason
> +  * was a power-on reset and (if not) issue an overtemp-reset to
> +  * reset the entire module.
> +  *
> +  * While this was previously fixed by modifying the various
> +  * places that could generate a software reset (e.g. U-Boot's
> +  * sysreset driver, the ATF or Linux), we now have it here to
> +  * ensure that we no longer have to track this through the
> +  * various components.
> +  */
> + if (cru->glb_rst_st != 0)
> + rk3399_force_power_on_reset();
> + }
>  
>   if (IS_ENABLED(CONFIG_SPL_DM_REGULATOR)) {
>   /*
> -- 
> 2.36.1
> 

The small correction (now that I think of it, the include might as well go at 
the top of file): 

---
 arch/arm/mach-rockchip/rk3399/rk3399.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index fced5c7e21..10b911f998 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -221,9 +221,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
   "u-boot,spl-boot-device", boot_ofpath);
 }
 
+#include 
 #if IS_ENABLED(CONFIG_SPL_GPIO)
 
-#include 
 static void rk3399_force_power_on_reset(void)
 {
ofnode node;
@@ -245,6 +245,10 @@ static void rk3399_force_power_on_reset(void)
 
dm_gpio_set_value(&sysreset_gpio, 1);
 }
+#else
+static inline void rk3399_force_power_on_reset(void)
+{
+}
 #endif
 
 void __weak led_setup(void)
-- 
2.20.1

Pull request: u-boot-spi/master

2022-07-18 Thread Jagan Teki

Hi Tom,

Please pull this PR.

Summary:
- add Macronix Octal flash (JaimeLiao)

CI:
https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/12778

thanks,
Jagan.

The following changes since commit 26f6f7fb5c0651d65afdee6d8ed36063606179a8:

  Merge branch '2022-07-14-migrate-wiki-to-sphinx' (2022-07-14 18:43:51 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-spi master

for you to fetch changes up to 47ed8b22fd561b65e8541919becc76ab3d86f7a3:

  mtd: spi-nor-ids: add winbond w25q512nw family support (2022-07-18 19:15:19 
+0530)


Jae Hyun Yoo (1):
  mtd: spi-nor-ids: add winbond w25q512nw family support

JaimeLiao (4):
  mtd: spi-nor: add support for Macronix Octal flash
  mtd: spi-nor-core: Adding different type of command extension in Soft 
Reset
  mtd: spi-nor: Parse SFDP SCCR Map
  mtd: spi-nor-core: Add support for Macronix Octal flash

Jan Kiszka (2):
  mtd: spi: Convert is_locked callback to is_unlocked
  sf: Query write-protection status before operating the flash

Vaishnav Achath (1):
  spl: spl_spi: add spi_nor_remove() to soft reset flash

 cmd/sf.c   |  12 +++
 common/spl/spl_spi.c   |   5 ++
 drivers/mtd/spi/Kconfig|   7 ++
 drivers/mtd/spi/spi-nor-core.c | 167 +
 drivers/mtd/spi/spi-nor-ids.c  |  29 ++-
 include/linux/mtd/spi-nor.h|  17 -
 6 files changed, 219 insertions(+), 18 deletions(-)

Re: [PATCH 1/2] dt-bindings: mtd: partitions: add binding for U-Boot bootloader

2022-07-18 Thread Rob Herring

On Mon, 11 Jul 2022 17:30:40 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Right now there is no (known) real reason for a custom binding for
> standard U-Boot partitions. Broadcom's U-Boot however requires extra
> handling - looking for environment variables subblocks. This commit adds
> Broadcom specific binding.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  .../bindings/mtd/partitions/u-boot.yaml   | 49 +++
>  1 file changed, 49 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
> 

Reviewed-by: Rob Herring

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

2022-07-18 Thread Michael Nazzareno Trimarchi

Hi Andre

On Mon, Jul 18, 2022 at 6:20 PM Andre Przywara  wrote:
>
> On Wed, 13 Jul 2022 22:15:22 -0500
> Samuel Holland  wrote:
>
> Hi,
>
> > NAND is always at function 2 on port C.
>
> Indeed.
>
> >
> > Pin lists and mux values were taken from the Linux drivers.
>
> Compared against the manuals. I didn't bother the check the pin ranges (I
> think some additional CS pins were not covered by the comments), but that
> shouldn't matter anyways.
>
> Reviewed-by: Andre Przywara 
>
> > Signed-off-by: Samuel Holland 
>
> Cheers,
> Andre
>
> P.S.: I see that the A83T kernel pinctrl driver uses "nand" for *some* pins
> instead of "nand0", not sure if that should to be fixed, or if it's too
> late for that (not that NAND is mentioned at all in the A83T DT files ...)
>

Are you going to queue them all?

Michael

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

Re: DWC3 host support

2022-07-18 Thread Angus Ainslie


Hi,

On 2022-07-18 01:13, Michal Simek wrote:

On 7/17/22 17:23, Marek Vasut wrote:

On 7/17/22 05:00, Angus Ainslie wrote:

On 2022-07-16 11:37, Marek Vasut wrote:

On 7/16/22 15:02, Angus Ainslie wrote:

Hi Michal,

I recently rebased my librem5 tree onto the latest u-boot-imx 
branch

and the dwc3 host mode stopped working.

I bisected it down to this commit:

142d50fbce7c364a74f5e8204dba491b9f066e6c usb: dwc3: Add support for
usb3-phy PHY configuration

Reverting that commit allows usb host mode to work on the librem5 
again.


Should this initialization go into an SOC specific glue_configure
function ?

Is the imx8mq.dtsi missing something that will keep usb host 
working

with this patch ?

Does this break usb host on other imx8mq devices ?


Wasn't this fixed by:
868d58f69c ("usb: dwc3: Fix non-usb3 configurations")
?


I've got that in my tree and it still fails to probe the USB2 hub and
USB 2 storage.


I assume you do have CONFIG_PHY_IMX8MQ_USB enabled ?

What does generic_phy_get_by_name() return for you in
drivers/usb/dwc3/dwc3-generic.c ?


As Marek said there was one patch which fixes origin patch which
didn't handle all the error cases properly. We need to know return
value from generic_phy_get_by_name(), also if you still have usb3-phy
in DT (as is in imx8mq.dtsi) with phy DT status enabled and enabled
phy driver (CONFIG_PHY_IMX8MQ_USB).



Removing the usb3 phy definition also "fixes" it

--- a/arch/arm/dts/imx8mq-librem5-r4.dts
+++ b/arch/arm/dts/imx8mq-librem5-r4.dts
@@ -33,3 +33,8 @@
 &proximity {
proximity-near-level = <10>;
 };
+
+&usb_dwc3_1 {
+   phys = <&usb3_phy1>;
+   phy-names = "usb2-phy";
+};

Thanks
Angus


Thanks,
Michal

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

On Wed, 13 Jul 2022 22:15:22 -0500
Samuel Holland  wrote:

Hi,

> NAND is always at function 2 on port C.

Indeed.

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

Compared against the manuals. I didn't bother the check the pin ranges (I
think some additional CS pins were not covered by the comments), but that
shouldn't matter anyways.

Reviewed-by: Andre Przywara 

> Signed-off-by: Samuel Holland 

Cheers,
Andre

P.S.: I see that the A83T kernel pinctrl driver uses "nand" for *some* pins
instead of "nand0", not sure if that should to be fixed, or if it's too
late for that (not that NAND is mentioned at all in the A83T DT files ...)

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

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

On Wed, 13 Jul 2022 22:15:21 -0500
Samuel Holland  wrote:

Hi,

> Currently NAND clock setup is done in board code, both in SPL and in
> U-Boot proper. Add the NAND clocks/resets here so they can be used by
> the "full" NAND driver once it is converted to the driver model.
> 
> The bit locations are copied from the Linux CCU drivers.
> 
> Signed-off-by: Samuel Holland 
> ---
> 
>  drivers/clk/sunxi/clk_a10.c  | 2 ++
>  drivers/clk/sunxi/clk_a10s.c | 2 ++
>  drivers/clk/sunxi/clk_a23.c  | 3 +++
>  drivers/clk/sunxi/clk_a31.c  | 6 ++
>  drivers/clk/sunxi/clk_a64.c  | 3 +++
>  drivers/clk/sunxi/clk_a80.c  | 8 
>  drivers/clk/sunxi/clk_a83t.c | 3 +++
>  drivers/clk/sunxi/clk_h3.c   | 3 +++
>  drivers/clk/sunxi/clk_h6.c   | 6 ++
>  drivers/clk/sunxi/clk_h616.c | 6 ++
>  drivers/clk/sunxi/clk_r40.c  | 3 +++
>  11 files changed, 45 insertions(+)
> 
> diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
> index db92848aafde..69c46da841e9 100644
> --- a/drivers/clk/sunxi/clk_a10.c
> +++ b/drivers/clk/sunxi/clk_a10.c
> @@ -23,6 +23,7 @@ static struct ccu_clk_gate a10_gates[] = {
>   [CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
>   [CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
>   [CLK_AHB_MMC3]  = GATE(0x060, BIT(11)),
> + [CLK_AHB_NAND]  = GATE(0x060, BIT(13)),
>   [CLK_AHB_EMAC]  = GATE(0x060, BIT(17)),
>   [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
>   [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
> @@ -47,6 +48,7 @@ static struct ccu_clk_gate a10_gates[] = {
>   [CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
>   [CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
>  
> + [CLK_NAND]  = GATE(0x080, BIT(31)),
>   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
>   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
>   [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
> diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
> index 0c6564ef3b62..6abccea3aa9e 100644
> --- a/drivers/clk/sunxi/clk_a10s.c
> +++ b/drivers/clk/sunxi/clk_a10s.c
> @@ -20,6 +20,7 @@ static struct ccu_clk_gate a10s_gates[] = {
>   [CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
>   [CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
>   [CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
> + [CLK_AHB_NAND]  = GATE(0x060, BIT(13)),
>   [CLK_AHB_EMAC]  = GATE(0x060, BIT(17)),
>   [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
>   [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
> @@ -35,6 +36,7 @@ static struct ccu_clk_gate a10s_gates[] = {
>   [CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
>   [CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
>  
> + [CLK_NAND]  = GATE(0x080, BIT(31)),
>   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
>   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
>   [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
> diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
> index 0280fb51e2db..342af83b158d 100644
> --- a/drivers/clk/sunxi/clk_a23.c
> +++ b/drivers/clk/sunxi/clk_a23.c
> @@ -17,6 +17,7 @@ static struct ccu_clk_gate a23_gates[] = {
>   [CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
>   [CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
>   [CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
> + [CLK_BUS_NAND]  = GATE(0x060, BIT(13)),
>   [CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
>   [CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
>   [CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
> @@ -34,6 +35,7 @@ static struct ccu_clk_gate a23_gates[] = {
>   [CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
>   [CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
>  
> + [CLK_NAND]  = GATE(0x080, BIT(31)),
>   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
>   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
>  
> @@ -52,6 +54,7 @@ static struct ccu_reset a23_resets[] = {
>   [RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
>   [RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
>   [RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
> + [RST_BUS_NAND]  = RESET(0x2c0, BIT(13)),
>   [RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
>   [RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
>   [RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
> diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
> index 26d25f324080..703ddc01dad0 100644
> --- a/drivers/clk/sunxi/clk_a31.c
> +++ b/drivers/clk/sunxi/clk_a31.c
> @@ -18,6 +18,8 @@ static struct ccu_clk_gate a31_gates[] = {
>   [CLK_AHB1_MMC1] = GATE(0x060, BIT(9)),
>   [CLK_AHB1_MMC2] = GATE(0x060, BIT(10)),
>   [CLK_AHB1_MMC3] = GATE(0x060, BIT(11)),
> + [CLK_AHB1_NAND1]= GATE(0x060, BIT(12)),
> + [CLK_AHB1_NAND0]= GATE(0x060, BIT(13)),
>   [CLK_AHB1_EMAC] = GATE(0x060, BIT(17))

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

Hi Jassi

On Mon, 18 Jul 2022 at 18:34, Jassi Brar  wrote:
>
> On Mon, 18 Jul 2022 at 10:31, Jassi Brar  wrote:
> >
> > Hi Ilias,
> >
> > On Mon, 18 Jul 2022 at 10:16, Ilias Apalodimas
> >  wrote:
> > >
> > > Hi Jassi
> > >
> > > On Mon, 18 Jul 2022 at 18:08, Jassi Brar  
> > > wrote:
> > > >
> > > > On Mon, 18 Jul 2022 at 09:47, Ilias Apalodimas
> > > >  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > On Mon, 18 Jul 2022 at 17:43, Jassi Brar  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > > > > > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > > > > > From: Masami Hiramatsu 
> > > > > > > >
> > > > > > 
> > > > > >
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > > > > > > +{
> > > > > > > > + int ret = 0;
> > > > > > > > +
> > > > > > > > + if (!plat_spi_flash)
> > > > > > > > + ret = __plat_sf_get_flash();
> > > > > > > > +
> > > > > > > > + *flash = plat_spi_flash;
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > > > > > > +{
> > > > > > > > + struct spi_flash *flash;
> > > > > > > > + int ret;
> > > > > > > > +
> > > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > > + if (ret < 0)
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > > > > > > + if (!*data)
> > > > > > > > + return -ENOMEM;
> > > > > > > > +
> > > > > > > > + ret = spi_flash_read(flash, offs, size, *data);
> > > > > > > > + if (ret < 0) {
> > > > > > > > + free(*data);
> > > > > > > > + *data = NULL;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > > > > > > +{
> > > > > > > > + struct spi_flash *flash;
> > > > > > > > + u32 sect_size, nsect;
> > > > > > > > + void *buf;
> > > > > > > > + int ret;
> > > > > > > > +
> > > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > > + if (ret < 0)
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > + sect_size = flash->mtd.erasesize;
> > > > > > > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > > > > > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> > > > > > >
> > > > > > > What it is interesting here that framework itself is using mtd 
> > > > > > > infrastructure
> > > > > > > but this platform driver is calling spi functions directly.
> > > > > > > It looks a little bit nonstandard way. What's the reason for it?
> > > > > > >
> > > > > > Yup, this whole sf shebang is unnecessary, and removed for next 
> > > > > > revision.
> > > > > >
> > > > > > > > +
> > > > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > > > +
> > > > > > > > +struct __packed devbox_metadata {
> > > > > > > > + u32 boot_index;
> > > > > > > > + u32 boot_count;
> > > > > > >
> > > > > > > There is the whole bootcount infrastructure for this. I think it 
> > > > > > > would be much
> > > > > > > better to use that framework instead of creating parallel one.
> > > > > > >
> > > > > > Yes, this goes too.
> > > > >
> > > > > Is bootcount really suited for this case?
> > > > > AFAIK bootcount either requires device specific registers (which won't
> > > > > reset on reboots), or an environment you can write data to.
> > > > > But what if a user wants to disable writing the env variables and the
> > > > > device doesn't have a set of registers we can use?
> > > > >
> > > > Maybe it should be moved in 'struct fwu_mdata' ?
> > >
> > > I was mostly thinking on moving this count as another 'bootcount'
> > > method.  So in case the user has disabled writing evn variables but he
> > > is booting with EFI he can use that.
> > >
> > Sorry, not sure I understand IIUIC there has to be some persistent 
> > storage.
> >
> > Of the three options - registers, efi-env and mdata, I think the last
> > one is more robust.
> > For ex, if BL33 isn't reached after an update. We want BL2 (which may
> > not have access to efi variables)
> > to be able to revert the active index.
> >
>  and which requires a bootcount for each stage. hmm...
> probably I am overlooking something.

Well it's indeed more complicated, but the reasoning was something
along the lines of
- What if BL2 crashes really early, before it can access storage?
- BL2 doesn't have code to write that data only read it (in some
cases, depends on how the data is stored)

So the solution was to have individual counters

Cheers
/Ilias

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

Hi Jassi,

On Mon, 18 Jul 2022 at 18:32, Jassi Brar  wrote:
>
> Hi Ilias,
>
> On Mon, 18 Jul 2022 at 10:16, Ilias Apalodimas
>  wrote:
> >
> > Hi Jassi
> >
> > On Mon, 18 Jul 2022 at 18:08, Jassi Brar  wrote:
> > >
> > > On Mon, 18 Jul 2022 at 09:47, Ilias Apalodimas
> > >  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > On Mon, 18 Jul 2022 at 17:43, Jassi Brar  
> > > > wrote:
> > > > >
> > > > > On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > > > > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > > > > From: Masami Hiramatsu 
> > > > > > >
> > > > > 
> > > > >
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > > > > > +{
> > > > > > > + int ret = 0;
> > > > > > > +
> > > > > > > + if (!plat_spi_flash)
> > > > > > > + ret = __plat_sf_get_flash();
> > > > > > > +
> > > > > > > + *flash = plat_spi_flash;
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > > > > > +{
> > > > > > > + struct spi_flash *flash;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > > > > > + if (!*data)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + ret = spi_flash_read(flash, offs, size, *data);
> > > > > > > + if (ret < 0) {
> > > > > > > + free(*data);
> > > > > > > + *data = NULL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > > > > > +{
> > > > > > > + struct spi_flash *flash;
> > > > > > > + u32 sect_size, nsect;
> > > > > > > + void *buf;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + sect_size = flash->mtd.erasesize;
> > > > > > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > > > > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> > > > > >
> > > > > > What it is interesting here that framework itself is using mtd 
> > > > > > infrastructure
> > > > > > but this platform driver is calling spi functions directly.
> > > > > > It looks a little bit nonstandard way. What's the reason for it?
> > > > > >
> > > > > Yup, this whole sf shebang is unnecessary, and removed for next 
> > > > > revision.
> > > > >
> > > > > > > +
> > > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > > +
> > > > > > > +struct __packed devbox_metadata {
> > > > > > > + u32 boot_index;
> > > > > > > + u32 boot_count;
> > > > > >
> > > > > > There is the whole bootcount infrastructure for this. I think it 
> > > > > > would be much
> > > > > > better to use that framework instead of creating parallel one.
> > > > > >
> > > > > Yes, this goes too.
> > > >
> > > > Is bootcount really suited for this case?
> > > > AFAIK bootcount either requires device specific registers (which won't
> > > > reset on reboots), or an environment you can write data to.
> > > > But what if a user wants to disable writing the env variables and the
> > > > device doesn't have a set of registers we can use?
> > > >
> > > Maybe it should be moved in 'struct fwu_mdata' ?
> >
> > I was mostly thinking on moving this count as another 'bootcount'
> > method.  So in case the user has disabled writing evn variables but he
> > is booting with EFI he can use that.
> >
> Sorry, not sure I understand IIUIC there has to be some persistent 
> storage.
>
> Of the three options - registers, efi-env and mdata, I think the last
> one is more robust.
> For ex, if BL33 isn't reached after an update. We want BL2 (which may
> not have access to efi variables)
> to be able to revert the active index.

I think BL2 has it's own set of internal counters for the number of
reboots already (and I think on the stmp32mp1 is based on a cpu
scratch register)
This is supposed with BL33 reboots only.  Sughosh do I remember this wrong?

Regards
/Ilias
>
> thanks.

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

On Mon, 18 Jul 2022 at 10:31, Jassi Brar  wrote:
>
> Hi Ilias,
>
> On Mon, 18 Jul 2022 at 10:16, Ilias Apalodimas
>  wrote:
> >
> > Hi Jassi
> >
> > On Mon, 18 Jul 2022 at 18:08, Jassi Brar  wrote:
> > >
> > > On Mon, 18 Jul 2022 at 09:47, Ilias Apalodimas
> > >  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > On Mon, 18 Jul 2022 at 17:43, Jassi Brar  
> > > > wrote:
> > > > >
> > > > > On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > > > > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > > > > From: Masami Hiramatsu 
> > > > > > >
> > > > > 
> > > > >
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > > > > > +{
> > > > > > > + int ret = 0;
> > > > > > > +
> > > > > > > + if (!plat_spi_flash)
> > > > > > > + ret = __plat_sf_get_flash();
> > > > > > > +
> > > > > > > + *flash = plat_spi_flash;
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > > > > > +{
> > > > > > > + struct spi_flash *flash;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > > > > > + if (!*data)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + ret = spi_flash_read(flash, offs, size, *data);
> > > > > > > + if (ret < 0) {
> > > > > > > + free(*data);
> > > > > > > + *data = NULL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > > > > > +{
> > > > > > > + struct spi_flash *flash;
> > > > > > > + u32 sect_size, nsect;
> > > > > > > + void *buf;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + sect_size = flash->mtd.erasesize;
> > > > > > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > > > > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> > > > > >
> > > > > > What it is interesting here that framework itself is using mtd 
> > > > > > infrastructure
> > > > > > but this platform driver is calling spi functions directly.
> > > > > > It looks a little bit nonstandard way. What's the reason for it?
> > > > > >
> > > > > Yup, this whole sf shebang is unnecessary, and removed for next 
> > > > > revision.
> > > > >
> > > > > > > +
> > > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > > +
> > > > > > > +struct __packed devbox_metadata {
> > > > > > > + u32 boot_index;
> > > > > > > + u32 boot_count;
> > > > > >
> > > > > > There is the whole bootcount infrastructure for this. I think it 
> > > > > > would be much
> > > > > > better to use that framework instead of creating parallel one.
> > > > > >
> > > > > Yes, this goes too.
> > > >
> > > > Is bootcount really suited for this case?
> > > > AFAIK bootcount either requires device specific registers (which won't
> > > > reset on reboots), or an environment you can write data to.
> > > > But what if a user wants to disable writing the env variables and the
> > > > device doesn't have a set of registers we can use?
> > > >
> > > Maybe it should be moved in 'struct fwu_mdata' ?
> >
> > I was mostly thinking on moving this count as another 'bootcount'
> > method.  So in case the user has disabled writing evn variables but he
> > is booting with EFI he can use that.
> >
> Sorry, not sure I understand IIUIC there has to be some persistent 
> storage.
>
> Of the three options - registers, efi-env and mdata, I think the last
> one is more robust.
> For ex, if BL33 isn't reached after an update. We want BL2 (which may
> not have access to efi variables)
> to be able to revert the active index.
>
 and which requires a bootcount for each stage. hmm...
probably I am overlooking something.

[PATCH] arm: Remove unused references to CONFIG_SOC_DM*

There are no references to CONFIG_SOC_DM355 / CONFIG_SOC_DM365 /
CONFIG_SOC_DM644X / CONFIG_SOC_DM646X and the files these Makefile lines
reference have already been dropped.

Signed-off-by: Tom Rini 
---
 arch/arm/mach-davinci/Makefile | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index ed8827407206..ae171e3ee222 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -7,14 +7,9 @@
 
 obj-y  += cpu.o misc.o timer.o psc.o pinmux.o reset.o
 obj-$(CONFIG_DA850_LOWLEVEL)   += da850_lowlevel.o
-obj-$(CONFIG_SOC_DM355)+= dm355.o
-obj-$(CONFIG_SOC_DM365)+= dm365.o
-obj-$(CONFIG_SOC_DM644X)   += dm644x.o
-obj-$(CONFIG_SOC_DM646X)   += dm646x.o
 obj-$(CONFIG_SOC_DA850)+= da850_pinmux.o
 
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_FRAMEWORK)+= spl.o
-obj-$(CONFIG_SOC_DM365)+= dm365_lowlevel.o
 obj-$(CONFIG_SOC_DA8XX)+= da850_lowlevel.o
 endif
-- 
2.25.1

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

Hi Ilias,

On Mon, 18 Jul 2022 at 10:16, Ilias Apalodimas
 wrote:
>
> Hi Jassi
>
> On Mon, 18 Jul 2022 at 18:08, Jassi Brar  wrote:
> >
> > On Mon, 18 Jul 2022 at 09:47, Ilias Apalodimas
> >  wrote:
> > >
> > > Hi all,
> > >
> > > On Mon, 18 Jul 2022 at 17:43, Jassi Brar  
> > > wrote:
> > > >
> > > > On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > > > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > > > From: Masami Hiramatsu 
> > > > > >
> > > > 
> > > >
> > > > > > +}
> > > > > > +
> > > > > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > > > > +{
> > > > > > + int ret = 0;
> > > > > > +
> > > > > > + if (!plat_spi_flash)
> > > > > > + ret = __plat_sf_get_flash();
> > > > > > +
> > > > > > + *flash = plat_spi_flash;
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > > > > +{
> > > > > > + struct spi_flash *flash;
> > > > > > + int ret;
> > > > > > +
> > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > > > > + if (!*data)
> > > > > > + return -ENOMEM;
> > > > > > +
> > > > > > + ret = spi_flash_read(flash, offs, size, *data);
> > > > > > + if (ret < 0) {
> > > > > > + free(*data);
> > > > > > + *data = NULL;
> > > > > > + }
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > > > > +{
> > > > > > + struct spi_flash *flash;
> > > > > > + u32 sect_size, nsect;
> > > > > > + void *buf;
> > > > > > + int ret;
> > > > > > +
> > > > > > + ret = plat_sf_get_flash(&flash);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + sect_size = flash->mtd.erasesize;
> > > > > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > > > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> > > > >
> > > > > What it is interesting here that framework itself is using mtd 
> > > > > infrastructure
> > > > > but this platform driver is calling spi functions directly.
> > > > > It looks a little bit nonstandard way. What's the reason for it?
> > > > >
> > > > Yup, this whole sf shebang is unnecessary, and removed for next 
> > > > revision.
> > > >
> > > > > > +
> > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > +
> > > > > > +struct __packed devbox_metadata {
> > > > > > + u32 boot_index;
> > > > > > + u32 boot_count;
> > > > >
> > > > > There is the whole bootcount infrastructure for this. I think it 
> > > > > would be much
> > > > > better to use that framework instead of creating parallel one.
> > > > >
> > > > Yes, this goes too.
> > >
> > > Is bootcount really suited for this case?
> > > AFAIK bootcount either requires device specific registers (which won't
> > > reset on reboots), or an environment you can write data to.
> > > But what if a user wants to disable writing the env variables and the
> > > device doesn't have a set of registers we can use?
> > >
> > Maybe it should be moved in 'struct fwu_mdata' ?
>
> I was mostly thinking on moving this count as another 'bootcount'
> method.  So in case the user has disabled writing evn variables but he
> is booting with EFI he can use that.
>
Sorry, not sure I understand IIUIC there has to be some persistent storage.

Of the three options - registers, efi-env and mdata, I think the last
one is more robust.
For ex, if BL33 isn't reached after an update. We want BL2 (which may
not have access to efi variables)
to be able to revert the active index.

thanks.

Re: [PATCH v6 00/13] FWU: Add FWU Multi Bank Update feature support

On Mon, 4 Jul 2022 at 00:17, Sughosh Ganu  wrote:

>
> The earlier patchset contained patches for both the DK2 and the
> Synquacer platforms. The handling of review comments for the Synquacer
> platform is to be taken up by a different engineer, and
>
That would be me.

> has not been
> done yet. After discussion with Tom Rini and Heinrich, it was decided
> to send the patches for the DK2 platform separately for review.
>
I see the whole not-gpt/mtd support has been dissected out of this revision.
I need to reintroduce those patches and then Synquacer support on top of that.
Is anybody already working on the first part?

thanks

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

Hi Jassi

On Mon, 18 Jul 2022 at 18:08, Jassi Brar  wrote:
>
> On Mon, 18 Jul 2022 at 09:47, Ilias Apalodimas
>  wrote:
> >
> > Hi all,
> >
> > On Mon, 18 Jul 2022 at 17:43, Jassi Brar  wrote:
> > >
> > > On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > > From: Masami Hiramatsu 
> > > > >
> > > 
> > >
> > > > > +}
> > > > > +
> > > > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > > > +{
> > > > > + int ret = 0;
> > > > > +
> > > > > + if (!plat_spi_flash)
> > > > > + ret = __plat_sf_get_flash();
> > > > > +
> > > > > + *flash = plat_spi_flash;
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > > > +{
> > > > > + struct spi_flash *flash;
> > > > > + int ret;
> > > > > +
> > > > > + ret = plat_sf_get_flash(&flash);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > > > + if (!*data)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + ret = spi_flash_read(flash, offs, size, *data);
> > > > > + if (ret < 0) {
> > > > > + free(*data);
> > > > > + *data = NULL;
> > > > > + }
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > > > +{
> > > > > + struct spi_flash *flash;
> > > > > + u32 sect_size, nsect;
> > > > > + void *buf;
> > > > > + int ret;
> > > > > +
> > > > > + ret = plat_sf_get_flash(&flash);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + sect_size = flash->mtd.erasesize;
> > > > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> > > >
> > > > What it is interesting here that framework itself is using mtd 
> > > > infrastructure
> > > > but this platform driver is calling spi functions directly.
> > > > It looks a little bit nonstandard way. What's the reason for it?
> > > >
> > > Yup, this whole sf shebang is unnecessary, and removed for next revision.
> > >
> > > > > +
> > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > +
> > > > > +struct __packed devbox_metadata {
> > > > > + u32 boot_index;
> > > > > + u32 boot_count;
> > > >
> > > > There is the whole bootcount infrastructure for this. I think it would 
> > > > be much
> > > > better to use that framework instead of creating parallel one.
> > > >
> > > Yes, this goes too.
> >
> > Is bootcount really suited for this case?
> > AFAIK bootcount either requires device specific registers (which won't
> > reset on reboots), or an environment you can write data to.
> > But what if a user wants to disable writing the env variables and the
> > device doesn't have a set of registers we can use?
> >
> Maybe it should be moved in 'struct fwu_mdata' ?

I was mostly thinking on moving this count as another 'bootcount'
method.  So in case the user has disabled writing evn variables but he
is booting with EFI he can use that.

Regards
/Ilias
>
> thnx

Re: [PATCH] efi: test/py: repair authenticated capsules tests

2022-07-18 Thread Heinrich Schuchardt


On 6/28/22 07:14, AKASHI Takahiro wrote:

Heinrich,

On Mon, Jun 27, 2022 at 12:46:07PM +0200, Heinrich Schuchardt wrote:

On 6/27/22 12:23, Vincent Stehlé wrote:

The UEFI console initialisation has been modified by commit 68edbed454b8
("efi_loader: initialize console size late"). A corresponding workaround is
now necessary for the automated tests, as added to some of the tests
already by commit e05bd68ed5fc ("test: work around for EFI terminal size
probing").

Add the same workaround to the UEFI authenticated capsules tests to repair
them.

This can be tested with sandbox_defconfig, sandbox64_defconfig or
sandbox_flattree_defconfig, plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.

Signed-off-by: Vincent Stehlé 


Why are these tests not run in Gitlab?
Can't we permanently adjust one of said defconfigs for this purpose?
Or do we need a new defconfig for testing?


Because we cannot turn on or off capsule authentication dynamically
on a single U-Boot image, we cannot test non-signed test cases
and signed test cases simultaneously in CI.

That is why I proposed a new config file for sandbox with
EFI_CAPSULE_AUTHENTICATE, but the idea was rejected (if I remember correctly, 
by Simon).

That said, I also made a small change to unsigned test cases
(test_efi_capsule_firmware(_*).py) so that they can *pass* even with
EFI_CAPSULE_AUTHENTICATE enabled.
(As you can image, however, actual capsule update never happens in
this test environment.)

commit e012550cd7d6 ("test/py: efi_capsule: check the results in case of
CAPSULE_AUTHENTICATE")


-Takahiro Akashi


Reviewed-by: Heinrich Schuchardt

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

On Mon, 18 Jul 2022 at 09:47, Ilias Apalodimas
 wrote:
>
> Hi all,
>
> On Mon, 18 Jul 2022 at 17:43, Jassi Brar  wrote:
> >
> > On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > From: Masami Hiramatsu 
> > > >
> > 
> >
> > > > +}
> > > > +
> > > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > > +{
> > > > + int ret = 0;
> > > > +
> > > > + if (!plat_spi_flash)
> > > > + ret = __plat_sf_get_flash();
> > > > +
> > > > + *flash = plat_spi_flash;
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > > +{
> > > > + struct spi_flash *flash;
> > > > + int ret;
> > > > +
> > > > + ret = plat_sf_get_flash(&flash);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > > + if (!*data)
> > > > + return -ENOMEM;
> > > > +
> > > > + ret = spi_flash_read(flash, offs, size, *data);
> > > > + if (ret < 0) {
> > > > + free(*data);
> > > > + *data = NULL;
> > > > + }
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > > +{
> > > > + struct spi_flash *flash;
> > > > + u32 sect_size, nsect;
> > > > + void *buf;
> > > > + int ret;
> > > > +
> > > > + ret = plat_sf_get_flash(&flash);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + sect_size = flash->mtd.erasesize;
> > > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> > >
> > > What it is interesting here that framework itself is using mtd 
> > > infrastructure
> > > but this platform driver is calling spi functions directly.
> > > It looks a little bit nonstandard way. What's the reason for it?
> > >
> > Yup, this whole sf shebang is unnecessary, and removed for next revision.
> >
> > > > +
> > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > +
> > > > +struct __packed devbox_metadata {
> > > > + u32 boot_index;
> > > > + u32 boot_count;
> > >
> > > There is the whole bootcount infrastructure for this. I think it would be 
> > > much
> > > better to use that framework instead of creating parallel one.
> > >
> > Yes, this goes too.
>
> Is bootcount really suited for this case?
> AFAIK bootcount either requires device specific registers (which won't
> reset on reboots), or an environment you can write data to.
> But what if a user wants to disable writing the env variables and the
> device doesn't have a set of registers we can use?
>
Maybe it should be moved in 'struct fwu_mdata' ?

thnx

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

2022-07-18 Thread Harald Seiler

Hi Simon,

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

Right, this is what I am relying on right now.  The problem is that this
does not have any effect when `console=` is not used and the console is
instead passed using the `/chosen/stdout-path` DT property.

I was wondering whether U-Boot should maybe delete this property from
the DT passed to Linux when going silent...

(But of course this is unrelated to the original patch here)

-- 
Harald

Re: DWC3 host support

2022-07-18 Thread Angus Ainslie


Hi Marek/Michal,

On 2022-07-18 01:13, Michal Simek wrote:

On 7/17/22 17:23, Marek Vasut wrote:

On 7/17/22 05:00, Angus Ainslie wrote:

On 2022-07-16 11:37, Marek Vasut wrote:

On 7/16/22 15:02, Angus Ainslie wrote:

Hi Michal,

I recently rebased my librem5 tree onto the latest u-boot-imx 
branch

and the dwc3 host mode stopped working.

I bisected it down to this commit:

142d50fbce7c364a74f5e8204dba491b9f066e6c usb: dwc3: Add support for
usb3-phy PHY configuration

Reverting that commit allows usb host mode to work on the librem5 
again.


Should this initialization go into an SOC specific glue_configure
function ?

Is the imx8mq.dtsi missing something that will keep usb host 
working

with this patch ?

Does this break usb host on other imx8mq devices ?


Wasn't this fixed by:
868d58f69c ("usb: dwc3: Fix non-usb3 configurations")
?


I've got that in my tree and it still fails to probe the USB2 hub and
USB 2 storage.


I assume you do have CONFIG_PHY_IMX8MQ_USB enabled ?

What does generic_phy_get_by_name() return for you in
drivers/usb/dwc3/dwc3-generic.c ?


As Marek said there was one patch which fixes origin patch which
didn't handle all the error cases properly. We need to know return
value from generic_phy_get_by_name(), also if you still have usb3-phy
in DT (as is in imx8mq.dtsi) with phy DT status enabled and enabled
phy driver (CONFIG_PHY_IMX8MQ_USB).



I use the imx8mq.dtsi from the u-boot-imx tree that includes the 
usb3-phy


https://source.denx.de/u-boot/custodians/u-boot-imx/-/blob/master/arch/arm/dts/imx8mq.dtsi#L1421

CONFIG_PHY_IMX8MQ_USB is defined in my defconfig

https://source.puri.sm/angus.ainslie/uboot-imx/-/blob/upstream/librem5-uart2/configs/librem5_defconfig#L114

Here is the error path I think you're talking about

https://source.puri.sm/angus.ainslie/uboot-imx/-/blob/upstream/librem5-uart2/drivers/usb/dwc3/dwc3-generic.c#L474

I modified dwc3-generic.c to print the return value

@@ -475,6 +477,8 @@ static int dwc3_glue_probe(struct udevice *dev)
phy.dev = NULL;
}

+   debug("phy3 initialized %d %s\n", ret, phy.dev ? phy.dev->name : 
"null");

+
glue->regs = dev_read_addr(dev);

Here's the output from the boot

U-Boot 2022.07-rc5-00014-g329f8a8ae05-dirty (Jul 18 2022 - 06:59:45 
-0700)


CPU:   Freescale i.MX8MQ rev2.0 1500 MHz (running at 1000 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 35C
Reset cause: POR
Model: Purism Librem 5r4
DRAM:  3 GiB
dwc3_glue_bind: subnode name: port@0
dwc3_glue_bind: dr_mode: OTG or Peripheral
dwc3_glue_bind: subnode name: port@1
dwc3_glue_bind: dr_mode: OTG or Peripheral
dwc3_glue_bind: subnode name: hub@1
dwc3_glue_bind: dr_mode: HOST
clk_register: failed to get  device (parent of ckil)
clk_register: failed to get  device (parent of clock-osc-27m)
clk_register: failed to get  device (parent of sys1_pll)
clk_register: failed to get  device (parent of sys2_pll)
clk_register: failed to get  device (parent of sys3_pll)
Enabling regulator-hub
tps65982 boot successful
Core:  192 devices, 25 uclasses, devicetree: separate
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:serial
Out:   serial
Err:   serial
Board name: librem5
Board rev:  4
vol_down_key_pressed : 1
Net:   No ethernet found.
Hit any key to stop autoboot:  0
u-boot=> usb start
starting USB...
Bus hub@1: generic_phy_get_by_name(dev=ffb19830, name=usb3-phy, 
phy=ffb08460)
generic_phy_get_by_index_nodev(node=usb@3820, index=1, 
phy=ffb08460)

generic_phy_xlate_offs_flags(phy=ffb08460)
phy3 initialized 0 usb-phy@382f0040
phy3 powered on
dwc3_glue_probe finished
generic_phy_get_by_index_nodev(node=usb@3820, index=0, 
phy=ffb2b1e0)

generic_phy_xlate_offs_flags(phy=ffb2b1e0)
generic_phy_get_by_index_nodev(node=usb@3820, index=1, 
phy=ffb2b1f0)

generic_phy_xlate_offs_flags(phy=ffb2b1f0)
dwc3-generic-host hub@1: Event buf ffb2b340 dma ffb2b340 length 
256

Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus hub@1 for devices... cannot reset port 1!?
1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
u-boot=> usb info
1: Hub,  USB Revision 3.0
 - U-Boot XHCI Host Controller
 - Class: Hub
 - PacketSize: 512  Configurations: 1
 - Vendor: 0x  Product 0x Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

Thanks
Angus


Thanks,
Michal

Re: [PATCH v5 20/23] FWU: synquacer: Generate dfu_alt_info from devicetree partition

On Fri, 17 Jun 2022 at 09:02, Michal Simek  wrote:
> On 6/9/22 14:30, Sughosh Ganu wrote:
> > From: Masami Hiramatsu 
.

> >
> > @@ -188,6 +178,9 @@ int board_late_init(void)
> >   {
> >   int ret;
> >
> > + /* Make mmc available for EFI */
> > + run_command("mmc dev 0", 0);
> > +
>
> What is this for?
>
> And I can't see any single note about in commit message.
>
For some reason, we get "No EFI system partition" during bootup and
the mmc does not show up in 'efidebug devices' unless we manually run
this (or mmc part) command.
Though not elegant, I found similar being done by some other
platforms  grep run_command -rw board/*
I am happy to learn the proper way of doing it.

Thanks.

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

Hi all,

On Mon, 18 Jul 2022 at 17:43, Jassi Brar  wrote:
>
> On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > From: Masami Hiramatsu 
> > >
> 
>
> > > +}
> > > +
> > > +static int plat_sf_get_flash(struct spi_flash **flash)
> > > +{
> > > + int ret = 0;
> > > +
> > > + if (!plat_spi_flash)
> > > + ret = __plat_sf_get_flash();
> > > +
> > > + *flash = plat_spi_flash;
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int sf_load_data(u32 offs, u32 size, void **data)
> > > +{
> > > + struct spi_flash *flash;
> > > + int ret;
> > > +
> > > + ret = plat_sf_get_flash(&flash);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > > + if (!*data)
> > > + return -ENOMEM;
> > > +
> > > + ret = spi_flash_read(flash, offs, size, *data);
> > > + if (ret < 0) {
> > > + free(*data);
> > > + *data = NULL;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int sf_save_data(u32 offs, u32 size, void *data)
> > > +{
> > > + struct spi_flash *flash;
> > > + u32 sect_size, nsect;
> > > + void *buf;
> > > + int ret;
> > > +
> > > + ret = plat_sf_get_flash(&flash);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + sect_size = flash->mtd.erasesize;
> > > + nsect = DIV_ROUND_UP(size, sect_size);
> > > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
> >
> > What it is interesting here that framework itself is using mtd 
> > infrastructure
> > but this platform driver is calling spi functions directly.
> > It looks a little bit nonstandard way. What's the reason for it?
> >
> Yup, this whole sf shebang is unnecessary, and removed for next revision.
>
> > > +
> > > +#define PLAT_METADATA_OFFSET 0x51
> > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > +
> > > +struct __packed devbox_metadata {
> > > + u32 boot_index;
> > > + u32 boot_count;
> >
> > There is the whole bootcount infrastructure for this. I think it would be 
> > much
> > better to use that framework instead of creating parallel one.
> >
> Yes, this goes too.

Is bootcount really suited for this case?
AFAIK bootcount either requires device specific registers (which won't
reset on reboots), or an environment you can write data to.
But what if a user wants to disable writing the env variables and the
device doesn't have a set of registers we can use?

Thanks
/Ilias
>
> Thanks.

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

On Mon, 20 Jun 2022 at 03:23, Michal Simek  wrote:
> On 6/9/22 14:30, Sughosh Ganu wrote:
> > From: Masami Hiramatsu 
> >


> > +}
> > +
> > +static int plat_sf_get_flash(struct spi_flash **flash)
> > +{
> > + int ret = 0;
> > +
> > + if (!plat_spi_flash)
> > + ret = __plat_sf_get_flash();
> > +
> > + *flash = plat_spi_flash;
> > +
> > + return ret;
> > +}
> > +
> > +static int sf_load_data(u32 offs, u32 size, void **data)
> > +{
> > + struct spi_flash *flash;
> > + int ret;
> > +
> > + ret = plat_sf_get_flash(&flash);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *data = memalign(ARCH_DMA_MINALIGN, size);
> > + if (!*data)
> > + return -ENOMEM;
> > +
> > + ret = spi_flash_read(flash, offs, size, *data);
> > + if (ret < 0) {
> > + free(*data);
> > + *data = NULL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int sf_save_data(u32 offs, u32 size, void *data)
> > +{
> > + struct spi_flash *flash;
> > + u32 sect_size, nsect;
> > + void *buf;
> > + int ret;
> > +
> > + ret = plat_sf_get_flash(&flash);
> > + if (ret < 0)
> > + return ret;
> > +
> > + sect_size = flash->mtd.erasesize;
> > + nsect = DIV_ROUND_UP(size, sect_size);
> > + ret = spi_flash_erase(flash, offs, nsect * sect_size);
>
> What it is interesting here that framework itself is using mtd infrastructure
> but this platform driver is calling spi functions directly.
> It looks a little bit nonstandard way. What's the reason for it?
>
Yup, this whole sf shebang is unnecessary, and removed for next revision.

> > +
> > +#define PLAT_METADATA_OFFSET 0x51
> > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > +
> > +struct __packed devbox_metadata {
> > + u32 boot_index;
> > + u32 boot_count;
>
> There is the whole bootcount infrastructure for this. I think it would be much
> better to use that framework instead of creating parallel one.
>
Yes, this goes too.

Thanks.

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper

On Mon, Jul 18, 2022 at 03:14:33PM +0200, Xavier Drudis Ferran wrote:
> El Mon, Jul 18, 2022 at 01:00:03PM +0200, Michal Suchánek deia:
>  
> > mmc@fe31: 3
> > mmc@fe32: 1 (SD)
> > mmc@fe33: 0 (eMMC)
> > 
> > This is not consistent with any of the above.
> >
> 
> I agree, but this is mmc, and this thread was about spi. 

Sorry for hijacking your thread then.

I was probably looking for the other patch that adjusts the mmc indexes.

Thanks

Michal

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper

On Mon, Jul 18, 2022 at 03:01:25PM +0200, Quentin Schulz wrote:
> Hi Michal,
> 
> On 7/18/22 13:00, Michal Suchánek wrote:
> > On Mon, Jul 18, 2022 at 11:09:56AM +0200, Xavier Drudis Ferran wrote:
> > > El Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz deia:
> > > > Hi Xavier,
> > > > 
> > > > On 7/15/22 18:30, Xavier Drudis Ferran wrote:
> > > > > Spi0 is not needed in SPL and SPL could be a little smaller without 
> > > > > it,
> > > > > but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
> > > > > that's confusing, because once U-Boot proper runs, it numbers the bus 
> > > > > 1.
> > > > > 
> > > > > Add spi0 to the pre-reloc and spl trees so that the flash is always
> > > > > connected to bus 1.
> > > > > 
> > > > 
> > > > Mmmm... Could we instead make U-Boot use the bus number from the alias 
> > > > in
> > > > the aliases DT node? I think the mmc subsystem does this already and it
> > > > would mean we don't need to enable unnecessary devices. Also, relying on
> > > > boot order for the bus number is brittle in Linux, I don't know about
> > > > U-Boot, but if we can avoid this assumption, it'd be great :)
> > > > 
> > > > See: 
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__source.denx.de_u-2Dboot_u-2Dboot_-2D_commit_2243d19e5618122d9d7aba23eb51f63f2719dba5&d=DwIBAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=G-LrZmlVXqwFFza02frCo5F8vUCol4vDYe6RpSOpezwdgWuNQZyIB2hF_SNO4Gz3&s=O9wEK10SUOQNv_9zcY0K2oSdD_soaQtgjga-pw9nAgY&e=
> > > > for how to do it today?
> > > > 
> > > 
> > > Maybe I should just drop this patch and try to define
> > > CONFIG_SPL_DM_SEQ_ALIAS in configs/rock-pi-4-rk3399 instead ?
> > > Let me test this a little...
> > > 
> > > I have CONFIG_DM_SEQ_ALIAS=y but   CONFIG_SPL_DM_SEQ_ALIAS unset.
> > > 
> > > > 
> > > > Your patch series got sent with each commit in their individual thread
> > > 
> > > I know. Sorry for the lapsus. I did it right in v1, wrong in v2, and will 
> > > do right in v3.
> > 
> > What is actually the correct naming here?
> > 
> > We have in arch/arm/mach-rockchip/rk3399/rk3399.c
> > 
> > const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> >  [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
> >  [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
> >  [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
> > };
> > 
> >  } spl_boot_devices_tbl[] = {
> >  { BOOT_DEVICE_MMC1, "/mmc@fe32" },
> >  { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
> >  { BOOT_DEVICE_SPI, "/spi@ff1d" },
> >  };
> > 
> 
> This one was incorrect for boards not redefining the aliases nodes for mmc
> devices from rk3399-u-boot.dtsi and I've sent a patch for it:
> https://lore.kernel.org/u-boot/20220715151552.953654-1-foss+ub...@0leil.net/

Which actually sounds reasonable.

> 
> > which then presumably gets converted in common/spl/spl_mmc.c
> > 
> > SPL_LOAD_IMAGE_METHOD("MMC1", 0, BOOT_DEVICE_MMC1, spl_mmc_load_image);
> > SPL_LOAD_IMAGE_METHOD("MMC2", 0, BOOT_DEVICE_MMC2, spl_mmc_load_image);
> > SPL_LOAD_IMAGE_METHOD("MMC2_2", 0, BOOT_DEVICE_MMC2_2, spl_mmc_load_image);
> > 
> 
> I actually think from spl_mmc_get_device_index()?

The above gives the user-visible string.

spl_mmc_get_device_index establishes the off-by-one between boot devices
and indexes:

static int spl_mmc_get_device_index(u32 boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
return 0;
case BOOT_DEVICE_MMC2:
case BOOT_DEVICE_MMC2_2:
return 1;
}


> 
> > We then have this in rk3399.dtsi:
> > 
> >  sdio0: mmc@fe31 {
> >  compatible = "rockchip,rk3399-dw-mshc",
> > 
> >  sdmmc: mmc@fe32 {
> >  compatible = "rockchip,rk3399-dw-mshc",
> > 
> >  sdhci: mmc@fe33 {
> >  compatible = "rockchip,rk3399-sdhci-5.1", 
> > "arasan,sdhci-5.1";
> > 
> > and this in rk3399-u-boot.dtsi
> > 
> >  mmc0 = &sdhci;
> >  mmc1 = &sdmmc;
> > 
> > and this in arch/arm/dts/rk3399-pinebook-pro.dts
> > 
> >  aliases {
> >  mmc0 = &sdio0;
> >  mmc1 = &sdmmc;
> >  mmc2 = &sdhci;
> >  };
> > 
> > 
> > mmc@fe31: 3
> > mmc@fe32: 1 (SD)
> > mmc@fe33: 0 (eMMC)

Which would then mean that this is off-by-one and consistent with
spl_mmc_get_device_index and the SoC dtsi but not the board dts.

It's also what's seen in upstream Linux

mmc0: SDHCI controller on fe33.mmc [fe33.mmc] using ADMA
mmc0: new HS200 MMC card at address 0001
mmcblk0: mmc0:0001 DA4064

mmc1: new ultra high speed SDR104 SDHC card at address 
mmcblk1: mmc1: SC32G

mmc3: new ultra high speed SDR104 SDIO card at address 0001

Where does the 3 come from is a mystery.

> > 
> > This is not consistent with any of the above.
> > 
> 
> I think spl_

[bug] boot failure on pinebook pro due to rk8xx changes in 2022.07

2022-07-18 Thread Jan Palus

u-boot 2022.07 successfully finds and loads kernel (5.18.3) on my
Pinebook Pro however boot process fails when loading rk808 module:

  rk3x-i2c ff3c.i2c: timeout, ipd: 0x00, state: 1
  rk808 0-001b: failed to read the chip id at 0x17
  rk808: probe of 0-001b failed with error -110

git bisect indicates first commit to cause regression:

  commit ad607512f5757f4485968efd5bcf2c0245a8a235 (refs/bisect/bad)
  Author: Chris Morgan 
  Date:   Fri May 27 20:18:19 2022
  
  power: pmic: rk8xx: Support sysreset shutdown method
  
  Add support for sysreset shutdown for this PMIC. The values were pulled
  from the various datasheets, but for now it has only been tested on
  the rk817 (for an Odroid Go Advance).
  
  Signed-off-by: Chris Morgan 
  Reviewed-by: Jaehoon Chung 
  Reviewed-by: Kever Yang 

Reverting this commit fixes the issue and upon rk808 module load
following is logged:

  rk808 0-001b: chip id: 0x0

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

Hi Kojima-san


On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima
 wrote:
>
> This commit add the "eficonfig" command.
> The "eficonfig" command implements the menu-driven UEFI boot option
> maintenance feature. This commit implements the addition of
> new boot option. User can select the block device volume having
> efi_simple_file_system_protocol and select the file corresponding
> to the Boot variable. User can also enter the description and
> optional_data of the BOOT variable in utf8.
>
> This commit adds "include/efi_config.h", it contains the common
> definition to be used from other menus such as UEFI Secure Boot
> key management.
>
> Signed-off-by: Masahisa Kojima 
> ---
> Changes in v9:
> - move "efi_guid_bootmenu_auto_generated definition" into efi_bootmgr.c
>   to address build error when CMD_EFICONFIG is disabled
> - fix typos and comment
> - remove file system information from error message
> - remove unreachable code in eficonfig_choice_entry()
> - single printf() call as much as possible
> - call only getchar() in  eficonfig_print_msg()
> - filter out '.' entry from file selection
> - update the efi_disk_get_device_name() implementation
> - add function comment
>
> Changes in v8:
> - command name is change from "efimenu" to "eficonfig"
> - function and struct prefixes is changed to "eficonfig"
> - fix menu header string
>
> Changes in v7:
> - add "efimenu" command and uefi variable maintenance code
>   moved into cmd/efimenu.c
> - create include/efimenu.h to define the common definition for
>   the other menu such as UEFI Secure Boot key management
> - update boot option edit UI, user can select description, file,
>   and optional_data to edit in the same menu like following.
>
>   ** Edit Boot Option **
>
>  Description: debian
>  File: virtio 0:1/EFI\debian\grubaa64.efi
>  Optional Data: test
>  Save
>  Quit
>
[...]

I'll have a look at the code as well, but something weird is happening
on QEMU.  I got an ESP partition and I can save EFI variables in a
ubootefi.var file.  However every time I start QEMU the options I add
via the menu are missing although the efi variables seem to be stored
properly.

=> printenv -e
[...]
Boot0001:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
NV|BS|RT, DataSize = 0x9d
: 01 00 00 00 8b 00 67 00 72 00 75 00 62 00 00 00  ..g.r.u.b...
0010: 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8  .s.J
0020: 28 f3 62 8b 01 04 15 00 92 37 29 63 f5 ad 25 93  (.b..7)c..%.
0030: b9 9f 4e 0e 45 5c 1b 1e 00 04 01 2a 00 01 00 00  ..N.E\.*
0040: 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00  
0050: 00 10 56 ae bd 31 33 4d 4e 94 66 ac b5 ca f0 b4  ..V..13MN.f.
0060: a6 02 02 04 04 34 00 45 00 46 00 49 00 5c 00 64  .4.E.F.I.\.d
0070: 00 65 00 62 00 69 00 61 00 6e 00 5c 00 67 00 72  .e.b.i.a.n.\.g.r
0080: 00 75 00 62 00 61 00 61 00 36 00 34 00 2e 00 65  .u.b.a.a.6.4...e
0090: 00 66 00 69 00 00 00 7f ff 04 00 00 00   .f.i.
Boot0002:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
NV|BS|RT, DataSize = 0x9d
: 01 00 00 00 8b 00 67 00 72 00 75 00 62 00 00 00  ..g.r.u.b...
0010: 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8  .s.J
0020: 28 f3 62 8b 01 04 15 00 92 37 29 63 f5 ad 25 93  (.b..7)c..%.
0030: b9 9f 4e 0e 45 5c 1b 1e 00 04 01 2a 00 01 00 00  ..N.E\.*
0040: 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00  
0050: 00 10 56 ae bd 31 33 4d 4e 94 66 ac b5 ca f0 b4  ..V..13MN.f.
0060: a6 02 02 04 04 34 00 45 00 46 00 49 00 5c 00 64  .4.E.F.I.\.d
0070: 00 65 00 62 00 69 00 61 00 6e 00 5c 00 67 00 72  .e.b.i.a.n.\.g.r
0080: 00 75 00 62 00 61 00 61 00 36 00 34 00 2e 00 65  .u.b.a.a.6.4...e
0090: 00 66 00 69 00 00 00 7f ff 04 00 00 00   .f.i.
Boot0003:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
NV|BS|RT, DataSize = 0x9d
: 01 00 00 00 8b 00 67 00 72 00 75 00 62 00 00 00  ..g.r.u.b...
0010: 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8  .s.J
0020: 28 f3 62 8b 01 04 15 00 92 37 29 63 f5 ad 25 93  (.b..7)c..%.
0030: b9 9f 4e 0e 45 5c 1b 1e 00 04 01 2a 00 01 00 00  ..N.E\.*
0040: 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00  
0050: 00 10 56 ae bd 31 33 4d 4e 94 66 ac b5 ca f0 b4  ..V..13MN.f.
0060: a6 02 02 04 04 34 00 45 00 46 00 49 00 5c 00 64  .4.E.F.I.\.d
0070: 00 65 00 62 00 69 00 61 00 6e 00 5c 00 67 00 72  .e.b.i.a.n.\.g.r
0080: 00 75 00 62 00 61 00 61 00 36 00 34 00 2e 00 65  .u.b.a.a.6.4...e
0090: 00 66 00 69 00 00 00 7f ff 04 00 00 00   .f.i.
Boot0004:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
N

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper

El Mon, Jul 18, 2022 at 01:00:03PM +0200, Michal Suchánek deia:
 
> mmc@fe31: 3
> mmc@fe32: 1 (SD)
> mmc@fe33: 0 (eMMC)
> 
> This is not consistent with any of the above.
>

I agree, but this is mmc, and this thread was about spi.

Re: [RESEND v9 8/9] doc:bootmenu: add description for UEFI boot support

Hi Kojima-san

On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima
 wrote:
>
> The bootmenu enumerates the UEFI boot options
> for boot device selection.
> This commit adds the description how the UEFI boot work
> in bootmenu. This commit also adds "Synopsis", "Description"
> and "Configuration" sections to follow the U-Boot command
> documentation format.
>
> Signed-off-by: Masahisa Kojima 
> ---
> No change since v7
>
> Changes in v7:
> - update the description what bootmenu do for uefi-related boot menu
> - add default behavior when user exits from bootmenu
>
> Changes in v6:
> - remove distro boot related contents because the distro boot
> support in bootmenu is dropped
> - update uefi entry example
> - add [delay] argument of bootmenu command
> - add description to enable uefi boot entry
>
> Changes in v5:
> - follow the cmd documentation format same as other command, add "Synopsis",
>   "Description" add "Configuration" sections
>
> Newly created in v4
>
>  doc/usage/cmd/bootmenu.rst | 74 ++
>  1 file changed, 74 insertions(+)
>
> diff --git a/doc/usage/cmd/bootmenu.rst b/doc/usage/cmd/bootmenu.rst
> index 9430f8c9aa..69435090a2 100644
> --- a/doc/usage/cmd/bootmenu.rst
> +++ b/doc/usage/cmd/bootmenu.rst
> @@ -4,6 +4,15 @@
>  bootmenu command
>  
>
> +Synopsis
> +
> +::
> +
> +bootmenu [delay]
> +
> +Description
> +---
> +
>  The "bootmenu" command uses U-Boot menu interfaces and provides
>  a simple mechanism for creating menus with different boot items.
>  The cursor keys "Up" and "Down" are used for navigation through
> @@ -79,6 +88,55 @@ The above example will be rendered as below::
>  The selected menu entry will be highlighted - it will have inverted
>  background and text colors.
>
> +UEFI boot variable enumeration
> +''
> +If enabled, the bootmenu command will automatically generate and add
> +UEFI-related boot menu entries for the following items.
> +
> + * possible bootable media with default file names
> + * user-defined UEFI boot options
> +
> +The bootmenu automatically enumerates the possible bootable
> +media devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
> +This auto generated entry is named as " :" format.
> +(e.g. "usb 0:1")
> +
> +The bootmenu displays the UEFI-related menu entries in order of "BootOrder".
> +When the user selects the UEFI boot menu entry, the bootmenu sets
> +the selected boot variable index to "BootNext" without non-volatile 
> attribute,
> +then call the uefi boot manager with the command "bootefi bootmgr".
> +
> +Example bootmenu is as below::
> +
> +*** U-Boot Boot Menu ***
> +
> +   mmc 0:1
> +   mmc 0:2
> +   debian
> +   nvme 0:1
> +   ubuntu
> +   nvme 0:2
> +   usb 0:2
> +   U-Boot console
> +
> +Default behavior when user exits from the bootmenu
> +~~
> +User can exit from bootmenu by selecting the last entry
> +"U-Boot console"/"Quit" or ESC/CTRL+C key.
> +
> +When the CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is disabled,
> +user exits from the bootmenu and returns to the U-Boot console.
> +
> +When the CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not
> +enter the U-Boot console. When the user exits from the bootmenu,
> +the bootmenu invokes the following default behabior.

Behavior

> +
> + * if CONFIG_CMD_BOOTEFI_BOOTMGR is enabled, execute "bootefi bootmgr" 
> command
> + * "bootefi bootmgr" fails or is not enabled, then execute "run bootcmt" 
> command.

"run bootcmd"

> +
> +Configuration
> +-
> +
>  The "bootmenu" command is enabled by::
>
>  CONFIG_CMD_BOOTMENU=y
> @@ -88,3 +146,19 @@ To run the bootmenu at startup add these additional 
> settings::
>  CONFIG_AUTOBOOT_KEYED=y
>  CONFIG_BOOTDELAY=30
>  CONFIG_AUTOBOOT_MENU_SHOW=y
> +
> +UEFI boot variable enumeration is enabled by::
> +
> +CONFIG_CMD_BOOTEFI_BOOTMGR=y
> +
> +To improve the product security, entering U-Boot console from bootmenu
> +can be disabled by::
> +
> +CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE=y
> +
> +To scan the discoverable devices connected to the buses such as
> +USB and PCIe prior to bootmenu showing up, CONFIG_PREBOOT can be
> +used to run the command before showing the bootmenu, i.e.::
> +
> +CONFIG_USE_PREBOOT=y
> +CONFIG_PREBOOT="pci enum; usb start; scsi scan; nvme scan; virtio scan"
> --
> 2.17.1
>

With these changes

Reviewed-by: Ilias Apalodimas

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper


Hi Michal,

On 7/18/22 13:00, Michal Suchánek wrote:

On Mon, Jul 18, 2022 at 11:09:56AM +0200, Xavier Drudis Ferran wrote:

El Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz deia:

Hi Xavier,

On 7/15/22 18:30, Xavier Drudis Ferran wrote:

Spi0 is not needed in SPL and SPL could be a little smaller without it,
but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
that's confusing, because once U-Boot proper runs, it numbers the bus 1.

Add spi0 to the pre-reloc and spl trees so that the flash is always
connected to bus 1.



Mmmm... Could we instead make U-Boot use the bus number from the alias in
the aliases DT node? I think the mmc subsystem does this already and it
would mean we don't need to enable unnecessary devices. Also, relying on
boot order for the bus number is brittle in Linux, I don't know about
U-Boot, but if we can avoid this assumption, it'd be great :)

See: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__source.denx.de_u-2Dboot_u-2Dboot_-2D_commit_2243d19e5618122d9d7aba23eb51f63f2719dba5&d=DwIBAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=G-LrZmlVXqwFFza02frCo5F8vUCol4vDYe6RpSOpezwdgWuNQZyIB2hF_SNO4Gz3&s=O9wEK10SUOQNv_9zcY0K2oSdD_soaQtgjga-pw9nAgY&e=
for how to do it today?



Maybe I should just drop this patch and try to define
CONFIG_SPL_DM_SEQ_ALIAS in configs/rock-pi-4-rk3399 instead ?
Let me test this a little...

I have CONFIG_DM_SEQ_ALIAS=y but   CONFIG_SPL_DM_SEQ_ALIAS unset.



Your patch series got sent with each commit in their individual thread


I know. Sorry for the lapsus. I did it right in v1, wrong in v2, and will do 
right in v3.


What is actually the correct naming here?

We have in arch/arm/mach-rockchip/rk3399/rk3399.c

const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
 [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
 [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
 [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
};

 } spl_boot_devices_tbl[] = {
 { BOOT_DEVICE_MMC1, "/mmc@fe32" },
 { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
 { BOOT_DEVICE_SPI, "/spi@ff1d" },
 };



This one was incorrect for boards not redefining the aliases nodes for 
mmc devices from rk3399-u-boot.dtsi and I've sent a patch for it:

https://lore.kernel.org/u-boot/20220715151552.953654-1-foss+ub...@0leil.net/


which then presumably gets converted in common/spl/spl_mmc.c

SPL_LOAD_IMAGE_METHOD("MMC1", 0, BOOT_DEVICE_MMC1, spl_mmc_load_image);
SPL_LOAD_IMAGE_METHOD("MMC2", 0, BOOT_DEVICE_MMC2, spl_mmc_load_image);
SPL_LOAD_IMAGE_METHOD("MMC2_2", 0, BOOT_DEVICE_MMC2_2, spl_mmc_load_image);



I actually think from spl_mmc_get_device_index()?


We then have this in rk3399.dtsi:

 sdio0: mmc@fe31 {
 compatible = "rockchip,rk3399-dw-mshc",

 sdmmc: mmc@fe32 {
 compatible = "rockchip,rk3399-dw-mshc",

 sdhci: mmc@fe33 {
 compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";

and this in rk3399-u-boot.dtsi

 mmc0 = &sdhci;
 mmc1 = &sdmmc;

and this in arch/arm/dts/rk3399-pinebook-pro.dts

 aliases {
 mmc0 = &sdio0;
 mmc1 = &sdmmc;
 mmc2 = &sdhci;
 };


mmc@fe31: 3
mmc@fe32: 1 (SD)
mmc@fe33: 0 (eMMC)

This is not consistent with any of the above.



I think spl_decode_boot_device() assumes the index is the same for all 
rk3399 boards which does not seem to be the case for the Pinebook Pro 
(and is a bad assumption I can agree on that :) ). I guess a way to 
correctly support your device would be to read the aliases node and do 
the mapping between DT's mmc0 and BOOT_DEVICE_MMC1. I am not sure there 
ever was an interest/desire to document/guarantee what a 
BOOT_DEVICE_MMCx would represent, see 
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-rockchip/spl-boot-order.c#L18-23 
(or maybe it's a convoluted way to say "BOOT_DEVICE_MMC1 is for mmc0, 
but mmc0 depends on your device tree definition"?) but I guess this 
mapping would make sense. We need to keep the current implementation 
though, in order to support SPL without CONFIG_SPL_DM_SEQ_ALIAS enabled.


There's also no BOOT_DEVICE_MMC3 but that could be added pretty easily I 
guess. I assume you'd need a new entry in spl_mmc_get_device_index too.



Also on upstream kernel eMMC is mmc0 and SD mmc1 (somewhat consistently
with the above), while on downstream kernel it seems these are mmc1 and
mmc2, respectively.



I'm afraid that will not be the only discrepancy you'll stumble upon 
between upstream and downstream.


Cheers,
Quentin

Re: [RESEND v9 4/9] menu: add KEY_PLUS and KEY_MINUS handling

On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima
 wrote:
>
> This is preparation to support menu-driven UEFI BootOrder
> variable updated by KEY_PLUS and KEY_MINUS.
>
> Signed-off-by: Masahisa Kojima 
> Reviewed-by: Heinrich Schuchardt 
> ---
> No change since v7
>
> Newly created in v7
>
>  common/menu.c  | 6 ++
>  include/menu.h | 2 ++
>  2 files changed, 8 insertions(+)
>
> diff --git a/common/menu.c b/common/menu.c
> index 3e876b55b3..3470f95a98 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -548,4 +548,10 @@ void bootmenu_loop(struct bootmenu_data *menu,
> /* ^C was pressed */
> if (c == 0x3)
> *key = KEY_QUIT;
> +
> +   if (c == '+')
> +   *key = KEY_PLUS;
> +
> +   if (c == '-')
> +   *key = KEY_MINUS;
>  }
> diff --git a/include/menu.h b/include/menu.h
> index e74616cae8..4c32e74ce9 100644
> --- a/include/menu.h
> +++ b/include/menu.h
> @@ -48,6 +48,8 @@ enum bootmenu_key {
> KEY_DOWN,
> KEY_SELECT,
> KEY_QUIT,
> +   KEY_PLUS,
> +   KEY_MINUS,
>  };
>
>  void bootmenu_autoboot_loop(struct bootmenu_data *menu,
> --
> 2.17.1
>

Reviewed-by: Ilias Apalodimas

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

On Thu, Jul 14, 2022 at 04:21:57AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 13 Jul 2022 at 12:21, Tom Rini  wrote:
> >
> > On Wed, Jul 13, 2022 at 09:28:06AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 12 Jul 2022 at 15:38, Tom Rini  wrote:
> > > >
> > > > On Mon, Jul 11, 2022 at 07:04:04PM -0600, Simon Glass wrote:
> > > > > Bring this tool into buildman, so we don't have to run it separately. 
> > > > > The
> > > > > board.cfg file is still produced as part of the build, to save time 
> > > > > when
> > > > > doing another build in the same working directory. If it is out of 
> > > > > date
> > > > > with respect to the Kconfig, it is updated.
> > > > >
> > > > > Time to regenerate on a recent single-thread machine is 4.6s (1.3s on 
> > > > > a
> > > > > 32-thread machine), so we do need some sort of cache if we want 
> > > > > buildman
> > > > > to be useful on incremental builds. We could use Python's pickle 
> > > > > format
> > > > > but:
> > > > >
> > > > > - it seems useful to allow boards.cfg to be regenerated, at least for 
> > > > > a
> > > > >   while, in case other tools use it
> > > > > - it is possible to grep the file easily, e.g. to find boards which 
> > > > > use
> > > > >   a particular SoC (similar to 'buildman -nv '
> > > >
> > > > While I don't think other tools still use boards.cfg, this will make it
> > > > easier to find out that I'm wrong.  Perhaps once the CONFIG to Kconfig
> > > > migration is done we can move to just pickle'ing the data or similar
> > > > since I find the main use of what was in boards.cfg can be figured out
> > > > with some other git grep'ing, and in turn that's mainly for me when
> > > > trying to convert stuff.  Thanks for doing this.
> > >
> > > Yes. I'm excited to hear that Kconfig migration might be done - any
> > > forecast as to when?
> >
> > Not yet.  I'm auditing CONFIG_SYS_* now, with a notion to move
> > everything that's not really configurable just out of CONFIG namespace
> > as the starting point.  That'll drop us down to ~500 to migrate, which
> > feels a bit less daunting.
> >
> > > One thing we could to is provide an option for buildman to spit out
> > > the various fields that go into boards.cfg
> >
> > Right.  So I might not have said this before, but one reason I wanted
> > buildman to natively know kconfiglib and have everything was that while
> > we can do a lot of good matching on what to build, it would be amazingly
> > good to be able to say "build every platform with NVME_PCI set" (and if
> > it's not too hard hex/int options with a specific value).
> 
> Ah OK. At present moveconfig has the functionality to list the boards
> that have particular options (-b and -f). It is expensive to build the
> database though - over a minute on a 32-thread machine. So we would
> have to cache it. Also just about any change would invalidate the
> cache and I'm not sure if it possible to detect which changes have no
> effect on which cache entries...

Ah, maybe it will take some more thinking about then.  Maybe an
"advanced" match option, and also seeing how to have Azure generate the db
in one job and pass it as an artifact to every other job in the world
build stage.  Not an immediate need.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] spl: Use SPL_TEXT_BASE instead of ISW_ENTRY_ADDR

On Fri, Jul 15, 2022 at 12:31:48PM -0500, Andrew Davis wrote:

> The ISW_ENTRY_ADDR symbol was used for OMAP devices in place of
> SPL_TEXT_BASE. Keystone2 HS devices were not using it right either.
> Remove ISW_ENTRY_ADDR and use SPL_TEXT_BASE directly.
> 
> Signed-off-by: Andrew Davis 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/4] arm: mach-k3: security: Remove certificate if detected on GP device

On Fri, Jul 15, 2022 at 11:34:35AM -0500, Andrew Davis wrote:

> If the device is a GP and we detect a signing certificate then remove it.
> It would fail to authenticate otherwise as the device is GP and has no
> secure authentication services in SYSFW.
> 
> This shouldn't happen often as trying to boot signed images on GP devices
> doesn't make much sense, but if we run into a signed image we should at
> least try to ignore the certificate and boot the image anyway. This could
> help with users of GP devices who only have HS images available.
> 
> If this does happen, print a nice big warning.
> 
> Signed-off-by: Andrew Davis 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/4] arm: mach-k3: Add support for device type detection

On Fri, Jul 15, 2022 at 11:34:32AM -0500, Andrew Davis wrote:

> K3 SoCs are available in a number of device types such as
> GP, HS-FS, EMU, etc. Like OMAP SoCs we can detect this at runtime
> and should print this out as part of the SoC information line.
> We add this as part of the common.c file as it will be used
> to also modify our security state early in the device boot.
> 
> Signed-off-by: Andrew Davis 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: mach-k3: Remove ROM firewalls on GP devices

On Fri, Jul 15, 2022 at 11:21:27AM -0500, Andrew Davis wrote:

> This isn't strictly needed as these firewalls should all be disabled on
> GP, but it also doesn't hurt, so do this unconditionally to remove this
> use of CONFIG_TI_SECURE_DEVICE.
> 
> Signed-off-by: Andrew Davis 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] spl: Move check for SPL_LIBCOMMON support to header

On Fri, Jul 15, 2022 at 10:35:00AM -0500, Andrew Davis wrote:

> From: "Andrew F. Davis" 
> 
> Print statements in SPL depend on lib/common support, due to this many
> such print statements are ifdef'd. Instead of checking at each call site
> move the check to the common.h header and remove these inline checks.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Simon Glass 

I thought we had this already, but I guess not.  That said:

[snip]
> diff --git a/include/stdio.h b/include/stdio.h
> index 1939a48f0f..2fbc3da5f9 100644
> --- a/include/stdio.h
> +++ b/include/stdio.h
> @@ -10,9 +10,8 @@ int tstc(void);
>  
>  /* stdout */
>  #if !defined(CONFIG_SPL_BUILD) || \
> - (defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_SERIAL)) || \
> - (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) && \
> - defined(CONFIG_SPL_SERIAL))
> + (defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_SERIAL) && 
> defined(CONFIG_TPL_LIBCOMMON_SUPPORT)) || \
> + (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_SERIAL) && 
> defined(CONFIG_SPL_LIBCOMMON_SUPPORT) && !defined(CONFIG_TPL_BUILD))

Can we write this as something like:
#if !defined(CONFIG_SPL_BUILD) || \
(CONFIG_IS_ENABLED(BUILD) && CONFIG_IS_ENABLED(SERIAL) &&
CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT))

?  I'm not 100% sure it will work for CONFIG_SPL_BUILD /
CONFIG_TPL_BUILD but it should for the rest and mean we can slightly
clean it up.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] arm: mach-k3: Rename SOC_K3_AM6 to SOC_K3_AM654

On Fri, Jul 15, 2022 at 10:25:27AM -0500, Andrew Davis wrote:

> The first AM6x device was the AM654x, but being the first we named it
> just AM6, since more devices have come out with this same prefix we
> should switch it to the normal convention of using the full name of the
> first compatibility device the series. This makes what device we are
> talking about more clear and matches all the K3 devices added since.
> 
> Signed-off-by: Andrew Davis 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] arm: mach-k3: Only build init files for SPL

On Fri, Jul 15, 2022 at 10:25:26AM -0500, Andrew Davis wrote:

> The content of these files are only used in SPL builds. The contents are
> already ifdef for the same, remove that and only include the whole file
> in the build when building for SPL.
> 
> Signed-off-by: Andrew Davis 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper

On Mon, Jul 18, 2022 at 11:09:56AM +0200, Xavier Drudis Ferran wrote:
> El Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz deia:
> > Hi Xavier,
> > 
> > On 7/15/22 18:30, Xavier Drudis Ferran wrote:
> > > Spi0 is not needed in SPL and SPL could be a little smaller without it,
> > > but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
> > > that's confusing, because once U-Boot proper runs, it numbers the bus 1.
> > > 
> > > Add spi0 to the pre-reloc and spl trees so that the flash is always
> > > connected to bus 1.
> > > 
> > 
> > Mmmm... Could we instead make U-Boot use the bus number from the alias in
> > the aliases DT node? I think the mmc subsystem does this already and it
> > would mean we don't need to enable unnecessary devices. Also, relying on
> > boot order for the bus number is brittle in Linux, I don't know about
> > U-Boot, but if we can avoid this assumption, it'd be great :)
> > 
> > See: 
> > https://source.denx.de/u-boot/u-boot/-/commit/2243d19e5618122d9d7aba23eb51f63f2719dba5
> > for how to do it today?
> >
> 
> Maybe I should just drop this patch and try to define
> CONFIG_SPL_DM_SEQ_ALIAS in configs/rock-pi-4-rk3399 instead ?
> Let me test this a little...
> 
> I have CONFIG_DM_SEQ_ALIAS=y but   CONFIG_SPL_DM_SEQ_ALIAS unset. 
> 
> > 
> > Your patch series got sent with each commit in their individual thread
> 
> I know. Sorry for the lapsus. I did it right in v1, wrong in v2, and will do 
> right in v3. 

What is actually the correct naming here?

We have in arch/arm/mach-rockchip/rk3399/rk3399.c

const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
[BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe32",
};

} spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe32" },
{ BOOT_DEVICE_MMC2, "/sdhci@fe33" },
{ BOOT_DEVICE_SPI, "/spi@ff1d" },
};

which then presumably gets converted in common/spl/spl_mmc.c

SPL_LOAD_IMAGE_METHOD("MMC1", 0, BOOT_DEVICE_MMC1, spl_mmc_load_image);
SPL_LOAD_IMAGE_METHOD("MMC2", 0, BOOT_DEVICE_MMC2, spl_mmc_load_image);
SPL_LOAD_IMAGE_METHOD("MMC2_2", 0, BOOT_DEVICE_MMC2_2, spl_mmc_load_image);

We then have this in rk3399.dtsi:

sdio0: mmc@fe31 {
compatible = "rockchip,rk3399-dw-mshc",

sdmmc: mmc@fe32 {
compatible = "rockchip,rk3399-dw-mshc",

sdhci: mmc@fe33 {
compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";

and this in rk3399-u-boot.dtsi

mmc0 = &sdhci;
mmc1 = &sdmmc;

and this in arch/arm/dts/rk3399-pinebook-pro.dts

aliases {
mmc0 = &sdio0;
mmc1 = &sdmmc;
mmc2 = &sdhci;
};


mmc@fe31: 3
mmc@fe32: 1 (SD)
mmc@fe33: 0 (eMMC)

This is not consistent with any of the above.

Also on upstream kernel eMMC is mmc0 and SD mmc1 (somewhat consistently
with the above), while on downstream kernel it seems these are mmc1 and
mmc2, respectively.

Thanks

Michal

Re: [PATCH] sunxi-nand: fix the PIO instead of DMA implementation

On Thu, 30 Jun 2022 01:26:39 +0200
Markus Hoffrogge  wrote:

Hi,

> The sunxi nand SPL loader was broken at least for SUN4I,
> SUN5I and SUN7I SOCs since the implementation change
> from DMA to PIO usage - commit 6ddbb1e.
> 
> Root cause for this issue is the NFC control flag NFC_CTL_RAM_METHOD
> being set by method nand_apply_config.
> 
> This flag controls the bus being used for the NFCs internal RAM access.
> It must be set for the DMA use case only.
> See A33_Nand_Flash_Controller_Specification.pdf page 12.
> 
> This fix is tested by myself on a Cubietruck A20 board.
> Others should test it on new generation SOCs as well.

I can't really test this, but looking at the datasheet indeed bit 14 must
not be set when we intend to read the SRAM buffers directly via MMIO.

> Signed-off-by: Markus Hoffrogge 

Reviewed-by: Andre Przywara 

Applied to sunxi/master.

Cheers,
Andre

> ---
>  drivers/mtd/nand/raw/sunxi_nand_spl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/sunxi_nand_spl.c
> b/drivers/mtd/nand/raw/sunxi_nand_spl.c
> index a29a76c58d..6de0b0a355 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand_spl.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand_spl.c
> @@ -208,7 +208,7 @@ static void nand_apply_config(const struct nfc_config
> *conf)
> 
>   val = readl(SUNXI_NFC_BASE + NFC_CTL);
>   val &= ~NFC_CTL_PAGE_SIZE_MASK;
> - writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
> + writel(val | NFC_CTL_PAGE_SIZE(conf->page_size),
> SUNXI_NFC_BASE + NFC_CTL);
>   writel(conf->ecc_size, SUNXI_NFC_BASE + NFC_CNT);
>   writel(conf->page_size, SUNXI_NFC_BASE + NFC_SPARE_AREA);
> --

Re: [PATCH] arm: mvebu: turris_omnia: Set ETHPRIME to DT alias


On 15.07.22 10:16, Pali Rohár wrote:

CONFIG_ETHPRIME can be set to DT node name or alias which refers to DT
node. Define ethernet aliases and set ETHPRIME to eth2 which refers to WAN
ethernet port. This removes hardcoded DT node name from U-Boot
configuration file.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/dts/armada-385-turris-omnia.dts | 6 ++
  configs/turris_omnia_defconfig   | 2 +-
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/armada-385-turris-omnia.dts 
b/arch/arm/dts/armada-385-turris-omnia.dts
index 5511c84849ee..7f1478edfd23 100644
--- a/arch/arm/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/dts/armada-385-turris-omnia.dts
@@ -55,6 +55,12 @@
stdout-path = &uart0;
};
  
+	aliases {

+   ethernet0 = ð0;
+   ethernet1 = ð1;
+   ethernet2 = ð2;
+   };
+
memory {
device_type = "memory";
reg = <0x 0x4000>; /* 1024 MB */
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 6460535ef94e..e2a0449b487b 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -65,7 +65,7 @@ CONFIG_CMD_FS_UUID=y
  CONFIG_ENV_OVERWRITE=y
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
  CONFIG_USE_ETHPRIME=y
-CONFIG_ETHPRIME="ethernet@34000"
+CONFIG_ETHPRIME="eth2"
  CONFIG_ARP_TIMEOUT=200
  CONFIG_NET_RETRY_COUNT=50
  CONFIG_NETCONSOLE=y


Viele Grüße,
Stefan Roese

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

Re: [PATCH] arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times


On 15.07.22 10:13, Pali Rohár wrote:

Change detection of platform/cpu from runtime to compile time via config
define. This completely eliminates compiling code which is not going to run
on selected platform. Code which parses and prints device / revision id
still reads device id from MVEBU_REG_PCIE_DEVID register, but only once.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan



---
  arch/arm/mach-mvebu/cpu.c  | 67 ++
  arch/arm/mach-mvebu/dram.c | 18 +++
  arch/arm/mach-mvebu/include/mach/cpu.h |  9 
  3 files changed, 32 insertions(+), 62 deletions(-)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 173d95a760a3..1457af1d6aa3 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -54,33 +54,6 @@ void reset_cpu(void)
;
  }
  
-int mvebu_soc_family(void)

-{
-   u16 devid = (readl(MVEBU_REG_PCIE_DEVID) >> 16) & 0x;
-
-   switch (devid) {
-   case SOC_MV78230_ID:
-   case SOC_MV78260_ID:
-   case SOC_MV78460_ID:
-   return MVEBU_SOC_AXP;
-
-   case SOC_88F6720_ID:
-   return MVEBU_SOC_A375;
-
-   case SOC_88F6810_ID:
-   case SOC_88F6820_ID:
-   case SOC_88F6828_ID:
-   return MVEBU_SOC_A38X;
-
-   case SOC_98DX3236_ID:
-   case SOC_98DX3336_ID:
-   case SOC_98DX4251_ID:
-   return MVEBU_SOC_MSYS;
-   }
-
-   return MVEBU_SOC_UNKNOWN;
-}
-
  u32 get_boot_device(void)
  {
u32 val;
@@ -305,7 +278,10 @@ int print_cpuinfo(void)
break;
}
  
-	if (mvebu_soc_family() == MVEBU_SOC_AXP) {

+   switch (devid) {
+   case SOC_MV78230_ID:
+   case SOC_MV78260_ID:
+   case SOC_MV78460_ID:
switch (revid) {
case 1:
puts("A0");
@@ -317,9 +293,9 @@ int print_cpuinfo(void)
printf("?? (%x)", revid);
break;
}
-   }
+   break;
  
-	if (mvebu_soc_family() == MVEBU_SOC_A375) {

+   case SOC_88F6720_ID:
switch (revid) {
case MV_88F67XX_A0_ID:
puts("A0");
@@ -328,9 +304,11 @@ int print_cpuinfo(void)
printf("?? (%x)", revid);
break;
}
-   }
+   break;
  
-	if (mvebu_soc_family() == MVEBU_SOC_A38X) {

+   case SOC_88F6810_ID:
+   case SOC_88F6820_ID:
+   case SOC_88F6828_ID:
switch (revid) {
case MV_88F68XX_Z1_ID:
puts("Z1");
@@ -345,9 +323,11 @@ int print_cpuinfo(void)
printf("?? (%x)", revid);
break;
}
-   }
+   break;
  
-	if (mvebu_soc_family() == MVEBU_SOC_MSYS) {

+   case SOC_98DX3236_ID:
+   case SOC_98DX3336_ID:
+   case SOC_98DX4251_ID:
switch (revid) {
case 3:
puts("A0");
@@ -359,6 +339,11 @@ int print_cpuinfo(void)
printf("?? (%x)", revid);
break;
}
+   break;
+
+   default:
+   printf("?? (%x)", revid);
+   break;
}
  
  	get_sar_freq(&sar_freq);

@@ -463,7 +448,7 @@ int arch_cpu_init(void)
struct pl310_regs *const pl310 =
(struct pl310_regs *)CONFIG_SYS_PL310_BASE;
  
-	if (mvebu_soc_family() == MVEBU_SOC_A38X) {

+   if (IS_ENABLED(CONFIG_ARMADA_38X)) {
/*
 * To fully release / unlock this area from cache, we need
 * to flush all caches and disable the L2 cache.
@@ -492,7 +477,7 @@ int arch_cpu_init(void)
 */
mvebu_mbus_probe(NULL, 0);
  
-	if (mvebu_soc_family() == MVEBU_SOC_AXP) {

+   if (IS_ENABLED(CONFIG_ARMADA_XP)) {
/*
 * Now the SDRAM access windows can be reconfigured using
 * the information in the SDRAM scratch pad registers
@@ -506,7 +491,7 @@ int arch_cpu_init(void)
 */
mvebu_mbus_probe(windows, ARRAY_SIZE(windows));
  
-	if (mvebu_soc_family() == MVEBU_SOC_AXP) {

+   if (IS_ENABLED(CONFIG_ARMADA_XP)) {
/* Enable GBE0, GBE1, LCD and NFC PUP */
clrsetbits_le32(ARMADA_XP_PUP_ENABLE, 0,
GE0_PUP_EN | GE1_PUP_EN | LCD_PUP_EN |
@@ -530,9 +515,9 @@ u32 mvebu_get_nand_clock(void)
  {
u32 reg;
  
-	if (mvebu_soc_family() == MVEBU_SOC_A38X)

+   if (IS_ENABLED(CONFIG_ARMADA_38X))
reg = MVEBU_DFX_DIV_CLK_CTRL(1);
-   else if (mvebu_soc_family() == MVEBU_SOC_MSYS)
+   else if (IS_ENABLED(CONFIG_ARMADA_MSYS))
reg = MVEBU_DFX_DIV_CLK_CTRL(8);
else
reg = MVEBU_CORE_DIV_CLK_CTRL(1);
@@ -678,7 +663,7 @@ void enable_caches(void)
 *

Re: [PATCH sunxi/next] spi: sunxi: use XCH status to detect in-progress transfer

On Tue, 28 Jun 2022 14:49:24 +0800
Icenowy Zheng  wrote:

Hi Icenowy,

many thanks for the patch!

> The current detection of RX FIFO depth seems to be not reliable, and
> XCH will self-clear when a transfer is done.
> 
> Check XCH bit when polling for transfer finish.

So as mentioned in the other reply, there are still issues in the SPI
driver, some problems being more general.
However this patch looks right, and seems like the more robust solution
than counting bytes in the FIFO, so I will take it.

> Signed-off-by: Icenowy Zheng 

Reviewed-by: Andre Przywara 

Applied to sunxi/master.

Thanks,
Andre

> ---
>  drivers/spi/spi-sunxi.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
> index 2f7725..a424c6a98e 100644
> --- a/drivers/spi/spi-sunxi.c
> +++ b/drivers/spi/spi-sunxi.c
> @@ -83,7 +83,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #endif
>  #define SUN4I_SPI_MIN_RATE   3000
>  #define SUN4I_SPI_DEFAULT_RATE   100
> -#define SUN4I_SPI_TIMEOUT_US 100
> +#define SUN4I_SPI_TIMEOUT_MS 1000
>  
>  #define SPI_REG(priv, reg)   ((priv)->base + \
>   (priv)->variant->regs[reg])
> @@ -326,7 +326,6 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   struct dm_spi_slave_plat *slave_plat = dev_get_parent_plat(dev);
>  
>   u32 len = bitlen / 8;
> - u32 rx_fifocnt;
>   u8 nbytes;
>   int ret;
>  
> @@ -364,13 +363,10 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   setbits_le32(SPI_REG(priv, SPI_TCR),
>SPI_BIT(priv, SPI_TCR_XCH));
>  
> - /* Wait till RX FIFO to be empty */
> - ret = readl_poll_timeout(SPI_REG(priv, SPI_FSR),
> -  rx_fifocnt,
> -  (((rx_fifocnt &
> -  SPI_BIT(priv, SPI_FSR_RF_CNT_MASK)) >>
> -  SUN4I_FIFO_STA_RF_CNT_BITS) >= nbytes),
> -  SUN4I_SPI_TIMEOUT_US);
> + /* Wait for the transfer to be done */
> + ret = wait_for_bit_le32((const void *)SPI_REG(priv, SPI_TCR),
> + SPI_BIT(priv, SPI_TCR_XCH),
> + false, SUN4I_SPI_TIMEOUT_MS, false);
>   if (ret < 0) {
>   printf("ERROR: sun4i_spi: Timeout transferring data\n");
>   sun4i_spi_set_cs(bus, slave_plat->cs, false);

Re: [PATCH v1] drivers: spi: sunxi: Fix spi speed settting

On Sat, 2 Jul 2022 16:20:37 +0800
qianfan  wrote:

Hi Qianfan,

again our mailserver dropped this email, so sorry for the delay!

> 在 2022/7/2 15:50, qianfan 写道:
> >
> >
> > 在 2022/7/2 11:09, qianfan 写道:  
> >>
> >>
> >> 在 2022/6/28 8:34, Andre Przywara 写道:  
> >>> On Thu,  9 Jun 2022 17:09:39 +0800
> >>> qianfangui...@163.com wrote:
> >>>
> >>> Hi Qianfan,
> >>>  
>  From: qianfan Zhao 
> 
>  dm_spi_claim_bus run spi_set_speed_mode first and then ops->claim_bus,
>  but spi clock is enabled when sun4i_spi_claim_bus, that will make
>  sun4i_spi_set_speed doesn't work.  
> >>> Thanks for bringing this up, and sorry for the delay (please CC: the
> >>> U-Boot sunxi maintainers!).
> >>> So this is very similar to the patch as I sent earlier:
> >>> https://lore.kernel.org/u-boot/20220503212040.27884-3-andre.przyw...@arm.com/
> >>>  
> >>>
> >>>
> >>> Can you please check whether this works for you as well, then reply to
> >>> that patch?
> >>> I put my version of the patch plus more fixes and F1C100s support to:
> >>> https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/
> >>>
> >>> Also I am curious under what circumstances and on what board you saw 
> >>> the
> >>> issue? In my case it was on the F1C100s, which has a higher base clock
> >>> (200 MHz instead of 24 MHz), so everything gets badly overclocked.  
> >> I tested based on those two commits:
> >>
> >> spi: sunxi: refactor SPI speed/mode programming
> >> spi: sunxi: improve SPI clock calculation
> >>
> >> And there are a couple of questions:
> >>
> >> 1. sun4i_spi_of_to_plat try reading "spi-max-frequency" from the spi 
> >> bus node:
> >>
> >> static int sun4i_spi_of_to_plat(struct udevice *bus)
> >> {
> >>     struct sun4i_spi_plat *plat = dev_get_plat(bus);
> >>     int node = dev_of_offset(bus);
> >>
> >>     plat->base = dev_read_addr(bus);
> >>     plat->variant = (struct sun4i_spi_variant 
> >> *)dev_get_driver_data(bus);
> >>     plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
> >>               "spi-max-frequency",
> >>               SUN4I_SPI_DEFAULT_RATE);
> >>
> >>     if (plat->max_hz > SUN4I_SPI_MAX_RATE)
> >>     plat->max_hz = SUN4I_SPI_MAX_RATE;
> >>
> >>     return 0;
> >> }
> >>
> >> Seems this is not a correct way. "spi-max-frequency" should reading 
> >> from spi device,
> >> not spi bus. On my dts, no "spi-max-frequency" prop on spi bus node, 
> >> this will make
> >> plat->max_hz has default SUN4I_SPI_DEFAULT_RATE(1M) value.
> >>
> >> &spi2 {
> >>     pinctrl-names = "default";
> >>     pinctrl-0 = <&spi2_cs0_pb_pin &spi2_pb_pins>;
> >>     status = "okay";
> >>
> >>     lcd@0 {
> >>     compatible = "sitronix,st75161";
> >>     spi-max-frequency = <1200>;
> >>     reg = <0>;
> >>     spi-cpol;
> >>     spi-cpha;
> >>
> >> So on my patch, I had changed the default plat->max_hz to 
> >> SUN4I_SPI_MAX_RATE.
> >>
> >> 2. When I changed the default plat->max_hz to SUN4I_SPI_MAX_RATE:
> >>
> >> 2.1: sun4i_spi_set_speed_mode doesn't consider when div = 1(freq = 
> >> SUNXI_INPUT_CLOCK),
> >> the spi running in 12M even if the spi-max-frequency is setted to 24M.
> >>
> >> 2.2: on my R40 based board, spi can't work when the spi clock <= 6M.
> >> I had check the CCR register, the value is correct, from logic analyzer
> >> only the first byte is sent. Next is the serial console logs:
> >>
> >> spi clock = 6M:
> >> CCR: 1001
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ...
> >>
> >> spi clock = 4M:
> >> CCR: 1002
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ERROR: sun4i_spi: Timeout transferring data
> >> ...  
> > Add udelay(1) before sun4i_spi_drain_fifo in sun4i_spi_xfer can fix it.
> > But I don't know why.  
> >>  
> >>>
> >>> Thanks!
> >>> Andre
> >>>  
>  Fix it.
> 
>  Signed-off-by: qianfan Zhao 
>  ---
>    drivers/spi/spi-sunxi.c | 78 
>  -
>    1 file changed, 30 insertions(+), 48 deletions(-)
> 
>  diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
>  index b6cd7ddafa..1043cde976 100644
>  --- a/drivers/spi/spi-sunxi.c
>  +++ b/drivers/spi/spi-sunxi.c
>  @@ -224,6 +224,7 @@ err_ahb:
>    static int sun4i_spi_claim_bus(struct udevice *dev)
>    {
>    struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
>  +    u32 div, reg;
>    int ret;
>      ret = sun4i_spi_set_clock(dev->parent, true);
>  @@ -233,12 +234,38 @@ static int sun4i_spi_claim_bus(struct udevice 
>  *dev)
>    setbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE |
>     SUN4I_CTL_MASTER | SPI_BIT(priv, SPI_GCR_TP));
>    +    /* Setup clock d

Re: [PATCH v1] drivers: spi: sunxi: Fix spi speed settting

On Sat, 2 Jul 2022 11:09:37 +0800
qianfan  wrote:

Hi Qianfan,

I am sorry for the late reply, our mailserver apparently always filters
your email, so I just found your answer by browsing through patchwork.

Anyway, many thanks for answering, and your testing and observations are all
very good! (and sadly true ;-)

Answers inline below:

> 在 2022/6/28 8:34, Andre Przywara 写道:
> > On Thu,  9 Jun 2022 17:09:39 +0800
> > qianfangui...@163.com wrote:
> >
> > Hi Qianfan,
> >  
> >> From: qianfan Zhao 
> >>
> >> dm_spi_claim_bus run spi_set_speed_mode first and then ops->claim_bus,
> >> but spi clock is enabled when sun4i_spi_claim_bus, that will make
> >> sun4i_spi_set_speed doesn't work.  
> > Thanks for bringing this up, and sorry for the delay (please CC: the
> > U-Boot sunxi maintainers!).
> > So this is very similar to the patch as I sent earlier:
> > https://lore.kernel.org/u-boot/20220503212040.27884-3-andre.przyw...@arm.com/
> >
> > Can you please check whether this works for you as well, then reply to
> > that patch?
> > I put my version of the patch plus more fixes and F1C100s support to:
> > https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/
> >
> > Also I am curious under what circumstances and on what board you saw the
> > issue? In my case it was on the F1C100s, which has a higher base clock
> > (200 MHz instead of 24 MHz), so everything gets badly overclocked.  
> I tested based on those two commits:
> 
> spi: sunxi: refactor SPI speed/mode programming
> spi: sunxi: improve SPI clock calculation
> 
> And there are a couple of questions:
> 
> 1. sun4i_spi_of_to_plat try reading "spi-max-frequency" from the spi bus 
> node:

Yes, indeed, that's broken. I found this myself the other day, when trying
to debug the other issue.
I asked about this here:
https://lore.kernel.org/u-boot/20220711165215.218e2...@donnerap.cambridge.arm.com/

> static int sun4i_spi_of_to_plat(struct udevice *bus)
> {
>      struct sun4i_spi_plat *plat = dev_get_plat(bus);
>      int node = dev_of_offset(bus);
> 
>      plat->base = dev_read_addr(bus);
>      plat->variant = (struct sun4i_spi_variant *)dev_get_driver_data(bus);
>      plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
>                "spi-max-frequency",
>                SUN4I_SPI_DEFAULT_RATE);
> 
>      if (plat->max_hz > SUN4I_SPI_MAX_RATE)
>      plat->max_hz = SUN4I_SPI_MAX_RATE;
> 
>      return 0;
> }
> 
> Seems this is not a correct way. "spi-max-frequency" should reading from 
> spi device,
> not spi bus. On my dts, no "spi-max-frequency" prop on spi bus node, 
> this will make
> plat->max_hz has default SUN4I_SPI_DEFAULT_RATE(1M) value.
> 
> &spi2 {
>      pinctrl-names = "default";
>      pinctrl-0 = <&spi2_cs0_pb_pin &spi2_pb_pins>;
>      status = "okay";
> 
>      lcd@0 {
>      compatible = "sitronix,st75161";
>      spi-max-frequency = <1200>;
>      reg = <0>;
>      spi-cpol;
>      spi-cpha;
> fdtdec_get_int
> So on my patch, I had changed the default plat->max_hz to 
> SUN4I_SPI_MAX_RATE.

Indeed, I did something very similar: remove that fdtdec_get_int() call
above and use the the max clock rate.
I will send a patch to that effect later, unless you beat me to it.

> 2. When I changed the default plat->max_hz to SUN4I_SPI_MAX_RATE:
> 
> 2.1: sun4i_spi_set_speed_mode doesn't consider when div = 1(freq = 
> SUNXI_INPUT_CLOCK),
> the spi running in 12M even if the spi-max-frequency is setted to 24M.
> 
> 2.2: on my R40 based board, spi can't work when the spi clock <= 6M.
> I had check the CCR register, the value is correct, from logic analyzer
> only the first byte is sent. Next is the serial console logs:
> 
> spi clock = 6M:
> CCR: 1001
> ERROR: sun4i_spi: Timeout transferring data
> ERROR: sun4i_spi: Timeout transferring data
> ERROR: sun4i_spi: Timeout transferring data
> ...
> 
> spi clock = 4M:
> CCR: 1002
> ERROR: sun4i_spi: Timeout transferring data
> ERROR: sun4i_spi: Timeout transferring data
> ERROR: sun4i_spi: Timeout transferring data
> ERROR: sun4i_spi: Timeout transferring data
> ERROR: sun4i_spi: Timeout transferring data

Yes, I have seen this as well: With the now 1 MHz clock, for some odd
reasons there is only one byte sent out. I don't have fancy measurement
tools, but this is what the FIFO register told me.

As you figured yourself (in the other mail), checking the XCH bit fixes
this problem, but it is unclear why, since the trigger sequence is the
same. I replied there.

Cheers,
Andre

> >
> > Thanks!
> > Andre
> >  
> >> Fix it.
> >>
> >> Signed-off-by: qianfan Zhao 
> >> ---
> >>   drivers/spi/spi-sunxi.c | 78 -
> >>   1 file changed, 30 insertions(+), 48 deletions(-)
> >>
> >> diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
> >> index b6cd7ddafa..1043cde976 100644
> >> --- a/drivers/spi/spi-sunxi.c
> >> +++ b/drivers/spi/spi-sunxi.c
> >> @@ -224,6 +224,7 @@ err_ahb:
> >>   static int sun4i_spi_c

Re: [PATCH 2/7] spi: sunxi: refactor SPI speed/mode programming

On Mon, 27 Jun 2022 23:43:25 -0400
Jesse Taube  wrote:

Hi Jesse,

> On 6/27/22 20:31, Andre Przywara wrote:
> > On Tue,  3 May 2022 22:20:35 +0100
> > Andre Przywara  wrote:
> > 
> > Hi,
> >   
> >> As George rightfully pointed out [1], the spi-sunxi driver programs the
> >> speed and mode settings only when the respective functions are called,
> >> but this gets lost over a call to release_bus(). That asserts the
> >> reset line, thus forces each SPI register back to its default value.
> >> Adding to that, trying to program SPI_CCR and SPI_TCR might be pointless
> >> in the first place, when the reset line is still asserted (before
> >> claim_bus()), so those setting won't apply most of the time. In reality
> >> I see two nested claim_bus() calls for the first use, so settings between
> >> the two would work (for instance for the initial "sf probe"). However
> >> later on the speed setting is not programmed into the hardware anymore.  
> > 
> > So this issue was addressed with patches by both George (earlier, in a
> > different way) and Qianfan (later, in a very similar way).
> > 
> > Can someone (Jagan?) please have a look at this change from the U-Boot
> > SPI perspective? And also the other changes in this series?
> > I pushed them to the sunxi/next branch:
> > https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/
> > 
> > So can people please test this and report whether this now works as
> > expected?  
> 
> I'm very confused I have forgotten much about this patch set.
> I'm going to test it, but why has it only been merged now?

Because no one reviewed it, or even replied to it - hence my email. And
apparently it was even broken.
The code quality in U-Boot is not really great, as the problems fixed with
this series and the other problems emerged lately ([1]) demonstrate. So I
am very reluctant to take any patches without a meaningful review, or at
least without confirmation of their functionality - regardless of the
author. For instance I just found a bug in my patch 4/7 ...

And I didn't really merge them yet, I just pushed them to the sunxi/next
branch, to expose them more widely and encourage testing - which
apparently worked out as planned ;-)

Cheers,
Andre

[1]
https://lore.kernel.org/u-boot/20220711165215.218e2...@donnerap.cambridge.arm.com/

> >> So far we get away with that default frequency, because that is a rather
> >> tame 24 MHz, which most SPI flash chips can handle just fine.
> >>
> >> Move the actual register programming into a separate function, and use
> >> .set_speed and .set_mode just to set the variables in our priv structure.
> >> Then we only call this new function in claim_bus(), when we are sure
> >> that register accesses actually work and are preserved.
> >>
> >> [1] https://lore.kernel.org/u-boot/20210725231636.879913-17...@yifangu.com/
> >>
> >> Signed-off-by: Andre Przywara 
> >> Reported-by: George Hilliard 
> >> ---
> >>   drivers/spi/spi-sunxi.c | 95 ++---
> >>   1 file changed, 52 insertions(+), 43 deletions(-)
> >>
> >> diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
> >> index b6cd7ddafad..d6b2dd09514 100644
> >> --- a/drivers/spi/spi-sunxi.c
> >> +++ b/drivers/spi/spi-sunxi.c
> >> @@ -221,6 +221,56 @@ err_ahb:
> >>return ret;
> >>   }
> >>   
> >> +static void sun4i_spi_set_speed_mode(struct udevice *dev)
> >> +{
> >> +  struct sun4i_spi_priv *priv = dev_get_priv(dev);
> >> +  unsigned int div;
> >> +  u32 reg;
> >> +
> >> +  /*
> >> +   * Setup clock divider.
> >> +   *
> >> +   * We have two choices there. Either we can use the clock
> >> +   * divide rate 1, which is calculated thanks to this formula:
> >> +   * SPI_CLK = MOD_CLK / (2 ^ (cdr + 1))
> >> +   * Or we can use CDR2, which is calculated with the formula:
> >> +   * SPI_CLK = MOD_CLK / (2 * (cdr + 1))
> >> +   * Whether we use the former or the latter is set through the
> >> +   * DRS bit.
> >> +   *
> >> +   * First try CDR2, and if we can't reach the expected
> >> +   * frequency, fall back to CDR1.
> >> +   */
> >> +
> >> +  div = SUN4I_SPI_MAX_RATE / (2 * priv->freq);
> >> +  reg = readl(SPI_REG(priv, SPI_CCR));
> >> +
> >> +  if (div <= (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
> >> +  if (div > 0)
> >> +  div--;
> >> +
> >> +  reg &= ~(SUN4I_CLK_CTL_CDR2_MASK | SUN4I_CLK_CTL_DRS);
> >> +  reg |= SUN4I_CLK_CTL_CDR2(div) | SUN4I_CLK_CTL_DRS;
> >> +  } else {
> >> +  div = __ilog2(SUN4I_SPI_MAX_RATE) - __ilog2(priv->freq);
> >> +  reg &= ~((SUN4I_CLK_CTL_CDR1_MASK << 8) | SUN4I_CLK_CTL_DRS);
> >> +  reg |= SUN4I_CLK_CTL_CDR1(div);
> >> +  }
> >> +
> >> +  writel(reg, SPI_REG(priv, SPI_CCR));
> >> +
> >> +  reg = readl(SPI_REG(priv, SPI_TCR));
> >> +  reg &= ~(SPI_BIT(priv, SPI_TCR_CPOL) | SPI_BIT(priv, SPI_TCR_CPHA));
> >> +
> >> +  if (priv->mode & SPI_CPOL)
> >> +  reg |= SPI_BIT(priv, SPI_TCR_CPOL);
> >> +
> >> +  if (priv->mode & SPI_CPHA)
> >> +  reg

Re: [PATCH 2/3] net: sun8i-emac: Drop use of arch-specific header

On Fri, 15 Jul 2022 00:20:57 -0500
Samuel Holland  wrote:

Hi,

> This header is not used since commit abdbefba2a4e ("net: sun8i_emac: Use
> consistent clock bitfield definitions"). Dropping it allows the driver
> to be architecture-independent.

Yes, we don't need this header anymore (all boards compile fine without
it), and indeed it seems to be this commit you mentioned that changed that.

> Signed-off-by: Samuel Holland 

Reviewed-by: Andre Przywara 

Cheers,
Andre

>  drivers/net/sun8i_emac.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index a4b3492b7647..9cca8fa4e0a1 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include

Re: [SPAM] [PATCH v2 2/2] rockchip: rk3399: fix incorrect ifdef check on SPL_GPIO

El Fri, Jul 15, 2022 at 05:09:49PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> The check to perform is on CONFIG_SPL_GPIO and not SPL_GPIO.
> Because this was never compiled in, it missed an include of cru.h that
> was not detected before. Let's include it too.
> 
> Also switch to IS_ENABLED ifdef and in-code check.
>

Thank you. That helps when CONGIF_SPL_GPIO is enabled.
 But in case CONFIG_SPL_GPIO is disabled...
 
> Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
> 
> v2:
>  - use IS_ENABLED checks,
> 
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 45 ++
>  1 file changed, 24 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 920da22307..db8a6cb83a 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -221,7 +221,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
>  "u-boot,spl-boot-device", boot_ofpath);
>  }
>  
> -#if defined(SPL_GPIO)
> +#if IS_ENABLED(CONFIG_SPL_GPIO)
> +
> +#include 

then (if CONFIG_SPL_GPIO is disabled...) the include is not in effect, but the 
call to 

>  static void rk3399_force_power_on_reset(void)
>  {
>   ofnode node;

the  #endif for that #if is somewhere over here.

> @@ -253,27 +255,28 @@ void spl_board_init(void)
>  {
>   led_setup();
>  
> -#if defined(SPL_GPIO)
> - struct rockchip_cru *cru = rockchip_get_cru();
> + if (IS_ENABLED(CONFIG_SPL_GPIO)) {
> + struct rockchip_cru *cru = rockchip_get_cru();
>  
[...]
> + /*
[...]
> +  */
> + if (cru->glb_rst_st != 0)

This gives me a compilation error (rock-pi-4, CONFIG_SPL_GPIO disabled), 
because of the missing include defining rockchip_cru
(and glb_rst_st as a member of it)

> + rk3399_force_power_on_reset();

This gives a warning, because the function declaration is #ifdefed out.

So we could leave the include outside the #if defined(SPL_GPIO)
and add an inline dummy function in #else, 

or we could change the if (IS_ENABLED(CONFIG_SPL_GPIO)) to 
#if (IS_ENABLED(CONFIG_SPL_GPIO))

I think the first is preferred in U-Boot, but not sure if that might
somehow make SPL bigger or something. I don't think so.

Re: [RFC PATCH 4/8] rockchip: pad u-boot-rockchip.bin correctly


Hi Philipp,

On 7/15/22 18:06, Philipp Tomsich wrote:

On Fri, 15 Jul 2022 at 17:37, Quentin Schulz  wrote:


From: Quentin Schulz 

On MMC storage media, the TPL/SPL needs to be flashed at offset 32KB.
Instead of requesting the user to put the input the appropriate offsets,
let's create u-boot-rockchip.bin with the padding already added.


NAK.

The storage layout provided by Rockchip leaves space for a
(protective) MBR and a primary GPT.
A bootloader update will overwrite the partition table if you create
the image as you suggest.



Ah, that was what I was missing. Thanks, makes complete sense!

Cheers,
Quentin

Re: [RFC PATCH 7/8] binman: add support for skipping file concatenation for mkimage


Hi Simon,

On 7/16/22 13:58, Simon Glass wrote:

On Fri, 15 Jul 2022 at 09:37, Quentin Schulz  wrote:


From: Quentin Schulz 

Some image types handled by mkimage require the datafiles to be passed
independently (-d data1:data2) for specific handling of each. A
concatenation of datafiles prior to passing them to mkimage wouldn't
work.

That is the case for rksd and rkspi for example, which require page
alignment (plus some weird hack for rkspi) plus size data of each stage
to be embedded in the mkimage header.



I forgot to rephrase the commit log. As seen in patch 1/8, there 
actually doesn't seem to be a need for rksd for passing multiple data 
files to mkimage, only the TPL could be passed to mkimage and SPL 
appended right after that blob generated by mkimage. Maybe it's luck but 
it seems to work for me the few tries I did on SD card and eMMC.



This adds the ability to tell binman to pass the datafiles without
prior concatenation to mkimage, by adding the multiple-data-files
boolean property to the mkimage node.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
  tools/binman/entries.rst  | 22 +++
  tools/binman/etype/mkimage.py | 41 +++
  2 files changed, 59 insertions(+), 4 deletions(-)


Reviewed-by: Simon Glass 

I wonder if we should move this logic to binman (from mkimage) when
all the boards are converted to binman?


Not sure this fits the "Relationship to mkimage" section in binman.rst? 
What part of the logic exactly would you like to move from mkimage to 
binman?


Cheers,
Quentin

Re: [PATCH] rockchip: rk3399: boot_devices: fix eMMC node name


On 7/11/22 20:22, Xavier Drudis Ferran wrote:

El Mon, Jul 11, 2022 at 04:15:33PM +0200, Quentin Schulz deia:

From: Quentin Schulz 

When idbloader.img is flashed on the eMMC, the SPL still tries to load
from SPI-NOR first.

This is due to an incorrect look-up in the Device Tree. Since commit
822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
node name (but not label) changed from sdhci@fe33 to mmc@fe33
meaning U-Boot SPL is not looking for the correct node name anymore and
fails to find the "same-as-spl" node when eMMC is the medium from which
the SPL booted.



Yes, I also saw that. I changed and tested it at some time, but since there
were other changes, I hesitate to send a Tested by for your patch. FWIW:

Reviewed-by: Xavier Drudis Ferran 

  

Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

Sorry for resend, was not yet subscribed.

  arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 01a05599cd..de11a3fa30 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
  #define GRF_BASE  0xff77
  
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

-   [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
[BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe32",
  };
@@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
const char *ofpath;
} spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe32" },
-   { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
+   { BOOT_DEVICE_MMC2, "/mmc@fe33" },
{ BOOT_DEVICE_SPI, "/spi@ff1d" },


Not related to this patch, but I also changed "/spi@ff1d" -> 
"/spi@ff1d/flash@0".
Not sure whether it needs to be different in both arrays in some case for some 
reason.



Thanks for the heads up, it seems that our board was the only (upstream) 
one impacted by this oversight because it's the only one reading 
u-boot,spl-boot-device DT property that is set using this table.


See patch here: 
https://lore.kernel.org/u-boot/20220715151552.953654-2-foss+ub...@0leil.net/


You can add your Suggested-by: I forgot to add it before sending.

Thanks!
Quentin

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper

El Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz deia:
> Hi Xavier,
> 
> On 7/15/22 18:30, Xavier Drudis Ferran wrote:
> > Spi0 is not needed in SPL and SPL could be a little smaller without it,
> > but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
> > that's confusing, because once U-Boot proper runs, it numbers the bus 1.
> > 
> > Add spi0 to the pre-reloc and spl trees so that the flash is always
> > connected to bus 1.
> > 
> 
> Mmmm... Could we instead make U-Boot use the bus number from the alias in
> the aliases DT node? I think the mmc subsystem does this already and it
> would mean we don't need to enable unnecessary devices. Also, relying on
> boot order for the bus number is brittle in Linux, I don't know about
> U-Boot, but if we can avoid this assumption, it'd be great :)
> 
> See: 
> https://source.denx.de/u-boot/u-boot/-/commit/2243d19e5618122d9d7aba23eb51f63f2719dba5
> for how to do it today?
>

Maybe I should just drop this patch and try to define
CONFIG_SPL_DM_SEQ_ALIAS in configs/rock-pi-4-rk3399 instead ?
Let me test this a little...

I have CONFIG_DM_SEQ_ALIAS=y but   CONFIG_SPL_DM_SEQ_ALIAS unset. 

> 
> Your patch series got sent with each commit in their individual thread

I know. Sorry for the lapsus. I did it right in v1, wrong in v2, and will do 
right in v3.

Re: [SPAM] [RFC PATCH 1/2] spl: enable regulator-boot-on and disable regulator-force-boot-off

El Mon, Jul 18, 2022 at 10:34:54AM +0200, Xavier Drudis Ferran deia:
> 
> Can we remove the #if ? 

Not sure if I was clear. 
I meant remove the #if and #endif and leave an inconditional #include.

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper

On Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz wrote:
> Hi Xavier,
> 
> On 7/15/22 18:30, Xavier Drudis Ferran wrote:
> > Spi0 is not needed in SPL and SPL could be a little smaller without it,
> > but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
> > that's confusing, because once U-Boot proper runs, it numbers the bus 1.
> > 
> > Add spi0 to the pre-reloc and spl trees so that the flash is always
> > connected to bus 1.
> > 
> 
> Mmmm... Could we instead make U-Boot use the bus number from the alias in
> the aliases DT node? I think the mmc subsystem does this already and it
> would mean we don't need to enable unnecessary devices. Also, relying on

It does not seem to work for mmc, though.

I have mmc2 and mmc1 in SPL, and mmc1 and mmc0 in u-boot.

There are actually 3 mmc interfaces using 2 drivers so the situations is
.. complex.

Thanks

Michal

Re: [SPAM] [RFC PATCH 1/2] spl: enable regulator-boot-on and disable regulator-force-boot-off



Hello, and thanks for you work 

El Fri, Jul 15, 2022 at 05:14:25PM +0200, Quentin Schulz deia:
> From: Quentin Schulz 
> 
> This makes sure regulators that need to be turned on or off at boot are
> turned on or off in the SPL.
> 
> This may be required for the SPL to do some operations, such as finding
> possible loading media for U-Boot proper.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
> 
>  - RFC because only tested on Puma Haikou RK3399
> 
>  common/spl/spl.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index c8c463f80b..762e9918c7 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -37,6 +37,9 @@
>  #include 
>  #include 
>  #include 
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
> +#include 
> +#endif
>

Can we remove the #if ? 
Otherwise I get 2 compilation warnings in tpl,
because I miss the dummy regulators_enable_boot_on (and _off)
  in include/power/regulator.h 

When compiling tpl for Rock-pi-4 
I have CONFIG_DM_REGULATOR=y, but not CONFIG_TPL_DM_REGULATOR or
CONFIG_SPL_DM_REGULATOR.

>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -766,6 +769,15 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>   if (CONFIG_IS_ENABLED(GPIO_HOG))
>   gpio_hog_probe_all();
>  
> + if (CONFIG_IS_ENABLED(DM_REGULATOR)) {
> + if (regulators_enable_boot_on(false))
> + debug("%s: Cannot enable boot on regulator\n",
> +   __func__);
> + if (regulators_enable_boot_off(false))
> + debug("%s: Cannot enable boot off regulator\n",
> +   __func__);
> + }
> +

This still introduces a warning for me. 

warning: implicit declaration of function 'regulators_enable_boot_off'

So maybe the dummy function must be added to include/power/regulator.h
 commit 16cc5ad0b439 ("power: regulator: add dummy helper")
introduced the dummy  regulators_enable_boot_on but missed 
the regulators_enable_boot_off.

Alternatively one could replace the if with an #if, but I think that'd 
be against U-Boot policy.

Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper

Hi Xavier,

On 7/15/22 18:30, Xavier Drudis Ferran wrote:

Spi0 is not needed in SPL and SPL could be a little smaller without it,
but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
that's confusing, because once U-Boot proper runs, it numbers the bus 1.

Add spi0 to the pre-reloc and spl trees so that the flash is always
connected to bus 1.

Mmmm... Could we instead make U-Boot use the bus number from the alias
in the aliases DT node? I think the mmc subsystem does this already and
it would mean we don't need to enable unnecessary devices. Also, relying
on boot order for the bus number is brittle in Linux, I don't know about
U-Boot, but if we can avoid this assumption, it'd be great :)

See:
https://source.denx.de/u-boot/u-boot/-/commit/2243d19e5618122d9d7aba23eb51f63f2719dba5
for how to do it today?

Changes since v1:
- new patch in v2.

Your patch series got sent with each commit in their individual thread
instead of the usual way, with 1/X patch as the first mail in the
thread. I think this could make this difficult to merge for the
maintainer, could you please try to put all your patch into a single
thread for the next version/patch series you will send? `git send-email
*.patch` should do that for you by default I'm pretty sure.

What happened with your patches:
https://lore.kernel.org/u-boot/20220715162712.GB2143@begut/T/#u
https://lore.kernel.org/u-boot/20220715162802.GC2143@begut/T/#u

What should have had happened:
https://lore.kernel.org/u-boot/20220715163435.1725-1-...@ti.com/T/#m6339d543cec31cf6a30355d0e44fd3b99492a30d

Cheers,
Quentin

Re: [PATCH] [Meson] add magicbox m16s config, dts and doc

2022-07-18 Thread Neil Armstrong


Hi,

On 13/07/2022 09:32, Zhang Ning wrote:

MagicBox M16S or MagicBox 3Pro is welcome Tv box in China,
which is developed by Alibaba at 2016.

No schemtics, no vendor source code right now
thus no fip blobs to create mainline u-boot.
Need to use chainloader to boot a mainline u-boot, then mainline kernel.

from pre-installed u-boot log, it's gxm_q201_v1 or its decendent.

add a simple dts and config to enable this Tv box.
a simple doc for how to enable mainline uboot.

Signed-off-by: Zhang Ning 
---
  arch/arm/dts/Makefile |   1 +
  .../dts/meson-gxm-magicbox-m16s-u-boot.dtsi   |   6 +
  arch/arm/dts/meson-gxm-magicbox-m16s.dts  |  24 
  configs/magicbox-m16s_defconfig   |  68 +++
  doc/board/amlogic/index.rst   |   1 +
  doc/board/amlogic/magicboxm16s.rst| 109 ++
  6 files changed, 209 insertions(+)
  create mode 100644 arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi
  create mode 100644 arch/arm/dts/meson-gxm-magicbox-m16s.dts
  create mode 100644 configs/magicbox-m16s_defconfig
  create mode 100644 doc/board/amlogic/magicboxm16s.rst

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a7e0d9f6c0..31294c4c18 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -191,6 +191,7 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
meson-gxm-wetek-core2.dtb \
+   meson-gxm-magicbox-m16s.dtb \
meson-g12a-radxa-zero.dtb \
meson-g12a-sei510.dtb \
meson-g12a-u200.dtb \
diff --git a/arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi 
b/arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi
new file mode 100644
index 00..87a6e8525e
--- /dev/null
+++ b/arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Zhang Ning 
+ */
+
+#include "meson-gxl-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-gxm-magicbox-m16s.dts 
b/arch/arm/dts/meson-gxm-magicbox-m16s.dts
new file mode 100644
index 00..a382fafc51
--- /dev/null
+++ b/arch/arm/dts/meson-gxm-magicbox-m16s.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Zhang Ning 
+ */
+
+/dts-v1/;
+
+#include "meson-gxm.dtsi"
+#include "meson-gx-p23x-q20x.dtsi"
+
+/ {
+   compatible = "magicbox,m16s", "amlogic,s912", "amlogic,meson-gxm";
+   model = "Magicbox M16S";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>; /* 2 GiB */
+   };
+
+};
+ðmac {
+phy-mode = "rmii";
+phy-handle = <&internal_phy>;
+};


For first support, I think it would be simpler to copy the Q201 DT from Linux,
rename meson-gxm-magicbox-m16s-u-boot.dtsi to meson-gxm-q201-u-boot.dtsi...


diff --git a/configs/magicbox-m16s_defconfig b/configs/magicbox-m16s_defconfig
new file mode 100644
index 00..df9a746b65
--- /dev/null
+++ b/configs/magicbox-m16s_defconfig
@@ -0,0 +1,68 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="meson-gxm-magicbox-m16s"


and here use "meson-gxm-q201"


+CONFIG_MESON_GXM=y
+CONFIG_DEBUG_UART_BASE=0xc81004c0
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" magicbox m16s"
+CONFIG_SYS_LOAD_ADDR=0x100
+CONFIG_DEBUG_UART=y
+CONFIG_REMAKE_ELF=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_MISC_INIT_R=y
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_ADC=y
+# CONFIG_EFI_LOADER is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SARADC_MESON=y
+CONFIG_MMC_MESON_GX=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
+CONFIG_ETH_DESIGNWARE_MESON8B=y
+CONFIG_MDIO_MUX_MMIOREG=y
+CONFIG_MESON_GXL_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_GXL=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_GX_VPU_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_RESET=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_DWC3_MESON_GXL=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
+CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 9c7fadf2c0..2620b38b5d 100644
--- a/doc/bo

Re: DWC3 host support

2022-07-18 Thread Michal Simek





On 7/17/22 17:23, Marek Vasut wrote:

On 7/17/22 05:00, Angus Ainslie wrote:

On 2022-07-16 11:37, Marek Vasut wrote:

On 7/16/22 15:02, Angus Ainslie wrote:

Hi Michal,

I recently rebased my librem5 tree onto the latest u-boot-imx branch
and the dwc3 host mode stopped working.

I bisected it down to this commit:

142d50fbce7c364a74f5e8204dba491b9f066e6c usb: dwc3: Add support for
usb3-phy PHY configuration

Reverting that commit allows usb host mode to work on the librem5 again.

Should this initialization go into an SOC specific glue_configure
function ?

Is the imx8mq.dtsi missing something that will keep usb host working
with this patch ?

Does this break usb host on other imx8mq devices ?


Wasn't this fixed by:
868d58f69c ("usb: dwc3: Fix non-usb3 configurations")
?


I've got that in my tree and it still fails to probe the USB2 hub and
USB 2 storage.


I assume you do have CONFIG_PHY_IMX8MQ_USB enabled ?

What does generic_phy_get_by_name() return for you in
drivers/usb/dwc3/dwc3-generic.c ?


As Marek said there was one patch which fixes origin patch which didn't handle 
all the error cases properly. We need to know return value from 
generic_phy_get_by_name(), also if you still have usb3-phy in DT (as is in 
imx8mq.dtsi) with phy DT status enabled and enabled  phy driver 
(CONFIG_PHY_IMX8MQ_USB).


Thanks,
Michal

Re: [PATCH 4/4] MIPS: convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig


On 10.07.22 17:15, Daniel Schwierzeck wrote:

This converts the following to Kconfig:
 CONFIG_SYS_MIPS_TIMER_REQ

Signed-off-by: Daniel Schwierzeck 


Reviewed-by: Stefan Roese 

Thanks,
Stefan



---

  arch/mips/Kconfig  | 18 ++
  configs/ap121_defconfig|  1 +
  configs/ap143_defconfig|  1 +
  configs/ap152_defconfig|  1 +
  configs/bcm968380gerg_ram_defconfig|  1 +
  configs/boston32r2_defconfig   |  1 +
  configs/boston32r2el_defconfig |  1 +
  configs/boston32r6_defconfig   |  1 +
  configs/boston32r6el_defconfig |  1 +
  configs/boston64r2_defconfig   |  1 +
  configs/boston64r2el_defconfig |  1 +
  configs/boston64r6_defconfig   |  1 +
  configs/boston64r6el_defconfig |  1 +
  configs/ci20_mmc_defconfig |  1 +
  configs/comtrend_ar5315u_ram_defconfig |  1 +
  configs/comtrend_ar5387un_ram_defconfig|  1 +
  configs/comtrend_ct5361_ram_defconfig  |  1 +
  configs/comtrend_vr3032u_ram_defconfig |  1 +
  configs/comtrend_wap5813n_ram_defconfig|  1 +
  configs/gardena-smart-gateway-mt7688_defconfig |  1 +
  configs/huawei_hg556a_ram_defconfig|  1 +
  configs/imgtec_xilfpga_defconfig   |  1 +
  configs/linkit-smart-7688_defconfig|  1 +
  configs/malta64_defconfig  |  1 +
  configs/malta64el_defconfig|  1 +
  configs/malta_defconfig|  1 +
  configs/maltael_defconfig  |  1 +
  configs/mscc_jr2_defconfig |  1 +
  configs/mscc_luton_defconfig   |  1 +
  configs/mscc_ocelot_defconfig  |  1 +
  configs/mscc_serval_defconfig  |  1 +
  configs/mscc_servalt_defconfig |  1 +
  configs/mt7620_mt7530_rfb_defconfig|  1 +
  configs/mt7620_rfb_defconfig   |  1 +
  configs/mt7621_nand_rfb_defconfig  |  1 +
  configs/mt7621_rfb_defconfig   |  1 +
  configs/mt7628_rfb_defconfig   |  1 +
  configs/netgear_cg3100d_ram_defconfig  |  1 +
  configs/netgear_dgnd3700v2_ram_defconfig   |  1 +
  configs/pic32mzdask_defconfig  |  1 +
  configs/sagem_f@st1704_ram_defconfig   |  1 +
  configs/sfr_nb4-ser_ram_defconfig  |  1 +
  configs/tplink_wdr4300_defconfig   |  1 +
  configs/vocore2_defconfig  |  1 +
  include/configs/ap121.h|  2 --
  include/configs/ap143.h|  2 --
  include/configs/ap152.h|  2 --
  include/configs/bmips_bcm3380.h|  3 ---
  include/configs/bmips_bcm6318.h|  3 ---
  include/configs/bmips_bcm63268.h   |  3 ---
  include/configs/bmips_bcm6328.h|  3 ---
  include/configs/bmips_bcm6338.h|  3 ---
  include/configs/bmips_bcm6348.h|  3 ---
  include/configs/bmips_bcm6358.h|  3 ---
  include/configs/bmips_bcm6362.h|  3 ---
  include/configs/bmips_bcm6368.h|  3 ---
  include/configs/bmips_bcm6838.h|  3 ---
  include/configs/boston.h   |  1 -
  include/configs/ci20.h |  3 ---
  include/configs/gardena-smart-gateway-mt7688.h |  3 ---
  include/configs/imgtec_xilfpga.h   |  2 --
  include/configs/linkit-smart-7688.h|  3 ---
  include/configs/malta.h|  1 -
  include/configs/mt7620.h   |  2 --
  include/configs/mt7621.h   |  2 --
  include/configs/mt7628.h   |  2 --
  include/configs/pic32mzdask.h  |  2 --
  include/configs/tplink_wdr4300.h   |  2 --
  include/configs/vcoreiii.h |  5 -
  include/configs/vocore2.h  |  3 ---
  scripts/config_whitelist.txt   |  1 -
  71 files changed, 61 insertions(+), 68 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 8bef63cbb7..9af0133f10 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -14,6 +14,7 @@ choice
  
  config TARGET_MALTA

bool "Support malta"
+   select HAS_FIXED_TIMER_FREQUENCY
select BOARD_EARLY_INIT_R
select DM
select DM_SERIAL
@@ -41,17 +42,20 @@ config TARGET_MALTA
  
  config ARCH_ATH79

bool "Support QCA/Atheros ath79"
+   select HAS_FIXED_TIMER_FREQUENCY
select DM
select OF_CONTROL
imply CMD_DM
  
  config ARCH_MSCC

bool "Support MSCC VCore-III"
+   select HAS_FIXED_TIMER_FREQUENCY
select OF_CONTROL
select DM
  
  config A

Re: [PATCH 3/4] MIPS: mscc: remove unused CPU_CLOCK_RATE


On 10.07.22 17:15, Daniel Schwierzeck wrote:

CPU_CLOCK_RATE is just used once for CONFIG_SYS_MIPS_TIMER_FREQ
which is migrated to Kconfig in the next patch.

Signed-off-by: Daniel Schwierzeck 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---

  include/configs/vcoreiii.h | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/configs/vcoreiii.h b/include/configs/vcoreiii.h
index 78a62a8b02..5c5036b8be 100644
--- a/include/configs/vcoreiii.h
+++ b/include/configs/vcoreiii.h
@@ -13,11 +13,9 @@
  #define CONFIG_SYS_INIT_SP_OFFSET   0x40
  
  #if defined(CONFIG_SOC_LUTON) || defined(CONFIG_SOC_SERVAL)

-#define CPU_CLOCK_RATE 41666 /* Clock for the MIPS core */
  #define CONFIG_SYS_MIPS_TIMER_FREQ20833
  #else
-#define CPU_CLOCK_RATE 5 /* Clock for the MIPS core */
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CPU_CLOCK_RATE / 2)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 25000
  #endif
  #define CONFIG_SYS_NS16550_CLKCONFIG_SYS_MIPS_TIMER_FREQ
  


Viele Grüße,
Stefan Roese

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

Re: [PATCH 2/4] MIPS: remove CONFIG_SYS_MHZ


On 10.07.22 17:15, Daniel Schwierzeck wrote:

Resolve all uses of CONFIG_SYS_MHZ with the currently defined value.
Remove code which depends on CONFIG_SYS_MHZ but where no board configs
actually use that code.

Signed-off-by: Daniel Schwierzeck 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---

  arch/mips/mach-jz47xx/include/mach/jz4780.h | 2 +-
  arch/mips/mach-jz47xx/jz4780/pll.c  | 6 +-
  board/imgtec/ci20/ci20.c| 4 
  include/configs/ap121.h | 3 +--
  include/configs/ap143.h | 3 +--
  include/configs/ap152.h | 3 +--
  include/configs/ci20.h  | 3 +--
  include/configs/malta.h | 3 +--
  include/configs/tplink_wdr4300.h| 3 +--
  scripts/config_whitelist.txt| 1 -
  10 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/arch/mips/mach-jz47xx/include/mach/jz4780.h 
b/arch/mips/mach-jz47xx/include/mach/jz4780.h
index 4422e503ed..880445dac3 100644
--- a/arch/mips/mach-jz47xx/include/mach/jz4780.h
+++ b/arch/mips/mach-jz47xx/include/mach/jz4780.h
@@ -60,7 +60,7 @@
  
  /* PLL setup */

  #define JZ4780_SYS_EXTAL  4800
-#define JZ4780_SYS_MEM_SPEED   (CONFIG_SYS_MHZ * 100)
+#define JZ4780_SYS_MEM_SPEED   (1200 * 100)
  #define JZ4780_SYS_MEM_DIV3
  #define JZ4780_SYS_AUDIO_SPEED(768 * 100)
  
diff --git a/arch/mips/mach-jz47xx/jz4780/pll.c b/arch/mips/mach-jz47xx/jz4780/pll.c

index 323c634fb3..4519b478cc 100644
--- a/arch/mips/mach-jz47xx/jz4780/pll.c
+++ b/arch/mips/mach-jz47xx/jz4780/pll.c
@@ -399,11 +399,7 @@ static void cpu_mux_select(int pll)
((2 - 1) << CPM_CPCCR_L2DIV_BIT) |
((1 - 1) << CPM_CPCCR_CDIV_BIT);
  
-	if (CONFIG_SYS_MHZ >= 1000)

-   clk_ctrl |= (12 - 1) << CPM_CPCCR_PDIV_BIT;
-   else
-   clk_ctrl |= (6 - 1) << CPM_CPCCR_PDIV_BIT;
-
+   clk_ctrl |= (12 - 1) << CPM_CPCCR_PDIV_BIT;
clrsetbits_le32(cpm_regs + CPM_CPCCR, 0x00ff, clk_ctrl);
  
  	while (readl(cpm_regs + CPM_CPCSR) & (CPM_CPCSR_CDIV_BUSY |

diff --git a/board/imgtec/ci20/ci20.c b/board/imgtec/ci20/ci20.c
index 7cbe49abd9..89f5e7ad79 100644
--- a/board/imgtec/ci20/ci20.c
+++ b/board/imgtec/ci20/ci20.c
@@ -350,10 +350,6 @@ static const struct jz4780_ddr_config 
H5TQ2G83CFR_48_config = {
.pulldn = 0x0e,
  };
  
-#if (CONFIG_SYS_MHZ != 1200)

-#error No DDR configuration for CPU speed
-#endif
-
  const struct jz4780_ddr_config *jz4780_get_ddr_config(void)
  {
const int board_revision = ci20_revision();
diff --git a/include/configs/ap121.h b/include/configs/ap121.h
index 099aac5421..61cc073a8a 100644
--- a/include/configs/ap121.h
+++ b/include/configs/ap121.h
@@ -6,8 +6,7 @@
  #ifndef __CONFIG_H
  #define __CONFIG_H
  
-#define CONFIG_SYS_MHZ  200

-#define CONFIG_SYS_MIPS_TIMER_FREQ  (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ  2
  
  #define CONFIG_SYS_SDRAM_BASE   0x8000
  
diff --git a/include/configs/ap143.h b/include/configs/ap143.h

index 60b9e779fa..579b9b4f2c 100644
--- a/include/configs/ap143.h
+++ b/include/configs/ap143.h
@@ -6,8 +6,7 @@
  #ifndef __CONFIG_H
  #define __CONFIG_H
  
-#define CONFIG_SYS_MHZ  325

-#define CONFIG_SYS_MIPS_TIMER_FREQ  (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ  32500
  
  #define CONFIG_SYS_SDRAM_BASE   0x8000
  
diff --git a/include/configs/ap152.h b/include/configs/ap152.h

index d165ead7bb..283762fd22 100644
--- a/include/configs/ap152.h
+++ b/include/configs/ap152.h
@@ -6,8 +6,7 @@
  #ifndef __CONFIG_H
  #define __CONFIG_H
  
-#define CONFIG_SYS_MHZ  375

-#define CONFIG_SYS_MIPS_TIMER_FREQ  (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ  37500
  
  #define CONFIG_SYS_SDRAM_BASE   0x8000
  
diff --git a/include/configs/ci20.h b/include/configs/ci20.h

index 192da015e1..7e8a9fcb80 100644
--- a/include/configs/ci20.h
+++ b/include/configs/ci20.h
@@ -10,8 +10,7 @@
  #define __CONFIG_CI20_H__
  
  /* Ingenic JZ4780 clock configuration. */

-#define CONFIG_SYS_MHZ 1200
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 12
  
  /* Memory configuration */

  #define CONFIG_SYS_MONITOR_LEN(512 * 1024)
diff --git a/include/configs/malta.h b/include/configs/malta.h
index c8b230ab21..717867d12a 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -18,8 +18,7 @@
  /*
   * CPU Configuration
   */
-#define CONFIG_SYS_MHZ 250 /* arbitrary value */
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 25000
  
  /*

   * Memory map
diff --git a/include/configs/tplink_wdr4300.h b/include/configs/tplink_wdr4300.h
index f5466fd509..1400

Re: [PATCH 1/4] MIPS: remove deprecated TARGET_VCT option