OK, I will forgive you guys this time (the patch is below), but from now
on if I notice someone deleting my posts without reading them, I won't give
you one more byte of code and you can be as sure as hell that NetBSD will
never support anything besides what it supports now.
   
   OK, here's the change. Find the following lines in arch/vax/vsa/vsbus.c:
   
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), 0x200C0180,
                        0x200C01A0,     0x200C01C0,     0x200C01C4,
                        KA410_DMA_BASE, KA410_DMA_SIZE, 0x00,   0x07,   },
        { "" },
};
   
   and change them to:
   
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,
                        KA43_DMA_BASE,  KA43_DMA_SIZE,  0x01,   0x07,   },
        { "ncr",        0,      0,      0x3FC,  (1<<0), 0x200C0180,
                        0x200C01A0,     0x200C01C0,     0x200C01C4,
                        KA43_DMA_BASE,  KA43_DMA_SIZE,  0x01,   0x07,   },
        { "" },
};
   
   i.e., change the DMA buffer address from KA410_DMA_BASE to
KA43_DMA_BASE, the DMA buffer size from KA410_DMA_SIZE to KA43_DMA_SIZE,
and the DMA flags from 0x00 to 0x01 for both SCSI buses. (Two lines need to
be changed.) Then go to arch/vax/vax/ka410.c. Starting at line 62 there is
a table of on-board devices. Add the following entry to it:
   
        { 0x202D0000,           0x202EFFFF,     0x00020000,     0 },
   
   I have added it to the end, but I don't think it matters. That's it,
guys. A 3-line change, as I have promised.
   
   Now for the story behind this change. One of the greatest flaws of the
present-state NetBSD, IMHO, is its jumping, skipping, and non-sequential
approach to supporting different systems. The reason KA42/41 has always
been behind all other BabyVAXen is that when the authors of the BabyVAX
support code first wrote it, they designed it for KA410 and KA43, skipping
KA42/41. The GENERIC kernel config file contains 'options "VAX410"' and
'options "VAX43"', but no 'options "VAX42"' or 'options "VAX420"'. In
arch/vax/vax you'll find ka410.c and ka43.c, but no ka42.c or ka420.c. By
making this jump, the developers have made the life harder both for
themselves and the users.
   
   Why for themselves? Simply because hardware evolves sequentially, and
the differences between KA410 and KA43 are nothing but a sum of the
differences between KA410 and KA42/41 and between KA42/41 and KA43. Going
through KA42/41 would have been both easier and more logical than making
the jump. Why for the users? Simply because when the time came for someone
to add the KA42/41 support, the jump came back to haunt them. Since the
code had already been designed with only two flavors in mind (KA410 and
KA43), there was no place for KA42/41. What has been done is a horrible
kludge. Someone has made the nut-headed assumption that KA42/41 is just
like KA410. If anything, it's MUCH closer to KA43. Remember the cache
problem? Well, guess what, KA42/41 and KA43 both have cache and KA410
doesn't. By making the nut-headed assumption that KA42/41 is "just like
KA410", the guy has dumbed it down from its rated performance of 2.8 or 3.8
VUPs (depending on what version you've got) to about the performance of
KA410 (0.9 VUPs). If KA42/41 is not like KA410, MAKE it KA410, right?
Exactly the same with SCSI. Even if you (like me) don't have any KA42/41
manuals, just a simple cursory visual examination of the KA42 board and the
SCSI/SCSI daughterboard should tell you that its DMA mechanism is much
closer to KA43 than to KA410. The chips that form the 128 KB DMA buffer are
big and clearly visible. Of course the result was that SCSI didn't work on
KA42/41 AT ALL (at least until the PIO kernel was built at a much later
point).
   
   I know exactly what the guy is going to say in response. "I didn't have
a KA42/41", or "I didn't have any KA42/41 manuals." But this is not an
excuse! As for manuals, I don't have any either. As for hardware, I do have
a bunch of KA42s, but this was not the instrumental point. My mental
picture of KA42/41 was complete before I powered one up for the first time.
The real difference between me and the NetBSD developers is my imagination.
This is my primary instrument. As soon as I decided that I was going to
compete with VMS and work on supporting everything from 780 to 10000, I
realized that there is no way I could follow the traditional method of
looking for a test machine and the docs for each supported model. I'm sure
as hell that I will never have a 10000. And yet this doesn't stop me.
Whenever my authoritative sources are inadequate, I fill in the gaps with
my imagination. Getting back to the KA42/41 SCSI issue, while everyone else
was leading an academic discussion of what are the differences between the
DMA mechanisms of different BabyVAXen, I boldly stepped forward and
declared in a thundering voice that my logical reasoning and imagination
tell me that there are NO differences. What did I get in response? Your
"plonks"? Well, as you can now see for yourselves, I was right. I changed 3
lines of code to make NetBSD treat KA42/41 more like KA43 than like KA410
and voila! The SCSI problem is gone.
   
   Of course, when you rely on your imagination, you cannot be absolutely
sure. I was not sure either. I have been refraining from posting anything
to this list for about 3 months precisely because I wanted to test my idea
first. By the beginning of March your "plonking" reached the point that I
was unable to participate in any technical discussion, and I had to leave.
First I had to get my Ultrix box fully up and running so that I could
change my address to bypass your foolish scripts. Second, I had to get
NetBSD up and running in order to test my theory. Because of all your
"plonks", I wasn't able to ask any questions and had to give up on
netbooting and go through the move-the-disk pain, further stretching the
schedule. Finally, I have made the change I have described at the beginning
of this message without having any idea as to whether it was going to work
or not. It was merely a stab in a dark, with the purpose of testing the
theory which I have declared so boldly on this list and which has got me so
much flame. Well, the stab has turned out to be successful. Do you still
feel like flaming me? If you do, go ahead. Your OS is going to suffer, not
mine.
   
   Sincerely,
   Michael Sokolov
   Phone: 216-368-6888 (Office) 440-449-0299 (Home) 216-217-2579 (Cellular)
   ARPA Internet SMTP mail: msokolov@blackwidow.cwru.edu