Subject: Re: 1.1 386 Hardware
To: John Dyson <dyson@freefall.freebsd.org>
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
List: current-users
Date: 11/08/1995 13:01:33
> > be done. IMHO. It only has to be done once. Yes, I know each driver needs
> > its own code - which has been made available for at least the AHA1542
> > series.
> >
> The method used in FreeBSD (and IS relatively machine independent) only
> requires a few 'C' statements in each driver.  The current code calls
> a '386 specific subroutine (which when the motivation arises -- will
> be cleaned up and placed in a machine independent portion of the tree.)

Unfortunately, this IS NOT enough.

the ISA drivers that do DMA do so by calling vtophys() to find out
what addresses things are at, and assume that ISA bus pysical
addresses are the SAME as system physical addresses.

This just doesn't work on all systems.


For instance, on many alpha systems, ISA/PCI bus memory space looks like:

	0-8M	ISA special stuff (e.g. VGA)
	8M-16M	scatter-gather-mapped windows into main memory
		(effectively virtual DMA).
	16M-1G	NOTHING
	1G-2G	Main memory
	2G-4G	PCI devices, etc.

the main memory that appears at 1G-2G is actually system bus physical
addresses 0-1G...  vtophys() just won't cut it.

Because there's _no RAM at all_ in the 0-16M range, you need
cpu-specific "map DMA" and "unmap DMA" routines for _all_ ISA DMA
accesses...

Similarly, "inb()" and "outb()" aren't sufficient in ISA bus drivers,
for the Alpha, as well...  not only can there be multiple "isa-like"
busses in a single machine on the alpha, there can even be multiple
_primary_ PCI busses in some...)


I think that the ISA/EISA/PCI bus interfaces -- and maybe even "most
bus interfaces" -- need to be largely rethought.



chris