openadk/package/aboot/src/doc/faq/SRM-HOWTO.sgml

<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">

<!-- <!DOCTYPE Article PUBLIC "-//Davenport//DTD DocBook V3.0//EN"> -->

<Article id="index">

<articleinfo>

<Title>SRM Firmware Howto</Title>

<authorgroup>
<AUTHOR>
<firstname>Rich</firstname> <surname>Payne</surname>
<affiliation><address><email>rdp@alphalinux.org</email></address></affiliation>
</AUTHOR>
<!-- and -->
<AUTHOR>
<firstname>David</firstname> <surname>Huggins-Daines</surname>
<affiliation><address><email>dhuggins@linuxcare.com</email></address></affiliation>
</AUTHOR>
</authorgroup>

<PubDate>v0.8.1, 14 February 2004</PubDate>

<Abstract>
<Para>
This document describes how to boot Linux/Alpha using the SRM console,
which is the console firmware also used to boot 
<productname>HP Tru64 Unix</productname>
(also known as <productname>Digital Unix</productname> and <productname>OSF/1</productname>) and <productname>OpenVMS</productname>.
</Para>
</Abstract>

</articleinfo>

<Sect1 id="SRM-about">
<Title>About this manual</Title>

<Sect2>
<Title>Who should read this manual</Title>

<Para>
You should read this manual if you are installing Linux on a new
Alpha system that can only boot from the SRM console, or if you are
installing Linux on an older Alpha system that can use the SRM console
and wish to use SRM to boot your Linux installation.
</Para>

<Para>
Because SRM is the only way to boot Linux on modern Alpha systems,
and because it provides the proper operating environment for Unix and
Unix-like operating systems (such as Linux), it is the recommended way
of booting Linux on Alpha when available.
</Para>

<Para>
Sometimes, it is preferable to use the ARC, ARCSBIOS, or AlphaBIOS
console, such as if you have a machine for which SRM is not available,
if you wish to dual-boot with <productname>Windows NT</productname>
without switching consoles,
or if you have hardware that is not supported by SRM.  On these
machines, you will typically use MILO to boot Linux.  For more
information, refer to the MILO Howto, available from
<ULink URL="http://www.alphalinux.org/faq/milo.html">http://www.alphalinux.org/faq/milo.html</ULink>.
</Para>

</Sect2>

<Sect2>
<Title>Conventions</Title>

<Para>
Throughout this manual, we will use the following conventions for
commands to be entered by the user:
</Para>

<Para>
SRM console commands will be shown with the characteristic SRM
'&#62;&#62;&#62;' prompt, like this: 
<FOOTNOTE>

<Para>
On multiprocessor machines, you
will see 'P00&#62&#62;' instead, or possibly some other number depending on
which processor SRM is running. 
</Para>

</FOOTNOTE>


<Screen>
&#62;&#62;&#62; boot dva0 -fi linux.gz -fl "root=/dev/fd0 load_ramdisk=1"
</Screen>

</Para>

<Para>
Unix commands will be shown with the '&num;' command prompt if they are
to be run as <Literal remap="tt">root</Literal>, or '$' if they are to be run by a normal user,
like this:

<Screen>
# swriteboot -f3 /dev/sda /boot/bootlx
</Screen>

</Para>

<Para>
Aboot commands will be shown with the 'aboot&#62;' command prompt, like
this:

<Screen>
aboot&#62; b 6/boot/vmlinuz root=/dev/hda6
</Screen>

</Para>

</Sect2>

</Sect1>

<Sect1 id="SRM-whatis">
<Title>What is SRM?</Title>

<Para>
SRM console is used by Alpha systems as
Unix-style boot firmware. <productname>Tru64 Unix</productname> and
<productname>OpenVMS</productname> depend on it and
Linux can boot from it. You can recognize SRM console as a blue screen
with a prompt that is presented to you on power-up.
</Para>

<Sect2>
<Title>Getting to SRM</Title>

<Para>
Most Alpha systems have both the SRM and ARC/AlphaBIOS console in
their firmware.  On one of these machines, if your machine starts up
with ARC/AlphaBIOS by default, you can switch to SRM through the
"<guimenuitem>Console Selection</guimenuitem>" option in the Advanced CMOS Setup menu.  To make <!-- FIXME Markup should do the marking -->
the change permanent, you should set the <Literal remap="tt">os&lowbar;type</Literal> environment
variable in SRM to "OpenVMS" or "Unix", like this:

<Screen>
&#62;&#62;&#62; set os_type Unix
</Screen>

</Para>

<Para>
Either one will work to boot Linux.  However, if you intend to
dual-boot OpenVMS on this machine, you must set <Literal remap="tt">os&lowbar;type</Literal> to
"OpenVMS".  Conversely, to return to ARC/AlphaBIOS, you can set
<Literal remap="tt">os&lowbar;type</Literal> to "NT".
</Para>

<Para>
Some older systems may not have both SRM and ARC in firmware as
shipped.  On these systems, you will have to upgrade your firmware.
See <ULink
URL="http://ftp.digital.com/pub/DEC/Alpha/firmware/"
>http://ftp.digital.com/pub/DEC/Alpha/firmware</ULink
> for the 
latest firmware updates and instructions.
</Para>

<Para>
A few older systems (primarily evaluation boards such as the 164SX
and 164LX) are "half-flash" systems, whose firmware can hold SRM or
AlphaBIOS, but not both.  If you have one of these machines, you will
have to reflash your firmware with the SRM console using the AlphaBIOS
firmware update utility.  Again, see
<ULink
URL="http://ftp.digital.com/pub/DEC/Alpha/firmware/"
>http://ftp.digital.com/pub/DEC/Alpha/firmware</ULink
> for firmware
images and instructions.  If you wish to return to AlphaBIOS on these
machines, you may rerun the firmware update utility from a floppy in
SRM using the <Literal remap="tt">fwupdate</Literal> command.  You can also start AlphaBIOS
from a floppy using the <Literal remap="tt">arc</Literal> command.
</Para>

</Sect2>

<Sect2>
<Title>Using the SRM console</Title>

<Para>
The SRM console works very much like a Unix or OpenVMS shell.  It
views your NVRAM and devices as a pseudo-filesystem.  You can see this
if you use the <command>ls</command> command.  Also, it contains a fairly large set
of diagnostic, setup, and debugging utilities, the details of which
are beyond the scope of this document.  As in the Unix shell, you can
pipe the output of one command to the input of another, and there is a
<command>more</command> command that works not unlike the Unix one.  To get a full
listing of available commands, run:

<Screen>
&#62;&#62;&#62; help | more
</Screen>

</Para>

<Para>
As well, SRM has environment variables, a number of which are
pre-defined and correspond to locations in NVRAM.  You can view the
entire list of environment variables and their values with the
<command>show</command> command (there are quite a few of them, so you will probably
want to pipe its output to <command>more</command>).  You can also show variables
matching a "glob" pattern - for example, <command>show boot*</command> will show all
the variables starting in "boot".
</Para>

<Para>
Environment variables are categorized as either <Emphasis>read-only</Emphasis>,
<Emphasis>warm non-volatile</Emphasis>, or <Emphasis>cold non-volatile</Emphasis>.  The full listing
of pre-defined variables is detailed in the Alpha Architecture
Reference Manual.  The most useful pre-defined environment variables
for the purposes of booting Linux are <varname>bootdef&lowbar;dev</varname>,
<varname>boot&lowbar;file</varname>, <varname>boot&lowbar;flags</varname>, and
<varname>auto&lowbar;action</varname>, all of which are cold non-volatile.
</Para>

<Para>
To set environment variables, use the <command>set</command> command, like this:

<Screen>
&#62;&#62;&#62; set bootdef_def dka0
</Screen>

</Para>

<Para>
If you set an undefined variable, it will be created for you, however
it will not persist across reboots.
</Para>

<Para>
The <varname>bootdef&lowbar;dev</varname> variable specifies the device (using
VMS naming conventions - see <XRef LinkEnd="device-naming"> for an
explanation of these) which will be booted from if no device is
specified on the <Literal remap="tt">boot</Literal> command line, or in an automatic boot.
The <varname>boot&lowbar;file</varname> variable contains the filename to be
loaded by the secondary bootloader, while <varname>boot&lowbar;flags</varname>
contains any extra flags.  <varname>auto&lowbar;action</varname> specifies the
action which the console should take on power-up.  By default, it is
set to <Literal remap="tt">HALT</Literal>, meaning that the machine will start up in the
SRM console.  Once you have configured your bootloader and the
boot-related variables, you can set it to <Literal remap="tt">BOOT</Literal> in order to
boot automatically on power-up.
</Para>

<Para>
Finally, two helpful console keystrokes you should know are
<keycombo action='simul'><keycap>Control</keycap><keycap>C</keycap></keycombo>,
which, as in the shell, halts a command in progress (such
as an automatic boot), and 
<keycombo action='simul'><keycap>Control</keycap><keycap>P</keycap></keycombo>,
which if issued from the aboot
prompt (or other secondary bootloader) will halt the bootloader and
return you to the SRM console.
</Para>

</Sect2>

<Sect2 id="how-srm-boots">
<Title>How Does SRM Boot an OS?</Title>

<Para>
All versions of SRM can boot from SCSI disks and the versions for
recent platforms, such as the Noname or AlphaStations can boot from
floppy disks as well.  Network booting via <Literal remap="tt">bootp</Literal> is supported.
Note that older SRM versions (notably the one for the Jensen)
cannot boot from floppy disks. Booting from IDE devices
is supported on newer platforms (164SX, 164LX, 164UX, DS20, DS10, DP264, UP2000(+), UP1000, UP1100 etc.). 
</Para>

<Para>
Booting Linux with SRM is a two step process: first, SRM loads and
transfers control to the secondary bootstrap loader.  Then the
secondary bootstrap loader sets up the environment for Linux, reads
the kernel image from a disk filesystem and finally transfers control to Linux.
</Para>

<Para>
Currently, there are two secondary bootstrap loaders for Linux:
the <Emphasis>raw</Emphasis> loader that comes with the Linux kernel and <Literal remap="tt">aboot</Literal>
which is distributed separately.  These two loaders are described in
more detail below.
</Para>

</Sect2>

<Sect2>
<Title>Loading The Secondary Bootstrap Loader</Title>

<Para>
SRM knows nothing about filesystems or disk-partitions.  It simply
expects that the secondary bootstrap loader occupies a consecutive
range of physical disk sector, starting from a given offset.  The
information on the size of the secondary bootstrap loader and the
offset of its first disk sector is stored in the first 512 byte
sector.  Specifically, the long integer at offset 480 stores the
<Emphasis>size</Emphasis> of the secondary bootstrap loader (in 512-byte blocks) and
the long at offset 488 gives the <Emphasis>sector number</Emphasis> at which the
secondary bootstrap loader starts.  The first sector also stores a
flag-word at offset 496 which is always 0 and a checksum at offset
504.  The checksum is simply the sum of the first 63 long integers in
the first sector.
</Para>

<Para>
If the checksum in the first sector is correct, SRM goes ahead and
reads the <Emphasis>size</Emphasis> sectors starting from the sector given in the
<Emphasis>sector number</Emphasis> field and places them in <Emphasis>virtual</Emphasis> memory at
address <Literal remap="tt">0x20000000</Literal>.  If the reading completes successfully,
SRM performs a jump to address <Literal remap="tt">0x20000000</Literal>.
</Para>

</Sect2>

</Sect1>

<Sect1 id="SRM-DeviceNaming">
<Title>SRM Device Naming</Title>
<Sect2>
<Title>The First Two Letter</Title>
<Para>The following is based on the example device dkb1.2.3.4.5 taken from a Digital Server 3300 (Whitebox version of
an AS800).
</Para>
<Para>
Two letter port or class driver designator:
<!-- <variablelist>
<varlistentry><term>DR:</term><listitem><para>RAID set device</Para></ListItem></varlistentry>
<varlistentry><term>DV:</term><ListItem><Para>Floppy Drive</Para></ListItem></varlistentry>
<ListItem><Para>         EW:     Ethernet port (TULIP, DEC 21040) </Para></ListItem>
<ListItem><Para>         EI:     Ethernet port (Intel 82557 or 82559) </Para></ListItem> 
<ListItem><Para>         PK:     SCSI port (controller) </Para></ListItem>
<ListItem><Para>         DK:     SCSI disk </Para></ListItem>
<ListItem><Para>         MK:     SCSI tape </Para></ListItem>
<ListItem><Para>         PU:     DSSI port </Para></ListItem>
<ListItem><Para>         DU:     DSSI disk </Para></ListItem>
<ListItem><Para>         MU:     DSSI tape </Para></ListItem>
<ListItem><Para>         JK:     SCSI monitor (or robot) </Para></ListItem>
<ListItem><Para>	 DQ:	 (E)IDE Device (disk or CD-ROM)</Para></ListItem>
</ItemizedList>
</variablelist> -->
<ItemizedList>
<ListItem><Para>         DR:     RAID set device </Para></ListItem>
<ListItem><Para>         DV:     Floppy Drive </Para></ListItem>
<ListItem><Para>         EW:     Ethernet port (TULIP, DEC 21040) </Para></ListItem>
<ListItem><Para>         EI:     Ethernet port (Intel 82557 or 82559) </Para></ListItem> 
<ListItem><Para>         PK:     SCSI port (controller) </Para></ListItem>
<ListItem><Para>         DK:     SCSI disk </Para></ListItem>
<ListItem><Para>         MK:     SCSI tape </Para></ListItem>
<ListItem><Para>         PU:     DSSI port </Para></ListItem>
<ListItem><Para>         DU:     DSSI disk </Para></ListItem>
<ListItem><Para>         MU:     DSSI tape </Para></ListItem>
<ListItem><Para>         JK:     SCSI monitor (or robot) </Para></ListItem>
<ListItem><Para>	 DQ:	 (E)IDE Device (disk or CD-ROM)</Para></ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>The Rest Of The Device Name</Title>
<Para>

<ItemizedList>
<ListItem><Para>
 b->adapter ID (one letter adapter designator)</Para></ListItem>

<ListItem><Para>
 1->Device number (SCSI unit numbers are forced to 100x Node ID)</Para></ListItem>

<ListItem><Para>
 2->Bus Node ID</Para></ListItem>

<ListItem><Para>
 3->Channel Number</Para></ListItem>

<ListItem><Para>
 4->Channel Number (used for multi-channel devices)</Para></ListItem>

<ListItem><Para>
 5->Logical Slot number

  <ItemizedList>
      <ListItem><Para>EISA: they correspond to the physical slot numbers (1-3)</Para></ListItem>
      <ListItem><Para>PCI:</Para>
      <ItemizedList>
         <ListItem><Para>slot 5= SCSI controller on system backplane (DS3300)</Para></ListItem>
         <ListItem><Para>slot 6= On board VGA (DS3300)</Para></ListItem>
         <ListItem><Para>slot 7= PCI to EISA bridge chip (DS3300)</Para></ListItem>
         <ListItem><Para>slots 11 - 14 = Correspond to Physical PCI option slots:
                 PCI11, PCI12, PCI13 and PCI14 (64bit) (DS3300)</Para></ListItem>
      </ItemizedList>
      </ListItem>
  </ItemizedList>
</Para>
</ListItem>
<ListItem><Para>
 6->Hose number: 0 PCI_0 (32bit PCI); 1 EISA (DS3300)</Para></ListItem>

</ItemizedList>
</Para>
</Sect2>
</Sect1>


<Sect1 id="SRM-rawloader">
<Title>The Raw Loader</Title>

<Para>
The sources for this loader can be found in directory
<filename>arch/alpha/boot</filename> of the Linux kernel source
distribution.  It loads the Linux kernel by reading
<varname>START&lowbar;SIZE</varname> bytes starting at disk offset
<varname>BOOT&lowbar;SIZE</varname><Literal remap="tt">+512</Literal>
(also in bytes).  The constants
<varname>START&lowbar;SIZE</varname> and <varname>BOOT&lowbar;SIZE</varname>
are defined in
<filename>linux/include/asm-alpha/system.h</filename>. 
<varname>START&lowbar;SIZE</varname>
must be at least as big as the kernel image (i.e., the size of the
<Literal remap="tt">.text</Literal>, <Literal remap="tt">.data</Literal>, and <Literal remap="tt">.bss</Literal> segments).  Similarly,
<varname>BOOT&lowbar;SIZE</varname> must be at least as big as the image of the
raw bootstrap loader.  Both constants should be an integer multiple of the
sector size, which is 512 bytes.  The default values are currently 2MB
for <varname>START&lowbar;SIZE</varname> and 16KB for 
<varname>BOOT&lowbar;SIZE</varname>.  Note
that if you want to boot from a 1.44MB floppy disk, you have to reduce
<varname>START&lowbar;SIZE</varname> to 1400KB and make sure that the kernel you
want to boot is no bigger than that.
</Para>

<Para>
To build a raw loader, simply type <command>make rawboot</command> in the top
directory of your linux source tree (typically
<filename>/usr/src/linux</filename>).  This should produce the following files 
in <filename>arch/alpha/boot</filename>:
</Para>

<Para>
<VariableList>

<VarListEntry>
<Term><filename>tools/lxboot</filename>:</Term>
<ListItem>
<Para>
The first
sector on the disk.  It contains the offset and size of
the next file in the format described above.
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term><filename>tools/bootlx</filename>:</Term>
<ListItem>
<Para>
The raw boot loader that
will load the file below.
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term><filename>vmlinux.nh</filename>:</Term>
<ListItem>
<Para>
The raw kernel image consisting of
the <Literal remap="tt">.text</Literal>, <Literal remap="tt">.data</Literal>, and <Literal remap="tt">.bss</Literal> segments of the
object file in <Literal remap="tt">/usr/src/linux/vmlinux</Literal>.  The
extension <Literal remap="tt">.nh</Literal> indicates that this file has no object-file
header.
</Para>
</Listitem>
</VarListEntry>
</VariableList>
</Para>

<Para>
The concatenation of these three files should be written to the
disk from which you want to boot.  For example, to boot from a floppy,
insert an empty floppy disk in, say, <filename>/dev/fd0</filename> and then type:

<Screen>
# cat tools/lxboot tools/bootlx vmlinux &#62;/dev/fd0
</Screen>

</Para>

<Para>
You can then shutdown the system and boot from the floppy by
issuing the command <command>boot dva0</command>.
</Para>

</Sect1>

<Sect1 id="SRM-aboot">
<Title>The aboot Loader</Title>

<Para>
When using the SRM firmware, <Literal remap="tt">aboot</Literal> is the preferred way of
booting Linux.  It supports:
</Para>

<Para>

<ItemizedList>
<ListItem>

<Para>
 direct booting from various filesystems (<Literal remap="tt">ext2</Literal>, <Literal remap="tt">ISO9660</Literal>, and
<Literal remap="tt">UFS</Literal>, the <productname>HP Tru64</productname> filesystem)
</Para>
</ListItem>
<ListItem>

<Para>
 listing directories and following symbolic links on ext2 (version 0.6 and later)
</Para>
</ListItem>
<ListItem>

<Para>
 booting of executable object files (both ELF and ECOFF)
</Para>
</ListItem>
<ListItem>

<Para>
 booting compressed kernels
</Para>
</ListItem>
<ListItem>

<Para>
 network booting (using bootp)
</Para>
</ListItem>
<ListItem>

<Para>
 partition tables in <productname>HP Tru64</productname> format (which is
compatible with BSD Unix partition tables)
</Para>
</ListItem>
<ListItem>

<Para>
 interactive booting and default configurations for
SRM consoles that cannot pass long option strings
</Para>
</ListItem>

<ListItem>

<Para>
 load initrd images to load modules at boot time (0.7 and later)
</Para>
</ListItem>

</ItemizedList>

</Para>

<Sect2>
<Title>Getting and Building aboot</Title>

<Para>
The latest sources for <Literal remap="tt">aboot</Literal> are available from <ULink
URL="http://www.sf.net/projects/aboot"
>Sourceforge</ULink>. They can
also be obtained via anonymous CVS from www.sf.net, to get the latest version from CVS use these commands:
<Screen>
bash# cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/aboot login 
bash# cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/aboot co aboot
</Screen>
(Note there is no password for the CVS login, just press enter)
</Para>

<Para>
The description in this manual applies to <Literal remap="tt">aboot</Literal> version 0.6
or newer. Please note that many distributions ship aboot with them so
downloading aboot from this directory is probably not neccesary.
</Para>

<Para>
 Once you downloaded and extracted the latest tar file, take a
look at the <filename>README</filename> and <filename>INSTALL</filename> files
for installation hints.  In particular, be sure to adjust the variables in
<filename>Makefile</filename> and in <filename>include/config.h</filename>
to match your
environment.  Normally, you won't need to change anything when
building under Linux, but it is always a good idea to double check.
If you're satisfied with the configuration, simply type <command>make</command>
to build it (if you're not building under Linux, be advised that
<Literal remap="tt">aboot</Literal> requires GNU <Literal remap="tt">make</Literal>).
</Para>

<Para>
After running <Literal remap="tt">make</Literal>, the <filename>aboot</filename>
directory should contain the following files:
</Para>

<Para>
<VariableList>

<VarListEntry>
<Term><filename>aboot</filename></Term>
<ListItem>
<Para>
This is the actual <Literal remap="tt">aboot</Literal> executable (either an
ECOFF or ELF object file).
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term><filename>bootlx</filename></Term>
<ListItem>
<Para>
Same as above, but it contains only the text, data
and bss segments &dash; that is, this file is not an object file.
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term><filename>sdisklabel/swriteboot</filename></Term>
<ListItem>
<Para>
Utility to install <Literal remap="tt">aboot</Literal> on a
hard disk.
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term><filename>tools/e2writeboot</filename></Term>
<ListItem>
<Para>
Utility to install <Literal remap="tt">aboot</Literal> on an ext2
filesystem (usually used for floppies only).
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term><filename>tools/isomarkboot</filename></Term>
<ListItem>
<Para>
Utility to install <Literal remap="tt">aboot</Literal> on a iso9660
filesystem (used by CD-ROM distributors).
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term><filename>tools/abootconf</filename></Term>
<ListItem>
<Para>
Utility to configure an installed <Literal remap="tt">aboot</Literal>.
</Para>
</Listitem>
</VarListEntry>
</VariableList>
</Para>

</Sect2>

<Sect2>
<Title>Floppy Installation</Title>

<Para>
 The bootloader can be installed on a floppy using the
<command>e2writeboot</command> command (note: this can't be done on a Jensen 
since
its firmware does <Emphasis>not</Emphasis> support booting from floppy).  This command
requires that the disk is not overly fragmented as it needs to find
enough contiguous file blocks to store the entire <Literal remap="tt">aboot</Literal> image
(currently about 90KB).  If <command>e2writeboot</command> fails because of this,
reformat the floppy and try again (e.g., with <command>fdformat</command>(1)).
For
example, the following steps install <Literal remap="tt">aboot</Literal> on floppy disk
assuming the floppy is in drive <filename>/dev/fd0</filename>:

<Screen>
# fdformat /dev/fd0
# mke2fs /dev/fd0
# e2writeboot /dev/fd0 bootlx
</Screen>

</Para>

</Sect2>

<Sect2>
<Title>Harddisk Installation</Title>

<Para>
Since the <command>e2writeboot</command> command may fail on highly fragmented
disks and since reformatting a harddisk is not without pain, it is
generally safer to install <Literal remap="tt">aboot</Literal> on a harddisk using the
<command>swriteboot</command> command.
<Literal remap="tt">swriteboot</Literal> requires that the first few
sectors are reserved for booting purposes.  We suggest that the disk
be partitioned such that the first partition starts at an offset of
2048 sectors.  This leaves 1MB of space for storing <Literal remap="tt">aboot</Literal>.  On
a properly partitioned disk, it is then possible to install <Literal remap="tt">aboot</Literal>
as follows (assuming the disk is <filename>/dev/sda</filename>):

<Screen>
# swriteboot /dev/sda bootlx
</Screen>

</Para>

<Para>
On systems where partition <Literal remap="tt">c</Literal> in the entire disk it will be
necessary to 'force' the write of aboot. In this case use the <Literal remap="tt">-f</Literal>
flag followed by the partition number (in the case of partition <Literal remap="tt">c</Literal>
this is 3):

<Screen>
# swriteboot /dev/sda bootlx -f3
</Screen>

</Para>

<Para>
On a Jensen, you will want to leave some more space, since you need to
write a kernel to this place, too---2MB should be sufficient when
using compressed kernels.  Use <Literal remap="tt">swriteboot</Literal> as described in Section
<XRef LinkEnd="booting"> to write <filename>bootlx</filename> together with
the Linux kernel.
</Para>

</Sect2>

<Sect2>
<Title>CD-ROM Installation</Title>

<Para>
 To make a CD-ROM bootable by SRM, simply build <Literal remap="tt">aboot</Literal> as
described above.  Then, make sure that the <filename>bootlx</filename> file is
present on the iso9660 filesystem (e.g., copy <filename>bootlx</filename> to
the directory that is the filesystem master, then run <command>mkisofs</command>
on that directory).  After that, all that remains to be done is to mark the
filesystem as SRM bootable.  This is achieved with a command of the
form:

<Screen>
# isomarkboot filesystem bootlx
</Screen>

</Para>

<Para>
The command above assumes that <filename>filesystem</filename> is a file
containing the iso9660 filesystem and that <filename>bootlx</filename> has been
copied into the
root directory of that filesystem.  That's it!
</Para>

</Sect2>

<Sect2 id="Building-Linux">
<Title>Building the Linux Kernel</Title>

<Para>
A bootable Linux kernel can be built with the following steps.
During the <command>make config</command>, be sure to answer "yes" to the
question
whether you want to boot the kernel via SRM (for certain platforms
this is automatically selected).  Note that if you build a generic
kernel (by selecting "Generic" as the alpha system type), the kernel
is able to guess whether it is running under SRM or not.

<Screen>
# cd /usr/src/linux
# make config
# make dep
# make boot
# make modules (if applicable)
# make modules_install (if applicable)
</Screen>

</Para>

<Para>
The last command will build the file
<filename>arch/alpha/boot/vmlinux.gz</filename> which can then be copied to the
disk from which you want to boot from.  In our floppy disk example
above, this would entail:

<Screen>
# mount /dev/fd0 /mnt
# cp arch/alpha/boot/vmlinux.gz /mnt
# umount /mnt
</Screen>

</Para>

</Sect2>

<Sect2 id="booting">
<Title>Booting Linux</Title>

<Para>
 With the SRM firmware and <Literal remap="tt">aboot</Literal> installed, Linux is generally
booted with a command of the form:

<Screen>
<Literal remap="tt">boot</Literal> <Emphasis remap="it">devicename</Emphasis> <Literal remap="tt">-fi</Literal> <Emphasis remap="it">filename</Emphasis>
<Literal remap="tt">-fl</Literal> <Emphasis remap="it">flags</Emphasis>
</Screen>

</Para>

<Para>
The <Emphasis remap="it">filename</Emphasis> and <Emphasis remap="it">flags</Emphasis> arguments are optional.  If
they are not specified, SRM uses the default values stored in
environment variables <varname>BOOTDEF&lowbar;DEV</varname>,
<varname>BOOT&lowbar;OSFILE</varname> and 
<varname>BOOT&lowbar;OSFLAGS</varname>.  The
syntax and meaning of these two arguments is described in more detail
below. To list the current values of these variables type 
<command>show boot*</command> at the SRM command prompt. This will also show a
<varname>boot&lowbar;dev</varname> variable (among others), this variable is
read only
and needs to be changed via the <varname>bootdef&lowbar;dev</varname> variable.
</Para>

<Sect3 id="device-naming">
<Title>Device Naming</Title>

<Para>
This corresponds to the device from which SRM will attempt to boot. Examples include:
</Para>

<Para>
<VariableList>

<VarListEntry>
<Term>dva0</Term>
<ListItem>
<Para>
- First floppy drive, <filename>/dev/fd0</filename> under Linux
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>dqa0</Term>
<ListItem>
<Para>
- Primary IDE CD-ROM or hard disk as Master, <filename>/dev/hda</filename>
  under Linux
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>dqa1</Term>
<ListItem>
<Para>
- Primary IDE CD-ROM or hard disk as Slave, <filename>/dev/hdb</filename>
  under Linux
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>dka0</Term>
<ListItem>
<Para>
- SCSI disk on first bus, Device 0, <filename>/dev/sda</filename> under Linux
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>ewa0</Term>
<ListItem>
<Para>
- First Ethernet Device, <filename>/dev/eth0</filename> under Linux
</Para>
</Listitem>
</VarListEntry>
</VariableList>
</Para>

<Para>
For example to boot from the disk at SCSI id 6, you would enter:

<Screen>
&#62;&#62;&#62; boot dka600
</Screen>

</Para>

<Para>
To list the devices currently installed in the system type
<command>show dev</command> at the SRM command line.  In contrast to Linux
device naming, the
partition number on a disk device is <Emphasis>not</Emphasis> given as part of the
device name (you may see extra numbers after the device names when
running <command>show dev</command> - these correspond to things like PCI bus and
device numbers and are not useful to the user).  Remember, as
mentioned in <XRef LinkEnd="how-srm-boots">, that SRM knows <Emphasis>nothing</Emphasis>
about partitions or disklabels - it merely reads a boot block and
secondary bootstrap from sectors on a disk.  Therefore, the partition
number is given as part of the boot filename.
</Para>

</Sect3>

<Sect3>
<Title>Boot Filename</Title>

<Para>
The filename argument takes the form:
<QUOTE
>&lsqb;<Emphasis>n</Emphasis>/&rsqb;<Emphasis>filename</Emphasis></QUOTE
>
</Para>

<Para>
<Emphasis>n</Emphasis> is a single digit in the range 1..8 that gives the partition
number from which to boot from.  <filename>filename</filename> is the path of the file 
you want boot.  For example to boot a kernel named
<filename>vmlinux.gz</filename> from the second partition of SCSI
device 6, you would enter:

<Screen>
&#62;&#62;&#62; boot dka600 -file 2/vmlinux.gz
</Screen>

</Para>

<Para>
Or to boot from floppy drive 0, you'd enter:

<Screen>
&#62;&#62;&#62; boot dva0 -file vmlinux.gz
</Screen>

</Para>

<Para>
If a disk has no partition table, <Literal remap="tt">aboot</Literal> pretends the disk
contains one <Literal remap="tt">ext2</Literal> partition starting at the first diskblock.
This allows booting from floppy disks.
</Para>

<Para>
As a special case, partition number 0 is used to request booting
from a disk that does not (yet) contain a file system.  When
specifying "partition" number 0, <Literal remap="tt">aboot</Literal> assumes that the Linux
kernel is stored right behind the <Literal remap="tt">aboot</Literal> image.  Such a layout
can be achieved with the <command>swriteboot</command> command.  For example, to
setup a filesystem-less boot from <filename>/dev/sda</filename>, one could use
the command:

<Screen>
# swriteboot /dev/sda bootlx vmlinux.gz
</Screen>

</Para>

<Para>
Booting a system in this way is not normally necessary.  The
reason this feature exists is to make it possible to get Linux
installed on a systems that can't boot from a floppy disk (e.g., the
Jensen).
</Para>

</Sect3>

<Sect3>
<Title>Boot Flags</Title>

<Para>
A number of bootflags can be specified.  The syntax is:

<Screen>
-flags "options..."
</Screen>

</Para>

<Para>
Where "options..." is any combination the following options (separated
by blanks).  There are many more bootoptions, depending on what
drivers your kernel has installed.  The options listed below are
therefore just examples to illustrate the general idea:
</Para>

<Para>
<VariableList>

<VarListEntry>
<Term>load&lowbar;ramdisk=1</Term>
<ListItem>
<Para>
Copy root file system from a (floppy) disk to the RAM disk
before starting the system.  The RAM disk will be used in
lieu of the root device.  This is useful to bootstrap Linux
on a system with only one floppy drive.
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>floppy=<Emphasis>str</Emphasis></Term>
<ListItem>
<Para>
Sets floppy configuration to <Emphasis>str</Emphasis>.
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>root=<Emphasis>dev</Emphasis></Term>
<ListItem>
<Para>
Select device <Emphasis>dev</Emphasis> as the root-file
system. The device can be specified as a major/minor hex number (e.g.,
0x802 for <filename>/dev/sda2</filename>) or one of a few canonical names (e.g.,
<filename>/dev/fd0</filename>, <filename>/dev/sda2</filename>).
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>single</Term>
<ListItem>
<Para>
Boot system in single user mode.
</Para>
</Listitem>
</VarListEntry>
<VarListEntry>
<Term>kgdb</Term>
<ListItem>
<Para>
Enable kernel-gdb (works only if <varname>CONFIG&lowbar;KGDB</varname> is
enabled; a second Alpha system needs to be connected over the serial
port in order to make this work)
</Para>
</Listitem>
</VarListEntry>
</VariableList>
</Para>

<Para>
Some SRM implementations (e.g., the one for the Jensen) are
handicapped and allow only short option strings (e.g., at most 8
characters).  In such a case, <Literal remap="tt">aboot</Literal> can be booted with the
single-character boot flag "i".  With this flag, <Literal remap="tt">aboot</Literal> will
enter interactive mode
</Para>

</Sect3>

<Sect3>
<Title>Using aboot interactively</Title>

<Para>
As of version 0.6, <Literal remap="tt">aboot</Literal> supports a simple command-oriented
interactive mode.  Note that this is <Emphasis>different</Emphasis> from the prompt
which previous versions issued when booted with the "i" flag, or after
failing to load a kernel.  You can get a summary of the available
commands by typing "h" or "?" at the prompt:

<Screen>
&#62;&#62;&#62; boot dka0 -fl i
aboot&#62; ?
 h, ?                   Display this message
 q                      Halt the system and return to SRM
 p 1-8                  Look in partition &#60;num&#62; for configuration/kernel
 l                      List pre-configured kernels
 d &#60;dir&#62;                List directory &#60;dir&#62; in current filesystem
 b &#60;file&#62; &#60;args&#62;        Boot kernel in &#60;file&#62; (- for raw boot)
                        with arguments &#60;args&#62;
 0-9                    Boot pre-configuration 0-9 (list with 'l')
aboot&#62; b 3/vmlinux.gz root=/dev/sda3 single
</Screen>

</Para>

</Sect3>

<Sect3>
<Title>The <filename>aboot.conf</filename> configuration file</Title>

<Para>
Since booting in that manner quickly becomes tedious, <Literal remap="tt">aboot</Literal>
allows to define short-hands for frequently used command lines.  In
particular, a single digit option (0-9) requests that <Literal remap="tt">aboot</Literal> uses
the corresponding option string stored in file
<filename>etc/aboot.conf</filename>.  A sample <filename>aboot.conf</filename> is shown below:

<Screen>
#
# aboot default configurations
#
0:3/vmlinux.gz root=/dev/sda3
1:3/vmlinux.gz root=/dev/sda3 single
2:3/vmlinux.new.gz root=/dev/sda3
3:3/vmlinux root=/dev/sda3
8:- root=/dev/sda3            # fs-less boot of raw kernel
9:0/vmlinux.gz root=/dev/sda3 # fs-less boot of (compressed) ECOFF kernel
-
</Screen>

</Para>

<Para>
With this configuration file, the command

<Screen>
&#62;&#62;&#62; boot dka0 -fl 1
</Screen>

corresponds exactly to the boot command shown above.
</Para>

<Para>
Finally, at the <Literal remap="tt">aboot</Literal> prompt, it is possible to enter one of the
single character flags ("0"-"9") to get the same effect as if that
flag had been specified in the boot command line.  As noted in the
help text cited above, you can also list the available default
configurations with the "l" command.
</Para>

<Sect4>
<Title>Selecting the Partition of <filename>etc/aboot.conf</filename></Title>

<Para>
When installed on a harddisk, <Literal remap="tt">aboot</Literal> needs to know what
partition to search for the <filename>/etc/aboot.conf</filename> file.  A newly
compiled <Literal remap="tt">aboot</Literal> will search the <Emphasis>second</Emphasis> partition (e.g.,
<filename>/dev/sda2</filename>).  Since it would be inconvenient to have to
recompile <Literal remap="tt">aboot</Literal> just to change the partition number,
<Literal remap="tt">abootconf</Literal> allows to directly modify an installed <Literal remap="tt">aboot</Literal>.
Specifically, if you want to change <Literal remap="tt">aboot</Literal> to use the <Emphasis>third</Emphasis>
partition on disk <filename>/dev/sda</filename>, you'd use the command:

<Screen>
# abootconf /dev/sda 3
</Screen>
</Para>

<Para>
You can verify the current setting by simply omitting the partition
number.  That is: <command>abootconf /dev/sda</command> will print the currently
selected partition number.  Note that <Literal remap="tt">aboot</Literal> does have to be
installed already for this command to succeed.  As of version 0.6,
<Literal remap="tt">swriteboot</Literal> it will preserve the existing configuration when
installing a new <Literal remap="tt">aboot</Literal> on a hard disk.
</Para>


<Para>
Since <Literal remap="tt">aboot</Literal> version 0.5, it is also possible to select the
<filename>aboot.conf</filename> partition via the boot command line. This can
be
done with a command line of the form <Emphasis remap="it">a</Emphasis><Literal remap="tt">:</Literal><Emphasis remap="it">b</Emphasis>
where <Emphasis remap="it">a</Emphasis>
is the partition that holds <filename>etc/aboot.conf</filename> and <Emphasis remap="it">b</Emphasis> is a
single-letter option as described above (<Literal remap="tt">0</Literal>-<Literal remap="tt">9</Literal>, <Literal remap="tt">i</Literal>, or
<Literal remap="tt">h</Literal>). For example, if you type 
<command>boot -fl "3:h" dka100</command> the
system boots from SCSI ID 1, loads <filename>etc/aboot.conf</filename> from the
third partition, prints its contents on the screen and waits for you
to enter the boot options.
</Para>

</Sect4>

</Sect3>

</Sect2>

<Sect2 id="DHCP-and-BOOTPD-server-setup">
<Title>Setting up a BOOTP capable server using DHCP</Title>

<Para>
The following configuration assumes that the server is running RH-6.2. 
Prerequisites packages are,
<ItemizedList>
<Listitem>
<Para>
dhcp-2.0.5 
</Para>
</Listitem>
<Listitem>
<Para>
tftp-server-0.16.5
</Para>
</Listitem>
</Itemizedlist>

</Para>

<Sect3>
<Title>DHCP & BOOTP configuation</Title>
<Para>
Once those packages are installed there are a few setup issues to take care of.
</Para>

<Para>
Create the default directory to which files will be pulled from using tftp.
</Para>
<Screen>
# mkdir /tftpboot
</Screen>

<Para>
Create the <filename>dhcp.leases</filename> file which is not create per default
(though it should be) when
you install the dhcp package so the dhcp server may start. 
</Para>

<Screen>
# mkdir -p /var/state/dhcp
# touch /var/state/dhcp/dhcpd.leases
</Screen>

<Para>
Configure the inetd to accept the tftp service. Edit your 
<filename>/etc/inetd.conf</filename> file and locate
the following line. Then uncomment it and save the file.
</Para>

<Screen>
#tftp	dgram	udp	wait	root	/usr/sbin/tcpd	in.tftpd
</Screen>

<Para>
Create the <filename>/etc/dhcp.conf</filename> configuation file. An example
config is provided below with the directives which allow BOOTP. 
</Para>

<Screen>
subnet 192.168.1.0 netmask 255.255.255.0 {
       option routers                        192.168.1.1;
       option subnet-mask                  255.255.255.0;
       option nis-domain                "alphalinux.org";
       option domain-name	        "alphalinux.org";
       option domain-name-servers            192.168.1.2;
       range                 192.168.1.3   192.168.1.254;
       range dynamic-bootp   192.168.1.3   192.168.1.254;
       default-lease-time                          21600;
       max-lease-time                              43200;
       allow bootp;
       allow booting;
       filename "/tftpboot/vmlinux.bootp";	
}                                 
</Screen>

<Sect4>
<Title>Examination of <filename>/etc/dhcp.conf</filename></Title>
<Para>
There are four directives that you should be concerned with.
</Para>

<ItemizedList>
<Listitem> 
<Para><Literal remap="tt">range dynamic-bootp 192.168.1.3 192.168.1.254;</Literal>
which defines the range of ip's available for bootp.
</Para></Listitem>
<Listitem><Para> 
<Literal remap="tt">allow bootp;</Literal>
which tells the dhcp server to allow the bootp protocol..
</Para></Listitem> 
<Listitem><Para> 
<Literal remap="tt">allow booting;</Literal>
which tells the dhcp server to allow the transfer of the file specified 
either in the the "filename" directive or passed in the "-file" flag in SRM. 
</Para></Listitem> 
<Listitem><Para> 
<Literal remap="tt">filename "<filename>/tftpboot/vmlinux.bootp</filename>";</Literal>
 which is the default file which is transferred and executed when no filename 
specified in SRM as an argument. 
</Para></Listitem> 
</ItemizedList>



<Para>Lastly, Restart the inetd daemon so that the changes we made can take effect</Para>

<Screen># service inet restart</Screen>

<Para>You should now have a DHCP server that is capable of BOOTP.</Para>
</Sect4>
</Sect3>

<Sect3>
<Title id="bootpd-setup">bootpd configuration</Title>
<Para>
The bootpd is the older way of making a bootp server and for the most part is not used anymore
in lieu of more modern DHCP servers that are capable of handling the protocol with minimal configuration
and more flexibility. This style of setup does not allow just any client to be granted a BOOTP request. 
Instead you must specify the ip address and MAC address of the allowed clients. Naturally this could get
quite tedious if you where say administrating more than a few machines. 
</Para>

<Para>
bootpd rpms can be found on older versions of RedHat's distributions like version 5.2 and below. Note:
the rpm itself is named bootp though the package does contain the bootpd filename. It is available
for download at your favorite RedHat <ulink url="ftp://ftp.freesoftware.com/.1/linux/redhat/old-releases/redhat-5.2/alpha/RedHat/RPMS/">mirror</ulink>.
The bootp package requires the tftp-server just as before and the location to where the files are grabbed from is the same.  
</Para>

<Para>
Once installed you must configure your inetd service to talk to the bootpd daemon. Uncomment the following line in your <filename>/etc/inetd.conf</filename>.
</Para>
<Screen>
#bootps dgram   udp     wait    root    /usr/sbin/tcpd  bootpd
</Screen>
<Para>
Then restart the inetd.
</Para>
<Screen>
# service inet restart
</Screen>

<Para>
Configuring the <filename>/etc/bootptab</filename> file.  The 
<filename>bootptab</filename> file
has one entry describing each client that is allowed to boot from
the server.  For example, if you want to boot the machine
<Literal remap="tt">voodoo.alphalinux.org</Literal>, then an entry of the following form would
be needed:

<Screen>
voodoo.alphalinux.org:\
	:hd=/tftpboot/:bf=vmlinux.bootp:\
	:ht=ethernet:ha=08012B1C51F8:hn:vm=rfc1048:\
	:ip=192.12.69.254:bs=auto:
</Screen>

</Para>

<Para>
This entry assumes that the machine's Ethernet address is
<Literal remap="tt">08012B1C51F8</Literal> and that its IP address is 192.12.69.254.  The
Ethernet address can be found with the <command>show device</command> command
of the SRM console or, if Linux is running, with the <command>ifconfig</command>
command.
The entry also defines that if the client does not specify otherwise,
the file that will be booted is <filename>vmlinux.bootp</filename> in directory
<filename>/tftpboot</filename>.  For more information on configuring <Literal remap="tt">bootpd</Literal>,
please refer to its man page.
</Para>

</Sect3>


</Sect2> 


<Sect2 id="Network-Booting">
<Title>Booting Over the Network</Title>

<Para>
Three steps are necessary before Linux can be booted via
a network.  First you need an Ethernet adapter that is supported by SRM.
Most version of SRM support the DE500 series of cards, with newer
versions (5.6 and later) also supporting the Intel EtherExpress/Pro series
of cards.
Second, you need to set the SRM environment variables to
enable booting via the bootp protocol and third you need to setup
another machine as the your boot server.  Enabling bootp in SRM is
usually done by setting the ewa0&lowbar;protocol (DE500 cards) or eia0&lowbar;protocol (Intel cards) variable to bootp.

<Screen>
&#62;&#62;&#62; set ewa0_protocol bootp
</Screen>
</Para>

<Para>
Also check to see that your ethernet device has a link light to whatever hub or switch it is connected to. If you
do not see a link light try forcing the negotiation of the ethernet device. For example:
</Para>

<Screen>
>>> set ewa0_mode FastFD
</Screen>

<Para> Would set the DE500 ethernet card to fast full duplex operation. To see a list of the available modes</Para>

<Screen>
>>> set ewa0_mode 
</Screen>

<Para>
Netboot using the aboot sources is currently broken though for the curious the steps needed are further below. Instead use the directions for netbooting using the kernel sources. 
</Para>

<Sect3>
<Title>Netboot using the kernel sources</Title>

<Para>
<OrderedList>
<Listitem>
<Para>
Make sure the kernel you want to boot has already been built 
</Para>
</Listitem>
<Listitem>
<Para>
Execute the following while in the linux source dir: 
  <ItemizedList>
  <Listitem>
  <Para>
    <Literal><command>make bootimage</command></Literal> 
  </Para>
  </Listitem>
  <Listitem>
  <Para>
    <Literal><command>make bootpfile</command></Literal>
  </Para>
  </Listitem>
  </Itemizedlist>
</Para>

<Para>
This creates a uncompressed kernel named <filename>bootpfile</filename> located
in <filename>arch/alpha/boot/</filename>. Note that this kernel is 
significantly larger than that produced by the aboot sources. 
</Para>
</Listitem>
<Listitem>
<Para>
Copy bootpfile to the bootp server's directory. With a default setup the tftp server would look in 
<filename>/tftpboot</filename> so copy <filename>bootpfile</filename> into
<filename>/tftpboot</filename>. 
  
</Para>
</Listitem>
</Orderedlist>
</Para>
</Sect3>


<Sect3>
<Title>Netboot using the aboot sources</Title> 
<Para>
<OrderedList>
<Listitem>
<Para>
Build aboot with with the command <command>make netboot</command>. 
</Para>
</Listitem>
<Listitem>
<Para>
Make sure the kernel that you want to boot has been built already. 

By default, the aboot Makefile uses the kernel in 
<filename>/usr/src/linux/arch/alpha/boot/vmlinux.gz</filename> (edit the 
Makefile if you want to use a different path). The result of 
<command>make netboot</command> is a file called 
<filename>vmlinux.bootp</filename> 
    which contains aboot and the Linux kernel, ready for network booting. 
</Para>
</Listitem>
<Listitem>
<Para>

Copy <filename>vmlinux.bootp</filename> to the bootp server's directory. In the
example above, you'd copy it into <filename>/tftpboot/vmlinux.bootp</filename>.
</Para>
</Listitem>
</Orderedlist>
</Para>
<Para>
Next, power up the client machine and boot it, specifying the Ethernet adapter as the boot device. Typically, SRM calls the DEC based Ethernet adapter ewa0 and the Intel based adapter
eia0, so to boot from that device, you'd use the command: 
<screen>
      >>> boot ewa0 
</screen>
</Para>
<Para>
The -fi and -fl options can be used as usual. For example, 
</Para>
<Para>
<screen>
      >>> boot ewa0 -fi  bootpfile -fl "root=/dev/hda2" 
</screen>
</Para>
<Para>
In particular, you can ask aboot to prompt for Linux kernel arguments by specifying the option 
-fl i .  
</Para>
</Sect3>
<Sect3>
<Title>Updating the SRM console through BOOTP</Title>
<Para>
Updating your SRM console over the network through BOOTP is just as easy as booting the Linux kernel
in the same manner. The hardware prerequisites are the same as netbooting Linux.
</Para>

<Para>
First you have to obtain an SRM image that is able to BOOTP over the network. These images normally
have a .exe extension. For DEC/Compaq/HP Alpha products these images can be found at 
<ulink url="ftp://ftp.digital.com/pub/Digital/Alpha/firmware/">ftp://ftp.digital.com/pub/Digital/Alpha/firmware/</ulink>; you will need version 5.8 or later. For access you might need to use an proper ftp client. You can also find these files on the Alpha Systems Firmware Update CD-ROM. <ulink url="http://www.api-networks.com">API NetWorks</ulink> did not offer any net bootable SRM image.
</Para>

<!--
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html [openvms ask the wizard link]
or
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/index.html [alpha site left nav firmware link]
but I think they are the same location. 
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/archive/ for old images
-->

<Para>
For example say you had a DS20 and wanted to update it's firmware over the network using BOOTP. You would have to,
<OrderedList>
<Listitem><Para>Get the correct firmware image for the DS20 that supported BOOTP execution which in this case the filename is 
<filename>ds20_v5_8.exe</filename> from  <ulink url="ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/">ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/</ulink>.</Para>
</Listitem>
<Listitem>
<Para>Copy the file to the <filename>/tftpboot</filename> folder located on the
BOOTP server.</Para>  <!-- FIXME Folder vs. Directory -->
</Listitem>
</OrderedList>
</Para>

<Para>
To execute the update from SRM you would do the following:
</Para>
<Screen>>>> b ewa0 -fi ds20_v5_8.exe</Screen>  
<Para>
SRM would then proceed to upgrade the firmware in the same fashion as if you had done the firmware update from a CD.
</Para>

</Sect3>

</Sect2>



<Sect2>
<Title>Partitioning Disks</Title>

<Sect3>
<Title>What is a disklabel?</Title>

<Para>
A disk label is a partition table. Unfortunately, there are several
formats the partition table can take, depending on the operating
system.
</Para>

<Para>
DOS partition tables are the standard used by Linux and
Windows. AlphaBIOS systems and every Linux kernel can read DOS
partition tables. Unfortunately, the SRM console's boot sector format
overlaps with parts of the DOS partition table on disk, and therefore
DOS partition tables cannot be used with SRM.
</Para>

<Para>
BSD disklabels are used by several variants of Unix, including
<productname>Tru64</productname>.  SRM's boot block does not conflict with
the BSD disklabel (in
fact, the BSD disklabel resides entirely within "reserved" areas of
the first sector), and Linux can use a BSD disklabel, provided that
support for BSD disklabels has been compiled into the kernel.
</Para>

<Para>
To boot from a disk using SRM, a BSD disklabel is required. If the
disk is not a boot disk, the BSD disklabel is not required. A BSD
disklabel can be created using fdisk, the standard Linux disk
partitioning tool.
</Para>

</Sect3>

<Sect3>
<Title>Partitioning the Easy Way: a DOS Disklabel</Title>

<Para>
The simplest way to partition your disk is to let your Linux installer
do it for you, for example by using Red Hat's disk druid or fdisk.  On
Red Hat 6.1, this will produce a valid BSD disklabel, but
<Emphasis>only</Emphasis> if the disk in question previously contained one.  In
most cases, this will produce a DOS disklabel.  It will be readable by
Linux, but you will not be able to boot from it via SRM.  For this
reason, you will probably want to create a BSD disklabel manually in
order to boot Linux
</Para>

</Sect3>

<Sect3>
<Title>Partitioning with a BSD Disklabel</Title>

<Para>

<OrderedList>
<ListItem>

<Para>
Start fdisk on the disk you're configuring
</Para>
</ListItem>
<ListItem>

<Para>
Choose to make a BSD disklabel - option 'b' (newer versions of
fdisk will detect existing BSD disklabels and automatically enter
disklabel mode)
</Para>
</ListItem>
<ListItem>

<Para>
You'll notice some things: Partitions are letters instead of
numbers, from a-h Partition 'c' covers the whole of the disk. This is
the convention, don't touch it.  While you can see it, note down the
disk parameters as you'll use them more often than with the
DOS-disklabel approach
</Para>
</ListItem>
<ListItem>

<Para>
Creating a new partition uses the same procedure as the
DOS-disklabel approach, except that the partitions are referred to by
letter instead of number. That is, 'n' to make a new partition
followed by the partition letter followed by the starting block
followed by the end block
</Para>
</ListItem>
<ListItem>

<Para>
Setting partition type is slightly different, because the
numbering scheme is different (1 is swap, 8 is ext2).
</Para>
</ListItem>
<ListItem>

<Para>
When you are finished, write ('w') and quit ('q') as normal.
</Para>
</ListItem>

</OrderedList>

</Para>

<Para>
There are some important catches that you must be aware of when
partitioning using a BSD disklabel:

<ItemizedList>
<ListItem>

