PCI config space - read only access

[Raj]

I need read-only access to PCI config space to detect hardware problems. I
developed 1394 device driver and use Windows bus driver. So I dont have
access to PCI config space where OHCI registers were mapped. I need to read
or display OHCI registers like Version to know which product to use or for
other debugging purpose.

1) Is there a kernel driver like WinUSB / tool that allows user application
to read PCI config space or any application that will display PCI config
space of a PC ?

2) Is it fairly easy to write a PCI kernel device driver that accomplishes
this. I know a device driver in Windows but never worked with PCI bus driver.

Thanks,
Raj

[Doron Holan [MSFT]]

1) no
2) if you write such a driver you will remove all functionality of the
original dirver (like the ohci 1394 driver). you could write a lower filter
driver in KMDF that uses bus_starndard_interface to look at config space.
as long as you do this only in preparehw() and not at runtime once the pci
funciton driver is running, you should be OK

with that said, I would strongly discourage you from doing this. the amount
of information you can get from this driver is limited, but the amount of
risk you are incurring (esp if you are going to install it on all of your
customer's machines) is very high

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"Raj" <R...@discussions.microsoft.com> wrote in message
news:82AEC0C1-93A3-430A...@microsoft.com...

[Alberto]

There are several tools that display the PCI config space of a PC.
Intel has a Pci Viewer. There's a PCI Explorer out there, also a
PciTree and a PciView; you can Google them up. You can also buy
yourself a VMetro PCI bus analyzer and use its BusView application.
The only problem is, you may need two - one for PCI, another for PCI
Express.

Also, I never tried it, but there's a chance that you may be able to
run a Linux PCI bus viewer from inside a VMWare client or even from
inside Hyper-V. Or, even better, if you install ESX and run your
client OS's such as Linux and/or Windows from inside it, they may
allow direct access to the iron and the client OS's will never know
what's going on. Ain't virtualization great ?

These little viewers seem to work by installing a little driver that
accesses the bare hardware. I personally find the VMetro invaluable,
because it accesses the hardware subarchitecturally from the OS:
Windows doesn't know the difference between running a board raw or
running it through a VMetro. I wouldn't develop a driver without my
VMetros. The VMetro has the additional attractive that you can hook it
to your intranet, and the host machine - where you're debugging from -
can access your VMetro target over TCP/IP. That allows you to diagnose
a server issue, for example, without having to lug the server to your
office or your host machine to the server location. It also saves you
the need for a USB connection.

If you want to access your hardware registers from your own driver, or
from your diagnostics application, the easiest way is to map the PCI
space somewhere you diag program can see it. I do it in my driver and
it works fine. There's no replacement for that kind of functionality,
for example, how do you allow the hardware developer to do dma by hand
inside his diag application when he's testing his prototype chip
that's partly implemented on FPGAs ? How do you allow a hardware
developer to try different strategies to circumvent a chip bug before
he's ready to convey that information to the driver developers ?

That said, remember that this is *dirty* functionality. It should be
for internal company use only. In my driver I have a state machine
that knows when diagnostics opens a device, and that shuts off a lot
of production level stuff because of the inherent danger. I also allow
diags to open a device in "inspect mode" even though that device might
be already open by an application, but I do not allow diagnostics to
open in full functionality mode unless there's nobody else on the
device. The transition rules are complicated, and that's why I have a
state machine!

About installing this kind of thing in your user machine, it depends
on what you want to do. For example, a customer complains that their
board(s) are dead on arrival. You're in Boston, they're in Tokyo. Lest
you want to spend a lot of money going there, the easiest way is to
get the company people at the remote site to install diags on the user
machine, run the sanity test, collect the information, and email it
back to Boston.

And put it this way, if you or your company's people don't do it,
chances are that your user may do it, or worse. If they do it, there's
a chance that they will break it, and inevitably they will blame you
and your company. And while you can control your own people, you
cannot control your customer! If your operation is such that you can
afford to put your board on a consumer market and screw supporting it,
maybe you can do without this kind of functionality; but if your board
is expensive enough, or sophisticated enough, that requires effective
on-site support, I don't know if you can avoid having a comprehensive
set of hardware level diag tools.

Alberto.