[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RE: Not enough address space
- To: Mailing List Recipients <email@example.com>
- Subject: RE: RE: Not enough address space
- From: Lame Brooks-G14738 <Brooks_Lame@mcg.mot.com>
- Date: Tue, 27 Jul 1999 14:51:16 -0700
- Delivered-To: pcisig@teleport.COM
- Resent-Date: Tue, 27 Jul 1999 15:35:17 -0700
- Resent-From: firstname.lastname@example.org
- Resent-Message-ID: <"JU93Z2.0.TS7.7gYdt"@electra.znyx.com>
- Resent-Sender: email@example.com
> > If a BAR request can not be granted, it should be disabled (set
> > to zero).
> I don't believe that the spec says that a zero BAR is disabled.
> In version 2.1 of the spec, the implementation note in 3.2.2, page 26,
> included the sentence ` Note: A Base Address register does not contain
> a valid address when it is equal to "0". ', which many people have
> interpreted as allowing individual BAR enabling/disabling by
> setting to zero.
You're right, it's not explicitly stated, it's implied - you don't deal with
an easily reachable, invalid state by letting any odd thing occur; you deal
with it gracefully by disabling the BAR.
> However, on page xvi (Document Conventions) of that spec, it
> states that ` Implementation notes are enclosed in a box. They are
> **NOT** part of the PCI specification and are included for clarification
> and illustration
> only. ' (emphisis mine.) So, that sentence about a 0 BAR is
> NOT part of the spec.
Right again, it's not part of the spec, rather it's a clarification that
explains how the spec is intended to work.
> In version 2.2 of PCI, that implementation note in 3.2.2, page 27, has
> had that last sentence dropped, so it doesn't even mention zero BARs.
> While I have not done a complete search through the entire 2.2 spec, I
> did look in the area of BARs in config space and there is no
> mention there
> about a zero BAR being disabled either. If the 2.2 spec does
> state that
> a zero BAR is disabled, I would appreciate it being pointed out to me.
Hmmm, I hadn't noticed that note has been dropped in 2.2. That seems to
leave us without a mechanism for disabling individual BARs. I suggest we
ask Brad Hosler and the SIG Compatibility Team to comment since it was he
that pointed out this requirement when I discussed this in-depth with him a
couple years ago regarding compatibility criteria and PCIPOST.exe.
> I see no PCI architectural reason why a zero BAR should not
> be allowed.
I tend to agree except that I see a greater need for a mech to disable
> Yes, Intel platforms cannot have a BAR there, but PCI is
> explicitly not
> tied to a specific CPU architecture and there is no reason why a RISC
> CPU (say, PPC) could not map some CPU address into 0 PCI
Well, with an Intel platform, you could set a PCI dev at PCI addr 0, but
with the typical Intel host bridge, transactions wouldn't be fwded to PCI
until you got over the top of main memory and then if your BAR is smaller
than that, then you'd miss it. However, new chipset architectures are
becoming available where the memory controller and PCI bus controllers are
separate, allowing for different CPU/PCI addr translations. So, it may
become more valuable to be able to put a BAR at 0, which is perhaps why that
implementation note was dropped in 2.2. Brad?
> Well, that depends. A single BAR requesting 2GB cannot ever
> be allocated
> on an Intel platform without 64-bit addressing.
I disagree based on my explanation above.
> That is
> because a 2GB bar
> can only be located in one of two places: 0->2GB or 2GB->4GB.
> It cannot be
> located at 0, because Intel CPUs use that space for interrupt vectors.
> It cannot be located just below 4GB because Intel CPUs use
> that space for
> it's reset vector.
Oops, I believe I was was thinking of a case where I did two 1GB BARs
instead of one 2GB BAR. Sorry for the confusion. However, you can still
allocate a 2GB BAR, w/o all accesses being fwded to PCI (how that affects
device operation is a system issue).
> > --
> > Brooks Lame'
> > Design Engineer, Motorola Monterey Design Center
> > firstname.lastname@example.org, email@example.com
> -Richard Walter
> Note: I speak for myself, not for Auspex.
Design Engineer, Motorola Monterey Design Center