[PATCH v2 0/4] Enable bloblist support on Vexpress64

[PATCH v2 0/4] Enable bloblist support on Vexpress64

[Harrison Mutai]

This series of patches enhances the vexpress64 platform by enabling bloblist
support. It also introduces support for CONFIG_BLOBLIST_PASSAGE. This is
necessary to boot vexpress64 and other boards without manually specifying a
fixed address and size for the bloblist.

After this change, all the bloblist init modes are supported (i.e., fixed,
alloc, passage) and Vexpress64 boots with CONFIG_BLOBLIST_PASSAGE.

Changes in v2:

* The commit body for the typo fix was expanded.
* The default BLOBLIST_RELOC_SIZE was removed when CONFIG_BLOBLIST_PASSAGE is
  enabled, the relocation size depends on the size of bloblist received.

Harrison Mutai (4):
  bloblist: fix typo in code comments
  board: vexpress64: default to hardware device tree
  bloblist: add support for CONFIG_BLOBLIST_PASSAGE
  board: vexpress64: enable bloblist for SPL handoff

 board/armltd/vexpress64/Makefile        |  3 ++-
 board/armltd/vexpress64/vexpress64.c    |  4 ++++
 common/Kconfig                          | 10 ++++++++--
 common/bloblist.c                       |  5 ++++-
 configs/vexpress_fvp_bloblist_defconfig |  5 +++++
 doc/board/armltd/vexpress64.rst         | 16 ++++++++++++++++
 include/bloblist.h                      |  2 +-
 include/configs/vexpress_aemv8.h        |  6 ++++--
 8 files changed, 44 insertions(+), 7 deletions(-)
 create mode 100644 configs/vexpress_fvp_bloblist_defconfig

-- 
2.46.2

[PATCH v2 1/4] bloblist: fix typo in code comments

[Harrison Mutai]

Fix the two typos in the spelling of same and set in common/Kconfig and
include/bloblist.h.

Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
---
 common/Kconfig     | 2 +-
 include/bloblist.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index 0e8c44f3f7..7a80b797df 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1083,7 +1083,7 @@ config BLOBLIST_SIZE
 	  Sets the size of the bloblist in bytes. This must include all
 	  overhead (alignment, bloblist header, record header). The bloblist
 	  is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
-	  proper), and this sane bloblist is used for subsequent phases.
+	  proper), and this same bloblist is used for subsequent phases.
 
 config BLOBLIST_SIZE_RELOC
 	hex "Size of bloblist after relocation"
diff --git a/include/bloblist.h b/include/bloblist.h
index f999391f74..03d9862c0f 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -463,7 +463,7 @@ int bloblist_init(void);
 /**
  * bloblist_maybe_init() - Init the bloblist system if not already done
  *
- * Calls bloblist_init() if the GD_FLG_BLOBLIST_READY flag is not et
+ * Calls bloblist_init() if the GD_FLG_BLOBLIST_READY flag is not set
  *
  * Return: 0 if OK, -ve on error
  */
-- 
2.46.2

Re: [PATCH v2 1/4] bloblist: fix typo in code comments

[Tom Rini]

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

On Wed, Jan 15, 2025 at 01:52:04PM +0000, Harrison Mutai wrote:

> Fix the two typos in the spelling of same and set in common/Kconfig and
> include/bloblist.h.
> 
> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

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

[PATCH v2 2/4] board: vexpress64: default to hardware device tree

[Harrison Mutai]

When booting into the Linux kernel with semi-hosting, use the device
tree provided by hardware unless one is provided in the current
directory.

Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
---
 include/configs/vexpress_aemv8.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/configs/vexpress_aemv8.h b/include/configs/vexpress_aemv8.h
index 8020689e39..2341b3a938 100644
--- a/include/configs/vexpress_aemv8.h
+++ b/include/configs/vexpress_aemv8.h
@@ -169,12 +169,14 @@
 		"  if load hostfs - ${kernel_addr_r} ${kernel_name}; then"	\
 		"    setenv fdt_high 0xffffffffffffffff;"		\
 		"    setenv initrd_high 0xffffffffffffffff;"		\
-		"    load hostfs - ${fdt_addr_r} ${fdtfile};"			\
+		"    if test -n load hostfs - ${fdt_addr_r} ${fdtfile}; then"			\
+		"        fdt move $fdtcontroladdr $fdt_addr_r;"			\
+		"    fi;"			\
 		"    load hostfs - ${ramdisk_addr_r} ${ramdisk_name};" \
 		"    fdt addr ${fdt_addr_r};"				\
 		"    fdt resize;"					\
 		"    fdt chosen ${ramdisk_addr_r} ${filesize};"	\
-		"    booti $kernel_addr_r - $fdt_addr_r;"		\
+		"    booti $kernel_addr_r - ${fdt_addr_r};"		\
 		"  fi;"							\
 		"fi\0"
 #define BOOTENV_DEV_NAME_SMH(devtypeu, devtypel, instance) "smh "
-- 
2.46.2

Re: [PATCH v2 2/4] board: vexpress64: default to hardware device tree

[Simon Glass]

Hi Harrison,

