Re: [PATCH v8 3/3] efi_loader: add PE/COFF image measurement

2021-05-24 Thread Masahisa Kojima
On Mon, 24 May 2021 at 21:53, Ilias Apalodimas
 wrote:
>
> new_efi);
> > +
> >  bool efi_image_parse(void *efi, size_t len, struct efi_image_regions 
> > **regp,
> >WIN_CERTIFICATE **auth, size_t *auth_len);
> >
> > diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> > index 40e241ce31..bcfb98168a 100644
> > --- a/include/efi_tcg2.h
> > +++ b/include/efi_tcg2.h
> > @@ -9,6 +9,7 @@
> >  #if !defined _EFI_TCG2_PROTOCOL_H_
> >  #define _EFI_TCG2_PROTOCOL_H_
> >
> > +#include 
> >  #include 
> >
> >  #define EFI_TCG2_PROTOCOL_GUID \
> > @@ -53,6 +54,14 @@ struct efi_tcg2_event {
> >   u8 event[];
> >  } __packed;
> >
> > +struct uefi_image_load_event {
> > + efi_physical_addr_t image_location_in_memory;
> > + u64 image_length_in_memory;
> > + u64 image_link_time_address;
> > + u64 length_of_device_path;
> > + struct efi_device_path device_path[];
> > +};
> > +
> >  struct efi_tcg2_boot_service_capability {
> >   u8 size;
> >   struct efi_tcg2_version structure_version;
> > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > index 7de7d6a57d..247b386967 100644
> > --- a/include/tpm-v2.h
> > +++ b/include/tpm-v2.h
> > @@ -70,6 +70,24 @@ struct udevice;
> >  #define EV_TABLE_OF_DEVICES  ((u32)0x000B)
> >  #define EV_COMPACT_HASH  ((u32)0x000C)
> >
> > +/*
> > + * event types, cf.
> > + * "TCG PC Client Platform Firmware Profile Specification", Family "2.0"
> > + * rev 1.04, June 3, 2019
> > + */
> > +#define EV_EFI_EVENT_BASE((u32)0x8000)
> > +#define EV_EFI_VARIABLE_DRIVER_CONFIG((u32)0x8001)
> > +#define EV_EFI_VARIABLE_BOOT ((u32)0x8002)
> > +#define EV_EFI_BOOT_SERVICES_APPLICATION ((u32)0x8003)
> > +#define EV_EFI_BOOT_SERVICES_DRIVER  ((u32)0x8004)
> > +#define EV_EFI_RUNTIME_SERVICES_DRIVER   ((u32)0x8005)
> > +#define EV_EFI_GPT_EVENT ((u32)0x8006)
> > +#define EV_EFI_ACTION((u32)0x8007)
> > +#define EV_EFI_PLATFORM_FIRMWARE_BLOB((u32)0x8008)
> > +#define EV_EFI_HANDOFF_TABLES((u32)0x8009)
> > +#define EV_EFI_HCRTM_EVENT   ((u32)0x8010)
> > +#define EV_EFI_VARIABLE_AUTHORITY((u32)0x80E0)
> > +
> >  /* TPMS_TAGGED_PROPERTY Structure */
> >  struct tpms_tagged_property {
> >   u32 property;
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 98845b8ba3..0e6200fa25 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -309,6 +309,7 @@ config EFI_TCG2_PROTOCOL
> >   select SHA512_ALGO
> >   select SHA384
> >   select SHA512
> > + select HASH_CALCULATE
> >   help
> > Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
> > of the platform.
> > diff --git a/lib/efi_loader/efi_image_loader.c 
> > b/lib/efi_loader/efi_image_loader.c
> > index fe1ee198e2..f37a85e56e 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -302,6 +302,40 @@ static int cmp_pe_section(const void *arg1, const void 
> > *arg2)
> >   return 1;
> >  }
> >
> > +/**
> > + * efi_prepare_aligned_image() - prepare 8-byte aligned image
> > + * @efi: pointer to the EFI binary
> > + * @efi_size:size of @efi binary
> > + * @new_efi: pointer to the newly allocated image
> > + *
> > + * If @efi is not 8-byte aligned, this function newly allocates
> > + * the image buffer and updates @efi_size.
> > + *
> > + * Return:   valid pointer to a image, return NULL if allocation fails.
> > + */
> > +void *efi_prepare_aligned_image(void *efi, u64 *efi_size, void **new_efi)
> > +{
> > + size_t new_efi_size;
> > + void *p;
> > +
> > + /*
> > +  * Size must be 8-byte aligned and the trailing bytes must be
> > +  * zero'ed. Otherwise hash value may be incorrect.
> > +  */
> > + if (!IS_ALIGNED(*efi_size, 8)) {
> > + new_efi_size = ALIGN(*efi_size, 8);
> > + p = calloc(new_efi_size, 1);
> > + if (!p)
> > + return NULL;
> > + memcpy(p, efi, *efi_size);
> > + *efi_size = new_efi_size;
>
> Do we really need new_efi here?  I might be missing some context for the
> original code, but since we return the new pointer, can't we just
> use that in the caller? If so the whole void **new_efi is not needed?

new_efi is required.
The caller uses returned pointer, it will be the pointer to the
original efi image or newly allocated buffer. Caller will need new_efi
to free the newly allocated buffer.

>
> > +
>
> [...]
>
> > + ret = __get_active_pcr_banks();
> > + if (ret != EFI_SUCCESS) {
> > + ret = EFI_DEVICE_ERROR;
>
> __get_active_pcr_banks is supposed to return the correct efi_status_t code.
> I don't think we need 

Re: [PATCH 8/8] mmc: sunxi: Use mmc_of_parse()

2021-05-24 Thread Jaehoon Chung
On 5/25/21 8:30 AM, Andre Przywara wrote:
> At the moment the Allwinner MMC driver parses the bus-width and
> non-removable DT properties itself, in the probe() routine.
> 
> There is actually a generic function provided by the MMC framework doing
> this job, also it parses more generic properties like broken-cd and
> advanced transfer modes.
> 
> Drop our own code and call mmc_of_parse() instead, to get all new
> features for free.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung
> ---
>  drivers/mmc/sunxi_mmc.c | 32 +---
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 115b519546e..178b8cf106d 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -37,7 +37,6 @@ struct sunxi_mmc_priv {
>   uint32_t *mclkreg;
>   unsigned fatal_err;
>   struct gpio_desc cd_gpio;   /* Change Detect GPIO */
> - int cd_inverted;/* Inverted Card Detect */
>   struct sunxi_mmc *reg;
>   struct mmc_config cfg;
>  };
> @@ -612,12 +611,21 @@ static int sunxi_mmc_send_cmd(struct udevice *dev, 
> struct mmc_cmd *cmd,
>  
>  static int sunxi_mmc_getcd(struct udevice *dev)
>  {
> + struct mmc *mmc = mmc_get_mmc_dev(dev);
>   struct sunxi_mmc_priv *priv = dev_get_priv(dev);
>  
> + /* If polling, assume that the card is always present. */
> + if ((mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE) ||
> + (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL))
> + return 1;
> +
>   if (dm_gpio_is_valid(>cd_gpio)) {
>   int cd_state = dm_gpio_get_value(>cd_gpio);
>  
> - return cd_state ^ priv->cd_inverted;
> + if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
> + return !cd_state;
> + else
> + return cd_state;
>   }
>   return 1;
>  }
> @@ -649,23 +657,21 @@ static int sunxi_mmc_probe(struct udevice *dev)
>   struct mmc_config *cfg = >cfg;
>   struct ofnode_phandle_args args;
>   u32 *ccu_reg;
> - int bus_width, ret;
> + int ret;
>  
>   cfg->name = dev->name;
> - bus_width = dev_read_u32_default(dev, "bus-width", 1);
>  
>   cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
> - cfg->host_caps = 0;
> - if (bus_width == 8)
> - cfg->host_caps |= MMC_MODE_8BIT;
> - if (bus_width >= 4)
> - cfg->host_caps |= MMC_MODE_4BIT;
> - cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
> + cfg->host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS;
>   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
>  
>   cfg->f_min = 40;
>   cfg->f_max = 5200;
>  
> + ret = mmc_of_parse(dev, cfg);
> + if (ret)
> + return ret;
> +
>   priv->reg = dev_read_addr_ptr(dev);
>  
>   /* We don't have a sunxi clock driver so find the clock address here */
> @@ -691,17 +697,13 @@ static int sunxi_mmc_probe(struct udevice *dev)
>   return ret;
>  
>   /* This GPIO is optional */
> - if (!dev_read_bool(dev, "non-removable") &&
> - !gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
> + if (!gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
> GPIOD_IS_IN)) {
>   int cd_pin = gpio_get_number(>cd_gpio);
>  
>   sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
>   }
>  
> - /* Check if card detect is inverted */
> - priv->cd_inverted = dev_read_bool(dev, "cd-inverted");
> -
>   upriv->mmc = >mmc;
>  
>   /* Reset controller */
> 



Re: [PATCH 4/8] mmc: sunxi: Cleanup "new timing mode" selection

2021-05-24 Thread Jaehoon Chung
On 5/25/21 8:30 AM, Andre Przywara wrote:
> Among the SoCs using the "new timing mode", only the A83T needs to
> explicitly switch to that mode.
> 
> By just defining the symbol for that one odd A83T bit to 0 for any other
> SoCs, we can always OR that in, and save the confusing nested #ifdefs.
> 
> Clean up the also confusing new_mode setting on the way.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/sunxi_mmc.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index bc68debdad6..33cedb4edba 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -23,6 +23,10 @@
>  #include 
>  #include 
>  
> +#ifndef CCM_MMC_CTRL_MODE_SEL_NEW
> +#define CCM_MMC_CTRL_MODE_SEL_NEW0
> +#endif
> +
>  struct sunxi_mmc_plat {
>   struct mmc_config cfg;
>   struct mmc mmc;
> @@ -102,13 +106,10 @@ static int mmc_resource_init(int sdc_no)
>  static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
>  {
>   unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
> - bool new_mode = true;
> + bool new_mode = IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE);
>   bool calibrate = false;
>   u32 val = 0;
>  
> - if (!IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE))
> - new_mode = false;
> -
>   /* A83T support new mode only on eMMC */
>   if (IS_ENABLED(CONFIG_MACH_SUN8I_A83T) && priv->mmc_no != 2)
>   new_mode = false;
> @@ -176,12 +177,8 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
> unsigned int hz)
>   }
>  
>   if (new_mode) {
> -#ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
> -#ifdef CONFIG_MMC_SUNXI_HAS_MODE_SWITCH
> - val = CCM_MMC_CTRL_MODE_SEL_NEW;
> -#endif
> + val |= CCM_MMC_CTRL_MODE_SEL_NEW;
>   setbits_le32(>reg->ntsr, SUNXI_MMC_NTSR_MODE_SEL_NEW);
> -#endif
>   } else if (!calibrate) {
>   /*
>* Use hardcoded delay values if controller doesn't support
> 



Re: [PATCH 2/8] mmc: sunxi: Fix warnings with CONFIG_PHYS_64BIT

2021-05-24 Thread Jaehoon Chung
On 5/25/21 8:30 AM, Andre Przywara wrote:
> When enabling PHYS_64BIT on 32-bit platforms, we get two warnings about
> pointer casts in sunxi_mmc.c. Those are related to MMIO addresses, which
> are always below 1GB on all Allwinner SoCs, so there is no problem with
> anything having more than 32 bits.
> 
> Add the proper casts to make it compile cleanly.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/sunxi_mmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 87b79fcf5ef..869af993d35 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -631,14 +631,14 @@ static int sunxi_mmc_probe(struct udevice *dev)
>   cfg->f_min = 40;
>   cfg->f_max = 5200;
>  
> - priv->reg = (void *)dev_read_addr(dev);
> + priv->reg = dev_read_addr_ptr(dev);
>  
>   /* We don't have a sunxi clock driver so find the clock address here */
>   ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
> 1, );
>   if (ret)
>   return ret;
> - ccu_reg = (u32 *)ofnode_get_addr(args.node);
> + ccu_reg = (u32 *)(uintptr_t)ofnode_get_addr(args.node);
>  
>   priv->mmc_no = ((uintptr_t)priv->reg - SUNXI_MMC0_BASE) / 0x1000;
>   priv->mclkreg = (void *)ccu_reg + get_mclk_offset() + priv->mmc_no * 4;
> 



Re: [PATCH 1/8] mmc: sunxi: Avoid #ifdefs in delay and width setup

2021-05-24 Thread Jaehoon Chung
On 5/25/21 8:30 AM, Andre Przywara wrote:
> The delay and bus-width setup are slightly different across the
> Allwinner SoC generations, and we covered this so far with some
> preprocessor conditionals.
> 
> Use the more readable IS_ENABLE() instead.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/sunxi_mmc.c | 33 +++--
>  1 file changed, 15 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 3503ccdb2ee..87b79fcf5ef 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -156,23 +156,19 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
> unsigned int hz)
>   } else if (hz <= 2500) {
>   oclk_dly = 0;
>   sclk_dly = 5;
> -#ifdef CONFIG_MACH_SUN9I
> - } else if (hz <= 5200) {
> - oclk_dly = 5;
> - sclk_dly = 4;
> - } else {
> - /* hz > 5200 */
> - oclk_dly = 2;
> - sclk_dly = 4;
> -#else
> - } else if (hz <= 5200) {
> - oclk_dly = 3;
> - sclk_dly = 4;
>   } else {
> - /* hz > 5200 */
> - oclk_dly = 1;
> + if (IS_ENABLED(CONFIG_MACH_SUN9I)) {
> + if (hz <= 5200)
> + oclk_dly = 5;
> + else
> + oclk_dly = 2;
> + } else {
> + if (hz <= 5200)
> + oclk_dly = 3;
> + else
> + oclk_dly = 1;
> + }
>   sclk_dly = 4;
> -#endif
>   }
>  
>   if (new_mode) {
> @@ -521,10 +517,11 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>  
>   cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
>   cfg->host_caps = MMC_MODE_4BIT;
> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) || 
> defined(CONFIG_SUN50I_GEN_H6)
> - if (sdc_no == 2)
> +
> + if ((IS_ENABLED(CONFIG_MACH_SUN50I) || IS_ENABLED(CONFIG_MACH_SUN8I) ||
> + IS_ENABLED(CONFIG_SUN50I_GEN_H6)) && (sdc_no == 2))
>   cfg->host_caps = MMC_MODE_8BIT;
> -#endif
> +
>   cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
>   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
>  
> 



Re: sdhci_data_transfer: Trasnfer data timeout

2021-05-24 Thread Jaehoon Chung
Hi 

On 5/24/21 11:43 PM, aregaard wrote:
> Hi,
> I have made a custom board based on ARM A53.
> I use a NOR-flash, eMMC and DDR3.
> 
> I can start the Uboot from NOR and communicate with the eMMC. 
> But for some reason it is timing out the first time I connect to the eMMC.
> 

You can enable MMC_TRACE, then you can see more information.

Best Regards,
Jaehoon Chung

> 
> *(CLK =25MHz)*
> => run mmc_format
> eMMC: INT_STATUS = 00018000
> eMMC: INT_STATUS = 00018001
> sdhci_transfer_data: Transfer data timeout
> sdhci_transfer_data: Transfer data timeout
> 
> After this part it can communicate:
> 
> *(CLK = 50MHz)*
> success!
> Writing GPT: success!
> Saving Environment to SPI Flash... SF: Detected n25q128a13 with page size
> 256 Bytes, erase size 4 KiB, total 16 MiB
> Erasing SPI flash...Writing to SPI flash...done
> Valid environment: 1
> OK
> 
> This Timeout might cause problems with the DDR3 (I am having problems with
> the Kernel not booting corretly). I think there is an issue with the
> communication with the eMMC and DDR, due to the timeout.
> 
> What can generate the timing-out-issue? 
> 
> To make it clear; I can communicate with the eMMC. The first time it is
> really slow and is timing out with 25 MHz FLASH-clk. The second time it goes
> directly into sync:
> 
> => run mmc_format
> success!
> Writing GPT: success!
> Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI
> flash...done
> Valid environment: 2
> OK
> 
> I sounds like a HW-issue, but what can cause this in the code?
> 
> If I reset the system it is timing out again the first time.
> 
> Kind Regards
> 
> 
> 
> --
> Sent from: http://u-boot.10912.n7.nabble.com/
> 



Re: [PATCH u-boot v4 17/36] sandbox: use sections instead of symbols for getopt array boundaries

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:06PM +0200, Marek Behún wrote:

> In style of linked lists, instead of declaring symbols for boundaries
> of getopt options array in the linker script, declare corresponding
> sections and retrieve the boundaries via static inline functions.
> 
> Without this clang's LTO produces binary without any getopt options,
> because for some reason it thinks that array is empty (start and end
> symbols are at the same address).
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 14/36] build: support building with Link Time Optimizations

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:03PM +0200, Marek Behún wrote:

> Add plumbing for building U-Boot with Link Time Optimizations.
> 
> When building with LTO, $(PLATFORM_LIBS) has to be in --whole-archive /
> --no-whole-archive group, otherwise some functions declared in assembly
> may not be resolved and linking may fail.
> 
> Note: clang may throw away linker list symbols it thinks are unused when
> compiling with LTO. To force these symbols to be included, we refer to
> them via the __ADDRESSABLE macro in a C file generated from compiled
> built-in.o files before linking.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 15/36] build: link with --build-id=none

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:04PM +0200, Marek Behún wrote:

> Some toolchains are compiled so that they pass a --build-id=something
> parameter to the linker implicitly.
> 
> This causes U-Boot LTO linking to fail with something like:
>   ld: section .note.gnu.build-id LMA ... overlaps section .text LMA ...
> because U-Boot's link scripts do not currently handle .note.gnu.build-id
> section.
> 
> Fix this by explicitly disabling build-id.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 16/36] sandbox: errno: avoid conflict with libc's errno

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:05PM +0200, Marek Behún wrote:

> When building with LTO, the system libc's `errno` variable used in
> arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
> lib/errno.c) with the following error:
>  .../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
>  section .tbss mismatches non-TLS reference in
>/tmp/u-boot.EQlEXz.ltrans0.ltrans.o
> 
> To avoid this conflict use different asm label for this variable when
> CONFIG_SANDBOX is enabled.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 25/36] ARM: fix LTO for keystone

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:14PM +0200, Marek Behún wrote:

> When building keystone with LTO the compiler complains:
>   Error: selected processor does not support `smc #0' in Thumb mode
> 
> Fix this by removing -flto for the file implementing these SMC calls.
> 
> Signed-off-by: Marek Behún 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 26/36] ARM: kona: fix clk_bsc_enable() type mismatch for LTO

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:15PM +0200, Marek Behún wrote:

> When building with LTO, the compiler complains about type mismatch of
> function clk_bsc_enable() in file:
>   arch/arm/cpu/armv7/kona-common/clk-stubs.c
> vs other files that define or use this function:
>   warning: type of ‘clk_bsc_enable’ does not match original declaration.
> 
> Change the type of this function to that of the other usages.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 24/36] ARM: fix LTO for apf27

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:13PM +0200, Marek Behún wrote:

> When apf27_defconfig is built with LTO, linking complains about
> undefined reference to `nand_boot`. This is because it is referenced
> from inline assembly. Make it visible.
> 
> Signed-off-by: Marek Behún 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 22/36] ARM: fix LTO build for some thumb-interwork cases

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:11PM +0200, Marek Behún wrote:

> Fix LTO build for some thumb-interwork usecases (such as for
> da850evm_defconfig), where inline assmebly such as
>   mrc p15,0,r2,c1,c0,0
> causes the compiler to fail during LTO linking with
>   Error: selected processor does not support `mrc p15,0,r2,c1,c0,0'
>  in Thumb mode
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 20/36] ARM: global_data: make set_gd() work for armv5 and armv6

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:09PM +0200, Marek Behún wrote:

> The Thumb instruction `ldr` is able to move high registers only from
> armv7. For armv5 and armv6 we have to use `mov`.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[ANN] U-Boot v2021.07-rc3 released

2021-05-24 Thread Tom Rini
Hey all,

It's release day, and here's v2021.07-rc3.  It's later in the day than I
would have liked, but getting the LTO series in took a bit longer than I
expected.  At this point, for v2021.07 related removal series, I've
posted DM_PCI and DM_USB series, and Anatolij just posted DM_VIDEO
related series.  That just leave DM_SPI_FLASH to sort out, but I think
we'll be in OK shape there.

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

In keeping with my previous plans, I'm going to open -next with -rc4.

I do have my reminders setup for doing -rc releases every other Monday
from here on out and final release on July 5th, 2021.  Thanks all!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] pylibfdt: Rework "avoid unused variable warning" lines

2021-05-24 Thread Tom Rini
On Mon, May 24, 2021 at 11:47:27AM -0400, Tom Rini wrote:

> Clang has -Wself-assign enabled by default under -Wall and so when
> building with -Werror we would get an error here.  Inspired by Linux
> kernel git commit a21151b9d81a ("tools/build: tweak unused value
> workaround") make use of the fact that both Clang and GCC support
> casting to `void` as the method to note that something is intentionally
> unused.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] stackprot: Make our test a bit more complex

2021-05-24 Thread Tom Rini
On Mon, May 24, 2021 at 02:59:13PM -0400, Tom Rini wrote:

> With better compiler optimizations available, a compiler may see we do
> nothing with our buffer after calling memset and omit the call, thus
> causing us to not smash the stack.  Add a comment to explain why we now
> also have a printf call, so that the test will pass as the memset will
> not be omitted.
> 
> Reported-by: Marek Behún 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 07/16] test: Avoid random numbers in dm_test_devm_regmap()

2021-05-24 Thread Tom Rini
On Thu, May 13, 2021 at 07:39:23PM -0600, Simon Glass wrote:

> There is no good reason to use a sequence from rand() here. We may as well
> invent our own sequence.
> 
> This should molify Coverity which does not use rand() being used.
> 
> Signed-off-by: Simon Glass 
> Reported-by: Coverity (CID: 312949)

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:25PM +0200, Marek Behún wrote:

