steve@vicom.com (Steve Maurer) (09/19/89)
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
ted@bangles.sgi.com (Ted Wilcox) (09/20/89)
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@vicom.com> steve@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@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@sgi.com {sun|decwrl|pyramid|ucbvax}!sgi!ted
len@synthesis.Synthesis.COM (Len Lattanzi) (09/22/89)
In article <1989Sep19.021146.2609@vicom.com> steve@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@vicom.com
\
Len Lattanzi ({ames,pyramid,decwrl}!mips!synthesis!len) <len@Synthesis.com>
Synthesis Software Solutions, Inc. The RISC Software Company
I would have put a disclaimer here but I already posted the article.