[PATCH 0/4] bloblist: fdt: Clean up the code

[PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

The bloblist code took what I consider to be a wrong turn a year or so
ago. As discussed with Tom, this series proposes a way to arrange things
so that it is simpler to understand and manage.

- Unwind some of the nesting in bloblist_init()
- Avoid needing to init the bloblist just to get the FDT
- Create a deterministic OF_BLOBLIST option rather than using guesswork

It is to be hoped that we can get a platform which uses OF_BLOBLIST into
CI at some point. In the meantime, the standard passage series[1] could
be resurrected to give some coverage.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*


Simon Glass (4):
  bloblist: Simplify bloblist init
  fdt: Introduce OF_BLOBLIST
  bloblist: Provide access to the FDT address
  fdt: Obtain the FDT from bloblist without parsing it

 arch/arm/lib/xferlist.c            |   6 +-
 common/bloblist.c                  | 102 ++++++++++++++++++-----------
 doc/develop/devicetree/control.rst |   3 +
 dts/Kconfig                        |   8 +++
 include/bloblist.h                 |  16 ++++-
 lib/fdtdec.c                       |  65 +++++++-----------
 6 files changed, 116 insertions(+), 84 deletions(-)

-- 
2.43.0

[PATCH 1/4] bloblist: Simplify bloblist init

[Simon Glass]

This has become quite complicated now, with much of the code indented,
gd->bloblist set in multiple places, multiple error paths and ret set to
different things in different places.

Make an attempt to simplify it, without changing functionality.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 common/bloblist.c | 67 ++++++++++++++++++++++-------------------------
 1 file changed, 31 insertions(+), 36 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 6e4f020d7c4..135fb149626 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -513,48 +513,43 @@ int __weak xferlist_from_boot_arg(ulong __always_unused *addr)
 int bloblist_init(void)
 {
 	bool fixed = IS_ENABLED(CONFIG_BLOBLIST_FIXED);
-	int ret = 0;
+	int ret = -ENOENT;
 	ulong addr = 0, size;
 
-	/* Check if a valid transfer list passed in */
-	if (!xferlist_from_boot_arg(&addr)) {
-		size = bloblist_get_total_size();
-	} else {
-		/*
-		 * If U-Boot is not in the first phase, an existing bloblist must
-		 * be at a fixed address.
-		 */
-		bool from_addr = fixed && !xpl_is_first_phase();
+	/*
+	 * If U-Boot is not in the first phase, an existing bloblist must be
+	 * at a fixed address.
+	 */
+	bool from_addr = fixed && !xpl_is_first_phase();
+	/*
+	 * If U-Boot is in the first phase then an arch custom routine should
+	 * install the bloblist passed from previous loader to this fixed
+	 * address.
+	 */
+	bool from_boot_arg = fixed && xpl_is_first_phase();
 
+	if (xpl_prev_phase() == PHASE_TPL && !IS_ENABLED(CONFIG_TPL_BLOBLIST))
+		from_addr = false;
+	if (fixed)
+		addr = IF_ENABLED_INT(CONFIG_BLOBLIST_FIXED,
+				      CONFIG_BLOBLIST_ADDR);
+	size = CONFIG_BLOBLIST_SIZE;
+
+	if (from_boot_arg) {
+		ret = xferlist_from_boot_arg(&addr);
 		/*
 		 * If Firmware Handoff is mandatory but no transfer list is
 		 * observed, report it as an error.
 		 */
-		if (IS_ENABLED(CONFIG_BLOBLIST_PASSAGE_MANDATORY))
+		if (ret && IS_ENABLED(CONFIG_BLOBLIST_PASSAGE_MANDATORY))
 			return -ENOENT;
-
-		ret = -ENOENT;
-
-		if (xpl_prev_phase() == PHASE_TPL &&
-		    !IS_ENABLED(CONFIG_TPL_BLOBLIST))
-			from_addr = false;
-		if (fixed)
-			addr = IF_ENABLED_INT(CONFIG_BLOBLIST_FIXED,
-					      CONFIG_BLOBLIST_ADDR);
-		size = CONFIG_BLOBLIST_SIZE;
-
-		if (from_addr)
-			ret = bloblist_check(addr, size);
-
-		if (ret)
-			log_warning("Bloblist at %lx not found (err=%d)\n",
-				    addr, ret);
-		else
-			/* Get the real size */
-			size = gd->bloblist->total_size;
+	} else if (from_addr) {
+		ret = bloblist_check(addr, size);
 	}
 
 	if (ret) {
+		log_warning("Bloblist at %lx not found (err=%d)\n", addr, ret);
+
 		/*
 		 * If we don't have a bloblist from a fixed address, or the one
 		 * in the fixed address is not valid. we must allocate the
@@ -573,13 +568,15 @@ int bloblist_init(void)
 		log_debug("Creating new bloblist size %lx at %lx\n", size,
 			  addr);
 		ret = bloblist_new(addr, size, 0, 0);
+		if (ret)
+			return log_msg_ret("ini", ret);
 	} else {
+		/* Get the real size */
+		size = gd->bloblist->total_size;
 		log_debug("Found existing bloblist size %lx at %lx\n", size,
 			  addr);
 	}
 
-	if (ret)
-		return log_msg_ret("ini", ret);
 	gd->flags |= GD_FLG_BLOBLIST_READY;
 
 #ifdef DEBUG
@@ -620,10 +617,8 @@ int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig, ulong xlist)
 	if (ret)
 		return ret;
 
-	if (rfdt != (ulong)bloblist_find(BLOBLISTT_CONTROL_FDT, 0)) {
-		gd->bloblist = NULL;  /* Reset the gd bloblist pointer */
+	if (rfdt != (ulong)bloblist_find(BLOBLISTT_CONTROL_FDT, 0))
 		return -EIO;
-	}
 
 	return 0;
 }
-- 
2.43.0

[PATCH 2/4] fdt: Introduce OF_BLOBLIST

[Simon Glass]

Add an option which indicates that the devicetree comes from the
bloblist.

After discussions with Tom, it seems we are comfortable with introducing
this option, ensuring of course that the transfer list is properly
supported.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 doc/develop/devicetree/control.rst |  3 ++
 dts/Kconfig                        |  8 ++++
 lib/fdtdec.c                       | 66 ++++++++++++------------------
 3 files changed, 38 insertions(+), 39 deletions(-)

diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 0233945f8b6..d80f4d420a9 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -137,6 +137,9 @@ If `OF_BOARD` is selected by Kconfig, a board-specific routine will provide the
 devicetree at runtime, for example if an earlier bootloader stage creates
 it and passes it to U-Boot.
 
+If `OF_BLOBLIST` is defined, the devicetree comes from a bloblist passed
+from a previous stage.
+
 If `BLOBLIST` is selected by Kconfig, the devicetree may come from a bloblist
 passed from a previous stage, if present.
 
diff --git a/dts/Kconfig b/dts/Kconfig
index 6a5141b56e9..04359a4d7b2 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -167,6 +167,14 @@ config OF_INITIAL_DTB_READONLY
 	  If initial DTB for DT control is read-only (e.g. points to
 	  memory-mapped flash memory), then set this option.
 
+config OF_BLOBLIST
+	bool "DTB is provided by a bloblist"
+	help
+	  Select this to read the devicetree from the bloblist. This allows
+	  using a bloblist to transfer the devicetree between U-Boot phases.
+	  The devicetree is stored in the bloblist by an earlier phase so that
+	  U-Boot can read it.
+
 config OF_BOARD
 	bool "Provided by the board (e.g a previous loader) at runtime"
 	default y if SANDBOX || OF_HAS_PRIOR_STAGE
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index f09c9926a7a..833f8aca3ce 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1689,55 +1689,43 @@ void fdtdec_setup_embed(void)
 
 int fdtdec_setup(void)
 {
-	int ret = -ENOENT;
+	int ret;
 
-	/*
-	 * If allowing a bloblist, check that first. There was discussion about
-	 * adding an OF_BLOBLIST Kconfig, but this was rejected.
-	 *
-	 * The necessary test is whether the previous phase passed a bloblist,
-	 * not whether this phase creates one.
-	 */
-	if (CONFIG_IS_ENABLED(BLOBLIST) &&
-	    (xpl_prev_phase() != PHASE_TPL ||
-	     IS_ENABLED(CONFIG_TPL_BLOBLIST))) {
+	if (CONFIG_IS_ENABLED(OF_BLOBLIST)) {
 		ret = bloblist_maybe_init();
-		if (!ret) {
-			gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
-			if (gd->fdt_blob) {
-				gd->fdt_src = FDTSRC_BLOBLIST;
-				log_debug("Devicetree is in bloblist at %p\n",
-					  gd->fdt_blob);
-				ret = 0;
-			} else {
-				log_debug("No FDT found in bloblist\n");
-				ret = -ENOENT;
-			}
+		if (ret)
+			return ret;
+		gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
+		if (!gd->fdt_blob) {
+			printf("Not FDT found in bloblist\n");
+			bloblist_show_list();
+			return -ENOENT;
 		}
-	}
-
-	/* Otherwise, the devicetree is typically appended to U-Boot */
-	if (ret) {
+		gd->fdt_src = FDTSRC_BLOBLIST;
+		bloblist_show_list();
+		log_debug("Devicetree is in bloblist at %p\n", gd->fdt_blob);
+	} else {
 		if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
 			gd->fdt_blob = fdt_find_separate();
 			gd->fdt_src = FDTSRC_SEPARATE;
 		} else { /* embed dtb in ELF file for testing / development */
-			fdtdec_setup_embed();
+			gd->fdt_blob = dtb_dt_embedded();
+			gd->fdt_src = FDTSRC_EMBED;
 		}
-	}
 
-	/* Allow the board to override the fdt address. */
-	if (IS_ENABLED(CONFIG_OF_BOARD)) {
-		void *blob;
+		/* Allow the board to override the fdt address. */
+		if (IS_ENABLED(CONFIG_OF_BOARD)) {
+			void *blob;
 
-		blob = (void *)gd->fdt_blob;
-		ret = board_fdt_blob_setup(&blob);
-		if (ret) {
-			if (ret != -EEXIST)
-				return ret;
-		} else {
-			gd->fdt_src = FDTSRC_BOARD;
-			gd->fdt_blob = blob;
+			blob = (void *)gd->fdt_blob;
+			ret = board_fdt_blob_setup(&blob);
+			if (ret) {
+				if (ret != -EEXIST)
+					return ret;
+			} else {
+				gd->fdt_src = FDTSRC_BOARD;
+				gd->fdt_blob = blob;
+			}
 		}
 	}
 
-- 
2.43.0

[PATCH 3/4] bloblist: Provide access to the FDT address

[Simon Glass]

The firmware handoff specification provides for a devicetree pointer in
a register. Provide access to that so we don't have to parse the
bloblist to get it.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/arm/lib/xferlist.c | 6 ++++--
 common/bloblist.c       | 5 +++--
 include/bloblist.h      | 5 +++--
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/lib/xferlist.c b/arch/arm/lib/xferlist.c
index 6425936d354..16c28e34604 100644
--- a/arch/arm/lib/xferlist.c
+++ b/arch/arm/lib/xferlist.c
@@ -8,7 +8,7 @@
 #include <bloblist.h>
 #include "xferlist.h"
 
-int xferlist_from_boot_arg(ulong *addr)
+int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
 {
 	int ret;
 
@@ -17,7 +17,9 @@ int xferlist_from_boot_arg(ulong *addr)
 	if (ret)
 		return ret;
 
-	*addr = bloblist_get_base();
+	*addrp = saved_args[3];
+	if (fdtp)
+		*fdtp = saved_args[0];
 
 	return 0;
 }
diff --git a/common/bloblist.c b/common/bloblist.c
index 135fb149626..83d9de2749e 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -505,7 +505,8 @@ int bloblist_reloc(void *to, uint to_size)
 /*
  * Weak default function for getting bloblist from boot args.
  */
-int __weak xferlist_from_boot_arg(ulong __always_unused *addr)
+int __weak xferlist_from_boot_arg(ulong __always_unused *addrp,
+				  ulong __always_unused *fdtp)
 {
 	return -ENOENT;
 }
@@ -536,7 +537,7 @@ int bloblist_init(void)
 	size = CONFIG_BLOBLIST_SIZE;
 
 	if (from_boot_arg) {
-		ret = xferlist_from_boot_arg(&addr);
+		ret = xferlist_from_boot_arg(&addr, NULL);
 		/*
 		 * If Firmware Handoff is mandatory but no transfer list is
 		 * observed, report it as an error.
diff --git a/include/bloblist.h b/include/bloblist.h
index f32faf78560..7ff70e9554c 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -509,9 +509,10 @@ int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig, ulong xlist);
 /**
  * xferlist_from_boot_arg() - Get bloblist from the boot args.
  *
- * @addr: Address of the bloblist
+ * @addrp: Returns address of the bloblist
+ * @fdtp: If non-NULL, returns address of the FDT
  * Return: 0 if OK, else on error
  */
-int xferlist_from_boot_arg(ulong *addr);
+int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp);
 
 #endif /* __BLOBLIST_H */
-- 
2.43.0

[PATCH 4/4] fdt: Obtain the FDT from bloblist without parsing it

[Simon Glass]

We don't need or want to parse the bloblist to obtain the FDT. Use the
feature in the transfer list that was designed for this situation.

This avoids the complexity of trying to init the bloblist twice before
relocation.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 common/bloblist.c  | 32 +++++++++++++++++++++++++++++---
 include/bloblist.h | 11 +++++++++++
 lib/fdtdec.c       | 11 ++++-------
 3 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 83d9de2749e..6bef1ab1895 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -596,11 +596,17 @@ int bloblist_maybe_init(void)
 	return 0;
 }
 
-int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig, ulong xlist)
+/**
+ * has_signature() - Check if the bloblist signature is in the registers
+ *
+ * @rzero: Register which should be zero
+ * @rsig: Register which should have the bloblist signature
+ * Return: true if signature found, false if not
+ */
+static bool has_signature(ulong rzero, ulong rsig)
 {
 	u64 version = BLOBLIST_REGCONV_VER;
 	ulong sigval;
-	int ret;
 
 	if ((IS_ENABLED(CONFIG_64BIT) && !IS_ENABLED(CONFIG_SPL_BUILD)) ||
 			(IS_ENABLED(CONFIG_SPL_64BIT) && IS_ENABLED(CONFIG_SPL_BUILD))) {
@@ -612,7 +618,17 @@ int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig, ulong xlist)
 	}
 
 	if (rzero || rsig != sigval)
-		return -EIO;
+		return false;
+
+	return true;
+}
+
+int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig, ulong xlist)
+{
+	int ret;
+
+	if (!has_signature(rzero, rsig))
+		return -ENOENT;
 
 	ret = bloblist_check(xlist, 0);
 	if (ret)
@@ -623,3 +639,13 @@ int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig, ulong xlist)
 
 	return 0;
 }
+
+void *bloblist_early_get_fdt(void)
+{
+	ulong addr, fdt;
+
+	if (xferlist_from_boot_arg(&addr, &fdt))
+		return NULL;
+
+	return map_sysmem(fdt, 0);
+}
diff --git a/include/bloblist.h b/include/bloblist.h
index 7ff70e9554c..8be871f2d98 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -515,4 +515,15 @@ int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig, ulong xlist);
  */
 int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp);
 
