've added the topic to the agenda of the next coreboot leadership meeting. Hopefully some sort of decision can be made there. I'm not trying to push any particular solution, but we need to be able to agree on something and then work towards implementinga single, or even a couple different options
Options: - Mulitboot - FDT - CBOR - Universal Payload - coreboot tables.
I've made a document to capture pros & cons of each: https://docs.google.com/document/d/1rN9PcrGliRCE-q2sa_k49WCInTELyyudN9RQvez5...
I'll try to go through the mailing list and capture arguments for and against each option, but if people could help out and fill things in as well, I'd appreciate it.
We need to be able to reach a decision and stick with it for a while, even if it's not the perfect solution and doesn't make everyone happy.
Martin
Nov 15, 2022, 05:17 by sheng.tan@9elements.com:
Thanks all for the good discussion. There will always be better ideas from time to time, I am very happy to see it happens as long as someone is willing to be in the driving seat on the effort to:
- come out with proper specification design
- communicate and with other firmware communities and silicon vendors for discussions
- align and finalize all inputs together
- set a timeline and follow up the implementation to the end
Meanwhile in parallel, as mentioned, I will continue to work on the FDT design with an incremental approach. Still drafting the specification and the code structure, happy to share the spec later for wider feedback. Please also let me know if you are interested in helping out :)
Best Regards, Lean Sheng Tan
On Fri, 11 Nov 2022 at 15:31, Nico Huber <> nico.h@gmx.de> > wrote:
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!
- the binary format (this is what FDT can replace)
- 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