[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 64 Bit Base Address Register
On Thu, 2 Nov 2000, O'Shea, David J wrote:
> You raise an interesting point on the PCI-to-PCI bridge
> spec (1.1 Header) limitations on non-prefetchable memory.
You misquoted the mail you replied too. It may well have been me, Gérard,
who raised this point.
> Since the P2P header only allows decode regions for non-prefetchable
> memory to be described in the 32-bit address space, we are
> heading toward a limit on non-prefetchable space for large systems.
We may need on such large systems Giga bytes of prefetchable space, but I
cannot imagine, given current technology, any need of Giga bytes of
non-prefetchable space. Could you elaborate, please ?
> Most of the newest chipsets from Intel, Serverworks, VIA, etc.
> are starting to map their Host-bus to I/O bus (PCI) bridges into the
> P2P spec headers. (Including the new 64-bit processor chipsets).
> This is to allow OS S/W some ability to remap resources if it
> so desires by virtue of the STANDARD P2P header. Host-bus bridge
> headers were never standardized.
> This puts an implicit limit of 4GB on the memory mapping of
> devices in a system. Even a really big 64-bit system, with tons
> of slots.
> Is anyone aware of any ongoing activity to revise the PCI-to-PCI
> bridge specification to possibly create a NEW header type for
> P2P bridges that can describe 64-bit windows for non-prefetchable
Seems not simple given than only 4 bytes are still unaffected in the
header and that we need 8 bytes. Note that if we get rid of I/O space,
this will fit just fine.
> -David O'Shea
> -----Original Message-----
> From: Gérard Roudier [mailto:email@example.com]
> Sent: Thursday, November 02, 2000 12:38 PM
> To: Richard Walter
> Cc: 'Olaf Reichenbaecher'; firstname.lastname@example.org
> Subject: RE: 64 Bit Base Address Register
> On Thu, 2 Nov 2000, Richard Walter wrote:
> > Olaf,
> > You are correct: A 64-bit BAR is created by "concatenating" two
> consecutive 32-bit registers together. The one at the lower address is the
> low 32-bits and include the indicator fields. The one at the next higher
> address is the upper 32-bits.
> > And Yes, if a device has all 64-bit BARs, then it can only have 3 of them.
> > If you want more, then you could have a multi-function device, where one
> function contains the first 3 64-bit BARs and the second function has the
> next 3 64-bit BARs and the the third function has the next 3 64-bit BARs,
> Indeed, but since PCI-to-PCI bridge spec. does not allow non prefetchable
> to be mapped beyond the 4GB limit, using 64 bit BAR for a non-prefetchable
> MMIO window is probably not worthwhile. Obviously, it is a different
> issue if the window is prefetchable (i.e. memory-like behaviour).
> > -Richard Walter
> > Hardware Engineer
> > email@example.com
> > Note: I speak for myself, not for Brocade.
> > -----Original Message-----
> > From: Olaf Reichenbaecher [mailto:Olaf.Reichenbaecher@sci-worx.com]
> > Sent: Thursday, November 02, 2000 6:07 AM
> > To: firstname.lastname@example.org
> > Subject: 64 Bit Base Address Register
> > hi there,
> > i am currently dealing with the issue to design a 32-bit PCI
> > interface module which supports 64-bit addressing (DAC).
> > i am wondering what the topology of the BARs in the CS header
> > looks like.
> > assuming an address space of 2GB or less which may be located
> > anywhere in the 64-bit address space, the BAR pointing to that
> > address space has to implement 33 or more (dependent on the
> > actual size) read-write bits.
> > is this accomplished by "concatenating" 2 subsequent 32-bit BARs
> > in the CS header? which one would be the upper part (bits 63:32),
> > which one the lower (bits 31:0). which of the "concatenated"
> > BARs features the indicator fields (prefetch/type/mem-io)?
> > does that mean a PCI function may only claim a maximum of
> > 3 base address spaces if all of them may be located
> > anywhere in the 64-bit address space?
> > although i scanned through the archive and found a number
> > of valuable information this issue is quite unclear to me.
> > even the spec was not of much help.
> > can someone please shade some light on this? any help
> > appreciated.
> > regards
> > olaf
> > --
> > Olaf Reichenbaecher
> > Senior Design Engineer
> > _____________________________
> > sci-worx GmbH
> > Garbsener Landstr. 10
> > 30419 Hannover
> > Germany
> > Tel +49 (0)511 277-1432
> > Fax +49 (0)511 277-2410
> > Olaf.Reichenbaecher@sci-worx.com
> > www.sci-worx.com