On Wed, 15 Jan 2025 at 06:52, Harrison Mutai <harrison.mutai@arm.com> wrote:
>
> When booting into the Linux kernel with semi-hosting, use the device
> tree provided by hardware unless one is provided in the current
> directory.
>
> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
> ---
>  include/configs/vexpress_aemv8.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>

Thinking about standard boot, could we add a bootdev for hostfs? Then
we could drop these scripts.

> diff --git a/include/configs/vexpress_aemv8.h b/include/configs/vexpress_aemv8.h
> index 8020689e39..2341b3a938 100644
> --- a/include/configs/vexpress_aemv8.h
> +++ b/include/configs/vexpress_aemv8.h
> @@ -169,12 +169,14 @@
>                 "  if load hostfs - ${kernel_addr_r} ${kernel_name}; then"      \
>                 "    setenv fdt_high 0xffffffffffffffff;"               \
>                 "    setenv initrd_high 0xffffffffffffffff;"            \
> -               "    load hostfs - ${fdt_addr_r} ${fdtfile};"                   \
> +               "    if test -n load hostfs - ${fdt_addr_r} ${fdtfile}; then"                   \
> +               "        fdt move $fdtcontroladdr $fdt_addr_r;"                 \
> +               "    fi;"                       \
>                 "    load hostfs - ${ramdisk_addr_r} ${ramdisk_name};" \
>                 "    fdt addr ${fdt_addr_r};"                           \
>                 "    fdt resize;"                                       \
>                 "    fdt chosen ${ramdisk_addr_r} ${filesize};" \
> -               "    booti $kernel_addr_r - $fdt_addr_r;"               \
> +               "    booti $kernel_addr_r - ${fdt_addr_r};"             \
>                 "  fi;"                                                 \
>                 "fi\0"
>  #define BOOTENV_DEV_NAME_SMH(devtypeu, devtypel, instance) "smh "
> --
> 2.46.2
>

Regards,
Simon

Re: [PATCH v2 2/4] board: vexpress64: default to hardware device tree

[Harrison Mutai]

Hi Simon,

On 16/01/2025 01:26, Simon Glass wrote:
> Hi Harrison,
> 
> On Wed, 15 Jan 2025 at 06:52, Harrison Mutai <harrison.mutai@arm.com> wrote:
>>
>> When booting into the Linux kernel with semi-hosting, use the device
>> tree provided by hardware unless one is provided in the current
>> directory.
>>
>> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
>> ---
>>   include/configs/vexpress_aemv8.h | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
> 
> Thinking about standard boot, could we add a bootdev for hostfs? Then
> we could drop these scripts.
> 
I have a patch in progress to migrate vexpress64 to standard boot that 
tries to do this. However, it's not quite ready for upstreaming. For 
one, there's other boot targets in this file that would need similar 
treatment (e.g., AFS, MEM). Would it be possible to transition these in 
a piece-wise manner?
>> diff --git a/include/configs/vexpress_aemv8.h b/include/configs/vexpress_aemv8.h
>> index 8020689e39..2341b3a938 100644
>> --- a/include/configs/vexpress_aemv8.h
>> +++ b/include/configs/vexpress_aemv8.h
>> @@ -169,12 +169,14 @@
>>                  "  if load hostfs - ${kernel_addr_r} ${kernel_name}; then"      \
>>                  "    setenv fdt_high 0xffffffffffffffff;"               \
>>                  "    setenv initrd_high 0xffffffffffffffff;"            \
>> -               "    load hostfs - ${fdt_addr_r} ${fdtfile};"                   \
>> +               "    if test -n load hostfs - ${fdt_addr_r} ${fdtfile}; then"                   \
>> +               "        fdt move $fdtcontroladdr $fdt_addr_r;"                 \
>> +               "    fi;"                       \
>>                  "    load hostfs - ${ramdisk_addr_r} ${ramdisk_name};" \
>>                  "    fdt addr ${fdt_addr_r};"                           \
>>                  "    fdt resize;"                                       \
>>                  "    fdt chosen ${ramdisk_addr_r} ${filesize};" \
>> -               "    booti $kernel_addr_r - $fdt_addr_r;"               \
>> +               "    booti $kernel_addr_r - ${fdt_addr_r};"             \
>>                  "  fi;"                                                 \
>>                  "fi\0"
>>   #define BOOTENV_DEV_NAME_SMH(devtypeu, devtypel, instance) "smh "
>> --
>> 2.46.2
>>
> 
> Regards,
> Simon
All the best,
Harrison

Re: [PATCH v2 2/4] board: vexpress64: default to hardware device tree

[Harrison Mutai]

On 16/01/2025 11:20, Harrison Mutai wrote:
> Hi Simon,
> 
> On 16/01/2025 01:26, Simon Glass wrote:
>> Hi Harrison,
>>
>> On Wed, 15 Jan 2025 at 06:52, Harrison Mutai <harrison.mutai@arm.com> 
>> wrote:
>>>
>>> When booting into the Linux kernel with semi-hosting, use the device
>>> tree provided by hardware unless one is provided in the current
>>> directory.
>>>
>>> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
>>> ---
>>>   include/configs/vexpress_aemv8.h | 6 ++++--
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>
>> Thinking about standard boot, could we add a bootdev for hostfs? Then
>> we could drop these scripts.
>>
> I have a patch in progress to migrate vexpress64 to standard boot that 
> tries to do this. However, it's not quite ready for upstreaming. For 
> one, there's other boot targets in this file that would need similar 
> treatment (e.g., AFS, MEM). Would it be possible to transition these in 
> a piece-wise manner?

