Date: Wed, 10 Jan 1996 15:17:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: neil@synthcom.com (Neil Bradley) Cc: terry@lambert.org, root@synthcom.com, hasty@rah.star-gate.com, freebsd-hackers@FreeBSD.org Subject: Re: PnP problem...y Message-ID: <199601102217.PAA15618@phaeton.artisoft.com> In-Reply-To: <Pine.BSD.3.91.960110133748.3072B-100000@beacon.synthcom.com> from "Neil Bradley" at Jan 10, 96 01:58:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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
>
> You mean to say that the GUS uses two interrupts for one ISA card? Now
> that is stupid.
Yep.
> > 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.
>
> Unfortunately we don't live in a PC world where Unix is king. Microsoft
> is. And there are a lot of vendors who haven't the foggiest idea of a
> clue as to how to properly coexist with other cards. Doing what you said
> above would break all DOS/Windoze drivers/apps very quickly. Of course,
> we live in the great world of FreeBSD where this isn't a problem for us
> programmers. We could remap our standard COM ports wherever we wanted in
> I/O space and to whatever interrupt we decide to use and our drivers are
> built to handle it. Or would be if we could remap those darned ISA
> devices out into oblivion.
I don't know if your statement above is really true or not. You'd have
to have a bridge chip driver to do the job; without it, you'd have the
BIOS default setup, which would mean the drivers for MS stuff would
just work as they do now, which is to say "if it hangs for too long,
reset the machine (do *not* type ctrl-alt-del) and select the 'resume
setup' option".
So I think you could maintain backward compatability for backward OS's (8-))
without too much trouble.
Turns out you'd have to do this anyway, since you have to be loaded
by BIOS POST load bootstrap on a BIOS mapped default disk anyway before
you can unmap and relocate the disk out from under yourself.
> > 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.
>
> This would be quite cool. What we would ideally like to see is each ISA
> slot treated as a completely separate slot from the next, I.E. Not being
> electronically connected. The logic in the bridge chip would be able to
> convert edge triggered interrupts into level, and do the mapping like you
> mention above.
I think that "logically seperate" is what an ISA PnP motherboard does
for you. You don't get to remap, but then you might not care to anyway.
> The Intel INCA chip takes care of a lot of this. It had the ability to
> convert edge->level triggered interrupts. We had a problem with on board
> devices screwing up the IRQ lines on the ISA bus (parallel port to be
> exact) because the output drive was set to totem pole. Once we tri-stated
> it from within INCA, things were fine.
Where do I buy one of these boards? 8-).
> I'd do this:
>
> 1) Disable all PNP devices
> 2) Probe for ISA
> 3) Obtain EISA information - report conflicts with ISA devices
> 4) Initialize EISA devices
> 5) Init PnP devices
and PCMCIA bridged devices
> 6) Init PCI devices
> 7) Boot system ;-)
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?199601102217.PAA15618>