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. > 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.) -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
