Hi Simon, On Tue, Aug 4, 2026 at 5:29 PM Alexey Charkov <[email protected]> wrote: > > Hi Simon, > > On Tue, Aug 4, 2026 at 5:02 PM Simon Glass <[email protected]> wrote: > > > > Hi Alexey, > > > > On 2026-07-31T17:10:44, Alexey Charkov <[email protected]> wrote: [...] > > > diff --git a/common/spl/spl.c b/common/spl/spl.c > > > @@ -105,6 +105,24 @@ __weak int spl_start_uboot(void) > > > +bool spl_falcon_boot(void) > > > +{ > > > + static int falcon = -1; > > > > Minor - since the return type is bool, I'd find it cleaner to use two > > bools (result and 'decided'), or an enum, rather than overloading an > > int with a -1 sentinel. It also keeps the value out of .data, which > > matters a little in SPL. > > Sounds good, will adjust in the next version.
Interestingly, the conversion to two bools on .bss turns out to be heavyweight enough to push the am335x_evm SPL image 8 bytes over its SRAM size [1]. The .data section shrinks by 3 bytes, but the .text section grows by 16 bytes compared to my v2 version, and it no longer fits :) I'm now thinking if it would make more sense to have the spl_atf handover function skip looking into the FIT contents and just trust that the loader selected the right one based on a one-off spl_start_uboot() reading - then I could skip the caching helper and wouldn't need to add any new global state, so there should not be any size impact. An edge case here would be a FIT containing BOTH a Linux kernel and a U-Boot proper (nothing technically prevents that, even though the binman template I'm adding as part of this series doesn't do that). There won't be any way to select which one to pick from the FIT at runtime anymore. Or somehow make the caching helper only apply to SPL_ATF devices (am335x_evm isn't one), although that sounds a bit cludgy. Any thoughts welcome! [1] https://git.u-boot-project.org/u-boot/contributors/alchark/u-boot/-/jobs/62374 Best regards, Alexey
