Hi Julius,
>> that doesn't care that much about boot speed, why wouldn't you just use FDT? [RK]I think you answered this question yourself. “there may not be a one-size-fits-all solution”. Can we use it? Yes! Do we want to use it, probably not, in a given context. UEFI HOB I think would fall in between for complexity and flexibility and you yourself said “They are intentionally on opposite ends of the complexity spectrum”. Two opposite ends may not fit the bill. There are perceptions around FDT too, just as there are perceptions around UEFI HOB. Bloblist, is also in-between the two complexity spectrums and I think it was said that may turn out to be acceptable with potential tweaks to tag assignment etc. To quote earlier emails: I understand the versatility of DT, but I see two major problems with DT: * DT requires more complicated parsing to get properties, and even more complex to dynamically set properties – this HOB structures may need to be generated in boot phases where DDR is not available, and therefore we will be extremely memory constrained. * DT is probably overkill for this purpose – We really just want a list of pointers to simple C structures that code cast (e.g. JEDEC SPD data blob) >> but then why would we replace it with a different mechanism that also has >> complexity and performance problems? >> and it should certainly be flexible enough to fill your needs [RK] I concede that this is your view but others may view UEFI HOB’s as not as complex and more performant than FDT. You may not agree with this assessment, but we can agree to disagree. Also, having this debate in itself proves that there are folks that think what is currently in TF-A does not meet needs of more than few ARM platform vendors. You assumption that FDT should be flexible enough to fill our needs is incorrect. >> 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. [RK] Agree. EDK2 has been around a lot longer and changing all of EDK2 to use FDT is likely a harder path and larger effort. Incorporating UEFI compatibility into TF-A(given that it runs before UEFI starts) has general ARM adoption benefits in many market segments that you may not work on or care about. As for maintenance burden, sure, anything that you add has extra burden but if the benefits outweigh the burden, we should consider it, and obviously I think it does. If the options are well managed, I think we should be fine burden wise. >> 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). [RK] I don’t think the intent of the proposal was “one HOB format to rule them all”. Perhaps you should read the earlier emails again. It only explains why FDT may not work for certain market segments and why HOB may be useful and a better fit in UEFI platforms. I wouldn’t dismiss the benefit to UEFI users as they are just as much a part of the ARM ecosystem as users of any other boot loader. >> 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. [RK] Not trying to find fault at all with the design. Just saying it may not work very well the way it is today for some systems and may be perfect for other systems! Thanks Raghu From: Julius Werner <jwer...@chromium.org> Sent: Monday, March 29, 2021 4:48 PM To: raghu.ncst...@icloud.com Cc: Julius Werner <jwer...@chromium.org>; Simon Glass <s...@chromium.org>; Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture@lists.linaro.org>; U-Boot Mailing List <u-b...@lists.denx.de>; Paul Isaac's <paul.isa...@linaro.org>; Ron Minnich <rminn...@google.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
