wyatt@cfa.UUCP (Bill Wyatt) (10/18/85)
I have recently been trying to write an ULTRIX 1.1 driver on a microVax II
for the AED {512,767,1024} parallel/DMA Q22-bus board. My problems and findings
may help others avoid a few arrows.
The people at AED have been very helpful and responsive in solving (or at
least illuminating) these probelms, by the way.
As background, we already have an AED 767 on our Ultrix 1.1 11/750, with a
4.2 bsd Unibus driver (obtained through MIT and originally from Ohio
State), running an AED-supplied Unibus interface. Everything runs fine, and
I anticipated no problems porting to the II, since the I/O space mapping is
functionally identical to a Unibus.
Problem 1:
The board (standard dual Q22 bus) does not auto-configure UNLESS the AED
terminal is powered on before reboot! It was designed that way! When the
terminal is off, the interface board is *gone*, and does not respond to
address probes. Thus, the booting Unix kernal will not even call the device
driver probe routine.
Apparently the terminal has most of the important logic in it, and at power
up time, some of the chips will be in an indeterminate state. There is some
chance (the AED person I talked to did not know how large) that if the
interface card were already active, the terminal would immediately request
a DMA write of 64k words *into* the host.
I agree the above is dangerous, but the solution is to fix the power-up
state of the terminal. The people at AED only know VMS, and since it is
possible under VMS to load a device driver after booting, they though this
was just fine. The guy I spoke to was very surprised to hear that a Unix
system would require rebooting. The kludge fix is to ground pin 9 of the
parallel connector, so that the interface board thinks the terminal is
always on. This might, of course, crash your system when the terminal is
susequently turned on.
Our Unibus interface does not do this, by the way, but AED is now modifying
all their Unibus boards to have the same behaviour as the Qbus boards!
Problem 2:
I couldn't seem to make use of the BUSY status bit to tell when the
terminal was ready to accept another command (even without trying DMA).
Well, it turns out there was a design flaw in the early Q22 bus boards such
that this signal was returned correctly only when the length of the cable
from interface to terminal was *zero*. Someone apparently forgot about
propagation delays! I am about to return my boards to AED for the (free)
fix.
Summary:
AED, I repeat, has been helpful and responsive to my problems. However, I
can't help feeling that I should not have had these problems in the first
place, and that there's a lot of flakiness in the design of these boards,
especially vis-a-vis problem 1, above, where the board violates both VMS
and Ultrix auto-configuration rules.
Bill Wyatt
{ihnp4,genrad,allegra,harvard}!wjh12!cfa!wyatt
--
Bill UUCP: {harvard,genrad,allegra,ihnp4}!wjh12!cfa!wyatt
ARPA: wyatt%cfa.UUCP@harvard.ARPA