On Tue, Mar 31, 2020 at 12:29 PM Kevin O'Connor kevin@koconnor.net wrote:
On Tue, Mar 31, 2020 at 04:53:02PM +0200, Gerd Hoffmann wrote:
On Fri, Mar 27, 2020 at 09:15:19AM -0400, Kevin O'Connor wrote:
On Fri, Mar 27, 2020 at 09:12:06AM +0100, Gerd Hoffmann wrote:
Something like:
struct hlist_head DSDTTree;
struct dsdt_entry { struct hlist_node node; char *name; // eg, "_SB.PCI0.ISA.COM1._HID" int type; // eg: Device, Name, Integer, String, ResourceTemplate, other void *value; // points to integer, string, resource template, or NULL };
Once the tree is parsed, it should be simple to walk the in-memory linked-list to find desired values later.
I was thinking more about storing a list of devices with parsed data, i.e. basically put into a linked list what the current code collects in the parse_dev struct.
FWIW, I suspect it will be painful to grow 'struct parse_dev' if there are future users. (For example, if there is more than one memory range needed, if it is necessary to check for the existence of some name other than _STA, etc. .) In contrast, I suspect a few helper functions that can walk the tree would be sufficient to extract the info currently in 'struct parse_dev' as needed.
Went with a hybrid approach now. parse_dev is still there, but for the most part part it stores pointers into the dsdt table and parsing happens later as needed.
sneak preview @ https://git.kraxel.org/cgit/seabios/log/?h=dsdt
Thanks. FWIW, I think the code would be simpler if it first parsed the tree into an internal structure, and then searched for _STA, _HID, etc. Attempting to do both at the same time seems to complicate the code.
Then we can easily lookup the virtio-mmio devices later. Maybe also check for isa devices (don't bother waiting for ps2 probe timeout if acpi says there isn't a keyboard ...). I don't see any other use cases.
It would be helpful to extract the location of builtin sdcards from the dsdt (currently, the "etc/sdcard" cbfs file is used instead).
That'll be used with coreboot, right? How do sdcard dsdt entries look like?
Yes, with coreboot. I don't recall the details right now - perhaps Matt or John recall?
currently, the etc/sdcard entries point to the PCI BAR0 for the eMMC/SD controllers on Baytrail/Braswell devices which coreboot puts into ACPI mode. Those values are somewhat build-specific (ie, they differ between the stock Google firmware and upstream coreboot), and are extracted from the cbmem log of a booted system. They aren't directly contained in the DSDT anywhere either -- you'll just find references to BAR0 inside the EMMC/SDCD objects, which is a GNVS variable.
-Kevin