Getting hardware address of a PnP/PCI device?

NTDEV
1

Ok, more annoying questions!

I need to get the physical address of a PnP/PCI device so I can bash on its registers. I know how to map physical addresses into my drivers process space, but the missing bit of information is figuring out where the I/O space for the device ended up!

I see a thing called SPDRP_ADDRESS that returns “the address of a device”, it appears the address returned is bus-specific… sooo… would this get me where the device lives? Or is there another way?

I see in Vista Device Manager that it displays Address, which appears to be legit physical address… but in “Resources” I see unexpected values in “I/O Range”… hmm.

Searching the forum for SPDRP_ADDRESS turned up some interesting information but not exactly what I needed to know.

Pardon my unfamiliarity with how to grab HW registers in Windows, my experience is mostly in embedded systems and I knew exactly where the hardware was!

I’m running on Vista, by the way, if that makes a difference.

…ed…

2

> I need to get the physical address of a PnP/PCI device so I can bash on its registers.

The addresses are provided to the device’s driver in the MN_START_DEVICE IRP.

As about touching the registers from the code which is other then the device’s PnP driver - this is just plain not supported in Windows. You can try to solve the problem by various hacks, but most of them have the probability of working on not-all machines, or even crashing the machine with 0.00001% probability.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Is your driver the owner of the resources that contain the address? If your
driver is, then your AddDevice routine will, or should acquire those
resources as either translated or raw. If your driver does NOT own that
resource, then mostly you are on your own since you have no business messing
with IO registers that are not your drivers resource.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@woolyloach.com
Sent: Thursday, September 23, 2010 11:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Getting hardware address of a PnP/PCI device?

Ok, more annoying questions!

I need to get the physical address of a PnP/PCI device so I can bash on its
registers. I know how to map physical addresses into my drivers process
space, but the missing bit of information is figuring out where the I/O
space for the device ended up!

I see a thing called SPDRP_ADDRESS that returns “the address of a device”,
it appears the address returned is bus-specific… sooo… would this get me
where the device lives? Or is there another way

I see in Vista Device Manager that it displays Address, which appears to be
legit physical address… but in “Resources” I see unexpected values in “I/O
Range”… hmm.

Searching the forum for SPDRP_ADDRESS turned up some interesting information
but not exactly what I needed to know.

Pardon my unfamiliarity with how to grab HW registers in Windows, my
experience is mostly in embedded systems and I knew exactly where the
hardware was!

I’m running on Vista, by the way, if that makes a difference.

…ed…

NTDEV is sponsored by OSR

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

4

>I know how to map physical addresses into my drivers process space, but the missing bit of >information is figuring out where the I/O space for the device ended up!

From CM_PARTIAL_RESOURCE_DESCRIPTOR you could get not only an address but also a length of memory.

Pardon my unfamiliarity with how to grab HW registers in Windows, my experience is mostly in >embedded systems and I knew exactly where the hardware was!

If you have a specification of hardware you could know physical address in hardware but you should more interested not this address but offset of memory in PCI mapped memory.

Igor Sharovar

5

Ok, obviously I need to tell you WHY I need these addresses.

I’m writing a driver to enable HD Audio testing under WinPE. Audio isn’t officially supported by Microsoft for WinPE, but we still have a requirement to test it on the factory floor in the PE environment. The driver isn’t loaded on boot, so I need to load this thing up, find the addresses, let the user-mode code run the tests, then the system is shut down.

There isn’t anything running but the PE OS and our diags.

Worst-case, if Windows won’t get me the info I need, I’ll plow through the PCI config data until I find what I need - but that’s a comparatively slow process and it also means I’ll have to keep a table of vendor/Device ID/etc. to know when I’ve hit the thing I want.

If I could get the DDI exposed by hdaudbus.sys I’d be home free, because I could send VERBs down to the hardware that way, but from my research doing that would also involve having access to portcls.sys - which I don’t believe exists in WinPE. I really wonder why hdaudbus.sys exists in WinPE at all, given the official stance.

I suppose if it’s going to take a hack to get audio hardware diags running under WinPE, a hack it will be, as little as anyone would like that. :-/

I see there are HAL functions to get this kind of info, but they’re deprecated. Ugh.

6

xxxxx@woolyloach.com wrote:

Ok, obviously I need to tell you WHY I need these addresses.

I’m writing a driver to enable HD Audio testing under WinPE. Audio isn’t officially supported by Microsoft for WinPE, but we still have a requirement to test it on the factory floor in the PE environment. The driver isn’t loaded on boot, so I need to load this thing up, find the addresses, let the user-mode code run the tests, then the system is shut down.