+/**
+ * bloblist_early_get_fdt() - Get the FDT from a bloblist before it is set up
+ *
+ * The transfer list calling convention specifies that the FDT can be obtained
+ * without parsing the bloblist. Check for the presence of a bloblist and return
+ * the FDT indicated
+ *
+ * Return: Pointer to FDT or NULL if no bloblist is present
+ */
+void *bloblist_early_get_fdt(void);
+
 #endif /* __BLOBLIST_H */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 833f8aca3ce..afa51f34867 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1692,17 +1692,14 @@ int fdtdec_setup(void)
 	int ret;
 
 	if (CONFIG_IS_ENABLED(OF_BLOBLIST)) {
-		ret = bloblist_maybe_init();
-		if (ret)
-			return ret;
-		gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
-		if (!gd->fdt_blob) {
+		const void *blob;
+
+		blob = bloblist_early_get_fdt();
+		if (!blob) {
 			printf("Not FDT found in bloblist\n");
-			bloblist_show_list();
 			return -ENOENT;
 		}
 		gd->fdt_src = FDTSRC_BLOBLIST;
-		bloblist_show_list();
 		log_debug("Devicetree is in bloblist at %p\n", gd->fdt_blob);
 	} else {
 		if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
-- 
2.43.0

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:

> The bloblist code took what I consider to be a wrong turn a year or so
> ago. As discussed with Tom, this series proposes a way to arrange things
> so that it is simpler to understand and manage.
> 
> - Unwind some of the nesting in bloblist_init()
> - Avoid needing to init the bloblist just to get the FDT
> - Create a deterministic OF_BLOBLIST option rather than using guesswork
> 
> It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> CI at some point. In the meantime, the standard passage series[1] could
> be resurrected to give some coverage.
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*

Based on how it's documented to be run in
doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
that platforms using the handoff spec still work?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
>
> > The bloblist code took what I consider to be a wrong turn a year or so
> > ago. As discussed with Tom, this series proposes a way to arrange things
> > so that it is simpler to understand and manage.
> >
> > - Unwind some of the nesting in bloblist_init()
> > - Avoid needing to init the bloblist just to get the FDT
> > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> >
> > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > CI at some point. In the meantime, the standard passage series[1] could
> > be resurrected to give some coverage.
> >
> > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
>
> Based on how it's documented to be run in
> doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> that platforms using the handoff spec still work?

I believe so, yes. I don't have that board to test it though. Raymond
may be able to test this series on QEMU?

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> >
> > > The bloblist code took what I consider to be a wrong turn a year or so
> > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > so that it is simpler to understand and manage.
> > >
> > > - Unwind some of the nesting in bloblist_init()
> > > - Avoid needing to init the bloblist just to get the FDT
> > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > >
> > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > CI at some point. In the meantime, the standard passage series[1] could
> > > be resurrected to give some coverage.
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> >
> > Based on how it's documented to be run in
> > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > that platforms using the handoff spec still work?
> 
> I believe so, yes. I don't have that board to test it though. Raymond
> may be able to test this series on QEMU?

I was pointing you at the docs so that you would have access to testing
it. That's part of the docs, running the emulator.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Tom and Simon,

On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > >
> > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > so that it is simpler to understand and manage.
> > > >
> > > > - Unwind some of the nesting in bloblist_init()
> > > > - Avoid needing to init the bloblist just to get the FDT
> > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > >
> > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > be resurrected to give some coverage.
> > > >
> > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > >
> > > Based on how it's documented to be run in
> > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > that platforms using the handoff spec still work?
> >
> > I believe so, yes. I don't have that board to test it though. Raymond
> > may be able to test this series on QEMU?
>
> I was pointing you at the docs so that you would have access to testing
> it. That's part of the docs, running the emulator.
>

I can help to test the firmware handoff on qemu.
I have all the necessary changes and unit tests for the OP-TEE repo
qemu v8 build to test this.
I will try to find some time early next week to review and test this
series before turning back to you.

Regards,
Raymond

> --
> Tom

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
>
> The bloblist code took what I consider to be a wrong turn a year or so
> ago. As discussed with Tom, this series proposes a way to arrange things
> so that it is simpler to understand and manage.
>
> - Unwind some of the nesting in bloblist_init()
> - Avoid needing to init the bloblist just to get the FDT
> - Create a deterministic OF_BLOBLIST option rather than using guesswork
>
We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
mandatorily use bloblist to hand over everything between boot stages
including fdt, creating OF_BLOBLIST is not necessary.

> It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> CI at some point. In the meantime, the standard passage series[1] could
> be resurrected to give some coverage.
>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
>
>
> Simon Glass (4):
>   bloblist: Simplify bloblist init
>   fdt: Introduce OF_BLOBLIST
>   bloblist: Provide access to the FDT address
>   fdt: Obtain the FDT from bloblist without parsing it
>
>  arch/arm/lib/xferlist.c            |   6 +-
>  common/bloblist.c                  | 102 ++++++++++++++++++-----------
>  doc/develop/devicetree/control.rst |   3 +
>  dts/Kconfig                        |   8 +++
>  include/bloblist.h                 |  16 ++++-
>  lib/fdtdec.c                       |  65 +++++++-----------
>  6 files changed, 116 insertions(+), 84 deletions(-)
>
> --
> 2.43.0
>

Re: [PATCH 2/4] fdt: Introduce OF_BLOBLIST

[Raymond Mao]

Hi Simon,

On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
>
> Add an option which indicates that the devicetree comes from the
> bloblist.
>
> After discussions with Tom, it seems we are comfortable with introducing
> this option, ensuring of course that the transfer list is properly
> supported.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  doc/develop/devicetree/control.rst |  3 ++
>  dts/Kconfig                        |  8 ++++
>  lib/fdtdec.c                       | 66 ++++++++++++------------------
>  3 files changed, 38 insertions(+), 39 deletions(-)
>
> diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
> index 0233945f8b6..d80f4d420a9 100644
> --- a/doc/develop/devicetree/control.rst
> +++ b/doc/develop/devicetree/control.rst
> @@ -137,6 +137,9 @@ If `OF_BOARD` is selected by Kconfig, a board-specific routine will provide the
>  devicetree at runtime, for example if an earlier bootloader stage creates
>  it and passes it to U-Boot.
>
> +If `OF_BLOBLIST` is defined, the devicetree comes from a bloblist passed
> +from a previous stage.
> +
>  If `BLOBLIST` is selected by Kconfig, the devicetree may come from a bloblist
>  passed from a previous stage, if present.
>
> diff --git a/dts/Kconfig b/dts/Kconfig
> index 6a5141b56e9..04359a4d7b2 100644
> --- a/dts/Kconfig
> +++ b/dts/Kconfig
> @@ -167,6 +167,14 @@ config OF_INITIAL_DTB_READONLY
>           If initial DTB for DT control is read-only (e.g. points to
>           memory-mapped flash memory), then set this option.
>
> +config OF_BLOBLIST
> +       bool "DTB is provided by a bloblist"
> +       help
> +         Select this to read the devicetree from the bloblist. This allows
> +         using a bloblist to transfer the devicetree between U-Boot phases.
> +         The devicetree is stored in the bloblist by an earlier phase so that
> +         U-Boot can read it.
> +
>  config OF_BOARD
>         bool "Provided by the board (e.g a previous loader) at runtime"
>         default y if SANDBOX || OF_HAS_PRIOR_STAGE
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index f09c9926a7a..833f8aca3ce 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1689,55 +1689,43 @@ void fdtdec_setup_embed(void)
>
>  int fdtdec_setup(void)

I think a better idea is to use BLOBLIST_PASSAGE_MANDATORY, see below
pseudo code:

```
if (IS_ENABLED(CONFIG_OF_BOARD)) {
    /* get fdt from board */
}

/* allow fdtcontroladdr to override it */

if (CONFIG_IS_ENABLED(BLOBLIST) && ... ) {
    /* try to find fdt from bloblist */

    if (CONFIG_IS_ENABLED(BLOBLIST_PASSAGE_MANDATORY) {
        if (no_fdt_in_bloblist)
            return ERROR;

        /* override fdt with the one from bloblist */
    }
}
```

Regards,
Raymond

>  {
> -       int ret = -ENOENT;
> +       int ret;
>
> -       /*
> -        * If allowing a bloblist, check that first. There was discussion about
> -        * adding an OF_BLOBLIST Kconfig, but this was rejected.
> -        *
> -        * The necessary test is whether the previous phase passed a bloblist,
> -        * not whether this phase creates one.
> -        */
> -       if (CONFIG_IS_ENABLED(BLOBLIST) &&
> -           (xpl_prev_phase() != PHASE_TPL ||
> -            IS_ENABLED(CONFIG_TPL_BLOBLIST))) {
> +       if (CONFIG_IS_ENABLED(OF_BLOBLIST)) {
>                 ret = bloblist_maybe_init();
> -               if (!ret) {
> -                       gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
> -                       if (gd->fdt_blob) {
> -                               gd->fdt_src = FDTSRC_BLOBLIST;
> -                               log_debug("Devicetree is in bloblist at %p\n",
> -                                         gd->fdt_blob);
> -                               ret = 0;
> -                       } else {
> -                               log_debug("No FDT found in bloblist\n");
> -                               ret = -ENOENT;
> -                       }
> +               if (ret)
> +                       return ret;
> +               gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
> +               if (!gd->fdt_blob) {
> +                       printf("Not FDT found in bloblist\n");
> +                       bloblist_show_list();
> +                       return -ENOENT;
>                 }
> -       }
> -
> -       /* Otherwise, the devicetree is typically appended to U-Boot */
> -       if (ret) {
> +               gd->fdt_src = FDTSRC_BLOBLIST;
> +               bloblist_show_list();
> +               log_debug("Devicetree is in bloblist at %p\n", gd->fdt_blob);
> +       } else {
>                 if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
>                         gd->fdt_blob = fdt_find_separate();
>                         gd->fdt_src = FDTSRC_SEPARATE;
>                 } else { /* embed dtb in ELF file for testing / development */
> -                       fdtdec_setup_embed();
> +                       gd->fdt_blob = dtb_dt_embedded();
> +                       gd->fdt_src = FDTSRC_EMBED;
>                 }
> -       }
>
> -       /* Allow the board to override the fdt address. */
> -       if (IS_ENABLED(CONFIG_OF_BOARD)) {
> -               void *blob;
> +               /* Allow the board to override the fdt address. */
> +               if (IS_ENABLED(CONFIG_OF_BOARD)) {
> +                       void *blob;
>
> -               blob = (void *)gd->fdt_blob;
> -               ret = board_fdt_blob_setup(&blob);
> -               if (ret) {
> -                       if (ret != -EEXIST)
> -                               return ret;
> -               } else {
> -                       gd->fdt_src = FDTSRC_BOARD;
> -                       gd->fdt_blob = blob;
> +                       blob = (void *)gd->fdt_blob;
> +                       ret = board_fdt_blob_setup(&blob);
> +                       if (ret) {
> +                               if (ret != -EEXIST)
> +                                       return ret;
> +                       } else {
> +                               gd->fdt_src = FDTSRC_BOARD;
> +                               gd->fdt_blob = blob;
> +                       }
>                 }
>         }
>
> --
> 2.43.0
>

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> >
> > The bloblist code took what I consider to be a wrong turn a year or so
> > ago. As discussed with Tom, this series proposes a way to arrange things
> > so that it is simpler to understand and manage.
> >
> > - Unwind some of the nesting in bloblist_init()
> > - Avoid needing to init the bloblist just to get the FDT
> > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> >
> We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> mandatorily use bloblist to hand over everything between boot stages
> including fdt, creating OF_BLOBLIST is not necessary.

Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
there must be a bloblist, not that it must contain a devicetree. So I
wasn't sure about removing it.

But actually, thinking about it just now, we can remove
BLOBLIST_PASSAGE_MANDATORY, since U-Boot won't make it that far if
there is no bloblist. It will die in fdtdec_setup(). Take a look and
see if you agree.

>
> > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > CI at some point. In the meantime, the standard passage series[1] could
> > be resurrected to give some coverage.
> >
> > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> >
> >
> > Simon Glass (4):
> >   bloblist: Simplify bloblist init
> >   fdt: Introduce OF_BLOBLIST
> >   bloblist: Provide access to the FDT address
> >   fdt: Obtain the FDT from bloblist without parsing it
> >
> >  arch/arm/lib/xferlist.c            |   6 +-
> >  common/bloblist.c                  | 102 ++++++++++++++++++-----------
> >  doc/develop/devicetree/control.rst |   3 +
> >  dts/Kconfig                        |   8 +++
> >  include/bloblist.h                 |  16 ++++-
> >  lib/fdtdec.c                       |  65 +++++++-----------
> >  6 files changed, 116 insertions(+), 84 deletions(-)
> >
> > --
> > 2.43.0
> >

Regards,
Simon

Re: [PATCH 2/4] fdt: Introduce OF_BLOBLIST

[Simon Glass]

Hi Raymond,

On Fri, 4 Apr 2025 at 04:34, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> >
> > Add an option which indicates that the devicetree comes from the
> > bloblist.
> >
> > After discussions with Tom, it seems we are comfortable with introducing
> > this option, ensuring of course that the transfer list is properly
> > supported.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >  doc/develop/devicetree/control.rst |  3 ++
> >  dts/Kconfig                        |  8 ++++
> >  lib/fdtdec.c                       | 66 ++++++++++++------------------
> >  3 files changed, 38 insertions(+), 39 deletions(-)
> >
> > diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
> > index 0233945f8b6..d80f4d420a9 100644
> > --- a/doc/develop/devicetree/control.rst
> > +++ b/doc/develop/devicetree/control.rst
> > @@ -137,6 +137,9 @@ If `OF_BOARD` is selected by Kconfig, a board-specific routine will provide the
> >  devicetree at runtime, for example if an earlier bootloader stage creates
> >  it and passes it to U-Boot.
> >
> > +If `OF_BLOBLIST` is defined, the devicetree comes from a bloblist passed
> > +from a previous stage.
> > +
> >  If `BLOBLIST` is selected by Kconfig, the devicetree may come from a bloblist
> >  passed from a previous stage, if present.
> >
> > diff --git a/dts/Kconfig b/dts/Kconfig
> > index 6a5141b56e9..04359a4d7b2 100644
> > --- a/dts/Kconfig
> > +++ b/dts/Kconfig
> > @@ -167,6 +167,14 @@ config OF_INITIAL_DTB_READONLY
> >           If initial DTB for DT control is read-only (e.g. points to
> >           memory-mapped flash memory), then set this option.
> >
> > +config OF_BLOBLIST
> > +       bool "DTB is provided by a bloblist"
> > +       help
> > +         Select this to read the devicetree from the bloblist. This allows
> > +         using a bloblist to transfer the devicetree between U-Boot phases.
> > +         The devicetree is stored in the bloblist by an earlier phase so that
> > +         U-Boot can read it.
> > +
> >  config OF_BOARD
> >         bool "Provided by the board (e.g a previous loader) at runtime"
> >         default y if SANDBOX || OF_HAS_PRIOR_STAGE
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > index f09c9926a7a..833f8aca3ce 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -1689,55 +1689,43 @@ void fdtdec_setup_embed(void)
> >
> >  int fdtdec_setup(void)
>
> I think a better idea is to use BLOBLIST_PASSAGE_MANDATORY, see below
> pseudo code:
>
> ```
> if (IS_ENABLED(CONFIG_OF_BOARD)) {
>     /* get fdt from board */
> }
>
> /* allow fdtcontroladdr to override it */
>
> if (CONFIG_IS_ENABLED(BLOBLIST) && ... ) {
>     /* try to find fdt from bloblist */
>
>     if (CONFIG_IS_ENABLED(BLOBLIST_PASSAGE_MANDATORY) {
>         if (no_fdt_in_bloblist)
>             return ERROR;
>
>         /* override fdt with the one from bloblist */
>     }
> }
> ```

See my other email on this. With OF_BLOBLIST we actually don't need
BLOBLIST_PASSAGE_MANDATORY so we can drop it.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Raymond,
>
> On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > The bloblist code took what I consider to be a wrong turn a year or so
> > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > so that it is simpler to understand and manage.
> > >
> > > - Unwind some of the nesting in bloblist_init()
> > > - Avoid needing to init the bloblist just to get the FDT
> > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > >
> > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > mandatorily use bloblist to hand over everything between boot stages
> > including fdt, creating OF_BLOBLIST is not necessary.
>
> Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> there must be a bloblist, not that it must contain a devicetree. So I
> wasn't sure about removing it.
>

See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
selected, we can override any fdt from board or env with the one from
the bloblist.
Moreover, it is not just for fdt, but for everything that is being
handed over from the previous boot stage using bloblist, but
OF_BLOBLIST is for fdt only.
I don't think it is a good idea to replace BLOBLIST_PASSAGE_MANDATORY
with OF_BLOBLIST.

Regards,
Raymond

> But actually, thinking about it just now, we can remove
> BLOBLIST_PASSAGE_MANDATORY, since U-Boot won't make it that far if
> there is no bloblist. It will die in fdtdec_setup(). Take a look and
> see if you agree.
>
> >
> > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > CI at some point. In the meantime, the standard passage series[1] could
> > > be resurrected to give some coverage.
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > >
> > >
> > > Simon Glass (4):
> > >   bloblist: Simplify bloblist init
> > >   fdt: Introduce OF_BLOBLIST
> > >   bloblist: Provide access to the FDT address
> > >   fdt: Obtain the FDT from bloblist without parsing it
> > >
> > >  arch/arm/lib/xferlist.c            |   6 +-
> > >  common/bloblist.c                  | 102 ++++++++++++++++++-----------
> > >  doc/develop/devicetree/control.rst |   3 +
> > >  dts/Kconfig                        |   8 +++
> > >  include/bloblist.h                 |  16 ++++-
> > >  lib/fdtdec.c                       |  65 +++++++-----------
> > >  6 files changed, 116 insertions(+), 84 deletions(-)
> > >
> > > --
> > > 2.43.0
> > >
>
> Regards,
> Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Raymond,
> >
> > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > so that it is simpler to understand and manage.
> > > >
> > > > - Unwind some of the nesting in bloblist_init()
> > > > - Avoid needing to init the bloblist just to get the FDT
> > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > >
> > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > mandatorily use bloblist to hand over everything between boot stages
> > > including fdt, creating OF_BLOBLIST is not necessary.
> >
> > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > there must be a bloblist, not that it must contain a devicetree. So I
> > wasn't sure about removing it.
> >
>
> See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> selected, we can override any fdt from board or env with the one from
> the bloblist.

Yes, but we should be explicit about what is going on here. With
OF_BLOBLIST we indicate that the devicetree is coming from the
bloblist. It becomes one of the sources for devicetree, like
OF_SEPARATE and OF_EMBED

> Moreover, it is not just for fdt, but for everything that is being
> handed over from the previous boot stage using bloblist, but
> OF_BLOBLIST is for fdt only.

What other things are there?

> I don't think it is a good idea to replace BLOBLIST_PASSAGE_MANDATORY
> with OF_BLOBLIST.

I am OK with keeping BLOBLIST_PASSAGE_MANDATORY for now. This series
does not remove it.

>
> > But actually, thinking about it just now, we can remove
> > BLOBLIST_PASSAGE_MANDATORY, since U-Boot won't make it that far if
> > there is no bloblist. It will die in fdtdec_setup(). Take a look and
> > see if you agree.

Regards,
SImon

> >
> > >
> > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > be resurrected to give some coverage.
> > > >
> > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > >
> > > >
> > > > Simon Glass (4):
> > > >   bloblist: Simplify bloblist init
> > > >   fdt: Introduce OF_BLOBLIST
> > > >   bloblist: Provide access to the FDT address
> > > >   fdt: Obtain the FDT from bloblist without parsing it
> > > >
> > > >  arch/arm/lib/xferlist.c            |   6 +-
> > > >  common/bloblist.c                  | 102 ++++++++++++++++++-----------
> > > >  doc/develop/devicetree/control.rst |   3 +
> > > >  dts/Kconfig                        |   8 +++
> > > >  include/bloblist.h                 |  16 ++++-
> > > >  lib/fdtdec.c                       |  65 +++++++-----------
> > > >  6 files changed, 116 insertions(+), 84 deletions(-)
> > > >
> > > > --
> > > > 2.43.0
> > > >
> >
> > Regards,
> > Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Raymond,
>
> On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > so that it is simpler to understand and manage.
> > > > >
> > > > > - Unwind some of the nesting in bloblist_init()
> > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > >
> > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > mandatorily use bloblist to hand over everything between boot stages
> > > > including fdt, creating OF_BLOBLIST is not necessary.
> > >
> > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > there must be a bloblist, not that it must contain a devicetree. So I
> > > wasn't sure about removing it.
> > >
> >
> > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > selected, we can override any fdt from board or env with the one from
> > the bloblist.
>
> Yes, but we should be explicit about what is going on here. With
> OF_BLOBLIST we indicate that the devicetree is coming from the
> bloblist. It becomes one of the sources for devicetree, like
> OF_SEPARATE and OF_EMBED
>

BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
mandatorily used and override other fdt sources like from the board or
env variables.

> > Moreover, it is not just for fdt, but for everything that is being
> > handed over from the previous boot stage using bloblist, but
> > OF_BLOBLIST is for fdt only.
>
> What other things are there?

All transfer entries defined in the Firmware Handoff spec should be
handed over via bloblist, for example, TPM event logs.

Regards,
Raymond

>
> > I don't think it is a good idea to replace BLOBLIST_PASSAGE_MANDATORY
> > with OF_BLOBLIST.
>
> I am OK with keeping BLOBLIST_PASSAGE_MANDATORY for now. This series
> does not remove it.
>
> >
> > > But actually, thinking about it just now, we can remove
> > > BLOBLIST_PASSAGE_MANDATORY, since U-Boot won't make it that far if
> > > there is no bloblist. It will die in fdtdec_setup(). Take a look and
> > > see if you agree.
>
> Regards,
> SImon
>
> > >
> > > >
> > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > be resurrected to give some coverage.
> > > > >
> > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > >
> > > > >
> > > > > Simon Glass (4):
> > > > >   bloblist: Simplify bloblist init
> > > > >   fdt: Introduce OF_BLOBLIST
> > > > >   bloblist: Provide access to the FDT address
> > > > >   fdt: Obtain the FDT from bloblist without parsing it
> > > > >
> > > > >  arch/arm/lib/xferlist.c            |   6 +-
> > > > >  common/bloblist.c                  | 102 ++++++++++++++++++-----------
> > > > >  doc/develop/devicetree/control.rst |   3 +
> > > > >  dts/Kconfig                        |   8 +++
> > > > >  include/bloblist.h                 |  16 ++++-
> > > > >  lib/fdtdec.c                       |  65 +++++++-----------
> > > > >  6 files changed, 116 insertions(+), 84 deletions(-)
> > > > >
> > > > > --
> > > > > 2.43.0
> > > > >
> > >
> > > Regards,
> > > Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Raymond,
> >
> > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > so that it is simpler to understand and manage.
> > > > > >
> > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > >
> > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > >
> > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > wasn't sure about removing it.
> > > >
> > >
> > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > selected, we can override any fdt from board or env with the one from
> > > the bloblist.
> >
> > Yes, but we should be explicit about what is going on here. With
> > OF_BLOBLIST we indicate that the devicetree is coming from the
> > bloblist. It becomes one of the sources for devicetree, like
> > OF_SEPARATE and OF_EMBED
> >
>
> BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> mandatorily used and override other fdt sources like from the board or
> env variables.

So long as you are OK with OF_BLOBLIST as well, I have no objection to
keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
very much. But I can see why it is called that as my standard passage
series was actually never applied. So I suppose I'll need to have
another try at that.

So to be clear, I want a separate option for devicetree, called
OF_BLOBLIST, which I can enable/disable as needed, without affecting
your option.

>
> > > Moreover, it is not just for fdt, but for everything that is being
> > > handed over from the previous boot stage using bloblist, but
> > > OF_BLOBLIST is for fdt only.
> >
> > What other things are there?
>
> All transfer entries defined in the Firmware Handoff spec should be
> handed over via bloblist, for example, TPM event logs.

OK, again no objection. I don't see any code for that though.

Regards,
SImon


>
> Regards,
> Raymond
>
> >
> > > I don't think it is a good idea to replace BLOBLIST_PASSAGE_MANDATORY
> > > with OF_BLOBLIST.
> >
> > I am OK with keeping BLOBLIST_PASSAGE_MANDATORY for now. This series
> > does not remove it.
> >
> > >
> > > > But actually, thinking about it just now, we can remove
> > > > BLOBLIST_PASSAGE_MANDATORY, since U-Boot won't make it that far if
> > > > there is no bloblist. It will die in fdtdec_setup(). Take a look and
> > > > see if you agree.
> >
> > Regards,
> > SImon
> >
> > > >
> > > > >
> > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > be resurrected to give some coverage.
> > > > > >
> > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > >
> > > > > >
> > > > > > Simon Glass (4):
> > > > > >   bloblist: Simplify bloblist init
> > > > > >   fdt: Introduce OF_BLOBLIST
> > > > > >   bloblist: Provide access to the FDT address
> > > > > >   fdt: Obtain the FDT from bloblist without parsing it
> > > > > >
> > > > > >  arch/arm/lib/xferlist.c            |   6 +-
> > > > > >  common/bloblist.c                  | 102 ++++++++++++++++++-----------
> > > > > >  doc/develop/devicetree/control.rst |   3 +
> > > > > >  dts/Kconfig                        |   8 +++
> > > > > >  include/bloblist.h                 |  16 ++++-
> > > > > >  lib/fdtdec.c                       |  65 +++++++-----------
> > > > > >  6 files changed, 116 insertions(+), 84 deletions(-)
> > > > > >
> > > > > > --
> > > > > > 2.43.0
> > > > > >
> > > >
> > > > Regards,
> > > > Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]

On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> Hi Raymond,
> 
> On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > so that it is simpler to understand and manage.
> > > > > > >
> > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > >
> > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > >
> > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > wasn't sure about removing it.
> > > > >
> > > >
> > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > selected, we can override any fdt from board or env with the one from
> > > > the bloblist.
> > >
> > > Yes, but we should be explicit about what is going on here. With
> > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > bloblist. It becomes one of the sources for devicetree, like
> > > OF_SEPARATE and OF_EMBED
> > >
> >
> > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > mandatorily used and override other fdt sources like from the board or
> > env variables.
> 
> So long as you are OK with OF_BLOBLIST as well, I have no objection to
> keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> very much. But I can see why it is called that as my standard passage
> series was actually never applied. So I suppose I'll need to have
> another try at that.
> 
> So to be clear, I want a separate option for devicetree, called
> OF_BLOBLIST, which I can enable/disable as needed, without affecting
> your option.

Sigh. Can I ask what the use case for this will be? And we are going to
get rid of BLOBLIST_FIXED at some point, yes?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > Hi Raymond,
> >
> > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Raymond,
> > > > > >
> > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > so that it is simpler to understand and manage.
> > > > > > > >
> > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > >
> > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > >
> > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > wasn't sure about removing it.
> > > > > >
> > > > >
> > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > selected, we can override any fdt from board or env with the one from
> > > > > the bloblist.
> > > >
> > > > Yes, but we should be explicit about what is going on here. With
> > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > bloblist. It becomes one of the sources for devicetree, like
> > > > OF_SEPARATE and OF_EMBED
> > > >
> > >
> > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > mandatorily used and override other fdt sources like from the board or
> > > env variables.
> >
> > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > very much. But I can see why it is called that as my standard passage
> > series was actually never applied. So I suppose I'll need to have
> > another try at that.
> >
> > So to be clear, I want a separate option for devicetree, called
> > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > your option.
>
> Sigh. Can I ask what the use case for this will be? And we are going to
> get rid of BLOBLIST_FIXED at some point, yes?

I thought we agreed that this was acceptable. We argued the toss for
months on this point and I would rather not revisit it.

Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
pretty sure it can be done. The only tricky bit is coming up with a
bloblist protocol for x86.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4332 bytes --]

On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > Hi Raymond,
> > >
> > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > >
> > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > >
> > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > >
> > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > wasn't sure about removing it.
> > > > > > >
> > > > > >
> > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > the bloblist.
> > > > >
> > > > > Yes, but we should be explicit about what is going on here. With
> > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > OF_SEPARATE and OF_EMBED
> > > > >
> > > >
> > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > mandatorily used and override other fdt sources like from the board or
> > > > env variables.
> > >
> > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > very much. But I can see why it is called that as my standard passage
> > > series was actually never applied. So I suppose I'll need to have
> > > another try at that.
> > >
> > > So to be clear, I want a separate option for devicetree, called
> > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > your option.
> >
> > Sigh. Can I ask what the use case for this will be? And we are going to
> > get rid of BLOBLIST_FIXED at some point, yes?
> 
> I thought we agreed that this was acceptable. We argued the toss for
> months on this point and I would rather not revisit it.
> 
> Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> pretty sure it can be done. The only tricky bit is coming up with a
> bloblist protocol for x86.

Yes, I'm stuck between being "flexible and saying yes" and how long we
have to live with what I also think are bad designs.

So maybe the pre-requisite here is that with "bloblist" and "standard
passage" being divorced, what is the requirement for bloblist again?
Because in practice, all of the problems we've had come down to looking
in fixed address locations before they're valid. You want to handle this
by saying "Ah, we won't look before it's valid with other CONFIG flags"
and I say we should handle this by not using a fixed address to start
with.

If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
OK. But it shouldn't need to exist long term.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Tom and Simon,

On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Tom and Simon,
>
> On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > >
> > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > so that it is simpler to understand and manage.
> > > > >
> > > > > - Unwind some of the nesting in bloblist_init()
> > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > >
> > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > be resurrected to give some coverage.
> > > > >
> > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > >
> > > > Based on how it's documented to be run in
> > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > that platforms using the handoff spec still work?
> > >
> > > I believe so, yes. I don't have that board to test it though. Raymond
> > > may be able to test this series on QEMU?
> >
> > I was pointing you at the docs so that you would have access to testing
> > it. That's part of the docs, running the emulator.
> >
>
> I can help to test the firmware handoff on qemu.
> I have all the necessary changes and unit tests for the OP-TEE repo
> qemu v8 build to test this.
> I will try to find some time early next week to review and test this
> series before turning back to you.
>

Just a follow-up on the testing with TF-A and OP-TEE.
Unfortunately, the patch series breaks the transfer list handoff to
U-Boot completely and just end up with below error when U-Boot boots:
```
No valid device tree binary found at 0000000000000000
initcall failed at call 0000000060097bcc (err=-2)
### ERROR ### Please RESET the board ###
```

U-Boot test version:
'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.

[1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/

Regards,
Raymond

> Regards,
> Raymond
>
> > --
> > Tom

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Tom and Simon,

On Fri, 4 Apr 2025 at 10:48, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Tom and Simon,
>
> On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Tom and Simon,
> >
> > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > >
> > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > so that it is simpler to understand and manage.
> > > > > >
> > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > >
> > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > be resurrected to give some coverage.
> > > > > >
> > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > >
> > > > > Based on how it's documented to be run in
> > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > that platforms using the handoff spec still work?
> > > >
> > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > may be able to test this series on QEMU?
> > >
> > > I was pointing you at the docs so that you would have access to testing
> > > it. That's part of the docs, running the emulator.
> > >
> >
> > I can help to test the firmware handoff on qemu.
> > I have all the necessary changes and unit tests for the OP-TEE repo
> > qemu v8 build to test this.
> > I will try to find some time early next week to review and test this
> > series before turning back to you.
> >
>
> Just a follow-up on the testing with TF-A and OP-TEE.
> Unfortunately, the patch series breaks the transfer list handoff to
> U-Boot completely and just end up with below error when U-Boot boots:
> ```
> No valid device tree binary found at 0000000000000000
> initcall failed at call 0000000060097bcc (err=-2)
> ### ERROR ### Please RESET the board ###
> ```
>
> U-Boot test version:
> 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
>

Forgot to mention: with OF_BLOBLIST selected.

> [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
>
> Regards,
> Raymond
>
> > Regards,
> > Raymond
> >
> > > --
> > > Tom

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > Hi Raymond,
> > > >
> > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Raymond,
> > > > > >
> > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Raymond,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > >
> > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > >
> > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > >
> > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > >
> > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > wasn't sure about removing it.
> > > > > > > >
> > > > > > >
> > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > the bloblist.
> > > > > >
> > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > OF_SEPARATE and OF_EMBED
> > > > > >
> > > > >
> > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > mandatorily used and override other fdt sources like from the board or
> > > > > env variables.
> > > >
> > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > very much. But I can see why it is called that as my standard passage
> > > > series was actually never applied. So I suppose I'll need to have
> > > > another try at that.
> > > >
> > > > So to be clear, I want a separate option for devicetree, called
> > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > your option.
> > >
> > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > get rid of BLOBLIST_FIXED at some point, yes?
> >
> > I thought we agreed that this was acceptable. We argued the toss for
> > months on this point and I would rather not revisit it.
> >
> > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > pretty sure it can be done. The only tricky bit is coming up with a
> > bloblist protocol for x86.
>
> Yes, I'm stuck between being "flexible and saying yes" and how long we
> have to live with what I also think are bad designs.
>
> So maybe the pre-requisite here is that with "bloblist" and "standard
> passage" being divorced, what is the requirement for bloblist again?
> Because in practice, all of the problems we've had come down to looking
> in fixed address locations before they're valid. You want to handle this
> by saying "Ah, we won't look before it's valid with other CONFIG flags"
> and I say we should handle this by not using a fixed address to start
> with.
>
> If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> OK. But it shouldn't need to exist long term.

For me, OF_BLOBLIST is needed for x86 devices which don't pass the
devicetree in the bloblist.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Tom and Simon,
>
> On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Tom and Simon,
> >
> > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > >
> > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > so that it is simpler to understand and manage.
> > > > > >
> > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > >
> > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > be resurrected to give some coverage.
> > > > > >
> > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > >
> > > > > Based on how it's documented to be run in
> > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > that platforms using the handoff spec still work?
> > > >
> > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > may be able to test this series on QEMU?
> > >
> > > I was pointing you at the docs so that you would have access to testing
> > > it. That's part of the docs, running the emulator.
> > >
> >
> > I can help to test the firmware handoff on qemu.
> > I have all the necessary changes and unit tests for the OP-TEE repo
> > qemu v8 build to test this.
> > I will try to find some time early next week to review and test this
> > series before turning back to you.
> >
>
> Just a follow-up on the testing with TF-A and OP-TEE.
> Unfortunately, the patch series breaks the transfer list handoff to
> U-Boot completely and just end up with below error when U-Boot boots:
> ```
> No valid device tree binary found at 0000000000000000
> initcall failed at call 0000000060097bcc (err=-2)
> ### ERROR ### Please RESET the board ###
> ```
>
> U-Boot test version:
> 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
>
> [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/

I suppose the FDT address in the register is not being read correctly.

Do you have a test case for this, e.g. in QEMU? Even if it is just
binary blobs for now, not suitable for CI, I'd like to get it in my
lab.

I did create a test back when I did standard passage, but that series
seems to have not been applied. I'll see if I can resurrect it.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3530 bytes --]

On Sat, Apr 05, 2025 at 06:40:08AM +1300, Simon Glass wrote:
> Hi Raymond,
> 
> On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Tom and Simon,
> >
> > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Tom and Simon,
> > >
> > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > >
> > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > so that it is simpler to understand and manage.
> > > > > > >
> > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > >
> > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > be resurrected to give some coverage.
> > > > > > >
> > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > >
> > > > > > Based on how it's documented to be run in
> > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > that platforms using the handoff spec still work?
> > > > >
> > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > may be able to test this series on QEMU?
> > > >
> > > > I was pointing you at the docs so that you would have access to testing
> > > > it. That's part of the docs, running the emulator.
> > > >
> > >
> > > I can help to test the firmware handoff on qemu.
> > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > qemu v8 build to test this.
> > > I will try to find some time early next week to review and test this
> > > series before turning back to you.
> > >
> >
> > Just a follow-up on the testing with TF-A and OP-TEE.
> > Unfortunately, the patch series breaks the transfer list handoff to
> > U-Boot completely and just end up with below error when U-Boot boots:
> > ```
> > No valid device tree binary found at 0000000000000000
> > initcall failed at call 0000000060097bcc (err=-2)
> > ### ERROR ### Please RESET the board ###
> > ```
> >
> > U-Boot test version:
> > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> >
> > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> 
> I suppose the FDT address in the register is not being read correctly.
> 
> Do you have a test case for this, e.g. in QEMU? Even if it is just
> binary blobs for now, not suitable for CI, I'd like to get it in my
> lab.
> 
> I did create a test back when I did standard passage, but that series
> seems to have not been applied. I'll see if I can resurrect it.

This problem should also be visible with running vexpress64 as
documented in doc/board/armltd/vexpress64.rst which is not yet in CI
(it's straight forward but non-trivial), which is why I was asking about
it earlier in the thread.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5038 bytes --]

On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > Hi Raymond,
> > > > >
> > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Raymond,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > >
> > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > >
> > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > >
> > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > wasn't sure about removing it.
> > > > > > > > >
> > > > > > > >
> > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > the bloblist.
> > > > > > >
> > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > >
> > > > > >
> > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > env variables.
> > > > >
> > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > very much. But I can see why it is called that as my standard passage
> > > > > series was actually never applied. So I suppose I'll need to have
> > > > > another try at that.
> > > > >
> > > > > So to be clear, I want a separate option for devicetree, called
> > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > your option.
> > > >
> > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > get rid of BLOBLIST_FIXED at some point, yes?
> > >
> > > I thought we agreed that this was acceptable. We argued the toss for
> > > months on this point and I would rather not revisit it.
> > >
> > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > pretty sure it can be done. The only tricky bit is coming up with a
> > > bloblist protocol for x86.
> >
> > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > have to live with what I also think are bad designs.
> >
> > So maybe the pre-requisite here is that with "bloblist" and "standard
> > passage" being divorced, what is the requirement for bloblist again?
> > Because in practice, all of the problems we've had come down to looking
> > in fixed address locations before they're valid. You want to handle this
> > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > and I say we should handle this by not using a fixed address to start
> > with.
> >
> > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > OK. But it shouldn't need to exist long term.
> 
> For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> devicetree in the bloblist.

I don't understand why that would become the case when it's not true
today.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Raymond,
>
> On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Tom and Simon,
> >
> > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Tom and Simon,
> > >
> > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > >
> > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > so that it is simpler to understand and manage.
> > > > > > >
> > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > >
> > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > be resurrected to give some coverage.
> > > > > > >
> > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > >
> > > > > > Based on how it's documented to be run in
> > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > that platforms using the handoff spec still work?
> > > > >
> > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > may be able to test this series on QEMU?
> > > >
> > > > I was pointing you at the docs so that you would have access to testing
> > > > it. That's part of the docs, running the emulator.
> > > >
> > >
> > > I can help to test the firmware handoff on qemu.
> > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > qemu v8 build to test this.
> > > I will try to find some time early next week to review and test this
> > > series before turning back to you.
> > >
> >
> > Just a follow-up on the testing with TF-A and OP-TEE.
> > Unfortunately, the patch series breaks the transfer list handoff to
> > U-Boot completely and just end up with below error when U-Boot boots:
> > ```
> > No valid device tree binary found at 0000000000000000
> > initcall failed at call 0000000060097bcc (err=-2)
> > ### ERROR ### Please RESET the board ###
> > ```
> >
> > U-Boot test version:
> > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> >
> > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
>
> I suppose the FDT address in the register is not being read correctly.
>
> Do you have a test case for this, e.g. in QEMU? Even if it is just
> binary blobs for now, not suitable for CI, I'd like to get it in my
> lab.
>
> I did create a test back when I did standard passage, but that series
> seems to have not been applied. I'll see if I can resurrect it.
>

I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
need my patch [2] for enabling transfer_ist in all components.

[1] https://github.com/OP-TEE
[2] https://github.com/OP-TEE/build/pull/821

Regards,
Raymond

> Regards,
> Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Raymond,
> >
> > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Tom and Simon,
> > >
> > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Tom and Simon,
> > > >
> > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > >
> > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > so that it is simpler to understand and manage.
> > > > > > > >
> > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > >
> > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > be resurrected to give some coverage.
> > > > > > > >
> > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > >
> > > > > > > Based on how it's documented to be run in
> > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > that platforms using the handoff spec still work?
> > > > > >
> > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > may be able to test this series on QEMU?
> > > > >
> > > > > I was pointing you at the docs so that you would have access to testing
> > > > > it. That's part of the docs, running the emulator.
> > > > >
> > > >
> > > > I can help to test the firmware handoff on qemu.
> > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > qemu v8 build to test this.
> > > > I will try to find some time early next week to review and test this
> > > > series before turning back to you.
> > > >
> > >
> > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > Unfortunately, the patch series breaks the transfer list handoff to
> > > U-Boot completely and just end up with below error when U-Boot boots:
> > > ```
> > > No valid device tree binary found at 0000000000000000
> > > initcall failed at call 0000000060097bcc (err=-2)
> > > ### ERROR ### Please RESET the board ###
> > > ```
> > >
> > > U-Boot test version:
> > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > >
> > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> >
> > I suppose the FDT address in the register is not being read correctly.
> >
> > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > binary blobs for now, not suitable for CI, I'd like to get it in my
> > lab.
> >
> > I did create a test back when I did standard passage, but that series
> > seems to have not been applied. I'll see if I can resurrect it.
> >
>
> I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> need my patch [2] for enabling transfer_ist in all components.
>
> [1] https://github.com/OP-TEE
> [2] https://github.com/OP-TEE/build/pull/821
>

Tom's email seems easier to follow. I got as far as building:

build/fvp/release/fip.bin

But I'm not sure how to run that in QEMU. The docs mention some sort
of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
to have.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > Hi Raymond,
> > > > > >
> > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Raymond,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Raymond,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > >
> > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > >
> > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > >
> > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > the bloblist.
> > > > > > > >
> > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > >
> > > > > > >
> > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > env variables.
> > > > > >
> > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > another try at that.
> > > > > >
> > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > your option.
> > > > >
> > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > >
> > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > months on this point and I would rather not revisit it.
> > > >
> > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > bloblist protocol for x86.
> > >
> > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > have to live with what I also think are bad designs.
> > >
> > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > passage" being divorced, what is the requirement for bloblist again?
> > > Because in practice, all of the problems we've had come down to looking
> > > in fixed address locations before they're valid. You want to handle this
> > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > and I say we should handle this by not using a fixed address to start
> > > with.
> > >
> > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > OK. But it shouldn't need to exist long term.
> >
> > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > devicetree in the bloblist.
>
> I don't understand why that would become the case when it's not true
> today.

If you look at the top of fdtdec_setup() in your tree you can see the
special-case code related to TPL, that I'm wanting to get rid of.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4355 bytes --]

On Mon, Apr 07, 2025 at 10:06:04AM +1200, Simon Glass wrote:
> Hi Raymond,
> 
> On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Tom and Simon,
> > > >
> > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Tom and Simon,
> > > > >
> > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > >
> > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > >
> > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > >
> > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > be resurrected to give some coverage.
> > > > > > > > >
> > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > >
> > > > > > > > Based on how it's documented to be run in
> > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > that platforms using the handoff spec still work?
> > > > > > >
> > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > may be able to test this series on QEMU?
> > > > > >
> > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > it. That's part of the docs, running the emulator.
> > > > > >
> > > > >
> > > > > I can help to test the firmware handoff on qemu.
> > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > qemu v8 build to test this.
> > > > > I will try to find some time early next week to review and test this
> > > > > series before turning back to you.
> > > > >
> > > >
> > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > ```
> > > > No valid device tree binary found at 0000000000000000
> > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > ### ERROR ### Please RESET the board ###
> > > > ```
> > > >
> > > > U-Boot test version:
> > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > >
> > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > >
> > > I suppose the FDT address in the register is not being read correctly.
> > >
> > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > lab.
> > >
> > > I did create a test back when I did standard passage, but that series
> > > seems to have not been applied. I'll see if I can resurrect it.
> > >
> >
> > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > need my patch [2] for enabling transfer_ist in all components.
> >
> > [1] https://github.com/OP-TEE
> > [2] https://github.com/OP-TEE/build/pull/821
> >
> 
> Tom's email seems easier to follow. I got as far as building:
> 
> build/fvp/release/fip.bin
> 
> But I'm not sure how to run that in QEMU. The docs mention some sort
> of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> to have.

Yes, you need to download the linked emulator, it's not QEMU.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6030 bytes --]

On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Raymond,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Raymond,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > >
> > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > >
> > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > >
> > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > the bloblist.
> > > > > > > > >
> > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > >
> > > > > > > >
> > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > env variables.
> > > > > > >
> > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > another try at that.
> > > > > > >
> > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > your option.
> > > > > >
> > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > >
> > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > months on this point and I would rather not revisit it.
> > > > >
> > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > bloblist protocol for x86.
> > > >
> > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > have to live with what I also think are bad designs.
> > > >
> > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > passage" being divorced, what is the requirement for bloblist again?
> > > > Because in practice, all of the problems we've had come down to looking
> > > > in fixed address locations before they're valid. You want to handle this
> > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > and I say we should handle this by not using a fixed address to start
> > > > with.
> > > >
> > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > OK. But it shouldn't need to exist long term.
> > >
> > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > devicetree in the bloblist.
> >
> > I don't understand why that would become the case when it's not true
> > today.
> 
> If you look at the top of fdtdec_setup() in your tree you can see the
> special-case code related to TPL, that I'm wanting to get rid of.

OK, but all of that too is for the case of a fixed bloblist being in
uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
to see passing of the bloblist from xPL -> PPL be implemented and so xPL
can allocate a bloblist (or grow a passed one if needed).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > Hi Raymond,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Raymond,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > >
> > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > the bloblist.
> > > > > > > > > >
> > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > env variables.
> > > > > > > >
> > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > another try at that.
> > > > > > > >
> > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > your option.
> > > > > > >
> > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > >
> > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > months on this point and I would rather not revisit it.
> > > > > >
> > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > bloblist protocol for x86.
> > > > >
> > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > have to live with what I also think are bad designs.
> > > > >
> > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > Because in practice, all of the problems we've had come down to looking
> > > > > in fixed address locations before they're valid. You want to handle this
> > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > and I say we should handle this by not using a fixed address to start
> > > > > with.
> > > > >
> > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > OK. But it shouldn't need to exist long term.
> > > >
> > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > devicetree in the bloblist.
> > >
> > > I don't understand why that would become the case when it's not true
> > > today.
> >
> > If you look at the top of fdtdec_setup() in your tree you can see the
> > special-case code related to TPL, that I'm wanting to get rid of.
>
> OK, but all of that too is for the case of a fixed bloblist being in
> uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> can allocate a bloblist (or grow a passed one if needed).

We are going around in circles though. Having it is registers doesn't
help with the problem that there isn't an FDT in the bloblist.

Also, I thought you decided that I could maintain bloblist. Have you
changed your mind?

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Raymond,
>
> On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Tom and Simon,
> > > >
> > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Tom and Simon,
> > > > >
> > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > >
> > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > >
> > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > >
> > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > be resurrected to give some coverage.
> > > > > > > > >
> > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > >
> > > > > > > > Based on how it's documented to be run in
> > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > that platforms using the handoff spec still work?
> > > > > > >
> > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > may be able to test this series on QEMU?
> > > > > >
> > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > it. That's part of the docs, running the emulator.
> > > > > >
> > > > >
> > > > > I can help to test the firmware handoff on qemu.
> > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > qemu v8 build to test this.
> > > > > I will try to find some time early next week to review and test this
> > > > > series before turning back to you.
> > > > >
> > > >
> > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > ```
> > > > No valid device tree binary found at 0000000000000000
> > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > ### ERROR ### Please RESET the board ###
> > > > ```
> > > >
> > > > U-Boot test version:
> > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > >
> > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > >
> > > I suppose the FDT address in the register is not being read correctly.
> > >
> > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > lab.
> > >
> > > I did create a test back when I did standard passage, but that series
> > > seems to have not been applied. I'll see if I can resurrect it.
> > >
> >
> > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > need my patch [2] for enabling transfer_ist in all components.
> >
> > [1] https://github.com/OP-TEE
> > [2] https://github.com/OP-TEE/build/pull/821
> >
>
> Tom's email seems easier to follow. I got as far as building:
>
> build/fvp/release/fip.bin
>
> But I'm not sure how to run that in QEMU. The docs mention some sort
> of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> to have.
>

If you want to test with QEMU v8, just simply:
$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
$ repo sync
$ cd build
Apply my patch https://github.com/OP-TEE/build/pull/821
In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
'OF_BLOBLIST=y'
$ make toolchains
$ make run

Regards,
Raymond

> Regards,
> Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7223 bytes --]

On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > Hi Raymond,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Raymond,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > the bloblist.
> > > > > > > > > > >
> > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > env variables.
> > > > > > > > >
> > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > another try at that.
> > > > > > > > >
> > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > your option.
> > > > > > > >
> > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > >
> > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > months on this point and I would rather not revisit it.
> > > > > > >
> > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > bloblist protocol for x86.
> > > > > >
> > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > have to live with what I also think are bad designs.
> > > > > >
> > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > with.
> > > > > >
> > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > OK. But it shouldn't need to exist long term.
> > > > >
> > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > devicetree in the bloblist.
> > > >
> > > > I don't understand why that would become the case when it's not true
> > > > today.
> > >
> > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > special-case code related to TPL, that I'm wanting to get rid of.
> >
> > OK, but all of that too is for the case of a fixed bloblist being in
> > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > can allocate a bloblist (or grow a passed one if needed).
> 
> We are going around in circles though. Having it is registers doesn't
> help with the problem that there isn't an FDT in the bloblist.

Sure it does. If we're passed a bloblist in a register we can then see
if it has a DT (and use it) or not (and move to the next DT location).

> Also, I thought you decided that I could maintain bloblist. Have you
> changed your mind?

You just mis-understood me. Yes, you can maintain bloblist. But also,
Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
problems is that no one understood you.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > Hi Raymond,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > env variables.
> > > > > > > > > >
> > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > another try at that.
> > > > > > > > > >
> > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > your option.
> > > > > > > > >
> > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > >
> > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > >
> > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > bloblist protocol for x86.
> > > > > > >
> > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > have to live with what I also think are bad designs.
> > > > > > >
> > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > with.
> > > > > > >
> > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > OK. But it shouldn't need to exist long term.
> > > > > >
> > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > devicetree in the bloblist.
> > > > >
> > > > > I don't understand why that would become the case when it's not true
> > > > > today.
> > > >
> > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > special-case code related to TPL, that I'm wanting to get rid of.
> > >
> > > OK, but all of that too is for the case of a fixed bloblist being in
> > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > can allocate a bloblist (or grow a passed one if needed).
> >
> > We are going around in circles though. Having it is registers doesn't
> > help with the problem that there isn't an FDT in the bloblist.
>
> Sure it does. If we're passed a bloblist in a register we can then see
> if it has a DT (and use it) or not (and move to the next DT location).
>
> > Also, I thought you decided that I could maintain bloblist. Have you
> > changed your mind?
>
> You just mis-understood me. Yes, you can maintain bloblist. But also,
> Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> problems is that no one understood you.

Is there a call tomorrow, or is it next week?

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7979 bytes --]

On Mon, Apr 07, 2025 at 09:24:16AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > Hi Raymond,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > env variables.
> > > > > > > > > > >
> > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > another try at that.
> > > > > > > > > > >
> > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > your option.
> > > > > > > > > >
> > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > >
> > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > >
> > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > bloblist protocol for x86.
> > > > > > > >
> > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > have to live with what I also think are bad designs.
> > > > > > > >
> > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > with.
> > > > > > > >
> > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > >
> > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > devicetree in the bloblist.
> > > > > >
> > > > > > I don't understand why that would become the case when it's not true
> > > > > > today.
> > > > >
> > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > >
> > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > can allocate a bloblist (or grow a passed one if needed).
> > >
> > > We are going around in circles though. Having it is registers doesn't
> > > help with the problem that there isn't an FDT in the bloblist.
> >
> > Sure it does. If we're passed a bloblist in a register we can then see
> > if it has a DT (and use it) or not (and move to the next DT location).
> >
> > > Also, I thought you decided that I could maintain bloblist. Have you
> > > changed your mind?
> >
> > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > problems is that no one understood you.
> 
> Is there a call tomorrow, or is it next week?

Tomorrow.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Mon, 7 Apr 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Apr 07, 2025 at 09:24:16AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > env variables.
> > > > > > > > > > > >
> > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > another try at that.
> > > > > > > > > > > >
> > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > your option.
> > > > > > > > > > >
> > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > >
> > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > >
> > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > bloblist protocol for x86.
> > > > > > > > >
> > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > >
> > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > with.
> > > > > > > > >
> > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > >
> > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > devicetree in the bloblist.
> > > > > > >
> > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > today.
> > > > > >
> > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > >
> > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > can allocate a bloblist (or grow a passed one if needed).
> > > >
> > > > We are going around in circles though. Having it is registers doesn't
> > > > help with the problem that there isn't an FDT in the bloblist.
> > >
> > > Sure it does. If we're passed a bloblist in a register we can then see
> > > if it has a DT (and use it) or not (and move to the next DT location).
> > >
> > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > changed your mind?
> > >
> > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > problems is that no one understood you.
> >
> > Is there a call tomorrow, or is it next week?
>
> Tomorrow.

OK, do we have somewhere to add things to the agenda? I'd like to
spend some time answering your bloblist questions here.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 8919 bytes --]

On Mon, Apr 07, 2025 at 02:17:46PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 7 Apr 2025 at 12:22, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Apr 07, 2025 at 09:24:16AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > your option.
> > > > > > > > > > > >
> > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > >
> > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > >
> > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > >
> > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > >
> > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > with.
> > > > > > > > > >
> > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > >
> > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > devicetree in the bloblist.
> > > > > > > >
> > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > today.
> > > > > > >
> > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > >
> > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > >
> > > > > We are going around in circles though. Having it is registers doesn't
> > > > > help with the problem that there isn't an FDT in the bloblist.
> > > >
> > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > >
> > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > changed your mind?
> > > >
> > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > problems is that no one understood you.
> > >
> > > Is there a call tomorrow, or is it next week?
> >
> > Tomorrow.
> 
> OK, do we have somewhere to add things to the agenda? I'd like to
> spend some time answering your bloblist questions here.

There's not a written agenda, no. But yes, if you're on, we can talk
there.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Raymond,
> >
> > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Tom and Simon,
> > > > >
> > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Tom and Simon,
> > > > > >
> > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > >
> > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > >
> > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > >
> > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > >
> > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > >
> > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > >
> > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > may be able to test this series on QEMU?
> > > > > > >
> > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > it. That's part of the docs, running the emulator.
> > > > > > >
> > > > > >
> > > > > > I can help to test the firmware handoff on qemu.
> > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > qemu v8 build to test this.
> > > > > > I will try to find some time early next week to review and test this
> > > > > > series before turning back to you.
> > > > > >
> > > > >
> > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > ```
> > > > > No valid device tree binary found at 0000000000000000
> > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > ### ERROR ### Please RESET the board ###
> > > > > ```
> > > > >
> > > > > U-Boot test version:
> > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > >
> > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > >
> > > > I suppose the FDT address in the register is not being read correctly.
> > > >
> > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > lab.
> > > >
> > > > I did create a test back when I did standard passage, but that series
> > > > seems to have not been applied. I'll see if I can resurrect it.
> > > >
> > >
> > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > need my patch [2] for enabling transfer_ist in all components.
> > >
> > > [1] https://github.com/OP-TEE
> > > [2] https://github.com/OP-TEE/build/pull/821
> > >
> >
> > Tom's email seems easier to follow. I got as far as building:
> >
> > build/fvp/release/fip.bin
> >
> > But I'm not sure how to run that in QEMU. The docs mention some sort
> > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > to have.
> >
>
> If you want to test with QEMU v8, just simply:
> $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> $ repo sync
> $ cd build
> Apply my patch https://github.com/OP-TEE/build/pull/821
> In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> 'OF_BLOBLIST=y'
> $ make toolchains
> $ make run

Thanks for the steps. It seemed to complete OK. I also found this:

https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8

But I'm not sure how to actually run it, or even what was actually
built. Do you have the QEMU cmdline I should use to make it start,
please?

Regards,
SImon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Raymond,
>
> On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Tom and Simon,
> > > > > >
> > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Tom and Simon,
> > > > > > >
> > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > >
> > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > >
> > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > >
> > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > >
> > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > >
> > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > >
> > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > may be able to test this series on QEMU?
> > > > > > > >
> > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > >
> > > > > > >
> > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > qemu v8 build to test this.
> > > > > > > I will try to find some time early next week to review and test this
> > > > > > > series before turning back to you.
> > > > > > >
> > > > > >
> > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > ```
> > > > > > No valid device tree binary found at 0000000000000000
> > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > ### ERROR ### Please RESET the board ###
> > > > > > ```
> > > > > >
> > > > > > U-Boot test version:
> > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > >
> > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > >
> > > > > I suppose the FDT address in the register is not being read correctly.
> > > > >
> > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > lab.
> > > > >
> > > > > I did create a test back when I did standard passage, but that series
> > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > >
> > > >
> > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > need my patch [2] for enabling transfer_ist in all components.
> > > >
> > > > [1] https://github.com/OP-TEE
> > > > [2] https://github.com/OP-TEE/build/pull/821
> > > >
> > >
> > > Tom's email seems easier to follow. I got as far as building:
> > >
> > > build/fvp/release/fip.bin
> > >
> > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > to have.
> > >
> >
> > If you want to test with QEMU v8, just simply:
> > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > $ repo sync
> > $ cd build
> > Apply my patch https://github.com/OP-TEE/build/pull/821
> > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > 'OF_BLOBLIST=y'
> > $ make toolchains
> > $ make run
>
> Thanks for the steps. It seemed to complete OK. I also found this:
>
> https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
>
> But I'm not sure how to actually run it, or even what was actually
> built. Do you have the QEMU cmdline I should use to make it start,
> please?
>

Besides the steps I mentioned in the previous reply, you will need to
checkout your U-Boot test branch after "repo sync", since by default
the manifest is pointing to an old release.
"make run" will start the QEMU automatically.
If you are not sure it is built properly or not, you can use "make
all" to build and "make run-only" for running.

Regards,
Raymond


> Regards,
> SImon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > Hi Raymond,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > env variables.
> > > > > > > > > >
> > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > another try at that.
> > > > > > > > > >
> > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > your option.
> > > > > > > > >
> > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > >
> > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > >
> > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > bloblist protocol for x86.
> > > > > > >
> > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > have to live with what I also think are bad designs.
> > > > > > >
> > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > with.
> > > > > > >
> > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > OK. But it shouldn't need to exist long term.
> > > > > >
> > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > devicetree in the bloblist.
> > > > >
> > > > > I don't understand why that would become the case when it's not true
> > > > > today.
> > > >
> > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > special-case code related to TPL, that I'm wanting to get rid of.
> > >
> > > OK, but all of that too is for the case of a fixed bloblist being in
> > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > can allocate a bloblist (or grow a passed one if needed).
> >
> > We are going around in circles though. Having it is registers doesn't
> > help with the problem that there isn't an FDT in the bloblist.
>
> Sure it does. If we're passed a bloblist in a register we can then see
> if it has a DT (and use it) or not (and move to the next DT location).
>
> > Also, I thought you decided that I could maintain bloblist. Have you
> > changed your mind?
>
> You just mis-understood me. Yes, you can maintain bloblist. But also,
> Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> problems is that no one understood you.

No, that's not actually true. The problem is that no one would listen
and everyone was sure I was wrong.

I sent the series on the basis that you were open to my maintaining
bloblist in your tree. I didn't know there were extra conditions. So
please let me know which way you want to go on this.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Raymond,
> >
> > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Raymond,
> > > > > >
> > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Tom and Simon,
> > > > > > >
> > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Tom and Simon,
> > > > > > > >
> > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > >
> > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > >
> > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > >
> > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > >
> > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > >
> > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > >
> > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > >
> > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > qemu v8 build to test this.
> > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > series before turning back to you.
> > > > > > > >
> > > > > > >
> > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > ```
> > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > ```
> > > > > > >
> > > > > > > U-Boot test version:
> > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > >
> > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > >
> > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > >
> > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > lab.
> > > > > >
> > > > > > I did create a test back when I did standard passage, but that series
> > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > >
> > > > >
> > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > >
> > > > > [1] https://github.com/OP-TEE
> > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > >
> > > >
> > > > Tom's email seems easier to follow. I got as far as building:
> > > >
> > > > build/fvp/release/fip.bin
> > > >
> > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > to have.
> > > >
> > >
> > > If you want to test with QEMU v8, just simply:
> > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > $ repo sync
> > > $ cd build
> > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > 'OF_BLOBLIST=y'
> > > $ make toolchains
> > > $ make run
> >
> > Thanks for the steps. It seemed to complete OK. I also found this:
> >
> > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> >
> > But I'm not sure how to actually run it, or even what was actually
> > built. Do you have the QEMU cmdline I should use to make it start,
> > please?
> >
>
> Besides the steps I mentioned in the previous reply, you will need to
> checkout your U-Boot test branch after "repo sync", since by default
> the manifest is pointing to an old release.
> "make run" will start the QEMU automatically.
> If you are not sure it is built properly or not, you can use "make
> all" to build and "make run-only" for running.

Well it turns out that it wasn't really building, but the build
produced so many MB of output that this fact was lost in the noise! It
turned out to be some LD_LIBRARY issue.

My ideal build would look like this:

$ make [-s]
<actionable warnings and errors here>
$

Anyway, now that I have it running, it's a nice environment, thank you. I see:

NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
from_boot_arg 1
regs 0 0 0 0
Bloblist at 0 not found (err=-2)


U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)

DRAM:  1 GiB
Core:  51 devices, 14 uclasses, devicetree: board
...

My code is this:

int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
{
int ret;

printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
      saved_args[1], saved_args[3]);
ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
      saved_args[1], saved_args[3]);
if (ret)
return ret;

*addrp = saved_args[3];
if (fdtp)
*fdtp = saved_args[0];

return 0;
}

