I'm trying to make the case for "unifying payload handoff formats between different firmwares is generally not a useful idea
MBR called to disagree.
What's MBR in this context -- Master Boot Record? Kernel handoff and firmware payload handoff are two entirely different ballparks here.
That said, I wouldn't worry about negative effects. I certainly have no interest to remove coreboot tables nor do I see any reason to do so nor have I seen anyone mention anything in that direction.
Do not make up strawmen.
I'm gonna try to ignore this and all the other slight jabs and personal attacks afterwards because I don't think it's productive or going to help us find a compromise. Throughout the whole rest of this thread it seems like everyone had a friendly and respectful discussion despite our technical differences in opinion, let's please try to keep it that way (especially since it seems like we have basically found a compromise that we can all live with already anyway).
Just so you understand where I'm coming from, Arthur's very first comment on the original changelist asked whether it is "a good idea to use FDT and eventually replace coreboot tables", and I think several others (maybe not you) had still hinted at that as a long-term goal a few times. So I'm not trying to "waste your time" with "strawmen", I'm just trying to make sure we're on the same page on this because it is important to me.
A RAM-less FDT parser probably doesn't need to load the entire tree but merely find one value at a time, perhaps without state between values. The complexity of that in an FDT is low since FDT is flat and has simple primitives. CBOR, well..
[...]
This is bizarrely complex for storing a simple scalar.
It just takes an AND and a switch to decode? I honestly think you're overestimating this. I've written a CBOR parser before (and most parts of an FDT parser, for that matter) and it's really not a big deal. In fact looking for a single value might be easier in CBOR because the data is entirely local, whereas with FDT you at least need to juggle the separate string table. (Then again FDT makes it a little easier to skip over unrelated parts of the tree when looking for a single item, so there are certainly trade-offs)
I disagree with abandoning coreboot tables or forcing FDT generator code into coreboot images for those who aren't interested in this project.
So a way forward where you can ignore FDT is for coreboot tables to stay as-is, and a Kconfig option to make coreboot use its coreboot tables to generate an FDT.
Yes, that approach is fine by me. It's not as efficient for your case as generating the FDT directly, of course, but if you want to do it this way I won't complain.
and since the argument for coreboot tables is mostly simplicity / lean code it's not a solution for that side to just generate both.
If you mean "it's not a solution for coreboot to just generate both" then I ask why not? Two things can be true at the same time: coreboot tables are simple to generate and the code to generate FDT from coreboot tables is also simple.
I meant that it wouldn't be a solution to do it unconditionally, because my main argument against FDT is that I don't want that extra bloat for configurations that don't use the FDT. If we have a Kconfig to decide between coreboot-table-only and coreboot-table+FDT, that works for me.
This is not about 64-bit values which you mentioned in your first email, this is about struct member offsets in the struct.
The structs are not packed so the compiler decides.
This is why both Nico and I are so strong proponents of explicit serialization of the tables. (I'd also like to create new tags for coreboot tables with packed values but that's another matter.)
There is no padding in coreboot tables. We intentionally arrange members such that they don't leave padding holes and insert explicit `unused` members where necessary. This is a common pattern in a lot of structures where exact data layout is important (e.g. those representing hardware registers as well). Using __attribute__((packed)) is usually a bad idea and should be avoided unless really necessary (i.e. in cases where individual members need to be explicitly misaligned), because it forces the compiler to assume that all loads may be misaligned and leads to bad code generation on architectures that can't tolerate unaligned accesses in all cases.
FWIW I think this is a completely separate discussion and has nothing to do with what we should do for payload handoff (again, just like with the FSP thing, kernel handoff is a completely different thing that would have very little to share with it).
If all handoff interfaces were to use a single format (this would be great) then obviously it can be a single data set, which would make life simpler for a lot of different people.
The information that is being passed from coreboot to payloads and from the payload to kernels is so fundamentally different that there would be very little overlap (maybe not in the cases where the memory table is the only thing you have in your payload handoff, but certainly in those that actually have enough records to make it worth worrying about the format). Besides, kernel handoff formats tend to differ widely between architectures which I don't think is something we want to duplicate at the payload boundary.