serial consoles, sash and other wonders

serial consoles, sash and other wonders

[Mike Shaver]

So damned close we can taste it.
I can tftp the kernel off neon, the bootp server is up (but not tested
-- anyone have a good way to test without a reboot), and we've got a
serial terminal set up.

We've still got to get the console working on the serial line, but we
should be OK with that.

What's got me confused is this, from the archive (I think it's wje's
message):

     On an Indy, the booted kernel (or other program) must be in MIPS
ECOFF format.  On Moosehead, the kernel must be in ELF format.  The
"-coff" option to the IRIX ld will cause it to create an ECOFF binary
instead of an ELF binary in the final link, even if all the input
binaries are in ELF format.  If you want to boot an ELF kernel on
Indy, you have to boot an indirect loader.  You can use the IRIX sash.
Put sash in the volume header on the Indy, or in a bootp-able place on
the host system.

-----

1) Where's sash?  A find / on my Indy didn't turn up anything by that
name.
2) What exactly does `bootp-able' mean?  If I stick it in
/tftpboot/205.207.220.72/sash, does that count?  (The Indy is my only
IRIX box, and I don't have the installation CDs, so I'm somewhat
loathe to go screwing with the disk.)
3) Once I get it booting (pls, pls) will the Linux kernel know how to
talk to the serial console?
4) I've just got the kernel as /tftpboot/205.207.220.72/vmlinux.  DO I
need to add .IP22 or anything?

Any ideas?

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>                   Welcome to the technocracy.
#>                                                                     
#> "you'd be so disappointed
#>              to find out that the magic was not
#>                          really meant for you" - OLP

Re: serial consoles, sash and other wonders

[Ariel Faigon]

Just in case the real experts on this don't answer.
I'll give my 0.02 ...

Check out the following man pages:

dvhtool (1M)            - modify and obtain disk volume header information
vh (7M)                 - disk volume header

sash is hidden in that volume header. In a normal IRIX system,
The ARC PROM boots sash and sash boots /unix.

/unix is ELF (32 or 64 depending on the platform) in every IRIX
since 6.2 (I think). Used to be ECOFF earlier.

sash is ECOFF on Indys and ELF in newer systems as Bill Earl
said. One of the things we need to give you are the sources
for sash, right ?

I'll see what I can do on the sash thing. (Actually was on my
TODO list for a while.)

:
:So damned close we can taste it.
:I can tftp the kernel off neon, the bootp server is up (but not tested
:-- anyone have a good way to test without a reboot), and we've got a
:serial terminal set up.
:
:We've still got to get the console working on the serial line, but we
:should be OK with that.
:
:What's got me confused is this, from the archive (I think it's wje's
:message):
:
:     On an Indy, the booted kernel (or other program) must be in MIPS
:ECOFF format.  On Moosehead, the kernel must be in ELF format.  The
:"-coff" option to the IRIX ld will cause it to create an ECOFF binary
:instead of an ELF binary in the final link, even if all the input
:binaries are in ELF format.  If you want to boot an ELF kernel on
:Indy, you have to boot an indirect loader.  You can use the IRIX sash.
:Put sash in the volume header on the Indy, or in a bootp-able place on
:the host system.
:
:-----
:
:1) Where's sash?  A find / on my Indy didn't turn up anything by that
:name.
:2) What exactly does `bootp-able' mean?  If I stick it in
:/tftpboot/205.207.220.72/sash, does that count?  (The Indy is my only
:IRIX box, and I don't have the installation CDs, so I'm somewhat
:loathe to go screwing with the disk.)
:3) Once I get it booting (pls, pls) will the Linux kernel know how to
:talk to the serial console?
:4) I've just got the kernel as /tftpboot/205.207.220.72/vmlinux.  DO I
:need to add .IP22 or anything?
:
:Any ideas?
:
:Mike
:
:-- 
:#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
:#>                   Welcome to the technocracy.
:#>                                                                     
:#> "you'd be so disappointed
:#>              to find out that the magic was not
:#>                          really meant for you" - OLP
:


-- 
Peace, Ariel

Re: serial consoles, sash and other wonders

[Ariel Faigon]