on this tree:

37802ca2381 (HEAD) wip
cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
4494e4adae0 bloblist: Provide access to the FDT address
ef7193a9f07 fdt: Introduce OF_BLOBLIST
9e6b2e9c53b bloblist: Simplify bloblist init
4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
https://source.denx.de/u-boot/custodians/u-boot-tegra into next

which I have pushed to:
source.denx.de:u-boot/custodians/u-boot-dm.git

in branch 'blob'

and the build/kconfigs/u-boot_tl.conf file contains:

CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
CONFIG_OF_BLOBLIST=y

I don't expect those registers to all be zero. I suppose I am missing
a config somewhere?

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Mon, 14 Apr 2025 at 15:35, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Raymond,
>
> On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Tom and Simon,
> > > > > > > >
> > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Tom and Simon,
> > > > > > > > >
> > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > >
> > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > >
> > > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > > >
> > > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > > >
> > > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > > >
> > > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > > qemu v8 build to test this.
> > > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > > series before turning back to you.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > > ```
> > > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > > ```
> > > > > > > >
> > > > > > > > U-Boot test version:
> > > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > > >
> > > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > > >
> > > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > > >
> > > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > > lab.
> > > > > > >
> > > > > > > I did create a test back when I did standard passage, but that series
> > > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > > >
> > > > > >
> > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > > >
> > > > > > [1] https://github.com/OP-TEE
> > > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > > >
> > > > >
> > > > > Tom's email seems easier to follow. I got as far as building:
> > > > >
> > > > > build/fvp/release/fip.bin
> > > > >
> > > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > > to have.
> > > > >
> > > >
> > > > If you want to test with QEMU v8, just simply:
> > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > > $ repo sync
> > > > $ cd build
> > > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > > 'OF_BLOBLIST=y'
> > > > $ make toolchains
> > > > $ make run
> > >
> > > Thanks for the steps. It seemed to complete OK. I also found this:
> > >
> > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > >
> > > But I'm not sure how to actually run it, or even what was actually
> > > built. Do you have the QEMU cmdline I should use to make it start,
> > > please?
> > >
> >
> > Besides the steps I mentioned in the previous reply, you will need to
> > checkout your U-Boot test branch after "repo sync", since by default
> > the manifest is pointing to an old release.
> > "make run" will start the QEMU automatically.
> > If you are not sure it is built properly or not, you can use "make
> > all" to build and "make run-only" for running.
>
> Well it turns out that it wasn't really building, but the build
> produced so many MB of output that this fact was lost in the noise! It
> turned out to be some LD_LIBRARY issue.
>
> My ideal build would look like this:
>
> $ make [-s]
> <actionable warnings and errors here>
> $
>
> Anyway, now that I have it running, it's a nice environment, thank you. I see:
>
> NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> from_boot_arg 1
> regs 0 0 0 0
> Bloblist at 0 not found (err=-2)
>
>
> U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)
>
> DRAM:  1 GiB
> Core:  51 devices, 14 uclasses, devicetree: board
> ...
>
> My code is this:
>
> int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
> {
> int ret;
>
> printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
>       saved_args[1], saved_args[3]);
> ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
>       saved_args[1], saved_args[3]);
> if (ret)
> return ret;
>
> *addrp = saved_args[3];
> if (fdtp)
> *fdtp = saved_args[0];
>
> return 0;
> }
>
> on this tree:
>
> 37802ca2381 (HEAD) wip
> cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
> 4494e4adae0 bloblist: Provide access to the FDT address
> ef7193a9f07 fdt: Introduce OF_BLOBLIST
> 9e6b2e9c53b bloblist: Simplify bloblist init
> 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
> https://source.denx.de/u-boot/custodians/u-boot-tegra into next
>
> which I have pushed to:
> source.denx.de:u-boot/custodians/u-boot-dm.git
>
> in branch 'blob'
>
> and the build/kconfigs/u-boot_tl.conf file contains:
>
> CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
> CONFIG_OF_BLOBLIST=y
>
> I don't expect those registers to all be zero. I suppose I am missing
> a config somewhere?
>

