It booooooooooots!

It booooooooooots!

[Mike Shaver]

>> boot -f bootp()neon.ingenia.ca:/vmlinux
Setting $netaddr to 205.207.220.72 (from server neon.ingenia.ca)
Obtaining /vmlinux from server neon.ingenia.ca
PROMLIB: SGI ARCS firmware Version 1 Revision 10
PROMLIB: Total free ram 65208320 bytes (63680K,62MB)
Loading R4000 MMU routines.
CPU REVISION IS: 00002310
Primary ICACHE 32K (linesize 32 bytes)
Primary DCACHE 32K (linesize 32 bytes)
R4600/R5000 SCACHE size 512K linesize 128 bytes
ARCH: SGI-IP22
CPU: MIPS-R5000 FPU<MIPS-R5000FPC> ICACHE DCACHE SCACHE
MC: SGI memory controller Revision 3
calculating r4koff... 000bd678(775800)
zs0: console input
zs0: console I/O
Calibrating delay loop.. ok - 154.83 BogoMIPS
Memory: 60564k/196604k available (792k kernel code, 2988k data)
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.12 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: ICMP, UDP, TCP
Checking for 'wait' instruction...  unavailable.
Linux version 2.0.12 (dm@neteng) (gcc version 2.7.2) #2 Mon Aug 12 04:43:30 PDT6
SGI Zilog8530 serial driver version 1.00
tty00 at 0xbfbd9838 (irq = 21) is a Zilog8530
tty01 at 0xbfbd9830 (irq = 21) is a Zilog8530
PS/2 auxiliary pointing device detected -- driver installed.
WD93: Driver version 1.21 compiled on Aug 12 1996 at 04:20:18
wd33c93-0: chip=WD33c93B microcode=0d
scsi0 : SGI WD93
scsi : 1 host.
Started kswapd v 1.3
  Vendor: SGI       Model: IBM DORS-32160    Rev: W80D
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 1, lun 0
  Vendor: CONNER    Model: CFP2107S  2.14GB  Rev: 172B
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0
scsi : detected 2 SCSI disks total.
SCSI device sda: hdwr sector= 512 bytes. Sectors= 4197405 [2049 MB] [2.0 GB]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 4194304 [2048 MB] [2.0 GB]
sgiseeq.c: David S. Miller (dm@engr.sgi.com)
eth0: SGI Seeq8003 08:00:69:0a:2a:9b
Partition check:
 sda: sda1 sda2 sda3 sda4
 sdb: sdb1 sdb2 sdb3 sdb4
Sending BOOTP and RARP requests............

Doesn't seem to want to find the server again for the NFS root thing,
but that's probably a config problem.

_Now_ we're ready to rock...

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>       Chief System Architect -- Head geek -- System exorcist        
#>                                                                     
#>   "Have you considered a life?  I hear they're quite affordable     
#>          these days." --- shields@tembel.org                        

Re: It booooooooooots!

[William J. Earl]

Mike Shaver writes:
 > >> boot -f bootp()neon.ingenia.ca:/vmlinux
 > Setting $netaddr to 205.207.220.72 (from server neon.ingenia.ca)
 > Obtaining /vmlinux from server neon.ingenia.ca
 > PROMLIB: SGI ARCS firmware Version 1 Revision 10
 > PROMLIB: Total free ram 65208320 bytes (63680K,62MB)
 > Loading R4000 MMU routines.
 > CPU REVISION IS: 00002310
...

    Congratulations -- quick work.

...
 > Checking for 'wait' instruction...  unavailable.
...

     This appears to be a bug.  The R5000 does have the wait instruction.

Re: It booooooooooots!

[Mike Shaver]

Thus spake Alistair Lambie:
> I used to have that...you probably haven't got a rarp server set up, so it
> can't find its address.  One of the things David was going to add was that
> ability to read it out of NVRAM...but that wasn't high on the priority list!
>  For now, the only way is to have a rarp server.

Actually, you can do it with
boot -f bootp()server:/vmlinux nfsaddrs=my.ip.ad.dr:nfs.ip.ad.dr

It mounts it now (I have the NFS daemon running with debugging on so
that I can watch) but it just stops after it looks at tty[4123 -- in
that order].

