Making sense of ACPI(CA)
Posted: Wed Dec 14, 2011 12:46 pm
OK, so I have ACPICA working (with debug support), but the interface is cludgy and not delivering what I want.
What I basically want is:
1. A function to map a PCI address to an IRQ on IO-APIC.
2. A function which returns a list of devices, not with callbacks, but with an index #, and then allows easy retrieval of IRQ, IO-range and memory-range.
3. A function that returns a list of PCI-devices, with an index #, and that allows easy retrieval of IRQs and possibly IO and memory-ranges
4. A function that returns a description of a device
What I get is:
1. Name-space walks
2. Retrieval of resource-objects in ways that are not readable in the debugger (nor easily dereferenced in C either).
So, what I have done is:
1. Created my own object-vector with a name-space walk
2. Created my own device-vector with a name-space walk
3. Created the resource descriptions by using a number of lists of real objects instead of worthless unions.
4. Created my own PCI irq-vector with a name-space walk
What I will do shortly is:
1. Add a command-line option to display devices (once I have the RdosGetDevice), along with description, IRQ and IO/memory ranges
2. Add a command-line option to display PCI-device, along with bus, device, function, IRQ and IO/memory ranges
However, I still don't think I properly understand some central concepts in ACPICA.
For instance:
1. How do you find the PCI device(s)?
2. Which methods are typically used/required with which devices? My listing of namespace objects is huge, but how do I know that my next machine has the same ones? Especially since neither the ACPICA document, nor the ACPI document, is clear on how typical devices should be represented.
3. Is there any use in reading-out the base address for keyboard controller, PIT, PIC, PCI? Wouldn't any new design that changed these settings be so broken that nobody would want it? Isn't the chance bigger that any deviation in these values would be errors in the ACPI tables rather than a genuine difference?
What I basically want is:
1. A function to map a PCI address to an IRQ on IO-APIC.
2. A function which returns a list of devices, not with callbacks, but with an index #, and then allows easy retrieval of IRQ, IO-range and memory-range.
3. A function that returns a list of PCI-devices, with an index #, and that allows easy retrieval of IRQs and possibly IO and memory-ranges
4. A function that returns a description of a device
What I get is:
1. Name-space walks
2. Retrieval of resource-objects in ways that are not readable in the debugger (nor easily dereferenced in C either).
So, what I have done is:
1. Created my own object-vector with a name-space walk
2. Created my own device-vector with a name-space walk
3. Created the resource descriptions by using a number of lists of real objects instead of worthless unions.
4. Created my own PCI irq-vector with a name-space walk
What I will do shortly is:
1. Add a command-line option to display devices (once I have the RdosGetDevice), along with description, IRQ and IO/memory ranges
2. Add a command-line option to display PCI-device, along with bus, device, function, IRQ and IO/memory ranges
However, I still don't think I properly understand some central concepts in ACPICA.
For instance:
1. How do you find the PCI device(s)?
2. Which methods are typically used/required with which devices? My listing of namespace objects is huge, but how do I know that my next machine has the same ones? Especially since neither the ACPICA document, nor the ACPI document, is clear on how typical devices should be represented.
3. Is there any use in reading-out the base address for keyboard controller, PIT, PIC, PCI? Wouldn't any new design that changed these settings be so broken that nobody would want it? Isn't the chance bigger that any deviation in these values would be errors in the ACPI tables rather than a genuine difference?