Are you writing a completely custom driver? That is, it’s not really a
media-class device and is not going to participate in the standard audio
stack? If so, then just ignore the HDAudio aspects. You should just be
able to write your own INF that matches the PCI vendor and device IDs of
your device. In that case, the operating system will politely hand the
BAR information to you in the StartDevice callback. You don’t have to
go searching for it. You would BE the device’s driver.

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

7

Going through the PCI config space is a great way to crash Windows
sporatically, this is something you really do not want to do. As Tim
pointed out, if you are just testing the device yourself write a stock
PCI driver (not an audio specific) for the device.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@woolyloach.com” wrote in message
news:xxxxx@ntdev:

> Ok, obviously I need to tell you WHY I need these addresses.
>
> I’m writing a driver to enable HD Audio testing under WinPE. Audio isn’t officially supported by Microsoft for WinPE, but we still have a requirement to test it on the factory floor in the PE environment. The driver isn’t loaded on boot, so I need to load this thing up, find the addresses, let the user-mode code run the tests, then the system is shut down.
>
> There isn’t anything running but the PE OS and our diags.
>
> Worst-case, if Windows won’t get me the info I need, I’ll plow through the PCI config data until I find what I need - but that’s a comparatively slow process and it also means I’ll have to keep a table of vendor/Device ID/etc. to know when I’ve hit the thing I want.
>
> If I could get the DDI exposed by hdaudbus.sys I’d be home free, because I could send VERBs down to the hardware that way, but from my research doing that would also involve having access to portcls.sys - which I don’t believe exists in WinPE. I really wonder why hdaudbus.sys exists in WinPE at all, given the official stance.
>
> I suppose if it’s going to take a hack to get audio hardware diags running under WinPE, a hack it will be, as little as anyone would like that. :-/
>
> I see there are HAL functions to get this kind of info, but they’re deprecated. Ugh.

8

@Tim - hmmph, I didn’t think of that! And yes, this is completely custom, never to ship, not in the standard stack etc. etc. - otherwise I’d tell management it’s not possible, go talk to Microsoft. :wink:

It does match the HD Audio specs, as far as behavior and for test purposes.

If I use devcon to load my driver, will I still get the appropriate callback?

Thanks for the pointer! I’ll look into that right away!

…ed…

9

@don - ouch! Definitely don’t want WinPE crashing on the factory floor, they’d come to my cube and beat me senseless.

Ok, off to crank out a generic PCI driver for the thing!

…ed…

10

xxxxx@woolyloach.com wrote:

@Tim - hmmph, I didn’t think of that! And yes, this is completely custom, never to ship, not in the standard stack etc. etc. - otherwise I’d tell management it’s not possible, go talk to Microsoft. :wink:

It does match the HD Audio specs, as far as behavior and for test purposes.

If I use devcon to load my driver, will I still get the appropriate callback?

Devcon has about a billion options. Which one were you thinking of using?

“devcon install” is the wrong answer. It is a common mistake to make.
“devcon install” invents a brand-new device node out of thin air – one
that is pitifully crying out for a driver – and then triggers the PnP
system so it will go find a driver to satisfy that node and stop the
crying. The problem is that the device node devcon creates has
absolutely no connection to your hardware. It is entirely imaginary.

All you need to do is “pre-install” your driver package. You can do
that with dpinst, or with “devcon dp_add”. That’s doesn’t actually
install any devices – it just puts your INF in a spot where the device
manager can find it (the “driver store”). Then, when your device
appears, pitifully crying out for a driver, PnP will find your driver
package and mate the two together. Happiness ensues.

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

11

@Tim - Alles klar! Thanks for that, I was going to do “install”, which would have produced a ton of hair-pulling when the expected PCI data didn’t appear.

I should be out of everyones hair until next week, now… thanks again!

…ed…

12

Is there anything preventing you from loading a driver that would then
acquire those resources via the normal route of IRP_MN_START_DEVICE? If your
driver is the only one with them then you own them and can do what you want
them. Sounds like you need a driver with a limited control set that gets the
resources, does it’s testing, releases and unloads.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@woolyloach.com
Sent: Thursday, September 23, 2010 12:20 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Getting hardware address of a PnP/PCI device?

Ok, obviously I need to tell you WHY I need these addresses.