If you already got my changes at:
https://github.com/OP-TEE/build/pull/821, and make changes on
u-boot_tl.conf on top of it, the only missing thing might be to change
"ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in
build/qemu_v8.mk.

Raymond


> Regards,
> Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

(trimming cc)

Hi Raymond,

On Mon, 14 Apr 2025 at 13:43, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Mon, 14 Apr 2025 at 15:35, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Raymond,
> >
> > On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Raymond,
> > > > > >
> > > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Raymond,
> > > > > > > >
> > > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Tom and Simon,
> > > > > > > > >
> > > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > >
> > > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > > > >
> > > > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > > > >
> > > > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > > > >
> > > > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > > > qemu v8 build to test this.
> > > > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > > > series before turning back to you.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > > > ```
> > > > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > > > ```
> > > > > > > > >
> > > > > > > > > U-Boot test version:
> > > > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > > > >
> > > > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > > > >
> > > > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > > > >
> > > > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > > > lab.
> > > > > > > >
> > > > > > > > I did create a test back when I did standard passage, but that series
> > > > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > > > >
> > > > > > >
> > > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > > > >
> > > > > > > [1] https://github.com/OP-TEE
> > > > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > > > >
> > > > > >
> > > > > > Tom's email seems easier to follow. I got as far as building:
> > > > > >
> > > > > > build/fvp/release/fip.bin
> > > > > >
> > > > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > > > to have.
> > > > > >
> > > > >
> > > > > If you want to test with QEMU v8, just simply:
> > > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > > > $ repo sync
> > > > > $ cd build
> > > > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > > > 'OF_BLOBLIST=y'
> > > > > $ make toolchains
> > > > > $ make run
> > > >
> > > > Thanks for the steps. It seemed to complete OK. I also found this:
> > > >
> > > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > >
> > > > But I'm not sure how to actually run it, or even what was actually
> > > > built. Do you have the QEMU cmdline I should use to make it start,
> > > > please?
> > > >
> > >
> > > Besides the steps I mentioned in the previous reply, you will need to
> > > checkout your U-Boot test branch after "repo sync", since by default
> > > the manifest is pointing to an old release.
> > > "make run" will start the QEMU automatically.
> > > If you are not sure it is built properly or not, you can use "make
> > > all" to build and "make run-only" for running.
> >
> > Well it turns out that it wasn't really building, but the build
> > produced so many MB of output that this fact was lost in the noise! It
> > turned out to be some LD_LIBRARY issue.
> >
> > My ideal build would look like this:
> >
> > $ make [-s]
> > <actionable warnings and errors here>
> > $
> >
> > Anyway, now that I have it running, it's a nice environment, thank you. I see:
> >
> > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > from_boot_arg 1
> > regs 0 0 0 0
> > Bloblist at 0 not found (err=-2)
> >
> >
> > U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)
> >
> > DRAM:  1 GiB
> > Core:  51 devices, 14 uclasses, devicetree: board
> > ...
> >
> > My code is this:
> >
> > int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
> > {
> > int ret;
> >
> > printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
> >       saved_args[1], saved_args[3]);
> > ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
> >       saved_args[1], saved_args[3]);
> > if (ret)
> > return ret;
> >
> > *addrp = saved_args[3];
> > if (fdtp)
> > *fdtp = saved_args[0];
> >
> > return 0;
> > }
> >
> > on this tree:
> >
> > 37802ca2381 (HEAD) wip
> > cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
> > 4494e4adae0 bloblist: Provide access to the FDT address
> > ef7193a9f07 fdt: Introduce OF_BLOBLIST
> > 9e6b2e9c53b bloblist: Simplify bloblist init
> > 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
> > https://source.denx.de/u-boot/custodians/u-boot-tegra into next
> >
> > which I have pushed to:
> > source.denx.de:u-boot/custodians/u-boot-dm.git
> >
> > in branch 'blob'
> >
> > and the build/kconfigs/u-boot_tl.conf file contains:
> >
> > CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
> > CONFIG_OF_BLOBLIST=y
> >
> > I don't expect those registers to all be zero. I suppose I am missing
> > a config somewhere?
> >
>
> If you already got my changes at:
> https://github.com/OP-TEE/build/pull/821, and make changes on
> u-boot_tl.conf on top of it, the only missing thing might be to change
> "ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in
> build/qemu_v8.mk.

