RE: Base Addresses, PCI Spec 2.2, Section 6.2.5

[Lame Brooks-G14738 <brooks.lame@motorola.com>]

Oh, boy, there we go "assuming" again (as stated in original message below);
the app note "Sizing a 32-bit base address register example" is just that,
checking the size of a BAR without disturbing the contents - it's not
"Allocating system resources and configuring a PCI device."  Nowhere does
the note say "host", nor "system", nor that the software is configuring the
BAR for first-time use.  Also, implementation notes and examples are not
part of the PCI requirements, but are there to aid understanding of its
mechanisms.  Further, a spec is not ussually a 'how-to' document, it just
describes the mechanisms that it provides.   And, you must keep in mind that
the PCI spec is primarily a bus spec - not specific to any processor
architecture; the code that configures a BAR for use may be some pre-boot
firmware as in a PC PnP BIOS, an OS, a special device driver, or some other
software.  I would think it "obvious to even the most casual observer" (to
quote an old friend) that some code must at some time write a valid address
into the BAR in order to use the BAR and that this code may not be the same
for all platforms.  In IntelArch PC systems, the PnP BIOS typically does
most if not all the PCI configuration and BAR value assignments.  
-- BrooksL

> -----Original Message-----
> From: David Shema [mailto:dkshema@collins.rockwell.com]
> Sent: Thursday, 11 May, 2000 13:12
> To: pci-sig@znyx.com
> Subject: Base Addresses, PCI Spec 2.2, Section 6.2.5
> 
> 
> I'm new to PCI.  After thoroughly reading the PCI 2.2 spec, it is
> painfully obvious that section 6.2.5 (and subparagraphs) are NOT clear
> in describing the usage of the Base Address Registers -- BAR0 through
> BAR5.
> 
> There is no definitive part of the specification clearly stating that
> once the size of a particular device's address space is determined by
> the using system, and after the using system assigns the device to a
> specific block in the overall system memory map, that the data
> originally found in the device's Base Address Area is 
> overwritten by the
> system software with the actual starting address of the block assigned
> to the device by the system software.
> 
> Specifically, the implementation note in paragraph 6.2.5.1, pg 204,
> "Sizing a 32-bit base address register example" is in error, and needs
> to be corrected.
> 
> According to the example, the device at power-up, or after reset,
> contains in its Base Address Register location(s) information to allow
> the system software to determine the size of the block of 
> memory (or I/O
> space) required by the device, and information as to whether 
> the device
> is intended for memory space, I/O space, whether the block is
> prefetchable, and if the device is a 32-bit or 64-bit device.
> 
> Again, according to the example, the host software reads the 
> information
> in the BAR "and saves the original value of the Base Address 
> Register".
> Next, the host sofware writes ones to the register, then performs a
> read.  The lower four-bits of the data read back are translated to
> zeros, then the host software calculates the two's-complement of the
> value read from the BAR in question.  This yields the size of 
> the memory
> or I/O block required by the device.  At this point, the host 
> now knows
> how large a block of space to allocate in the host memory 
> map.  I assume
> at this point the host actually makes the assignment of a specific
> address space for this device.
> 
> Continuing with the example in the spec, "the original value 
> in the Base
> Address Register is restored before enabling decode in the command
> register of the device."
> 
> So, we read a value, saved it, performed a two's-complement 
> of the value
> to determine block size, then simply wrote the original value 
> back into
> the BAR.  At no time, did the host software write the ACTUAL PHYSICAL
> BASE ADDRESS allocated by the host software into the BASE ADDRESS
> REGISTER of the device.  Therefore, the device does NOT know which set
> of actual physical addresses to respond to within the system.
> 
> Nowhere within the spec is there a clear, unambiguous 
> statement that the
> BAR initially contains the block size required by the device, and once
> the using system determines where the device is to reside in the
> memory-I/O map of the system, that the initial SIZING data in 
> the BAR is
> REPLACED with the ACTUAL PHYSICAL
> ADDRESS assigned by the using system to the device.  The only example
> given to demonstrate this sequence is in error, and tells us that the
> ACTUAL PHYSICAL ADDRESS is NOT written into the BAR, but rather, the
> initial sizing data is restored to the BAR.
> 
> My recommendation is that the spec be clarified with respect to the
> actual usage of the BARs, and that the example be corrected 
> to show that
> the host software writes the ACTUAL PHYSICAL BASE ADDRESS assigned to
> the device into the BAR (instead of the original stored value), after
> reading the initial sizing information, and mapping of all devices in
> the system.
> 
> Dave Shema
> 
> 
>