I’m writing a driver to enable HD Audio testing under WinPE. Audio isn’t
officially supported by Microsoft for WinPE, but we still have a
requirement to test it on the factory floor in the PE environment. The
driver isn’t loaded on boot, so I need to load this thing up, find the
addresses, let the user-mode code run the tests, then the system is shut
down.

There isn’t anything running but the PE OS and our diags.

Worst-case, if Windows won’t get me the info I need, I’ll plow through the
PCI config data until I find what I need - but that’s a comparatively slow
process and it also means I’ll have to keep a table of vendor/Device ID/etc.
to know when I’ve hit the thing I want.

If I could get the DDI exposed by hdaudbus.sys I’d be home free, because I
could send VERBs down to the hardware that way, but from my research doing
that would also involve having access to portcls.sys - which I don’t believe
exists in WinPE. I really wonder why hdaudbus.sys exists in WinPE at all,
given the official stance.

I suppose if it’s going to take a hack to get audio hardware diags running
under WinPE, a hack it will be, as little as anyone would like that. :-/

I see there are HAL functions to get this kind of info, but they’re
deprecated. Ugh.

NTDEV is sponsored by OSR

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

13

In runtime, I have replaced OEM drivers by simply forcing an install from
device manager. Dunno about PE, but can you not do much the same thing, or
use a bus-filter?

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@woolyloach.com
Sent: Thursday, September 23, 2010 12:20 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Getting hardware address of a PnP/PCI device?

Ok, obviously I need to tell you WHY I need these addresses.

I’m writing a driver to enable HD Audio testing under WinPE. Audio isn’t
officially supported by Microsoft for WinPE, but we still have a
requirement to test it on the factory floor in the PE environment. The
driver isn’t loaded on boot, so I need to load this thing up, find the
addresses, let the user-mode code run the tests, then the system is shut
down.

There isn’t anything running but the PE OS and our diags.

Worst-case, if Windows won’t get me the info I need, I’ll plow through the
PCI config data until I find what I need - but that’s a comparatively slow
process and it also means I’ll have to keep a table of vendor/Device ID/etc.
to know when I’ve hit the thing I want.

If I could get the DDI exposed by hdaudbus.sys I’d be home free, because I
could send VERBs down to the hardware that way, but from my research doing
that would also involve having access to portcls.sys - which I don’t believe
exists in WinPE. I really wonder why hdaudbus.sys exists in WinPE at all,
given the official stance.

I suppose if it’s going to take a hack to get audio hardware diags running
under WinPE, a hack it will be, as little as anyone would like that. :-/

I see there are HAL functions to get this kind of info, but they’re
deprecated. Ugh.

NTDEV is sponsored by OSR

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

14

WinPE has drvload utility to install PnP drivers, instead of device manager

http://technet.microsoft.com/en-us/library/cc766220(WS.10).aspx

–pa

wrote in message news:xxxxx@ntdev…
> @Tim - hmmph, I didn’t think of that! And yes, this is completely custom,
> never to ship, not in the standard stack etc. etc. - otherwise I’d tell
> management it’s not possible, go talk to Microsoft. :wink:
>
> It does match the HD Audio specs, as far as behavior and for test
> purposes.
>
> If I use devcon to load my driver, will I still get the appropriate
> callback?
>
> Thanks for the pointer! I’ll look into that right away!
>
> …ed…
>
>

15

Call me a heritic, but is it a requirement to use WinPE? If not, then I would suggest a minimal Linux-based image or even Windows CE image with the hardware testing app you need. Both are much less restrictive and put more direct hardware control at your disposal.

(Please, no flames, I am just suggesting an option to get the OP what he needs: Test the hardware).

Greg
— xxxxx@woolyloach.com wrote:

From: xxxxx@woolyloach.com
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Getting hardware address of a PnP/PCI device?
Date: Thu, 23 Sep 2010 13:20:28 -0400 (EDT)

Ok, obviously I need to tell you WHY I need these addresses.

I’m writing a driver to enable HD Audio testing under WinPE. Audio isn’t officially supported by Microsoft for WinPE, but we still have a requirement to test it on the factory floor in the PE environment. The driver isn’t loaded on boot, so I need to load this thing up, find the addresses, let the user-mode code run the tests, then the system is shut down.

There isn’t anything running but the PE OS and our diags.

Worst-case, if Windows won’t get me the info I need, I’ll plow through the PCI config data until I find what I need - but that’s a comparatively slow process and it also means I’ll have to keep a table of vendor/Device ID/etc. to know when I’ve hit the thing I want.

