Re: [docs] [RFC PATCH 1/1] ref-manual: add boot architecture documentation

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Jon,

On 3/31/26 10:06 PM, Jon Mason wrote:
> Hello Quentin,
> Thank you for taking the time to look this over and provide feedback.
> 
> Work email is outlook and I wasn't smart enough to cc myself on the initial email.  So, I've had to get creative with the inline responses below (via cut-n-paste and vim).  Please forgive that.
> 

You can download an .mbox.gz or Atom feed from lore.kernel.org directly, 
see at the bottom of 
https://lore.kernel.org/yocto-docs/20260331122924.54516-1-jon.mason@arm.com/T/#t.

On Thunderbird (which I use instead of Outlook to access my Microsoft 
Outlook company emails), you can then use ImportExportNG plugin to 
import the (first uncompressed) .mbox to have it in Thunderbird as if 
you had received it. I used to know how to bounce a mail from one 
address to another but I couldn't find that on Thunderbird last time I 
checked, that could have been another option.

> 
>> From: Quentin Schulz <quentin.schulz@cherry.de>
>> Date: Tuesday, March 31, 2026 at 9:53 AM
>> To: Jon Mason <Jon.Mason@arm.com>, docs@lists.yoctoproject.org <docs@lists.yoctoproject.org>
>> Subject: Re: [docs] [RFC PATCH 1/1] ref-manual: add boot architecture documentation
>>
>> Hi Jon,
>>
>> On 3/31/26 2:29 PM, Jon Mason via lists.yoctoproject.org wrote:

[...]

>>> +firmware is usually platform-specific and typically has fewer
>>> +interchangeable implementations than later boot stages.
>>> +
>>> +Examples include:
>>> +
>>> +* Trusted Firmware-A (TF-A)
>>> +* Trusted Firmware-M (TF-M), where applicable
>>> +* System Control Processor (SCP) firmware
>>> +* OpenSBI, which implements the Supervisor Binary Interface (SBI)
>>> +
>>
>> This is not correct for at least Rockchip SoCs. I think it's also not
>> correct for Allwinner SoCs. I **think** TI may be doing this but I have
>> never worked with their SoCs. For Rockchip, a TPL/SPL is loaded first,
>> and then it loads a U-Boot FIT with TF-A, OP-TEE OS and U-Boot proper.
>> So if you will, one boots a first part of the System Firmware, which
>> loads the Platform Firmware which in turn loads the second part of the
>> System Firmware.
>>
>> Note also that people are increasingly wanting to have TF-A/OP-TEE OS as
>> late as possible in the boot process, and I've seen implementations
>> where TF-A is part of the kernel FIT image. This allows to easily update
>> those persistent and security-critical components without requiring a
>> risky bootloader (here called System Firmware) update.
>>
>> I think this may make things even more confusing since the boot process
>> clearly won't be identical for all Aarch64 SoC vendors (at least for the
>> time being) and won't match the documentation. Do you have a plan on how
>> to handle that?
> 
> And this is the reason why this is an RFC :)
> 
> I was not aware this is how things are being used in some of the SoCs.  I guess this would provide a fallback if something is broken during an update.  I'm not sure it is worth the extra layers of indirection and potential for that potentially being broken, but probably no point in arguing that here.
> 

I am not following here, what is "this" starting from the second sentence?

> My intention in this document is to provide a rough idea of how boot works and show what is mutually exclusive, and the logic behind it.  Perhaps there is a way to rewrite this to allow for it to be generic enough to cover the straightforward way I was saying and the indirect way you are saying is used.  I'll see what I can do regarding this in v2.
> 
It isn't path A or path B.

[...]

>>> +Examples include:
>>> +
>>> +* GRUB
>>> +* Syslinux / EXTLINUX
>>> +* systemd-boot
>>> +
>>> +In Yocto Project builds this layer can also be selected through a
>>> +virtual provider.
>>> +
>>> +The name ``virtual/boot-manager`` reflects the role of this software in
>>> +selecting and loading an operating system kernel from storage.
>>> +
>>> +Example configuration::
>>> +
>>> +   PREFERRED_PROVIDER_virtual/boot-manager = "grub-efi"
>>> +
>>> +Some systems boot the kernel directly from system firmware (for example
>>> +U-Boot or UEFI). In these cases an additional OS loader is not required.
>>> +
>>
>> What do we do when we're expecting to use the extlinux implementation in
>> U-Boot? Or another implementation? How is this going to be handled?
>> Technically, it **is** syslinux/extlinux, just that the extlinux.conf
>> file needs to be in a bootable partition readable by U-Boot proper (the
>> System Firmware).
> 
> This is the case that I was trying to reference.  The case where you are trying to make sure that grub or systemd-boot isn't used (and thus shouldn't be added to the image).
> I'll clean-up the language to make it clearer.
> 

