date:20210408




> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Wednesday, March 31, 2021 10:39 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 10/17] arm: socfpga: Add SDRAM driver helper function for Intel
> N5X device
> 
> Add is_ddr_init_skipped function to check if need to skip DDR initialization
> for N5X. This patch is preparation for N5X DDR driver support.
> 
> Signed-off-by: Siew Chin Lim 
> Signed-off-by: Tien Fong Chee 
> ---
>  arch/arm/mach-socfpga/include/mach/misc.h |  4 ++
>  arch/arm/mach-socfpga/misc_soc64.c| 67
> ++-
>  2 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/misc.h b/arch/arm/mach-
> socfpga/include/mach/misc.h
> index 649d2f6ce2..c41b7c14cd 100644
> --- a/arch/arm/mach-socfpga/include/mach/misc.h
> +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> @@ -44,6 +44,10 @@ void socfpga_sdram_remap_zero(void);  int
> is_fpga_config_ready(void);  #endif
> 
> +#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
> +bool is_ddr_init_skipped(void);
> +#endif
> +
>  void do_bridge_reset(int enable, unsigned int mask);  void
> socfpga_pl310_clear(void);  void socfpga_get_managers_addr(void); diff --git
> a/arch/arm/mach-socfpga/misc_soc64.c b/arch/arm/mach-
> socfpga/misc_soc64.c
> index 7b973a79e8..d3945e55aa 100644
> --- a/arch/arm/mach-socfpga/misc_soc64.c
> +++ b/arch/arm/mach-socfpga/misc_soc64.c
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright (C) 2016-2018 Intel Corporation 
> + * Copyright (C) 2016-2021 Intel Corporation 
>   *
>   */
> 
> @@ -19,6 +19,13 @@
> 
>  DECLARE_GLOBAL_DATA_PTR;
> 
> +/* Reset type */
> +enum reset_type {
> + POR_RESET,
> + WARM_RESET,
> + COLD_RESET
> +};
> +
>  /*
>   * FPGA programming support for SoC FPGA Stratix 10
>   */
> @@ -88,3 +95,61 @@ void do_bridge_reset(int enable, unsigned int mask)
> 
>   socfpga_bridges_reset(enable);
>  }
> +
> +#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
> +static bool is_ddr_retention_enabled(u32 boot_scratch_cold0_reg) {
> + return boot_scratch_cold0_reg &
> +ALT_SYSMGR_SCRATCH_REG_0_DDR_RETENTION_MASK;
> +}
> +
> +static bool is_ddr_bitstream_sha_matching(u32 boot_scratch_cold0_reg) {
> + return boot_scratch_cold0_reg &
> ALT_SYSMGR_SCRATCH_REG_0_DDR_SHA_MASK;
> +}
> +
> +static enum reset_type get_reset_type(u32 boot_scratch_cold0_reg) {
> + return (boot_scratch_cold0_reg &
> + ALT_SYSMGR_SCRATCH_REG_0_DDR_RESET_TYPE_MASK) >>
> + ALT_SYSMGR_SCRATCH_REG_0_DDR_RESET_TYPE_SHIFT;
> +}
> +
> +bool is_ddr_init_skipped(void)

1. This function can move to DDR driver.
2. Change this function return true if need the DDR init, so that doesn't need 
to invert checking when call to this function, more readable.

> +{
> + u32 reg = readl(socfpga_get_sysmgr_addr() +
> + SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> +
> + if (get_reset_type(reg) == POR_RESET) {
Store reset type in a variable, don't call get_reset_type() multiple times.

> + debug("%s: POR reset is triggered\n", __func__);
> + debug("%s: DDR init is required\n", __func__);
> + return false;
> + }
> +
> + if (get_reset_type(reg) == WARM_RESET) {
> + debug("%s: Warm reset is triggered\n", __func__);
> + debug("%s: DDR init is skipped\n", __func__);
> + return true;
> + }
> +
> + if (get_reset_type(reg) == COLD_RESET) {
> + debug("%s: Cold reset is triggered\n", __func__);
> +
> + if (is_ddr_retention_enabled(reg)) {
> + debug("%s: DDR retention bit is set\n", __func__);
> +
> + if (is_ddr_bitstream_sha_matching(reg)) {
Combine this IF with parent IF with &&.

> + debug("%s: Matching in DDR bistream\n",
> +   __func__);
> + debug("%s: DDR init is skipped\n", __func__);
> + return true;
> + }
> +
> + debug("%s: Mismatch in DDR bistream\n", __func__);
> + }
> + }
> +
> + debug("%s: DDR init is required\n", __func__);
> + return false;
> +}
> +#endif
> --
> 2.13.0

RE: [v1 11/17] ddr: socfpga: Enable memory test on memory size less than 1GB




> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Wednesday, March 31, 2021 10:39 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai 
> Subject: [v1 11/17] ddr: socfpga: Enable memory test on memory size less
> than 1GB
> 
> From: Tien Fong Chee 
> 
> Minimum 1GB memory size is required in current memory test, so this patch
> improves the memory test for processing memory size less than 1GB, and
> the size in power of two.
> 
> Signed-off-by: Tien Fong Chee 
> ---
>  drivers/ddr/altera/sdram_soc64.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ddr/altera/sdram_soc64.c
> b/drivers/ddr/altera/sdram_soc64.c
> index a08f0953e5..171cde0e6b 100644
> --- a/drivers/ddr/altera/sdram_soc64.c
> +++ b/drivers/ddr/altera/sdram_soc64.c
> @@ -182,6 +182,7 @@ void sdram_size_check(struct bd_info *bd)
>   phys_size_t total_ram_check = 0;
>   phys_size_t ram_check = 0;
>   phys_addr_t start = 0;
> + phys_size_t size, total_size;

Use "remaining_size" is more suitable.

>   int bank;
> 
>   /* Sanity check ensure correct SDRAM size specified */ @@ -189,10
> +190,23 @@ void sdram_size_check(struct bd_info *bd)
> 
>   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>   start = bd->bi_dram[bank].start;
> + total_size = bd->bi_dram[bank].size;
>   while (ram_check < bd->bi_dram[bank].size) {
> - ram_check += get_ram_size((void *)(start +
> ram_check),
> -  (phys_size_t)SZ_1G);
> + size = min((phys_addr_t)SZ_1G,
> (phys_addr_t)total_size);
> +
> + /*
> +  * Ensure the size is power of two, this is requirement
> to run
> +  * get_ram_size() / memory test
> +  */
> + if (size != 0 && ((size & (size - 1)) == 0)) {
> + ram_check += get_ram_size((void *)(start +
> ram_check), size);
> + total_size = bd->bi_dram[bank].size -
> ram_check;
> + } else {
> + puts("DDR: Memory test requires SDRAM
> size in power of two!\n");
> + hang();
> + }
>   }
> +
>   total_ram_check += ram_check;
>   ram_check = 0;
>   }
> --
> 2.13.0

RE: [v1 09/17] arm: socfpga: Changed misc_s10.c to misc_soc64.c




> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Wednesday, March 31, 2021 10:39 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 09/17] arm: socfpga: Changed misc_s10.c to misc_soc64.c
> 
> Rename to common file name to used by all SOC64 devices.
> No functionality change.
> 
> Signed-off-by: Siew Chin Lim 
> ---

Reviewed-by: Ley Foon Tan

RE: [v1 08/17] arm: socfpga: Add clock manager for Intel N5X device




> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Wednesday, March 31, 2021 10:39 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 08/17] arm: socfpga: Add clock manager for Intel N5X device
> 
> Add clock manager for N5X.
> 
> Signed-off-by: Siew Chin Lim 
> ---
>  ...{clock_manager_agilex.c => clock_manager_n5x.c} | 32 ++---
> -  arch/arm/mach-socfpga/include/mach/clock_manager.h |  2
> ++  .../mach-socfpga/include/mach/clock_manager_n5x.h  | 12 
>  3 files changed, 29 insertions(+), 17 deletions(-)  copy arch/arm/mach-
> socfpga/{clock_manager_agilex.c => clock_manager_n5x.c} (64%)  create
> mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_n5x.h

Reviewed-by: Ley Foon Tan

Re: [PATCH] power: regulator: Add support for regulator-force-boot-off

2021-04-08 Thread Stefan Roese


Hi Jaehoon,

On 09.04.21 02:37, Jaehoon Chung wrote:

On 4/9/21 7:52 AM, Jaehoon Chung wrote:

Hi Stefan,

On 4/8/21 6:20 PM, Stefan Roese wrote:

From: Konstantin Porotchkin 

Add support for regulator-force-boot-off DT property.
This property can be used by the board/device drivers for
turning off regulators on early init stages as pre-requisite
for the other components initialization.

Signed-off-by: Konstantin Porotchkin 
Signed-off-by: Stefan Roese 
Cc: Jaehoon Chung 
Cc: Simon Glass 
---
  drivers/power/regulator/regulator-uclass.c | 38 ++
  include/power/regulator.h  | 23 +
  2 files changed, 61 insertions(+)

diff --git a/drivers/power/regulator/regulator-uclass.c 
b/drivers/power/regulator/regulator-uclass.c
index 4d2e730271f9..423867edced8 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -311,6 +311,17 @@ int regulator_autoset(struct udevice *dev)
return ret;
  }
  
+int regulator_unset(struct udevice *dev)

+{
+   struct dm_regulator_uclass_plat *uc_pdata;
+
+   uc_pdata = dev_get_uclass_plat(dev);
+   if (uc_pdata->force_off)


Could you check whether uc_pdata is NULL or not?
It can be returned to NULL.


+   return regulator_set_enable(dev, false);
+
+   return -EMEDIUMTYPE;
+}
+
  static void regulator_show(struct udevice *dev, int ret)
  {
struct dm_regulator_uclass_plat *uc_pdata;
@@ -443,6 +454,7 @@ static int regulator_pre_probe(struct udevice *dev)
uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
0);
+   uc_pdata->force_off = dev_read_bool(dev, "regulator-force-boot-off");
  
  	node = dev_read_subnode(dev, "regulator-state-mem");

if (ofnode_valid(node)) {
@@ -495,6 +507,32 @@ int regulators_enable_boot_on(bool verbose)
return ret;
  }
  
+int regulators_enable_boot_off(bool verbose)

+{
+   struct udevice *dev;
+   struct uclass *uc;
+   int ret;
+
+   ret = uclass_get(UCLASS_REGULATOR, &uc);
+   if (ret)
+   return ret;
+   for (uclass_first_device(UCLASS_REGULATOR, &dev);
+dev;


typo?


I have checked that it was not typo. :)
how about making one line?


I could do this. But this would lead to a quite long line:

	for (uclass_first_device(UCLASS_REGULATOR, &dev); dev; 
uclass_next_device(&dev)) {


Only putting "dev;" into the same line is not appealing, at least not
to me. Please note that this style of uclass looping is pretty
common. It's also used a few lines above in regulators_enable_boot_on():

int regulators_enable_boot_on(bool verbose)
{
struct udevice *dev;
struct uclass *uc;
int ret;

ret = uclass_get(UCLASS_REGULATOR, &uc);
if (ret)
return ret;
for (uclass_first_device(UCLASS_REGULATOR, &dev);
 dev;
 uclass_next_device(&dev)) {
ret = regulator_autoset(dev);
...

So I would like to keep it as in v1.

Thanks,
Stefan



Best Regards,
Jaehoo Chung



Best Regards,
Jaehoon Chung


+uclass_next_device(&dev)) {
+   ret = regulator_unset(dev);
+   if (ret == -EMEDIUMTYPE) {
+   ret = 0;
+   continue;
+   }
+   if (verbose)
+   regulator_show(dev, ret);
+   if (ret == -ENOSYS)
+   ret = 0;
+   }
+
+   return ret;
+}
+
  UCLASS_DRIVER(regulator) = {
.id = UCLASS_REGULATOR,
.name   = "regulator",
diff --git a/include/power/regulator.h b/include/power/regulator.h
index da9a065bdde0..fad87c99e5db 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -151,6 +151,7 @@ enum regulator_flag {
   * @max_uA*- maximum amperage (micro Amps)
   * @always_on* - bool type, true or false
   * @boot_on*   - bool type, true or false
+ * @force_off* - bool type, true or false
   * TODO(s...@chromium.org): Consider putting the above two into @flags
   * @ramp_delay - Time to settle down after voltage change (unit: uV/us)
   * @flags: - flags value (see REGULATOR_FLAG_...)
@@ -176,6 +177,7 @@ struct dm_regulator_uclass_plat {
unsigned int ramp_delay;
bool always_on;
bool boot_on;
+   bool force_off;
const char *name;
int flags;
u8 ctrl_reg;
@@ -420,6 +422,15 @@ int regulator_set_mode(struct udevice *dev, int mode_id);
   */
  int regulators_enable_boot_on(bool verbose);
  
+/**

+ * regulators_enable_boot_off() - disable regulators needed for boot
+ *
+ * This disables all regulators which are marked to be off at boot time.
+ *
+ * This effectively calls regulator_unset() for every regulator.
+ */
+int regulators_enable_boot_off(bool verbose);
+
  /**
   * regula

Re: [PATCH] power: regulator: Add support for regulator-force-boot-off

2021-04-08 Thread Stefan Roese


Hi Jaehoon,

On 09.04.21 00:52, Jaehoon Chung wrote:

Hi Stefan,

On 4/8/21 6:20 PM, Stefan Roese wrote:

From: Konstantin Porotchkin 

Add support for regulator-force-boot-off DT property.
This property can be used by the board/device drivers for
turning off regulators on early init stages as pre-requisite
for the other components initialization.

Signed-off-by: Konstantin Porotchkin 
Signed-off-by: Stefan Roese 
Cc: Jaehoon Chung 
Cc: Simon Glass 
---
  drivers/power/regulator/regulator-uclass.c | 38 ++
  include/power/regulator.h  | 23 +
  2 files changed, 61 insertions(+)

diff --git a/drivers/power/regulator/regulator-uclass.c 
b/drivers/power/regulator/regulator-uclass.c
index 4d2e730271f9..423867edced8 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -311,6 +311,17 @@ int regulator_autoset(struct udevice *dev)
return ret;
  }
  
+int regulator_unset(struct udevice *dev)

+{
+   struct dm_regulator_uclass_plat *uc_pdata;
+
+   uc_pdata = dev_get_uclass_plat(dev);
+   if (uc_pdata->force_off)


Could you check whether uc_pdata is NULL or not?
It can be returned to NULL.


Sure. I'll add this check in v2.


+   return regulator_set_enable(dev, false);
+
+   return -EMEDIUMTYPE;
+}
+
  static void regulator_show(struct udevice *dev, int ret)
  {
struct dm_regulator_uclass_plat *uc_pdata;
@@ -443,6 +454,7 @@ static int regulator_pre_probe(struct udevice *dev)
uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
0);
+   uc_pdata->force_off = dev_read_bool(dev, "regulator-force-boot-off");
  
  	node = dev_read_subnode(dev, "regulator-state-mem");

if (ofnode_valid(node)) {
@@ -495,6 +507,32 @@ int regulators_enable_boot_on(bool verbose)
return ret;
  }
  
+int regulators_enable_boot_off(bool verbose)

+{
+   struct udevice *dev;
+   struct uclass *uc;
+   int ret;
+
+   ret = uclass_get(UCLASS_REGULATOR, &uc);
+   if (ret)
+   return ret;
+   for (uclass_first_device(UCLASS_REGULATOR, &dev);
+dev;


typo?


See comment in next mail.

Thanks,
Stefan


Best Regards,
Jaehoon Chung


+uclass_next_device(&dev)) {
+   ret = regulator_unset(dev);
+   if (ret == -EMEDIUMTYPE) {
+   ret = 0;
+   continue;
+   }
+   if (verbose)
+   regulator_show(dev, ret);
+   if (ret == -ENOSYS)
+   ret = 0;
+   }
+
+   return ret;
+}
+
  UCLASS_DRIVER(regulator) = {
.id = UCLASS_REGULATOR,
.name   = "regulator",
diff --git a/include/power/regulator.h b/include/power/regulator.h
index da9a065bdde0..fad87c99e5db 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -151,6 +151,7 @@ enum regulator_flag {
   * @max_uA*- maximum amperage (micro Amps)
   * @always_on* - bool type, true or false
   * @boot_on*   - bool type, true or false
+ * @force_off* - bool type, true or false
   * TODO(s...@chromium.org): Consider putting the above two into @flags
   * @ramp_delay - Time to settle down after voltage change (unit: uV/us)
   * @flags: - flags value (see REGULATOR_FLAG_...)
@@ -176,6 +177,7 @@ struct dm_regulator_uclass_plat {
unsigned int ramp_delay;
bool always_on;
bool boot_on;
+   bool force_off;
const char *name;
int flags;
u8 ctrl_reg;
@@ -420,6 +422,15 @@ int regulator_set_mode(struct udevice *dev, int mode_id);
   */
  int regulators_enable_boot_on(bool verbose);
  
+/**

+ * regulators_enable_boot_off() - disable regulators needed for boot
+ *
+ * This disables all regulators which are marked to be off at boot time.
+ *
+ * This effectively calls regulator_unset() for every regulator.
+ */
+int regulators_enable_boot_off(bool verbose);
+
  /**
   * regulator_autoset: setup the voltage/current on a regulator
   *
@@ -439,6 +450,18 @@ int regulators_enable_boot_on(bool verbose);
   */
  int regulator_autoset(struct udevice *dev);
  
+/**

+ * regulator_unset: turn off a regulator
+ *
+ * The setup depends on constraints found in device's uclass's platform data
+ * (struct dm_regulator_uclass_platdata):
+ *
+ * - Disable - will set - if  'force_off' is set to true,
+ *
+ * The function returns on the first-encountered error.
+ */
+int regulator_unset(struct udevice *dev);
+
  /**
   * regulator_autoset_by_name: setup the regulator given by its uclass's
   * platform data name field. The setup depends on constraints found in 
device's






Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, G

Re: MXC I2C recover/idle_bus does not work if CONFIG_DM_I2C is configured

2021-04-08 Thread Heiko Schocher

Hello Kees,

added Simon to cc...

On 08.04.21 14:20, Trommel, Kees (Contractor) wrote:
> Heiko,
> 
> When an I2C transaction fails because a previous transaction (by the kernel) 
> was aborted halfway the MXC I2C driver tries to recover from this by calling 
> i2c_idle_bus (if CONFIG_DM_I2C is configured). i2c_idle_bus is defined in 
> drivers/i2c/mxc_i2c.c

Ok, so imx based hardware.

> As part of the recover procedure i2c_idle_bus (tries) to change the direction 
> of I2C GPIO pins from output to input using the function 
> dm_gpio_set_dir_flags. However dm_gpio_set_dir_flags only sets flags without 
> clearing any previously set flags, see statement "flags |= desc->flags" in 
> dm_gpio_set_dir_flags. Because it is not allowed to set both GPIOD_IS_IN and 
> GPIOD_IS_OUT (see function check_dir_flags) only the 
> dm_gpio_set_dir_flags(GPIO_D_IS_OUT) calls are successful,  the 
> dm_gpio_set_dir_flags(GPIO_D_IS_IN) calls fail and the GPIO pin is never set 
> as an input. This causes that i2c_idle_bus finds that clearing the bus is 
> unsuccessful and returns an error.

Ok, sounds like a bug to me.

> Although i2c_idle_bus returns an error the i2c recover procedure itself is 
> successful and the next I2C transfer will be successful. This requires that 
> the I2C application to do a retry. This will work but is not the intention of 
> the I2C driver.
> 
> I want to fix this problem. However it looks like that no dm_gpio API exists 
> to change the direction of an GPIO pin while this is required to successful 
> recover the i2c bus and detect that the recovery is successful. To fix this 
> issue I see 2 possibilities:
> 
> 1. Use the old fashioned APIs gpio_direction_input and gpio_direction_output
> 2. Add a new dm_gpio API dm_gpio_clear_and_set_dir_flags that allows to clear 
> all existing set flags before setting the new flag(s)

Hmm.. I see, we only "or" the flags in dm_gpio_set_dir_flags() ... and
than check if there are conflicts ... May we rework dm_gpio_set_dir_flags()
so we prevent the conflicts we check in check_dir_flags() ?

Assumption is, the caller of dm_gpio_set_dir_flags() knows what he do...

@Simon: What do you think?

> I prefer option 2 but I like to hear the opinion of the developer that 
> designed the dm_gpio interface.

I did not designed the gpio interface!

bye,
Heiko
> 
> Kind regards,
> 
> Kees Trommel.
> 
> ---
> This communication contains confidential information. If you are not the 
> intended recipient please return this email to the sender and delete it from 
> your records.
> 
> Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht der 
> beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte diese an den 
> Absender zurueck und loeschen Sie die E-mail aus Ihrem System.
> 

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

Re: Running u-boot 2021.04 on Raspberry Pi 4


On 4/8/21 8:18 PM, Roman Shaposhnik wrote:

Hi!

first time poster, long time lurker here. Over at Project EVE
https://github.com/lf-edge/eve I've been trying to migrate
from our current u-boot v2020.07 + patches:

https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020.07
to the latest u-boot 2021.04.

Great news is that most of the patches we dependent
on seem to have been pulled upstream. However, this
single *chunk* of one patchset wasn't:

https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020.07/0001-usb-xhci-Load-Raspberry-Pi-4-VL805-s-firmware.patch#L293

I'm wondering what was the reason for leaving it behind,


+CC Nicolas

 - Get rid of PCI core patch as not needed with correct DT PCI topology 


also from the cover letter


This also depends on a DT/bindings patch available on the linux-mailing lists:
https://www.mail-archive.com/linux-kernel@.../msg2205783.html


The merged version of this series is

https://patchwork.kernel.org/project/linux-usb/list/?series=310015&state=%2A&archive=both


Here is the relevant bit for reference/discussion:

&pcie0 {
   pci@1,0 {
   #address-cells = <3>;
   #size-cells = <2>;
   ranges;

   reg = <0 0 0 0 0>;

   usb@1,0 {
   reg = <0x1 0 0 0 0>;
   resets = <&reset 
RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
   };
   };
};



since without it I don't seem to have functioning USB
devices on my  Raspberry Pi 4. In fact, adding it back:

https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04
(just that one chunk -- 'cuz the reset got upstreamed)
seems to solve the issue for me.

Another question I have is that the new u-boot seems to have
some kind of a regression that I can't quite debug. The SMBIOS
tables that it constructs during EFI boot sequence seem to be
broken (see the dmidecode output below). Again, this seems
to be a regression compared to  v2020.07. Any ideas on what
could be wrong or how can I start debugging it would be


You can always bisect it ;)

--Sean


greatly appreciated (in fact I actually added printf's to
write_smbios_table() to see if there's any micalculation going
on -- but no -- it seems that all method->write() methods
there work as expected and their cumulative output
adds up to  209 bytes -- but only 128 are present)

Thanks,
Roman.

# dmidecode
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
7 structures occupying 209 bytes.
Table at 0x3CB28020.
Wrong DMI structures length: bytes announced, only 128 bytes available.
Handle 0x, DMI type 0, 24 bytes
BIOS Information
 Vendor: U-Boot
 Version: 2021.04
 Release Date: 04/08/2021
 ROM Size: 64 kB
 Characteristics:
 PCI is supported
 BIOS is upgradeable
 Selectable boot is supported
 I2O boot is supported
 Targeted content distribution is supported
 BIOS Revision: 21.4
Handle 0x0001, DMI type 1, 27 bytes
System Information
 Manufacturer: Not Specified
 Product Name: Not Specified
 Version: Not Specified
 Serial Number: 1ffddf0b
 UUID: 30303031-3030-3030-3066-666464663062
 Wake-up Type: Reserved
 SKU Number: Not Specified
 Family: Not Specified
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
 Manufacturer: Not Specified
 Product Name: Not Specified
 Version: Not Specified
 Serial Number: Not Specified
 Asset Tag: Not Specified
 Features:
 Board is a hosting board
 Location In Chassis: Not Specified
 Chassis Handle: 0x
 Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.

Re: [PATCH 1/4] command: Use a constant pointer for the help


On 4/6/21 12:30 AM, Simon Glass wrote:

This text should never change during execution, so it makes sense to
use a const char * so that it can be declared as const in the code.
Update struct cmd_tbl with a const char * pointer for 'help'.

Signed-off-by: Simon Glass 
---

  include/command.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/command.h b/include/command.h
index 747f8f80958..675c16a1249 100644
--- a/include/command.h
+++ b/include/command.h
@@ -45,7 +45,7 @@ struct cmd_tbl {
   char *const argv[]);
char*usage; /* Usage message(short) */


Should usage also be const?

--Sean


  #ifdefCONFIG_SYS_LONGHELP
-   char*help;  /* Help  message(long)  */
+   const char  *help;  /* Help  message(long)  */
  #endif
  #ifdef CONFIG_AUTO_COMPLETE
/* do auto completion on the arguments */

Re: [PATCH v3 05/11] clk: k210: Move the clint clock to under aclk


On 4/8/21 10:58 PM, Damien Le Moal wrote:

On 2021/04/09 11:54, Damien Le Moal wrote:

On 2021/04/09 11:13, Sean Anderson wrote:

No other (real) clocks have the cpu clock as their parent; instead they are
children of aclk. Move the clint clock under aclk to match them.

Signed-off-by: Sean Anderson 
---

(no changes since v2)

Changes in v2:
- New

  drivers/clk/kendryte/clk.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index ab86533bb4..5091f07eb0 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -643,7 +643,7 @@ static int k210_clk_probe(struct udevice *dev)
  
  	/* The MTIME register in CLINT runs at one 50th the CPU clock speed */

clk_dm(K210_CLK_CLINT,
-  clk_register_fixed_factor(NULL, "clint", "cpu", 0, 1, 50));
+  clk_register_fixed_factor(NULL, "clint", "aclk", 0, 1, 50));
  
  	return 0;

  }



Looks good, but representing this clock is in fact useless, at least in Linux,
since the clint driver does not use it directly and derives its rate from
riscv_timebase which is set from the timebase-frequency DT property.

Not sure how u-boot handles that though. Since your code allows changing the
PLLs frequency, the timebase-frequency property may end up being buggy if it is
not changed too.


Actually, thinking about this some more, the clint DT node should have an
optional clock entry and use that clock rate to set riscv_timebase if the clock
entry is present. riscv_timebase can be set using timebase-frequency DT property
if the clock is not set.


This is how it is done in U-Boot. See timer_pre_probe and
timer_timebase_fallback for the mechanism.

--Sean

Re: [PATCH v3 05/11] clk: k210: Move the clint clock to under aclk




On 4/8/21 10:54 PM, Damien Le Moal wrote:

On 2021/04/09 11:13, Sean Anderson wrote:

No other (real) clocks have the cpu clock as their parent; instead they are
children of aclk. Move the clint clock under aclk to match them.

Signed-off-by: Sean Anderson 
---

(no changes since v2)

Changes in v2:
- New

  drivers/clk/kendryte/clk.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index ab86533bb4..5091f07eb0 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -643,7 +643,7 @@ static int k210_clk_probe(struct udevice *dev)
  
  	/* The MTIME register in CLINT runs at one 50th the CPU clock speed */

clk_dm(K210_CLK_CLINT,
-  clk_register_fixed_factor(NULL, "clint", "cpu", 0, 1, 50));
+  clk_register_fixed_factor(NULL, "clint", "aclk", 0, 1, 50));
  
  	return 0;

  }



Looks good, but representing this clock is in fact useless, at least in Linux,
since the clint driver does not use it directly and derives its rate from
riscv_timebase which is set from the timebase-frequency DT property.

Not sure how u-boot handles that though. Since your code allows changing the
PLLs frequency, the timebase-frequency property may end up being buggy if it is
not changed too.



U-Boot uses the clocks property since 47d7e3b5eb ("riscv: Move timer
portions of SiFive CLINT to drivers/timer") :)

--Sean

[GIT PULL] SoCFPGA changes for v2021.07-rc1

Hi Tom

Please pull the SoCFPGA changes for v2021.07.

Regards
Ley Foon


The following changes since commit e9c99db7787e3b5c2ef05701177c43ed1c023c27:

  Merge branch '2021-04-07-CI-improvements' (2021-04-07 15:54:07 -0400)

are available in the Git repository at:

  https://github.com/lftan/u-boot.git v2021.07-rc1

for you to fetch changes up to 96fe4f6485e92ed9da464c96c5f536698c5ee66d:

  arm: socfpga: smc: Add function to get usercode (2021-04-08 17:29:13 +0800)


Siew Chin Lim (11):
  arm: socfpga: smc: Remove unused SMC function ID
  arm: socfpga: Move Stratix10 and Agilex SPL common code
  arm: socfpga: Rename Stratix10 and Agilex handoff common macros
  arm: socfpga: Changed wrap_pll_config_s10.c to wrap_pll_config_soc64.c
  arm: socfpga: Changed system_manager_s10.c to system_manager_soc64.c
  arm: socfpga: Rearrange sequence of macros in handoff_soc64.h
  arm: socfpga: Restructure Stratix10 and Agilex handoff code
  arm: socfpga: Move Stratix10 and Agilex clock manager common code
  arm: socfpga: Changed to store QSPI reference clock in kHz
  arm: socfpga: Enable FIT signature with crc32 for SOC64 devices
  arm: socfpga: smc: Add function to get usercode

 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 30 --
 arch/arm/mach-socfpga/Makefile | 14 +++--
 arch/arm/mach-socfpga/clock_manager.c  | 43 +-
 arch/arm/mach-socfpga/clock_manager_agilex.c   |  6 --
 arch/arm/mach-socfpga/clock_manager_s10.c  |  8 +--
 arch/arm/mach-socfpga/include/mach/clock_manager.h |  5 ++
 .../include/mach/clock_manager_arria10.h   |  2 -
 .../mach-socfpga/include/mach/clock_manager_gen5.h |  1 -
 .../mach-socfpga/include/mach/clock_manager_s10.h  |  1 -
 arch/arm/mach-socfpga/include/mach/handoff_s10.h   | 39 -
 arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 62 
 arch/arm/mach-socfpga/include/mach/smc_api.h   |  1 +
 .../include/mach/system_manager_soc64.h| 20 +--
 arch/arm/mach-socfpga/mailbox_s10.c| 17 +++---
 arch/arm/mach-socfpga/smc_api.c| 17 ++
 arch/arm/mach-socfpga/spl_agilex.c | 16 --
 arch/arm/mach-socfpga/spl_s10.c| 17 --
 arch/arm/mach-socfpga/spl_soc64.c  | 25 
 ...system_manager_s10.c => system_manager_soc64.c} | 55 +++---
 arch/arm/mach-socfpga/wrap_handoff_soc64.c | 66 ++
 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c | 56 --
 ...ap_pll_config_s10.c => wrap_pll_config_soc64.c} | 16 +++---
 configs/socfpga_agilex_atf_defconfig   |  4 ++
 configs/socfpga_agilex_vab_defconfig   |  4 ++
 configs/socfpga_stratix10_atf_defconfig|  4 ++
 include/configs/socfpga_soc64_common.h |  4 +-
 include/linux/intel-smc.h  | 52 +++--
 27 files changed, 341 insertions(+), 244 deletions(-)
 delete mode 100644 arch/arm/mach-socfpga/include/mach/handoff_s10.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/handoff_soc64.h
 create mode 100644 arch/arm/mach-socfpga/spl_soc64.c
 rename arch/arm/mach-socfpga/{system_manager_s10.c => system_manager_soc64.c} 
