Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!news.seinf.abb.se!nooft.abb.no!Norway.EU.net!nntp.uio.no!news.cais.net!news.mathworks.com!uunet!inXS.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc
Subject: Re: Curious about *BSD History
Date: Tue, 25 Jun 1996 19:39:05 -0700
Organization: Me
Lines: 58
Message-ID: <31D0A2C9.72741EA8@lambert.org>
References: <4k1nue$lm8@orb.direct.ca> <4kl863$rno@news.rhrz.uni-bonn.de> <1996Apr12.210743.28292@wavehh.hanse.de> <317006C4.77C0450E@lambert.org> <4qkegg$9as@pier2.bayarea.net>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:22152 comp.unix.bsd.netbsd.misc:3850
Jason R. Thorpe wrote:
] Actually, it's more of a "bounce buffer-like" scheme that the
] Alpha needs. This is because, unlike the i386, the ISA's view
] of system memory can is radically different from the CPU's
] view of system memory.
]
] So, really, NetBSD won't be getting "bounce buffers", per se,
] but rather a "machine independent ISA DMA solution", which
] will have a bounce buffer effect for machines that require
] such a scheme.
Doesn't it really want a "machine independent target range
restricted DMA soloution"? The Amiga, for instance, does
not have ISA, but has the DMA targetting problem for "fast RAM".
] This is actually the symptom of a larger problem with MI bus code
] and device drivers. Most PCI drivers are written on the i386, and
] hence driver writers tend to use things like kvtop() or vtophys()
] to point bus-mastering cards (like the DEC Tulip, for example) at
] their memory space. NetBSD/alpha currently has an evil little
] hack to get around this problem, but real DMA mapping functions need
] to be designed and written; can't survive on little hacks forever.
Yes, the generic soloution is the best. The 21066 had the ISA
bridged off the PCI instead of the other way around (like in
most PC's), and so the problem was inverted. The real issue
is generalized DMA routines that say "this will work" to the
driver coder, and then a generalized subsystem that hooks to
that interface so the Amiga and PC ISA and similar systems with
problems (ie: EISA systems with HiNT chipsets, like the old NiCE
"EISA" motherboards) can share common management code.
] Other problems arise when dealing with cards like the Matrox
] frame-grabber, which wants a chunk of several physically
] contiguous pages. FreeBSD has a VM routine (contig_alloc()
] I think?) that deals with this. However, systems like the
] Alpha can do the scatter/gather in hardware, transparently
] to the card that wants the contiguous space (like DVMA on
] the Sun 4). Thus, a VM trick isn't needed. This sort of
] routine also needs to be implemented in bus DMA mapping
] routines.
That's a cheat based on the fact that the page management is
partially in software in the Alpha MMU. 8-). The same cheat
applies to the PPC.
I have to admit that I've been considering writing software
to make the MMU hardware pretend to be PC MMU hardware so I
can more easily track the FreeBSD VM changes on the PPC (I
known, I know, "evil incarnate").
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.