Anders Magnusson wrote:
> 
> > A very good point - possibly the major device number is 
> wrong?  Looking
> > at a 1.3.2 release copy of MAKEDEV I see
> > 
> I haven't changed anything around the dhu driver ever; because I don't
> have the hardware to test it that would be foolish of me :-) If it has
> broke down it must be because of a side-effect from something totally
> unrelated... :-/

It is _not_ broken, it works just fine. At least I have 16 lines working
perfectly with VT320 terminals @9600 baud, 8N1 on my uVAXII running
1.3E. I have not tried running pppd on them.


Here's an attempt at a sort-of-a-howto:

Determine the correct CSR addresses of the cards for your configuration.
I did this on a machine running VMS, but Tom Ivar Helbekkmo (of this
list) has written a utility for doing the same on Unix. Check the list
archives. This example is based on the actual configuration of my
uVAXII:


VMS$ 
VMS$ mc sysgen
SYSGEN>  CONFIG       <--- Enter config mode of SYSGEN
DEVICE> uda,2         <--- I have two hard disk controllers
DEVICE> tu81          <--- And a TQK50
DEVICE> qna           <--- Ethernet (DEQNA in my case)
DEVICE> dhv11,2       <--- Two serial line controllers
DEVICE>  Exit         <--- Press CTRL/Z to exit
Device: UDA    Name: PUA  CSR: 772150   Vector: 154   Support: yes 
Device: TU81   Name: PTA  CSR: 774500   Vector: 260   Support: yes 
Device: QNA    Name: XQA  CSR: 774440   Vector: 120   Support: yes 
Device: UDA    Name: PUB  CSR: 760334*  Vector: 300*  Support: yes 
Device: DHV11  Name: TXA  CSR: 760500*  Vector: 310*  Support: yes 
Device: DHV11  Name: TXB  CSR: 760520*  Vector: 320*  Support: yes 
SYSGEN>  


Next step is to set the address(es) on the card(s) using the dip
switches. This is not as difficult as it may seem at first sight, even
without the docs. The three first and the last digits of the CSR and the
last digit of the Vector are given, so you may not find switches for
them. You could find a pack of switches looking something like this:

 0 0 0  0 0 0  0 0 0  0 0 0
 | * |  * | *  * | |  * | *
 * | *  | * |  | * *  | * |
 1 1 1  1 1 1  1 1 1  1 1 1

where the asterisk (*) denotes open (0) or closed (1). In other words,
read from left to right, the switches above are set to 5 2 3 2, giving a
CSR of (760)52(0), and a Vector of 32(0). Note, the dip switches for CSR
and Vector may be on the same pack or the CSR and the first digit of the
Vector may be on one pack with the last digit of the Vector on another
pack. To make matters even more confusing there may be some dip switches
"left over" (i.e. unused) on the second pack. Or a single digit may have
its dip switches spread across two packs. How this is laid out depends
on the model of the board you have. A rule of thumb that always works
for me is to determine which bits are significant and then look for a
pattern on the dips on the board.

After physically installing the card(s) in the machine you need to build
a kernel with support for the serial controller(s) at the configured
address(es). Still using the example from my uVAXII you would need to
add the following to the kernel config file:


# Terminal lines
dhu0            at uba? csr 0160500     # DHU-11
dhu1            at uba? csr 0160520     # DHU-11


When this kernel boots on my machine, it probes like this:


NetBSD 1.3E (VAXINE) #0: Tue May 26 18:07:18 CEST 1998
    root@doublesix.bitcon.no:/usr/src/sys/arch/vax/compile/VAXINE

MicroVAX II
realmem = 9427968
avail mem = 6435840
Using 460 buffers containing 471040 bytes of memory.
backplane0 (root)
cpu0 at backplane0: KA630
uba0 at backplane0: Q22
mtc0 at uba0 csr 174500 vec 774 ipl 17
mscpbus0 at mtc0: version 4 model 3
mscpbus0: DMA burst size set to 4
uda0 at uba0 csr 172150 vec 770 ipl 17
mscpbus1 at uda0: version 2 model 3
mscpbus1: DMA burst size set to 4
uda1 at uba0 csr 160334 vec 764 ipl 17
mscpbus2 at uda1: version 9 model 7
mscpbus2: DMA burst size set to 4
ra0 at mscpbus2 drive 0: RA81
qe0 at uba0 csr 174440 vec 760 ipl 17
qe0: delqa, hardware address 08:00:2b:09:6f:c7
dhu0 at uba0 csr 160500 vec 310 ipl 17
dhu0: rom(1) version 2 rom(0) version 2
dhu1 at uba0 csr 160520 vec 320 ipl 17
dhu1: rom(1) version 2 rom(0) version 2
boot device: ra0
root on ra0a dumps on ra0b
ra0: size 2063970 sectors
root file system type: ffs


The standard NetBSD/vax distribution only comes with special device
files for the first dhu controller, so you need to make device files for
the second, if installed:


vaxine:~# cd /dev
vaxine:/dev# ./MAKEDEV dhu1


This creates the special device files ttyT0 -> ttyTf.

My cards have 8 serial ports each. In VMS they were called TXA0 -> TXA7
and TXB0 -> TXB7. In NetBSD/vax they're know as /dev/ttyS0 -> /dev/ttyS7
and /dev/ttyT0 -> /dev/ttyT7. Next step is to add them to /dev/ttys if
you want gettys on all of them:


# dhu0, TXA0-TXA7
ttyS0   "/usr/libexec/getty std.9600"   unknown on secure
ttyS1   "/usr/libexec/getty std.9600"   unknown on secure
ttyS2   "/usr/libexec/getty std.9600"   unknown on secure
ttyS3   "/usr/libexec/getty std.9600"   unknown on secure
ttyS4   "/usr/libexec/getty std.9600"   unknown on secure
ttyS5   "/usr/libexec/getty std.9600"   unknown on secure
ttyS6   "/usr/libexec/getty std.9600"   unknown on secure
ttyS7   "/usr/libexec/getty std.9600"   unknown on secure

# dhu1, TXB0-TXB7
ttyT0   "/usr/libexec/getty std.9600"   unknown on secure
ttyT1   "/usr/libexec/getty std.9600"   unknown on secure
ttyT2   "/usr/libexec/getty std.9600"   unknown on secure
ttyT3   "/usr/libexec/getty std.9600"   unknown on secure
ttyT4   "/usr/libexec/getty std.9600"   unknown on secure
ttyT5   "/usr/libexec/getty std.9600"   unknown on secure
ttyT6   "/usr/libexec/getty std.9600"   unknown on secure
ttyT7   "/usr/libexec/getty std.9600"   unknown on secure


Remove "secure" if you don't want to enable root login on these terminal
lines.

Connect the terminals, send a SIGHUP to init and away you go. To connect
the VT320 terminals I used standard "DECconnect Office Cable" MMJ cables
and H8571-A MMJ to DB25-female adapters.

Hardware note: A friend of mine who used to work for DEC Field Circus
once told me that on the Qbus serial mux' only the first one or two
ports on each card have (partial) modem control. The rest don't have any
modem control even though the pins are physically present. YMMV.

Please send any corrections/additions to me and I'll add this to the
FAQ.

Gunnar

--
Gunnar Helliesen   | Bergen IT Consult AS  | NetBSD/VAX on a uVAX II
Systems Consultant | Bergen, Norway        | '86 Jaguar Sovereign 4.2
gunnar@bitcon.no   | http://www.bitcon.no/ | '73 Mercedes 280 (240D)