> Enable LTO for some boards that were tested by people on U-Boot Mailing
> List.
> 
> Signed-off-by: Marek Behún 
> Tested-by: Adam Ford 
> Tested-by: Pali Rohár 
> Tested-by: Tim Harvey 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 35/36] ARM: don't use --gc-sections with LTO when using private libgcc

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:24PM +0200, Marek Behún wrote:

> When using LTO, we can throw away the --gc-sections flag, but only if
> using private libgcc.
> 
> When using system's libgcc, --gc-sections is still needed, otherwise
> linking will fail due to undefined references to libc's symbols.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 34/36] ARM: don't use -ffunction-sections/-fdata-sections with LTO build

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:23PM +0200, Marek Behún wrote:

> When building with LTO, using -ffunction-sections/-fdata-sections is not
> useful anymore.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 33/36] ARM: make LTO available

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:22PM +0200, Marek Behún wrote:

> Make LTO available for ARM architecture.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 32/36] ata: ahci: fix ahci_link_up() type mismatch for LTO

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:21PM +0200, Marek Behún wrote:

> When building highbank_defconfig with LTO, the compiler complains about
> type mismatch of function ahci_link_up().
> 
> The third parameter of this function is of type u8 in
> drivers/ata/ahci.c, but of type int in board/highbank/ahci.c.
> 
> There is no reason in using u8, and the code using this function
> actually passes an int variable into the function (so it is implicitly
> converted to u8).
> 
> Change the type of this parameter to int in drivers/ata/ahci.c.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 31/36] armv8: SPL: discard relocation information

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:20PM +0200, Marek Behún wrote:

> For some reason when building SPL for ARMv8 with LTO, the relocation
> information is not discarded.
> 
> Discard it explicitly in the linker script.
> 
> This fixes LTO build for imx8mm_venice_defconfig.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 30/36] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards)

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:19PM +0200, Marek Behún wrote:

> Adam Ford says that DM3730 needs board.c compiled without LTO flags.
> 
> Signed-off-by: Marek Behún 
> Tested-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 29/36] ARM: fix LTO for rockchip and samsung

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:18PM +0200, Marek Behún wrote:

> When building with LTO, the compiler complains about type mismatch of
> function usb_gadget_handle_interrupts(). This function is defined
> without parameters in files
>   arch/arm/mach-rockchip/board.c
>   board/samsung/common/exynos5-dt.c
> but it should have one parameter, int index.
> 
> Fix this.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 
> Reviewed-by: Kever Yang 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 28/36] ARM: fix LTO for seaboard

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:17PM +0200, Marek Behún wrote:

> When seaboard_defconfig is compiled with LTO, the compiler complains
> about some instructions not being supported in ARM mode.
> 
> This is caused by arch/arm/mach-tegra/tegra20/warmboot_avp.c having
> different CFLAGS declared in Makefile. This file needs to be compiled
> without LTO.
> 
> Fix this by removing -flto for this file.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 27/36] ARM: imx8m: fix imx_eqos_txclk_set_rate() type mismatch for LTO

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:16PM +0200, Marek Behún wrote:

> When building imx8mp_evk_defconfig with LTO, the compiler complains
> about type mismatch of function imx_eqos_txclk_set_rate() in file
>   drivers/net/dwc_eth_qos.c:845:12
> which contains a weak definition of this function, vs file
>   arch/arm/mach-imx/imx8m/clock_imx8mm.c
> which contains an implementation.
> 
> Change the type of this function in the implementation to fix this.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 21/36] ARM: make gd a function call for LTO and set via set_gd()

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:10PM +0200, Marek Behún wrote:

> On ARM, the gd pointer is stored in registers r9 / x18. For this the
> -ffixed-r9 / -ffixed-x18 flag is used when compiling, but using global
> register variables causes errors when building with LTO, and these
> errors are very difficult to overcome.
> 
> Richard Biener says [1]:
>   Note that global register vars shouldn't be used with LTO and if they
>   are restricted to just a few compilation units the recommended fix is
>   to build those CUs without -flto.
> 
> We cannot do this for U-Boot since all CUs use -ffixed-reg flag.
> 
> It seems that with LTO we could in fact store the gd pointer differently
> and gain performance or size benefit by allowing the compiler to use
> r9 / x18. But this would need more work.
> 
> So for now, when building with LTO, go the clang way, and instead of
> declaring gd a global register variable, we make it a function call via
> macro.
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68384
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 23/36] ARM: fix LTO for imx28_xea

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:12PM +0200, Marek Behún wrote:

> When imx28_xea_defconfig is built with LTO, the compiler complains about
> the two different declarations of _start:
>include/asm-generic/sections.has  extern void _start(void);
>arch/arm/cpu/arm926ejs/mxs/mxs.c  as  extern uint32_t _start;
> 
> Fix this.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 19/36] sandbox: enable LTO by default

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:08PM +0200, Marek Behún wrote:

> Build sandbox targets with LTO by default.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 18/36] sandbox: make LTO available

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:07PM +0200, Marek Behún wrote:

> Make LTO available for sandbox architecture.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 13/36] build: use thin archives instead of incremental linking

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:02PM +0200, Marek Behún wrote:

> Currently we use incremental linking (ld -r) to link several object
> files from one directory into one built-in.o object file containing the
> linked code from that directory (and its subdirectories).
> 
> Linux has, some time ago, moved to thin archives instead.
> 
> Thin archives are archives (.a) that do not really contain the object
> files, only references to them.
> 
> Using thin archives instead of incremental linking
> - saves disk space
> - apparently works better with dead code elimination
> - makes things easier for LTO
> 
> The third point is the important one for us. With incremental linking
> there are several options how to do LTO, and that would unnecessarily
> complicate things.
> 
> We have to use the --whole-archive/--no-whole-archive linking option
> instead of --start-group/--end-group, otherwise linking may fail because
> of unresolved symbols, or the resulting binary will be unusable.
> 
> We also need to use the P flag for ar, otherwise final linking may fail.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 12/36] Makefile, Makefile.spl: cosmetic change

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:01PM +0200, Marek Behún wrote:

> Indent the linking commands so that they look cosmetically better.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 12/36] Makefile, Makefile.spl: cosmetic change

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:01PM +0200, Marek Behún wrote:

> Indent the linking commands so that they look cosmetically better.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 11/36] lib: crc32: put the crc_table variable into efi_runtime_rodata section

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:24:00PM +0200, Marek Behún wrote:

> When compiling with LTO, the compiler fails with an error saying that
> `crc_table` causes a section type conflict with `efi_var_buf`.
> 
> This is because both are declared to be in the same section (via macro
> `__efi_runtime_data`), but one is const while the other is not.
> 
> Put this variable into the section .rodata.efi_runtime, instead of
> .data.efi_runtime, via macro __efi_runtime_rodata.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Marek Vasut 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 10/36] efi_selftest: compiler flags for efi_selftest_miniapp_exception.o

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:59PM +0200, Marek Behún wrote:

> Add $(CFLAGS_EFI) and remove $(CFLAGS_NON_EFI) for
> efi_selftest_miniapp_exception.o.
> 
> The removal is needed when compiling with LTO - this object file needs
> to be compiled without -flto.
> 
> The adding is for consistency with other miniapps.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 09/36] efi_loader: add macro for const EFI runtime data

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:58PM +0200, Marek Behún wrote:

> Add macro __efi_runtime_rodata, for const variables with similar purpose
> as those using __efi_runtime_data.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 08/36] efi_loader: add Sphinx doc for __efi_runtime and __efi_runtime_data

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:57PM +0200, Marek Behún wrote:

> Document the macros __efi_runtime and __efi_runtime_data in Sphinx
> style.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 07/36] efi_loader: fix warning when linking with LTO

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:56PM +0200, Marek Behún wrote:

> When linking with LTO, the compiler complains about type mismatch of
> variables `__efi_runtime_start`, `__efi_runtime_stop`,
> `__efi_runtime_rel_start` and `__efi_runtime_rel_stop`:
> 
>  include/efi_loader.h:218:21: warning: type of ‘__efi_runtime_start’
>does not match original
>declaration [-Wlto-type-mismatch]
> 218 | extern unsigned int __efi_runtime_start, __efi_runtime_stop;
> | ^
>   arch/sandbox/lib/sections.c:7:6: note: ‘__efi_runtime_start’ was
>  previously declared here
>   7 | char __efi_runtime_start[0] __attribute__((section(".__efi_run
> |  ^
> 
> Change the type to char[] in include/efi_loader.h.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 06/36] string: make memcpy(), memset(), memcmp() and memmove() visible for LTO

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:55PM +0200, Marek Behún wrote:

> It seems that sometimes (happening on ARM64, for example with
> turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> names of some functions, for example lib/string.c's memcpy() function to
> memcpy.isra.0.
> 
> This is a problem however when GCC for a code such as this:
>   struct some_struct *info = get_some_struct();
>   struct some struct tmpinfo;
>   tmpinfo = *info;
> emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> 
> This then results in the following linking error:
>   .../lz4.c:93: undefined reference to `memcpy'
>   .../uuid.c:206: more undefined references to `memcpy' follow
> 
> GCC's documentation says this about -nodefaultlibs option:
>   The compiler may generate calls to "memcmp", "memset", "memcpy" and
>   "memmove".  These entries are usually resolved by entries in libc.
>   These entry points should be supplied through some other mechanism
>   when this option is specified.
> 
> Make these functions visible by using the __used macro to avoid this
> error.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 05/36] test/py: improve regular expression for ut subtest symbol matcher

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:54PM +0200, Marek Behún wrote:

> Improve the regular expression that matches unittest symbols in
> u-boot.sym.
> 
> Currently we do not enforce no prefix in symbol string, but with the
> soon to come change in linker lists declaring lists and entries with the
> __ADDRESSABLE macro (because of LTO), the symbol file will contain for
> every symbol of the form
>   _u_boot_list_2_ut_X_2_Y
> also symbol
>   __UNIQUE_ID___addressable__u_boot_list_2_ut_X_2_YN,
> (where N at the end is some number).
> 
> In order to avoid matching these additional symbols, ensure that the
> character before "_u_boot_list_2_ut" is not a symbol name character.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 04/36] compiler.h: align the __ADDRESSABLE macro with Linux' version

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:53PM +0200, Marek Behún wrote:

> Use UNIQUE_ID in the __ADDRESSABLE macro.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 02/36] checkpatch: require quotes around section name in the __section() macro

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:51PM +0200, Marek Behún wrote:

> This is how Linux does this now, see Linux commit 339f29d91acf.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 03/36] treewide: Convert macro and uses of __section(foo) to __section("foo")

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:52PM +0200, Marek Behún wrote:

> This commit does the same thing as Linux commit 33def8498fdd.
> 
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
> 
> Remove the quote operator # from compiler_attributes.h __section macro.
> 
> Convert all unquoted __section(foo) uses to quoted __section("foo").
> Also convert __attribute__((section("foo"))) uses to __section("foo")
> even if the __attribute__ has multiple list entry forms.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 01/36] regmap: fix a serious pointer casting bug

2021-05-24 Thread Tom Rini
On Thu, May 20, 2021 at 01:23:50PM +0200, Marek Behún wrote:

> There is a serious bug in regmap_read() and regmap_write() functions
> where an uint pointer is cast to (void *) which is then cast to (u8 *),
> (u16 *), (u32 *) or (u64 *), depending on register width of the map.
> 
> For example given a regmap with 16-bit register width the code
>   int val = 0x1234;
>   regmap_read(map, 0, );
> only changes the lower 16 bits of val on little-endian machines.
> The upper 16 bits will remain 0x1234.
> 
> Nobody noticed this probably because this bug can be triggered with
> regmap_write() only on big-endian architectures (which are not used by
> many people anymore), and on little endian this bug has consequences
> only if register width is 8 or 16 bits and also the memory place to
> which regmap_read() should store it's result has non-zero upper bits,
> which it seems doesn't happen anywhere in U-Boot normally. CI managed to
> trigger this bug in unit test of dm_test_devm_regmap_field when compiled
> for sandbox_defconfig using LTO.
> 
> Fix this by utilizing an union { u8; u16; u32; u64; } and reading data
> into this union / writing data from this union.
> 
> Signed-off-by: Marek Behún 
> Cc: Simon Glass 
> Cc: Heiko Schocher 
> Cc: Bin Meng 
> Cc: Pratyush Yadav 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


sdhci_data_transfer: Trasnfer data timeout

2021-05-24 Thread aregaard
Hi,
I have made a custom board based on ARM A53.
I use a NOR-flash, eMMC and DDR3.

I can start the Uboot from NOR and communicate with the eMMC. 
But for some reason it is timing out the first time I connect to the eMMC.


*(CLK =25MHz)*
=> run mmc_format
eMMC: INT_STATUS = 00018000
eMMC: INT_STATUS = 00018001
sdhci_transfer_data: Transfer data timeout
sdhci_transfer_data: Transfer data timeout

After this part it can communicate:

*(CLK = 50MHz)*
success!
Writing GPT: success!
Saving Environment to SPI Flash... SF: Detected n25q128a13 with page size
256 Bytes, erase size 4 KiB, total 16 MiB
Erasing SPI flash...Writing to SPI flash...done
Valid environment: 1
OK

This Timeout might cause problems with the DDR3 (I am having problems with
the Kernel not booting corretly). I think there is an issue with the
communication with the eMMC and DDR, due to the timeout.

What can generate the timing-out-issue? 

To make it clear; I can communicate with the eMMC. The first time it is
really slow and is timing out with 25 MHz FLASH-clk. The second time it goes
directly into sync:

=> run mmc_format
success!
Writing GPT: success!
Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI
flash...done
Valid environment: 2
OK

I sounds like a HW-issue, but what can cause this in the code?

If I reset the system it is timing out again the first time.

Kind Regards



--
Sent from: http://u-boot.10912.n7.nabble.com/


[PATCH 7/8] mmc: sunxi: Increase MMIO FIFO read performance

2021-05-24 Thread Andre Przywara
To avoid the complexity of DMA operations (with chained descriptors), we
use repeated MMIO reads and writes to the SD_FIFO_REG, which allows us
to drain or fill the MMC data buffer FIFO very easily.

However those MMIO accesses are somewhat costly, so this limits our MMC
performance, to between 17 and 22 MB/s, but down to 9.5 MB/s on the H6
(partly due to the lower AHB1 frequency).

As it turns out we read the FIFO status register after *every* word we
read or write, which effectively doubles the number of MMIO accesses,
thus effectively more than halving our performance.

To avoid this overhead, we can make use of the FIFO level bits, which are
in the very same FIFO status registers.
So for a read request, we now can collect as many words as the FIFO
level originally indicated, and only then need to update the status
register.

We don't know for sure the size of the FIFO (and it seems to differ
across SoCs anyway), so writing is more fragile, which is why we still
use the old method for that. If we find a minimum FIFO size available on
all SoCs, we could use that, in a later optimisation.

