Re: PC System BIOS and Base Address Register

[Bruce Young <Bruce_Young@ccm.jf.intel.com>]

---------------------------- Forwarded with Changes ---------------------------
From: pci-sig-request@znyx.com at SMTPGATE
Date: 8/7/96 4:21PM
*To: pci-sig-request@znyx.com at SMTPGATE
Subject: Re: PC System BIOS and Base Address Register
-------------------------------------------------------------------------------

Text item: 

OK - You caught me being glib and I did not think my answer reply fully! 
You are right, all zeros would mean 4 GB not 0 B as I said if strictly 
interpreted. Consider my sword fallen upon! :-(

The gist of my answer still remains, however. There are no good reasons to 
require the BARs to be contiguous and the INTENT of the spec was not to require 
this. I would agree that the wording could use improvement to make things clear 
but it really doesn't matter which way the hardware guy interprets it and there 
are other mechanisms now to ensure that the BIOS guys do it right.

-Bruce Young
On the net I speak for myself, not Intel

--------------

Bruce Young <Bruce_Young@ccm.jf.intel.com> writes:
     
> A agree with Don James that it is legal to implement non-contiguous 
> Base address Registers (BARs). I would maintain that a BAR
> implemented as read-only all zeros is a request for 0 MB of 
> non-prefetchable 32 bit addressable memory space! (check the 
> details in section 6.2.5.1 of the spec)
     
Could you explain how that section of the spec leads to that 
conclusion?  As I mentioned in my earlier message, I see an all-zero 
BAR as a _reductio_ad_absurdum_ in exactly the opposite direction. 
Having the bottom 4 bits all be zero implies a request for 
non-prefetchable chunk of 32-bit Memory Space.  The spec also states 
that "the device will return 0's on all don't-care address bits, 
effectively specifying the address space required".  Straightforwardly 
applying this rule implies that a BAR with all 28 address bits 
hard-wired to zero should be interpreted as a request for a full 4 GB 
of address space starting at address 0!  Obviously, using the entire 
0-to-4 GB range of memory addresses is unreasonable, so BIOSes are 
logical to treat all-zero BARs as no-ops, but I'm troubled that the 
PCI spec doesn't explicitly call out this case as an exception to the 
general BAR rule.
     
> So a "Compliant" device can implement a BAR at 10h that requests
> 1 MB of 32 bit addressable space, and another BAR at 20h requesting 
> 16 bytes of I/O space and still be fully compliant with the spec.
> The section of the spec referred to by Bob Goudreau was not meant to 
> indicate that no BARs could be skipped. It was meant to describe how 
> you parse the BAR section with a mix of 32 bit and 64 bit registers. 
> I would agree that unless there are good reasons to do otherwise, it 
> is good design practice to put all the "necessary" BARs at the
> beginning with no gaps but I do not believe that it is required by 
> the specification.
     
I'm quite willing to believe that this was the intent of the spec 
writers, but I agree with Daniele Beccari that the next revision 
could use some additional clarifying text.  Someone interpreting 
the 2.1 spec literally would have to conclude that there is no way 
to make "a request for 0 MB" of any type of address space (Memory 
or I/O), because 0 is not a power of 2, and the spec says that:
     
     This design implies that all address spaces used are a power 
     of two in size, and are naturally aligned.
     
(And in fact, the rules for Memory Space BARs are more restrictive 
still, since they make it impossible to request a region smaller 
than 16 bytes, which is what you get when *none* of the 28 Base 
Address bits are "don't-care" bits.)
     
Regards,
     
---------------------------------------------------------------------- 
Bob Goudreau               Data General Corporation 
goudreau@dg-rtp.dg.com          62 Alexander Drive
+1 919 248 6231               Research Triangle Park, NC  27709, USA

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

To: Mailing List Recipients <pci-sig-request@znyx.com>
Resent-Sender: pci-sig-request@znyx.com
Precedence: list
X-Loop: pci-sig@znyx.com
X-Mailing-List: <pci-sig@znyx.com> archive/latest/3423
Resent-Message-Id: <"sD4Si.0.FW3.RlF2o"@dart>
Subject: Re: PC System BIOS and Base Address Register
Message-Id: <199608072021.QAA01980@bob.rtp.dg.com>
From: goudreau@dg-rtp.dg.com (Bob Goudreau)
Date: Wed, 7 Aug 1996 16:21:11 -0400
Resent-Date: Wed, 7 Aug 1996 16:21:11 -0400
Received: by znyx.com (5.65/1.35)
     id AA14393; Wed, 7 Aug 96 13:27:05 -0700
Received: from znyx.com by netcomsv.netcom.com with SMTP (8.6.12/SMI-4.1)
     id NAA21128; Wed, 7 Aug 1996 13:26:00 -0700
Received: from netcomsv.netcom.com (uumail1.netcom.com [163.179.3.50]) by ormail
.intel.com (8.7.4/8.7.3) with SMTP id NAA26533; Wed, 7 Aug 1996 13:58:46 -0700 (
PDT)
Resent-From: pci-sig-request@znyx.com
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.7.4/8.7.3) with ESMTP id NAA19681; Wed, 7 Aug 1996 13:58:45 -0700 (P
DT)
Return-Path: pci-sig-request@znyx.com

ðß