[coreboot] coreboot specific ACPI table

[Aaron Durbin]

On Mon, Apr 18, 2016 at 12:09 PM, Vadim Bendebury <vbendeb at chromium.org> wrote:
> 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).

All information is already in the coreboot table as noted originally.
You could just keep bounds in the ACPI table and subsequently parse
the entries. That's the base case of "walked to identify those
specific entries".

>
> --vb
>
> On Mon, Apr 18, 2016 at 8:45 AM, Aaron Durbin via coreboot
> <coreboot at coreboot.org> 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: coreboot at coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot