[PATCH v2] spl: bootstage: move bootstage_stash before jumping to image

[Chanho Park]

Regarding IH_OS_OPENSBI, IH_OS_LINUX and IH_OS_TEE, there is no chance
to stash bootstage record because they do not return to SPL after
jumping to the image.
Hence, this patch separates the final stage bootstage code into
spl_bootstage_finish and call the function before jumping to the image.

Signed-off-by: Chanho Park 
---
Changes from v1
- Separate the final stage bootstage code into spl_bootstage_finish.
- As Simon suggests, call the function before jumping to the image.

 common/spl/spl.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0062f3f45d9a..eaf2f076ddd1 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -738,6 +738,19 @@ void board_init_f(ulong dummy)
 }
 #endif
 
+static void spl_bootstage_finish(void)
+{
+   int ret;
+
+   bootstage_mark_name(get_bootstage_id(false), "end phase");
+#ifdef CONFIG_BOOTSTAGE_STASH
+   ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
+ CONFIG_BOOTSTAGE_STASH_SIZE);
+   if (ret)
+   debug("Failed to stash bootstage: err=%d\n", ret);
+#endif
+}
+
 void board_init_r(gd_t *dummy1, ulong dummy2)
 {
u32 spl_boot_list[] = {
@@ -865,12 +878,14 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
case IH_OS_TEE:
debug("Jumping to U-Boot via OP-TEE\n");
spl_board_prepare_for_optee(spl_image.fdt_addr);
+   spl_bootstage_finish();
jump_to_image_optee(_image);
break;
 #endif
 #if CONFIG_IS_ENABLED(OPENSBI)
case IH_OS_OPENSBI:
debug("Jumping to U-Boot via RISC-V OpenSBI\n");
+   spl_bootstage_finish();
spl_invoke_opensbi(_image);
break;
 #endif
@@ -881,6 +896,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_fixup_fdt((void *)CONFIG_SYS_SPL_ARGS_ADDR);
 #endif
spl_board_prepare_for_linux();
+   spl_bootstage_finish();
jump_to_image_linux(_image);
 #endif
default:
@@ -890,13 +906,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
debug("SPL malloc() used 0x%lx bytes (%ld KB)\n", gd->malloc_ptr,
  gd->malloc_ptr / 1024);
 #endif
-   bootstage_mark_name(get_bootstage_id(false), "end phase");
-#ifdef CONFIG_BOOTSTAGE_STASH
-   ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
- CONFIG_BOOTSTAGE_STASH_SIZE);
-   if (ret)
-   debug("Failed to stash bootstage: err=%d\n", ret);
-#endif
+   spl_bootstage_finish();
 
if (IS_ENABLED(CONFIG_SPL_VIDEO_REMOVE)) {
struct udevice *dev;
-- 
2.39.2

[PATCH] spi: cadence_qspi: Select flash subnode at runtime

[Udit Kumar]

Currently spi driver gets flash parameter from first subnode.

Few boards have more than one flash with different parameters
and selection of flash is done by on board switch settings.
In such case, uboot needs to be recompiled with updated
device tree to align with board switch settings.

This patch allows to select flash node at runtime.

Boards those are supporting multiple flashes
needs to implement cadence_qspi_get_subnode function and return correct
flash node.

Cc: Apurva Nandan 
Signed-off-by: Udit Kumar 
---
One of such platform is J721S2 EVM
link https://www.ti.com/lit/pdf/spruj67
Fig 3.1, Page 18 has details of two flashes connected with
one controller.

 drivers/spi/cadence_qspi.c | 7 ++-
 drivers/spi/cadence_qspi.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index cc3a54f295..7a02ceed10 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -40,6 +40,11 @@ __weak int cadence_qspi_versal_flash_reset(struct udevice 
*dev)
return 0;
 }
 
+__weak ofnode  cadence_qspi_get_subnode(struct udevice *dev)
+{
+   return dev_read_first_subnode(dev);
+}
+
 static int cadence_spi_write_speed(struct udevice *bus, uint hz)
 {
struct cadence_spi_priv *priv = dev_get_priv(bus);
@@ -401,7 +406,7 @@ static int cadence_spi_of_to_plat(struct udevice *bus)
plat->is_dma = dev_read_bool(bus, "cdns,is-dma");
 
/* All other parameters are embedded in the child node */
-   subnode = dev_read_first_subnode(bus);
+   subnode = cadence_qspi_get_subnode(bus);
if (!ofnode_valid(subnode)) {
printf("Error: subnode with SPI flash config missing!\n");
return -ENODEV;
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 1c59d1a9d9..12825f8911 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -304,6 +304,7 @@ int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv,
 int cadence_qspi_apb_wait_for_dma_cmplt(struct cadence_spi_priv *priv);
 int cadence_qspi_apb_exec_flash_cmd(void *reg_base, unsigned int reg);
 int cadence_qspi_versal_flash_reset(struct udevice *dev);
+ofnode cadence_qspi_get_subnode(struct udevice *dev);
 void cadence_qspi_apb_enable_linear_mode(bool enable);
 
 #endif /* __CADENCE_QSPI_H__ */
-- 
2.34.1

RE: [PATCH] spl: bootstage: move bootstage_stash before jumping to image

[Chanho Park]

Hi Simon,

> -Original Message-
> From: Simon Glass 
> Sent: Tuesday, August 29, 2023 2:55 AM
> To: Chanho Park 
> Cc: Nikhil M Jain ; Marek Vasut ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] spl: bootstage: move bootstage_stash before jumping
> to image
> 
> Hi Chanho,
> 
> On Mon, 28 Aug 2023 at 03:46, Chanho Park 
> wrote:
> >
> > For IH_OS_OPENSBI and IH_OS_LINUX, there is no chance to stash
> > bootstare record because it will not return after jumping to the image.
> > Hence, this patch moves the location of bootstage_stash before jumping
> > to image.
> >
> 
> Please fix your implementation instead. You must jump to the OS at the end
> of this function and not before.

In case of OS_TEE/OPENSBI/LINUX images, they will not be returned to SPL so 
they can't get a chance to stash boot stage records.

> 
> In fact I have a patch to move bootstage later in this function!

Will you post the patch soon? Or it was already posted?

Best Regards,
Chanho Park

[PATCH] spl: add __noreturn attribute to spl_invoke_opensbi function

[Chanho Park]

spl_invoke_opensbi function is not returned to SPL. Thus, we need to
set __noreturn function attribute.

Signed-off-by: Chanho Park 
---
 common/spl/spl_opensbi.c | 7 ---
 include/spl.h| 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index b0f40076c345..e2aaa460468c 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -43,11 +43,12 @@ static int spl_opensbi_find_uboot_node(void *blob, int 
*uboot_node)
return -ENODEV;
 }
 
-void spl_invoke_opensbi(struct spl_image_info *spl_image)
+void __noreturn spl_invoke_opensbi(struct spl_image_info *spl_image)
 {
int ret, uboot_node;
ulong uboot_entry;
-   void (*opensbi_entry)(ulong hartid, ulong dtb, ulong info);
+   typedef void __noreturn (*opensbi_entry_t)(ulong hartid, ulong dtb, 
ulong info);
+   opensbi_entry_t opensbi_entry;
 
if (!spl_image->fdt_addr) {
pr_err("No device tree specified in SPL image\n");
@@ -74,7 +75,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
opensbi_info.options = CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS;
opensbi_info.boot_hart = gd->arch.boot_hart;
 
-   opensbi_entry = (void (*)(ulong, ulong, ulong))spl_image->entry_point;
+   opensbi_entry = (opensbi_entry_t)spl_image->entry_point;
invalidate_icache_all();
 
 #ifdef CONFIG_SPL_SMP
diff --git a/include/spl.h b/include/spl.h
index 92bcaa90a4af..93e906431e7d 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -862,7 +862,7 @@ void __noreturn spl_optee_entry(void *arg0, void *arg1, 
void *arg2, void *arg3);
 /**
  * spl_invoke_opensbi - boot using a RISC-V OpenSBI image
  */
-void spl_invoke_opensbi(struct spl_image_info *spl_image);
+void __noreturn spl_invoke_opensbi(struct spl_image_info *spl_image);
 
 /**
  * board_return_to_bootrom - allow for boards to continue with the boot ROM
-- 
2.39.2

RE: [PATCH RESEND v3] fpga: add inline stub for fpga_load

[Chanho Park]

Hi Eugen,

> -Original Message-
> From: Eugen Hristev 
> Sent: Monday, August 28, 2023 8:47 PM
> To: Michal Simek ; u-boot@lists.denx.de;
> s...@chromium.org; Chanho Park 
> Subject: Re: [PATCH RESEND v3] fpga: add inline stub for fpga_load
> 
> On 8/28/23 13:53, Michal Simek wrote:
> > Hi Eugen, + Chanho,
> >
> > On 8/8/23 12:22, Eugen Hristev wrote:
> >> In case CC_OPTIMIZE_FOR_DEBUG is set, unused code will not be
> >> optimized out, hence the reference to fpga_load will be compiled.
> >> if DM_FPGA and SPL_FPGA are not set, the build will fail with :
> >
> > this is not correct. It is not DM_FPGA but only FPGA.
> >
> >
> >>
> >> aarch64-none-linux-gnu-ld.bfd: common/spl/spl_fit.o: in function
> >> `spl_fit_upload_fpga':
> >> u-boot/common/spl/spl_fit.c:595: undefined reference to `fpga_load'
> >>
> >> To solve this, added an inline empty stub in the header if
> >> CC_OPTIMIZE_FOR_DEBUG is set such that the build will succeed.
> >>
> >> Signed-off-by: Eugen Hristev 
> >> ---
> >> Changes in v3:
> >> - return -ENOSYS
> >> Changes in v2:
> >> - this is a rework as suggested by Simon of this previous patch :
> >> https://protect2.fireeye.com/v1/url?k=eed360f4-8f5875c2-eed2ebbb-74fe
> >> 485cbff1-6ddceb7720c8265c=1=f4039d69-e052-4de7-b3b0-f25e8f4581a3&
> >> u=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F2023
> >> 0619102839.277902-1-eugen.hristev%40collabora.com%2F
> >>
> >>   include/fpga.h | 9 +
> >>   1 file changed, 9 insertions(+)
> >>
> >> diff --git a/include/fpga.h b/include/fpga.h index
> >> ed688cc0fa3b..33d0dbbe2ba4 100644
> >> --- a/include/fpga.h
> >> +++ b/include/fpga.h
> >> @@ -60,8 +60,17 @@ int fpga_add(fpga_type devtype, void *desc);
> >>   int fpga_count(void);
> >>   const fpga_desc *const fpga_get_desc(int devnum);
> >>   int fpga_is_partial_data(int devnum, size_t img_len);
> >> +#if defined(CONFIG_CC_OPTIMIZE_FOR_DEBUG)
> >
> > And when you enable CONFIG_CC_OPTIMIZE_FOR_DEBUG and FPGA you get
> > compilation warnings.
> >
> > drivers/fpga/fpga.c:265:5: error: redefinition of 'fpga_load'
> >265 | int fpga_load(int devnum, const void *buf, size_t bsize,
> > bitstream_type bstype,
> >| ^
> > In file included from include/xilinx.h:7,
> >   from drivers/fpga/fpga.c:11:
> > include/fpga.h:64:19: note: previous definition of 'fpga_load' with
> > type 'int(int,  const void *, size_t,  bitstream_type,  int)' {aka
> > 'int(int, const void *, long unsigned int,  bitstream_type,  int)'}
> > 64 | static inline int fpga_load(int devnum, const void *buf,
> > size_t bsize,
> >|   ^
> > make[2]: *** [scripts/Makefile.build:257: drivers/fpga/fpga.o] Error 1
> >
> > I means please tune that condition properly not to create additional
> > compilation warnings for other combinations.
> >
> > Thanks,
> > Michal
> >
> 
> Hello Michal,
> 
> Thanks for reviewing .
> 
> Chanho, I cannot try this at the moment, if you are in a hurry you can
> send a v4 or v2 to your patch addressing this (or maybe your patch does
> not have this problem)

Sure. Actually, my patch does not have the problem.
Michal, could review my patch?

Best Regards,
Chanho Park

Re: [PATCH v4 2/8] doc: Add gpt command documentation

[Heinrich Schuchardt]

On 8/29/23 00:45, Heinrich Schuchardt wrote:

/On 8/28/23 23:56, Joshua Watt wrote:

Adds initial documentation for the gpt command

Signed-off-by: Joshua Watt 
---
  doc/usage/cmd/gpt.rst | 184 ++
  doc/usage/index.rst   |   1 +
  2 files changed, 185 insertions(+)
  create mode 100644 doc/usage/cmd/gpt.rst

diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
new file mode 100644
index 00..6387c8116f
--- /dev/null
+++ b/doc/usage/cmd/gpt.rst
@@ -0,0 +1,184 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+gpt command
+===
+
+Synopsis
+
+
+::
+
+    gpt enumerate  
+    gpt guid   []
+    gpt read   []
+    gpt rename
+    gpt repair  
+    gpt setenv   
+    gpt swap
+    gpt verify   []
+    gpt write   
+
+Description
+---
+
+The gpt command lets users read, create, modify, or verify the GPT (GUID
+Partition Table) partition layout.
+
+Common arguments:
+
+interface
+    interface for accessing the block device (mmc, sata, scsi, usb,
)
+
+dev
+    device number
+
+partition string
+    Describes the GPT partition layout for a disk.  The syntax is
similar to
+    the one used by the :doc:`mbr command ` command. The string
contains
+    one or more partition descriptors, each separated by a ";". Each
descriptor
+    contains one or more fields, with each field separated by a ",".
Fields are
+    either of the form "key=value" to set a specific value, or simple
"flag" to
+    set a boolean flag
+
+    The first descriptor can optionally be used to describe
parameters for the
+    whole disk with the following fields:
+
+    * uuid_disk=UUID - Set the UUID for the disk
+
+    Partition descriptors can have the following fields:
+
+    * name= - The partition name, required
+    * start= - The partition start offset in bytes, required


The code has this comment: "start address is optional".


+    * size= - The partition size in bytes or "-" to expand it
to the whole free area


This filed is mandatory.


+    * bootable - Set the legacy bootable flag


This field is optional


+    * uuid= - The partition UUID, optional if
CONFIG_RANDOM_UUID=y is enabled
+    * type= - The partition type GUID, requires
CONFIG_PARTITION_TYPE_GUID=y


This field is optional

Thanks for all the updates. Looks much neater now.

The sequence expected in set_gpt_info() is:

uuid (optional if CONFIG_RANDOM_UUID=y),
type (optional, only usable for CONFIG_PARTITION_TYPE_GUID=y),
name (mandatory),
size (mandatory),
start (optional),
bootable (optional).


A gross bug in the gpt command is that 'gpt read' creates a different
sequence than 'gpt write' needs.

Furthermore 'gpt read' does not write all fields needed by 'gpt write'
to recreate the partition table: bootable and type are missing.

Best regards

Heinrich



 From the description above it is not clear that:

* semicolons are used to separate partitions
* the exact sequence of fields must be kept
* commas are used to separate fields
* no extra white-space is allowed.


+
+
+    If 'uuid' is not specified, but CONFIG_RANDOM_UUID is enabled, a
random UUID
+    will be generated for the partition
+
+gpt enumerate
+~
+
+Sets the variable 'gpt_partition_list' to be a list of all the
partition names
+on the device.
+
+gpt guid
+
+
+Report the GUID of a disk. If 'varname' is specified, the command
will set the
+variable to the GUID, otherwise it will be printed out.
+
+gpt read
+
+
+Prints the current state of the GPT partition table. If 'varname' is
specified,
+the variable will be filled with a partition string in the same
format as a
+'', suitable for passing to other 'gpt' commands.
If the
+argument is omitted, a human readable description is printed out.
+CONFIG_CMD_GPT_RENAME=y is required.
+
+gpt rename
+~~
+
+Renames all partitions named 'part' to be 'name'.
CONFIG_CMD_GPT_RENAME=y is
+required.
+
+gpt repair
+~~
+
+Repairs the GPT partition tables if it they become corrupted.
+
+gpt setenv
+~~
+
+The 'gpt setenv' command will set a series of environment variables with
+information about the partition named ''. The
variables are:
+
+gpt_partition_addr
+    the starting offset of the partition in blocks as a hexadecimal
number
+
+gpt_partition_size
+    the size of the partition in blocks as a hexadecimal number
+
+gpt_partition_name
+    the name of the partition
+
+gpt_partition_entry
+    the partition number in the table, e.g. 1, 2, 3, etc.


Since eeef58401520 ("cmd: let gpt_partition_entry be hexadecimal") this
is a hexadecimal number. As partitions are not required to be numbered
start at 1:

%s/, e.g. 1, 2, 3, etc./as a hexadecimal number/


+
+gpt swap
+
+
+Changes the names of all partitions that are named 'name1' to be
'name2', and
+all partitions named 'name2' to be 'name1'. CONFIG_CMD_GPT_RENAME=y is
+required.
+
+gpt verify
+~~
+
+Sets return value $? to 0 (true) if the partition layout on the
+specified disk 

Re: [PATCH v4 5/8] cmd: gpt: Add command to set bootable flags

[Heinrich Schuchardt]

On 8/28/23 23:56, Joshua Watt wrote:

Adds a command that can be used to modify the GPT partition table to
indicate which partitions should have the bootable flag set

Signed-off-by: Joshua Watt 
---
  cmd/gpt.c | 80 +++
  doc/usage/cmd/gpt.rst | 12 ++
  test/py/tests/test_gpt.py | 22 +++
  3 files changed, 114 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index c6c8282ac9..45fbe07404 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -972,6 +972,81 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
free(partitions_list);
return ret;
  }
+
+/**
+ * gpt_set_bootable() - Set bootable flags for partitions
+ *
+ * Sets the bootable flag for any partition names in the comma separated list 
of
+ * partition names. Any partitions not in the list have their bootable flag
+ * cleared
+ *
+ * @desc: block device descriptor
+ * @name: Comma separated list of partition names
+ *
+ * @Return: '0' on success and -ve error on failure
+ */
+static int gpt_set_bootable(struct blk_desc *blk_dev_desc, char *const 
part_list)
+{
+   char *name;
+   char disk_guid[UUID_STR_LEN + 1];
+   struct list_head *pos;
+   struct disk_part *curr;
+   struct disk_partition *partitions = NULL;
+   int part_count = 0;
+   int ret = get_disk_guid(blk_dev_desc, disk_guid);
+
+   if (ret < 0)
+   return ret;
+
+   ret = get_gpt_info(blk_dev_desc);
+   if (ret <= 0)
+   goto out;
+
+   part_count = ret;
+   partitions = malloc(sizeof(*partitions) * part_count);
+   if (!partitions) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   /* Copy partitions and clear bootable flag */
+   part_count = 0;
+   list_for_each(pos, _partitions) {
+   curr = list_entry(pos, struct disk_part, list);
+   partitions[part_count] = curr->gpt_part_info;
+   partitions[part_count].bootable &= ~PART_BOOTABLE;
+   part_count++;
+   }
+
+   name = strtok(part_list, ",");
+   while (name) {
+   bool found = false;
+
+   for (int i = 0; i < part_count; i++) {
+   if (strcmp((char *)partitions[i].name, name) == 0) {
+   partitions[i].bootable |= PART_BOOTABLE;
+   found = true;
+   }
+   }
+
+   if (!found) {
+   printf("Warning: No partition matching '%s' found\n",
+  name);
+   }
+
+   name = strtok(NULL, ",");
+   }
+
+   ret = gpt_restore(blk_dev_desc, disk_guid, partitions, part_count);
+
+out:
+   del_gpt_info();
+
+   if (partitions)
+   free(partitions);
+
+   return ret;
+}
  #endif

  /**
@@ -1031,6 +1106,8 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
} else if ((strcmp(argv[1], "swap") == 0) ||
   (strcmp(argv[1], "rename") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4], 
argv[5]);
+   } else if ((strcmp(argv[1], "set-bootable") == 0)) {
+   ret = gpt_set_bootable(blk_dev_desc, argv[4]);
  #endif
} else {
return CMD_RET_USAGE;
@@ -1082,8 +1159,11 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
"  and vice-versa\n"
" gpt rename\n"
"- rename the specified partition\n"
+   " gpt set-bootable   \n"
+   "- make partition names in list bootable\n"
" Example usage:\n"
" gpt swap mmc 0 foo bar\n"
" gpt rename mmc 0 3 foo\n"
+   " gpt set-bootable mmc 0 boot_a,boot_b\n"
  #endif
  );
diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
index b505b159d0..288dd365c0 100644
--- a/doc/usage/cmd/gpt.rst
+++ b/doc/usage/cmd/gpt.rst
@@ -13,6 +13,7 @@ Synopsis
  gpt read   []
  gpt rename
  gpt repair  
+gpt set-bootable   
  gpt setenv   
  gpt swap
  gpt verify   []
@@ -90,6 +91,13 @@ gpt repair

  Repairs the GPT partition tables if it they become corrupted.

+gpt set-bootable
+
+
+Sets the bootable flag for all partitions in the table. If the partition name
+is in 'partition list' (separated by ','), the bootable flag is set, otherwise
+it is cleared. CONFIG_CMD_GPT_RENAME=y is required.


Why should this feature be related to CONFIG_CMD_GPT_RENAME?

Why do we need this sub-command? You can use gpt read and gpt write for
this rarely needed manipulation.

Best regards

Heinrich


+
  gpt setenv
  ~~

@@ -187,3 +195,7 @@ Get the GUID for a disk::
  => gpt guid mmc gpt_disk_uuid
  => echo ${gpt_disk_uuid}
  bec9fc2a-86c1-483d-8a0e-0109732277d7
+
+Set the bootable flag for the 'boot' partition and clear it for all others::
+
+=> gpt set-bootable mmc 0 boot
diff 

Re: [PATCH v4 2/8] doc: Add gpt command documentation

[Heinrich Schuchardt]

/On 8/28/23 23:56, Joshua Watt wrote:

Adds initial documentation for the gpt command

Signed-off-by: Joshua Watt 
---
  doc/usage/cmd/gpt.rst | 184 ++
  doc/usage/index.rst   |   1 +
  2 files changed, 185 insertions(+)
  create mode 100644 doc/usage/cmd/gpt.rst

diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
new file mode 100644
index 00..6387c8116f
--- /dev/null
+++ b/doc/usage/cmd/gpt.rst
@@ -0,0 +1,184 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+gpt command
+===
+
+Synopsis
+
+
+::
+
+gpt enumerate  
+gpt guid   []
+gpt read   []
+gpt rename
+gpt repair  
+gpt setenv   
+gpt swap
+gpt verify   []
+gpt write   
+
+Description
+---
+
+The gpt command lets users read, create, modify, or verify the GPT (GUID
+Partition Table) partition layout.
+
+Common arguments:
+
+interface
+interface for accessing the block device (mmc, sata, scsi, usb, )
+
+dev
+device number
+
+partition string
+Describes the GPT partition layout for a disk.  The syntax is similar to
+the one used by the :doc:`mbr command ` command. The string contains
+one or more partition descriptors, each separated by a ";". Each descriptor
+contains one or more fields, with each field separated by a ",". Fields are
+either of the form "key=value" to set a specific value, or simple "flag" to
+set a boolean flag
+
+The first descriptor can optionally be used to describe parameters for the
+whole disk with the following fields:
+
+* uuid_disk=UUID - Set the UUID for the disk
+
+Partition descriptors can have the following fields:
+
+* name= - The partition name, required
+* start= - The partition start offset in bytes, required


The code has this comment: "start address is optional".


+* size= - The partition size in bytes or "-" to expand it to the 
whole free area


This filed is mandatory.


+* bootable - Set the legacy bootable flag


This field is optional


+* uuid= - The partition UUID, optional if CONFIG_RANDOM_UUID=y is 
enabled
+* type= - The partition type GUID, requires 
CONFIG_PARTITION_TYPE_GUID=y


This field is optional

Thanks for all the updates. Looks much neater now.

The sequence expected in set_gpt_info() is:

uuid (optional if CONFIG_RANDOM_UUID=y),
type (optional, only usable for CONFIG_PARTITION_TYPE_GUID=y),
name (mandatory),
size (mandatory),
start (optional),
bootable (optional).

From the description above it is not clear that:

* semicolons are used to separate partitions
* the exact sequence of fields must be kept
* commas are used to separate fields
* no extra white-space is allowed.


+
+
+If 'uuid' is not specified, but CONFIG_RANDOM_UUID is enabled, a random 
UUID
+will be generated for the partition
+
+gpt enumerate
+~
+
+Sets the variable 'gpt_partition_list' to be a list of all the partition names
+on the device.
+
+gpt guid
+
+
+Report the GUID of a disk. If 'varname' is specified, the command will set the
+variable to the GUID, otherwise it will be printed out.
+
+gpt read
+
+
+Prints the current state of the GPT partition table. If 'varname' is specified,
+the variable will be filled with a partition string in the same format as a
+'', suitable for passing to other 'gpt' commands.  If the
+argument is omitted, a human readable description is printed out.
+CONFIG_CMD_GPT_RENAME=y is required.
+
+gpt rename
+~~
+
+Renames all partitions named 'part' to be 'name'. CONFIG_CMD_GPT_RENAME=y is
+required.
+
+gpt repair
+~~
+
+Repairs the GPT partition tables if it they become corrupted.
+
+gpt setenv
+~~
+
+The 'gpt setenv' command will set a series of environment variables with
+information about the partition named ''. The variables are:
+
+gpt_partition_addr
+the starting offset of the partition in blocks as a hexadecimal number
+
+gpt_partition_size
+the size of the partition in blocks as a hexadecimal number
+
+gpt_partition_name
+the name of the partition
+
+gpt_partition_entry
+the partition number in the table, e.g. 1, 2, 3, etc.


Since eeef58401520 ("cmd: let gpt_partition_entry be hexadecimal") this
is a hexadecimal number. As partitions are not required to be numbered
start at 1:

%s/, e.g. 1, 2, 3, etc./as a hexadecimal number/


+
+gpt swap
+
+
+Changes the names of all partitions that are named 'name1' to be 'name2', and
+all partitions named 'name2' to be 'name1'. CONFIG_CMD_GPT_RENAME=y is
+required.
+
+gpt verify
+~~
+
+Sets return value $? to 0 (true) if the partition layout on the
+specified disk matches the one in the provided partition string, and 1 (false)
+if it does not match. If no partition string is specified, the command will
+check if the disk is partitioned or not.
+
+gpt write
+~
+
+(Re)writes the partition table on the disk to match the provided
+partition string. It returns 0 on 

Re: [PATCH v1] board: toradex: verdin-imx8mp: enable usb device and fastboot support

[Fabio Estevam]

Hi Marcel,

On Mon, Aug 28, 2023 at 6:38 PM Marcel Ziswiler  wrote:
>
> From: Marcel Ziswiler 
>
> Enable USB device and fastboot support which may be used to load the
> Toradex Easy Installer FIT image.
>
> While at it also enable USB mass storage aka UMS support.
>
> Note that the i.MX 8M Plus recovery mode support is based on the USB
> boot stage of the BOOTROM and does NOT require USB SDP SPL aka serial
> downloader support.
>
> Signed-off-by: Marcel Ziswiler 

Reviewed-by: Fabio Estevam 

Re: [PATCH v1 1/2] verdin-am62: add u-boot update wrappers

[Marcel Ziswiler]

On Thu, 2023-08-24 at 16:42 +0200, Francesco Dolcini wrote:
> Hello Nishanth,
> 
> On Thu, Aug 24, 2023 at 07:10:57AM -0500, Nishanth Menon wrote:
> > On 13:19-20230824, Francesco Dolcini wrote:
> > > On Thu, Aug 24, 2023 at 10:08:49AM +0200, Emanuele Ghidoli wrote:
> > > > From: Emanuele Ghidoli 
> > > > 
> > > > Add update_tiboot3, update_tispl and update_uboot wrappers to update
> > > > R5 SPL, A53 SPL and A53 U-boot respectively.
> > > > 
> > > > Usage example:
> > > > > tftpboot ${loadaddr} tiboot3-am62x-gp-verdin.bin
> > > > > run update_tiboot3
> > > > 
> > > > > tftpboot ${loadaddr} tispl.bin
> > > > > run update_tispl
> > > > 
> > > > > tftpboot ${loadaddr} u-boot.img
> > > > > run update_uboot
> > > > 
> > > > Signed-off-by: Emanuele Ghidoli 
> > > 
> > > Acked-by: Francesco Dolcini 
> > 
> > Should you update documentation to indicate the usage?
> 
> Yeah, probably we could add it. I would not remove the existing direct
> command usage since this is adding just env variables that could be
> removed from the env even at runtime.
> 
> In general the reason for these commands is that our users are
> accustomed to have a "guided" way to update u-boot without having to dig
> into the documentation. They are just convenient.
> 
> Marcel: what do you think?

Sure, we took care of it here:

https://lore.kernel.org/all/20230828220154.483362-1-mar...@ziswiler.com

> Francesco

Cheers

Marcel

Re: [PATCH 1/1] bootstd: BOOTDEV_SPI_FLASH requires BOOTSTD

[Simon Glass]

On Mon, 28 Aug 2023 at 12:49, Heinrich Schuchardt
 wrote:
>
> Compiling sandbox_defconfig with CONFIG_BOOTSTD=n fails:
>
> /usr/bin/ld: drivers/mtd/spi/sf_bootdev.o:
> in function `sf_get_bootflow':
> /drivers/mtd/spi/sf_bootdev.c:43:(.text+0x96):
> undefined reference to `bootmeth_set_bootflow'
>
> Add the missing Kconfig dependency.
>
> Fixes: Fixes: 0c1f4a9fb13a ("bootstd: Add a SPI flash bootdev")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/mtd/spi/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Re: [PATCH v3 5/9] board: qualcomm: Add support for dragonboard845c

[Simon Glass]

Hi Peter,

On Mon, 28 Aug 2023 at 14:24, Peter Robinson  wrote:
>
> On Mon, Aug 28, 2023 at 6:55 PM Simon Glass  wrote:
> >
> > Hi Sumit,
> >
> > On Thu, 24 Aug 2023 at 04:44, Sumit Garg  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Thu, 24 Aug 2023 at 05:29, Simon Glass  wrote:
> > > >
> > > > Hi Sumit,
> > > >
> > > > On Tue, 12 Jul 2022 at 01:12, Sumit Garg  wrote:
> > > > >
> > > > > Add support for 96Boards Dragonboard 845C aka Robotics RB3 development
> > > > > platform. This board complies with 96Boards Open Platform 
> > > > > Specifications.
> > > > >
> > > > > Features:
> > > > > - Qualcomm Snapdragon SDA845 SoC
> > > > > - 4GiB RAM
> > > > > - 64GiB UFS drive
> > > > >
> > > > > U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> > > > > For detailed build and boot instructions, refer to
> > > > > doc/board/qualcomm/sdm845.rst, board: dragonboard845c.
> > > > >
> > > > > Signed-off-by: Sumit Garg 
> > > > > Reviewed-by: Ramon Fried 
> > > > > ---
> > > > >  arch/arm/dts/dragonboard845c-uboot.dtsi   |  37 +++
> > > > >  arch/arm/dts/dragonboard845c.dts  |  44 
> > > > >  arch/arm/mach-snapdragon/Kconfig  |  14 +++
> > > > >  board/qualcomm/dragonboard845c/Kconfig|  12 +++
> > > > >  board/qualcomm/dragonboard845c/MAINTAINERS|   6 ++
> > > > >  board/qualcomm/dragonboard845c/Makefile   |   9 ++
> > > > >  board/qualcomm/dragonboard845c/db845c.its |  63 +++
> > > > >  .../dragonboard845c/dragonboard845c.c |   9 ++
> > > > >  configs/dragonboard845c_defconfig |  28 +
> > > > >  doc/board/qualcomm/sdm845.rst | 100 
> > > > > +++---
> > > > >  include/configs/dragonboard845c.h |  28 +
> > > > >  11 files changed, 337 insertions(+), 13 deletions(-)
> > > > >  create mode 100644 arch/arm/dts/dragonboard845c-uboot.dtsi
> > > > >  create mode 100644 arch/arm/dts/dragonboard845c.dts
> > > > >  create mode 100644 board/qualcomm/dragonboard845c/Kconfig
> > > > >  create mode 100644 board/qualcomm/dragonboard845c/MAINTAINERS
> > > > >  create mode 100644 board/qualcomm/dragonboard845c/Makefile
> > > > >  create mode 100644 board/qualcomm/dragonboard845c/db845c.its
> > > > >  create mode 100644 board/qualcomm/dragonboard845c/dragonboard845c.c
> > > > >  create mode 100644 configs/dragonboard845c_defconfig
> > > > >  create mode 100644 include/configs/dragonboard845c.h
> > > > >
> > > > [..]
> > > >
> > > > > diff --git a/doc/board/qualcomm/sdm845.rst 
> > > > > b/doc/board/qualcomm/sdm845.rst
> > > > > index b6642c9579..8ef4749287 100644
> > > > > --- a/doc/board/qualcomm/sdm845.rst
> > > > > +++ b/doc/board/qualcomm/sdm845.rst
> > > > > @@ -35,9 +35,25 @@ Pack android boot image
> > > > >  ^^^
> > > > >  We'll assemble android boot image with ``u-boot.bin`` instead of 
> > > > > linux kernel,
> > > > >  and FIT image instead of ``initramfs``. Android bootloader expect 
> > > > > gzipped kernel
> > > > > -with appended dtb, so let's mimic linux to satisfy stock bootloader:
> > > > > +with appended dtb, so let's mimic linux to satisfy stock bootloader.
> > > > >
> > > >
> > > > [..]
> > > >
> > > > > +The dragonboard845c is a Qualcomm Robotics RB3 Development Platform, 
> > > > > based on
> > > > > +the Qualcomm SDM845 SoC.
> > > > > +
> > > > > +Steps:
> > > > > +
> > > > > +- Build u-boot::
> > > > > +
> > > > > +   $ export CROSS_COMPILE=
> > > > > +   $ make dragonboard845c_defconfig
> > > > > +   $ make
> > > > > +
> > > > > +- Create dummy dtb::
> > > > > +
> > > > > +   workdir=/tmp/prepare_payload
> > > > > +   mkdir -p "$workdir"
> > > > > +   mock_dtb="$workdir"/payload_mock.dtb
> > > > > +
> > > > > +   dtc -I dts -O dtb -o "$mock_dtb" << EOF
> > > > > +   /dts-v1/;
> > > > > +   / {
> > > > > +   #address-cells = <2>;
> > > > > +   #size-cells = <2>;
> > > > > +
> > > > > +   memory@8000 {
> > > > > +   device_type = "memory";
> > > > > +   /* We expect the bootloader to fill in the 
> > > > > size */
> > > > > +   reg = <0 0x8000 0 0>;
> > > > > +   };
> > > > > +
> > > > > +   chosen { };
> > > > > +   };
> > > > > +   EOF
> > > > > +
> > > > > +- gzip u-boot::
> > > > > +
> > > > > +   gzip u-boot.bin
> > > > > +
> > > > > +- Append dtb to gzipped u-boot::
> > > > > +
> > > > > +cat u-boot.bin.gz "$mock_dtb" > u-boot.bin.gz-dtb
> > > > > +
> > > > > +- A ``db845c.its`` file can be found in 
> > > > > ``board/qualcomm/dragonboard845c/``
> > > > > +  directory. It expects a folder as ``db845c_imgs/`` in the main 
> > > > > directory
> > > > > +  containing pre-built kernel, dts and ramdisk images. See 
> > > > > ``db845c.its``
> > > > > +  for full path to images::
> > > > > +
> > > > > +   mkimage -f db845c.its db845c.itb
> > > > > +
> > > > > 

Re: [PATCH 1/1] video: fix typo in video_sync_all documentation

[Simon Glass]

On Mon, 28 Aug 2023 at 14:40, Heinrich Schuchardt
 wrote:
>
> %s/there/their/
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/video.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Simon Glass]

