Accessing the LPC interface using Microsoft's IPMIDrv.sys

NTDEV
1

Hi All,

I have a server system on which a LPC interface is exposed through a ISA bridge sitting on the PCI device. When I go to the device manager I see that a Microsoft provides the driver for the bridge device. For LPC device on this Bridge the Microsoft’s IPMIDrv.sys is loaded and the device is working fine. My requirement is to be able to read and write to this LPC interface from a user mode application.

Is there any documented API for doing this (like IOCTLS exposed by the IPMI Driver etc?)

Please let me know.
Appreciate your help in advance.

Thanks,
Ajitabh

2

Ajitabh Saxena (ajisaxen) wrote:

I have a server system on which a LPC interface is exposed through a ISA bridge sitting on the PCI device. When I go to the device manager I see that a Microsoft provides the driver for the bridge device. For LPC device on this Bridge the Microsoft’s IPMIDrv.sys is loaded and the device is working fine. My requirement is to be able to read and write to this LPC interface from a user mode application.

Is there any documented API for doing this (like IOCTLS exposed by the IPMI Driver etc?)

This topic has been a matter of spirited debate over the last few
years. The LPC is basically a bus that offers access to other
resources. Sometimes, those resources can be enumerated in your ACPI
BIOS DSDT, which allows you to load a driver for them. Specifically,
what kind of resource do you need to access? I/O port? GPIO pin? I2C?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

The only documented way to access info from the IPMI driver is via WMI. Specifically, there’s a Microsoft_IPMI class.

Peter
OSR
@OSRDrivers

4

Hi Tim,
We are trying to access the IO port to get the BT (Block Transfer) working alongside the Keyboard Style Transfer (KCS). As an experiment I dumped the ACPI tables and saw that the KCS devices was exposed in the ACPI table and the BIOS did not have the BT port entries in the ACPI table. My belief is that once the BIOS guys puts the entry for the block transfer device, it will be exposed as another device to the OS and I should be able to write a driver for that.

Please let me know if I am overlooking something here.

Thanks
Ajitabh

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, July 06, 2015 11:03 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Accessing the LPC interface using Microsoft’s IPMIDrv.sys

Ajitabh Saxena (ajisaxen) wrote:

I have a server system on which a LPC interface is exposed through a ISA bridge sitting on the PCI device. When I go to the device manager I see that a Microsoft provides the driver for the bridge device. For LPC device on this Bridge the Microsoft’s IPMIDrv.sys is loaded and the device is working fine. My requirement is to be able to read and write to this LPC interface from a user mode application.

Is there any documented API for doing this (like IOCTLS exposed by the
IPMI Driver etc?)

This topic has been a matter of spirited debate over the last few years. The LPC is basically a bus that offers access to other resources. Sometimes, those resources can be enumerated in your ACPI BIOS DSDT, which allows you to load a driver for them. Specifically, what kind of resource do you need to access? I/O port? GPIO pin? I2C?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Ajitabh Saxena (ajisaxen) wrote:

We are trying to access the IO port to get the BT (Block Transfer) working alongside the Keyboard Style Transfer (KCS). As an experiment I dumped the ACPI tables and saw that the KCS devices was exposed in the ACPI table and the BIOS did not have the BT port entries in the ACPI table. My belief is that once the BIOS guys puts the entry for the block transfer device, it will be exposed as another device to the OS and I should be able to write a driver for that.

That is exactly the right path to follow. PnP will load your driver and
hand you the resources.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

I only know that Dell PowerEdge servers once required to replace the MS’s IPMI driver with Dell’s for some (if not all) IPMI features to work.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

“Ajitabh Saxena (ajisaxen)” wrote in message news:xxxxx@ntdev…

Hi All,

I have a server system on which a LPC interface is exposed through a ISA bridge sitting on the PCI device. When I go to the device manager I see that a Microsoft provides the driver for the bridge device. For LPC device on this Bridge the Microsoft’s IPMIDrv.sys is loaded and the device is working fine. My requirement is to be able to read and write to this LPC interface from a user mode application.

Is there any documented API for doing this (like IOCTLS exposed by the IPMI Driver etc?)

Please let me know.
Appreciate your help in advance.

Thanks,
Ajitabh

7

Hi Tim,
With the modified BIOS I am able to see the device under ISA bridge Device (“Unknown Device”) with three port resources. Port numbers assigned to this device are 0x620, 0x621 and 0x622.