(57%)
 create mode 100644 arch/arm/mach-socfpga/wrap_handoff_soc64.c
 delete mode 100644 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c
 rename arch/arm/mach-socfpga/{wrap_pll_config_s10.c => 
wrap_pll_config_soc64.c} (74%)

[PATCH v3 10/11] riscv: k210: Use AI as the parent clock of aisram, not PLL1

Testing showed that disabling AI while leaving PLL1 enabled disabled the
aisram. This suggests that AI is a more appropriate clock for that ram
bank.

Signed-off-by: Sean Anderson 
---

(no changes since v2)

Changes in v2:
- New

 arch/riscv/dts/k210.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index 2032f1e5c2..75e101530b 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -89,7 +89,7 @@
reg-names = "sram0", "sram1", "aisram";
clocks = <&sysclk K210_CLK_SRAM0>,
 <&sysclk K210_CLK_SRAM1>,
-<&sysclk K210_CLK_PLL1>;
+<&sysclk K210_CLK_AI>;
clock-names = "sram0", "sram1", "aisram";
u-boot,dm-pre-reloc;
};
-- 
2.31.0

[PATCH v3 11/11] riscv: Don't reserve AI ram in k210 dts

It is no longer necessary to disallow ai ram, since it is enabled by the
sram driver.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 arch/riscv/dts/k210.dtsi | 12 
 1 file changed, 12 deletions(-)

diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index 75e101530b..2492af8038 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -94,17 +94,6 @@
u-boot,dm-pre-reloc;
};
 
-   reserved-memory {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   ai_reserved: ai@8060 {
-   reg = <0x8060 0x20>;
-   reusable;
-   };
-   };
-
clocks {
in0: osc {
compatible = "fixed-clock";
@@ -179,7 +168,6 @@
reg = <0x4080 0xc0>;
interrupts = <25>;
clocks = <&sysclk K210_CLK_AI>;
-   memory-region = <&ai_reserved>;
status = "disabled";
};
 
-- 
2.31.0

[PATCH v3 09/11] riscv: k210: Rename airam to aisram

This is more consistent with the naming of other ram banks, and matches
what Linux is doing.

Reported-by: Damien Le Moal 
Signed-off-by: Sean Anderson 
---

(no changes since v2)

Changes in v2:
- New

 arch/riscv/dts/k210.dtsi | 4 ++--
 board/sipeed/maix/maix.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index a735bebf2c..2032f1e5c2 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -86,11 +86,11 @@
reg = <0x8000 0x40>,
  <0x8040 0x20>,
  <0x8060 0x20>;
-   reg-names = "sram0", "sram1", "airam";
+   reg-names = "sram0", "sram1", "aisram";
clocks = <&sysclk K210_CLK_SRAM0>,
 <&sysclk K210_CLK_SRAM1>,
 <&sysclk K210_CLK_PLL1>;
-   clock-names = "sram0", "sram1", "airam";
+   clock-names = "sram0", "sram1", "aisram";
u-boot,dm-pre-reloc;
};
 
diff --git a/board/sipeed/maix/maix.c b/board/sipeed/maix/maix.c
index 6e582911f8..52e4fee2f0 100644
--- a/board/sipeed/maix/maix.c
+++ b/board/sipeed/maix/maix.c
@@ -17,7 +17,7 @@ phys_size_t get_effective_memsize(void)
 static int sram_init(void)
 {
int ret, i;
-   const char * const banks[] = { "sram0", "sram1", "airam" };
+   const char * const banks[] = { "sram0", "sram1", "aisram" };
ofnode memory;
struct clk clk;
 
-- 
2.31.0

[PATCH v3 07/11] riscv: Enable some devices pre-relocation

These devices are necessary for the clock driver, which is required by the
sram driver, to run pre-relocation.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 arch/riscv/dts/k210.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index 0b79a29600..a735bebf2c 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -91,6 +91,7 @@
 <&sysclk K210_CLK_SRAM1>,
 <&sysclk K210_CLK_PLL1>;
clock-names = "sram0", "sram1", "airam";
+   u-boot,dm-pre-reloc;
};
 
reserved-memory {
@@ -109,6 +110,7 @@
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2600>;
+   u-boot,dm-pre-reloc;
};
};
 
@@ -505,11 +507,13 @@
 "syscon", "simple-mfd";
reg = <0x5044 0x100>;
reg-io-width = <4>;
+   u-boot,dm-pre-reloc;
 
sysclk: clock-controller {
#clock-cells = <1>;
compatible = "kendryte,k210-clk";
clocks = <&in0>;
+   u-boot,dm-pre-reloc;
};
 
sysrst: reset-controller {
-- 
2.31.0

[PATCH v3 08/11] riscv: Enable AI ram on K210

We just need to initialize all the clocks pre-reloc. The clock driver
creates a bunch of devices, so we need to increase the pre-reloc malloc
arena.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 board/sipeed/maix/maix.c   | 12 +++-
 configs/sipeed_maix_bitm_defconfig |  2 ++
 include/configs/sipeed-maix.h  |  3 +--
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/board/sipeed/maix/maix.c b/board/sipeed/maix/maix.c
index cbcb23cf5c..6e582911f8 100644
--- a/board/sipeed/maix/maix.c
+++ b/board/sipeed/maix/maix.c
@@ -14,7 +14,7 @@ phys_size_t get_effective_memsize(void)
return CONFIG_SYS_SDRAM_SIZE;
 }
 
