README.html - pub/scm/linux/kernel/git/deller/palo - Git at Google

 <title> palo PA-Risc/Linux Boot Loader </title>
 <body bgcolor=white text=black vlink=navy alink=red link=blue>
 <h1 align=center> <i>palo</i> PA-Risc/Linux Boot Loader </h1>

 <h2 align=center>Building <i>palo</i></h2>
 <center><table border=1 bgcolor=yellow width=80%><tr><td>
 If you are self hosted on PA-RISC/LInux you should already have
 <i>palo</i> on your system.  Assuming you have <i>apt</i> configured
 you can always run "<tt>apt-get update; apt-get install palo</tt>" to
 obtain the latest released version.
 <p>
 If you need to build <i>palo</i> yourself, especially if you are
 cross-compiling on x86, skip to the end of this document.
 </table></center>

 <h2 align=center>Kernel Command Line</h2>
 <i>Palo</i>'s boot loader
 parses the kernel command line to determine which kernel
 to boot and optionally which ramdisk to load.
 Given a command line: '0/vmlinux&nbsp;...&nbsp;initrd=0/ramdisk&nbsp;...',
 palo uses '0/vmlinux' as the kernel file and '0/ramdisk' as
 the ramdisk file.
 Both names are composed of a partition number followed by a file
 path name within that partition.
 Partition number '0' is magic and refers to
 the kernel (ramdisk) you placed on the boot medium with '-k' ('-r').
 The path name on the '0' partition is ignored, '0/vmlinux' and '0/xyzzy'
 work identically, but it's a good idea to be consistent with what
 you'll call kernels and ramdisks on an ext2/3/4 partition.

 <h2 align=center>Creating and Maintaining Bootable Disks </h2>
 Partitioned media usually refers to disks, in this case disks partitioned
 by <i>fdisk</i> or a similar program.
 Normally your disk is properly initialized when you install
 PA-RISC Linux, but if you need to do it by hand here are some clues:

 <ul>
     <li>Use <i>fdisk</i> or something to (re)partition the disk.  When
     you are finished, the disk may need to have a partition of type
     "F0" somewhere in the first 2Gb.  This is where the boot loader
     and an optional kernel and ramdisk will be stored, so make it big
     enough for that -- at least 4Mb (I like 8-16Mb).  There must also
     be an ext2/3/4 partition within the first 2Gb where you'll store your
     Linux kernel.

     <li>If <i>fdisk</i> created the first partition at sector 2048,
     which is usual for modern fdisk, you don't need a F0 partition, so
     set all partition types to 82 swap or 83 linux and palo will place
     the boot loader inside the disk label.  You still need a /boot
     partition <2GB from the beginning of the disk formatted as
     ext2/3/4 where you keep your boot kernels and initial ramdisks.

     <p><li>Use <i>mke2fs</i> and <i>mkswap</i> as usual.

     <p><li>Mount the partition, copy your kernel and any other
     interesting files to it, unmount.

     <p><li>Use <i>palo</i> to make the disk bootable:
     <pre>
 	$ palo \
 	     -c "5/vmlinux HOME=/ TERM=linux console=tty" \
 	     -k path/to/vmlinux \
 	     -I /dev/your-disk</pre>
 <center><table border=1 bgcolor=yellow width=80%><tr><td>
 On a self-hosted system, you can accomplish the same thing by placing
 the following into <tt>/etc/palo.conf</tt>:
 <pre>--commandline=5/vmlinux HOME=/ TERM=linux console=tty
 --recoverykernel=/boot/vmlinux
 --init-partitioned=/dev/your-disk</pre>
 and running <i>palo</i>.
 </table></center>

     <p> <b>-k&nbsp;path/to/vmlinux</b> designates a kernel to be stored
     along with the boot loader in the "F0" partition.
     You can omit this if you want, since you'll usually be booting
     a kernel from an ext2/3/4 partition instead.  I like to have a kernel
     there just in case the ext2/3/4 one is lost for some reason.  I
     call it a <i><b>recovery kernel</b></i>.

     <p> <b>-c&nbsp;5/vmlinux</b> must be changed for your situation.  The
     number, 5, is the partition number of your ext2/3/4 partition as
     reported by fdisk, the same number you use
     when you mounted the partition (e.g., "mount /dev/sdb5 /mnt").
     "/vmlinux" is the path to
     your kernel executable within your ext2/3/4 partition.
     The special partition number "0" is used to load the "recovery"
     kernel which you placed into the "F0" partition with <b>-k</b>.

     <p><b>-I /dev/your-disk</b> tells <i>palo</i> to initialize the <i>palo</i> boot
     parameters on the drive rather than preserving any existing
     parameters.

     <p>Use '<tt>palo -?</tt>' or '<tt>palo --help</tt>' for more information.
 </ul>

 <p>You now have a partitioned bootable disk, try it!

 <p>There is no need to run <i>palo</i> when you change the
 kernel in your ext2/3/4 partition because it is located dynamically
 by the <i>palo</i> boot loader when you boot.  However there are probably
 some tasks which will again require <i>palo</i>.

 <p>Once you have a partitioned bootable disk, <i>palo</i>
 can be used to change the default command line or kernel or
 boot loader.  The most common task is probably changing the "recovery"
 kernel:
 <center><table border=5 bgcolor=red><tr><th><font color=white>The update (-U)
 feature is currently disabled, perhaps permanently.  The usual method
 for maintaining your disk is to edit /etc/palo.conf and rerun <i>palo</i>.
 </font></table></center>
     <pre>
 	./palo -k path/to/vmlinux -U /dev/your-disk</pre>
 or command line:
     <pre>
 	./palo -c "new command line" -U /dev/your-disk</pre>
 Which will normally be done in a self-hosted environment by
 editing /etc/palo.conf and re-running palo.
 Hopefully you won't need to use <i>palo</i> very often.
 <h2 align=center>Creating ISO9660 Bootable CD-ROMs</h2>
 Bootable CDs are often used for installation.
 In short the process is:
 <ol>
 <li>Master your CD image but don't burn it.
 <b>The image MUST contain the kernel(s), iplboot, and ramdisk file (if used).</b>
 <p><li>Run <i>palo</i> to make the image bootable:
     <pre>
 	./palo  -k path/to/vmlinux \
 		-b iplboot \
 		-c '0/vmlinux ....' \
 		-C your-iso-image</pre>
     <p><b>-C</b> tells <i>palo</i> to prepare a CD-ROM image.  'iplboot'
     and 'path/to/vmlinux' <b>must be exactly the same files</b> (same
     contents) you previously
     copied into the future root file system or <i>palo</i> will fail.
     I usually point those paths at the exact files in the directory
     from which I mastered the CD just to be sure.
 <p><li>Burn the CD and boot it.
 </ol>
 <p>CD-ROM support at the moment is a bit of a hack.  Here's how it
 works.
 <p><i>palo</i> currently treats CD-ROM as an unpartitioned sequential
 medium like tape or bootp.  Unlike other unpartitioned media, there
 is no room to store the kernel and bootloader (iplboot) near the
 start of the (ISO-standard) medium, so <i>palo</i> requires you
 to put those files
 into the ISO file system.  HP boot firmware requires the boot loader
 (iplboot) to be a multiple of 2k in length and be
 stored contiguously on a 2k boundary.  Luckily the ISO file system
 meets all these criteria except for the mod-2k length, which is achieved
 by padding iplboot.
 The palo bootloader (iplboot) requires requires the kernel to be stored
 contiguously (except when booting from ext2/3/4), and the ISO file system
 works well for this too.

 <p>When you run <i>palo</i>, it locates the boot loader and kernel
 (optionally ramdisk)
 files in the ISO file system by doing a raw search through the ISO
 image.  That's why the files in the ISO file system, and those named
 on the <i>palo</i> command line must be identical.
 Once found, pointers to those files are stored in the appropriate
 places in the boot headers.

 <p>Ideally <i>palo</i> and the boot loader would both understand
 the ISO file system, but that'll take more investment than I'm
 interested in supplying.  If anyone pursues this, note that I've
 had good luck leveraging code from <i>aboot</i>, one of the Alpha
 boot loaders.  I recommend starting with the ISO code from
 aboot-0.6 or later.

 <p>It may be possible to place a MS-DOS partition table on a CD-ROM
 therefore having an "F0" partition as on a hard disk, but I don't feel
 confident this would be understandable by, say, a Windows box.

 <h2 align=center>Some Newer Features</h2>
 During installation testing several annoyances were discovered
 which have been partly addressed
 by two new features:
 <ol>
 <li>HP machines can use either a serial or a graphics boot console.
 <i>Palo</i> now figures out which one you are using and adds
 the appropriate "console=" to the end of the boot command line.
 It is only added if you don't already have "console=" in your
 boot command line.

 <p><li>It would be nice to have a single bootable image, especially
 when using CD-ROM.  This requires proper console selection (see #1)
 and booting a 32-bit or 64-bit kernel as appropriate for the hardware.
 <i>Palo</i> can now place both a 32 and 64-bit kernel on sequential
 (or CD-ROM) media.  Simply use the <b>-k</b> (or <b>--recoverykernel</b>)
 option twice, once for each kernel.
 The <i>palo</i> boot loader examines the kernel name, which
 on sequential&CD-ROM is often "0/vmlinux", and if it ends in "32" or "64"
 <i>palo</i> boots the requested kernel.  However if the name does not
 end in "32" or "64", <i>palo</i> chooses a kernel based upon a
 recommendation by firmware, which is almost always the right thing.
 (Note that a 32-bit kernel will be chosen to a 64-bit one on hardware
 which can boot both.  Change the kernel name to 0/vmlinux64 if you
 want to force a 64-bit kernel.)
 </ol>

 <h2 align=center> Original Goals </h2>
 <ul>
     <li> #1 support target is PA/Linux on a disk by itself
     	 (another disk(s) may contain a standard HP-UX installation)
     <li> #2 support target is PA/Linux with kernel on sequential media such
 	 as tape or tftp/bootp (or CD-ROM??????)
     <li> #3 support target is PA/Linux kernel on HP-UX disk with
 	 second disk for PA/Linux file system.
 	 (NOTE this is currently impossible with the ELF32 compiler
 	 <font color=red>**This is now a non-goal**</font>
 	 )
     <li> Not a support target: dual-boot HP-UX/Linux systems with
 	 both Linux and HP-UX file systems on a single disk
     <li> Possibility: write mnttab into palo so you can boot with
 	"normal" path names on that machine.  If palo knew where
 	to find /etc/mnttab...
 </ul>
 <h2 align=center> Features </h2>
 PA/Linux partitioned hard disks:
 <ul>
     <li> can be read/written by current Linux boxes, expecially x86
     <li> can be read/written by IA-64 Linux boxes
     <li> are tolerated by IA-32 and IA-64 non-Linux boxes
     <li> are not understood by the HP-UX secondary boot loader
     <li> require no new disk partitioning tools
 </ul>
 <h2 align=center> Terminology </h2>
 <i>palo</i> is two programs, a <b>boot loader</b>, which is loaded by the
 HP firmware into memory and then executed, and <b>boot media management
 tool</b>, which initializes and updates bootable media such as disks.
 The <i>palo</i> boot loader is stored in a file called <b>iplboot</b>.
 "IPL" is HP jargon for Initial Program Loader.  It's mostly called
 "the palo boot loader" in this document.
 <p> The boot media management tool is called <b>palo</b>, just as
 on x86 the LILO boot media management tool is called <b>lilo</b>,
 though it's worth noting that <b>palo</b> doesn't usually need to be
 used every time you build a new kernel, as <b>lilo</b> does.
 <h2 align=center> Basic Media Format </h2>
 Bootable PA/Linux disks
 combine a standard MS-DOS partition table
 with the data required for HP firmware to locate its boot loader,
 all within the first 512-byte "sector" of the disk.
 Here is the detailed layout of the first 512 bytes of the disk.
 <b><i>Only these bytes can be depended upon!</i></b>
 The term "IPL" means Initial Program Loader e.g., boot loader in HP-ese.
 <pre>
 	Offset (hex)		Contents	Why

 	0			0x80		These two bytes denote
 	1			0x00		a LIF volume to HP firmware

 	f0-f3			IPL_ADDR	disk offset to beginning
 						of boot "IPL" loader.  Must
 						not be zero.  Must be a
 						multiple of 2kbytes.
 						Big endian.

 	f4-f7			IPL_SIZE	Size of boot loader in bytes.
 						Must be a multiple of 2kbytes.
 						Big endian.

 	f8-f11			IPL_ENTRY	Offset from the beginning
 						of the boot loader to its
 						entry point.  This really
 						better be a multiple of 4bytes.
 						Big endian.

 	1b0-1ff			P-TABLE		DOS partition table, managed
 						by fdisk.
 </pre>

 Information about the kernel, command line, and ramdisk, is
 sandwiched between the LIF magic number and the IPL_ADDR.  Check out
 <b>struct firstblock</b> in
 <tt>common.h</tt> for the details.

 The boot program must be located
 <b><i>within the first 2 Gb of the boot medium</i></b>
 (a limitation of older machines, which might not be permanent).

 <p><i>palo</i> works with both un-partitioned (usually sequential) media
 such as tapes, and partitioned (usually random-access) media such
 as disks.  The media format for un-partitioned media is described first
 since it is a subset of the format for partitioned media.
 In the remaining discussion, the term sequential is synonymous with
 un-partitioned, and random-access is synonymous with partitioned
 media.  This restriction is not present in the <i>palo</i> software however.

 <p>On <b>unpartitioned</b> media,
 the partition table shown in the previous figure is unused and
 set to values which will not be mistaken for a partition table.
 The boot loader program is stored starting
 at 2kbytes from the beginning of the medium and is followed
 by the kernel file and optional ramdisk file.

 <p>On <b>partitioned</b> media, which is usually random-access, for example
 disks, the boot loader program must be stored in an area protected
 from disk management software, and often cannot be located at the
 first 2kbyte boundary as on sequential media.
 <i>palo</i> therefore places
 the boot loader, and optionally a kernel and ramdisk,
 in a special partition,
 created by <i>fdisk</i>, of type <b>F0</b>.
 HP-UX firmware requires the boot program to be stored on the boot
 medium starting on a multiple
 of 2kbytes, whereas the <b>F0</b> partition might start on a 512-byte
 sector boundary.  The boot program starts within the <b>F0</b> partition
 on the first 2k boundary, which may be up to 3 sectors from the start
 of the partition.

 <p>The format of the boot loader, kernel, and ramdisk are identical
 to the sequential case except that some padding is added in order
 that somewhat larger kernels and boot loaders can be added later
 without re-writing the rest of the F0 partition (this feature may
 not yet be supported by <i>palo</i> however).

 <p>On partitioned media, <i>palo</i> can load a kernel from any
 ext2/3/4-formatted partition which falls within the first 2G of the
 medium, in addition to having a "sequential" kernel, perhaps best seen
 as a recovery kernel, within the <b>F0</b> partition.


 <h2 align=center>Really Building <i>palo</i></h2>
 In the source directory type 'make'.  On x86 you will need the
 PA-RISC cross compilers installed and in your $PATH.
 <p>
 You can use "<tt>make DESTDIR=/ install</tt>" to install <i>palo</i>
 in the normal location.  On x86 the cross compilers are usually
 in "<tt>/opt/palinux</tt>" so I use
 "<tt>make DESTDIR=/opt/palinux install</tt>".
 Note that the <i>palo</i> executable goes into "<tt>DESTDIR/<b>sbin</b></tt>"
 which you may want to add to your $PATH.
 <p>
 <i>Palo</i> can also be built in the normal way as a Debian package
 though it cannot be cross-compiled as a Debian package.
	<title> palo PA-Risc/Linux Boot Loader </title>
	<body bgcolor=white text=black vlink=navy alink=red link=blue>
	<h1 align=center> <i>palo</i> PA-Risc/Linux Boot Loader </h1>

	<h2 align=center>Building <i>palo</i></h2>
	<center><table border=1 bgcolor=yellow width=80%><tr><td>
	If you are self hosted on PA-RISC/LInux you should already have
	<i>palo</i> on your system. Assuming you have <i>apt</i> configured
	you can always run "<tt>apt-get update; apt-get install palo</tt>" to
	obtain the latest released version.
	<p>
	If you need to build <i>palo</i> yourself, especially if you are
	cross-compiling on x86, skip to the end of this document.
	</table></center>

	<h2 align=center>Kernel Command Line</h2>
	<i>Palo</i>'s boot loader
	parses the kernel command line to determine which kernel
	to boot and optionally which ramdisk to load.
	Given a command line: '0/vmlinux ... initrd=0/ramdisk ...',
	palo uses '0/vmlinux' as the kernel file and '0/ramdisk' as
	the ramdisk file.
	Both names are composed of a partition number followed by a file
	path name within that partition.
	Partition number '0' is magic and refers to
	the kernel (ramdisk) you placed on the boot medium with '-k' ('-r').
	The path name on the '0' partition is ignored, '0/vmlinux' and '0/xyzzy'
	work identically, but it's a good idea to be consistent with what
	you'll call kernels and ramdisks on an ext2/3/4 partition.

	<h2 align=center>Creating and Maintaining Bootable Disks </h2>
	Partitioned media usually refers to disks, in this case disks partitioned
	by <i>fdisk</i> or a similar program.
	Normally your disk is properly initialized when you install
	PA-RISC Linux, but if you need to do it by hand here are some clues:

	<ul>
	<li>Use <i>fdisk</i> or something to (re)partition the disk. When
	you are finished, the disk may need to have a partition of type
	"F0" somewhere in the first 2Gb. This is where the boot loader
	and an optional kernel and ramdisk will be stored, so make it big
	enough for that -- at least 4Mb (I like 8-16Mb). There must also
	be an ext2/3/4 partition within the first 2Gb where you'll store your
	Linux kernel.

	<li>If <i>fdisk</i> created the first partition at sector 2048,
	which is usual for modern fdisk, you don't need a F0 partition, so
	set all partition types to 82 swap or 83 linux and palo will place
	the boot loader inside the disk label. You still need a /boot
	partition <2GB from the beginning of the disk formatted as
	ext2/3/4 where you keep your boot kernels and initial ramdisks.

	<p><li>Use <i>mke2fs</i> and <i>mkswap</i> as usual.

	<p><li>Mount the partition, copy your kernel and any other
	interesting files to it, unmount.

	<p><li>Use <i>palo</i> to make the disk bootable:
	<pre>
	$ palo \
	-c "5/vmlinux HOME=/ TERM=linux console=tty" \
	-k path/to/vmlinux \
	-I /dev/your-disk</pre>
	<center><table border=1 bgcolor=yellow width=80%><tr><td>
	On a self-hosted system, you can accomplish the same thing by placing
	the following into <tt>/etc/palo.conf</tt>:
	<pre>--commandline=5/vmlinux HOME=/ TERM=linux console=tty
	--recoverykernel=/boot/vmlinux
	--init-partitioned=/dev/your-disk</pre>
	and running <i>palo</i>.
	</table></center>

	<p> <b>-k path/to/vmlinux</b> designates a kernel to be stored
	along with the boot loader in the "F0" partition.
	You can omit this if you want, since you'll usually be booting
	a kernel from an ext2/3/4 partition instead. I like to have a kernel
	there just in case the ext2/3/4 one is lost for some reason. I
	call it a <i><b>recovery kernel</b></i>.

	<p> <b>-c 5/vmlinux</b> must be changed for your situation. The
	number, 5, is the partition number of your ext2/3/4 partition as
	reported by fdisk, the same number you use
	when you mounted the partition (e.g., "mount /dev/sdb5 /mnt").
	"/vmlinux" is the path to
	your kernel executable within your ext2/3/4 partition.
	The special partition number "0" is used to load the "recovery"
	kernel which you placed into the "F0" partition with <b>-k</b>.

	<p><b>-I /dev/your-disk</b> tells <i>palo</i> to initialize the <i>palo</i> boot
	parameters on the drive rather than preserving any existing
	parameters.

	<p>Use '<tt>palo -?</tt>' or '<tt>palo --help</tt>' for more information.
	</ul>

	<p>You now have a partitioned bootable disk, try it!

	<p>There is no need to run <i>palo</i> when you change the
	kernel in your ext2/3/4 partition because it is located dynamically
	by the <i>palo</i> boot loader when you boot. However there are probably
	some tasks which will again require <i>palo</i>.

	<p>Once you have a partitioned bootable disk, <i>palo</i>
	can be used to change the default command line or kernel or
	boot loader. The most common task is probably changing the "recovery"
	kernel:
	<center><table border=5 bgcolor=red><tr><th><font color=white>The update (-U)
	feature is currently disabled, perhaps permanently. The usual method
	for maintaining your disk is to edit /etc/palo.conf and rerun <i>palo</i>.
	</font></table></center>
	<pre>
	./palo -k path/to/vmlinux -U /dev/your-disk</pre>
	or command line:
	<pre>
	./palo -c "new command line" -U /dev/your-disk</pre>
	Which will normally be done in a self-hosted environment by
	editing /etc/palo.conf and re-running palo.
	Hopefully you won't need to use <i>palo</i> very often.
	<h2 align=center>Creating ISO9660 Bootable CD-ROMs</h2>
	Bootable CDs are often used for installation.
	In short the process is:
	<ol>
	<li>Master your CD image but don't burn it.
	<b>The image MUST contain the kernel(s), iplboot, and ramdisk file (if used).</b>
	<p><li>Run <i>palo</i> to make the image bootable:
	<pre>
	./palo -k path/to/vmlinux \
	-b iplboot \
	-c '0/vmlinux ....' \
	-C your-iso-image</pre>
	<p><b>-C</b> tells <i>palo</i> to prepare a CD-ROM image. 'iplboot'
	and 'path/to/vmlinux' <b>must be exactly the same files</b> (same
	contents) you previously
	copied into the future root file system or <i>palo</i> will fail.
	I usually point those paths at the exact files in the directory
	from which I mastered the CD just to be sure.
	<p><li>Burn the CD and boot it.
	</ol>
	<p>CD-ROM support at the moment is a bit of a hack. Here's how it
	works.
	<p><i>palo</i> currently treats CD-ROM as an unpartitioned sequential
	medium like tape or bootp. Unlike other unpartitioned media, there
	is no room to store the kernel and bootloader (iplboot) near the
	start of the (ISO-standard) medium, so <i>palo</i> requires you
	to put those files
	into the ISO file system. HP boot firmware requires the boot loader
	(iplboot) to be a multiple of 2k in length and be
	stored contiguously on a 2k boundary. Luckily the ISO file system
	meets all these criteria except for the mod-2k length, which is achieved
	by padding iplboot.
	The palo bootloader (iplboot) requires requires the kernel to be stored
	contiguously (except when booting from ext2/3/4), and the ISO file system
	works well for this too.

	<p>When you run <i>palo</i>, it locates the boot loader and kernel
	(optionally ramdisk)
	files in the ISO file system by doing a raw search through the ISO
	image. That's why the files in the ISO file system, and those named
	on the <i>palo</i> command line must be identical.
	Once found, pointers to those files are stored in the appropriate
	places in the boot headers.

	<p>Ideally <i>palo</i> and the boot loader would both understand
	the ISO file system, but that'll take more investment than I'm
	interested in supplying. If anyone pursues this, note that I've
	had good luck leveraging code from <i>aboot</i>, one of the Alpha
	boot loaders. I recommend starting with the ISO code from
	aboot-0.6 or later.

	<p>It may be possible to place a MS-DOS partition table on a CD-ROM
	therefore having an "F0" partition as on a hard disk, but I don't feel
	confident this would be understandable by, say, a Windows box.

	<h2 align=center>Some Newer Features</h2>
	During installation testing several annoyances were discovered
	which have been partly addressed
	by two new features:
	<ol>
	<li>HP machines can use either a serial or a graphics boot console.
	<i>Palo</i> now figures out which one you are using and adds
	the appropriate "console=" to the end of the boot command line.
	It is only added if you don't already have "console=" in your
	boot command line.

	<p><li>It would be nice to have a single bootable image, especially
	when using CD-ROM. This requires proper console selection (see #1)
	and booting a 32-bit or 64-bit kernel as appropriate for the hardware.
	<i>Palo</i> can now place both a 32 and 64-bit kernel on sequential
	(or CD-ROM) media. Simply use the <b>-k</b> (or <b>--recoverykernel</b>)
	option twice, once for each kernel.
	The <i>palo</i> boot loader examines the kernel name, which
	on sequential&CD-ROM is often "0/vmlinux", and if it ends in "32" or "64"
	<i>palo</i> boots the requested kernel. However if the name does not
	end in "32" or "64", <i>palo</i> chooses a kernel based upon a
	recommendation by firmware, which is almost always the right thing.
	(Note that a 32-bit kernel will be chosen to a 64-bit one on hardware
	which can boot both. Change the kernel name to 0/vmlinux64 if you
	want to force a 64-bit kernel.)
	</ol>

	<h2 align=center> Original Goals </h2>
	<ul>
	<li> #1 support target is PA/Linux on a disk by itself
	(another disk(s) may contain a standard HP-UX installation)
	<li> #2 support target is PA/Linux with kernel on sequential media such
	as tape or tftp/bootp (or CD-ROM??????)
	<li> #3 support target is PA/Linux kernel on HP-UX disk with
	second disk for PA/Linux file system.
	(NOTE this is currently impossible with the ELF32 compiler
	<font color=red>This is now a non-goal</font>
	)
	<li> Not a support target: dual-boot HP-UX/Linux systems with
	both Linux and HP-UX file systems on a single disk
	<li> Possibility: write mnttab into palo so you can boot with
	"normal" path names on that machine. If palo knew where
	to find /etc/mnttab...
	</ul>
	<h2 align=center> Features </h2>
	PA/Linux partitioned hard disks:
	<ul>
	<li> can be read/written by current Linux boxes, expecially x86
	<li> can be read/written by IA-64 Linux boxes
	<li> are tolerated by IA-32 and IA-64 non-Linux boxes
	<li> are not understood by the HP-UX secondary boot loader
	<li> require no new disk partitioning tools
	</ul>
	<h2 align=center> Terminology </h2>
	<i>palo</i> is two programs, a <b>boot loader</b>, which is loaded by the
	HP firmware into memory and then executed, and <b>boot media management
	tool</b>, which initializes and updates bootable media such as disks.
	The <i>palo</i> boot loader is stored in a file called <b>iplboot</b>.
	"IPL" is HP jargon for Initial Program Loader. It's mostly called
	"the palo boot loader" in this document.
	<p> The boot media management tool is called <b>palo</b>, just as
	on x86 the LILO boot media management tool is called <b>lilo</b>,
	though it's worth noting that <b>palo</b> doesn't usually need to be
	used every time you build a new kernel, as <b>lilo</b> does.
	<h2 align=center> Basic Media Format </h2>
	Bootable PA/Linux disks
	combine a standard MS-DOS partition table
	with the data required for HP firmware to locate its boot loader,
	all within the first 512-byte "sector" of the disk.
	Here is the detailed layout of the first 512 bytes of the disk.
	<b><i>Only these bytes can be depended upon!</i></b>
	The term "IPL" means Initial Program Loader e.g., boot loader in HP-ese.
	<pre>
	Offset (hex) Contents Why

	0 0x80 These two bytes denote
	1 0x00 a LIF volume to HP firmware

	f0-f3 IPL_ADDR disk offset to beginning
	of boot "IPL" loader. Must
	not be zero. Must be a
	multiple of 2kbytes.
	Big endian.

	f4-f7 IPL_SIZE Size of boot loader in bytes.
	Must be a multiple of 2kbytes.
	Big endian.

	f8-f11 IPL_ENTRY Offset from the beginning
	of the boot loader to its
	entry point. This really
	better be a multiple of 4bytes.
	Big endian.

	1b0-1ff P-TABLE DOS partition table, managed
	by fdisk.
	</pre>

	Information about the kernel, command line, and ramdisk, is
	sandwiched between the LIF magic number and the IPL_ADDR. Check out
	<b>struct firstblock</b> in
	<tt>common.h</tt> for the details.

	The boot program must be located
	<b><i>within the first 2 Gb of the boot medium</i></b>
	(a limitation of older machines, which might not be permanent).

	<p><i>palo</i> works with both un-partitioned (usually sequential) media
	such as tapes, and partitioned (usually random-access) media such
	as disks. The media format for un-partitioned media is described first
	since it is a subset of the format for partitioned media.
	In the remaining discussion, the term sequential is synonymous with
	un-partitioned, and random-access is synonymous with partitioned
	media. This restriction is not present in the <i>palo</i> software however.

	<p>On <b>unpartitioned</b> media,
	the partition table shown in the previous figure is unused and
	set to values which will not be mistaken for a partition table.
	The boot loader program is stored starting
	at 2kbytes from the beginning of the medium and is followed
	by the kernel file and optional ramdisk file.

	<p>On <b>partitioned</b> media, which is usually random-access, for example
	disks, the boot loader program must be stored in an area protected
	from disk management software, and often cannot be located at the
	first 2kbyte boundary as on sequential media.
	<i>palo</i> therefore places
	the boot loader, and optionally a kernel and ramdisk,
	in a special partition,
	created by <i>fdisk</i>, of type <b>F0</b>.
	HP-UX firmware requires the boot program to be stored on the boot
	medium starting on a multiple
	of 2kbytes, whereas the <b>F0</b> partition might start on a 512-byte
	sector boundary. The boot program starts within the <b>F0</b> partition
	on the first 2k boundary, which may be up to 3 sectors from the start
	of the partition.

	<p>The format of the boot loader, kernel, and ramdisk are identical
	to the sequential case except that some padding is added in order
	that somewhat larger kernels and boot loaders can be added later
	without re-writing the rest of the F0 partition (this feature may
	not yet be supported by <i>palo</i> however).

	<p>On partitioned media, <i>palo</i> can load a kernel from any
	ext2/3/4-formatted partition which falls within the first 2G of the
	medium, in addition to having a "sequential" kernel, perhaps best seen
	as a recovery kernel, within the <b>F0</b> partition.


	<h2 align=center>Really Building <i>palo</i></h2>
	In the source directory type 'make'. On x86 you will need the
	PA-RISC cross compilers installed and in your $PATH.
	<p>
	You can use "<tt>make DESTDIR=/ install</tt>" to install <i>palo</i>
	in the normal location. On x86 the cross compilers are usually
	in "<tt>/opt/palinux</tt>" so I use
	"<tt>make DESTDIR=/opt/palinux install</tt>".
	Note that the <i>palo</i> executable goes into "<tt>DESTDIR/<b>sbin</b></tt>"
	which you may want to add to your $PATH.
	<p>
	<i>Palo</i> can also be built in the normal way as a Debian package
	though it cannot be cross-compiled as a Debian package.