Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: netbsd-5.1 cpu probe/attach for 11/7xx?

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

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.)

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
auxiliary CPU.

>>> [...] for an 11/780, nor any other Unibus VAX.
>> I thought the 780 was SBI-based, [...]
> He.  Of course someone should catch me in that lie... :-)


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

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,

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index