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 arthur@aheymans.xyz 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 -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org