On Mon, Apr 25, 2016 at 10:13 AM, Aaron Durbin <[email protected]> wrote: > On Fri, Apr 22, 2016 at 9:35 PM, Stefan Reinauer > <[email protected]> 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 <[email protected]> wrote: >>>> On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <[email protected]> wrote: >>>>> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <[email protected]> >>>>> 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 [email protected] 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. -Aaron -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
