Re: [PATCH v2 01/10] spl: Decide about Falcon mode boot only once

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