From owner-freebsd-hackers Fri Oct 13 16:06:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA16137 for hackers-outgoing; Fri, 13 Oct 1995 16:06:29 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA16132 for ; Fri, 13 Oct 1995 16:06:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA18445; Fri, 13 Oct 1995 16:01:06 -0700 From: Terry Lambert Message-Id: <199510132301.QAA18445@phaeton.artisoft.com> Subject: Re: IPX now available To: matt@lkg.dec.com (Matt Thomas) Date: Fri, 13 Oct 1995 16:01:06 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <199510131816.SAA24191@whydos.lkg.dec.com> from "Matt Thomas" at Oct 13, 95 06:16:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8132 Sender: owner-hackers@freebsd.org Precedence: bulk [ ... ] > Either via a smarter bootloader or a VM86 mode, calls into the BIOS > to get configuration information should be done as well. For instance, > getting the information out of the EISA CMOS should the DEPCA driver > since the DE422 config registers are write-only. Actually, the EISA configuration is accessable from protected mode. What is *not* accessable about EISA from protected mode is the amount of per slot CMOS (though thihas generally leveled out at 1k, older hardware is not required to have a specific amount). There is a nice book on "EISA system architecture" (shiny paperback, rag bond pages, all white; I can get ISBN information if necessary) that describes how to hueristically determine the amount so that BIOS calls are totally unnecessary. I've been thinking on EISA for some time, actually, since it seems to me that EISA configuration is the last bastion of "DOS required" for those boxes. > Also, the probe needs to be done once on a per bus-type basis; > a probe should never try to all the different bus types at once. Agreed. A pereference should be given to the local bus. If an ISA is bridged onto a PCI, it's block relocatable, but should be the first "PCI device" probed. I'd order it: ISA ISA bridged to PCI EISA PCI bridged to ISA MCA PCI > For PCI, I'm beginning in favor of having the driver call a pci_match > routine to find instances of itself instead of the currently "passive" > method. The passive method just doesn't lend itself to LKM. One other > reason I favor it is so that I could have a "generic" DC21x4X module > and then have various board/chip specific LKMs. The de driver is getting > fairly large and I'd like a method to trim out the unneeded code. Both of these are plusses with no real minuses that I can see. The idea of "controller/target" seems to fit well, with the "controller" being the "generic" module and the "target" being an implementation instance. If one view SCSI as a bus attach, the generic SCSI code can be loaded in the same fashion as a "controller" with each controller type as a "target" fo the bus attach. Then the bus can be treated seperately as "controller/target" (target/LUN) pairings. A lot of the disk stuff really wants to be ordered before the non-disk devices. I think classification of devices as "boot critical" or not is an issue that begs the VM86() question. If there is VM86() support (the equivalent of Sun/PPC OpenFirmware for PC class machines), then it's a no-brainer. You make them loadable. Otherwise, you must decide what you will be booting to decide what you want to load. For a BIOS-based boot, there's the possibility of using BIOS calls to load the device in such a way that when you jump to the kernel, the devices are used as if they had been loaded. Using a VM86()/OpenFirmware based driver almost cries out for the ability to tag segments as "initializtion,discardable" to recover the memory into the kernel memory map after boot. > > On the pci-sig mailing list, it seems many BIOS makers are putting in > a Micro$oft configuration mode which only configurations "boot" devices > and then expects the PnP O/S to call into the PCI BIOS to finish This make sense, but seems to lock out Apple, IBM, and Motorolla. Either there will need to be processor as well as VM86() mode emulation, or there will need to be some serious driver writing if this becomes common. The "OpenFirmware" mechanism for this is supposedly a FORTH program in the ROMs so that it doesn't matter what processor is doing the "BIOS" calls. > Only if said port address was dynamically assigned to the device, > if the port (or memory) address is fixed then that address should > not be released. An important point. Device with static address mappings must be considered to always be present if they are installed hardware. Removable hardware (PCMCIA), however, could in fact change this mapping by switching between two devices with fixed mapping addresses which overlap, but which will never be present at the same time. I think it's important to distinguish between devices that are physically and virtually present when calculating address/io/IRQ/DRQ space collisions. > Note that if there was a conflict, the configuration manager should > have never bothered to call the attach routine. With the caveat of virtually present but physically missing devices (above). > > A destructive probe should be limited to a "add hardware mode". Just like > > Windows 95: a user triggered event or an install triggered event that does > > not repeat each boot. > > In my mind, if a user configures a device (such the probe and/or meta_attach > is bypassed) and then the attach routine is called, the attach is allowed > to do the equivalent of a destructive probe since it unconditionally owns > those resources. I think that relocatable devices will not be destructively probed because of card services doing mapping notification. On the outside chance, however, that this is not the case, virtualy present devices could become quite a problem if you make the above assumption. > The database created by the configuration manager and filled in by the probes > and refined by the meta_attaches must be non-volatile and independent of the > kernel. Note that this means that either the resource information in the > config file disappears or config will need to able to write out a resource > database file. This is the function performed by the registry in Win95, and accessed via kernel level file I/O. I think it is imperitive to consider at least a multistage (by bus type) two pass (by device classifiaction: boot device, not boot device) probe sequence. This may require the ability to dynamically relocate a relocatable device (like a PCI SCSI controller) by stopping all outstanding I/O, detaching it at its present location, and reattaching it at the new location. How you would deal with this for non-disk boot devices becomes a real issue, but I think it is sufficiently limited in scope (ie: what are you really allowed to boot off of anyway?) that it's generally soluable. > The boot loader will need to able to read this configuration database and > put it into memory along side the kernel image. Userconfig could then > either stay in the kernel or become a separate entity. Actually, it might > even make sense for userconfig to become the second-stage loader since it > will have the proper information to do it. The use of firmware-based fallback drivers would be better. Otherwise you will end up with a chicken-and-egg problem to resolve. The firmware is guaranteed to be present, since it is the code that loads the second stage boot image itself. The ability to do kernel level file I/O could leverage the two pass model (described above) with the firmware to get you to that point. This alleviates the need to make the boot loader so smart that it is inconvenient to write in the first place. The second stage boot will probably need to leave kernel accessable routines around to allow the kernel to do firmware based I/O. This would have the advantage of divocing the device and kernel architectures from one another, if the mechanism was sufficiently general (ie: the kernel is passed the address of a function vector list at startup to allow us to abstract the firmware interface from its implementation). This is how the Motorolla "bug" firmware worked on 68K machines, and how it currently works on their non-OpenFirmware PPC machines. So the firmware boots the boot code, which is either a selector or a second stage boot locator or the second stage boot code itself, and the second stage boot contains firmware interface vectors to load the kernel and allow the vectors to be accessed by the kernel. The kernel itself is unaware of the boot mechanism used to load it, so the only thing that changes from a PPC Ultra 603/604 to an IBM RS/6000 43P to an Apple CHRP box is the second stage boot. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.