Subject: boot problem

From: William Ellis <[email-masked]>
Date: Wed, 14 Jan 1998 15:50:22 -0800

I'm working with a Challenge S, R5000 (Allegedly the same
hardware as an Indy without a graphics card)

Initially booting via tftp with various errors, I am
now trying to just get the sash boot -f to work.
I have tried several of the applicable precompiled kernels 
at ftp.linux.sgi.com/pub/test all with similar errors:

Standalone Shell SGI Version 6.2 ARCS   Mar  9, 1996 (32 Bit)
sash: boot -f /vmlinux root=/dev/sda1
1278928+236160 entry: 0x8800250c
newport_probe: read back wrong value ;-(

What is the newport_probe?  The only non-stock thing about
the machine is it has a fddi card in it, (which I do not
need to get going for linux).  Could this error be an effect
of the fddi card being present, or that there is no graphics
card present?  Or am I missing something else all together?
Thanks in Advance, Bill

---

From: [email-masked] (Ariel Faigon)
Date: Wed, 14 Jan 1998 15:55:29 -0800 (PST)

:
:I'm working with a Challenge S, R5000 (Allegedly the same
:hardware as an Indy without a graphics card)
:
:Initially booting via tftp with various errors, I am
:now trying to just get the sash boot -f to work.
:I have tried several of the applicable precompiled kernels 
:at ftp.linux.sgi.com/pub/test all with similar errors:
:
:Standalone Shell SGI Version 6.2 ARCS   Mar  9, 1996 (32 Bit)
:sash: boot -f /vmlinux root=/dev/sda1
:1278928+236160 entry: 0x8800250c
:newport_probe: read back wrong value ;-(
:
:What is the newport_probe?  The only non-stock thing about
:the machine is it has a fddi card in it, (which I do not
:need to get going for linux).  Could this error be an effect
:of the fddi card being present, or that there is no graphics
:card present?  Or am I missing something else all together?
:Thanks in Advance, Bill
:
Newport == Indy graphics

So I guess the code should be changed so it doesn't assume
there's a newport hardware.

-- 
Peace, Ariel

---

From: Shrijeet Mukherjee <[email-masked]>
Date: Wed, 14 Jan 1998 15:58:15 -0800 (PST)

->
->What is the newport_probe?  

newport is the internal name for indy graphics .. and u are missing one
;-)

--
--------------------------------------------------------------------------
Shrijeet Mukherjee,    			Member of Technical Staff (MTS)
					Advanced Graphics Division 
                     			Silicon Graphics Computer Systems

http://reality.sgi.com/shm_engr     	phone: 650-933-5312
email: [email-masked], [email-masked], [email-masked]
--------------------------------------------------------------------------
Life is a comedy to those that think, a tragedy to those that feel.

---

From: [email-masked] (Charles Marker)
Date: Wed, 14 Jan 1998 16:00:39 -0800 (PST)

> card present?  Or am I missing something else all together?

Newport is the name of the graphics on Indy systems which is removed
on Challenge S systems.  As I mentioned previously, I believe that
Challenge S systems also have the ISDN and AV hardware removed.  One
difference which I forgot to mention the other day was that the
Challenge S has a car which plugs into the newport spot and provides
extra ethernets and differential SCSI (WD95 I believe).  I believe
that the SCSI controller on the system board is still WD93.

					Charles

---

From: Eric Kimminau <[email-masked]>
Date: Wed, 14 Jan 1998 19:11:17 -0500

> card present?  Or am I missing something else all together?

A MAJOR difference in the ChallengeS is that it has differential SCSI
controllers as well as the Indy SingleEnded controller.

-- 
---------1---------2---------3---------4---------5---------6---------7---------8
Eric Kimminau                           RTA/RSA
[email-masked]                     Silicon Graphics, Inc
Voice: (248) 848-4455                   39001 West 12 Mile Rd.
Fax:   (248) 848-5600                   Farmington, MI 48331-2903

                 VNet Extension - 6-327-4455
              "I speak my mind and no one else's."
       http://www.dcs.ex.ac.uk/~aba/rsa/perl-rsa-sig.html

    When confronted by a difficult problem, solve it by reducing 
    it to the question, "How would the Lone Ranger handle this?"
	
         "I am the great supportfolio, do you have http?"

---

From: [email-masked]
Date: Thu, 15 Jan 1998 01:26:22 +0100

> card present?  Or am I missing something else all together?

No, the FDDI card is just being ignored by Linux.  The problem is
indeed the fact that the newport GFX card isn't installed.  I'll
take a look at it when I have time for more than one breath
per minute ...

Thinking about it, the kernel should only try to touch the gfx hardware
at all, if the ARC environment variable ``console'' is unset.  If you
want to run from a serial console, then the variable's value should be
either ``d1'' or ``d2'' for the first rsp. second serial interface.
I suppose IRIX just defaults to serial console because it knows that
a Challenge S is headless or after a failed probe for gfx hardware.

William, what is the recommended way to recognice whethere a machine
is a Indy or Challenge S?  Probing for a GFX card or checking via
ARC firmware?

  Ralf

---

From: [email-masked] (Alan Cox)
Date: Thu, 15 Jan 1998 00:34:14 +0000 (GMT)

> hardware as an Indy without a graphics card)

Nod

> What is the newport_probe?  The only non-stock thing about

The graphics card..

---

From: "William J. Earl" <[email-masked]>
Date: Wed, 14 Jan 1998 16:56:38 -0800

[email-masked] writes:
...
 > a Challenge S is headless or after a failed probe for gfx hardware.

     IRIX probes for the graphics card.  If the probe fails, it
assumes this is not one.  If there is no graphics, or if console != g,
it sets the system console to the serial port.  Note, however, that
IRIX normally puts up an X login on the graphics head even if
console=d and thus the console is on the serial port.  This seems
like a reasonable approach for linux as well.

 > is a Indy or Challenge S?  Probing for a GFX card or checking via

       I would probe for the graphics card.  If you try to fetch
from the configuration register and get a bus error, or if the
returned value is wrong, assume no graphics. 

       You can check that you can read from the first register
location (0x1f0f0000); if there is a bus error, there is no graphics.
Then check that the GFXBUSY bit (0x8) in the status register at 
0x1f0f1338 turns off within about 300 ms.  The IRIX driver also
does this to check that the card is alive:

	/*
	 * Write an int into the 16-bit xstarti register.
	 * Read it back from the fixed-point xstartf register.
	 * The format is 16 bits of integer, 4 bits of fraction,
	 * all << 7.  In this case, the fraction is 0, so we expect
	 * to read (0x12348765 & 0xffff) << 11.
	 */

	rex3->set.xstarti = 0x12348765;
	if ( rex3->set._xstart.word == ((0x12348765 & 0xffff) << 11) ) {
		ng1_probed[index] = NG1_FOUND;
		return 1;
	}

set.xstarti is 0x1f0f0148 and set._xstart.word is 0x1f0f0100.

---

From: [email-masked]
Date: Thu, 15 Jan 1998 06:15:19 +0100

> like a reasonable approach for linux as well.

Indeed, this is how Linux will behave after the probe / console env
thing is fixed.  I assume your more than minimal necessary probe has the
purpose to make shut that the machine does not only have gfx but also
that the gfx found in the address space is not something else like the
XZ for example?

William Ellis: could you try to set the ARC environment variable ``console''
to d1 / d2 according to the port you're using and run the kernel you've
tested once again?

  Ralf

---

From: "William J. Earl" <[email-masked]>
Date: Wed, 14 Jan 1998 22:10:45 -0800

...

      Yes, that is correct.  Also, it means that the system will
come up with a serial console if the graphics board is completely dead.