Subject: VS3100: success with netbooting, limited SCSI success
To: maximum entropy <>
From: Bertram Barth <>
List: port-vax
Date: 08/15/1997 10:00:02
> I succeeded in getting NetBSD/vax-1.2G installed on a VAXstation 3100


> 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

There are no standalone drivers for NCR/SCSI, thus programs like edlabel and
copy which rely on the standalone drivers don't work for 3100's SCSI.

> DMA incomplete: ntrans=8193/8192, lock=98
> 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.

>From the first look I'd say it's a problem with the DMA interface.
I don't know if this helps, but you could try to force the use of
the ka43 interface instead of the ka410 interface which is default
for ka42.

> 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?

Yes and No. /boot also relies on the standalone drivers, thus this is
the reason for your problems. On the other hand, for just loading a 
kernel from your boot drive, you can use the builtin ROM routines.
At the nboot-prompt just type: "rom(0,0)/kernel-name" if your kernel
is on sd0. This works for me.

> 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:

You might want to try this one instead:
struct confargs ka420_devs[] = {
        { "le",         5,      5,      0x250,  (1<<5), KA420_LAN_BASE,
                        KA420_NWA_BASE, 0x00,                           },
        { "ncr",        1,      1,      0x3F8,  (1<<1), KA420_SC1_BASE,
                        KA420_SC1_DADR, KA420_SC1_DCNT, KA420_SC1_DDIR,
                        KA420_DMA_BASE, KA420_DMA_SIZE, 0x01,   0x07,   },
        { "ncr",        0,      0,      0x3FC,  (1<<0), KA420_SC2_BASE,
                        KA420_SC2_DADR, KA420_SC2_DCNT, KA420_SC2_DDIR,
                        KA420_DMA_BASE, KA420_DMA_SIZE, 0x01,   0x07,   },
        { "" },
        { "hdc",        0,      0,      0x3FC,  (1<<0), KA420_DKC_BASE, 
                        0,      0,      0, 
                        KA420_D16_BASE, KA420_D16_SIZE, 0x00,           },

Maybe you'll need to add "#include <machine/ka420.h>" also...