Various SGI Questions (VME bus interface & other programming)

[Ted Wilcox]

I will just answer the parts of Steve's posting.  As to the questions he
asks that I am leaving out, I just don't know the answer.

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:
>
>	What is causing this?

I Dunno.

>
>    #2] We need to reserve an entire interrupt priority level for
>	communication between our various boards.  This means that the
>	How do you do this?

I Dunno.

>
>    #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).

This manual is fairly good, but not as complete as a newer version due out
"Real Soon Now."  Actually, this supposedly means at the end of this month.
The document number for the new manual is: 007-0911-010.  You should be able
to order it from you friendly neighborhood sales rep.

>	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?

Ok, there are a few issues here.

1) The table you are looking at is for a VME device doing DMA to/from the IRIS'
main memory.  The table you are really interested in is the one labled
"A32 Kernel-VMEbus Mapping".  (Table 5)

This table says that "Kernel Addresses" 0xB0000000 - 0xBBFFFFFF map into
VME addresses 0x10000000 to 0x1BFFFFFF.  (This is all unprivileged data access
--VME address modifier 0x09.)  So, if you wanted to assert VME address
0x1000A000 you would use the Kernel address 0xB000A000.

2) The reason that the manual emphasizes the use of the "Kernel Virtual"
address is that up through rev. 3.1C of our operating system, we expected
"physical" addresses in the mmmap_addrs array.  A physical address is NOT
a VMEbus address, but is a "K1" address with the top 3 bits stripped off.
(A K1 address is an address in which the top 3 bits are 101.)  K1 addresses
are not cached, and do not go through the TLB.

>
>    #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.

Actually, YOU have a more detailed copy of what space SGI uses for what
boards.  It's in the file /usr/sysgen/system on your system.  (Assuming
that you have 3.1D or later.

In addition, this file has a better table of what spaces we reserve for
customer use.  Just in case the one you have is not as complete as mine,
mine says that any A32 VME address in the following two ranges

  0001 01xx xxxx xxxx xxxx xxxx xxxx xxxx  np (All but R2300)
    -Should be OK, since 4D70s use IP4s.
  0001 11xx xxxx xxxx xxxx xxxx xxxx xxxx  np

(where each digit represents a bit) is reserved for customer use.  So this
gives you two 64M spaces to use.  Additionally, this file tells you
specifically what SGI boards use what spaces.

>	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).

Well, from the info I have, it looks bad for our heros.  The addresses you
want (0x00200000 - 0x02800000) are not in the VMEbus ranges which the driver
guide and the system file state are accessable.  If there's a way to get to
those addresses, it's a deep dark secret.

>
>
>							Steve Maurer
>							steve at vicom.com

I'm not one of the SGI kernel hackers, so I don't know every in and out of
our memory mapping scheme.  However, I have written a couple of drivers for
4D70 systems, and have been through the memory mapping stuff a jillion times,
so I do have a pretty good idea of what can be done, and what problems often
occur when writing drivers for our systems.

Good Luck.

P.S.  If you have more questions, I'd be glad to help you out any way I can
via e-mail.

Ted.
ted at sgi.com
{sun|decwrl|pyramid|ucbvax}!sgi!ted