I'm going to see how the SPARC guys did it; I think it's just a matter
of getting the device entries correct.

> Did you get my root filesystem etc off http://reality.sgi.com/ariel/alambie.
> This should give you the bits you need to get multiuser (init), set up
> networking and mount disks.

Yeah, and that's what I'm using for my root filesystem.
It mounts everything and checks out stuff like /var/log/utmp (!), but
then hangs after it looks at the ttys.

Curious...

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>           Resident Linux bigot and kernel hacker. (OOPS!)           
#> `If you get bitten by a bug, tough luck...the one thing I won't do  
#> is feel sorry for you.  In fact, I might ask you to do it all over  
#> again, just to get more information.  I'm a heartless bastard.'     
#>                       -- Linus Torvalds (on development kernels)    

Re: It booooooooooots!

[Mike Shaver]

Thus spake Alistair Lambie:
> I used to have that...you probably haven't got a rarp server set up, so it
> can't find its address.  One of the things David was going to add was that
> ability to read it out of NVRAM...but that wasn't high on the priority list!
>  For now, the only way is to have a rarp server.

Actually, you can do it with
boot -f bootp()server:/vmlinux nfsaddrs=my.ip.ad.dr:nfs.ip.ad.dr

It mounts it now (I have the NFS daemon running with debugging on so
that I can watch) but it just stops after it looks at tty[4123 -- in
that order].

I'm going to see how the SPARC guys did it; I think it's just a matter
of getting the device entries correct.

> Did you get my root filesystem etc off http://reality.sgi.com/ariel/alambie.
> This should give you the bits you need to get multiuser (init), set up
> networking and mount disks.

Yeah, and that's what I'm using for my root filesystem.
It mounts everything and checks out stuff like /var/log/utmp (!), but
then hangs after it looks at the ttys.

Curious...

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>           Resident Linux bigot and kernel hacker. (OOPS!)           
#> `If you get bitten by a bug, tough luck...the one thing I won't do  
#> is feel sorry for you.  In fact, I might ask you to do it all over  
#> again, just to get more information.  I'm a heartless bastard.'     
#>                       -- Linus Torvalds (on development kernels)    

Re: It booooooooooots!

[William J. Earl]

Alistair Lambie writes:
 > On Apr 9, 10:27am, Mike Shaver wrote:
 > > Subject: It booooooooooots!
 > > Sending BOOTP and RARP requests............
 > >
 > > Doesn't seem to want to find the server again for the NFS root thing,
 > > but that's probably a config problem.
 > >
 > 
 > I used to have that...you probably haven't got a rarp server set up, so it
 > can't find its address.  One of the things David was going to add was that
 > ability to read it out of NVRAM...but that wasn't high on the priority list!
 >  For now, the only way is to have a rarp server.  The other way is to have the
 > root file system on hard disk....but to do that you need to boot linux and copy
 > it across.
 > Kind of the chicken and the egg situation!

     Can you pass the information to the kernel via the command line arguments
