> - "bloblist" is a general term for concept of linked list and it's not exactly U-boot implementation. The proposed solution will cause some degree of changes in all the participating projects. For backward compatibility issue, we have already though about it and proposed to have build configs which will be enabled by platform integrators.
Okay, let's gather the requirements and then decide how the existing
system needs to be expanded to meet them. Please keep me in the loop
on those discussions.
> > U-Boot has an established mechanism which is used in particular on all chrome
> > books in both x86 and Arm environments. I have the impression that
> > U-Boot is the typical BL33 so I would import the mechanism into TFA,
> > not the other way round.
There has been no Chromebook (x86 or Arm) shipping with U-Boot since
2013 (before TF-A existed). In fact, Chromebooks are all running
coreboot today and using the bl_aux_params mechanism (it's 3 SoC
vendors, more than 3 SoCs, but the parameter code is shared at the
vendor level), and one of my concerns here is trying to limit
disruption to those existing setups. I don't have enough data to say
what the "typical" boot flow among all TF-A devices in existence is,
but at least for the millions of Chromebooks out there it is coreboot
+ TF-A, not U-Boot.
My bad! I candidly inferred from Chromebook reference in U-Boot and Simon's VBE proposal that U-Boot was used.
This is a bit off-topic, but it is somewhat in the reverse. U-Boot's verified boot (2014 I think) uses the crypto from Chromium OS (which I think came from Android at some point). VBE is an attempt to provide a standard boot flow for U-Boot devices and is again heavily influenced by Chromium OS. U-Boot does ship on most Chromebooks (oddly enough, not the ARM ones!) but just as an alternate bootloader and is not used in the verified-boot flow. I won't get into the details of how the Chroimum OS replacement came about, as that is way off topic!
Is that the right place?
There is not a huge amount of code in TF-A that uses it (mediatek and rockchip?) so I don't see a problem with updating it, given the benefits of interoperability.
In fact, having taken a bit of a look, my view is that U-Boot's bloblist is a much better starting point for this effort:
- fuller implementation with more features
- has comments / more documentation
- easily supports everything in one block instead of a linked list (easier to allocate)
- avoids 64-bit tags/size which seem quite unnecessary
- has unit tests
plus some minor points I won't mention. So I think it is worth the pain to switch TF-A over.
Perhaps we can gather the requirements that are needed for this? So far I am aware of:
- devicetree bob tag
- vendor-private tag area
- ability to link to another bloblist (do we really need this?)
Regards,
Simon