Notably, we do already have fs/sandbox/host_bootdev.c. What was the 
original intent of this?

>>> diff --git a/include/configs/vexpress_aemv8.h b/include/configs/ 
>>> vexpress_aemv8.h
>>> index 8020689e39..2341b3a938 100644
>>> --- a/include/configs/vexpress_aemv8.h
>>> +++ b/include/configs/vexpress_aemv8.h
>>> @@ -169,12 +169,14 @@
>>>                  "  if load hostfs - ${kernel_addr_r} ${kernel_name}; 
>>> then"      \
>>>                  "    setenv fdt_high 
>>> 0xffffffffffffffff;"               \
>>>                  "    setenv initrd_high 
>>> 0xffffffffffffffff;"            \
>>> -               "    load hostfs - ${fdt_addr_r} 
>>> ${fdtfile};"                   \
>>> +               "    if test -n load hostfs - ${fdt_addr_r} 
>>> ${fdtfile}; then"                   \
>>> +               "        fdt move $fdtcontroladdr 
>>> $fdt_addr_r;"                 \
>>> +               "    fi;"                       \
>>>                  "    load hostfs - ${ramdisk_addr_r} 
>>> ${ramdisk_name};" \
>>>                  "    fdt addr 
>>> ${fdt_addr_r};"                           \
>>>                  "    fdt 
>>> resize;"                                       \
>>>                  "    fdt chosen ${ramdisk_addr_r} ${filesize};" \
>>> -               "    booti $kernel_addr_r - 
>>> $fdt_addr_r;"               \
>>> +               "    booti $kernel_addr_r - 
>>> ${fdt_addr_r};"             \
>>>                  "  
>>> fi;"                                                 \
>>>                  "fi\0"
>>>   #define BOOTENV_DEV_NAME_SMH(devtypeu, devtypel, instance) "smh "
>>> -- 
>>> 2.46.2
>>>
>>
>> Regards,
>> Simon
> All the best,
> Harrison
> 

Regards,
Harrison

[PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Harrison Mutai]

When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
bloblist present in the incoming standard passage is utilised in-place.
There is no need to specify the size of the bloblist as the system
automatically detects it using the header information.

Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
---
 common/Kconfig    | 8 +++++++-
 common/bloblist.c | 5 ++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index 7a80b797df..49fe04ffca 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1064,6 +1064,12 @@ config BLOBLIST_ALLOC
 	  specify a fixed address on systems where this is unknown or can
 	  change at runtime.
 
+config BLOBLIST_PASSAGE
+	bool "Use bloblist in-place"
+	help
+	  Use a bloblist in the incoming standard passage. The size is detected
+	  automatically so CONFIG_BLOBLIST_SIZE can be 0.
+
 endchoice
 
 config BLOBLIST_ADDR
@@ -1078,6 +1084,7 @@ config BLOBLIST_ADDR
 
 config BLOBLIST_SIZE
 	hex "Size of bloblist"
+	default 0x0 if BLOBLIST_PASSAGE
 	default 0x400
 	help
 	  Sets the size of the bloblist in bytes. This must include all
@@ -1088,7 +1095,6 @@ config BLOBLIST_SIZE
 config BLOBLIST_SIZE_RELOC
 	hex "Size of bloblist after relocation"
 	default BLOBLIST_SIZE if BLOBLIST_FIXED || BLOBLIST_ALLOC
-	default 0x0 if BLOBLIST_PASSAGE
 	default 0x20000 if (ARM && EFI_LOADER && GENERATE_ACPI_TABLE)
 	help
 	  Sets the size of the bloblist in bytes after relocation. Since U-Boot
diff --git a/common/bloblist.c b/common/bloblist.c
index 110bb9dc44..f52f1eaca9 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -475,6 +475,9 @@ int bloblist_reloc(void *to, uint to_size)
 {
 	struct bloblist_hdr *hdr;
 
+	if (to_size == 0)
+		return 0;
+
 	if (to_size < gd->bloblist->total_size)
 		return -ENOSPC;
 
@@ -510,7 +513,7 @@ int bloblist_init(void)
 	 * install the bloblist passed from previous loader to this fixed
 	 * address.
 	 */
-	bool from_boot_arg = fixed && xpl_is_first_phase();
+	bool from_boot_arg = xpl_is_first_phase();
 
 	if (xpl_prev_phase() == PHASE_TPL && !IS_ENABLED(CONFIG_TPL_BLOBLIST))
 		from_addr = false;
-- 
2.46.2

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Tom Rini]

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

On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:

> When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
> bloblist present in the incoming standard passage is utilised in-place.
> There is no need to specify the size of the bloblist as the system
> automatically detects it using the header information.
> 
> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

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

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Simon Glass]

Hi Harrison,

On Wed, 15 Jan 2025 at 06:53, Harrison Mutai <harrison.mutai@arm.com> wrote:
>
> When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
> bloblist present in the incoming standard passage is utilised in-place.
> There is no need to specify the size of the bloblist as the system
> automatically detects it using the header information.
>
> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
> ---
>  common/Kconfig    | 8 +++++++-
>  common/bloblist.c | 5 ++++-
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 7a80b797df..49fe04ffca 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -1064,6 +1064,12 @@ config BLOBLIST_ALLOC
>           specify a fixed address on systems where this is unknown or can
>           change at runtime.
>
> +config BLOBLIST_PASSAGE
> +       bool "Use bloblist in-place"
> +       help
> +         Use a bloblist in the incoming standard passage. The size is detected
> +         automatically so CONFIG_BLOBLIST_SIZE can be 0.
> +
>  endchoice
>
>  config BLOBLIST_ADDR
> @@ -1078,6 +1084,7 @@ config BLOBLIST_ADDR
>
>  config BLOBLIST_SIZE
>         hex "Size of bloblist"
> +       default 0x0 if BLOBLIST_PASSAGE
>         default 0x400
>         help
>           Sets the size of the bloblist in bytes. This must include all
> @@ -1088,7 +1095,6 @@ config BLOBLIST_SIZE
>  config BLOBLIST_SIZE_RELOC
>         hex "Size of bloblist after relocation"
>         default BLOBLIST_SIZE if BLOBLIST_FIXED || BLOBLIST_ALLOC
> -       default 0x0 if BLOBLIST_PASSAGE
>         default 0x20000 if (ARM && EFI_LOADER && GENERATE_ACPI_TABLE)
>         help
>           Sets the size of the bloblist in bytes after relocation. Since U-Boot
> diff --git a/common/bloblist.c b/common/bloblist.c
> index 110bb9dc44..f52f1eaca9 100644
> --- a/common/bloblist.c
> +++ b/common/bloblist.c
> @@ -475,6 +475,9 @@ int bloblist_reloc(void *to, uint to_size)
>  {
>         struct bloblist_hdr *hdr;
>
> +       if (to_size == 0)

if (!to_size)

> +               return 0;
> +
>         if (to_size < gd->bloblist->total_size)
>                 return -ENOSPC;
>
> @@ -510,7 +513,7 @@ int bloblist_init(void)
>          * install the bloblist passed from previous loader to this fixed
>          * address.
>          */
> -       bool from_boot_arg = fixed && xpl_is_first_phase();
> +       bool from_boot_arg = xpl_is_first_phase();
>
>         if (xpl_prev_phase() == PHASE_TPL && !IS_ENABLED(CONFIG_TPL_BLOBLIST))
>                 from_addr = false;
> --
> 2.46.2
>

Regards,
Simon

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Tom Rini]

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

On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:

> When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
> bloblist present in the incoming standard passage is utilised in-place.
> There is no need to specify the size of the bloblist as the system
> automatically detects it using the header information.
> 
> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
> ---
>  common/Kconfig    | 8 +++++++-
>  common/bloblist.c | 5 ++++-
>  2 files changed, 11 insertions(+), 2 deletions(-)

This leads to failure to boot on qemu-arm-sbsa as seen in CI:
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423

-- 
Tom

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

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Harrison Mutai]

On 22/01/2025 17:21, Tom Rini wrote:
> On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:
> 
>> When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
>> bloblist present in the incoming standard passage is utilised in-place.
>> There is no need to specify the size of the bloblist as the system
>> automatically detects it using the header information.
>>
>> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
>> ---
>>   common/Kconfig    | 8 +++++++-
>>   common/bloblist.c | 5 ++++-
>>   2 files changed, 11 insertions(+), 2 deletions(-)
> 
> This leads to failure to boot on qemu-arm-sbsa as seen in CI:
> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
> 
Sorry, I'm unfamilliar with U-Boot's CI but I can't make out what the 
source of the failure is. All I see in the logs is what looks like an 
intermittent error.

https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423

Would you be able to share the results XML?

All the best,
Harrison

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Tom Rini]

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

On Thu, Jan 23, 2025 at 05:03:40PM +0000, Harrison Mutai wrote:
> On 22/01/2025 17:21, Tom Rini wrote:
> > On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:
> > 
> > > When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
> > > bloblist present in the incoming standard passage is utilised in-place.
> > > There is no need to specify the size of the bloblist as the system
> > > automatically detects it using the header information.
> > > 
> > > Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
> > > ---
> > >   common/Kconfig    | 8 +++++++-
> > >   common/bloblist.c | 5 ++++-
> > >   2 files changed, 11 insertions(+), 2 deletions(-)
> > 
> > This leads to failure to boot on qemu-arm-sbsa as seen in CI:
> > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
> > 
> Sorry, I'm unfamilliar with U-Boot's CI but I can't make out what the source
> of the failure is. All I see in the logs is what looks like an intermittent
> error.
> 
> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
> 
> Would you be able to share the results XML?

