Config Space and ROMBARs

NTDEV
1

Here’s what I need to do…

From either user-mode or driver or a combination of both (doesn’t matter
which) I need to be able to read the boot ROM from any PCI device which
has one.

I’ve done a few days research and followed up on snippets as best I could
but don’t have a definitive solution.

IIUC it’s not possible to read/write an arbitrary device’s PCI
configuration space safely, without writing a bus filter driver which,
again IIUC, isn’t documented/supported. Yes?

I can enumerate PCI devices and their resources from user-mode using
either the DEVCON sample or my own code via SetupDi_XXX but don’t know how
to identify the ROMBAR resource - there doesn’t appear to be a
corresponding ResType_XXX defined for it.

So my questions are:

* How does one identify ROMBARs in the resource list?

* Assuming I can extract the ROMBAR, can I safely read the contents of the
ROM from any PCI device from either user mode or, if need be, my
existing (though unrelated) device driver?

An aside:

I have downloaded some freeware software called PCI32 which enumerates PCI
devices and dumps the configuration space of all devices. According to the
doco it dynamically installs and removes a driver each time it is run. I’m
wondering if it can *safely* read the PCI config or whether it is throwing
caution to the wind and using I/O port accesses?

Interestingly it detects an unused ROMBAR on my graphics device - config
space dump shows “00000000” so I’m assumming it actually probes the
register, ie. it’s actually writing to config space!

Any advice would be greatly appreciated!

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

2

Mark,

I can’t come up with a way for you to do this. ROM BARs are unique in that they can be enabled or disabled - regular BARs can only be controlled with the global memory decode. So it’s possible to have a fully functional device that has a ROM BAR but doesn’t have it turned on. The low bit of the BAR indicates whether it is enabled, so 0 in your video device is just an un-enabled ROM BAR.

Because of this, and because ROM BARs aren’t generally useful during system runtime, the Windows PCI driver only enables and configures a ROM BAR on demand, when it receives a QueryInterface from the driver stack asking it to do so. The ROM BAR is not listed in the resource list, and does not have space allocated for it in any way, so its location isn’t retrievable from user-mode (it doesn’t have a location most of the time). I can’t even think of a way to probe the BAR to see if it is supported or simply unused.

The NT4 method of accessing config space from a driver is HalGetBusData. It allows access to arbitrary devices but isn’t hooked into the PnP system, meaning the values you read can be changing out from under you. It has a number of problems because of this, and therefore isn’t logo-able. For your purposes, however, it’s worse than that. Reading the value of the ROM BAR using this interface will probably not be a huge problem. Probing the BAR to see whether it exists opens you up to conflicts with the (possibly active) driver for the device.

But programming the ROM BAR to a legitimate address that will be decoded by the device is basically impossible. When the Windows PCI driver is asked to do this on behalf of the driver, it can make some guarantees about what the driver is and is not doing with the device. You can’t do that, so I’m not sure how you would find yourself a good address to program into the ROM BAR in order to read it. Because of this, I’m not even sure that HalGetBusData helps very much.

This isn’t a whole pile of help, but hopefully it explains what you are seeing a bit more.

Dave

3

xxxxx@microsoft.com wrote:

Because of this, and because ROM BARs aren’t generally useful during
system runtime, the Windows PCI driver only enables and configures a
ROM BAR on demand, when it receives a QueryInterface from the driver
stack asking it to do so.

Thanks for your response!

If a PCI device does boot from ROM, would that ROMBAR always be
enabled during system run-time, or is it conceivable that once a card has
booted, the system/driver could then disable that ROMBAR???

In a nutshell, I’d only be interested in ROMs that were active during
booting, so I’m hoping that such ROMs (ROMBARs) would be (still) enabled
during system runtime?!?

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

4

Mark, I’ve never once seen an active ROM BAR. It seems as if the system BIOS tends to have an implementation similar to Windows - enable the BAR, post the ROM into some location in RAM, then disable the BAR.

Sorry I can’t be more helpful.

Dave

5

xxxxx@microsoft.com wrote:

Mark, I’ve never once seen an active ROM BAR. It seems as if the
system BIOS tends to have an implementation similar to Windows - enable
the BAR, post the ROM into some location in RAM, then disable the BAR.

Sorry I can’t be more helpful.

Ah well, I got what I paid for! :wink:

But seriously, thanks for your input. After my last post I realised that
if Windows doesn’t store the ROMBAR in the resource list, then I wouldn’t
be able to read it from config space of an arbitrary device even if it
was enabled.

Looks like the customer will have to settle for reading the ROMs in the
boot-loader, which should be straight-forward. Just not sure if that
satisfies their requirements…

Thanks again!
Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

6

Let me add to what Dave is saying. If you read the PCI spec carefully, it
says that you’re allowed to share the decoders between your ROM BAR and one
of your runtime BARs, implying that they can’t both be enabled at once.
Thus BIOSes tend to copy the contents of a ROM BAR into shadow memory and
then disable it. Only the driver for the device can know if it can be
safely turned on after that.

  • Jake Oshins
    Windows Kernel Team

“Mark McDougall” wrote in message news:xxxxx@ntdev…
> xxxxx@microsoft.com wrote:
>
>> Because of this, and because ROM BARs aren’t generally useful during
>> system runtime, the Windows PCI driver only enables and configures a
>> ROM BAR on demand, when it receives a QueryInterface from the driver
>> stack asking it to do so.
>
> Thanks for your response!
>
> If a PCI device does boot from ROM, would that ROMBAR always be
> enabled during system run-time, or is it conceivable that once a card has
> booted, the system/driver could then disable that ROMBAR???
>
> In a nutshell, I’d only be interested in ROMs that were active during
> booting, so I’m hoping that such ROMs (ROMBARs) would be (still) enabled
> during system runtime?!?
>
> Regards,
>
> –
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, http:
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266
></http:>

7

Jake Oshins wrote:

Let me add to what Dave is saying. If you read the PCI spec carefully,
it says that you’re allowed to share the decoders between your ROM BAR
and one of your runtime BARs, implying that they can’t both be enabled
at once. Thus BIOSes tend to copy the contents of a ROM BAR into shadow
memory and then disable it. Only the driver for the device can know if
it can be safely turned on after that.

Very interesting! Thanks Jake!

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>