ACPI is largely made up of a language where the BIOS hands the OS a set of
objects and methods on those objects to accomplish basic motherboard
management tasks. This code is made up of an interpreted language, designed
for the task. (See chapters 16 and 17 of ACPI.)
This language, called AML, is made up of loads and stores from various
defined region spaces, which are themselves objects within the ACPI
namespace. You can, for instance, create an object which represents I/O
port 2012 and defines 7 bits within that register. Then you can read or
write those bits merely by referencing them as the target of a load or
store.
There are about seven predefined region spaces. ACPI 1.0 defined I/O,
memory, PCI Config, SMBus and “Embedded Controller.” The last was just
fictitious space exposed by the driver in Windows for the Embedded
Controller device that was also defined in ACPI, which itself was just a
conduit for passing data between the OS and the embedded processor that is
present in every laptop – it’s the part that operates even when the machine
is turned off.
You could, for instance, define a location in your BIOS that represented the
current state of charge of the battery. When the OS interpreted the method
for getting the battery data, it referenced that location in EC space, which
caused the EC driver to send a message to the EC asking for that byte in the
EC. Since your BIOS and your embedded controller firmware are delivered
from the same source, they can agree on what the various offsets in this
fictitious address space actually mean, and that’s opaque to the OS.
ACPI 2.0 added a couple more spaces, CMOS and a special space that
corresponds to whatever a specific PCI device’s BAR is currently pointing
to, allowing you to reference a PCI device in a relative fashion without
knowing what is currently written in a BAR.
ACPI 3.0, to my memory, didn’t add any spaces. ACPI 4.0 might add some, but
I’m no longer really involved.
In any case, you can provide your own address space, with a type code in a
vendor-defined range (above 0xC0 if I remember correctly.) Then your BIOS
can reference this space and it will end up in your provider driver asking
you what to do about reads and writes. This is useful if you’re trying to
glue ACPI into a system with a fairly sophisticated management controller,
as with a high-end server chassis.
In truth, though, not many people use this feature, as it only works when
your driver is present, and because triggering a System Management Interrupt
seems much more straightforward to most BIOS guys.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team
This post implies no warranties and confers no rights.
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Now that you mention it, Jake, I was just wondering about (3); it’s funny
> how life works sometimes. In any case, would you mind expanding on it a
> little bit?
>
>
> Thanks,
>
> mm
>
> Jake Oshins wrote:
>> Your question is ambiguous, but that’s usually true for somebody starting
>> on a project.
>>
>> Let’s start with the term “ACPI driver.” You could mean one of several
>> things:
>>
>> 1) A driver which replaces the “ACPI driver” in Windows. I doubt that
>> you mean this, but this is what the phrase you used directly implies.
>>
>> 2) A driver which is enumerated because the ACPI BIOS contained a device
>> object representing it, which in turn caused the ACPI driver in Windows
>> to create a Windows Physical Device Object onto which your driver loads.
>> This driver then has nothing more to do with ACPI, except that it can’t
>> be found through other means. I doubt that this is what you mean because
>> your hardware guy gave you some PCI IDs.
>>
>> 3) A driver which implements an operation region space so that ACPI BIOS
>> control methods can reference address spaces not otherwise supported by
>> the in-box ACPI driver. I doubt that this is what you mean because it’s
>> a relatively rare situation and an advanced topic.
>>
>> 4) A driver that invokes BIOS control methods to interact with a device
>> embedded on the motherboard. This driver may also register for
>> notifications from the BIOS. I suspect that this is what you meant.
>>
>> 5) A group of control methods and BIOS declarations in the form of “ACPI
>> Source Language” (ASL) which implents some aspect of your device,
>> delivered as BIOS code, not a Windows driver.
>>
>> 6) A group of ACPI objects which implement WMI functionality, passed up
>> to the OS by the in-box ACPI driver, so that an application can directly
>> access your device through WMI.
>>
>> Give us more to go on with respect to your problem and we can be more
>> helpful. (I just honestly don’t feel like typing a twenty-five-page
>> dissertation on all six of the above.)
>>
>