It's been a while since I looked at it, but why not to pass all information through the coreboot table? (so that just one pointer needs to be shared through ACPI).
--vb On Mon, Apr 18, 2016 at 8:45 AM, Aaron Durbin via coreboot <[email protected]> wrote: > 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 > > -- > coreboot mailing list: [email protected] > https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
