Date: Wed, 30 Jul 1997 20:30:37 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Terry Lambert <terry@lambert.org> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, mo@uu.net, hackers@FreeBSD.ORG Subject: Re: SMBIOS/DMI etc Message-ID: <19970730203037.49081@mi.uni-koeln.de> In-Reply-To: <199707300015.RAA03604@phaeton.artisoft.com>; from Terry Lambert on Tue, Jul 29, 1997 at 05:15:14PM -0700 References: <199707290211.LAA09448@genesis.atrad.adelaide.edu.au> <199707300015.RAA03604@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 29, Terry Lambert <terry@lambert.org> wrote: > > > I have considered adding calls to the PCI BIOS as an > > > alternate mechanism to directly reading configuration > > > space registers. But I have no intention to make the > > > PCI code depend on PCI BIOS services. > > > > This is because...? > > If I had to guess, it's probably because BIOS calls are Intel-centric. Yes, this is one of the reasons. PCI introduced the concept of the configuration space, which requires another distinct address space other than memory and (optionally) I/O port address space to exist. Configuration space can be seen as "bus controller registers" provided as part of each PCI device. In some way the config space registers belong not to the device, but to a "virtual" "bus tree" device. Due to backwards compatibility constraints in PC motherboards, the PCI BIOS has additional knowledge, that is not available from any other source. This includes the traces between the PCI bus interrupt lines and the emulated ICUs in the chip-set, for example. But the PCI BIOS puts information about the Int to IRQ routing for each device that has been located into a config space register of that device, and you don't need to call the PCI BIOS, except if you are interested in where those traces end even though *no* device is directly connected. (Well, the SMP people are interested in exactly that information, in order to deal with some (old) format of the SMP table, but that is a different story :) The PCI BIOS is known to be buggy on lots of older mother-boards. And there still are quite some 486 boards, where calling the 32bit functions may not be a good idea, even though the real mode calls work just fine. (Nobody cared for the 32bit calls at that time, it seems, since they are not used by Win3.11 :) There are quite some broken chip-sets, which violate explicit and boldly printed requirements of the PCI specs, even in the latest machines. If you want to have fun, just run "probepci" on just about any Compaq and watch it go mad ... :) I once complained about this, and some Compaq engineer replied, that their systems worked fine with their BIOS and all O/S code they release, and that it is their decision, whether the system complies at the register level or at the BIOS level with the PCI spec. Well, that's definitely not true, but I don't think there is much I can do about it, except work around their bugs. (And that broke EISA support some time ago, until I added even more work-arounds, since they broke exactly the machanism that is proposed to distinguish a PCI chip-set from some EISA device.) I'm going to add some code to deal with their latest TriFlex to -current soon, since I just got access to a Deskpro 4000 for testing ... One thing that calling the PCI BIOS may be good for is that the device scan order is not defined, and some BIOS does it from low to high, the other from high to low slot numbers. Calling the PCI BIOS from the FreeBSD probe code is the only way to have FreeBSD probe the PCI bus in the same order as the BIOS init code does, and some people with multiple SCSI cards asked for that feature. (But I'd rather want to be able to wire devices to bus slots from the user config menu as an alternative with many more uses :) Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970730203037.49081>