Various SGI Questions (VME bus interface & other programming)

[Len Lattanzi]

In article <1989Sep19.021146.2609 at vicom.com> steve at vicom.COM (Steve Maurer) writes:
:
:    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?
Typically this is caused by one importing module referencing a symbol as text
and trying to jump to it. And the exporting module defining the symbol
to be data. Text and Data are normally too far apart to jump between.
You could use -Wl,-yerror,-yasm on the link command to indicate all
modules referencing error and asm and make sure the uses are consistent.
:
:    #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


\
 Len Lattanzi	({ames,pyramid,decwrl}!mips!synthesis!len) <len at Synthesis.com>
 Synthesis Software Solutions, Inc.		The RISC Software Company
 I would have put a disclaimer here but I already posted the article.