OK thanks. But when I do that:

$ make run -j30 -s
mk/config.mk:520: *** CFG_MAP_EXT_DT_SECURE is set to 'n' (from file)
but its value must be 'y'.  Stop.
make: *** [common.mk:590: optee-os-devkit] Error 2

I can see that value in the same build/qemu_v8.mk file.

OPTEE_OS_COMMON_EXTRA_FLAGS     += CFG_DT=y CFG_MAP_EXT_DT_SECURE=y

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Mon, 14 Apr 2025 at 16:06, Simon Glass <sjg@chromium.org> wrote:
>
> (trimming cc)
>
> Hi Raymond,
>
> On Mon, 14 Apr 2025 at 13:43, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Mon, 14 Apr 2025 at 15:35, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Raymond,
> > > > > > > > >
> > > > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > >
> > > > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > > > > >
> > > > > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > > > > qemu v8 build to test this.
> > > > > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > > > > series before turning back to you.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > > > > ```
> > > > > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > > > > ```
> > > > > > > > > >
> > > > > > > > > > U-Boot test version:
> > > > > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > > > > >
> > > > > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > > > > >
> > > > > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > > > > >
> > > > > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > > > > lab.
> > > > > > > > >
> > > > > > > > > I did create a test back when I did standard passage, but that series
> > > > > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > > > > >
> > > > > > > > [1] https://github.com/OP-TEE
> > > > > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > > > > >
> > > > > > >
> > > > > > > Tom's email seems easier to follow. I got as far as building:
> > > > > > >
> > > > > > > build/fvp/release/fip.bin
> > > > > > >
> > > > > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > > > > to have.
> > > > > > >
> > > > > >
> > > > > > If you want to test with QEMU v8, just simply:
> > > > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > > > > $ repo sync
> > > > > > $ cd build
> > > > > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > > > > 'OF_BLOBLIST=y'
> > > > > > $ make toolchains
> > > > > > $ make run
> > > > >
> > > > > Thanks for the steps. It seemed to complete OK. I also found this:
> > > > >
> > > > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > >
> > > > > But I'm not sure how to actually run it, or even what was actually
> > > > > built. Do you have the QEMU cmdline I should use to make it start,
> > > > > please?
> > > > >
> > > >
> > > > Besides the steps I mentioned in the previous reply, you will need to
> > > > checkout your U-Boot test branch after "repo sync", since by default
> > > > the manifest is pointing to an old release.
> > > > "make run" will start the QEMU automatically.
> > > > If you are not sure it is built properly or not, you can use "make
> > > > all" to build and "make run-only" for running.
> > >
> > > Well it turns out that it wasn't really building, but the build
> > > produced so many MB of output that this fact was lost in the noise! It
> > > turned out to be some LD_LIBRARY issue.
> > >
> > > My ideal build would look like this:
> > >
> > > $ make [-s]
> > > <actionable warnings and errors here>
> > > $
> > >
> > > Anyway, now that I have it running, it's a nice environment, thank you. I see:
> > >
> > > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > > from_boot_arg 1
> > > regs 0 0 0 0
> > > Bloblist at 0 not found (err=-2)
> > >
> > >
> > > U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)
> > >
> > > DRAM:  1 GiB
> > > Core:  51 devices, 14 uclasses, devicetree: board
> > > ...
> > >
> > > My code is this:
> > >
> > > int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
> > > {
> > > int ret;
> > >
> > > printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
> > >       saved_args[1], saved_args[3]);
> > > ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
> > >       saved_args[1], saved_args[3]);
> > > if (ret)
> > > return ret;
> > >
> > > *addrp = saved_args[3];
> > > if (fdtp)
> > > *fdtp = saved_args[0];
> > >
> > > return 0;
> > > }
> > >
> > > on this tree:
> > >
> > > 37802ca2381 (HEAD) wip
> > > cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
> > > 4494e4adae0 bloblist: Provide access to the FDT address
> > > ef7193a9f07 fdt: Introduce OF_BLOBLIST
> > > 9e6b2e9c53b bloblist: Simplify bloblist init
> > > 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
> > > https://source.denx.de/u-boot/custodians/u-boot-tegra into next
> > >
> > > which I have pushed to:
> > > source.denx.de:u-boot/custodians/u-boot-dm.git
> > >
> > > in branch 'blob'
> > >
> > > and the build/kconfigs/u-boot_tl.conf file contains:
> > >
> > > CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
> > > CONFIG_OF_BLOBLIST=y
> > >
> > > I don't expect those registers to all be zero. I suppose I am missing
> > > a config somewhere?
> > >
> >
> > If you already got my changes at:
> > https://github.com/OP-TEE/build/pull/821, and make changes on
> > u-boot_tl.conf on top of it, the only missing thing might be to change
> > "ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in
> > build/qemu_v8.mk.
>
> OK thanks. But when I do that:
>
> $ make run -j30 -s
> mk/config.mk:520: *** CFG_MAP_EXT_DT_SECURE is set to 'n' (from file)
> but its value must be 'y'.  Stop.
> make: *** [common.mk:590: optee-os-devkit] Error 2
>
> I can see that value in the same build/qemu_v8.mk file.
>
> OPTEE_OS_COMMON_EXTRA_FLAGS     += CFG_DT=y CFG_MAP_EXT_DT_SECURE=y
>

