RE: Device at address 0

[wen-king@myri.com]

>From: Richard Walter <rwalter@brocade.com>

><I'm about to get up on my soap-box...>
>
>In PCI 2.2, page xix, at the bottom of the page:
>
>"Implementation Notes:    Implementation notes are enclosed in a box.  They
>are ***NOT*** part of the PCI specification and are included for
>clarification and illustration only."  (My emphasis added.)
>
>This explanation was also included in PCI 2.1, for which I will provide a
>page reference on Monday.  (I can't right now because I don't have PCI 2.1
>in the office, but keep it at home.)
>
>Therefore, Wen's reference to section 3.2.2 is specifically ***NOT*** part
>of the spec.
>
>PCI 2.1 ***DOES NOT*** state that a 0 BAR is invalid.
>
>I believe that this traces it's roots to an issue about partially
>configuring a device (assigning some BARs and not others) and unfortunately
>ended up with a confusing, poorly worded "solution" that just clouded things
>further.  *sigh*.
>
>Thank you for allowing me to vent... :)
>
><Getting down off of my soap box>
>
>-Richard Walter
>Note: I speak for myself, not for Brocade.

Hello Richard,

Waaaay back, like 6 years ago, I have implemented a PCI interface in
which the BAR is not disabled when set to zero.  Then I came across
something odd during my test and I posted on this mailing list:

    During a logic analyzer test of my pci board, I caught the BIOS
    fiddling with the memory space enable bit before it set the memory
    BAR.  Apparently it is trying to use the writability of the memory
    space enable bit to determine whether the board contain memory
    space BARS.  Is this something that is OK for BIOS to do?   It
    appears to be quite dangerous as it would turn on the board's
    address decoding mechanism without knowing if doing so will create
    address conflicts.  What fun if you happens to have two memory BARs
    on the same board and both of them are mapped to zero.

Then someone replied:

    I doubt if the system BIOS is testing for memory BARs via the mem
    enable bit.  It's simple enough to determine if a board uses any
    memory BARs.  The usual sequence is to assign _all_ BAR resources
    (I/O & MEM), assign an IRQ if requested, then set the enable bits
    as required, then copy & init the expansion ROM via the ROM BAR
    (that's how my BIOS does it).

    I agree that the enable bits should be OFF until a PCI board is
    properly set up, although, technically, any BAR set to 00000000h is
    disabled. At power-on, the board's hardware is responsible for
    clearing mem & I/O enable; during reset (soft or hard), the system
    BIOS often has to ensure that all PCI devices are disabled. This
    may be what you're seeing as 'fiddling'.

Then I responded:

    I don't see how a BAR can be set to all 0, as there are hard-wire
    bits in the lower 4 bit positions of a BAR.  If any of them are
    one, then it can't be set to zero.  Perhaps you meant when the
    upper part of the BAR is set to all zero, but I don't see where it
    says that in the spec.

To which the younger you replied:

    This came up recently in the discussion about mixing of 32-bit and
    64-bit BARs.  On page 26 of the 2.1 spec, section 3.3.2. in the
    Implementation Note:  Device Address Space, the last sentence is
    "Note: A Base Address register does not contain a valid address
    when it is equal to '0'".

    Maybe this should also be explictly stated in the configuration
    chapter as well in the next revision of the spec, because people
    who are looking for information about BARs would look there first.

So I grudgingly went back to rev the implementation, and made sure the
chip is dead as a rock when a BAR's address bits are 0.  And that is
also how I remembered there being this line in the implementation
note.  So now I guess I have to change it back in the next rev.  In any
case, I think it is fair to say that at one point in time setting BAR
to 0 will disable the BAR is widely assumed.
								- Wen