[coreboot] coreboot specific ACPI table

[Aaron Durbin]

On Sun, Apr 24, 2016 at 5:02 PM, Peter Stuge <peter at stuge.se> wrote:
> 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.

This is somewhat orthogonal, but the coreboot tables are not really
defined all that well. There's no specific endianness for each of the
fields aside from whatever the endianness the CPUs was in during the
time of the write. The structs used are also not  marked as packed so
there's not much of a guarantee on field alignment -- especially as
they are allocated one after another within the table itself.
Something to think about, but it's not blocking requesting a HID so we
can export something more generic that common code can use in the
kernel.

>
> 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: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot