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.