Re: [coreboot] coreboot specific ACPI table

[Aaron Durbin]

On Fri, Apr 22, 2016 at 2:49 PM, ron minnich  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  wrote:
> > On Fri, Apr 22, 2016 at 2:38 PM, ron minnich  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
> > >  wrote:
> > > > 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:
> > > > CORE
> > > > CBOOT
> > > > ... ?
> > > >
> > > > 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