Maybe I can add some more details about the SCSI problem
on ELCs.  I haven't been able to get any of the NetBSD
kernels to boot on my ELC without replacing esp.c,
and I've tried 1.1, some of the recent snapshots,
and building -current myself.  This is what happens
with a kernel built from current sources about a week
ago (with esp.c,v 1.39 1996/02/29 23:33:48 pk)

.....
sbus0 at mainbus0 ioaddr 0xf8000000: clock = 20 MHz
dma0 at sbus0 slot 0 offset 0x400000: rev 1+
esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100A
[ESP_INIT(1)]<cmd:0x2><cmd:0x0><cmd0x3> 20 MHz, target 7
scsibus0 at esp0
[esp_scsi_cmd] [0x0,6]->0 [esp_poll]
[espintr]regs[intr=98,stat=80,step=00]
[esp_sched][espselect(t0,l0,cmd:0)]
<cmd:0x1><cmd:0x43>
[espintr]regs[intr=18,stat=86,step=01]
MESSAGE_OUT_PHASE [esp_msgout(priq:40,prevphase:101)]
dma0: start 5@0xf85ddaee,0
dma_setup: dmasize = 5
<cmd:0x80><cmd:0x90>
[espintr]regs[intr=10,stat=87,step=01]
dma0: intr: addr f85ddaf4 csr 96400210 <IEN,DMAON>
dma0: xfer (-65530) > req (5)
dmaintr: tcl=255, tcm=255, tch=0; trans=5, resid=65535
esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0

-------------------------------------------------------------
It seems to be saying that 6 bytes were transferred instead
of 5, and the transfer counter is now 0xFFFF, so TC is not set.
At this point, the bytes at 0xf85ddaee are: 01 03 01 3E 0F 00
so the message was supposed to be
SDTR with period 248 ns, offset 15,
which should be accepted by this disk.
But it isn't:
-------------------------------------------------------------

MESSAGE_IN_PHASE<cmd:0x1><cmd:0x0>
regs[intr=08,stat=87,step=01]
MESSAGE_IN_PHASE[esp_msgin(curmsglen:0)]<msgbyte:0x07>
gotmsg(7)esp0: our message rejected by target
<cmd:0x12>
.......

After this, it just gets stuck in a loop.
The more recent snapshot does essentially the same thing,
but with somewhat different error messages.

The only way I have been able to get NetBSD to boot is
by replacing esp.c and dma.c with Theo's versions from
ftp.openbsd.org.  His SDTR message is a little different
from the one shown above.  It seems to contain an additional
MSG_IDENTIFY byte before the 5 above, and it sets the offset to 0,
requesting async transfers.  But I tried changing the offset
to 15 and even using periods as fast as 180ns (as mentioned
in Sun's espreg.h), and all of the combinations I tried
worked ok with the ST51080N disk I've been using.  Other disks
sometimes reply with messages increasing the period and/or
reducing the offset, but they end up booting ok.

Also, Theo's version of esp_msgout() copies the message to
the fifo one byte at a time, which looks like the part of
the current esp.c that's commented out.  It looks like
somebody has been experimenting with this part of the code,
although it doesn't seem to have changed in  v 1.43.
Maybe it isn't getting the message to the disk correctly?

Charles Retter
<retter@arl.mil>