Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!vsi1!steve
From: steve@vicom.com (Steve Maurer)
Newsgroups: comp.sys.sgi
Subject: Various SGI Questions (VME bus interface & other programming)
Message-ID: <1989Sep19.021146.2609@vicom.com>
Date: 19 Sep 89 02:11:46 GMT
Reply-To: steve@vicom.COM (Steve Maurer)
Distribution: usa
Organization: Vicom Systems Inc. San Jose, Cal.
Lines: 74


    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@vicom.com