Wondering if we cannot have U-Boot extlinux boot a UEFI payload (e.g. 
grub). It seems like you can boot a FIT which contains a UEFI binary 
(I'm assuming grub). You can then simply get this FIT using extlinux I'm 
assuming still.

>>> +Example::
>>> +
>>> +   PREFERRED_PROVIDER_virtual/boot-manager = "none"
>>> +
>>> +
>>> +Boot Process by Architecture
>>> +----------------------------
>>> +
>>> +
>>> +Arm (Arm32)
>>> +~~~~~~~~~~~
>>
>>
>>
>> I've seen Aarch32 being used also. The wikipedia page
>> (https://en.wikipedia.org/wiki/ARM_architecture_family) hints at Aarch32
>> being Armv7+ and Arm32 being Armv6-, is this what you wanted to convey?
>>
>> Working at arm I guess it's the kind of information you'd have access
>> to, but then what matters between what marketing says it is and what the
>> public believes it is...
> 
> There is an ARMv8 core that is 32bit only (A32), there are others that are 64bit only, and there are a lot that do both.  I'm not trying to muddy the waters here, but more trying to say that there is the legacy 32bit way of doing things ("the easy way" is how I have it in my mind).
> 
> I didn't think that Aarch32 was used outside of Arm, but if that is less confusing then I'm happy to replace Arm32 with Aarch32, or write it in a way more understandable
> 

I meant Aarch32 is for 32b Armv7+ cores and Arm32 for 32b Armv6- cores. 
I guess just make it explicit what the 32/64 part of the name comes from 
(and potentially mention it can be called Arm32/Aarch32. (We won't say 
anything about arm in the Linux kernel meaning Arm32, no we won't :) ).

>>
>>> +
>>> +Many Arm32 systems boot directly into U-Boot using its SPL stage.
>>> +
>>> +::
>>> +
>>> +   Boot ROM
>>> +      ↓
>>> +   U-Boot SPL
>>> +      ↓
>>> +   U-Boot
>>> +      ↓
>>> +   Linux Kernel
>>> +
>>> +
>>> +Arm64 (AArch64)
>>> +~~~~~~~~~~~~~~~
>>> +
>>> +Arm64 platforms commonly include Trusted Firmware-A prior to the
>>> +main boot firmware.
>>> +
>>
>>
>>
>> Which SoCs vendors do that? Rockchip doesn't for sure. Allwinner I think
>> as well. TI may. Unsure about the others. Or is this something specific
>> to ACPI-supported Aarch64 platforms?
> 
> The Arm reference platforms do it this way, but the point you made above that others don't has me reconsidering how to make this more complete.  Perhaps an "Option A" and "Option B" that has both ways.
> 

I think there are N options, with N increasing every year.

FYI, on some Arm32 Rockchip SoCs, I believe OP-TEE OS (BL32) is required 
to boot.

Also, Platform Firmware may load another Platform Firmware. That is the 
case on Rockchip SoCs with U-Boot SPL jumps into TF-A as BL31 which in 
turn jumps into OP-TEE OS as BL32 which in turn jumps into U-Boot proper.

Also, when I say "Rockchip SoCs", I mean what we've settled for as the 
"default" boot process. I'm not sure there's anything forbidding you 
from having a different boot flow.

Note also that there's some people (mainly Simon Glass at that point I 
think) about VBE (Verified Boot for Embedded) which is yet another boot 
flow.

Is there any plan to integrate with update software like swupdate/rauc? 
UEFI-supporting U-Boot seems to support update capsules, I see patches 
on the U-Boot ML every now and then for adding capsules to Qualcomm, 
Samsung, Amlogic, Raspberry Pi, NXP, TI, ... devices.

For the sake of completeness, know that Rockchip provides binary blobs 
for the DDR init (which we call TPL because it's there to replace U-Boot 
TPL until there's an open-source implem), (ancient) TF-A and OP-TEE OS 
(as far as I know incompatible with upstream U-Boot). We've plumbing in 
meta-rockchip to allow picking between blob TF-A or upstream TF-A. Not 
sure it's important for you, but at least it's out there now :)

[...]

I think the part we're (I am) missing here, is what you're trying to 
achieve or improve or change. But maybe I'm too early in the discussion 
(especially since only the docs people are in Cc :) ) and this will be 
part of the patch series with the actual implementation. Maybe provide a 
bird eye view on what's the plan in the cover letter to help us out?

Cheers,
Quentin