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. ron On Fri, Apr 22, 2016 at 2:40 PM Aaron Durbin <[email protected]> wrote: > On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <[email protected]> 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 > > <[email protected]> wrote: > >> > >> 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: > >> > > >> > "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 > >> 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: [email protected] > >> > https://www.coreboot.org/mailman/listinfo/coreboot > >> > >> -- > >> coreboot mailing list: [email protected] > >> https://www.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
