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
-
Aaron Durbin