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 <[email protected]> > > > > > --- > > > > > 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
signature.asc
Description: PGP signature
