<div dir="ltr">I tend to vote for CORE, I think it is really going to be clear to people what it's for ....<div><br></div><div>I like CRBT but fear it gets lost in the plethora of ACPI alphabet soup.</div><div><br></div><div>ron</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 22, 2016 at 2:40 PM Aaron Durbin <<a href="mailto:adurbin@google.com">adurbin@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>> wrote:<br>
> Wait, I thought it had to be 4 characters.<br>
<br>
Yes. I cannot count. :/ CRBT<br>
><br>
> ron<br>
><br>
> On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot<br>
> <<a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>> wrote:<br>
>><br>
>> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <<a href="mailto:dlaurie@chromium.org" target="_blank">dlaurie@chromium.org</a>><br>
>> wrote:<br>
>> > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <<a href="mailto:adurbin@google.com" target="_blank">adurbin@google.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <<a href="mailto:jwerner@chromium.org" target="_blank">jwerner@chromium.org</a>><br>
>> >> 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<br>
>> >> > 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<br>
>> >> > 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>
>> >> 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>
>> >><br>
>> ><br>
>> ><br>
>> > The official tables are all defined in the ACPI spec while the related<br>
>> > tables are also linked to from the spec, so we'd need to convince the<br>
>> > UEFI<br>
>> > forum to at least reserve the signature for us (and then link to our<br>
>> > table<br>
>> > definition) since they intend to act as gatekeepers to avoid collisions<br>
>> > in<br>
>> > table signatures:<br>
>> ><br>
>> > "Requests to reserve a 4-byte alphanumeric table signature should be<br>
>> > sent to<br>
>> > the email address <a href="mailto:info@acpi.info" target="_blank">info@acpi.info</a> and should include the purpose of the<br>
>> > table<br>
>> > and reference URL to a document that describes the table format."<br>
>> ><br>
>> > An easier path would be to define a specific device in the DSDT and<br>
>> > populate<br>
>> > it with the various data we want to be there on every system.  That<br>
>> > would<br>
>> > allow us to control the format and be able to alter it in the future if<br>
>> > we<br>
>> > want to expose new information.<br>
>> ><br>
>> > As you note a Device would need a valid unique HID, and that needs an ID<br>
>> > prefix if it wants to be official.  In theory we could request something<br>
>> > like "CORE" as an official APCI ID from<br>
>> > <a href="http://www.uefi.org/PNP_ACPI_Registry" rel="noreferrer" target="_blank">http://www.uefi.org/PNP_ACPI_Registry</a><br>
>><br>
>> OK. Time for bikeshedding:<br>
>><br>
>> 1. CORE<br>
>> 2. CBOOT<br>
>> 3. ... ?<br>
>><br>
>> Stefan, we'll likely need you to request the HID w/ your <a href="http://coreboot.org" rel="noreferrer" target="_blank">coreboot.org</a><br>
>> email.<br>
>><br>
>> ><br>
>> > I suppose the real difference between the two is whether we need this<br>
>> > data<br>
>> > early in boot before there is an AML interpreter available in the OS.<br>
>><br>
>> I don't think we need it that early. Right now the current usage (at<br>
>> least on x86) is all very late since we're doing AML evaluation. We<br>
>> could go w/ the ACPI device first. Just need to request that HID.<br>
>><br>
>> ><br>
>> > -duncan<br>
>> ><br>
>> ><br>
>> > --<br>
>> > coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
>> > <a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailman/listinfo/coreboot</a><br>
>><br>
>> --<br>
>> coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
>> <a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div>