<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <span dir="ltr"><<a href="mailto:adurbin@google.com">adurbin@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <<a href="mailto:jwerner@chromium.org">jwerner@chromium.org</a>> wrote:<br>
> I think we should only export the coreboot table location and size<br>
> through ACPI and then read everything else from there. That way we can<br>
> share almost all of the kernel driver code with ARM and just need a<br>
> tiny platform-specific stub to look up the table location first. If we<br>
> add all the information into an actual ACPI table, we're building an<br>
> x86-only solution again. (A generic, platform-independent coreboot<br>
> driver could just as easily export the stuff we want into sysfs.)<br>
><br>
<br>
</span>That's fine. The only thing I was concerned about was implementing an<br>
ACPI table proper or try to do some ACPI device shenanigans like the<br>
ramoops device. coreboot doesn't currently have a ACPI ID assigned to<br>
it. If we go with a ACPI device coreboot should apply for an ACPI ID.<br>
I personally think the coreboot ACPI table seems more straight<br>
forward, but I was wondering if people knew of any downsides to going<br>
that route.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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:</div><div style="font-size:12.8px"><br></div><div><span style="font-size:12.8px">"Requests to reserve a 4-byte alphanumeric table signature should be sent to the email address <a href="mailto:info@acpi.info">info@acpi.info</a> and should include the purpose of the table and reference URL to a document that describes the table format."</span><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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 <a href="http://www.uefi.org/PNP_ACPI_Registry">http://www.uefi.org/PNP_ACPI_Registry</a></div></div><div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div></div><div><br></div><div>-duncan</div><div><br></div></div></div></div>