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?
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 <dlau...@chromium.org> wrote: >> On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adur...@google.com> wrote: >>> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwer...@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. >> >> "Requests to reserve a 4-byte alphanumeric table signature should be sent to >> the email address i...@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
signature.asc
Description: OpenPGP digital signature
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot