From owner-freebsd-hackers Mon Aug 16 2: 0:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dialup124.zpr.uni-koeln.de (1-212.K.dial.o-tel-o.net [212.144.1.212]) by hub.freebsd.org (Postfix) with ESMTP id 6A54214E3D; Mon, 16 Aug 1999 02:00:10 -0700 (PDT) (envelope-from se@zpr.uni-koeln.de) Received: by dialup124.zpr.uni-koeln.de (Postfix, from userid 200) id 598FACDF; Sat, 14 Aug 1999 02:12:38 +0200 (CEST) Date: Sat, 14 Aug 1999 02:12:38 +0200 From: Stefan Esser To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG, Stefan Esser Subject: Re: Configuration mechanism of PCI bus Message-ID: <19990814021238.A662@dialup124.zpr.uni-koeln.de> Reply-To: se@freebsd.org Mail-Followup-To: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Zhihui Zhang on Mon, Aug 09, 1999 at 10:08:16PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-08-09 22:08 -0400, Zhihui Zhang 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