Now this device is basically a ACPI device. What type of driver would I need to write for this. I believe the GenPort driver sample should be the way to go for this.

Just want to make sure that I am on the right path.

Please let me know.
Thanks
Ajitabh.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, July 07, 2015 10:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Accessing the LPC interface using Microsoft’s IPMIDrv.sys

Ajitabh Saxena (ajisaxen) wrote:

We are trying to access the IO port to get the BT (Block Transfer) working alongside the Keyboard Style Transfer (KCS). As an experiment I dumped the ACPI tables and saw that the KCS devices was exposed in the ACPI table and the BIOS did not have the BT port entries in the ACPI table. My belief is that once the BIOS guys puts the entry for the block transfer device, it will be exposed as another device to the OS and I should be able to write a driver for that.

That is exactly the right path to follow. PnP will load your driver and hand you the resources.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

Ajitabh Saxena (ajisaxen) wrote:

Just wanted to thank you for your help. The PORTIO driver loads up correctly and acquires all the three port resources. After about 3-4 years I am back in windows domain and doing some useful work. :slight_smile:

Let me give you some food for thought about this.

What you have done here is basically exposed an ISA I/O port to user
mode. Your driver is little more than dumb plumbing that forces the
user-mode application to think about I/O ports and specific bits within
them. That’s not a very good abstraction, nor does it have any future.

Instead, you might think about your interface in a different way.
Instead of just exposing port 0x620, ask yourself “what tasks need to be
done?” When the user-mode app wants to talk to the device, what is it
doing? What things does it need to know? What options does it need to
set? Now, think about having your driver provide those abstract
functions as ioctls instead of raw I/O port access.

That way, your driver can provide a little validation to make sure the
device can’t be left in an inconsistent state, or be asked to do things
in the wrong order, or have undefined bits triggered. Plus, in the next
generation, if the interface should happen to move to USB or PCIExpress,
you can modify the driver without requiring a rewrite of the application.

Now, if you’re just writing hack-em-up tools for diagnostic use in your
design lab, then you can ignore my objections. In that kind of
environment, there’s nothing wrong with having the diagnostic tools
think in terms of bits and registers. But if this will be released into
the wild, you should seriously consider an abstraction.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

Hi Tim,
I 100% agree with you on this and that is the path we are following…The GenPort sample is just a proof of concept and to make sure that we are doing everything right to claim the resources and write to the ports. We are going to a write a new driver for doing exactly what you have stated. We will expose a API set from the driver (IOCTLS) and then write a library which issues those IOCTL to the driver. The Library will expose a bunch of API which the user mode application will use to write applications. This way the application does not even need to know the driver interfaces. We are in process of doing this. What we have done is just an initial exercise to make sure we are on the right path to achieve the objectives.

Thanks again for sharing this information.
Appreciate your help.
Ajitabh

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, July 09, 2015 11:56 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Accessing the LPC interface using Microsoft’s IPMIDrv.sys

Ajitabh Saxena (ajisaxen) wrote:

Just wanted to thank you for your help. The PORTIO driver loads
up correctly and acquires all the three port resources. After about
3-4 years I am back in windows domain and doing some useful work. :slight_smile:

Let me give you some food for thought about this.

What you have done here is basically exposed an ISA I/O port to user mode. Your driver is little more than dumb plumbing that forces the user-mode application to think about I/O ports and specific bits within them. That’s not a very good abstraction, nor does it have any future.

Instead, you might think about your interface in a different way.
Instead of just exposing port 0x620, ask yourself “what tasks need to be done?” When the user-mode app wants to talk to the device, what is it doing? What things does it need to know? What options does it need to set? Now, think about having your driver provide those abstract functions as ioctls instead of raw I/O port access.

That way, your driver can provide a little validation to make sure the device can’t be left in an inconsistent state, or be asked to do things in the wrong order, or have undefined bits triggered. Plus, in the next generation, if the interface should happen to move to USB or PCIExpress, you can modify the driver without requiring a rewrite of the application.

Now, if you’re just writing hack-em-up tools for diagnostic use in your design lab, then you can ignore my objections. In that kind of environment, there’s nothing wrong with having the diagnostic tools think in terms of bits and registers. But if this will be released into the wild, you should seriously consider an abstraction.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer