Hi Chris,

On 08.11.22 20:35, Christian Walter wrote:
> I wasn't sure if I should also shim in here, but I just wanted to leave
> my opinion here. I agree with adding FDT as another method to handoff
> data to a payload. Despite all the advantages that Ron and others
> pointed out, I think something that passed data into another project
> e.g. payload here - whatever that is, should never be specific to one
> project. It should not be the status-quo that other projects, if they
> want to be loaded as a payload after coreboot need to implement other
> project specific implementations. What I mean by this is that
> hands-off's between different projects should always rely on an open
> standard that is *not* specific to the project.

this, having an open standard, is theoretically the ideal solution.
However, depending on the size of the problem, it might be much much
more effort to achieve this compared to the effort to work around its
absence. For instance, how many payload projects actually want to be
loaded by different firmware frameworks? is it 10%, 20%, 90%? I have
no idea. If it's few, the projects may lose interest before the new
standard is ready. Also, how much trouble is it to adapt a payload?
Let's not forget that the goal should be to make the work of firmware
developers easier, not harder.

And of course, such a standard shouldn't be decided by a single project
or group. If the goal is to get as many projects as possible to imple-
ment it, we should get many firmware framework and payload projects
together before making a decision. Otherwise, the risk is very high
that we work towards an instance of the famous xkcd/927.

Then about FDT: It can only cover a small part of the standard. There
is one important point that is often forgotten in this discussion:
  coreboot tables specify two things!
1. the binary format (this is what FDT can replace)
2. what data is passed (this is what bindings can replace)

Virtually nobody seems to be talking about 2. While IMO it would
be the much more important part of an open standard. Replacing 1.
is the part that creates churn; agreeing on 2. is mandatory to
actually achieve payload compatibility.

I know experimenting with the code is much more fun than creating
a standard. But replacing 1. alone won't make an open standard. It
would leave us with the 2. part of coreboot tables. Which IIRC,
was actually the part that Intel folks didn't want to agree with
in the first place.

Nico
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org