Just in case the real experts on this don't answer.
I'll give my 0.02 ...

Check out the following man pages:

dvhtool (1M)            - modify and obtain disk volume header information
vh (7M)                 - disk volume header

sash is hidden in that volume header. In a normal IRIX system,
The ARC PROM boots sash and sash boots /unix.

/unix is ELF (32 or 64 depending on the platform) in every IRIX
since 6.2 (I think). Used to be ECOFF earlier.

sash is ECOFF on Indys and ELF in newer systems as Bill Earl
said. One of the things we need to give you are the sources
for sash, right ?

I'll see what I can do on the sash thing. (Actually was on my
TODO list for a while.)

:
:So damned close we can taste it.
:I can tftp the kernel off neon, the bootp server is up (but not tested
:-- anyone have a good way to test without a reboot), and we've got a
:serial terminal set up.
:
:We've still got to get the console working on the serial line, but we
:should be OK with that.
:
:What's got me confused is this, from the archive (I think it's wje's
:message):
:
:     On an Indy, the booted kernel (or other program) must be in MIPS
:ECOFF format.  On Moosehead, the kernel must be in ELF format.  The
:"-coff" option to the IRIX ld will cause it to create an ECOFF binary
:instead of an ELF binary in the final link, even if all the input
:binaries are in ELF format.  If you want to boot an ELF kernel on
:Indy, you have to boot an indirect loader.  You can use the IRIX sash.
:Put sash in the volume header on the Indy, or in a bootp-able place on
:the host system.
:
:-----
:
:1) Where's sash?  A find / on my Indy didn't turn up anything by that
:name.
:2) What exactly does `bootp-able' mean?  If I stick it in
:/tftpboot/205.207.220.72/sash, does that count?  (The Indy is my only
:IRIX box, and I don't have the installation CDs, so I'm somewhat
:loathe to go screwing with the disk.)
:3) Once I get it booting (pls, pls) will the Linux kernel know how to
:talk to the serial console?
:4) I've just got the kernel as /tftpboot/205.207.220.72/vmlinux.  DO I
:need to add .IP22 or anything?
:
:Any ideas?
:
:Mike
:
:-- 
:#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
:#>                   Welcome to the technocracy.
:#>                                                                     
:#> "you'd be so disappointed
:#>              to find out that the magic was not
:#>                          really meant for you" - OLP
:


-- 
Peace, Ariel

Re: serial consoles, sash and other wonders

[William J. Earl]

Mike Shaver writes:
...
 >      On an Indy, the booted kernel (or other program) must be in MIPS
 > ECOFF format.  On Moosehead, the kernel must be in ELF format.  The
 > "-coff" option to the IRIX ld will cause it to create an ECOFF binary
 > instead of an ELF binary in the final link, even if all the input
 > binaries are in ELF format.  If you want to boot an ELF kernel on
 > Indy, you have to boot an indirect loader.  You can use the IRIX sash.
 > Put sash in the volume header on the Indy, or in a bootp-able place on
 > the host system.
 > 
 > -----
 > 
 > 1) Where's sash?  A find / on my Indy didn't turn up anything by that
 > name.

     Usually, it is only installed on the volume header, but you can
extract it into a regular file using dvhtool.  Sometimes you can find
it in /stand.  To extract sash:

<tanoak#1> dvhtool /dev/rvh

Command? (read, vd, pt, dp, write, bootfile, or quit): read
Volume? (/dev/rvh) 

Command? (read, vd, pt, dp, write, bootfile, or quit): vd
(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
	l

Current contents:
	File name        Length     Block #
	sgilabel            512           2
	sash             140800           3
	symmon           245760         278

(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
	g symmon /stand/symmon

(d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
	q

Command? (read, vd, pt, dp, write, bootfile, or quit): quit
<tanoak#2> ls /stand/symmon
-rw-r--r--    1 root     sys       245760 Apr  8 12:26 /stand/symmon


 > 2) What exactly does `bootp-able' mean?  If I stick it in
 > /tftpboot/205.207.220.72/sash, does that count?  (The Indy is my only
 > IRIX box, and I don't have the installation CDs, so I'm somewhat
 > loathe to go screwing with the disk.)

    See the tftpd man page.  The default directory for IRIX tftpd is