The problem is that qemu doesn't start anymore, sorry for being unclear.
Looking at
https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-arm-sbsa_na?ref_type=heads
we can see how qemu is invoked.

-- 
Tom

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

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Harrison Mutai]

Hi Tom,

Thanks for the additional details, that helped!

On 23/01/2025 17:12, Tom Rini wrote:
> On Thu, Jan 23, 2025 at 05:03:40PM +0000, Harrison Mutai wrote:
>> On 22/01/2025 17:21, Tom Rini wrote:
>>> On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:
>>>
>>>> When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
>>>> bloblist present in the incoming standard passage is utilised in-place.
>>>> There is no need to specify the size of the bloblist as the system
>>>> automatically detects it using the header information.
>>>>
>>>> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
>>>> ---
>>>>    common/Kconfig    | 8 +++++++-
>>>>    common/bloblist.c | 5 ++++-
>>>>    2 files changed, 11 insertions(+), 2 deletions(-)
>>>
>>> This leads to failure to boot on qemu-arm-sbsa as seen in CI:
>>> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
>>>
>> Sorry, I'm unfamilliar with U-Boot's CI but I can't make out what the source
>> of the failure is. All I see in the logs is what looks like an intermittent
>> error.
>>
>> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
>>
>> Would you be able to share the results XML?
> 
> The problem is that qemu doesn't start anymore, sorry for being unclear.
> Looking at
> https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-arm-sbsa_na?ref_type=heads
> we can see how qemu is invoked.
> 

I've successfully reproduced and resolved the error. The issue occurred 
because I relaxed the condition for calling the architecture-specific 
hook xferlist_from_boot_arg. Previously, this hook was only called if 
the bloblist was at a fixed address and U-Boot was in the first phase. 
However, since we also need the hook for BLOBLIST_PASSAGE, I've added a 
condition to prevent calling the hook if BLOBLIST_ALLOC is enabled, 
assuming we don't expect to receive a bloblist from the previous stage 
in this mode.

However, I'm slightly unsure if this assumption is correct. Generally, 
when BLOBLIST_ALLOC is enabled, is it expected that U-Boot will allocate 
memory for the bloblist, ignoring the bloblist from previous stages? In 
the case of BLOBLIST_FIXED, we relocate any bloblist received from the 
prior stage to the fixed address. I'm surprised we don't do the same 
with BLOBLIST_ALLOC.

Best regards,
Harrison

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Tom Rini]

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

On Mon, Jan 27, 2025 at 12:42:30PM +0000, Harrison Mutai wrote:
> Hi Tom,
> 
> Thanks for the additional details, that helped!
> 
> On 23/01/2025 17:12, Tom Rini wrote:
> > On Thu, Jan 23, 2025 at 05:03:40PM +0000, Harrison Mutai wrote:
> > > On 22/01/2025 17:21, Tom Rini wrote:
> > > > On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:
> > > > 
> > > > > When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
> > > > > bloblist present in the incoming standard passage is utilised in-place.
> > > > > There is no need to specify the size of the bloblist as the system
> > > > > automatically detects it using the header information.
> > > > > 
> > > > > Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
> > > > > ---
> > > > >    common/Kconfig    | 8 +++++++-
> > > > >    common/bloblist.c | 5 ++++-
> > > > >    2 files changed, 11 insertions(+), 2 deletions(-)
> > > > 
> > > > This leads to failure to boot on qemu-arm-sbsa as seen in CI:
> > > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
> > > > 
> > > Sorry, I'm unfamilliar with U-Boot's CI but I can't make out what the source
> > > of the failure is. All I see in the logs is what looks like an intermittent
> > > error.
> > > 
> > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
> > > 
> > > Would you be able to share the results XML?
> > 
> > The problem is that qemu doesn't start anymore, sorry for being unclear.
> > Looking at
> > https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-arm-sbsa_na?ref_type=heads
> > we can see how qemu is invoked.
> > 
> 
> I've successfully reproduced and resolved the error. The issue occurred
> because I relaxed the condition for calling the architecture-specific hook
> xferlist_from_boot_arg. Previously, this hook was only called if the
> bloblist was at a fixed address and U-Boot was in the first phase. However,
> since we also need the hook for BLOBLIST_PASSAGE, I've added a condition to
> prevent calling the hook if BLOBLIST_ALLOC is enabled, assuming we don't
> expect to receive a bloblist from the previous stage in this mode.
> 
> However, I'm slightly unsure if this assumption is correct. Generally, when
> BLOBLIST_ALLOC is enabled, is it expected that U-Boot will allocate memory
> for the bloblist, ignoring the bloblist from previous stages? In the case of
> BLOBLIST_FIXED, we relocate any bloblist received from the prior stage to
> the fixed address. I'm surprised we don't do the same with BLOBLIST_ALLOC.

The problem is that today at least yes, BLOBLIST_ALLOC is only viable
for full U-Boot as we don't have a mechanism to pass our own from one
stage to the next unless it's fixed.

-- 
Tom

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

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Harrison Mutai]

