[coreboot] coreboot specific ACPI table

Vadim Bendebury vbendeb at chromium.org
Mon Apr 18 19:09:18 CEST 2016


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



More information about the coreboot mailing list