On Fri, Apr 22, 2016 at 2:49 PM, ron minnich <rminn...@gmail.com> wrote: > I tend to vote for CORE, I think it is really going to be clear to people > what it's for .... > > I like CRBT but fear it gets lost in the plethora of ACPI alphabet soup. >
It's been decided. Stefan, time to work your magic. > ron > > On Fri, Apr 22, 2016 at 2:40 PM Aaron Durbin <adur...@google.com> wrote: >> >> On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <rminn...@gmail.com> wrote: >> > Wait, I thought it had to be 4 characters. >> >> Yes. I cannot count. :/ CRBT >> > >> > ron >> > >> > On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot >> > <coreboot@coreboot.org> wrote: >> >> >> >> 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: >> >> > >> >> > "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 >> >> 2. CBOOT >> >> 3. ... ? >> >> >> >> Stefan, we'll likely need you to request the HID w/ your coreboot.org >> >> email. >> >> >> >> > >> >> > 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. >> >> >> >> > >> >> > -duncan >> >> > >> >> > >> >> > -- >> >> > coreboot mailing list: coreboot@coreboot.org >> >> > https://www.coreboot.org/mailman/listinfo/coreboot >> >> >> >> -- >> >> coreboot mailing list: coreboot@coreboot.org >> >> https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot