[Top] [All Lists]

Re: Linux-mips

To: Paul Antoine <>
Subject: Re: Linux-mips
From: Thomas Riemer <>
Date: Wed, 24 Jan 1996 09:48:46 +0000
Cc: Linux MIPS mailing list <>
In-reply-to: <>
I might be able to give you a definitive answer as to whether the 3100s
support tftp as well...

I happen to work in a place where I have a 3100 sitting in front of me
most days.  As long as its safe for the machine to boot the kernel - i.e.
it doesn't trash the hard disk - and I can get back to my previous config
I should be able to test that as well.

Of course, finding a bootp server at the company might be a bit more 
difficult - but doable.   Tomorrow night - assuming the cold that I 
seem to have contracted in the past 24 hours doesn't keep me in bed 
for tomorrow.  We'll see.


On Thu, 25 Jan 1996, Paul Antoine wrote:

> Tom,
> (I'm cc'ing this to the linux-mips mailing list, as it has info of
> general interest.)
> > The good news is that the 2100 does support tftp booting...
> > in a very similar fashion.
> > 
> > the command I used was:
> > boot -f tftp(0,6)/data/tftpd/dec_vmlinux
> > 
> > Where 0,6 refer to controller, and device
> > and /data/tftpd/dec_vmlinux is the full path to the kernel.
> Great - we should add it to the document.
> > And this time, I must point out that there is no Appendix F at all.
> > It was pretty much a pure guess.  No docs at all. 
> Great work!  I personally find this kind of hacking very satisfying... :-)
> > The bad news is that the kernel seems to dump core...
> Bum!
> > The error I got was first was at the end of the checksum stuff:
> >
> > 409824+103760+72304-47c xfer addr: 0x80030000
> > 
> > Exceptn: <vtr=UTLBM>
> > Exceptn PC: 0x0
> > CReg      : 0x8 < CE=0, EXC=RMISS>
> > SReg      : 0x30080000 < CU1, CU0, CM, IPL=8>
> > VAddr     : 0x0
> > Sp        0xa0ffc000
> > 
> >   And then the dump of the stack which was all zeros.
> Hmmm... I wonder what the load address is for Ultrix kernals on the
> 2100's... I'll check the docs and MACH code to see if there are any
> hints of whether the 2100 memory architecture is any different from
> the 5000's.
The one major difference that I noted in my reading of MIPS RISC Architecture
to date was:

   " The CPU normally operates in User mode until an exception is detected
forcing it into Kernel mode.  It remains in Kernel mode until a Restore
from Exception (RFE) instruction is executed (the R4000 uses the ERET 
instruction.)."  (P. 218)

> The only other thing I can think of is this: Does the boot prom on the
> 2100's provide the same BIOS-like functions as are supported on the
> 5000's prom ('cos one of the first things I do is print out a message
> to the console using such services). Again I'll check the MACH code.
Where would I look to find the docs - Hardware manual?

> Anyway, you've certainly advanced the DECStation Linux-mips cause!  We
> now have reason to suspect that the 3100's will also be able to use
> tftp (as I believe the 3100 is essentially a 2100 with an R3000).

> It'd be great if you could add your info to the tftp document and send
> it to me so I can put it up on my web pages and pass it on to Luc.
Here you GO:

                Booting a DecStation via bootp/tftp

            Paul M. Antoine 12/11/95 (DecStation 5000/2x)

               Updated Triemer 1/23/96 (DecStation 2100)

The DECStation 5000 Harware Operator's manual hints at the ability to 
boot with bootp/tftp on  page 6 of Appendix F of the User's Guide.  
It is, however, very vague about how to set this up.  These notes are 
intended to clarify this method of booting.

After booting a decstation, depending on your configuration, you will
automatically be dumped to a prompt ">>" or not.  If not, a control C
will usually do the job.  If this does not do the job, there is a reset
jumper on the board the for the 5000.

Assuming that you have reached the Boot Prom prompt ">>", the commands
depend on the version of DECStation that is being used:

For DecStations 5000

  The normal console command for booting a Personal DECStation 5000/2x
  is something like this:

        boot 3/rz0/vmunix -a

  The "3/rz0/vmunix -a" portion of the string can also be stored in the
  'boot' environment variable to allow auto-booting.

For DecStation 2100
  The normal console command for booting a Personl DECStation 2100 
  is something like this:
       boot -f rz(0,1)vmunix

  The "rz(0,1)vmunix portion of the string can also be stored in the
  bootpath environment variable to allow auto-booting. The -f is a
  flag to indicate that what follows is a file specification.
  The numbers in paranthesis refer to controller and device.

The DecStation 5000 Hardware User's Guide states that there are 
two alternatives to the stanard boot command, namely:

        boot 3/tz5
        boot 3/mop
It does not mention the tftp option in Chapter 11 (page 10), where one might
expect to find such a mention. 

The DecStation 2100 Hardware Users's Guide states that there are
two alternates as well

        boot -f tz(0,5)
        boot -f mop()

Here, we  will concentrate on the second on the option that the manual barely 
alludes to:  Boting with bootp/tftp

Booting with bootp/tftp:

