boot problem
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: 0x8800250cnewport_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
:
: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.
Signature · 1 line
Peace, Ariel
->
->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 protected], [email protected], [email protected]
--------------------------------------------------------------------------
Life is a comedy to those that think, a tragedy to those that feel.
Quoted 14 lines
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:0x8800250cnewport_probe: read back wrong value ;-(
Quoted 7 lines
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 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
Quoted 2 lines
I'm working with a Challenge S, R5000 (Allegedly the same hardware as an Indy without a graphics card)
Nod
Quoted 1 line
What is the
newport_probe? The only non-stock thing about
The graphics card..
Quoted 14 lines · William Ellis
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:0x8800250cnewport_probe: read back wrong value ;-(
Quoted 6 lines
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
A MAJOR difference in the ChallengeS is that it has differential SCSI controllers as well as the Indy SingleEnded controller.
Signature · 14 lines
---------1---------2---------3---------4---------5---------6---------7---------8 Eric Kimminau RTA/RSA [email protected] 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?"
Quoted 13 lines · William Ellis
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:0x8800250cnewport_probe: read back wrong value ;-(
Quoted 5 lines
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?
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
[email protected] writes:
...
Quoted 11 lines
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.
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.
Quoted 3 lines
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?
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.
Quoted 7 lines · William J. Earl
Quoted 6 lines
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.
Quoted 6 lines
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.
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
Quoted 16 lines · [email protected] writes:
Quoted 7 lines · William J. Earl
Quoted 6 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
...
Yes, that is correct. Also, it means that the system will
come up with a serial console if the graphics board is completely dead.