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: > 1. coreboot tables base address and size.
Yes, unless the kernel absolutely can not find them any other way. > 2. console base address and size. > 3. 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 -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
