earleh@dartvax.UUCP (11/23/86)
This query relates to running two Intel iSBC 86/30 processor
boards off the same disk in an Intel 86-310 micro-computer with a
Multibus I card cage, iSBC 215G Winchester controller, and with
one of the boards running iRMX86, Version 7. For the benefit of
those not familiar with Intel's whole product line, in addition to
chips they also make computers, operating systems, and a whole
line of software development tools to make use of said chips. The
particular computer I have is an 86-310, which is about the same
size as an AT, but has a Multibus I card cage, and much snazzier
cabinet (black and white, with attractive Intel logo on the
front). The operating system, iRMX86, comes with enough source
code, libraries, and an "Interactive Configuration Utility" to
allow the user to recreate a custom version of the operating
system to his own specifications. (This is a nice touch, try and
get the source code for MSDOS, for instance). The setup we have
is primarilly for OEM types, but it functions very well in my
particular application, Radio Astronomy signal averaging.
My situation is this: I have two iSBC 86/30 CPU boards I use
in this system, together with an iSBC 012B memory expansion board,
a iSBC 215G generic Winchester controller, and some custom boards
which handle the signals coming from the radio telescope. I have
set up the two iSBC 86/30 boards for "serial priority resolution"
of Multibus requests. The board I have given the highest priority
in this scheme, which I will call the "master", runs iRMX86 and
accesses the iSBC 012B and the 215G. The other processor, which I
will call the "slave", gets its input data from an iSBX analog to
digital converter board of our design, and shares the 012B with
the master. Specifically, a reserved area in high RAM on the iSBC
012B is used to pass control information and data between the
slave and the master. At present, the slave runs a program which
I have installed in PROM mounted on the slave 86/30, and the
master boots the operating system through the 215G as normal.
What I would like to be able to do is to have the slave 86/30
run a program which I have saved on the same Winchester that the
operating system and all my user programs reside on. I have the
configuration code and libraries to generate the bootstrap loader
(bs1.a86, bs1.cfg, etc.). I envision booting the operating system
from the Winchester, and then having the bootstrap loader (IN PROM)
load and run my slave data-acquistion program, which is only about
800 bytes in size. This would be extremely convenient for me in
the event I decided to make changes in the data-acquisition
program while at the radio telescope site (2000 miles from my base
of operations). Changing the program in PROM while in the middle
of the New Mexico desert would be a trick, but changing a
disk-based program would be trivial.
The problem as I see it is as follows: The bootstrap loader
that comes with the computer apparently loads programs by an
algorithm which makes use of whatever Multibus memory is available
for a scratch area, and then loads the actual program to the
Multibus addresses contained in the object record. I think I can
fix the code in the "system_support" macro to use a scratch area
consisting entirely of the on-board RAM on my slave 86/30, but how
do I reconcile the conflicts that seem inevitable with two CPUs
trying to load off of the same disk? Also, does the 215G
controller load the information from disk directly into RAM at the
request of the bus master, or does the bus master "fetch" the
information from the 215G and put it into RAM itself? Since the
first method seems more efficient to me, I have assumed it is the
method used. If it is, how do I tell the 215G which CPU is
presently loading a program from disk? At present, the master has
its on board memory dual-ported to the Multibus so that the
on-board and off-board addresses to access this memory are the
same. The slave does not at present have its on-board memory
accessible from the Multibus. Does this mean that I cannot use
the bootstrap loader in a "normal" mode to boot my slave CPU?
Does anyone who subscribes to this newsgroup (a) know what
I'm talking about, (b) have experience in running two CPUs in a
Multibus I card cage from the same disk, or (c) know someone who
can help?kwb@omssw2.UUCP (Kurt Bailey) (11/25/86)
In response to the query about how to run two iSBC 86/30 CPU boards on one MULTIBUS, and have both use the iSBC 215G disk controller: Don't do it! Try this instead. Treat the second 86/30 as a peripheral board and have the "Master" board load "slushware" to it. The iSBC 188/56 is an example of this type of "slave" board. (iSBC 188/56 HRM Order Number 148209-001). On power-up or reset, the firmware on the "slave" board loops watching a control location for a "magic pattern". The 188/56 F/W uses "RIGHTNOWGOTO". The master board powers up, goes thru the system confidence test (assuming you have the 310 system firmware), enters the firmware bootloader and loads your iRMX for the master. Once up you can either write a CUSP (if you are using the Human Interface) or integrate code into your application job that loads the desired program for the slave from disk into the slave's dual port RAM or a shared MULTIBUS space. The master sets a pointer in a prearranged shared location (just before the "magic pattern" is a good place) and sets the "magic pattern". This causes the slave firmware to transfer control to the location indicated by the pointer. If the RAM on the slave that you wish to load to is not visible to the master, you will have to do the job in two steps (1) master loads a slushware loader into the part of RAM that *is* visible to the MULTIBUS and starts it with the "magic pattern" (2) master and slushware loader cooperate to load the slave iRMX (or program). If you write a CUSP to do this job you will have the ability to load various programs to the slave, on command. Or, you can treat the slave 86/30 and A/D SBX board (I'm assuming it's an SBX board) as one "intellegent A/D peripheral with dual port memory" and write a device driver for it. The slushware would be loaded during the device_init portion of the driver attachment. You could set up a file in /config that specifies the file that contains the slushware. You should also set up some mechanism to "soft reset" the slave. A command in a shared data structure would tell the slave slushware to soft reset (branch to the firmware). This would be needed if you wanted to reload slushware without a hard system reset. Intel makes 310 systems called "APEX" that have up to four iSBC 286/12 CPUs on one MULTIBUS and runs Xenix (trademark of Microsoft). These boxes use a similar scheme, that is, only one CPU "owns" and controls the iSBC 214 disk controller. For the record, the bootstrap algorithm for a 310 system goes like this: The firmware bootloader reads the first block on the first track of the device and uses the information formatted thereon to determine the device characteristics (ie winnie, floppy, 5", 8", 48 or 96 tpi, etc). It then loads and transfers control to the second stage bootloader which is a binary image that has been formatted in a fixed location on the first track by iRMX. This program is Position Independant Code, which means it was compiled COMPACT and can be relocated by the firmware loader simply by setting up the segment registers. The firmware loader will do a memory scan prior to loading the second stage, and will relocate the second stage to the top of RAM. (Some of the old firmware bootloaders you encounter may not do this relocation). A pointer to the name of the file to be loaded, a pointer to the firmware device driver to use, and a pointer to an error reporting routine are passed in registers. The second stage knows how to search and access the iRMX file system and will proceed to load and transfer control to the target file. FYI, I am an engineer with the Intel Custom Systems group in Hillsboro Oregon.