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

[Marek Vasut]

On 6/10/26 9:51 AM, Alexey Charkov wrote:
> 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 suspect they renamed it because of naming collision with 
https://en.wikipedia.org/wiki/Bureau_of_Alcohol,_Tobacco,_Firearms_and_Explosives 
.

> 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

TF-A ... Trusted Firmware for the A-cores .

> , and OP-TEE being the
> upstream opensource implementation for the BL32 part (or is this part
> TEE-OS?).

OPTEE-OS is implementation of TEE (trusted execution env.), one of many.

> 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.

Please dig through the code a bit, see if this MPIDR passing is even 
needed, it might not be. Iit also smells a bit bogus, since MPIDR uses 
full 32bits of the register to encode core position, so why is there the 
0xffff is not clear to me.

>>> -     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.
Ahh, now I see it, thank you for the clarification.