[coreboot] coreboot specific ACPI table

[ron minnich]

I tend to vote for CORE, I think it is really going to be clear to people
what it's for ....

I like CRBT but fear it gets lost in the plethora of ACPI alphabet soup.

ron

On Fri, Apr 22, 2016 at 2:40 PM Aaron Durbin <adurbin at google.com> wrote:

> On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <rminnich at gmail.com> wrote:
> > Wait, I thought it had to be 4 characters.
>
> Yes. I cannot count. :/ CRBT
> >
> > ron
> >
> > On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot
> > <coreboot at coreboot.org> wrote:
> >>
> >> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie at chromium.org>
> >> wrote:
> >> > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin at google.com>
> >> > wrote:
> >> >>
> >> >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <
> jwerner at chromium.org>
> >> >> 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 info at acpi.info 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
> >> >
> >> >
> >> > --
> >> > coreboot mailing list: coreboot at coreboot.org
> >> > https://www.coreboot.org/mailman/listinfo/coreboot
> >>
> >> --
> >> coreboot mailing list: coreboot at coreboot.org
> >> https://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160422/b77fa08f/attachment.html>