I sent this message to you sun-managers on April 30, 1992:
> A few months ago, I upgraded my Sun 3/460 to a 670MP.
>
> I have an unusual piece of hardware: a Micro Technology Unlimited DS-16
> audio digitizer. This thing used to work with my 3/460 via an Ikon
> parallel interface VME board. I didn't have much hope of it working
> with the 670; the driver (for which I have source) dates back to the
> early days of SunOS 4.0 but worked okay with 4.1.
>
> I couldn't resist installing the thing in the 670 just to see what
> would happen. The driver compiled okay with very few changes. From a
> fellow DS-16 victim/user I had obtained a driver patch which fixes a
> SPARC alignment problem.
>
> I was all set for massive, terrible panics and had pulled the pin on
> the fire extinguisher and dialed "91". 8-) I tried playing back an
> old sound file and got only noise. Then I tried recording some audio
> and playing it back. It worked! I dug out some old known-good sound
> files, but they produced only noise. I'm not sure what made me think
> of it, but I tried using dd to swap the bytes in one of the old sound
> files. It worked! Apparently, the system now swaps bytes when
> recording and playing back.
>
> The Ikon board does DVMA using the "standard" Sun mechanism. At least,
> I think it does. I don't expect Sun-Managers to fix a problem with
> driver source code when I don't understand much of it myself. My
> question is: Did Sun change the way that data transfers using the VME
> bus occur such that byte swapping would occur with an old driver?
Most everyone who responded told me that the bus architecture has not
changed in such a way as to cause byte swapping.
Hal Stern sent me a copy of his "SPARCsystem 600MP Porting Guide." This
has a number of invaluable tips for those of us porting old device
drivers to the 600MP architecture. Hal did not want me to post the
whole thing (12 pages, PostScript) to the net, but I've just got to
broadcast to the world the part of it that saved the day:
Write buffers sit between the MBus and the SBus/VME bus interfaces.
The SunOS kernel flushes these buffers before calling a device driver
interrupt routine, and any attempt to read from a cached address will
cause the write buffer to be flushed as well. Consider this simple
sequence of events:
Write to device
Delay 100 usec
Write to device
Relative time-ordering of write operations is not preserved with the
write buffers: the execution order is maintained, but the write
operations may be performed back-to-back rather than with a delay
between them. The actual delay may be less than 100 usec if no cache
flushes occur within the delay window. If your driver relies on
certain minimum inter-write time delays, you can perform a read-back
from the device to force the write buffers to be flushed.
Of course, the driver I was using (and most that I've seen) has this
very construction in it. I added some dummy reads from the device csr,
and the problem was mostly fixed. I added a few more, and the problem
was solved. In at least one case, the additional reads probably were
necessary to fix a write recovery time problem rather than to cause the
write to be flushed. I asked Hal if it was necessary to do a dummy
read before an mbrelse() in the following circumstance; he says no,
mbrelse() will flush it out:
mbsetup()
...
Write to device (command to do a single-word DMA cycle)
mbrelse()
Why would flushing the write buffer solve a byte order problem? Fellow
DS-16 user Vaughan Pratt provided a possible clue. The data transfer
to/from the DS-16 takes place across an 8-bit wide parallel data path.
An extra (or missing) byte across the interface would cause the DS-16
to lose word sync. I think that the buffer flush bug caused the DS-16
to lose the first byte of a transfer.
The DS-16 driver does some really loony things. Hal Stern provided me
with a number of suggestions as to how to fix them. Among those I
hadn't already thought of was the idea of using the iopbmap for small
DMA transfers like the previous example. This saves the
mbsetup()/mbrelse() delays. I'd like to completely fix this driver,
but I don't really have the time. (Really!) If you want to join a
mailing list devoted to the DS-16, send mail to pratt@cs.stanford.edu.
Here is the list of good people who responded to my panic attack:
stern@sunne.east.sun.com (Hal Stern - NE Area Systems Engineer)
Vaughan Pratt <pratt@cs.stanford.edu>
shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
kalli!kevin@fourx.aus.sun.com (Kevin Sheehan {Consulting Poster Child})
Thanks, one and all.
-- J. Porter Clark jpc@avdms8.msfc.nasa.gov or jpc@gaia.msfc.nasa.gov NASA/MSFC/EB33 (205)544-3661 Huntsville, AL 35812 FAX: (205)544-9582
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:42 CDT