[PATCH 1/4] spl: atf: support Linux as BL33 with ATF

[Alexey Charkov]

On Wed, Jun 10, 2026 at 8:00 AM Marek Vasut <marek.vasut at mailbox.org> wrote:
>
> On 6/9/26 6:52 PM, Alexey Charkov wrote:
> > Modern SoCs such as Rockchip RK3576 need ATF to be running to provide
> > firmware services to the OS.
> >
> > Enable the ATF boot flow to allow using Linux as BL33 (including its
> > calling convention) to facilitate Falcon mode boot on such SoCs.
>
> TFA

Ok, thanks. The whole file is saying atf though :)

I have to admit I'm still confused with all the naming. My latest
understanding has been that ATF is the whole firmware including both
non-secure BL31 and secure BL32, with TF-A being the upstream
opensource implementation for the BL31 part, and OP-TEE being the
upstream opensource implementation for the BL32 part (or is this part
TEE-OS?).

Anyway, happy to rename.

> > +/* BL33 defaults to U-Boot unless Falcon mode selects Linux. */
> > +static int spl_atf_bl33_os;
> > +
>
> Can we avoid this global static variable ?

Yep, let me try to refactor to drop it.

> >   /* Holds all the structures we need for bl31 parameter passing */
> >   struct bl2_to_bl31_params_mem {
> >       struct bl31_params bl31_params;
> > @@ -87,8 +90,11 @@ struct bl31_params *bl2_plat_get_bl31_params_default(ulong bl32_entry,
> >       SET_PARAM_HEAD(bl33_ep_info, ATF_PARAM_EP, ATF_VERSION_1,
> >                      ATF_EP_NON_SECURE);
> >
> > -     /* BL33 expects to receive the primary CPU MPID (through x0) */
>
> That seems a bit inconsistent, and not quite right. Do you know where
> U-Boot expects primary CPU ID in x0 exactly ? Which part of U-Boot code
> depends on it ?

That was pre-existing logic and comment, so I left it in place to
avoid unintentionally breaking someone's setup. Happy to try and drop
it, but I only have an assortment of Rockchip RK3576 based boards to
test it on, which won't be very representative.

> > -     bl33_ep_info->args.arg0 = 0xffff & read_mpidr();
> > +     /* Linux-at-BL33 expects DTB in x0, U-Boot expects primary CPU MPID in x0. */
> > +     if (IS_ENABLED(CONFIG_SPL_OS_BOOT) && spl_atf_bl33_os == IH_OS_LINUX)
> > +             bl33_ep_info->args.arg0 = fdt_addr;
> > +     else
> > +             bl33_ep_info->args.arg0 = 0xffff & read_mpidr();
>
> [...]
>
> > @@ -269,15 +279,22 @@ void __noreturn spl_invoke_atf(struct spl_image_info *spl_image)
> >               bl32_entry = spl_fit_images_get_entry(blob, node);
> >
> >       /*
> > -      * Find the U-Boot binary (in /fit-images) load addreess or
> > -      * entry point (if different) and pass it as the BL3-3 entry
> > -      * point.
> > -      * This will need to be extended to support Falcon mode.
> > +      * Find BL33 entry point. In Falcon mode, prefer Linux when requested.
> > +      * Fall back to U-Boot if Linux cannot be resolved.
> That does not seem correct, if Linux cannot be resolved, then the system
> should stop booting, falling back into a bootloader could be security
> risk. There is a "recovery" boot weak symbol function, which can be used
> to start fallback bootloader, but that has to be deliberately
> implemented and triggered by the user e.g. by holding a button down.

I thought from reading existing documentation [1] that "plain" Falcon
mode is supposed to fall back to U-boot, while "secure" Falcon mode
should fail. Which prompts me to at least add a fail path for the case
when SPL_OS_BOOT_SECURE is enabled.

[1] https://docs.u-boot.org/en/stable/develop/falcon.html#fallback-mechanism

Thanks for looking into this Marek!

Best regards,
Alexey