On 31/01/2025 00:10, Tom Rini wrote:
> On Mon, Jan 27, 2025 at 12:42:30PM +0000, Harrison Mutai wrote:
>> Hi Tom,
>>
>> Thanks for the additional details, that helped!
>>
>> On 23/01/2025 17:12, Tom Rini wrote:
>>> On Thu, Jan 23, 2025 at 05:03:40PM +0000, Harrison Mutai wrote:
>>>> On 22/01/2025 17:21, Tom Rini wrote:
>>>>> On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:
>>>>>
>>>>>> When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
>>>>>> bloblist present in the incoming standard passage is utilised in-place.
>>>>>> There is no need to specify the size of the bloblist as the system
>>>>>> automatically detects it using the header information.
>>>>>>
>>>>>> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
>>>>>> ---
>>>>>>     common/Kconfig    | 8 +++++++-
>>>>>>     common/bloblist.c | 5 ++++-
>>>>>>     2 files changed, 11 insertions(+), 2 deletions(-)
>>>>>
>>>>> This leads to failure to boot on qemu-arm-sbsa as seen in CI:
>>>>> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
>>>>>
>>>> Sorry, I'm unfamilliar with U-Boot's CI but I can't make out what the source
>>>> of the failure is. All I see in the logs is what looks like an intermittent
>>>> error.
>>>>
>>>> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
>>>>
>>>> Would you be able to share the results XML?
>>>
>>> The problem is that qemu doesn't start anymore, sorry for being unclear.
>>> Looking at
>>> https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-arm-sbsa_na?ref_type=heads
>>> we can see how qemu is invoked.
>>>
>>
>> I've successfully reproduced and resolved the error. The issue occurred
>> because I relaxed the condition for calling the architecture-specific hook
>> xferlist_from_boot_arg. Previously, this hook was only called if the
>> bloblist was at a fixed address and U-Boot was in the first phase. However,
>> since we also need the hook for BLOBLIST_PASSAGE, I've added a condition to
>> prevent calling the hook if BLOBLIST_ALLOC is enabled, assuming we don't
>> expect to receive a bloblist from the previous stage in this mode.
>>
>> However, I'm slightly unsure if this assumption is correct. Generally, when
>> BLOBLIST_ALLOC is enabled, is it expected that U-Boot will allocate memory
>> for the bloblist, ignoring the bloblist from previous stages? In the case of
>> BLOBLIST_FIXED, we relocate any bloblist received from the prior stage to
>> the fixed address. I'm surprised we don't do the same with BLOBLIST_ALLOC.
> 
> The problem is that today at least yes, BLOBLIST_ALLOC is only viable
> for full U-Boot as we don't have a mechanism to pass our own from one
> stage to the next unless it's fixed.
> 

To summarize, BLOBLIST_ALLOC is meant to serve as a fallback buffer for 
internal use when a prior-stage bootloader hasn't provided a bloblist at 
a fixed address (BLOBLIST_FIXED) or a pointer to a bloblist 
(BLOBLIST_PASSAGE). From the perspective of a prior-stage bootloader, 
these are the only relevant options. BLOBLIST_ALLOC is also entirely 
irrelevant when U-Boot is staged. Have a I missed anything?

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Tom Rini]

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

On Mon, Feb 03, 2025 at 12:28:25PM +0000, Harrison Mutai wrote:
> On 31/01/2025 00:10, Tom Rini wrote:
> > On Mon, Jan 27, 2025 at 12:42:30PM +0000, Harrison Mutai wrote:
> > > Hi Tom,
> > > 
> > > Thanks for the additional details, that helped!
> > > 
> > > On 23/01/2025 17:12, Tom Rini wrote:
> > > > On Thu, Jan 23, 2025 at 05:03:40PM +0000, Harrison Mutai wrote:
> > > > > On 22/01/2025 17:21, Tom Rini wrote:
> > > > > > On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:
> > > > > > 
> > > > > > > When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
> > > > > > > bloblist present in the incoming standard passage is utilised in-place.
> > > > > > > There is no need to specify the size of the bloblist as the system
> > > > > > > automatically detects it using the header information.
> > > > > > > 
> > > > > > > Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
> > > > > > > ---
> > > > > > >     common/Kconfig    | 8 +++++++-
> > > > > > >     common/bloblist.c | 5 ++++-
> > > > > > >     2 files changed, 11 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > This leads to failure to boot on qemu-arm-sbsa as seen in CI:
> > > > > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
> > > > > > 
> > > > > Sorry, I'm unfamilliar with U-Boot's CI but I can't make out what the source
> > > > > of the failure is. All I see in the logs is what looks like an intermittent
> > > > > error.
> > > > > 
> > > > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
> > > > > 
> > > > > Would you be able to share the results XML?
> > > > 
> > > > The problem is that qemu doesn't start anymore, sorry for being unclear.
> > > > Looking at
> > > > https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-arm-sbsa_na?ref_type=heads
> > > > we can see how qemu is invoked.
> > > > 
> > > 
> > > I've successfully reproduced and resolved the error. The issue occurred
> > > because I relaxed the condition for calling the architecture-specific hook
> > > xferlist_from_boot_arg. Previously, this hook was only called if the
> > > bloblist was at a fixed address and U-Boot was in the first phase. However,
> > > since we also need the hook for BLOBLIST_PASSAGE, I've added a condition to
> > > prevent calling the hook if BLOBLIST_ALLOC is enabled, assuming we don't
> > > expect to receive a bloblist from the previous stage in this mode.
> > > 
> > > However, I'm slightly unsure if this assumption is correct. Generally, when
> > > BLOBLIST_ALLOC is enabled, is it expected that U-Boot will allocate memory
> > > for the bloblist, ignoring the bloblist from previous stages? In the case of
> > > BLOBLIST_FIXED, we relocate any bloblist received from the prior stage to
> > > the fixed address. I'm surprised we don't do the same with BLOBLIST_ALLOC.
> > 
> > The problem is that today at least yes, BLOBLIST_ALLOC is only viable
> > for full U-Boot as we don't have a mechanism to pass our own from one
> > stage to the next unless it's fixed.
> > 
> 
> To summarize, BLOBLIST_ALLOC is meant to serve as a fallback buffer for
> internal use when a prior-stage bootloader hasn't provided a bloblist at a
> fixed address (BLOBLIST_FIXED) or a pointer to a bloblist
> (BLOBLIST_PASSAGE). From the perspective of a prior-stage bootloader, these
> are the only relevant options. BLOBLIST_ALLOC is also entirely irrelevant
> when U-Boot is staged. Have a I missed anything?

