> > Questions:
> > 1. Does the above paragraph mean that, if the device allows, all
> > firmware
> binaries (TF-A, U-Boot, and some others)
> > must be stored in a dedicated firmware partition formatted with a
> > FAT
> filesystem and GUID Partition Table (GPT)
> > disk layout?
>
> Hi Ghennadi,
Hi Vincent,
Thank you for taking the time to provide the answers!
> 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 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.
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?
Regards,
Ghennadi
_______________________________________________
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
