Jay Maynard <jmaynard@phoenix.net> wrote:
> I'm not planning on doing it this way, at least not explicitly. My goal,
> at least for the SGEC and SHAC drivers, is to make them just another pair
> of drivers that anyone can include in their system's configuration
> independent of the bus type - since it's not attached to the Qbus anyway.
> At least for the KA670, the SGEC is just 16 registers starting at
> 0x20008000; making it work for other CPUs should be a matter of making it
> figure out which machine it's on and supplying the appropriate address
> for the SGEC, [...]
   
   To the best of my knowledge, the CPUs with SGEC are KA660, KA670, KA690,
and KA50/52. I know for sure (have the docs) that on the first two it's
located at 0x20008000, and I have very good reasons to believe that it's
the same for the last two. Also to the best of my knowledge, the CPUs with
SHAC are KA640, KA660, KA670, KA690, and KA50/52 equipped with a special
daughterboard (officially only for KA52, but I'm sure as hell that it would
work on KA50 just as well). Of these I have docs only for KA660 and KA670,
and they tell me that the former has one SHAC at 0x20004200 while the
latter has two SHACs at 0x20004000 and 0x20004200. I would be very
surprised if KA640 and the KA50/52 daughterboard had their SHACs somewhere
other than at 0x20004200.
   
   Both SHAC and SGEC are DEC proprietary chips that interface directly to
the CDAL bus, so once you know the address, you are all set and you don't
have to wait for surprises with some registers being slightly different or
counters being off by 1. This is in marked contrast to generic chips like
NCR 5380 that require a lot of glue logic to interface to CDAL or any other
bus and give DEC's engineers the freedom to annoy VAX OS writers in various
creative ways by making this logic "just a bit different" on different
boards.
   
   The problem you are going to run into is not with addresses, but with
NetBSD's code (mis)organization. In any BSD-style OS all devices have to be
viewed as being attached to some kind of bus. NetBSD invents the concept of
"vsbus" ("VAXstation bus") to contain the various devices on the busless
KA410, KA42/41, and KA43 boards. Not only is the term very poorly chosen
(KA41 is not a VAXstation and VAXstation II is definitely not busless;
BabyVAX would be a much better term), but this mechanism also makes no
provision for supporting non-Q-bus devices on Q-bus CPUs. When you say that
you will make the SHAC and SGEC drivers "just another pair of drivers",
what bus are you going to attach them to logically? vsbus? In this case
you'd have a lot of fun explaining to the NetBSD code that a VAX may have
both a uba (Q-bus) and a vsbus. Invent yet another "virtual bus"? In this
case the fellow who decides to port your drivers to KA50/52 would have some
fun bridging the gap between two different "virtual buses", as the SHAC and
SGEC drivers would be on the new one while things like the serial lines
would remain on the vsbus as a heritage from the current KA410/41/42/43
code.
   
> adding code to figure out what the machine's Ethernet address is (if it's
> not stored in the same manner as the KA670, which has it as byte 1 of 6
> longwords starting at 0x20008400).
   
   Hmm, so that's where it's stored... My docs have chosen to omit this
little detail... Anyway I'm sure that it's the same on all CPUs with SGEC.
   
> Only one gotcha: I don't _have_ a KA640/KA50/whatever to play with.
   
   I don't either.
   
> The only reason I'm doing the KA670 is that I stumbled across a smoking
> deal to get it. With that in mind, how would you suggest I proceed? It's
> kinda hard to write driver code for a machine you don't have to test on.
   
   I'm faced with such problems all the time. My solution is to use my
imagination. First to imagine what does a CPU look like without having any
docs for it and write the code for it, then to imagine that your code works
without being able to test it. Of course the chances that it will "just
work" are very slim, but those who come next will have something to start
with. It is my belief that it's always better to have at least some code
(even if it doesn't work) than to leave a hole in the chain of supported
systems. Why? While writing working code requires full technical docs and a
test machine, if the only thing you are after is a basic understanding of
what does the beast look and feel like, imagination, reasoning, and
extrapolation from the more readily available but less technical docs is
all you need. If you have this basic understanding, you can plan your work
accordingly. If you, on the other hand, simply neglect a system's
existence, you may make some poor choices in your code structure that would
cause an obstacle to the fellow who later decides to port it to the system
you have neglected.
   
   Getting back to practical issues, you should keep two things in mind.
When you write your SHAC code, keep in mind that SHAC also exists on KA640,
which is supported by the KA650 code, that is, the code that already
exists. With this in mind take a look at the KA650 code and make sure that
your new code is easy to integrate with it. When you develop a mechanism
for recognizing SHAC and SGEC on Q-bus CPUs, design it with more than just
these two chips in mind. The Ethernet interface on KA640 is LANCE, not
SGEC. This chip is also used by KA410, KA42/41, KA43, KA45, and KA46, and
NetBSD supports it on the first 3 of these. Given that Ultrix seems to
always look for it at a fixed address and manages to find it on all systems
from the above list that it supports (KA640, KA410, and KA42/41), I believe
that the address of this chip is the same on all of them. This is a generic
chip, however, and requires glue logic. I'm just praying to 11/780 that
it's the same too. (My prayers may be in vain, though. The LANCE chip can
address only 16 MB of memory, and mapping this into a larger address space
requires changing the glue logic. This is exactly the case on KA41/42/43
with their 32 MB address space. Since the KA650 family has a 64 MB address
space, the glue logic may be different again.)
   
   Sincerely,
   Michael Sokolov
   Phone: 216-368-6888 (Office) 440-449-0299 (Home) 216-217-2579 (Cellular)
   ARPA Internet SMTP mail: msokolov@blackwidow.cwru.edu