or the environment variables?  (argc, argv, and environ are passed in $a0, $a1,
and $a2 by the PROM or sash to the kernel on entry, just as they are passed
to a main program in a regular process; you can look for the "netaddr" environment
variable to find your IP address:

	netaddr=192.111.24.24

Set netaddr at the prom this way:

	setenv -p netaddr 192.111.24.24

Re: It booooooooooots!

[William J. Earl]

Alistair Lambie writes:
 > On Apr 9, 11:38am, William J. Earl wrote:
 > > Subject: Re: It booooooooooots!
 > > Mike Shaver writes:
...
 > >  > Checking for 'wait' instruction...  unavailable.
 > > ...
 > >
 > >      This appears to be a bug.  The R5000 does have the wait instruction.
 > 
 > I don't think David ever worked on an R5000.  The only platforms were R4600 &
 > R4400...soooo, there may be some issues to be resolved.
...

     On an Indy, the R5000 and R4600 are basically equivalent, except
for the MIPS IV extensions and larger caches (32 KB versus 16 KB) on the R5000.
The R5000 does have built-in secondary cache control, which is used on the O2,
but it is not used on the Indy.  On the Indy, the R5000 uses the same off-chip
secondary cache controller as the R4600.  The wait instruction operates the
same on both processors.  The wait instruction is not really essential in any
case, since its main purpose is to save power, and the R5000 and R4600 don't
use much power anyway.

Re: It booooooooooots!

[Ralf Baechle]

> ...
>  > Checking for 'wait' instruction...  unavailable.
> ...
> 
>      This appears to be a bug.  The R5000 does have the wait instruction.

Linux doesn't really check; instead it has encoded which CPU types
have a wait instruction.  I add the R500 to that list.

  Ralf

Re: It booooooooooots!

[Ralf Baechle]

> ...
>  > Checking for 'wait' instruction...  unavailable.
> ...
> 
>      This appears to be a bug.  The R5000 does have the wait instruction.

Linux doesn't really check; instead it has encoded which CPU types
have a wait instruction.  I add the R500 to that list.

  Ralf

Re: It booooooooooots!

[Alistair Lambie]

On Apr 9, 10:27am, Mike Shaver wrote:
> Subject: It booooooooooots!
> Sending BOOTP and RARP requests............
>
> Doesn't seem to want to find the server again for the NFS root thing,
> but that's probably a config problem.
>

I used to have that...you probably haven't got a rarp server set up, so it
can't find its address.  One of the things David was going to add was that
ability to read it out of NVRAM...but that wasn't high on the priority list!
 For now, the only way is to have a rarp server.  The other way is to have the
root file system on hard disk....but to do that you need to boot linux and copy
it across.
Kind of the chicken and the egg situation!

> _Now_ we're ready to rock...
>

Did you get my root filesystem etc off http://reality.sgi.com/ariel/alambie.
This should give you the bits you need to get multiuser (init), set up
networking and mount disks.

Cheers, Alistair

-- 
Alistair Lambie					    alambie@wellington.sgi.com
Silicon Graphics New Zealand				  SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower,				    Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ			  	   Fax: +64-4-802 1459

Re: It booooooooooots!

[Alistair Lambie]

On Apr 9, 11:56am, Mike Shaver wrote:
> Subject: Re: It booooooooooots!
> Thus spake Alistair Lambie:
> > I used to have that...you probably haven't got a rarp server set up, so it
> > can't find its address.  One of the things David was going to add was that
> > ability to read it out of NVRAM...but that wasn't high on the priority
list!
> >  For now, the only way is to have a rarp server.
>
> Actually, you can do it with
> boot -f bootp()server:/vmlinux nfsaddrs=my.ip.ad.dr:nfs.ip.ad.dr
>

Forgot that one!!  It all seems so long ago :-)

> It mounts it now (I have the NFS daemon running with debugging on so
> that I can watch) but it just stops after it looks at tty[4123 -- in
> that order].
>

Have you set up the 'init' environment, or are you just using the plain 'root'
package.  If the later, I seem to remeber that the kernel looks for init, but
doesn't look in the correct place for the shell.  There is a boot argument that
I used to use to get the shell...can't remeber what now, but it was real easy
to find in the kernel source....

Even if you are using init, you might want to just boot the shell first to
track down what is happening!

Cheers

-- 
Alistair Lambie					    alambie@wellington.sgi.com
Silicon Graphics New Zealand				  SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower,				    Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ			  	   Fax: +64-4-802 1459

Re: It booooooooooots!

[William J. Earl]

Ralf Baechle writes:
 > > ...
 > >  > Checking for 'wait' instruction...  unavailable.
 > > ...
 > > 
 > >      This appears to be a bug.  The R5000 does have the wait instruction.
 > 
 > Linux doesn't really check; instead it has encoded which CPU types
 > have a wait instruction.  I add the R500 to that list.

     As far as I know, all QED processors have the "wait" instruction.
All the 0x2???  processor ID values are QED processors.  Here are the current
values:

#define C0_IMP_NEVADA	0x28
#define C0_IMP_RM7000	0x27
#define C0_IMP_MAGIC	0x25
#define C0_IMP_SONIC	0x24
#define	C0_IMP_R5000 	0x23
#define	C0_IMP_R4650 	0x22 
#define	C0_IMP_R4700 	0x21
#define	C0_IMP_R4600 	0x20

I don't know which processors are SONIC, MAGIC, or NEVADA, but I think NEVADA
is the new RM5260 (a low-cost R5000).