-int board_init(void)
+static int sram_init(void)
 {
int ret, i;
const char * const banks[] = { "sram0", "sram1", "airam" };
@@ -39,3 +39,13 @@ int board_init(void)
 
return 0;
 }
+
+int board_early_init_f(void)
+{
+   return sram_init();
+}
+
+int board_init(void)
+{
+   return 0;
+}
diff --git a/configs/sipeed_maix_bitm_defconfig 
b/configs/sipeed_maix_bitm_defconfig
index 210848cccf..bd877cd055 100644
--- a/configs/sipeed_maix_bitm_defconfig
+++ b/configs/sipeed_maix_bitm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_RISCV=y
+CONFIG_SYS_MALLOC_F_LEN=0x1
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0xfff000
 CONFIG_ENV_SECT_SIZE=0x1000
@@ -7,6 +8,7 @@ CONFIG_ARCH_RV64I=y
 CONFIG_STACK_SIZE=0x10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="run k210_bootcmd"
+CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_HUSH_PARSER=y
 CONFIG_MTDIDS_DEFAULT="nor0=spi3:0"
 CONFIG_MTDPARTS_DEFAULT="nor0:1M(u-boot),0x1000@0xfff000(env)"
diff --git a/include/configs/sipeed-maix.h b/include/configs/sipeed-maix.h
index 4c1ff98ec6..0fbe8a5905 100644
--- a/include/configs/sipeed-maix.h
+++ b/include/configs/sipeed-maix.h
@@ -15,8 +15,7 @@
 #define CONFIG_SYS_CACHELINE_SIZE 64
 
 #define CONFIG_SYS_SDRAM_BASE 0x8000
-/* Don't relocate into AI ram since it isn't set up yet */
-#define CONFIG_SYS_SDRAM_SIZE (SZ_4M + SZ_2M)
+#define CONFIG_SYS_SDRAM_SIZE SZ_8M
 
 #ifndef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
2.31.0

[PATCH v3 06/11] clk: Add support for the k210 clock driver pre-relocation

Variables which had previously been stored in .bss are moved to .data. In
addition, probed needs to be reset when the clock driver is re-bound
post-relocation.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

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

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index 5091f07eb0..2d6ac03693 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -347,9 +347,7 @@ static const struct k210_comp_params k210_comps[] = {
 #undef COMP_NOMUX_ID
 #undef COMP_LIST
 
-static struct clk *k210_bypass_children = {
-   NULL,
-};
+static struct clk *k210_bypass_children __section(.data);
 
 /* Helper functions to create sub-clocks */
 static struct clk_mux *k210_create_mux(const struct k210_mux_params *params,
@@ -475,7 +473,14 @@ cleanup_mux:
return comp;
 }
 
-static bool probed;
+static bool __section(.data) probed;
+
+/* reset probed so we will probe again post-relocation */
+static int k210_clk_bind(struct udevice *dev)
+{
+   probed = false;
+   return 0;
+}
 
 static int k210_clk_probe(struct udevice *dev)
 {
@@ -658,5 +663,6 @@ U_BOOT_DRIVER(k210_clk) = {
.id = UCLASS_CLK,
.of_match = k210_clk_ids,
.ops = &k210_clk_ops,
+   .bind = k210_clk_bind,
.probe = k210_clk_probe,
 };
-- 
2.31.0

[PATCH v3 03/11] clk: k210: Fix PLL enable always getting taken

This conditional always evaluated as false, regardless of the value of reg.
Fix it so that it properly tests the bits in the PLL register. Also test
PLL_EN, now that we set it.

Reported-by: Damien Le Moal 
Signed-off-by: Sean Anderson 
---

(no changes since v2)

Changes in v2:
- New

 drivers/clk/kendryte/pll.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/kendryte/pll.c b/drivers/clk/kendryte/pll.c
index f198920113..d46fd0ebbf 100644
--- a/drivers/clk/kendryte/pll.c
+++ b/drivers/clk/kendryte/pll.c
@@ -512,7 +512,8 @@ static int k210_pll_enable(struct clk *clk)
struct k210_pll *pll = to_k210_pll(clk);
u32 reg = readl(pll->reg);
 
-   if ((reg | K210_PLL_PWRD) && !(reg | K210_PLL_RESET))
+   if ((reg & K210_PLL_PWRD) && (reg & K210_PLL_EN) &&
+   !(reg & K210_PLL_RESET))
return 0;
 
reg |= K210_PLL_PWRD;
-- 
2.31.0

[PATCH v3 04/11] clk: k210: Remove k210_register_pll

This simplifies the PLL creation process, since we don't have to pass all
the parameters individually.

Signed-off-by: Sean Anderson 
---

(no changes since v2)

Changes in v2:
- New

 drivers/clk/kendryte/clk.c | 10 +++---
 drivers/clk/kendryte/pll.c | 21 -
 include/kendryte/pll.h |  4 
 3 files changed, 3 insertions(+), 32 deletions(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index 3b674a998e..ab86533bb4 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -528,14 +528,10 @@ static int k210_clk_probe(struct udevice *dev)
return -ENOMEM;
}
 
-   {
-   const struct k210_pll_params *params = &k210_plls[1];
-
+   pll = k210_create_pll(&k210_plls[1], base);
+   if (pll)
clk_dm(K210_CLK_PLL1,
-  k210_register_pll("pll1", in0, base + params->off,
-base + params->lock_off, params->shift,
-params->width));
-   }
+  k210_register_pll_struct("pll1", in0, pll));
 
/* PLL2 is muxed, so set up a composite clock */
mux = k210_create_mux(&k210_muxes[MUXIFY(K210_CLK_PLL2)], base);
diff --git a/drivers/clk/kendryte/pll.c b/drivers/clk/kendryte/pll.c
index d46fd0ebbf..184f37aaf2 100644
--- a/drivers/clk/kendryte/pll.c
+++ b/drivers/clk/kendryte/pll.c
@@ -578,27 +578,6 @@ struct clk *k210_register_pll_struct(const char *name, 
const char *parent_name,
return clk;
 }
 
-struct clk *k210_register_pll(const char *name, const char *parent_name,
- void __iomem *reg, void __iomem *lock, u8 shift,
- u8 width)
-{
-   struct clk *clk;
-   struct k210_pll *pll;
-
-   pll = kzalloc(sizeof(*pll), GFP_KERNEL);
-   if (!pll)
-   return ERR_PTR(-ENOMEM);
-   pll->reg = reg;
-   pll->lock = lock;
-   pll->shift = shift;
-   pll->width = width;
-
-   clk = k210_register_pll_struct(name, parent_name, pll);
-   if (IS_ERR(clk))
-   kfree(pll);
-   return clk;
-}
-
 U_BOOT_DRIVER(k210_pll) = {
.name   = CLK_K210_PLL,
.id = UCLASS_CLK,
diff --git a/include/kendryte/pll.h b/include/kendryte/pll.h
index 55a40b9c97..95b8494f40 100644
--- a/include/kendryte/pll.h
+++ b/include/kendryte/pll.h
@@ -55,8 +55,4 @@ extern const struct clk_ops k210_pll_ops;
 
 struct clk *k210_register_pll_struct(const char *name, const char *parent_name,
 struct k210_pll *pll);
-struct clk *k210_register_pll(const char *name, const char *parent_name,
- void __iomem *reg, void __iomem *lock, u8 shift,
- u8 width);
-
 #endif /* K210_PLL_H */
-- 
2.31.0

[PATCH v3 05/11] clk: k210: Move the clint clock to under aclk

No other (real) clocks have the cpu clock as their parent; instead they are
children of aclk. Move the clint clock under aclk to match them.

Signed-off-by: Sean Anderson 
---

(no changes since v2)

Changes in v2:
- New

 drivers/clk/kendryte/clk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index ab86533bb4..5091f07eb0 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -643,7 +643,7 @@ static int k210_clk_probe(struct udevice *dev)
 
/* The MTIME register in CLINT runs at one 50th the CPU clock speed */
clk_dm(K210_CLK_CLINT,
-  clk_register_fixed_factor(NULL, "clint", "cpu", 0, 1, 50));
+  clk_register_fixed_factor(NULL, "clint", "aclk", 0, 1, 50));
 
return 0;
 }
-- 
2.31.0

[PATCH v3 02/11] clk: k210: Fix PLLs not being enabled

After starting or setting the rate of a PLL, the enable bit must be set.

This fixes a bug where the AI ram would not be accessible, because it
requires PLL1 to be running.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/kendryte/pll.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/kendryte/pll.c b/drivers/clk/kendryte/pll.c
index ab6d75d585..f198920113 100644
--- a/drivers/clk/kendryte/pll.c
+++ b/drivers/clk/kendryte/pll.c
@@ -531,6 +531,7 @@ static int k210_pll_enable(struct clk *clk)
k210_pll_waitfor_lock(pll);
 
reg &= ~K210_PLL_BYPASS;
+   reg |= K210_PLL_EN;
writel(reg, pll->reg);
 
return 0;
@@ -550,6 +551,7 @@ static int k210_pll_disable(struct clk *clk)
writel(reg, pll->reg);
 
reg &= ~K210_PLL_PWRD;
+   reg &= ~K210_PLL_EN;
writel(reg, pll->reg);
return 0;
 }
-- 
2.31.0

[PATCH v3 01/11] clk: Warn on failure to assign rate

If the user/dev explicitly requests a clock be assigned a certain rate,
then we should warn them if we can't do it. This makes it clear if the
clock is running at the default rate.

Signed-off-by: Sean Anderson 
---

Changes in v3:
- New

 drivers/clk/clk-uclass.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 4ab3c402ed..53e7be764d 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -309,8 +310,9 @@ static int clk_set_default_rates(struct udevice *dev, int 
stage)
ret = clk_get_by_indexed_prop(dev, "assigned-clocks",
  index, &clk);
if (ret) {
-   debug("%s: could not get assigned clock %d for %s\n",
- __func__, index, dev_read_name(dev));
+   dev_dbg(dev,
+   "could not get assigned clock %d (err = %d)\n",
+   index, ret);
continue;
}
 
@@ -332,8 +334,9 @@ static int clk_set_default_rates(struct udevice *dev, int 
stage)
ret = clk_set_rate(c, rates[index]);
 
if (ret < 0) {
-   debug("%s: failed to set rate on clock index %d (%ld) 
for %s\n",
- __func__, index, clk.id, dev_read_name(dev));
+   dev_warn(dev,
+"failed to set rate on clock index %d (%ld) 
(error = %d)\n",
+index, clk.id, ret);
break;
}
}
-- 
2.31.0

[PATCH v3 00/11] riscv: k210: Enable use of AI ram bank

This ram bank was previously unusable because PLL1 was not started correctly.
This series fixes that bug, and allows U-Boot to relocate into the AI ram. This
provides an extra 2M of space in which to load payloads.  I've also added some
minor patches to bring the device tree and clock driver closer to what Linux has
(or will have).

The bypass clock turned out to be still necessary after all; I had neglected to
test with CLK_K210_SET_RATE enabled, and I didn't notice that the clock rate
wasn't actually getting set (oops). I've added a warning which will hopefully
make it more difficult to make such mistakes in the future.

Changes in v3:
- Add a warning if we can't assign rates
- Split off patchs for fdtdec_setup_mem_size_base_* into another series
- Eliminated separate RAM driver
- Rebased onto u-boot/next

Changes in v2:
- Don't re-enable the PLL
- Simplify PLL instantiation
- Modify clock tree so clint is a child of aclk
- Sync memory dts node with Linux
- Use correct aisram clock