Hi Peter,

On Mon, 28 Aug 2023 at 14:29, Peter Robinson  wrote:
>
> On Mon, Aug 28, 2023 at 6:54 PM Simon Glass  wrote:
> >
> > Hi Peter,
> >
> > On Mon, 28 Aug 2023 at 10:37, Peter Robinson  wrote:
> > >
> > > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  
> > > > wrote:
> > > > >
> > > > >
> > > > > Provide a way for removing certain devicetree nodes and/or properties
> > > > > from the devicetree. This is needed to purge certain nodes and
> > > > > properties which may be relevant only in U-Boot. Such nodes and
> > > > > properties are then removed from the devicetree before it is passed to
> > > > > the kernel. This ensures that the devicetree passed to the OS does not
> > > > > contain any non-compliant nodes and properties.
> > > > >
> > > > > The removal of the nodes and properties is being done through an
> > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> > > > > behind any Kconfig symbol.
> > > > >
> > > > > I have only build tested this on sandbox, and tested on qemu arm64
> > > > > virt platform. This being a RFC, I have not put this through a CI run.
> > > > >
> > > > > Sughosh Ganu (5):
> > > > >   dt: Provide a way to remove non-compliant nodes and properties
> > > > >   fwu: Add the fwu-mdata node for removal from devicetree
> > > > >   capsule: Add the capsule-key property for removal from devicetree
> > > > >   bootefi: Call the EVT_FT_FIXUP event handler
> > > > >   doc: Add a document for non-compliant DT node/property removal
> > > > >
> > > > >  cmd/bootefi.c | 18 +
> > > > >  .../devicetree/dt_non_compliant_purge.rst | 64 
> > > > >  drivers/fwu-mdata/fwu-mdata-uclass.c  |  5 ++
> > > > >  include/dt-structs.h  | 11 +++
> > > > >  lib/Makefile  |  1 +
> > > > >  lib/dt_purge.c| 73 
> > > > > +++
> > > > >  lib/efi_loader/efi_capsule.c  |  7 ++
> > > > >  7 files changed, 179 insertions(+)
> > > > >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> > > > >  create mode 100644 lib/dt_purge.c
> > > >
> > > > What is the point of removing them? Instead, we should make sure that
> > > > we upstream the bindings and encourage SoC vendors to sync them. If we
> > > > remove them, no one will bother and U-Boot just becomes a dumping
> > > > ground.
> > >
> > > Well things like the binman entries in DT are U-Boot specific and not
> > > useful for HW related descriptions or for Linux or another OS being
> > > able to deal with HW so arguably we're already a dumping ground to
> > > some degree for not defining hardware.
> >
> > I have started the process to upstream the binman bindings.
>
> I don't think they should be in DT at all, they don't describe
> anything to do with hardware, or generally even the runtime of a
> device, they don't even describe the boot/runtime state of the
> firmware, they describe build time, so I don't see what that has to do
> with device tree? Can you explain that? To me those sorts of things
> should live in a build time style config file.

I beg to differ. Devicetree is more than just hardware and always has
been. See, for example the /chosen and /options nodes.

We need run-time configuration here, since we cannot know at build
time what we will be asked to do by a previous firmware phase.

>
> > Perhaps we should use the issue tracker[1] to follow progress on all
> > of this. We need to clean it up.
> >
> > >
> > > > Instead of this, how about working on bringing the DT validation into
> > > > U-Boot so we can see what state things are in?
> > > >
> > > > Please send the bindings for Linaro's recent series (which I suspect
> > > > are motivating this series) so we can start the process.
> >
> > Regards,
> > Simon
> >
> > [1] https://source.denx.de/u-boot/u-boot/-/issues

Regards,
Simon

Re: [PATCH v2 1/2] dm: event: document all events

[Simon Glass]

On Mon, 28 Aug 2023 at 13:12, Heinrich Schuchardt
 wrote:
>
> Provide Sphinx documentation for all events.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> remove non-printing comments from num event_t
> correct texts according to Simon's suggestions
> ---
>  include/event.h | 97 ++---
>  1 file changed, 91 insertions(+), 6 deletions(-)
>

Reviewed-by: Simon Glass 

Thanks!

Re: [PATCH v5 00/13] Add video damage tracking

[Simon Glass]

Hi Alex,

On Mon, 28 Aug 2023 at 14:24, Alexander Graf  wrote:
>
>
> On 28.08.23 19:54, Simon Glass wrote:
> > Hi Alex,
> >
> > On Wed, 23 Aug 2023 at 02:56, Alexander Graf  wrote:
> >> Hey Simon,
> >>
> >> On 22.08.23 20:56, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Tue, 22 Aug 2023 at 01:47, Alexander Graf  wrote:
>  On 22.08.23 01:03, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 21 Aug 2023 at 16:40, Alexander Graf  wrote:
> >> On 22.08.23 00:10, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 21 Aug 2023 at 14:20, Alexander Graf  wrote:
>  On 21.08.23 21:57, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 21 Aug 2023 at 13:33, Alexander Graf  
> > wrote:
> >> On 21.08.23 21:11, Simon Glass wrote:
> >>> Hi Alper,
> >>>
> >>> On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak 
> >>>  wrote:
>  This is a rebase of Alexander Graf's video damage tracking 
>  series, with
>  some tests and other changes. The original cover letter is as 
>  follows:
> 
> > This patch set speeds up graphics output on ARM by a factor of 
> > 60x.
> >
> > On most ARM SBCs, we keep the frame buffer in DRAM and map it 
> > as cached,
> > but need it accessible by the display controller which reads 
> > directly
> > from a later point of consistency. Hence, we flush the frame 
> > buffer to
> > DRAM on every change. The full frame buffer.
> >>> It should not, see below.
> >>>
> > Unfortunately, with the advent of 4k displays, we are seeing 
> > frame buffers
> > that can take a while to flush out. This was reported by Da Xue 
> > with grub,
> > which happily print 1000s of spaces on the screen to draw a 
> > menu. Every
> > printed space triggers a cache flush.
> >>> That is a bug somewhere in EFI.
> >> Unfortunately not :). You may call it a bug in grub: It literally 
> >> prints
> >> over space characters for every character in its menu that it wants
> >> cleared. On every text screen draw.
> >>
> >> This wouldn't be a big issue if we only flush the reactangle that 
> >> gets
> >> modified. But without this patch set, we're flushing the full DRAM
> >> buffer on every u-boot text console character write, which means 
> >> for
> >> every character (as that's the only API UEFI has).
> >>
> >> As a nice side effect, we speed up the normal U-Boot text console 
> >> as
> >> well with this patch set, because even "normal" text prints that 
> >> write
> >> for example a single line of text on the screen today flush the 
> >> full
> >> frame buffer to DRAM.
> > No, I mean that it is a bug that U-Boot (apparently) flushes the 
> > cache
> > after every character. It doesn't do that for normal character 
> > output
> > and I don't think it makes sense to do it for EFI either.
>  I see. Let's trace the calls:
> 
>  efi_cout_output_string()
>  -> fputs()
>  -> vidconsole_puts()
>  -> video_sync()
>  -> flush_dcache_range()
> 
>  Unfortunately grub abstracts character backends down to the "print
>  character" level, so it calls UEFI's sopisticated "output_string"
>  callback with single characters at a time, which means we do a full
>  dcache flush for every character that we print:
> 
>  https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/efi/console.c#n165
> 
> 
> > This patch set implements the easiest mitigation against this 
> > problem:
> > Damage tracking. We remember the lowest common denominator 
> > region that was
> > touched since the last video_sync() call and only flush that. 
> > The most
> > typical writer to the frame buffer is the video console, which 
> > always
> > writes rectangles of characters on the screen and syncs 
> > afterwards.
> >
> > With this patch set applied, we reduce drawing a large grub 
> > menu (with
> > serial console attached for size information) on an RK3399-ROC 
> > system
> > at 1440p from 55 seconds to less than 1 second.
> >
> > Version 2 also implements VIDEO_COPY using this mechanism, 
> > reducing its
> > overhead compared to before as well. So even x86 systems should 
> > be faster
> > with this now :).
> 

Re: [PATCH v4 1/8] cmd: gpt: Remove confusing help text

[Heinrich Schuchardt]

On 8/28/23 23:56, Joshua Watt wrote:

This help text appears to be a fragment of the text shown when
CONFIG_CMD_GPT_RENAME is enabled, but is confusing so remove it.

Signed-off-by: Joshua Watt 


Reviewed-by: Heinrich Schuchardt 


---
  cmd/gpt.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 964056bd28..fe9e06681c 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -1060,8 +1060,6 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
"  gpt_partition_name, gpt_partition_entry\n"
" gpt enumerate mmc 0\n"
"- store list of partitions to gpt_partition_list environment 
variable\n"
-   " read  \n"
-   "- read GPT into a data structure for manipulation\n"
" gpt guid  \n"
"- print disk GUID\n"
" gpt guid   \n"

[PATCH v1 2/2] doc: board: toradex: verdin-am62: document update u-boot wrapper

[Marcel Ziswiler]

From: Marcel Ziswiler 

Now with the update U-Boot wrappers having been sorted out, document
their usage.

Signed-off-by: Marcel Ziswiler 

---

 doc/board/toradex/verdin-am62.rst | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/doc/board/toradex/verdin-am62.rst 
b/doc/board/toradex/verdin-am62.rst
index ecc7e0777cb..e8d90273288 100644
--- a/doc/board/toradex/verdin-am62.rst
+++ b/doc/board/toradex/verdin-am62.rst
@@ -74,6 +74,20 @@ Flash to eMMC
 => fatload mmc 1 ${loadaddr} u-boot.img
 => mmc write ${loadaddr} 0x1400 0x2000
 
+As a convenience, instead of having to remember all those addresses and sizes,
+one may also use the update U-Boot wrappers:
+
+.. code-block:: bash
+
+> tftpboot ${loadaddr} tiboot3-am62x-gp-verdin.bin
+> run update_tiboot3
+
+> tftpboot ${loadaddr} tispl.bin
+> run update_tispl
+
+> tftpboot ${loadaddr} u-boot.img
+> run update_uboot
+
 Boot
 
 
-- 
2.36.1

[PATCH v1 1/2] doc: board: toradex: minor documentation update

[Marcel Ziswiler]

From: Marcel Ziswiler 

- Update SPDX-License-Identifier from obsolete GPL-2.0+ to
  GPL-2.0-or-later.
- Add links to product websites of SoM and carrier board where missing.
- Add information about update U-Boot wrapper where missing.
- Add sectionauthor where missing.
- Update information about imx-seco from version 3.7.4 to 3.8.1.
- Various minor grammatic and spelling fixes.
- Improve whitespace by adding or removing new lines.
- Change from code-block for output to just Output::.

Signed-off-by: Marcel Ziswiler 
---

 doc/board/toradex/apalis-imx8.rst   | 22 +
 doc/board/toradex/colibri-imx8x.rst | 31 ---
 doc/board/toradex/colibri_imx7.rst  | 38 +++--
 doc/board/toradex/verdin-am62.rst   |  8 +++---
 doc/board/toradex/verdin-imx8mm.rst |  9 +++
 doc/board/toradex/verdin-imx8mp.rst |  9 +++
 6 files changed, 71 insertions(+), 46 deletions(-)

diff --git a/doc/board/toradex/apalis-imx8.rst 
b/doc/board/toradex/apalis-imx8.rst
index 849b1172bd4..ffc4c7d222a 100644
--- a/doc/board/toradex/apalis-imx8.rst
+++ b/doc/board/toradex/apalis-imx8.rst
@@ -1,7 +1,11 @@
-.. SPDX-License-Identifier: GPL-2.0+
+.. SPDX-License-Identifier: GPL-2.0-or-later
+.. sectionauthor:: Marcel Ziswiler 
 
-Apalis iMX8QM V1.0B Module
-==
+Apalis iMX8 Module
+==
+
+- SoM: https://www.toradex.com/computer-on-modules/apalis-arm-family/nxp-imx-8
+- Carrier board: 
https://www.toradex.com/products/carrier-board/apalis-evaluation-board
 
 Quick Start
 ---
@@ -49,6 +53,7 @@ Copy the following firmware to the U-Boot folder:
 
 Build U-Boot
 
+
 .. code-block:: bash
 
 $ make apalis-imx8_defconfig
@@ -61,8 +66,8 @@ Get the latest version of the universal update utility (uuu) 
aka ``mfgtools 3.0`
 
 
https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
 
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute uuu:
+Put the module into USB recovery aka serial downloader mode, connect the USB
+device to your host and execute ``uuu``:
 
 .. code-block:: bash
 
@@ -80,3 +85,10 @@ partition and boot:
 setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
 mmc dev 0 1
 mmc write ${loadaddr} 0x0 ${blkcnt}
+
+As a convenience, instead of the last three commands, one may also use the
+update U-Boot wrapper:
+
+.. code-block:: bash
+
+> run update_uboot
diff --git a/doc/board/toradex/colibri-imx8x.rst 
b/doc/board/toradex/colibri-imx8x.rst
index 545568c844a..9e61d98c6b1 100644
--- a/doc/board/toradex/colibri-imx8x.rst
+++ b/doc/board/toradex/colibri-imx8x.rst
@@ -1,7 +1,11 @@
-.. SPDX-License-Identifier: GPL-2.0+
+.. SPDX-License-Identifier: GPL-2.0-or-later
+.. sectionauthor:: Marcel Ziswiler 
 
-Colibri iMX8QXP V1.0D Module
-
+Colibri iMX8X Module
+
+
+- SoM: 
https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-imx-8x
+- Carrier board: 
https://www.toradex.com/products/carrier-board/colibri-evaluation-board
 
 Quick Start
 ---
@@ -23,18 +27,19 @@ Get and Build the ARM Trusted Firmware
 
 Get scfw_tcm.bin and ahab-container.img
 ---
+
 .. code-block:: bash
 
 $ wget 
https://github.com/toradex/i.MX-System-Controller-Firmware/raw/master/src/scfw_export_mx8qx_b0/build_mx8qx_b0/mx8qx-colibri-scfw-tcm.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.7.4.bin
-$ sh imx-seco-3.7.4.bin --auto-accept
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.8.1.bin
+$ sh imx-seco-3.8.1.bin --auto-accept
 
 Copy the following firmware to the U-Boot folder:
 
 .. code-block:: bash
 
 $ cp imx-atf/build/imx8qx/release/bl31.bin .
-$ cp imx-seco-3.7.4/firmware/seco/mx8qxc0-ahab-container.img 
mx8qx-ahab-container.img
+$ cp imx-seco-3.8.1/firmware/seco/mx8qxc0-ahab-container.img 
mx8qx-ahab-container.img
 
 Build U-Boot
 
@@ -51,8 +56,8 @@ Get the latest version of the universal update utility (uuu) 
aka ``mfgtools 3.0`
 
 
https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
 
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute ``uuu``:
+Put the module into USB recovery aka serial downloader mode, connect the USB
+device to your host and execute ``uuu``:
 
 .. code-block:: bash
 
@@ -61,7 +66,8 @@ to your host and execute ``uuu``:
 Flash the U-Boot Binary into the eMMC
 -
 
-Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area 
partition:
+Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area
+partition and boot:
 
 .. code-block:: bash
 
@@ -69,3 +75,10 @@ Burn the ``u-boot-dtb.imx`` binary to the primary eMMC 
hardware boot area partit
 

[PATCH v1 0/2] doc: board: toradex: documentation update

[Marcel Ziswiler]

From: Marcel Ziswiler 


This series contains some minor documentation updates. The second commit
documents what got discussed here [1] and therefore depends on
Emanuele's series landing first.

[1] https://lore.kernel.org/all/zodsx2vmnf20i...@francesco-nb.int.toradex.com


Marcel Ziswiler (2):
  doc: board: toradex: minor documentation update
  doc: board: toradex: verdin-am62: document update u-boot wrapper

 doc/board/toradex/apalis-imx8.rst   | 22 +
 doc/board/toradex/colibri-imx8x.rst | 31 ---
 doc/board/toradex/colibri_imx7.rst  | 38 +++--
 doc/board/toradex/verdin-am62.rst   | 22 ++---
 doc/board/toradex/verdin-imx8mm.rst |  9 +++
 doc/board/toradex/verdin-imx8mp.rst |  9 +++
 6 files changed, 85 insertions(+), 46 deletions(-)

-- 
2.36.1

[PATCH v4 8/8] cmd: gpt: Add command to swap partition order

[Joshua Watt]

Adds a command called "gpt swap-postition" which will swap the order two
partition table entries in the GPT partition table (but leaves them
pointing to the same locations on disk).

This can be useful for swapping bootloaders in systems that use an A/B
partitioning scheme where the bootrom is hard coded to look for the
bootloader in a specific index in the GPT partition table.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 46 ---
 doc/usage/cmd/gpt.rst | 25 +
 test/py/tests/test_gpt.py | 19 
 3 files changed, 87 insertions(+), 3 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 927b6afa68..c7d3f65ff2 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -858,8 +858,9 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
u8 part_count = 0;
int partlistlen, ret, numparts = 0, partnum, i = 1, ctr1 = 0, ctr2 = 0;
 
