Hi All,
This is my first post into this group. Hope to get my doubts cleared 
I need to read ACPI table in kernel mode. I am aware of this API “AuxKlibGetSystemFirmwareTable” already discussed in this group, but it has a restriction
“if the system firmware contains multiple tables with the same name, it retrieves only the first table in the list that has this name.”
My requirement is to read this complete ACPI table in Win Server 2008, 2012 and 2012 R2.
Really appreciate your help. Thanks in advance.
-Savita
xxxxx@gmail.com wrote:
I need to read ACPI table in kernel mode. I am aware of this API “AuxKlibGetSystemFirmwareTable” already discussed in this group, but it has a restriction
“if the system firmware contains multiple tables with the same name, it retrieves only the first table in the list that has this name.”
My requirement is to read this complete ACPI table in Win Server 2008, 2012 and 2012 R2.
ACPI is not a table. ACPI is a complete spec. An ACPI BIOS can expose
a number of different tables, the most useful usually being the DSDT.
Which table do you need to get? Are you quite sure your machine has
multiple tables with the same name?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
I need to read System Descriptor Table, which has definition block. That definition block can give the system mapped memory range for my device (BIOS changes are done for this).Once I get to know the system mapped memory range, i can map it to kernel virtual address and talk to my device with proprietary protocol.
Thanks,
Savita
This is exactly what is done in a proper way by inbox ACPI.SYS driver.
So, just fix the table to meet the reqs of ACPI.SYS (see ACPI spec), and you will not need to do such hacks, everything will be done by the inbox component.
wrote in message news:xxxxx@ntdev…
> Hi Tim,
> I need to read System Descriptor Table, which has definition block. That definition block can give the system mapped memory range for my device (BIOS changes are done for this).Once I get to know the system mapped memory range, i can map it to kernel virtual address and talk to my device with proprietary protocol.
> Thanks,
> Savita
>
>
Maxim,
Major requirement is not to let ACPI.sys to do it’s usual job. I want to represent my device as I want. suppose I read only one DSDT table, How can I parse its definition block? I m using GetSystemFirmwareTable only.
thanks,
Savita
xxxxx@gmail.com wrote:
Major requirement is not to let ACPI.sys to do it’s usual job. I want to represent my device as I want.
That’s simply not an option. Acpi.sys is the lowest-level driver. It
communicates directly with the BIOS. There’s no way to get in between
to alter its behavior.
You can override your DSDT with one of your own design by placing a
replacement in the registry and turning on TESTSIGNING.
suppose I read only one DSDT table, How can I parse its definition block? I m using GetSystemFirmwareTable only.
Have you done any research at all on this topic? There are many
hundreds of web pages that describe how to fetch your DSDT and
disassemble it into a human-readable form that can be modified and
recompiled. If you want to understand the binary format, you’ll need to
download the ACPI spec. Be prepared – it is very large.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
I understand its huge work, I am taking baby steps, thats where i need experts(your) inputs.
MSDN says
"Acpi.sys and the ACPI BIOS support the basic functions of an ACPI device. To enhance the functionality of an ACPI device, the device vendor can supply a WDM function driver. "
Is there any sample available for this?
If I plan to write this WDM driver will I be able to access the system memory range mapped for my device? I am new to ACPI, trying to understand concepts of OpRegion, Control Methods and all. Please provide your inputs.
Thanks,
Savita
xxxxx@gmail.com wrote:
MSDN says
"Acpi.sys and the ACPI BIOS support the basic functions of an ACPI device. To enhance the functionality of an ACPI device, the device vendor can supply a WDM function driver. "
Is there any sample available for this?
Not that I am aware of. There is some MSDN documentation.
If I plan to write this WDM driver will I be able to access the system memory range mapped for my device? I am new to ACPI, trying to understand concepts of OpRegion, Control Methods and all.
Yes. I presume your resources are handed to you at START_DEVICE time,
just like a PCI driver. You’d then have to register your operation
region to gain access.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim.
I have seen earlier threads in this topic.Jake Oshin an expert of ACPI had given many inputs.
Awaiting for his response too. I have not seen him participating in this thread 
Thanks,
Savita
You’re down the wrong path.
Why can’t you just write a function driver for your device and claim your resources in the normal manner? There should be no need to fool with ACPI at all.
Peter
OSR
@OSRDrivers
I think there is some confusion about what you’re actually trying to do. Your initial question was about getting access to ACPI tables in kernel space. The problem with that question is that you’re making an assumption that you actually need to do this at all.
What is it that you are trying to accomplish? Are you trying to write a driver for a device that is exposed via ACPI? Is this a device that already has a driver and you want to extend functionality? Or do you have control of the BIOS firmware and you created a new entry in the DSDT and need help figuring out how to expose this to the operating system so you can attach a device driver to it? What problem are you trying to solve?
xxxxx@osr.com wrote:
You’re down the wrong path.
Why can’t you just write a function driver for your device and claim your resources in the normal manner? There should be no need to fool with ACPI at all.
I suspect that’s what he actually wants. I’m doing a lot of inferring
here, but I believe he has a device that is created by ACPI and gets
assigned an operational region. Now, I don’t actually know whether the
OpRegion for an ACPI-created device gets handed to the FDO at
START_DEVICE time just like it does for a PCI device, but if it does,
then he shouldn’t have to communicate with ACPI at all.
The problem, as I see it, is that the documentation is pretty good in
nitty-gritty but falls a little short in explaining the overall
strategies, and there is no sample (as far as I am aware). Part of
that, I think, is because ACPI devices tend to be very custom. It’s
hard to come up with a good generic template.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Shane,
I am really very sorry if my questions are not clear. you are rightI I started off with question how to read ACPI table entries. GetSystemFirmwareTable fetches me only one DSDT,I really don’t know if there are more than one entry how to fetch it.I left this concern of multiple DSDT and continued further. multiple DSDT fetching is still open question!
Now assuming system will have only one DSDT, how do I fetch system mapped memory range of my device from ACPI table? DSDT has definition block which will be in AML language.
Next question was how do I parse and get my device’s system mapped memory range
in kernel mode??? I didn’t get a clue so changed the direction now
MSDN talks of vendor defined driver, where in we can register operation region handler, operation region memory buffer and some evaluate ioctls. I am unable to connect these with OpRegion defined within the device. if I register a handler when n how that handler would be invoked?? using this vendor specific driver will I be able to fetch my device’s system mapped memory? or I am completely looking at wrong driver for my requirement?
I am new to ACPI so please suggest. really appreciate your inputs
thanks
Savita
The other part of it is that it’s just so very easy. It’s just an FDO. Do what you want. There’s plenty of documentation on how to “evaluate” ACPI methods.
OP… Read what I wrote one reply back. You’re down the wrong path.
This has nothing to do with getting the DSDT or parsing tables. Forget that.
Just write an ordinary KMDF function driver that instantiates on the Hardware ID “ACPI<yourdevicehid>” Where is the same value as the HID in the DSDT for your device.
Just write a driver. Let ACPI.SYS parse the ACPI tables. He’ll pass you what you need. There’s a whole section in the WDK Docs about this:
https:
Very simple, really. Read and enjoy.
Peter
OSR
@OSRDrivers</https:>
Peter,
Thanks for clearing my doubts. I was too much confused with all the concepts.
I will do as you have said.
Thanks,
Savita