Date: Wed, 10 Jan 1996 12:42:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: root@synthcom.com (Neil Bradley) Cc: terry@lambert.org, hasty@rah.star-gate.com, freebsd-hackers@FreeBSD.org Subject: Re: PnP problem... Message-ID: <199601101942.MAA15208@phaeton.artisoft.com> In-Reply-To: <Pine.BSD.3.91.960109195925.13432A-100000@synthcom.com> from "Neil Bradley" at Jan 9, 96 08:11:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 9 Jan 1996, Terry Lambert wrote: > > ISA Interrupts are not shareable - they're edge triggered. Except on multiport serial boards, which have additional interrupt decode hardware with latches that can be interrogated to determine who has interupt conditions pending. > > It makese sense that you would have one interrupt per card so you don't > > run out between card slots and onboard devices... it's stupid that the > > GUS doesn't have an interupt multiplex on board. You'll have to live > > with it until you buy a pure PCI system instead of a PCI bridged off > > of ISA. I recommend the Apple and Motorolla chipsets. 8-). > > Too bad no one makes extensive lines of boards for PCI Apples. ;-) Naw. Too bad no one uses the Motorolla and Apple PCI bus controller chips. We're not talking about hardware from Apple; everyone knows that all interesting Apple hardware is undocumented and all documented Apple hardware is uninteresting. > PCI Isn't "bridged off" of ISA. It's the other way around. If that were > the case, then PCI couldn't run faster than ISA, now could it. ;-) Besides, > this isn't a problem with Intel/Mortorola, it's a problem with the ISA > bus, and if you recall correctly was implemented by IBM - not Intel. The problem is the system bus. This is the design difference between the DEC Alpha 21064 and the Intel P5 bus interface logic. The Intel bridge chips give the ISA priority. In reality, you want to map the ISA bus as a PCI device so you can relocate the "unrelocatable" cards on the ISA bus as far as the processors view of their resource apetures is concerned, and demux ISA interrupts onto PCI interrupts. If what you said were true, on an ISA bus on a PCI machine, each slot would be permitted to consume the full gamut of available ISA interrupts and geneare a single (potentially shared between slots) interrupt per ISA slot. Then the PCI/ISA bridge logic would let me determine which of the PCI intterrupts was triggered by what mapping, and then ask which ISA interrupts were pending service in the ISA mapped slot as a PCI device. Finally, I could have as many ISA S3 based boards as I wanted, all of them thinking they were at d8000 with port 2e8, and map them to a different location in real space using the PCI. Effectively, then, all my hardware would be PnP relocatable, even if it wasn't. Then I would execute a single probe sequence once per PCI and once per device mapped ISA slot, identify all hardware I could and disable (and report) all hardware I couldn't, and as long as boot critical devices existed, I'd be up and running with zero collisions caused by unidentifiable and undisableable crap ISA devices. > Back when I designed BIOSes for P5 motherboards, we'd initialize ISA > devices first. We'd start by shutting off all on-board capabilities in > case someone plugged in an off-board IDE, Serial, Video, etc... card. > After it did that, we'd take the existing user's setup and set up > on-board devices. Then EISA. Then, from the pool of I/O, memory, and > interrupts, we'd allocate space for PCI devices. PCI Devices always went > to the end of the heap, because, by PCI's definition, it was a > requirement that they not be fixed in BIOS. Sounds like you are the guy for the job. 8-). I'd put PCI at the end of the heap from a software perspective because they are the most relocatable. I'd prefer to ignore motherboards that weren't totally PnP, either by slot by intent, or by PCI bridge by mapping order. Obviously, that's not very realistic. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601101942.MAA15208>