[coreboot] coreboot specific ACPI table

[Aaron Durbin]

On Fri, Apr 22, 2016 at 2:49 PM, ron minnich <rminnich at gmail.com> wrote:
> 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.
>

It's been decided. Stefan, time to work your magic.

> 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