> > 1. You said that coreboot tables were GPLv2 licensed, and this could
> > be an adoption problem for payloads...
>
> The only generator code I know is GPLv2.
>
> One could argue that only coreboot should ever generate this format,
> but I think one goal here is to enable or even encourage new situations.
Yes, I think only coreboot should ever generate this format. I'm
certainly not trying to make a case for "we should get other firmware
projects to adopt coreboot tables" here, I don't think that makes any
sense. I'm trying to make the case for "unifying payload handoff
formats between different firmwares is generally not a useful idea and
not worth the cost".
> > I think the fundamental question here is still: what do we want to
> > achieve, and how does replacing coreboot tables with something else
> > help with that.
>
> This isn't just a technical change, for me there is also the more
> political goal to make more of what Intel does with USF going forward
> (please see https://github.com/UniversalScalableFirmware/Introduction/blob/main/USF_Overview.pdf )
> maximally useful for and within the coreboot context, ideally while
> encouraging reuse.
>
> Since Intel has planned to use CBOR and are unlikely to use coreboot
> tables for anything outside of coreboot I see using FDT as a way to
> improve the situation for everyone while making players come together
> more - that's an unusually rare win-win.
>
> I strongly prefer FDT over CBOR. FDT is simple on byte level, which I
> find important to not lose the simplicity of coreboot tables. FDT can
> easily be parsed without RAM, CBOR not so much.
I'm a bit confused by the hate for CBOR here to be honest, I think
it's a very simple format and not much different from FDT in terms of
complexity (maybe the CBOR tag parsing is slightly more complicated,
but in return FDT has weird quirks like the memory reserve map,
separate strings table and phandles you have to deal with), and I
don't think parsing one of them without RAM would be much more
cumbersome than the other. But I don't want to replace the coreboot
tables with either so it's probably not worth going off on that
tangent.
I understand that some people here want to instrumentalize coreboot to
try to force Intel to change course on its USF specification, and
honestly I don't really care about that one way or the other, I'm just
asking to please not let the fallout of that negatively affect those
of us who still just care about using coreboot as a firmware and not
as a political cudgel.
> > ending up with a solution that's less suited for either target
>
> I don't think FDT is less suited than coreboot tables where it
> matters the most - simplicity on byte level.
FDT is a tokenized hierarchical key-value store with string keys (and
a ton of extra quirks), whereas the coreboot tables are just a tagged
list of C structures. That's an order of magnitude of difference in
simplicity (and binary size).
> > The way we use payloads nowadays is often very deeply tied to
> > coreboot,
>
> More so if "often" means number of shipped systems, less so if "often"
> means the number of individual payloads.
Well, if we want to open that line of argument we also have to
consider what's left in the handoff for the payloads where this isn't
true. If your payload isn't even accessing CBFS or printing logs to
the CBMEM console (both of which are supported directly within
libpayload), then what do you still need a handoff for at all? Just to
parse the mainboard vendor string?
> > can hopefully stay pretty isolated and self-contained in the code base
>
> I think there should be just one source of truth, from which other
> formats are translated/derived.
I mean I generally agree with that sentiment, but then we are at an
impasse because I disagree with abandoning coreboot tables or forcing
FDT generator code into coreboot images for those who aren't
interested in this project. I think keeping these things side-by-side
in the code base with a Kconfig to switch between them is the only way
we're going to let everyone achieve what they want here, even if it is
going to add extra maintenance burden.
> > I'd like to make sure that we can agree to keep coreboot tables as
> > a first-class citizen now and in the future, and don't force a new
> > format on anyone.
>
> I don't think anyone proposed to not generate coreboot tables anymore.
I'm talking about where this is eventually supposed to be headed, not
just the first experimental patch. I think we can all agree that
there's no point in having two firmware handoff structures that both
need to be parsed to get the full picture, and since the argument for
coreboot tables is mostly simplicity / lean code it's not a solution
for that side to just generate both.
> Julius Werner wrote:
> > > - reflection is easy
> > > - no problem of 'header mismatch' to have the right definition of a struct
> > > - easy to update with a text editor without needing to write code
> >
> > Well, Arthur also admitted that none of these points are really
> > relevant to coreboot's payload handoff, ;) which I fully agree with.
>
> Currently that may be true, but reflection would pretty much be
> required for a new payload for manual parameter tweaking during boot.
Yeah, but what's the use case? When have you ever had a situation
where you'd want to edit coreboot table structures at runtime? (FWIW,
even if you wanted to do that for some reason it would still not be
very hard to write such a thing for coreboot tables -- the surrounding
UI and stuff of this shim payload would probably take the lion's share
of the effort, compared to the code to be able to delete/add/change
table entries for the known structures.)
> As I understand it, cbtable member alignment is currently undefined.
> That matters when building firmware and payload with different compilers.
> "Just use the coreboot compiler" is not a good answer.
Can we please stop perpetuating this myth? It's just wrong, like I
already explained in my first email here.
> > Unless we wanted to replace ACPI with FDT¹
> > ¹ I wouldn't mind that btw., replacing ACPI.
>
> That would be fantastic! But maybe it's more of a stretch goal. :)
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). We already have support
for FDT for kernel handoff in coreboot today, after all.
For the record, I just met with Lean from 9elements about this as well
and basically discussed that same position -- that I don't want to
block anyone from doing this but that I would like it to remain a
compile-time option and would like coreboot tables to continue being
available and supported as a first-party citizen going forward (and
not "soft deprecated" in favor of FDT, or have the FDT stuff seep into
something that can not be compiled out). As I understood, Lean (and
Arthur?) want to continue pursuing this implementation under that
premise, and then we'll have to see in practice how well we can make
them coexist side-by-side without stepping on each other's toes.
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org