The manual doesn't mention much of the specifics of booting using the
tftp protocol, but when you issue the command:

        boot 3/tftp/vmunix -a                      (DecStation 5000)
        boot -f tftp(0,6)/datapath/vmunix          (DecStation 2100)

The DECStation sends out a bootp request first, an arp request after
that, and finally is able to initiate a tftp session to load the file.
There are, however, some tricks to this.

First you need to configure bootpd on your Linux box so that it will
respond to the request.  Most Linux setups I've seen are reasonably
configured in inetd.conf so that inetd will start the bootpd daemon,
but the bootptab file will probably need some work.  Here's my example
bootptab file:

        # First, define a global entry which specifies the stuff
        # every host uses.
        # Define all individual entries.
        # hostname:ht=1:ha=ether_addr_in_hex:ip=ip_addr_in_dec:tc=allhost:

The bootpd manual entry is quite good, so refer to that for the
meaning of most of the tags, though I will explain a few of them:

        ha:     is host ethernet address, get this by copying down
                what you see when you type 'cnfg' at the monitor
                prompt on the DECStation.
        ip:     the IP address you want to assign the DECStation
        hd:     the directory where boot files can be found
        bf:     the boot file.  I've set this to 'null' in the
                'allhost' definition so that I can specify the file on
                the monitor command line.  You may in fact want to use
                a specific file for testing, rather than having to
                type in a boot command line on the DEC all the time.

I found that even though I specified both an IP address and an
ethernet address to bootpd, the copy of bootpd I have was unable to
add an arp entry for it.  I therefore had enter one manually, using
the following:

        arp -s 08:00:2B:2D:90:C0

[triemer comment] This seems to have been fixed as I did not need to do this.
[triemer]I used bootp 
[triemer]<A HREF="";>
[triemer]Version 2.4.</A>
[triemer]I believe there is a kernel configuration that
[triemer] needs to be enable on the Linux kernel and this is 
[triemer]done automatically that it the Linux machine responds when the DEC boot monitor
ethernet code does an arp request to find it's IP address before
initiating the tftp transfer.  <sigh>

Note that this may have been fixed in newer copies of bootpd (mine's a
couple of years old from an ancient Debian release and I suspect a
library problem).

Tricks & Traps:

Having set all the above up on the Linux host, it's now time to try a
remote boot with a command at the DEC boot monitor prompt.  Try this:

        boot 3/tftp/vmunix

Now, assuming you copied vmunix (I used a copy of Ultrix for testing)
to the /home/mips/decstation directory, you would presume that this
command would load it.  But no, as you'll see if you run bootpd in
debug mode, in fact it tried to load /vmunix (i.e. an absolute path!).

O.K., we next try:

        boot 3/tftp vmunix

Nope, we get FNF? as a response (i.e. file not found).  So then we

        boot 3/tftpvmunix

No again, now the boot monitor is confused about the name of the
script to use, because it uses the / as both a seperator, AND sends it
as part of the filename! <sigh>

It seems that the only way around this is to specify the file in the
bootptab using the bf tag, so you can issue:

        boot 3/tftp

and have it grab the right file, OR you must specify the entire path
in the boot command, e.g.:

        boot 3/tftp/home/mips/decstation/vmunix

[triemer comment] On the Decstation 2100, the full command is 
[triemer]  boot -f tftp(#controller,#device)fullpathname.
[triemer]So on my 2100... the command is 
[triemer] boot -f tftp(0,6)/data/tftpd/dec_vmlinux

[triemer comment] The alternative for the 5000 is to give the bootpath
[triemer]in the bootptab file using the hd= tag.   So for example,
[triemer]my bootptab looks like this:
[triemer]        :bf=dec_vmlinux:\
[triemer]        :hd=/data/tftpd:\        
[triemer]        :sa=\
[triemer]        :hn:ip=\
[triemer]        :ds=\
[triemer]        :gw=\
[triemer]        :sm=
[triemer]Note the line bf=dec_vmlinux.  The tab bf is the bootfile. 
[triemer]Note the line hd=/data/tftpd.This is my full path on the host machine.
[triemer]In fact, what this means is that you can actually make the command
[triemer]to boot even cleaner.  "boot 3/tftp" does the job on the 5000
[triemer]Sadly, the 2100 is not quite so fortunate. Here the full path is
[triemer]necessary "boot -f tftp(0,6)/data/tftpd/dec_vmlinux

However, if anyone else figures out how to give the boot monitor a
relative filename, *please* let me know.

Paul M. Antoine (

> A note on R2000 support - I have tried to make all my code work on
> both R2000 and R3000, so with any luck you won't have to deal with
> many of those issues.  The main ones will be support for the various
> hardware devices on 2100/3100 machines, many of which will hopefully
> be very similar to the 5000's.
> I finished patching my code into the 1.3.58 kernel last night, so now
> all I need do is attempt a compile and clean up the mess that will no
> doubt ensue! :-)

BTW, I haven't received anything back from my mail sent to
about joining the linux-mips mailing list.  Is this information
accurate... (Am I just being a bit impatient or what? - smack if I'm
being obnoxious)

---- Where theory and reality meet. 
---- Thomas Riemer,

<Prev in Thread] Current Thread [Next in Thread>