One dependence is at here:
https://github.com/OP-TEE/optee_os/pull/7352/files#diff-6301a2703b709daa4d84ead1c30bf67cdaf088abed68753a8f9c740f1e58b54a

Raymond


> Regards,
> Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 9195 bytes --]

On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > Hi Raymond,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > env variables.
> > > > > > > > > > >
> > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > another try at that.
> > > > > > > > > > >
> > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > your option.
> > > > > > > > > >
> > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > >
> > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > >
> > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > bloblist protocol for x86.
> > > > > > > >
> > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > have to live with what I also think are bad designs.
> > > > > > > >
> > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > with.
> > > > > > > >
> > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > >
> > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > devicetree in the bloblist.
> > > > > >
> > > > > > I don't understand why that would become the case when it's not true
> > > > > > today.
> > > > >
> > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > >
> > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > can allocate a bloblist (or grow a passed one if needed).
> > >
> > > We are going around in circles though. Having it is registers doesn't
> > > help with the problem that there isn't an FDT in the bloblist.
> >
> > Sure it does. If we're passed a bloblist in a register we can then see
> > if it has a DT (and use it) or not (and move to the next DT location).
> >
> > > Also, I thought you decided that I could maintain bloblist. Have you
> > > changed your mind?
> >
> > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > problems is that no one understood you.
> 
> No, that's not actually true. The problem is that no one would listen
> and everyone was sure I was wrong.

That's another way of saying "no one understood you", IMO.

> I sent the series on the basis that you were open to my maintaining
> bloblist in your tree. I didn't know there were extra conditions. So
> please let me know which way you want to go on this.

I thought we had made progress on the community call, but now you're
sending this so I don't know?

You need to:
- Not break handoff spec. Raymond is telling you how to get a QEMU that
  uses that now, and I'm actively waiting on Harrison Mutai to answer
  one last question I had before adding vexpress_fvp to our CI. So this
  should be a reasonable requirement.
- You were going to add register passing of bloblist location for x86,
  and then add register passing of bloblist between U-Boot phases
  without relying on BLOBLIST_FiXED.
- Some amount of un-tangling "do we have a bloblist" from "did we get a
  bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
  in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
  a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
  the logic at the top of lib/fdtdec.c::fdtdec_setup() too.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Mon, 14 Apr 2025 at 14:16, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Mon, 14 Apr 2025 at 16:06, Simon Glass <sjg@chromium.org> wrote:
> >
> > (trimming cc)
> >
> > Hi Raymond,
> >
> > On Mon, 14 Apr 2025 at 13:43, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, 14 Apr 2025 at 15:35, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Raymond,
> > > > > >
> > > > > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Raymond,
> > > > > > > >
> > > > > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Raymond,
> > > > > > > > > >
> > > > > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > > > > > qemu v8 build to test this.
> > > > > > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > > > > > series before turning back to you.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > > > > > ```
> > > > > > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > > > > > ```
> > > > > > > > > > >
> > > > > > > > > > > U-Boot test version:
> > > > > > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > > > > > >
> > > > > > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > > > > > >
> > > > > > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > > > > > >
> > > > > > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > > > > > lab.
> > > > > > > > > >
> > > > > > > > > > I did create a test back when I did standard passage, but that series
> > > > > > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > > > > > >
> > > > > > > > > [1] https://github.com/OP-TEE
> > > > > > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > > > > > >
> > > > > > > >
> > > > > > > > Tom's email seems easier to follow. I got as far as building:
> > > > > > > >
> > > > > > > > build/fvp/release/fip.bin
> > > > > > > >
> > > > > > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > > > > > to have.
> > > > > > > >
> > > > > > >
> > > > > > > If you want to test with QEMU v8, just simply:
> > > > > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > > > > > $ repo sync
> > > > > > > $ cd build
> > > > > > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > > > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > > > > > 'OF_BLOBLIST=y'
> > > > > > > $ make toolchains
> > > > > > > $ make run
> > > > > >
> > > > > > Thanks for the steps. It seemed to complete OK. I also found this:
> > > > > >
> > > > > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > >
> > > > > > But I'm not sure how to actually run it, or even what was actually
> > > > > > built. Do you have the QEMU cmdline I should use to make it start,
> > > > > > please?
> > > > > >
> > > > >
> > > > > Besides the steps I mentioned in the previous reply, you will need to
> > > > > checkout your U-Boot test branch after "repo sync", since by default
> > > > > the manifest is pointing to an old release.
> > > > > "make run" will start the QEMU automatically.
> > > > > If you are not sure it is built properly or not, you can use "make
> > > > > all" to build and "make run-only" for running.
> > > >
> > > > Well it turns out that it wasn't really building, but the build
> > > > produced so many MB of output that this fact was lost in the noise! It
> > > > turned out to be some LD_LIBRARY issue.
> > > >
> > > > My ideal build would look like this:
> > > >
> > > > $ make [-s]
> > > > <actionable warnings and errors here>
> > > > $
> > > >
> > > > Anyway, now that I have it running, it's a nice environment, thank you. I see:
> > > >
> > > > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > > > from_boot_arg 1
> > > > regs 0 0 0 0
> > > > Bloblist at 0 not found (err=-2)
> > > >
> > > >
> > > > U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)
> > > >
> > > > DRAM:  1 GiB
> > > > Core:  51 devices, 14 uclasses, devicetree: board
> > > > ...
> > > >
> > > > My code is this:
> > > >
> > > > int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
> > > > {
> > > > int ret;
> > > >
> > > > printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
> > > >       saved_args[1], saved_args[3]);
> > > > ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
> > > >       saved_args[1], saved_args[3]);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > *addrp = saved_args[3];
> > > > if (fdtp)
> > > > *fdtp = saved_args[0];
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > on this tree:
> > > >
> > > > 37802ca2381 (HEAD) wip
> > > > cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
> > > > 4494e4adae0 bloblist: Provide access to the FDT address
> > > > ef7193a9f07 fdt: Introduce OF_BLOBLIST
> > > > 9e6b2e9c53b bloblist: Simplify bloblist init
> > > > 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
> > > > https://source.denx.de/u-boot/custodians/u-boot-tegra into next
> > > >
> > > > which I have pushed to:
> > > > source.denx.de:u-boot/custodians/u-boot-dm.git
> > > >
> > > > in branch 'blob'
> > > >
> > > > and the build/kconfigs/u-boot_tl.conf file contains:
> > > >
> > > > CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
> > > > CONFIG_OF_BLOBLIST=y
> > > >
> > > > I don't expect those registers to all be zero. I suppose I am missing
> > > > a config somewhere?
> > > >
> > >
> > > If you already got my changes at:
> > > https://github.com/OP-TEE/build/pull/821, and make changes on
> > > u-boot_tl.conf on top of it, the only missing thing might be to change
> > > "ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in
> > > build/qemu_v8.mk.
> >
> > OK thanks. But when I do that:
> >
> > $ make run -j30 -s
> > mk/config.mk:520: *** CFG_MAP_EXT_DT_SECURE is set to 'n' (from file)
> > but its value must be 'y'.  Stop.
> > make: *** [common.mk:590: optee-os-devkit] Error 2
> >
> > I can see that value in the same build/qemu_v8.mk file.
> >
> > OPTEE_OS_COMMON_EXTRA_FLAGS     += CFG_DT=y CFG_MAP_EXT_DT_SECURE=y
> >
>
> One dependence is at here:
> https://github.com/OP-TEE/optee_os/pull/7352/files#diff-6301a2703b709daa4d84ead1c30bf67cdaf088abed68753a8f9c740f1e58b54a

Thanks, I changed it to n but I still don't see anything in the registers:

NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
from_boot_arg 1
regs 0 0 0 0
Bloblist at 0 not found (err=-2)


U-Boot 2025.04-rc5-00663-g37802ca2381a (Apr 14 2025 - 14:37:38 -0600)

I think I need to rebuild BL31. So I'm doing 'make clean' and we'll see.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi again Raymond,

On Mon, 14 Apr 2025 at 14:41, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Raymond,
>
> On Mon, 14 Apr 2025 at 14:16, Raymond Mao <raymond.mao@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Mon, 14 Apr 2025 at 16:06, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > (trimming cc)
> > >
> > > Hi Raymond,
> > >
> > > On Mon, 14 Apr 2025 at 13:43, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Mon, 14 Apr 2025 at 15:35, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Raymond,
> > > > > > > > >
> > > > > > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Raymond,
> > > > > > > > > > >
> > > > > > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > > > > > > qemu v8 build to test this.
> > > > > > > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > > > > > > series before turning back to you.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > > > > > > ```
> > > > > > > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > > > > > > ```
> > > > > > > > > > > >
> > > > > > > > > > > > U-Boot test version:
> > > > > > > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > > > > > > >
> > > > > > > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > > > > > > >
> > > > > > > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > > > > > > >
> > > > > > > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > > > > > > lab.
> > > > > > > > > > >
> > > > > > > > > > > I did create a test back when I did standard passage, but that series
> > > > > > > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > > > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > > > > > > >
> > > > > > > > > > [1] https://github.com/OP-TEE
> > > > > > > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Tom's email seems easier to follow. I got as far as building:
> > > > > > > > >
> > > > > > > > > build/fvp/release/fip.bin
> > > > > > > > >
> > > > > > > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > > > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > > > > > > to have.
> > > > > > > > >
> > > > > > > >
> > > > > > > > If you want to test with QEMU v8, just simply:
> > > > > > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > > > > > > $ repo sync
> > > > > > > > $ cd build
> > > > > > > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > > > > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > > > > > > 'OF_BLOBLIST=y'
> > > > > > > > $ make toolchains
> > > > > > > > $ make run
> > > > > > >
> > > > > > > Thanks for the steps. It seemed to complete OK. I also found this:
> > > > > > >
> > > > > > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > > >
> > > > > > > But I'm not sure how to actually run it, or even what was actually
> > > > > > > built. Do you have the QEMU cmdline I should use to make it start,
> > > > > > > please?
> > > > > > >
> > > > > >
> > > > > > Besides the steps I mentioned in the previous reply, you will need to
> > > > > > checkout your U-Boot test branch after "repo sync", since by default
> > > > > > the manifest is pointing to an old release.
> > > > > > "make run" will start the QEMU automatically.
> > > > > > If you are not sure it is built properly or not, you can use "make
> > > > > > all" to build and "make run-only" for running.
> > > > >
> > > > > Well it turns out that it wasn't really building, but the build
> > > > > produced so many MB of output that this fact was lost in the noise! It
> > > > > turned out to be some LD_LIBRARY issue.
> > > > >
> > > > > My ideal build would look like this:
> > > > >
> > > > > $ make [-s]
> > > > > <actionable warnings and errors here>
> > > > > $
> > > > >
> > > > > Anyway, now that I have it running, it's a nice environment, thank you. I see:
> > > > >
> > > > > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > > > > from_boot_arg 1
> > > > > regs 0 0 0 0
> > > > > Bloblist at 0 not found (err=-2)
> > > > >
> > > > >
> > > > > U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)
> > > > >
> > > > > DRAM:  1 GiB
> > > > > Core:  51 devices, 14 uclasses, devicetree: board
> > > > > ...
> > > > >
> > > > > My code is this:
> > > > >
> > > > > int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
> > > > > {
> > > > > int ret;
> > > > >
> > > > > printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
> > > > >       saved_args[1], saved_args[3]);
> > > > > ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
> > > > >       saved_args[1], saved_args[3]);
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > *addrp = saved_args[3];
> > > > > if (fdtp)
> > > > > *fdtp = saved_args[0];
> > > > >
> > > > > return 0;
> > > > > }
> > > > >
> > > > > on this tree:
> > > > >
> > > > > 37802ca2381 (HEAD) wip
> > > > > cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
> > > > > 4494e4adae0 bloblist: Provide access to the FDT address
> > > > > ef7193a9f07 fdt: Introduce OF_BLOBLIST
> > > > > 9e6b2e9c53b bloblist: Simplify bloblist init
> > > > > 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
> > > > > https://source.denx.de/u-boot/custodians/u-boot-tegra into next
> > > > >
> > > > > which I have pushed to:
> > > > > source.denx.de:u-boot/custodians/u-boot-dm.git
> > > > >
> > > > > in branch 'blob'
> > > > >
> > > > > and the build/kconfigs/u-boot_tl.conf file contains:
> > > > >
> > > > > CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
> > > > > CONFIG_OF_BLOBLIST=y
> > > > >
> > > > > I don't expect those registers to all be zero. I suppose I am missing
> > > > > a config somewhere?
> > > > >
> > > >
> > > > If you already got my changes at:
> > > > https://github.com/OP-TEE/build/pull/821, and make changes on
> > > > u-boot_tl.conf on top of it, the only missing thing might be to change
> > > > "ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in
> > > > build/qemu_v8.mk.
> > >
> > > OK thanks. But when I do that:
> > >
> > > $ make run -j30 -s
> > > mk/config.mk:520: *** CFG_MAP_EXT_DT_SECURE is set to 'n' (from file)
> > > but its value must be 'y'.  Stop.
> > > make: *** [common.mk:590: optee-os-devkit] Error 2
> > >
> > > I can see that value in the same build/qemu_v8.mk file.
> > >
> > > OPTEE_OS_COMMON_EXTRA_FLAGS     += CFG_DT=y CFG_MAP_EXT_DT_SECURE=y
> > >
> >
> > One dependence is at here:
> > https://github.com/OP-TEE/optee_os/pull/7352/files#diff-6301a2703b709daa4d84ead1c30bf67cdaf088abed68753a8f9c740f1e58b54a
>
> Thanks, I changed it to n but I still don't see anything in the registers:
>
> NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> from_boot_arg 1
> regs 0 0 0 0
> Bloblist at 0 not found (err=-2)
>
>
> U-Boot 2025.04-rc5-00663-g37802ca2381a (Apr 14 2025 - 14:37:38 -0600)
>
> I think I need to rebuild BL31. So I'm doing 'make clean' and we'll see.

OK that fixed it. So I'll be able to take a look one of these
mornings. Thanks for your help. Please get this into CI soon.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Raymond Mao]

Hi Simon,

On Mon, 14 Apr 2025 at 16:47, Simon Glass <sjg@chromium.org> wrote:
>
> Hi again Raymond,
>
> On Mon, 14 Apr 2025 at 14:41, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Raymond,
> >
> > On Mon, 14 Apr 2025 at 14:16, Raymond Mao <raymond.mao@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, 14 Apr 2025 at 16:06, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > (trimming cc)
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Mon, 14 Apr 2025 at 13:43, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Mon, 14 Apr 2025 at 15:35, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Raymond,
> > > > > >
> > > > > > On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Raymond,
> > > > > > > >
> > > > > > > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Raymond,
> > > > > > > > > >
> > > > > > > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > > > > > > > qemu v8 build to test this.
> > > > > > > > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > > > > > > > series before turning back to you.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > > > > > > > ```
> > > > > > > > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > > > > > > > ```
> > > > > > > > > > > > >
> > > > > > > > > > > > > U-Boot test version:
> > > > > > > > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > > > > > > > >
> > > > > > > > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > > > > > > > >
> > > > > > > > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > > > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > > > > > > > lab.
> > > > > > > > > > > >
> > > > > > > > > > > > I did create a test back when I did standard passage, but that series
> > > > > > > > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > > > > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > > > > > > > >
> > > > > > > > > > > [1] https://github.com/OP-TEE
> > > > > > > > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Tom's email seems easier to follow. I got as far as building:
> > > > > > > > > >
> > > > > > > > > > build/fvp/release/fip.bin
> > > > > > > > > >
> > > > > > > > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > > > > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > > > > > > > to have.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > If you want to test with QEMU v8, just simply:
> > > > > > > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > > > > > > > $ repo sync
> > > > > > > > > $ cd build
> > > > > > > > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > > > > > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > > > > > > > 'OF_BLOBLIST=y'
> > > > > > > > > $ make toolchains
> > > > > > > > > $ make run
> > > > > > > >
> > > > > > > > Thanks for the steps. It seemed to complete OK. I also found this:
> > > > > > > >
> > > > > > > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > > > >
> > > > > > > > But I'm not sure how to actually run it, or even what was actually
> > > > > > > > built. Do you have the QEMU cmdline I should use to make it start,
> > > > > > > > please?
> > > > > > > >
> > > > > > >
> > > > > > > Besides the steps I mentioned in the previous reply, you will need to
> > > > > > > checkout your U-Boot test branch after "repo sync", since by default
> > > > > > > the manifest is pointing to an old release.
> > > > > > > "make run" will start the QEMU automatically.
> > > > > > > If you are not sure it is built properly or not, you can use "make
> > > > > > > all" to build and "make run-only" for running.
> > > > > >
> > > > > > Well it turns out that it wasn't really building, but the build
> > > > > > produced so many MB of output that this fact was lost in the noise! It
> > > > > > turned out to be some LD_LIBRARY issue.
> > > > > >
> > > > > > My ideal build would look like this:
> > > > > >
> > > > > > $ make [-s]
> > > > > > <actionable warnings and errors here>
> > > > > > $
> > > > > >
> > > > > > Anyway, now that I have it running, it's a nice environment, thank you. I see:
> > > > > >
> > > > > > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > > > > > from_boot_arg 1
> > > > > > regs 0 0 0 0
> > > > > > Bloblist at 0 not found (err=-2)
> > > > > >
> > > > > >
> > > > > > U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)
> > > > > >
> > > > > > DRAM:  1 GiB
> > > > > > Core:  51 devices, 14 uclasses, devicetree: board
> > > > > > ...
> > > > > >
> > > > > > My code is this:
> > > > > >
> > > > > > int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
> > > > > > {
> > > > > > int ret;
> > > > > >
> > > > > > printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
> > > > > >       saved_args[1], saved_args[3]);
> > > > > > ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
> > > > > >       saved_args[1], saved_args[3]);
> > > > > > if (ret)
> > > > > > return ret;
> > > > > >
> > > > > > *addrp = saved_args[3];
> > > > > > if (fdtp)
> > > > > > *fdtp = saved_args[0];
> > > > > >
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > on this tree:
> > > > > >
> > > > > > 37802ca2381 (HEAD) wip
> > > > > > cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
> > > > > > 4494e4adae0 bloblist: Provide access to the FDT address
> > > > > > ef7193a9f07 fdt: Introduce OF_BLOBLIST
> > > > > > 9e6b2e9c53b bloblist: Simplify bloblist init
> > > > > > 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-tegra into next
> > > > > >
> > > > > > which I have pushed to:
> > > > > > source.denx.de:u-boot/custodians/u-boot-dm.git
> > > > > >
> > > > > > in branch 'blob'
> > > > > >
> > > > > > and the build/kconfigs/u-boot_tl.conf file contains:
> > > > > >
> > > > > > CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
> > > > > > CONFIG_OF_BLOBLIST=y
> > > > > >
> > > > > > I don't expect those registers to all be zero. I suppose I am missing
> > > > > > a config somewhere?
> > > > > >
> > > > >
> > > > > If you already got my changes at:
> > > > > https://github.com/OP-TEE/build/pull/821, and make changes on
> > > > > u-boot_tl.conf on top of it, the only missing thing might be to change
> > > > > "ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in
> > > > > build/qemu_v8.mk.
> > > >
> > > > OK thanks. But when I do that:
> > > >
> > > > $ make run -j30 -s
> > > > mk/config.mk:520: *** CFG_MAP_EXT_DT_SECURE is set to 'n' (from file)
> > > > but its value must be 'y'.  Stop.
> > > > make: *** [common.mk:590: optee-os-devkit] Error 2
> > > >
> > > > I can see that value in the same build/qemu_v8.mk file.
> > > >
> > > > OPTEE_OS_COMMON_EXTRA_FLAGS     += CFG_DT=y CFG_MAP_EXT_DT_SECURE=y
> > > >
> > >
> > > One dependence is at here:
> > > https://github.com/OP-TEE/optee_os/pull/7352/files#diff-6301a2703b709daa4d84ead1c30bf67cdaf088abed68753a8f9c740f1e58b54a
> >
> > Thanks, I changed it to n but I still don't see anything in the registers:
> >
> > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > from_boot_arg 1
> > regs 0 0 0 0
> > Bloblist at 0 not found (err=-2)
> >
> >
> > U-Boot 2025.04-rc5-00663-g37802ca2381a (Apr 14 2025 - 14:37:38 -0600)
> >
> > I think I need to rebuild BL31. So I'm doing 'make clean' and we'll see.
>
> OK that fixed it. So I'll be able to take a look one of these
> mornings. Thanks for your help. Please get this into CI soon.
>