<Para>
Partition 'a' should start about 1M into the disk: don't start
it at sector 1, try starting at sector 10 (for example). This leaves
plenty of space for writing the boot block (see below)
</Para>
</ListItem>
<ListItem>

<Para>
There is a bug in some versions of fdisk which makes the disk
look one sector bigger than it actually is.  The listing when you
create the BSD disklabel is correct.  The last sector of partition 'c'
is correct.  The default last sector when creating a new partition is
1 sector too big
</Para>
</ListItem>
<ListItem>

<Para>
Always adjust for this extra sector. This bug exists in the
version of fdisk shipped with Red Hat 6.0. Not making an adjustment
for this problem almost always leads to "Access beyond end of device"
errors from the Linux kernel.
</Para>
</ListItem>

</ItemizedList>

</Para>

<Para>
Once you have made a BSD disklabel, continue the installation. After
installation, you can write a boot block to your disk to make it
bootable from SRM.
</Para>

</Sect3>

</Sect2>

</Sect1>

<Sect1 id="SRM-sharingWithDEC">
<Title>Sharing a Disk With <productname>HP Tru64</productname></Title>

<Para>
Unfortunately, <productname>HP Tru64</productname> doesn't know anything about Linux, so sharing
a single disk between the two OSes is not entirely trivial.  However,
it is not a difficult task if you heed the tips in this section.  The
section assumes you are using <Literal remap="tt">aboot</Literal> version 0.5 or newer.
</Para>

<Sect2>
<Title>Partitioning the disk</Title>

<Para>
First and foremost: <Emphasis>never</Emphasis> use any of the Linux partitioning
programs (<Literal remap="tt">minlabel</Literal> or <Literal remap="tt">fdisk</Literal>) on a disk that is also
used by <productname>HP Tru64</productname>.  The Linux <Literal remap="tt">minlabel</Literal> program uses the same
partition table format as <productname>HP Tru64</productname> <Literal remap="tt">disklabel</Literal>, but there are
some incompatibilities in the data that <Literal remap="tt">minlabel</Literal> fills in, so
<productname>HP Tru64</productname> will simply refuse to accept a partition table generated by
<Literal remap="tt">minlabel</Literal>.  To setup a Linux <Literal remap="tt">ext2</Literal> partition under <productname>HP Tru64</productname>,
you'll have to change the disktab entry for your disk.  For the
purpose of this discussion, let's assume that you have an rz26 disk (a
common 1GB drive) on which you want to install Linux.  The disktab
entry under <productname>HP Tru64</productname> v3.2 looks like this (see file
<filename>/etc/disktab</filename>):

<Screen>
rz26|RZ26|DEC RZ26 Winchester:\
        :ty=winchester:dt=SCSI:ns#57:nt#14:nc#2570:\
        :oa#0:pa#131072:ba#8192:fa#1024:\
        :ob#131072:pb#262144:bb#8192:fb#1024:\
        :oc#0:pc#2050860:bc#8192:fc#1024:\
        :od#393216:pd#552548:bd#8192:fd#1024:\
        :oe#945764:pe#552548:be#8192:fe#1024:\
        :of#1498312:pf#552548:bf#8192:ff#1024:\
        :og#393216:pg#819200:bg#8192:fg#1024:\
        :oh#1212416:ph#838444:bh#8192:fh#1024:
</Screen>

</Para>

<Para>
The interesting fields here are <Literal remap="tt">o</Literal><Emphasis remap="it">?</Emphasis>, and
<Literal remap="tt">p</Literal><Emphasis remap="it">?</Emphasis>, where <Emphasis remap="it">?</Emphasis> is a letter in the range
<Literal remap="tt">a</Literal>-<Literal remap="tt">h</Literal> (first through 8-th partition).  The <Literal remap="tt">o</Literal>
value gives the starting offset of the partition (in sectors) and the
<Literal remap="tt">p</Literal> value gives the size of the partition (also in sectors).
See <Literal remap="tt">disktab</Literal>(4) for more info.  Note that <productname>HP Tru64</productname> likes to
define overlapping partitions.  For the entry above, the partition
layout looks like this (you can verify this by adding up the various
<Literal remap="tt">o</Literal> and <Literal remap="tt">p</Literal> values):

<Screen>
  a    	b      	  d    	      e	     	  f
|---|-------|-----------|-----------|-----------|

                        c
|-----------------------------------------------|

                     g                 h
            |-----------------|-----------------|
</Screen> <!-- FIXME This is screen? -->

</Para>

<Para>
<productname>HP Tru64</productname> insists that partition <Literal remap="tt">a</Literal> starts at offset 0 and that
partition <Literal remap="tt">c</Literal> spans the entire disk.  Other than that, you can
setup the partition table any way you like.
</Para>

<Para>
Let's suppose you have <productname>HP Tru64</productname> using partition <Literal remap="tt">g</Literal> and want to
install Linux on partition <Literal remap="tt">h</Literal> with partition <Literal remap="tt">b</Literal> being a
(largish) swap partition.  To get this layout without destroying the
existing <productname>HP Tru64</productname> partition, you need to set the partition types
explicitly.  You can do this by adding a <Literal remap="tt">t</Literal> field for each
partition.  In our case, we add the following line to the above
disktab entry.

<Screen>
	:ta=unused:tb=swap:tg=4.2BSD:th=resrvd8:
</Screen>

</Para>

<Para>
Now why do we mark partition <Literal remap="tt">h</Literal> as "reservd8" instead of "ext2"?
Well, <productname>HP Tru64</productname> doesn't know about Linux.  It so happens that partition
type "ext2" corresponds to a numeric value of 8, and <productname>HP Tru64</productname> uses the
string "reservd8" for that value.  Thus, in <productname>HP Tru64</productname> speak, "reservd8"
means "ext2".  OK, this was the hard part.  Now we just need to
install the updated disktab entry on the disk.  Let's assume the disk
has SCSI id 5.  In this case, we'd do:

<Screen>
# disklabel -rw /dev/rrz5c rz26
</Screen>

</Para>

<Para>
You can verify that everything is all right by reading back the
disklabel with <command>disklabel -r /dev/rrz5c</command>.  At this point, you
may want to reboot <productname>HP Tru64</productname> and make sure the existing <productname>HP Tru64</productname>
partition is still alive and well.  If that is the case, you can shut
down the machine and start with the Linux installation.  Be sure to
skip the disk partitioning step during the install.  Since we already
installed a good partition table, you should be able to proceed and
select the 8th partition as the Linux root partition and the 2nd
partition as the swap partition.  If the disk is, say, the second SCSI
disk in the machine, then the device name for these partitions would
be <filename>/dev/sdb8</filename> and <filename>/dev/sdb2</filename>,
respectively (note that
Linux uses letters to name the drives and numbers to name the
partitions, which is exactly reversed from what <productname>HP Tru64</productname> does; the
Linux scheme makes more sense, of course ;-).
</Para>

</Sect2>

<Sect2>
<Title>Installing <Literal remap="tt">aboot</Literal></Title>

<Para>
<Emphasis>First big caveat</Emphasis>: with the SRM firmware, you can boot one and
only one operating system per disk.  For this reason, it is generally
best to have at least two SCSI disks in a machine that you want to
dual-boot between Linux and <productname>HP Tru64</productname>.  Of course, you could also boot
Linux from a floppy if speed doesn't matter or over the network, if
you have a <Literal remap="tt">bootp</Literal>-capable server.  But in this section we assume
you want to boot Linux from a disk that contains one or more <productname>HP Tru64</productname>
partitions.
</Para>

<Para>
<Emphasis>Second big caveat</Emphasis>: installing <Literal remap="tt">aboot</Literal> on a disk shared with
<productname>HP Tru64</productname> renders the first and third partition unusable (since those
<Emphasis>must</Emphasis> have a starting offset of 0).  For this reason, we recommend
that you change the size of partition <Literal remap="tt">a</Literal> to something that is just
big enough to hold <Literal remap="tt">aboot</Literal> (1MB should be plenty).
</Para>

<Para>
Once these two caveats are taken care of, installing <Literal remap="tt">aboot</Literal> is
almost as easy as usual: since partition <Literal remap="tt">a</Literal> and <Literal remap="tt">c</Literal> will
overlap with <Literal remap="tt">aboot</Literal>, we need to tell <Literal remap="tt">swriteboot</Literal> that this is
indeed OK.  We can do this under Linux with a command line of the
following form (again, assuming we're trying to install <Literal remap="tt">aboot</Literal> on
the second SCSI disk):

<Screen>
# swriteboot -f1 -f3 /dev/sdb bootlx
</Screen>

</Para>

<Para>
The <Literal remap="tt">-f1</Literal> means that we want to force writing 
<filename>bootlx</filename> even
though it overlaps with partition 1.  The corresponding applies for
partition 3.
</Para>

<Para>
This is it.  You should now be able to shutdown the system and boot
Linux from the harddisk.  In our example, the SRM command line to do
this would be:

