[TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Julius Werner]

Hi Raghu,


> It appears there are opinions you carry around UUID being complicated,
> bloated, code being an eyesore, parsing these lists early with MMU/Caches
> disabled, calculating checksums etc. While there is certainly a LOT of
> truth to those statements, these concerns need to be put into context and
> may not necessarily apply to all platforms running TF-A. Standardization
> and interoperability may be valued more on some platforms and some of the
> bloat and performance issues may be worth those tradeoffs. Some of these
> concerns may not even apply on powerful CPU’s and SoC’s with lots of
> memory. Also a quick grep for “uuid” in the TF-A repository shows that
> there is significant use of UUID’s for FIP, some SMC’s, secure partitions
> etc so use of UUID is not something new to TF-A.
>

Granted, I understand that different platforms have different requirements,
and there may not be a one-size-fits-all solution for this. But if you have
a system with a powerful CPU and lots of memory that doesn't care that much
about boot speed, why wouldn't you just use FDT? I thought FDT is already
established on many platforms to pass information between TF-A boot stages
today, and it should certainly be flexible enough to fill your needs. Most
of the earlier discussion in this thread seemed to focus on people wanting
a different mechanism besides FDT because FDT is complex and not performant
enough for all use cases, but then why would we replace it with a different
mechanism that also has complexity and performance problems?

Basically, as far as I'm aware there are two established mechanisms to pass
data between boot stages in TF-A today (some platforms, like Rockchip's,
even support both of them at once): passing an FDT and the bl_aux_params
linked list. They are intentionally on opposite ends of the complexity
spectrum because different platforms can have different needs. The question
is really just whether we need to add a third one, and whether that offers
anything that the other two can't already cover. I guess we can support the
exact UEFI HOB format just to make things easier for UEFI users, and maybe
that's okay, but it does add maintenance burden to TF-A to support so many
different things and we should at least consider if the UEFI part couldn't
just translate its stuff into an FDT instead. But mainly, the way this
thread started it sounded more like "we want to standardize on a new HOB
format that will be used by everyone", and for that goal, I think sticking
with what we have would make a lot more sense for TF-A. If UEFI HOB support
was added in addition then I think only UEFI users would really gain any
benefit from that, and that mechanism would only end up getting used by
UEFI platforms (which again, maybe that's okay, but I'm just saying I don't
think this is going to become some great new "one HOB format to rule them
all" design if it doesn't do anything better than the established FDT
format already does).


> Does the method mentioned below allow you to create a dynamic list of
> arbitrary lengths and NOT lists of lengths decided at compile time? It
> appears that it is mainly being used on lists fixed at compile time.
>

The bl_aux_params list elements don't need to have a fixed size. The only
common thing about each element is the tag (and the next pointer),
everything else (including size) is tag-specific. You can just define a new
tag where the next uint64_t after the next pointer defines the size of the
rest of the element or something like that. Heck, you can even have the
list element contain pointers to other random stuff in memory that isn't
directly part of the list. (The whole thing is not consecutive in memory
anyway. It's not designed to be a serializable, persistent thing like an
FDT blob, just something that a calling bootloader stage can quickly
assemble in its own memory right before handoff and that will only stay
valid until the next stage is done parsing it and starts reusing available
memory for its own purposes.)


> Clearly the solution below was tailored to coreboot.
>
>
Not really, it was just the simplest flexible design I could come up with
at the point. The APIs upstream is in the TF-A repo and coreboot (and other
software) can include it from there.