Subject: Re: MicroVAX I: in need of modern OS.
To: None <port-vax@netbsd.org>
From: John Wilson <wilson@dbit.dbit.com>
List: port-vax
Date: 02/06/1999 02:29:01
>From: Brian D Chase <bdc@world.std.com>
>Wait, I'm confused. I thought we got past this whole mapping thing when
>you explained that Q-bus address space == Physical address space on the
>MicroVAX I (hence no mapping registers required)? I don't care about the
>18bit Unibus :-) At least not until I find an 11/730 within hauling
>distance.
I think he meant all Q-bus VAXen *except* the MicroVAX I.
>I was just wanting to know in general how you locate DMA buffers in
>physical memory such that 1) the CPU knows where they are, 2) the device
>knows where they are, and 3) how virtual memory management and DMA on a
>physical address space peacefully coexist.
The usual problem (not on MV I) is that the I/O bus address space isn't as big
as the physical memory space, so the devices can't beam data to/from arbitrary
address w/o help from a mapper of some kind. DEC's been doing these for
ages (on PDP-10 and PDP-11 machines as well as VAXen), the idea is to fake
out the controllers. They generally still think they're on a PDP-11 (or MV
I), and all Q-bus addresses below 17760000 point to 4088 KB of real memory.
On mapped systems this is still sort of true, except instead of putting the
real memory directly on the Q-bus, you insert a map between the two so that
each page of what looks like real Q-bus memory, can in fact be any page of
real memory depending on what value has been stuffed into that map register
by the host CPU.
So, instead of giving the actual buffer address to the peripheral, you
allocate (either staticly or per-transfer) a chunk of Q-bus address space
which is big enough to cover the buffer, feed *its* Q-bus address to the
peripheral, and set the map registers for those pages to point at where the
*real* buffer is in physical memory. This can be a bit annoying because map
registers (and their corresponding chunks of Q-bus address space) become a
precious system resource and you could end up with controllers sitting idle
because they're waiting in line to get the map register(s) they need to do
their next transfer. But anyway, besides fixing the problem of accessing
big memory from the 4 MB Q22 address space, the map can also be used to do
crude page-oriented scatter/gather so it doesn't matter whether the user's
buffer is physically contiguous as long as the breaks come at page boundaries
(which is the most likely thing anyway).
On the MV I, Q-bus addresses really *are* main memory addresses so you don't
have to bother with allocating map registers and redirecting I/O through them,
the down side is that now all I/O buffers do have to be physically contiguous.
John Wilson
D Bit