Date: Sat, 14 Aug 1999 02:12:38 +0200 From: Stefan Esser <se@zpr.uni-koeln.de> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-hackers@FreeBSD.ORG, Stefan Esser <se@freebsd.org> Subject: Re: Configuration mechanism of PCI bus Message-ID: <19990814021238.A662@dialup124.zpr.uni-koeln.de> In-Reply-To: <Pine.GSO.3.96.990809214913.20038A-100000@sol.cs.binghamton.edu>; from Zhihui Zhang on Mon, Aug 09, 1999 at 10:08:16PM -0400 References: <Pine.GSO.3.96.990809214913.20038A-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1999-08-09 22:08 -0400, Zhihui Zhang <zzhang@cs.binghamton.edu> wrote:
>
> Even with "PCI System Architecture, 4th edition" at hand, I still have
> some problems understanding the code in isa/pcibus.c. Please point out
> any misunderstanding I may have in the following:
It has been some time since I write that code, but I'll try to remember
why it became the way you found it ... ;-)
> (1) At first, you can not modify the address port at 0xcf8 without a FULL
> 32-bit write. The routine pci_cfgopen() seems to use this fact.
Yes.
> (2) The constant CONF1_ENABLE_MSK includes 4 higher bus number bits, only
> 4 bits can be used as bus number, so we can have at most 16 PCI buses.
This is partially true. The code assumes (and I have yet to meet a PCI
BIOS that violates that assumption), that the address register will not
have any of the bits masked by 0x7ff00000 set. This is generally true,
since the **last** prior access to PCI config space by the BIOS will
have been to a PCI bridge (i.e. to a bus number much lower than the
highest PCI bus number in the system).
You are correct: If the previous config cycle was to a bus higher than 15,
then this heuristic will assume that there is no configuration mechanism 1
address register. I had to add that heuristic in order to prevent the PCI
porbe from crahsing EISA only systems.
> (3) The variable "mode1res" seems to refer to any residual left by BIOS in
> the address port. If it is non-zero, we will try to find a device using
> configuration mechanism 1.
Yes. Writing 0xff000000 should result in 0x80000000 being read back.
Only the MSB is writable, the remaining high order bits are wired to 0.
This is another test that is most likely to fail for non-PCI systems.
> (3) The magic constant 0xf870ff excludes many devices. How it is chosen?
> I guess those excluded devices are not important or supported by FreeBSD.
> It seems to me that if pci_cfgcheck() finds at least one device, then the
> configuration mechanism is regarded as correctly detected.
Yes. After testing for config mechanism 1 or 2, another last test is done
to make sure, there is at least one PCI device on the bus. The mask is
chosen in such a way, that there is at least one device on PCI bus 0, which
satisfies the following conditions:
class in 0..7
subclass in 0..15 or equal 0x80 (in fact 0x80 .. 0x8f are accepted)
prog if equal 0
and finally
class not equal 0 or subclass not equal 0
This will for example be true for a PCI VGA card (present in just about
every system), which has class=0 and subclass=1 or class=3 and subclass
in {0,1,0x80}. But in any PCI 2.0 or later system, the chip-set will also
be present on PCI bus 0 and will cause a match with class=6 and subclass
in 0 .. 7 (or 0x80). Any disk or network controller should also suffice
to make this test succeed.
The only case that will have this test fail is an ancient (pre PCI-2.0)
system with no PCI VGA card.
Regards, STefan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990814021238.A662>