Re: RFC: generating more ACPI tables at buildtime

Funnily enough I had this thought as well when I first started working with
acpigen, but now that I've used it more, I definitely appreciate the
ability to generate tables/device status etc at runtime based on the actual
hardware. I definitely agree that having more asl / more build-time tables
makes debugging easier. I think the idea of a userspace program that can
generate a mock SSDT (and/or any other runtime-generated tables) based on
assumed hardware presence would be great, that way we can inspect and debug
the ssdt without having to boot actual hardware and dump it. It could even
generate a config file with all the "toggleable" hardware and we could set
the status to on/off and then use that for the mock table generation. And
we could expand our ACPI checks to validate the mock tables (or just run
them through iasl), which would allow us to improve our ACPI to
better handle "picky" OSes like Windows.

re: setting various enable bits (or ACPI _STA) at runtime: we've actually
started doing that already for a lot of things in soc/amd/common, where the
devices are generated by static asl and the _STA() method returns a
variable (eg, STAT) which defaults to off (0x0) and if present is
overridden in the SSDT (by setting STAT to 0xF). I'm not sure this is the
ideal way of doing it, so would love to hear other ideas as well.

On Sat, Oct 28, 2023 at 7:39 AM Arthur Heymans <[email protected]> wrote:

> Hi
>
> Except the DSDT most ACPI tables are generated at runtime in coreboot.
> For some tables runtime generation is actually desirable like SSDT.
> For other tables a lot of the data is known at buildtime, which makes it
> possible to create them at buildtime and simply load them into memory at
> runtime.
> Having the tables generated at runtime makes them hard to debug and
> inspect or even validate.
>
> A few examples:
> - MCFG: everything is known at buildtime
> - FADT: only pointers to DSDT and FACS need updating. The rest is
> typically known at buildtime.
> - MADT: Currently all LAPICs are generated in SSDT and in MADT. Maybe this
> could be changed to swapping the enabled 'bits' at runtime but having the
> table there at buildtime? This could avoid the complicated code to deal
> with SMP threads sorting and Intels hybrid infrastructure that currently
> happens at runtime.
> - TMP log tables: only the pointer to the table needs updating.
>
> What do you think about creating a userspace program that takes most of
> the ramstage sources, mocks a few functions, creates some meaningful data
> input values to make it usable/executable in userspace and runs the ACPI
> generation code with it and outputs it into a file or even multiple files?
> Then the coreboot ramstage could just load those tables from cbfs instead
> of generating them.
>
> Some thoughts:
> - It could mean more maintenance as you likely want to keep both runtime
> and buildtime options available for most tables.
> - code size is reduced (good) in favor of larger data. I am not sure what
> the overall impact is on the boot medium footprint.
> - Having a way to generate tables at buildtime makes writing ACPI code
> easier. You don't need to run it on actual hardware to develop them, even
> if the end goal is to eventually generate things at runtime.
>
> Let me know what you think.
>
> Arthur
> _______________________________________________
> coreboot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]