[coreboot] coreboot specific ACPI table

Aaron Durbin adurbin at google.com
Tue May 24 16:52:55 CEST 2016

On Mon, Apr 25, 2016 at 10:13 AM, Aaron Durbin <adurbin at google.com> wrote:
> On Fri, Apr 22, 2016 at 9:35 PM, Stefan Reinauer
> <stefan.reinauer at coreboot.org> wrote:
>> On 04/22/2016 02:35 PM, Aaron Durbin via coreboot wrote:
>>> 1. coreboot tables base address and size.
>>> 2. console base address and size.
>>> 3. ramoops info.
>> Since ramoops already has its own object in the DSDT, do we want to
>> mention it here?
>> What about other cbmem entries? coverage, timestamps...?
>> Do we want a pointer to cbmem in there, instead?
> All of those things are in the coreboot table already. We can use the
> same code/parser for ARM (and other device tree archs) as x86. The
> only difference is where to source the initial information for where
> the table resides.
>> Here's the 1 million dollar question: Do we want to get rid of coreboot
>> table and only have a coreboot
>> specific table? For a non-ACPI OS it's not much harder to read a
>> (non-DSDT) ACPI table than the current
>> coreboot table approach. For ACPI OSes it might make things a bit easier
>> (and counter the argument that
>> coreboot requires "support for non-standard tables")
>>> 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:
>> I like the idea of having a separate table rather than an object.
> We can pursue that if it's needed, but it sounds like it should be
> easy to just apply for HID and place a coreboot device object in the
> acpi code.
>>>> "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
>> This one is it!

Did CORE get requested from the ACPI forum as a hid we can use? I
think it should be fairly easy to request and get.


More information about the coreboot mailing list