Various SGI Questions (VME bus interface & other programming)
Steve Maurer
steve at vicom.com
Tue Sep 19 12:11:46 AEST 1989
I am working on a project in which we are integrating a number
of boards into an SGI 4D/70GT. The boards include a real-time
"system-controller", which talks to the SGI via a simple message-passing
scheme (through dual ported memory), and our own memory boards (VME
A32/D16). I'm also porting software.
Now for my questions:
#1] Our upper level software gives a "warning" in the link
stage about "jump relocation". The actual messages read:
Warning: error: multiply defined
Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489dbc to 0x10066270 (asm)
Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489eac to 0x10066270 (asm)
Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489fc8 to 0x10066270 (asm)
Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x48a0c8 to 0x10066270 (asm)
What is causing this?
#2] We need to reserve an entire interrupt priority level for
communication between our various boards. This means that the
SGI hardware must ignore an IPL (not just have a null interrupt
vectors, but actually not respond to it). When we started the
project, SGI told us this is possible, but not how it was done.
How do you do this?
#3] We need the SGI to talk to both our system controller and our
memory as VME slaves. The document we were provided seems to
be unclear in a number of areas, however. (We have: Guide To
Writing Device Drivers For Silicon Graphics IRIS-4D Computer
Systems, Revision 1.1, Dec 13 1988).
The description under Simple Memory Mapped Device Driver in
Chapter 3 strictly warns about using "kernel virtual addresses",
not physical bus addresses in the mmmap_addrs array, and refers
to the appendix entitled: VME slave addressing. In the appendix
however, there is no mention of what the difference actually is
between these two addressing schemes. It does have a chart (Table
7 for A32 VMEbus-Physical Address Mapping), with two columns
entitled "VME Address" and "Physical Address". The numbers are
exactly the same, except for one unique reference for the IP5/7,
which appears incompatible with all the other. It isn't clear
what is meant, but am I correct in my presumption that the "kernel
virtual address" is the "VME address", and that except for the
IP5/7, the two are basically the same? If not, assuming that my
A32 memory starts at "physical location" 0x800000, and goes up
for 32 MB, what is the corresponding "kernel virtual address" that
I should enter into the mmmap_addrs array?
#4] Chart A.8 in the same section, "VMEbus Space Reserved for Customer
Drivers", also seems to be incomplete. SGI told us that their
system could support our addressing requirements (which on our
Sun version, runs contiguously from 0x200000 to 0x2800000 in A32).
Yet the VME bus addresses reserved for customers by the chart A.8,
gives only a pitiful 32 MB (0x1A000000 - 0x1BFFFFFF), barely enough
to support our extra memory. Thus, the VME addressing the chart
gives is insuffient to run the system.
Presumably, SGI was just overly aggressive in reserving space for
itself on the VME bus, as I have a hard time believing that they
could be actually using all that address space. So does anybody
have a more detailed copy of the SGI mem map, which says what is
really REALLY off-limits to trash, rather than the "A.8" chart
they have now? If necessary, I might even consider installing
our VME boards over addresses reserved for SGI optional add-on
boards, and just saying that our system won't work with them
installed. This project is under extreme time pressure, so I am
hoping not to have to relocate any boards at all if possible (or
the absolute fewest necessary).
Steve Maurer
steve at vicom.com
More information about the Comp.sys.sgi
mailing list