Greetings,

I succeeded in getting NetBSD/vax-1.2G installed on a VAXstation 3100
(not sure what model number, on the back it lists the model as
"VS42A-AA" and after a cold boot the machine identifies itself as
"KA42-A V1.2").  I wanted to share a few of my experiences for the
benefit of the FAQ maintainers and developers.

My first attempt was to boot from a SCSI TK50 drive.  I dd'd the two
images onto a tape using an Ultrix 4.1 box that was handy at the time.
I managed to boot to a ":" prompt and then thrashed around a bit, but
wasn't able to load edlabel, copy, or a kernel.  A few things seemed
to want to work ("st(0,0)edlabel" and "st(0,1)netbsd"), but always
ended up complaining about "bad adaptor number".  The README's
seemed to be a bit out of date, and I wasn't really sure what I was
supposed to be doing, so eventually I gave up on this and decided to
try netbooting.

So I grabbed the latest stuff from ftp.luth.se:/pub/NetBSD/vaxport/
and Brian's excellent HOWTO.  I then went about configuring my
NetBSD/i386 machine as a boot server.  Most of this was trivial for me
because this machine was already serving another NetBSD/i386 machine.

The tricky part was getting the mopd under NetBSD/i386 to actually
respond to the VAX when it booted.  I had installed a MOPBOOT.SYS in
/tftpboot/mop as indicated in the HOWTO.  After trying to boot a few
times with mopd running in debug mode, I randomly looked in the
/var/log/messages file on the server, and saw messages like this:

Aug 12 21:22:49 tardis mopd[586]: 8:0:2b:f:3a:30 (1) Do you have 08002b0f3a30? (No)

A quick review of the mopd(8) man page turned up no mention of
MOPBOOT.SYS, but rather indicated that the boot file should be the
enet address followed by ".SYS".  So either my VAX behaves differently
from some others in that it never requests "MOPBOOT.SYS" or the HOWTO
might just be out of date (It didn't seem to mention mopd running
under NetBSD at all!)

After creating a symlimk MOPBOOT.SYS -> 08002b0f3a30.SYS, the system
came up multiuser, on the first try!

The first thing I did was to set the clock from my time server:
"timed -F zippy".  This did set the clock, but the machine seemed to
hang.  So I halted it and rebooted.  I set timed running again...no
crash this time, everything seemed just peachy.

So...on to the RZ26 SCSI disk.  I stole a disktab entry from an
Alpha-OSF/1 box and set about trying to label the disk:

vivax# disklabel -w -r sd0 rz26
sd0: no disk label
DMA incomplete: ntrans=8193/8192, lock=98
si_dma_stop: timeout?
[ repeats about 6 times ]
write: Input/output error

Looking back in the port-vax archives, I saw someone else who had a
similar problem.  Bertram responded saying essentially that the ncr
driver was known to be somewhat flakey, and that some timing
parameters he had fudged might not be quite right for any system
except his.  He also said that in the "ntrans=x,y" the x is the number
of bytes actually transferred, and y is the number of bytes requested
to transfer.

My problem seemed to be somewhat different from the original posting
in that in the original problem x < y, whereas for me x > y.  It
seemed odd to me that *more* data was transferred than was requested.
So I started fiddling around with /sys/arch/vax/vsa/ncr.c.  First I
tried thwacking the delay(3*xlen/4), making the delay both longer and
shorter.  I also tried turning on POLL_MODE.  Then I tried cutting the
MAX_DMA_LEN value in half, guessing that the DMA system on the 3100
might not be exactly the same as the VS2000.  None of these had any
effect whatsoever.

Time for drastic measures.  Digging around a bit in the code turned up
the following chunk:

/*
 * Transfers smaller than this are done using PIO
 * (on assumption they're not worth DMA overhead)
 */
#define MIN_DMA_LEN 128

Well, if DMA is the problem, and this gives us a way to circumvent
DMA, how about forcing the system to *always* use PIO:

#define MIN_DMA_LEN 128 * 8192 /* XXX XXX XXX */

Success!  I was able to label both drives and install filesystems.
It is VERY VERY VERY SLOW as you might imagine, but it seems to
actually work.

So, I happily went about labeling the drive, making filesystems,
installing files over the network, and finally installed some
bootblocks.

I then tried booting from the drive, and got a warning that device
type 42 was unrecognized.  Attemts to boot from sd(0,0)netbsd and the
like complained about a bad adaptor number.  Looking up at the initial
boot message, I see that bdev = 2a, which of course is 42 in hex, so
hmmm...maybe SCSI disks aren't supported as a boot device after all?

Back to the source...and in the source it looks like it ought to
work...BDEV_SD is defined as 42 and there are cases to handle BDEV_SD
in bootxx.c.  Hmm, so maybe the boot binaries I grabbed are somewhat
out of date...so I recompile and reinstall from the source.

At least it *tries* to boot from the disk now, but doesn't actually
get very far.  I'd like to give exact error messages but I didn't
write them down at the time, and I've screwed around with the boot
blocks quite a bit now trying to make this go, and anything I'm seeing
now would probably be slightly misleading.

One thing that looks somewhat screwy is that the DMA base address is
defined differently for KA410 and KA420 machines in ka410.h and
ka420.h.  But only the KA410 DMA address seems to occur anywhere in
the code -- in vsa/vsbus.c we have:

struct confargs ka420_devs[] = {
        { "le",         5,      5,      0x250,  (1<<5), KA410_LAN_BASE,
                KA410_NWA_BASE, 0x00,                                   },
        { "ncr",        1,      1,      0x3F8,  (1<<1), KA410_SCS_BASE,
                        KA410_SCS_DADR, KA410_SCS_DCNT, KA410_SCS_DDIR,
                        KA410_DMA_BASE, KA410_DMA_SIZE, 0x00,   0x07,   },
        { "ncr",        0,      0,      0x3FC,  (1<<0), 0x100C0180,
                        0x100C01A0,     0x100C01C0,     0x100C01C4,
                        KA410_DMA_BASE, KA410_DMA_SIZE, 0x00,   0x07,   },
        { "" },
};

and in boot/scsi_low.c:

#define SC_DMA          0x200D0000      /* base for data registers (8/16K) */

I've tried setting these to more appropriate values for KA420, but so
far it doesn't seem to make much difference.

Well, that's enough for now...back to netbooting, and off to work.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.

This message may refer to a product containing software developed by
Christopher G. Demetriou for the NetBSD Project.