No worries, please take your time and feel free to let me know if
there are any questions.

Raymond

> Regards,
> Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Raymond,

On Mon, 14 Apr 2025 at 18:33, Raymond Mao <raymond.mao@linaro.org> wrote:
>
> Hi Simon,
>
> On Mon, 14 Apr 2025 at 16:47, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi again Raymond,
> >
> > On Mon, 14 Apr 2025 at 14:41, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Raymond,
> > >
> > > On Mon, 14 Apr 2025 at 14:16, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Mon, 14 Apr 2025 at 16:06, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > (trimming cc)
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Mon, 14 Apr 2025 at 13:43, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Mon, 14 Apr 2025 at 15:35, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Mon, 14 Apr 2025 at 07:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Sun, 13 Apr 2025 at 17:13, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Raymond,
> > > > > > > > >
> > > > > > > > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Raymond,
> > > > > > > > > > >
> > > > > > > > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Tom and Simon,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, Simon Glass wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > It is to be hoped that we can get a platform which uses OF_BLOBLIST into
> > > > > > > > > > > > > > > > > > > CI at some point. In the meantime, the standard passage series[1] could
> > > > > > > > > > > > > > > > > > > be resurrected to give some coverage.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=*
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Based on how it's documented to be run in
> > > > > > > > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next branch, have you confirmed
> > > > > > > > > > > > > > > > > > that platforms using the handoff spec still work?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I believe so, yes. I don't have that board to test it though. Raymond
> > > > > > > > > > > > > > > > > may be able to test this series on QEMU?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I was pointing you at the docs so that you would have access to testing
> > > > > > > > > > > > > > > > it. That's part of the docs, running the emulator.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I can help to test the firmware handoff on qemu.
> > > > > > > > > > > > > > > I have all the necessary changes and unit tests for the OP-TEE repo
> > > > > > > > > > > > > > > qemu v8 build to test this.
> > > > > > > > > > > > > > > I will try to find some time early next week to review and test this
> > > > > > > > > > > > > > > series before turning back to you.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Just a follow-up on the testing with TF-A and OP-TEE.
> > > > > > > > > > > > > > Unfortunately, the patch series breaks the transfer list handoff to
> > > > > > > > > > > > > > U-Boot completely and just end up with below error when U-Boot boots:
> > > > > > > > > > > > > > ```
> > > > > > > > > > > > > > No valid device tree binary found at 0000000000000000
> > > > > > > > > > > > > > initcall failed at call 0000000060097bcc (err=-2)
> > > > > > > > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > > > > > > > > ```
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > U-Boot test version:
> > > > > > > > > > > > > > 'next' branch + this series + my patch [1] to point fdt_addr to gd->fdt_blob.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]: https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond.mao@linaro.org/
> > > > > > > > > > > > >
> > > > > > > > > > > > > I suppose the FDT address in the register is not being read correctly.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Do you have a test case for this, e.g. in QEMU? Even if it is just
> > > > > > > > > > > > > binary blobs for now, not suitable for CI, I'd like to get it in my
> > > > > > > > > > > > > lab.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I did create a test back when I did standard passage, but that series
> > > > > > > > > > > > > seems to have not been applied. I'll see if I can resurrect it.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. You will also
> > > > > > > > > > > > need my patch [2] for enabling transfer_ist in all components.
> > > > > > > > > > > >
> > > > > > > > > > > > [1] https://github.com/OP-TEE
> > > > > > > > > > > > [2] https://github.com/OP-TEE/build/pull/821
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Tom's email seems easier to follow. I got as far as building:
> > > > > > > > > > >
> > > > > > > > > > > build/fvp/release/fip.bin
> > > > > > > > > > >
> > > > > > > > > > > But I'm not sure how to run that in QEMU. The docs mention some sort
> > > > > > > > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I don't seem
> > > > > > > > > > > to have.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > If you want to test with QEMU v8, just simply:
> > > > > > > > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> > > > > > > > > > $ repo sync
> > > > > > > > > > $ cd build
> > > > > > > > > > Apply my patch https://github.com/OP-TEE/build/pull/821
> > > > > > > > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' and add
> > > > > > > > > > 'OF_BLOBLIST=y'
> > > > > > > > > > $ make toolchains
> > > > > > > > > > $ make run
> > > > > > > > >
> > > > > > > > > Thanks for the steps. It seemed to complete OK. I also found this:
> > > > > > > > >
> > > > > > > > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > > > > >
> > > > > > > > > But I'm not sure how to actually run it, or even what was actually
> > > > > > > > > built. Do you have the QEMU cmdline I should use to make it start,
> > > > > > > > > please?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Besides the steps I mentioned in the previous reply, you will need to
> > > > > > > > checkout your U-Boot test branch after "repo sync", since by default
> > > > > > > > the manifest is pointing to an old release.
> > > > > > > > "make run" will start the QEMU automatically.
> > > > > > > > If you are not sure it is built properly or not, you can use "make
> > > > > > > > all" to build and "make run-only" for running.
> > > > > > >
> > > > > > > Well it turns out that it wasn't really building, but the build
> > > > > > > produced so many MB of output that this fact was lost in the noise! It
> > > > > > > turned out to be some LD_LIBRARY issue.
> > > > > > >
> > > > > > > My ideal build would look like this:
> > > > > > >
> > > > > > > $ make [-s]
> > > > > > > <actionable warnings and errors here>
> > > > > > > $
> > > > > > >
> > > > > > > Anyway, now that I have it running, it's a nice environment, thank you. I see:
> > > > > > >
> > > > > > > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > > > > > > from_boot_arg 1
> > > > > > > regs 0 0 0 0
> > > > > > > Bloblist at 0 not found (err=-2)
> > > > > > >
> > > > > > >
> > > > > > > U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - 13:25:06 -0600)
> > > > > > >
> > > > > > > DRAM:  1 GiB
> > > > > > > Core:  51 devices, 14 uclasses, devicetree: board
> > > > > > > ...
> > > > > > >
> > > > > > > My code is this:
> > > > > > >
> > > > > > > int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp)
> > > > > > > {
> > > > > > > int ret;
> > > > > > >
> > > > > > > printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2],
> > > > > > >       saved_args[1], saved_args[3]);
> > > > > > > ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
> > > > > > >       saved_args[1], saved_args[3]);
> > > > > > > if (ret)
> > > > > > > return ret;
> > > > > > >
> > > > > > > *addrp = saved_args[3];
> > > > > > > if (fdtp)
> > > > > > > *fdtp = saved_args[0];
> > > > > > >
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > on this tree:
> > > > > > >
> > > > > > > 37802ca2381 (HEAD) wip
> > > > > > > cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without parsing it
> > > > > > > 4494e4adae0 bloblist: Provide access to the FDT address
> > > > > > > ef7193a9f07 fdt: Introduce OF_BLOBLIST
> > > > > > > 9e6b2e9c53b bloblist: Simplify bloblist init
> > > > > > > 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of
> > > > > > > https://source.denx.de/u-boot/custodians/u-boot-tegra into next
> > > > > > >
> > > > > > > which I have pushed to:
> > > > > > > source.denx.de:u-boot/custodians/u-boot-dm.git
> > > > > > >
> > > > > > > in branch 'blob'
> > > > > > >
> > > > > > > and the build/kconfigs/u-boot_tl.conf file contains:
> > > > > > >
> > > > > > > CONFIG_BLOBLIST_PASSAGE_MANDATORY=y
> > > > > > > CONFIG_OF_BLOBLIST=y
> > > > > > >
> > > > > > > I don't expect those registers to all be zero. I suppose I am missing
> > > > > > > a config somewhere?
> > > > > > >
> > > > > >
> > > > > > If you already got my changes at:
> > > > > > https://github.com/OP-TEE/build/pull/821, and make changes on
> > > > > > u-boot_tl.conf on top of it, the only missing thing might be to change
> > > > > > "ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in
> > > > > > build/qemu_v8.mk.
> > > > >
> > > > > OK thanks. But when I do that:
> > > > >
> > > > > $ make run -j30 -s
> > > > > mk/config.mk:520: *** CFG_MAP_EXT_DT_SECURE is set to 'n' (from file)
> > > > > but its value must be 'y'.  Stop.
> > > > > make: *** [common.mk:590: optee-os-devkit] Error 2
> > > > >
> > > > > I can see that value in the same build/qemu_v8.mk file.
> > > > >
> > > > > OPTEE_OS_COMMON_EXTRA_FLAGS     += CFG_DT=y CFG_MAP_EXT_DT_SECURE=y
> > > > >
> > > >
> > > > One dependence is at here:
> > > > https://github.com/OP-TEE/optee_os/pull/7352/files#diff-6301a2703b709daa4d84ead1c30bf67cdaf088abed68753a8f9c740f1e58b54a
> > >
> > > Thanks, I changed it to n but I still don't see anything in the registers:
> > >
> > > NOTICE:  BL31: Built : 15:06:52, Apr 13 2025
> > > from_boot_arg 1
> > > regs 0 0 0 0
> > > Bloblist at 0 not found (err=-2)
> > >
> > >
> > > U-Boot 2025.04-rc5-00663-g37802ca2381a (Apr 14 2025 - 14:37:38 -0600)
> > >
> > > I think I need to rebuild BL31. So I'm doing 'make clean' and we'll see.
> >
> > OK that fixed it. So I'll be able to take a look one of these
> > mornings. Thanks for your help. Please get this into CI soon.
> >
>
> No worries, please take your time and feel free to let me know if
> there are any questions.

Unfortunately I've broken it again and I'm not sure what is going on.
I have burned quite a bit of time on this, unfortunately.

Really we need a proper test (within U-Boot) for this. I will send a
series which works for that. Once I've sent it, perhaps if you can
push a clean tree somewhere with all the optee stuff? Then we should
be able to figure out what is wrong.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > env variables.
> > > > > > > > > > > >
> > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > another try at that.
> > > > > > > > > > > >
> > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > your option.
> > > > > > > > > > >
> > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > >
> > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > >
> > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > bloblist protocol for x86.
> > > > > > > > >
> > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > >
> > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > with.
> > > > > > > > >
> > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > >
> > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > devicetree in the bloblist.
> > > > > > >
> > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > today.
> > > > > >
> > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > >
> > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > can allocate a bloblist (or grow a passed one if needed).
> > > >
> > > > We are going around in circles though. Having it is registers doesn't
> > > > help with the problem that there isn't an FDT in the bloblist.
> > >
> > > Sure it does. If we're passed a bloblist in a register we can then see
> > > if it has a DT (and use it) or not (and move to the next DT location).
> > >
> > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > changed your mind?
> > >
> > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > problems is that no one understood you.
> >
> > No, that's not actually true. The problem is that no one would listen
> > and everyone was sure I was wrong.
>
> That's another way of saying "no one understood you", IMO.
>
> > I sent the series on the basis that you were open to my maintaining
> > bloblist in your tree. I didn't know there were extra conditions. So
> > please let me know which way you want to go on this.
>
> I thought we had made progress on the community call, but now you're
> sending this so I don't know?
>
> You need to:
> - Not break handoff spec. Raymond is telling you how to get a QEMU that
>   uses that now, and I'm actively waiting on Harrison Mutai to answer
>   one last question I had before adding vexpress_fvp to our CI. So this
>   should be a reasonable requirement.
> - You were going to add register passing of bloblist location for x86,
>   and then add register passing of bloblist between U-Boot phases
>   without relying on BLOBLIST_FiXED.
> - Some amount of un-tangling "do we have a bloblist" from "did we get a
>   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
>   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
>   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
>   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.

That seems very much like a list of instructions. So in fact you still
want to be the maintainer?

To be clear, I don't disagree with the list here but I am not willing
to argue with people anymore about how it should work. I designed it
and I know how it should work.

Also I think I now understand what you are saying about bloblist and
standard passage being split. It's because most of my standard passage
series from a few years back was never applied.

So I'd like to go back and revisit that and get it applied, including
the gitlab test for the new qemu_arm/64_spl

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 10955 bytes --]

On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > your option.
> > > > > > > > > > > >
> > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > >
> > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > >
> > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > >
> > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > >
> > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > with.
> > > > > > > > > >
> > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > >
> > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > devicetree in the bloblist.
> > > > > > > >
> > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > today.
> > > > > > >
> > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > >
> > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > >
> > > > > We are going around in circles though. Having it is registers doesn't
> > > > > help with the problem that there isn't an FDT in the bloblist.
> > > >
> > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > >
> > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > changed your mind?
> > > >
> > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > problems is that no one understood you.
> > >
> > > No, that's not actually true. The problem is that no one would listen
> > > and everyone was sure I was wrong.
> >
> > That's another way of saying "no one understood you", IMO.
> >
> > > I sent the series on the basis that you were open to my maintaining
> > > bloblist in your tree. I didn't know there were extra conditions. So
> > > please let me know which way you want to go on this.
> >
> > I thought we had made progress on the community call, but now you're
> > sending this so I don't know?
> >
> > You need to:
> > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> >   one last question I had before adding vexpress_fvp to our CI. So this
> >   should be a reasonable requirement.
> > - You were going to add register passing of bloblist location for x86,
> >   and then add register passing of bloblist between U-Boot phases
> >   without relying on BLOBLIST_FiXED.
> > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> 
> That seems very much like a list of instructions. So in fact you still
> want to be the maintainer?

I mean, I'm the project maintainer. No, I'm not going to sit over your
shoulder and tell you how to do that. But I am telling you what is and
isn't acceptable. I don't just blindly take patches from anyone. You are
not being singled out here.

> To be clear, I don't disagree with the list here but I am not willing
> to argue with people anymore about how it should work. I designed it
> and I know how it should work.
> 
> Also I think I now understand what you are saying about bloblist and
> standard passage being split. It's because most of my standard passage
> series from a few years back was never applied.
> 
> So I'd like to go back and revisit that and get it applied, including
> the gitlab test for the new qemu_arm/64_spl

I assume you'll be posting a v2 of something, which can be applied,
soon then?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Thu, 17 Apr 2025 at 08:14, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > > your option.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > > >
> > > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > > >
> > > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > > >
> > > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > > with.
> > > > > > > > > > >
> > > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > > >
> > > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > > devicetree in the bloblist.
> > > > > > > > >
> > > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > > today.
> > > > > > > >
> > > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > > >
> > > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > > >
> > > > > > We are going around in circles though. Having it is registers doesn't
> > > > > > help with the problem that there isn't an FDT in the bloblist.
> > > > >
> > > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > > >
> > > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > > changed your mind?
> > > > >
> > > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > > problems is that no one understood you.
> > > >
> > > > No, that's not actually true. The problem is that no one would listen
> > > > and everyone was sure I was wrong.
> > >
> > > That's another way of saying "no one understood you", IMO.
> > >
> > > > I sent the series on the basis that you were open to my maintaining
> > > > bloblist in your tree. I didn't know there were extra conditions. So
> > > > please let me know which way you want to go on this.
> > >
> > > I thought we had made progress on the community call, but now you're
> > > sending this so I don't know?
> > >
> > > You need to:
> > > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> > >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> > >   one last question I had before adding vexpress_fvp to our CI. So this
> > >   should be a reasonable requirement.
> > > - You were going to add register passing of bloblist location for x86,
> > >   and then add register passing of bloblist between U-Boot phases
> > >   without relying on BLOBLIST_FiXED.
> > > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> > >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> > >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> > >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> > >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> >
> > That seems very much like a list of instructions. So in fact you still
> > want to be the maintainer?
>
> I mean, I'm the project maintainer. No, I'm not going to sit over your
> shoulder and tell you how to do that. But I am telling you what is and
> isn't acceptable. I don't just blindly take patches from anyone. You are
> not being singled out here.

Heaven forbid. Although I see that you reverted the PXE stuff rather
than taking my fix-up patch. That's different from what you did with
all the lmb breakage.