This patch increases the eMMC read speed on a Pine64-LTS from about
22MB/s to 44 MB/s. SD card reads don't gain that much, but with 23 MB/s
we now reach the practical limit for 3.3V SD cards.
On the H6 we double our transfer speed, from 9.5 MB/s to 19.7 MB/s.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/mmc.h |  1 +
 drivers/mmc/sunxi_mmc.c   | 39 +--
 2 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 340e25b04d2..5daacf10eb1 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -119,6 +119,7 @@ struct sunxi_mmc {
 #define SUNXI_MMC_STATUS_CARD_PRESENT  (0x1 << 8)
 #define SUNXI_MMC_STATUS_CARD_DATA_BUSY(0x1 << 9)
 #define SUNXI_MMC_STATUS_DATA_FSM_BUSY (0x1 << 10)
+#define SUNXI_MMC_STATUS_FIFO_LEVEL(reg)   (((reg) >> 17) & 0x3fff)
 
 #define SUNXI_MMC_NTSR_MODE_SEL_NEW(0x1 << 31)
 
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index a30fd8fbdb1..115b519546e 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -311,8 +311,9 @@ static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv 
*priv, struct mmc *mmc,
  SUNXI_MMC_STATUS_FIFO_FULL;
unsigned i;
unsigned *buff = (unsigned int *)(reading ? data->dest : data->src);
-   unsigned byte_cnt = data->blocksize * data->blocks;
-   unsigned timeout_msecs = byte_cnt >> 8;
+   unsigned word_cnt = (data->blocksize * data->blocks) >> 2;
+   unsigned timeout_msecs = word_cnt >> 6;
+   uint32_t status;
unsigned long  start;
 
if (timeout_msecs < 2000)
@@ -323,16 +324,38 @@ static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv 
*priv, struct mmc *mmc,
 
start = get_timer(0);
 
-   for (i = 0; i < (byte_cnt >> 2); i++) {
-   while (readl(>reg->status) & status_bit) {
+   for (i = 0; i < word_cnt;) {
+   unsigned int in_fifo;
+
+   while ((status = readl(>reg->status)) & status_bit) {
if (get_timer(start) > timeout_msecs)
return -1;
}
 
-   if (reading)
-   buff[i] = readl(>reg->fifo);
-   else
-   writel(buff[i], >reg->fifo);
+   /*
+* For writing we do not easily know the FIFO size, so have
+* to check the FIFO status after every word written.
+* TODO: For optimisation we could work out a minimum FIFO
+* size across all SoCs, and use that together with the current
+* fill level to write chunks of words.
+*/
+   if (!reading) {
+   writel(buff[i++], >reg->fifo);
+   continue;
+   }
+
+   /*
+* The status register holds the current FIFO level, so we
+* can be sure to collect as many words from the FIFO
+* register without checking the status register after every
+* read. That saves half of the costly MMIO reads, effectively
+* doubling the read performance.
+*/
+   for (in_fifo = SUNXI_MMC_STATUS_FIFO_LEVEL(status);
+in_fifo > 0;
+in_fifo--)
+   buff[i++] = readl_relaxed(>reg->fifo);
+   dmb();
}
 
return 0;
-- 
2.17.5



[PATCH 8/8] mmc: sunxi: Use mmc_of_parse()

2021-05-24 Thread Andre Przywara
At the moment the Allwinner MMC driver parses the bus-width and
non-removable DT properties itself, in the probe() routine.

There is actually a generic function provided by the MMC framework doing
this job, also it parses more generic properties like broken-cd and
advanced transfer modes.

Drop our own code and call mmc_of_parse() instead, to get all new
features for free.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 115b519546e..178b8cf106d 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -37,7 +37,6 @@ struct sunxi_mmc_priv {
uint32_t *mclkreg;
unsigned fatal_err;
struct gpio_desc cd_gpio;   /* Change Detect GPIO */
-   int cd_inverted;/* Inverted Card Detect */
struct sunxi_mmc *reg;
struct mmc_config cfg;
 };
@@ -612,12 +611,21 @@ static int sunxi_mmc_send_cmd(struct udevice *dev, struct 
mmc_cmd *cmd,
 
 static int sunxi_mmc_getcd(struct udevice *dev)
 {
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
struct sunxi_mmc_priv *priv = dev_get_priv(dev);
 
+   /* If polling, assume that the card is always present. */
+   if ((mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE) ||
+   (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL))
+   return 1;
+
if (dm_gpio_is_valid(>cd_gpio)) {
int cd_state = dm_gpio_get_value(>cd_gpio);
 
-   return cd_state ^ priv->cd_inverted;
+   if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
+   return !cd_state;
+   else
+   return cd_state;
}
return 1;
 }
@@ -649,23 +657,21 @@ static int sunxi_mmc_probe(struct udevice *dev)
struct mmc_config *cfg = >cfg;
struct ofnode_phandle_args args;
u32 *ccu_reg;
-   int bus_width, ret;
+   int ret;
 
cfg->name = dev->name;
-   bus_width = dev_read_u32_default(dev, "bus-width", 1);
 
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
-   cfg->host_caps = 0;
-   if (bus_width == 8)
-   cfg->host_caps |= MMC_MODE_8BIT;
-   if (bus_width >= 4)
-   cfg->host_caps |= MMC_MODE_4BIT;
-   cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
+   cfg->host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS;
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
cfg->f_min = 40;
cfg->f_max = 5200;
 
+   ret = mmc_of_parse(dev, cfg);
+   if (ret)
+   return ret;
+
priv->reg = dev_read_addr_ptr(dev);
 
/* We don't have a sunxi clock driver so find the clock address here */
@@ -691,17 +697,13 @@ static int sunxi_mmc_probe(struct udevice *dev)
return ret;
 
/* This GPIO is optional */
-   if (!dev_read_bool(dev, "non-removable") &&
-   !gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
+   if (!gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
  GPIOD_IS_IN)) {
int cd_pin = gpio_get_number(>cd_gpio);
 
sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
}
 
-   /* Check if card detect is inverted */
-   priv->cd_inverted = dev_read_bool(dev, "cd-inverted");
-
upriv->mmc = >mmc;
 
/* Reset controller */
-- 
2.17.5



[PATCH 6/8] mmc: sunxi: Cleanup and fix self-calibration code

2021-05-24 Thread Andre Przywara
Newer SoCs have a self calibration feature, which avoids us writing hard
coded phase delay values into the controller.

Consolidate the code by avoiding unnecessary #ifdefs, and also enabling
the feature for all those newer SoCs.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 33cedb4edba..a30fd8fbdb1 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -103,21 +103,29 @@ static int mmc_resource_init(int sdc_no)
 }
 #endif
 
+/*
+ * All A64 and later MMC controllers feature auto-calibration. This would
+ * normally be detected via the compatible string, but we need something
+ * which works in the SPL as well.
+ */
+static bool sunxi_mmc_can_calibrate(void)
+{
+   return IS_ENABLED(CONFIG_MACH_SUN50I) ||
+  IS_ENABLED(CONFIG_MACH_SUN50I_H5) ||
+  IS_ENABLED(CONFIG_SUN50I_GEN_H6) ||
+  IS_ENABLED(CONFIG_MACH_SUN8I_R40);
+}
+
 static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
 {
unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
bool new_mode = IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE);
-   bool calibrate = false;
u32 val = 0;
 
/* A83T support new mode only on eMMC */
if (IS_ENABLED(CONFIG_MACH_SUN8I_A83T) && priv->mmc_no != 2)
new_mode = false;
 
-#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_SUN50I_GEN_H6)
-   calibrate = true;
-#endif
-
if (hz <= 2400) {
pll = CCM_MMC_CTRL_OSCM24;
pll_hz = 2400;
@@ -179,7 +187,9 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
if (new_mode) {
val |= CCM_MMC_CTRL_MODE_SEL_NEW;
setbits_le32(>reg->ntsr, SUNXI_MMC_NTSR_MODE_SEL_NEW);
-   } else if (!calibrate) {
+   }
+
+   if (!sunxi_mmc_can_calibrate()) {
/*
 * Use hardcoded delay values if controller doesn't support
 * calibration
@@ -237,14 +247,15 @@ static int mmc_config_clock(struct sunxi_mmc_priv *priv, 
struct mmc *mmc)
rval &= ~SUNXI_MMC_CLK_DIVIDER_MASK;
writel(rval, >reg->clkcr);
 
-#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_SUN50I_GEN_H6)
+#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
/* A64 supports calibration of delays on MMC controller and we
 * have to set delay of zero before starting calibration.
 * Allwinner BSP driver sets a delay only in the case of
 * using HS400 which is not supported by mainline U-Boot or
 * Linux at the moment
 */
-   writel(SUNXI_MMC_CAL_DL_SW_EN, >reg->samp_dl);
+   if (sunxi_mmc_can_calibrate())
+   writel(SUNXI_MMC_CAL_DL_SW_EN, >reg->samp_dl);
 #endif
 
/* Re-enable Clock */
-- 
2.17.5



[PATCH 5/8] mmc: sunxi: Enable "new timing mode" on all new SoCs

2021-05-24 Thread Andre Przywara
All SoCs since the Allwinner A64 (H5, H6, R40, H616) feature the so
called "new timing mode", so enable this in Kconfig for those SoCs.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index bc8509b72a2..b8abe2fefa9 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -152,6 +152,7 @@ config SUN50I_GEN_H6
bool
select FIT
select SPL_LOAD_FIT
+   select MMC_SUNXI_HAS_NEW_MODE
select SUPPORT_SPL
---help---
Select this for sunxi SoCs which have H6 like peripherals, clocks
@@ -297,6 +298,7 @@ config MACH_SUN8I_R40
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
+   select MMC_SUNXI_HAS_NEW_MODE
select SUPPORT_SPL
select SUNXI_DRAM_DW
select SUNXI_DRAM_DW_32BIT
@@ -346,6 +348,7 @@ config MACH_SUN50I_H5
bool "sun50i (Allwinner H5)"
select ARM64
select MACH_SUNXI_H3_H5
+   select MMC_SUNXI_HAS_NEW_MODE
select FIT
select SPL_LOAD_FIT
 
-- 
2.17.5



[PATCH 4/8] mmc: sunxi: Cleanup "new timing mode" selection

2021-05-24 Thread Andre Przywara
Among the SoCs using the "new timing mode", only the A83T needs to
explicitly switch to that mode.

By just defining the symbol for that one odd A83T bit to 0 for any other
SoCs, we can always OR that in, and save the confusing nested #ifdefs.

Clean up the also confusing new_mode setting on the way.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index bc68debdad6..33cedb4edba 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -23,6 +23,10 @@
 #include 
 #include 
 
+#ifndef CCM_MMC_CTRL_MODE_SEL_NEW
+#define CCM_MMC_CTRL_MODE_SEL_NEW  0
+#endif
+
 struct sunxi_mmc_plat {
struct mmc_config cfg;
struct mmc mmc;
@@ -102,13 +106,10 @@ static int mmc_resource_init(int sdc_no)
 static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
 {
unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
-   bool new_mode = true;
+   bool new_mode = IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE);
bool calibrate = false;
u32 val = 0;
 
-   if (!IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE))
-   new_mode = false;
-
/* A83T support new mode only on eMMC */
if (IS_ENABLED(CONFIG_MACH_SUN8I_A83T) && priv->mmc_no != 2)
new_mode = false;
@@ -176,12 +177,8 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
}
 
if (new_mode) {
-#ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
-#ifdef CONFIG_MMC_SUNXI_HAS_MODE_SWITCH
-   val = CCM_MMC_CTRL_MODE_SEL_NEW;
-#endif
+   val |= CCM_MMC_CTRL_MODE_SEL_NEW;
setbits_le32(>reg->ntsr, SUNXI_MMC_NTSR_MODE_SEL_NEW);
-#endif
} else if (!calibrate) {
/*
 * Use hardcoded delay values if controller doesn't support
-- 
2.17.5



[PATCH 3/8] mmc: sunxi: Fix MMC clock parent selection

2021-05-24 Thread Andre Przywara
Most Allwinner SoCs which use the so called "new timing mode" in their
MMC controllers actually use the double-rate PLL6/PERIPH0 clock as their
parent input clock. This is interestingly enough compensated by a hidden
"by 2" post-divider in the mod clock, so the divider and actual output
rate stay the same.

Even though for the H6 and H616 (but only for them!) we use the doubled
input clock for the divider computation, we never accounted for the
implicit post-divider, so the clock was only half the speed on those SoCs.
This didn't really matter so far, as our slow MMIO routine limits the
transfer speed anyway, but we will fix this soon.

Clean up the code around that selection, to always use the normal PLL6
(PERIPH0(1x)) clock as an input. As the rate and divider are the same,
that makes no difference.
Explain the hardware differences in a comment.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h |  2 +-
 drivers/mmc/sunxi_mmc.c   | 10 +++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index 62abfc4ef6b..e000f78ff45 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -326,7 +326,7 @@ struct sunxi_ccm_reg {
 #define CCM_MMC_CTRL_M(x)  ((x) - 1)
 #define CCM_MMC_CTRL_N(x)  ((x) << 8)
 #define CCM_MMC_CTRL_OSCM24(0x0 << 24)
-#define CCM_MMC_CTRL_PLL6X2(0x1 << 24)
+#define CCM_MMC_CTRL_PLL6  (0x1 << 24)
 #define CCM_MMC_CTRL_PLL_PERIPH2X2 (0x2 << 24)
 #define CCM_MMC_CTRL_ENABLE(0x1 << 31)
 /* H6 doesn't have these delays */
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 869af993d35..bc68debdad6 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -124,10 +124,14 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
 #ifdef CONFIG_MACH_SUN9I
pll = CCM_MMC_CTRL_PLL_PERIPH0;
pll_hz = clock_get_pll4_periph0();
-#elif defined(CONFIG_SUN50I_GEN_H6)
-   pll = CCM_MMC_CTRL_PLL6X2;
-   pll_hz = clock_get_pll6() * 2;
 #else
+   /*
+* SoCs since the A64 (H5, H6, H616) actually use the doubled
+* rate of PLL6/PERIPH0 as an input clock, but compensate for
+* that with a fixed post-divider of 2 in the mod clock.
+* This cancels each other out, so for simplicity we just
+* pretend it's always PLL6 without a post divider here.
+*/
pll = CCM_MMC_CTRL_PLL6;
pll_hz = clock_get_pll6();
 #endif
-- 
2.17.5



[PATCH 2/8] mmc: sunxi: Fix warnings with CONFIG_PHYS_64BIT

2021-05-24 Thread Andre Przywara
When enabling PHYS_64BIT on 32-bit platforms, we get two warnings about
pointer casts in sunxi_mmc.c. Those are related to MMIO addresses, which
are always below 1GB on all Allwinner SoCs, so there is no problem with
anything having more than 32 bits.

Add the proper casts to make it compile cleanly.

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

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 87b79fcf5ef..869af993d35 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -631,14 +631,14 @@ static int sunxi_mmc_probe(struct udevice *dev)
cfg->f_min = 40;
cfg->f_max = 5200;
 
-   priv->reg = (void *)dev_read_addr(dev);
+   priv->reg = dev_read_addr_ptr(dev);
 
/* We don't have a sunxi clock driver so find the clock address here */
ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
  1, );
if (ret)
return ret;
-   ccu_reg = (u32 *)ofnode_get_addr(args.node);
+   ccu_reg = (u32 *)(uintptr_t)ofnode_get_addr(args.node);
 
priv->mmc_no = ((uintptr_t)priv->reg - SUNXI_MMC0_BASE) / 0x1000;
priv->mclkreg = (void *)ccu_reg + get_mclk_offset() + priv->mmc_no * 4;
-- 
2.17.5



[PATCH 1/8] mmc: sunxi: Avoid #ifdefs in delay and width setup

2021-05-24 Thread Andre Przywara
The delay and bus-width setup are slightly different across the
Allwinner SoC generations, and we covered this so far with some
preprocessor conditionals.

Use the more readable IS_ENABLE() instead.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 33 +++--
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 3503ccdb2ee..87b79fcf5ef 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -156,23 +156,19 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
} else if (hz <= 2500) {
oclk_dly = 0;
sclk_dly = 5;
-#ifdef CONFIG_MACH_SUN9I
-   } else if (hz <= 5200) {
-   oclk_dly = 5;
-   sclk_dly = 4;
-   } else {
-   /* hz > 5200 */
-   oclk_dly = 2;
-   sclk_dly = 4;
-#else
-   } else if (hz <= 5200) {
-   oclk_dly = 3;
-   sclk_dly = 4;
} else {
-   /* hz > 5200 */
-   oclk_dly = 1;
+   if (IS_ENABLED(CONFIG_MACH_SUN9I)) {
+   if (hz <= 5200)
+   oclk_dly = 5;
+   else
+   oclk_dly = 2;
+   } else {
+   if (hz <= 5200)
+   oclk_dly = 3;
+   else
+   oclk_dly = 1;
+   }
sclk_dly = 4;
-#endif
}
 
if (new_mode) {
@@ -521,10 +517,11 @@ struct mmc *sunxi_mmc_init(int sdc_no)
 
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
cfg->host_caps = MMC_MODE_4BIT;
-#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) || 
defined(CONFIG_SUN50I_GEN_H6)
-   if (sdc_no == 2)
+
+   if ((IS_ENABLED(CONFIG_MACH_SUN50I) || IS_ENABLED(CONFIG_MACH_SUN8I) ||
+   IS_ENABLED(CONFIG_SUN50I_GEN_H6)) && (sdc_no == 2))
cfg->host_caps = MMC_MODE_8BIT;
-#endif
+
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
-- 
2.17.5



[PATCH 0/8] sunxi: mmc: Fixes and speed increase

2021-05-24 Thread Andre Przywara
While debugging some eMMC problem on the H616 SoC, I stumbled upon some
weird code in the Allwinner MMC driver. Some closer inspection and some
help from Ondrej later this series of fixes emerged:
Some patches remove part of the #ifdef hell we needlessly had in the
driver.
A big chunk is around the "new timing mode", which all "newer" SoCs
(since around 2015) have, and which requires some extra bit to be set. We
didn't enable this mode for all SoCs, this is now fixed in patches 3-6.
Patch 7 fixes a big performance problem we had due to using MMIO accesses
for the actual data transfer, as opposed to DMA transfers used in Linux.
Short from adding a lot of code to use DMA as well, we can actually halve
the number of MMIO accesses on reads, effectively doubling the bus
transfer performance. This helps the H6 a lot, but also improves the eMMC
read performance.
The final patch makes use of some generic MMC DT code, to parse generic
DT properties. This allows us to remove sunxi specific code, but also
adds support for "broken-cd" and more advanced MMC speed modes.

Please have a look and test this code on as many boards as possible.
While a performance increase is nice, we don't want to risk data
integrity over this, so please try to verify that it still works for
you.

Cheers,
Andre.

P.S. Patches 5 and 6 use different approaches to differentiate between
SoCs specific quirks: Patch 5/8 selects an explicit symbol from the
SoC specific sections in our Kconfig file, while patch 6/8 compares
the selected SoC type in the C code. Please let me know which approach
is better, I can then use this for both patches (and in the future).

Andre Przywara (8):
  mmc: sunxi: Avoid #ifdefs in delay and width setup
  mmc: sunxi: Fix warnings with CONFIG_PHYS_64BIT
  mmc: sunxi: Fix MMC clock parent selection
  mmc: sunxi: Cleanup "new timing mode" selection
  mmc: sunxi: Enable "new timing mode" on all new SoCs
  mmc: sunxi: Cleanup and fix self-calibration code
  mmc: sunxi: Increase MMIO FIFO read performance
  mmc: sunxi: Use mmc_of_parse()

 .../include/asm/arch-sunxi/clock_sun50i_h6.h  |   2 +-
 arch/arm/include/asm/arch-sunxi/mmc.h |   1 +
 arch/arm/mach-sunxi/Kconfig   |   3 +
 drivers/mmc/sunxi_mmc.c   | 160 +++---
 4 files changed, 102 insertions(+), 64 deletions(-)

-- 
2.17.5



Re: [PATCH v2] tee: optee: sync cache on pre-reloc OP-TEE invocation

2021-05-24 Thread Ilias Apalodimas
On Wed, May 19, 2021 at 04:27:41PM +0200, Etienne Carriere wrote:
> This change ensures both U-Boot and OP-TEE see the same content
> from shared memory when OP-TEE is invoked prior U-Boot relocation.
> 
> This change is required since U-Boot may execute with data cahce off
> while OP-TEE always enables cache on memory shared with U-Boot.
> 
> Signed-off-by: Etienne Carriere 
> ---
> Changes since v1:
> - Fix invocation argument buffer size in optee/core.c, using
>   OPTEE_MSG_GET_ARG_SIZE().
> - add missing #include  in tee-uclass.c
> ---
>  drivers/tee/optee/core.c | 21 -
>  drivers/tee/tee-uclass.c | 19 ++-
>  include/tee.h|  6 ++
>  3 files changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 73dbb22ba0..dad46aa388 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -1,9 +1,10 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * Copyright (c) 2018 Linaro Limited
> + * Copyright (c) 2018-2020 Linaro Limited
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -295,6 +296,16 @@ static u32 call_err_to_res(u32 call_err)
>   }
>  }
>  
> +static void flush_shm_dcache(struct udevice *dev, struct optee_msg_arg *arg)
> +{
> + size_t sz = OPTEE_MSG_GET_ARG_SIZE(arg->num_params);
> +
> + flush_dcache_range(rounddown((ulong)arg, CONFIG_SYS_CACHELINE_SIZE),
> +roundup((ulong)arg + sz, CONFIG_SYS_CACHELINE_SIZE));
> +
> + tee_flush_all_shm_dcache(dev);
> +}
> +
>  static u32 do_call_with_arg(struct udevice *dev, struct optee_msg_arg *arg)
>  {
>   struct optee_pdata *pdata = dev_get_plat(dev);
> @@ -305,9 +316,17 @@ static u32 do_call_with_arg(struct udevice *dev, struct 
> optee_msg_arg *arg)
>   while (true) {
>   struct arm_smccc_res res;
>  
> + /* If cache are off from U-Boot, sync the cache shared with 
> OP-TEE */
> + if (!dcache_status())
> + flush_shm_dcache(dev, arg);
> +
>   pdata->invoke_fn(param.a0, param.a1, param.a2, param.a3,
>param.a4, param.a5, param.a6, param.a7, );
>  
> + /* If cache are off from U-Boot, sync the cache shared with 
> OP-TEE */
> + if (!dcache_status())
> + flush_shm_dcache(dev, arg);
> +
>   free(page_list);
>   page_list = NULL;
>  
> diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
> index 2cc6b6c407..24321ba1d2 100644
> --- a/drivers/tee/tee-uclass.c
> +++ b/drivers/tee/tee-uclass.c
> @@ -1,13 +1,15 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * Copyright (c) 2018 Linaro Limited
> + * Copyright (c) 2018-2020 Linaro Limited
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -233,3 +235,18 @@ void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
>   d[7] = s->time_hi_and_version;
>   memcpy(d + 8, s->clock_seq_and_node, sizeof(s->clock_seq_and_node));
>  }
> +
> +void tee_flush_all_shm_dcache(struct udevice *dev)
> +{
> + struct tee_uclass_priv *priv = dev_get_uclass_priv(dev);
> + struct tee_shm *s;
> +
> + list_for_each_entry(s, >list_shm, link) {
> + ulong start = rounddown((ulong)s->addr,
> + CONFIG_SYS_CACHELINE_SIZE);
> + ulong end = roundup((ulong)s->addr + s->size,
> + CONFIG_SYS_CACHELINE_SIZE);
> +
> + flush_dcache_range(start, end);
> + }
> +}
> diff --git a/include/tee.h b/include/tee.h
> index 99367b258e..2ef29bfc8f 100644
> --- a/include/tee.h
> +++ b/include/tee.h
> @@ -377,4 +377,10 @@ void tee_optee_ta_uuid_from_octets(struct 
> tee_optee_ta_uuid *d,
>  void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
>const struct tee_optee_ta_uuid *s);
>  
> +/**
> + * tee_flush_all_shm_dcache() - Flush data cache for all shared memories
> + * @dev: The TEE device
> + */
> +void tee_flush_all_shm_dcache(struct udevice *dev);
> +
>  #endif /* __TEE_H */
> -- 
> 2.17.1
> 

Acked-by: Ilias Apalodimas 



[PATCH] tools: Use a single target-independent config to enable OpenSSL

2021-05-24 Thread Alexandru Gagniuc
Host tool features, such as mkimage's ability to sign FIT images were
enabled or disabled based on the target configuration. However, this
misses the point of a target-agnostic host tool.

A target's ability to verify FIT signatures is independent of
mkimage's ability to create those signatures. In fact, u-boot's build
system doesn't sign images. The target code can be successfully built
without relying on any ability to sign such code.

Conversely, mkimage's ability to sign images does not require that
those images will only work on targets which support FIT verification.
Linking mkimage cryptographic features to target support for FIT
verification is misguided.

Without loss of generality, we can say that host features are and
should be independent of target features.

While we prefer that a host tool always supports the same feature set,
we recognize the following
  - some users prefer to build u-boot without a dependency on OpenSSL.
  - some distros prefer to ship mkimage without linking to OpenSSL

To allow these use cases, introduce a host-only Kconfig which is used
to select or deselect libcrypto support. Some mkimage features or some
host tools might not be available, but this shouldn't affect the
u-boot build.

I also considered setting the default of this config based on
FIT_SIGNATURE. While it would preserve the old behaviour it's also
contrary to the goals of this change. I decided to enable it by
default, so that the default build yields the most feature-complete
mkimage.

Signed-off-by: Alexandru Gagniuc 
---

This patch is designed to apply on top of
[PATCH v2 00/18] image: Reduce #ifdef abuse in image code



 tools/Kconfig  | 11 +++
 tools/Makefile | 46 ++
 2 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/tools/Kconfig b/tools/Kconfig
index b2f5012240..214932ae30 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -9,4 +9,15 @@ config MKIMAGE_DTC_PATH
  some cases the system dtc may not support all required features
  and the path to a different version should be given here.
 
+config TOOLS_USE_LIBCRYPTO
+   bool "Use OpenSSL's libcrypto library for host tools"
+   default y
+   help
+ Cryptographic signature, verification, and encryption of images is
+ provided by host tools using OpenSSL's libcrypto. Select 'n' here if
+ you wish to build host tools without OpenSSL. mkimage will not have
+ the ability to sign images.
+ This selection does not affect target features, such as runtime FIT
+ signature verification.
+
 endmenu
diff --git a/tools/Makefile b/tools/Makefile
index 722355e984..1f30a06cce 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -3,6 +3,25 @@
 # (C) Copyright 2000-2006
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 
+# A note on target vs host configuration:
+#
+# Host tools can be used across multiple targets, or different configurations
+# of the same target. Thus, host tools must be able to handle any combination
+# of target configurations. To prevent having different variations of the same
+# tool, the tool build options may not depend on target configuration.
+#
+# Some linux distributions package these utilities as u-boot-tools, and it
+# would be unmaintainable to have a different tool variation for each
+# arch or configuration.
+#
+# A couple of simple rules:
+#
+# 1) Do not use target CONFIG_* options to enable or disable features in host
+#tools. Only use the configs from tools/Kconfig
+# 2) It's okay to use target configs to disable building specific tools.
+#That's as long as the features of those tools aren't modified.
+#
+
 # Enable all the config-independent tools
 ifneq ($(HOST_TOOLS_ALL),)
 CONFIG_ARCH_KIRKWOOD = y
@@ -53,30 +72,30 @@ hostprogs-y += mkenvimage
 mkenvimage-objs := mkenvimage.o os_support.o lib/crc32.o
 
 hostprogs-y += dumpimage mkimage
-hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info fit_check_sign
+hostprogs-$(CONFIG_TOOLS_USE_LIBCRYPTO) += fit_info fit_check_sign
 
 hostprogs-$(CONFIG_CMD_BOOTEFI_SELFTEST) += file2include
 
 FIT_OBJS-$(CONFIG_FIT) := fit_common.o fit_image.o image-host.o 
common/image-fit.o
-FIT_SIG_OBJS-$(CONFIG_FIT_SIGNATURE) := image-sig-host.o common/image-fit-sig.o
-FIT_CIPHER_OBJS-$(CONFIG_FIT_CIPHER) := common/image-cipher.o
+FIT_SIG_OBJS-$(CONFIG_TOOLS_USE_LIBCRYPTO) := image-sig-host.o 
common/image-fit-sig.o
+FIT_CIPHER_OBJS-$(CONFIG_TOOLS_USE_LIBCRYPTO) := common/image-cipher.o
 
 # The following files are synced with upstream DTC.
 # Use synced versions from scripts/dtc/libfdt/.
 LIBFDT_OBJS := $(addprefix libfdt/, fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o 
\
fdt_strerror.o fdt_empty_tree.o fdt_addresses.o fdt_overlay.o)
 
-RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := $(addprefix lib/rsa/, \
+RSA_OBJS-$(CONFIG_TOOLS_USE_LIBCRYPTO) := $(addprefix lib/rsa/, \
rsa-sign.o rsa-verify.o \
 

[PATCH v2 18/18] image: Add support for relocating crypto_algos in linker lists

2021-05-24 Thread Alexandru Gagniuc
Function pointers from crypto_algos array are relocated, when
NEEDS_MANUAL_RELOC is set. This relocation doesn't happen if the algo
is placed in a linker list. Implement this relocation.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
Acked-by: Michal Simek 
---
 common/image-sig.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/common/image-sig.c b/common/image-sig.c
index 498cd78af4..5c7ddd984d 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -98,6 +98,19 @@ struct crypto_algo *image_get_crypto_algo(const char 
*full_name)
int i;
const char *name;
 
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
+   static bool done;
+
+   if (!done) {
+   crypto = ll_entry_start(struct crypto_algo, cryptos);
+   end = ll_entry_end(struct crypto_algo, cryptos);
+   for (; crypto < end; crypto++) {
+   crypto->name += gd->reloc_off;
+   crypto->verify += gd->reloc_off;
+   }
+   }
+#endif
+
/* Move name to after the comma */
name = strchr(full_name, ',');
if (!name)
-- 
2.31.1



[PATCH v2 17/18] image: Eliminate IMAGE_ENABLE_VERIFY_ECDSA macro

2021-05-24 Thread Alexandru Gagniuc
This macro is no longer needed for code flow or #ifdefs. Remove it.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 include/image.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/image.h b/include/image.h
index ee930b0265..2f48a6eecf 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1196,17 +1196,14 @@ int calculate_hash(const void *data, int data_len, 
const char *algo,
 #if defined(USE_HOSTCC)
 # if defined(CONFIG_FIT_SIGNATURE)
 #  define IMAGE_ENABLE_SIGN1
-#  define IMAGE_ENABLE_VERIFY_ECDSA1
 #  define FIT_IMAGE_ENABLE_VERIFY  1
 #  include 
 # else
 #  define IMAGE_ENABLE_SIGN0
-# define IMAGE_ENABLE_VERIFY_ECDSA 0
 #  define FIT_IMAGE_ENABLE_VERIFY  0
 # endif
 #else
 # define IMAGE_ENABLE_SIGN 0
-# define IMAGE_ENABLE_VERIFY_ECDSA 0
 # define FIT_IMAGE_ENABLE_VERIFY   CONFIG_IS_ENABLED(FIT_SIGNATURE)
 #endif
 
-- 
2.31.1



[PATCH v2 15/18] lib: rsa: Remove #ifdefs from rsa.h

2021-05-24 Thread Alexandru Gagniuc
It is no longer necessary to implement rsa_() functions as no-ops
depending on config options. It is merely sufficient to provide the
prototypes, as the rsa code is no longer linked when unused.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 include/u-boot/rsa.h | 47 
 1 file changed, 47 deletions(-)

diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
index bc564d56fa..89a9c4caa0 100644
--- a/include/u-boot/rsa.h
+++ b/include/u-boot/rsa.h
@@ -31,7 +31,6 @@ struct rsa_public_key {
 
 struct image_sign_info;
 
-#if IMAGE_ENABLE_SIGN
 /**
  * sign() - calculate and return signature for given input data
  *
@@ -66,22 +65,7 @@ int rsa_sign(struct image_sign_info *info,
other -ve value on error
 */
 int rsa_add_verify_data(struct image_sign_info *info, void *keydest);
-#else
-static inline int rsa_sign(struct image_sign_info *info,
-   const struct image_region region[], int region_count,
-   uint8_t **sigp, uint *sig_len)
-{
-   return -ENXIO;
-}
-
-static inline int rsa_add_verify_data(struct image_sign_info *info,
- void *keydest)
-{
-   return -ENXIO;
-}
-#endif
 
-#if IMAGE_ENABLE_VERIFY
 /**
  * rsa_verify_hash() - Verify a signature against a hash
  *
@@ -124,37 +108,6 @@ int padding_pss_verify(struct image_sign_info *info,
   uint8_t *msg, int msg_len,
   const uint8_t *hash, int hash_len);
 #endif /* CONFIG_FIT_RSASSA_PSS */
-#else
-static inline int rsa_verify_hash(struct image_sign_info *info,
- const uint8_t *hash,
- uint8_t *sig, uint sig_len)
-{
-   return -ENXIO;
-}
-
-static inline int rsa_verify(struct image_sign_info *info,
-   const struct image_region region[], int region_count,
-   uint8_t *sig, uint sig_len)
-{
-   return -ENXIO;
-}
-
-static inline int padding_pkcs_15_verify(struct image_sign_info *info,
-uint8_t *msg, int msg_len,
-const uint8_t *hash, int hash_len)
-{
-   return -ENXIO;
-}
-
-#ifdef CONFIG_FIT_RSASSA_PSS
-static inline int padding_pss_verify(struct image_sign_info *info,
-uint8_t *msg, int msg_len,
-const uint8_t *hash, int hash_len)
-{
-   return -ENXIO;
-}
-#endif /* CONFIG_FIT_RSASSA_PSS */
-#endif
 
 #define RSA_DEFAULT_PADDING_NAME   "pkcs-1.5"
 
-- 
2.31.1



[PATCH v2 16/18] image: Eliminate IMAGE_ENABLE_VERIFY macro

2021-05-24 Thread Alexandru Gagniuc
This macro is no longer needed for code flow or #ifdefs. Remove it.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 include/image.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/image.h b/include/image.h
index f7f8f8a029..ee930b0265 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1196,19 +1196,16 @@ int calculate_hash(const void *data, int data_len, 
const char *algo,
 #if defined(USE_HOSTCC)
 # if defined(CONFIG_FIT_SIGNATURE)
 #  define IMAGE_ENABLE_SIGN1
-#  define IMAGE_ENABLE_VERIFY  1
 #  define IMAGE_ENABLE_VERIFY_ECDSA1
 #  define FIT_IMAGE_ENABLE_VERIFY  1
 #  include 
 # else
 #  define IMAGE_ENABLE_SIGN0
-#  define IMAGE_ENABLE_VERIFY  0
 # define IMAGE_ENABLE_VERIFY_ECDSA 0
 #  define FIT_IMAGE_ENABLE_VERIFY  0
 # endif
 #else
 # define IMAGE_ENABLE_SIGN 0
-# define IMAGE_ENABLE_VERIFY   CONFIG_IS_ENABLED(RSA_VERIFY)
 # define IMAGE_ENABLE_VERIFY_ECDSA 0
 # define FIT_IMAGE_ENABLE_VERIFY   CONFIG_IS_ENABLED(FIT_SIGNATURE)
 #endif
@@ -1260,7 +1257,7 @@ struct image_region {
int size;
 };
 
-#if IMAGE_ENABLE_VERIFY
+#if FIT_IMAGE_ENABLE_VERIFY
 # include 
 #endif
 struct checksum_algo {
-- 
2.31.1



[PATCH v2 14/18] lib: ecdsa: Remove #ifdefs from ecdsa.h

2021-05-24 Thread Alexandru Gagniuc
It is no longer necessary to implement ecdsa_() functions as no-ops
depending on config options. It is merely sufficient to provide the
prototypes, as the ecdsa code is no longer linked when unused.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 include/u-boot/ecdsa.h | 25 -
 1 file changed, 25 deletions(-)

diff --git a/include/u-boot/ecdsa.h b/include/u-boot/ecdsa.h
index 979690d966..f6951c7346 100644
--- a/include/u-boot/ecdsa.h
+++ b/include/u-boot/ecdsa.h
@@ -15,7 +15,6 @@
  * @see "struct crypto_algo"
  * @{
  */
-#if IMAGE_ENABLE_SIGN
 /**
  * sign() - calculate and return signature for given input data
  *
@@ -49,22 +48,7 @@ int ecdsa_sign(struct image_sign_info *info, const struct 
image_region region[],
  * other -ve value on error
  */
 int ecdsa_add_verify_data(struct image_sign_info *info, void *keydest);
-#else
-static inline
-int ecdsa_sign(struct image_sign_info *info, const struct image_region 
region[],
-  int region_count, uint8_t **sigp, uint *sig_len)
-{
-   return -ENXIO;
-}
-
-static inline
-int ecdsa_add_verify_data(struct image_sign_info *info, void *keydest)
-{
-   return -ENXIO;
-}
-#endif
 
-#if IMAGE_ENABLE_VERIFY_ECDSA
 /**
  * verify() - Verify a signature against some data
  *
@@ -78,15 +62,6 @@ int ecdsa_add_verify_data(struct image_sign_info *info, void 
*keydest)
 int ecdsa_verify(struct image_sign_info *info,
 const struct image_region region[], int region_count,
 uint8_t *sig, uint sig_len);
-#else
-static inline
-int ecdsa_verify(struct image_sign_info *info,
-const struct image_region region[], int region_count,
-uint8_t *sig, uint sig_len)
-{
-   return -ENXIO;
-}
-#endif
 /** @} */
 
 #define ECDSA256_BYTES (256 / 8)
-- 
2.31.1



[PATCH v2 13/18] image: image-sig.c: Remove crypto_algos array

2021-05-24 Thread Alexandru Gagniuc
Crytographic algorithms (currently RSA), are stored in linker lists.
The crypto_algos array is unused, so remove it, and any logic
associated with it.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 common/image-sig.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/common/image-sig.c b/common/image-sig.c
index d996b7ba50..498cd78af4 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -51,10 +51,6 @@ struct checksum_algo checksum_algos[] = {
 
 };
 
-struct crypto_algo crypto_algos[] = {
-   {
-};
-
 struct padding_algo padding_algos[] = {
{
.name = "pkcs-1.5",
@@ -102,29 +98,12 @@ struct crypto_algo *image_get_crypto_algo(const char 
*full_name)
int i;
const char *name;
 
-#if defined(CONFIG_NEEDS_MANUAL_RELOC)
-   static bool done;
-
-   if (!done) {
-   done = true;
-   for (i = 0; i < ARRAY_SIZE(crypto_algos); i++) {
-   crypto_algos[i].name += gd->reloc_off;
-   crypto_algos[i].verify += gd->reloc_off;
-   }
-   }
-#endif
-
/* Move name to after the comma */
name = strchr(full_name, ',');
if (!name)
return NULL;
name += 1;
 
-   for (i = 0; i < ARRAY_SIZE(crypto_algos); i++) {
-   if (!strcmp(crypto_algos[i].name, name))
-   return _algos[i];
-   }
-
crypto = ll_entry_start(struct crypto_algo, cryptos);
end = ll_entry_end(struct crypto_algo, cryptos);
for (; crypto < end; crypto++) {
-- 
2.31.1



[PATCH v2 12/18] image: rsa: Move verification algorithm to a linker list

2021-05-24 Thread Alexandru Gagniuc
Move the RSA verification crytpo_algo structure out of the
crypto_algos array, and into a linker list.

Although it appears we are adding an #ifdef to rsa-verify.c, the gains
outweigh this small inconvenience. This is because rsa_verify() is
defined differently based on #ifdefs. This change allows us to have
a single definition of rsa_verify().

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 common/image-sig.c   |  9 -
 lib/rsa/rsa-verify.c | 16 
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/common/image-sig.c b/common/image-sig.c
index 81a3b739fe..d996b7ba50 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -53,15 +53,6 @@ struct checksum_algo checksum_algos[] = {
 
 struct crypto_algo crypto_algos[] = {
{
-   .name = "rsa2048",
-   .key_len = RSA2048_BYTES,
-   .verify = rsa_verify,
-   },
-   {
-   .name = "rsa4096",
-   .key_len = RSA4096_BYTES,
-   .verify = rsa_verify,
-   },
 };
 
 struct padding_algo padding_algos[] = {
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 1998c773fc..bb8cc61d94 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -571,3 +571,19 @@ int rsa_verify(struct image_sign_info *info,
 
return rsa_verify_hash(info, hash, sig, sig_len);
 }
+
+#ifndef USE_HOSTCC
+
+U_BOOT_CRYPTO_ALGO(rsa2048) = {
+   .name = "rsa2048",
+   .key_len = RSA2048_BYTES,
+   .verify = rsa_verify,
+};
+
+U_BOOT_CRYPTO_ALGO(rsa4096) = {
+   .name = "rsa4096",
+   .key_len = RSA4096_BYTES,
+   .verify = rsa_verify,
+};
+
+#endif
-- 
2.31.1



[PATCH v2 07/18] image: Drop IMAGE_ENABLE_SHAxxx

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

We already have a host Kconfig for these SHA options. Use
CONFIG_IS_ENABLED(SHAxxx) directly in the code shared with the host build,
so we can drop the unnecessary indirections.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/image-fit.c |  6 +++---
 include/image.h| 21 -
 2 files changed, 3 insertions(+), 24 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 24e92a8e92..c0c75e92ba 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1222,15 +1222,15 @@ int calculate_hash(const void *data, int data_len, 
const char *algo,
sha1_csum_wd((unsigned char *)data, data_len,
 (unsigned char *)value, CHUNKSZ_SHA1);
*value_len = 20;
-   } else if (IMAGE_ENABLE_SHA256 && strcmp(algo, "sha256") == 0) {
+   } else if (CONFIG_IS_ENABLED(SHA256) && strcmp(algo, "sha256") == 0) {
sha256_csum_wd((unsigned char *)data, data_len,
   (unsigned char *)value, CHUNKSZ_SHA256);
*value_len = SHA256_SUM_LEN;
-   } else if (IMAGE_ENABLE_SHA384 && strcmp(algo, "sha384") == 0) {
+   } else if (CONFIG_IS_ENABLED(SHA384) && strcmp(algo, "sha384") == 0) {
sha384_csum_wd((unsigned char *)data, data_len,
   (unsigned char *)value, CHUNKSZ_SHA384);
*value_len = SHA384_SUM_LEN;
-   } else if (IMAGE_ENABLE_SHA512 && strcmp(algo, "sha512") == 0) {
+   } else if (CONFIG_IS_ENABLED(SHA512) && strcmp(algo, "sha512") == 0) {
sha512_csum_wd((unsigned char *)data, data_len,
   (unsigned char *)value, CHUNKSZ_SHA512);
*value_len = SHA512_SUM_LEN;
diff --git a/include/image.h b/include/image.h
index 8c718adba0..aa03f0a722 100644
--- a/include/image.h
+++ b/include/image.h
@@ -81,27 +81,6 @@ struct fdt_region;
 #define IMAGE_ENABLE_MD5   0
 #endif
 
-#if defined(CONFIG_FIT_SHA256) || \
-   defined(CONFIG_SPL_FIT_SHA256)
-#define IMAGE_ENABLE_SHA2561
-#else
-#define IMAGE_ENABLE_SHA2560
-#endif
-
-#if defined(CONFIG_FIT_SHA384) || \
-   defined(CONFIG_SPL_FIT_SHA384)
-#define IMAGE_ENABLE_SHA3841
-#else
-#define IMAGE_ENABLE_SHA3840
-#endif
-
-#if defined(CONFIG_FIT_SHA512) || \
-   defined(CONFIG_SPL_FIT_SHA512)
-#define IMAGE_ENABLE_SHA5121
-#else
-#define IMAGE_ENABLE_SHA5120
-#endif
-
 #endif /* IMAGE_ENABLE_FIT */
 
 #ifdef CONFIG_SYS_BOOT_GET_CMDLINE
-- 
2.31.1



[PATCH v2 10/18] common: image-sig.c: Remove host-specific logic and #ifdefs

2021-05-24 Thread Alexandru Gagniuc
Remove any ifdefs in image-sig.c that were previously used to
differentiate from the host code. Note that all code dedicated to
relocating ->sign() and ->add_verify_data)_ can be safely removed,
as signing is not supported target-side.

NOTE that although it appears we are removing ecdsa256 support, this
is intentional. ecdsa_verify() is a no-op on the target, and is
currently only used by host code.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 common/image-sig.c | 39 ++-
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/common/image-sig.c b/common/image-sig.c
index 8b5cecbfa4..5e2d171975 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -3,18 +3,11 @@
  * Copyright (c) 2013, Google Inc.
  */
 
-#ifdef USE_HOSTCC
-#include "mkimage.h"
-#include 
-#include 
-#include 
-#else
 #include 
 #include 
 #include 
 #include 
 DECLARE_GLOBAL_DATA_PTR;
-#endif /* !USE_HOSTCC*/
 #include 
 #include 
 #include 
@@ -28,9 +21,6 @@ struct checksum_algo checksum_algos[] = {
.checksum_len = SHA1_SUM_LEN,
.der_len = SHA1_DER_LEN,
.der_prefix = sha1_der_prefix,
-#if IMAGE_ENABLE_SIGN
-   .calculate_sign = EVP_sha1,
-#endif
.calculate = hash_calculate,
},
{
@@ -38,9 +28,6 @@ struct checksum_algo checksum_algos[] = {
.checksum_len = SHA256_SUM_LEN,
.der_len = SHA256_DER_LEN,
.der_prefix = sha256_der_prefix,
-#if IMAGE_ENABLE_SIGN
-   .calculate_sign = EVP_sha256,
-#endif
.calculate = hash_calculate,
},
 #ifdef CONFIG_SHA384
@@ -49,9 +36,6 @@ struct checksum_algo checksum_algos[] = {
.checksum_len = SHA384_SUM_LEN,
.der_len = SHA384_DER_LEN,
.der_prefix = sha384_der_prefix,
-#if IMAGE_ENABLE_SIGN
-   .calculate_sign = EVP_sha384,
-#endif
.calculate = hash_calculate,
},
 #endif
@@ -61,9 +45,6 @@ struct checksum_algo checksum_algos[] = {
.checksum_len = SHA512_SUM_LEN,
.der_len = SHA512_DER_LEN,
.der_prefix = sha512_der_prefix,
-#if IMAGE_ENABLE_SIGN
-   .calculate_sign = EVP_sha512,
-#endif
.calculate = hash_calculate,
},
 #endif
@@ -74,24 +55,13 @@ struct crypto_algo crypto_algos[] = {
{
.name = "rsa2048",
.key_len = RSA2048_BYTES,
-   .sign = rsa_sign,
-   .add_verify_data = rsa_add_verify_data,
.verify = rsa_verify,
},
{
.name = "rsa4096",
.key_len = RSA4096_BYTES,
-   .sign = rsa_sign,
-   .add_verify_data = rsa_add_verify_data,
.verify = rsa_verify,
},
-   {
-   .name = "ecdsa256",
-   .key_len = ECDSA256_BYTES,
-   .sign = ecdsa_sign,
-   .add_verify_data = ecdsa_add_verify_data,
-   .verify = ecdsa_verify,
-   },
 };
 
 struct padding_algo padding_algos[] = {
@@ -112,16 +82,13 @@ struct checksum_algo *image_get_checksum_algo(const char 
*full_name)
int i;
const char *name;
 
-#if !defined(USE_HOSTCC) && defined(CONFIG_NEEDS_MANUAL_RELOC)
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
static bool done;
 
if (!done) {
done = true;
for (i = 0; i < ARRAY_SIZE(checksum_algos); i++) {
checksum_algos[i].name += gd->reloc_off;
-#if IMAGE_ENABLE_SIGN
-   checksum_algos[i].calculate_sign += gd->reloc_off;
-#endif
checksum_algos[i].calculate += gd->reloc_off;
}
}
@@ -143,15 +110,13 @@ struct crypto_algo *image_get_crypto_algo(const char 
*full_name)
int i;
const char *name;
 
-#if !defined(USE_HOSTCC) && defined(CONFIG_NEEDS_MANUAL_RELOC)
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
static bool done;
 
if (!done) {
done = true;
for (i = 0; i < ARRAY_SIZE(crypto_algos); i++) {
crypto_algos[i].name += gd->reloc_off;
-   crypto_algos[i].sign += gd->reloc_off;
-   crypto_algos[i].add_verify_data += gd->reloc_off;
crypto_algos[i].verify += gd->reloc_off;
}
}
-- 
2.31.1



[PATCH v2 11/18] image: Add support for placing crypto_algo in linker lists

2021-05-24 Thread Alexandru Gagniuc
The purpose of this change is to enable crypto algorithms to be placed
in linker lists, rather than be declared as a static array. The goal
is to remove the crypto_algos array in a subsequent patch.

Create a new linker list named "cryptos", and search it when
image_get_crypto_algo() is invoked.

NOTE that adding support for manual relocation of crypto_algos within
linker lists is beyond the scope of this patch.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 common/image-sig.c | 9 +
 include/image.h| 5 +
 2 files changed, 14 insertions(+)

diff --git a/common/image-sig.c b/common/image-sig.c
index 5e2d171975..81a3b739fe 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -107,6 +107,7 @@ struct checksum_algo *image_get_checksum_algo(const char 
*full_name)
 
 struct crypto_algo *image_get_crypto_algo(const char *full_name)
 {
+   struct crypto_algo *crypto, *end;
int i;
const char *name;
 
@@ -133,6 +134,14 @@ struct crypto_algo *image_get_crypto_algo(const char 
*full_name)
return _algos[i];
}
 
+   crypto = ll_entry_start(struct crypto_algo, cryptos);
+   end = ll_entry_end(struct crypto_algo, cryptos);
+   for (; crypto < end; crypto++) {
+   if (!strcmp(crypto->name, name))
+   return crypto;
+   }
+
+   /* Not found */
return NULL;
 }
 
diff --git a/include/image.h b/include/image.h
index dbb24993f1..f7f8f8a029 100644
--- a/include/image.h
+++ b/include/image.h
@@ -47,6 +47,7 @@ struct fdt_region;
 #include 
 #include 
 #include 
+#include 
 
 /* Take notice of the 'ignore' property for hashes */
 #define IMAGE_ENABLE_IGNORE1
@@ -1328,6 +1329,10 @@ struct crypto_algo {
  uint8_t *sig, uint sig_len);
 };
 
+/* Declare a new U-Boot crypto algorithm handler */
+#define U_BOOT_CRYPTO_ALGO(__name) 
\
+ll_entry_declare(struct crypto_algo, __name, cryptos)
+
 struct padding_algo {
const char *name;
int (*verify)(struct image_sign_info *info,
-- 
2.31.1



[PATCH v2 09/18] common: Move host-only logic in image-sig.c to separate file

2021-05-24 Thread Alexandru Gagniuc
image-sig.c is used to map a hash or crypto algorithm name to a
handler of that algorithm. There is some similarity between the host
and target variants, with the differences worked out by #ifdefs. The
purpose of this change is to remove those ifdefs.

First, copy the file to a host-only version, and remove target
specific code. Although it looks like we are duplicating code,
subsequent patches will change the way target algorithms are searched.
Besides we are only duplicating three string to struct mapping
functions. This isn't something to fuss about.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
 tools/Makefile |   2 +-
 tools/image-sig-host.c | 133 +
 2 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 tools/image-sig-host.c

diff --git a/tools/Makefile b/tools/Makefile
index d020c55d66..722355e984 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -58,7 +58,7 @@ hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info fit_check_sign
 hostprogs-$(CONFIG_CMD_BOOTEFI_SELFTEST) += file2include
 
 FIT_OBJS-$(CONFIG_FIT) := fit_common.o fit_image.o image-host.o 
common/image-fit.o
-FIT_SIG_OBJS-$(CONFIG_FIT_SIGNATURE) := common/image-sig.o 
common/image-fit-sig.o
+FIT_SIG_OBJS-$(CONFIG_FIT_SIGNATURE) := image-sig-host.o common/image-fit-sig.o
 FIT_CIPHER_OBJS-$(CONFIG_FIT_CIPHER) := common/image-cipher.o
 
 # The following files are synced with upstream DTC.
diff --git a/tools/image-sig-host.c b/tools/image-sig-host.c
new file mode 100644
index 00..8ed6998dab
--- /dev/null
+++ b/tools/image-sig-host.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2013, Google Inc.
+ */
+
+#include "mkimage.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct checksum_algo checksum_algos[] = {
+   {
+   .name = "sha1",
+   .checksum_len = SHA1_SUM_LEN,
+   .der_len = SHA1_DER_LEN,
+   .der_prefix = sha1_der_prefix,
+   .calculate_sign = EVP_sha1,
+   .calculate = hash_calculate,
+   },
+   {
+   .name = "sha256",
+   .checksum_len = SHA256_SUM_LEN,
+   .der_len = SHA256_DER_LEN,
+   .der_prefix = sha256_der_prefix,
+   .calculate_sign = EVP_sha256,
+   .calculate = hash_calculate,
+   },
+   {
+   .name = "sha384",
+   .checksum_len = SHA384_SUM_LEN,
+   .der_len = SHA384_DER_LEN,
+   .der_prefix = sha384_der_prefix,
+   .calculate_sign = EVP_sha384,
+   .calculate = hash_calculate,
+   },
+   {
+   .name = "sha512",
+   .checksum_len = SHA512_SUM_LEN,
+   .der_len = SHA512_DER_LEN,
+   .der_prefix = sha512_der_prefix,
+   .calculate_sign = EVP_sha512,
+   .calculate = hash_calculate,
+   },
+};
+
+struct crypto_algo crypto_algos[] = {
+   {
+   .name = "rsa2048",
+   .key_len = RSA2048_BYTES,
+   .sign = rsa_sign,
+   .add_verify_data = rsa_add_verify_data,
+   .verify = rsa_verify,
+   },
+   {
+   .name = "rsa4096",
+   .key_len = RSA4096_BYTES,
+   .sign = rsa_sign,
+   .add_verify_data = rsa_add_verify_data,
+   .verify = rsa_verify,
+   },
+   {
+   .name = "ecdsa256",
+   .key_len = ECDSA256_BYTES,
+   .sign = ecdsa_sign,
+   .add_verify_data = ecdsa_add_verify_data,
+   .verify = ecdsa_verify,
+   },
+};
+
+struct padding_algo padding_algos[] = {
+   {
+   .name = "pkcs-1.5",
+   .verify = padding_pkcs_15_verify,
+   },
+   {
+   .name = "pss",
+   .verify = padding_pss_verify,
+   }
+};
+
+struct checksum_algo *image_get_checksum_algo(const char *full_name)
+{
+   int i;
+   const char *name;
+
+   for (i = 0; i < ARRAY_SIZE(checksum_algos); i++) {
+   name = checksum_algos[i].name;
+   /* Make sure names match and next char is a comma */
+   if (!strncmp(name, full_name, strlen(name)) &&
+   full_name[strlen(name)] == ',')
+   return _algos[i];
+   }
+
+   return NULL;
+}
+
+struct crypto_algo *image_get_crypto_algo(const char *full_name)
+{
+   int i;
+   const char *name;
+
+   /* Move name to after the comma */
+   name = strchr(full_name, ',');
+   if (!name)
+   return NULL;
+   name += 1;
+
+   for (i = 0; i < ARRAY_SIZE(crypto_algos); i++) {
+   if (!strcmp(crypto_algos[i].name, name))
+   return _algos[i];
+   }
+
+   return NULL;
+}
+
+struct padding_algo *image_get_padding_algo(const char *name)
+{
+   int 

[PATCH v2 06/18] image: Drop IMAGE_ENABLE_SHA1

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

We already have a host Kconfig for SHA1. Use CONFIG_IS_ENABLED(SHA1)
directly in the code shared with the host build, so we can drop the
unnecessary indirection.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/image-fit.c | 2 +-
 include/image.h| 8 
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index e614643fe3..24e92a8e92 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1218,7 +1218,7 @@ int calculate_hash(const void *data, int data_len, const 
char *algo,
CHUNKSZ_CRC32);
*((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
*value_len = 4;
-   } else if (IMAGE_ENABLE_SHA1 && strcmp(algo, "sha1") == 0) {
+   } else if (CONFIG_IS_ENABLED(SHA1) && strcmp(algo, "sha1") == 0) {
sha1_csum_wd((unsigned char *)data, data_len,
 (unsigned char *)value, CHUNKSZ_SHA1);
*value_len = 20;
diff --git a/include/image.h b/include/image.h
index 887a3270bd..8c718adba0 100644
--- a/include/image.h
+++ b/include/image.h
@@ -68,13 +68,9 @@ struct fdt_region;
 #  ifdef CONFIG_SPL_MD5
 #   define IMAGE_ENABLE_MD51
 #  endif
-#  ifdef CONFIG_SPL_FIT_SHA1
-#   define IMAGE_ENABLE_SHA1   1
-#  endif
 # else
 #  define IMAGE_ENABLE_CRC32   1
 #  define IMAGE_ENABLE_MD5 1
-#  define IMAGE_ENABLE_SHA11
 # endif
 
 #ifndef IMAGE_ENABLE_CRC32
@@ -85,10 +81,6 @@ struct fdt_region;
 #define IMAGE_ENABLE_MD5   0
 #endif
 
-#ifndef IMAGE_ENABLE_SHA1
-#define IMAGE_ENABLE_SHA1  0
-#endif
-
 #if defined(CONFIG_FIT_SHA256) || \
defined(CONFIG_SPL_FIT_SHA256)
 #define IMAGE_ENABLE_SHA2561
-- 
2.31.1



[PATCH v2 08/18] image: Drop IMAGE_ENABLE_BEST_MATCH

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

This is not needed with Kconfig, since we can use IS_ENABLED() easily
enough. Drop it.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/image-fit.c | 2 +-
 include/image.h| 5 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index c0c75e92ba..5df2cf8571 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -2026,7 +2026,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 * fit_conf_get_node() will try to find default config node
 */
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_NO_UNIT_NAME);
-   if (IMAGE_ENABLE_BEST_MATCH && !fit_uname_config) {
+   if (IS_ENABLED(CONFIG_FIT_BEST_MATCH) && !fit_uname_config) {
cfg_noffset = fit_conf_find_compat(fit, gd_fdt_blob());
} else {
cfg_noffset = fit_conf_get_node(fit,
diff --git a/include/image.h b/include/image.h
index aa03f0a722..dbb24993f1 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1221,11 +1221,6 @@ void image_set_host_blob(void *host_blob);
 # define gd_fdt_blob() (gd->fdt_blob)
 #endif
 
-#ifdef CONFIG_FIT_BEST_MATCH
-#define IMAGE_ENABLE_BEST_MATCH1
-#else
-#define IMAGE_ENABLE_BEST_MATCH0
-#endif
 #endif /* IMAGE_ENABLE_FIT */
 
 /*
-- 
2.31.1



[PATCH v2 04/18] Kconfig: Rename SPL_CRC32_SUPPORT to SPL_CRC32

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

Drop the _SUPPORT suffix so we can use CONFIG_IS_ENABLED() with this
option.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/spl/Kconfig| 4 ++--
 configs/axm_defconfig | 2 +-
 configs/chromebit_mickey_defconfig| 2 +-
 configs/chromebook_jerry_defconfig| 2 +-
 configs/chromebook_minnie_defconfig   | 2 +-
 configs/chromebook_speedy_defconfig   | 2 +-
 configs/evb-px30_defconfig| 2 +-
 configs/firefly-px30_defconfig| 2 +-
 configs/imxrt1020-evk_defconfig   | 2 +-
 configs/imxrt1050-evk_defconfig   | 2 +-
 configs/odroid-go2_defconfig  | 2 +-
 configs/px30-core-ctouch2-px30_defconfig  | 2 +-
 configs/px30-core-edimm2.2-px30_defconfig | 2 +-
 configs/socfpga_agilex_atf_defconfig  | 2 +-
 configs/socfpga_agilex_vab_defconfig  | 2 +-
 configs/socfpga_stratix10_atf_defconfig   | 2 +-
 configs/taurus_defconfig  | 2 +-
 include/image.h   | 2 +-
 18 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index d94b989217..0329d93b29 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -204,7 +204,7 @@ config SPL_LEGACY_IMAGE_SUPPORT
 config SPL_LEGACY_IMAGE_CRC_CHECK
bool "Check CRC of Legacy images"
depends on SPL_LEGACY_IMAGE_SUPPORT
-   select SPL_CRC32_SUPPORT
+   select SPL_CRC32
help
  Enable this to check the CRC of Legacy images. While this increases
  reliability, it affects both code size and boot duration.
@@ -407,7 +407,7 @@ config SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
  the eMMC EXT_CSC_PART_CONFIG selection should be overridden in SPL
  by user defined partition number.
 
-config SPL_CRC32_SUPPORT
+config SPL_CRC32
bool "Support CRC32"
default y if SPL_LEGACY_IMAGE_SUPPORT
help
diff --git a/configs/axm_defconfig b/configs/axm_defconfig
index 0bfd7548b0..4e776fd695 100644
--- a/configs/axm_defconfig
+++ b/configs/axm_defconfig
@@ -32,7 +32,7 @@ CONFIG_BOOTCOMMAND="run flash_self"
 CONFIG_BOARD_EARLY_INIT_F=y
 # CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_CRC32_SUPPORT=y
+CONFIG_SPL_CRC32=y
 CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_SPL_NAND_DRIVERS=y
 CONFIG_SPL_NAND_ECC=y
diff --git a/configs/chromebit_mickey_defconfig 
b/configs/chromebit_mickey_defconfig
index c09b63b946..2b664e118c 100644
--- a/configs/chromebit_mickey_defconfig
+++ b/configs/chromebit_mickey_defconfig
@@ -25,7 +25,7 @@ CONFIG_BOARD_EARLY_INIT_R=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
 # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
-# CONFIG_SPL_CRC32_SUPPORT is not set
+# CONFIG_SPL_CRC32 is not set
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
diff --git a/configs/chromebook_jerry_defconfig 
b/configs/chromebook_jerry_defconfig
index 692b630174..a757d259f5 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -26,7 +26,7 @@ CONFIG_BOARD_EARLY_INIT_R=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
 # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
-# CONFIG_SPL_CRC32_SUPPORT is not set
+# CONFIG_SPL_CRC32 is not set
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
diff --git a/configs/chromebook_minnie_defconfig 
b/configs/chromebook_minnie_defconfig
index ae55842e3b..353aa01ea9 100644
--- a/configs/chromebook_minnie_defconfig
+++ b/configs/chromebook_minnie_defconfig
@@ -26,7 +26,7 @@ CONFIG_BOARD_EARLY_INIT_R=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
 # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
-# CONFIG_SPL_CRC32_SUPPORT is not set
+# CONFIG_SPL_CRC32 is not set
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
diff --git a/configs/chromebook_speedy_defconfig 
b/configs/chromebook_speedy_defconfig
index 4b460ee6a9..c5be5597b1 100644
--- a/configs/chromebook_speedy_defconfig
+++ b/configs/chromebook_speedy_defconfig
@@ -26,7 +26,7 @@ CONFIG_BOARD_EARLY_INIT_R=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
 # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
-# CONFIG_SPL_CRC32_SUPPORT is not set
+# CONFIG_SPL_CRC32 is not set
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
diff --git a/configs/evb-px30_defconfig b/configs/evb-px30_defconfig
index d2fdfef293..55e2702a17 100644
--- a/configs/evb-px30_defconfig
+++ b/configs/evb-px30_defconfig
@@ -29,7 +29,7 @@ CONFIG_SPL_BOOTROM_SUPPORT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 # CONFIG_TPL_BANNER_PRINT is not set
-CONFIG_SPL_CRC32_SUPPORT=y
+CONFIG_SPL_CRC32=y
 CONFIG_SPL_ATF=y
 # CONFIG_TPL_FRAMEWORK is not set
 # CONFIG_CMD_BOOTD is not set
diff --git a/configs/firefly-px30_defconfig b/configs/firefly-px30_defconfig

[PATCH v2 05/18] Kconfig: Rename SPL_MD5_SUPPORT to SPL_MD5

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

Drop the _SUPPORT suffix so we can use CONFIG_IS_ENABLED() with this
option.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/spl/Kconfig | 2 +-
 include/image.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0329d93b29..c83ce4d367 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -417,7 +417,7 @@ config SPL_CRC32
  for detected accidental image corruption. For secure applications you
  should consider SHA1 or SHA256.
 
-config SPL_MD5_SUPPORT
+config SPL_MD5
bool "Support MD5"
depends on SPL_FIT
help
diff --git a/include/image.h b/include/image.h
index 2c812d22a9..887a3270bd 100644
--- a/include/image.h
+++ b/include/image.h
@@ -65,7 +65,7 @@ struct fdt_region;
 #  ifdef CONFIG_SPL_CRC32
 #   define IMAGE_ENABLE_CRC32  1
 #  endif
-#  ifdef CONFIG_SPL_MD5_SUPPORT
+#  ifdef CONFIG_SPL_MD5
 #   define IMAGE_ENABLE_MD51
 #  endif
 #  ifdef CONFIG_SPL_FIT_SHA1
-- 
2.31.1



[PATCH v2 03/18] image: Rename CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

Drop the ENABLE and SUPPORT parts of this, which are redundant.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/Kconfig.boot | 2 +-
 common/image-sig.c  | 4 ++--
 configs/bcm963158_ram_defconfig | 2 +-
 configs/sandbox_defconfig   | 2 +-
 include/image.h | 2 +-
 include/u-boot/rsa.h| 8 
 lib/rsa/rsa-sign.c  | 4 ++--
 lib/rsa/rsa-verify.c| 2 +-
 8 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 066a48a96d..99fa98b35d 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -104,7 +104,7 @@ config FIT_SIGNATURE_MAX_SIZE
  device memory. Assure this size does not extend past expected storage
  space.
 
-config FIT_ENABLE_RSASSA_PSS_SUPPORT
+config FIT_RSASSA_PSS
bool "Support rsassa-pss signature scheme of FIT image contents"
depends on FIT_SIGNATURE
default n
diff --git a/common/image-sig.c b/common/image-sig.c
index 0f8e592aba..8b5cecbfa4 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -99,12 +99,12 @@ struct padding_algo padding_algos[] = {
.name = "pkcs-1.5",
.verify = padding_pkcs_15_verify,
},
-#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+#ifdef CONFIG_FIT_RSASSA_PSS
{
.name = "pss",
.verify = padding_pss_verify,
}
-#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
+#endif /* CONFIG_FIT_RSASSA_PSS */
 };
 
 struct checksum_algo *image_get_checksum_algo(const char *full_name)
diff --git a/configs/bcm963158_ram_defconfig b/configs/bcm963158_ram_defconfig
index 0be1e0981a..ec006514d1 100644
--- a/configs/bcm963158_ram_defconfig
+++ b/configs/bcm963158_ram_defconfig
@@ -11,7 +11,7 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm963158"
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
-CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT=y
+CONFIG_FIT_RSASSA_PSS=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_SUPPORT_RAW_INITRD=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index bdbf714e2b..7b8603d1ef 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -10,7 +10,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
-CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT=y
+CONFIG_FIT_RSASSA_PSS=y
 CONFIG_FIT_CIPHER=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_BOOTSTAGE=y
diff --git a/include/image.h b/include/image.h
index 3284f36c97..9eb45ffd40 100644
--- a/include/image.h
+++ b/include/image.h
@@ -30,7 +30,7 @@ struct fdt_region;
 #define IMAGE_ENABLE_FIT   1
 #define IMAGE_ENABLE_OF_LIBFDT 1
 #define CONFIG_FIT_VERBOSE 1 /* enable fit_format_{error,warning}() */
-#define CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT 1
+#define CONFIG_FIT_RSASSA_PSS 1
 #define CONFIG_FIT_SHA256
 #define CONFIG_FIT_SHA384
 #define CONFIG_FIT_SHA512
diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
index bed1c097c2..bc564d56fa 100644
--- a/include/u-boot/rsa.h
+++ b/include/u-boot/rsa.h
@@ -119,11 +119,11 @@ int padding_pkcs_15_verify(struct image_sign_info *info,
   uint8_t *msg, int msg_len,
   const uint8_t *hash, int hash_len);
 
-#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+#ifdef CONFIG_FIT_RSASSA_PSS
 int padding_pss_verify(struct image_sign_info *info,
   uint8_t *msg, int msg_len,
   const uint8_t *hash, int hash_len);
-#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
+#endif /* CONFIG_FIT_RSASSA_PSS */
 #else
 static inline int rsa_verify_hash(struct image_sign_info *info,
  const uint8_t *hash,
@@ -146,14 +146,14 @@ static inline int padding_pkcs_15_verify(struct 
image_sign_info *info,
return -ENXIO;
 }
 
-#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+#ifdef CONFIG_FIT_RSASSA_PSS
 static inline int padding_pss_verify(struct image_sign_info *info,
 uint8_t *msg, int msg_len,
 const uint8_t *hash, int hash_len)
 {
return -ENXIO;
 }
-#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
+#endif /* CONFIG_FIT_RSASSA_PSS */
 #endif
 
 #define RSA_DEFAULT_PADDING_NAME   "pkcs-1.5"
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 5a1583b8f7..f4ed11e74a 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -442,7 +442,7 @@ static int rsa_sign_with_key(EVP_PKEY *pkey, struct 
padding_algo *padding_algo,
goto err_sign;
}
 
-#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+#ifdef CONFIG_FIT_RSASSA_PSS
if (padding_algo && !strcmp(padding_algo->name, "pss")) {
if (EVP_PKEY_CTX_set_rsa_padding(ckey,
 RSA_PKCS1_PSS_PADDING) <= 0) {
@@ -450,7 +450,7 @@ static int 

[PATCH v2 02/18] image: Rename SPL_SHAxxx_SUPPORT to SPL_FIT_SHAxxx

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

These option are named inconsistently with other SPL options, thus making
them incompatible with the CONFIG_IS_ENABLED() macro. Rename them.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/spl/Kconfig | 8 
 include/image.h| 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index df5468f1ac..d94b989217 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -429,7 +429,7 @@ config SPL_MD5_SUPPORT
  applications where images may be changed maliciously, you should
  consider SHA256 or SHA384.
 
-config SPL_SHA1_SUPPORT
+config SPL_FIT_SHA1
bool "Support SHA1"
depends on SPL_FIT
select SHA1
@@ -441,7 +441,7 @@ config SPL_SHA1_SUPPORT
  due to the expanding computing power available to brute-force
  attacks. For more security, consider SHA256 or SHA384.
 
-config SPL_SHA256_SUPPORT
+config SPL_FIT_SHA256
bool "Support SHA256"
depends on SPL_FIT
select SHA256
@@ -450,7 +450,7 @@ config SPL_SHA256_SUPPORT
  checksum is a 256-bit (32-byte) hash value used to check that the
  image contents have not been corrupted.
 
-config SPL_SHA384_SUPPORT
+config SPL_FIT_SHA384
bool "Support SHA384"
depends on SPL_FIT
select SHA384
@@ -461,7 +461,7 @@ config SPL_SHA384_SUPPORT
  image contents have not been corrupted. Use this for the highest
  security.
 
-config SPL_SHA512_SUPPORT
+config SPL_FIT_SHA512
bool "Support SHA512"
depends on SPL_FIT
select SHA512
diff --git a/include/image.h b/include/image.h
index 9319a779b9..3284f36c97 100644
--- a/include/image.h
+++ b/include/image.h
@@ -68,7 +68,7 @@ struct fdt_region;
 #  ifdef CONFIG_SPL_MD5_SUPPORT
 #   define IMAGE_ENABLE_MD51
 #  endif
-#  ifdef CONFIG_SPL_SHA1_SUPPORT
+#  ifdef CONFIG_SPL_FIT_SHA1
 #   define IMAGE_ENABLE_SHA1   1
 #  endif
 # else
@@ -90,21 +90,21 @@ struct fdt_region;
 #endif
 
 #if defined(CONFIG_FIT_SHA256) || \
-   defined(CONFIG_SPL_SHA256_SUPPORT)
+   defined(CONFIG_SPL_FIT_SHA256)
 #define IMAGE_ENABLE_SHA2561
 #else
 #define IMAGE_ENABLE_SHA2560
 #endif
 
 #if defined(CONFIG_FIT_SHA384) || \
-   defined(CONFIG_SPL_SHA384_SUPPORT)
+   defined(CONFIG_SPL_FIT_SHA384)
 #define IMAGE_ENABLE_SHA3841
 #else
 #define IMAGE_ENABLE_SHA3840
 #endif
 
 #if defined(CONFIG_FIT_SHA512) || \
-   defined(CONFIG_SPL_SHA512_SUPPORT)
+   defined(CONFIG_SPL_FIT_SHA512)
 #define IMAGE_ENABLE_SHA5121
 #else
 #define IMAGE_ENABLE_SHA5120
-- 
2.31.1



[PATCH v2 01/18] image: Shorten FIT_ENABLE_SHAxxx_SUPPORT

2021-05-24 Thread Alexandru Gagniuc
From: Simon Glass 

The ENABLE part of this name is redundant, since all boolean Kconfig
options serve to enable something. The SUPPORT part is also redundant
since Kconfigs can be assumed to enable support for something. Together
they just serve to make these options overly long and inconsistent
with other options.

Rename FIT_ENABLE_SHAxxx_SUPPORT to FIT_SHAxxx

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
 common/Kconfig.boot  |  6 +++---
 configs/mt8516_pumpkin_defconfig |  2 +-
 include/image.h  | 12 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 3c6e77d099..066a48a96d 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -35,7 +35,7 @@ config FIT_EXTERNAL_OFFSET
  could be put in the hole between data payload and fit image
  header, such as CSF data on i.MX platform.
 
-config FIT_ENABLE_SHA256_SUPPORT
+config FIT_SHA256
bool "Support SHA256 checksum of FIT image contents"
default y
select SHA256
@@ -44,7 +44,7 @@ config FIT_ENABLE_SHA256_SUPPORT
  SHA256 checksum is a 256-bit (32-byte) hash value used to check that
  the image contents have not been corrupted.
 
-config FIT_ENABLE_SHA384_SUPPORT
+config FIT_SHA384
bool "Support SHA384 checksum of FIT image contents"
default n
select SHA384
@@ -54,7 +54,7 @@ config FIT_ENABLE_SHA384_SUPPORT
  the image contents have not been corrupted. Use this for the highest
  security.
 
-config FIT_ENABLE_SHA512_SUPPORT
+config FIT_SHA512
bool "Support SHA512 checksum of FIT image contents"
default n
select SHA512
diff --git a/configs/mt8516_pumpkin_defconfig b/configs/mt8516_pumpkin_defconfig
index 780660058d..356f18acd8 100644
--- a/configs/mt8516_pumpkin_defconfig
+++ b/configs/mt8516_pumpkin_defconfig
@@ -13,7 +13,7 @@ CONFIG_DEBUG_UART_CLOCK=2600
 CONFIG_DEFAULT_DEVICE_TREE="mt8516-pumpkin"
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
-# CONFIG_FIT_ENABLE_SHA256_SUPPORT is not set
+# CONFIG_FIT_SHA256 is not set
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 CONFIG_DEFAULT_FDT_FILE="mt8516-pumpkin"
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/include/image.h b/include/image.h
index 459685d4d4..9319a779b9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -31,9 +31,9 @@ struct fdt_region;
 #define IMAGE_ENABLE_OF_LIBFDT 1
 #define CONFIG_FIT_VERBOSE 1 /* enable fit_format_{error,warning}() */
 #define CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT 1
-#define CONFIG_FIT_ENABLE_SHA256_SUPPORT
-#define CONFIG_FIT_ENABLE_SHA384_SUPPORT
-#define CONFIG_FIT_ENABLE_SHA512_SUPPORT
+#define CONFIG_FIT_SHA256
+#define CONFIG_FIT_SHA384
+#define CONFIG_FIT_SHA512
 #define CONFIG_SHA1
 #define CONFIG_SHA256
 #define CONFIG_SHA384
@@ -89,21 +89,21 @@ struct fdt_region;
 #define IMAGE_ENABLE_SHA1  0
 #endif
 
-#if defined(CONFIG_FIT_ENABLE_SHA256_SUPPORT) || \
+#if defined(CONFIG_FIT_SHA256) || \
defined(CONFIG_SPL_SHA256_SUPPORT)
 #define IMAGE_ENABLE_SHA2561
 #else
 #define IMAGE_ENABLE_SHA2560
 #endif
 
-#if defined(CONFIG_FIT_ENABLE_SHA384_SUPPORT) || \
+#if defined(CONFIG_FIT_SHA384) || \
defined(CONFIG_SPL_SHA384_SUPPORT)
 #define IMAGE_ENABLE_SHA3841
 #else
 #define IMAGE_ENABLE_SHA3840
 #endif
 
-#if defined(CONFIG_FIT_ENABLE_SHA512_SUPPORT) || \
+#if defined(CONFIG_FIT_SHA512) || \
defined(CONFIG_SPL_SHA512_SUPPORT)
 #define IMAGE_ENABLE_SHA5121
 #else
-- 
2.31.1



[PATCH v2 00/18] image: Reduce #ifdef abuse in image code

2021-05-24 Thread Alexandru Gagniuc
This is a combination of select patches from Simon's series:
"image: Reduce #ifdefs and ad-hoc defines in image code"
and alternative solutions I proposed in:
"image: Reduce the abuse of #ifdefs in image-sig.c"

After syncing with Simon, we agree that this is a reasonable base for
further work in #ifdef reduction. Rather than describing changes from
Simon's series or mine, we present this series de novo.
Most patches are already peer-reviewed.

Changes since v1:
  - Place fit_common.o under CONFIG_FIT, not CONFIG_FIT_SIGNATURE

Alexandru Gagniuc (10):
  common: Move host-only logic in image-sig.c to separate file
  common: image-sig.c: Remove host-specific logic and #ifdefs
  image: Add support for placing crypto_algo in linker lists
  image: rsa: Move verification algorithm to a linker list
  image: image-sig.c: Remove crypto_algos array
  lib: ecdsa: Remove #ifdefs from ecdsa.h
  lib: rsa: Remove #ifdefs from rsa.h
  image: Eliminate IMAGE_ENABLE_VERIFY macro
  image: Eliminate IMAGE_ENABLE_VERIFY_ECDSA macro
  image: Add support for relocating crypto_algos in linker lists

Simon Glass (8):
  image: Shorten FIT_ENABLE_SHAxxx_SUPPORT
  image: Rename SPL_SHAxxx_SUPPORT to SPL_FIT_SHAxxx
  image: Rename CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
  Kconfig: Rename SPL_CRC32_SUPPORT to SPL_CRC32
  Kconfig: Rename SPL_MD5_SUPPORT to SPL_MD5
  image: Drop IMAGE_ENABLE_SHA1
  image: Drop IMAGE_ENABLE_SHAxxx
  image: Drop IMAGE_ENABLE_BEST_MATCH

 common/Kconfig.boot   |   8 +-
 common/image-fit.c|  10 +-
 common/image-sig.c|  75 +++-
 common/spl/Kconfig|  14 +--
 configs/axm_defconfig |   2 +-
 configs/bcm963158_ram_defconfig   |   2 +-
 configs/chromebit_mickey_defconfig|   2 +-
 configs/chromebook_jerry_defconfig|   2 +-
 configs/chromebook_minnie_defconfig   |   2 +-
 configs/chromebook_speedy_defconfig   |   2 +-
 configs/evb-px30_defconfig|   2 +-
 configs/firefly-px30_defconfig|   2 +-
 configs/imxrt1020-evk_defconfig   |   2 +-
 configs/imxrt1050-evk_defconfig   |   2 +-
 configs/mt8516_pumpkin_defconfig  |   2 +-
 configs/odroid-go2_defconfig  |   2 +-
 configs/px30-core-ctouch2-px30_defconfig  |   2 +-
 configs/px30-core-edimm2.2-px30_defconfig |   2 +-
 configs/sandbox_defconfig |   2 +-
 configs/socfpga_agilex_atf_defconfig  |   2 +-
 configs/socfpga_agilex_vab_defconfig  |   2 +-
 configs/socfpga_stratix10_atf_defconfig   |   2 +-
 configs/taurus_defconfig  |   2 +-
 include/image.h   |  59 ++
 include/u-boot/ecdsa.h|  25 
 include/u-boot/rsa.h  |  51 +
 lib/rsa/rsa-sign.c|   4 +-
 lib/rsa/rsa-verify.c  |  18 ++-
 tools/Makefile|   2 +-
 tools/image-sig-host.c| 133 ++
 30 files changed, 218 insertions(+), 219 deletions(-)
 create mode 100644 tools/image-sig-host.c

-- 
2.31.1



Re: [PATCH 06/18] image: Drop IMAGE_ENABLE_SHA1

2021-05-24 Thread Alex G.




On 5/21/21 2:39 PM, Simon Glass wrote:

Hi Alex,

On Thu, 20 May 2021 at 18:07, Alex G.  wrote:




On 5/20/21 6:17 PM, Simon Glass wrote:

Hi Alex,

On Thu, 20 May 2021 at 17:13, Alex G.  wrote:




On 5/20/21 12:52 PM, Simon Glass wrote:

Hi Alex,

On Wed, 19 May 2021 at 20:41, Alex G.  wrote:




On 5/19/21 4:55 PM, Simon Glass wrote:

Hi Alex,

On Wed, 19 May 2021 at 11:44, Alex G  wrote:




On 5/19/21 11:36 AM, Simon Glass wrote:

Hi Alexandru,

On Mon, 17 May 2021 at 10:38, Alexandru Gagniuc  wrote:


From: Simon Glass 

We already have a host Kconfig for SHA1. Use CONFIG_IS_ENABLED(SHA1)
directly in the code shared with the host build, so we can drop the
unnecessary indirection.

Signed-off-by: Simon Glass 
Reviewed-by: Alexandru Gagniuc 
Signed-off-by: Alexandru Gagniuc 
---
  common/image-fit.c | 2 +-
  include/image.h| 8 
  2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index e614643fe3..24e92a8e92 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1218,7 +1218,7 @@ int calculate_hash(const void *data, int data_len, const 
char *algo,
 CHUNKSZ_CRC32);
 *((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
 *value_len = 4;
-   } else if (IMAGE_ENABLE_SHA1 && strcmp(algo, "sha1") == 0) {
+   } else if (CONFIG_IS_ENABLED(SHA1) && strcmp(algo, "sha1") == 0) {


This can only work if the my host Kconfig patch comes first. Otherwise
this code will just be skipped on the host.


I was scratching my head too as to why this works in practice, but not
in theory. There is a #define CONFIG_SHA1 in image.h.

Although not a perfect fix, we go from two ways to enable SHA1 ("#define
IMAGE_ENABLE_SHA1", and "#define CONFIG_SHA1"), to just one. That's why
I think this change is an improvement, and part of this series.


No, we really should not do that...everything needs to be in Kconfig.


I agree for target code. But, as a long term solution, let's look at how
we can get hash algos in linker lists, like we're proposing to do for
crytpo algos. Or I could just drop this change in v2.


Would it not be easier to have a host Kconfig for these? You seem to
be going to extreme lengths to avoid it, but it seems like the
simplest solution, easy to understand, no effect on code size and
scalable to the future.


It's easy for the short term in terms if the goal is to get something
merged. It just hides more fundamental issues with the code. For
ecample, why is there hash_calculate() and clacultae_hash()


It is just a naming issue, isn't it? They are quite different functions.


Because one resets the watchdog after every CHUNK bytes and the other
doesn't?


Well hash_calculate() is used for hashing parts of a devicetree, so is
quite a different function.





I was under the impression that we were agreed on the combination of
patches. I won't try to defend your patch from yourself. I'll drop the
hash changes from v2 if it helps get things moving along.


I'm OK with this as a short-term fix to get this series through. But I
think we are going to end up with a Kconfig solution at some point.
What do you think?


I think it's possible and reasonable to have common code without host
Kconfig. coreboot did it.


There is very little code shared between target and tools there. I am
sure there is some, but can't think of anything except some library
functions. There is also no equivalent of CONFIG_IS_ENABLED(), but
instead a log of ENV_... macros and entirely separate rules in the
Makefile.

Can you point to another way to do this? I think your approach is
valuable in untangling code that does not need to be shared, but I
still think that the host Kconfig thing is a great idea for everything
else. It isn't my idea, but Rasmus' (now on cc).


I have a couple of ideas to start, but nothing submittable.

Let's start with hash_calculate(). It's just a big switch() with string 
processing. But we've already done part of the work in 
fit_image_check_hash(). So instead of stopping at a "char *algo", why 
not get an actual "struct hash_algo *" with the correct ops to begin 
with, and not need a huge switch() function() ?


We have "struct hash_algo" and "struct checksum_algo" that seem to serve 
very similar purposes. Would it actually make sense to merge them?


And if that is done, you open the gates to significantly reducing the 
CONFIG_IS_ENABLED() use for hashes, as well as really simplify the hash 
selection in Kconfig.


In order to do this, we are reducing the occurrence of IS_ENABLED(), 
which is just an eye-candy version of #ifdef. This leads to the natural 
conclusion of eliminating IS_ENABLED() from common code.


Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Tom Rini
On Mon, May 24, 2021 at 09:19:35PM +0200, Marek Behun wrote:
> On Mon, 24 May 2021 13:44:38 -0400
> Tom Rini  wrote:
> 
> > On Mon, May 24, 2021 at 01:09:19PM -0400, Tom Rini wrote:
> > > On Mon, May 24, 2021 at 05:58:55PM +0200, Marek Behun wrote:  
> > > > On Mon, 24 May 2021 11:40:53 -0400
> > > > Tom Rini  wrote:
> > > >   
> > > > > On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:  
> > > > > > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:
> > > > > > > On Fri, 21 May 2021 10:11:47 -0400
> > > > > > > Tom Rini  wrote:
> > > > > > > 
> > > > > > > > On Thu, May 20, 2021 at 01:56:29PM -0500, Adam Ford wrote:
> > > > > > > > > On Thu, May 20, 2021 at 6:25 AM Marek Behún 
> > > > > > > > > 
> > > > > > > > > wrote:  
> > > > > > > > > >
> > > > > > > > > > Enable LTO for some boards that were tested by people on 
> > > > > > > > > > U-Boot
> > > > > > > > > > Mailing List.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Marek Behún 
> > > > > > > > > > Tested-by: Adam Ford 
> > > > > > > > > > Tested-by: Pali Rohár 
> > > > > > > > > > Tested-by: Tim Harvey   
> > > > > > > > > 
> > > > > > > > > Since the imx8mm beacon boards and the imx8mm venice board 
> > > > > > > > > both show
> > > > > > > > > promise, does it make sense to 'imply' the LTO for anything 
> > > > > > > > > enabling
> > > > > > > > > imx8mm?
> > > > > > > > > Same thing for the various omap3 boards, and potentially the 
> > > > > > > > > renesas
> > > > > > > > > RZ/G2 boards.  I know Tom went through to remove a bunch of 
> > > > > > > > > boards
> > > > > > > > > that were never converted to DM.  Most of the boards remaining
> > > > > > > > > boards have minimal board files and most of code is common to 
> > > > > > > > > other
> > > > > > > > > boards in the same platforms.
> > > > > > > > > 
> > > > > > > > > I have an l138_lcdk that I can use to test which I expect to 
> > > > > > > > > be
> > > > > > > > > similar to the da850evm.  
> > > > > > > > 
> > > > > > > > As much as I am eager to move everything, quickly, over to LTO 
> > > > > > > > by
> > > > > > > > default, I think the problems that we've seen thus far show 
> > > > > > > > it's best
> > > > > > > > to really make it an explicit enable per board at least for the 
> > > > > > > > first
> > > > > > > > release or two.  Once we've hopefully gotten more boards tested 
> > > > > > > > and
> > > > > > > > enabled we can see what makes sense for defaults, give a 
> > > > > > > > release worth
> > > > > > > > of heads up, and then go.
> > > > > > > 
> > > > > > > Tom, are there some other issues aside from the one failing CI 
> > > > > > > scenario
> > > > > > > (sandbox_clang)? Would you be willing to merge this if I resolved 
> > > > > > > that
> > > > > > > one fail by disabling LTO for that scenario (until I resolve it)? 
> > > > > > > It
> > > > > > > would help me not having to maintain all 30+ patches...
> > > > > > 
> > > > > > Yeah, CI needs to keep passing, so if we need to disable
> > > > > > sandbox+clang+lto for now, OK.
> > > > > 
> > > > > Ah, I see the problem now.  I've worked out a fix after looking at the
> > > > > Linux kernel a bit and I'll post something for us and upstream dtc as
> > > > > well.
> > > > >   
> > > > 
> > > > What do you mean? The problem is in dtc? I see 2 problems:
> > > > - one with DM test
> > > > - one with stack protector test  
> > > 
> > > I don't have a full answer about the stack protector test just yet, but
> > > it almost seems like it's too simple and maybe something is happening
> > > with it being optimized to not a problem?  
> > 
> > Yeah, so clang with LTO optimizes away that memset call, and so the test
> > passes.  I'll do something to make sure the array is used so it won't be
> > optimized away.
> > 
> 
> I am unable to make the compiler to protect the stack of that function
> even with GCC on my local machine. It seems that at least on my gentoo
> with gcc-10.2, when compiling with -ffreestanding, the call to
> __stack_chk_fail is not made at all.
> 
> I even started reading sources of gcc on thursday because of this, but
> it didn't lead anywhere...
> 
> When you compile sandbox_defconfig with gcc, does the test pass on your
> local machine?

It passes here with gcc-7.5 as well as gcc-9.2.0 in CI.  When I moved to
a gcc-11 snapshot in CI, it was also passing there before, so I'm not
sure what's going on in your setup.  But as part of coming up with the
patch I sent to fix the test, I ran it manually and saw the expected
failure message.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Tom Rini
On Mon, May 24, 2021 at 05:58:55PM +0200, Marek Behun wrote:
> On Mon, 24 May 2021 11:40:53 -0400
> Tom Rini  wrote:
> 
> > On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:
> > > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:  
> > > > On Fri, 21 May 2021 10:11:47 -0400
> > > > Tom Rini  wrote:
> > > >   
> > > > > On Thu, May 20, 2021 at 01:56:29PM -0500, Adam Ford wrote:  
> > > > > > On Thu, May 20, 2021 at 6:25 AM Marek Behún 
> > > > > > wrote:
> > > > > > >
> > > > > > > Enable LTO for some boards that were tested by people on U-Boot
> > > > > > > Mailing List.
> > > > > > >
> > > > > > > Signed-off-by: Marek Behún 
> > > > > > > Tested-by: Adam Ford 
> > > > > > > Tested-by: Pali Rohár 
> > > > > > > Tested-by: Tim Harvey 
> > > > > > 
> > > > > > Since the imx8mm beacon boards and the imx8mm venice board both show
> > > > > > promise, does it make sense to 'imply' the LTO for anything enabling
> > > > > > imx8mm?
> > > > > > Same thing for the various omap3 boards, and potentially the renesas
> > > > > > RZ/G2 boards.  I know Tom went through to remove a bunch of boards
> > > > > > that were never converted to DM.  Most of the boards remaining
> > > > > > boards have minimal board files and most of code is common to other
> > > > > > boards in the same platforms.
> > > > > > 
> > > > > > I have an l138_lcdk that I can use to test which I expect to be
> > > > > > similar to the da850evm.
> > > > > 
> > > > > As much as I am eager to move everything, quickly, over to LTO by
> > > > > default, I think the problems that we've seen thus far show it's best
> > > > > to really make it an explicit enable per board at least for the first
> > > > > release or two.  Once we've hopefully gotten more boards tested and
> > > > > enabled we can see what makes sense for defaults, give a release worth
> > > > > of heads up, and then go.  
> > > > 
> > > > Tom, are there some other issues aside from the one failing CI scenario
> > > > (sandbox_clang)? Would you be willing to merge this if I resolved that
> > > > one fail by disabling LTO for that scenario (until I resolve it)? It
> > > > would help me not having to maintain all 30+ patches...  
> > > 
> > > Yeah, CI needs to keep passing, so if we need to disable
> > > sandbox+clang+lto for now, OK.  
> > 
> > Ah, I see the problem now.  I've worked out a fix after looking at the
> > Linux kernel a bit and I'll post something for us and upstream dtc as
> > well.
> > 
> 
> What do you mean? The problem is in dtc? I see 2 problems:
> - one with DM test

So, this looks like another case of the optimizer being so good it
causes the test to fail.  Happily in this case, a patch Simon made to
fix coverity complaining about using srand/rand here:
https://patchwork.ozlabs.org/project/uboot/patch/20210514014011.2832707-5-...@chromium.org/
also gets the test passing with LTO.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH RFC 2/2] efi_loader: Work-around build issue due to missing hash_calculate()

2021-05-24 Thread Alexandru Gagniuc
The hash_calculate() symbol is provided by hash-checksum.c. It depends
on hash_progressive_lookup_algo(), provided when CONFIG_HASH=y.

The issue is that hash_calculate() is used by the efi_loader,
irregardless of CONFIG_FIT_SIGNATURE. As pointed out in
commit 87316da05f2f ("lib: introduce HASH_CALCULATE option"),
enabling hash_calculate() based on CONFIG_FIT_SIGNATURE is incorrect.

To resolve this, use CONFIG_HASH as the compile switch for
hash-checksum.c. This ensures that all dependencies are compiled, and
is the most natural Kconfig to use.

There is the issue of having to 'select HASH' in a couple of places
that already 'select SHA256'. This is a deeper problem with how hashes
are organized, and fixing it is beyonf the scope of this change.

Signed-off-by: Alexandru Gagniuc 
---
 lib/Makefile   | 2 +-
 lib/efi_loader/Kconfig | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/Makefile b/lib/Makefile
index 6825671955..b4795a62a0 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -61,7 +61,7 @@ endif
 obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi/
 obj-$(CONFIG_$(SPL_)MD5) += md5.o
 obj-$(CONFIG_$(SPL_)RSA) += rsa/
-obj-$(CONFIG_FIT_SIGNATURE) += hash-checksum.o
+obj-$(CONFIG_HASH) += hash-checksum.o
 obj-$(CONFIG_SHA1) += sha1.o
 obj-$(CONFIG_SHA256) += sha256.o
 obj-$(CONFIG_SHA512_ALGO) += sha512.o
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c259abe033..b112e62334 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -166,6 +166,7 @@ config EFI_CAPSULE_AUTHENTICATE
depends on EFI_CAPSULE_FIRMWARE
depends on EFI_CAPSULE_ON_DISK
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
+   select HASH
select SHA256
select RSA
select RSA_VERIFY
@@ -333,6 +334,7 @@ config EFI_LOAD_FILE2_INITRD
 config EFI_SECURE_BOOT
bool "Enable EFI secure boot support"
depends on EFI_LOADER
+   select HASH
select SHA256
select RSA
select RSA_VERIFY_WITH_PKEY
-- 
2.31.1



[PATCH RFC 1/2] Revert "lib: introduce HASH_CALCULATE option"

2021-05-24 Thread Alexandru Gagniuc
When we think of Kconfig, we usually think of features that we like
to enable or not. Ideally, we wouldn't use Kconfig to fix a build
issue, although sometimes it might make sense. With Kconfig it's hard
to guarantee that the fix is universal. We can only say that it works
for the set of tested configurations. In the majority of cases, it's
preferable to let the linker figure things out for us.

The reverted commit attempted to fix a build issue by adding an
invisible Kconfig option. This is wrong in several ways:

It invents a new Kconfig variable when CONFIG_HASH already
exists for the same purpose.
Second, hash-checksum.c makes use of the hash_progressive_lookup_algo()
symbol, which is only provided with CONFIG_HASH, but this dependency
was not expressed in the reverted patch.

It feels like Kconfig is turning into a listing of all available
source files, and a buffet to 'select' which ones to compile. The
purpose of this revert is to enable the next change to make use of
CONFIG_HASH instead of adding to Kconfig.

This reverts commit 87316da05f2fd49d3709275e64ef0c5980366ade.

Signed-off-by: Alexandru Gagniuc 
---
 common/Kconfig.boot| 1 -
 lib/Kconfig| 3 ---
 lib/Makefile   | 2 +-
 lib/efi_loader/Kconfig | 2 --
 4 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 3c6e77d099..89a3161f1f 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -80,7 +80,6 @@ config FIT_SIGNATURE
select RSA_VERIFY
select IMAGE_SIGN_INFO
select FIT_FULL_CHECK
-   select HASH_CALCULATE
help
  This option enables signature verification of FIT uImages,
  using a hash signed and verified using RSA. If
diff --git a/lib/Kconfig b/lib/Kconfig
index d675ab1d82..15019d2c65 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -439,9 +439,6 @@ config CRC32C
 config XXHASH
bool
 
-config HASH_CALCULATE
-   bool
-
 endmenu
 
 menu "Compression Support"
diff --git a/lib/Makefile b/lib/Makefile
index 0835ea292c..6825671955 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -61,7 +61,7 @@ endif
 obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi/
 obj-$(CONFIG_$(SPL_)MD5) += md5.o
 obj-$(CONFIG_$(SPL_)RSA) += rsa/
-obj-$(CONFIG_HASH_CALCULATE) += hash-checksum.o
+obj-$(CONFIG_FIT_SIGNATURE) += hash-checksum.o
 obj-$(CONFIG_SHA1) += sha1.o
 obj-$(CONFIG_SHA256) += sha256.o
 obj-$(CONFIG_SHA512_ALGO) += sha512.o
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index eb5c4d6f29..c259abe033 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -174,7 +174,6 @@ config EFI_CAPSULE_AUTHENTICATE
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
select IMAGE_SIGN_INFO
-   select HASH_CALCULATE
default n
help
  Select this option if you want to enable capsule
@@ -343,7 +342,6 @@ config EFI_SECURE_BOOT
select X509_CERTIFICATE_PARSER
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
-   select HASH_CALCULATE
default n
help
  Select this option to enable EFI secure boot support.
-- 
2.31.1



[PATCH RFC 0/2] lib: Remove the need for a HASH_CALCULATE config

2021-05-24 Thread Alexandru Gagniuc
I had accidentally noticed commit 87316da05f2f ("lib: introduce
HASH_CALCULATE option"), when rebasing an unrelated series. It
immediately caught my attention because It seemed to me to increase
complexity, without any actual benefit.

In this series, I present an alternative approach, which solves the
problem by leveraging existing infrastructure instead of adding more
Kconfig variables.

Alexandru Gagniuc (2):
  Revert "lib: introduce HASH_CALCULATE option"
  efi_loader: Work-around build issue due to missing hash_calculate()

 common/Kconfig.boot| 1 -
 lib/Kconfig| 3 ---
 lib/Makefile   | 2 +-
 lib/efi_loader/Kconfig | 4 ++--
 4 files changed, 3 insertions(+), 7 deletions(-)

-- 
2.31.1



Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Marek Behun
On Mon, 24 May 2021 13:44:38 -0400
Tom Rini  wrote:

> On Mon, May 24, 2021 at 01:09:19PM -0400, Tom Rini wrote:
> > On Mon, May 24, 2021 at 05:58:55PM +0200, Marek Behun wrote:  
> > > On Mon, 24 May 2021 11:40:53 -0400
> > > Tom Rini  wrote:
> > >   
> > > > On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:  
> > > > > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:
> > > > > > On Fri, 21 May 2021 10:11:47 -0400
> > > > > > Tom Rini  wrote:
> > > > > > 
> > > > > > > On Thu, May 20, 2021 at 01:56:29PM -0500, Adam Ford wrote:
> > > > > > > > On Thu, May 20, 2021 at 6:25 AM Marek Behún 
> > > > > > > > wrote:  
> > > > > > > > >
> > > > > > > > > Enable LTO for some boards that were tested by people on 
> > > > > > > > > U-Boot
> > > > > > > > > Mailing List.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Marek Behún 
> > > > > > > > > Tested-by: Adam Ford 
> > > > > > > > > Tested-by: Pali Rohár 
> > > > > > > > > Tested-by: Tim Harvey   
> > > > > > > > 
> > > > > > > > Since the imx8mm beacon boards and the imx8mm venice board both 
> > > > > > > > show
> > > > > > > > promise, does it make sense to 'imply' the LTO for anything 
> > > > > > > > enabling
> > > > > > > > imx8mm?
> > > > > > > > Same thing for the various omap3 boards, and potentially the 
> > > > > > > > renesas
> > > > > > > > RZ/G2 boards.  I know Tom went through to remove a bunch of 
> > > > > > > > boards
> > > > > > > > that were never converted to DM.  Most of the boards remaining
> > > > > > > > boards have minimal board files and most of code is common to 
> > > > > > > > other
> > > > > > > > boards in the same platforms.
> > > > > > > > 
> > > > > > > > I have an l138_lcdk that I can use to test which I expect to be
> > > > > > > > similar to the da850evm.  
> > > > > > > 
> > > > > > > As much as I am eager to move everything, quickly, over to LTO by
> > > > > > > default, I think the problems that we've seen thus far show it's 
> > > > > > > best
> > > > > > > to really make it an explicit enable per board at least for the 
> > > > > > > first
> > > > > > > release or two.  Once we've hopefully gotten more boards tested 
> > > > > > > and
> > > > > > > enabled we can see what makes sense for defaults, give a release 
> > > > > > > worth
> > > > > > > of heads up, and then go.
> > > > > > 
> > > > > > Tom, are there some other issues aside from the one failing CI 
> > > > > > scenario
> > > > > > (sandbox_clang)? Would you be willing to merge this if I resolved 
> > > > > > that
> > > > > > one fail by disabling LTO for that scenario (until I resolve it)? It
> > > > > > would help me not having to maintain all 30+ patches...
> > > > > 
> > > > > Yeah, CI needs to keep passing, so if we need to disable
> > > > > sandbox+clang+lto for now, OK.
> > > > 
> > > > Ah, I see the problem now.  I've worked out a fix after looking at the
> > > > Linux kernel a bit and I'll post something for us and upstream dtc as
> > > > well.
> > > >   
> > > 
> > > What do you mean? The problem is in dtc? I see 2 problems:
> > > - one with DM test
> > > - one with stack protector test  
> > 
> > I don't have a full answer about the stack protector test just yet, but
> > it almost seems like it's too simple and maybe something is happening
> > with it being optimized to not a problem?  
> 
> Yeah, so clang with LTO optimizes away that memset call, and so the test
> passes.  I'll do something to make sure the array is used so it won't be
> optimized away.
> 

I am unable to make the compiler to protect the stack of that function
even with GCC on my local machine. It seems that at least on my gentoo
with gcc-10.2, when compiling with -ffreestanding, the call to
__stack_chk_fail is not made at all.

I even started reading sources of gcc on thursday because of this, but
it didn't lead anywhere...

When you compile sandbox_defconfig with gcc, does the test pass on your
local machine?

Marek


Re: [PATCH] test: Fix filesystem tests always being skipped

2021-05-24 Thread Andy Shevchenko
On Thu, May 20, 2021 at 10:09:46PM +0300, Alper Nebi Yasak wrote:
> Commit 1ba21bb06b08 ("test: Don't unmount not (yet) mounted system")
> fixes an issue in the filesystem tests where the test setup may fail
> to mount an image and still attempt to unmount it. However, the commit
> unintentionally breaks the test setups in two ways.
> 
> The newly created unmounted filesystem images are being immediately
> deleted due to some cleanup steps being misplaced into finally blocks,
> which makes them always run instead of only on failures. The mount calls
> always fail since the images never exist, causing the tests to be always
> skipped. This patch moves these cleanup calls into the except blocks to
> fix this and makes the tests run again.
> 
> There are also unmount calls misplaced into finally blocks, making them
> run after the tests instead of before the tests. These unmount calls
> make the filesystem image file consistent with the changes made to it as
> part of the test setup, and this misplacement is making a number of
> tests fail unexpectedly.
> 
> The unmount calls must be run before the tests use the image, meaning
> before the yield call and not in the finally block. They must also be
> run as a cleanup step when the filesystem setup fails, so they can't be
> placed as the final call in the try blocks since they would be skipped
> on such failures. For these reasons, this patch places the unmount calls
> both in the except blocks and the else blocks of the final setup step.
> This makes the unexpectedly failing tests to succeed again.
> 
> Furthermore, this isolates the mount calls to their own try-except
> statement to avoid reintroducing the original issue of unmounting a
> not-mounted image while fixing the unmount misplacement.
> 
> After these fixes, running "make tests" with guestmount available results
> in two test failures not related to the mentioned commit. If the
> guestmount executables are unavailable, the mounts fallback to using
> sudo and result in no failures.
> 
> Fixes: 1ba21bb06b08 ("test: Don't unmount not (yet) mounted system")
> Signed-off-by: Alper Nebi Yasak 
> ---
> There is more discussion at Heinrich's revert-patch [1] of the mentioned
> commit. This patch is an alternative to the revert.
> 
> Andy: I don't think unmounting the failed-to-mount image was the cause
> of the sudo call you described in that commit, so I believe this would
> end up running sudo on your system. Wanted to warn in advance, but looks
> like your issue needs a different solution.

Thanks for doing this!

If you think this fix is a right thing to do, go ahead for it, I prefer it over
revert.

Acked-by: Andy Shevchenko 

> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20210513114035.177293-1-xypron.g...@gmx.de/
> 
>  test/py/tests/test_fs/conftest.py | 48 +++
>  1 file changed, 36 insertions(+), 12 deletions(-)
> 
> diff --git a/test/py/tests/test_fs/conftest.py 
> b/test/py/tests/test_fs/conftest.py
> index 50af9efcf768..410a675b9714 100644
> --- a/test/py/tests/test_fs/conftest.py
> +++ b/test/py/tests/test_fs/conftest.py
> @@ -278,14 +278,19 @@ def fs_obj_basic(request, u_boot_config):
>  check_call('mkdir -p %s' % mount_dir, shell=True)
>  except CalledProcessError as err:
>  pytest.skip('Preparing mount folder failed for filesystem: ' + 
> fs_type + '. {}'.format(err))
> -return
> -finally:
>  call('rm -f %s' % fs_img, shell=True)
> +return
>  
>  try:
>  # Mount the image so we can populate it.
>  mount_fs(fs_type, fs_img, mount_dir)
> +except CalledProcessError as err:
> +pytest.skip('Mounting to folder failed for filesystem: ' + fs_type + 
> '. {}'.format(err))
> +call('rmdir %s' % mount_dir, shell=True)
> +call('rm -f %s' % fs_img, shell=True)
> +return
>  
> +try:
>  # Create a subdirectory.
>  check_call('mkdir %s/SUBDIR' % mount_dir, shell=True)
>  
> @@ -348,11 +353,12 @@ def fs_obj_basic(request, u_boot_config):
>  
>  except CalledProcessError as err:
>  pytest.skip('Setup failed for filesystem: ' + fs_type + '. 
> {}'.format(err))
> +umount_fs(mount_dir)
>  return
>  else:
> +umount_fs(mount_dir)
>  yield [fs_ubtype, fs_img, md5val]
>  finally:
> -umount_fs(mount_dir)
>  call('rmdir %s' % mount_dir, shell=True)
>  call('rm -f %s' % fs_img, shell=True)
>  
> @@ -394,14 +400,19 @@ def fs_obj_ext(request, u_boot_config):
>  check_call('mkdir -p %s' % mount_dir, shell=True)
>  except CalledProcessError as err:
>  pytest.skip('Preparing mount folder failed for filesystem: ' + 
> fs_type + '. {}'.format(err))
> -return
> -finally:
>  call('rm -f %s' % fs_img, shell=True)
> +return
>  
>  try:
>  # Mount the image so we can populate it.
>  mount_fs(fs_type, fs_img, mount_dir)
> +

[PATCH] stackprot: Make our test a bit more complex

2021-05-24 Thread Tom Rini
With better compiler optimizations available, a compiler may see we do
nothing with our buffer after calling memset and omit the call, thus
causing us to not smash the stack.  Add a comment to explain why we now
also have a printf call, so that the test will pass as the memset will
not be omitted.

Reported-by: Marek Behún 
Signed-off-by: Tom Rini 
---
 cmd/stackprot_test.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/cmd/stackprot_test.c b/cmd/stackprot_test.c
index 36f5bac8d230..1e26193e88b0 100644
--- a/cmd/stackprot_test.c
+++ b/cmd/stackprot_test.c
@@ -9,9 +9,16 @@
 static int do_test_stackprot_fail(struct cmd_tbl *cmdtp, int flag, int argc,
  char *const argv[])
 {
+   /*
+* In order to avoid having the compiler optimize away the stack 
smashing
+* we need to do a little something here.
+*/
char a[128];
 
memset(a, 0xa5, 512);
+
+   printf("We have smashed our stack as this should not exceed 128: 
sizeof(a) = %ld\n", strlen(a));
+
return 0;
 }
 
-- 
2.17.1



[Contributor call] Request for agenda items

2021-05-24 Thread Simon Glass
Hi,

If you plan to join tomorrow and want to add a topic, please do so at [1].

For now the main topic is to talk about VPL, the Verifying Program Loader,
a proposed new phase of U-Boot.

Regards,
Simon

[1] https://bit.ly/3bFvwA1
or
https://docs.google.com/document/d/1YBOMsbM19uSFyoJWnt7-PsOLBaevzQUgV-hiR88a5-o/edit#heading=h.flytinyefvov


[PATCH] clk: clk_versaclock: Add support for versaclock driver

2021-05-24 Thread Adam Ford
The driver is based on the Versaclock driver from the Linux code, but
do differences in the clock API between them, some pieces had to change.

This driver creates a mux, pfd, pll, and a series of fod ouputs.
 Rate   Usecnt  Name
--
 2500 0`-- x304-clock
 2500 0`-- clock-control...@6a.mux
 2500 0|-- clock-control...@6a.pfd
 28   0|   `-- clock-control...@6a.pll
  0|   |-- clock-controller@6a.fod0
  0|   |   `-- clock-controller@6a.out1
  0|   |-- clock-controller@6a.fod1
  0|   |   `-- clock-controller@6a.out2
 5000 0|   |-- clock-controller@6a.fod2
 5000 0|   |   `-- clock-controller@6a.out3
 125000|   `-- clock-controller@6a.fod3
 125000|   `-- clock-controller@6a.out4
 2500 0`-- clock-controller@6a.out0_sel_i2cb

A translation function is added so the references to < X> get routed
to the corresponding clock-control...@6a.outx.

Signed-off-by: Adam Ford 

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 40a5a5dd88..75adccc138 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -197,4 +197,12 @@ config SANDBOX_CLK_CCF
  Enable this option if you want to test the Linux kernel's Common
  Clock Framework [CCF] code in U-Boot's Sandbox clock driver.
 
+config CLK_VERSACLOCK
+   tristate "Enable VersaClock 5/6 devices"
+   depends on CLK
+   depends on OF_CONTROL
+   help
+ This driver supports the IDT VersaClock 5 and VersaClock 6
+ programmable clock generators.
+
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 645709b855..2a9ebec860 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
 obj-$(CONFIG_STM32H7) += clk_stm32h7.o
 obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
 obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
+obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o
diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
new file mode 100644
index 00..30e49fad31
--- /dev/null
+++ b/drivers/clk/clk_versaclock.c
@@ -0,0 +1,1025 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Driver for IDT Versaclock 5/6
+ *
+ * Derived from code Copyright (C) 2017 Marek Vasut 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* VersaClock5 registers */
+#define VC5_OTP_CONTROL0x00
+
+/* Factory-reserved register block */
+#define VC5_RSVD_DEVICE_ID 0x01
+#define VC5_RSVD_ADC_GAIN_7_0  0x02
+#define VC5_RSVD_ADC_GAIN_15_8 0x03
+#define VC5_RSVD_ADC_OFFSET_7_00x04
+#define VC5_RSVD_ADC_OFFSET_15_8   0x05
+#define VC5_RSVD_TEMPY 0x06
+#define VC5_RSVD_OFFSET_TBIN   0x07
+#define VC5_RSVD_GAIN  0x08
+#define VC5_RSVD_TEST_NP   0x09
+#define VC5_RSVD_UNUSED0x0a
+#define VC5_RSVD_BANDGAP_TRIM_UP   0x0b
+#define VC5_RSVD_BANDGAP_TRIM_DN   0x0c
+#define VC5_RSVD_CLK_R_12_CLK_AMP_40x0d
+#define VC5_RSVD_CLK_R_34_CLK_AMP_40x0e
+#define VC5_RSVD_CLK_AMP_123   0x0f
+
+/* Configuration register block */
+#define VC5_PRIM_SRC_SHDN  0x10
+#define VC5_PRIM_SRC_SHDN_EN_XTAL  BIT(7)
+#define VC5_PRIM_SRC_SHDN_EN_CLKIN BIT(6)
+#define VC5_PRIM_SRC_SHDN_EN_DOUBLE_XTAL_FREQ  BIT(3)
+#define VC5_PRIM_SRC_SHDN_SP   BIT(1)
+#define VC5_PRIM_SRC_SHDN_EN_GBL_SHDN  BIT(0)
+
+#define VC5_VCO_BAND   0x11
+#define VC5_XTAL_X1_LOAD_CAP   0x12
+#define VC5_XTAL_X2_LOAD_CAP   0x13
+#define VC5_REF_DIVIDER0x15
+#define VC5_REF_DIVIDER_SEL_PREDIV2BIT(7)
+#define VC5_REF_DIVIDER_REF_DIV(n) ((n) & 0x3f)
+
+#define VC5_VCO_CTRL_AND_PREDIV0x16
+#define VC5_VCO_CTRL_AND_PREDIV_BYPASS_PREDIV  BIT(7)
+
+#define VC5_FEEDBACK_INT_DIV   0x17
+#define VC5_FEEDBACK_INT_DIV_BITS  0x18
+#define VC5_FEEDBACK_FRAC_DIV(n)   (0x19 + (n))
+#define VC5_RC_CONTROL00x1e
+#define VC5_RC_CONTROL10x1f
+/* Register 0x20 is factory reserved */
+
+/* Output divider control for divider 1,2,3,4 */

Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Tom Rini
On Mon, May 24, 2021 at 01:09:19PM -0400, Tom Rini wrote:
> On Mon, May 24, 2021 at 05:58:55PM +0200, Marek Behun wrote:
> > On Mon, 24 May 2021 11:40:53 -0400
> > Tom Rini  wrote:
> > 
> > > On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:
> > > > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:  
> > > > > On Fri, 21 May 2021 10:11:47 -0400
> > > > > Tom Rini  wrote:
> > > > >   
> > > > > > On Thu, May 20, 2021 at 01:56:29PM -0500, Adam Ford wrote:  
> > > > > > > On Thu, May 20, 2021 at 6:25 AM Marek Behún 
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Enable LTO for some boards that were tested by people on U-Boot
> > > > > > > > Mailing List.
> > > > > > > >
> > > > > > > > Signed-off-by: Marek Behún 
> > > > > > > > Tested-by: Adam Ford 
> > > > > > > > Tested-by: Pali Rohár 
> > > > > > > > Tested-by: Tim Harvey 
> > > > > > > 
> > > > > > > Since the imx8mm beacon boards and the imx8mm venice board both 
> > > > > > > show
> > > > > > > promise, does it make sense to 'imply' the LTO for anything 
> > > > > > > enabling
> > > > > > > imx8mm?
> > > > > > > Same thing for the various omap3 boards, and potentially the 
> > > > > > > renesas
> > > > > > > RZ/G2 boards.  I know Tom went through to remove a bunch of boards
> > > > > > > that were never converted to DM.  Most of the boards remaining
> > > > > > > boards have minimal board files and most of code is common to 
> > > > > > > other
> > > > > > > boards in the same platforms.
> > > > > > > 
> > > > > > > I have an l138_lcdk that I can use to test which I expect to be
> > > > > > > similar to the da850evm.
> > > > > > 
> > > > > > As much as I am eager to move everything, quickly, over to LTO by
> > > > > > default, I think the problems that we've seen thus far show it's 
> > > > > > best
> > > > > > to really make it an explicit enable per board at least for the 
> > > > > > first
> > > > > > release or two.  Once we've hopefully gotten more boards tested and
> > > > > > enabled we can see what makes sense for defaults, give a release 
> > > > > > worth
> > > > > > of heads up, and then go.  
> > > > > 
> > > > > Tom, are there some other issues aside from the one failing CI 
> > > > > scenario
> > > > > (sandbox_clang)? Would you be willing to merge this if I resolved that
> > > > > one fail by disabling LTO for that scenario (until I resolve it)? It
> > > > > would help me not having to maintain all 30+ patches...  
> > > > 
> > > > Yeah, CI needs to keep passing, so if we need to disable
> > > > sandbox+clang+lto for now, OK.  
> > > 
> > > Ah, I see the problem now.  I've worked out a fix after looking at the
> > > Linux kernel a bit and I'll post something for us and upstream dtc as
> > > well.
> > > 
> > 
> > What do you mean? The problem is in dtc? I see 2 problems:
> > - one with DM test
> > - one with stack protector test
> 
> I don't have a full answer about the stack protector test just yet, but
> it almost seems like it's too simple and maybe something is happening
> with it being optimized to not a problem?

Yeah, so clang with LTO optimizes away that memset call, and so the test
passes.  I'll do something to make sure the array is used so it won't be
optimized away.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 5/5] pico-imx6ul: disable video after DM_VIDEO conversion deadline

2021-05-24 Thread Anatolij Gustschin
These boards were not converted to DM_VIDEO before deadline,
so disable video support for now.

Signed-off-by: Anatolij Gustschin 
Cc: Richard Hu 
Cc: Fabio Estevam 
---
 configs/pico-dwarf-imx6ul_defconfig  | 4 ++--
 configs/pico-hobbit-imx6ul_defconfig | 4 ++--
 configs/pico-pi-imx6ul_defconfig | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/configs/pico-dwarf-imx6ul_defconfig 
b/configs/pico-dwarf-imx6ul_defconfig
index 9695eb2657..bf016f80ed 100644
--- a/configs/pico-dwarf-imx6ul_defconfig
+++ b/configs/pico-dwarf-imx6ul_defconfig
@@ -68,7 +68,7 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_RLE8 is not set
diff --git a/configs/pico-hobbit-imx6ul_defconfig 
b/configs/pico-hobbit-imx6ul_defconfig
index 5c1ca0b8d7..14d36c5e6a 100644
--- a/configs/pico-hobbit-imx6ul_defconfig
+++ b/configs/pico-hobbit-imx6ul_defconfig
@@ -71,7 +71,7 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_RLE8 is not set
diff --git a/configs/pico-pi-imx6ul_defconfig b/configs/pico-pi-imx6ul_defconfig
index 51b71a77e5..ba8b1a1e8e 100644
--- a/configs/pico-pi-imx6ul_defconfig
+++ b/configs/pico-pi-imx6ul_defconfig
@@ -71,7 +71,7 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_RLE8 is not set
-- 
2.17.1



[PATCH 3/5] mx28evk: disable video after DM_VIDEO conversion deadline

2021-05-24 Thread Anatolij Gustschin
The board was not converted to DM_VIDEO before deadline, so disable
video support for now.

Signed-off-by: Anatolij Gustschin 
Cc: Fabio Estevam 
---
 configs/mx28evk_auart_console_defconfig | 6 +++---
 configs/mx28evk_defconfig   | 6 +++---
 configs/mx28evk_nand_defconfig  | 6 +++---
 configs/mx28evk_spi_defconfig   | 6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/configs/mx28evk_auart_console_defconfig 
b/configs/mx28evk_auart_console_defconfig
index ec4fd6585e..60b9f3999e 100644
--- a/configs/mx28evk_auart_console_defconfig
+++ b/configs/mx28evk_auart_console_defconfig
@@ -56,8 +56,8 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_SMSC95XX=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 CONFIG_SPLASH_SCREEN=y
-CONFIG_VIDEO_BMP_GZIP=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_GZIP is not set
+# CONFIG_VIDEO_BMP_RLE8 is not set
 CONFIG_OF_LIBFDT=y
diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index 4f0ed83bc1..abc0c48d21 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -56,8 +56,8 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_SMSC95XX=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 CONFIG_SPLASH_SCREEN=y
-CONFIG_VIDEO_BMP_GZIP=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_GZIP is not set
+# CONFIG_VIDEO_BMP_RLE8 is not set
 CONFIG_OF_LIBFDT=y
diff --git a/configs/mx28evk_nand_defconfig b/configs/mx28evk_nand_defconfig
index 7d95b8fc52..0a376a2f80 100644
--- a/configs/mx28evk_nand_defconfig
+++ b/configs/mx28evk_nand_defconfig
@@ -57,8 +57,8 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_SMSC95XX=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 CONFIG_SPLASH_SCREEN=y
-CONFIG_VIDEO_BMP_GZIP=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_GZIP is not set
+# CONFIG_VIDEO_BMP_RLE8 is not set
 CONFIG_OF_LIBFDT=y
diff --git a/configs/mx28evk_spi_defconfig b/configs/mx28evk_spi_defconfig
index e969d50af7..a6b00c29f5 100644
--- a/configs/mx28evk_spi_defconfig
+++ b/configs/mx28evk_spi_defconfig
@@ -53,8 +53,8 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_SMSC95XX=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 CONFIG_SPLASH_SCREEN=y
-CONFIG_VIDEO_BMP_GZIP=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_GZIP is not set
+# CONFIG_VIDEO_BMP_RLE8 is not set
 CONFIG_OF_LIBFDT=y
-- 
2.17.1



[PATCH 4/5] brxre1: disable video after DM_VIDEO conversion deadline

2021-05-24 Thread Anatolij Gustschin
The board was not converted to DM_VIDEO before deadline, so disable
video support for now.

Signed-off-by: Anatolij Gustschin 
Cc: Hannes Schmelzer 
---
 board/BuR/brxre1/board.c | 9 +
 configs/brxre1_defconfig | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/board/BuR/brxre1/board.c b/board/BuR/brxre1/board.c
index ef692b006d..544e09f447 100644
--- a/board/BuR/brxre1/board.c
+++ b/board/BuR/brxre1/board.c
@@ -164,12 +164,21 @@ int board_late_init(void)
br_resetc_bmode();
 
/* setup othbootargs for bootvx-command (vxWorks bootline) */
+#ifdef CONFIG_LCD
snprintf(othbootargs, sizeof(othbootargs),
 "u=vxWorksFTP pw=vxWorks o=0x%08x;0x%08x;0x%08x;0x%08x",
 (u32)gd->fb_base - 0x20,
 (u32)env_get_ulong("vx_memtop", 16, gd->fb_base - 0x20),
 (u32)env_get_ulong("vx_romfsbase", 16, 0),
 (u32)env_get_ulong("vx_romfssize", 16, 0));
+#else
+   snprintf(othbootargs, sizeof(othbootargs),
+"u=vxWorksFTP pw=vxWorks o=0x%08x;0x%08x;0x%08x;0x%08x",
+(u32)gd->relocaddr,
+(u32)env_get_ulong("vx_memtop", 16, gd->relocaddr),
+(u32)env_get_ulong("vx_romfsbase", 16, 0),
+(u32)env_get_ulong("vx_romfssize", 16, 0));
+#endif
env_set("othbootargs", othbootargs);
/*
 * reset VBAR registers to its reset location, VxWorks 6.9.3.2 does
diff --git a/configs/brxre1_defconfig b/configs/brxre1_defconfig
index 57f3f437d9..6d9f24314f 100644
--- a/configs/brxre1_defconfig
+++ b/configs/brxre1_defconfig
@@ -92,8 +92,8 @@ CONFIG_USB_MUSB_TI=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_SYS_WHITE_ON_BLACK=y
-CONFIG_AM335X_LCD=y
-CONFIG_LCD=y
+# CONFIG_AM335X_LCD is not set
+# CONFIG_LCD is not set
 CONFIG_SPL_TINY_MEMSET=y
 # CONFIG_OF_LIBFDT_OVERLAY is not set
 # CONFIG_EFI_LOADER is not set
-- 
2.17.1



[PATCH 2/5] pxm2: disable video after DM_VIDEO conversion deadline

2021-05-24 Thread Anatolij Gustschin
The board was not converted to DM_VIDEO before deadline, so disable
video support for now.

Signed-off-by: Anatolij Gustschin 
Cc: Samuel Egli 
---
 configs/pxm2_defconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/pxm2_defconfig b/configs/pxm2_defconfig
index 90ef4c8d99..da6b1bb0e3 100644
--- a/configs/pxm2_defconfig
+++ b/configs/pxm2_defconfig
@@ -101,10 +101,10 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x02d2
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_SYS_CONSOLE_BG_COL=0xff
 CONFIG_SYS_CONSOLE_FG_COL=0x00
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_RLE8 is not set
-- 
2.17.1



[PATCH 1/5] rut: disable video after DM_VIDEO conversion deadline

2021-05-24 Thread Anatolij Gustschin
The board was not converted to DM_VIDEO before deadline, so disable
video support for now.

Signed-off-by: Anatolij Gustschin 
Cc: Samuel Egli 
---
 configs/rut_defconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/rut_defconfig b/configs/rut_defconfig
index 6fc06f1ed9..5b15789100 100644
--- a/configs/rut_defconfig
+++ b/configs/rut_defconfig
@@ -101,10 +101,10 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0908
 CONFIG_USB_GADGET_PRODUCT_NUM=0x02d2
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
-CONFIG_VIDEO=y
+# CONFIG_VIDEO is not set
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_SYS_CONSOLE_BG_COL=0xff
 CONFIG_SYS_CONSOLE_FG_COL=0x00
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
+# CONFIG_VIDEO_BMP_RLE8 is not set
-- 
2.17.1



Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Tom Rini
On Mon, May 24, 2021 at 05:58:55PM +0200, Marek Behun wrote:
> On Mon, 24 May 2021 11:40:53 -0400
> Tom Rini  wrote:
> 
> > On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:
> > > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:  
> > > > On Fri, 21 May 2021 10:11:47 -0400
> > > > Tom Rini  wrote:
> > > >   
> > > > > On Thu, May 20, 2021 at 01:56:29PM -0500, Adam Ford wrote:  
> > > > > > On Thu, May 20, 2021 at 6:25 AM Marek Behún 
> > > > > > wrote:
> > > > > > >
> > > > > > > Enable LTO for some boards that were tested by people on U-Boot
> > > > > > > Mailing List.
> > > > > > >
> > > > > > > Signed-off-by: Marek Behún 
> > > > > > > Tested-by: Adam Ford 
> > > > > > > Tested-by: Pali Rohár 
> > > > > > > Tested-by: Tim Harvey 
> > > > > > 
> > > > > > Since the imx8mm beacon boards and the imx8mm venice board both show
> > > > > > promise, does it make sense to 'imply' the LTO for anything enabling
> > > > > > imx8mm?
> > > > > > Same thing for the various omap3 boards, and potentially the renesas
> > > > > > RZ/G2 boards.  I know Tom went through to remove a bunch of boards
> > > > > > that were never converted to DM.  Most of the boards remaining
> > > > > > boards have minimal board files and most of code is common to other
> > > > > > boards in the same platforms.
> > > > > > 
> > > > > > I have an l138_lcdk that I can use to test which I expect to be
> > > > > > similar to the da850evm.
> > > > > 
> > > > > As much as I am eager to move everything, quickly, over to LTO by
> > > > > default, I think the problems that we've seen thus far show it's best
> > > > > to really make it an explicit enable per board at least for the first
> > > > > release or two.  Once we've hopefully gotten more boards tested and
> > > > > enabled we can see what makes sense for defaults, give a release worth
> > > > > of heads up, and then go.  
> > > > 
> > > > Tom, are there some other issues aside from the one failing CI scenario
> > > > (sandbox_clang)? Would you be willing to merge this if I resolved that
> > > > one fail by disabling LTO for that scenario (until I resolve it)? It
> > > > would help me not having to maintain all 30+ patches...  
> > > 
> > > Yeah, CI needs to keep passing, so if we need to disable
> > > sandbox+clang+lto for now, OK.  
> > 
> > Ah, I see the problem now.  I've worked out a fix after looking at the
> > Linux kernel a bit and I'll post something for us and upstream dtc as
> > well.
> > 
> 
> What do you mean? The problem is in dtc? I see 2 problems:
> - one with DM test
> - one with stack protector test

I don't have a full answer about the stack protector test just yet, but
it almost seems like it's too simple and maybe something is happening
with it being optimized to not a problem?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Tom Rini
On Mon, May 24, 2021 at 05:58:55PM +0200, Marek Behun wrote:
> On Mon, 24 May 2021 11:40:53 -0400
> Tom Rini  wrote:
> 
> > On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:
> > > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:  
> > > > On Fri, 21 May 2021 10:11:47 -0400
> > > > Tom Rini  wrote:
> > > >   
> > > > > On Thu, May 20, 2021 at 01:56:29PM -0500, Adam Ford wrote:  
> > > > > > On Thu, May 20, 2021 at 6:25 AM Marek Behún 
> > > > > > wrote:
> > > > > > >
> > > > > > > Enable LTO for some boards that were tested by people on U-Boot
> > > > > > > Mailing List.
> > > > > > >
> > > > > > > Signed-off-by: Marek Behún 
> > > > > > > Tested-by: Adam Ford 
> > > > > > > Tested-by: Pali Rohár 
> > > > > > > Tested-by: Tim Harvey 
> > > > > > 
> > > > > > Since the imx8mm beacon boards and the imx8mm venice board both show
> > > > > > promise, does it make sense to 'imply' the LTO for anything enabling
> > > > > > imx8mm?
> > > > > > Same thing for the various omap3 boards, and potentially the renesas
> > > > > > RZ/G2 boards.  I know Tom went through to remove a bunch of boards
> > > > > > that were never converted to DM.  Most of the boards remaining
> > > > > > boards have minimal board files and most of code is common to other
> > > > > > boards in the same platforms.
> > > > > > 
> > > > > > I have an l138_lcdk that I can use to test which I expect to be
> > > > > > similar to the da850evm.
> > > > > 
> > > > > As much as I am eager to move everything, quickly, over to LTO by
> > > > > default, I think the problems that we've seen thus far show it's best
> > > > > to really make it an explicit enable per board at least for the first
> > > > > release or two.  Once we've hopefully gotten more boards tested and
> > > > > enabled we can see what makes sense for defaults, give a release worth
> > > > > of heads up, and then go.  
> > > > 
> > > > Tom, are there some other issues aside from the one failing CI scenario
> > > > (sandbox_clang)? Would you be willing to merge this if I resolved that
> > > > one fail by disabling LTO for that scenario (until I resolve it)? It
> > > > would help me not having to maintain all 30+ patches...  
> > > 
> > > Yeah, CI needs to keep passing, so if we need to disable
> > > sandbox+clang+lto for now, OK.  
> > 
> > Ah, I see the problem now.  I've worked out a fix after looking at the
> > Linux kernel a bit and I'll post something for us and upstream dtc as
> > well.
> 
> What do you mean? The problem is in dtc? I see 2 problems:
> - one with DM test
> - one with stack protector test

The first problem I saw was a bunch of warnings building pylibfdt.  I
see now those two problems, and yeah, OK, gotta figure out something
there next.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5,1/2] driver: watchdog: reset watchdog in designware_wdt_stop() function

2021-05-24 Thread Sean Anderson




On 5/23/21 10:22 PM, meng...@windriver.com wrote:

From: MengLi 

In uboot command line environment, watchdog is not able to be
stopped with below commands:
SOCFPGA_STRATIX10 # wdt dev watchdog@ffd00200
SOCFPGA_STRATIX10 # wdt stop
Refer to watchdog driver in linux kernel, it is also need to reset
watchdog after disable it so that the disable action takes effect.

Signed-off-by: Meng Li 
Reviewed-by: Stefan Roese 

---
v5:
fix build issue, and verify this patch with latest upstream u-boot.
v4:
Remove the unauthorized signature.
v3:
Add the resets to designware_wdt_priv and initialize it in probe().
v2:
Change "#if CONFIG_IS_ENABLED(DM_RESET)" into
"if (CONFIG_IS_ENABLED(DM_RESET)) {", and define the variable
into if condition sentence.
---
  drivers/watchdog/designware_wdt.c | 19 +++
  1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
index 9e5487168c..afed81e6c6 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -22,6 +22,7 @@
  struct designware_wdt_priv {
void __iomem*base;
unsigned intclk_khz;
+   struct reset_ctl_bulk *resets;
  };
  
  /*

@@ -95,6 +96,18 @@ static int designware_wdt_stop(struct udevice *dev)
designware_wdt_reset(dev);
writel(0, priv->base + DW_WDT_CR);
  
+if (CONFIG_IS_ENABLED(DM_RESET)) {

+   int ret;
+
+   ret = reset_assert_bulk(priv->resets);
+   if (ret)
+   return ret;
+
+   ret = reset_deassert_bulk(priv->resets);
+   if (ret)
+   return ret;
+   }
+
return 0;
  }
  
@@ -143,13 +156,11 @@ static int designware_wdt_probe(struct udevice *dev)

  #endif
  
  	if (CONFIG_IS_ENABLED(DM_RESET)) {

-   struct reset_ctl_bulk resets;
-
-   ret = reset_get_bulk(dev, );
+   ret = reset_get_bulk(dev, priv->resets);
if (ret)
goto err;
  
-		ret = reset_deassert_bulk();

+   ret = reset_deassert_bulk(priv->resets);
if (ret)
goto err;
}



Reviewed-by: Sean Anderson 


Re: [PATCH u-boot v4 36/36] ARM: enable LTO for some boards

2021-05-24 Thread Marek Behun
On Mon, 24 May 2021 11:40:53 -0400
Tom Rini  wrote:

> On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:
> > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:  
> > > On Fri, 21 May 2021 10:11:47 -0400
> > > Tom Rini  wrote:
> > >   
> > > > On Thu, May 20, 2021 at 01:56:29PM -0500, Adam Ford wrote:  
> > > > > On Thu, May 20, 2021 at 6:25 AM Marek Behún 
> > > > > wrote:
> > > > > >
> > > > > > Enable LTO for some boards that were tested by people on U-Boot
> > > > > > Mailing List.
> > > > > >
> > > > > > Signed-off-by: Marek Behún 
> > > > > > Tested-by: Adam Ford 
> > > > > > Tested-by: Pali Rohár 
> > > > > > Tested-by: Tim Harvey 
> > > > > 
> > > > > Since the imx8mm beacon boards and the imx8mm venice board both show
> > > > > promise, does it make sense to 'imply' the LTO for anything enabling
> > > > > imx8mm?
> > > > > Same thing for the various omap3 boards, and potentially the renesas
> > > > > RZ/G2 boards.  I know Tom went through to remove a bunch of boards
> > > > > that were never converted to DM.  Most of the boards remaining
> > > > > boards have minimal board files and most of code is common to other
> > > > > boards in the same platforms.
> > > > > 
> > > > > I have an l138_lcdk that I can use to test which I expect to be
> > > > > similar to the da850evm.
> > > > 
> > > > As much as I am eager to move everything, quickly, over to LTO by
> > > > default, I think the problems that we've seen thus far show it's best
> > > > to really make it an explicit enable per board at least for the first
> > > > release or two.  Once we've hopefully gotten more boards tested and
> > > > enabled we can see what makes sense for defaults, give a release worth
> > > > of heads up, and then go.  
> > > 
> > > Tom, are there some other issues aside from the one failing CI scenario
> > > (sandbox_clang)? Would you be willing to merge this if I resolved that
> > > one fail by disabling LTO for that scenario (until I resolve it)? It
> > > would help me not having to maintain all 30+ patches...  
> > 
> > Yeah, CI needs to keep passing, so if we need to disable
> > sandbox+clang+lto for now, OK.  
> 
> Ah, I see the problem now.  I've worked out a fix after looking at the
> Linux kernel a bit and I'll post something for us and upstream dtc as
> well.
> 

What do you mean? The problem is in dtc? I see 2 problems:
- one with DM test
- one with stack protector test


[PATCH] pylibfdt: Rework "avoid unused variable warning" lines

2021-05-24 Thread Tom Rini
Clang has -Wself-assign enabled by default under -Wall and so when
building with -Werror we would get an error here.  Inspired by Linux
kernel git commit a21151b9d81a ("tools/build: tweak unused value
workaround") make use of the fact that both Clang and GCC support
casting to `void` as the method to note that something is intentionally
unused.

Signed-off-by: Tom Rini 
---
 scripts/dtc/pylibfdt/libfdt.i_shipped | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/dtc/pylibfdt/libfdt.i_shipped 
b/scripts/dtc/pylibfdt/libfdt.i_shipped
index 1d69ad38e2e3..27c29ea2603a 100644
--- a/scripts/dtc/pylibfdt/libfdt.i_shipped
+++ b/scripts/dtc/pylibfdt/libfdt.i_shipped
@@ -1010,7 +1010,7 @@ typedef uint32_t fdt32_t;
}
$1 = (void *)PyByteArray_AsString($input);
 fdt = $1;
-fdt = fdt; /* avoid unused variable warning */
+(void)fdt; /* avoid unused variable warning */
 }
 
 /* Some functions do change the device tree, so use void * */
@@ -1021,7 +1021,7 @@ typedef uint32_t fdt32_t;
}
$1 = PyByteArray_AsString($input);
 fdt = $1;
-fdt = fdt; /* avoid unused variable warning */
+(void)fdt; /* avoid unused variable warning */
 }
 
 /* typemap used for fdt_get_property_by_offset() */
-- 
2.17.1



  1   2   >