Tim, Thanks for the feedback _STA is certainly an option. I ended up implementing the hex file method and having iasl do the compilation. When the patch is ready I’ll submit it for review. Basically I’ve created a new definition block for the ASL code that needs to be loaded dynamically. This allows for adding multiple SSDT tables and runtime C code can decide to load the tabled based on the HW features detected (e.g multi-socket systems).
From: Tim Wawrzynczak <twawrzync...@google.com> Sent: Tuesday, April 27, 2021 9:59 AM To: Rocky Phagura <rphag...@fb.com> Cc: coreboot@coreboot.org Subject: Re: [coreboot] ACPI SSDT Help Hi Rocky, You have a couple of options that I can think of: 1) Add the device to the DSDT, but find a way to implement a `_STA` Method that will return 0x0 if the device does not exist, and 0xF if it does 2) Push a patch to add a similar mechanism to load a `ssdt.aml` file from CBFS (similar to DSDT) 3) Live with using the `acpigen` library to generate the AML (lots of us use this in production, if you do choose this route, feel free to ping me for help if you want). Cheers, -Tim On Mon, Apr 26, 2021 at 5:44 PM Rocky Phagura via coreboot <coreboot@coreboot.org<mailto:coreboot@coreboot.org>> wrote: Hello, Looking for some recommendations here. I have a situation where I would like to compile ACPI ASL code into its own definition block and load it dynamically based on some features present in the HW. For example, the code below has its own definition block. Today all of the projects in Coreboot seem to be using only 1 definition block (in dsdt.asl) and the whole thing is loaded at once. I’m looking to create a second definition block and load it dynamically. The SSDT table in Coreboot is mostly derived from C code generating asl code. I prefer iasl compile the asl code. The code I have below functions correctly using the SSDT method. My issue is that it doesn’t work well with the existing make system. Right now I have to use a 2 step approach. (1) compile the asl code manually, iasl -tc ras.asl (2) compile Coreboot and include the newly generated hex file (iasl generates c code include file, ras.hex) which links with c code that creates an SSDT table at runtime just like all other tables are added (madt, hpet, etc). While the above 2 step process works, its not clean. I think there is a better way and I’m looking for the Coreboot community’s help. Any recommendations are welcome. Thank you, DefinitionBlock ( "ras.aml", "SSDT", 2, "Test", "Test", 0x1000 ) { Scope (\_GPE) { //#include <acpi/acpi.h> OperationRegion (PMIO, SystemIO, 0x500, 0xFF) Field (PMIO, ByteAcc, NoLock, Preserve) { Offset(0x34), /* 0x34, SMI/SCI STS*/ , 9, SGCS, 1, /* SWGPE STS BIT */ Offset(0x40), /* 0x40, SMI/SCI_EN*/ , 17, SGPC, 1, /* SWGPE CTRL BIT */ Offset(0x8C), /* 0x8C, General Purpose Event 0 Status [127:96] */ , 2, SGPS, 1, /* SWGPE STATUS */ Offset(0x9C), /* 0x9C, General Purpose Event 0 Enable [127:96] */ , 2, SGPE, 1 /* SWGPE ENABLE */ } Device (RAS) { Name (_HID, EisaId ("PNP0C33")) Name (_UID, 0) Name (_DDN, "RAS Error Device Controller") Store(" Initialized RAS Device PNP0C33", Debug) } Method(_L62, 0) { Store(" SWGPE Method _L62", Debug) Store(0, SGPC) // clear SWGPE enable Store(1, SGPS) // clear SWGPE Status Notify(RAS, 0x80) } } } _______________________________________________ coreboot mailing list -- coreboot@coreboot.org<mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-le...@coreboot.org<mailto:coreboot-le...@coreboot.org>
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
