Extended configuration registers of a bridge.

NTDEV
1

OK, I’ve got a problem.

I’m writing a Windows 2000 driver for a device that uses as its interface
an i960RD (or 80303 in the future). This chip is a multi-function PCI
device, with function 0 a PCI-to-PCI bridge and function 1 a messaging
unit for talking with an i960 processor.

The i960 on the board normally starts up on its own via program code
in its flash, but after the initial boot the processor can be restarted
and reloaded at will. The “reset button” for the processor is in a
device specific register of the *bridge* device. The device drivers
resets the processor by:

Saving volatile bits of the configuration space of function 1,
Resetting the processor with a bin in the EBCR, then
Restoring the function unit 1 configuration space.

The problem here is that I need to be able to locate the associated
bridge unit given the processor interface.

Under Linux it’s easy. The bus number is the same, the dfn number is
the same device number but the function number turned to 0. This works
under NT4 as well as the SlotNumber is the same as the dfn under Linux.

But under Windows 2000 there are two (pertinent) problems:

  1. HalSetBusData is “obsolete”, and
  2. the PnP monster doesn’t give me the SlotNumber needed
    to pass to HalSetBusData anyhow.

I see that there are PnP IRPs for manipulating the config space
of the self device, but those IRPs don’t have any slot number parameter
and can’t (so far as I can tell) be made to apply to another device.

So how can I, under WDM:

  1. Find a PCI device with this very specific relationship,
  2. Access the config space of said device to do what needs
    to be done.

–
Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

Stephen,

I’m assuming this is for a transparent bridge, so for starters it’s just not
available/supported/documented/legal/allowed for your driver to
configure/modify the bridge’s registers (ie. a ‘hard problem’). Have the
hardware designer make a register accessible from the function 1’s memory
mapped or port mapped address space, or solder a big button on the board.
[ note - If, however, it’s a non-transparent bridge, you can just load a
driver specifically for it and access it as you described below from
within that driver (instead of the driver for the i960 - you can communicate
between the drivers). ]

Now, that said, it appears from your messages you’re doing this just for
firmware debugging purposes. One the firmware is ‘right’, I’m assuming
you’ll put that in flash and deploy (… and hoping you’re not considering
using the following technique for upgrading once it’s deployed…).

I would be absolutely loathe to ship a production driver with the
following technique, but I’m guessing (and hoping) you’re only wanting to do
this for debugging your driver/firmware, so I’ll suggest it. If that’s not
the case, please do not associate my name with this technique!

This method contains a synchronization bug (since the bus driver is entirely
possibly doing the exact same thing at the exact same time…) and also
makes a large number of assumptions about the system you’re running on (such
as it’s X86, PCI config mechanism #1 supported or PCI 2.2 compliant, I could
go on.)



You can very easily generate the PCI config cycles just by using the
registers at 0x0CF8 and 0xCFC (for details see PCI config mechanism in 2.2
spec or PCI config mechanism #1 in 2.1). Write the address (in config
space) that you want to access into 0x0CF8 (AS A 32b VALUE), then read/write
the data (ALSO AS A 32b VALUE) to/from 0xCFC. A few minutes of searching on
the web will likely turn up some code to do that to search for a card on all
buses in a machine. The format of the address is also available on the web
and in the PCI spec. You can get most of the address bits from your
function’s PDO by using the IoGetDeviceProperty call as described in
Q253232:
http://support.microsoft.com/support/kb/articles/Q253/2/32.ASP

DO NOT DO NOT DO NOT deploy your driver with such an aggregious hack as what
I’ve suggested here. If the 20 min. it takes to write that hack hack hack
code keeps you from rebooting/reseting your machine a couple hundred times
during debugging of your firmware, however, great…

-Tim

Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Stephen Williams
> Sent: Thursday, May 03, 2001 3:54 PM
> To: NT Developers Interest List
> Subject: [ntdev] Extended configuration registers of a bridge.
>
>
>
> OK, I’ve got a problem.
>
> I’m writing a Windows 2000 driver for a device that uses as its interface
> an i960RD (or 80303 in the future). This chip is a multi-function PCI
> device, with function 0 a PCI-to-PCI bridge and function 1 a messaging
> unit for talking with an i960 processor.
>
> The i960 on the board normally starts up on its own via program code
> in its flash, but after the initial boot the processor can be restarted
> and reloaded at will. The “reset button” for the processor is in a
> device specific register of the bridge device. The device drivers
> resets the processor by:
>
> Saving volatile bits of the configuration space of function 1,
> Resetting the processor with a bin in the EBCR, then
> Restoring the function unit 1 configuration space.
>
> The problem here is that I need to be able to locate the associated
> bridge unit given the processor interface.
>
> Under Linux it’s easy. The bus number is the same, the dfn number is
> the same device number but the function number turned to 0. This works
> under NT4 as well as the SlotNumber is the same as the dfn under Linux.
>
> But under Windows 2000 there are two (pertinent) problems:
>
> 1) HalSetBusData is “obsolete”, and
> 2) the PnP monster doesn’t give me the SlotNumber needed
> to pass to HalSetBusData anyhow.
>
> I see that there are PnP IRPs for manipulating the config space
> of the self device, but those IRPs don’t have any slot number parameter
> and can’t (so far as I can tell) be made to apply to another device.
>
> So how can I, under WDM:
>
> 1) Find a PCI device with this very specific relationship,
> 2) Access the config space of said device to do what needs
> to be done.
>
>
> –
> Steve Williams “The woods are lovely, dark and deep.
> xxxxx@icarus.com But I have promises to keep,
> xxxxx@picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@driverdev.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

xxxxx@driverdev.com said:

Have the hardware designer make a register accessible from the
function 1’s memory mapped or port mapped address space, or solder a
big button on the board.

The hardware designer is Intel Corp. The PCI-to-PCI bridge and the
i960 w/ its own PCI interface are on the same slab of silicon. (Too
big to call it a “chip”:slight_smile:

xxxxx@driverdev.com said:

You can very easily generate the PCI config cycles just by using the
registers at 0x0CF8 and 0xCFC

Ack! No! Not that!

This is the deal. There is a “boot firmware” that starts the board
going, and lets the host O/S get on with booting. However, the customer
firmware is loaded into the i960 (with the help of the boot firmware)
in order to start the device. The boot firmware and the customer
firmware talk the same interface, so the host driver can stay throughout,
but the resets are needed to return to the boot firmware.

The customer can have several different firmwares, for example one for
full-speed operation and another for calibration and technical access.

Also, by this same technique, the bootstrap flash is field upgradable.

Anyhow, there are reasonably canonical ways to do this under Linux and
NT. It worked under NT in spite of NT’s abuse of bridges because the
necessary bits are in the vendor specific area of the bridge. It’s safe.
It is just Windows 2000 that is being stubborn … as usual.

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

> You can very easily generate the PCI config cycles just by using the

registers at 0x0CF8 and 0xCFC (for details see PCI config mechanism in 2.2
spec or PCI config mechanism #1 in 2.1). Write the address (in config
space) that you want to access into 0x0CF8 (AS A 32b VALUE), then read/write
the data (ALSO AS A 32b VALUE) to/from 0xCFC.

This won’t help the current situation, but FYI, you can read/write 0xCFC,
0xCFD, 0xCFE, or 0xCFF for 32,24,16, or 8-bit accesses respectively. Some
hardware will not allow 32-bit r/w on smaller sized registers.

But, as you stated, one should never even think about shipping code that
does this in an NT/2000 driver.

Bill M.

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

5

> This won’t help the current situation, but FYI, you can read/write 0xCFC,

0xCFD, 0xCFE, or 0xCFF for 32,24,16, or 8-bit accesses
respectively. Some
hardware will not allow 32-bit r/w on smaller sized registers.

Whoops, sorry - good catch. You’re right (fingers got ahead of the brain
there…).

-Tim

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

6

>

This won’t help the current situation, but FYI, you can read/write 0xCFC,
0xCFD, 0xCFE, or 0xCFF for 32,24,16, or 8-bit accesses respectively. Some
hardware will not allow 32-bit r/w on smaller sized registers.

Oops, I think I somewhat misstated that, I believe you can do 8-bit
transactions from any of those registers, 16-bit from 0xcfc, 0xcfd, or
0xcfe, 24-bit from 0xcfc, or 0xcfd, and 32-bit only from 0xcfc. And, the
accesses are guaranteed to only touch the bits of interest.

Been a while since I worked at that level :slight_smile:

Bill M.

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

7

> Anyhow, there are reasonably canonical ways to do this under Linux and

NT. It worked under NT in spite of NT’s abuse of bridges because the
necessary bits are in the vendor specific area of the bridge. It’s safe.
It is just Windows 2000 that is being stubborn … as usual.

Without getting into too much of a debate about whether it’s the ‘correct’
approach, I’d still recommend that Intel move the reset/reload functionality
in the next rev, at least to the config space of the FUNCTION that’s being
reset, if not to memory mapped or port mapped registers. Another good
approach would be to use a non-transparent bridge (for which you could then
just write a device driver). Since that’s all in one slab terminology>, and the OS/bus driver owns the bridges, this won’t be the last
time this problem shows up.

HalSetBusData[ByOffset] exists on Windows 2000 and works like it does on NT4
on the common Windows 2000 platforms. Calling it is cleaner than my last
suggestion, but still obsolete/dangerous. I don’t know if it lets you get
at a bridge’s vendor specific area, but given you already have the code,
it’s a reasonable thing to test/try.

A separate bus driver or perhaps just a bus filter driver that handles the
differences in this bridge is probably the most correct approach from a ‘PnP
Windows 2000 driver’ perspective. That driver could provide a private
interface to the function driver to reset the device. There may be other
issues with reconfiguring the device ‘on the fly’, if the configuration also
[potentially] changes the common config space on the device. The bus driver
would be the correct place to deal with those issues. Develoment of such a
driver is not a trivial undertaking.

-Tim

Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

8

Steve,

I saw your posting on ntdev and it struck a chord. I am currently
“porting” an NT driver to WDM. The target board also contains an i960 and
I seem to be having similar problems with the PCI bridge. It seems we
might both gain by pooling our knowledge. However, I do not claim to be an
expert.

As you know, with WDM you can’t go looking for PCI device, you have to be
informed about them. The driver then creates a device object for the PCI
device which is then added to a Device stack. All operations on the PCI
device are then performed through that device object (often by the Bus
Driver PDO that resides at the bottom of the Device Stack). I hope that
this is correct and makes sense.

This is fine for the i960 MU and my driver is informed of its presence and
creates a device which receives an AddDevice entry point call and PNP
notifications for the i960 MU. [By the way, this might be a method by
which you could obtain the slotnumber information, although I’m not sure
how this helps you.]

However, it seems that the i960 PCI bridge is handled by the system. The
system creates a device object for the bridge (I think that you can verify
this using DEVVIEW). If there were a way to obtain a handle on this device
object then I believe that we could access the configuration data space
using the method described in Q253232 (this seems to work for the other
PCI devices). In my case, I want to obtain the secondary bus identity, in
order that I can correctly associated the devices on the i960 secondary
bus with the relevant i960 (see my ntdev posting #11576 - the problem with
IRP_MN_READ_CONFIG was that it was accessing the MU device not the PCI
bridge).

One big problem I have had is with the architecture of Device Objects
when there is a secondary PCI bus, but I won’t go into that unless you
want me to.

I hope this helps and that we can help each other through this foreign
land.

Regards,
Richard

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

9

xxxxx@driverdev.com said:

I’d still recommend that Intel move the reset/reload functionality in
the next rev, at least to the config space of the FUNCTION that’s
being reset, if not to memory mapped or port mapped registers.

a) You think *you* can convince Intel of anything?

b) tons of hardware already in the field. Each assembly costs in the
vicinity of $5000.

c) The super-latest, just barely starting production, version of this
chip is the 80303, and it is structured the same way.

Besides, the hardware design, including the placement of the reset bit,
is not completely unreasonable, and it works conveniently and reliably
in other operating systems.

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

10

xxxxx@cix.co.uk said:

I saw your posting on ntdev and it struck a chord. I am currently
“porting” an NT driver to WDM. The target board also contains an i960
and I seem to be having similar problems with the PCI bridge. It
seems we might both gain by pooling our knowledge. However, I do not
claim to be an expert.

I may punt on this. The inbound doorbell register has a NMI bit, and
if I change the run-time of my flash and firmwares appropriately, I
can use that to do a soft reset. This rules out Windows 2000 for firmware
development, but that’s OK as I can get away with requiring Linux for
that.

It’s painful, because I will need to upgrade all the boards in the field
(replace their flash) with “Windows 2000 compatible” flashes, and I will
also have to upgrade all the customer firmwares to be 2000 compatible.

Somebody, shoot me now:-(

(BTW, “porting” NT drivers to 2000 is pointless, I’ve found. The PCI
API is so different that there is really no use. Better to start from
an empty editor screen, write all the detection and access code for 2000,
then use the NT driver as a reference for the new 2000 version. Most of
a windows driver is appeasement for the O/S anyhow.)

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

11

This sounds very similar to a problem I’m trying to deal with.

I have an HBA that contains an i960, and am in the process of implementing
IRP_MN_REMOVE_DEVICE.

W2k DDK doc describes this 11 step process for removing a device in a
function driver. I got to step 3 “Ensure the device is inactive”, and
decided I would do this by resetting it. To reset it, I need to write to the
config space of the bridge. (My device is function 1, the bridge is function
0).

The OS configures the bridge as a standard PCI bridge, and I can see no way
of getting a handle to it so I can issue a IRP_MN_WRITE_CONFIG to write the
config space.

But maybe I’m trying to do this the wrong way. What I want to achieve is to
prevent the device generating any more interrupts. It is connected to a
network with packets coming in all the time. I suppose I could send it some
kind of message telling it to shut down, and then wait for a handshake
indicating that the device had acted on the message (seems complicated). I
know that simply resetting will do the trick, because that’s how it is done
for this device in another OS.

In general, how does one ensure that such a device is inactive (i.e., won’t
generate any more interrupts) ?

Neil

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

12

Disable the device via it’s Command register in it’s PCI config space (i.e.
not on the bridge).

----- Original Message -----
From: “Neil Baylis”
To: “NT Developers Interest List”
Sent: Friday, May 04, 2001 10:24 AM
Subject: [ntdev] Extended configuration registers of a bridge.

> This sounds very similar to a problem I’m trying to deal with.
>
> I have an HBA that contains an i960, and am in the process of implementing
> IRP_MN_REMOVE_DEVICE.
>
> W2k DDK doc describes this 11 step process for removing a device in a
> function driver. I got to step 3 “Ensure the device is inactive”, and
> decided I would do this by resetting it. To reset it, I need to write to
the
> config space of the bridge. (My device is function 1, the bridge is
function
> 0).
>
> The OS configures the bridge as a standard PCI bridge, and I can see no
way
> of getting a handle to it so I can issue a IRP_MN_WRITE_CONFIG to write
the
> config space.
>
> But maybe I’m trying to do this the wrong way. What I want to achieve is
to
> prevent the device generating any more interrupts. It is connected to a
> network with packets coming in all the time. I suppose I could send it
some
> kind of message telling it to shut down, and then wait for a handshake
> indicating that the device had acted on the message (seems complicated). I
> know that simply resetting will do the trick, because that’s how it is
done
> for this device in another OS.
>
> In general, how does one ensure that such a device is inactive (i.e.,
won’t
> generate any more interrupts) ?
>
> Neil
>
> —
> You are currently subscribed to ntdev as: xxxxx@home.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

13

xxxxx@home.com said:

Disable the device via it’s Command register in it’s PCI config space
(i.e. not on the bridge).

That will stop bus-mastering, but will not turn off interrupts that
the i960 processor decides to send.

–
Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

14

You can disable the I/O and memory accesses also. This way when you get the
interrupt they’ll be no way you could possibly clear it
----- Original Message -----
From: “Stephen Williams”
To: “NT Developers Interest List”
Sent: Friday, May 04, 2001 1:28 PM
Subject: [ntdev] Re: Extended configuration registers of a bridge.

>
> xxxxx@home.com said:
> > Disable the device via it’s Command register in it’s PCI config space
> > (i.e. not on the bridge).
>
> That will stop bus-mastering, but will not turn off interrupts that
> the i960 processor decides to send.
>
> –
> Steve Williams “The woods are lovely, dark and deep.
> xxxxx@icarus.com But I have promises to keep,
> xxxxx@picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@home.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

15

Tim,

Thanks for this. It seems like an excellent suggestion and I have been
trying to get it working but I have not been successful.

I searched through the registry to find the GUID for the PCI bridge and
found it to be GUID_DEVCLASS_SYSTEM. I also set the
PNP_NOTIFY_DEVICEINTERFACE_INCLUDE_EXISTING_INTERFACES flag but I did not
get back any notifications to my callback routine.

I extended my code to register for all GUIDs in devguid.h and then I did
receive a call to my callback routine, which seems to suggest that the
underlying code is sound. Investigation showed it to be for a device of
class GUID_DEVCLASS_PORTS.

I can’t really see what I could be doing wrong. I can only imagine that I
have the wrong GUID, but it is as determined from the registry. I’m
surprised to only obtain one notification for all these GUIDs.

Thanks,
Richard

-------- Original Message --------

Richard and Steve,

I just dreamed up a way to read/write the
bridge’s config space ‘legally’. It’s a lot of code, and has some
assumptions. This is so wild I would not post/publish it without trying
it first, but you two are certainly welcome to give it a shot. I believe
the only truly missing piece is the device interface GUID for the PCI
driver’s FDO’s, but that can be deduced from the trying each of the
possible device interface entries in the registry (tedious).

The first assumption is that the PCI bus driver creates an FDO for each
P2P bridge in the system. Seems logical to me, but I have no evidence.

The method is this:
1. Driver uses IoRegisterPlugPlayNotification(GUID>, EventCategoryDeviceInterfaceChange,
PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES ) to enumerate all
P2P bridges in the system.

As each callback is called:

2. Use IoGetDeviceObjectPointer to get a reference to the corresponding
device object for the symbolic link that is passed in the
DEVICE_INTERFACE_CHANGE_NOTIFICATION structure.
3. Send an IRP_MN_READ_CONFIG IRP to see if the vendor/device ids match
the bridge you’re looking for. If not, dereference the file object and
return from the callback.
4. Walk the device object’s AttachedDevice pointer to find the PDO/bottom
driver stack - once again logical, but no evidence> outstanding reference to the device keeps the OS from juggling the bus
numbers - this may be a bad assumption, and hard to prove (unless you’ve
got a Compact PCI expansion chassis or something lying around>
5. Use IoGetDeviceProperty for both your device and for the device you’ve
now got a reference to, and compare results to see if it’s indeed the
specific bridge in question. If not, dereference the fileobject and
return.
6. At this point, you know it’s your bridge, so you can send the
IRP_MN_WRITE_CONFIG to talk to your bridge’s config space.
7. Dereference the fileobject and return.

WHEW! Assuming the assumptions are correct (the first derivitive of an
assumption?), I think that’s all valid. That’s also still quite admitedly
a darn lot of work/code/debugging/trial-and-error for something as simple
as reading a vendor-specific configuration register.

-Tim

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

16

Richard,

So much for theories, darn those assumptions… I can confirm there is no
Device Interface GUID for PCI bus driver’s FDOs, so this method will not
work.

Another similarly complex method would be to track down the
hardware key for the device and add a driver as a filter driver (either
upper or lower filter would likely work), and send the
IRP_MN_READ_CONFIG/IRP_MN_WRITE_CONFIG from that driver.

To track down the hardware key for that bridge, you can probably use
‘something’ along with SetupDiOpenDeviceInfo(),
SetupDiOpenDevRegKey(DIREG_DEV). I say ‘something’ because I’m not
personally aware of a method to enumerate device instances based on the PnP
Device ID and Instance, other than a for() loop and sprintf().

Alternately, you might also be able to add this filter specifically for
bridges with the device/vendor ID using an INF file.

Again, those methods would require some experimentation.

-Tim

Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Richard Edmonds
> Sent: Thursday, May 17, 2001 6:48 AM
> To: NT Developers Interest List
> Cc: xxxxx@lists.osr.com; xxxxx@cix.co.uk
> Subject: [ntdev] Re: Extended configuration registers of a bridge.
>
>
> Tim,
>
> Thanks for this. It seems like an excellent suggestion and I have been
> trying to get it working but I have not been successful.
>
> I searched through the registry to find the GUID for the PCI bridge and
> found it to be GUID_DEVCLASS_SYSTEM. I also set the
> PNP_NOTIFY_DEVICEINTERFACE_INCLUDE_EXISTING_INTERFACES flag but I did not
> get back any notifications to my callback routine.
>
> I extended my code to register for all GUIDs in devguid.h and then I did
> receive a call to my callback routine, which seems to suggest that the
> underlying code is sound. Investigation showed it to be for a device of
> class GUID_DEVCLASS_PORTS.
>
> I can’t really see what I could be doing wrong. I can only imagine that I
> have the wrong GUID, but it is as determined from the registry. I’m
> surprised to only obtain one notification for all these GUIDs.
>
> Thanks,
> Richard
>
>
>
> -------- Original Message --------
>
> Richard and Steve,
>
> I just dreamed up a way to read/write the
> bridge’s config space ‘legally’. It’s a lot of code, and has some
> assumptions. This is so wild I would not post/publish it without trying
> it first, but you two are certainly welcome to give it a shot. I believe
> the only truly missing piece is the device interface GUID for the PCI
> driver’s FDO’s, but that can be deduced from the trying each of the
> possible device interface entries in the registry (tedious).
>
> The first assumption is that the PCI bus driver creates an FDO for each
> P2P bridge in the system. Seems logical to me, but I have no evidence.
>
> The method is this:
> 1. Driver uses IoRegisterPlugPlayNotification(> GUID>, EventCategoryDeviceInterfaceChange,
> PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES ) to enumerate all
> P2P bridges in the system.
>
> As each callback is called:
>
> 2. Use IoGetDeviceObjectPointer to get a reference to the corresponding
> device object for the symbolic link that is passed in the
> DEVICE_INTERFACE_CHANGE_NOTIFICATION structure.
> 3. Send an IRP_MN_READ_CONFIG IRP to see if the vendor/device ids match
> the bridge you’re looking for. If not, dereference the file object and
> return from the callback.
> 4. Walk the device object’s AttachedDevice pointer to find the
> PDO/bottom
> driver > stack - once again logical, but no evidence> > outstanding reference to the device keeps the OS from juggling the bus
> numbers - this may be a bad assumption, and hard to prove (unless you’ve
> got a Compact PCI expansion chassis or something lying around>
> 5. Use IoGetDeviceProperty for both your device and for the
> device you’ve
> now got a reference to, and compare results to see if it’s indeed the
> specific bridge in question. If not, dereference the fileobject and
> return.
> 6. At this point, you know it’s your bridge, so you can send the
> IRP_MN_WRITE_CONFIG to talk to your bridge’s config space.
> 7. Dereference the fileobject and return.
>
> WHEW! Assuming the assumptions are correct (the first derivitive of an
> assumption?), I think that’s all valid. That’s also still quite
> admitedly
> a darn lot of work/code/debugging/trial-and-error for something as simple
> as reading a vendor-specific configuration register.
>
> -Tim
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@driverdev.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

17

> I just dreamed up a way to read/write the
> bridge’s config space ‘legally’. It’s a lot of code, and has some
> assumptions. This is so wild I would not post/publish it without trying
> it first, but you two are certainly welcome to give it a shot. I believe

I’ve come to the simple conclusion that it is plain impossible to get at
the i960RP/80303 processor reset under Windows 2000. I’m going to have
to find another way. And I have to accept that a processor reset means
a Windows 2000 reboot. (The primary PCI RESET# works fine, at least,
although you never know with DELL BIOSes:-/)

P.S. The i960Rx processors have an NMI# bit in the doorbell register
of the messaging unit. I’ve confirmed with Intel, however, that that
bit doesn’t work. I doubt it’s fixed in the 80303.

So reset is inaccessible and the NMI# doesn’t work. Microsoft and Intel
have non-intersecting bugs! Oh, joy.
–
Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com