<Screen>
&#62;&#62;&#62; boot dka5 -fi 8/vmlinux.gz -fl root=/dev/sdb8
</Screen>

</Para>

</Sect2>

</Sect1>

<Sect1 id="SRM-Distributions">
<Title>Installation of Distributions</Title>

<Sect2>
<Title>RedHat 6.0, 6.1 and 6.2</Title>

<Sect3>
<Title>Installation from the Red Hat 6.0, 6.1 or 6.2 CD</Title>

<Para>
Red Hat have made their distribution CD bootable from SRM console
<FOOTNOTE>

<Para>
Please note that through the official RedHat CD-ROM is SRM
bootable, copies made by various other companies may not be
bootable.
</Para>

</FOOTNOTE>

To start an installation, put the CD in and type
the following:

<Screen>
&#62;&#62;&#62; boot srm-device -file kernels/generic.gz -flags root=linux-device
</Screen>

</Para>

<Para>
In the above, the SRM device name and Linux device name for your
CD-ROM drive are needed.  For Example if the machine had an IDE CD-ROM
installed as primary master the command would look like this:

<Screen>
&#62;&#62;&#62; boot dqa0 -file kernels/generic.gz -flags "root=/dev/hda"
</Screen>

</Para>

<Para>
See the section on <XRef LinkEnd="device-naming"> conventions if you don't know what these are.
</Para>

</Sect3>

</Sect2>

<!-- FIXME Newer RedHat ?? -->

<Sect2>
<Title>SuSE 6.1</Title>

<Sect3>
<Title>Installation from the SuSE 6.1 CD</Title>

<Para>
The SuSE 6.1 CD is not bootable from SRM console. SuSE have an
alternative approach which involves creating two boot floppies, the
images of which are included on the CD.  The boot disks can be created
in various ways, depending on the systems you have available
</Para>

<Para>
Writing the boot disks from a linux system
The command to use is dd. From the mount-point of SuSE CD 1, the commands are:

<Screen>
# dd if=disks/aboot of=/dev/fd0
# dd if=disks/install of=/dev/fd0
</Screen>

</Para>

<Para>
For writing the boot disks from a windows system, the command to use
is rawrite. It is available on the CD.

<Screen>
 D:\tools\&#62; rawrite
</Screen>

</Para>

<Para>
The program then prompts for input disk image and output disk
drive. Run this command once for each of the disk images as shown
above.
</Para>

<Para>
Starting the SuSE installer from the boot disks
With the floppy disk made from the aboot image in place, type:

<Screen>
&#62;&#62;&#62; boot dva0 -file vmlinux.gz -flags "root=/dev/fd0 load_ramdisk=1"
</Screen>

</Para>

<Para>
This will start the kernel, prompt you for the second boot disk, and start the installer
</Para>

</Sect3>

</Sect2>

<Sect2>
<Title>SuSE 6.3</Title>

<Sect3>
<Title>Installation from the SuSE 6.3 CD</Title>

<Para>
The SuSE 6.3 CD-ROM is SRM bootable much like the RedHat 6.0 and 6.1 CD-ROMs. The best way
to start the install from SRM is to use the following command:

<Screen>
&#62;&#62;&#62; boot srm-device -flags 0
</Screen>

</Para>

<Para>
In the above, the SRM device names for your
CD-ROM drive is needed.  For example if the machine had an IDE CD-ROM
installed as primary master the command would look like this:

<Screen>
&#62;&#62;&#62; boot dqa0 -flags 0
</Screen>

SuSE has added support to aboot to allow it to load initrd files. The above command will from the
CD-ROM drive and use config number 0 from the <filename>/etc/aboot.conf</filename> file. For other variations
on this refer to the SuSE installation guide.
</Para>

</Sect3>

</Sect2>
<!-- FIXME Newer RedHat ?? -->
<!-- FIXME Debian ??  -->

</Sect1>

<Sect1 id="SRM-history">
<Title>Document History</Title>
<para>
v0.8.1 14th February 2004 Updated by Helge Kreutzmann <email>kreutzm@physik.uni-hannover.de</email>
</para>
<ItemizedList>
<listitem>
<para>
Introduced more SGML-Tags, updated DocBook-Version
</para>
</listitem>
<listitem>
<para>
Minor typographic corrections (e.g., whitespaces)
</para>
</listitem>
<listitem>
<para>
Fixed some (outdated) URLS
</para>
</listitem>
</ItemizedList>
<Para>
v0.8 9th November 2000 Changed from Rich Payne <email>rdp@alphalinux.org</email>
<ItemizedList>
<ListItem>
<Para>
 Added section on SRM Device names
</Para>
</ListItem>

<ListItem>
<Para>
 Many spelling/grammer fixes.
</Para>
</ListItem>

</ItemizedList>
</Para>

<Para>
v0.7.1 6th November 2000 Changes from Peter Petrakis <email>ppetrakis@alphalinux.org</email>

<ItemizedList>
<ListItem>

<Para>
 Cleaned up netbooting section. Avoid duplicate information.
</Para>
</ListItem>
<ListItem>

<Para>
 Added DHCP/BOOTP server configuration section. 
</Para>
</ListItem>

<ListItem>
<Para>
 Added SRM netbooting section.
</Para>
</ListItem>

<ListItem>
<Para>
 Put the older bootpd configuration in it's own section and elaborated on it. 
</Para>
</ListItem>

</ItemizedList>
</Para>


<Para>
v0.7 10th July 2000 Changes from Rich Payne <email>rdp@alphalinux.org</email>

<ItemizedList>
<ListItem>

<Para>
 Updated for RedHat 6.2
</Para>
</ListItem>
<ListItem>

<Para>
 Fixed aboot link for alphalinux.org and added CVS information.
</Para>
</ListItem>

<ListItem>
<Para>
 Added additional netboot information from Peter Petrakis <email>ppetrakis@alphalinux.org</email>
</Para>
</ListItem>
</ItemizedList>
</Para>


<Para>
v0.6.1 21 March 2000 Changes from Rich Payne <email>rdp@alphalinux.org</email>

<ItemizedList>
<ListItem>

<Para>
 Made the installation hints a new chapter
</Para>
</ListItem>
<ListItem>

<Para>
 Added information on Netbooting
</Para>
</ListItem>
<ListItem>

<Para>
 Added to the new section on RedHat 6.1 and BSD disklabels
</Para>
</ListItem>
<ListItem>

<Para>
 Removed David Mosberger-Tang's name from the authors list
</Para>
</ListItem>
<ListItem>

<Para>
 Marked a few of the feature as being in 0.6 only
</Para>
</ListItem>
<ListItem>

<Para>
 Added info for SuSE 6.3 and RedHat 6.1
</Para>
</ListItem>

</ItemizedList>

</Para>

<Para>
v0.6 3 March 2000 Changes and information from David Huggins-Daines
<email>dhd@linuxcare.com</email>

<ItemizedList>
<ListItem>

<Para>
Moved the notes on MILO vs. SRM to an "About this document" section
</Para>
</ListItem>
<ListItem>

<Para>
Added sections on switching to SRM, and basic SRM usage
</Para>
</ListItem>
<ListItem>

<Para>
Added section on the new interactive use of aboot
</Para>
</ListItem>
<ListItem>

<Para>
Updated the note on DOS partition tables to mention the Red Hat 6.1
installer's behavior.
</Para>
</ListItem>
<ListItem>

<Para>
Normalized the markup, and codified the conventions used for
user-entered commands.
</Para>
</ListItem>
<ListItem>

<Para>
Corrected the notes on BSD disklabels (SRM does <Emphasis>not</Emphasis>
read BSD disklabels, it's just that they don't conflict with the boot
block).
</Para>
</ListItem>

</ItemizedList>

</Para>

<Para>
v0.5.2 5 December 1999 Added comments and information from Stig Telfer
(<email>stig@alpha-processor.com</email>).

<ItemizedList>
<ListItem>

<Para>
Added chart on SRM to Linux name mappings
</Para>
</ListItem>
<ListItem>

<Para>
Added RedHat 6.0 and SuSE 6.1 installation information
</Para>
</ListItem>
<ListItem>

<Para>
Added Disk Partitioning Information
</Para>
</ListItem>

</ItemizedList>

</Para>

<Para>
v0.5.1 (Not Released) 13 November 1999 Took the original 0.5 document and updated several parts:
</Para>

<Para>

<ItemizedList>
<ListItem>

<Para>
Update information on SRM booting from IDE devices
</Para>
</ListItem>
<ListItem>

<Para>
Fixed URL to aboot source
</Para>
</ListItem>
<ListItem>

<Para>
Update toc page to reflect MILO's future
</Para>
</ListItem>
<ListItem>

<Para>
Included information on bootdef&lowbar;dev and boot&lowbar;dev to chapter 3
</Para>
</ListItem>
<ListItem>

<Para>
Added this section
</Para>
</ListItem>

</ItemizedList>

</Para>

<Para>
v0.5 17 August 1996 - Original Document by David Mosberger-Tang
</Para>

</Sect1>

</Article>