If I could get the DDI exposed by hdaudbus.sys I’d be home free, because I could send VERBs down to the hardware that way, but from my research doing that would also involve having access to portcls.sys - which I don’t believe exists in WinPE. I really wonder why hdaudbus.sys exists in WinPE at all, given the official stance.

I suppose if it’s going to take a hack to get audio hardware diags running under WinPE, a hack it will be, as little as anyone would like that. :-/

I see there are HAL functions to get this kind of info, but they’re deprecated. Ugh.

—
NTDEV is sponsored by OSR

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

16

@Greg - I wish! I could have a Linux kernel driver that did this done in a short time, but the Powers That Be have said “WinPE is The Way” and I’m kind of stuck with it. :-/

Ah well, it’s a learning experience, if nothing else.

17

xxxxx@woolyloach.com wrote:

@Greg - I wish! I could have a Linux kernel driver that did this done in a short time, but the Powers That Be have said “WinPE is The Way” and I’m kind of stuck with it. :-/

That’s interesting. And WHY did they decide that? Because WinPE is
free. And what ELSE is free? Linux. Hmmm…

WinPE is not supposed to be used for production systems. It’s supposed
to be used to prepare a given system to receive Windows. You might want
to have the company lawyers check the WinPE license to make sure what
they’re doing is legal.

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

18

@Tim - I have no idea why on Earth the folks here at decided to go that way, someday I’ll corner my boss and find out! I suspect the origins of this choice are lost in the mists of time at this point.

We’re not using WinPE for production systems, it’s being used to test/validate hardware on the factory floor for certain classes of machine. It’s also used to do the Windows install thing, which might be why someone decided to use it to host our diag tools as well. And I’m pretty sure the building full of lawyers this place has, has done due diligence.

Someone definitely didn’t do their homework first, though. Urgh. Funny that I can get 90% of what I need done, done in user mode in full-on Vista via Core Audio APIs.

I guess it’ll look good on a resume’! (famous last words)

19

Ok, just a quick status update as someone may learn from my fail… erm… successes.

I can get my driver to load and get passed memory and interrupt resources, by doing the following:

1: “devcon remove PCI\VEND_1002*” (removes existing driver)
2: “devcon dp_add hdaudtestdrv.inf” (hacked to bind to the HD Audio PCI hardware)
3: “devcon restart PCI\VEND_8086*” (forces PCI rescan as a side effect)

…and, at that point, DbgView shows all my DbgPrint() output from my driver, and when I run my user-mode test app I get the responses I expect (just test responses, no hardware bashing yet).

I’m pretty sure this is the most violent way to cause WinPE to load my driver instead of the default, but by golly it works! WdfVerifier shows my driver loaded with possession of the appropriate PCI\VEN* devices I would expect.

The only reason I have to go through this jiggery-pokery is that WinPE has hdaudbus.sys installed and it wants to load on boot, before I get there. If I can get our build team to remove that there’ll be less violence needed to make this work. I hope… this is pretty unexplored territory for me.

Scary stuff.

…ed…

20

xxxxx@woolyloach.com wrote:

Ok, just a quick status update as someone may learn from my fail… erm… successes.

I can get my driver to load and get passed memory and interrupt resources, by doing the following:

1: “devcon remove PCI\VEND_1002*” (removes existing driver)
2: “devcon dp_add hdaudtestdrv.inf” (hacked to bind to the HD Audio PCI hardware)
3: “devcon restart PCI\VEND_8086*” (forces PCI rescan as a side effect)

…and, at that point, DbgView shows all my DbgPrint() output from my driver, and when I run my user-mode test app I get the responses I expect (just test responses, no hardware bashing yet).

Why is the “remove” necessary? Is the existing driver creating an
HDAUDIO bus, so that your device ID doesn’t appear by itself? If you do
just steps 2 and 3, that’s not enough?

I’m pretty sure this is the most violent way to cause WinPE to load my driver instead of the default, but by golly it works! WdfVerifier shows my driver loaded with possession of the appropriate PCI\VEN* devices I would expect.

The only reason I have to go through this jiggery-pokery is that WinPE has hdaudbus.sys installed and it wants to load on boot, before I get there. If I can get our build team to remove that there’ll be less violence needed to make this work. I hope… this is pretty unexplored territory for me.

Personally, I don’t find that sequence scary at all. It seems like a
straightforward way to do what you need to do, under the circumstances
you are forced to endure. I would have hoped that “devcon update” would
be enough, but if your sequence works, I don’t see anything wrong with it.

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