[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: netbsd-5.1 cpu probe/attach for 11/7xx?
On 2011-06-26 04.00, der Mouse wrote:
Older VAXen don't really have a CPU attach function. There can
only be one CPU, and it is implicitly already attached.
NetBSD/vax doesn't support the 782?
Right. The 782 is not supported. It is in fact rather tricky, if we
were ever to support it, since it's not an SMP machine. The second
CPU acts as a slave to the first one. They are not equal. The
second CPU can only do computations, and have no I/O attached to it.
Aren't a lot of multiprocessor machines asymmetric in that sort of way?
For example, only one CPU can field interrupts?
Hmm. Well, I can't really say. The MP machines I've worked on have been
much more SMP than the 11/782 is. But it's true that few machines are
truly symmetric. There is usually some CPU which is a little special.
I must admit that I'm not totally aware of how the hardware works in the
11/782. I only know how VMS ran on that machine, and as far as I know,
only VMS supported it. But for VMS, the secondary CPU was scheduled by
the primary CPU. It did not run the OS at all. Instead, the primary CPU
scheduled the secondary, and whenever something significant happened for
the process controlled by the secondary CPU, it just interrupted the
primary, who had to deal with it. And the secondary CPU then waited for
some new work to be scheduled for it by the primary CPU. The machine did
have shared memory, but apart from that, I'm not sure how the
communication between the CPUs were done. Some sort of way for the
secondary to interrupt the primary existed, and some way for the primary
to feed information to the secondary for it to start work, but I lack
more detail. (I bet it exists somewhere though, if we really want to
figure this out...)
Certainly the MicroVAX-II supported relatively symmetric
multiprocessing; as far as I can recall the only asymmetries there are
that the CPU at ID 0 (a) terminates the Qbus, (b) runs at power-up
instead of halting and waiting for another CPU to boot it, and (c) gets
Qbus device interrupts. (Not all device interrupts; some devices, such
as console serial ports, exist on each CPU board and interrupt the CPU
whose board they're on.)
Well, not really that simple. There are no IDs for devices on a Qbus. If
you wanted to have a second CPU on the Qbus, you need to remove the bus
termination and bus arbitration from that CPU, since you cannot have two
bus arbitrators. And as far as I know, the KA630 don't have a way to
actually do that disabling.
Also, the uVAX II have the memory on PMI, which is separate from the
Qbus, so a second CPU cannot access the memory of the primary CPU. This
is the difference from the uVAX I, which actually had memory on the Qbus
(that also limited the memory to 4MB on the uVAX I).
It was difficult to get a KA-630 without a MicroVAX around it, becaus
DEC didn't want knock-off Qbus backplanes furnished with KA630s and
sold as cheap MicroVAXen. (The KA620 was their answer to that; I don't
recall whether NetBSD supports the KA620. It would probably be easy to
add if not; it was a minor tweak.) I know a bit about this because a
reseacher I was supporting once wrote a robot control system where the
control law ran on an auxiliary KA620 - and I wrote the kernel for the
I have actually never seen or heard of a MP KA630, but if you have some
real references, it would be interesting. I looked up the KA620, and it
might be that this model was designed with the possibility to have
several on a single Qbus, but it is a bit unclear. I'm also not sure how
you dealt with interprocessor communication in this case. I suspect the
KA620 used normal Qbus memory, but how would one CPU interrupt another one?
KA630 cpu boards exists in ridiculous numbers nowadays, you know... ;-)
There is in fact no VAX which have a Unibus as the native bus. The
closest would be the uVAX I, which have the Qbus as the system bus.
But that's the only one.
What did the uV2 have? Certainly from a user's perspective the Qbus
was the system bus there; are you considering there to be a memory bus
on the CPU board which the CPU, RAM, and Qbus all hang off of?
RAM does not sit on the Qbus. Remember, the Qbus can only address 4MB.
You have a Unibus map (well, I guess it should be called a Qbus map in
this case) between the Qbus and memory, while the CPU talks to memory
There is no official name for whatever bus is closest to the CPU on the
uVAX II, and since that bus is internal to the CPU card, it's easy to
regard the machine as a Qbus machine, but looking closer, it is pretty
obvious that it's not really true that the Qbus is the system bus. The
Qbus is just an I/O bus for the uVAX II.
I think that in NetBSD we call it "VSBUS" for lack of a better name.
Certainly from a multiprocessing perspective, the Qbus was the main
interconnect; for one CPU to get the attention of another required a
Qbus cycle. (Each CPU had its own memory interconnect; the only way to
share memory between CPUs, as far as I know, was over the Qbus. This
was a bit of a pain, because it meant that for every byte of memory,
one CPU had fast access to it and everybody else had slow, or no,
That would also imply DMA access to get to another CPUs memory, running
through that CPUs mapping registers, and so on. It also becomes even
more weird, since memory access by one CPU does not even go out on the
Qbus, so you can only get access to another CPUs memory by faking that
you are accessing the I/O page of the Qbus, which is a 8Kbyte memory in
the high end. The fiddling to pull this off is more than I want to think
of, if at all possible. Such an I/O page access on the Qbus is not the
same as a DMA memory access by some other device on the Qbus, so I very
much doubt the other CPUs memory mapping and response would be
activated. And you'd still need to avoid your own CPU to react to those
accesses. Besides, you then also need to make the CPU respond to a whole
range of addresses up high. And this has not at all solved the interrupt
issues. If a device field an interrupt, all CPUs would see it. How would
you prevent all but one CPU to ignore this?
Main Index |
Thread Index |