On Mon, 15 Nov 2004, Blaz Antonic wrote:
> Can option board do DMA anywhere in Vax memory space ?

IIRC, addresses are passed through the adapter without being modified
when the scatter/gather map is off. Since the adapter sits in the system
between the CPU and S-Chip, it should be able to access anything the CPU
can access. However, the adapter tries to suck up a lot of memory when
a DMA read starts, so attempting to access CSRs is probably not a good
idea.

I'm pretty certain the adapter counts the block size signalled by the
adapter (this is done by holding the DMA request asserted for the
appropriate number of clocks after the grant has been issued), so I
don't think it will attempt to fetch more data than the option says it
wants. But I'm not absolutely certain of that.

> For example, if i
> have network card with buffers mapped to some virtual addresses that may
> or may not be contiguous physical addresses, can option perform DMA in
> and out of the virtual memory space transparenly or do i have to use TCA
> sgmap to point the option to the right physical addresses ? That's what
> i meant by 'transparent'.

AFAIK, you cannot do DMA to virtual addresses in general. The only
options I'm aware of that did it are the DR-780, it's cousin the BI
version (IIRC, the DMB32), and the third-pary VAXBI quad IEEE-488
adapter for which I wrote the firmware (a Z-80 looking things up in the
VAX page tables. Yum!). All DMA is to physical addresses.

The point of the scatter/gather map is to provide some sort of virtual
translation between the addresses used by a DMA device and the physical
addresses. If you want to DMA to some sort of virtual address, you'll
need to load scatter/gather map entries.

Since QBus devices are supported, there should be some latent support
for scatter/gather maps in the kernel. The TURBOchannel adapter uses the
same scatter/gather map layout (with the same number of map entries) as
a QBus.

A device that knows how to (and is willing to) look things up in the VAX
page table is certainly welcome to do so. However, I'm not aware of any
TURBOchannel devices capable of doing the deed. The TURBOchannel guys
tended to have a 4KB page orientation driven by the MIPS architecture; I
had a fight with the TURBOchannel to VMEbus adapter guys to get
them to include a 512-byte page mode on their scatter/gather maps.

> What restrictions are there regarding this up to 4 MB area ? Any
> alignment issues (1 or 2 KB boundary perhaps) ?

Byte offsets into a page are passed through the adapter unchanged; only
bits 9 through whatever are modified by the adapter.

In other words, it works in the same manner as a QBus or UNIBUS
scatter/gather map. I even chose the layout of the registers to match
those maps.

> If option can do DMA anywhere in Vaxstation's memory space without even
> realizing adapter is there that means i don't need adapter's sgmap
> capability at all - i just rip the corresponding drivers from Decstation
> port, substitute few function names with 'vsbus' equivalents and it
> shoudl Just Work(TM).

As long as your devices are willing to live within the VAX's 512-byte
page size.

> I'm no TC expert but i do seem to recall that transfer size is known
> upfront so i take adapter will wait for *at most* 2 KB of data ?

That's correct. The TC option signals the length of a transfer for a
read by how long it holds the request asserted after the grant has been
issued and the address taken. Writes work essentially the same way, but
the option is supplying data while it is signalling the block length.

> Hmm ... self-test/unjam routine wipes clean an area 128 KB in size for
> some reason. I assumed it was the FIFO, as there is nothing else that
> ought to be reset to default values of such a huge size (not a register
> window or anything).

The FIFO actually appears at a single address; you can load a chunk of
data into the FIFO using a single address. However, since the addressing
is sparsely decoded, the FIFO appears throughout a large chunk of the
address space.

The proper way to clear the FIFO is to read from the FIFO until the CSR
indicates it is empty.

On the other hand, the microcode resets the FIFO before it starts a
transaction, so clearing the FIFO should not be necessary.

> > The only time I talked directly to the DZ on the /90 I did not use
> > interrupts. I also accidentally erased the flash in my /90; be careful!
> > If you accidentally try to run a DZ on the /90 at the /60 CSR address,
> > you WILL bzap your flash!
>
> Older versions of NetBSD did just that :-) I have newest flash ROM (MOP
> and disk images), in case you need - and still can - update your 4000/90
> to get it working correctly again.

I don't mind the error message.

> I just thought of something else: if you've been dealing with model 60
> you're maybe familiar with SPXg/SPXgt graphics ?

Sorry. My mode of operation was to yank the graphics and use a serial
console. It's a little known fact that the 4000/60 is exactly the right
size to sit on top a VT-52. I got no sympathy from the console guys when
I complained that the 4000/60 kept putting my VT-52 into hold-screen
mode (the ESC[ issued in the terminal discovery sequence is used by the
VT-52 to enter hold-screen mode).
-- 
Roger Ivie
rivie@ridgenet.net
http://anachronda.webhop.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++
------END GEEK CODE BLOCK------