On Sun, Oct 29, 2023 at 11:25 AM Felix Held felix-coreboot@felixheld.de wrote:
Hi,
for ACPI table debugging purposes, there is an option for coreboot to print all ACPI tables on the serial console in a format that one of the tools from the iasl package can read after removing the few chars per line that the coreboot console adds. That option has been especially helpful to debug ACPI issues that prevent the OS from booting successfully.
While helpful, how about cases where you don't have access to the hardware? or don't have serial output? This is where I think a userspace/post-processing tool would be useful for debugging runtime-generated tables
Regards,
Felix
On 29/10/2023 14:29, niewoehner.michael wrote:
Heh, once I had that idea as well when working with ACPI. This really would help when debugging stuff. The way I did it was dumping the generated ASL from the live OS and then loading overriding stuff through Linux' means (boot dsdt override + runtime patching). That somehow worked but wasn't really stable and reliable.
---- Am Sa, 28 Okt 2023 16:28:45 +0200 schrieb *Matt DeVillier <matt.devillier@gmail.com mailto:matt.devillier@gmail.com>* ----
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 <mailto:arthur@aheymans.xyz>> wrote: _______________________________________________ coreboot mailing list -- coreboot@coreboot.org <mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org> Hi Except the DSDT most ACPI tables are generated at runtime in coreboot. For some tables runtime generation is actually desirable likeSSDT.
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 <mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org>
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org