Re: [coreboot] coreboot specific ACPI table

[Aaron Durbin]

On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie  wrote:
> On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin  wrote:
> > On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner 
> > wrote:
> > > I think we should only export the coreboot table location and size
> > > through ACPI and then read everything else from there. That way we can
> > > share almost all of the kernel driver code with ARM and just need a
> > > tiny platform-specific stub to look up the table location first. If we
> > > add all the information into an actual ACPI table, we're building an
> > > x86-only solution again. (A generic, platform-independent coreboot
> > > driver could just as easily export the stuff we want into sysfs.)
> >
> > That's fine. The only thing I was concerned about was implementing an
> > ACPI table proper or try to do some ACPI device shenanigans like the
> > ramoops device. coreboot doesn't currently have a ACPI ID assigned to
> > it. If we go with a ACPI device coreboot should apply for an ACPI ID.
> > I personally think the coreboot ACPI table seems more straight
> > forward, but I was wondering if people knew of any downsides to going
> > that route.
>
> The official tables are all defined in the ACPI spec while the related
> tables are also linked to from the spec, so we'd need to convince the UEFI
> forum to at least reserve the signature for us (and then link to our table
> definition) since they intend to act as gatekeepers to avoid collisions in
> table signatures:
>
> "Requests to reserve a 4-byte alphanumeric table signature should be sent to
> the email address [e-mail] and should include the purpose of the table
> and reference URL to a document that describes the table format."
>
> An easier path would be to define a specific device in the DSDT and populate
> it with the various data we want to be there on every system.  That would
> allow us to control the format and be able to alter it in the future if we
> want to expose new information.
>
> As you note a Device would need a valid unique HID, and that needs an ID
> prefix if it wants to be official.  In theory we could request something
> like "CORE" as an official APCI ID from
> http://www.uefi.org/PNP_ACPI_Registry

OK. Time for bikeshedding:

1. CORE
2. CBOOT
3. ... ?

Stefan, we'll likely need you to request the HID w/ your coreboot.org email.
> I suppose the real difference between the two is whether we need this data
> early in boot before there is an AML interpreter available in the OS.

I don't think we need it that early. Right now the current usage (at
least on x86) is all very late since we're doing AML evaluation. We
could go w/ the ACPI device first. Just need to request that HID.
> -duncan