up vote 0 down vote favorite
share [g+] share [fb]

I have a Compact PCI card in a PXI chassis; it has 2 BARs of memory which should be accessible via National Instruments NiVisa operations. I'm having trouble with Windows 7 changing the command register on the card during its start up sequence so that the card's memory Bars are inaccessible. I ran a Bus analyzer and observe that the command register of the configuration space is set to a desirable value (0x0197) after BIOS runs.

I'd like this value to persist through the Windows start up sequence. It does remain the same when using the Windows XP operating system, but not when running Windows 7. I've set up a dual booting machine with Windows XP and Windows 7 to make sure all the hardware is the same during the comparison. After the Windows 7 start up sequence, the value is 0x0194.

I am able to set the command register to 0x197 to get those last two bits the way I want them from within the program I'm using to talk to the PXI card, and this allows me to use the card as desired, but it is not a stable fix. I get frequent errors when starting new communication sessions (after closing old sessions) that memory allocation can't be performed by the National Instruments libraries.

  • Is there a way of preventing Windows 7 from configuring the PXI card?

It seems to be already the way I want it after the BIOS is done. It appears that Windows CE disables card configuration with a NoConfig registry flag. I wasn't able to find a method that worked on Windows 7 or Windows XP.

Windows XP attempts to reconfigure the card's configuration space as well, but leaves it in a usable state. Optionally, as it would increase my understanding, but is probably tangential to getting my problem solved, I'm interested in:

  • What difference is the Windows 7 reconfiguration doing that is getting a different outcome in this card than Windows XP gets?
link|improve this question
feedback

1 Answer

up vote 0 down vote accepted

Welcome to the 21st century. You are running a Plug and Play operating system.

You cannot go mapping device memory and I/O registers into memory and I/O space willy-nilly, which is exactly what manually enabling memory and I/O access on your PCI device will do. Mapping device resources has to be done in conjunction with the operating system's Plug and Play manager. The Plug and Play Manager tracks what memory and I/O address ranges are used and by whom, and ensures that no conflicts arise due to (say) multiple devices mapping the same address ranges.

Windows is disabling memory and I/O cycles to your device because it has not been possible to assign memory and I/O resources to your device as part of Plug and Play bus enumeration and resource arbitration. (I'm discounting the possibility that Windows has decided to power you down, given that it has left busmastering enabled.) Either there's simply no room in your machine's physical memory map for the resources that the device wants to map, or it wasn't possible to start your device with an assigned resource configuration. (I'm discounting the possibility that your device is simply broken, and isn't reporting its resource requirements properly in PCI configuration space.)

The latter is the more probable. The usual cause is a PCI device which doesn't have a device driver. Without a device driver to drive the device in the first place, there's no way for the PaP Manager to assign a resource configuration to your device and bring it into the "started" state. These require a (function) device driver to respond to the appropriate PaP IORPs. In which case: Your device needs a device driver.

Device Manager will tell you what is happening with your device in this regard.

link|improve this answer
As I'm not a PCI expert, I turned to the internet to help me debug this issue. A few sites suggested it is appropriate to turn on the bits of the command register from software that are required for your application to run. There shouldn't be a problem with turning on Memory and I/O on your card if you know the card has that capability, and you do so before trying to use the memory and I/O operations available. Do you have any references stating that altering the command register is not to be done? The device manager thinks everything is great with the card. I will search for "IORP". – Atreys Jun 28 '11 at 14:33
You mean apart from section 6.5.2 of the PCI Local Bus Specification version 2.3? (-: It's not hard to work out from first principles that this is not your register to program. The BARs must be set up first, with the addresses assigned by the PaP Manager, because enabling the decoding enables decoding at whatever address is in the BAR. On Windows, all of this stuff is dealt with by the PCI bus driver, which responds to the relevant PaP I/O Request Packets. If the BARs haven't been programmed nor the decoding enabled, it's because PaP management has decided not to. – JdeBP Jun 28 '11 at 15:40
Thank you for the reference, that's very useful. My device manager does list memory address ranges for the BARs for the functions of the card which have memory. Does that mean that PaP has assigned this memory to the card to use? – Atreys Jun 28 '11 at 18:19
If the resources are listed against the device in Device Manager, and Device Manager doesn't indicate a resource conflict, then those resources should have been assigned to the device, yes. For most PCI devices, the PDO provided by pci.sys programs the BARs with the assigned resources when the IRP_MN_START_DEVICE IORP is received. It's possible for a higher-level driver to modify this process. That's a matter for whoever wrote that device driver, though. It's not the normal way of things. – JdeBP Jun 28 '11 at 19:01
That should be section 6.2.5, not 6.5.2, above, by the way. Typing error on my part. – JdeBP Jun 28 '11 at 19:08
show 1 more comment
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.