Subject: cross-compile fails

From: Vince Weaver <[email-masked]>
Date: Wed, 12 Jan 2000 11:27:41 -0500 (EST)

Hello

I am trying to compile a kernel to boot on an Indigo2 I have access too.

I installed the rpm's of the mips cross-compile tools from oss.sgi.com, 
and got the latest CVS kernel [at about 10am EST today].

the compile fails at the end with this:

make[1]: Leaving directory `/home/vince/sgi/linux/arch/mips/lib'
mips-linux-ld -static -G 0 -N -T arch/mips/ld.script.little -Ttext 0x88002000 
arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o
init/version.o \
        --start-group \
        arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
        fs/filesystems.a \
        net/network.a \
        drivers/block/block.a drivers/char/char.o drivers/misc/misc.o
drivers/parport/parport.a drivers/net/net.a drivers/scsi/scsi.a
drivers/cdrom/cdrom.a drivers/sgi/sgi.a drivers/video/video.a \
        arch/mips/lib/lib.a /home/vince/sgi/linux/lib/lib.a
arch/mips/sgi/kernel/sgikern.a arch/mips/arc/arclib.a \
        --end-group \
        -o vmlinux
mips-linux-ld: arch/mips/kernel/head.o: compiled for a big endian system
and target is little endian
mips-linux-ld: arch/mips/kernel/init_task.o: compiled for a big endian
system and target is little endian
.......

and the last error repeats for a bunch of files

if I change in the config file from little-endian to big endian I get the
same error in reverse, a bunch of files compiled for a little endian
system and the target is big endian.

is there an easy fix to this? am I missing something obvious?

Vince

____________
\  /\  /\  /  Vince Weaver          
 \/__\/__\/   [email-masked]     http://www.glue.umd.edu/~weave

---

From: Vince Weaver <[email-masked]>
Date: Wed, 12 Jan 2000 15:04:20 -0500 (EST)

Hello again

OK, I got things to compile [I hadn't done enough "make clean"'s it would
seem]

after copying the created vmlinux file to / on the machine [it is running
Irix 6.5] I then rebooted into the BootProm and told it to
"boot vmlinux"

It then gave this:

[------------------------------------]

134480+22592+3216+341792+49040d+4460+6704 entry: 0x8dfa5fa0

Exception: <vector=Normal>
Status register: 0x30044803<CU1,CU0,CH,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x3010<LE=0,IP6,IP5,EXL=RADE>
Exception PC: 0x88147eec
Read address error exception, bad address: 0x2b
Local I/O interrupt register 1: 0x80 <VR/GIO2>
Local I/O interrupt register 2: 0xc0 <SLOT0,SLOT1>
  Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
  tmp: 881be090 881be090 a 88150864 13 8dfabd30 0 48
  sve: 8dfde8e4 8dfff908 8dfb0b00 8dfff300 a8747590 9fc4a744 0 9fc4a744
  t8 48 t9 8dfffb8f at 88150000 v0 0 v1 8dfff2e0 k1 bad11bad
  gp 88008000 fp 9fc4a88c sp 88009fd0 ra 880025d0

PANIC: Unexpected exception

[-------------------------------]

Typed that in by hand, hope there are no mistakes

if I look up the PC in the System.map file I find

0000000088147eec T sgi_sysinit

and if I do an objdump I find:

0000000088147eec <sgi_sysinit>:
    88147eec:   27bdffd0        addiu   $sp,$sp,-48
    88147ef0:   afb20018        sw      $s2,24($sp)
    88147ef4:   00009021        move    $s2,$zero
    88147ef8:   afb10014        sw      $s1,20($sp)
    88147efc:   2411ffff        li      $s1,-1
    88147f00:   02402021        move    $a0,$s2
    88147f04:   afbf0028        sw      $ra,40($sp)
    88147f08:   afb50024        sw      $s5,36($sp)
    88147f0c:   afb40020        sw      $s4,32($sp)
    88147f10:   afb3001c        sw      $s3,28($sp)
    88147f14:   0e0522de        jal     88148b78 <prom_getchild>
    .....
    continues for a while

any hints what might be wrong?  I can send a .config to anyone who might
want it.

The cross compiler tools are from the i386/mips-linux .rpm file on
oss.sgi.com....

The system I am trying this on is an Indigo2:

orws1:/disk3/usr/people/vince$ hinv
CPU: MIPS R4000 Processor Chip Revision: 3.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
1 100 MHZ IP22 Processor
Main memory size: 96 Mbytes
Secondary unified instruction/data cache size: 1 Mbyte on Processor 0
Instruction cache size: 8 Kbytes
Data cache size: 8 Kbytes
Integral SCSI controller 0: Version WD33C93B, revision D
  Disk drive: unit 1 on SCSI controller 0
  Tape drive: unit 2 on SCSI controller 0: DAT
  Disk drive: unit 3 on SCSI controller 0
Integral SCSI controller 1: Version WD33C93B, revision D
On-board serial ports: 2
On-board bi-directional parallel port
Graphics board: GU1-Extreme
Integral Ethernet: ec0, version 1
Iris Audio Processor: version A2 revision 0.1.0
EISA bus: adapter 0

Vince

____________
\  /\  /\  /  Vince Weaver

---

From: Vince Weaver <[email-masked]>
Date: Wed, 12 Jan 2000 17:31:11 -0500 (EST)

Ugh.. turns out I missed a faq.

Just went into arch/mips and removed -N from the Makefile, and it worked
like a charm... I've been trying to get Linux on this box off and on for 2
years... ;)  Now time to get the Personal Iris working ;)

thanks for the help everyone,
Vince

____________
\  /\  /\  /  Vince Weaver

---

From: Vince Weaver <[email-masked]>
Date: Thu, 13 Jan 2000 13:09:16 -0500 (EST)

Hello again

I was trying to see if I could get this Indigo2 to display that it is an
Indigo2 under /proc/cpuinfo [instead of current behavior, which assumes
all SGI's are indy's].

I thought that maybe I could get the PROM to tell me this info, using code
like this

    #include <asm/sgialib.h>

    struct linux_sysid *mree;

    mree=prom_getsysid();
    printk("Vendor: %s     Prod: %s\n",mree->vend,mree->prod);

the vendor is returned as SGI, but the "prod" just returns the serial
number [which seems to be just the last few octets of the MAC address of
the ethernet card].  

Is it possible to figure out what system type it is from this info?  Is
there another way to find out sgi system type?  Or is this just not
possible?

Vince
____________
\  /\  /\  /  Vince Weaver

---

From: Avi Bercovich <[email-masked]>
Date: Thu, 13 Jan 2000 19:32:04 +0100 (MET)

Hello All,

I was wondering what the status was of the effort to build a beowulf 
cluster using Indigo2's. 

kind regards,

avi

--------------------------------------------------------------------------
Avi Bercovich                                      [email-masked]
Sinjeur Semeynsstraat 9          Dept. of Social Science Informatics (SWI)
1183LD Amstelveen                                  University of Amsterdam

---

From: Eric Kimminau <[email-masked]>
Date: Thu, 13 Jan 2000 14:18:40 -0500

> there another way to find out sgi system type?  Or is this just not

Howdy Vince!

I can give you a bit of info but I am not sure how helpful it will be.

Booting into the IRIX command monitor (esc on boot)
               To perform system maintenance instead, press <Esc>

(then option 5)
System Maintenance Menu
5) Enter Command Monitor

You have available the hinv command:
>> hinv
                   System: IP22
                Processor: 200 Mhz R4400, with FPU
     Primary I-cache size: 16 Kbytes
     Primary D-cache size: 16 Kbytes
     Secondary cache size: 1024 Kbytes
              Memory size: 128 Mbytes
                 Graphics: Indy 8-bit
                SCSI Disk: scsi(0)disk(1)
                SCSI Disk: scsi(0)disk(2)
                SCSI Disk: scsi(0)disk(3)
                SCSI Disk: scsi(0)disk(6)
                    Audio: Iris Audio Processor: version A2 revision
4.1.0
Also try:
hinv -v
hinv -t
hinv -v -t 
hinv -t -p
hinv -v -t -p

The problem is that IP22 could be an Indy or an Indigo/2. Even under
IRIX if you run hinv it doesn't tell you that a system is an Indy or
an Indigo/2. Your only clues come from knowing additional bits about
what is or is not Indy or I2 hardware.  For example you would never
see Impact graphics on an Indy and you would never see an Indy 8-bit
graphics board on an Indigo/2 (although there were 8 bit boards on an
Indigo/2 - I have been looking aorund internally to see if I can find
one to see what it actually reports at command monitor for graphics).
Further confusion would be to try and identify an older Indigo with an
R4000 upgrade from an Indy.

If you actually got booted to IRIX, you would have even more options
available using the "-c" option to hinv:

Option requires an argument -- c
usage: hinv {-v -m -s -c class -t type -d dev -u unit -a file}
       where class can be:
           processor
           disk
           memory
           serial
           parallel
           tape
           graphics
           network
           scsi
           audio
           iobd
           video
           bus
           misc
           compression
           vscsi
           display
           unconnected scsi lun
           PCI card
           PCI no driver
           prom
           IEEE1394
           rps
           tpu
       type can be:
           fpu
           cpu
           dcache
           icache
           memory
           qic
           a2
           dsp
       dev can be:
           cdsio
           aso
           ec
           et
           ee
           ecf
           ef
           eg
           enp
           fxp
           ep
           hy
           ipg
           rns
           xpi
           fv
           gtr
           mtr
           mtr
           atm
           hippi
           vfe
           gfe
           gsn
           divo
           xthd

but again, hinv -c processor will only tell you that it is an IP22 :

Indy1 % hinv -c processor 
1 200 MHZ IP22 Processor
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
CPU: MIPS R4000 Processor Chip Revision: 2.2

Indy2 % hinv -c processor
CPU: MIPS R4600 Processor Chip Revision: 2.0
FPU: MIPS R4600 Floating Point Coprocessor Revision: 2.0
1 133 MHZ IP22 Processor

ChalS% hinv -c processor
CPU: MIPS R4400 Processor Chip Revision: 6.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
1 200 MHZ IP22 Processor

Indigo2 % hinv -c processor
CPU: MIPS R4400 Processor Chip Revision: 6.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
1 250 MHZ IP22 Processor

Where graphics would yield more information:
Indy1 % hinv -c graphics
Graphics board: Indy 8-bit

Indy2 % hinv -c graphics
Graphics board: Indy 24-bit

Indigo2% hinv -c graphics
Graphics board: Solid Impact

I am asking around internally to see what if  any portions of kernel
probe related code might be releaseable but the problem with even
attempting that (from the few limited conversations I have had with
kernel engineers) is that none of the IRIX hardware identification
code is in one central place. It is really all over the place and
dynamically builds this type of information in the hardware graph unde
IRIX based on all of the hardware the kernel finds in the system.

Short of identifying every possible piece of SGI hardware and doing
the same kinds of things under Linux as are done in IRIX to build the
hardware graph, I think this is probably going to be a fairly
difficult proposition. I am BCC'ing a few people on this message in
hope that they may respond to you singularly with additional
information.

I wish I could tell you more. I will let you knwo if I do find
something more useful.

Eric.

-- 
.--------1---------2---------3---------4---------5---------6---------7.
  Eric Kimminau           [email-masked]       SGI Extranet Services
      Vox:650-933-6441  Fax:248-618-9178  VNET:6-933-6441  
              "I speak my mind and no one else's."
 "I am a bomb technician. If you see me running, try to keep up..."
                    http://support.sgi.com

---

From: Vince Weaver <[email-masked]>
Date: Thu, 13 Jan 2000 15:31:50 -0500 (EST)

> IRIX based on all of the hardware the kernel finds in the system.

OK, I've done a tiny bit of research on the web, and this is what would be
useful:

a way of finding the hardware IP as opposed to the software IP
    i.e., according to the SGI HARDWARE FAQ, while hinv reports
          both indy's and indigo2's as IP22, hardware wise
          the indy has an IP24 motherboard...

what ranges of serial numbers the various hardware have
    i.e., both of our indigo2's have serial numbers starting
          with 69:07, but that could be co-incidence because
          I am sure they were purchased at the same time.  
          ( the personal IRIS starts with E0:48 and the giant
          Crimson looks like A0:08 )

anyway I guess this isn't the most critical of problems, I was just
interested in having /proc/cpuinfo display it correctly [and thus, have
linux_logo show it correctly as well].

Thanks

Vince

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 13 Jan 2000 13:15:36 -0800 (PST)

> > there another way to find out sgi system type?  Or is this just not
...
 > R4000 upgrade from an Indy.

      One key difference is that Indigo2 always has an EISA bus and
Indy never does.  

      Note that the Linux kernel (like the IRIX kernel) has a way of
detecting the difference, since it needs to know which box it is
running on, so you could just get the kernel to export the data via
/proc somewhere.  The kernel variable "sgi_guiness" is 1 if the system
is an Indy ("Guinness") and 0 if the system is an Indigo2
("FullHouse").  Look at the file indy_hpc.c to see how this is detected.

---

From: Vince Weaver <[email-masked]>
Date: Thu, 13 Jan 2000 16:45:41 -0500 (EST)

> ("FullHouse").  Look at the file indy_hpc.c to see how this is detected.

thanks, this is what I needed!  It works (at least for me!)

Here is the patch, I'd like someone with and Indy to try and be sure it
works all around....

bash# cat /proc/cpuinfo
cpu                     : MIPS
cpu model               : R4000SC V3.0
system type             : SGI Indigo2
BogoMIPS                : 49.87
byteorder               : big endian
unaligned accesses      : 0
wait instruction        : no
microsecond timers      : no
extra interrupt vector  : no
hardware watchpoint     : yes
VCED exceptions         : 38
VCEI exceptions         : 56

[---------------]

patch against CVS as of yesterday....

--- ./linux/include/asm-mips/bootinfo.old.h	Thu Jan 13 12:29:17 2000
+++ ./linux/include/asm-mips/bootinfo.h	Thu Jan 13 12:29:42 2000
@@ -91,8 +91,8 @@
  * Valid machtype for group SGI
  */
 #define MACH_SGI_INDY		0	/* R4?K and R5K Indy workstaions */
-
-#define GROUP_SGI_NAMES { "Indy" }
+#define MACH_SGI_INDIGO2	1
+#define GROUP_SGI_NAMES { "Indy", "Indigo2" }
 
 /*
  * Valid machtype for group COBALT
--- ./linux/arch/mips/arc/identify.old.c	Thu Jan 13 12:45:18 2000
+++ ./linux/arch/mips/arc/identify.c	Thu Jan 13 16:26:27 2000
@@ -17,6 +17,7 @@
 #include <asm/sgi/sgi.h>
 #include <asm/sgialib.h>
 #include <asm/bootinfo.h>
+#include <asm/sgi/sgihpc.h>
 
 struct smatch {
     char *name;
@@ -60,9 +61,9 @@
     p = prom_getchild(PROM_NULL_COMPONENT);
     printk("ARCH: %s\n", p->iname);
     mach = string_to_mach(p->iname);
-
+   
     mips_machgroup = mach->group;
-    mips_machtype = mach->type;
+    mips_machtype = !sgi_guiness;
     prom_flags = mach->flags;
 }

--- ./linux/include/asm-mips/bootinfo.old.h	Thu Jan 13 12:29:17 2000
+++ ./linux/include/asm-mips/bootinfo.h	Thu Jan 13 12:29:42 2000
@@ -91,8 +91,8 @@
  * Valid machtype for group SGI
  */
 #define MACH_SGI_INDY		0	/* R4?K and R5K Indy workstaions */
-
-#define GROUP_SGI_NAMES { "Indy" }
+#define MACH_SGI_INDIGO2	1
+#define GROUP_SGI_NAMES { "Indy", "Indigo2" }
 
 /*
  * Valid machtype for group COBALT
--- ./linux/arch/mips/arc/identify.old.c	Thu Jan 13 12:45:18 2000
+++ ./linux/arch/mips/arc/identify.c	Thu Jan 13 16:26:27 2000
@@ -17,6 +17,7 @@
 #include <asm/sgi/sgi.h>
 #include <asm/sgialib.h>
 #include <asm/bootinfo.h>
+#include <asm/sgi/sgihpc.h>
 
 struct smatch {
     char *name;
@@ -60,9 +61,9 @@
     p = prom_getchild(PROM_NULL_COMPONENT);
     printk("ARCH: %s\n", p->iname);
     mach = string_to_mach(p->iname);
-
+   
     mips_machgroup = mach->group;
-    mips_machtype = mach->type;
+    mips_machtype = !sgi_guiness;
     prom_flags = mach->flags;
 }

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 13 Jan 2000 15:19:22 -0800 (PST)

> there another way to find out sgi system type?  Or is this just not

      It is possible, but only with a database of serial numbers which
is not readily available.  The simple way is to have the kernel export
the value of the "sgi_guiness" variable somehow, presumably via /proc.

---

From: "Andrew R. Baker" <[email-masked]>
Date: Fri, 14 Jan 2000 11:01:03 -0600 (CST)

> I was wondering what the status was of the effort to build a beowulf 

The cluster, named pixel (after a negative attitude towards the original
name), has been up and running for a while now, however we have not
built a web page for it.  Some benchmarks have been run against it, not
by me so I do not know the results.  It is currently configured with eight
nodes.  Currently I am working on finishing up the floating point
exception handling for the kernel so we can run more benchmarks.  I am
looking at the end of the month for that to be complete.  The cluster will
then be put into more of a production enviroment, being used primarily for
research and education.  We are then planning on putting together a four
node cluster to do more benchmarking and testing.  I want to get the 64bit
kernel working on that cluster to see what performance gains it can
achieve.  I also want to use the small cluster to look into kernel based
cluster performance enhancements.  I should also mention that we have
tested pvm, MPI, and DIPC on the cluster, but I do not have any statistics
to quote.

-Andrew

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 14 Jan 2000 13:25:25 +0100

> Here is the patch, I'd like someone with and Indy to try and be sure it

It's ``obviously correct''.  However I'd prefer if somebody would rewrite
the bootinfo.h and /proc stuff in a cleaner, more easy to maintain way.
We've got various modules that want to output information via cpuinfo
like the CPU-info, the second level cache handler and about the board
itself.  So what I want is something where various subsystems that want
to contribute to the /proc/cpuinfo content can register their own routines
when then will be called via get_cpuinfo().

  Ralf