Re: RFC: generating more ACPI tables at buildtime

On Sun, Oct 29, 2023 at 11:25 AM Felix Held <[email protected]>
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
> > <[email protected] <mailto:[email protected]>>* ----
> >
> >
> >
> >     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]
> >     <mailto:[email protected]>> wrote:
> >
> >     _______________________________________________
> >     coreboot mailing list -- [email protected]
> >     <mailto:[email protected]>
> >     To unsubscribe send an email to [email protected]
> >     <mailto:[email protected]>
> >
> >         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]
> >         <mailto:[email protected]>
> >         To unsubscribe send an email to [email protected]
> >         <mailto:[email protected]>
> >
> >
> >
> > _______________________________________________
> > 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]
>

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