>
> > To be clear, I don't disagree with the list here but I am not willing
> > to argue with people anymore about how it should work. I designed it
> > and I know how it should work.
> >
> > Also I think I now understand what you are saying about bloblist and
> > standard passage being split. It's because most of my standard passage
> > series from a few years back was never applied.
> >
> > So I'd like to go back and revisit that and get it applied, including
> > the gitlab test for the new qemu_arm/64_spl
>
> I assume you'll be posting a v2 of something, which can be applied,
> soon then?

Yes, v3 is posted. It took a while as the original series was from 2021.

Regards,
SImon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 12418 bytes --]

On Thu, Apr 17, 2025 at 03:24:17PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 17 Apr 2025 at 08:14, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > > > your option.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > > > >
> > > > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > > > with.
> > > > > > > > > > > >
> > > > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > > > >
> > > > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > > > devicetree in the bloblist.
> > > > > > > > > >
> > > > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > > > today.
> > > > > > > > >
> > > > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > > > >
> > > > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > > > >
> > > > > > > We are going around in circles though. Having it is registers doesn't
> > > > > > > help with the problem that there isn't an FDT in the bloblist.
> > > > > >
> > > > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > > > >
> > > > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > > > changed your mind?
> > > > > >
> > > > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > > > problems is that no one understood you.
> > > > >
> > > > > No, that's not actually true. The problem is that no one would listen
> > > > > and everyone was sure I was wrong.
> > > >
> > > > That's another way of saying "no one understood you", IMO.
> > > >
> > > > > I sent the series on the basis that you were open to my maintaining
> > > > > bloblist in your tree. I didn't know there were extra conditions. So
> > > > > please let me know which way you want to go on this.
> > > >
> > > > I thought we had made progress on the community call, but now you're
> > > > sending this so I don't know?
> > > >
> > > > You need to:
> > > > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> > > >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> > > >   one last question I had before adding vexpress_fvp to our CI. So this
> > > >   should be a reasonable requirement.
> > > > - You were going to add register passing of bloblist location for x86,
> > > >   and then add register passing of bloblist between U-Boot phases
> > > >   without relying on BLOBLIST_FiXED.
> > > > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> > > >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> > > >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> > > >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> > > >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> > >
> > > That seems very much like a list of instructions. So in fact you still
> > > want to be the maintainer?
> >
> > I mean, I'm the project maintainer. No, I'm not going to sit over your
> > shoulder and tell you how to do that. But I am telling you what is and
> > isn't acceptable. I don't just blindly take patches from anyone. You are
> > not being singled out here.
> 
> Heaven forbid. Although I see that you reverted the PXE stuff rather
> than taking my fix-up patch. That's different from what you did with
> all the lmb breakage.

Because you said I should just revert it since I didn't "support" it.
And didn't look in to booti. So yes, that series needs a re-baking to
also fix booti as it has a similar set of handling things outside the
bootm state machine, and really re-checking nothing else got missed.

> > > To be clear, I don't disagree with the list here but I am not willing
> > > to argue with people anymore about how it should work. I designed it
> > > and I know how it should work.
> > >
> > > Also I think I now understand what you are saying about bloblist and
> > > standard passage being split. It's because most of my standard passage
> > > series from a few years back was never applied.
> > >
> > > So I'd like to go back and revisit that and get it applied, including
> > > the gitlab test for the new qemu_arm/64_spl
> >
> > I assume you'll be posting a v2 of something, which can be applied,
> > soon then?
> 
> Yes, v3 is posted. It took a while as the original series was from 2021.

OK.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Thu, 17 Apr 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Apr 17, 2025 at 03:24:17PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 17 Apr 2025 at 08:14, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > > > > your option.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > > > > with.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > > > > >
> > > > > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > > > > devicetree in the bloblist.
> > > > > > > > > > >
> > > > > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > > > > today.
> > > > > > > > > >
> > > > > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > > > > >
> > > > > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > > > > >
> > > > > > > > We are going around in circles though. Having it is registers doesn't
> > > > > > > > help with the problem that there isn't an FDT in the bloblist.
> > > > > > >
> > > > > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > > > > >
> > > > > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > > > > changed your mind?
> > > > > > >
> > > > > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > > > > problems is that no one understood you.
> > > > > >
> > > > > > No, that's not actually true. The problem is that no one would listen
> > > > > > and everyone was sure I was wrong.
> > > > >
> > > > > That's another way of saying "no one understood you", IMO.
> > > > >
> > > > > > I sent the series on the basis that you were open to my maintaining
> > > > > > bloblist in your tree. I didn't know there were extra conditions. So
> > > > > > please let me know which way you want to go on this.
> > > > >
> > > > > I thought we had made progress on the community call, but now you're
> > > > > sending this so I don't know?
> > > > >
> > > > > You need to:
> > > > > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> > > > >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> > > > >   one last question I had before adding vexpress_fvp to our CI. So this
> > > > >   should be a reasonable requirement.
> > > > > - You were going to add register passing of bloblist location for x86,
> > > > >   and then add register passing of bloblist between U-Boot phases
> > > > >   without relying on BLOBLIST_FiXED.
> > > > > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> > > > >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> > > > >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> > > > >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> > > > >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> > > >
> > > > That seems very much like a list of instructions. So in fact you still
> > > > want to be the maintainer?
> > >
> > > I mean, I'm the project maintainer. No, I'm not going to sit over your
> > > shoulder and tell you how to do that. But I am telling you what is and
> > > isn't acceptable. I don't just blindly take patches from anyone. You are
> > > not being singled out here.
> >
> > Heaven forbid. Although I see that you reverted the PXE stuff rather
> > than taking my fix-up patch. That's different from what you did with
> > all the lmb breakage.
>
> Because you said I should just revert it since I didn't "support" it.
> And didn't look in to booti. So yes, that series needs a re-baking to
> also fix booti as it has a similar set of handling things outside the
> bootm state machine, and really re-checking nothing else got missed.

If you want the series I'm happy to resend it with the fix integrated.
Yes I carefully checked that nothing else got missed. Still, I did
that the first time and still missed something.

Just let me know.

>
> > > > To be clear, I don't disagree with the list here but I am not willing
> > > > to argue with people anymore about how it should work. I designed it
> > > > and I know how it should work.
> > > >
> > > > Also I think I now understand what you are saying about bloblist and
> > > > standard passage being split. It's because most of my standard passage
> > > > series from a few years back was never applied.
> > > >
> > > > So I'd like to go back and revisit that and get it applied, including
> > > > the gitlab test for the new qemu_arm/64_spl
> > >
> > > I assume you'll be posting a v2 of something, which can be applied,
> > > soon then?
> >
> > Yes, v3 is posted. It took a while as the original series was from 2021.
>
> OK.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 12931 bytes --]

On Thu, Apr 17, 2025 at 04:02:20PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 17 Apr 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Apr 17, 2025 at 03:24:17PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 17 Apr 2025 at 08:14, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > > > > > your option.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > > > > > with.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > > > > > >
> > > > > > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > > > > > devicetree in the bloblist.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > > > > > today.
> > > > > > > > > > >
> > > > > > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > > > > > >
> > > > > > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > > > > > >
> > > > > > > > > We are going around in circles though. Having it is registers doesn't
> > > > > > > > > help with the problem that there isn't an FDT in the bloblist.
> > > > > > > >
> > > > > > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > > > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > > > > > >
> > > > > > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > > > > > changed your mind?
> > > > > > > >
> > > > > > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > > > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > > > > > problems is that no one understood you.
> > > > > > >
> > > > > > > No, that's not actually true. The problem is that no one would listen
> > > > > > > and everyone was sure I was wrong.
> > > > > >
> > > > > > That's another way of saying "no one understood you", IMO.
> > > > > >
> > > > > > > I sent the series on the basis that you were open to my maintaining
> > > > > > > bloblist in your tree. I didn't know there were extra conditions. So
> > > > > > > please let me know which way you want to go on this.
> > > > > >
> > > > > > I thought we had made progress on the community call, but now you're
> > > > > > sending this so I don't know?
> > > > > >
> > > > > > You need to:
> > > > > > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> > > > > >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> > > > > >   one last question I had before adding vexpress_fvp to our CI. So this
> > > > > >   should be a reasonable requirement.
> > > > > > - You were going to add register passing of bloblist location for x86,
> > > > > >   and then add register passing of bloblist between U-Boot phases
> > > > > >   without relying on BLOBLIST_FiXED.
> > > > > > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> > > > > >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> > > > > >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> > > > > >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> > > > > >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> > > > >
> > > > > That seems very much like a list of instructions. So in fact you still
> > > > > want to be the maintainer?
> > > >
> > > > I mean, I'm the project maintainer. No, I'm not going to sit over your
> > > > shoulder and tell you how to do that. But I am telling you what is and
> > > > isn't acceptable. I don't just blindly take patches from anyone. You are
> > > > not being singled out here.
> > >
> > > Heaven forbid. Although I see that you reverted the PXE stuff rather
> > > than taking my fix-up patch. That's different from what you did with
> > > all the lmb breakage.
> >
> > Because you said I should just revert it since I didn't "support" it.
> > And didn't look in to booti. So yes, that series needs a re-baking to
> > also fix booti as it has a similar set of handling things outside the
> > bootm state machine, and really re-checking nothing else got missed.
> 
> If you want the series I'm happy to resend it with the fix integrated.
> Yes I carefully checked that nothing else got missed. Still, I did
> that the first time and still missed something.
> 
> Just let me know.

The "booti" code still needs to be fixed too, that was the first of the
bug reports.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Simon Glass]

Hi Tom,

On Thu, 17 Apr 2025 at 16:14, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Apr 17, 2025 at 04:02:20PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 17 Apr 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Apr 17, 2025 at 03:24:17PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 17 Apr 2025 at 08:14, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > > > > > > your option.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > > > > > > with.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > > > > > > devicetree in the bloblist.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > > > > > > today.
> > > > > > > > > > > >
> > > > > > > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > > > > > > >
> > > > > > > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > > > > > > >
> > > > > > > > > > We are going around in circles though. Having it is registers doesn't
> > > > > > > > > > help with the problem that there isn't an FDT in the bloblist.
> > > > > > > > >
> > > > > > > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > > > > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > > > > > > >
> > > > > > > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > > > > > > changed your mind?
> > > > > > > > >
> > > > > > > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > > > > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > > > > > > problems is that no one understood you.
> > > > > > > >
> > > > > > > > No, that's not actually true. The problem is that no one would listen
> > > > > > > > and everyone was sure I was wrong.
> > > > > > >
> > > > > > > That's another way of saying "no one understood you", IMO.
> > > > > > >
> > > > > > > > I sent the series on the basis that you were open to my maintaining
> > > > > > > > bloblist in your tree. I didn't know there were extra conditions. So
> > > > > > > > please let me know which way you want to go on this.
> > > > > > >
> > > > > > > I thought we had made progress on the community call, but now you're
> > > > > > > sending this so I don't know?
> > > > > > >
> > > > > > > You need to:
> > > > > > > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> > > > > > >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> > > > > > >   one last question I had before adding vexpress_fvp to our CI. So this
> > > > > > >   should be a reasonable requirement.
> > > > > > > - You were going to add register passing of bloblist location for x86,
> > > > > > >   and then add register passing of bloblist between U-Boot phases
> > > > > > >   without relying on BLOBLIST_FiXED.
> > > > > > > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> > > > > > >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> > > > > > >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> > > > > > >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> > > > > > >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> > > > > >
> > > > > > That seems very much like a list of instructions. So in fact you still
> > > > > > want to be the maintainer?
> > > > >
> > > > > I mean, I'm the project maintainer. No, I'm not going to sit over your
> > > > > shoulder and tell you how to do that. But I am telling you what is and
> > > > > isn't acceptable. I don't just blindly take patches from anyone. You are
> > > > > not being singled out here.
> > > >
> > > > Heaven forbid. Although I see that you reverted the PXE stuff rather
> > > > than taking my fix-up patch. That's different from what you did with
> > > > all the lmb breakage.
> > >
> > > Because you said I should just revert it since I didn't "support" it.
> > > And didn't look in to booti. So yes, that series needs a re-baking to
> > > also fix booti as it has a similar set of handling things outside the
> > > bootm state machine, and really re-checking nothing else got missed.
> >
> > If you want the series I'm happy to resend it with the fix integrated.
> > Yes I carefully checked that nothing else got missed. Still, I did
> > that the first time and still missed something.
> >
> > Just let me know.
>
> The "booti" code still needs to be fixed too, that was the first of the
> bug reports.

Yes, I suggested plumbing through a setting to ignore SYS_BOOTM_LEN
and use 4x the compressed size instead. If you are OK with that then I
can incorporate it.

Regards,
Simon

Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 14330 bytes --]

On Thu, Apr 17, 2025 at 04:28:42PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 17 Apr 2025 at 16:14, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Apr 17, 2025 at 04:02:20PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 17 Apr 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Apr 17, 2025 at 03:24:17PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 17 Apr 2025 at 08:14, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > > > > > > > > > > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > > > > > > > > > > > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > > > > > > > > > > > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > > > > > > > > > > > > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > > > > > > > > > > > > > > > > > wasn't sure about removing it.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > > > > > > > > > > > > > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > > > > > > > > > > > > > > > > > the bloblist.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Yes, but we should be explicit about what is going on here. With
> > > > > > > > > > > > > > > > > > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > > > > > > > > > > > > > > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > > > > > > > > > > > > > > > > > OF_SEPARATE and OF_EMBED
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > > > > > > > > > > > > > > > > > mandatorily used and override other fdt sources like from the board or
> > > > > > > > > > > > > > > > > > > > env variables.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > > > > > > > > > > > > > > > > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > > > > > > > > > > > > > > > > > very much. But I can see why it is called that as my standard passage
> > > > > > > > > > > > > > > > > > > series was actually never applied. So I suppose I'll need to have
> > > > > > > > > > > > > > > > > > > another try at that.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > So to be clear, I want a separate option for devicetree, called
> > > > > > > > > > > > > > > > > > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > > > > > > > > > > > > > > > > > your option.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Sigh. Can I ask what the use case for this will be? And we are going to
> > > > > > > > > > > > > > > > > > get rid of BLOBLIST_FIXED at some point, yes?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I thought we agreed that this was acceptable. We argued the toss for
> > > > > > > > > > > > > > > > > months on this point and I would rather not revisit it.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> > > > > > > > > > > > > > > > > pretty sure it can be done. The only tricky bit is coming up with a
> > > > > > > > > > > > > > > > > bloblist protocol for x86.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, I'm stuck between being "flexible and saying yes" and how long we
> > > > > > > > > > > > > > > > have to live with what I also think are bad designs.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So maybe the pre-requisite here is that with "bloblist" and "standard
> > > > > > > > > > > > > > > > passage" being divorced, what is the requirement for bloblist again?
> > > > > > > > > > > > > > > > Because in practice, all of the problems we've had come down to looking
> > > > > > > > > > > > > > > > in fixed address locations before they're valid. You want to handle this
> > > > > > > > > > > > > > > > by saying "Ah, we won't look before it's valid with other CONFIG flags"
> > > > > > > > > > > > > > > > and I say we should handle this by not using a fixed address to start
> > > > > > > > > > > > > > > > with.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
> > > > > > > > > > > > > > > > OK. But it shouldn't need to exist long term.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > > > > > > > devicetree in the bloblist.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > > > > > > > today.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > > > > > > > >
> > > > > > > > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > > > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > > > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > > > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > > > > > > > >
> > > > > > > > > > > We are going around in circles though. Having it is registers doesn't
> > > > > > > > > > > help with the problem that there isn't an FDT in the bloblist.
> > > > > > > > > >
> > > > > > > > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > > > > > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > > > > > > > >
> > > > > > > > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > > > > > > > changed your mind?
> > > > > > > > > >
> > > > > > > > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > > > > > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > > > > > > > problems is that no one understood you.
> > > > > > > > >
> > > > > > > > > No, that's not actually true. The problem is that no one would listen
> > > > > > > > > and everyone was sure I was wrong.
> > > > > > > >
> > > > > > > > That's another way of saying "no one understood you", IMO.
> > > > > > > >
> > > > > > > > > I sent the series on the basis that you were open to my maintaining
> > > > > > > > > bloblist in your tree. I didn't know there were extra conditions. So
> > > > > > > > > please let me know which way you want to go on this.
> > > > > > > >
> > > > > > > > I thought we had made progress on the community call, but now you're
> > > > > > > > sending this so I don't know?
> > > > > > > >
> > > > > > > > You need to:
> > > > > > > > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> > > > > > > >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> > > > > > > >   one last question I had before adding vexpress_fvp to our CI. So this
> > > > > > > >   should be a reasonable requirement.
> > > > > > > > - You were going to add register passing of bloblist location for x86,
> > > > > > > >   and then add register passing of bloblist between U-Boot phases
> > > > > > > >   without relying on BLOBLIST_FiXED.
> > > > > > > > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> > > > > > > >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> > > > > > > >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> > > > > > > >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> > > > > > > >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> > > > > > >
> > > > > > > That seems very much like a list of instructions. So in fact you still
> > > > > > > want to be the maintainer?
> > > > > >
> > > > > > I mean, I'm the project maintainer. No, I'm not going to sit over your
> > > > > > shoulder and tell you how to do that. But I am telling you what is and
> > > > > > isn't acceptable. I don't just blindly take patches from anyone. You are
> > > > > > not being singled out here.
> > > > >
> > > > > Heaven forbid. Although I see that you reverted the PXE stuff rather
> > > > > than taking my fix-up patch. That's different from what you did with
> > > > > all the lmb breakage.
> > > >
> > > > Because you said I should just revert it since I didn't "support" it.
> > > > And didn't look in to booti. So yes, that series needs a re-baking to
> > > > also fix booti as it has a similar set of handling things outside the
> > > > bootm state machine, and really re-checking nothing else got missed.
> > >
> > > If you want the series I'm happy to resend it with the fix integrated.
> > > Yes I carefully checked that nothing else got missed. Still, I did
> > > that the first time and still missed something.
> > >
> > > Just let me know.
> >
> > The "booti" code still needs to be fixed too, that was the first of the
> > bug reports.
> 
> Yes, I suggested plumbing through a setting to ignore SYS_BOOTM_LEN
> and use 4x the compressed size instead. If you are OK with that then I
> can incorporate it.

I'd prefer to take the existing code we have in cmd/booti.c and
migrate that similar to your patch for bootz, so that we don't change
expected behavior and can evaluate any later cleanups by themselves and
not related to fixing regressions.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]