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! > >> 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 > -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
