Hello,
Is there any sample ACPI driver that I can refer to? I am trying to write a driver for a device that is SoC. I am new to this framework.
Thank you,
Rohit
Hello,
Is there any sample ACPI driver that I can refer to? I am trying to write a driver for a device that is SoC. I am new to this framework.
Thank you,
Rohit
How is your device actually attached to the SoC? ACPI is just how you
describe the attachment to Windows.
Assuming that it’s similar to I2C/SPI, the SpbTestTool driver demonstrates
interacting with a device connected via I2C/SPI with an interrupt from a
GPIO:
https://github.com/Microsoft/Windows-driver-samples/tree/master/spb/SpbTestTool
It’s useful for seeing how this type of driver is structured. It’s also
generic enough that we use it to validate new devices that we work on.
Note that this is a KMDF driver. Depending on the characteristics and
requirements of the device, you should also look into doing this as a UMDF
driver. If you can limit yourself to Windows 8.1 and later the structure of
a UMDF 2.0 driver would be very similar to the KMDF sample.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
Hello,
Is there any sample ACPI driver that I can refer to? I am trying to write a
driver for a device that is SoC. I am new to this framework.
Thank you,
Rohit
Hello Scott,
Thank you for your reply. Currently I am trying to write a watchdog driver for Intel Kaby Lake architecture. This hardware is generally controlled by Microsoft driver itself and the resources are shown under mother board resources.
The watchdog hardware is neither on I2C nor on SPI bus. It is interfaced with processor on internal memory bus.
My understanding is I can write a driver for this using the following documentation.
https://docs.microsoft.com/en-us/windows-hardware/drivers/acpi/supporting-acpi-devices
But is there any sample code for this? I could not find any example where apis like RegisterOpRegionHandler() are used as described below.
https://docs.microsoft.com/en-us/windows-hardware/drivers/acpi/registering-and-deregistering-an-operation-region-handler
Thanks,
Rohit
OK, details are important…
These callbacks allow the BIOS to access a device using a driver on the
host. I’m not sure that this actually achieves your goal? Does the device
have a vendor defined operational region defined for it? Though I honestly
don’t know anything about the device or how the platform interacts with it,
so I don’t know how you would write a custom driver for it (or if it’s even
possible without support from the platform).
AFAIK these operational region handler drivers are rare, I wouldn’t expect
many examples. Seems relatively straightforward based on the docs though.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
Hello Scott,
Thank you for your reply. Currently I am trying to write a watchdog driver
for Intel Kaby Lake architecture. This hardware is generally controlled by
Microsoft driver itself and the resources are shown under mother board
resources.
The watchdog hardware is neither on I2C nor on SPI bus. It is interfaced
with processor on internal memory bus.
My understanding is I can write a driver for this using the following
documentation.
https://docs.microsoft.com/en-us/windows-hardware/drivers/acpi/supporting-acpi-devices
But is there any sample code for this? I could not find any example where
apis like RegisterOpRegionHandler() are used as described below.
https://docs.microsoft.com/en-us/windows-hardware/drivers/acpi/registering-and-deregistering-an-operation-region-handler
Thanks,
Rohit
As Scott pointed out that OpRegion are in BIOS, they can be defined in ASL
and different drivers can registry if they want to get callback, basically
a mean of communication.
but here what functionality is supposed to be provided by your driver, and
how this driver is enumerated.
On Tue, Aug 29, 2017 at 11:11 AM, xxxxx@gmail.com <
xxxxx@lists.osr.com> wrote:
Hello Scott,
Thank you for your reply. Currently I am trying to write a watchdog driver
for Intel Kaby Lake architecture. This hardware is generally controlled by
Microsoft driver itself and the resources are shown under mother board
resources.
The watchdog hardware is neither on I2C nor on SPI bus. It is interfaced
with processor on internal memory bus.
My understanding is I can write a driver for this using the following
documentation.
https://docs.microsoft.com/en-us/windows-hardware/drivers/
acpi/supporting-acpi-devicesBut is there any sample code for this? I could not find any example where
apis like RegisterOpRegionHandler() are used as described below.
https://docs.microsoft.com/en-us/windows-hardware/drivers/
acpi/registering-and-deregistering-an-operation-region-handlerThanks,
Rohit
NTDEV is sponsored by OSR
Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
xxxxx@gmail.com xxxxx@lists.osr.com wrote:
Thank you for your reply. Currently I am trying to write a watchdog driver for Intel Kaby Lake architecture. This hardware is generally controlled by Microsoft driver itself and the resources are shown under mother board resources.
The watchdog hardware is neither on I2C nor on SPI bus. It is interfaced with processor on internal memory bus.
You asked about this several month ago. Have you learned any more about
it since then? Are you absolutely certain that Intel doesn’t have
anything that exposes the watchdog capability? They usually supply
drivers for all of the chipset resources.
Assuming that’s not available – and I suspect it probably IS available
– it seems to me you have two problems. First, you need to be able to
communicate with the resources from driver land. That can be done by
modifying the ACPI BIOS to expose the resources and force your driver to
be loaded. But second, you need to convince the operating system that
your driver is the watchdog driver for the system. I don’t know how
that is done.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank you very much for your reply.
@Tim to answer your question, yes since last time I did found out few new things, that you guys have already mentioned in your answers.
Here is the whole scenario. There is this watchdog hardware provided by Intel itself and is on chip. As you mentioned correctly there is a default driver provided for this by Microsoft. I did learn about this later.
Now my client’s requirement was that, client’s application should be able to have exclusive access to this hardware and should be able to kick the watchdog from User mode. So they needed a custom driver that will have exclusive access of this hardware.
We contacted Microsoft for the same, but Microsoft came back saying the current driver that is handling the device is a platform driver and has other responsibilities too and they wont be able to help much in this case.
So like @Tim correctly pointed out, client modified its BIOS and gave us a new BIOS which exposed the device with different name.
Now this device does show up in RW tool, it has its DSDT table, operation region etc. But the device does not show up in Device Manager. I am not able to find out the device ID. I am not sure how do I start writing the driver for this specific device. This is probably because of my lack of understanding of how ACPI devices are exposed and handled by the system. I will be happy read about it if you guys can point me to the right direction. Or if there is any other way I can handle this.
Thank you,
Rohit
What Mr. Roberts said.
Fighting with the Windows-supplied platform driver, that Windows actually uses for stuff, over a device embedded in the PCH is almost always an invitation to failure. If this client came to OSR, I would almost certainly tell them that we would not do this project (I suppose it would depend on how these systems were used, WHY the client needed the watchdog, and various other things). Shakespeare wrote: “Discretion is the better part of valour” – this is the case for this project, I think.
You mean HARDWARE ID, right? The ACPI namespace object _HID provides the hardware ID. Sooo… if you had
Device(Fred) {
Name(_ADR, 0)
Name(_HID, “Bob”)
Name(_CID, “Poo”)
Name(_UID, 4)
…
}
The Hardware ID in your INF used to load your driver would be ACPI\Bob.
Does that help?
Seriously, tell you management and your client that they don’t want to do this project.
Peter
OSR
@OSRDrivers