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=lo...
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=lo...
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/... 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