[coreboot] coreboot specific ACPI table

Aaron Durbin adurbin at google.com
Mon Apr 25 17:13:17 CEST 2016


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!
>
>> 2. CBOOT
> Would end up as CBOO... dunno.
>
>> 3. ... ?
> We could try just "BOOT" (Drop the core, it's cleaner!)
>
>> Stefan, we'll likely need you to request the HID w/ your coreboot.org email.
> Can't wait to do it, this is exciting. But we should come up with a
> reasonable data structure first, and document it (as Duncan quoted the
> standard)
>
>>> 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.
>
> A driver could merge our log with dmesg if it ran early enough.
>
>>> -duncan
> Stefan
>



More information about the coreboot mailing list