Sean Anderson (11):
  clk: Warn on failure to assign rate
  clk: k210: Fix PLLs not being enabled
  clk: k210: Fix PLL enable always getting taken
  clk: k210: Remove k210_register_pll
  clk: k210: Move the clint clock to under aclk
  clk: Add support for the k210 clock driver pre-relocation
  riscv: Enable some devices pre-relocation
  riscv: Enable AI ram on K210
  riscv: k210: Rename airam to aisram
  riscv: k210: Use AI as the parent clock of aisram, not PLL1
  riscv: Don't reserve AI ram in k210 dts

 arch/riscv/dts/k210.dtsi   | 22 +++---
 board/sipeed/maix/maix.c   | 14 --
 configs/sipeed_maix_bitm_defconfig |  2 ++
 drivers/clk/clk-uclass.c   | 11 +++
 drivers/clk/kendryte/clk.c | 26 ++
 drivers/clk/kendryte/pll.c | 26 --
 include/configs/sipeed-maix.h  |  3 +--
 include/kendryte/pll.h |  4 
 8 files changed, 47 insertions(+), 61 deletions(-)

-- 
2.31.0

Running u-boot 2021.04 on Raspberry Pi 4

2021-04-08 Thread Roman Shaposhnik

Hi!

first time poster, long time lurker here. Over at Project EVE
https://github.com/lf-edge/eve I've been trying to migrate
from our current u-boot v2020.07 + patches:

https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020.07
to the latest u-boot 2021.04.

Great news is that most of the patches we dependent
on seem to have been pulled upstream. However, this
single *chunk* of one patchset wasn't:

https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020.07/0001-usb-xhci-Load-Raspberry-Pi-4-VL805-s-firmware.patch#L293

I'm wondering what was the reason for leaving it behind,
since without it I don't seem to have functioning USB
devices on my Raspberry Pi 4. In fact, adding it back:

