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
