Re: [PATCH] net: ipv6: Fix IPv6 netmask parsing

2023-01-08 Thread Vyacheslav V. Mitrofanov
On Fri, 2023-01-06 at 14:22 -0800, seanedm...@linux.microsoft.com
wrote:
> From: Sean Edmond 
> 
> It should be possible to specify a netmask when
> setting a static IPv6 address.  For example:
> setenv ip6addr 2001:cafe:cafe:cafe::100/64
> 
> The net_prefix_length and net_ip6 should be updated
> properly.
> 
> Signed-off-by: Sean Edmond 
> ---
>  net/net6.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/net/net6.c b/net/net6.c
> index fdea078788..75577bcea1 100644
> --- a/net/net6.c
> +++ b/net/net6.c
> @@ -47,10 +47,13 @@ static int on_ip6addr(const char *name, const
> char *value, enum env_op op,
> }
> 
> mask = strchr(value, '/');
> -   len = strlen(value);
> 
> -   if (mask)
> -   net_prefix_length = simple_strtoul(value + len, NULL,
> 10);
> +   if (mask) {
> +   net_prefix_length = simple_strtoul(mask + 1, NULL,
> 10);
> +   len = mask - value;
> +   } else {
> +   len = strlen(value);
> +   }
> 
> return string_to_ip6(value, len, _ip6);
>  }
> --
> 2.39.0
I do agree with your changes.Thanks

Reviewed-by: Viacheslav Mitrofanov 


Re: [PATCHv3 1/5] fwu: gpt: use cached meta-data partition numbers

2023-01-08 Thread Ilias Apalodimas
On Mon, Jan 02, 2023 at 12:26:19PM -0600, Jassi Brar wrote:
> Use cached values and avoid parsing and scanning through partitions
> everytime for meta-data partitions because they can't change after bootup.
> 
> Acked-by: Etienne Carriere 
> Signed-off-by: Jassi Brar 
> ---
>  drivers/fwu-mdata/gpt_blk.c | 43 +
>  1 file changed, 24 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/fwu-mdata/gpt_blk.c b/drivers/fwu-mdata/gpt_blk.c
> index d35ce49c5c..28f5d23e1e 100644
> --- a/drivers/fwu-mdata/gpt_blk.c
> +++ b/drivers/fwu-mdata/gpt_blk.c
> @@ -24,8 +24,9 @@ enum {
>   MDATA_WRITE,
>  };
>  
> -static int gpt_get_mdata_partitions(struct blk_desc *desc,
> - uint mdata_parts[2])
> +static uint g_mdata_part[2]; /* = {0, 0} to check against uninit parts */
> +
> +static int gpt_get_mdata_partitions(struct blk_desc *desc)
>  {
>   int i, ret;
>   u32 nparts;
> @@ -33,18 +34,19 @@ static int gpt_get_mdata_partitions(struct blk_desc *desc,
>   struct disk_partition info;
>   const efi_guid_t fwu_mdata_guid = FWU_MDATA_GUID;
>  
> + /* if primary and secondary partitions already found */
> + if (g_mdata_part[0] && g_mdata_part[1])
> + return 0;
> +
>   nparts = 0;
> - for (i = 1; i < MAX_SEARCH_PARTITIONS; i++) {
> + for (i = 1; i < MAX_SEARCH_PARTITIONS && nparts < 2; i++) {
>   if (part_get_info(desc, i, ))
>   continue;
>   uuid_str_to_bin(info.type_guid, part_type_guid.b,
>   UUID_STR_FORMAT_GUID);
>  
> - if (!guidcmp(_mdata_guid, _type_guid)) {
> - if (nparts < 2)
> - mdata_parts[nparts] = i;
> - ++nparts;
> - }
> + if (!guidcmp(_mdata_guid, _type_guid))
> + g_mdata_part[nparts++] = i;
>   }
>  
>   if (nparts != 2) {
> @@ -127,26 +129,25 @@ static int fwu_gpt_update_mdata(struct udevice *dev, 
> struct fwu_mdata *mdata)
>  {
>   int ret;
>   struct blk_desc *desc;
> - uint mdata_parts[2];
>   struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev);
>  
>   desc = dev_get_uclass_plat(priv->blk_dev);
>  
> - ret = gpt_get_mdata_partitions(desc, mdata_parts);
> + ret = gpt_get_mdata_partitions(desc);
>   if (ret < 0) {
>   log_debug("Error getting the FWU metadata partitions\n");
>   return -ENOENT;
>   }
>  
>   /* First write the primary partition */
> - ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, mdata_parts[0]);
> + ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, g_mdata_part[0]);
>   if (ret < 0) {
>   log_debug("Updating primary FWU metadata partition failed\n");
>   return ret;
>   }
>  
>   /* And now the replica */
> - ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, mdata_parts[1]);
> + ret = gpt_read_write_mdata(desc, mdata, MDATA_WRITE, g_mdata_part[1]);
>   if (ret < 0) {
>   log_debug("Updating secondary FWU metadata partition failed\n");
>   return ret;
> @@ -158,16 +159,14 @@ static int fwu_gpt_update_mdata(struct udevice *dev, 
> struct fwu_mdata *mdata)
>  static int gpt_get_mdata(struct blk_desc *desc, struct fwu_mdata *mdata)
>  {
>   int ret;
> - uint mdata_parts[2];
> -
> - ret = gpt_get_mdata_partitions(desc, mdata_parts);
>  
> + ret = gpt_get_mdata_partitions(desc);
>   if (ret < 0) {
>   log_debug("Error getting the FWU metadata partitions\n");
>   return -ENOENT;
>   }
>  
> - ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, mdata_parts[0]);
> + ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, g_mdata_part[0]);
>   if (ret < 0) {
>   log_debug("Failed to read the FWU metadata from the device\n");
>   return -EIO;
> @@ -182,7 +181,7 @@ static int gpt_get_mdata(struct blk_desc *desc, struct 
> fwu_mdata *mdata)
>* Try to read the replica.
>*/
>   memset(mdata, '\0', sizeof(struct fwu_mdata));
> - ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, mdata_parts[1]);
> + ret = gpt_read_write_mdata(desc, mdata, MDATA_READ, g_mdata_part[1]);
>   if (ret < 0) {
>   log_debug("Failed to read the FWU metadata from the device\n");
>   return -EIO;
> @@ -206,9 +205,15 @@ static int fwu_gpt_get_mdata(struct udevice *dev, struct 
> fwu_mdata *mdata)
>  static int fwu_gpt_get_mdata_partitions(struct udevice *dev, uint 
> *mdata_parts)
>  {
>   struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev);
> + int err;
> +
> + err = gpt_get_mdata_partitions(dev_get_uclass_plat(priv->blk_dev));
> + if (!err) {
> + mdata_parts[0] = g_mdata_part[0];
> + mdata_parts[1] = g_mdata_part[1];
> + }
>  
> - return 

Re: [PATCH v2 3/3] lmb: consider EFI memory map

2023-01-08 Thread Ilias Apalodimas
On Thu, Jan 05, 2023 at 09:25:36PM +0100, Heinrich Schuchardt wrote:
> Add reservations for all EFI memory areas that are not
> EFI_CONVENTIONAL_MEMORY.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   use efi_get_memory_map_alloc()
> ---
>  lib/lmb.c | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/lib/lmb.c b/lib/lmb.c
> index c599608fa3..ec790760db 100644
> --- a/lib/lmb.c
> +++ b/lib/lmb.c
> @@ -7,7 +7,9 @@
>   */
>  
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -153,6 +155,37 @@ void arch_lmb_reserve_generic(struct lmb *lmb, ulong sp, 
> ulong end, ulong align)
>   }
>  }
>  
> +/**
> + * efi_lmb_reserve() - add reservations for EFI memory
> + *
> + * Add reservations for all EFI memory areas that are not
> + * EFI_CONVENTIONAL_MEMORY.
> + *
> + * @lmb: lmb environment
> + * Return:   0 on success, 1 on failure
> + */
> +static __maybe_unused int efi_lmb_reserve(struct lmb *lmb)
> +{
> + struct efi_mem_desc *memmap = NULL, *map;
> + efi_uintn_t i, map_size = 0;
> + efi_status_t ret;
> +
> + ret = efi_get_memory_map_alloc(_size, );
> + if (ret != EFI_SUCCESS)
> + return 1;
> +
> + for (i = 0, map = memmap; i < map_size / sizeof(*map); ++map, ++i) {
> + if (map->type != EFI_CONVENTIONAL_MEMORY)
> + lmb_reserve(lmb,
> + map_to_sysmem((void *)(uintptr_t)
> +   map->physical_start),
> + map->num_pages * EFI_PAGE_SIZE);
> + }
> + efi_free_pool(memmap);
> +
> + return 0;
> +}
> +
>  static void lmb_reserve_common(struct lmb *lmb, void *fdt_blob)
>  {
>   arch_lmb_reserve(lmb);
> @@ -160,6 +193,9 @@ static void lmb_reserve_common(struct lmb *lmb, void 
> *fdt_blob)
>  
>   if (CONFIG_IS_ENABLED(OF_LIBFDT) && fdt_blob)
>   boot_fdt_add_mem_rsv_regions(lmb, fdt_blob);
> +
> + if (CONFIG_IS_ENABLED(EFI_LOADER))
> + efi_lmb_reserve(lmb);
>  }
>  
>  /* Initialize the struct, add memory and call arch/board reserve functions */
> -- 
> 2.37.2
> 
Reviewed-by: Ilias Apalodimas 



Re: [PATCH v2 2/3] efi_loader: carve out efi_get_memory_map_alloc()

2023-01-08 Thread Ilias Apalodimas
On Thu, Jan 05, 2023 at 09:25:35PM +0100, Heinrich Schuchardt wrote:
> Carve out code from efidebug command used to read the memory map.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   new patch
> ---
>  cmd/efidebug.c  | 18 --
>  include/efi_loader.h|  3 +++
>  lib/efi_loader/efi_memory.c | 34 ++
>  3 files changed, 41 insertions(+), 14 deletions(-)
> 
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index 569003ae2e..e6959ede93 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -591,25 +591,15 @@ static void print_memory_attributes(u64 attributes)
>  static int do_efi_show_memmap(struct cmd_tbl *cmdtp, int flag,
> int argc, char *const argv[])
>  {
> - struct efi_mem_desc *memmap = NULL, *map;
> - efi_uintn_t map_size = 0;
> + struct efi_mem_desc *memmap, *map;
> + efi_uintn_t map_size;
>   const char *type;
>   int i;
>   efi_status_t ret;
>  
> - ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> - if (ret == EFI_BUFFER_TOO_SMALL) {
> - map_size += sizeof(struct efi_mem_desc); /* for my own */
> - ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
> - (void *));
> - if (ret != EFI_SUCCESS)
> - return CMD_RET_FAILURE;
> - ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> - }
> - if (ret != EFI_SUCCESS) {
> - efi_free_pool(memmap);
> + ret = efi_get_memory_map_alloc(_size, );
> + if (ret != EFI_SUCCESS)
>   return CMD_RET_FAILURE;
> - }
>  
>   printf("Type Start%.*s End%.*s Attributes\n",
>  EFI_PHYS_ADDR_WIDTH - 5, spc, EFI_PHYS_ADDR_WIDTH - 3, spc);
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0899e293e5..02d151b715 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -734,6 +734,9 @@ efi_status_t efi_allocate_pool(enum efi_memory_type 
> pool_type,
>  efi_uintn_t size, void **buffer);
>  /* EFI pool memory free function. */
>  efi_status_t efi_free_pool(void *buffer);
> +/* Allocate and retrieve EFI memory map */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> +   struct efi_mem_desc **memory_map);
>  /* Returns the EFI memory map */
>  efi_status_t efi_get_memory_map(efi_uintn_t *memory_map_size,
>   struct efi_mem_desc *memory_map,
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 8d347f101f..32254d2433 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -736,6 +736,40 @@ efi_status_t efi_get_memory_map(efi_uintn_t 
> *memory_map_size,
>   return EFI_SUCCESS;
>  }
>  
> +/**
> + * efi_get_memory_map_alloc() - allocate map describing memory usage
> + *
> + * The caller is responsible for calling FreePool() if the call succeeds.
> + *
> + * @memory_map   buffer to which the memory map is written
> + * @map_size size of the memory map
> + * Return:   status code
> + */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> +   struct efi_mem_desc **memory_map)
> +{
> + efi_status_t ret;
> +
> + *memory_map = NULL;
> + *map_size = 0;
> + ret = efi_get_memory_map(map_size, *memory_map, NULL, NULL, NULL);

Although this is correct and efi_get_memory_map() will only return
EFI_BUFFER_TOO_SMALL, since we initialize the map_size to 0,  I don't know
if code analysis tools are smart enough to understand this.  Perhaps we
should initialize ret?


> + if (ret == EFI_BUFFER_TOO_SMALL) {
> + *map_size += sizeof(struct efi_mem_desc); /* for the map */
> + ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, *map_size,
> + (void **)memory_map);
> + if (ret != EFI_SUCCESS)
> + return ret;
> + ret = efi_get_memory_map(map_size, *memory_map,
> +  NULL, NULL, NULL);
> + if (ret != EFI_SUCCESS) {
> + efi_free_pool(*memory_map);
> + *memory_map = NULL;
> + }
> + }
> +
> + return ret;
> +}
> +
>  /**
>   * efi_add_conventional_memory_map() - add a RAM memory area to the map
>   *
> -- 
> 2.37.2
> 

Reviewed-by: Ilias Apalodimas 



[PATCH v2 2/2] musb-new: omap2430: fix compiling in DM_USB_GADGET config

2023-01-08 Thread Andreas Kemnade
Add the separate IRQ handling function and change the registration.

Signed-off-by: Andreas Kemnade 
---
 drivers/usb/musb-new/omap2430.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/usb/musb-new/omap2430.c b/drivers/usb/musb-new/omap2430.c
index 0d1fb03727..42e7abddbc 100644
--- a/drivers/usb/musb-new/omap2430.c
+++ b/drivers/usb/musb-new/omap2430.c
@@ -46,6 +46,15 @@ static inline void omap2430_low_level_init(struct musb *musb)
musb_writel(musb->mregs, OTG_FORCESTDBY, l);
 }
 
+#ifdef CONFIG_DM_USB_GADGET
+int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+{
+   struct musb_host_data *host = dev_get_priv(dev);
+
+   host->host->isr(0, host->host);
+   return 0;
+}
+#endif
 
 static int omap2430_musb_init(struct musb *musb)
 {
@@ -235,6 +244,16 @@ static int omap2430_musb_probe(struct udevice *dev)
return -EIO;
 
return musb_lowlevel_init(host);
+   } else if (CONFIG_IS_ENABLED(DM_USB_GADGET)) {
+   struct musb_host_data *host = dev_get_priv(dev);
+
+   host->host = musb_init_controller(>plat,
+ (struct device 
*)otg_board_data,
+ plat->base);
+   if (!host->host)
+   return -EIO;
+
+   return usb_add_gadget_udc((struct device *)otg_board_data, 
>host->g);
}
 
musbp = musb_register(>plat, (struct device *)otg_board_data,
-- 
2.30.2



[PATCH v2 1/2] musb-new: omap2430: no host data access in gadget mode

2023-01-08 Thread Andreas Kemnade
Avoid accessing structures (usb_bus_priv) only present when musb is
in host mode.

Signed-off-by: Andreas Kemnade 
---
 drivers/usb/musb-new/omap2430.c | 34 -
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/musb-new/omap2430.c b/drivers/usb/musb-new/omap2430.c
index 7d15b94a6c..0d1fb03727 100644
--- a/drivers/usb/musb-new/omap2430.c
+++ b/drivers/usb/musb-new/omap2430.c
@@ -214,37 +214,35 @@ static int omap2430_musb_of_to_plat(struct udevice *dev)
 
 static int omap2430_musb_probe(struct udevice *dev)
 {
-#ifdef CONFIG_USB_MUSB_HOST
-   struct musb_host_data *host = dev_get_priv(dev);
-#else
-   struct musb *musbp;
-#endif
struct omap2430_musb_plat *plat = dev_get_plat(dev);
-   struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
struct omap_musb_board_data *otg_board_data;
int ret = 0;
void *base = dev_read_addr_ptr(dev);
-
-   priv->desc_before_addr = true;
+   struct musb *musbp;
 
otg_board_data = >otg_board_data;
 
-#ifdef CONFIG_USB_MUSB_HOST
-   host->host = musb_init_controller(>plat,
- (struct device *)otg_board_data,
- plat->base);
-   if (!host->host) {
-   return -EIO;
+   if (CONFIG_IS_ENABLED(USB_MUSB_HOST)) {
+   struct musb_host_data *host = dev_get_priv(dev);
+   struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
+
+   priv->desc_before_addr = true;
+
+   host->host = musb_init_controller(>plat,
+ (struct device 
*)otg_board_data,
+ plat->base);
+   if (!host->host)
+   return -EIO;
+
+   return musb_lowlevel_init(host);
}
 
-   ret = musb_lowlevel_init(host);
-#else
musbp = musb_register(>plat, (struct device *)otg_board_data,
  plat->base);
if (IS_ERR_OR_NULL(musbp))
return -EINVAL;
-#endif
-   return ret;
+
+   return 0;
 }
 
 static int omap2430_musb_remove(struct udevice *dev)
-- 
2.30.2



[PATCH v2 0/2] musb-new: fix omap peripheral support

2023-01-08 Thread Andreas Kemnade
DM_GADGET did not compile at all, probe was not called in
non-gadget mode.

Tested on an omap4 board with ums and fastboot command.

Changes in V2:
- split up former 2/2 patch into two.
- do not break non-DM_USB_GADGET compile further

Andreas Kemnade (2):
  musb-new: omap2430: no host data access in gadget mode
  musb-new: omap2430: fix compiling in DM_USB_GADGET config

 drivers/usb/musb-new/omap2430.c | 53 ++---
 1 file changed, 35 insertions(+), 18 deletions(-)

-- 
2.30.2



Re: [PATCH] efi_loader: fix description of memory functions

2023-01-08 Thread Ilias Apalodimas
On Sun, Jan 08, 2023 at 01:00:00AM +0100, Heinrich Schuchardt wrote:
> * Add missing function descriptions
> * Adjust to Sphinx style
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_memory.c | 82 -
>  1 file changed, 62 insertions(+), 20 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 32254d2433..a108427d72 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -78,12 +78,19 @@ static u64 checksum(struct efi_pool_allocation *alloc)
>   return ret;
>  }
>  
> -/*
> +/**
> + * efi_mem_cmp() - comparator function for sorting memory map
> + *
>   * Sorts the memory list from highest address to lowest address
>   *
>   * When allocating memory we should always start from the highest
>   * address chunk, so sort the memory list such that the first list
>   * iterator gets the highest address and goes lower from there.
> + *
> + * @priv:unused
> + * @a:   first memory area
> + * @b:   second memory area
> + * Return:   1 if @a is before @b, -1 if @b is before @a, 0 if equal
>   */
>  static int efi_mem_cmp(void *priv, struct list_head *a, struct list_head *b)
>  {
> @@ -98,11 +105,22 @@ static int efi_mem_cmp(void *priv, struct list_head *a, 
> struct list_head *b)
>   return -1;
>  }
>  
> +/**
> + * desc_get_end() - get end address of memory area
> + *
> + * @desc:memory descriptor
> + * Return:   end address + 1
> + */
>  static uint64_t desc_get_end(struct efi_mem_desc *desc)
>  {
>   return desc->physical_start + (desc->num_pages << EFI_PAGE_SHIFT);
>  }
>  
> +/**
> + * efi_mem_sort() - sort memory map
> + *
> + * Sort the memory map and then try to merge adjacent memory areas.
> + */
>  static void efi_mem_sort(void)
>  {
>   struct list_head *lhandle;
> @@ -148,12 +166,13 @@ static void efi_mem_sort(void)
>   }
>  }
>  
> -/** efi_mem_carve_out - unmap memory region
> +/**
> + * efi_mem_carve_out() - unmap memory region
>   *
>   * @map: memory map
>   * @carve_desc:  memory region to unmap
>   * @overlap_only_ram:the carved out region may only overlap RAM
> - * Return Value: the number of overlapping pages which have been
> + * Return:   the number of overlapping pages which have been
>   *   removed from the map,
>   *   EFI_CARVE_NO_OVERLAP, if the regions don't overlap,
>   *   EFI_CARVE_OVERLAPS_NONRAM, if the carve and map overlap,
> @@ -403,6 +422,13 @@ static efi_status_t efi_check_allocated(u64 addr, bool 
> must_be_allocated)
>   return EFI_NOT_FOUND;
>  }
>  
> +/**
> + * efi_find_free_memory() - find free memory pages
> + *
> + * @len: size of memory area needed
> + * @max_addr:highest address to allocate
> + * Return:   pointer to free memory area or 0
> + */
>  static uint64_t efi_find_free_memory(uint64_t len, uint64_t max_addr)
>  {
>   struct list_head *lhandle;
> @@ -445,13 +471,13 @@ static uint64_t efi_find_free_memory(uint64_t len, 
> uint64_t max_addr)
>   return 0;
>  }
>  
> -/*
> - * Allocate memory pages.
> +/**
> + * efi_allocate_pages - allocate memory pages
>   *
> - * @type type of allocation to be performed
> - * @memory_type  usage type of the allocated memory
> - * @pagesnumber of pages to be allocated
> - * @memory   allocated memory
> + * @type:type of allocation to be performed
> + * @memory_type: usage type of the allocated memory
> + * @pages:   number of pages to be allocated
> + * @memory:  allocated memory
>   * Return:   status code
>   */
>  efi_status_t efi_allocate_pages(enum efi_allocate_type type,
> @@ -507,6 +533,13 @@ efi_status_t efi_allocate_pages(enum efi_allocate_type 
> type,
>   return EFI_SUCCESS;
>  }
>  
> +/**
> + * efi_alloc() - allocate memory pages
> + *
> + * @len: size of the memory to be allocated
> + * @memory_type: usage type of the allocated memory
> + * Return:   pointer to the allocated memory area or NULL
> + */
>  void *efi_alloc(uint64_t len, int memory_type)
>  {
>   uint64_t ret = 0;
> @@ -552,7 +585,7 @@ efi_status_t efi_free_pages(uint64_t memory, efi_uintn_t 
> pages)
>  }
>  
>  /**
> - * efi_alloc_aligned_pages - allocate
> + * efi_alloc_aligned_pages() - allocate aligned memory pages
>   *
>   * @len: len in bytes
>   * @memory_type: usage type of the allocated memory
> @@ -673,15 +706,15 @@ efi_status_t efi_free_pool(void *buffer)
>   return ret;
>  }
>  
> -/*
> - * Get map describing memory usage.
> +/**
> + * efi_get_memory_map() - get map describing memory usage.
>   *
> - * @memory_map_size  on entry the size, in bytes, of the memory map buffer,
> + * @memory_map_size: on entry the size, in bytes, of the memory map buffer,
>   *   on exit the size of the copied 

Re: [PATCH 1/2] efi_loader: refine set_keyboard_layout() status

2023-01-08 Thread Ilias Apalodimas
On Fri, 6 Jan 2023 at 17:27, Heinrich Schuchardt  wrote:
>
> On 1/6/23 10:46, Vincent Stehlé wrote:
> > As per the EFI specification, the HII database protocol function
> > set_keyboard_layout() must return EFI_INVALID_PARAMETER when it is called
> > with a NULL key_guid argument. Modify the function accordingly to improve
> > conformance.
> >
> > Signed-off-by: Vincent Stehlé 
> > Cc: Heinrich Schuchardt 
> > Cc: Ilias Apalodimas 
> > ---
> >   lib/efi_loader/efi_hii.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
> > index 27db3be6a17..3b54ecb11ac 100644
> > --- a/lib/efi_loader/efi_hii.c
> > +++ b/lib/efi_loader/efi_hii.c
> > @@ -758,6 +758,9 @@ set_keyboard_layout(const struct 
> > efi_hii_database_protocol *this,
> >   {
> >   EFI_ENTRY("%p, %pUs", this, key_guid);
> >
> > + if (!key_guid)
> > + return EFI_EXIT(EFI_INVALID_PARAMETER);
>
> This is just suppressing an SCT warning for an unimplemented function. I
> think we should complete the implementation of the HII protocols instead
> of trying to hide the deficiency.

I don't think we are hiding the fact that the function isn't implemented here.
34.8.11 EFI_HII_DATABASE_PROTOCOL.SetKeyboardLayout() says that we
must return if the KeyGuid is NULL

Reviewed-by: Ilias Apalodimas 


>
> Best regards
>
> Heinrich
>
> > +
> >   return EFI_EXIT(EFI_NOT_FOUND);
> >   }
> >
>


Re: [PATCH 1/1] doc: fix description of u16_strcasecmp()

2023-01-08 Thread Ilias Apalodimas
On Sun, 8 Jan 2023 at 01:25, Heinrich Schuchardt
 wrote:
>
> Remove non-existent parameter 'n' from function description.
>
> Fixes: 7a9b366cd9b7 ("lib: add function u16_strcasecmp()")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/charset.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/charset.h b/include/charset.h
> index 6e79d7152e..44034c71d3 100644
> --- a/include/charset.h
> +++ b/include/charset.h
> @@ -178,7 +178,6 @@ s32 utf_to_upper(const s32 code);
>   *
>   * @s1:first string to compare
>   * @s2:second string to compare
> - * @n: maximum number of u16 to compare
>   * Return: 0  if the first n u16 are the same in s1 and s2
>   * < 0 if the first different u16 in s1 is less than the
>   * corresponding u16 in s2
> --
> 2.37.2
>

Reviewed-by: Ilias Apalodimas 


Re: [PATCH v1 1/2] ARM: configs: npcm7xx: add full function for nuvoton npcm750

2023-01-08 Thread Jim Liu
Hi Tom

I push some patches to fix some errors about this config patch and
wait for all reviewers to merge.
Could you check this patch again or should I use new master uboot
update patch and resend it ?

Best regards,
Jim

On Tue, Aug 2, 2022 at 8:28 PM Jim Liu  wrote:
>
> Hi Tom
>
> Yes , the link is as below
>
> https://patchwork.ozlabs.org/project/uboot/patch/20220623053142.6659-1-jjl...@nuvoton.com/
>
> Best regards,
> Jim
>
>
> Tom Rini 於 2022年8月2日 週二,下午8:09寫道:
>>
>> On Tue, Aug 02, 2022 at 10:54:33AM +0800, Jim Liu wrote:
>> > Hi Tom
>> >
>> > Thanks for your review.
>> > My i2c driver status is  Awaiting Upstream.
>> > Is this the reason for the failure?
>> > What should I do to fix this build error?
>> >
>> > Any comments are most welcome!
>>
>> Heiko?
>>
>> >
>> >
>> > Best regards,
>> > Jim
>> >
>> > On Tue, Jul 26, 2022 at 12:59 AM Tom Rini  wrote:
>> > >
>> > > On Tue, Jul 12, 2022 at 05:24:06PM +0800, Jim Liu wrote:
>> > >
>> > > > Add add full function config for nuvoton npcm750
>> > > >
>> > > > Signed-off-by: Jim Liu 
>> > >
>> > > Does the i2c driver need to be reposted?  This patch causes the platform
>> > > to fail to build as the i2c driver file is missing.
>> > >
>> > > --
>> > > Tom
>>
>> --
>> Tom


[PATCHv3 5/5] tools: Add mkfwumdata tool for FWU metadata image

2023-01-08 Thread Jassi Brar
From: Masami Hiramatsu 

Add 'mkfwumdata' tool to generate FWU metadata image for the meta-data
partition to be used in A/B Update imeplementation.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Sughosh Ganu 
Signed-off-by: Jassi Brar 
---
 tools/Kconfig  |   9 ++
 tools/Makefile |   4 +
 tools/mkfwumdata.c | 326 +
 3 files changed, 339 insertions(+)
 create mode 100644 tools/mkfwumdata.c

diff --git a/tools/Kconfig b/tools/Kconfig
index 539708f277..6e23f44d55 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -157,4 +157,13 @@ config LUT_SEQUENCE
help
  Look Up Table Sequence
 
+config TOOLS_MKFWUMDATA
+   bool "Build mkfwumdata command"
+   default y if FWU_MULTI_BANK_UPDATE
+   help
+ This command allows users to create a raw image of the FWU
+ metadata for initial installation of the FWU multi bank
+ update on the board. The installation method depends on
+ the platform.
+
 endmenu
diff --git a/tools/Makefile b/tools/Makefile
index 26be0a7ba2..024d6c8eca 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -255,6 +255,10 @@ HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
 hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
 
+mkfwumdata-objs := mkfwumdata.o lib/crc32.o
+HOSTLDLIBS_mkfwumdata += -luuid
+hostprogs-$(CONFIG_TOOLS_MKFWUMDATA) += mkfwumdata
+
 # We build some files with extra pedantic flags to try to minimize things
 # that won't build on some weird host compiler -- though there are lots of
 # exceptions for files that aren't complaint.
diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c
new file mode 100644
index 00..e0b6702039
--- /dev/null
+++ b/tools/mkfwumdata.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* This will dynamically allocate the fwu_mdata */
+#define CONFIG_FWU_NUM_BANKS   0
+#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0
+
+/* Since we can not include fwu.h, redefine version here. */
+#define FWU_MDATA_VERSION  1
+
+typedef uint8_t u8;
+typedef int16_t s16;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint64_t u64;
+
+#include 
+
+/* TODO: Endianess conversion may be required for some arch. */
+
+static const char *opts_short = "b:i:a:p:gh";
+
+static struct option options[] = {
+   {"banks", required_argument, NULL, 'b'},
+   {"images", required_argument, NULL, 'i'},
+   {"guid", required_argument, NULL, 'g'},
+   {"active-bank", required_argument, NULL, 'a'},
+   {"previous-bank", required_argument, NULL, 'p'},
+   {"help", no_argument, NULL, 'h'},
+   {NULL, 0, NULL, 0},
+};
+
+static void print_usage(void)
+{
+   fprintf(stderr, "Usage: mkfwumdata [options]  \n");
+   fprintf(stderr, "Options:\n"
+   "\t-i, --images   Number of images\n"
+   "\t-b, --banksNumber of banks\n"
+   "\t-a, --active-bank  Active bank\n"
+   "\t-p, --previous-bankPrevious active bank\n"
+   "\t-g, --guid  Use GUID instead of UUID\n"
+   "\t-h, --help  print a help message\n"
+   );
+   fprintf(stderr, "  UUIDs list syntax:\n"
+   "\t  ,,\n"
+   "\timages uuid list syntax:\n"
+   "\t\timg_uuid_00,img_uuid_01...img_uuid_0b,\n"
+   "\t\timg_uuid_10,img_uuid_11...img_uuid_1b,\n"
+   "\t\t...,\n"
+   "\t\timg_uuid_i0,img_uuid_i1...img_uuid_ib,\n"
+   "\t\twhere 'b' and 'i' are number of banks and numbder of 
images in a bank respectively.\n"
+  );
+}
+
+static int active_bank = 0;
+static int previous_bank = INT_MAX; /* unset */
+static bool __use_guid = false;
+
+struct fwu_mdata_object {
+   size_t images;
+   size_t banks;
+   size_t size;
+   struct fwu_mdata *mdata;
+};
+
+struct fwu_mdata_object *fwu_alloc_mdata(size_t images, size_t banks)
+{
+   struct fwu_mdata_object *mobj;
+
+   mobj = calloc(1, sizeof(*mobj));
+   if (!mobj)
+   return NULL;
+
+   mobj->size = sizeof(struct fwu_mdata) +
+   (sizeof(struct fwu_image_entry) +
+sizeof(struct fwu_image_bank_info) * banks) * images;
+   mobj->images = images;
+   mobj->banks = banks;
+
+   mobj->mdata = calloc(1, mobj->size);
+   if (!mobj->mdata) {
+   free(mobj);
+   return NULL;
+   }
+
+   return mobj;
+}
+
+struct fwu_image_entry *fwu_get_image(struct fwu_mdata_object *mobj, size_t 
idx)
+{
+   size_t offset;
+
+   offset = sizeof(struct fwu_mdata) +
+   (sizeof(struct fwu_image_entry) +
+sizeof(struct 

[PATCHv3 4/5] fwu: DeveloperBox: add support for FWU

2023-01-08 Thread Jassi Brar
Add code to support FWU_MULTI_BANK_UPDATE.
The platform does not have gpt-partition storage for
Banks and MetaData, rather it used SPI-NOR backed
mtd regions for the purpose.

Signed-off-by: Jassi Brar 
---
 board/socionext/developerbox/Makefile   |  1 +
 board/socionext/developerbox/developerbox.c |  8 ++
 board/socionext/developerbox/fwu_plat.c | 57 
 configs/synquacer_developerbox_defconfig| 13 ++-
 doc/board/socionext/developerbox.rst| 96 +
 include/configs/synquacer.h | 10 +++
 6 files changed, 183 insertions(+), 2 deletions(-)
 create mode 100644 board/socionext/developerbox/fwu_plat.c

diff --git a/board/socionext/developerbox/Makefile 
b/board/socionext/developerbox/Makefile
index 4a46de995a..9b80ee38e7 100644
--- a/board/socionext/developerbox/Makefile
+++ b/board/socionext/developerbox/Makefile
@@ -7,3 +7,4 @@
 #
 
 obj-y  := developerbox.o
+obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_plat.o
diff --git a/board/socionext/developerbox/developerbox.c 
b/board/socionext/developerbox/developerbox.c
index 6415c90c1c..2123914f21 100644
--- a/board/socionext/developerbox/developerbox.c
+++ b/board/socionext/developerbox/developerbox.c
@@ -20,6 +20,13 @@
 
 #if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
 struct efi_fw_image fw_images[] = {
+#if defined(CONFIG_FWU_MULTI_BANK_UPDATE)
+   {
+   .image_type_id = DEVELOPERBOX_FIP_IMAGE_GUID,
+   .fw_name = u"DEVELOPERBOX-FIP",
+   .image_index = 1,
+   },
+#else
{
.image_type_id = DEVELOPERBOX_UBOOT_IMAGE_GUID,
.fw_name = u"DEVELOPERBOX-UBOOT",
@@ -35,6 +42,7 @@ struct efi_fw_image fw_images[] = {
.fw_name = u"DEVELOPERBOX-OPTEE",
.image_index = 3,
},
+#endif
 };
 
 struct efi_capsule_update_info update_info = {
diff --git a/board/socionext/developerbox/fwu_plat.c 
b/board/socionext/developerbox/fwu_plat.c
new file mode 100644
index 00..29b258f86c
--- /dev/null
+++ b/board/socionext/developerbox/fwu_plat.c
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DFU_ALT_BUF_LEN 256
+
+/* Generate dfu_alt_info from partitions */
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   int ret;
+   struct mtd_info *mtd;
+
+   ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
+   memset(buf, 0, sizeof(buf));
+
+   mtd_probe_devices();
+
+   mtd = get_mtd_device_nm("nor1");
+   if (IS_ERR_OR_NULL(mtd))
+   return;
+
+   ret = fwu_gen_alt_info_from_mtd(buf, DFU_ALT_BUF_LEN, mtd);
+   if (ret < 0) {
+   log_err("Error: Failed to generate dfu_alt_info. (%d)\n", ret);
+   return;
+   }
+   log_debug("Make dfu_alt_info: '%s'\n", buf);
+
+   env_set("dfu_alt_info", buf);
+}
+
+int fwu_plat_get_alt_num(struct udevice __always_unused *dev,
+efi_guid_t *image_id, u8 *alt_num)
+{
+   return fwu_mtd_get_alt_num(image_id, alt_num, "nor1");
+}
+
+void fwu_plat_get_bootidx(uint *boot_idx)
+{
+   int ret;
+   u32 active_idx;
+   u32 *bootidx = boot_idx;
+
+   ret = fwu_get_active_index(_idx);
+
+   if (ret < 0)
+   *bootidx = -1;
+
+   *bootidx = active_idx;
+}
diff --git a/configs/synquacer_developerbox_defconfig 
b/configs/synquacer_developerbox_defconfig
index f69b873a36..b1085a388e 100644
--- a/configs/synquacer_developerbox_defconfig
+++ b/configs/synquacer_developerbox_defconfig
@@ -1,10 +1,11 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SYNQUACER=y
-CONFIG_TEXT_BASE=0x0820
+CONFIG_POSITION_INDEPENDENT=y
+CONFIG_SYS_TEXT_BASE=0
 CONFIG_SYS_MALLOC_LEN=0x100
 CONFIG_SYS_MALLOC_F_LEN=0x400
 CONFIG_ENV_SIZE=0x3
-CONFIG_ENV_OFFSET=0x30
+CONFIG_ENV_OFFSET=0x58
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="synquacer-sc2a11-developerbox"
@@ -96,3 +97,11 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_IGNORE_OSINDICATIONS=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_SECURE_BOOT=y
+CONFIG_FWU_MULTI_BANK_UPDATE=y
+CONFIG_FWU_MDATA=y
+CONFIG_FWU_MDATA_MTD=y
+CONFIG_FWU_NUM_BANKS=2
+CONFIG_FWU_NUM_IMAGES_PER_BANK=1
+CONFIG_CMD_FWU_METADATA=y
+CONFIG_TOOLS_MKFWUMDATA=y
diff --git a/doc/board/socionext/developerbox.rst 
b/doc/board/socionext/developerbox.rst
index 2d943c23be..be872aa79d 100644
--- a/doc/board/socionext/developerbox.rst
+++ b/doc/board/socionext/developerbox.rst
@@ -85,3 +85,99 @@ Once the flasher tool is running we are ready flash the UEFI 
image::
 
 After transferring the SPI_NOR_UBOOT.fd, turn off the DSW2-7 and reset the 
board.
 
+
+Enable FWU Multi Bank Update
+
+
+DeveloperBox supports the FWU Multi Bank Update. You *MUST* update both *SCP 
firmware* and *TF-A* for this feature. This will change 

[PATCHv3 3/5] dt: fwu: developerbox: enable fwu banks and mdata regions

2023-01-08 Thread Jassi Brar
Specify Bank-0/1 and fwu metadata mtd regions.

Signed-off-by: Jassi Brar 
Acked-by: Ilias Apalodimas 
---
 .../synquacer-sc2a11-developerbox-u-boot.dtsi | 22 ++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi 
b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
index 7a56116d6f..62eee0aaf0 100644
--- a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
+++ b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
@@ -23,7 +23,7 @@
active_clk_edges;
chipselect_num = <1>;
 
-   spi-flash@0 {
+   spi_flash: spi-flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
@@ -36,6 +36,7 @@
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
+   uuid = "17e86d77-41f9-4fd7-87ec-a55df9842de5";
 
partition@0 {
label = "BootStrap-BL1";
@@ -79,6 +80,19 @@
label = "Ex-OPTEE";
reg = <0x50 0x20>;
};
+
+   /* FWU Multi bank update partitions */
+   partition@60 {
+   label = "FIP-Bank0";
+   reg = <0x60 0x40>;
+   uuid = 
"5a66a702-99fd-4fef-a392-c26e261a2828";
+   };
+
+   partition@a0 {
+   label = "FIP-Bank1";
+   reg = <0xa0 0x40>;
+   uuid = 
"a8f868a1-6e5c-4757-878d-ce63375ef2c0";
+   };
};
};
};
@@ -104,6 +118,12 @@
optee {
status = "okay";
};
+
+   fwu-mdata {
+   compatible = "u-boot,fwu-mdata-mtd";
+   fwu-mdata-store = <_flash>;
+   mdata-offsets = <0x50 0x53>;
+   };
};
 };
 
-- 
2.34.1



[PATCHv3 2/5] FWU: mtd: Add helper functions for accessing FWU metadata

2023-01-08 Thread Jassi Brar
From: Sughosh Ganu 

Add helper functions needed for accessing the FWU metadata which
contains information on the updatable images.

Signed-off-by: Sughosh Ganu 
Signed-off-by: Jassi Brar 
---
 include/fwu.h |  27 ++
 lib/fwu_updates/Makefile  |   1 +
 lib/fwu_updates/fwu_mtd.c | 172 ++
 3 files changed, 200 insertions(+)
 create mode 100644 lib/fwu_updates/fwu_mtd.c

diff --git a/include/fwu.h b/include/fwu.h
index ea25aca2cd..2edfa72caf 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -251,4 +252,30 @@ u8 fwu_empty_capsule_checks_pass(void);
  */
 int fwu_trial_state_ctr_start(void);
 
+/**
+ * fwu_gen_alt_info_from_mtd() - Parse dfu_alt_info from metadata in mtd
+ * @buf: Buffer into which the dfu_alt_info is filled
+ * @len: Maximum charaters that can be written in buf
+ * @mtd: Pointer to underlying MTD device
+ *
+ * Parse dfu_alt_info from metadata in mtd. Used for setting the env.
+ *
+ * Return: 0 if OK, -ve on error
+ *
+ */
+int fwu_gen_alt_info_from_mtd(char *buf, size_t len, struct mtd_info *mtd);
+
+/**
+ * fwu_mtd_get_alt_num() - Mapping of fwu_plat_get_alt_num for MTD device
+ * @image_guid: Image GUID for which DFU alt number needs to be retrieved
+ * @alt_num: Pointer to the alt_num
+ * @mtd_dev: Name of mtd device instance
+ *
+ * To map fwu_plat_get_alt_num onto mtd based metadata implementation.
+ *
+ * Return: 0 if OK, -ve on error
+ *
+ */
+int fwu_mtd_get_alt_num(efi_guid_t *image_id, u8 *alt_num, const char 
*mtd_dev);
+
 #endif /* _FWU_H_ */
diff --git a/lib/fwu_updates/Makefile b/lib/fwu_updates/Makefile
index 1993088e5b..c9e3c06b48 100644
--- a/lib/fwu_updates/Makefile
+++ b/lib/fwu_updates/Makefile
@@ -5,3 +5,4 @@
 
 obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu.o
 obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_gpt.o
+obj-$(CONFIG_FWU_MDATA_MTD) += fwu_mtd.o
diff --git a/lib/fwu_updates/fwu_mtd.c b/lib/fwu_updates/fwu_mtd.c
new file mode 100644
index 00..1895b8fab3
--- /dev/null
+++ b/lib/fwu_updates/fwu_mtd.c
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+int fwu_mtd_get_alt_num(efi_guid_t *image_id, u8 *alt_num,
+   const char *mtd_dev)
+{
+   int i, nalt;
+   int ret = -1;
+   struct mtd_info *mtd;
+   struct dfu_entity *dfu;
+   ofnode node, parts_node;
+   fdt_addr_t offset, size;
+   char uuidbuf[UUID_STR_LEN + 1];
+
+   mtd_probe_devices();
+   mtd = get_mtd_device_nm(mtd_dev);
+
+   /* Find partition node under given MTD device. */
+   parts_node = ofnode_by_compatible(mtd_get_ofnode(mtd),
+ "fixed-partitions");
+
+   uuid_bin_to_str(image_id->b, uuidbuf, UUID_STR_FORMAT_STD);
+   node = ofnode_by_prop_value(parts_node, "uuid", uuidbuf,
+   sizeof(uuidbuf));
+   if (!ofnode_valid(node)) {
+   log_warning("Warning: Failed to find partition by image 
UUID\n");
+   return -ENOENT;
+   }
+
+   offset = ofnode_get_addr_size_index_notrans(node, 0, );
+   if (offset == FDT_ADDR_T_NONE || !size)
+   return -ENOENT;
+
+   dfu_init_env_entities(NULL, NULL);
+
+   nalt = 0;
+   list_for_each_entry(dfu, _list, list)
+   nalt++;
+
+   if (!nalt) {
+   log_warning("No entities in dfu_alt_info\n");
+   dfu_free_entities();
+   return -ENOENT;
+   }
+
+   for (i = 0; i < nalt; i++) {
+   dfu = dfu_get_entity(i);
+
+   /* Only MTD RAW access */
+   if (!dfu || dfu->dev_type != DFU_DEV_MTD ||
+   dfu->layout != DFU_RAW_ADDR ||
+   dfu->data.mtd.start != offset ||
+   dfu->data.mtd.size != size)
+   continue;
+
+   *alt_num = dfu->alt;
+   ret = 0;
+   break;
+   }
+
+   dfu_free_entities();
+
+   return ret;
+}
+
+static int gen_image_alt_info(char *buf, size_t len, int sidx,
+  struct fwu_image_entry *img, struct mtd_info *mtd)
+{
+   int i;
+   const char *suuid;
+   ofnode node, parts_node;
+   char uuidbuf[UUID_STR_LEN + 1];
+   char *p = buf, *end = buf + len;
+
+   /* Find partition node under given MTD device. */
+   parts_node = ofnode_by_compatible(mtd_get_ofnode(mtd),
+ "fixed-partitions");
+   if (!ofnode_valid(parts_node))
+   return -ENOENT;
+
+   /* Check the media UUID if exist. */
+   suuid = ofnode_read_string(parts_node, "uuid");
+   if (suuid) {
+   log_debug("Got location uuid %s\n", suuid);
+   

[PATCHv3 1/5] FWU: Add FWU metadata access driver for MTD storage regions

2023-01-08 Thread Jassi Brar
From: Sughosh Ganu 

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, on a separate
region. Add a driver for reading from and writing to the metadata
when the updatable images and the metadata are stored on a raw
MTD region.

Signed-off-by: Sughosh Ganu 
Signed-off-by: Jassi Brar 
---
 drivers/fwu-mdata/Kconfig   |  15 +++
 drivers/fwu-mdata/Makefile  |   1 +
 drivers/fwu-mdata/raw_mtd.c | 201 
 3 files changed, 217 insertions(+)
 create mode 100644 drivers/fwu-mdata/raw_mtd.c

diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
index 36c4479a59..42736a5e43 100644
--- a/drivers/fwu-mdata/Kconfig
+++ b/drivers/fwu-mdata/Kconfig
@@ -6,6 +6,11 @@ config FWU_MDATA
  FWU Metadata partitions reside on the same storage device
  which contains the other FWU updatable firmware images.
 
+choice
+   prompt "Storage Layout Scheme"
+   depends on FWU_MDATA
+   default FWU_MDATA_GPT_BLK
+
 config FWU_MDATA_GPT_BLK
bool "FWU Metadata access for GPT partitioned Block devices"
select PARTITION_TYPE_GUID
@@ -14,3 +19,13 @@ config FWU_MDATA_GPT_BLK
help
  Enable support for accessing FWU Metadata on GPT partitioned
  block devices.
+
+config FWU_MDATA_MTD
+   bool "Raw MTD devices"
+   depends on MTD
+   help
+ Enable support for accessing FWU Metadata on non-partitioned
+ (or non-GPT partitioned, e.g. partition nodes in devicetree)
+ MTD devices.
+
+endchoice
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
index 3fee64c10c..06c49747ba 100644
--- a/drivers/fwu-mdata/Makefile
+++ b/drivers/fwu-mdata/Makefile
@@ -6,3 +6,4 @@
 
 obj-$(CONFIG_FWU_MDATA) += fwu-mdata-uclass.o
 obj-$(CONFIG_FWU_MDATA_GPT_BLK) += gpt_blk.o
+obj-$(CONFIG_FWU_MDATA_MTD) += raw_mtd.o
diff --git a/drivers/fwu-mdata/raw_mtd.c b/drivers/fwu-mdata/raw_mtd.c
new file mode 100644
index 00..edd28b4525
--- /dev/null
+++ b/drivers/fwu-mdata/raw_mtd.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#define LOG_CATEGORY UCLASS_FWU_MDATA
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/* Internal helper structure to move data around */
+struct fwu_mdata_mtd_priv {
+   struct mtd_info *mtd;
+   u32 pri_offset;
+   u32 sec_offset;
+};
+
+enum fwu_mtd_op {
+   FWU_MTD_READ,
+   FWU_MTD_WRITE,
+};
+
+#define FWU_MDATA_PRIMARY  true
+#define FWU_MDATA_SECONDARYfalse
+
+static bool mtd_is_aligned_with_block_size(struct mtd_info *mtd, u64 size)
+{
+   return !do_div(size, mtd->erasesize);
+}
+
+static int mtd_io_data(struct mtd_info *mtd, u32 offs, u32 size, void *data,
+  enum fwu_mtd_op op)
+{
+   struct mtd_oob_ops io_op ={};
+   u64 lock_offs, lock_len;
+   size_t len;
+   void *buf;
+   int ret;
+
+   if (!mtd_is_aligned_with_block_size(mtd, offs)) {
+   log_err("Offset unaligned with a block (0x%x)\n", 
mtd->erasesize);
+   return -EINVAL;
+   }
+
+   lock_offs = offs;
+   /* This will expand erase size to align with the block size */
+   lock_len = round_up(size, mtd->erasesize);
+
+   ret = mtd_unlock(mtd, lock_offs, lock_len);
+   if (ret && ret != -EOPNOTSUPP)
+   return ret;
+
+   if (op == FWU_MTD_WRITE) {
+   struct erase_info erase_op = {};
+
+   erase_op.mtd = mtd;
+   erase_op.addr = lock_offs;
+   erase_op.len = lock_len;
+   erase_op.scrub = 0;
+
+   ret = mtd_erase(mtd, _op);
+   if (ret)
+   goto lock;
+   }
+
+   /* Also, expand the write size to align with the write size */
+   len = round_up(size, mtd->writesize);
+
+   buf = memalign(ARCH_DMA_MINALIGN, len);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto lock;
+   }
+   memset(buf, 0xff, len);
+
+   io_op.mode = MTD_OPS_AUTO_OOB;
+   io_op.len = len;
+   io_op.ooblen = 0;
+   io_op.datbuf = buf;
+   io_op.oobbuf = NULL;
+
+   if (op == FWU_MTD_WRITE) {
+   memcpy(buf, data, size);
+   ret = mtd_write_oob(mtd, offs, _op);
+   } else {
+   ret = mtd_read_oob(mtd, offs, _op);
+   if (!ret)
+   memcpy(data, buf, size);
+   }
+   free(buf);
+
+lock:
+   mtd_lock(mtd, lock_offs, lock_len);
+
+   return ret;
+}
+
+static int fwu_mtd_read_mdata(struct udevice *dev, struct fwu_mdata *mdata, 
bool primary)
+{
+   struct fwu_mdata_mtd_priv *mtd_priv = dev_get_priv(dev);
+   struct mtd_info *mtd = mtd_priv->mtd;
+   u32 offs = primary ? mtd_priv->pri_offset : mtd_priv->sec_offset;
+
+   return mtd_io_data(mtd, offs, sizeof(struct fwu_mdata), mdata, 
FWU_MTD_READ);

[PATCHv3 0/5] FWU: Add support for mtd backed feature on DeveloperBox

2023-01-08 Thread Jassi Brar
Introduce support for mtd backed storage for FWU feature and enable it on
Synquacer platform based DeveloperBox.

This revision is rebased onto patchset that trims the FWU api
  
https://lore.kernel.org/u-boot/20230102182532.2411125-1-jaswinder.si...@linaro.org/

Jassi Brar (2):
  dt: fwu: developerbox: enable fwu banks and mdata regions
  fwu: DeveloperBox: add support for FWU

Masami Hiramatsu (1):
  tools: Add mkfwumdata tool for FWU metadata image

Sughosh Ganu (2):
  FWU: Add FWU metadata access driver for MTD storage regions
  FWU: mtd: Add helper functions for accessing FWU metadata

 .../synquacer-sc2a11-developerbox-u-boot.dtsi |  22 +-
 board/socionext/developerbox/Makefile |   1 +
 board/socionext/developerbox/developerbox.c   |   8 +
 board/socionext/developerbox/fwu_plat.c   |  57 +++
 configs/synquacer_developerbox_defconfig  |  13 +-
 doc/board/socionext/developerbox.rst  |  96 ++
 drivers/fwu-mdata/Kconfig |  15 +
 drivers/fwu-mdata/Makefile|   1 +
 drivers/fwu-mdata/raw_mtd.c   | 201 +++
 include/configs/synquacer.h   |  10 +
 include/fwu.h |  27 ++
 lib/fwu_updates/Makefile  |   1 +
 lib/fwu_updates/fwu_mtd.c | 172 +
 tools/Kconfig |   9 +
 tools/Makefile|   4 +
 tools/mkfwumdata.c| 326 ++
 16 files changed, 960 insertions(+), 3 deletions(-)
 create mode 100644 board/socionext/developerbox/fwu_plat.c
 create mode 100644 drivers/fwu-mdata/raw_mtd.c
 create mode 100644 lib/fwu_updates/fwu_mtd.c
 create mode 100644 tools/mkfwumdata.c

-- 
2.34.1



Re: [PATCH 1/3] dt-bindings: nvmem: u-boot,env: add MAC's #nvmem-cell-cells

2023-01-08 Thread Rob Herring
On Thu, Jan 05, 2023 at 06:10:36PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> U-Boot's "ethaddr" environment variable is very often used to store
> *base* MAC address. It's used as a base for calculating addresses for
> multiple interfaces. It's done by adding proper values. Actual offsets
> are picked by manufacturers and vary across devices.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  Documentation/devicetree/bindings/nvmem/u-boot,env.yaml | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml 
> b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> index cbc5c69fd405..1c139bd689ea 100644
> --- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> @@ -50,7 +50,11 @@ properties:
>  
>ethaddr:
>  type: object
> -description: Ethernet interface's MAC address
> +description:
> +  Ethernet interfaces base MAC address. The first argument is an offset.

The 2nd sentence belongs in the '#nvmem-cell-cells' description.

> +properties:
> +  "#nvmem-cell-cells":
> +const: 1
>  
>  additionalProperties: false
>  
> @@ -72,6 +76,7 @@ examples:
>  reg = <0x4 0x1>;
>  
>  mac: ethaddr {
> +#nvmem-cell-cells = <1>;
>  };
>  };
>  };
> -- 
> 2.34.1
> 
> 


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

2023-01-08 Thread Samuel Holland
On 7/13/22 11:21, Andre Przywara wrote:
> For legacy reasons we were defining the card detect GPIO for all sunxi
> boards in each board's defconfig.
> There is actually no need for a card-detect check in the SPL code (which
> consequently has been removed already), and also in U-Boot proper we
> have DM code to query the CD GPIO name from the device tree.
> 
> That means we don't have any user of that information left, so can
> remove the definitions from the defconfigs.
> 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-sunxi/Kconfig  | 27 

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland 



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

2023-01-08 Thread Samuel Holland
On 7/13/22 11:21, Andre Przywara wrote:
> As the SPL code for sunxi boards does not use the driver model, we have
> two mmc_ops structures, one for DM, one for non-DM. The actual hardware
> access code is shared, with the respective callback functions using that
> common code.
> 
> To make this more obvious and easier to read, reorder the functions to
> group them: we first have the common code, then the non-DM bits, and
> the proper DM implementation at the end.
> Also document this structure in the comment at the beginning of the file.
> 
> No functional change intended.
> 
> Signed-off-by: Andre Przywara 
> ---
>  drivers/mmc/sunxi_mmc.c | 117 +---
>  1 file changed, 61 insertions(+), 56 deletions(-)

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland 



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

2023-01-08 Thread Samuel Holland
Hi Andre,

Thanks for helping to get rid of sunxi_name_to_gpio().

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

The card detection logic is useless for an even simpler reason: because
of our spl_boot_device() implementation, SPL only accesses the MMC
interface where SPL itself was originally read from. Therefore, it must
have a card inserted.

> Remove the card detect code from the non-DM implementation of the sunxi
> MMC driver, to get rid of this unneeded code.
> 
> Signed-off-by: Andre Przywara 
> ---
>  drivers/mmc/sunxi_mmc.c | 37 ++---
>  1 file changed, 2 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 1bb7b6d0e9..b2f7e2d142 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -44,22 +44,10 @@ struct sunxi_mmc_priv {
>  /* support 4 mmc hosts */
>  struct sunxi_mmc_priv mmc_host[4];
>  
> -static int sunxi_mmc_getcd_gpio(int sdc_no)
> -{
> - switch (sdc_no) {
> - case 0: return sunxi_name_to_gpio(CONFIG_MMC0_CD_PIN);
> - case 1: return sunxi_name_to_gpio(CONFIG_MMC1_CD_PIN);
> - case 2: return sunxi_name_to_gpio(CONFIG_MMC2_CD_PIN);
> - case 3: return sunxi_name_to_gpio(CONFIG_MMC3_CD_PIN);
> - }
> - return -EINVAL;
> -}
> -
>  static int mmc_resource_init(int sdc_no)
>  {
>   struct sunxi_mmc_priv *priv = _host[sdc_no];
>   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> - int cd_pin, ret = 0;
>  
>   debug("init mmc %d resource\n", sdc_no);
>  
> @@ -90,16 +78,7 @@ static int mmc_resource_init(int sdc_no)
>   }
>   priv->mmc_no = sdc_no;
>  
> - cd_pin = sunxi_mmc_getcd_gpio(sdc_no);
> - if (cd_pin >= 0) {
> - ret = gpio_request(cd_pin, "mmc_cd");
> - if (!ret) {
> - sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
> - ret = gpio_direction_input(cd_pin);
> - }
> - }
> -
> - return ret;
> + return 0;
>  }
>  #endif
>  
> @@ -523,23 +502,11 @@ static int sunxi_mmc_send_cmd_legacy(struct mmc *mmc, 
> struct mmc_cmd *cmd,
>   return sunxi_mmc_send_cmd_common(priv, mmc, cmd, data);
>  }
>  
> -static int sunxi_mmc_getcd_legacy(struct mmc *mmc)
> -{
> - struct sunxi_mmc_priv *priv = mmc->priv;
> - int cd_pin;
> -
> - cd_pin = sunxi_mmc_getcd_gpio(priv->mmc_no);
> - if (cd_pin < 0)
> - return 1;
> -
> - return !gpio_get_value(cd_pin);
> -}
> -
> +/* .get_cd is not needed by the SPL */

nit: s/get_cd/getcd/

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland 

>  static const struct mmc_ops sunxi_mmc_ops = {
>   .send_cmd   = sunxi_mmc_send_cmd_legacy,
>   .set_ios= sunxi_mmc_set_ios_legacy,
>   .init   = sunxi_mmc_core_init,
> - .getcd  = sunxi_mmc_getcd_legacy,
>  };
>  
>  struct mmc *sunxi_mmc_init(int sdc_no)



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

2023-01-08 Thread Samuel Holland
On 7/13/22 10:27, Andre Przywara wrote:
> When using the USB OTG FEL mode on the Allwinner H616, the BootROM
> stores some data at the end of SRAM C. This is also the location where
> we place the initial SPL stack, so it will overwrite this data.
> We still need the BROM code after running the SPL, so should leave that
> area alone.
> Interestingly this does not seem to have an adverse effect, I guess on
> the "way out" (when we return to FEL after the SPL has run), this data
> is not needed by the BROM, for just the trailing end of the USB operation.
> However this is still wrong, and we should not clobber BROM data.
> 
> Lower the SPL stack address to be situated right below the swap buffers
> we use in sunxi-fel: that should be out of the way of everyone else.

If we are going to limit SPL size based on these buffers, we should
ensure they are as close to the end of SRAM as possible.

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

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland 



Re: Pull request for u-boot-nand-20230108

2023-01-08 Thread Tom Rini
On Sun, Jan 08, 2023 at 01:41:53PM +0100, Dario Binacchi wrote:

> Hi Tom,
> 
> The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a:
> 
>   Merge branch '2023-01-02-platform-updates' into next (2023-01-02
> 18:07:41 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
> tags/u-boot-nand-20230108
> 
> for you to fetch changes up to 7363cf0581a3e70b3dbd346dec8b7ae652776f80:
> 
>   mtd: rawnand: omap_elm: u-boot driver model support (2023-01-08
> 10:38:50 +0100)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14646
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


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

2023-01-08 Thread Samuel Holland
On 7/13/22 10:27, Andre Przywara wrote:
> For some reasons shrouded in mystery, the code saving the FEL state was
> saving the SCTLR register twice, with the second copy trying to justify
> itself by using its ancient "control register" alias name.
> 
> Drop the redundant second copy, both from the fel_stash data structure,
> and also the code saving and restoring it.
> 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv7/sunxi/fel_utils.S | 4 
>  arch/arm/mach-sunxi/board.c  | 1 -
>  2 files changed, 5 deletions(-)

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland 



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

2023-01-08 Thread Samuel Holland
On 7/13/22 10:27, Andre Przywara wrote:
> Both the values and the MMIO addresses that we need during the 64-bit FEL
> restore are smaller than 2^32, so we don't need to do any 64-bit loads.
> 
> Change the loads to only load 32 bits worth of data, that saves us some
> bytes for storing the values.
> 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/fel_utils.S | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland 



Re: [PATCH v9 14/14] treewide: Disable USE_SPL_FIT_GENERATOR by default

2023-01-08 Thread Simon Glass
Hi Tom,

On Sun, 8 Jan 2023 at 09:24, Tom Rini  wrote:
>
> On Sun, Jan 08, 2023 at 09:20:09AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 8 Jan 2023 at 09:06, Tom Rini  wrote:
> > >
> > > On Sun, Jan 08, 2023 at 08:48:37AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 8 Jan 2023 at 06:41, Tom Rini  wrote:
> > > > >
> > > > > On Sat, Jan 07, 2023 at 02:07:21PM -0700, Simon Glass wrote:
> > > > >
> > > > > > This option is deprecated and only used by two boards. Enable it 
> > > > > > for just
> > > > > > those two boards, so others don't accidentally enable it.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > [snip]
> > > > > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > > > > index 55f06761ef8..7ab0dd14211 100644
> > > > > > --- a/boot/Kconfig
> > > > > > +++ b/boot/Kconfig
> > > > > > @@ -282,12 +282,13 @@ config SPL_FIT_SOURCE
> > > > > >  config USE_SPL_FIT_GENERATOR
> > > > > >   bool "Use a script to generate the .its script"
> > > > > >   depends on SPL_FIT
> > > > > > - default y if SPL_FIT && ARCH_ZYNQMP
> > > > > > + help
> > > > > > +   This is deprecated. Please do not use it. Use binman 
> > > > > > instead.
> > > > >
> > > > > Lets remove the text around bool so it can't be enabled, and move to
> > > > > select'ing it from the two boards that need it. Michal, Luca, what's
> > > > > needed to move your two platforms
> > > > > (avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0 and xilinx_zynqmp_virt 
> > > > > off
> > > > > of this very legacy option, given that other xilinx platforms have
> > > > > already migrated to binman ?
> > > >
> > > > That's a good idea, but these two boards do not have TARGET Kconfig
> > > > options so it is not possible without adding some Kconfig specific to
> > > > those boards, then defining it in the defconfig files.
> > > >
> > > > We already have the legacy warning.
> > >
> > > Yes, but I swear these are new legacy users as when we started trying to
> > > kill off this option it was just a few i.MX platforms lagging behind.
> > >
> > > Maybe make ARCH_ZYNQMP select DEPRECATED, USE_SPL_FIT_GENERATOR depend
> > > on DEPRECATED and add "DERECATED" to the end of the text line?  Or maybe
> > > Michal or Luca will speak up soon and migrate these over quickly so we
> > > can just nuke this.
> >
> > Isn't that just more tortuous? I can disable SPL_LOAD_FIT on these two
> > boards since they don't appear in CI. Then they can convert them when
> > ready.
> >
> > That way we can drop the option now, if that is your goal.
>
> I thought xilinx_zynqmp_virt was in CI, but I see I'm mistaken. I still
> don't want to break platforms outright, and since it's Sunday right now
> afterall, we should let Michal and Luca a chance to catch up and chime
> in. I hope it's either going to be a quick conversion or expose
> something missing and needed in binman, as to why these still haven't
> been converted.
>

OK let's hold off on this patch for now. It is just a clean-up anyway.

Regards,
Simon


[PATCH 1/1] efi_loader: add .rela sections to .text on arm64

2023-01-08 Thread Heinrich Schuchardt
_relocate() needs the information in .rela* for self relocation
of the EFI binary.

Fixes: d7ddeb66a6ce ("efi_loader: fix building aarch64 EFI binaries")
Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/lib/elf_aarch64_efi.lds | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/lib/elf_aarch64_efi.lds b/arch/arm/lib/elf_aarch64_efi.lds
index 3e3da47d6a..5dd9809169 100644
--- a/arch/arm/lib/elf_aarch64_efi.lds
+++ b/arch/arm/lib/elf_aarch64_efi.lds
@@ -28,6 +28,10 @@ SECTIONS
*(.dynamic);
. = ALIGN(512);
}
+   .rela.dyn : { *(.rela.dyn) }
+   .rela.plt : { *(.rela.plt) }
+   .rela.got : { *(.rela.got) }
+   .rela.data : { *(.rela.data) *(.rela.data*) }
_etext = .;
_text_size = . - _text;
. = ALIGN(4096);
@@ -57,10 +61,6 @@ SECTIONS
_edata = .;
} :data
_data_size = _edata - _data;
-   .rela.dyn : { *(.rela.dyn) }
-   .rela.plt : { *(.rela.plt) }
-   .rela.got : { *(.rela.got) }
-   .rela.data : { *(.rela.data) *(.rela.data*) }
 
. = ALIGN(4096);
.dynsym   : { *(.dynsym) }
-- 
2.37.2



Re: [PATCH v2 1/2] wandboard: Pass mmc aliases

2023-01-08 Thread Fabio Estevam
On Sun, Jan 8, 2023 at 11:58 AM Tom Rini  wrote:

> It's already been merged:
> commit f827f84d3f5607d0b33e927f6127a888e7bd664f

Ok, great! I haven't received any message saying it has been applied,
so that's why I missed it.

Thanks


Re: [PATCH 1/1] efi_loader: fix .reloc section of arm64

2023-01-08 Thread Heinrich Schuchardt




On 1/8/23 15:19, Heinrich Schuchardt wrote:

When adding

 const unsigned short *menu_items[] = {
 u"abc\n",
 u"def\n",
 NULL
 };

to  helloworld.c outside of a function and then referring to the variable
in a function the pointer the reference is incorrect. This is due to not
considering the generated relocations.

Fix the linker script and the PE-COFF header.

Fixes: c65d76ed5f81 ("efi: arm: Add aarch64 EFI app support")
Signed-off-by: Heinrich Schuchardt 


Debugging shows that function _relocate() finds a pointer to .rela.data 
and then uses this for the self relocation.


Do this .rela.data should not be in .reloc but in .text.

Best regards

Heinrich


Re: [PATCH] pylibfdt: Allow version normalization to fail

2023-01-08 Thread Tom Rini
On Sat, Jan 07, 2023 at 06:04:07PM -0500, Tom Rini wrote:

> In some cases, we might not have the sic portion of setuputils
> available. Make our import and use of this be done in try/except blocks
> as this is done to suppress a run-time warning that is otherwise
> non-fatal.
> 
> Reported-by: Pali Rohár 
> Fixes: 141659187667 ("pylibfdt: Fix disable version normalization")
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] distro_bootcmd: Fix copy-paste error

2023-01-08 Thread Tom Rini
On Thu, Jan 05, 2023 at 02:26:03AM +0100, Marek Vasut wrote:

> The "SCRIPT FAILED" string is copied from scan_dev_for_scripts script,
> update it so it prints "EXTLINUX FAILED" instead in scan_dev_for_extlinux
> script.
> 
> Signed-off-by: Marek Vasut 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] common/memsize.c: Check for overflow in get_effective_memsize() only for mpc85xx

2023-01-08 Thread Tom Rini
On Sat, Jan 07, 2023 at 10:55:26PM +0100, Pali Rohár wrote:

> This reverts commit 777706bc ("common/memsize.c: Fix
> get_effective_memsize() to check for overflow") for non-mpc85xx platforms.
> 
> The changes to this generic function, which is intended to help with
> 32bit platforms with large amounts of memory has unintended side effects
> (which in turn lead to boot failures) on other platforms which were
> previously functional.
> 
> For now do overflow check only for powerpc mpc85xx platform. It is needed
> to prevent crashing of P1/P2 boards with 4GB DDR module in 32-bit mode.
> 
> Fixes: 777706bc ("common/memsize.c: Fix get_effective_memsize() to check 
> for overflow")
> Signed-off-by: Pali Rohár 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v9 14/14] treewide: Disable USE_SPL_FIT_GENERATOR by default

2023-01-08 Thread Tom Rini
On Sun, Jan 08, 2023 at 09:20:09AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 8 Jan 2023 at 09:06, Tom Rini  wrote:
> >
> > On Sun, Jan 08, 2023 at 08:48:37AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 8 Jan 2023 at 06:41, Tom Rini  wrote:
> > > >
> > > > On Sat, Jan 07, 2023 at 02:07:21PM -0700, Simon Glass wrote:
> > > >
> > > > > This option is deprecated and only used by two boards. Enable it for 
> > > > > just
> > > > > those two boards, so others don't accidentally enable it.
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > > [snip]
> > > > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > > > index 55f06761ef8..7ab0dd14211 100644
> > > > > --- a/boot/Kconfig
> > > > > +++ b/boot/Kconfig
> > > > > @@ -282,12 +282,13 @@ config SPL_FIT_SOURCE
> > > > >  config USE_SPL_FIT_GENERATOR
> > > > >   bool "Use a script to generate the .its script"
> > > > >   depends on SPL_FIT
> > > > > - default y if SPL_FIT && ARCH_ZYNQMP
> > > > > + help
> > > > > +   This is deprecated. Please do not use it. Use binman instead.
> > > >
> > > > Lets remove the text around bool so it can't be enabled, and move to
> > > > select'ing it from the two boards that need it. Michal, Luca, what's
> > > > needed to move your two platforms
> > > > (avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0 and xilinx_zynqmp_virt off
> > > > of this very legacy option, given that other xilinx platforms have
> > > > already migrated to binman ?
> > >
> > > That's a good idea, but these two boards do not have TARGET Kconfig
> > > options so it is not possible without adding some Kconfig specific to
> > > those boards, then defining it in the defconfig files.
> > >
> > > We already have the legacy warning.
> >
> > Yes, but I swear these are new legacy users as when we started trying to
> > kill off this option it was just a few i.MX platforms lagging behind.
> >
> > Maybe make ARCH_ZYNQMP select DEPRECATED, USE_SPL_FIT_GENERATOR depend
> > on DEPRECATED and add "DERECATED" to the end of the text line?  Or maybe
> > Michal or Luca will speak up soon and migrate these over quickly so we
> > can just nuke this.
> 
> Isn't that just more tortuous? I can disable SPL_LOAD_FIT on these two
> boards since they don't appear in CI. Then they can convert them when
> ready.
> 
> That way we can drop the option now, if that is your goal.

I thought xilinx_zynqmp_virt was in CI, but I see I'm mistaken. I still
don't want to break platforms outright, and since it's Sunday right now
afterall, we should let Michal and Luca a chance to catch up and chime
in. I hope it's either going to be a quick conversion or expose
something missing and needed in binman, as to why these still haven't
been converted.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v9 14/14] treewide: Disable USE_SPL_FIT_GENERATOR by default

2023-01-08 Thread Simon Glass
Hi Tom,

On Sun, 8 Jan 2023 at 09:06, Tom Rini  wrote:
>
> On Sun, Jan 08, 2023 at 08:48:37AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 8 Jan 2023 at 06:41, Tom Rini  wrote:
> > >
> > > On Sat, Jan 07, 2023 at 02:07:21PM -0700, Simon Glass wrote:
> > >
> > > > This option is deprecated and only used by two boards. Enable it for 
> > > > just
> > > > those two boards, so others don't accidentally enable it.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > [snip]
> > > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > > index 55f06761ef8..7ab0dd14211 100644
> > > > --- a/boot/Kconfig
> > > > +++ b/boot/Kconfig
> > > > @@ -282,12 +282,13 @@ config SPL_FIT_SOURCE
> > > >  config USE_SPL_FIT_GENERATOR
> > > >   bool "Use a script to generate the .its script"
> > > >   depends on SPL_FIT
> > > > - default y if SPL_FIT && ARCH_ZYNQMP
> > > > + help
> > > > +   This is deprecated. Please do not use it. Use binman instead.
> > >
> > > Lets remove the text around bool so it can't be enabled, and move to
> > > select'ing it from the two boards that need it. Michal, Luca, what's
> > > needed to move your two platforms
> > > (avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0 and xilinx_zynqmp_virt off
> > > of this very legacy option, given that other xilinx platforms have
> > > already migrated to binman ?
> >
> > That's a good idea, but these two boards do not have TARGET Kconfig
> > options so it is not possible without adding some Kconfig specific to
> > those boards, then defining it in the defconfig files.
> >
> > We already have the legacy warning.
>
> Yes, but I swear these are new legacy users as when we started trying to
> kill off this option it was just a few i.MX platforms lagging behind.
>
> Maybe make ARCH_ZYNQMP select DEPRECATED, USE_SPL_FIT_GENERATOR depend
> on DEPRECATED and add "DERECATED" to the end of the text line?  Or maybe
> Michal or Luca will speak up soon and migrate these over quickly so we
> can just nuke this.

Isn't that just more tortuous? I can disable SPL_LOAD_FIT on these two
boards since they don't appear in CI. Then they can convert them when
ready.

That way we can drop the option now, if that is your goal.

Regards,
Simon


Re: Applying DTB Overlays from ATF on RZ/G2

2023-01-08 Thread Adam Ford
On Sat, Jan 7, 2023 at 6:01 AM Adam Ford  wrote:
>
> On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut  wrote:
> >
> > On 1/5/23 00:48, Heinrich Schuchardt wrote:
> > > Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :
> > >> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt  
> > >> wrote:
> > >>>
> > >>> On 1/4/23 22:35, Adam Ford wrote:
> >  ATF generates a couple memory nodes based on how it's compiled and
> >  generates a reserved-memory node, and I want to overlay it with the
> >  device tree so Linux knows about this reserved memory.
> > 
> >  When I boot U-Boot, I can read the reserved-memory node:
> > 
> >  => fdt addr 0xe631e588
> >  Working FDT set to e631e588
> >  => fdt print /reserved-memory
> >  reserved-memory {
> >  lossy-decompression@5400 {
> >  renesas,formats = <0x>;
> >  no-map;
> >  reg = <0x 0x5400 0x 0x0300>;
> >  compatible = "renesas,lossy-decompression", "shared-dma-pool";
> >  };
> >  };
> >  =>
> > 

+ CC Biju Das
> >  I attempt to overlay it with the following:
> > 
> >  => run loadfdt
> >  65932 bytes read in 6 ms (10.5 MiB/s)
> >  => fdt addr $load_addr
> > >>>
> > >>> When actually setting the address you will see a message "Working FDT
> > >>> set to %lx\n". So I assume $load_addr is empty.
> > >>>
> > >>> Did you mean $loadaddr or $fileaddr?
> > >>
> > >> Opps, that was a copy-paste error.  Even with that, I still get the
> > >> failure to overlay:
> > >>
> > >
> > > Did you load a .dtbo file to apply? You cannot apply a devicetree.
> > >
> > > Is the fdt that you want to apply the overlay to built with symbols (dtc 
> > > parameter -@)?
> >
> > Note that the fragment passed to U-Boot by upstream ATF is already
> > automatically merged into the U-Boot control DT (see
> > board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
> > Linux automatically.
>
> I ran some tests, and it appears the function fdtdec_board_setup is
> never getting called.  That looks like the code that grabs the blob
> from ATF.  I intentionally removed the memory nodes from the kernel
> device tree expecting the memory nodes to get added from ATF, but when
> I booted it, it promptly hung.  That implied to me that the memory
> nodes didn't get added from ATF.
>
> I added some debug code and noticed that ft_board_setup did not get
> executed, so I created a call to fdtdec_board_setup from
> ft_board_setup and my board booted just fine.  I am curious to know if
> other rcar/rzg2 boards are seeing something similar?  Is calling
> fdtdec_board_setup from ft_board_setup appropriate?
>
> adam


[PATCH v2] board: rockchip: Fix binman_init failure on EVB-RK3568

2023-01-08 Thread Jagan Teki
For some newer SoCs like RK3568, the Rockchip has not released
any DDR drivers yet so idbloader needs to create manually using
DDR binaries offered by rkbin. This indeed no requirement to
enable TPL in the U-Boot source code.

If we mark TPL disabled and mark BINMAN enabled by default then
there would be an issue of binman_init failure during board
relocation. This is true as binman failed to find the top-level
node like u-boot-tpl here.

Here is the boot issue observed in Radxa-CM3 RK3566 board,

 U-Boot 2023.01-rc4-00057-gac2505d463-dirty (Jan 04 2023 - 23:44:18 +0530)

 Model: Radxa Compute Module 3(CM3) IO Board
 DRAM:  2 GiB
 binman_init failed:-2
 initcall sequence 7ffd2008 failed at call 00a18cac (err=-2)
 ### ERROR ### Please RESET the board ###

This might be fixed via binman node in rockchip-u-boot.dtsi however
disable BINMAN_FDT for evb-rk3568 defconfig for now as we are at the
end of the release cycle.

Fixes: 05713d570762 ("rockchip: generate u-boot-rockchip.bin with binman
for ARM64 boards")
Cc: Quentin Schulz 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- disable BINMAN_FDT in defconfig instead disabling BINMAN in
  ARCH_ROCKCHIP

 configs/evb-rk3568_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/evb-rk3568_defconfig b/configs/evb-rk3568_defconfig
index db3acf5be5..e799690578 100644
--- a/configs/evb-rk3568_defconfig
+++ b/configs/evb-rk3568_defconfig
@@ -64,4 +64,5 @@ CONFIG_DM_RESET=y
 CONFIG_BAUDRATE=150
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
+# CONFIG_BINMAN_FDT is not set
 CONFIG_ERRNO_STR=y
-- 
2.25.1



Re: [PATCH v9 14/14] treewide: Disable USE_SPL_FIT_GENERATOR by default

2023-01-08 Thread Tom Rini
On Sun, Jan 08, 2023 at 08:48:37AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 8 Jan 2023 at 06:41, Tom Rini  wrote:
> >
> > On Sat, Jan 07, 2023 at 02:07:21PM -0700, Simon Glass wrote:
> >
> > > This option is deprecated and only used by two boards. Enable it for just
> > > those two boards, so others don't accidentally enable it.
> > >
> > > Signed-off-by: Simon Glass 
> > [snip]
> > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > index 55f06761ef8..7ab0dd14211 100644
> > > --- a/boot/Kconfig
> > > +++ b/boot/Kconfig
> > > @@ -282,12 +282,13 @@ config SPL_FIT_SOURCE
> > >  config USE_SPL_FIT_GENERATOR
> > >   bool "Use a script to generate the .its script"
> > >   depends on SPL_FIT
> > > - default y if SPL_FIT && ARCH_ZYNQMP
> > > + help
> > > +   This is deprecated. Please do not use it. Use binman instead.
> >
> > Lets remove the text around bool so it can't be enabled, and move to
> > select'ing it from the two boards that need it. Michal, Luca, what's
> > needed to move your two platforms
> > (avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0 and xilinx_zynqmp_virt off
> > of this very legacy option, given that other xilinx platforms have
> > already migrated to binman ?
> 
> That's a good idea, but these two boards do not have TARGET Kconfig
> options so it is not possible without adding some Kconfig specific to
> those boards, then defining it in the defconfig files.
> 
> We already have the legacy warning.

Yes, but I swear these are new legacy users as when we started trying to
kill off this option it was just a few i.MX platforms lagging behind.

Maybe make ARCH_ZYNQMP select DEPRECATED, USE_SPL_FIT_GENERATOR depend
on DEPRECATED and add "DERECATED" to the end of the text line?  Or maybe
Michal or Luca will speak up soon and migrate these over quickly so we
can just nuke this.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 13/14] rockchip: Enable bootstage on rockpro64

2023-01-08 Thread Simon Glass
On Sat, 7 Jan 2023 at 14:57, Simon Glass  wrote:
>
> This board is useful for benchmarking overall U-Boot performance. Enable
> the bootstage feature so we get a report.
>
> Since this returns to the boot rom before finishing executing
> board_init_r() in SPL, add a few bootstage calls so that we can collect
> timing from TPL.
>
> For the stash region, use a portion of SRAM, 64KB below the stack top.
> This allows the TPL image to be up to nearly 120KB (it is typically about
> 64KB). SPL normally runs from SDRAM at 0, so can use the same stash
> region.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Drop unwanted debugging
>
>  arch/arm/mach-rockchip/tpl.c   | 16 +---
>  configs/rockpro64-rk3399_defconfig |  8 
>  2 files changed, 21 insertions(+), 3 deletions(-)
>

Applied to u-boot-dm/next


Re: [PATCH v4 7/9] video: Use VIDEO_DAMAGE for VIDEO_COPY

2023-01-08 Thread Simon Glass
Hi Heinrich,

On Sat, 7 Jan 2023 at 16:22, Heinrich Schuchardt  wrote:
>
> On 1/7/23 01:13, Simon Glass wrote:
> > Hi Alexander,
> >
> > On Tue, 3 Jan 2023 at 14:50, Alexander Graf  wrote:
> >>
> >> CONFIG_VIDEO_COPY implemented a range based copying mechanism: If we
> >
> > range-based
> >
> >> print a single character, it will always copy the full range of bytes
> >> from the top left corner of the character to the lower right onto the
> >> uncached frame buffer. This includes pretty much the full line contents
> >> of the printed character.
> >>
> >> Since we now have proper damage tracking, let's make use of that to reduce
> >> the amount of data we need to copy. With this patch applied, we will only
> >> copy the tiny rectangle surrounding characters when we print them,
> >> speeding up the video console.
> >>
> >> As a bonus, we remove a lot of code.
> >>
> >> Signed-off-by: Alexander Graf 
> >>
> >> ---
> >>
> >> v2 -> v3:
> >>
> >>- Rebase
> >>- Make CONFIG_COPY always select VIDEO_DAMAGE
> >> ---
> >>   drivers/video/Kconfig |  5 ++
> >>   drivers/video/console_normal.c| 14 +
> >>   drivers/video/console_rotate.c| 37 ++---
> >>   drivers/video/console_truetype.c  | 17 +-
> >>   drivers/video/vidconsole-uclass.c | 16 --
> >>   drivers/video/video-uclass.c  | 91 ---
> >>   drivers/video/video_bmp.c |  7 ---
> >>   include/video.h   | 37 -
> >>   include/video_console.h   | 49 -
> >>   9 files changed, 37 insertions(+), 236 deletions(-)
> >>
> >
> > This feature needs some tests in test/dm/video.c
> >
> > For sandbox, I think you will need to allow it to be enabled /
> > disabled at runtime, so the some tests can use it and some not?
>
> It should be good enough to enable the feature in one of the sandbox
> defconfigs and disable it in another.

Yes that would work, e.g. enable in sandbox but not sandbox_flattree

Regards,
Simon


Re: [PATCH v9 14/14] treewide: Disable USE_SPL_FIT_GENERATOR by default

2023-01-08 Thread Simon Glass
Hi Tom,

On Sun, 8 Jan 2023 at 06:41, Tom Rini  wrote:
>
> On Sat, Jan 07, 2023 at 02:07:21PM -0700, Simon Glass wrote:
>
> > This option is deprecated and only used by two boards. Enable it for just
> > those two boards, so others don't accidentally enable it.
> >
> > Signed-off-by: Simon Glass 
> [snip]
> > diff --git a/boot/Kconfig b/boot/Kconfig
> > index 55f06761ef8..7ab0dd14211 100644
> > --- a/boot/Kconfig
> > +++ b/boot/Kconfig
> > @@ -282,12 +282,13 @@ config SPL_FIT_SOURCE
> >  config USE_SPL_FIT_GENERATOR
> >   bool "Use a script to generate the .its script"
> >   depends on SPL_FIT
> > - default y if SPL_FIT && ARCH_ZYNQMP
> > + help
> > +   This is deprecated. Please do not use it. Use binman instead.
>
> Lets remove the text around bool so it can't be enabled, and move to
> select'ing it from the two boards that need it. Michal, Luca, what's
> needed to move your two platforms
> (avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0 and xilinx_zynqmp_virt off
> of this very legacy option, given that other xilinx platforms have
> already migrated to binman ?

That's a good idea, but these two boards do not have TARGET Kconfig
options so it is not possible without adding some Kconfig specific to
those boards, then defining it in the defconfig files.

We already have the legacy warning.

Regards,
Simon


Re: [PATCH 1/1] doc: building documentation

2023-01-08 Thread Simon Glass
Hi Tom,

On Sun, 8 Jan 2023 at 06:44, Tom Rini  wrote:
>
> On Sat, Jan 07, 2023 at 07:37:03PM -0700, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sat, 7 Jan 2023 at 17:11, Heinrich Schuchardt
> >  wrote:
> > >
> > >
> > >
> > > On 1/7/23 23:54, Simon Glass wrote:
> > > > Hi Heinrich,
> > > >
> > > > On Sat, 7 Jan 2023 at 15:16, Heinrich Schuchardt
> > > >  wrote:
> > > >>
> > > >>
> > > >>
> > > >> On 1/7/23 19:55, Simon Glass wrote:
> > > >>> Hi Heinrich,
> > > >>>
> > > >>> On Fri, 30 Dec 2022 at 12:08, Heinrich Schuchardt
> > > >>>  wrote:
> > > 
> > > 
> > > 
> > >  On 12/30/22 20:02, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Fri, 30 Dec 2022 at 12:31, Heinrich Schuchardt
> > > >  wrote:
> > > >>
> > > >>
> > > >>
> > > >> On 12/30/22 19:12, Tom Rini wrote:
> > > >>> On Fri, Dec 30, 2022 at 11:51:15AM -0600, Simon Glass wrote:
> > >  Hi Heinrich,
> > > 
> > >  On Thu, 29 Dec 2022 at 22:08, Heinrich Schuchardt
> > >   wrote:
> > > >
> > > > Provide a man-page describing how to build the U-Boot 
> > > > documentation.
> > > >
> > > > Signed-off-by: Heinrich Schuchardt 
> > > > 
> > > > ---
> > > >  doc/build/documentation.rst | 90 
> > > > +
> > > >  doc/build/index.rst |  1 +
> > > >  2 files changed, 91 insertions(+)
> > > >  create mode 100644 doc/build/documentation.rst
> > > >
> > > > diff --git a/doc/build/documentation.rst 
> > > > b/doc/build/documentation.rst
> > > > new file mode 100644
> > > > index 00..896264dd7c
> > > > --- /dev/null
> > > > +++ b/doc/build/documentation.rst
> > > > @@ -0,0 +1,90 @@
> > > > +.. SPDX-License-Identifier: GPL-2.0+:
> > > > +
> > > > +Building documentation
> > > > +==
> > > > +
> > > > +The U-Boot documentation is based on the Sphinx documentation 
> > > > generator.
> > > > +
> > > > +HTML documentation
> > > > +--
> > > > +
> > > > +The *htmldocs* target is used to build the HTML documentation. 
> > > > It uses the
> > > > +`Read the Docs Sphinx theme 
> > > > `_.
> > > > +
> > > > +.. code-block:: bash
> > > > +
> > > > +# Create Python environment 'myenv'
> > > > +python3 -m venv myenv
> > > > +# Activate the Python environment
> > > > +. myenv/bin/activate
> > > > +# Install build requirements
> > > > +python3 -m pip install -r doc/sphinx/requirements.txt
> > > > +# Build the documentation
> > > > +make htmldocs
> > > > +# Deactivate the Python environment
> > > > +deactivate
> > > > +# Display the documentation in a graphical web browser
> > > > +x-www-browser doc/output/index.html
> > > 
> > >  If this is necessary then it is a bit of a sad indictment on 
> > >  Python. I
> > >  would use:
> > > 
> > >  pip3 install -r doc/sphinx/requirements.txt
> > >  make htmldocs
> > > >>>
> > > >>> Which part, exactly? Using a virtual environment is I believe a 
> > > >>> normal
> > > >>> best practice and "python3 -m pip" rather than "pip3" I assume is
> > > >>> another best practice for portability. Then maybe the final step 
> > > >>> should
> > > >>> say "Review" not "Display" ?
> > > >>>
> > > >>
> > > >> Review only applies to documentation developers.
> > > >> Normal users just want to read the documentation.
> > > >
> > > > Using a virtual environment seems annoying to me. Should we put that
> > > > in a separate section for those who want to do it?
> > > 
> > >  Current Ubuntu packages are incompatible with the readthedocs theme.
> > >  Therefore I describe a way of building that works for most users.
> > > >>>
> > > >>> OK I see. Somehow it builds OK for me on 22.04 but I have not tried
> > > >>> newer versions.
> > > >>
> > > >> make htmldocs builds but the formatting of the HTML does not conform to
> > > >> the readthedocs style. Just open the documentation in a browser.
> > > >
> > > > It looks OK for me...what should I be seeing?
> > >
> > > This is the output without Python environment:
> > > https://gist.github.com/xypron/aef88822a1f2f34e29faf5302313de6a
> > >
> > > This is what it should look like:
> > > https://u-boot.readthedocs.io/en/latest/
> >
> > Strangely, for me, it looks like the second thing even without the
> > environment. I have seen the first one though, but not for a while.I
> > vaguely remember installing some style package?
>

Re: [PATCH v2 1/2] wandboard: Pass mmc aliases

2023-01-08 Thread Tom Rini
On Sun, Jan 08, 2023 at 08:36:21AM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Tue, Jan 3, 2023 at 8:00 AM Fabio Estevam  wrote:
> >
> > Hi Tom and Stefano,
> >
> > On Fri, Nov 4, 2022 at 8:13 AM Fabio Estevam  wrote:
> > >
> > > From: Fabio Estevam 
> > >
> > > Originally, the mmc aliases node was present in imx6qdl-wandboard.dtsi.
> > >
> > > After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
> > > synchronise device trees with linux"), the aliases node is gone as
> > > the upstream version does not have it.
> > >
> > > This causes a regression in which the SD card cannot be found anymore:
> > >
> > > Since commit  the aliases node has been removed
> > > U-Boot 2022.10-00999-gcca41ed3d63f-dirty (Nov 03 2022 - 22:07:38 -0300)
> > >
> > > CPU:   Freescale i.MX6QP rev1.0 at 792 MHz
> > > Reset cause: POR
> > > DRAM:  2 GiB
> > > Core:  62 devices, 17 uclasses, devicetree: separate
> > > PMIC:  PFUZE100 ID=0x10
> > > MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> > > Loading Environment from MMC... MMC: no card present
> > > *** Warning - No block device, using default environment
> > >
> > > Fix it by passing the alias node in the u-boot.dtsi file to
> > > restore the original behaviour where the SD card (esdhc3) was
> > > mapped to mmc0.
> > >
> > > Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with 
> > > linux")
> > > Signed-off-by: Fabio Estevam 
> > > ---
> > > Changes since v1:
> > > - Add patch numbering.
> >
> > Please consider applying this one to 2023.01 to fix the boot regression.
> 
> Could you please apply this one directly to 2023.01 to fix the boot 
> regression?

It's already been merged:
commit f827f84d3f5607d0b33e927f6127a888e7bd664f
Author: Fabio Estevam 
AuthorDate: Fri Nov 4 08:12:54 2022 -0300
Commit: Stefano Babic 
CommitDate: Wed Nov 9 17:12:31 2022 +0100

wandboard: Pass mmc aliases

Originally, the mmc aliases node was present in imx6qdl-wandboard.dtsi.

After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
synchronise device trees with linux"), the aliases node is gone as
the upstream version does not have it.

This causes a regression in which the SD card cannot be found anymore:

Since commit  the aliases node has been removed
U-Boot 2022.10-00999-gcca41ed3d63f-dirty (Nov 03 2022 - 22:07:38 -0300)

CPU:   Freescale i.MX6QP rev1.0 at 792 MHz
Reset cause: POR
DRAM:  2 GiB
Core:  62 devices, 17 uclasses, devicetree: separate
PMIC:  PFUZE100 ID=0x10
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... MMC: no card present
*** Warning - No block device, using default environment

Fix it by passing the alias node in the u-boot.dtsi file to
restore the original behaviour where the SD card (esdhc3) was
mapped to mmc0.

Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with linux")
Signed-off-by: Fabio Estevam 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] board: sifive: unmatched: enable booting on a second NVME device

2023-01-08 Thread Maciej W. Rozycki
On Sun, 8 Jan 2023, Heinrich Schuchardt wrote:

> > diff --git a/include/configs/sifive-unmatched.h
> > b/include/configs/sifive-unmatched.h
> > index 85fab92719..9261932af9 100644
> > --- a/include/configs/sifive-unmatched.h
> > +++ b/include/configs/sifive-unmatched.h
> > @@ -19,6 +19,7 @@
> > 
> >   #define BOOT_TARGET_DEVICES(func) \
> > func(NVME, nvme, 0) \
> > +   func(NVME, nvme, 1) \
> 
> We can have up to three NVMe drives directly connected. Just put an
> adapter into the 2230 m.2 slot (e.g.
> https://www.aliexpress.com/item/32968036136.html, NGFF M.2 Key M to Key
> A+E Extension Cable NGFF Key M to A+E Adapter Card Board).

 Or you can have an adapter with a PCIe switch such as the SI-PEX40152 
 
plugged with up to 4 NVMe devices.  So it really looks to me like this 
should be dynamic or at least set to a reasonably high static limit such 
as 16.

 NB I have 12 buses present with various devices in the PCIe hierarchy 
with my Unmatched system, so it's up to the user really how far to extend 
the system and it has to be taken into account while arranging firmware 
configuration IMHO:

00:00.0 PCI bridge: SiFive, Inc. FU740-C000 RISC-V SoC PCI Express x8 to AXI4 
Bridge
01:00.0 PCI bridge: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch 
(rev 01)
02:00.0 PCI bridge: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch 
(rev 01)
02:02.0 PCI bridge: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch 
(rev 01)
02:03.0 PCI bridge: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch 
(rev 01)
02:04.0 PCI bridge: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch 
(rev 01)
02:08.0 PCI bridge: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch 
(rev 01)
04:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
05:00.0 PCI bridge: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane 
Packet Switch (rev 05)
06:01.0 PCI bridge: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane 
Packet Switch (rev 05)
06:02.0 PCI bridge: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane 
Packet Switch (rev 05)
07:00.0 Parallel controller: Oxford Semiconductor Ltd OXPCIe952 Parallel Port
07:00.3 Serial controller: Oxford Semiconductor Ltd OXPCIe952 Native 950 UART
08:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge 
(rev 04)
09:01.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ 
Interface Chip [PFI] FDDI (DEFPA) (rev 02)
09:02.0 ATM network controller: Microsemi / PMC / IDT IDT77201/77211 155Mbps 
ATM SAR Controller [NICStAR] (rev 03)
0a:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD 
Controller SM981/PM981/PM983
0b:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9120 SATA 6Gb/s 
Controller (rev 20)
0b:00.1 IDE interface: Marvell Technology Group Ltd. 88SE912x IDE Controller 
(rev 20)

  Maciej


[PATCH 1/1] efi_loader: fix .reloc section of arm64

2023-01-08 Thread Heinrich Schuchardt
When adding

const unsigned short *menu_items[] = {
u"abc\n",
u"def\n",
NULL
};

to  helloworld.c outside of a function and then referring to the variable
in a function the pointer the reference is incorrect. This is due to not
considering the generated relocations.

Fix the linker script and the PE-COFF header.

Fixes: c65d76ed5f81 ("efi: arm: Add aarch64 EFI app support")
Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/lib/crt0_aarch64_efi.S  | 32 
 arch/arm/lib/elf_aarch64_efi.lds | 11 +++
 2 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S
index 3c2cef6ec7..3520182217 100644
--- a/arch/arm/lib/crt0_aarch64_efi.S
+++ b/arch/arm/lib/crt0_aarch64_efi.S
@@ -89,22 +89,6 @@ section_table:
 * because EFI applications must be relocatable.  This is a
 * dummy section as far as we are concerned.
 */
-   .ascii  ".reloc"
-   .byte   0
-   .byte   0   /* end of 0 padding of section name */
-   .long   0
-   .long   0
-   .long   0   /* SizeOfRawData */
-   .long   0   /* PointerToRawData */
-   .long   0   /* PointerToRelocations */
-   .long   0   /* PointerToLineNumbers */
-   .short  0   /* NumberOfRelocations */
-   .short  0   /* NumberOfLineNumbers */
-   /* Characteristics (section flags) */
-   .long   (IMAGE_SCN_MEM_READ | \
-IMAGE_SCN_MEM_DISCARDABLE | \
-IMAGE_SCN_CNT_INITIALIZED_DATA)
-
.ascii  ".text"
.byte   0
.byte   0
@@ -139,6 +123,22 @@ section_table:
 IMAGE_SCN_MEM_READ | \
 IMAGE_SCN_CNT_INITIALIZED_DATA)
 
+   .ascii  ".reloc"
+   .byte   0
+   .byte   0   /* end of 0 padding of section name */
+   .long   _relo_size  /* VirtualSize */
+   .long   _relo - ImageBase   /* VirtualAddress */
+   .long   _relo_size  /* SizeOfRawData */
+   .long   _relo - ImageBase   /* PointerToRawData */
+   .long   0   /* PointerToRelocations */
+   .long   0   /* PointerToLineNumbers */
+   .short  0   /* NumberOfRelocations */
+   .short  0   /* NumberOfLineNumbers */
+   /* Characteristics (section flags) */
+   .long   (IMAGE_SCN_MEM_READ | \
+IMAGE_SCN_MEM_DISCARDABLE | \
+IMAGE_SCN_CNT_INITIALIZED_DATA)
+
.align  12
 _start:
stp x29, x30, [sp, #-32]!
diff --git a/arch/arm/lib/elf_aarch64_efi.lds b/arch/arm/lib/elf_aarch64_efi.lds
index 3e3da47d6a..1ec2e7fec8 100644
--- a/arch/arm/lib/elf_aarch64_efi.lds
+++ b/arch/arm/lib/elf_aarch64_efi.lds
@@ -57,10 +57,13 @@ SECTIONS
_edata = .;
} :data
_data_size = _edata - _data;
-   .rela.dyn : { *(.rela.dyn) }
-   .rela.plt : { *(.rela.plt) }
-   .rela.got : { *(.rela.got) }
-   .rela.data : { *(.rela.data) *(.rela.data*) }
+   . = ALIGN(4096);
+   .reloc : {
+   _relo = .;
+   *(.rela*)
+   _erelo = .;
+   }
+   _relo_size = _erelo - _relo;
 
. = ALIGN(4096);
.dynsym   : { *(.dynsym) }
-- 
2.37.2



Re: [PATCH 1/1] doc: building documentation

2023-01-08 Thread Tom Rini
On Sat, Jan 07, 2023 at 07:37:03PM -0700, Simon Glass wrote:
> Hi Heinrich,
> 
> On Sat, 7 Jan 2023 at 17:11, Heinrich Schuchardt
>  wrote:
> >
> >
> >
> > On 1/7/23 23:54, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Sat, 7 Jan 2023 at 15:16, Heinrich Schuchardt
> > >  wrote:
> > >>
> > >>
> > >>
> > >> On 1/7/23 19:55, Simon Glass wrote:
> > >>> Hi Heinrich,
> > >>>
> > >>> On Fri, 30 Dec 2022 at 12:08, Heinrich Schuchardt
> > >>>  wrote:
> > 
> > 
> > 
> >  On 12/30/22 20:02, Simon Glass wrote:
> > > Hi,
> > >
> > > On Fri, 30 Dec 2022 at 12:31, Heinrich Schuchardt
> > >  wrote:
> > >>
> > >>
> > >>
> > >> On 12/30/22 19:12, Tom Rini wrote:
> > >>> On Fri, Dec 30, 2022 at 11:51:15AM -0600, Simon Glass wrote:
> >  Hi Heinrich,
> > 
> >  On Thu, 29 Dec 2022 at 22:08, Heinrich Schuchardt
> >   wrote:
> > >
> > > Provide a man-page describing how to build the U-Boot 
> > > documentation.
> > >
> > > Signed-off-by: Heinrich Schuchardt 
> > > 
> > > ---
> > >  doc/build/documentation.rst | 90 
> > > +
> > >  doc/build/index.rst |  1 +
> > >  2 files changed, 91 insertions(+)
> > >  create mode 100644 doc/build/documentation.rst
> > >
> > > diff --git a/doc/build/documentation.rst 
> > > b/doc/build/documentation.rst
> > > new file mode 100644
> > > index 00..896264dd7c
> > > --- /dev/null
> > > +++ b/doc/build/documentation.rst
> > > @@ -0,0 +1,90 @@
> > > +.. SPDX-License-Identifier: GPL-2.0+:
> > > +
> > > +Building documentation
> > > +==
> > > +
> > > +The U-Boot documentation is based on the Sphinx documentation 
> > > generator.
> > > +
> > > +HTML documentation
> > > +--
> > > +
> > > +The *htmldocs* target is used to build the HTML documentation. 
> > > It uses the
> > > +`Read the Docs Sphinx theme 
> > > `_.
> > > +
> > > +.. code-block:: bash
> > > +
> > > +# Create Python environment 'myenv'
> > > +python3 -m venv myenv
> > > +# Activate the Python environment
> > > +. myenv/bin/activate
> > > +# Install build requirements
> > > +python3 -m pip install -r doc/sphinx/requirements.txt
> > > +# Build the documentation
> > > +make htmldocs
> > > +# Deactivate the Python environment
> > > +deactivate
> > > +# Display the documentation in a graphical web browser
> > > +x-www-browser doc/output/index.html
> > 
> >  If this is necessary then it is a bit of a sad indictment on 
> >  Python. I
> >  would use:
> > 
> >  pip3 install -r doc/sphinx/requirements.txt
> >  make htmldocs
> > >>>
> > >>> Which part, exactly? Using a virtual environment is I believe a 
> > >>> normal
> > >>> best practice and "python3 -m pip" rather than "pip3" I assume is
> > >>> another best practice for portability. Then maybe the final step 
> > >>> should
> > >>> say "Review" not "Display" ?
> > >>>
> > >>
> > >> Review only applies to documentation developers.
> > >> Normal users just want to read the documentation.
> > >
> > > Using a virtual environment seems annoying to me. Should we put that
> > > in a separate section for those who want to do it?
> > 
> >  Current Ubuntu packages are incompatible with the readthedocs theme.
> >  Therefore I describe a way of building that works for most users.
> > >>>
> > >>> OK I see. Somehow it builds OK for me on 22.04 but I have not tried
> > >>> newer versions.
> > >>
> > >> make htmldocs builds but the formatting of the HTML does not conform to
> > >> the readthedocs style. Just open the documentation in a browser.
> > >
> > > It looks OK for me...what should I be seeing?
> >
> > This is the output without Python environment:
> > https://gist.github.com/xypron/aef88822a1f2f34e29faf5302313de6a
> >
> > This is what it should look like:
> > https://u-boot.readthedocs.io/en/latest/
> 
> Strangely, for me, it looks like the second thing even without the
> environment. I have seen the first one though, but not for a while.I
> vaguely remember installing some style package?

See, stuff like this is why the virtualenv is the default and a python
best practice. You don't have to guess why things randomly look
different than expected (or even more fun, unexpectedly work) because
everyone is on the same environment. Skipping virtualenv is a user
beware kind of thing and not what we want 

Re: [PATCH v9 14/14] treewide: Disable USE_SPL_FIT_GENERATOR by default

2023-01-08 Thread Tom Rini
On Sat, Jan 07, 2023 at 02:07:21PM -0700, Simon Glass wrote:

> This option is deprecated and only used by two boards. Enable it for just
> those two boards, so others don't accidentally enable it.
> 
> Signed-off-by: Simon Glass 
[snip]
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 55f06761ef8..7ab0dd14211 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -282,12 +282,13 @@ config SPL_FIT_SOURCE
>  config USE_SPL_FIT_GENERATOR
>   bool "Use a script to generate the .its script"
>   depends on SPL_FIT
> - default y if SPL_FIT && ARCH_ZYNQMP
> + help
> +   This is deprecated. Please do not use it. Use binman instead.

Lets remove the text around bool so it can't be enabled, and move to
select'ing it from the two boards that need it. Michal, Luca, what's
needed to move your two platforms
(avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0 and xilinx_zynqmp_virt off
of this very legacy option, given that other xilinx platforms have
already migrated to binman ?

-- 
Tom


signature.asc
Description: PGP signature


Status of dma-range issues with BCM2711

2023-01-08 Thread Stefan Wahren

Hi,

there has been some attempts to fix the booting issues of newer 
Raspberry Pi 4 (BCM2711 C0) [1] [2]. Since none of them has been applied 
yet, i wanted to know the status of this?


Best regards

[1] - https://lists.denx.de/pipermail/u-boot/2022-August/491455.html
[2] - https://marc.info/?l=u-boot=166678304628542=2



Pull request for u-boot-nand-20230108

2023-01-08 Thread Dario Binacchi
Hi Tom,

The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a:

  Merge branch '2023-01-02-platform-updates' into next (2023-01-02
18:07:41 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
tags/u-boot-nand-20230108

for you to fetch changes up to 7363cf0581a3e70b3dbd346dec8b7ae652776f80:

  mtd: rawnand: omap_elm: u-boot driver model support (2023-01-08
10:38:50 +0100)

Gitlab CI showed no issues:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14646


Pull request for u-boot-nand-20230108

- rawnand: omap_gpmc: driver model support


Roger Quadros (8):
  mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
  mtd: rawnand: nand_base: Allow base driver to be used in SPL
without nand_bbt
  dt-bindings: mtd: Add ti, gpmc-nand DT binding documentation
  mtd: rawnand: omap_gpmc: support u-boot driver model
  mtd: rawnand: omap_gpmc: Add SPL NAND support
  mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
  dt-bindings: mtd: Add ti, elm DT binding documentation
  mtd: rawnand: omap_elm: u-boot driver model support

 doc/device-tree-bindings/mtd/ti,elm.yaml   |  72
+
 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml | 129
++
 drivers/mtd/nand/raw/Kconfig   |   9 ++-
 drivers/mtd/nand/raw/Makefile  |   2 +-
 drivers/mtd/nand/raw/nand_base.c   |  18 +-
 drivers/mtd/nand/raw/omap_elm.c|  38 +++-
 {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h |   6 ++
 drivers/mtd/nand/raw/omap_gpmc.c   | 441
++---
 8 files changed, 607 insertions(+), 108 deletions(-)
 create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
 create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
 rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)

-- 
Dario Binacchi

Senior Embedded Linux Developer

dario.binac...@amarulasolutions.com

__


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
i...@amarulasolutions.com

www.amarulasolutions.com


Re: [PATCH v2 1/2] wandboard: Pass mmc aliases

2023-01-08 Thread Fabio Estevam
Hi Tom,

On Tue, Jan 3, 2023 at 8:00 AM Fabio Estevam  wrote:
>
> Hi Tom and Stefano,
>
> On Fri, Nov 4, 2022 at 8:13 AM Fabio Estevam  wrote:
> >
> > From: Fabio Estevam 
> >
> > Originally, the mmc aliases node was present in imx6qdl-wandboard.dtsi.
> >
> > After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
> > synchronise device trees with linux"), the aliases node is gone as
> > the upstream version does not have it.
> >
> > This causes a regression in which the SD card cannot be found anymore:
> >
> > Since commit  the aliases node has been removed
> > U-Boot 2022.10-00999-gcca41ed3d63f-dirty (Nov 03 2022 - 22:07:38 -0300)
> >
> > CPU:   Freescale i.MX6QP rev1.0 at 792 MHz
> > Reset cause: POR
> > DRAM:  2 GiB
> > Core:  62 devices, 17 uclasses, devicetree: separate
> > PMIC:  PFUZE100 ID=0x10
> > MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... MMC: no card present
> > *** Warning - No block device, using default environment
> >
> > Fix it by passing the alias node in the u-boot.dtsi file to
> > restore the original behaviour where the SD card (esdhc3) was
> > mapped to mmc0.
> >
> > Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with linux")
> > Signed-off-by: Fabio Estevam 
> > ---
> > Changes since v1:
> > - Add patch numbering.
>
> Please consider applying this one to 2023.01 to fix the boot regression.

Could you please apply this one directly to 2023.01 to fix the boot regression?

Thanks


Re: [PATCH v2 48/71] bootstd: Support reading the device tree with EFI

2023-01-08 Thread Mark Kettenis
> From: Simon Glass 
> Date: Sat,  7 Jan 2023 19:50:24 -0700
> 
> With EFI booting the device tree is required but is not actually specified
> in any way. The normal method is to use a fdtfile environment variable to
> get the filename, then look for that file on the media.
> 
> Implement this in the bootmeth.
> 
> Signed-off-by: Simon Glass 
> ---

Hi Simon,

The distroboot scripts also reads dtb files from the root directory of
the ESP (so without the "dtb/" prefix).  This code needs to do that as
well otherwise some folks will run with a different device tree after
switching to bootstd.

The construction of a fallback dtb filename based on soc, board and
boardver is only done for (32-bit) arm and not for arm64.  It isn't
done for riscv either.  That feels to me like someone recognized that
was a bit of a mistake and shouldn't be done for modern targets.  So I
think that code should be under the same

   #if defined(CONFIG_ARM) && !defined(CONFIG_ARM64)

as it is now in config_distro_bootcmd.h.

Cheers,

Mark

> (no changes since v1)
> 
>  boot/bootmeth_efi.c | 105 +---
>  1 file changed, 99 insertions(+), 6 deletions(-)
> 
> diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
> index 77b4ba22470..53a0489b93c 100644
> --- a/boot/bootmeth_efi.c
> +++ b/boot/bootmeth_efi.c
> @@ -143,10 +143,32 @@ static int distro_efi_check(struct udevice *dev, struct 
> bootflow_iter *iter)
>   return 0;
>  }
>  
> +static void distro_efi_get_fdt_name(char *fname, int size)
> +{
> + const char *fdt_fname;
> +
> + fdt_fname = env_get("fdtfile");
> + if (fdt_fname) {
> + snprintf(fname, size, "dtb/%s", fdt_fname);
> + log_debug("Using device tree: %s\n", fname);
> + } else {
> + const char *soc = env_get("soc");
> + const char *board = env_get("board");
> + const char *boardver = env_get("boardver");
> +
> + /* cf the code in label_boot() which seems very complex */
> + snprintf(fname, size, "dtb/%s%s%s%s.dtb",
> +  soc ? soc : "", soc ? "-" : "", board ? board : "",
> +  boardver ? boardver : "");
> + log_debug("Using default device tree: %s\n", fname);
> + }
> +}
> +
>  static int distro_efi_read_bootflow_file(struct udevice *dev,
>struct bootflow *bflow)
>  {
>   struct blk_desc *desc = NULL;
> + ulong fdt_addr, size;
>   char fname[256];
>   int ret;
>  
> @@ -170,15 +192,43 @@ static int distro_efi_read_bootflow_file(struct udevice 
> *dev,
>   if (ret)
>   return log_msg_ret("read", -EINVAL);
>  
> + distro_efi_get_fdt_name(fname, sizeof(fname));
> + bflow->fdt_fname = strdup(fname);
> + if (!bflow->fdt_fname)
> + return log_msg_ret("fil", -ENOMEM);
> +
> + fdt_addr = env_get_hex("fdt_addr_r", 0);
> + ret = bootmeth_common_read_file(dev, bflow, fname, fdt_addr, );
> + if (!ret) {
> + bflow->fdt_size = size;
> + bflow->fdt_addr = fdt_addr;
> +
> + /*
> +  * TODO: Apply extension overlay
> +  *
> +  * Here we need to load and apply the extension overlay. This is
> +  * not implemented. See do_extension_apply(). The extension
> +  * stuff needs an implementation in boot/extension.c so it is
> +  * separate from the command code. Really the extension stuff
> +  * should use the device tree and a uclass / driver interface
> +  * rather than implementing its own list
> +  */
> + } else {
> + log_debug("No device tree available\n");
> + }
> +
>   return 0;
>  }
>  
>  static int distro_efi_read_bootflow_net(struct bootflow *bflow)
>  {
> - const char *addr_str;
> + char file_addr[17], fname[256];
> + char *tftp_argv[] = {"tftp", file_addr, fname, NULL};
> + struct cmd_tbl cmdtp = {};  /* dummy */
> + const char *addr_str, *fdt_addr_str;
>   int ret, arch, size;
> + ulong addr, fdt_addr;
>   char str[36];
> - ulong addr;
>  
>   ret = get_efi_pxe_vci(str, sizeof(str));
>   if (ret)
> @@ -216,6 +266,25 @@ static int distro_efi_read_bootflow_net(struct bootflow 
> *bflow)
>   efi_set_bootdev("Net", "", bflow->fname, map_sysmem(addr, 0),
>   bflow->size);
>  
> + /* read the DT file also */
> + fdt_addr_str = env_get("fdt_addr_r");
> + if (!fdt_addr_str)
> + return log_msg_ret("fdt", -EINVAL);
> + fdt_addr = hextoul(fdt_addr_str, NULL);
> + sprintf(file_addr, "%lx", fdt_addr);
> +
> + distro_efi_get_fdt_name(fname, sizeof(fname));
> + bflow->fdt_fname = strdup(fname);
> + if (!bflow->fdt_fname)
> + return log_msg_ret("fil", -ENOMEM);
> +
> + if (!do_tftpb(, 0, 3, tftp_argv)) {
> + bflow->fdt_size = 

[PATCH] doc: fix references to distro documentation

2023-01-08 Thread Dario Binacchi
Commit 37c5195dfcd157 ("doc: Move distro boot doc to rST") renamed
doc/README.distro to doc/develop/distro.rst.

Signed-off-by: Dario Binacchi 
---

 doc/README.gpt   | 2 +-
 doc/README.uniphier  | 2 +-
 doc/board/emulation/qemu-x86.rst | 2 +-
 doc/board/st/stm32mp1.rst| 2 +-
 doc/board/tbs/tbs2910.rst| 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/README.gpt b/doc/README.gpt
index 91e397d06f88..394cea0aa875 100644
--- a/doc/README.gpt
+++ b/doc/README.gpt
@@ -177,7 +177,7 @@ To restore GUID partition table one needs to:
  "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;name=rootfs,size=0"
It can be used to locate bootable disks with command
"part list   -bootable ",
-   please check out doc/README.distro for use.
+   please check out doc/develop/distro.rst for use.
 
 2. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT'
 
diff --git a/doc/README.uniphier b/doc/README.uniphier
index badfacd66aa5..af746f6c316e 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -336,7 +336,7 @@ Deployment for Distro Boot
 --
 
 UniPhier SoC family boot the kernel in a generic manner as described in
-doc/README.distro .
+doc/develop/distro.rst.
 
 To boot the kernel, you need to deploy necesssary components to a file
 system on one of your block devices (eMMC, NAND, USB drive, etc.).
diff --git a/doc/board/emulation/qemu-x86.rst b/doc/board/emulation/qemu-x86.rst
index db842f2ece6e..e605ae3ab32e 100644
--- a/doc/board/emulation/qemu-x86.rst
+++ b/doc/board/emulation/qemu-x86.rst
@@ -57,7 +57,7 @@ to instantiate. Note, the maximum supported CPU number in 
QEMU is 255.
 U-Boot uses 'distro_bootcmd' by default when booting on x86 QEMU. This tries to
 load a boot script, kernel, and ramdisk from several different interfaces. For
 the default boot order, see 'qemu-x86.h'. For more information, see
-'README.distro'. Most Linux distros can be booted by writing a uboot script.
+'distro.rst'. Most Linux distros can be booted by writing a uboot script.
 For example, Debian (stretch) can be booted by creating a script file named
 'boot.txt' with the contents::
 
diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
index 3759df353ee5..0dcc6b783b89 100644
--- a/doc/board/st/stm32mp1.rst
+++ b/doc/board/st/stm32mp1.rst
@@ -478,7 +478,7 @@ or:
   
+---++-+++
 
 And the 4th partition (Rootfs) is marked bootable with a file extlinux.conf
-following the Generic Distribution feature (doc/README.distro for use).
+following the Generic Distribution feature (doc/develop/distro.rst for use).
 
 The size of fip or ssbl partition must be enough for the associated binary 
file,
 4MB and 2MB are default values.
diff --git a/doc/board/tbs/tbs2910.rst b/doc/board/tbs/tbs2910.rst
index e97f2b6e6135..4760922a93e6 100644
--- a/doc/board/tbs/tbs2910.rst
+++ b/doc/board/tbs/tbs2910.rst
@@ -181,7 +181,7 @@ If that fails it will then try to boot from several 
interfaces using
 'distro_bootcmd': It will first try to boot from the microSD slot, then the
 SD slot, then the internal eMMC, then the SATA interface and finally the USB
 interface. For more information on how to configure your distribution to boot,
-see 'README.distro'.
+see 'distro.rst'.
 
 Links:
 --
-- 
2.32.0



Re: Pull request for u-boot-nand-20230104

2023-01-08 Thread Roger Quadros



On 07/01/2023 20:46, Dario Binacchi wrote:
> Hi,
> 
> On Sat, Jan 7, 2023 at 7:36 PM Tom Rini  wrote:
>>
>> On Sat, Jan 07, 2023 at 07:32:51PM +0100, Dario Binacchi wrote:
>>> Hi,
>>>
>>> On Sat, Jan 7, 2023 at 6:30 PM Tom Rini  wrote:

 On Sat, Jan 07, 2023 at 04:48:02PM +0200, Roger Quadros wrote:

>
> On 07/01/2023 16:19, Roger Quadros wrote:
>> Hi,
>>
>> On 06/01/2023 20:59, Tom Rini wrote:
>>> On Thu, Jan 05, 2023 at 09:10:55AM +0100, Dario Binacchi wrote:
>>>
 Hi Tom,

 The following changes since commit 
 a95410696d21d38b629c61a09c100197c5fc533a:

   Merge branch '2023-01-02-platform-updates' into next (2023-01-02
 18:07:41 -0500)

 are available in the Git repository at:

   https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
 tags/u-boot-nand-20230104

 for you to fetch changes up to 
 48f219cb16f88cd2e392e2f438409a00d3ddff54:

   mtd: rawnand: omap_elm: u-boot driver model support (2023-01-04
 17:24:30 +0100)

 Gitlab CI showed no issues:
 https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14597

>>>
>>> NAK. This commit:
>>> commit 48f219cb16f88cd2e392e2f438409a00d3ddff54
>>> Author: Roger Quadros 
>>> Date:   Tue Dec 20 12:22:03 2022 +0200
>>>
>>> mtd: rawnand: omap_elm: u-boot driver model support
>>>
>>> Support u-boot driver model. We still retain
>>> support legacy way of doing things if ELM_BASE
>>> is defined in 
>>>
>>> We could completely get rid of that if all
>>> platforms defining ELM_BASE get rid of that definition
>>> and enable CONFIG_SYS_NAND_SELF_INIT and are verified
>>> to work.
>>>
>>> Signed-off-by: Roger Quadros 
>>> Signed-off-by: Michael Trimarchi 
>>>
>>> Breaks am335x_evm thusly:
>>> U-Boot SPL 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 
>>> 13:56:52 -0500)
>>> Trying to boot from MMC1
>>>
>>>
>>> U-Boot 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 
>>> -0500)
>>>
>>> CPU  : AM335X-GP rev 2.1
>>> Model: TI AM335x EVM
>>> DRAM:  1 GiB
>>> Error binding driver 'omap-elm': -96
>>> Some drivers failed to bind
>>> Error binding driver 'ti_sysc': -96
>>> Some drivers failed to bind
>>> Error binding driver 'simple_bus': -96
>>> Some drivers failed to bind
>>> Error binding driver 'simple_bus': -96
>>> Some drivers failed to bind
>>> Error binding driver 'simple_bus': -96
>>> Some drivers failed to bind
>>> initcall sequence bffdbbe0 failed at call 808155a9 (err=-96)
>>> ### ERROR ### Please RESET the board ###
>>>
>>
>> Sorry about that. My broken am335x-evm has suddenly come alive.
>> I will come up with a fix in a day or two.
>
> The below patch fixes boot on am335x-evm for me.
>
> Does it look reasonable?
>
> From 06e2695f8420a1fa6eaf3fcf2e5dbbf28c73a34d Mon Sep 17 00:00:00 2001
> From: Roger Quadros 
> Date: Sat, 7 Jan 2023 16:40:52 +0200
> Subject: [PATCH] mtd: rawnand: omap_elm: Fix boot on am335x-evm
>
> Prevent registering with Driver Model if CONFIG_SYS_NAND_SELF_INIT
> is not enabled.
>
> Legacy OMAP2+ systems do not use driver model yet for
> NAND/ELM and don't define CONFIG_SYS_NAND_SELF_INIT.
>
> Signed-off-by: Roger Quadros 

 Reviewed-by: Tom Rini 
>>>
>>> If Roger will submit this patch (I still don't see it with patchwork), 
>>> tomorrow
>>> I will add to the other patches, I will run the tests and in case of success
>>> I will submit a new pull-request.
>>> Is this, Tom, the correct workflow?
>>
>> Patchwork likely doesn't like a patch in reply to a pull request, and
>> I'd assume this should get folded in to the patch in question, to
>> prevent breaking bisectability.
> 
> Ok, I will add the changes to the "mtd: rawnand: omap_elm: u-boot
> driver model support" patch,
> and after the tests I will submit another pull-request.
> 
> Thanks and regards,
> Dario

Thank you Dario and Tom.

cheers,
-roger