Hi Alexey, On Fri, 7 Aug 2026 at 01:38, Alexey Charkov <[email protected]> wrote: > > 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.
That seems reasonable to me - the edge case seems very unlikely and possibly broken. > > 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! Regards, Simon > > [1] > https://git.u-boot-project.org/u-boot/contributors/alchark/u-boot/-/jobs/62374