-   if ((subcomm == NULL) || (name1 == NULL) || (name2 == NULL) ||
-   (strcmp(subcomm, "swap") && (strcmp(subcomm, "rename"
+   if (!subcomm || !name1 || !name2 ||
+   (strcmp(subcomm, "swap") && strcmp(subcomm, "rename") &&
+strcmp(subcomm, "swap-position")))
return -EINVAL;
 
ret = get_disk_guid(dev_desc, disk_guid);
@@ -920,6 +921,41 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
ret = -EINVAL;
goto out;
}
+   } else if (!strcmp(subcomm, "swap-position")) {
+   int idx1, idx2;
+   struct disk_partition* first = NULL;
+   struct disk_partition* second= NULL;
+   struct disk_partition tmp_part;
+
+   idx1 = simple_strtoul(name1, NULL, 10);
+   idx2 = simple_strtoul(name2, NULL, 10);
+   if (idx1 == idx2) {
+   printf("Cannot swap partition with itself\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
+   list_for_each(pos, _partitions) {
+   curr = list_entry(pos, struct disk_part, list);
+   if (curr->partnum == idx1)
+   first = >gpt_part_info;
+   else if (curr->partnum == idx2)
+   second = >gpt_part_info;
+   }
+   if (!first) {
+   printf("Illegal partition number %s\n", name1);
+   ret = -EINVAL;
+   goto out;
+   }
+   if (!second) {
+   printf("Illegal partition number %s\n", name2);
+   ret = -EINVAL;
+   goto out;
+   }
+
+   tmp_part = *first;
+   *first = *second;
+   *second = tmp_part;
} else { /* rename */
if (strlen(name2) > PART_NAME_LEN) {
printf("Names longer than %d characters are 
truncated.\n", PART_NAME_LEN);
@@ -1123,7 +1159,8 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
} else if (strcmp(argv[1], "read") == 0) {
ret = do_get_gpt_info(blk_dev_desc, (argc == 5) ? argv[4] : 
NULL);
} else if ((strcmp(argv[1], "swap") == 0) ||
-  (strcmp(argv[1], "rename") == 0)) {
+  (strcmp(argv[1], "rename") == 0) ||
+  (strcmp(argv[1], "swap-position") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4], 
argv[5]);
} else if ((strcmp(argv[1], "set-bootable") == 0)) {
ret = gpt_set_bootable(blk_dev_desc, argv[4]);
@@ -1176,6 +1213,8 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt swap\n"
"- change all partitions named name1 to name2\n"
"  and vice-versa\n"
+   " gpt swap-position\n"
+   "- Swap the order of the entries for part1 and part2 in the 
partition table\n"
" gpt rename\n"
"- rename the specified partition\n"
" gpt set-bootable   \n"
@@ -1184,5 +1223,6 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt swap mmc 0 foo bar\n"
" gpt rename mmc 0 3 foo\n"
" gpt set-bootable mmc 0 boot_a,boot_b\n"
+   " gpt swap-position mmc 0 1 2\n"
 #endif
 );
diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
index 288dd365c0..b2aaf4a701 100644
--- a/doc/usage/cmd/gpt.rst
+++ b/doc/usage/cmd/gpt.rst
@@ -16,6 +16,7 @@ Synopsis
 gpt set-bootable   
 gpt setenv   
 gpt swap
+gpt swap-position
 gpt verify   []
 gpt write   
 
@@ -126,6 +127,13 @@ Changes the names of all partitions that are named 'name1' 
to be 'name2', and
 all partitions named 'name2' to be 'name1'. CONFIG_CMD_GPT_RENAME=y is
 required.
 
+gpt swap-position
+~
+
+Swaps the 

[PATCH v4 7/8] cmd: gpt: Preserve bootable flag

[Joshua Watt]

Sets the bootable flag when constructing the partition string from the
current partition configuration. This ensures that when the partitions
are written back (for example, when renaming a partition), the flag is
preserved.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 3 +++
 test/py/tests/test_gpt.py | 1 +
 2 files changed, 4 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 0090e02110..927b6afa68 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -176,6 +176,7 @@ static int calc_parts_list_len(int numparts)
 #ifdef CONFIG_PARTITION_TYPE_GUID
partlistlen += numparts * (strlen("type=,") + UUID_STR_LEN + 1);
 #endif
+   partlistlen += numparts * strlen("bootable,");
partlistlen += numparts * (strlen("uuid=;") + UUID_STR_LEN + 1);
/* for the terminating null */
partlistlen++;
@@ -318,6 +319,8 @@ static int create_gpt_partitions_list(int numparts, const 
char *guid,
strcat(partitions_list, ",uuid=");
strncat(partitions_list, curr->gpt_part_info.uuid,
UUID_STR_LEN + 1);
+   if (curr->gpt_part_info.bootable & PART_BOOTABLE)
+   strcat(partitions_list, ",bootable");
strcat(partitions_list, ";");
}
return 0;
diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
index 93007dee9a..b4c03bc3a2 100644
--- a/test/py/tests/test_gpt.py
+++ b/test/py/tests/test_gpt.py
@@ -143,6 +143,7 @@ def test_gpt_read_var(state_disk_image, u_boot_console):
 "size": "0x10",
 "type": "0fc63daf-8483-4772-8e79-3d69d8477de4",
 "uuid": "33194895-67f6-4561-8457-6fdeed4f50a3",
+"bootable": True,
 },
 {
 "name": "part2",
-- 
2.33.0

[PATCH v4 6/8] cmd: gpt: Preserve type GUID if enabled

[Joshua Watt]

If CONFIG_PARTITION_TYPE_GUID is enabled, the type GUID will be
preserved when writing out the partition string. It was already
respected when writing out partitions; this ensures that if you capture
the current partition layout and write it back (such as when renaming),
the type GUIDs are preserved.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 16 ++
 test/py/tests/test_gpt.py | 65 +++
 2 files changed, 81 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 45fbe07404..0090e02110 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -173,6 +173,9 @@ static int calc_parts_list_len(int numparts)
/* see part.h for definition of struct disk_partition */
partlistlen += numparts * (strlen("start=MiB,") + sizeof(lbaint_t) + 1);
partlistlen += numparts * (strlen("size=MiB,") + sizeof(lbaint_t) + 1);
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   partlistlen += numparts * (strlen("type=,") + UUID_STR_LEN + 1);
+#endif
partlistlen += numparts * (strlen("uuid=;") + UUID_STR_LEN + 1);
/* for the terminating null */
partlistlen++;
@@ -211,6 +214,11 @@ static struct disk_part *allocate_disk_part(struct 
disk_partition *info,
PART_TYPE_LEN);
newpart->gpt_part_info.type[PART_TYPE_LEN - 1] = '\0';
newpart->gpt_part_info.bootable = info->bootable;
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   strncpy(newpart->gpt_part_info.type_guid, (const char *)info->type_guid,
+   UUID_STR_LEN);
+   newpart->gpt_part_info.type_guid[UUID_STR_LEN] = '\0';
+#endif
 #ifdef CONFIG_PARTITION_UUIDS
strncpy(newpart->gpt_part_info.uuid, (const char *)info->uuid,
UUID_STR_LEN);
@@ -252,6 +260,9 @@ static void print_gpt_info(void)
   curr->gpt_part_info.name);
printf("Type %s, bootable %d\n", curr->gpt_part_info.type,
   curr->gpt_part_info.bootable & PART_BOOTABLE);
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   printf("Type GUID %s\n", curr->gpt_part_info.type_guid);
+#endif
 #ifdef CONFIG_PARTITION_UUIDS
printf("UUID %s\n", curr->gpt_part_info.uuid);
 #endif
@@ -299,6 +310,11 @@ static int create_gpt_partitions_list(int numparts, const 
char *guid,
curr->gpt_part_info.blksz);
strncat(partitions_list, partstr, PART_NAME_LEN + 1);
 
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   strcat(partitions_list, ",type=");
+   strncat(partitions_list, curr->gpt_part_info.type_guid,
+   UUID_STR_LEN + 1);
+#endif
strcat(partitions_list, ",uuid=");
strncat(partitions_list, curr->gpt_part_info.uuid,
UUID_STR_LEN + 1);
diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
index 5d23f9b292..93007dee9a 100644
--- a/test/py/tests/test_gpt.py
+++ b/test/py/tests/test_gpt.py
@@ -16,6 +16,35 @@ the test.
 # Mark all tests here as slow
 pytestmark = pytest.mark.slow
 
+def parse_gpt_parts(disk_str):
+"""Parser a partition string into a list of partitions.
+
+Args:
+disk_str: The disk description string, as returned by `gpt read`
+
+Returns:
+A list of parsed partitions. Each partition is a dictionary with the
+string value from each specified key in the partition description, or a
+key with with the value True for a boolean flag
+"""
+parts = []
+for part_str in disk_str.split(';'):
+part = {}
+for option in part_str.split(","):
+if not option:
+continue
+
+if "=" in option:
+key, value = option.split("=")
+part[key] = value
+else:
+part[option] = True
+
+if part:
+parts.append(part)
+
+return parts
+
 class GptTestDiskImage(object):
 """Disk Image used by the GPT tests."""
 
@@ -49,11 +78,13 @@ class GptTestDiskImage(object):
 u_boot_utils.run_and_log(u_boot_console, cmd)
 # part1 offset 1MB size 1MB
 cmd = ('sgdisk', '--new=1:2048:4095', '--change-name=1:part1',
+'--partition-guid=1:33194895-67f6-4561-8457-6fdeed4f50a3',
 '-A 1:set:2',
 persistent)
 # part2 offset 2MB size 1.5MB
 u_boot_utils.run_and_log(u_boot_console, cmd)
 cmd = ('sgdisk', '--new=2:4096:7167', '--change-name=2:part2',
+'--partition-guid=2:cc9c6e4a-6551-4cb5-87be-3210f96c86fb',
 persistent)
 u_boot_utils.run_and_log(u_boot_console, cmd)
 cmd = ('sgdisk', '--load-backup=' + persistent)
@@ -88,6 +119,40 @@ def test_gpt_read(state_disk_image, u_boot_console):
 assert '0x0800 0x0fff  "part1"' in output
 assert '0x1000 0x1bff  "part2"' in output
 

[PATCH v4 5/8] cmd: gpt: Add command to set bootable flags

[Joshua Watt]

Adds a command that can be used to modify the GPT partition table to
indicate which partitions should have the bootable flag set

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 80 +++
 doc/usage/cmd/gpt.rst | 12 ++
 test/py/tests/test_gpt.py | 22 +++
 3 files changed, 114 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index c6c8282ac9..45fbe07404 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -972,6 +972,81 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
free(partitions_list);
return ret;
 }
+
+/**
+ * gpt_set_bootable() - Set bootable flags for partitions
+ *
+ * Sets the bootable flag for any partition names in the comma separated list 
of
+ * partition names. Any partitions not in the list have their bootable flag
+ * cleared
+ *
+ * @desc: block device descriptor
+ * @name: Comma separated list of partition names
+ *
+ * @Return: '0' on success and -ve error on failure
+ */
+static int gpt_set_bootable(struct blk_desc *blk_dev_desc, char *const 
part_list)
+{
+   char *name;
+   char disk_guid[UUID_STR_LEN + 1];
+   struct list_head *pos;
+   struct disk_part *curr;
+   struct disk_partition *partitions = NULL;
+   int part_count = 0;
+   int ret = get_disk_guid(blk_dev_desc, disk_guid);
+
+   if (ret < 0)
+   return ret;
+
+   ret = get_gpt_info(blk_dev_desc);
+   if (ret <= 0)
+   goto out;
+
+   part_count = ret;
+   partitions = malloc(sizeof(*partitions) * part_count);
+   if (!partitions) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   /* Copy partitions and clear bootable flag */
+   part_count = 0;
+   list_for_each(pos, _partitions) {
+   curr = list_entry(pos, struct disk_part, list);
+   partitions[part_count] = curr->gpt_part_info;
+   partitions[part_count].bootable &= ~PART_BOOTABLE;
+   part_count++;
+   }
+
+   name = strtok(part_list, ",");
+   while (name) {
+   bool found = false;
+
+   for (int i = 0; i < part_count; i++) {
+   if (strcmp((char *)partitions[i].name, name) == 0) {
+   partitions[i].bootable |= PART_BOOTABLE;
+   found = true;
+   }
+   }
+
+   if (!found) {
+   printf("Warning: No partition matching '%s' found\n",
+  name);
+   }
+
+   name = strtok(NULL, ",");
+   }
+
+   ret = gpt_restore(blk_dev_desc, disk_guid, partitions, part_count);
+
+out:
+   del_gpt_info();
+
+   if (partitions)
+   free(partitions);
+
+   return ret;
+}
 #endif
 
 /**
@@ -1031,6 +1106,8 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
} else if ((strcmp(argv[1], "swap") == 0) ||
   (strcmp(argv[1], "rename") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4], 
argv[5]);
+   } else if ((strcmp(argv[1], "set-bootable") == 0)) {
+   ret = gpt_set_bootable(blk_dev_desc, argv[4]);
 #endif
} else {
return CMD_RET_USAGE;
@@ -1082,8 +1159,11 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
"  and vice-versa\n"
" gpt rename\n"
"- rename the specified partition\n"
+   " gpt set-bootable   \n"
+   "- make partition names in list bootable\n"
" Example usage:\n"
" gpt swap mmc 0 foo bar\n"
" gpt rename mmc 0 3 foo\n"
+   " gpt set-bootable mmc 0 boot_a,boot_b\n"
 #endif
 );
diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
index b505b159d0..288dd365c0 100644
--- a/doc/usage/cmd/gpt.rst
+++ b/doc/usage/cmd/gpt.rst
@@ -13,6 +13,7 @@ Synopsis
 gpt read   []
 gpt rename
 gpt repair  
+gpt set-bootable   
 gpt setenv   
 gpt swap
 gpt verify   []
@@ -90,6 +91,13 @@ gpt repair
 
 Repairs the GPT partition tables if it they become corrupted.
 
+gpt set-bootable
+
+
+Sets the bootable flag for all partitions in the table. If the partition name
+is in 'partition list' (separated by ','), the bootable flag is set, otherwise
+it is cleared. CONFIG_CMD_GPT_RENAME=y is required.
+
 gpt setenv
 ~~
 
@@ -187,3 +195,7 @@ Get the GUID for a disk::
 => gpt guid mmc gpt_disk_uuid
 => echo ${gpt_disk_uuid}
 bec9fc2a-86c1-483d-8a0e-0109732277d7
+
+Set the bootable flag for the 'boot' partition and clear it for all others::
+
+=> gpt set-bootable mmc 0 boot
diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
index 946858800d..5d23f9b292 100644
--- a/test/py/tests/test_gpt.py
+++ b/test/py/tests/test_gpt.py
@@ -222,6 +222,28 @@ def test_gpt_swap_partitions(state_disk_image, 
u_boot_console):
 

[PATCH v4 4/8] cmd: gpt: Add gpt_partition_bootable variable

[Joshua Watt]

Adds an additional variable called gpt_partition_bootable that indicates
if the given partition is bootable or not.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c |  9 +++--
 doc/usage/cmd/gpt.rst |  5 +
 test/py/tests/test_gpt.py | 33 +
 3 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index fe9e06681c..c6c8282ac9 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -725,7 +725,7 @@ static int gpt_enumerate(struct blk_desc *desc)
  * gpt_setenv_part_variables() - setup partition environmental variables
  *
  * Setup the gpt_partition_name, gpt_partition_entry, gpt_partition_addr
- * and gpt_partition_size environment variables.
+ * and gpt_partition_size, gpt_partition_bootable environment variables.
  *
  * @pinfo: pointer to disk partition
  * @i: partition entry
@@ -752,6 +752,10 @@ static int gpt_setenv_part_variables(struct disk_partition 
*pinfo, int i)
if (ret)
goto fail;
 
+   ret = env_set_ulong("gpt_partition_bootable", !!(pinfo->bootable & 
PART_BOOTABLE));
+   if (ret)
+   goto fail;
+
return 0;
 
 fail:
@@ -1057,7 +1061,8 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt setenv mmc 0 $name\n"
"- setup environment variables for partition $name:\n"
"  gpt_partition_addr, gpt_partition_size,\n"
-   "  gpt_partition_name, gpt_partition_entry\n"
+   "  gpt_partition_name, gpt_partition_entry,\n"
+   "  gpt_partition_bootable\n"
" gpt enumerate mmc 0\n"
"- store list of partitions to gpt_partition_list environment 
variable\n"
" gpt guid  \n"
diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
index 6387c8116f..b505b159d0 100644
--- a/doc/usage/cmd/gpt.rst
+++ b/doc/usage/cmd/gpt.rst
@@ -108,6 +108,9 @@ gpt_partition_name
 gpt_partition_entry
 the partition number in the table, e.g. 1, 2, 3, etc.
 
+gpt_partition_bootable
+1 if the partition is marked as bootable, 0 if not
+
 gpt swap
 
 
@@ -167,6 +170,8 @@ Get the information about the partition named 'rootfs'::
 rootfs
 => echo ${gpt_partition_entry}
 2
+=> echo ${gpt_partition_bootable}
+0
 
 Get the list of partition names on the disk::
 
diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
index 339468bc12..946858800d 100644
--- a/test/py/tests/test_gpt.py
+++ b/test/py/tests/test_gpt.py
@@ -49,6 +49,7 @@ class GptTestDiskImage(object):
 u_boot_utils.run_and_log(u_boot_console, cmd)
 # part1 offset 1MB size 1MB
 cmd = ('sgdisk', '--new=1:2048:4095', '--change-name=1:part1',
+'-A 1:set:2',
 persistent)
 # part2 offset 2MB size 1.5MB
 u_boot_utils.run_and_log(u_boot_console, cmd)
@@ -117,6 +118,38 @@ def test_gpt_guid(state_disk_image, u_boot_console):
 output = u_boot_console.run_command('gpt guid host 0')
 assert '375a56f7-d6c9-4e81-b5f0-09d41ca89efe' in output
 
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_gpt')
+@pytest.mark.requiredtool('sgdisk')
+def test_gpt_setenv(state_disk_image, u_boot_console):
+"""Test the gpt setenv command."""
+u_boot_console.run_command('host bind 0 ' + state_disk_image.path)
+output = u_boot_console.run_command('gpt setenv host 0 part1')
+assert 'success!' in output
+output = u_boot_console.run_command('echo ${gpt_partition_addr}')
+assert output.rstrip() == '800'
+output = u_boot_console.run_command('echo ${gpt_partition_size}')
+assert output.rstrip() == '800'
+output = u_boot_console.run_command('echo ${gpt_partition_name}')
+assert output.rstrip() == 'part1'
+output = u_boot_console.run_command('echo ${gpt_partition_entry}')
+assert output.rstrip() == '1'
+output = u_boot_console.run_command('echo ${gpt_partition_bootable}')
+assert output.rstrip() == '1'
+
+output = u_boot_console.run_command('gpt setenv host 0 part2')
+assert 'success!' in output
+output = u_boot_console.run_command('echo ${gpt_partition_addr}')
+assert output.rstrip() == '1000'
+output = u_boot_console.run_command('echo ${gpt_partition_size}')
+assert output.rstrip() == 'c00'
+output = u_boot_console.run_command('echo ${gpt_partition_name}')
+assert output.rstrip() == 'part2'
+output = u_boot_console.run_command('echo ${gpt_partition_entry}')
+assert output.rstrip() == '2'
+output = u_boot_console.run_command('echo ${gpt_partition_bootable}')
+assert output.rstrip() == '0'
+
 @pytest.mark.boardspec('sandbox')
 @pytest.mark.buildconfigspec('cmd_gpt')
 @pytest.mark.requiredtool('sgdisk')
-- 
2.33.0

[PATCH v4 3/8] tests: gpt: Remove test order dependency

[Joshua Watt]

Re-create a clean disk image for each test to prevent modifications from
one test affecting another

Signed-off-by: Joshua Watt 
---
 test/py/tests/test_gpt.py | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
index 73bfbf77a2..339468bc12 100644
--- a/test/py/tests/test_gpt.py
+++ b/test/py/tests/test_gpt.py
@@ -61,18 +61,14 @@ class GptTestDiskImage(object):
 cmd = ('cp', persistent, self.path)
 u_boot_utils.run_and_log(u_boot_console, cmd)
 
-gtdi = None
 @pytest.fixture(scope='function')
 def state_disk_image(u_boot_console):
 """pytest fixture to provide a GptTestDiskImage object to tests.
 This is function-scoped because it uses u_boot_console, which is also
-function-scoped. However, we don't need to actually do any function-scope
-work, so this simply returns the same object over and over each time."""
+function-scoped. A new disk is returned each time to prevent tests from
+interfering with each other."""
 
-global gtdi
-if not gtdi:
-gtdi = GptTestDiskImage(u_boot_console)
-return gtdi
+return GptTestDiskImage(u_boot_console)
 
 @pytest.mark.boardspec('sandbox')
 @pytest.mark.buildconfigspec('cmd_gpt')
@@ -186,12 +182,12 @@ def test_gpt_swap_partitions(state_disk_image, 
u_boot_console):
 
 u_boot_console.run_command('host bind 0 ' + state_disk_image.path)
 output = u_boot_console.run_command('part list host 0')
-assert '0x0800 0x0fff  "first"' in output
-assert '0x1000 0x1bff  "second"' in output
-u_boot_console.run_command('gpt swap host 0 first second')
+assert '0x0800 0x0fff  "part1"' in output
+assert '0x1000 0x1bff  "part2"' in output
+u_boot_console.run_command('gpt swap host 0 part1 part2')
 output = u_boot_console.run_command('part list host 0')
-assert '0x0800 0x0fff  "second"' in output
-assert '0x1000 0x1bff  "first"' in output
+assert '0x0800 0x0fff  "part2"' in output
+assert '0x1000 0x1bff  "part1"' in output
 
 @pytest.mark.boardspec('sandbox')
 @pytest.mark.buildconfigspec('cmd_gpt')
-- 
2.33.0

[PATCH v4 2/8] doc: Add gpt command documentation

[Joshua Watt]

Adds initial documentation for the gpt command

Signed-off-by: Joshua Watt 
---
 doc/usage/cmd/gpt.rst | 184 ++
 doc/usage/index.rst   |   1 +
 2 files changed, 185 insertions(+)
 create mode 100644 doc/usage/cmd/gpt.rst

diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
new file mode 100644
index 00..6387c8116f
--- /dev/null
+++ b/doc/usage/cmd/gpt.rst
@@ -0,0 +1,184 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+gpt command
+===
+
+Synopsis
+
+
+::
+
+gpt enumerate  
+gpt guid   []
+gpt read   []
+gpt rename
+gpt repair  
+gpt setenv   
+gpt swap
+gpt verify   []
+gpt write   
+
+Description
+---
+
+The gpt command lets users read, create, modify, or verify the GPT (GUID
+Partition Table) partition layout.
+
+Common arguments:
+
+interface
+interface for accessing the block device (mmc, sata, scsi, usb, )
+
+dev
+device number
+
+partition string
+Describes the GPT partition layout for a disk.  The syntax is similar to
+the one used by the :doc:`mbr command ` command. The string contains
+one or more partition descriptors, each separated by a ";". Each descriptor
+contains one or more fields, with each field separated by a ",". Fields are
+either of the form "key=value" to set a specific value, or simple "flag" to
+set a boolean flag
+
+The first descriptor can optionally be used to describe parameters for the
+whole disk with the following fields:
+
+* uuid_disk=UUID - Set the UUID for the disk
+
+Partition descriptors can have the following fields:
+
+* name= - The partition name, required
+* start= - The partition start offset in bytes, required
+* size= - The partition size in bytes or "-" to expand it to the 
whole free area
+* bootable - Set the legacy bootable flag
+* uuid= - The partition UUID, optional if CONFIG_RANDOM_UUID=y is 
enabled
+* type= - The partition type GUID, requires 
CONFIG_PARTITION_TYPE_GUID=y
+
+
+If 'uuid' is not specified, but CONFIG_RANDOM_UUID is enabled, a random 
UUID
+will be generated for the partition
+
+gpt enumerate
+~
+
+Sets the variable 'gpt_partition_list' to be a list of all the partition names
+on the device.
+
+gpt guid
+
+
+Report the GUID of a disk. If 'varname' is specified, the command will set the
+variable to the GUID, otherwise it will be printed out.
+
+gpt read
+
+
+Prints the current state of the GPT partition table. If 'varname' is specified,
+the variable will be filled with a partition string in the same format as a
+'', suitable for passing to other 'gpt' commands.  If the
+argument is omitted, a human readable description is printed out.
+CONFIG_CMD_GPT_RENAME=y is required.
+
+gpt rename
+~~
+
+Renames all partitions named 'part' to be 'name'. CONFIG_CMD_GPT_RENAME=y is
+required.
+
+gpt repair
+~~
+
+Repairs the GPT partition tables if it they become corrupted.
+
+gpt setenv
+~~
+
+The 'gpt setenv' command will set a series of environment variables with
+information about the partition named ''. The variables are:
+
+gpt_partition_addr
+the starting offset of the partition in blocks as a hexadecimal number
+
+gpt_partition_size
+the size of the partition in blocks as a hexadecimal number
+
+gpt_partition_name
+the name of the partition
+
+gpt_partition_entry
+the partition number in the table, e.g. 1, 2, 3, etc.
+
+gpt swap
+
+
+Changes the names of all partitions that are named 'name1' to be 'name2', and
+all partitions named 'name2' to be 'name1'. CONFIG_CMD_GPT_RENAME=y is
+required.
+
+gpt verify
+~~
+
+Sets return value $? to 0 (true) if the partition layout on the
+specified disk matches the one in the provided partition string, and 1 (false)
+if it does not match. If no partition string is specified, the command will
+check if the disk is partitioned or not.
+
+gpt write
+~
+
+(Re)writes the partition table on the disk to match the provided
+partition string. It returns 0 on success or 1 on failure.
+
+Configuration
+-
+
+To use the 'gpt' command you must specify CONFIG_CMD_GPT=y. To enable 'gpt
+read', 'gpt swap' and 'gpt rename', you must specify CONFIG_CMD_GPT_RENAME=y.
+
+Examples
+
+Create 6 partitions on a disk::
+
+=> setenv gpt_parts 'uuid_disk=bec9fc2a-86c1-483d-8a0e-0109732277d7;
+
name=boot,start=4M,size=128M,bootable,type=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7,
+name=rootfs,size=3072M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=system-data,size=512M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=[ext],size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=user,size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=modules,size=100M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=ramdisk,size=8M,type=0fc63daf-8483-4772-8e79-3d69d8477de4
+=> 

[PATCH v4 1/8] cmd: gpt: Remove confusing help text

[Joshua Watt]

This help text appears to be a fragment of the text shown when
CONFIG_CMD_GPT_RENAME is enabled, but is confusing so remove it.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 964056bd28..fe9e06681c 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -1060,8 +1060,6 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
"  gpt_partition_name, gpt_partition_entry\n"
" gpt enumerate mmc 0\n"
"- store list of partitions to gpt_partition_list environment 
variable\n"
-   " read  \n"
-   "- read GPT into a data structure for manipulation\n"
" gpt guid  \n"
"- print disk GUID\n"
" gpt guid   \n"
-- 
2.33.0

[PATCH v4 0/8] cmd: gpt: GPT manipulation improvements

[Joshua Watt]

Adds several improvements and additions to the gpt command processing,
specifically (although not exclusively) for the purpose of supporting
"ping-pong" booting when doing A/B boot partitions with u-boot itself.

In this mechanism, u-boot must boot up, and then check if the correct
boot partition is active, and if not switch the GPT partition table to
the other boot partition and reboot to activate the other u-boot.

In order to facilitate this, the gpt command needs to be better at
preserving entry attributes when manipulating the partition table. It
also learns two new commands, one which can swap the order of partitions
in the table, and another that lets it change which partitions have the
bootable flag.

V2: Add documentation and tests
V3: Review Feedback
V4: More review feedback. Fixed 'gpt swap-partition' to work with
missing partition indexes.

Joshua Watt (8):
  cmd: gpt: Remove confusing help text
  doc: Add gpt command documentation
  tests: gpt: Remove test order dependency
  cmd: gpt: Add gpt_partition_bootable variable
  cmd: gpt: Add command to set bootable flags
  cmd: gpt: Preserve type GUID if enabled
  cmd: gpt: Preserve bootable flag
  cmd: gpt: Add command to swap partition order

 cmd/gpt.c | 156 --
 doc/usage/cmd/gpt.rst | 226 ++
 doc/usage/index.rst   |   1 +
 test/py/tests/test_gpt.py | 160 +--
 4 files changed, 524 insertions(+), 19 deletions(-)
 create mode 100644 doc/usage/cmd/gpt.rst

-- 
2.33.0

Re: [PATCH V5 02/17] include: configs: am62x_evm: Drop unused SDRAM address

[Marcel Ziswiler]

On Thu, 2023-08-24 at 18:15 +0200, Francesco Dolcini wrote:

[snip]

> > > > > What about include/configs/verdin-am62.h ?
> > > > > 
> > > > > It seems that that board, which is am62x based, also has the un-needed
> > > > > include.
> > > > > 
> > > > > Since i'm not 100% sure, I have added Marcel (who posted the verdin 
> > > > > am62
> > > > > support) here.
> > > > 
> > > > Toradex team, Can you handle that cleanup? I stayed focussed on 
> > > > am62x_evm side
> > > > of things.
> > > 
> > > Yes, of course.
> > 
> > I believe that this is used on verdin-am62, please double check marcel.
> 
> No, likely I need to go home and not spread incomplete information here ...

(;-p)

We took care of it.

https://lore.kernel.org/all/20230828215037.482278-1-mar...@ziswiler.com

Thanks!

Cheers

Marcel

Re: [PATCH v5 00/13] Add video damage tracking

[Heinrich Schuchardt]

On 8/28/23 22:24, Alexander Graf wrote:


On 28.08.23 19:54, Simon Glass wrote:

Hi Alex,

On Wed, 23 Aug 2023 at 02:56, Alexander Graf  wrote:

Hey Simon,

On 22.08.23 20:56, Simon Glass wrote:

Hi Alex,

On Tue, 22 Aug 2023 at 01:47, Alexander Graf  wrote:

On 22.08.23 01:03, Simon Glass wrote:

Hi Alex,

On Mon, 21 Aug 2023 at 16:40, Alexander Graf  wrote:

On 22.08.23 00:10, Simon Glass wrote:

Hi Alex,

On Mon, 21 Aug 2023 at 14:20, Alexander Graf 
wrote:

On 21.08.23 21:57, Simon Glass wrote:

Hi Alex,

On Mon, 21 Aug 2023 at 13:33, Alexander Graf 
wrote:

On 21.08.23 21:11, Simon Glass wrote:

Hi Alper,

On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak
 wrote:

This is a rebase of Alexander Graf's video damage tracking
series, with
some tests and other changes. The original cover letter is
as follows:


This patch set speeds up graphics output on ARM by a
factor of 60x.

On most ARM SBCs, we keep the frame buffer in DRAM and map
it as cached,
but need it accessible by the display controller which
reads directly
from a later point of consistency. Hence, we flush the
frame buffer to
DRAM on every change. The full frame buffer.

It should not, see below.


Unfortunately, with the advent of 4k displays, we are
seeing frame buffers
that can take a while to flush out. This was reported by
Da Xue with grub,
which happily print 1000s of spaces on the screen to draw
a menu. Every
printed space triggers a cache flush.

That is a bug somewhere in EFI.

Unfortunately not :). You may call it a bug in grub: It
literally prints
over space characters for every character in its menu that it
wants
cleared. On every text screen draw.

This wouldn't be a big issue if we only flush the reactangle
that gets
modified. But without this patch set, we're flushing the full
DRAM
buffer on every u-boot text console character write, which
means for
every character (as that's the only API UEFI has).

As a nice side effect, we speed up the normal U-Boot text
console as
well with this patch set, because even "normal" text prints
that write
for example a single line of text on the screen today flush
the full
frame buffer to DRAM.

No, I mean that it is a bug that U-Boot (apparently) flushes
the cache
after every character. It doesn't do that for normal character
output
and I don't think it makes sense to do it for EFI either.

I see. Let's trace the calls:

efi_cout_output_string()
-> fputs()
-> vidconsole_puts()
-> video_sync()
-> flush_dcache_range()

Unfortunately grub abstracts character backends down to the "print
character" level, so it calls UEFI's sopisticated "output_string"
callback with single characters at a time, which means we do a
full
dcache flush for every character that we print:

https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/efi/console.c#n165



This patch set implements the easiest mitigation against
this problem:
Damage tracking. We remember the lowest common denominator
region that was
touched since the last video_sync() call and only flush
that. The most
typical writer to the frame buffer is the video console,
which always
writes rectangles of characters on the screen and syncs
afterwards.

With this patch set applied, we reduce drawing a large
grub menu (with
serial console attached for size information) on an
RK3399-ROC system
at 1440p from 55 seconds to less than 1 second.

Version 2 also implements VIDEO_COPY using this mechanism,
reducing its
overhead compared to before as well. So even x86 systems
should be faster
with this now :).


Alternatives considered:

    1) Lazy sync - Sandbox does this. It only calls
video_sync(true) ever
   so often. We are missing timers to do this
generically.

    2) Double buffering - We could try to identify
whether anything changed
   at all and only draw to the FB if it did. That
would require
   maintaining a second buffer that we need to scan.

    3) Text buffer - Maintain a buffer of all text
printed on the screen with
   respective location. Don't write if the old and
new character are
   identical. This would limit applicability to
text only and is an
   optimization on top of this patch set.

    4) Hash screen lines - Create a hash (sha256?)
over every line when it
   changes. Only flush when it does. I'm not sure
if this would waste
   more time, memory and cache than the current
approach. It would make
   full screen updates much more expensive.

5) Fix the bug mentioned above?


Changes in v5:
- Add patch "video: test: Split copy frame buffer check
into a function"
- Add patch "video: test: Support checking copy frame
buffer contents"
- Add patch "video: test: Test partial updates of hardware
frame buffer"
- Use xstart, ystart, xend, yend as names for damage region
- Document damage struct and fields in struct video_priv
comment
- Return void from video_damage()
- Fix undeclared priv error in video_sync()
- Drop unused headers from video-uclass.c
- Use 

Re: [PATCH v3 2/8] doc: Add gpt command documentation

[Joshua Watt]

On Fri, Aug 25, 2023 at 5:53 PM Simon Glass  wrote:
>
> Hi Joshua,
>
> On Fri, 25 Aug 2023 at 13:38, Joshua Watt  wrote:
> >
> > Adds initial documentation for the gpt command
> >
> > Signed-off-by: Joshua Watt 
> > ---
> >  doc/usage/cmd/gpt.rst | 141 ++
> >  doc/usage/index.rst   |   1 +
> >  2 files changed, 142 insertions(+)
> >  create mode 100644 doc/usage/cmd/gpt.rst
>
> I don't see a change log?

Sorry, I didn't realize patman was a thing until I just looked now;
I've just been using git send-email, and I'm not really sure how to
switch over to patman now; I'll start with it next time though.

>
> Reviewed-by: Simon Glass 

[PATCH v1] include: configs: verdin-am62: drop unused sdram address

[Marcel Ziswiler]

From: Marcel Ziswiler 

Drop unused macro. This was copied straight from the AM62x EVM but while
meant for a second region of DDR this is not even needed for the AM62x
EVM configurations and has meanwhile also been dropped there.

Note that on the Verdin AM62, we do auto-detect the amount of SDRAM.

While at it also update the comment noting that CFG_SYS_SDRAM_SIZE is
the maximum which is only used for such auto-detection.

Signed-off-by: Marcel Ziswiler 

---

 include/configs/verdin-am62.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/configs/verdin-am62.h b/include/configs/verdin-am62.h
index 7990ea83102..e1a5f5ad44b 100644
--- a/include/configs/verdin-am62.h
+++ b/include/configs/verdin-am62.h
@@ -13,8 +13,7 @@
 
 /* DDR Configuration */
 #define CFG_SYS_SDRAM_BASE 0x8000
-#define CFG_SYS_SDRAM_BASE10x88000
-#define CFG_SYS_SDRAM_SIZE SZ_2G /* Maximum supported size */
+#define CFG_SYS_SDRAM_SIZE SZ_2G /* Maximum supported size, auto-detection 
is used */
 
 #define MEM_LAYOUT_ENV_SETTINGS \
"fdt_addr_r=0x9020\0" \
-- 
2.36.1

Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Sam Edwards]

On 8/26/23 04:22, Marc Zyngier wrote:

Hi Marc!


The GIC definitely has the NS bit routed to it. Otherwise, the secure
configuration would just be an utter joke. Just try it.


Thank you for your response. I'd like to revisit my prior point about 
the distinction between the NS bit and AxPROT[1] bits in the context of 
monitor mode: in monitor mode, the NS bit does not determine the 
security state of the CPU core (monitor mode is always secure). But even 
then, the NS bit is still significant for other purposes, such as to 
bank accesses to certain CP15 registers -- and if I understand Chen-Yu 
correctly, some GIC registers also. That would require a special NS bit 
signal routed to the GIC so that it can distinguish between "secure, 
NS=0" and "secure, NS=1" accesses, which is why I asked if such a thing 
exists.


I understand that the GIC is designed to be aware of the security state 
(using the existing AxPROT[1] signals) so that it can protect the 
sensitive registers. And unless I misunderstand, this seems to be the 
point that you made here (my interpretation -- correct me if I'm wrong 
-- is that you are using "NS bit" as a metonym for "security state"). 
However I must clarify that my question was to seek further information 
from Chen-Yu about the possibility that NS is significant when accessing 
the GIC, even in monitor mode. Alternatively, his point might be merely 
highlighting that the GIC permits different types of access depending on 
the CPU's security state, which aligns with the viewpoint you've reiterated.


I apologize if my previous message didn't convey this context clearly 
enough. My goal was to unravel this nuanced aspect of the NS bit when in 
monitor mode, and to determine if NS needs to be getting set/cleared 
during GIC setup to maneuver around the banking, or if the value of the 
NS bit when in psci_arch_init() is truly of no consequence due to 
monitor mode.



Well, history is unfortunately against you on that front. Running on
the secure side definitely was a requirement when this code was
initially written, as the AW BSP *required* to run on the secure side.

If that requirement is no more, great. But I don't think you can
decide that unilaterally.


I have no idea when/if this requirement was changed. It might have never 
happened "formally": perhaps at some point, the SCR.NS=1 code got added 
after the call to psci_arch_init(), breaking (that version of) the AW 
BSP, and nobody ever complained or changed it back... so it stayed.


But we're starting to digress from what _this_ patch does. The intent 
here is only to remove two lines of code that (we're discussing to 
confirm) have no effect. I'm not touching the code that *actually* 
determines the world into which monitor mode exits.


Cheers,
Sam

[PATCH v1] board: toradex: verdin-imx8mp: enable usb device and fastboot support

[Marcel Ziswiler]

From: Marcel Ziswiler 

Enable USB device and fastboot support which may be used to load the
Toradex Easy Installer FIT image.

While at it also enable USB mass storage aka UMS support.

Note that the i.MX 8M Plus recovery mode support is based on the USB
boot stage of the BOOTROM and does NOT require USB SDP SPL aka serial
downloader support.

Signed-off-by: Marcel Ziswiler 

---

 configs/verdin-imx8mp_defconfig | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/configs/verdin-imx8mp_defconfig b/configs/verdin-imx8mp_defconfig
index 2df0f4f3443..4c6650c3453 100644
--- a/configs/verdin-imx8mp_defconfig
+++ b/configs/verdin-imx8mp_defconfig
@@ -79,6 +79,7 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_READ=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
@@ -108,6 +109,12 @@ CONFIG_BOOTCOUNT_ENV=y
 CONFIG_CLK_COMPOSITE_CCF=y
 CONFIG_CLK_IMX8MP=y
 CONFIG_FSL_CAAM=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x4280
+CONFIG_FASTBOOT_BUF_SIZE=0x4000
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_UUU_SUPPORT=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_GPIO_HOG=y
 CONFIG_SPL_GPIO_HOG=y
 CONFIG_MXC_GPIO=y
@@ -138,6 +145,7 @@ CONFIG_DWC_ETH_QOS_IMX=y
 CONFIG_FEC_MXC=y
 CONFIG_RGMII=y
 CONFIG_MII=y
+CONFIG_PHY=y
 CONFIG_PHY_IMX8MQ_USB=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
@@ -160,14 +168,20 @@ CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
 CONFIG_IMX_TMU=y
 CONFIG_USB=y
+# CONFIG_SPL_DM_USB is not set
+CONFIG_DM_USB_GADGET=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_XHCI_DWC3_OF_SIMPLE=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_MXC_USB_OTG_HACTIVE=y
+# CONFIG_USB_EHCI_MX7 is not set
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GENERIC=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Toradex"
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
+CONFIG_USB_GADGET_PRODUCT_NUM=0x4000
 CONFIG_IMX_WATCHDOG=y
 CONFIG_HEXDUMP=y
-- 
2.36.1

Re: [PATCH v3 2/8] doc: Add gpt command documentation

[Joshua Watt]

On Mon, Aug 28, 2023 at 2:00 PM Heinrich Schuchardt  wrote:
>
> On 8/28/23 21:29, Joshua Watt wrote:
> > On Fri, Aug 25, 2023 at 7:57 PM Heinrich Schuchardt  
> > wrote:
> >>
> >> On 8/25/23 21:38, Joshua Watt wrote:
> >>> Adds initial documentation for the gpt command
> >>
> >> Thanks a lot for filling the gap.
> >>
> >>>
> >>> Signed-off-by: Joshua Watt 
> >>> ---
> >>>doc/usage/cmd/gpt.rst | 141 ++
> >>>doc/usage/index.rst   |   1 +
> >>>2 files changed, 142 insertions(+)
> >>>create mode 100644 doc/usage/cmd/gpt.rst
> >>>
> >>> diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
> >>> new file mode 100644
> >>> index 00..f6e082fb94
> >>> --- /dev/null
> >>> +++ b/doc/usage/cmd/gpt.rst
> >>> @@ -0,0 +1,141 @@
> >>> +.. SPDX-License-Identifier: GPL-2.0+
> >>> +
> >>> +gpt command
> >>> +===
> >>> +
> >>> +Synopsis
> >>> +
> >>> +
> >>> +::
> >>> +
> >>> +gpt repair  
> >>> +gpt write   
> >>> +gpt verify   
> >>
> >>  is not required. Please, add brackets [].
> >
> > It's not optional; there is no standardized string for the list of GPT
> > partitions like there is for MBR
>
> You can use the command without partition string. It will tell you if
> the device is partitioned or not.

Ah, right. I missed that

>
> >
> >>
> >>> +gpt setenv   
> >>
> >> gpt setenv can be called without partition name which leads to a crash.
> >>
> >> If that parameter is meant to be optional, this should be indicated
> >> here. Otherwise an argc check is missing.
> >
> > I don't believe the argument is optional, but either way it can be
> > fixed in a subsequent patch series. I'd rather not hold up the
> > documentation to fix bugs
> >
> >>
> >>> +gpt enumerate  
> >>> +gpt guid   []
> >>> +gpt read   []
> >>> +gpt swap
> >>> +gpt rename
> >>
> >> Thanks a lot for providing a man-page for this command.
> >>
> >> If  and  both relate to the same object type, we should
> >> use the same text.  would be fine.
> >>
> >> The sequence looks random. Please, sort the sub-commands either
> >> logically or alphabetically.
> >
> > They are sorted to match the gpt command help text. Reordering of both
> > can be done later if desired.
>
> There is no requirement to follow the gpt help =sequence here.
>
> We should not reproduce what is not helpful.
>
> Best regards
>
> Heinrich
>
> >
> >>
> >>> +
> >>> +Description
> >>> +---
> >>> +
> >>> +The gpt command lets users read, create, modify, or verify the GPT (GUID
> >>> +Partition Table) partition layout.
> >>> +
> >>> +The syntax of the text description of the partition list is similar to
> >>> +the one used by the 'mbr' command. The string contains one or more 
> >>> partition
> >>
> >> Please, link the mbr page:
> >>
> >> by the :doc:`mbr command `.
> >>
> >>> +descriptors, each separated by a ";". Each descriptor contains one or 
> >>> more
> >>> +fields, with each field separated by a ",". Fields are either of the form
> >>> +"key=value" to set a specific value, or simple "flag" to set a boolean 
> >>> flag
> >>
> >> At this point it remains unclear to the reader what this ;-separated
> >> string format relates to.
> >> Is it an output format?
> >> Is it a format used in variables?
> >> Is it used for the parameter 'partition string'?
> >>
> >> Maybe describe it after the parameters and relate it to the 'partition
> >> string' parameter.
> >>
> >> Please, describe all parameters (in this indented format):
> >>
> >> interface
> >>   interface for accessing the block device (mmc, sata, scsi, usb, )
> >>
> >> device no
> >>   device number
> >>
> >> ...
> >>
> >>> +
> >>> +The first descriptor can optionally be used to describe parameters for 
> >>> the
> >>> +whole disk with the following fields:
> >>> +
> >>> +* uuid_disk=UUID - Set the UUID for the disk
> >>> +
> >>> +Partition descriptors can have the following fields:
> >>> +* name=NAME - The partition name, required
> >>
> >> Maybe better
> >>
> >> name=
> >>
> >> This is not rendered as an unordered list but everything is in one line.
> >> Please, add the missing blank lines.
> >>
> >> Please, generate the HTML documentation as described in
> >> https://u-boot.readthedocs.io/en/latest/build/documentation.html
> >> and check the output before resubmitting.
> >>
> >>> +* start=BYTES - The partition start offset in bytes, required
> >>> +* size=BYTES - The partition size, in bytes or "-" to expand it to the 
> >>> whole free area
> >>> +* bootable - Set the legacy bootable flag
> >>> +* uuid=UUID - Set the partition UUID, optional if CONFIG_RANDOM_UUID=y 
> >>> is enabled
> >>> +* type=UUID - Set the partition type GUID, requires 
> >>> CONFIG_PARTITION_TYPE_GUID=y
> >>> +
> >>
> >> The following should be in a separate 'Examples' section to match the
> >> other man-pages.
> >>
> >>> +Here is an example how to create a 6 partitions, some of the predefined 
> >>> sizes:
> >>> +
> >>> 

Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default

[Alexander Graf]

On 28.08.23 22:38, Simon Glass wrote:

Hi Alper,

On Mon, 28 Aug 2023 at 12:29, Alper Nebi Yasak  wrote:

On 2023-08-28 20:54 +03:00, Simon Glass wrote:

Hi Alper,
On Mon, 28 Aug 2023 at 09:46, Alper Nebi Yasak  wrote:

On 2023-08-22 21:56 +03:00, Simon Glass wrote:

Hi Alper,

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:

From: Alexander Graf 

Now that we have everything in place to support ramfb, let's wire it up
by default in the ARM QEMU targets. That way, you can easily use a
graphical console by just passing -device ramfb to the QEMU command line.

Signed-off-by: Alexander Graf 
[Alper: Rebase on bochs changes, add pre-reloc init, error handling]
Co-developed-by: Alper Nebi Yasak 
Signed-off-by: Alper Nebi Yasak 
---

Changes in v2:
- Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
- Drop env changes from ARM (necessary but in prerequisite series)
- Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
- Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
- Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU

  arch/arm/Kconfig|  3 +++
  board/emulation/qemu-arm/qemu-arm.c | 41 +
  2 files changed, 44 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1fd3ccd1607f..7afe26ac804f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1046,6 +1046,9 @@ config ARCH_QEMU
 imply USB_XHCI_PCI
 imply USB_KEYBOARD
 imply CMD_USB
+   imply VIDEO_RAMFB
+   imply BOARD_EARLY_INIT_F
+   imply BOARD_EARLY_INIT_R

  config ARCH_RMOBILE
 bool "Renesas ARM SoCs"
diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 942f1fff5717..23ef31cb7feb 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
  struct mm_region *mem_map = qemu_arm64_mem_map;
  #endif

+int board_early_init_f(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   /*
+* Make sure we enumerate the QEMU Firmware device to bind ramfb
+* so video_reserve() can reserve memory for it.
+*/
+   if (IS_ENABLED(CONFIG_QFW)) {
+   ret = qfw_get_dev();
+   if (ret) {
+   log_err("Failed to get QEMU FW device: %d\n", ret);

We should only present an error if the device is present but
failed...so if the user doesn't provide the flag, all should be well.

I don't understand what you mean by "user doesn't provide the flag". But
I assume this should ignore the error (unless what?) so that we can
continue to boot. Would that apply for board_early_init_r below as well?

I thought you said there was a qemu flag to enable ramfb? So add it to
the DT and then the device can (in its bind routine) decide not to be
bound by returning -ENODEV

Ah. I'm not used to calling them flags, especially those that have
values as in "-device ramfb". My mind jumped to DM_FLAG_PRE_RELOC /
bootph-some-ram.

But note that what this code tries to probe here is not the ramfb
device, it's the bus/parent of that. If this fails, we can't know if the
user specified "-device ramfb" or not.

Is the parent node's device probed by the time .bind() is called? Or,
can I have it probed by calling qfw_get_dev() (which is just
uclass_first_device_err(UCLASS_QFW, ...))?

I suppose your problem might be that there are up to three possible
video devices (vesa, bochs, ramfb) and one of them needs to return 0
from bind() and the others need to return -ENODEV?



How do multiple Legacy VGA devices work in parallel in the first place? 
Do we access the legacy VGA PIO ports or memory ranges? If so, which of 
the VGA devices owns it at which point in time?


IIRC the only way you can actually multiplex real VGA is by putting a 
VGA arbiter[1] in between that literally maps the BARs in and out or 
enables/disables device mapping dynamically, no?


It probably makes most sense to make multiple video outputs work 
smoothly with at most 1 VGA device at a time for now to resolve any 
U-Boot internal infrastructure problems, then maybe later try multiple VGAs.



Alex

[1] https://docs.kernel.org/gpu/vgaarbiter.html

[PATCH 1/1] video: fix typo in video_sync_all documentation

[Heinrich Schuchardt]

%s/there/their/

Signed-off-by: Heinrich Schuchardt 
---
 include/video.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/video.h b/include/video.h
index 269915160b..16f7a83f8d 100644
--- a/include/video.h
+++ b/include/video.h
@@ -260,7 +260,7 @@ int video_fill_part(struct udevice *dev, int xstart, int 
ystart, int xend,
 int video_sync(struct udevice *vid, bool force);
 
 /**
- * video_sync_all() - Sync all devices' frame buffers with there hardware
+ * video_sync_all() - Sync all devices' frame buffers with their hardware
  *
  * This calls video_sync() on all active video devices.
  */
-- 
2.40.1

Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default

[Simon Glass]

Hi Alper,

On Mon, 28 Aug 2023 at 12:29, Alper Nebi Yasak  wrote:
>
> On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> > Hi Alper,
> > On Mon, 28 Aug 2023 at 09:46, Alper Nebi Yasak  
> > wrote:
> >>
> >> On 2023-08-22 21:56 +03:00, Simon Glass wrote:
> >>> Hi Alper,
> >>>
> >>> On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  
> >>> wrote:
> 
>  From: Alexander Graf 
> 
>  Now that we have everything in place to support ramfb, let's wire it up
>  by default in the ARM QEMU targets. That way, you can easily use a
>  graphical console by just passing -device ramfb to the QEMU command line.
> 
>  Signed-off-by: Alexander Graf 
>  [Alper: Rebase on bochs changes, add pre-reloc init, error handling]
>  Co-developed-by: Alper Nebi Yasak 
>  Signed-off-by: Alper Nebi Yasak 
>  ---
> 
>  Changes in v2:
>  - Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
>  - Drop env changes from ARM (necessary but in prerequisite series)
>  - Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
>  - Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
>  - Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU
> 
>   arch/arm/Kconfig|  3 +++
>   board/emulation/qemu-arm/qemu-arm.c | 41 +
>   2 files changed, 44 insertions(+)
> 
>  diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>  index 1fd3ccd1607f..7afe26ac804f 100644
>  --- a/arch/arm/Kconfig
>  +++ b/arch/arm/Kconfig
>  @@ -1046,6 +1046,9 @@ config ARCH_QEMU
>  imply USB_XHCI_PCI
>  imply USB_KEYBOARD
>  imply CMD_USB
>  +   imply VIDEO_RAMFB
>  +   imply BOARD_EARLY_INIT_F
>  +   imply BOARD_EARLY_INIT_R
> 
>   config ARCH_RMOBILE
>  bool "Renesas ARM SoCs"
>  diff --git a/board/emulation/qemu-arm/qemu-arm.c 
>  b/board/emulation/qemu-arm/qemu-arm.c
>  index 942f1fff5717..23ef31cb7feb 100644
>  --- a/board/emulation/qemu-arm/qemu-arm.c
>  +++ b/board/emulation/qemu-arm/qemu-arm.c
>  @@ -11,6 +11,7 @@
>   #include 
>   #include 
>   #include 
>  +#include 
>   #include 
>   #include 
>   #include 
>  @@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
>   struct mm_region *mem_map = qemu_arm64_mem_map;
>   #endif
> 
>  +int board_early_init_f(void)
>  +{
>  +   struct udevice *dev;
>  +   int ret;
>  +
>  +   /*
>  +* Make sure we enumerate the QEMU Firmware device to bind ramfb
>  +* so video_reserve() can reserve memory for it.
>  +*/
>  +   if (IS_ENABLED(CONFIG_QFW)) {
>  +   ret = qfw_get_dev();
>  +   if (ret) {
>  +   log_err("Failed to get QEMU FW device: %d\n", 
>  ret);
> >>>
> >>> We should only present an error if the device is present but
> >>> failed...so if the user doesn't provide the flag, all should be well.
> >>
> >> I don't understand what you mean by "user doesn't provide the flag". But
> >> I assume this should ignore the error (unless what?) so that we can
> >> continue to boot. Would that apply for board_early_init_r below as well?
> >
> > I thought you said there was a qemu flag to enable ramfb? So add it to
> > the DT and then the device can (in its bind routine) decide not to be
> > bound by returning -ENODEV
>
> Ah. I'm not used to calling them flags, especially those that have
> values as in "-device ramfb". My mind jumped to DM_FLAG_PRE_RELOC /
> bootph-some-ram.
>
> But note that what this code tries to probe here is not the ramfb
> device, it's the bus/parent of that. If this fails, we can't know if the
> user specified "-device ramfb" or not.
>
> Is the parent node's device probed by the time .bind() is called? Or,
> can I have it probed by calling qfw_get_dev() (which is just
> uclass_first_device_err(UCLASS_QFW, ...))?

I suppose your problem might be that there are up to three possible
video devices (vesa, bochs, ramfb) and one of them needs to return 0
from bind() and the others need to return -ENODEV?

Perhaps another way would be to update the logic in
stdio_init_tables() to find them all (which I believe it already
does?) and then select one?

Regards,
Simon

Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default

[Alexander Graf]

On 28.08.23 20:28, Alper Nebi Yasak wrote:

On 2023-08-28 20:54 +03:00, Simon Glass wrote:

Hi Alper,
On Mon, 28 Aug 2023 at 09:46, Alper Nebi Yasak  wrote:

On 2023-08-22 21:56 +03:00, Simon Glass wrote:

Hi Alper,

On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  wrote:

From: Alexander Graf 

Now that we have everything in place to support ramfb, let's wire it up
by default in the ARM QEMU targets. That way, you can easily use a
graphical console by just passing -device ramfb to the QEMU command line.

Signed-off-by: Alexander Graf 
[Alper: Rebase on bochs changes, add pre-reloc init, error handling]
Co-developed-by: Alper Nebi Yasak 
Signed-off-by: Alper Nebi Yasak 
---

Changes in v2:
- Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
- Drop env changes from ARM (necessary but in prerequisite series)
- Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
- Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
- Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU

  arch/arm/Kconfig|  3 +++
  board/emulation/qemu-arm/qemu-arm.c | 41 +
  2 files changed, 44 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1fd3ccd1607f..7afe26ac804f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1046,6 +1046,9 @@ config ARCH_QEMU
 imply USB_XHCI_PCI
 imply USB_KEYBOARD
 imply CMD_USB
+   imply VIDEO_RAMFB
+   imply BOARD_EARLY_INIT_F
+   imply BOARD_EARLY_INIT_R

  config ARCH_RMOBILE
 bool "Renesas ARM SoCs"
diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 942f1fff5717..23ef31cb7feb 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
  struct mm_region *mem_map = qemu_arm64_mem_map;
  #endif

+int board_early_init_f(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   /*
+* Make sure we enumerate the QEMU Firmware device to bind ramfb
+* so video_reserve() can reserve memory for it.
+*/
+   if (IS_ENABLED(CONFIG_QFW)) {
+   ret = qfw_get_dev();
+   if (ret) {
+   log_err("Failed to get QEMU FW device: %d\n", ret);

We should only present an error if the device is present but
failed...so if the user doesn't provide the flag, all should be well.

I don't understand what you mean by "user doesn't provide the flag". But
I assume this should ignore the error (unless what?) so that we can
continue to boot. Would that apply for board_early_init_r below as well?

I thought you said there was a qemu flag to enable ramfb? So add it to
the DT and then the device can (in its bind routine) decide not to be
bound by returning -ENODEV

Ah. I'm not used to calling them flags, especially those that have
values as in "-device ramfb". My mind jumped to DM_FLAG_PRE_RELOC /
bootph-some-ram.

But note that what this code tries to probe here is not the ramfb
device, it's the bus/parent of that. If this fails, we can't know if the
user specified "-device ramfb" or not.



You bring up a great point here. I don't think we should model the 
actual ramfb device as device tree (platform) device. It's 100% 
enumerable from QFW which means we should treat it as a dynamic entity 
that gets created by QFW instead of from device tree, just like USB or 
PCI devices.


And when you do that, everything should fall into place nicely: You 
don't need to dynamically modify device trees on boot, the DT you get 
from QEMU is sufficient to enumerate everything, etc etc.



Alex

Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Peter Robinson]

On Mon, Aug 28, 2023 at 6:54 PM Simon Glass  wrote:
>
> Hi Peter,
>
> On Mon, 28 Aug 2023 at 10:37, Peter Robinson  wrote:
> >
> > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass  wrote:
> > >
> > > Hi,
> > >
> > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  
> > > wrote:
> > > >
> > > >
> > > > Provide a way for removing certain devicetree nodes and/or properties
> > > > from the devicetree. This is needed to purge certain nodes and
> > > > properties which may be relevant only in U-Boot. Such nodes and
> > > > properties are then removed from the devicetree before it is passed to
> > > > the kernel. This ensures that the devicetree passed to the OS does not
> > > > contain any non-compliant nodes and properties.
> > > >
> > > > The removal of the nodes and properties is being done through an
> > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> > > > behind any Kconfig symbol.
> > > >
> > > > I have only build tested this on sandbox, and tested on qemu arm64
> > > > virt platform. This being a RFC, I have not put this through a CI run.
> > > >
> > > > Sughosh Ganu (5):
> > > >   dt: Provide a way to remove non-compliant nodes and properties
> > > >   fwu: Add the fwu-mdata node for removal from devicetree
> > > >   capsule: Add the capsule-key property for removal from devicetree
> > > >   bootefi: Call the EVT_FT_FIXUP event handler
> > > >   doc: Add a document for non-compliant DT node/property removal
> > > >
> > > >  cmd/bootefi.c | 18 +
> > > >  .../devicetree/dt_non_compliant_purge.rst | 64 
> > > >  drivers/fwu-mdata/fwu-mdata-uclass.c  |  5 ++
> > > >  include/dt-structs.h  | 11 +++
> > > >  lib/Makefile  |  1 +
> > > >  lib/dt_purge.c| 73 +++
> > > >  lib/efi_loader/efi_capsule.c  |  7 ++
> > > >  7 files changed, 179 insertions(+)
> > > >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> > > >  create mode 100644 lib/dt_purge.c
> > >
> > > What is the point of removing them? Instead, we should make sure that
> > > we upstream the bindings and encourage SoC vendors to sync them. If we
> > > remove them, no one will bother and U-Boot just becomes a dumping
> > > ground.
> >
> > Well things like the binman entries in DT are U-Boot specific and not
> > useful for HW related descriptions or for Linux or another OS being
> > able to deal with HW so arguably we're already a dumping ground to
> > some degree for not defining hardware.
>
> I have started the process to upstream the binman bindings.

I don't think they should be in DT at all, they don't describe
anything to do with hardware, or generally even the runtime of a
device, they don't even describe the boot/runtime state of the
firmware, they describe build time, so I don't see what that has to do
with device tree? Can you explain that? To me those sorts of things
should live in a build time style config file.

> Perhaps we should use the issue tracker[1] to follow progress on all
> of this. We need to clean it up.
>
> >
> > > Instead of this, how about working on bringing the DT validation into
> > > U-Boot so we can see what state things are in?
> > >
> > > Please send the bindings for Linaro's recent series (which I suspect
> > > are motivating this series) so we can start the process.
>
> Regards,
> Simon
>
> [1] https://source.denx.de/u-boot/u-boot/-/issues

Re: [PATCH v5 00/13] Add video damage tracking

[Alexander Graf]

On 28.08.23 19:54, Simon Glass wrote:

Hi Alex,

On Wed, 23 Aug 2023 at 02:56, Alexander Graf  wrote:

Hey Simon,

On 22.08.23 20:56, Simon Glass wrote:

Hi Alex,

On Tue, 22 Aug 2023 at 01:47, Alexander Graf  wrote:

On 22.08.23 01:03, Simon Glass wrote:

Hi Alex,

On Mon, 21 Aug 2023 at 16:40, Alexander Graf  wrote:

On 22.08.23 00:10, Simon Glass wrote:

Hi Alex,

On Mon, 21 Aug 2023 at 14:20, Alexander Graf  wrote:

On 21.08.23 21:57, Simon Glass wrote:

Hi Alex,

On Mon, 21 Aug 2023 at 13:33, Alexander Graf  wrote:

On 21.08.23 21:11, Simon Glass wrote:

Hi Alper,

On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak  wrote:

This is a rebase of Alexander Graf's video damage tracking series, with
some tests and other changes. The original cover letter is as follows:


This patch set speeds up graphics output on ARM by a factor of 60x.

On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached,
but need it accessible by the display controller which reads directly
from a later point of consistency. Hence, we flush the frame buffer to
DRAM on every change. The full frame buffer.

It should not, see below.


Unfortunately, with the advent of 4k displays, we are seeing frame buffers
that can take a while to flush out. This was reported by Da Xue with grub,
which happily print 1000s of spaces on the screen to draw a menu. Every
printed space triggers a cache flush.

That is a bug somewhere in EFI.

Unfortunately not :). You may call it a bug in grub: It literally prints
over space characters for every character in its menu that it wants
cleared. On every text screen draw.

This wouldn't be a big issue if we only flush the reactangle that gets
modified. But without this patch set, we're flushing the full DRAM
buffer on every u-boot text console character write, which means for
every character (as that's the only API UEFI has).

As a nice side effect, we speed up the normal U-Boot text console as
well with this patch set, because even "normal" text prints that write
for example a single line of text on the screen today flush the full
frame buffer to DRAM.

No, I mean that it is a bug that U-Boot (apparently) flushes the cache
after every character. It doesn't do that for normal character output
and I don't think it makes sense to do it for EFI either.

I see. Let's trace the calls:

efi_cout_output_string()
-> fputs()
-> vidconsole_puts()
-> video_sync()
-> flush_dcache_range()

Unfortunately grub abstracts character backends down to the "print
character" level, so it calls UEFI's sopisticated "output_string"
callback with single characters at a time, which means we do a full
dcache flush for every character that we print:

https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/efi/console.c#n165



This patch set implements the easiest mitigation against this problem:
Damage tracking. We remember the lowest common denominator region that was
touched since the last video_sync() call and only flush that. The most
typical writer to the frame buffer is the video console, which always
writes rectangles of characters on the screen and syncs afterwards.

With this patch set applied, we reduce drawing a large grub menu (with
serial console attached for size information) on an RK3399-ROC system
at 1440p from 55 seconds to less than 1 second.

Version 2 also implements VIDEO_COPY using this mechanism, reducing its
overhead compared to before as well. So even x86 systems should be faster
with this now :).


Alternatives considered:

1) Lazy sync - Sandbox does this. It only calls video_sync(true) ever
   so often. We are missing timers to do this generically.

2) Double buffering - We could try to identify whether anything changed
   at all and only draw to the FB if it did. That would require
   maintaining a second buffer that we need to scan.

3) Text buffer - Maintain a buffer of all text printed on the screen 
with
   respective location. Don't write if the old and new character are
   identical. This would limit applicability to text only and is an
   optimization on top of this patch set.

4) Hash screen lines - Create a hash (sha256?) over every line when it
   changes. Only flush when it does. I'm not sure if this would waste
   more time, memory and cache than the current approach. It would make
   full screen updates much more expensive.

5) Fix the bug mentioned above?


Changes in v5:
- Add patch "video: test: Split copy frame buffer check into a function"
- Add patch "video: test: Support checking copy frame buffer contents"
- Add patch "video: test: Test partial updates of hardware frame buffer"
- Use xstart, ystart, xend, yend as names for damage region
- Document damage struct and fields in struct video_priv comment
- Return void from video_damage()
- Fix undeclared priv error in video_sync()
- Drop unused headers from video-uclass.c
- Use IS_ENABLED() instead of 

Re: [PATCH v3 5/9] board: qualcomm: Add support for dragonboard845c

[Peter Robinson]

On Mon, Aug 28, 2023 at 6:55 PM Simon Glass  wrote:
>
> Hi Sumit,
>
> On Thu, 24 Aug 2023 at 04:44, Sumit Garg  wrote:
> >
> > Hi Simon,
> >
> > On Thu, 24 Aug 2023 at 05:29, Simon Glass  wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Tue, 12 Jul 2022 at 01:12, Sumit Garg  wrote:
> > > >
> > > > Add support for 96Boards Dragonboard 845C aka Robotics RB3 development
> > > > platform. This board complies with 96Boards Open Platform 
> > > > Specifications.
> > > >
> > > > Features:
> > > > - Qualcomm Snapdragon SDA845 SoC
> > > > - 4GiB RAM
> > > > - 64GiB UFS drive
> > > >
> > > > U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> > > > For detailed build and boot instructions, refer to
> > > > doc/board/qualcomm/sdm845.rst, board: dragonboard845c.
> > > >
> > > > Signed-off-by: Sumit Garg 
> > > > Reviewed-by: Ramon Fried 
> > > > ---
> > > >  arch/arm/dts/dragonboard845c-uboot.dtsi   |  37 +++
> > > >  arch/arm/dts/dragonboard845c.dts  |  44 
> > > >  arch/arm/mach-snapdragon/Kconfig  |  14 +++
> > > >  board/qualcomm/dragonboard845c/Kconfig|  12 +++
> > > >  board/qualcomm/dragonboard845c/MAINTAINERS|   6 ++
> > > >  board/qualcomm/dragonboard845c/Makefile   |   9 ++
> > > >  board/qualcomm/dragonboard845c/db845c.its |  63 +++
> > > >  .../dragonboard845c/dragonboard845c.c |   9 ++
> > > >  configs/dragonboard845c_defconfig |  28 +
> > > >  doc/board/qualcomm/sdm845.rst | 100 +++---
> > > >  include/configs/dragonboard845c.h |  28 +
> > > >  11 files changed, 337 insertions(+), 13 deletions(-)
> > > >  create mode 100644 arch/arm/dts/dragonboard845c-uboot.dtsi
> > > >  create mode 100644 arch/arm/dts/dragonboard845c.dts
> > > >  create mode 100644 board/qualcomm/dragonboard845c/Kconfig
> > > >  create mode 100644 board/qualcomm/dragonboard845c/MAINTAINERS
> > > >  create mode 100644 board/qualcomm/dragonboard845c/Makefile
> > > >  create mode 100644 board/qualcomm/dragonboard845c/db845c.its
> > > >  create mode 100644 board/qualcomm/dragonboard845c/dragonboard845c.c
> > > >  create mode 100644 configs/dragonboard845c_defconfig
> > > >  create mode 100644 include/configs/dragonboard845c.h
> > > >
> > > [..]
> > >
> > > > diff --git a/doc/board/qualcomm/sdm845.rst 
> > > > b/doc/board/qualcomm/sdm845.rst
> > > > index b6642c9579..8ef4749287 100644
> > > > --- a/doc/board/qualcomm/sdm845.rst
> > > > +++ b/doc/board/qualcomm/sdm845.rst
> > > > @@ -35,9 +35,25 @@ Pack android boot image
> > > >  ^^^
> > > >  We'll assemble android boot image with ``u-boot.bin`` instead of linux 
> > > > kernel,
> > > >  and FIT image instead of ``initramfs``. Android bootloader expect 
> > > > gzipped kernel
> > > > -with appended dtb, so let's mimic linux to satisfy stock bootloader:
> > > > +with appended dtb, so let's mimic linux to satisfy stock bootloader.
> > > >
> > >
> > > [..]
> > >
> > > > +The dragonboard845c is a Qualcomm Robotics RB3 Development Platform, 
> > > > based on
> > > > +the Qualcomm SDM845 SoC.
> > > > +
> > > > +Steps:
> > > > +
> > > > +- Build u-boot::
> > > > +
> > > > +   $ export CROSS_COMPILE=
> > > > +   $ make dragonboard845c_defconfig
> > > > +   $ make
> > > > +
> > > > +- Create dummy dtb::
> > > > +
> > > > +   workdir=/tmp/prepare_payload
> > > > +   mkdir -p "$workdir"
> > > > +   mock_dtb="$workdir"/payload_mock.dtb
> > > > +
> > > > +   dtc -I dts -O dtb -o "$mock_dtb" << EOF
> > > > +   /dts-v1/;
> > > > +   / {
> > > > +   #address-cells = <2>;
> > > > +   #size-cells = <2>;
> > > > +
> > > > +   memory@8000 {
> > > > +   device_type = "memory";
> > > > +   /* We expect the bootloader to fill in the size 
> > > > */
> > > > +   reg = <0 0x8000 0 0>;
> > > > +   };
> > > > +
> > > > +   chosen { };
> > > > +   };
> > > > +   EOF
> > > > +
> > > > +- gzip u-boot::
> > > > +
> > > > +   gzip u-boot.bin
> > > > +
> > > > +- Append dtb to gzipped u-boot::
> > > > +
> > > > +cat u-boot.bin.gz "$mock_dtb" > u-boot.bin.gz-dtb
> > > > +
> > > > +- A ``db845c.its`` file can be found in 
> > > > ``board/qualcomm/dragonboard845c/``
> > > > +  directory. It expects a folder as ``db845c_imgs/`` in the main 
> > > > directory
> > > > +  containing pre-built kernel, dts and ramdisk images. See 
> > > > ``db845c.its``
> > > > +  for full path to images::
> > > > +
> > > > +   mkimage -f db845c.its db845c.itb
> > > > +
> > > > +- Now we've got everything to build android boot image::
> > > > +
> > > > +   mkbootimg --kernel u-boot.bin.gz-dtb --ramdisk db845c.itb \
> > > > +   --output boot.img --pagesize 4096 --base 0x8000
> > > > +
> > > > +- Flash boot.img using db845c fastboot method.
> > >
> > > What command should be used here? I 

Re: [PATCH v3 2/8] doc: Add gpt command documentation

[Heinrich Schuchardt]

On 8/28/23 21:29, Joshua Watt wrote:

On Fri, Aug 25, 2023 at 7:57 PM Heinrich Schuchardt  wrote:


On 8/25/23 21:38, Joshua Watt wrote:

Adds initial documentation for the gpt command


Thanks a lot for filling the gap.



Signed-off-by: Joshua Watt 
---
   doc/usage/cmd/gpt.rst | 141 ++
   doc/usage/index.rst   |   1 +
   2 files changed, 142 insertions(+)
   create mode 100644 doc/usage/cmd/gpt.rst

diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
new file mode 100644
index 00..f6e082fb94
--- /dev/null
+++ b/doc/usage/cmd/gpt.rst
@@ -0,0 +1,141 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+gpt command
+===
+
+Synopsis
+
+
+::
+
+gpt repair  
+gpt write   
+gpt verify   


 is not required. Please, add brackets [].


It's not optional; there is no standardized string for the list of GPT
partitions like there is for MBR


You can use the command without partition string. It will tell you if
the device is partitioned or not.






+gpt setenv   


gpt setenv can be called without partition name which leads to a crash.

If that parameter is meant to be optional, this should be indicated
here. Otherwise an argc check is missing.


I don't believe the argument is optional, but either way it can be
fixed in a subsequent patch series. I'd rather not hold up the
documentation to fix bugs




+gpt enumerate  
+gpt guid   []
+gpt read   []
+gpt swap
+gpt rename


Thanks a lot for providing a man-page for this command.

If  and  both relate to the same object type, we should
use the same text.  would be fine.

The sequence looks random. Please, sort the sub-commands either
logically or alphabetically.


They are sorted to match the gpt command help text. Reordering of both
can be done later if desired.


There is no requirement to follow the gpt help =sequence here.

We should not reproduce what is not helpful.

Best regards

Heinrich






+
+Description
+---
+
+The gpt command lets users read, create, modify, or verify the GPT (GUID
+Partition Table) partition layout.
+
+The syntax of the text description of the partition list is similar to
+the one used by the 'mbr' command. The string contains one or more partition


Please, link the mbr page:

by the :doc:`mbr command `.


+descriptors, each separated by a ";". Each descriptor contains one or more
+fields, with each field separated by a ",". Fields are either of the form
+"key=value" to set a specific value, or simple "flag" to set a boolean flag


At this point it remains unclear to the reader what this ;-separated
string format relates to.
Is it an output format?
Is it a format used in variables?
Is it used for the parameter 'partition string'?

Maybe describe it after the parameters and relate it to the 'partition
string' parameter.

Please, describe all parameters (in this indented format):

interface
  interface for accessing the block device (mmc, sata, scsi, usb, )

device no
  device number

...


+
+The first descriptor can optionally be used to describe parameters for the
+whole disk with the following fields:
+
+* uuid_disk=UUID - Set the UUID for the disk
+
+Partition descriptors can have the following fields:
+* name=NAME - The partition name, required


Maybe better

name=

This is not rendered as an unordered list but everything is in one line.
Please, add the missing blank lines.

Please, generate the HTML documentation as described in
https://u-boot.readthedocs.io/en/latest/build/documentation.html
and check the output before resubmitting.


+* start=BYTES - The partition start offset in bytes, required
+* size=BYTES - The partition size, in bytes or "-" to expand it to the whole 
free area
+* bootable - Set the legacy bootable flag
+* uuid=UUID - Set the partition UUID, optional if CONFIG_RANDOM_UUID=y is 
enabled
+* type=UUID - Set the partition type GUID, requires 
CONFIG_PARTITION_TYPE_GUID=y
+


The following should be in a separate 'Examples' section to match the
other man-pages.


+Here is an example how to create a 6 partitions, some of the predefined sizes:
+
+::
+
+=> setenv gpt_parts 'uuid_disk=bec9fc2a-86c1-483d-8a0e-0109732277d7;
+
name=boot,start=4M,size=128M,bootable,type=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7,
+name=rootfs,size=3072M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=system-data,size=512M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=[ext],size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=user,size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=modules,size=100M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
+name=ramdisk,size=8M,type=0fc63daf-8483-4772-8e79-3d69d8477de4
+=> gpt write mmc 0 $gpt_parts
+
+
+If 'uuid' is not specified, but CONFIG_RANDOM_UUID is enabled, a random UUID
+will be generated for the partition
+
+The 'gpt verify' command returns 0 if the layout matches the one on the storage
+device 

Re: [PATCH v3 00/13] Fuzzing and ASAN for sandbox

[Tom Rini]

On Mon, Aug 28, 2023 at 10:20:02AM -0600, Simon Glass wrote:
> Hi Andrew,
> 
> On Mon, 30 May 2022 at 04:00, Andrew Scull  wrote:
> >
> > This series introduces ASAN and a basic fuzzing infrastructure that
> > works with sandbox. The example fuzz test towards the end of the series
> > will find something pretty quickly. That something is fixed by the
> > series "virtio: Harden and test vring" that needs to be applied for the
> > final patch in this series.
> >
> > There is some refactoring to stop using '.' prefixed sections. ELF
> > defines sections with names that contain anything that isn't
> > alphanumeric or an underscore as being for system use which means
> > clang's ASAN instrumentation happily add redzones between the contained
> > objects. That's not what we want for things like linker lists where the
> > linker script has carefully placed the sections contiguously. By
> > renaming the sections, clang sees them as user sections and doesn't add
> > instrumentation.
> >
> > ASAN is left disabled by default as there are still some tests that it
> > triggers on and will need some more investigation to fix. It can be
> > enabled with CONFIG_ASAN or passing `-a ASAN` to buildman.
> >
> > I abandonded the previous attempts to refactor sandbox EFI and getopt
> > declaration as the changes resulted in problems out of the scope of this
> > CL. I haven't tried to understand what EFI on sandbox should look like,
> > but I have found that the linker list implementation is very brittle
> > when up against compiler optimisation since ef123c5253 started to use
> > static, zero-length arrays to mark the beginning and end of lists but
> > the compiler see this as something it can get rid of.
> >
> > From v1:
> >  - corrected handling of EFI symbols by sandbox linker script
> >  - per comments, some renaming and explaining
> >  - dropped RFC for dlmalloc ASAN instrumentation (work required to improve 
> > it)
> >  - added patch to reduce logging noise in fuzzer
> >
> > From v2:
> >  - remove sandbox EFI and getopt refactoring, they obstruct the series
> >  - resolve a couple more ASAN errors
> >  - fix LTO, xtensa and MIPS builds
> >  - add ASAN build targets for CI
> >
> > Andrew Scull (13):
> >   serial: sandbox: Fix buffer underflow in puts
> >   sandbox: Rename EFI runtime sections
> >   sandbox: Rename getopt sections
> >   linker_lists: Rename sections to remove . prefix
> >   sandbox: Add support for Address Sanitizer
> >   test/py: test_stackprotector: Disable for ASAN
> >   CI: Azure: Build with ASAN enabled
> >   fuzzing_engine: Add fuzzing engine uclass
> >   test: fuzz: Add framework for fuzzing
> >   sandbox: Decouple program entry from sandbox init
> >   sandbox: Add libfuzzer integration
> >   sandbox: Implement fuzzing engine driver
> >   fuzz: virtio: Add fuzzer for vring
> >
> >  .azure-pipelines.yml  |  6 ++
> >  Kconfig   | 16 
> >  arch/Kconfig  |  2 +
> >  arch/arc/cpu/u-boot.lds   |  4 +-
> >  arch/arm/config.mk|  4 +-
> >  arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds   |  4 +-
> >  arch/arm/cpu/armv7/sunxi/u-boot-spl.lds   |  4 +-
> >  arch/arm/cpu/armv8/u-boot-spl.lds |  4 +-
> >  arch/arm/cpu/armv8/u-boot.lds |  4 +-
> >  arch/arm/cpu/u-boot-spl.lds   |  4 +-
> >  arch/arm/cpu/u-boot.lds   |  6 +-
> >  arch/arm/mach-at91/arm926ejs/u-boot-spl.lds   |  2 +-
> >  arch/arm/mach-at91/armv7/u-boot-spl.lds   |  2 +-
> >  arch/arm/mach-omap2/u-boot-spl.lds|  4 +-
> >  arch/arm/mach-orion5x/u-boot-spl.lds  |  4 +-
> >  arch/arm/mach-rockchip/u-boot-tpl-v8.lds  |  4 +-
> >  arch/arm/mach-zynq/u-boot-spl.lds |  4 +-
> >  arch/arm/mach-zynq/u-boot.lds |  4 +-
> >  arch/m68k/cpu/u-boot.lds  |  4 +-
> >  arch/microblaze/cpu/u-boot-spl.lds|  4 +-
> >  arch/microblaze/cpu/u-boot.lds|  4 +-
> >  arch/mips/config.mk   |  2 +-
> >  arch/mips/cpu/u-boot-spl.lds  |  4 +-
> >  arch/mips/cpu/u-boot.lds  |  4 +-
> >  arch/nios2/cpu/u-boot.lds |  4 +-
> >  arch/powerpc/cpu/mpc83xx/u-boot.lds   |  4 +-
> >  arch/powerpc/cpu/mpc85xx/u-boot-spl.lds   |  4 +-
> >  arch/powerpc/cpu/mpc85xx/u-boot.lds   |  4 +-
> >  arch/riscv/cpu/u-boot-spl.lds |  4 +-
> >  arch/riscv/cpu/u-boot.lds |  4 +-
> >  arch/sandbox/config.mk| 21 -
> >  arch/sandbox/cpu/os.c | 76 +
> >  arch/sandbox/cpu/start.c  |  2 +-
> >  arch/sandbox/cpu/u-boot-spl.lds   | 10 +--
> >  arch/sandbox/cpu/u-boot.lds   | 32 
> >  arch/sandbox/dts/test.dts |  4 +
> >  

[PATCH v1 2/2] clk: Add clock driver for Amlogic A1

[Igor Prusov]

This patch adds basic clock driver for Amlogic A1 Family which supports
enabling/disabling some gates, getting frequencies and setting rate
with limited reparenting.

Signed-off-by: Igor Prusov 
---
 arch/arm/include/asm/arch-meson/clock-a1.h |  23 +
 drivers/clk/meson/Kconfig  |   8 +
 drivers/clk/meson/Makefile |   1 +
 drivers/clk/meson/a1.c | 681 +
 4 files changed, 713 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-meson/clock-a1.h
 create mode 100644 drivers/clk/meson/a1.c

diff --git a/arch/arm/include/asm/arch-meson/clock-a1.h 
b/arch/arm/include/asm/arch-meson/clock-a1.h
new file mode 100644
index 00..f6795f5e0c
--- /dev/null
+++ b/arch/arm/include/asm/arch-meson/clock-a1.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018 - AmLogic, Inc.
+ * Copyright 2023 (C) SberDevices, Inc.
+ */
+
+#ifndef _ARCH_MESON_CLOCK_A1_H_
+#define _ARCH_MESON_CLOCK_A1_H_
+
+/*
+ * Clock controller register offsets
+ */
+#define A1_SYS_OSCIN_CTRL  0x0
+#define A1_SYS_CLK_CTRL0   0x10
+#define A1_SYS_CLK_EN0 0x1c
+#define A1_SAR_ADC_CLK_CTR 0xc0
+#define A1_SPIFC_CLK_CTRL  0xd8
+#define A1_USB_BUSCLK_CTRL 0xdc
+#define A1_SD_EMMC_CLK_CTRL0xe0
+
+#define A1_ANACTRL_FIXPLL_CTRL00x0
+
+#endif /* _ARCH_MESON_CLOCK_A1_H_ */
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 994b44ad7a..cdc9d6f76c 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -21,3 +21,11 @@ config CLK_MESON_G12A
help
  Enable clock support for the Amlogic G12A SoC family, such as
  the S905X/D2
+
+config CLK_MESON_A1
+   bool "Enable clock support for Amlogic A1"
+   depends on CLK && ARCH_MESON
+   default MESON_A1
+   help
+ Enable clock support for the Amlogic A1 SoC family, such as
+ the A113L
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index a486b13e9c..d975f07aab 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_MESON_AXG) += axg.o
 obj-$(CONFIG_CLK_MESON_AXG) += axg-ao.o
 obj-$(CONFIG_CLK_MESON_G12A) += g12a.o
 obj-$(CONFIG_CLK_MESON_G12A) += g12a-ao.o
+obj-$(CONFIG_CLK_MESON_A1) += a1.o
diff --git a/drivers/clk/meson/a1.c b/drivers/clk/meson/a1.c
new file mode 100644
index 00..6b2b9e6925
--- /dev/null
+++ b/drivers/clk/meson/a1.c
@@ -0,0 +1,681 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023 SberDevices, Inc.
+ * Author: Igor Prusov 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "clk_meson.h"
+
+/*
+ * This driver supports both PLL and peripherals clock sources.
+ * Following operations are supported:
+ * - calculating clock frequency on a limited tree
+ * - reading muxes and dividers
+ * - enabling/disabling gates without propagation
+ * - reparenting without rate propagation, only on muxes
+ * - setting rates with limited reparenting, only on dividers with mux parent
+ */
+
+#define NR_CLKS154
+#define NR_PLL_CLKS11
+
+#define EXTERNAL_XTAL  (NR_CLKS + 0)
+#define EXTERNAL_FCLK_DIV2 (NR_CLKS + 1)
+#define EXTERNAL_FCLK_DIV3 (NR_CLKS + 2)
+#define EXTERNAL_FCLK_DIV5 (NR_CLKS + 3)
+#define EXTERNAL_FCLK_DIV7 (NR_CLKS + 4)
+
+#define EXTERNAL_FIXPLL_IN (NR_PLL_CLKS + 1)
+
+#define SET_PARM_VALUE(_priv, _parm, _val) \
+   regmap_update_bits((_priv)->map, (_parm)->reg_off,  \
+  SETPMASK((_parm)->width, (_parm)->shift),\
+  (_val) << (_parm)->shift)
+
+#define GET_PARM_VALUE(_priv, _parm)   \
+({ \
+   uint _reg;  \
+   regmap_read((_priv)->map, (_parm)->reg_off, &_reg); \
+   PARM_GET((_parm)->width, (_parm)->shift, _reg); \
+})
+
+struct meson_clk {
+   struct regmap *map;
+};
+
+enum meson_clk_type {
+   MESON_CLK_ANY = 0,
+   MESON_CLK_GATE,
+   MESON_CLK_MUX,
+   MESON_CLK_DIV,
+   MESON_CLK_FIXED_DIV,
+   MESON_CLK_EXTERNAL,
+   MESON_CLK_PLL,
+};
+
+struct meson_clk_info {
+   const char *name;
+   union {
+   const struct parm *parm;
+   u8 div;
+   };
+   const unsigned int *parents;
+   const enum meson_clk_type type;
+};
+
+struct meson_clk_data {
+   const u8 num_clocks;
+   const struct meson_clk_info **clocks;
+};
+
+#define CLK_MUX(_name, _reg, _shift, _width, ...)  \
+   (&(struct meson_clk_info){  \
+ 

[PATCH v1 1/2] dt-bindings: clock: Add Amlogic A1 clock bindings

[Igor Prusov]

Add clock bindings for Amlogic A1 from linux-next next-20230821.

Signed-off-by: Igor Prusov 
---
 .../clock/amlogic,a1-peripherals-clkc.h   | 168 ++
 .../dt-bindings/clock/amlogic,a1-pll-clkc.h   |  25 +++
 2 files changed, 193 insertions(+)
 create mode 100644 include/dt-bindings/clock/amlogic,a1-peripherals-clkc.h
 create mode 100644 include/dt-bindings/clock/amlogic,a1-pll-clkc.h

diff --git a/include/dt-bindings/clock/amlogic,a1-peripherals-clkc.h 
b/include/dt-bindings/clock/amlogic,a1-peripherals-clkc.h
new file mode 100644
index 00..06f198ee76
--- /dev/null
+++ b/include/dt-bindings/clock/amlogic,a1-peripherals-clkc.h
@@ -0,0 +1,168 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ * Author: Jian Hu 
+ *
+ * Copyright (c) 2023, SberDevices. All Rights Reserved.
+ * Author: Dmitry Rokosov 
+ */
+
+#ifndef __A1_PERIPHERALS_CLKC_H
+#define __A1_PERIPHERALS_CLKC_H
+
+#define CLKID_XTAL_IN  0
+#define CLKID_FIXPLL_IN1
+#define CLKID_USB_PHY_IN   2
+#define CLKID_USB_CTRL_IN  3
+#define CLKID_HIFIPLL_IN   4
+#define CLKID_SYSPLL_IN5
+#define CLKID_DDS_IN   6
+#define CLKID_SYS  7
+#define CLKID_CLKTREE  8
+#define CLKID_RESET_CTRL   9
+#define CLKID_ANALOG_CTRL  10
+#define CLKID_PWR_CTRL 11
+#define CLKID_PAD_CTRL 12
+#define CLKID_SYS_CTRL 13
+#define CLKID_TEMP_SENSOR  14
+#define CLKID_AM2AXI_DIV   15
+#define CLKID_SPICC_B  16
+#define CLKID_SPICC_A  17
+#define CLKID_MSR  18
+#define CLKID_AUDIO19
+#define CLKID_JTAG_CTRL20
+#define CLKID_SARADC_EN21
+#define CLKID_PWM_EF   22
+#define CLKID_PWM_CD   23
+#define CLKID_PWM_AB   24
+#define CLKID_CEC  25
+#define CLKID_I2C_S26
+#define CLKID_IR_CTRL  27
+#define CLKID_I2C_M_D  28
+#define CLKID_I2C_M_C  29
+#define CLKID_I2C_M_B  30
+#define CLKID_I2C_M_A  31
+#define CLKID_ACODEC   32
+#define CLKID_OTP  33
+#define CLKID_SD_EMMC_A34
+#define CLKID_USB_PHY  35
+#define CLKID_USB_CTRL 36
+#define CLKID_SYS_DSPB 37
+#define CLKID_SYS_DSPA 38
+#define CLKID_DMA  39
+#define CLKID_IRQ_CTRL 40
+#define CLKID_NIC  41
+#define CLKID_GIC  42
+#define CLKID_UART_C   43
+#define CLKID_UART_B   44
+#define CLKID_UART_A   45
+#define CLKID_SYS_PSRAM46
+#define CLKID_RSA  47
+#define CLKID_CORESIGHT48
+#define CLKID_AM2AXI_VAD   49
+#define CLKID_AUDIO_VAD50
+#define CLKID_AXI_DMC  51
+#define CLKID_AXI_PSRAM52
+#define CLKID_RAMB 53
+#define CLKID_RAMA 54
+#define CLKID_AXI_SPIFC55
+#define CLKID_AXI_NIC  56
+#define CLKID_AXI_DMA  57
+#define CLKID_CPU_CTRL 58
+#define CLKID_ROM  59
+#define CLKID_PROC_I2C 60
+#define CLKID_DSPA_SEL 61
+#define CLKID_DSPB_SEL 62
+#define CLKID_DSPA_EN  63
+#define CLKID_DSPA_EN_NIC  64
+#define CLKID_DSPB_EN  65
+#define CLKID_DSPB_EN_NIC  66
+#define CLKID_RTC  67
+#define CLKID_CECA_32K 68
+#define CLKID_CECB_32K 69
+#define CLKID_24M  70
+#define CLKID_12M  71
+#define CLKID_FCLK_DIV2_DIVN   72
+#define CLKID_GEN  73
+#define CLKID_SARADC_SEL   74
+#define CLKID_SARADC   75
+#define CLKID_PWM_A76
+#define CLKID_PWM_B77
+#define CLKID_PWM_C78
+#define CLKID_PWM_D79
+#define CLKID_PWM_E80
+#define CLKID_PWM_F81
+#define CLKID_SPICC82
+#define CLKID_TS   83
+#define CLKID_SPIFC84
+#define CLKID_USB_BUS  85
+#define CLKID_SD_EMMC  86
+#define CLKID_PSRAM87
+#define CLKID_DMC  88
+#define CLKID_SYS_A_SEL89
+#define CLKID_SYS_A_DIV90
+#define CLKID_SYS_A91
+#define CLKID_SYS_B_SEL92
+#define CLKID_SYS_B_DIV93
+#define CLKID_SYS_B94
+#define CLKID_DSPA_A_SEL   95
+#define CLKID_DSPA_A_DIV   96
+#define CLKID_DSPA_A   97
+#define CLKID_DSPA_B_SEL   98
+#define CLKID_DSPA_B_DIV   99
+#define CLKID_DSPA_B   100
+#define CLKID_DSPB_A_SEL   101
+#define CLKID_DSPB_A_DIV   102
+#define CLKID_DSPB_A   103
+#define CLKID_DSPB_B_SEL   104
+#define CLKID_DSPB_B_DIV   105
+#define CLKID_DSPB_B   106
+#define CLKID_RTC_32K_IN   107
+#define CLKID_RTC_32K_DIV  108
+#define CLKID_RTC_32K_XTAL 109
+#define CLKID_RTC_32K_SEL  110
+#define 

[PATCH v1 0/2] clk: amlogic: a1: Add Amlogic A1 clock driver

[Igor Prusov]

This series adds dt-bindings and driver implementation for Amlogic A1
PLL and Peripherals clock controllers.

Igor Prusov (2):
  dt-bindings: clock: Add Amlogic A1 clock bindings
  clk: Add clock driver for Amlogic A1

 arch/arm/include/asm/arch-meson/clock-a1.h|  23 +
 drivers/clk/meson/Kconfig |   8 +
 drivers/clk/meson/Makefile|   1 +
 drivers/clk/meson/a1.c| 681 ++
 .../clock/amlogic,a1-peripherals-clkc.h   | 168 +
 .../dt-bindings/clock/amlogic,a1-pll-clkc.h   |  25 +
 6 files changed, 906 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-meson/clock-a1.h
 create mode 100644 drivers/clk/meson/a1.c
 create mode 100644 include/dt-bindings/clock/amlogic,a1-peripherals-clkc.h
 create mode 100644 include/dt-bindings/clock/amlogic,a1-pll-clkc.h

-- 
2.34.1

Re: [PATCH v3 2/8] doc: Add gpt command documentation

[Joshua Watt]

On Fri, Aug 25, 2023 at 7:57 PM Heinrich Schuchardt  wrote:
>
> On 8/25/23 21:38, Joshua Watt wrote:
> > Adds initial documentation for the gpt command
>
> Thanks a lot for filling the gap.
>
> >
> > Signed-off-by: Joshua Watt 
> > ---
> >   doc/usage/cmd/gpt.rst | 141 ++
> >   doc/usage/index.rst   |   1 +
> >   2 files changed, 142 insertions(+)
> >   create mode 100644 doc/usage/cmd/gpt.rst
> >
> > diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
> > new file mode 100644
> > index 00..f6e082fb94
> > --- /dev/null
> > +++ b/doc/usage/cmd/gpt.rst
> > @@ -0,0 +1,141 @@
> > +.. SPDX-License-Identifier: GPL-2.0+
> > +
> > +gpt command
> > +===
> > +
> > +Synopsis
> > +
> > +
> > +::
> > +
> > +gpt repair  
> > +gpt write   
> > +gpt verify   
>
>  is not required. Please, add brackets [].

It's not optional; there is no standardized string for the list of GPT
partitions like there is for MBR

>
> > +gpt setenv   
>
> gpt setenv can be called without partition name which leads to a crash.
>
> If that parameter is meant to be optional, this should be indicated
> here. Otherwise an argc check is missing.

I don't believe the argument is optional, but either way it can be
fixed in a subsequent patch series. I'd rather not hold up the
documentation to fix bugs

>
> > +gpt enumerate  
> > +gpt guid   []
> > +gpt read   []
> > +gpt swap
> > +gpt rename
>
> Thanks a lot for providing a man-page for this command.
>
> If  and  both relate to the same object type, we should
> use the same text.  would be fine.
>
> The sequence looks random. Please, sort the sub-commands either
> logically or alphabetically.

They are sorted to match the gpt command help text. Reordering of both
can be done later if desired.

>
> > +
> > +Description
> > +---
> > +
> > +The gpt command lets users read, create, modify, or verify the GPT (GUID
> > +Partition Table) partition layout.
> > +
> > +The syntax of the text description of the partition list is similar to
> > +the one used by the 'mbr' command. The string contains one or more 
> > partition
>
> Please, link the mbr page:
>
> by the :doc:`mbr command `.
>
> > +descriptors, each separated by a ";". Each descriptor contains one or more
> > +fields, with each field separated by a ",". Fields are either of the form
> > +"key=value" to set a specific value, or simple "flag" to set a boolean flag
>
> At this point it remains unclear to the reader what this ;-separated
> string format relates to.
> Is it an output format?
> Is it a format used in variables?
> Is it used for the parameter 'partition string'?
>
> Maybe describe it after the parameters and relate it to the 'partition
> string' parameter.
>
> Please, describe all parameters (in this indented format):
>
> interface
>  interface for accessing the block device (mmc, sata, scsi, usb, )
>
> device no
>  device number
>
> ...
>
> > +
> > +The first descriptor can optionally be used to describe parameters for the
> > +whole disk with the following fields:
> > +
> > +* uuid_disk=UUID - Set the UUID for the disk
> > +
> > +Partition descriptors can have the following fields:
> > +* name=NAME - The partition name, required
>
> Maybe better
>
> name=
>
> This is not rendered as an unordered list but everything is in one line.
> Please, add the missing blank lines.
>
> Please, generate the HTML documentation as described in
> https://u-boot.readthedocs.io/en/latest/build/documentation.html
> and check the output before resubmitting.
>
> > +* start=BYTES - The partition start offset in bytes, required
> > +* size=BYTES - The partition size, in bytes or "-" to expand it to the 
> > whole free area
> > +* bootable - Set the legacy bootable flag
> > +* uuid=UUID - Set the partition UUID, optional if CONFIG_RANDOM_UUID=y is 
> > enabled
> > +* type=UUID - Set the partition type GUID, requires 
> > CONFIG_PARTITION_TYPE_GUID=y
> > +
>
> The following should be in a separate 'Examples' section to match the
> other man-pages.
>
> > +Here is an example how to create a 6 partitions, some of the predefined 
> > sizes:
> > +
> > +::
> > +
> > +=> setenv gpt_parts 'uuid_disk=bec9fc2a-86c1-483d-8a0e-0109732277d7;
> > +
> > name=boot,start=4M,size=128M,bootable,type=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7,
> > +name=rootfs,size=3072M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
> > +
> > name=system-data,size=512M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
> > +name=[ext],size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
> > +name=user,size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
> > +name=modules,size=100M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;
> > +name=ramdisk,size=8M,type=0fc63daf-8483-4772-8e79-3d69d8477de4
> > +=> gpt write mmc 0 $gpt_parts
> > +
> > +
> > +If 'uuid' is not specified, but CONFIG_RANDOM_UUID is enabled, a random 
> > UUID
> > 

[PATCH v2 1/2] dm: event: document all events

[Heinrich Schuchardt]

Provide Sphinx documentation for all events.

Signed-off-by: Heinrich Schuchardt 
---
v2:
remove non-printing comments from num event_t
correct texts according to Simon's suggestions
---
 include/event.h | 97 ++---
 1 file changed, 91 insertions(+), 6 deletions(-)

diff --git a/include/event.h b/include/event.h
index bb38ba98e7..f5c5d30a64 100644
--- a/include/event.h
+++ b/include/event.h
@@ -19,29 +19,114 @@
  * @EVT_DM_PRE_PROBE: Device is about to be probed
  */
 enum event_t {
-   EVT_NONE,
+   /**
+* @EVT_NONE: This zero value is not used for events.
+*/
+   EVT_NONE = 0,
+
+   /**
+* @EVT_TEST: This event is used in unit tests.
+*/
EVT_TEST,
 
-   /* Events related to driver model */
+   /**
+* @EVT_DM_POST_INIT_F:
+* This event is triggered after pre-relocation initialization of the
+* driver model. Its parameter is NULL.
+* A non-zero return code from the event handler let's the boot process
+* fail.
+*/
EVT_DM_POST_INIT_F,
+
+   /**
+* @EVT_DM_POST_INIT_R:
+* This event is triggered after post-relocation initialization of the
+* driver model. Its parameter is NULL.
+* A non-zero return code from the event handler let's the boot process
+* fail.
+*/
EVT_DM_POST_INIT_R,
+
+   /**
+* @EVT_DM_PRE_PROBE:
+* This event is triggered before probing a device. Its parameter is the
+* device to be probed.
+* A non-zero return code from the event handler lets the device not
+* being probed.
+*/
EVT_DM_PRE_PROBE,
+
+   /**
+* @EVT_DM_POST_PROBE:
+* This event is triggered after probing a device. Its parameter is the
+* device that was probed.
+* A non-zero return code from the event handler leaves the device in
+* the unprobed state and therefore not usable.
+*/
EVT_DM_POST_PROBE,
+
+   /**
+* @EVT_DM_PRE_REMOVE:
+* This event is triggered after removing a device. Its parameter is
+* the device to be removed.
+* A non-zero return code from the event handler stops the removal of
+* the device before any changes.
+*/
EVT_DM_PRE_REMOVE,
+
+   /**
+* @EVT_DM_POST_REMOVE:
+* This event is triggered before removing a device. Its parameter is
+* the device that was removed.
+* A non-zero return code stops from the event handler the removal of
+* the device after all removal changes. The previous state is not
+* restored. All children will be gone and the device may not be
+* functional.
+*/
EVT_DM_POST_REMOVE,
 
-   /* Init hooks */
+   /**
+* @EVT_MISC_INIT_F:
+* This event is triggered during the initialization sequence before
+* relocation. Its parameter is NULL.
+* A non-zero return code from the event handler let's the boot process
+* fail.
+*/
EVT_MISC_INIT_F,
 
-   /* Fpga load hook */
+   /**
+* @EVT_FPGA_LOAD:
+* The FPGA load hook is called after loading an FPGA with a new binary.
+* Its parameter is of type struct event_fpga_load and contains
+* information about the loaded image.
+*/
EVT_FPGA_LOAD,
 
-   /* Device tree fixups before booting */
+   /**
+* @EVT_FT_FIXUP:
+* This event is triggered during device-tree fix up after all
+* other device-tree fixups have been executed.
+* Its parameter is of type struct event_ft_fixup which contains
+* the address of the device-tree to fix up and the list of images to be
+* booted.
+* A non-zero return code from the event handler let's booting the
+* images fail.
+*/
EVT_FT_FIXUP,
 
-   /* To be called once, before calling main_loop() */
+   /**
+* @EVT_MAIN_LOOP:
+* This event is triggered immediately before calling main_loop() which
+* is the entry point of the command line. Its parameter is NULL.
+* A non-zero return value causes the boot to fail.
+*/
EVT_MAIN_LOOP,
 
+   /**
+* @EVT_COUNT:
+* This constants holds the maximum event number + 1 and is used when
+* looping over all event classes.
+*/
EVT_COUNT
 };
 
-- 
2.40.1

[PATCH v2 2/2] doc: add events.h to documentation

[Heinrich Schuchardt]

Add the events.h include to the API documentation.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Simon Glass 
---
v2:
no change
---
 doc/api/event.rst | 9 +
 doc/api/index.rst | 1 +
 2 files changed, 10 insertions(+)
 create mode 100644 doc/api/event.rst

diff --git a/doc/api/event.rst b/doc/api/event.rst
new file mode 100644
index 00..8a57d43832
--- /dev/null
+++ b/doc/api/event.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Events
+==
+
+The concept of events is decribed :doc:`here <../develop/event>`.
+
+.. kernel-doc:: include/event.h
+   :internal:
diff --git a/doc/api/index.rst b/doc/api/index.rst
index 3a80ae0635..2f0218c47a 100644
--- a/doc/api/index.rst
+++ b/doc/api/index.rst
@@ -10,6 +10,7 @@ U-Boot API documentation
dfu
dm
efi
+   event
getopt
linker_lists
lmb
-- 
2.40.1

[PATCH v2 0/2] doc: event: document all events

[Heinrich Schuchardt]

Document all events and add event.h to the HTML documentation.

Heinrich Schuchardt (2):
  dm: event: document all events
  doc: add events.h to documentation

 doc/api/event.rst |  9 +
 doc/api/index.rst |  1 +
 include/event.h   | 97 ---
 3 files changed, 101 insertions(+), 6 deletions(-)
 create mode 100644 doc/api/event.rst

-- 
2.40.1

Re: [PATCH 0/6] Attempt to enforce standard extensions for build output

[Tom Rini]

On Mon, Aug 28, 2023 at 11:54:55AM -0600, Simon Glass wrote:
> Hi Alper,
> 
> On Sun, 27 Aug 2023 at 13:17, Alper Nebi Yasak  
> wrote:
> >
> > On 2023-08-24 06:02 +03:00, Simon Glass wrote:
> > > In this early stage of using binman to produce output files, we are mostly
> > > seeing people using common extensions such as '.bin' and '.rom'
> > >
> > > But unusual extensions appear in some places.
> > >
> > > We would like 'buildman -k' to keep the build outputs, but this is hard if
> > > there is no consistency as to the extension used.
> > >
> > > This series adjusts binman to enforce just 4 extensions for output images:
> > >
> > >.bin
> > >.rom
> > >.itb
> > >.img
> > >
> > > Other extensions will produce an error. With this rule observed, buildman
> > > can keep the required files.
> >
> > I dislike this limitation. We know what files we will generate, they are
> > listed in binman dtb, so we can add something like `binman build --ls`
> > to print their names/paths for buildman to preserve them.
> 
> Yes, it would be good to have that...
> 
> But why do you dislike the limitation? Do you think extensions provide
> useful information? I suppose one problem is that *.bin might pick up
> private blobs that happen to be in the source directory?

I think all of the complaints thus far have shown the problem with
trying to enforce an arbitrary limit here.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 1/1] bootstd: BOOTDEV_SPI_FLASH requires BOOTSTD

[Heinrich Schuchardt]

Compiling sandbox_defconfig with CONFIG_BOOTSTD=n fails:

/usr/bin/ld: drivers/mtd/spi/sf_bootdev.o:
in function `sf_get_bootflow':
/drivers/mtd/spi/sf_bootdev.c:43:(.text+0x96):
undefined reference to `bootmeth_set_bootflow'

Add the missing Kconfig dependency.

Fixes: Fixes: 0c1f4a9fb13a ("bootstd: Add a SPI flash bootdev")
Signed-off-by: Heinrich Schuchardt 
---
 drivers/mtd/spi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index a9617c6c58..d3b1b21a47 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -82,6 +82,7 @@ if SPI_FLASH
 
 config BOOTDEV_SPI_FLASH
bool "SPI Flash bootdev support"
+   depends on BOOTSTD
help
  Enable a boot device for SPI flash. This allows reading a script
  from SPI flash so that it can be used to boot an Operating System.
-- 
2.40.1

Re: [RFC PATCH 5/5] doc: Add a document for non-compliant DT node/property removal

[Tom Rini]

On Tue, Aug 29, 2023 at 12:04:53AM +0530, Sughosh Ganu wrote:
> hi Simon,
> 
> On Mon, 28 Aug 2023 at 23:25, Simon Glass  wrote:
> >
> > Hi Sughosh,
> >
> > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
> > >
> > > Add a document explaining the need for removal of non-compliant
> > > devicetree nodes and properties. Also describe in brief, the macros
> > > that can be used for this removal.
> > >
> > > Signed-off-by: Sughosh Ganu 
> > > ---
> > >  .../devicetree/dt_non_compliant_purge.rst | 64 +++
> > >  1 file changed, 64 insertions(+)
> > >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> > >
> > > diff --git a/doc/develop/devicetree/dt_non_compliant_purge.rst 
> > > b/doc/develop/devicetree/dt_non_compliant_purge.rst
> > > new file mode 100644
> > > index 00..c3a8feab5b
> > > --- /dev/null
> > > +++ b/doc/develop/devicetree/dt_non_compliant_purge.rst
> > > @@ -0,0 +1,64 @@
> > > +.. SPDX-License-Identifier: GPL-2.0+
> > > +
> > > +Removal of non-compliant nodes and properties
> > > +=
> > > +
> > > +The devicetree used in U-Boot might contain nodes and properties which
> > > +are specific only to U-Boot, and are not necessarily being used to
> > > +describe hardware but to pass information to U-Boot. An example of
> > > +such a property would be the public key being passed to U-Boot for
> > > +verification.
> >
> > It has nothing to do with describing hardware. The DT can describe
> > other things too. See the /options node, for example.
> >
> > Please don't bring this highly misleading language into U-Boot.
> 
> Please point out what is misleading in the above paragraph. What is
> being emphasised in the above paragraph is that certain nodes and
> properties in the devicetree are relevant only in u-boot, and not the
> kernel. And this is precisely what the devicetree maintainers are
> saying [1].
> 
> >
> > > +
> > > +This devicetree can then be passed to the OS. Since certain nodes and
> > > +properties are not really describing hardware, and more importantly,
> > > +these are only relevant to U-Boot, bindings for these cannot be
> > > +upstreamed into the devicetree repository. There have been instances
> > > +of attempts being made to upstream such bindings, and these deemed not
> > > +fit for upstreaming.
> >
> > Then either they should not be in U-Boot, or there is a problem with
> > the process.
> >
> > > Not having a binding for these nodes and
> > > +properties means that the devicetree fails the schema compliance tests
> > > +[1]. This also means that the platform cannot get certifications like
> > > +SystemReady [2] which, among other things require a devicetree which
> > > +passes the schema compliance tests.
> > > +
> > > +For such nodes and properties, it has been suggested by the devicetree
> > > +maintainers that the right thing to do is to remove them from the
> > > +devicetree before it gets passed on to the OS [3].
> >
> > Hard NAK. If we go this way, then no one will ever have an incentive
> > to do the right thing.
> >
> > Please send bindings for Linaro's work, instead. If something is
> > entirely U-Boot-specific, then it can go in /options/u-boot but it
> > still must be in the dt-schema.
> 
> Please re-read the document including the last link [1]. If you go
> through that entire thread, you will notice that this is precisely
> what Linaro was trying to do here -- upstream the binding for the
> fwu-mdata node. It is only based on the feedback of the devicetree
> maintainers that this patchset was required.
> 
> -sughosh
> 
> [1] - 
> https://lore.kernel.org/u-boot/cal_jsqjn4fehoml7z3yj0wj9bpx1ose7zf26l_gv2os6cg-...@mail.gmail.com/#t

Please note that this right here, that the explanation of why we need to
delete this node, not being a bright shiny visible object is one of the
big problems with this patchset and implementation. It cannot be
footnotes in email threads as to why such-and-such node/property isn't
upstream, it needs to be documented and visible in the code base /
documentation and an obvious you must do this for future cases.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 5/5] doc: Add a document for non-compliant DT node/property removal

[Sughosh Ganu]

hi Simon,

On Mon, 28 Aug 2023 at 23:25, Simon Glass  wrote:
>
> Hi Sughosh,
>
> On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
> >
> > Add a document explaining the need for removal of non-compliant
> > devicetree nodes and properties. Also describe in brief, the macros
> > that can be used for this removal.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >  .../devicetree/dt_non_compliant_purge.rst | 64 +++
> >  1 file changed, 64 insertions(+)
> >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> >
> > diff --git a/doc/develop/devicetree/dt_non_compliant_purge.rst 
> > b/doc/develop/devicetree/dt_non_compliant_purge.rst
> > new file mode 100644
> > index 00..c3a8feab5b
> > --- /dev/null
> > +++ b/doc/develop/devicetree/dt_non_compliant_purge.rst
> > @@ -0,0 +1,64 @@
> > +.. SPDX-License-Identifier: GPL-2.0+
> > +
> > +Removal of non-compliant nodes and properties
> > +=
> > +
> > +The devicetree used in U-Boot might contain nodes and properties which
> > +are specific only to U-Boot, and are not necessarily being used to
> > +describe hardware but to pass information to U-Boot. An example of
> > +such a property would be the public key being passed to U-Boot for
> > +verification.
>
> It has nothing to do with describing hardware. The DT can describe
> other things too. See the /options node, for example.
>
> Please don't bring this highly misleading language into U-Boot.

Please point out what is misleading in the above paragraph. What is
being emphasised in the above paragraph is that certain nodes and
properties in the devicetree are relevant only in u-boot, and not the
kernel. And this is precisely what the devicetree maintainers are
saying [1].

>
> > +
> > +This devicetree can then be passed to the OS. Since certain nodes and
> > +properties are not really describing hardware, and more importantly,
> > +these are only relevant to U-Boot, bindings for these cannot be
> > +upstreamed into the devicetree repository. There have been instances
> > +of attempts being made to upstream such bindings, and these deemed not
> > +fit for upstreaming.
>
> Then either they should not be in U-Boot, or there is a problem with
> the process.
>
> > Not having a binding for these nodes and
> > +properties means that the devicetree fails the schema compliance tests
> > +[1]. This also means that the platform cannot get certifications like
> > +SystemReady [2] which, among other things require a devicetree which
> > +passes the schema compliance tests.
> > +
> > +For such nodes and properties, it has been suggested by the devicetree
> > +maintainers that the right thing to do is to remove them from the
> > +devicetree before it gets passed on to the OS [3].
>
> Hard NAK. If we go this way, then no one will ever have an incentive
> to do the right thing.
>
> Please send bindings for Linaro's work, instead. If something is
> entirely U-Boot-specific, then it can go in /options/u-boot but it
> still must be in the dt-schema.

Please re-read the document including the last link [1]. If you go
through that entire thread, you will notice that this is precisely
what Linaro was trying to do here -- upstream the binding for the
fwu-mdata node. It is only based on the feedback of the devicetree
maintainers that this patchset was required.

-sughosh

[1] - 
https://lore.kernel.org/u-boot/cal_jsqjn4fehoml7z3yj0wj9bpx1ose7zf26l_gv2os6cg-...@mail.gmail.com/#t

>
> > +
> > +Removing nodes/properties
> > +-
> > +
> > +In U-Boot, this is been done through adding information on such nodes
> > +and properties in a list. The entire node can be deleted, or a
> > +specific property under a node can be deleted. The list of such nodes
> > +and properties is generated at compile time, and the function to purge
> > +these can be invoked through a EVT_FT_FIXUP event notify call.
> > +
> > +For deleting a node, this can be done by declaring a macro::
> > +
> > +   DT_NON_COMPLIANT_PURGE(fwu_mdata) = {
> > +   .node_path  = "/fwu-mdata",
> > +   };
> > +
> > +Similarly, for deleting a property under a node, that can be done by
> > +specifying the property name::
> > +
> > +   DT_NON_COMPLIANT_PURGE(capsule_key) = {
> > +   .node_path  = "/signature",
> > +   .prop   = "capsule-key",
> > +   };
> > +
> > +In the first example, the entire node with path /fwu-mdata will be
> > +removed. In the second example, the property capsule-key
> > +under /signature node will be removed.
> > +
> > +Similarly, a list of nodes and properties can be specified using the
> > +following macro::
> > +
> > +   DT_NON_COMPLIANT_PURGE_LIST(foo) = {
> > +   { .node_path = "/some_node", .prop = "some_bar" },
> > +   { .node_path = "/some_node" },
> > +   };
> > +
> > +[1] - https://github.com/devicetree-org/dt-schema
> > +[2] - 
> > 

Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default

[Alper Nebi Yasak]

On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> Hi Alper,
> On Mon, 28 Aug 2023 at 09:46, Alper Nebi Yasak  
> wrote:
>>
>> On 2023-08-22 21:56 +03:00, Simon Glass wrote:
>>> Hi Alper,
>>>
>>> On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  
>>> wrote:

 From: Alexander Graf 

 Now that we have everything in place to support ramfb, let's wire it up
 by default in the ARM QEMU targets. That way, you can easily use a
 graphical console by just passing -device ramfb to the QEMU command line.

 Signed-off-by: Alexander Graf 
 [Alper: Rebase on bochs changes, add pre-reloc init, error handling]
 Co-developed-by: Alper Nebi Yasak 
 Signed-off-by: Alper Nebi Yasak 
 ---

 Changes in v2:
 - Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
 - Drop env changes from ARM (necessary but in prerequisite series)
 - Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
 - Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
 - Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU

  arch/arm/Kconfig|  3 +++
  board/emulation/qemu-arm/qemu-arm.c | 41 +
  2 files changed, 44 insertions(+)

 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index 1fd3ccd1607f..7afe26ac804f 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -1046,6 +1046,9 @@ config ARCH_QEMU
 imply USB_XHCI_PCI
 imply USB_KEYBOARD
 imply CMD_USB
 +   imply VIDEO_RAMFB
 +   imply BOARD_EARLY_INIT_F
 +   imply BOARD_EARLY_INIT_R

  config ARCH_RMOBILE
 bool "Renesas ARM SoCs"
 diff --git a/board/emulation/qemu-arm/qemu-arm.c 
 b/board/emulation/qemu-arm/qemu-arm.c
 index 942f1fff5717..23ef31cb7feb 100644
 --- a/board/emulation/qemu-arm/qemu-arm.c
 +++ b/board/emulation/qemu-arm/qemu-arm.c
 @@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
  struct mm_region *mem_map = qemu_arm64_mem_map;
  #endif

 +int board_early_init_f(void)
 +{
 +   struct udevice *dev;
 +   int ret;
 +
 +   /*
 +* Make sure we enumerate the QEMU Firmware device to bind ramfb
 +* so video_reserve() can reserve memory for it.
 +*/
 +   if (IS_ENABLED(CONFIG_QFW)) {
 +   ret = qfw_get_dev();
 +   if (ret) {
 +   log_err("Failed to get QEMU FW device: %d\n", ret);
>>>
>>> We should only present an error if the device is present but
>>> failed...so if the user doesn't provide the flag, all should be well.
>>
>> I don't understand what you mean by "user doesn't provide the flag". But
>> I assume this should ignore the error (unless what?) so that we can
>> continue to boot. Would that apply for board_early_init_r below as well?
> 
> I thought you said there was a qemu flag to enable ramfb? So add it to
> the DT and then the device can (in its bind routine) decide not to be
> bound by returning -ENODEV

Ah. I'm not used to calling them flags, especially those that have
values as in "-device ramfb". My mind jumped to DM_FLAG_PRE_RELOC /
bootph-some-ram.

But note that what this code tries to probe here is not the ramfb
device, it's the bus/parent of that. If this fails, we can't know if the
user specified "-device ramfb" or not.

Is the parent node's device probed by the time .bind() is called? Or,
can I have it probed by calling qfw_get_dev() (which is just
uclass_first_device_err(UCLASS_QFW, ...))?

Re: [RFC PATCH 1/5] dt: Provide a way to remove non-compliant nodes and properties

[Tom Rini]

On Sat, Aug 26, 2023 at 02:36:29PM +0530, Sughosh Ganu wrote:

> Add a function which is registered to spy for a EVT_FT_FIXUP event,
> and removes the non upstreamed nodes and properties from the
> devicetree before it gets passed to the OS.
> 
> This allows removing entire nodes, or specific properties under nodes
> from the devicetree. The required nodes and properties can be
> registered for removal through the DT_NON_COMPLIANT_PURGE and
> DT_NON_COMPLIANT_PURGE_LIST macros.
> 
> Signed-off-by: Sughosh Ganu 

So, the conceptual problem here is that while we do need to have a way
to purge nodes and properties that have been rejected by upstream, we
also need to ensure an upstream attempt was made. To that end, how I
envision things is:
- When we build the docs, something under doc/develop/ has a page /
  section for each binding we're purging, which links to and summarizes
  why it's not appropriate for upstream.
- It's non-default to purge said nodes.
- We at least make checkpatch / et al complain about new purges being
  added, and CI failing on the number of purges increasing without also
  increasing the number of allowed purges.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 0/6] Attempt to enforce standard extensions for build output

[Simon Glass]

Hi Alper,

On Sun, 27 Aug 2023 at 13:17, Alper Nebi Yasak  wrote:
>
> On 2023-08-24 06:02 +03:00, Simon Glass wrote:
> > In this early stage of using binman to produce output files, we are mostly
> > seeing people using common extensions such as '.bin' and '.rom'
> >
> > But unusual extensions appear in some places.
> >
> > We would like 'buildman -k' to keep the build outputs, but this is hard if
> > there is no consistency as to the extension used.
> >
> > This series adjusts binman to enforce just 4 extensions for output images:
> >
> >.bin
> >.rom
> >.itb
> >.img
> >
> > Other extensions will produce an error. With this rule observed, buildman
> > can keep the required files.
>
> I dislike this limitation. We know what files we will generate, they are
> listed in binman dtb, so we can add something like `binman build --ls`
> to print their names/paths for buildman to preserve them.

Yes, it would be good to have that...

But why do you dislike the limitation? Do you think extensions provide
useful information? I suppose one problem is that *.bin might pick up
private blobs that happen to be in the source directory?

>
> Regarding the output directory suggestion, I think the binman outputs
> (not temporary/intermediate files) should be in the same directory as
> make outputs

Agreed

>, and the Makefile should default to O=build to achieve the
> "output dir". I'm not sure if that's going to happen.

I would quite like the 'non-output' file (i.e. things that are not a
binman image) to appear in a 'binman-work' subdir of the output dir.
What do you think?

Regards,
Simon

Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros

[Simon Glass]

Hi Alper,

On Sun, 27 Aug 2023 at 09:49, Alper Nebi Yasak  wrote:
>
> On 2023-08-15 01:43 +03:00, Simon Glass wrote:
> > Hi Alper,
> >
> > On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak  
> > wrote:
> >> I actually want to put the root.img device first so that the VM can boot
> >> into the installed system when it reboots, but U-Boot can't find the
> >> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
> >> scan -lab`, but it seems to only ever search the first virtio-blk.
> >> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
> >
> > Yes, this is annoying.
> >
> > The problem is that the scanning is getting so complicated. The
> > boot_targets var lists things which can either be a uclass, or a
> > uclass with a device number. The currently implementation sees
> > "virtio" and moves on to the next thing in boot_targets once it has
> > processed one virtio device. That is obviously not correct, but...
> >
> > Would it be possible to just drop the 'boot_targets' var? That is what
> > is stuffing it up, but we don't actually need it now. The defaults end
> > up doing the same thing, apart (perhaps) from the strangeness of
> > virtio which can be both a network and a blk device.
> >
> > I believe it is possible to do the right thing, but I'll need to
> > create a better test mechanism to handle all the cases.
>
> I think some kind of a "priority score" could help -- iterate over
> boot_targets first just to generate bootdev priorities, then carry them
> over as bootflows are discovered (adjusted for bootmeth order), then use
> those scores as the order to boot / to show a sorted menu / to test?

We sort-of have that, in that bootdevs have a priority. We could add
something to struct bootflow which takes that but adds more
fine-grained information, e.g. based on some sort of filter function
that can decide?

Bear in mind that we normally want to boot the first thing we find,
and we also want to use lazy init (so no USB unless we need it). But
yes for the case where we display a menu I think we could make more of
the priority feature. What are you thinking of?

BTW, even for the menu, my original vision was that the menu would
display immediately, with new bootflows appearing as they are
discovered.

Regards,
Simon

Re: [PATCH v5 00/13] Add video damage tracking

[Simon Glass]

Hi Alex,

On Wed, 23 Aug 2023 at 02:56, Alexander Graf  wrote:
>
> Hey Simon,
>
> On 22.08.23 20:56, Simon Glass wrote:
> > Hi Alex,
> >
> > On Tue, 22 Aug 2023 at 01:47, Alexander Graf  wrote:
> >>
> >> On 22.08.23 01:03, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 21 Aug 2023 at 16:40, Alexander Graf  wrote:
>  On 22.08.23 00:10, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 21 Aug 2023 at 14:20, Alexander Graf  wrote:
> >> On 21.08.23 21:57, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 21 Aug 2023 at 13:33, Alexander Graf  wrote:
>  On 21.08.23 21:11, Simon Glass wrote:
> > Hi Alper,
> >
> > On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak 
> >  wrote:
> >> This is a rebase of Alexander Graf's video damage tracking series, 
> >> with
> >> some tests and other changes. The original cover letter is as 
> >> follows:
> >>
> >>> This patch set speeds up graphics output on ARM by a factor of 
> >>> 60x.
> >>>
> >>> On most ARM SBCs, we keep the frame buffer in DRAM and map it as 
> >>> cached,
> >>> but need it accessible by the display controller which reads 
> >>> directly
> >>> from a later point of consistency. Hence, we flush the frame 
> >>> buffer to
> >>> DRAM on every change. The full frame buffer.
> > It should not, see below.
> >
> >>> Unfortunately, with the advent of 4k displays, we are seeing 
> >>> frame buffers
> >>> that can take a while to flush out. This was reported by Da Xue 
> >>> with grub,
> >>> which happily print 1000s of spaces on the screen to draw a menu. 
> >>> Every
> >>> printed space triggers a cache flush.
> > That is a bug somewhere in EFI.
>  Unfortunately not :). You may call it a bug in grub: It literally 
>  prints
>  over space characters for every character in its menu that it wants
>  cleared. On every text screen draw.
> 
>  This wouldn't be a big issue if we only flush the reactangle that 
>  gets
>  modified. But without this patch set, we're flushing the full DRAM
>  buffer on every u-boot text console character write, which means for
>  every character (as that's the only API UEFI has).
> 
>  As a nice side effect, we speed up the normal U-Boot text console as
>  well with this patch set, because even "normal" text prints that 
>  write
>  for example a single line of text on the screen today flush the full
>  frame buffer to DRAM.
> >>> No, I mean that it is a bug that U-Boot (apparently) flushes the cache
> >>> after every character. It doesn't do that for normal character output
> >>> and I don't think it makes sense to do it for EFI either.
> >> I see. Let's trace the calls:
> >>
> >> efi_cout_output_string()
> >> -> fputs()
> >> -> vidconsole_puts()
> >> -> video_sync()
> >> -> flush_dcache_range()
> >>
> >> Unfortunately grub abstracts character backends down to the "print
> >> character" level, so it calls UEFI's sopisticated "output_string"
> >> callback with single characters at a time, which means we do a full
> >> dcache flush for every character that we print:
> >>
> >> https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/efi/console.c#n165
> >>
> >>
> >>> This patch set implements the easiest mitigation against this 
> >>> problem:
> >>> Damage tracking. We remember the lowest common denominator region 
> >>> that was
> >>> touched since the last video_sync() call and only flush that. The 
> >>> most
> >>> typical writer to the frame buffer is the video console, which 
> >>> always
> >>> writes rectangles of characters on the screen and syncs 
> >>> afterwards.
> >>>
> >>> With this patch set applied, we reduce drawing a large grub menu 
> >>> (with
> >>> serial console attached for size information) on an RK3399-ROC 
> >>> system
> >>> at 1440p from 55 seconds to less than 1 second.
> >>>
> >>> Version 2 also implements VIDEO_COPY using this mechanism, 
> >>> reducing its
> >>> overhead compared to before as well. So even x86 systems should 
> >>> be faster
> >>> with this now :).
> >>>
> >>>
> >>> Alternatives considered:
> >>>
> >>>1) Lazy sync - Sandbox does this. It only calls 
> >>> video_sync(true) ever
> >>>   so often. We are missing timers to do this generically.
> >>>
> >>>2) Double buffering - We could try to identify whether 
> >>> anything changed
> >>> 

Re: [PATCH 1/1] cmd: gpt: fix gpt read

[Simon Glass]

Hi Heinrich,

On Sun, 27 Aug 2023 at 01:42, Heinrich Schuchardt
 wrote:
>
> To partition a block device the partition type GUIDs are needed but 'gpt
> read' does not provide these. Add the missing parts.
>
> Part of gpt.c has been written to work with CONFIG_PARTITION_UUIDS=n. But
> when reading the disk information this is not considered. Currently we let
> CONFIG_CMD_GPT select CONFIG_PARTITION_UUIDS but we should enable dropping
> this requirement.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/gpt.c | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index 964056bd28..d5d525397f 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -173,7 +173,10 @@ static int calc_parts_list_len(int numparts)
> /* see part.h for definition of struct disk_partition */
> partlistlen += numparts * (strlen("start=MiB,") + sizeof(lbaint_t) + 
> 1);
> partlistlen += numparts * (strlen("size=MiB,") + sizeof(lbaint_t) + 
> 1);
> -   partlistlen += numparts * (strlen("uuid=;") + UUID_STR_LEN + 1);
> +   if (CONFIG_IS_ENABLED(PARTITION_UUIDS))
> +   partlistlen += numparts * (strlen("uuid=,") + UUID_STR_LEN + 
> 1);
> +   if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))
> +   partlistlen += numparts * (strlen("type=;") + UUID_STR_LEN + 
> 1);
> /* for the terminating null */
> partlistlen++;
> debug("Length of partitions_list is %d for %d partitions\n", 
> partlistlen,
> @@ -217,6 +220,12 @@ static struct disk_part *allocate_disk_part(struct 
> disk_partition *info,
> /* UUID_STR_LEN is correct, as uuid[]'s length is UUID_STR_LEN+1 
> chars */
> newpart->gpt_part_info.uuid[UUID_STR_LEN] = '\0';
>  #endif
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> +   strncpy(newpart->gpt_part_info.type_guid, (const char 
> *)info->type_guid,
> +   UUID_STR_LEN);
> +   newpart->gpt_part_info.type_guid[UUID_STR_LEN] = '\0';
> +#endif
> +
> newpart->partnum = partnum;
>
> return newpart;
> @@ -254,6 +263,9 @@ static void print_gpt_info(void)
>curr->gpt_part_info.bootable & PART_BOOTABLE);
>  #ifdef CONFIG_PARTITION_UUIDS
> printf("UUID %s\n", curr->gpt_part_info.uuid);
> +#endif
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> +   printf("Type GUID %s\n", curr->gpt_part_info.type_guid);
>  #endif
> printf("\n");
> }
> @@ -298,10 +310,16 @@ static int create_gpt_partitions_list(int numparts, 
> const char *guid,
> (unsigned long long)curr->gpt_part_info.size *
> curr->gpt_part_info.blksz);
> strncat(partitions_list, partstr, PART_NAME_LEN + 1);
> -
> +#if CONFIG_IS_ENABLED(PARTITION_UUIDS)
> strcat(partitions_list, ",uuid=");
> strncat(partitions_list, curr->gpt_part_info.uuid,
> UUID_STR_LEN + 1);
> +#endif
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> +   strcat(partitions_list, ",type=");
> +   strncat(partitions_list, curr->gpt_part_info.type_guid,
> +   UUID_STR_LEN + 1);
> +#endif

Can you please remove the #ifdefs ? We have accessors for this now in
part.h in -next


> strcat(partitions_list, ";");
> }
> return 0;
> --
> 2.40.1
>

Regards,
Simon

Re: [PATCH 1/2] dm: event: document all events

[Simon Glass]

Hi Heinrich,

On Mon, 28 Aug 2023 at 09:22, Heinrich Schuchardt
 wrote:
>
> Provide Sphinx documentation for all events.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/event.h | 84 +++--
>  1 file changed, 82 insertions(+), 2 deletions(-)
>

Great to see this, thank you

> diff --git a/include/event.h b/include/event.h
> index bb38ba98e7..6dee4adef2 100644
> --- a/include/event.h
> +++ b/include/event.h
> @@ -19,29 +19,109 @@
>   * @EVT_DM_PRE_PROBE: Device is about to be probed
>   */
>  enum event_t {
> -   EVT_NONE,
> +   /**
> +* @EVT_NONE: This zero value is not used for events.
> +*/
> +   EVT_NONE = 0,
> +
> +   /**
> +* @EVT_TEST: This event is used in unit tests.
> +*/
> EVT_TEST,
>
> /* Events related to driver model */
> +   /**
> +* @EVT_DM_POST_INIT_F:
> +* This event is triggered after initialization of the driver model
> +* before relocation. Its parameter is NULL.

Perhaps better is 'triggered after pre-relocation init of driver
model'. It seems a bit odd to have before and after in the same
sentence.

> +* A non-zero return code from the event handler let's the boot 
> process
> +* fail.
> +*/
> EVT_DM_POST_INIT_F,
> +   /**
> +* @EVT_DM_POST_INIT_R:
> +* This event is triggered after initialization of the driver model
> +* after relocation. Its parameter is NULL.

same here

> +* A non-zero return code from the event handler let's the boot 
> process
> +* fail.
> +*/
> EVT_DM_POST_INIT_R,
> +   /**
> +* @EVT_DM_PRE_PROBE:
> +* This event is triggered before probing a device. Its parameter is 
> the
> +* udevice to be probed.

device

> +* A non-zero return code lets the device not being probed.
> +*/
> EVT_DM_PRE_PROBE,
> +   /**
> +* @EVT_DM_POST_PROBE:
> +* This event is triggered after probing a device. Its parameter is 
> the
> +* udevice to be probed.

device that was probed

> +* A non-zero return code leaves the device in the unprobed state and
> +* therefore not usable.
> +*/
> EVT_DM_POST_PROBE,
> +   /**
> +* @EVT_DM_PRE_REMOVE:
> +* This event is triggered before removing a device. Its parameter is
> +* the udevice to be removed.
> +* A non-zero return code stops the removal of the device before any
> +* changes.
> +*/
> EVT_DM_PRE_REMOVE,
> +   /**
> +* @EVT_DM_POST_REMOVE:
> +* This event is triggered before removing a device. Its parameter is

after

> +* the udevice to be removed.

that was removed

> +* A non-zero return code stops the removal of the device after all
> +* removal changes. The previous state is not restored. All children
> +* will be gone and the device may not be functional.

Great!

> +*/
> EVT_DM_POST_REMOVE,
>
> /* Init hooks */
> +   /**
> +* @EVT_MISC_INIT_F:
> +* This event is triggered during the initialization sequence bofore

before

> +* relocation. Its parameter is NULL.
> +* A non-zero return code from the event handler let's the boot 
> process
> +* fail.
> +*/
> EVT_MISC_INIT_F,
>
> -   /* Fpga load hook */
> +   /**
> +* @EVT_FPGA_LOAD:
> +* The FPGA load hook is called after loading an FPGA with a new 
> binary.
> +* Its parameter is of type struct event_fpga_load and contains
> +* information about the loaded image.
> +*/
> EVT_FPGA_LOAD,
>
> /* Device tree fixups before booting */
> +   /**
> +* @EVT_FT_FIXUP:
> +* This event is triggered during device-tree fix up after all
> +* other device-tree fixups have been executed.
> +* Its parameter is of type struct event_ft_fixup which contains
> +* the address of the device-tree to fix up and the list of images to 
> be
> +* booted.

A non-zero return causes the boot to fail

> +*/
> EVT_FT_FIXUP,
>
> /* To be called once, before calling main_loop() */
> +   /**
> +* @EVT_MAIN_LOOP:
> +* This event is triggered immediately before calling main_loop() 
> which
> +* is the entry point of the command line.
> +* Its parameter is NULL.
> +*/
> EVT_MAIN_LOOP,
>
> +   /**
> +* @EVT_COUNT:
> +* This constants holds the maximum event number + 1 and is used when
> +* looping over all event classes.
> +*/
> EVT_COUNT
>  };
>
> --
> 2.40.1
>

Regards,
Simon

Re: [PATCH v3 5/9] board: qualcomm: Add support for dragonboard845c

[Simon Glass]

Hi Sumit,

On Thu, 24 Aug 2023 at 04:44, Sumit Garg  wrote:
>
> Hi Simon,
>
> On Thu, 24 Aug 2023 at 05:29, Simon Glass  wrote:
> >
> > Hi Sumit,
> >
> > On Tue, 12 Jul 2022 at 01:12, Sumit Garg  wrote:
> > >
> > > Add support for 96Boards Dragonboard 845C aka Robotics RB3 development
> > > platform. This board complies with 96Boards Open Platform Specifications.
> > >
> > > Features:
> > > - Qualcomm Snapdragon SDA845 SoC
> > > - 4GiB RAM
> > > - 64GiB UFS drive
> > >
> > > U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> > > For detailed build and boot instructions, refer to
> > > doc/board/qualcomm/sdm845.rst, board: dragonboard845c.
> > >
> > > Signed-off-by: Sumit Garg 
> > > Reviewed-by: Ramon Fried 
> > > ---
> > >  arch/arm/dts/dragonboard845c-uboot.dtsi   |  37 +++
> > >  arch/arm/dts/dragonboard845c.dts  |  44 
> > >  arch/arm/mach-snapdragon/Kconfig  |  14 +++
> > >  board/qualcomm/dragonboard845c/Kconfig|  12 +++
> > >  board/qualcomm/dragonboard845c/MAINTAINERS|   6 ++
> > >  board/qualcomm/dragonboard845c/Makefile   |   9 ++
> > >  board/qualcomm/dragonboard845c/db845c.its |  63 +++
> > >  .../dragonboard845c/dragonboard845c.c |   9 ++
> > >  configs/dragonboard845c_defconfig |  28 +
> > >  doc/board/qualcomm/sdm845.rst | 100 +++---
> > >  include/configs/dragonboard845c.h |  28 +
> > >  11 files changed, 337 insertions(+), 13 deletions(-)
> > >  create mode 100644 arch/arm/dts/dragonboard845c-uboot.dtsi
> > >  create mode 100644 arch/arm/dts/dragonboard845c.dts
> > >  create mode 100644 board/qualcomm/dragonboard845c/Kconfig
> > >  create mode 100644 board/qualcomm/dragonboard845c/MAINTAINERS
> > >  create mode 100644 board/qualcomm/dragonboard845c/Makefile
> > >  create mode 100644 board/qualcomm/dragonboard845c/db845c.its
> > >  create mode 100644 board/qualcomm/dragonboard845c/dragonboard845c.c
> > >  create mode 100644 configs/dragonboard845c_defconfig
> > >  create mode 100644 include/configs/dragonboard845c.h
> > >
> > [..]
> >
> > > diff --git a/doc/board/qualcomm/sdm845.rst b/doc/board/qualcomm/sdm845.rst
> > > index b6642c9579..8ef4749287 100644
> > > --- a/doc/board/qualcomm/sdm845.rst
> > > +++ b/doc/board/qualcomm/sdm845.rst
> > > @@ -35,9 +35,25 @@ Pack android boot image
> > >  ^^^
> > >  We'll assemble android boot image with ``u-boot.bin`` instead of linux 
> > > kernel,
> > >  and FIT image instead of ``initramfs``. Android bootloader expect 
> > > gzipped kernel
> > > -with appended dtb, so let's mimic linux to satisfy stock bootloader:
> > > +with appended dtb, so let's mimic linux to satisfy stock bootloader.
> > >
> >
> > [..]
> >
> > > +The dragonboard845c is a Qualcomm Robotics RB3 Development Platform, 
> > > based on
> > > +the Qualcomm SDM845 SoC.
> > > +
> > > +Steps:
> > > +
> > > +- Build u-boot::
> > > +
> > > +   $ export CROSS_COMPILE=
> > > +   $ make dragonboard845c_defconfig
> > > +   $ make
> > > +
> > > +- Create dummy dtb::
> > > +
> > > +   workdir=/tmp/prepare_payload
> > > +   mkdir -p "$workdir"
> > > +   mock_dtb="$workdir"/payload_mock.dtb
> > > +
> > > +   dtc -I dts -O dtb -o "$mock_dtb" << EOF
> > > +   /dts-v1/;
> > > +   / {
> > > +   #address-cells = <2>;
> > > +   #size-cells = <2>;
> > > +
> > > +   memory@8000 {
> > > +   device_type = "memory";
> > > +   /* We expect the bootloader to fill in the size */
> > > +   reg = <0 0x8000 0 0>;
> > > +   };
> > > +
> > > +   chosen { };
> > > +   };
> > > +   EOF
> > > +
> > > +- gzip u-boot::
> > > +
> > > +   gzip u-boot.bin
> > > +
> > > +- Append dtb to gzipped u-boot::
> > > +
> > > +cat u-boot.bin.gz "$mock_dtb" > u-boot.bin.gz-dtb
> > > +
> > > +- A ``db845c.its`` file can be found in 
> > > ``board/qualcomm/dragonboard845c/``
> > > +  directory. It expects a folder as ``db845c_imgs/`` in the main 
> > > directory
> > > +  containing pre-built kernel, dts and ramdisk images. See ``db845c.its``
> > > +  for full path to images::
> > > +
> > > +   mkimage -f db845c.its db845c.itb
> > > +
> > > +- Now we've got everything to build android boot image::
> > > +
> > > +   mkbootimg --kernel u-boot.bin.gz-dtb --ramdisk db845c.itb \
> > > +   --output boot.img --pagesize 4096 --base 0x8000
> > > +
> > > +- Flash boot.img using db845c fastboot method.
> >
> > What command should be used here? I can run 'fastboot devices' but am
> > not sure what command to use to flash U-Boot.
> >
>
> At the time of writing this doc, I thought it was understood how to
> flash boot.img on db845c. But I will make that more explicit. Since
> u-boot has to be chain loaded by ABL, the command to flash boot.img
> (containing u-boot) is as follows:
>
> 

Re: [RFC PATCH 5/5] doc: Add a document for non-compliant DT node/property removal

[Simon Glass]

Hi Sughosh,

On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
>
> Add a document explaining the need for removal of non-compliant
> devicetree nodes and properties. Also describe in brief, the macros
> that can be used for this removal.
>
> Signed-off-by: Sughosh Ganu 
> ---
>  .../devicetree/dt_non_compliant_purge.rst | 64 +++
>  1 file changed, 64 insertions(+)
>  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
>
> diff --git a/doc/develop/devicetree/dt_non_compliant_purge.rst 
> b/doc/develop/devicetree/dt_non_compliant_purge.rst
> new file mode 100644
> index 00..c3a8feab5b
> --- /dev/null
> +++ b/doc/develop/devicetree/dt_non_compliant_purge.rst
> @@ -0,0 +1,64 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Removal of non-compliant nodes and properties
> +=
> +
> +The devicetree used in U-Boot might contain nodes and properties which
> +are specific only to U-Boot, and are not necessarily being used to
> +describe hardware but to pass information to U-Boot. An example of
> +such a property would be the public key being passed to U-Boot for
> +verification.

It has nothing to do with describing hardware. The DT can describe
other things too. See the /options node, for example.

Please don't bring this highly misleading language into U-Boot.

> +
> +This devicetree can then be passed to the OS. Since certain nodes and
> +properties are not really describing hardware, and more importantly,
> +these are only relevant to U-Boot, bindings for these cannot be
> +upstreamed into the devicetree repository. There have been instances
> +of attempts being made to upstream such bindings, and these deemed not
> +fit for upstreaming.

Then either they should not be in U-Boot, or there is a problem with
the process.

> Not having a binding for these nodes and
> +properties means that the devicetree fails the schema compliance tests
> +[1]. This also means that the platform cannot get certifications like
> +SystemReady [2] which, among other things require a devicetree which
> +passes the schema compliance tests.
> +
> +For such nodes and properties, it has been suggested by the devicetree
> +maintainers that the right thing to do is to remove them from the
> +devicetree before it gets passed on to the OS [3].

Hard NAK. If we go this way, then no one will ever have an incentive
to do the right thing.

Please send bindings for Linaro's work, instead. If something is
entirely U-Boot-specific, then it can go in /options/u-boot but it
still must be in the dt-schema.

> +
> +Removing nodes/properties
> +-
> +
> +In U-Boot, this is been done through adding information on such nodes
> +and properties in a list. The entire node can be deleted, or a
> +specific property under a node can be deleted. The list of such nodes
> +and properties is generated at compile time, and the function to purge
> +these can be invoked through a EVT_FT_FIXUP event notify call.
> +
> +For deleting a node, this can be done by declaring a macro::
> +
> +   DT_NON_COMPLIANT_PURGE(fwu_mdata) = {
> +   .node_path  = "/fwu-mdata",
> +   };
> +
> +Similarly, for deleting a property under a node, that can be done by
> +specifying the property name::
> +
> +   DT_NON_COMPLIANT_PURGE(capsule_key) = {
> +   .node_path  = "/signature",
> +   .prop   = "capsule-key",
> +   };
> +
> +In the first example, the entire node with path /fwu-mdata will be
> +removed. In the second example, the property capsule-key
> +under /signature node will be removed.
> +
> +Similarly, a list of nodes and properties can be specified using the
> +following macro::
> +
> +   DT_NON_COMPLIANT_PURGE_LIST(foo) = {
> +   { .node_path = "/some_node", .prop = "some_bar" },
> +   { .node_path = "/some_node" },
> +   };
> +
> +[1] - https://github.com/devicetree-org/dt-schema
> +[2] - 
> https://www.arm.com/architecture/system-architectures/systemready-certification-program
> +[3] - 
> https://lore.kernel.org/u-boot/cal_jsqjn4fehoml7z3yj0wj9bpx1ose7zf26l_gv2os6cg-...@mail.gmail.com/
> --
> 2.34.1
>

Regards,
Simon

Re: [PATCH 1/2] imx: Drop unneeded phandle in FIT template

[Simon Glass]

Hi Tim,

On Mon, 28 Aug 2023 at 11:33, Tim Harvey  wrote:
>
> On Wed, Aug 23, 2023 at 6:18 PM Simon Glass  wrote:
> >
> > Adding a phandle to a template node is not allowed, since when the node is
> > instantiated multiple times, we end up with duplicate phandles.
> >
> > Drop this invalid constructs.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 2 ++
> >  arch/arm/dts/imx8mm-u-boot.dtsi   | 2 +-
> >  arch/arm/dts/imx8mn-u-boot.dtsi   | 2 +-
> >  arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi| 2 ++
> >  arch/arm/dts/imx8mp-u-boot.dtsi   | 4 ++--
> >  arch/arm/dts/imx8qm-u-boot.dtsi   | 2 +-
> >  arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  | 8 
> >  7 files changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi 
> > b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> > index 484e31824b85..d93e1cbd8a71 100644
> > --- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> > @@ -41,9 +41,11 @@
> > };
> >  };
> >
> > +/* This cannot work since it refers to a template node
> >  _configuration {
> > loadables = "atf", "fip";
> >  };
> > +*/
> >
> >   {
> > phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
> > diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi 
> > b/arch/arm/dts/imx8mm-u-boot.dtsi
> > index 035282bf0b00..6085128e24ec 100644
> > --- a/arch/arm/dts/imx8mm-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-u-boot.dtsi
> > @@ -140,7 +140,7 @@
> > configurations {
> > default = "@config-DEFAULT-SEQ";
> >
> > -   binman_configuration: @config-SEQ {
> > +   @config-SEQ {
> > description = "NAME";
> > fdt = "fdt-SEQ";
> > firmware = "uboot";
> > diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi 
> > b/arch/arm/dts/imx8mn-u-boot.dtsi
> > index 5046b38e4e29..bc57566a108f 100644
> > --- a/arch/arm/dts/imx8mn-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mn-u-boot.dtsi
> > @@ -204,7 +204,7 @@
> > configurations {
> > default = "@config-DEFAULT-SEQ";
> >
> > -   binman_configuration: @config-SEQ {
> > +   @config-SEQ {
> > description = "NAME";
> > fdt = "fdt-SEQ";
> > firmware = "uboot";
> > diff --git a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi 
> > b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
> > index f3fb44046d5c..c4ea536b29bb 100644
> > --- a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
> > @@ -162,6 +162,8 @@
> > };
> >  };
> >
> > +/* This cannot work since it refers to a template node
> >  _configuration {
> > loadables = "atf", "fip";
> >  };
> > +*/
> > diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi 
> > b/arch/arm/dts/imx8mp-u-boot.dtsi
> > index 36e7444a627b..200938a98072 100644
> > --- a/arch/arm/dts/imx8mp-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mp-u-boot.dtsi
> > @@ -146,7 +146,7 @@
> > type = "flat_dt";
> > compression = "none";
> >
> > -   uboot_fdt_blob: blob-ext {
> > +   blob-ext {
> > filename = "u-boot.dtb";
> > };
> > };
> > @@ -155,7 +155,7 @@
> > configurations {
> > default = "@config-DEFAULT-SEQ";
> >
> > -   binman_configuration: @config-SEQ {
> > +   @config-SEQ {
> > description = "NAME";
> > fdt = "fdt-SEQ";
> > firmware = "uboot";
> > diff --git a/arch/arm/dts/imx8qm-u-boot.dtsi 
> > b/arch/arm/dts/imx8qm-u-boot.dtsi
> > index a3e0af48109b..d316e869516f 100644
> > --- a/arch/arm/dts/imx8qm-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8qm-u-boot.dtsi
> > @@ -112,7 +112,7 @@
> > configurations {
> > default = "@config-DEFAULT-SEQ";
> >
> > -   binman_configuration: @config-SEQ {
> > +   @config-SEQ {
> > description = "NAME";
> > fdt = "fdt-SEQ";
> > firmware = "uboot";
> > diff --git 

Re: [PATCH v2] tools: ensure zeroed padding in external FIT images

[Simon Glass]

Hi Roman,

On Mon, 28 Aug 2023 at 02:00, Roman Azarenko  wrote:
>
> On Fri, 2023-08-25 at 12:06 -0600, Simon Glass wrote:
> > > @@ -564,9 +564,13 @@ static int fit_extract_data(struct
> > > image_tool_params *params, const char *fname)
> > >  /* Pack the FDT and place the data after it */
> > >  fdt_pack(fdt);
> > >
> > > -   new_size = fdt_totalsize(fdt);
> > > -   new_size = ALIGN(new_size, align_size);
> > > +   unpadded_size = fdt_totalsize(fdt);
> > > +   new_size = ALIGN(unpadded_size, align_size);
> > >  fdt_set_totalsize(fdt, new_size);
> >
> > I didn't know that was allowed...I thought it needed fdt_open_into() ?
>
> The introduction of fdt_set_totalsize() comes from commit ebfe611be91e
> ("mkimage: fit_image: Add option to make fit header align"). The commit
> message doesn't describe the choice of this function vs fdt_open_into().
>
> Personally I'm unable to definitively comment on it. I can only blindly
> guess, that because we're only changing the total length of the fdt
> struct, and keeping all other fields the same, we don't need to allocate
> a new fdt struct with a different size.

I am not sure if it would cause problems. I do understand that you
didn't write the code. You could copy the people who did (and those
that reviewed it) for their input.

But I think it should change to call fdt_open_into()...if you look at
that function it does extra things. Unfortunately, the function has no
comment in libfdt.h.

Could you add another patch before or after this one?

Regards,
Simon

Re: [PATCH] doc: board: sdm845: Explicitly add boot.img flashing command

[Simon Glass]

On Thu, 24 Aug 2023 at 06:44, Sumit Garg  wrote:
>
> Signed-off-by: Sumit Garg 
> ---
>  doc/board/qualcomm/sdm845.rst | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH] setexpr: Silence some diagnostic messages

[Simon Glass]

On Thu, 24 Aug 2023 at 06:51, Łukasz Stelmach  wrote:
>
> Neither successful match nor lack thereof should be considered an
> extraordinary situation. Thus, neither require printing a message.
>
> Signed-off-by: Łukasz Stelmach 
> ---
>  cmd/setexpr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH 2/2] doc: add events.h to documentation

[Simon Glass]

On Mon, 28 Aug 2023 at 09:22, Heinrich Schuchardt
 wrote:
>
> Add the events.h include to the API documentation.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  doc/api/event.rst | 9 +
>  doc/api/index.rst | 1 +
>  2 files changed, 10 insertions(+)
>  create mode 100644 doc/api/event.rst
>

Reviewed-by: Simon Glass 

Re: [PATCH] spl: bootstage: move bootstage_stash before jumping to image

[Simon Glass]

Hi Chanho,

On Mon, 28 Aug 2023 at 03:46, Chanho Park  wrote:
>
> For IH_OS_OPENSBI and IH_OS_LINUX, there is no chance to stash
> bootstare record because it will not return after jumping to the image.
> Hence, this patch moves the location of bootstage_stash before jumping
> to image.
>

Please fix your implementation instead. You must jump to the OS at the
end of this function and not before.

In fact I have a patch to move bootstage later in this function!

> Signed-off-by: Chanho Park 
> ---
>  common/spl/spl.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 0062f3f45d9a..364d439f65e2 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -850,6 +850,14 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>ret);
> }
>
> +   bootstage_mark_name(get_bootstage_id(false), "end phase");
> +#ifdef CONFIG_BOOTSTAGE_STASH
> +   ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> + CONFIG_BOOTSTAGE_STASH_SIZE);
> +   if (ret)
> +   debug("Failed to stash bootstage: err=%d\n", ret);
> +#endif
> +
> switch (spl_image.os) {
> case IH_OS_U_BOOT:
> debug("Jumping to %s...\n", spl_phase_name(spl_next_phase()));
> @@ -890,13 +898,6 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> debug("SPL malloc() used 0x%lx bytes (%ld KB)\n", gd->malloc_ptr,
>   gd->malloc_ptr / 1024);
>  #endif
> -   bootstage_mark_name(get_bootstage_id(false), "end phase");
> -#ifdef CONFIG_BOOTSTAGE_STASH
> -   ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> - CONFIG_BOOTSTAGE_STASH_SIZE);
> -   if (ret)
> -   debug("Failed to stash bootstage: err=%d\n", ret);
> -#endif
>
> if (IS_ENABLED(CONFIG_SPL_VIDEO_REMOVE)) {
> struct udevice *dev;
> --
> 2.39.2
>

Regards,
Simon

Re: [RFC PATCH 4/5] bootefi: Call the EVT_FT_FIXUP event handler

[Simon Glass]

Hi Heinrich,

On Mon, 28 Aug 2023 at 05:02, Heinrich Schuchardt  wrote:
>
> On 28.08.23 11:32, Sughosh Ganu wrote:
> > On Sat, 26 Aug 2023 at 15:57, Heinrich Schuchardt  
> > wrote:
> >>
> >> On 8/26/23 11:06, Sughosh Ganu wrote:
> >>> The bootefi command passes the devicetree to the kernel through the
> >>> EFI config table. Call the event handlers for fixing the devicetree
> >>> before jumping into the kernel. This removes any devicetree nodes
> >>> and/or properties that are specific only to U-Boot, and are not to be
> >>> passed to the OS.
> >>>
> >>> Signed-off-by: Sughosh Ganu 
> >>> ---
> >>>cmd/bootefi.c | 18 ++
> >>>1 file changed, 18 insertions(+)
> >>>
> >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >>> index f73d6eb0e2..c359a46ec4 100644
> >>> --- a/cmd/bootefi.c
> >>> +++ b/cmd/bootefi.c
> >>> @@ -237,6 +237,23 @@ static void *get_config_table(const efi_guid_t *guid)
> >>>return NULL;
> >>>}
> >>>
> >>> +/**
> >>> + * event_notify_dt_fixup() - call ft_fixup event
> >>> + *
> >>> + * @fdt: address of the device tree to be passed to the kernel
> >>> + *   through the configuration table
> >>> + * Return:   None
> >>> + */
> >>> +static void event_notify_dt_fixup(void *fdt)
> >>> +{
> >>> + int ret;
> >>> + struct event_ft_fixup fixup = {0};
> >>> +
> >>> + fixup.tree.fdt = fdt;
> >>> + ret = event_notify(EVT_FT_FIXUP, , sizeof(fixup));
> >>> + if (ret)
> >>> + printf("Error: %d: FDT Fixup event failed\n", ret);
> >>> +}
> >>>#endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */
> >>>
> >>>/**
> >>> @@ -318,6 +335,7 @@ efi_status_t efi_install_fdt(void *fdt)
> >>>efi_carve_out_dt_rsv(fdt);
> >>>
> >>>efi_try_purge_kaslr_seed(fdt);
> >>> + event_notify_dt_fixup(fdt);
> >>
> >> The event is already triggered in image_setup_libfdt(). Don't trigger it
> >> twice.
> >
> > The reason I put an explicit event_notify call is because the
> > image_setup_libfdt() call only calls the ft_fixup handlers if the
> > livetree is not active. So the fixup handlers would not be called on
> > platforms that enable livetree. Although I'm not sure if livetree
> > should be disabled before the ft fixup has to happen, or platforms
> > that need ft fixup should not enable OF_LIVE. Disabling the livetree
> > is not happening now, so I am not sure how the fixup event should work
> > on platforms which have OF_LIVE enabled.
>
> We still must not call the same event twice. We further must ensure that
> our fix-up is called last (e.g. by calling it zzz_something) and not
> before adding VBE nodes.
>
> Is there any need to use the event mechanism here?
>
> @Simon:
> None of the other function calls in image_setup_libfdt() depend on
> of_live_active(). I think it would be preferable to move that check into
> the listeners. If instead of of_live_active() you could use a
> configuration setting for the decision, gcc could eliminate a lot of code.

Firstly, of_live_active() should check CONFIG_IS_ENABLED(OF_LIVE)
first. I noticed this over the weekend when looking at something else.

The original code was due to a limitation with U-Boot's ofnode
implementation, in that it did not support multiple devicetrees
without OF_LIVE. We need to support at least two, since we have the
'control' DTB and the one being set up to boot the OS.

Anyway, that limitation can be removed, so long as
CONFIG_MULTI_DTB_FIT is set. In other words, we should enable
MULTI_DTB_FIT if !OF_LIVE and all will be well.

>
> We definitely need better descriptions in include/event.h and a man-page
> generated from that include:
>
> EVT_NONE
>  undescribed
> EVT_TEST
>  undescribed
> EVT_DM_POST_INIT_F
>  undescribed
> EVT_DM_POST_INIT_R
>  undescribed
> EVT_DM_PRE_PROBE
>  Device is about to be probed
> EVT_DM_POST_PROBE
>  undescribed
> EVT_DM_PRE_REMOVE
>  undescribed
> EVT_DM_POST_REMOVE
>  undescribed
> EVT_MISC_INIT_F
>  undescribed
> EVT_FPGA_LOAD
>  undescribed
> EVT_FT_FIXUP
>  undescribed
> EVT_MAIN_LOOP
>  undescribed
> EVT_COUNT
>  undescribed

Yes indeed. I added some for the latest patch in this area.

https://patchwork.ozlabs.org/project/uboot/patch/20230822031705.1340941-15-...@chromium.org/

Regards,
Simon

Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default

[Simon Glass]

Hi Alper,
On Mon, 28 Aug 2023 at 09:46, Alper Nebi Yasak  wrote:
>
> On 2023-08-22 21:56 +03:00, Simon Glass wrote:
> > Hi Alper,
> >
> > On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  
> > wrote:
> >>
> >> From: Alexander Graf 
> >>
> >> Now that we have everything in place to support ramfb, let's wire it up
> >> by default in the ARM QEMU targets. That way, you can easily use a
> >> graphical console by just passing -device ramfb to the QEMU command line.
> >>
> >> Signed-off-by: Alexander Graf 
> >> [Alper: Rebase on bochs changes, add pre-reloc init, error handling]
> >> Co-developed-by: Alper Nebi Yasak 
> >> Signed-off-by: Alper Nebi Yasak 
> >> ---
> >>
> >> Changes in v2:
> >> - Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
> >> - Drop env changes from ARM (necessary but in prerequisite series)
> >> - Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
> >> - Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
> >> - Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU
> >>
> >>  arch/arm/Kconfig|  3 +++
> >>  board/emulation/qemu-arm/qemu-arm.c | 41 +
> >>  2 files changed, 44 insertions(+)
> >>
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index 1fd3ccd1607f..7afe26ac804f 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -1046,6 +1046,9 @@ config ARCH_QEMU
> >> imply USB_XHCI_PCI
> >> imply USB_KEYBOARD
> >> imply CMD_USB
> >> +   imply VIDEO_RAMFB
> >> +   imply BOARD_EARLY_INIT_F
> >> +   imply BOARD_EARLY_INIT_R
> >>
> >>  config ARCH_RMOBILE
> >> bool "Renesas ARM SoCs"
> >> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> >> b/board/emulation/qemu-arm/qemu-arm.c
> >> index 942f1fff5717..23ef31cb7feb 100644
> >> --- a/board/emulation/qemu-arm/qemu-arm.c
> >> +++ b/board/emulation/qemu-arm/qemu-arm.c
> >> @@ -11,6 +11,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
> >>  struct mm_region *mem_map = qemu_arm64_mem_map;
> >>  #endif
> >>
> >> +int board_early_init_f(void)
> >> +{
> >> +   struct udevice *dev;
> >> +   int ret;
> >> +
> >> +   /*
> >> +* Make sure we enumerate the QEMU Firmware device to bind ramfb
> >> +* so video_reserve() can reserve memory for it.
> >> +*/
> >> +   if (IS_ENABLED(CONFIG_QFW)) {
> >> +   ret = qfw_get_dev();
> >> +   if (ret) {
> >> +   log_err("Failed to get QEMU FW device: %d\n", ret);
> >
> > We should only present an error if the device is present but
> > failed...so if the user doesn't provide the flag, all should be well.
>
> I don't understand what you mean by "user doesn't provide the flag". But
> I assume this should ignore the error (unless what?) so that we can
> continue to boot. Would that apply for board_early_init_r below as well?

I thought you said there was a qemu flag to enable ramfb? So add it to
the DT and then the device can (in its bind routine) decide not to be
bound by returning -ENODEV

>
> >> +   return ret;
> >> +   }
> >> +   }
> >> +
> >> +   return 0;
> >> +}
> >> +
> >> +int board_early_init_r(void)
> >> +{
> >> +   struct udevice *dev;
> >> +   int ret;
> >> +
> >> +   /*
> >> +* Make sure we enumerate the QEMU Firmware device to find ramfb
> >> +* before console_init.
> >> +*/
> >> +   if (IS_ENABLED(CONFIG_QFW)) {
> >> +   ret = qfw_get_dev();
> >> +   if (ret) {
> >> +   log_err("Failed to get QEMU FW device: %d\n", ret);
> >> +   return ret;
> >> +   }
> >> +   }
> >> +
> >> +   return 0;
> >> +}
> >> +
> >>  int board_init(void)
> >>  {
> >> return 0;
> >> --
> >> 2.40.1
> >>
> >
> > The glue here feels like a bit of a hack...we should rely on normal DT
> > mechanisms here.
> >
> > Regards,
> > Simon

Regards.

Simon

Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Tom Rini]

On Mon, Aug 28, 2023 at 10:19:55AM -0600, Simon Glass wrote:
> Hi,
> 
> On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
> >
> >
> > Provide a way for removing certain devicetree nodes and/or properties
> > from the devicetree. This is needed to purge certain nodes and
> > properties which may be relevant only in U-Boot. Such nodes and
> > properties are then removed from the devicetree before it is passed to
> > the kernel. This ensures that the devicetree passed to the OS does not
> > contain any non-compliant nodes and properties.
> >
> > The removal of the nodes and properties is being done through an
> > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> > behind any Kconfig symbol.
> >
> > I have only build tested this on sandbox, and tested on qemu arm64
> > virt platform. This being a RFC, I have not put this through a CI run.
> >
> > Sughosh Ganu (5):
> >   dt: Provide a way to remove non-compliant nodes and properties
> >   fwu: Add the fwu-mdata node for removal from devicetree
> >   capsule: Add the capsule-key property for removal from devicetree
> >   bootefi: Call the EVT_FT_FIXUP event handler
> >   doc: Add a document for non-compliant DT node/property removal
> >
> >  cmd/bootefi.c | 18 +
> >  .../devicetree/dt_non_compliant_purge.rst | 64 
> >  drivers/fwu-mdata/fwu-mdata-uclass.c  |  5 ++
> >  include/dt-structs.h  | 11 +++
> >  lib/Makefile  |  1 +
> >  lib/dt_purge.c| 73 +++
> >  lib/efi_loader/efi_capsule.c  |  7 ++
> >  7 files changed, 179 insertions(+)
> >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> >  create mode 100644 lib/dt_purge.c
> 
> What is the point of removing them? Instead, we should make sure that
> we upstream the bindings and encourage SoC vendors to sync them. If we
> remove them, no one will bother and U-Boot just becomes a dumping
> ground.

It's about having a defined process to remove them, rather than an
ad-hoc process like one can do today to remove them. And it's about
having control over the situation rather than dismissing it, as vendor
can already say they used $this version of the software for validation,
so patches-on-top aren't out of the question.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Simon Glass]

Hi Peter,

On Mon, 28 Aug 2023 at 10:37, Peter Robinson  wrote:
>
> On Mon, Aug 28, 2023 at 5:20 PM Simon Glass  wrote:
> >
> > Hi,
> >
> > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
> > >
> > >
> > > Provide a way for removing certain devicetree nodes and/or properties
> > > from the devicetree. This is needed to purge certain nodes and
> > > properties which may be relevant only in U-Boot. Such nodes and
> > > properties are then removed from the devicetree before it is passed to
> > > the kernel. This ensures that the devicetree passed to the OS does not
> > > contain any non-compliant nodes and properties.
> > >
> > > The removal of the nodes and properties is being done through an
> > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> > > behind any Kconfig symbol.
> > >
> > > I have only build tested this on sandbox, and tested on qemu arm64
> > > virt platform. This being a RFC, I have not put this through a CI run.
> > >
> > > Sughosh Ganu (5):
> > >   dt: Provide a way to remove non-compliant nodes and properties
> > >   fwu: Add the fwu-mdata node for removal from devicetree
> > >   capsule: Add the capsule-key property for removal from devicetree
> > >   bootefi: Call the EVT_FT_FIXUP event handler
> > >   doc: Add a document for non-compliant DT node/property removal
> > >
> > >  cmd/bootefi.c | 18 +
> > >  .../devicetree/dt_non_compliant_purge.rst | 64 
> > >  drivers/fwu-mdata/fwu-mdata-uclass.c  |  5 ++
> > >  include/dt-structs.h  | 11 +++
> > >  lib/Makefile  |  1 +
> > >  lib/dt_purge.c| 73 +++
> > >  lib/efi_loader/efi_capsule.c  |  7 ++
> > >  7 files changed, 179 insertions(+)
> > >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> > >  create mode 100644 lib/dt_purge.c
> >
> > What is the point of removing them? Instead, we should make sure that
> > we upstream the bindings and encourage SoC vendors to sync them. If we
> > remove them, no one will bother and U-Boot just becomes a dumping
> > ground.
>
> Well things like the binman entries in DT are U-Boot specific and not
> useful for HW related descriptions or for Linux or another OS being
> able to deal with HW so arguably we're already a dumping ground to
> some degree for not defining hardware.

I have started the process to upstream the binman bindings.

Perhaps we should use the issue tracker[1] to follow progress on all
of this. We need to clean it up.

>
> > Instead of this, how about working on bringing the DT validation into
> > U-Boot so we can see what state things are in?
> >
> > Please send the bindings for Linaro's recent series (which I suspect
> > are motivating this series) so we can start the process.

Regards,
Simon

[1] https://source.denx.de/u-boot/u-boot/-/issues

Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Tom Rini]

On Mon, Aug 28, 2023 at 05:37:45PM +0100, Peter Robinson wrote:
> On Mon, Aug 28, 2023 at 5:20 PM Simon Glass  wrote:
> >
> > Hi,
> >
> > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
> > >
> > >
> > > Provide a way for removing certain devicetree nodes and/or properties
> > > from the devicetree. This is needed to purge certain nodes and
> > > properties which may be relevant only in U-Boot. Such nodes and
> > > properties are then removed from the devicetree before it is passed to
> > > the kernel. This ensures that the devicetree passed to the OS does not
> > > contain any non-compliant nodes and properties.
> > >
> > > The removal of the nodes and properties is being done through an
> > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> > > behind any Kconfig symbol.
> > >
> > > I have only build tested this on sandbox, and tested on qemu arm64
> > > virt platform. This being a RFC, I have not put this through a CI run.
> > >
> > > Sughosh Ganu (5):
> > >   dt: Provide a way to remove non-compliant nodes and properties
> > >   fwu: Add the fwu-mdata node for removal from devicetree
> > >   capsule: Add the capsule-key property for removal from devicetree
> > >   bootefi: Call the EVT_FT_FIXUP event handler
> > >   doc: Add a document for non-compliant DT node/property removal
> > >
> > >  cmd/bootefi.c | 18 +
> > >  .../devicetree/dt_non_compliant_purge.rst | 64 
> > >  drivers/fwu-mdata/fwu-mdata-uclass.c  |  5 ++
> > >  include/dt-structs.h  | 11 +++
> > >  lib/Makefile  |  1 +
> > >  lib/dt_purge.c| 73 +++
> > >  lib/efi_loader/efi_capsule.c  |  7 ++
> > >  7 files changed, 179 insertions(+)
> > >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> > >  create mode 100644 lib/dt_purge.c
> >
> > What is the point of removing them? Instead, we should make sure that
> > we upstream the bindings and encourage SoC vendors to sync them. If we
> > remove them, no one will bother and U-Boot just becomes a dumping
> > ground.
> 
> Well things like the binman entries in DT are U-Boot specific and not
> useful for HW related descriptions or for Linux or another OS being
> able to deal with HW so arguably we're already a dumping ground to
> some degree for not defining hardware.

It's about validation and Simon is literally in the process of having
the binman bindings upstreamed.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] imx: Drop unneeded phandle in FIT template

[Tim Harvey]

On Wed, Aug 23, 2023 at 6:18 PM Simon Glass  wrote:
>
> Adding a phandle to a template node is not allowed, since when the node is
> instantiated multiple times, we end up with duplicate phandles.
>
> Drop this invalid constructs.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 2 ++
>  arch/arm/dts/imx8mm-u-boot.dtsi   | 2 +-
>  arch/arm/dts/imx8mn-u-boot.dtsi   | 2 +-
>  arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi| 2 ++
>  arch/arm/dts/imx8mp-u-boot.dtsi   | 4 ++--
>  arch/arm/dts/imx8qm-u-boot.dtsi   | 2 +-
>  arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  | 8 
>  7 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi 
> b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> index 484e31824b85..d93e1cbd8a71 100644
> --- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> @@ -41,9 +41,11 @@
> };
>  };
>
> +/* This cannot work since it refers to a template node
>  _configuration {
> loadables = "atf", "fip";
>  };
> +*/
>
>   {
> phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
> index 035282bf0b00..6085128e24ec 100644
> --- a/arch/arm/dts/imx8mm-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-u-boot.dtsi
> @@ -140,7 +140,7 @@
> configurations {
> default = "@config-DEFAULT-SEQ";
>
> -   binman_configuration: @config-SEQ {
> +   @config-SEQ {
> description = "NAME";
> fdt = "fdt-SEQ";
> firmware = "uboot";
> diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
> index 5046b38e4e29..bc57566a108f 100644
> --- a/arch/arm/dts/imx8mn-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-u-boot.dtsi
> @@ -204,7 +204,7 @@
> configurations {
> default = "@config-DEFAULT-SEQ";
>
> -   binman_configuration: @config-SEQ {
> +   @config-SEQ {
> description = "NAME";
> fdt = "fdt-SEQ";
> firmware = "uboot";
> diff --git a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi 
> b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
> index f3fb44046d5c..c4ea536b29bb 100644
> --- a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
> @@ -162,6 +162,8 @@
> };
>  };
>
> +/* This cannot work since it refers to a template node
>  _configuration {
> loadables = "atf", "fip";
>  };
> +*/
> diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
> index 36e7444a627b..200938a98072 100644
> --- a/arch/arm/dts/imx8mp-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-u-boot.dtsi
> @@ -146,7 +146,7 @@
> type = "flat_dt";
> compression = "none";
>
> -   uboot_fdt_blob: blob-ext {
> +   blob-ext {
> filename = "u-boot.dtb";
> };
> };
> @@ -155,7 +155,7 @@
> configurations {
> default = "@config-DEFAULT-SEQ";
>
> -   binman_configuration: @config-SEQ {
> +   @config-SEQ {
> description = "NAME";
> fdt = "fdt-SEQ";
> firmware = "uboot";
> diff --git a/arch/arm/dts/imx8qm-u-boot.dtsi b/arch/arm/dts/imx8qm-u-boot.dtsi
> index a3e0af48109b..d316e869516f 100644
> --- a/arch/arm/dts/imx8qm-u-boot.dtsi
> +++ b/arch/arm/dts/imx8qm-u-boot.dtsi
> @@ -112,7 +112,7 @@
> configurations {
> default = "@config-DEFAULT-SEQ";
>
> -   binman_configuration: @config-SEQ {
> +   @config-SEQ {
> description = "NAME";
> fdt = "fdt-SEQ";
> firmware = "uboot";
> diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi 
> b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> index 3ecb461b0110..64318d09cf0a 100644
> --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> @@ -41,7 +41,7 @@
> os = 

Re: [PATCH v1 0/4] J721E DTS Sync with Kernel v6.5-rc1

[Nishanth Menon]

On 17:01-20230828, Neha Malcom Francis wrote:
> This series aims to sync kernel.org v6.5-rc1 DTS with that of U-Boot. It
> also includes cleanups where necessary along with certain changes to
> ensure boot is unaffected.
> 
> While it's mainly synced to the tag v6.5-rc1, one extra commit has been
> added that cleans up duplicating wkup_i2c0 nodes [1] in Kernel.
> 
> Same as with other board series that have taken up this effort, cleanup
> of mcu_ringacc and mcu_udmap are dependent on MCU Ringacc [2] and DMA
> [3] fixes. This will be taken up after their merge to Linux.
> 
> [1] https://lore.kernel.org/all/20230721082344.1534094-1-u-kum...@ti.com/
> [2] https://lore.kernel.org/all/20230809175932.2553156-1-vigne...@ti.com/
> [3] https://lore.kernel.org/all/20230810174356.3322583-1-vigne...@ti.com/
> 
> Boot logs:
> https://gist.github.com/nehamalcom/231426b784e0ba96ef3a0da84346e038
> 
> Neha Malcom Francis (4):
>   arm: dts: k3-j721e-r5: Clean up inclusion hierarchy
>   arm: dts: k3-j721e: Sync with v6.5-rc1
>   drivers: misc: k3_avs: Add linux compatible to maintain sync
>   configs: j721e: Remove HBMC_AM654 config
please change the order of patches:
a) introduce the driver change for vtm
b) cleanup config and drop the hbmc node stuff
c) rest of dts sync

NOTE:
* J721e does'nt use SYSFW - it uses TIFS
* for properties that dont use bootph or u-boot, properties, we
  should'nt be including property changes in u-boot.dtsi or r5.dts
  without explanation as to what.
* There is a bunch of /delete-property/ plugged in for no clear reason.
  I see that even for timer - but timer data could have been included in
  arch/arm/mach-k3/j721e/dev-data.c and so could have been others too.
  This needs clear explanation.

> 
>  .../k3-j721e-common-proc-board-u-boot.dtsi| 139 ++-
>  arch/arm/dts/k3-j721e-common-proc-board.dts   | 483 ++---
>  arch/arm/dts/k3-j721e-main.dtsi   | 974 --
>  arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 280 -
>  .../k3-j721e-r5-common-proc-board-u-boot.dtsi |  29 -
>  .../arm/dts/k3-j721e-r5-common-proc-board.dts | 308 +-
>  arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi   |  31 -
>  arch/arm/dts/k3-j721e-r5-sk.dts   | 536 +-
>  arch/arm/dts/k3-j721e-sk-u-boot.dtsi  | 158 +--
>  arch/arm/dts/k3-j721e-sk.dts  | 663 +---
>  arch/arm/dts/k3-j721e-som-p0.dtsi | 213 ++--
>  arch/arm/dts/k3-j721e-thermal.dtsi|  75 ++
>  arch/arm/dts/k3-j721e.dtsi|  32 +-
>  configs/j721e_evm_a72_defconfig   |   1 -
>  configs/j721e_evm_r5_defconfig|   1 -
>  drivers/misc/k3_avs.c |   1 +
>  16 files changed, 2428 insertions(+), 1496 deletions(-)
>  delete mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi
>  create mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi
> 
> -- 
> 2.34.1
> 

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

Re: [PATCH v1 2/4] arm: dts: k3-j721e: Sync with v6.5-rc1

[Nishanth Menon]

On 17:01-20230828, Neha Malcom Francis wrote:
> Sync k3-j721e DTS with kernel.org v6.5-rc1.
>   * pcie_epx nodes have been deleted, they are not needed [1]
>   * use mcu_timer0 instead of the redundant timer1. Also delete
> clock and power domain properties since J721E follows legacy
> boot flow where system firmware is not yet available to modify
> clocks
>   * remove mcu_i2c0 as it is used for tps659413 PMIC in j721e-sk
> for which support is not yet added.
>   * remove main_i2c2 pinmux for j721e-sk as it is connected to the
> test automation header for which support is not there
>   * change mcu_secproxy to secure_proxy_mcu since linux has
> defined these nodes
>   * hbmc nodes have been disabled as their support in kernel
> itself is unfinished (dependent series not merged) [2]
>   * Drop mcu_cpsw node in U-Boot as it is no longer needed here
> thanks to [3]

Just use spaces.

You do not need to provide changelog to all the u-boot changes in the commit
message - use the diffstat for that. if you are referring to topics such
as those use commit id style.

[...]

> diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
> b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> index 540c847eb3..6a95ed2a96 100644
> --- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> @@ -8,12 +8,10 @@
>  
>  / {
>   chosen {
> - stdout-path = "serial2:115200n8";
> - tick-timer = 
> + tick-timer = _timer0;

Looking at Manorit's series, I realized that tick-timer property is only
needed for R5 dts.

>   };
>  
>   aliases {
> - ethernet0 = _port1;
>   spi0 = 
>   spi1 = 
You don't need any of these. nor do you need i2c aliases etc. all those
come from the board.dts.

>   remoteproc0 = _r5fss0_core0;

remoteproc aliases is probably needed to remain sane - upstream kernel
maintainer hasn't agreed[1] to pick up aliases so far.

> @@ -34,52 +32,44 @@
>  
>  _main{

watch for that space after nodename _main { instead of _main{

>   bootph-pre-ram;
[...]

>   assigned-clock-parents = <_clks 295 0>, <_clks 295 9>;

Why do we still have this for _pll1_refclk and _pll1_refclk
_pcie_link ?

Also why  are we dropping assigned-clocks and assigned-clock-parents in
? And these dont even have a bootph or u-boot, property - so
what is the point in invoking them if they are'nt getting set in early
stages of boot. if this is a valid clocking bug, fix should have gone to
kernel - and document it as such.

[...]

I will comment about dr_mode and usb

There is a bit of a debate ongoing on this.
https://lore.kernel.org/u-boot/20230706-handle-otg-as-periph-v3-0-27e24fa17...@baylibre.com/

But I don't see why we need to hold off for that resolution.

>  _mmc1_pins_default {
>   bootph-pre-ram;
>  };
> @@ -169,8 +158,14 @@
>   bootph-pre-ram;
>  };
>  
> +_uart0 {
> + bootph-pre-ram;
> + status = "okay";
> +};
> +
>  _i2c0 {
>   bootph-pre-ram;
> + status = "okay";
>  };
>  
>  _i2c0 {
> @@ -181,6 +176,10 @@
>   bootph-pre-ram;
>  };
>  
> +_esm{

Watch out for that space before {.

> + bootph-pre-ram;
> +};
> +
>   {
>   bootph-pre-ram;
>  };
> @@ -194,6 +193,7 @@
>  };
>  
>   {
> + status = "disabled";
>   bootph-pre-ram;
>  
>   flash@0,0 {

Just drop the flash information etc in the node and mark the node as disabled.

> @@ -268,7 +268,38 @@
>   assigned-clock-parents = <_pll1_refclk>;
>  };
>  
> -_qsgmii_link {
> - assigned-clocks = < CDNS_SIERRA_PLL_CMNLC1>;
> - assigned-clock-parents = <_pll1_refclk>;
> +_crypto {
> + dma-coherent;
> +};

Why?

> +
> + {
> + clocks = <_clks 264 1>;
> +};

We don't even use rng in u-boot.

> +
> +_i2c2 {
> + status = "okay";
> +};
> +
> +_i2c4 {
> + status = "okay";
> +};
> +
> +_i2c5 {
> + status = "okay";
> +};

You need all of these in u-boot? They dont even have bootph properties.
nothing without bootph OR u-boot, properties should even be present in
u-boot.dtsi

> +
> +_uart0 {
> + status = "okay";
> +};
> +
> +_i2c0 {
> + status = "okay";
> +};
> +
> +_i2c1 {
> + status = "okay";
> +};
> +
> + {
> + status = "disabled";
>  };

Why not just leave things as is from kernel dts?

[...]

> diff --git a/arch/arm/dts/k3-j721e-r5-comm

Re: [PATCH v1 2/4] arm: dts: k3-j721e: Sync with v6.5-rc1

[Nishanth Menon]

On 17:01-20230828, Neha Malcom Francis wrote:
> Sync k3-j721e DTS with kernel.org v6.5-rc1.
>   * pcie_epx nodes have been deleted, they are not needed [1]
>   * use mcu_timer0 instead of the redundant timer1. Also delete
> clock and power domain properties since J721E follows legacy
> boot flow where system firmware is not yet available to modify
> clocks
>   * remove mcu_i2c0 as it is used for tps659413 PMIC in j721e-sk
> for which support is not yet added.
>   * remove main_i2c2 pinmux for j721e-sk as it is connected to the
> test automation header for which support is not there
>   * change mcu_secproxy to secure_proxy_mcu since linux has
> defined these nodes
>   * hbmc nodes have been disabled as their support in kernel
> itself is unfinished (dependent series not merged) [2]
>   * Drop mcu_cpsw node in U-Boot as it is no longer needed here
> thanks to [3]
> 
> [1] https://lore.kernel.org/lkml/20230515172137.474626-2-...@ti.com/
> [2] https://lore.kernel.org/all/20230513123313.11462-2-vaishna...@ti.com/
> [3] https://lore.kernel.org/all/20230722193151.117345-1-rog...@kernel.org/
> 
> Signed-off-by: Neha Malcom Francis 
> ---
>  .../k3-j721e-common-proc-board-u-boot.dtsi| 139 ++-
>  arch/arm/dts/k3-j721e-common-proc-board.dts   | 483 ++---
>  arch/arm/dts/k3-j721e-main.dtsi   | 974 --
>  arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 280 -
>  .../arm/dts/k3-j721e-r5-common-proc-board.dts | 270 +
>  arch/arm/dts/k3-j721e-r5-sk.dts   | 493 +
>  arch/arm/dts/k3-j721e-sk-u-boot.dtsi  | 158 +--
>  arch/arm/dts/k3-j721e-sk.dts  | 663 +---
>  arch/arm/dts/k3-j721e-som-p0.dtsi | 213 ++--

Are you sure you copied this correctly?
I see this change when i copy in files from 6.5-rc1 linux kernel *after*
I applied this series of patches.

diff --git a/arch/arm/dts/k3-j721e-som-p0.dtsi 
b/arch/arm/dts/k3-j721e-som-p0.dtsi
index e90e43202546..38ae13cc3aa3 100644
--- a/arch/arm/dts/k3-j721e-som-p0.dtsi
+++ b/arch/arm/dts/k3-j721e-som-p0.dtsi
@@ -201,6 +201,19 @@
};
 };
 
+_i2c0 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0_pins_default>;
+   clock-frequency = <40>;
+
+   eeprom@50 {
+   /* CAV24C256WE-GT3 */
+   compatible = "atmel,24c256";
+   reg = <0x50>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_fss0_ospi0_pins_default>;

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

Re: [PATCH v2 1/6] configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM

[Nishanth Menon]

On 16:46-20230825, Manorit Chawdhry wrote:
> From: Udit Kumar 
> 
> The malloc capacity in DRAM at R5 SPL is set to 1MB which isn't
> sufficient to load the new tispl.bin to
> enable loading of tispl.bin the size is increased by 256KB to 1.25MB.
> 
> Cc: Nikhil M Jain 
> Signed-off-by: Udit Kumar 
> Signed-off-by: Manorit Chawdhry 
> ---
>  configs/j721s2_evm_r5_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig
> index 1e66ac23d05b..e2b83b337809 100644
> --- a/configs/j721s2_evm_r5_defconfig
> +++ b/configs/j721s2_evm_r5_defconfig
> @@ -42,6 +42,7 @@ CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
>  CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x14
>  CONFIG_SPL_SEPARATE_BSS=y
>  CONFIG_SYS_SPL_MALLOC=y
>  CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y

Though this makes me curious who AM62x did'nt need this.. but anyways..


Reviewed-by: Nishanth Menon 

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

Re: [PATCH v2 6/6] board: ti: j721s2: MAINTAINERS: Update the MAINTAINERS File.

[Nishanth Menon]

On 16:47-20230825, Manorit Chawdhry wrote:
> Update the MAINTAINERS file and propose a new MAINTAINER for j721s2 due
> to the previous MAINTAINER not being associated with TI.
> 
> Signed-off-by: Manorit Chawdhry 
> ---
>  board/ti/j721s2/MAINTAINERS | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/board/ti/j721s2/MAINTAINERS b/board/ti/j721s2/MAINTAINERS
> index 323bd2353a7e..97a0581d0405 100644
> --- a/board/ti/j721s2/MAINTAINERS
> +++ b/board/ti/j721s2/MAINTAINERS
> @@ -1,7 +1,8 @@
>  J721S2 BOARD
> -M:   Aswath Govindraju 
> +M:   Manorit Chawdhry 

Thank you for stepping up.

>  S:   Maintained
>  F:   board/ti/j721s2
> +F:   doc/board/ti/j721s2_evm.rst
>  F:   include/configs/j721s2_evm.h
>  F:   configs/j721s2_evm_r5_defconfig
>  F:   configs/j721s2_evm_a72_defconfig
> @@ -11,6 +12,6 @@ F:  arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi
>  F:   arch/arm/dts/k3-j721s2-som-p0.dtsi
>  F:   arch/arm/dts/k3-j721s2-common-proc-board.dts
>  F:   arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
> -F:   arch/arm/dts//k3-j721s2-r5-common-proc-board.dts
> +F:   arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
>  F:   arch/arm/dts/k3-j721s2-ddr.dtsi
>  F:   arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi


I suggest adding additional patch to include AM68 as well.

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

Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Peter Robinson]

On Mon, Aug 28, 2023 at 5:20 PM Simon Glass  wrote:
>
> Hi,
>
> On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
> >
> >
> > Provide a way for removing certain devicetree nodes and/or properties
> > from the devicetree. This is needed to purge certain nodes and
> > properties which may be relevant only in U-Boot. Such nodes and
> > properties are then removed from the devicetree before it is passed to
> > the kernel. This ensures that the devicetree passed to the OS does not
> > contain any non-compliant nodes and properties.
> >
> > The removal of the nodes and properties is being done through an
> > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> > behind any Kconfig symbol.
> >
> > I have only build tested this on sandbox, and tested on qemu arm64
> > virt platform. This being a RFC, I have not put this through a CI run.
> >
> > Sughosh Ganu (5):
> >   dt: Provide a way to remove non-compliant nodes and properties
> >   fwu: Add the fwu-mdata node for removal from devicetree
> >   capsule: Add the capsule-key property for removal from devicetree
> >   bootefi: Call the EVT_FT_FIXUP event handler
> >   doc: Add a document for non-compliant DT node/property removal
> >
> >  cmd/bootefi.c | 18 +
> >  .../devicetree/dt_non_compliant_purge.rst | 64 
> >  drivers/fwu-mdata/fwu-mdata-uclass.c  |  5 ++
> >  include/dt-structs.h  | 11 +++
> >  lib/Makefile  |  1 +
> >  lib/dt_purge.c| 73 +++
> >  lib/efi_loader/efi_capsule.c  |  7 ++
> >  7 files changed, 179 insertions(+)
> >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> >  create mode 100644 lib/dt_purge.c
>
> What is the point of removing them? Instead, we should make sure that
> we upstream the bindings and encourage SoC vendors to sync them. If we
> remove them, no one will bother and U-Boot just becomes a dumping
> ground.

Well things like the binman entries in DT are U-Boot specific and not
useful for HW related descriptions or for Linux or another OS being
able to deal with HW so arguably we're already a dumping ground to
some degree for not defining hardware.

> Instead of this, how about working on bringing the DT validation into
> U-Boot so we can see what state things are in?
>
> Please send the bindings for Linaro's recent series (which I suspect
> are motivating this series) so we can start the process.
>
> Regards,
> Simon

Re: [PATCH v2 2/6] arm: mach-k3: j721s2: Add mcu_timer0 id to the dev list

[Nishanth Menon]

On 16:47-20230825, Manorit Chawdhry wrote:
> mcu_timer0 is used by u-boot as the tick-timer. Add it to the soc
> devices lsit so it an be enabled via the k3 power controller.
> 
> Signed-off-by: Manorit Chawdhry 

> ---
>  arch/arm/mach-k3/j721s2/dev-data.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-k3/j721s2/dev-data.c 
> b/arch/arm/mach-k3/j721s2/dev-data.c
> index 8c999a3c5a8b..df70c5e5d7c0 100644
> --- a/arch/arm/mach-k3/j721s2/dev-data.c
> +++ b/arch/arm/mach-k3/j721s2/dev-data.c
> @@ -47,6 +47,7 @@ static struct ti_lpsc soc_lpsc_list[] = {
>  };
>  
>  static struct ti_dev soc_dev_list[] = {
> + PSC_DEV(35, _lpsc_list[0]),

Reviewed that mcu_timer0 with device ID 35 maps to LPSC_wkup_alwayson
which maps to index 0.

Reviewed-by: Nishanth Menon 

>   PSC_DEV(108, _lpsc_list[0]),
>   PSC_DEV(109, _lpsc_list[0]),
>   PSC_DEV(110, _lpsc_list[0]),
> 
> -- 
> 2.41.0
> 

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

Re: [PATCH v2 4/6] k3-am68: Sync from Linux tag v6.5-rc1

[Nishanth Menon]

On 16:47-20230825, Manorit Chawdhry wrote:
> The following commit syncs the device tree from Linux tag
> v6.5-rc1 to U-boot and fixes the following to be compatible with
> the future syncs -
> 
[..]

> 
> Signed-off-by: Manorit Chawdhry 
> ---
>  arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi |  69 ++---
>  arch/arm/dts/k3-am68-sk-base-board.dts | 389 
> +++--
>  arch/arm/dts/k3-am68-sk-r5-base-board.dts  | 143 ++---
>  arch/arm/dts/k3-am68-sk-som.dtsi   | 112 ++-

These files don't have maintainer entries?

>  4 files changed, 300 insertions(+), 413 deletions(-)
> 
> diff --git a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi 
> b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
> index 79faa1b5737d..b05a2245b6da 100644
> --- a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
> +
[...]

> + {
> + dr_mode = "peripheral";

There is a bit of a debate ongoing on this.
https://lore.kernel.org/u-boot/20230706-handle-otg-as-periph-v3-0-27e24fa17...@baylibre.com/

But I don't see why we need to hold off for that resolution.

>   bootph-pre-ram;
>  };
> diff --git a/arch/arm/dts/k3-am68-sk-r5-base-board.dts 
> b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
> index a64baba14986..bb49e866aa2c 100644
> --- a/arch/arm/dts/k3-am68-sk-r5-base-board.dts
> +++ b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
> @@ -1,19 +1,19 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> + * Copyright (C) 2022-2023 Texas Instruments Incorporated - 
> https://www.ti.com/
>   */
>  
>  /dts-v1/;
>  
> -#include "k3-am68-sk-som.dtsi"
> +#include "k3-am68-sk-base-board.dts"
>  #include "k3-j721s2-ddr-evm-lp4-4266.dtsi"
>  #include "k3-j721s2-ddr.dtsi"
> +#include "k3-am68-sk-base-board-u-boot.dtsi"
>  
>  / {
>   chosen {
> - firmware-loader = _loader0;
>   stdout-path = _uart8;

Does'nt this come from board.dts?

[...]

>  _ringacc {
> @@ -191,4 +85,3 @@
>   ti,sci = <_tifs>;
>  };
>  
There is an extra EoL here.
> -#include "k3-am68-sk-base-board-u-boot.dtsi"
[...]
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 3/6] k3-j721s2: Sync from Linux tag v6.5-rc1

[Nishanth Menon]

On 16:47-20230825, Manorit Chawdhry wrote:
> The following commit syncs the device tree from Linux tag
> v6.5-rc1 to U-boot and fixes the following to be compatible with
> the future syncs -

[...]

> 
> diff --git a/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi 
> b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
> index f940ffee8787..faa01169ebd8 100644
> --- a/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
> @@ -1,28 +1,10 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
>  

[...]
> -_sdhci1 {
> + {
> + dr_mode = "peripheral";
There is a bit of a debate going on this one
https://lore.kernel.org/u-boot/20230706-handle-otg-as-periph-v3-0-27e24fa17...@baylibre.com/

But I don't see why we need to hold off for that resolution.

>   bootph-pre-ram;
>  };

[...]

> diff --git a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts 
> b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
> index c74e8e58ae81..022618b37c74 100644
> --- a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
> @@ -1,20 +1,19 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
> + * Copyright (C) 2021-2023 Texas Instruments Incorporated - 
> https://www.ti.com/
>   */
>  
>  /dts-v1/;
>  
> -#include "k3-j721s2-som-p0.dtsi"
> +#include "k3-j721s2-common-proc-board.dts"
>  #include "k3-j721s2-ddr-evm-lp4-4266.dtsi"
>  #include "k3-j721s2-ddr.dtsi"
> -#include "k3-j721s2-binman.dtsi"
> +#include "k3-j721s2-common-proc-board-u-boot.dtsi"
>  
>  / {
>   chosen {
> - firmware-loader = _loader0;
>   stdout-path = _uart8;
we don't need this either.

[...]

> - clk_19_2mhz: dummy_clock_19_2mhz {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <1920>;
> +_timer0 {
> + clock-frequency = <25000>;
>   bootph-pre-ram;

Check your tabs for the clock-frequency and bootph property (you have
one extra tab tab).

> - };
>  };
>  

[...]

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

Re: [PATCH v3 00/13] Fuzzing and ASAN for sandbox

[Simon Glass]

Hi Andrew,

On Mon, 30 May 2022 at 04:00, Andrew Scull  wrote:
>
> This series introduces ASAN and a basic fuzzing infrastructure that
> works with sandbox. The example fuzz test towards the end of the series
> will find something pretty quickly. That something is fixed by the
> series "virtio: Harden and test vring" that needs to be applied for the
> final patch in this series.
>
> There is some refactoring to stop using '.' prefixed sections. ELF
> defines sections with names that contain anything that isn't
> alphanumeric or an underscore as being for system use which means
> clang's ASAN instrumentation happily add redzones between the contained
> objects. That's not what we want for things like linker lists where the
> linker script has carefully placed the sections contiguously. By
> renaming the sections, clang sees them as user sections and doesn't add
> instrumentation.
>
> ASAN is left disabled by default as there are still some tests that it
> triggers on and will need some more investigation to fix. It can be
> enabled with CONFIG_ASAN or passing `-a ASAN` to buildman.
>
> I abandonded the previous attempts to refactor sandbox EFI and getopt
> declaration as the changes resulted in problems out of the scope of this
> CL. I haven't tried to understand what EFI on sandbox should look like,
> but I have found that the linker list implementation is very brittle
> when up against compiler optimisation since ef123c5253 started to use
> static, zero-length arrays to mark the beginning and end of lists but
> the compiler see this as something it can get rid of.
>
> From v1:
>  - corrected handling of EFI symbols by sandbox linker script
>  - per comments, some renaming and explaining
>  - dropped RFC for dlmalloc ASAN instrumentation (work required to improve it)
>  - added patch to reduce logging noise in fuzzer
>
> From v2:
>  - remove sandbox EFI and getopt refactoring, they obstruct the series
>  - resolve a couple more ASAN errors
>  - fix LTO, xtensa and MIPS builds
>  - add ASAN build targets for CI
>
> Andrew Scull (13):
>   serial: sandbox: Fix buffer underflow in puts
>   sandbox: Rename EFI runtime sections
>   sandbox: Rename getopt sections
>   linker_lists: Rename sections to remove . prefix
>   sandbox: Add support for Address Sanitizer
>   test/py: test_stackprotector: Disable for ASAN
>   CI: Azure: Build with ASAN enabled
>   fuzzing_engine: Add fuzzing engine uclass
>   test: fuzz: Add framework for fuzzing
>   sandbox: Decouple program entry from sandbox init
>   sandbox: Add libfuzzer integration
>   sandbox: Implement fuzzing engine driver
>   fuzz: virtio: Add fuzzer for vring
>
>  .azure-pipelines.yml  |  6 ++
>  Kconfig   | 16 
>  arch/Kconfig  |  2 +
>  arch/arc/cpu/u-boot.lds   |  4 +-
>  arch/arm/config.mk|  4 +-
>  arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds   |  4 +-
>  arch/arm/cpu/armv7/sunxi/u-boot-spl.lds   |  4 +-
>  arch/arm/cpu/armv8/u-boot-spl.lds |  4 +-
>  arch/arm/cpu/armv8/u-boot.lds |  4 +-
>  arch/arm/cpu/u-boot-spl.lds   |  4 +-
>  arch/arm/cpu/u-boot.lds   |  6 +-
>  arch/arm/mach-at91/arm926ejs/u-boot-spl.lds   |  2 +-
>  arch/arm/mach-at91/armv7/u-boot-spl.lds   |  2 +-
>  arch/arm/mach-omap2/u-boot-spl.lds|  4 +-
>  arch/arm/mach-orion5x/u-boot-spl.lds  |  4 +-
>  arch/arm/mach-rockchip/u-boot-tpl-v8.lds  |  4 +-
>  arch/arm/mach-zynq/u-boot-spl.lds |  4 +-
>  arch/arm/mach-zynq/u-boot.lds |  4 +-
>  arch/m68k/cpu/u-boot.lds  |  4 +-
>  arch/microblaze/cpu/u-boot-spl.lds|  4 +-
>  arch/microblaze/cpu/u-boot.lds|  4 +-
>  arch/mips/config.mk   |  2 +-
>  arch/mips/cpu/u-boot-spl.lds  |  4 +-
>  arch/mips/cpu/u-boot.lds  |  4 +-
>  arch/nios2/cpu/u-boot.lds |  4 +-
>  arch/powerpc/cpu/mpc83xx/u-boot.lds   |  4 +-
>  arch/powerpc/cpu/mpc85xx/u-boot-spl.lds   |  4 +-
>  arch/powerpc/cpu/mpc85xx/u-boot.lds   |  4 +-
>  arch/riscv/cpu/u-boot-spl.lds |  4 +-
>  arch/riscv/cpu/u-boot.lds |  4 +-
>  arch/sandbox/config.mk| 21 -
>  arch/sandbox/cpu/os.c | 76 +
>  arch/sandbox/cpu/start.c  |  2 +-
>  arch/sandbox/cpu/u-boot-spl.lds   | 10 +--
>  arch/sandbox/cpu/u-boot.lds   | 32 
>  arch/sandbox/dts/test.dts |  4 +
>  arch/sandbox/include/asm/fuzzing_engine.h | 25 ++
>  arch/sandbox/include/asm/getopt.h |  2 +-
>  arch/sandbox/include/asm/main.h   | 18 
>  arch/sandbox/include/asm/sections.h   |  4 +-
>  arch/sandbox/lib/sections.c 

Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Simon Glass]

Hi,

On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu  wrote:
>
>
> Provide a way for removing certain devicetree nodes and/or properties
> from the devicetree. This is needed to purge certain nodes and
> properties which may be relevant only in U-Boot. Such nodes and
> properties are then removed from the devicetree before it is passed to
> the kernel. This ensures that the devicetree passed to the OS does not
> contain any non-compliant nodes and properties.
>
> The removal of the nodes and properties is being done through an
> EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> behind any Kconfig symbol.
>
> I have only build tested this on sandbox, and tested on qemu arm64
> virt platform. This being a RFC, I have not put this through a CI run.
>
> Sughosh Ganu (5):
>   dt: Provide a way to remove non-compliant nodes and properties
>   fwu: Add the fwu-mdata node for removal from devicetree
>   capsule: Add the capsule-key property for removal from devicetree
>   bootefi: Call the EVT_FT_FIXUP event handler
>   doc: Add a document for non-compliant DT node/property removal
>
>  cmd/bootefi.c | 18 +
>  .../devicetree/dt_non_compliant_purge.rst | 64 
>  drivers/fwu-mdata/fwu-mdata-uclass.c  |  5 ++
>  include/dt-structs.h  | 11 +++
>  lib/Makefile  |  1 +
>  lib/dt_purge.c| 73 +++
>  lib/efi_loader/efi_capsule.c  |  7 ++
>  7 files changed, 179 insertions(+)
>  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
>  create mode 100644 lib/dt_purge.c

What is the point of removing them? Instead, we should make sure that
we upstream the bindings and encourage SoC vendors to sync them. If we
remove them, no one will bother and U-Boot just becomes a dumping
ground.

Instead of this, how about working on bringing the DT validation into
U-Boot so we can see what state things are in?

Please send the bindings for Linaro's recent series (which I suspect
are motivating this series) so we can start the process.

Regards,
Simon

Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot

[Tom Rini]

On Mon, Aug 28, 2023 at 01:09:17PM -0300, Alvaro Fernando García wrote:
> Hello,
> 
> El jue, 24 ago. 2023 06:27, Abdellatif El Khlifi <
> abdellatif.elkhl...@arm.com> escribió:
> 
> > Hi Tom,
> >
> > > Here's the latest report
> > >
> > > -- Forwarded message -
> > > From: 
> > > Date: Mon, Aug 21, 2023 at 4:30 PM
> > > Subject: New Defects reported by Coverity Scan for Das U-Boot
> > > To: 
> > >
> > >
> > > Hi,
> > >
> > > Please find the latest report on new defect(s) introduced to Das
> > > U-Boot found with Coverity Scan.
> > >
> > > 4 new defect(s) introduced to Das U-Boot found with Coverity Scan.
> > >
> > >
> > > New defect(s) Reported-by: Coverity Scan
> > > Showing 4 of 4 defect(s)
> > >
> > >
> > > ** CID 464361:  Control flow issues  (DEADCODE)
> > > /drivers/firmware/arm-ffa/arm-ffa-uclass.c: 148 in ffa_print_error_log()
> >
> > Well received, I started working on that.
> > I'll provide a fix  after coming back fom holidays (mid September)
> >
> > Cheers,
> > Abdellatif
> >
> 
> Is there something I could do to help with this?

Everyone is free to work on these issues, yes.

-- 
Tom


signature.asc
Description: PGP signature

Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot

[Alvaro Fernando García]

Hello,

El jue, 24 ago. 2023 06:27, Abdellatif El Khlifi <
abdellatif.elkhl...@arm.com> escribió:

> Hi Tom,
>
> > Here's the latest report
> >
> > -- Forwarded message -
> > From: 
> > Date: Mon, Aug 21, 2023 at 4:30 PM
> > Subject: New Defects reported by Coverity Scan for Das U-Boot
> > To: 
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to Das
> > U-Boot found with Coverity Scan.
> >
> > 4 new defect(s) introduced to Das U-Boot found with Coverity Scan.
> >
> >
> > New defect(s) Reported-by: Coverity Scan
> > Showing 4 of 4 defect(s)
> >
> >
> > ** CID 464361:  Control flow issues  (DEADCODE)
> > /drivers/firmware/arm-ffa/arm-ffa-uclass.c: 148 in ffa_print_error_log()
>
> Well received, I started working on that.
> I'll provide a fix  after coming back fom holidays (mid September)
>
> Cheers,
> Abdellatif
>

Is there something I could do to help with this?

Re: [PATCH] clk: Dont return error when assigned-clocks is empty or missing

[Tom Rini]

On Mon, Aug 28, 2023 at 12:25:30PM +0200, Michal Simek wrote:
> 
> 
> On 8/25/23 16:39, Tom Rini wrote:
> > On Fri, Aug 25, 2023 at 09:15:09AM +0200, Michal Simek wrote:
> > > Hi Tom,
> > > 
> > > On 7/11/23 11:51, Ashok Reddy Soma wrote:
> > > > There is a chance that assigned-clock-rates is given and assigned-clocks
> > > > could be empty. Dont return error in that case, because the probe of the
> > > > corresponding driver will not be called at all if this fails.
> > > > Better to continue to look for it and return 0.
> > > > 
> > > > Signed-off-by: Ashok Reddy Soma 
> > > > ---
> > > > 
> > > >drivers/clk/clk-uclass.c | 8 +++-
> > > >1 file changed, 7 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > > index dc3e9d6a26..f186fcbcdb 100644
> > > > --- a/drivers/clk/clk-uclass.c
> > > > +++ b/drivers/clk/clk-uclass.c
> > > > @@ -329,7 +329,13 @@ static int clk_set_default_rates(struct udevice 
> > > > *dev,
> > > > dev_dbg(dev,
> > > > "could not get assigned clock %d (err = 
> > > > %d)\n",
> > > > index, ret);
> > > > -   continue;
> > > > +   /* Skip if it is empty */
> > > > +   if (ret == -ENOENT) {
> > > > +   ret = 0;
> > > > +   continue;
> > > > +   }
> > > > +
> > > > +   return ret;
> > > > }
> > > > /* This is clk provider device trying to program itself
> > > 
> > > What's your take on this one?  I didn't get reply from Sean.
> > 
> > I guess, what's the validated upstream dts where this is the case?
> > 
> 
> It was found by incorrect DT. It means I don't think there is any DT which
> contains this issue.
> But that being said we can extend current clock tests to cover this case.
> Please look below.

Well, if the DT is invalid (and yes, we can't easily run the validation
suite in U-Boot today), I'd rather go with a debug we can optimize out
so that the next person with an invalid DT can more quickly find their
problem and we don't work-around it instead.  Or am I missing something?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 7/7] x86: qemu: Enable ramfb by default

[Tom Rini]

On Mon, Aug 28, 2023 at 06:40:10PM +0300, Alper Nebi Yasak wrote:
> On 2023-08-22 21:56 +03:00, Simon Glass wrote:
> > Hi Alper,
> > 
> > On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  
> > wrote:
> >>
> >> Now that we have everything in place to support ramfb, let's wire it up
> >> by default in the x86 QEMU targets. That way, we can use ramfb graphical
> >> console instead of the default by passing -vga none -device ramfb to the
> >> QEMU command line.
> >>
> >> Also increase SYS_MALLOC_F_LEN for QEMU x86_64 to be the same as its SPL
> >> counterpart, because we're running out of alloc space in pre-reloc stage
> >> with ramfb enabled.
> >>
> >> Signed-off-by: Alper Nebi Yasak 
> >> ---
> >> This also suffers from the same issue with distros as the Bochs display
> >> driver [1], where it results in a hang after GRUB menu selection before
> >> the kernel can display anything. Couldn't reproduce on arm*/riscv*.
> > 
> > Yes I see that problem too. I wonder how we can debug it?
> 
> No idea, and I couldn't find a good commit to bisect from, tried as far
> back as v2021.10.
> 
> >> But just having it enabled doesn't seem to cause problems unless you run
> >> QEMU with -device ramfb, so this (unlike the Bochs video driver) can
> >> actually be co-enabled with VIDEO_VESA.
> > 
> > Indeed...which makes me wonder if we can do something similar with
> > Bochs, so that (from the cmdline) it is possible to chose ramfb, bochs
> > or vesa?
> 
> (Tried to answer video choice and DT concerns in another mail)
> 
> >> [1] 
> >> https://lore.kernel.org/u-boot/20230724145210.304917-4-...@chromium.org/
> >>
> >> Changes in v2:
> >> - Add patch "x86: qemu: Enable ramfb by default"
> >>
> >>  arch/x86/cpu/qemu/Kconfig   |  4 +++
> >>  board/emulation/qemu-x86/qemu-x86.c | 47 +
> >>  configs/qemu-x86_64_defconfig   |  4 +--
> >>  configs/qemu-x86_defconfig  |  1 -
> >>  4 files changed, 52 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig
> >> index f8f2f6473088..e0a57ac2d687 100644
> >> --- a/arch/x86/cpu/qemu/Kconfig
> >> +++ b/arch/x86/cpu/qemu/Kconfig
> >> @@ -13,6 +13,10 @@ config QEMU
> >> imply USB
> >> imply USB_EHCI_HCD
> >> imply VIDEO_VESA
> >> +   imply VIDEO_RAMFB
> >> +   imply BOARD_EARLY_INIT_F
> >> +   imply BOARD_EARLY_INIT_R
> >> +   imply CMD_QFW
> >>
> >>  if QEMU
> >>
> >> [...]
> >> 
> >> @@ -59,7 +58,6 @@ CONFIG_CMD_USB=y
> >>  CONFIG_BOOTP_BOOTFILESIZE=y
> >>  CONFIG_CMD_EFIDEBUG=y
> >>  CONFIG_CMD_TIME=y
> >> -CONFIG_CMD_QFW=y
> > 
> > What is happening here? Why disable it?
> 
> I used `imply CMD_QFW` above to be consistent with previous patches, so
> it's no longer necessary in defconfigs. Should I drop the imply and keep
> these in defconfig?

I think our Kconfig logic around the QFW options is a bit backwards,
given that it's universal to the "qemu" boards and not used on
qemu-emulates-known-hardware platforms.  The qemu boards should be
select'ing QFW, and CMD_QFW should be depends on QFW and default y,
rather than selects.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 5/7] arm: qemu: Enable ramfb by default

[Alper Nebi Yasak]

On 2023-08-22 21:56 +03:00, Simon Glass wrote:
> Hi Alper,
> 
> On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  
> wrote:
>>
>> From: Alexander Graf 
>>
>> Now that we have everything in place to support ramfb, let's wire it up
>> by default in the ARM QEMU targets. That way, you can easily use a
>> graphical console by just passing -device ramfb to the QEMU command line.
>>
>> Signed-off-by: Alexander Graf 
>> [Alper: Rebase on bochs changes, add pre-reloc init, error handling]
>> Co-developed-by: Alper Nebi Yasak 
>> Signed-off-by: Alper Nebi Yasak 
>> ---
>>
>> Changes in v2:
>> - Rebase on "qemu: arm: Enable Bochs, console buffering, USB keyboard"
>> - Drop env changes from ARM (necessary but in prerequisite series)
>> - Drop imply VIDEO, SYS_CONSOLE_IN_ENV changes from ARM (in prereq.)
>> - Probe QFW in ARM QEMU board_early_init_f to bind ramfb pre-reloc
>> - Add IS_ENABLED(CONFIG_QFW) check and error handling to ARM QEMU
>>
>>  arch/arm/Kconfig|  3 +++
>>  board/emulation/qemu-arm/qemu-arm.c | 41 +
>>  2 files changed, 44 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 1fd3ccd1607f..7afe26ac804f 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1046,6 +1046,9 @@ config ARCH_QEMU
>> imply USB_XHCI_PCI
>> imply USB_KEYBOARD
>> imply CMD_USB
>> +   imply VIDEO_RAMFB
>> +   imply BOARD_EARLY_INIT_F
>> +   imply BOARD_EARLY_INIT_R
>>
>>  config ARCH_RMOBILE
>> bool "Renesas ARM SoCs"
>> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
>> b/board/emulation/qemu-arm/qemu-arm.c
>> index 942f1fff5717..23ef31cb7feb 100644
>> --- a/board/emulation/qemu-arm/qemu-arm.c
>> +++ b/board/emulation/qemu-arm/qemu-arm.c
>> @@ -11,6 +11,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -102,6 +103,46 @@ static struct mm_region qemu_arm64_mem_map[] = {
>>  struct mm_region *mem_map = qemu_arm64_mem_map;
>>  #endif
>>
>> +int board_early_init_f(void)
>> +{
>> +   struct udevice *dev;
>> +   int ret;
>> +
>> +   /*
>> +* Make sure we enumerate the QEMU Firmware device to bind ramfb
>> +* so video_reserve() can reserve memory for it.
>> +*/
>> +   if (IS_ENABLED(CONFIG_QFW)) {
>> +   ret = qfw_get_dev();
>> +   if (ret) {
>> +   log_err("Failed to get QEMU FW device: %d\n", ret);
> 
> We should only present an error if the device is present but
> failed...so if the user doesn't provide the flag, all should be well.

I don't understand what you mean by "user doesn't provide the flag". But
I assume this should ignore the error (unless what?) so that we can
continue to boot. Would that apply for board_early_init_r below as well?

>> +   return ret;
>> +   }
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>> +int board_early_init_r(void)
>> +{
>> +   struct udevice *dev;
>> +   int ret;
>> +
>> +   /*
>> +* Make sure we enumerate the QEMU Firmware device to find ramfb
>> +* before console_init.
>> +*/
>> +   if (IS_ENABLED(CONFIG_QFW)) {
>> +   ret = qfw_get_dev();
>> +   if (ret) {
>> +   log_err("Failed to get QEMU FW device: %d\n", ret);
>> +   return ret;
>> +   }
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>>  int board_init(void)
>>  {
>> return 0;
>> --
>> 2.40.1
>>
> 
> The glue here feels like a bit of a hack...we should rely on normal DT
> mechanisms here.
> 
> Regards,
> Simon

Re: [PATCH v2 7/7] x86: qemu: Enable ramfb by default

[Alper Nebi Yasak]

On 2023-08-22 21:56 +03:00, Simon Glass wrote:
> Hi Alper,
> 
> On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak  
> wrote:
>>
>> Now that we have everything in place to support ramfb, let's wire it up
>> by default in the x86 QEMU targets. That way, we can use ramfb graphical
>> console instead of the default by passing -vga none -device ramfb to the
>> QEMU command line.
>>
>> Also increase SYS_MALLOC_F_LEN for QEMU x86_64 to be the same as its SPL
>> counterpart, because we're running out of alloc space in pre-reloc stage
>> with ramfb enabled.
>>
>> Signed-off-by: Alper Nebi Yasak 
>> ---
>> This also suffers from the same issue with distros as the Bochs display
>> driver [1], where it results in a hang after GRUB menu selection before
>> the kernel can display anything. Couldn't reproduce on arm*/riscv*.
> 
> Yes I see that problem too. I wonder how we can debug it?

No idea, and I couldn't find a good commit to bisect from, tried as far
back as v2021.10.

>> But just having it enabled doesn't seem to cause problems unless you run
>> QEMU with -device ramfb, so this (unlike the Bochs video driver) can
>> actually be co-enabled with VIDEO_VESA.
> 
> Indeed...which makes me wonder if we can do something similar with
> Bochs, so that (from the cmdline) it is possible to chose ramfb, bochs
> or vesa?

(Tried to answer video choice and DT concerns in another mail)

>> [1] https://lore.kernel.org/u-boot/20230724145210.304917-4-...@chromium.org/
>>
>> Changes in v2:
>> - Add patch "x86: qemu: Enable ramfb by default"
>>
>>  arch/x86/cpu/qemu/Kconfig   |  4 +++
>>  board/emulation/qemu-x86/qemu-x86.c | 47 +
>>  configs/qemu-x86_64_defconfig   |  4 +--
>>  configs/qemu-x86_defconfig  |  1 -
>>  4 files changed, 52 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig
>> index f8f2f6473088..e0a57ac2d687 100644
>> --- a/arch/x86/cpu/qemu/Kconfig
>> +++ b/arch/x86/cpu/qemu/Kconfig
>> @@ -13,6 +13,10 @@ config QEMU
>> imply USB
>> imply USB_EHCI_HCD
>> imply VIDEO_VESA
>> +   imply VIDEO_RAMFB
>> +   imply BOARD_EARLY_INIT_F
>> +   imply BOARD_EARLY_INIT_R
>> +   imply CMD_QFW
>>
>>  if QEMU
>>
>> [...]
>> 
>> @@ -59,7 +58,6 @@ CONFIG_CMD_USB=y
>>  CONFIG_BOOTP_BOOTFILESIZE=y
>>  CONFIG_CMD_EFIDEBUG=y
>>  CONFIG_CMD_TIME=y
>> -CONFIG_CMD_QFW=y
> 
> What is happening here? Why disable it?

I used `imply CMD_QFW` above to be consistent with previous patches, so
it's no longer necessary in defconfigs. Should I drop the imply and keep
these in defconfig?

Re: [PATCH V6 16/20] configs: am62x_evm_a53_defconfig: Disable semi-functional PSCI reset support

[Mattijs Korpershoek]

On ven., août 25, 2023 at 13:03, Nishanth Menon  wrote:

> From: Jan Kiszka 
>
> At this point, system shutdown is not supported by the DM firmware
> that TF-A calls. As we can't de-select only this feature[1], declare
> complete PSCI reset support as non-functional so that we don't signal
> incomplete support to the OS via EFI runtime services. This makes
> power-off under Linux work again when booting via EFI.
>
> [1] 
> https://uefi.org/specs/UEFI/2.9_A/08_Services_Runtime_Services.html?highlight=efiresetshutdown#resetsystem
> Signed-off-by: Jan Kiszka 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Mattijs Korpershoek 

> ---
> New patch picked from Jan
> https://lore.kernel.org/all/c93b19ed-43fe-44a2-9726-371fb9d2f...@web.de/
> Changes:
> - modify am62x_evm as common change.
> - slight update to $subject and commit message
>
>  configs/am62x_evm_a53_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
> index 112125673699..a2729c1d0e36 100644
> --- a/configs/am62x_evm_a53_defconfig
> +++ b/configs/am62x_evm_a53_defconfig
> @@ -25,6 +25,7 @@ CONFIG_SPL_FS_FAT=y
>  CONFIG_SPL_LIBDISK_SUPPORT=y
>  CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI=y
> +# CONFIG_PSCI_RESET is not set
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> -- 
> 2.40.0

Re: [PATCH V6 11/20] board: ti: am62x: am62x.env: Use default findfdt

[Mattijs Korpershoek]

On ven., août 25, 2023 at 13:02, Nishanth Menon  wrote:

> Use the default findfdt using CONFIG_DEFAULT_DEVICE_TREE
>
> Reviewed-by: Tom Rini 
> Tested-by: Mattijs Korpershoek 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Mattijs Korpershoek 

> ---
> No change that picking up Review, tested by and using new include file.
>
> V5: https://lore.kernel.org/r/20230824031101.3460411-10...@ti.com
>  board/ti/am62x/am62x.env | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
> index 1ef948df83d7..3b79ae1b3f0d 100644
> --- a/board/ti/am62x/am62x.env
> +++ b/board/ti/am62x/am62x.env
> @@ -1,10 +1,7 @@
>  #include 
> +#include 
>  #include 
>  
> -default_device_tree=ti/k3-am625-sk.dtb
> -findfdt=
> - setenv name_fdt ${default_device_tree};
> - setenv fdtfile ${name_fdt}
>  name_kern=Image
>  console=ttyS2,115200n8
>  args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
> -- 
> 2.40.0

Re: [PATCH V6 10/20] include: env: ti: Add a generic default_findfdt.env

[Mattijs Korpershoek]

On ven., août 25, 2023 at 13:02, Nishanth Menon  wrote:

> ti_mmc bootmethod uses a findfdt routine that is expected to be
> implemented by all platforms.
>
> Define a default findfdt based on configured DEFAULT_DEVICE_TREE option
> for u-boot. This saves duplication across multiple boards and handles
> architecture folder location changes centrally.
>
> TI ARMV7 platforms will need to override default_device_tree_subarch
> in the env file to point to the appropriate platform. Note: default
> "omap" is used to cater to "most common" default.
>
> Tested-by: Mattijs Korpershoek 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Mattijs Korpershoek 

> ---
> Changes:
> * Made it as default_findfdt as discussed in review.
>
> V5: https://lore.kernel.org/r/20230824031101.3460411-9...@ti.com
>  include/env/ti/default_findfdt.env | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 include/env/ti/default_findfdt.env
>
> diff --git a/include/env/ti/default_findfdt.env 
> b/include/env/ti/default_findfdt.env
> new file mode 100644
> index ..a2b51dd923bb
> --- /dev/null
> +++ b/include/env/ti/default_findfdt.env
> @@ -0,0 +1,12 @@
> +default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
> +default_device_tree_arch=ti
> +#ifdef CONFIG_ARM64
> +findfdt=
> + setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
> + setenv fdtfile ${name_fdt}
> +#else
> +default_device_tree_subarch=omap
> +findfdt=
> + setenv name_fdt 
> ${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
> + setenv fdtfile ${name_fdt}
> +#endif
> -- 
> 2.40.0

Re: [PATCH V6 08/20] include: configs: am62x_evm: Drop distro_bootcmd usage

[Mattijs Korpershoek]

On ven., août 25, 2023 at 13:02, Nishanth Menon  wrote:

> Now that BOOTSTD is used by default, drop un-used header file
> inclusion.
>
> Reviewed-by: Tom Rini 
> Tested-by: Mattijs Korpershoek 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Mattijs Korpershoek 

> ---
> No change other than picking up reviews, tested tags along the way.
> V5: https://lore.kernel.org/r/20230824031101.3460411-7...@ti.com
>  include/configs/am62x_evm.h | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/include/configs/am62x_evm.h b/include/configs/am62x_evm.h
> index 81d7658cdb0d..c8fe59b75313 100644
> --- a/include/configs/am62x_evm.h
> +++ b/include/configs/am62x_evm.h
> @@ -9,11 +9,6 @@
>  #ifndef __CONFIG_AM625_EVM_H
>  #define __CONFIG_AM625_EVM_H
>  
> -#ifdef CONFIG_DISTRO_DEFAULTS
> -#include 
> -#include 
> -#endif
> -
>  /* Now for the remaining common defines */
>  #include 
>  
> -- 
> 2.40.0

Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd

[Mattijs Korpershoek]

On ven., août 25, 2023 at 13:02, Nishanth Menon  wrote:

> Switch to using bootstd. Note with this change, we will stop using
> distro_bootcmd and instead depend entirely on bootflow method of
> starting the system up.
>
> Suggested-by: Tom Rini 
> Suggested-by: Simon Glass 
> Reviewed-by: Tom Rini 
> Tested-by: Mattijs Korpershoek 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Mattijs Korpershoek 

> ---
> No change other than picking up reviews, tested tags along the way.
> V5: https://lore.kernel.org/r/20230824031101.3460411-6...@ti.com
>  configs/am62x_evm_a53_defconfig | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
> index d55caabe22c9..1807df8bbee9 100644
> --- a/configs/am62x_evm_a53_defconfig
> +++ b/configs/am62x_evm_a53_defconfig
> @@ -28,8 +28,9 @@ CONFIG_SPL_SPI=y
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> -CONFIG_DISTRO_DEFAULTS=y
> -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
> +CONFIG_BOOTSTD_FULL=y
> +CONFIG_BOOTSTD_DEFAULTS=y
> +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
>  CONFIG_SPL_MAX_SIZE=0x58000
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
>  CONFIG_SPL_BSS_START_ADDR=0x80c8
> -- 
> 2.40.0

Re: [PATCH V6 06/20] board: ti: am62x: am62x.env: Add explicit boot_targets

[Mattijs Korpershoek]

On ven., août 25, 2023 at 13:02, Nishanth Menon  wrote:

> Add explicit boot_targets to indicate the specific boot sequence to
> follow.
>
> NOTE: The non-standard ti_mmc emulates what is done for distro_boot.
> With bootstd, this will eventually need to be replaced by equivalent
> class.
>
> Tested-by: Mattijs Korpershoek 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Mattijs Korpershoek 

> ---
> No change other than picking up reviews, tested tags along the way.
>
> V5: https://lore.kernel.org/r/20230824031101.3460411-5...@ti.com
>  board/ti/am62x/am62x.env | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
> index f2dc87893a92..1cf56dbd8128 100644
> --- a/board/ti/am62x/am62x.env
> +++ b/board/ti/am62x/am62x.env
> @@ -11,6 +11,7 @@ args_all=setenv optargs ${optargs} 
> earlycon=ns16550a,mmio32,0x0280
>   ${mtdparts}
>  run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
>  
> +boot_targets=ti_mmc mmc0 mmc1 usb pxe dhcp
>  boot=mmc
>  mmcdev=1
>  bootpart=1:2
> -- 
> 2.40.0