I have done some experimentation with this. You can easily do things like
use a 3/60 running x-kernel as an intelligent graphics subsystem in the
same chassis as a server.

To share a backplane between two VMEbus "systems" you can also build a
kernel for one "system" that does not have any VMEbus devices. One system
can use the left side of a 12 slot chassis and another system can use slots
10-12. The secondary CPU has to have the VMEbus clock generator jumpered
off and has to have the VMEbus arbiter jumpered for slave mode. You have to
bring both "systems" up in the EPROM monitor before you boot the OS because
the monitor probes the VMEbus.

It would also be possible to have the kernels for each "system" built so
that it would ignore the other "system's" VMEbus boards. The device
addresses and interrupts would have to be non-standard for some of the
boards. The CPUs will share the IACK driver but handle their own interrupts.

Communicating between the boards using TCP/IP is a standard called BusNet.
See http://www.vita.com/vso/draftstd/VITA-19.0.pdf for more information.
For high performance this standard depends on mailbox interrupts that most
modern VMEbus CPUs have and Sun boards lack. You can run the boards in
polled mode but the latency is higher.

Sun sold software called ONC that supported multiple 1E 6U SPARC CPUs in
the same chassis. The CPU number was programmed into the EEPROM. There is a
monitor command to boot a secondary CPU from the primary CPU across the
VMEbus using ONC.

Linux has custering software that could be adapted to deal with the VMEbus
TCP/IP device.


At 01:59 AM 3/30/01 -0000, jwbirdsa@picarefy.picarefy.com wrote:
>   I'd have to go dig up my docs and look at the actual pin assignments
>to be 100% sure of exactly what's where, but the general concept that
>P1 is primarily VME, P2 is primarily Sun's private bus, and P3 is primarily
>VME again, mostly power, is valid.
>
>   Whether two machines could coexist in a chassis is an interesting
>question. In theory, if on different P2 segments, each would have a
>private memory bus. The VME bus to devices would be shared, but many
>CPU boards can be jumpered for VME slave mode. By clever trimming of
>the kernels, you could keep them from trying to grab the same devices.
>I guess it would hinge on whether "slave mode" is purely a hardware-level
>thing, invisible to the OS, or requires that the OS make or not make
>certain assumptions. Electrically speaking, I think it would work, but
>whether it would require OS modification or not is an open question.
>   I've heard rumors of clustering experiments using CPU boards with
>onboard memory, speaking TCP/IP to each other across the VME bus, but
>that was using very custom software.
>
>   --James B.
>
>
>

Michael Thompson
E-Mail: M_Thompson@IDS.net