[coreboot] coreboot specific ACPI table

Aaron Durbin adurbin at google.com
Mon Apr 18 17:45:19 CEST 2016


Hi Folks,

There was a CL going around internal to chromium
(https://chromium-review.googlesource.com/#/c/339121) to expose the
coreboot table address proper through ACPI. However, it was put in the
GNVS of a few SoCs. There are different mechanisms for firmware
console and ramoops (pstore for kernel dmesg storage to catch
failures), but the kernel could probably use a generic coreboot driver
which could utilize the coreboot tables proper. There's already
semi-similar mechanisms (./drivers/firmware/google/coreboot_table.c in
linux). It needs to handle both device tree and should handle ACPI,
but it currently only handles device tree.

Where things really get messy is that for memconsole (exporting
firmware logs through sysfs) has both an x86 variant and a devicetree
one. The x86 variant has a cbmem parser when it should be relying
coreboot tables proper as that's the ABI.  There's also a path for
discovering the console by evaluating the \\CBMC object. The patch
referenced above takes a similar route. As noted above there is a
ramoops ACPI device that has been utilized for discovering the pstore
buffer to use which is different than just a named ACPI object.

All that said, I feel like we likely want to define a ACPI table which
has the coreboot specific data we care about:
1. coreboot tables base address and size.
2. console base address and size.
3. ramoops info.

The coreboot tables currently contain all the cbmem entries as well.
So if something is not explicitly in the ACPI table proper the
coreboot tables could be walked to identify those specific entries.

Thoughts? I'm not sure what the ramifications are of making a coreboot
ACPI table proper. On the surface it feels very much doable, but I
might be missing some details where things break down.

-Aaron



More information about the coreboot mailing list