Re: [PATCH v2 02/10] spl: atf: support Linux as BL33 with TFA

On Fri, Jul 31, 2026 at 10:47 PM Tom Rini <[email protected]> wrote:
>
> On Fri, Jul 31, 2026 at 09:10:46PM +0400, Alexey Charkov wrote:
> > Modern SoCs such as Rockchip RK3576 need TFA to be running to provide
> > firmware services to the OS.
> >
> > Enable the TFA boot flow to allow using Linux as BL33 (including its
> > calling convention) to facilitate Falcon mode boot on such SoCs.
> >
> > Signed-off-by: Alexey Charkov <[email protected]>
> > ---
> >  common/spl/Kconfig   | 22 ++++++++++++++++++++--
> >  common/spl/spl_atf.c | 49 +++++++++++++++++++++++++++++++++----------------
> >  2 files changed, 53 insertions(+), 18 deletions(-)
> >
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > index 0618f42c9410..7c639ed8f763 100644
> > --- a/common/spl/Kconfig
> > +++ b/common/spl/Kconfig
> > @@ -1230,22 +1230,40 @@ config SPL_BOOTZ
> >       help
> >         Boot a linux zimage from memory in falcon boot.
> >
> > +       This provides an entry path which is unused when the OS is entered
> > +       through TF-A, since SPL then only places the kernel in memory and
> > +       BL31 is what enters it. It remains selectable: SPL can still enter
> > +       a kernel itself on such a platform, dropping to EL2 without TF-A
> > +       resident, just without any firmware services being available to the
> > +       OS afterwards.
> > +
> >  config SPL_BOOTI
> >       bool "Allow booting an Image style Linux kernel from SPL"
> >       depends on SPL_OS_BOOT && !SPL_OS_BOOT_SECURE
> > -     default y if ARM64 || RISCV
> > +     default y if (ARM64 || RISCV) && !SPL_ATF
> >       select SPL_LIB_BOOTI
> >       help
> >         Boot an uncompressed linux kernel image from memory in falcon boot.
> >
> > +       This provides an entry path which is unused when the OS is entered
> > +       through TF-A, since SPL then only places the kernel in memory and
> > +       BL31 is what enters it, so it does not default to y in that case. It
> > +       remains selectable: SPL can still enter a kernel itself on such a
> > +       platform, dropping to EL2 without TF-A resident, just without any
> > +       firmware services being available to the OS afterwards.
> > +
> >  config SPL_OS_BOOT_ARGS
> >       bool "Allow SPL to load args for kernel in falcon mode"
> >       depends on (SPL_OS_BOOT || SPL_LOAD_FIT_OPENSBI_OS_BOOT) && !SPL_OS_BOOT_SECURE
> > -     default y if !SPL_OS_BOOT_SECURE
> > +     default y if !SPL_OS_BOOT_SECURE && !SPL_ATF
> >       help
> >         This option enables the SPL to load an args file (usually the FDT)
> >         alongside the kernel image in falcon boot mode.
> >
> > +       This is not needed when the OS is entered through TF-A, since the
> > +       device tree is then taken from the same FIT as the kernel, which is
> > +       why it does not default to y in that case.
> > +
> >  config SPL_PAYLOAD_ARGS_ADDR
> >       hex "Address in memory to load 'args' file for Falcon Mode to"
> >       depends on SPL_OS_BOOT_ARGS
>
> Expanding on the help text is good. I'm not immediately sure on changing
> the default statements however. Maybe the changes are fine but just need
> a bit of a rewording to be a tiny bit more concise, the "which is why it
> does not default to y in that case" can probably be dropped and you just
> add text explaining when it's not appropriate to enable.

Makes sense, thank you, will distill in v3.

The change in defaults for SPL_OS_BOOT_ARGS also helps avoid the
prompt for SPL_PAYLOAD_ARGS_ADDR when selecting Falcon mode with ATF.
Otherwise it breaks non-interactive builds by endlessly asking for a
value (it has no default of its own, and there isn't any meaningful
arch-independent default to consider), even though that value is never
used in this configuration.

SPL_BOOTI and SPL_BOOTZ don't hurt, but are simply not useful here, so
I thought excluding them from defaults here would make more sense than
disabling them in every defconfig which wants to enable Falcon with
ATF.

Best regards,
Alexey