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.
For comparison, the coreboot device tree interface on ARM (https://lkml.org/lkml/2014/6/16/622, unfortunately never picked up by the maintainers but still used on Chromebooks today) only exports start address and size of the coreboot table and the whole CBMEM area, so maybe ACPI should just match that. (I guess if CBMEM is referenced by the coreboot table like Aaron said, we could also drop that part.)
-
Aaron Durbin