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

[Harrison Mutai <harrison.mutai@arm.com>]

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.