On 7/22/2024 2:45 PM, Daniel Thompson wrote:
> On Fri, Jul 19, 2024 at 07:51:26PM +0000, Ghennadi Procopciuc wrote:
>>> Yes, ideally this is what EBBR recommends as the second-best option (the
>>> best
>>> option being to use a dedicated storage).
>>
>> Ok, I thought that the ideal case is when all firmware images are stored on a
>> dedicated storage device or hardware logical unit (UFS LU or eMMC boot
>> partition), and that device or LU is formatted with FAT filesystem where each
>> file can be referenced by name rather than by an offset. At least this is
>> what
>> 'Where possible, firmware images and data should be stored in a filesystem'
>> suggested to me, the reason being iterated later: ' Using a filesystem makes
>> it
>> simpler to manage multiple firmware files and makes it possible for a single
>> disk image to contain firmware for various platforms.' Using a filesystem
>> makes it simpler to manage multiple firmware files and makes it possible for
>> a
>> single disk image to contain firmware for multiple platforms'.
>
> I think section 4.2 ends up being a rather unclear about what it applies
> to.
>
> To be honest I have long thought that is only applied to shared storage
> (e.g. where firmware and OS are both included in partitions from a
> single GPT/MBR). However I can see it could be read differently.
>
> In particular note that the ESP "belongs" to the OS so firmware stored
> in an ESP does imply shared storage or at least the that ESP exists
> on media that is controlled by the OS.
>
Could this section be updated in order to reduce the number of different
interpretations?
>
>> I understand there are cases when, due to various factors, everything will be
>> placed on the same storage memory (no LU), as described in 'Partitioning of
>> Shared Storage', but I was referring to cases when separate storage can be
>> dedicated for firmware images.
>>
>>>> 2. If so, would this also mean that, where possible, the BootROM or a
>>>> (first
>>> stage) bootloader running before TF-A
>>>> should have GPT and FAT support embedded support to load one of
>>>> the TF-
>>> A stages (BL1/BL2)?
>>>
>>> Yes. This is not as crazy as it sounds; I know some Texan SoCs from a
>>> decade ago,
>>> which had FAT + MBR support in ROM.
>>> Alternatively, U-Boot SPL as a first stage bootloader, as you mentioned,
>>> would tick
>>> all the boxes, too. This might be easier to fit in a small, dedicated
>>> storage.
>>>
>>
>> In my question, I considered a case where the platform contains a System
>> Control
>> Processor that boots first and acts as a first-stage bootloader as well. I
>> assumed
>> that this bootloader runs on a different CPU/type of core than the TF-A and
>> U-Boot and uses different storage than firmware images used for the core(s)
>> involved in the second-stage bootloader's execution.
>> Here is the assumed bootflow:
>> BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> Linux
>>
>> This way, the storage and the CPU execution are entirely isolated from each
>> other.
>>
>> On the other hand, from what I understand, the boot flow described in your
>> reply looks like this:
>> BootROM -> U-Boot SPL -> BL2 -> BL31 -> U-Boot -> Linux
>>
>> In this example, the same core executes all bootloaders starting with U-Boot
>> SPL. While the BL2, BL31, and U-Boot are somehow stored in a FAT32
>> partition, the U-Boot SPL is stored in a raw format and loaded by the
>> BootROM by an offset.
>>
>> I'm a bit puzzled because I assumed all firmware images, including U-Boot
>> SPL, should be placed in the same FAT partition. Given that in this example,
>> we have a mix of offset-based (U-Boot SPL) and filesystem-stored binaries,
>> it seems that I misunderstood some aspects of EBBR.
>
> I think what might be missed here is that some of what appears in
> section 4 is effectively advisory information for boot ROM authors. If
> you are working with a chip whose boot ROM is incompatible with these
> recommendations (by loading something from a fixed offset) it is
> impossible (or at least extremely impractical) to fully follow the
> advice w.r.t. loading firmware from a filesystem.
>
> This need to work with chips whose boot ROMs prevent the use of a
> filesystem leads to a lot of the section 4 complexity. It is also
> why this section is merely recommended ("should") rather than required
> ("shall").
>
>
>> Or, I may have wrongly interpreted your answer. Could you please provide
>> more details?
>> Maybe a dumb question: could you clarify what the term 'firmware' refers to
>> when used in EBBR?
>
> EBBR separates the world into firmware and OS and the dividing line
> between them is EFI (exactly as it would be on a modern PC). Whether
> you boot on the main core or via a co-processor between boot ROM
> and OS is "firmware".
>
> If I were to edit your first assumed bootflow as an example it becomes:
>
> BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> grub -> Linux
> Provided by: ROM f/w f/w f/w f/w OS OS
>
> Note that you can also replace "grub" with "systemd-boot", "UKI/systemd
> stub" or any other OS controlled bootloader[1].
>
In this example, SCP, BL2, BL31 and U-Boot shall all be part of the FAT
partition given their firmware classification. If so, then BootROM, SCP,
and BL2, all of which can load images, must also be able to load their
next stages from FAT. Is that right?
Regards,
Ghennadi
_______________________________________________
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
