[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Disabling a BAR



To continue a discussion from a while back:

What is the correct behavior for a target device if a BAR is configured
(by software) with all zeros (in the address field)?

The PCI 2.1 specification says (page 26) '...does not contain a valid
address when it is equal to "0".'  It does not distinguish between the
address field of the BAR and the entire BAR, but the context would imply
the address field.  In addition, the implementation note describes a
scenario where configuration software could choose to disable some BARs
in a device without disabling the device entirely (I don't want to get
into a discussion about whether this is a good idea since my application
is mapping address spaces between PCI and another bus and I need to
support several distinct mapping regions and allow the system
implementer a choice on using them).

In reviewing the mailing list archives, I found several references to
configuration software disabling a BAR and one that stated that writing
zero to a BAR should disable it.  I did not find any statement defining
what disabling a BAR meant in hardware terms.

More questions:

Is a BAR supposed to be disabled when configuration software writes a
particular value (presumably zero, although all ones would make sense as
well)?

Is it non-compliant for a target device to respond to an address of zero
(up to the range of the BAR) if one of its BARs is configured with a
zero address field (the core I am using does)? 

If a BAR is disabled, does that mean that it should read back as
non-existent (LS four bits forced to zero)?  Is it sufficient for it to
just not respond to bus transactions?  Will it confuse any software if
the BAR reads as existing but zero?

I am planning on detecting a zero address field to disable a BAR and
ignore any address within the range defined by that BAR.  I plan to
force the LS four bits to zero if the address range is zero.

Comments/Answers?

Cliff Kimmery
Honeywell Inc.
kimmery@space.honeywell.com
”¬œ