On 04/22/2016 02:35 PM, Aaron Durbin via coreboot wrote:
- coreboot tables base address and size.
- console base address and size.
- ramoops info.
Since ramoops already has its own object in the DSDT, do we want to mention it here? What about other cbmem entries? coverage, timestamps...? Do we want a pointer to cbmem in there, instead?
Here's the 1 million dollar question: Do we want to get rid of coreboot table and only have a coreboot specific table? For a non-ACPI OS it's not much harder to read a (non-DSDT) ACPI table than the current coreboot table approach. For ACPI OSes it might make things a bit easier (and counter the argument that coreboot requires "support for non-standard tables")
On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie dlaurie@chromium.org wrote:
On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin adurbin@google.com wrote:
On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner jwerner@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:
I like the idea of having a separate table rather than an object.
"Requests to reserve a 4-byte alphanumeric table signature should be sent to the email address info@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:
- CORE
This one is it!
- CBOOT
Would end up as CBOO... dunno.
- ... ?
We could try just "BOOT" (Drop the core, it's cleaner!)
Stefan, we'll likely need you to request the HID w/ your coreboot.org email.
Can't wait to do it, this is exciting. But we should come up with a reasonable data structure first, and document it (as Duncan quoted the standard)
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.
A driver could merge our log with dmesg if it ran early enough.
-duncan
Stefan
Aaron Durbin via coreboot wrote:
I feel like we likely want to define a ACPI table which has the coreboot specific data we care about:
- coreboot tables base address and size.
Yes, unless the kernel absolutely can not find them any other way.
- console base address and size.
- ramoops info.
No. This, and everything else coreboot and coreboot users care about, should be in coreboot tables.
Thoughts?
Do not put a single thing into ACPI that is not absolutely neccessary.
Stefan Reinauer wrote:
Since ramoops already has its own object in the DSDT, do we want to mention it here?
No.
What about other cbmem entries? coverage, timestamps...? Do we want a pointer to cbmem in there, instead?
In coreboot tables.
Here's the 1 million dollar question: Do we want to get rid of coreboot table and only have a coreboot> specific table?
I absolutely do not want that. Maybe Google does. It's clearly not desirable for coreboot to enter into a dependency on the UEFI Forum.
it's not much harder
It's still the wrong thing to do.
For ACPI OSes it might make things a bit easier (and counter the argument that coreboot requires "support for non-standard tables")
Too much politics.
Please invest effort into the proper solution; make it clear that coreboot tables are very much standardized by the coreboot project, and that they are a required standard for Chrome platforms.
Someone once told me that a standard is something with more than one implementation. AFAIK ACPI only has a single compiler, so by that logic ACPI is actually not a standard at all.
If kernel refuses coreboot then maintain a tight patchset for ODMs.
Kernel will take it once enough pressure has built up and if the pressure never builds up you've failed anyway.
//Peter
On Sun, Apr 24, 2016 at 5:02 PM, Peter Stuge peter@stuge.se wrote:
Aaron Durbin via coreboot wrote:
I feel like we likely want to define a ACPI table which has the coreboot specific data we care about:
- coreboot tables base address and size.
Yes, unless the kernel absolutely can not find them any other way.
- console base address and size.
- ramoops info.
No. This, and everything else coreboot and coreboot users care about, should be in coreboot tables.
Thoughts?
Do not put a single thing into ACPI that is not absolutely neccessary.
Stefan Reinauer wrote:
Since ramoops already has its own object in the DSDT, do we want to mention it here?
No.
What about other cbmem entries? coverage, timestamps...? Do we want a pointer to cbmem in there, instead?
In coreboot tables.
Here's the 1 million dollar question: Do we want to get rid of coreboot table and only have a coreboot> specific table?
I absolutely do not want that. Maybe Google does. It's clearly not desirable for coreboot to enter into a dependency on the UEFI Forum.
it's not much harder
It's still the wrong thing to do.
For ACPI OSes it might make things a bit easier (and counter the argument that coreboot requires "support for non-standard tables")
Too much politics.
Please invest effort into the proper solution; make it clear that coreboot tables are very much standardized by the coreboot project, and that they are a required standard for Chrome platforms.
This is somewhat orthogonal, but the coreboot tables are not really defined all that well. There's no specific endianness for each of the fields aside from whatever the endianness the CPUs was in during the time of the write. The structs used are also not marked as packed so there's not much of a guarantee on field alignment -- especially as they are allocated one after another within the table itself. Something to think about, but it's not blocking requesting a HID so we can export something more generic that common code can use in the kernel.
Someone once told me that a standard is something with more than one implementation. AFAIK ACPI only has a single compiler, so by that logic ACPI is actually not a standard at all.
If kernel refuses coreboot then maintain a tight patchset for ODMs.
Kernel will take it once enough pressure has built up and if the pressure never builds up you've failed anyway.
//Peter
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
On Fri, Apr 22, 2016 at 9:35 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
On 04/22/2016 02:35 PM, Aaron Durbin via coreboot wrote:
- coreboot tables base address and size.
- console base address and size.
- ramoops info.
Since ramoops already has its own object in the DSDT, do we want to mention it here? What about other cbmem entries? coverage, timestamps...? Do we want a pointer to cbmem in there, instead?
All of those things are in the coreboot table already. We can use the same code/parser for ARM (and other device tree archs) as x86. The only difference is where to source the initial information for where the table resides.
Here's the 1 million dollar question: Do we want to get rid of coreboot table and only have a coreboot specific table? For a non-ACPI OS it's not much harder to read a (non-DSDT) ACPI table than the current coreboot table approach. For ACPI OSes it might make things a bit easier (and counter the argument that coreboot requires "support for non-standard tables")
On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie dlaurie@chromium.org wrote:
On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin adurbin@google.com wrote:
On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner jwerner@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:
I like the idea of having a separate table rather than an object.
We can pursue that if it's needed, but it sounds like it should be easy to just apply for HID and place a coreboot device object in the acpi code.
"Requests to reserve a 4-byte alphanumeric table signature should be sent to the email address info@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:
- CORE
This one is it!
- CBOOT
Would end up as CBOO... dunno.
- ... ?
We could try just "BOOT" (Drop the core, it's cleaner!)
Stefan, we'll likely need you to request the HID w/ your coreboot.org email.
Can't wait to do it, this is exciting. But we should come up with a reasonable data structure first, and document it (as Duncan quoted the standard)
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.
A driver could merge our log with dmesg if it ran early enough.
-duncan
Stefan
-
Aaron Durbin -
Peter Stuge -
Stefan Reinauer