/var/boot/, so /var/boot/sash and /var/boot/vmlinux would do for boot files.

    If you don't have the installation CD's, I recommend that you back
up the disk, perhaps to a second disk (complete with volume header and
root partitions), so you can recover from any potential failure.  The
"cp" command in the prom can be used to copy disk to disk to recover.

 > 3) Once I get it booting (pls, pls) will the Linux kernel know how to
 > talk to the serial console?

      I believe that David Miller had that working.  How do you tell linux
to use a serial port as the console (in single-user mode)?  For IRIX,
one does

	setenv -p console d

(for "debug" console, as opposed to the usual "g" for "graphics" console).

 > 4) I've just got the kernel as /tftpboot/205.207.220.72/vmlinux.  DO I
 > need to add .IP22 or anything?

      If you put sash and vmlinux in /var/boot, then do

	boot -f bootp()bootphost:sash

from the PROM, where bootphost is the hostname of your IRIX system, and then

	boot -f bootp()bootphost:vmlinux

from sash, all should be well.  Note that you can boot an ELF kernel directly
from the PROM on an Indy with a newer PROM image (such as the PROM for an 
Indy R5000 system), so try that first.  If it works, your Indy has the newer
PROM, and you can forget about sash.

     By the way, it is pretty easy to write a little program to convert
a kernel ELF binary to an ECOFF binary, discarding most of the symbols and
other stuff, assuming you have the header files for the file formats.
(The result would not be acceptable to many of the tools, such as dbx,
but it would be bootable.)

     For a production linux for the Indy, the most reasonable approach,
however, would be to make silo or whatever boot program you are using be
ECOFF, so that old PROMs are supported.

Re: serial consoles, sash and other wonders

[Mike Shaver]

Thus spake William J. Earl:
> <tanoak#1> dvhtool /dev/rvh
> (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
> 	g symmon /stand/symmon
> (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
> 	q
> <tanoak#2> ls /stand/symmon
> -rw-r--r--    1 root     sys       245760 Apr  8 12:26 /stand/symmon

_Cool_.

>  > 2) What exactly does `bootp-able' mean?  If I stick it in
> 
>     See the tftpd man page.  The default directory for IRIX tftpd is
> /var/boot/, so /var/boot/sash and /var/boot/vmlinux would do for boot files.

OK, that's what I thought.  I just wanted to make sure I was on the
right track when I read `bootp-able' as `tftpable in the right dir'.

>     If you don't have the installation CD's, I recommend that you back
> up the disk, perhaps to a second disk (complete with volume header and
> root partitions), so you can recover from any potential failure.  The
> "cp" command in the prom can be used to copy disk to disk to recover.

That I will do.
Will that work with differently-sized drives?

> [if I boot with serial console, will Linux use that?]
>       I believe that David Miller had that working.  How do you tell linux
> to use a serial port as the console (in single-user mode)?

Ugh.
On Intel, you have to use a patch.
On the SPARC, you just have to set things up right in /dev.
I shall hope that it's SPARC-ish on the Indy and poke around for good
instructions on that.  (I shall also hedge my bets and copy DaveM on
this message. =) )

> from sash, all should be well.  Note that you can boot an ELF kernel directly
> from the PROM on an Indy with a newer PROM image (such as the PROM for an 
> Indy R5000 system), so try that first.  If it works, your Indy has the newer
> PROM, and you can forget about sash.

I've got an R5K, so that'll make things easier.

>      For a production linux for the Indy, the most reasonable approach,
> however, would be to make silo or whatever boot program you are using be
> ECOFF, so that old PROMs are supported.

I think that's the plan.