https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04
(just that one chunk -- 'cuz the reset got upstreamed)
seems to solve the issue for me.

Another question I have is that the new u-boot seems to have
some kind of a regression that I can't quite debug. The SMBIOS
tables that it constructs during EFI boot sequence seem to be
broken (see the dmidecode output below). Again, this seems
to be a regression compared to v2020.07. Any ideas on what
could be wrong or how can I start debugging it would be
greatly appreciated (in fact I actually added printf's to
write_smbios_table() to see if there's any micalculation going
on -- but no -- it seems that all method->write() methods
there work as expected and their cumulative output
adds up to 209 bytes -- but only 128 are present)

Thanks,
Roman.

# dmidecode
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
7 structures occupying 209 bytes.
Table at 0x3CB28020.
Wrong DMI structures length: bytes announced, only 128 bytes available.
Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: U-Boot
Version: 2021.04
Release Date: 04/08/2021
ROM Size: 64 kB
Characteristics:
PCI is supported
BIOS is upgradeable
Selectable boot is supported
I2O boot is supported
Targeted content distribution is supported
BIOS Revision: 21.4
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: 1ffddf0b
UUID: 30303031-3030-3030-3066-666464663062
Wake-up Type: Reserved
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x
Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.

Re: [PATCH v4 7/7] board: Add rt-thread art-pi board support

2021-04-08 Thread dillon min

Hi Patrice,

Thanks for the reminder.

On Thu, Apr 8, 2021 at 9:53 PM Patrice CHOTARD
 wrote:
>
> Hi Dillon
>
> 2 minor remarks below, Once fixed, you can add my
> Reviewed-by: Patrice Chotard 
>
> Thanks
> Patrice
>
> On 4/2/21 10:42 AM, dillon.min...@gmail.com wrote:
> > From: dillon min 
> >
> > All these files are add for support rt-thread art-pi board
> > - add board/st/stm32h750-art-pi, defconfig, header support for u-boot
> >
> > for more information about art-pi, please goto:
> > https://art-pi.gitee.io/website/
> >
> > Signed-off-by: dillon min 
> > ---
> > v4: update CONFIG_BOOTARGS, remove rdinit=/linuxrc, to use kernel's devtmpfs
> >
> >  arch/arm/mach-stm32/stm32h7/Kconfig  |  4 ++
> >  board/st/stm32h750-art-pi/Kconfig| 19 +
> >  board/st/stm32h750-art-pi/MAINTAINERS|  7 
> >  board/st/stm32h750-art-pi/Makefile   |  6 +++
> >  board/st/stm32h750-art-pi/stm32h750-art-pi.c | 58 
> > 
> >  configs/stm32h750-art-pi_defconfig   | 51 
> >  include/configs/stm32h750-art-pi.h   | 48 +++
> >  7 files changed, 193 insertions(+)
> >  create mode 100644 board/st/stm32h750-art-pi/Kconfig
> >  create mode 100644 board/st/stm32h750-art-pi/MAINTAINERS
> >  create mode 100644 board/st/stm32h750-art-pi/Makefile
> >  create mode 100644 board/st/stm32h750-art-pi/stm32h750-art-pi.c
> >  create mode 100644 configs/stm32h750-art-pi_defconfig
> >  create mode 100644 include/configs/stm32h750-art-pi.h
> >
> > diff --git a/arch/arm/mach-stm32/stm32h7/Kconfig 
> > b/arch/arm/mach-stm32/stm32h7/Kconfig
> > index 55e6217..70233a4 100644
> > --- a/arch/arm/mach-stm32/stm32h7/Kconfig
> > +++ b/arch/arm/mach-stm32/stm32h7/Kconfig
> > @@ -6,7 +6,11 @@ config TARGET_STM32H743_DISCO
> >  config TARGET_STM32H743_EVAL
> >   bool "STM32H743 Evaluation board"
> >
> > +config TARGET_STM32H750_ART_PI
> > + bool "STM32H750 ART Pi board"
> > +
> >  source "board/st/stm32h743-eval/Kconfig"
> >  source "board/st/stm32h743-disco/Kconfig"
> > +source "board/st/stm32h750-art-pi/Kconfig"
> >
> >  endif
> > diff --git a/board/st/stm32h750-art-pi/Kconfig 
> > b/board/st/stm32h750-art-pi/Kconfig
> > new file mode 100644
> > index 000..c31b984
> > --- /dev/null
> > +++ b/board/st/stm32h750-art-pi/Kconfig
> > @@ -0,0 +1,19 @@
> > +if TARGET_STM32H750_ART_PI
> > +
> > +config SYS_BOARD
> > + string
> > + default "stm32h750-art-pi"
> > +
> > +config SYS_VENDOR
> > + string
> > + default "st"
> > +
> > +config SYS_SOC
> > + string
> > + default "stm32h7"
> > +
> > +config SYS_CONFIG_NAME
> > + string
> > + default "stm32h750-art-pi"
> > +
> > +endif
> > diff --git a/board/st/stm32h750-art-pi/MAINTAINERS 
> > b/board/st/stm32h750-art-pi/MAINTAINERS
> > new file mode 100644
> > index 000..9578833
> > --- /dev/null
> > +++ b/board/st/stm32h750-art-pi/MAINTAINERS
> > @@ -0,0 +1,7 @@
> > +STM32H750 ART PI BOARD
> > +M:   Dillon Min 
> > +S:   Maintained
> > +F:   board/st/stm32h750-art-pi
> > +F:   include/configs/stm32h750-art-pi.h
> > +F:   configs/stm32h750-art-pi_defconfig
> > +F:   arch/arm/dts/stm32h7*
> > diff --git a/board/st/stm32h750-art-pi/Makefile 
> > b/board/st/stm32h750-art-pi/Makefile
> > new file mode 100644
> > index 000..a06de87
> > --- /dev/null
> > +++ b/board/st/stm32h750-art-pi/Makefile
> > @@ -0,0 +1,6 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2021, RT-Thread - All Rights Reserved
> > +# Author(s): Dillon Min,  for RT-Thread.
> > +
> > +obj-y:= stm32h750-art-pi.o
> > diff --git a/board/st/stm32h750-art-pi/stm32h750-art-pi.c 
> > b/board/st/stm32h750-art-pi/stm32h750-art-pi.c
> > new file mode 100644
> > index 000..c374dd3
> > --- /dev/null
> > +++ b/board/st/stm32h750-art-pi/stm32h750-art-pi.c
> > @@ -0,0 +1,58 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2021, STMicroelectronics - All Rights Reserved
> > + * Author(s): Dillon Min  for STMicroelectronics.
>
> As you are not member of STMicroelectronics company, remove the "for 
> STMicroelectronics."
Okay, I will fix this. thanks
>
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +int dram_init(void)
> > +{
> > + struct udevice *dev;
> > + int ret;
> > +
> > + ret = uclass_get_device(UCLASS_RAM, 0, &dev);
> > + if (ret) {
> > + debug("DRAM init failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + if (fdtdec_setup_mem_size_base() != 0)
> > + ret = -EINVAL;
> > +
> > + return ret;
> > +}
> > +
> > +int dram_init_banksize(void)
> > +{
> > + fdtdec_setup_memory_banksize();
> > +
> > + return 0;
> > +}
> > +
> > +int board_early_init_f(void)
> > +{
> > + return 0;
> > +}
> > +
> > +u32 get_board_rev(void)
> > +{
> > + return 0;
> > +}
> > +
> > +int board_late

Re: [PATCH] power: regulator: Add support for regulator-force-boot-off

On 4/9/21 7:52 AM, Jaehoon Chung wrote:
> Hi Stefan,
> 
> On 4/8/21 6:20 PM, Stefan Roese wrote:
>> From: Konstantin Porotchkin 
>>
>> Add support for regulator-force-boot-off DT property.
>> This property can be used by the board/device drivers for
>> turning off regulators on early init stages as pre-requisite
>> for the other components initialization.
>>
>> Signed-off-by: Konstantin Porotchkin 
>> Signed-off-by: Stefan Roese 
>> Cc: Jaehoon Chung 
>> Cc: Simon Glass 
>> ---
>>  drivers/power/regulator/regulator-uclass.c | 38 ++
>>  include/power/regulator.h  | 23 +
>>  2 files changed, 61 insertions(+)
>>
>> diff --git a/drivers/power/regulator/regulator-uclass.c 
>> b/drivers/power/regulator/regulator-uclass.c
>> index 4d2e730271f9..423867edced8 100644
>> --- a/drivers/power/regulator/regulator-uclass.c
>> +++ b/drivers/power/regulator/regulator-uclass.c
>> @@ -311,6 +311,17 @@ int regulator_autoset(struct udevice *dev)
>>  return ret;
>>  }
>>  
>> +int regulator_unset(struct udevice *dev)
>> +{
>> +struct dm_regulator_uclass_plat *uc_pdata;
>> +
>> +uc_pdata = dev_get_uclass_plat(dev);
>> +if (uc_pdata->force_off)
> 
> Could you check whether uc_pdata is NULL or not?
> It can be returned to NULL.
> 
>> +return regulator_set_enable(dev, false);
>> +
>> +return -EMEDIUMTYPE;
>> +}
>> +
>>  static void regulator_show(struct udevice *dev, int ret)
>>  {
>>  struct dm_regulator_uclass_plat *uc_pdata;
>> @@ -443,6 +454,7 @@ static int regulator_pre_probe(struct udevice *dev)
>>  uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
>>  uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
>>  0);
>> +uc_pdata->force_off = dev_read_bool(dev, "regulator-force-boot-off");
>>  
>>  node = dev_read_subnode(dev, "regulator-state-mem");
>>  if (ofnode_valid(node)) {
>> @@ -495,6 +507,32 @@ int regulators_enable_boot_on(bool verbose)
>>  return ret;
>>  }
>>  
>> +int regulators_enable_boot_off(bool verbose)
>> +{
>> +struct udevice *dev;
>> +struct uclass *uc;
>> +int ret;
>> +
>> +ret = uclass_get(UCLASS_REGULATOR, &uc);
>> +if (ret)
>> +return ret;
>> +for (uclass_first_device(UCLASS_REGULATOR, &dev);
>> + dev;
> 
> typo?

I have checked that it was not typo. :)
how about making one line?


Best Regards,
Jaehoo Chung

> 
> Best Regards,
> Jaehoon Chung
> 
>> + uclass_next_device(&dev)) {
>> +ret = regulator_unset(dev);
>> +if (ret == -EMEDIUMTYPE) {
>> +ret = 0;
>> +continue;
>> +}
>> +if (verbose)
>> +regulator_show(dev, ret);
>> +if (ret == -ENOSYS)
>> +ret = 0;
>> +}
>> +
>> +return ret;
>> +}
>> +
>>  UCLASS_DRIVER(regulator) = {
>>  .id = UCLASS_REGULATOR,
>>  .name   = "regulator",
>> diff --git a/include/power/regulator.h b/include/power/regulator.h
>> index da9a065bdde0..fad87c99e5db 100644
>> --- a/include/power/regulator.h
>> +++ b/include/power/regulator.h
>> @@ -151,6 +151,7 @@ enum regulator_flag {
>>   * @max_uA*- maximum amperage (micro Amps)
>>   * @always_on* - bool type, true or false
>>   * @boot_on*   - bool type, true or false
>> + * @force_off* - bool type, true or false
>>   * TODO(s...@chromium.org): Consider putting the above two into @flags
>>   * @ramp_delay - Time to settle down after voltage change (unit: uV/us)
>>   * @flags: - flags value (see REGULATOR_FLAG_...)
>> @@ -176,6 +177,7 @@ struct dm_regulator_uclass_plat {
>>  unsigned int ramp_delay;
>>  bool always_on;
>>  bool boot_on;
>> +bool force_off;
>>  const char *name;
>>  int flags;
>>  u8 ctrl_reg;
>> @@ -420,6 +422,15 @@ int regulator_set_mode(struct udevice *dev, int 
>> mode_id);
>>   */
>>  int regulators_enable_boot_on(bool verbose);
>>  
>> +/**
>> + * regulators_enable_boot_off() - disable regulators needed for boot
>> + *
>> + * This disables all regulators which are marked to be off at boot time.
>> + *
>> + * This effectively calls regulator_unset() for every regulator.
>> + */
>> +int regulators_enable_boot_off(bool verbose);
>> +
>>  /**
>>   * regulator_autoset: setup the voltage/current on a regulator
>>   *
>> @@ -439,6 +450,18 @@ int regulators_enable_boot_on(bool verbose);
>>   */
>>  int regulator_autoset(struct udevice *dev);
>>  
>> +/**
>> + * regulator_unset: turn off a regulator
>> + *
>> + * The setup depends on constraints found in device's uclass's platform data
>> + * (struct dm_regulator_uclass_platdata):
>> + *
>> + * - Disable - will set - if  'force_off' is set to true,
>> + *
>> + * The function returns on the first-encountered error.
>> + */
>> +int regulator_unset(struct udevice *dev);
>> +
>>  /**
>>   * regulator_autoset_by_name: setup the regulato

Re: [PATCH 0/5] Add support for embedding public key in platform's dtb

2021-04-08 Thread Simon Glass

Hi Sughosh,

On Thu, 8 Apr 2021 at 18:53, Sughosh Ganu  wrote:
>
> hi Simon,
>
> On Wed, 7 Apr 2021 at 21:44, Simon Glass  wrote:
>>
>> Hi,
>>
>> On Wed, 7 Apr 2021 at 23:54, Sughosh Ganu  wrote:
>> >
>> > Patch 1 fixes an issue of selection of IMAGE_SIGN_INFO config option
>> > when capsule authentication is enabled.
>> >
>> > Patch 2 add two config symbols, EFI_PKEY_DTB_EMBED and EFI_PKEY_FILE
>> > which are used for enabling embedding of the public key in the dtb,
>> > and specifying the esl file name.
>> >
>> > Patch 3 moves efi_capsule_auth_enabled as a weak function, which can
>> > be used as a default mechanism for checking if capsule authentication
>> > has been enabled.
>> >
>> > Patch 4 adds a default weak function for retrieving the public key
>> > from the platform's dtb.
>> >
>> > Patch 5 adds the functionality to embed the esl file into the
>> > platform's dtb during the platform build.
>> >
>> > I have tested this functionality on the STM32MP157C DK2 board.
>> >
>> > [1] - https://lists.denx.de/pipermail/u-boot/2021-March/442867.html
>> >
>> > Sughosh Ganu (5):
>> >   efi_loader: Kconfig: Select IMAGE_SIGN_INFO when capsule
>> > authentication is enabled
>> >   efi_loader: Kconfig: Add symbols for embedding the public key into the
>> > platform's dtb
>> >   efi_capsule: Add a weak function to check whether capsule
>> > authentication is enabled
>> >   efi_capsule: Add a weak function to get the public key needed for
>> > capsule authentication
>> >   Makefile: Add provision for embedding public key in platform's dtb
>> >
>> >  Makefile  | 10 ++
>> >  board/emulation/common/qemu_capsule.c |  6 
>> >  lib/efi_loader/Kconfig| 16 ++
>> >  lib/efi_loader/efi_capsule.c  | 44 ---
>> >  4 files changed, 66 insertions(+), 10 deletions(-)
>> >
>> > --
>> > 2.17.1
>> >
>>
>> We need to rethink the use of weak functions for this sort of thing,
>> or we will end up with an unnavigable mess at some point. If we need
>> to adjust the flow of boot, let's adjust the flow rather than adding
>> hooks everywhere.
>
>
> There are two weak functions being added. One is for retrieving the public 
> key to be used for the capsule authentication, and the other is for checking 
> for whether capsule authentication has been enabled. The reason why a weak 
> function is needed is because platforms can have other mechanisms for 
> retrieval of the public key or for testing if capsule authentication has been 
> enabled.
>
> If we consider the case of public key retrieval, the majority of platforms 
> would be built with the device tree concatenated with the u-boot binary. The 
> weak function would cater to all of those platforms -- having a weak function 
> would mean that we are not required to repeat the same functionality for 
> every platform that uses the same mechanism for extracting the public key. 
> However, there would be platforms where the public key is obtained through a 
> different mechanism which is platform specific. Those platforms would have to 
> define their own function to get the public key. Same for checking whether 
> capsule authentication feature has been enabled or not.
>
> -sughosh

Yes, I get it, but if this is to be a critical feature and part of the
grand new design for verified boot using UEFI, surely we should be
building a new front door, not digging a tunnel in the bathroom :-)

We can either use drivers with driver model, or perhaps have a Kconfig
that enables calling the function (so we get a link error if not
provided). Or if there will be more than one handler, a linker_list.

Perhaps it is time to consider a 'hook' system, with a command to let
us see what hooks are active for any particular event?

Regards,
Simon

Re: mkimage regression when building ARCH=mips defconfig Linux kernel

2021-04-08 Thread Simon Glass

+Tom Rini

Hi Nathan,

On Fri, 9 Apr 2021 at 06:23, Nathan Chancellor  wrote:
>
> Hi Simon,
>
> Apologies if this is not the proper way to report a regression, this is my 
> first
> time interacting with the U-Boot community.
>
> My distribution updated the uboot-tools package to 2021.04, which broke my
> Linux kernel builds for ARCH=mips:
>
> $ make -skj"$(nproc)" ARCH=mips CROSS_COMPILE=mips-linux- defconfig all
> ...
> /usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1
> make[2]: *** [arch/mips/boot/Makefile:173: arch/mips/boot/vmlinux.gz.itb] 
> Error 1
> ...
>
> I bisected this down to your commit:
>
> 3f04db891a353f4b127ed57279279f851c6b4917 is the first bad commit
> commit 3f04db891a353f4b127ed57279279f851c6b4917
> Author: Simon Glass 
> Date:   Mon Feb 15 17:08:12 2021 -0700
>
> image: Check for unit addresses in FITs
>
> Using unit addresses in a FIT is a security risk. Add a check for this
> and disallow it.
>
> CVE-2021-27138
>
> Signed-off-by: Simon Glass 
> Reported-by: Bruce Monroe 
> Reported-by: Arie Haenel 
> Reported-by: Julien Lenoir 
>
>  common/image-fit.c  | 56 
> +
>  test/py/tests/test_vboot.py |  9 
>  2 files changed, 57 insertions(+), 8 deletions(-)
> bisect run success
>
> $ git bisect log
> # bad: [e9c99db7787e3b5c2ef05701177c43ed1c023c27] Merge branch 
> '2021-04-07-CI-improvements'
> # good: [c4fddedc48f336eabc4ce3f74940e6aa372de18c] Prepare v2021.01
> git bisect start 'e9c99db7787e3b5c2ef05701177c43ed1c023c27' 'v2021.01'
> # good: [b2c86f596cfb1ea9f7f5138f72f1c5c49e3ae3f1] arm: dts: r8a774a1: Import 
> DTS queued for Linux 5.12-rc1
> git bisect good b2c86f596cfb1ea9f7f5138f72f1c5c49e3ae3f1
> # bad: [74f4929c2c73beb595faf7d5d9bb6a78d710c2fd] ddr: marvell: axp: fix 
> array types have different bounds warning
> git bisect bad 74f4929c2c73beb595faf7d5d9bb6a78d710c2fd
> # bad: [cbe607b920bc0827d8fe379ed4f5ae4e2058513e] Merge tag 
> 'xilinx-for-v2021.04-rc3' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze
> git bisect bad cbe607b920bc0827d8fe379ed4f5ae4e2058513e
> # good: [d5f3aadacbc63df3b690d6fd9f0aa3f575b43356] test: Add tests for the 
> 'evil' vboot attacks
> git bisect good d5f3aadacbc63df3b690d6fd9f0aa3f575b43356
> # bad: [a1a652e8016426e2d67148cab225cd5ec45189fb] Merge tag 'mmc-2021-2-19' 
> of https://gitlab.denx.de/u-boot/custodians/u-boot-mmc
> git bisect bad a1a652e8016426e2d67148cab225cd5ec45189fb
> # bad: [aeedeae40733131467de72c68e639cf9d795e059] spl: fit: Replace #ifdef 
> blocks with more readable constructs
> git bisect bad aeedeae40733131467de72c68e639cf9d795e059
> # bad: [eb5fd9e46c11ea41430d9c5bcc81d4583424216e] usb: kbd: destroy device 
> after console is stopped
> git bisect bad eb5fd9e46c11ea41430d9c5bcc81d4583424216e
> # bad: [99cb2b996bd649d98069a95941beaaade0a4447a] stdio: Split out 
> nulldev_register() and move it under #if
> git bisect bad 99cb2b996bd649d98069a95941beaaade0a4447a
> # bad: [3f04db891a353f4b127ed57279279f851c6b4917] image: Check for unit 
> addresses in FITs
> git bisect bad 3f04db891a353f4b127ed57279279f851c6b4917
> # good: [6f3c2d8aa5e6cbd80b5e869bbbddecb66c329d01] image: Add an option to do 
> a full check of the FIT
> git bisect good 6f3c2d8aa5e6cbd80b5e869bbbddecb66c329d01
> # good: [124c255731c76a2b09587378b2bcce561bcd3f2d] libfdt: Check for 
> multiple/invalid root nodes
> git bisect good 124c255731c76a2b09587378b2bcce561bcd3f2d
> # first bad commit: [3f04db891a353f4b127ed57279279f851c6b4917] image: Check 
> for unit addresses in FITs
>
> Is this an actual regression or is this now the expected behavior? I have 
> added
> Thomas and the linux-mips mailing list to take a look and see if the Linux
> kernel needs to have its sources updated.

It is expected. See the code in that commit:

  /*
   * U-Boot stopped using unit addressed in 2017. Since libfdt
   * can match nodes ignoring any unit address, signature
   * verification can see the wrong node if one is inserted with
   * the same name as a valid node but with a unit address
   * attached. Protect against this by disallowing unit addresses.
   */
  if (!ret && CONFIG_IS_ENABLED(FIT_SIGNATURE)) {
 ret = fdt_check_no_at(fit, 0);

 if (ret) {
log_debug("FIT check error %d\n", ret);
return ret;
 }
  }

Possibly you are using @ nodes in your FIT files in the kernel. Is it
possible to use a hyphen instead?

Regards,
Simon

Re: [PATCH] Revert "spl: Drop bd_info in the data section"

2021-04-08 Thread Simon Glass

Hi Alexandru,

On Fri, 9 Apr 2021 at 04:56, Alexandru Gagniuc  wrote:
>
> This reverts commit 38d6b7ebdaee3e0e8426ef1b9df88bdce8ae2e75.
>
> struct global_data contains a pointer to the bd_info structure. This
> pointer was populated spl_set_bd() to a pre-allocated bd_info in the
> ".data" section. The referenced commit replaced this mechanism to one
> that uses malloc(). That new mechanism is only used if SPL_ALLOC_BD=y.
> which very few boards do.
>
> The result is that (struct global_data)->bd is NULL in SPL on most
> platforms. This breaks falcon mode, since arch_fixup_fdt() tries to
> access (struct global_data)->bd and set the "/memory" node in the
> devicetree. The result is that the "/memory" node contains garbage
> values, causing linux to panic() as it sets up the page table.
>
> Instead of trying to fix the mess, potentially causing other issues,
> revert to the code that worked, while this change is reworked.

The goal here is to drop a feature that few boards use and reduce
memory usage in SPL. It has been in place for two releases now.

If Falcon mode needs it, perhaps you could add an 'imply' in the
Kconfig for that feature? Is there one? Or perhaps
CONFIG_ARCH_FIXUP_FDT_MEMORY ?

One option would be to return an error in arch_fixup_fdt(). In
general, fixups make things tricky because there is no way to
determine when they are used but at least this one has a CONFIG.

Regards,
Simon


>
> Signed-off-by: Alexandru Gagniuc 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/spl.c |  5 +
>  common/spl/Kconfig  |  9 -
>  common/spl/spl.c| 20 
>  include/spl.h   | 10 +-
>  4 files changed, 10 insertions(+), 34 deletions(-)
>

Re: [PATCH] power: regulator: Add support for regulator-force-boot-off

Hi Stefan,

On 4/8/21 6:20 PM, Stefan Roese wrote:
> From: Konstantin Porotchkin 
> 
> Add support for regulator-force-boot-off DT property.
> This property can be used by the board/device drivers for
> turning off regulators on early init stages as pre-requisite
> for the other components initialization.
> 
> Signed-off-by: Konstantin Porotchkin 
> Signed-off-by: Stefan Roese 
> Cc: Jaehoon Chung 
> Cc: Simon Glass 
> ---
>  drivers/power/regulator/regulator-uclass.c | 38 ++
>  include/power/regulator.h  | 23 +
>  2 files changed, 61 insertions(+)
> 
> diff --git a/drivers/power/regulator/regulator-uclass.c 
> b/drivers/power/regulator/regulator-uclass.c
> index 4d2e730271f9..423867edced8 100644
> --- a/drivers/power/regulator/regulator-uclass.c
> +++ b/drivers/power/regulator/regulator-uclass.c
> @@ -311,6 +311,17 @@ int regulator_autoset(struct udevice *dev)
>   return ret;
>  }
>  
> +int regulator_unset(struct udevice *dev)
> +{
> + struct dm_regulator_uclass_plat *uc_pdata;
> +
> + uc_pdata = dev_get_uclass_plat(dev);
> + if (uc_pdata->force_off)

Could you check whether uc_pdata is NULL or not?
It can be returned to NULL.

> + return regulator_set_enable(dev, false);
> +
> + return -EMEDIUMTYPE;
> +}
> +
>  static void regulator_show(struct udevice *dev, int ret)
>  {
>   struct dm_regulator_uclass_plat *uc_pdata;
> @@ -443,6 +454,7 @@ static int regulator_pre_probe(struct udevice *dev)
>   uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
>   uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
>   0);
> + uc_pdata->force_off = dev_read_bool(dev, "regulator-force-boot-off");
>  
>   node = dev_read_subnode(dev, "regulator-state-mem");
>   if (ofnode_valid(node)) {
> @@ -495,6 +507,32 @@ int regulators_enable_boot_on(bool verbose)
>   return ret;
>  }
>  
> +int regulators_enable_boot_off(bool verbose)
> +{
> + struct udevice *dev;
> + struct uclass *uc;
> + int ret;
> +
> + ret = uclass_get(UCLASS_REGULATOR, &uc);
> + if (ret)
> + return ret;
> + for (uclass_first_device(UCLASS_REGULATOR, &dev);
> +  dev;

typo?

Best Regards,
Jaehoon Chung

> +  uclass_next_device(&dev)) {
> + ret = regulator_unset(dev);
> + if (ret == -EMEDIUMTYPE) {
> + ret = 0;
> + continue;
> + }
> + if (verbose)
> + regulator_show(dev, ret);
> + if (ret == -ENOSYS)
> + ret = 0;
> + }
> +
> + return ret;
> +}
> +
>  UCLASS_DRIVER(regulator) = {
>   .id = UCLASS_REGULATOR,
>   .name   = "regulator",
> diff --git a/include/power/regulator.h b/include/power/regulator.h
> index da9a065bdde0..fad87c99e5db 100644
> --- a/include/power/regulator.h
> +++ b/include/power/regulator.h
> @@ -151,6 +151,7 @@ enum regulator_flag {
>   * @max_uA*- maximum amperage (micro Amps)
>   * @always_on* - bool type, true or false
>   * @boot_on*   - bool type, true or false
> + * @force_off* - bool type, true or false
>   * TODO(s...@chromium.org): Consider putting the above two into @flags
>   * @ramp_delay - Time to settle down after voltage change (unit: uV/us)
>   * @flags: - flags value (see REGULATOR_FLAG_...)
> @@ -176,6 +177,7 @@ struct dm_regulator_uclass_plat {
>   unsigned int ramp_delay;
>   bool always_on;
>   bool boot_on;
> + bool force_off;
>   const char *name;
>   int flags;
>   u8 ctrl_reg;
> @@ -420,6 +422,15 @@ int regulator_set_mode(struct udevice *dev, int mode_id);
>   */
>  int regulators_enable_boot_on(bool verbose);
>  
> +/**
> + * regulators_enable_boot_off() - disable regulators needed for boot
> + *
> + * This disables all regulators which are marked to be off at boot time.
> + *
> + * This effectively calls regulator_unset() for every regulator.
> + */
> +int regulators_enable_boot_off(bool verbose);
> +
>  /**
>   * regulator_autoset: setup the voltage/current on a regulator
>   *
> @@ -439,6 +450,18 @@ int regulators_enable_boot_on(bool verbose);
>   */
>  int regulator_autoset(struct udevice *dev);
>  
> +/**
> + * regulator_unset: turn off a regulator
> + *
> + * The setup depends on constraints found in device's uclass's platform data
> + * (struct dm_regulator_uclass_platdata):
> + *
> + * - Disable - will set - if  'force_off' is set to true,
> + *
> + * The function returns on the first-encountered error.
> + */
> +int regulator_unset(struct udevice *dev);
> +
>  /**
>   * regulator_autoset_by_name: setup the regulator given by its uclass's
>   * platform data name field. The setup depends on constraints found in 
> device's
>

RE: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

2021-04-08 Thread Harb Abdulhamid OS

Manish, Simon,

  *   The U-boot bloblist mentioned by Simon is conceptually similar to what 
TF-A is using,  if there is consensus of using bloblist/taglist then TF-A tag 
list may be enhanced to take best of both the implementations.

Honestly, “conceptually similar” is not good enough and feels like a 
frustratingly dismissive response to the concerns we are raising.  The whole 
point of starting this thread is because we *know* the existing TF-A mechanisms 
don’t work for the datacenter market segment for various reasons that we called 
out below.

We have a specific set of requirements that the existing framework does not 
really meet.  And that was not for a lack of trying after many years of trying 
to make TF-A framework work on ARMv8 Server SoC’s.


  *   Regarding usage of either UUID or tag, I echo the sentiments of Simon and 
Julius to keep it simple and use tag values.

I think you might be misunderstanding the problem UUIDs solve.  We are talking 
about implementing early BL phases (BL1 – BL31) that can support a broad range 
of BL33 flavors with the same silicon (EDK2, AptioV, CoreBoot, LinuxBoot, or 
other future boot loaders).

These structures we are talking about may not be defined by the SiP, and just 
saying we have SiP specific tags is not good enough.

These maybe many different structures that we need to pass from BL1/BL2/BL31 to 
BL33 that could be defined by one of many different standards bodies (e.g. ARM, 
JEDEC, TCG, UEFI, PCI SIG, CXL, etc.).

If we use tags, then we must agree on who owns/dictates the tag list, and how 
we add/claim tags for vendor specific purposes and avoid tag collisions.

I have not heard a solution to that without establishing some owner / standards 
body to allocate tags.  Until we do, tags are not going to work for the types 
of platform/system agnostic features we must support.

We can’t just hand-wave this problem away, because it is a real and major 
problem that exists on highly configurable systems.


  *   Looking forward to having further discussions on zoom call today.

Looks like there was a mix up on the zoom call time… so look forward to the 
follow up.

Hopefully we can try to sort things out at the next opportunity.

Thanks,
--Harb

From: Manish Pandey2 
Sent: Thursday, April 8, 2021 7:56 AM
To: Simon Glass ; Julius Werner 
Cc: Harb Abdulhamid OS ; Boot Architecture 
Mailman List ; 
t...@lists.trustedfirmware.org; U-Boot Mailing List ; 
Paul Isaac's ; Ron Minnich 
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for 
information passing between boot stages

Hi,

From TF-A project point of view, we prefer to use existing mechanism to pass 
parameters across boot stages using linked list of tagged elements (as 
suggested by Julius). It has support for both generic and SiP-specific tags. 
Having said that, it does not stop partners to introduce new mechanisms 
suitable for their usecase in platform port initially and later move to generic 
code if its suitable for other platforms.

To start with, Ampere can introduce a platform specific implementation of 
memory tag(speed/NUMA topology etc) which can be evaluated and discussed for 
generalization in future. The tag will be populated in BL2 stage and can be 
forwarded to further stages(and to BL33) by passing the head of list pointer in 
one of the registers. Initially any register can be used but going forward a 
standardization will be needed.

The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is 
using,  if there is consensus of using bloblist/taglist then TF-A tag list may 
be enhanced to take best of both the implementations.

One of the potential problems of having structure used in different projects is 
maintainability, this can be avoided by having a single copy of these 
structures in TF-A (kept inside "include/export" which intended to be used by 
other projects.)

Regarding usage of either UUID or tag, I echo the sentiments of Simon and 
Julius to keep it simple and use tag values.

Looking forward to having further discussions on zoom call today.

Thanks
Manish P


From: TF-A 
mailto:tf-a-boun...@lists.trustedfirmware.org>>
 on behalf of Julius Werner via TF-A 
mailto:t...@lists.trustedfirmware.org>>
Sent: 25 March 2021 02:43
To: Simon Glass mailto:s...@chromium.org>>
Cc: Harb Abdulhamid OS 
mailto:abdulha...@os.amperecomputing.com>>; 
Boot Architecture Mailman List 
mailto:boot-architect...@lists.linaro.org>>;
 t...@lists.trustedfirmware.org 
mailto:t...@lists.trustedfirmware.org>>; U-Boot 
Mailing List mailto:u-boot@lists.denx.de>>; Paul Isaac's 
mailto:paul.isa...@linaro.org>>; Ron Minnich 
mailto:rminn...@google.com>>
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for 
information passing between boot stages

Just want to point out that TF-A currently already supports a (very simple) 
mechanism like this:

https://review.trustedfirmware.org/plu

Re: [PATCH] stm32mp1: remove the board_check_usb_power function when ADC is not activated

On 4/6/21 4:57 PM, Patrick Delaunay wrote:
> Simplify the code of the function board_check_usb_power
> based in CONFIG_ADC and adc_measurement; the function is removed by the
> linker when the CONFIG_ADC is not activated.
> 
> Signed-off-by: Patrick Delaunay 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
>  board/st/stm32mp1/stm32mp1.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 759181fb5d..261ec15e1b 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -347,6 +347,9 @@ static int board_check_usb_power(void)
>   u32 nb_blink;
>   u8 i;
>  
> + if (!IS_ENABLED(CONFIG_ADC))
> + return -ENODEV;
> +
>   node = ofnode_path("/config");
>   if (!ofnode_valid(node)) {
>   log_debug("no /config node?\n");
> @@ -370,11 +373,7 @@ static int board_check_usb_power(void)
>  
>   /* perform maximum of 2 ADC measurements to detect power supply current 
> */
>   for (i = 0; i < 2; i++) {
> - if (IS_ENABLED(CONFIG_ADC))
> - ret = adc_measurement(node, adc_count, &min_uV, 
> &max_uV);
> - else
> - ret = -ENODEV;
> -
> + ret = adc_measurement(node, adc_count, &min_uV, &max_uV);
>   if (ret)
>   return ret;
>  
>

Re: [PATCH 15/17] x86: Check ROM exists before building vboot

On 4/7/21 1:32 PM, Simon Glass wrote:
> All the x86 devicetree files are built at once, whichever board is
> actually being built. If coreboot is the target build, CONFIG_ROM_SIZE
> is not defined and samus cannot build Chromium OS verified boot. Add
> this condition to avoid errors about CONFIG_ROM_SIZE being missing.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
>  arch/x86/dts/chromebook_coral.dts | 2 +-
>  arch/x86/dts/chromebook_samus.dts | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/dts/chromebook_coral.dts 
> b/arch/x86/dts/chromebook_coral.dts
> index c8cb4e21c6d..66c31efb6cd 100644
> --- a/arch/x86/dts/chromebook_coral.dts
> +++ b/arch/x86/dts/chromebook_coral.dts
> @@ -10,7 +10,7 @@
>  /include/ "rtc.dtsi"
>  /include/ "tsc_timer.dtsi"
>  
> -#ifdef CONFIG_CHROMEOS_VBOOT
> +#if defined(CONFIG_CHROMEOS_VBOOT) && defined(CONFIG_ROM_SIZE)
>  #include "chromeos-x86.dtsi"
>  #include "flashmap-x86-ro.dtsi"
>  #include "flashmap-16mb-rw.dtsi"
> diff --git a/arch/x86/dts/chromebook_samus.dts 
> b/arch/x86/dts/chromebook_samus.dts
> index adaeb1ea355..ad35ab2e3fd 100644
> --- a/arch/x86/dts/chromebook_samus.dts
> +++ b/arch/x86/dts/chromebook_samus.dts
> @@ -11,7 +11,7 @@
>  
>  #include "smbios.dtsi"
>  
> -#ifdef CONFIG_CHROMEOS_VBOOT
> +#if defined(CONFIG_CHROMEOS_VBOOT) && defined(CONFIG_ROM_SIZE)
>  #include "chromeos-x86.dtsi"
>  #include "flashmap-x86-ro.dtsi"
>  #include "flashmap-8mb-rw.dtsi"
>

Re: [PATCH v2] imx: support i.MX8QM DMSSE20 a1 board

2021-04-08 Thread Stefano Babic


Hi Oliver,

I get errors when I build the board (some configs must be in defconfig 
instead of header):


+(imx8qm_dmsse20a1) Error: You must add new CONFIG options using Kconfig
+(imx8qm_dmsse20a1) The following new ad-hoc CONFIG options were detected:
+(imx8qm_dmsse20a1) CONFIG_ETHPRIME1
+(imx8qm_dmsse20a1) CONFIG_FEC1_ENET_DEV
+(imx8qm_dmsse20a1) CONFIG_FEC1_MXC_PHYADDR
+(imx8qm_dmsse20a1) CONFIG_FEC2_ENET_DEV
+(imx8qm_dmsse20a1) CONFIG_FEC2_MXC_PHYADDR
+(imx8qm_dmsse20a1) CONFIG_IMX_SMMU
+(imx8qm_dms

Can you check this, please ?

Best regards,
Stefano Babic

On 19.02.21 09:40, Oliver Graute wrote:

Add i.MX8QM DMSSE20 a1 board support

U-Boot 2021.04-rc1-00070-g30e1471671 (Feb 19 2021 - 09:25:19 +0100)

Model: Advantech iMX8QM DMSSE20
Board: DMS-SE20A1 8GB
Build: SCFW 494c97f3, SECO-FW d7523fe8, ATF 09c5cc9
Boot:  USB
DRAM:  8 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial@5a06
Out:   serial@5a06
Err:   serial@5a06
Net:   eth0: ethernet@5b04 [PRIME]
Warning: ethernet@5b05 (eth1) using random MAC address - fe:ac:c4:1f:d9:9c
, eth1: ethernet@5b05
Hit any key to stop autoboot:  0

Signed-off-by: Oliver Graute 
---

Changes for v2
  -replaced bd_t with struct bd_info
  -added missing DTS in MAINTAINERS
  -replaced README with imx8qm-dmsse20-a1.rst
  -move CMD_FUSE to Kconfig
  -removed fdt_high
  -added i2c support
  -added rtc support

  arch/arm/dts/Makefile |   1 +
  arch/arm/dts/imx8qm-dmsse20-a1.dts| 407 ++
  arch/arm/mach-imx/imx8/Kconfig|   7 +
  board/advantech/imx8qm_dmsse20_a1/Kconfig |  14 +
  board/advantech/imx8qm_dmsse20_a1/MAINTAINERS |   7 +
  board/advantech/imx8qm_dmsse20_a1/Makefile|   8 +
  .../imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c | 188 
  .../advantech/imx8qm_dmsse20_a1/imximage.cfg  |  21 +
  board/advantech/imx8qm_dmsse20_a1/spl.c   | 224 ++
  common/Kconfig|   2 +-
  configs/imx8qm_dmsse20a1_defconfig|  94 
  doc/board/advantech/imx8qm-dmsse20-a1.rst |  58 +++
  doc/board/advantech/index.rst |   1 +
  include/configs/imx8qm_dmsse20.h  | 187 
  14 files changed, 1218 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/imx8qm-dmsse20-a1.dts
  create mode 100644 board/advantech/imx8qm_dmsse20_a1/Kconfig
  create mode 100644 board/advantech/imx8qm_dmsse20_a1/MAINTAINERS
  create mode 100644 board/advantech/imx8qm_dmsse20_a1/Makefile
  create mode 100644 board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c
  create mode 100644 board/advantech/imx8qm_dmsse20_a1/imximage.cfg
  create mode 100644 board/advantech/imx8qm_dmsse20_a1/spl.c
  create mode 100644 configs/imx8qm_dmsse20a1_defconfig
  create mode 100644 doc/board/advantech/imx8qm-dmsse20-a1.rst
  create mode 100644 include/configs/imx8qm_dmsse20.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c64ba90f01..db5e465cd7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -763,6 +763,7 @@ dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
imx8qm-cgtqmx8.dtb \
+   imx8qm-dmsse20-a1.dtb \
imx8qm-rom7720-a1.dtb \
fsl-imx8qxp-ai_ml.dtb \
fsl-imx8qxp-colibri.dtb \
diff --git a/arch/arm/dts/imx8qm-dmsse20-a1.dts 
b/arch/arm/dts/imx8qm-dmsse20-a1.dts
new file mode 100644
index 00..81ef7fb2ce
--- /dev/null
+++ b/arch/arm/dts/imx8qm-dmsse20-a1.dts
@@ -0,0 +1,407 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2017 NXP
+ */
+
+/dts-v1/;
+
+/* First 128KB is for PSCI ATF. */
+/memreserve/ 0x8000 0x0002;
+
+#include "fsl-imx8qm.dtsi"
+
+/ {
+   model = "Advantech iMX8QM DMSSE20";
+   compatible = "fsl,imx8qm-mek", "fsl,imx8qm";
+
+   aliases {
+  mmc0 = &usdhc1;
+  mmc2 = &usdhc3;
+   };
+
+   chosen {
+   bootargs = "console=ttyLP0,115200 
earlycon=lpuart32,0x5a06,115200";
+   stdout-path = &lpuart0;
+   };
+
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_usb_otg1_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "usb_otg1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio4 3 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_usdhc2_vmmc: usdhc2_vmmc {
+   compatible = "regulator-fixed";
+   regulator-name = "sw-3p3-sd1";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+

Re: [PATCH] ARM: imx: imx8mn-ddr4-evk: Add ethernet support

2021-04-08 Thread Stefano Babic


Hi Marek,

sorry, false positive. This patch creates warnings for the imx8mn_evk board:

   aarch64:  +   imx8mn_evk
+(imx8mn_evk) board/freescale/imx8mn_evk/imx8mn_evk.c: In function 
'board_init':
+(imx8mn_evk) board/freescale/imx8mn_evk/imx8mn_evk.c:53:3: error: 
implicit declaration of function 'setup_fec' 
[-Werror=implicit-function-declaration]

+(imx8mn_evk)53 |   setup_fec();
+(imx8mn_evk)   |   ^
+(imx8mn_evk) cc1: all warnings being treated as errors
+(imx8mn_evk) make[2]: *** [scripts/Makefile.build:266: 
board/freescale/imx8mn_evk/imx8mn_evk.o] Error 1
+(imx8mn_evk) make[1]: *** [Makefile:1746: board/freescale/imx8mn_evk] 
Error 2

+(imx8mn_evk) make: *** [Makefile:171: sub-make] Error 2

Can you check this ? Thanks !

Best regards,
Stefano


On 08.04.21 22:58, sba...@denx.de wrote:

Add support for ethernet on the imx8mn-ddr4-evk.
Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 

Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

2021-04-08 Thread Julius Werner

> These structures we are talking about may not be defined by the SiP, and
just saying we have SiP specific tags is not good enough.


There is enough room in 64-bits to create separate tag spaces for every
kind of category you can think of. (In fact, we could also just let every
vendor allocate their globally unique tags instead if we prefer that model.
We're not going to have more than 4 billion entities working on this
together, and none of them will need more than 4 billion types of tags.)


> If we use tags, then we must agree on who owns/dictates the tag list, and
> how we add/claim tags for vendor specific purposes and avoid tag
> collisions.
>
>
>
> I have not heard a solution to that without establishing some owner /
> standards body to allocate tags.  Until we do, tags are not going to work
> for the types of platform/system agnostic features we must support.
>

Why not just define the tags in the TF-A upstream repository? Like Simon
said, TF-A needs to maintain a list of them anyway to be able to interpret
them, so why not just make that list the global authoritative source? This
doesn't need to be some complicated bureaucracy. The TF-A headers defining
this are written in a way that they can directly be included from other C
code bases without include dependency issues (e.g. as a Git submodule, or
by just copying them verbatim and resyncing regularly... this is the
include/export thing Manish mentioned). I think that model actually makes
coordination much easier than if a bunch of different projects needed
to manually reimplement the same structure definitions tied to UUIDs.

[PATCH] dm: core: Fix uninitialized return value from dm_scan_fdt_node

If there are no nodes or if all nodes are disabled, this function would
return err without setting it first. Fix this by initializing err to
zero.

Fixes: 94f7afdf7e ("dm: core: Ignore disabled devices when binding")

Signed-off-by: Sean Anderson 
---

 drivers/core/root.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/root.c b/drivers/core/root.c
index d9a19c5e6b..f852d867db 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -265,7 +265,7 @@ int dm_scan_plat(bool pre_reloc_only)
 static int dm_scan_fdt_node(struct udevice *parent, ofnode parent_node,
bool pre_reloc_only)
 {
-   int ret = 0, err;
+   int ret = 0, err = 0;
ofnode node;
 
if (!ofnode_valid(parent_node))
-- 
2.25.1

[PATCH 2/2] net: fec: Only unregister MII bus if we registered it

If we fail to probe for whatever reason, we cannot unregister/free the
MII bus unless we registered it with fec_get_miibus. This fixes FECs
sharing an MDIO bus from destroying it, preventing the other FEC from
using it.

Fixes: 6a895d039b ("net: Update eQos driver and FEC driver to use eth phy 
interfaces")

Signed-off-by: Sean Anderson 
---

 drivers/net/fec_mxc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 37eb894248..a64ba955a5 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1355,6 +1355,7 @@ static void fec_gpio_reset(struct fec_priv *priv)
 
 static int fecmxc_probe(struct udevice *dev)
 {
+   bool dm_mii_bus = true;
struct eth_pdata *pdata = dev_get_plat(dev);
struct fec_priv *priv = dev_get_priv(dev);
struct mii_dev *bus = NULL;
@@ -1462,6 +1463,7 @@ static int fecmxc_probe(struct udevice *dev)
 #endif
 
if (!bus) {
+   dm_mii_bus = false;
 #ifdef CONFIG_FEC_MXC_MDIO_BASE
bus = fec_get_miibus((ulong)CONFIG_FEC_MXC_MDIO_BASE,
 dev_seq(dev));
@@ -1507,8 +1509,10 @@ static int fecmxc_probe(struct udevice *dev)
return 0;
 
 err_phy:
-   mdio_unregister(bus);
-   free(bus);
+   if (!dm_mii_bus) {
+   mdio_unregister(bus);
+   free(bus);
+   }
 err_mii:
 err_timeout:
fec_free_descs(priv);
-- 
2.25.1

[PATCH 1/2] net: fec: Don't use disabled phys