With the perspective of a non-U-Boot prior stage, this is right.
Ideally, U-Boot should be able to use BLOBLIST_ALLOC in one phase and
pass bloblist to a later stage. But that's outside of the scope of what
you're dealing with right now, yes?

-- 
Tom

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

Re: [PATCH v2 3/4] bloblist: add support for CONFIG_BLOBLIST_PASSAGE

[Harrison Mutai]

On 03/02/2025 22:22, Tom Rini wrote:
> On Mon, Feb 03, 2025 at 12:28:25PM +0000, Harrison Mutai wrote:
>> On 31/01/2025 00:10, Tom Rini wrote:
>>> On Mon, Jan 27, 2025 at 12:42:30PM +0000, Harrison Mutai wrote:
>>>> Hi Tom,
>>>>
>>>> Thanks for the additional details, that helped!
>>>>
>>>> On 23/01/2025 17:12, Tom Rini wrote:
>>>>> On Thu, Jan 23, 2025 at 05:03:40PM +0000, Harrison Mutai wrote:
>>>>>> On 22/01/2025 17:21, Tom Rini wrote:
>>>>>>> On Wed, Jan 15, 2025 at 01:52:06PM +0000, Harrison Mutai wrote:
>>>>>>>
>>>>>>>> When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
>>>>>>>> bloblist present in the incoming standard passage is utilised in-place.
>>>>>>>> There is no need to specify the size of the bloblist as the system
>>>>>>>> automatically detects it using the header information.
>>>>>>>>
>>>>>>>> Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
>>>>>>>> ---
>>>>>>>>      common/Kconfig    | 8 +++++++-
>>>>>>>>      common/bloblist.c | 5 ++++-
>>>>>>>>      2 files changed, 11 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> This leads to failure to boot on qemu-arm-sbsa as seen in CI:
>>>>>>> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
>>>>>>>
>>>>>> Sorry, I'm unfamilliar with U-Boot's CI but I can't make out what the source
>>>>>> of the failure is. All I see in the logs is what looks like an intermittent
>>>>>> error.
>>>>>>
>>>>>> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10392&view=logs&j=ac5e904b-a30c-5e1d-9570-462b8181c990&t=863544fb-ed04-5d34-fdac-10f5bbb057bd&l=423
>>>>>>
>>>>>> Would you be able to share the results XML?
>>>>>
>>>>> The problem is that qemu doesn't start anymore, sorry for being unclear.
>>>>> Looking at
>>>>> https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-arm-sbsa_na?ref_type=heads
>>>>> we can see how qemu is invoked.
>>>>>
>>>>
>>>> I've successfully reproduced and resolved the error. The issue occurred
>>>> because I relaxed the condition for calling the architecture-specific hook
>>>> xferlist_from_boot_arg. Previously, this hook was only called if the
>>>> bloblist was at a fixed address and U-Boot was in the first phase. However,
>>>> since we also need the hook for BLOBLIST_PASSAGE, I've added a condition to
>>>> prevent calling the hook if BLOBLIST_ALLOC is enabled, assuming we don't
>>>> expect to receive a bloblist from the previous stage in this mode.
>>>>
>>>> However, I'm slightly unsure if this assumption is correct. Generally, when
>>>> BLOBLIST_ALLOC is enabled, is it expected that U-Boot will allocate memory
>>>> for the bloblist, ignoring the bloblist from previous stages? In the case of
>>>> BLOBLIST_FIXED, we relocate any bloblist received from the prior stage to
>>>> the fixed address. I'm surprised we don't do the same with BLOBLIST_ALLOC.
>>>
>>> The problem is that today at least yes, BLOBLIST_ALLOC is only viable
>>> for full U-Boot as we don't have a mechanism to pass our own from one
>>> stage to the next unless it's fixed.
>>>
>>
>> To summarize, BLOBLIST_ALLOC is meant to serve as a fallback buffer for
>> internal use when a prior-stage bootloader hasn't provided a bloblist at a
>> fixed address (BLOBLIST_FIXED) or a pointer to a bloblist
>> (BLOBLIST_PASSAGE). From the perspective of a prior-stage bootloader, these
>> are the only relevant options. BLOBLIST_ALLOC is also entirely irrelevant
>> when U-Boot is staged. Have a I missed anything?
> 
> With the perspective of a non-U-Boot prior stage, this is right.
> Ideally, U-Boot should be able to use BLOBLIST_ALLOC in one phase and
> pass bloblist to a later stage. But that's outside of the scope of what
> you're dealing with right now, yes?
> 

