Aaron Durbin via coreboot wrote:
I feel like we likely want to define a ACPI table which has the coreboot specific data we care about:
- coreboot tables base address and size.
Yes, unless the kernel absolutely can not find them any other way.
- console base address and size.
- ramoops info.
No. This, and everything else coreboot and coreboot users care about, should be in coreboot tables.
Thoughts?
Do not put a single thing into ACPI that is not absolutely neccessary.
Stefan Reinauer wrote:
Since ramoops already has its own object in the DSDT, do we want to mention it here?
No.
What about other cbmem entries? coverage, timestamps...? Do we want a pointer to cbmem in there, instead?
In coreboot tables.
Here's the 1 million dollar question: Do we want to get rid of coreboot table and only have a coreboot> specific table?
I absolutely do not want that. Maybe Google does. It's clearly not desirable for coreboot to enter into a dependency on the UEFI Forum.
it's not much harder
It's still the wrong thing to do.
For ACPI OSes it might make things a bit easier (and counter the argument that coreboot requires "support for non-standard tables")
Too much politics.
Please invest effort into the proper solution; make it clear that coreboot tables are very much standardized by the coreboot project, and that they are a required standard for Chrome platforms.
Someone once told me that a standard is something with more than one implementation. AFAIK ACPI only has a single compiler, so by that logic ACPI is actually not a standard at all.
If kernel refuses coreboot then maintain a tight patchset for ODMs.
Kernel will take it once enough pressure has built up and if the pressure never builds up you've failed anyway.
//Peter