I'm having some trouble with the serial console, though.
I did an `nvram console d' and that took, but I fear that I've got to
set something else, since my serial cable is connected to port 2.  The
getty I'm running on ttyd2 works fine, FWIW.

When I reboot, I get nothing on the serial console until the getty
login: prompt.

(I can't think off the top of my head as to why I'm using that port,
but I think it had something to do with the available cabling.  I'm
not physically with the machine until 1400 EST tomorrow, but Josh
should feel free to step forward and explain it. =) )

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>      Chief System Architect -- will tame sendmail(8) for food       
#>                                                                     
#> "You are a very perverse individual, and I think I'd like to get to 
#>  know you better." --- eric@reference.com                           

Re: serial consoles, sash and other wonders

[Mike Shaver]

Thus spake William J. Earl:
> <tanoak#1> dvhtool /dev/rvh
> (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
> 	g symmon /stand/symmon
> (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)?
> 	q
> <tanoak#2> ls /stand/symmon
> -rw-r--r--    1 root     sys       245760 Apr  8 12:26 /stand/symmon

_Cool_.

>  > 2) What exactly does `bootp-able' mean?  If I stick it in
> 
>     See the tftpd man page.  The default directory for IRIX tftpd is
> /var/boot/, so /var/boot/sash and /var/boot/vmlinux would do for boot files.

OK, that's what I thought.  I just wanted to make sure I was on the
right track when I read `bootp-able' as `tftpable in the right dir'.

>     If you don't have the installation CD's, I recommend that you back
> up the disk, perhaps to a second disk (complete with volume header and
> root partitions), so you can recover from any potential failure.  The
> "cp" command in the prom can be used to copy disk to disk to recover.

That I will do.
Will that work with differently-sized drives?

> [if I boot with serial console, will Linux use that?]
>       I believe that David Miller had that working.  How do you tell linux
> to use a serial port as the console (in single-user mode)?

Ugh.
On Intel, you have to use a patch.
On the SPARC, you just have to set things up right in /dev.
I shall hope that it's SPARC-ish on the Indy and poke around for good
instructions on that.  (I shall also hedge my bets and copy DaveM on
this message. =) )

> from sash, all should be well.  Note that you can boot an ELF kernel directly
> from the PROM on an Indy with a newer PROM image (such as the PROM for an 
> Indy R5000 system), so try that first.  If it works, your Indy has the newer
> PROM, and you can forget about sash.

I've got an R5K, so that'll make things easier.

>      For a production linux for the Indy, the most reasonable approach,
> however, would be to make silo or whatever boot program you are using be
> ECOFF, so that old PROMs are supported.

I think that's the plan.

I'm having some trouble with the serial console, though.
I did an `nvram console d' and that took, but I fear that I've got to
set something else, since my serial cable is connected to port 2.  The
getty I'm running on ttyd2 works fine, FWIW.

When I reboot, I get nothing on the serial console until the getty
login: prompt.

(I can't think off the top of my head as to why I'm using that port,
but I think it had something to do with the available cabling.  I'm
not physically with the machine until 1400 EST tomorrow, but Josh
should feel free to step forward and explain it. =) )

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>      Chief System Architect -- will tame sendmail(8) for food       
#>                                                                     
#> "You are a very perverse individual, and I think I'd like to get to 
#>  know you better." --- eric@reference.com                           

Re: serial consoles, sash and other wonders

[William J. Earl]

Mike Shaver writes:
 > Thus spake William J. Earl:
...
 > >     If you don't have the installation CD's, I recommend that you back
 > > up the disk, perhaps to a second disk (complete with volume header and
 > > root partitions), so you can recover from any potential failure.  The
 > > "cp" command in the prom can be used to copy disk to disk to recover.
 > 
 > That I will do.
 > Will that work with differently-sized drives?

     Yes, but the drive to which you copy the data will have to be bigger,
but it will then not appear to be any larger than the original drive.
That is, the partition table in the volume header will claim that the
second drive is really the same size as the original drive.  This is of
course ok if you only want the extra drive as a backup.

...
 > I'm having some trouble with the serial console, though.
 > I did an `nvram console d' and that took, but I fear that I've got to
 > set something else, since my serial cable is connected to port 2.  The
 > getty I'm running on ttyd2 works fine, FWIW.

      Yes, you really need two serial lines, one for the console (port 1,
ttyd1) and one for the debug port (port 2, ttyd2).  At least, that is the
way I control my test system from my host system.  Here, we usually use
an Annex Ethernet-based serial concentrator for serial ports, and connect
via telnet (or the Annex rtelnetd) to the serial ports, which are then
wired to the test machines.  

 > When I reboot, I get nothing on the serial console until the getty
 > login: prompt.
 >
 > (I can't think off the top of my head as to why I'm using that port,
 > but I think it had something to do with the available cabling.  I'm
 > not physically with the machine until 1400 EST tomorrow, but Josh
 > should feel free to step forward and explain it. =) )

       The PROM talks only to port 1, so you are seeing what I would