That clarifies things for me - thanks! And indeed, my interest is mainly 
in passing information from firmware (i.e., TF-A) to U-Boot.

[PATCH v2 4/4] board: vexpress64: enable bloblist for SPL handoff

[Harrison Mutai]

Enable bloblist on vexpress64 platforms to facilitate information
passing from TF-A using the firmware handoff framework.

Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

---
 board/armltd/vexpress64/Makefile        |  3 ++-
 board/armltd/vexpress64/vexpress64.c    |  4 ++++
 configs/vexpress_fvp_bloblist_defconfig |  5 +++++
 doc/board/armltd/vexpress64.rst         | 16 ++++++++++++++++
 4 files changed, 27 insertions(+), 1 deletion(-)
 create mode 100644 configs/vexpress_fvp_bloblist_defconfig

diff --git a/board/armltd/vexpress64/Makefile b/board/armltd/vexpress64/Makefile
index 1878fbed4e..4729787c5e 100644
--- a/board/armltd/vexpress64/Makefile
+++ b/board/armltd/vexpress64/Makefile
@@ -3,5 +3,6 @@
 # (C) Copyright 2000-2004
 # Wolfgang Denk, DENX Software Engineering, wd@denx.de.
 
-obj-y	:= vexpress64.o lowlevel_init.o
+obj-y	:= vexpress64.o
+obj-$(CONFIG_OF_HAS_PRIOR_STAGE)	:= lowlevel_init.o
 obj-$(CONFIG_TARGET_VEXPRESS64_JUNO)	+= pcie.o
diff --git a/board/armltd/vexpress64/vexpress64.c b/board/armltd/vexpress64/vexpress64.c
index b5ede58757..0b75c1358f 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -100,7 +100,9 @@ int dram_init_banksize(void)
  * Push the variable into the .data section so that it
  * does not get cleared later.
  */
+#ifdef CONFIG_OF_HAS_PRIOR_STAGE
 unsigned long __section(".data") prior_stage_fdt_address[2];
+#endif
 
 #ifdef CONFIG_OF_BOARD
 
@@ -151,6 +153,7 @@ static phys_addr_t find_dtb_in_nor_flash(const char *partname)
 }
 #endif
 
+#ifdef CONFIG_OF_HAS_PRIOR_STAGE
 /*
  * Filter for a valid DTB, as TF-A happens to provide a pointer to some
  * data structure using the DTB format, which we cannot use.
@@ -201,6 +204,7 @@ int board_fdt_blob_setup(void **fdtp)
 	return -ENXIO;
 }
 #endif
+#endif
 
 /* Actual reset is done via PSCI. */
 void reset_cpu(void)
diff --git a/configs/vexpress_fvp_bloblist_defconfig b/configs/vexpress_fvp_bloblist_defconfig
new file mode 100644
index 0000000000..dcc87db872
--- /dev/null
+++ b/configs/vexpress_fvp_bloblist_defconfig
@@ -0,0 +1,5 @@
+#include <configs/vexpress_fvp_defconfig>
+
+CONFIG_BLOBLIST=y
+CONFIG_BLOBLIST_PASSAGE=y
+CONFIG_BLOBLIST_SIZE_RELOC=0x10000
diff --git a/doc/board/armltd/vexpress64.rst b/doc/board/armltd/vexpress64.rst
index a7f771d266..4dadadb53d 100644
--- a/doc/board/armltd/vexpress64.rst
+++ b/doc/board/armltd/vexpress64.rst
@@ -43,6 +43,22 @@ Juno is an Arm development board with the following features:
 
 More details can be found in the board documentation [3]_.
 
+Bloblist Support
+----------------
+
+The ``vexpress_fvp_bloblist_defconfig`` configures U-Boot to be compiled for
+Vexpress64 with Bloblist as the primary method for information handoff between
+boot stages. U-Boot offers three methods to set up a bloblist: using a
+predefined bloblist at a specified address, dynamically allocating memory for a
+bloblist, or utilizing a standard passage-provided bloblist with automatic size
+detection.
+
+By default, ``vexpress_fvp_bloblist_defconfig`` uses the standard passage method
+(CONFIG_BLOBLIST_PASSAGE) because TF-A provides a Transfer List in non-secure
+memory that U-Boot can utilise. This Bloblist, which is referred to as a Transfer List in
+TF-A, contains all necessary data for the handoff process, including DT and ACPI
+tables.
+
 References
 ----------
 
-- 
2.46.2