expect.

Re: serial consoles, sash and other wonders

[William J. Earl]

Mike Shaver writes:
 > Thus spake William J. Earl:
...
 > >     If you don't have the installation CD's, I recommend that you back
 > > up the disk, perhaps to a second disk (complete with volume header and
 > > root partitions), so you can recover from any potential failure.  The
 > > "cp" command in the prom can be used to copy disk to disk to recover.
 > 
 > That I will do.
 > Will that work with differently-sized drives?

     Yes, but the drive to which you copy the data will have to be bigger,
but it will then not appear to be any larger than the original drive.
That is, the partition table in the volume header will claim that the
second drive is really the same size as the original drive.  This is of
course ok if you only want the extra drive as a backup.

...
 > I'm having some trouble with the serial console, though.
 > I did an `nvram console d' and that took, but I fear that I've got to
 > set something else, since my serial cable is connected to port 2.  The
 > getty I'm running on ttyd2 works fine, FWIW.

      Yes, you really need two serial lines, one for the console (port 1,
ttyd1) and one for the debug port (port 2, ttyd2).  At least, that is the
way I control my test system from my host system.  Here, we usually use
an Annex Ethernet-based serial concentrator for serial ports, and connect
via telnet (or the Annex rtelnetd) to the serial ports, which are then
wired to the test machines.  

 > When I reboot, I get nothing on the serial console until the getty
 > login: prompt.
 >
 > (I can't think off the top of my head as to why I'm using that port,
 > but I think it had something to do with the available cabling.  I'm
 > not physically with the machine until 1400 EST tomorrow, but Josh
 > should feel free to step forward and explain it. =) )

       The PROM talks only to port 1, so you are seeing what I would
expect.

Re: serial consoles, sash and other wonders

[Ralf Baechle]

Hi,

>      By the way, it is pretty easy to write a little program to convert
> a kernel ELF binary to an ECOFF binary, discarding most of the symbols and
> other stuff, assuming you have the header files for the file formats.
> (The result would not be acceptable to many of the tools, such as dbx,
> but it would be bootable.)
> 
>      For a production linux for the Indy, the most reasonable approach,
> however, would be to make silo or whatever boot program you are using be
> ECOFF, so that old PROMs are supported.

I also have to deal with ARC machines (the little endian NT stuff).  By
definiton they have to support ECOFF; everything else is optional.  This
brings in the extra issue that the loader needs to be relocatable.
MIPS-ECOFF configurations of GCC can't do that and the linker dies when
loading ELF PIC code into an ECOFF executable.  Unfortunately fixing is
nontrivial.

The {Net,Open}BSD people already have a converter tool which they use to
generate their kernel executable.  It would solve the ld problems.
I did some work on it and I should probably finish it ...

  Ralf

Re: serial consoles, sash and other wonders

[Ralf Baechle]

Hi,

>      By the way, it is pretty easy to write a little program to convert
> a kernel ELF binary to an ECOFF binary, discarding most of the symbols and
> other stuff, assuming you have the header files for the file formats.
> (The result would not be acceptable to many of the tools, such as dbx,
> but it would be bootable.)
> 
>      For a production linux for the Indy, the most reasonable approach,
> however, would be to make silo or whatever boot program you are using be
> ECOFF, so that old PROMs are supported.

I also have to deal with ARC machines (the little endian NT stuff).  By
definiton they have to support ECOFF; everything else is optional.  This
brings in the extra issue that the loader needs to be relocatable.
MIPS-ECOFF configurations of GCC can't do that and the linker dies when
loading ELF PIC code into an ECOFF executable.  Unfortunately fixing is
nontrivial.

The {Net,Open}BSD people already have a converter tool which they use to
generate their kernel executable.  It would solve the ld problems.
I did some work on it and I should probably finish it ...

  Ralf