mirror of https://github.com/tLDP/LDP
1130 lines
46 KiB
Plaintext
1130 lines
46 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<title>Alpha Miniloader Howto</title>
|
|
<author>David A. Rusling, <tt/david.rusling@reo.mts.dec.com/
|
|
<date>v0.84, 6 December 1996
|
|
<abstract>
|
|
This document describes the Miniloader, a program for Alpha
|
|
based systems that can be used to initialize the machine and
|
|
load Linux. The Alpha Linux Miniloader (to give it it's full
|
|
name) is also known as MILO.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect> Introduction <label id="intro-section">
|
|
|
|
<p>This document describes the Miniloader for Linux on Alpha AXP (MILO).
|
|
This firmware is used to initialize Alpha AXP based systems, load and
|
|
start Linux and, finally, provide PALcode for Linux.
|
|
|
|
<sect1> Copyright
|
|
|
|
<p>The Alpha Miniloader (MILO) HOWTO is copyright (C) 1995, 1996 David A Rusling.
|
|
|
|
<p><bf/Copyright./ Like all Linux HOWTO documents, it may be reproduced and distributed
|
|
in whole or in part, in any medium, physical or electronic, so long as
|
|
this copyright notice is retained on all copies.
|
|
Commercial redistribution is allowed and encouraged; however the author
|
|
would <em/like/ to be notified of such distributions.
|
|
You may translate this HOWTO into any language whatsover provided that
|
|
you leave this copyright statement and disclaimer intact, and that you append
|
|
a notice stating who translated the document.
|
|
|
|
<p><bf/Disclaimer./ While I have tried to include the most correct and
|
|
up to date information available to me, I cannot guarantee that usage
|
|
of information in this document does not result in loss of data or
|
|
equipment. I provide NO WARRENTY about the information in the HOWTO and
|
|
I cannot be made liable for any consequences resulting from using the
|
|
information in this HOWTO.
|
|
|
|
<sect1> New Versions of this Document
|
|
|
|
<p> The latest version of this document can be found in
|
|
<url
|
|
url="ftp://gatekeeper.dec.com/pub/Digital/Linux-Alpha/Miniloader/docs">
|
|
and David Mosberger-Tang is kind enough to include the html form of it
|
|
in his excellent Linux Alpha FAQ site
|
|
<url url="http://www.azstarnet.com/~axplinux">.
|
|
|
|
<sect> What is MILO? <label id="what-section">
|
|
|
|
<p>On Intel based PC systems, the BIOS firmware
|
|
sets up the system and then loads the image to be run from the boot
|
|
block of a DOS file system.
|
|
This is more or less what MILO does on an Alpha based system,
|
|
however there are several interesting differences between BIOS firmware and
|
|
MILO, not least of which is that MILO includes and
|
|
uses standard Linux device drivers unmodified.
|
|
MILO is firmware, unlike LILO, which relies on the BIOS firmware to
|
|
get itself loaded.
|
|
The main functional parts of MILO are:
|
|
|
|
<enum>
|
|
<item> PALcode,
|
|
<item> Memory set up code (builds page tables and turns on virtual addressing),
|
|
<item> Video code (BIOS emulation code and TGA (21030)),
|
|
<item> Linux kernel code. This includes real Linux
|
|
kernel code (for example, the interrupt handling) and
|
|
ersatz or mock Linux kernel,
|
|
<item> Linux block device drivers (for example, the floppy driver),
|
|
<item> File system support (ext2, MS-DOS and ISO9660),
|
|
<item> User inteface code (MILO),
|
|
<item> Kernel interface code (sets up the HWRPB and memory map for linux),
|
|
<item> NVRAM code for managing environment variables.
|
|
</enum>
|
|
|
|
<p>The following paragraphs describe these functional parts in more detail.
|
|
|
|
<p>PALcode can be thought of as a tiny software layer that tailors the
|
|
chip to a particular operating system.
|
|
It runs in a special mode (PALmode) which has certain restrictions but it
|
|
uses the standard Alpha instruction set with just five extra instructions.
|
|
In this way, the Alpha chip can run such diverse operating systems as
|
|
Windows NT, OpenVMS, Digital Unix and, of course, Linux.
|
|
The PALcode that MILO uses (and therefore Linux itself)
|
|
is, like the rest of MILO, freeware.
|
|
It is derived from Digital's Evaluation Board software example Digital Unix
|
|
PALcode..
|
|
The differences between the different PALcodes are because of
|
|
differences in address mapping and interrupt handling that
|
|
exist between the Alpha chips (21066 based systems have
|
|
a different I/O map to 21064+2107x systems) and different
|
|
Alpha based systems.
|
|
|
|
<p>For MILO to operate properly it needs to know what memory
|
|
is available, where Linux will eventually be running from and it must be
|
|
able to allocate temporary memory for the Linux device drivers.
|
|
The code maintains a memory map that has entries for permanent and temporary
|
|
allocated pages.
|
|
As it boots, MILO uncompresses itself into the correct place in
|
|
physical memory. When it passes control to the Linux kernel,
|
|
it reserves memory for the compressed version of itself, the PALcode
|
|
(which the kernel needs) and some data structures.
|
|
This leaves <tt/most/ of the memory in the system for Linux itself.
|
|
|
|
<p>The final act of the memory code is to set up and turn on virtual addressing
|
|
so that the data structures that Linux expects to see are at the correct place
|
|
in virtual memory.
|
|
|
|
<p>MILO contains video code that initialises and uses the video device
|
|
for the system.
|
|
It will detect and use a VGA device if there is one, otherwise
|
|
it will try to use a TGA (21030) video device.
|
|
Failing that, it will assume that there is no graphics device.
|
|
The BIOS emulation that the standard, pre-built, images include is
|
|
Digital's own BIOS emulation which supports most, if not all, of
|
|
the standard graphics devices available.
|
|
|
|
<p>Linux device drivers live within the kernel and expect
|
|
certain services from the kernel. Some of these services are provided directly
|
|
by Linux kernel code, for example the interrupt handling and some is provided
|
|
by kernel look-alike routines.
|
|
|
|
<p>MILO's most powerful
|
|
feature is that you can embed unaltered Linux device drivers into it.
|
|
This gives it the potential to support every device that Linux does.
|
|
MILO includes all of the block devices that are configured into the
|
|
Linux kernel that it is built against as well as a lot of the block device
|
|
code (for example, ll_rw_blk()).
|
|
|
|
<p>MILO loads the Linux kernel from real file systems rather
|
|
than from boot blocks and other strange places.
|
|
It understands MSDOS, EXT2 and ISO9660 filesystems.
|
|
Gzip'd files are supported and these are recommended, particularly if
|
|
you are loading from floppy which is rather slow.
|
|
MILO recognises these by their <em>.gz</em> suffix.
|
|
|
|
<p>Built into MILO is a simple keyboard driver which, together with
|
|
an equally simple video driver allows it to have a simple user interface.
|
|
That interface allows you to list file systems on configured devices, boot
|
|
Linux or run flash update utilities and set environment variables that
|
|
control the system's booting.
|
|
Like LILO, you can pass arguments to the Kernel.
|
|
|
|
<p>MILO must tell the Linux kernel what sort of system this is,
|
|
how much memory there is and which of that memory is free.
|
|
It does this using the HWRPB (Hardware Restart Parameter Block) data
|
|
structure and associated memory cluster descriptions.
|
|
These are placed at the appropriate place in virtual memory just before
|
|
control is passed to the Linux kernel.
|
|
|
|
<sect> Pre-Built Standard MILO Images.
|
|
|
|
<p>If you are planning to run Linux on a standard Alpha based system, then
|
|
there are pre-built "standard" MILO images that you might use.
|
|
These (along with the sources and other interesting stuff)
|
|
can be found in
|
|
<url
|
|
url="ftp://gatekeeper.dec.com/pub/Digital/Linux-Alpha/Miniloader">.
|
|
|
|
<p>The <tt>images</tt> subdirectory contains a directory per standard system
|
|
(eg AlphaPC64) with MILO images having the following naming convention:
|
|
|
|
<enum>
|
|
<item> <tt>MILO</tt> - Miniloader executable image, this image can be loaded in a
|
|
variety of ways,
|
|
<item> <tt>fmu.gz</tt> - Flash management utility,
|
|
<item> <tt>MILO.dd</tt> - Boot block floppy disk image.
|
|
These should be written using rawrite.exe or <tt>dd</tt> on Linux.
|
|
</enum>
|
|
|
|
<p>The <tt>test-images</tt>, like the <tt>images</tt> subdirectory
|
|
contains a directory per standard system. These images are somewhat
|
|
experimental but tend to contain all the latest features.
|
|
|
|
<sect> How To Build MILO <label id="build-section">
|
|
|
|
<p> You build MILO
|
|
seperately from the Kernel. As MILO requires parts of the kernel
|
|
to function (for example interrupt handling) you must first
|
|
configure and build the
|
|
kernel that matches with MILO that you want to build. Mostly this
|
|
means building the kernel with the same version number.
|
|
So, MILO-2.0.25.tar.gz will build against linux-2.0.25.tar.gz.
|
|
MILO <tt/may/ build against a higher version of the kernel, but there
|
|
again it may not.
|
|
Also, now that ELF shared libraries are fully supported, there are two
|
|
versions of the MILO sources.
|
|
To build under an ELF system you must first unpack the standard MILO sources
|
|
and then patch those sources with the same version numbered ELF patch.
|
|
In the remainder of this discussion,
|
|
I assume that your kernel sources and object files are stored in the
|
|
subtree at <tt>/usr/src/linux</tt> and that the linux kernel has been fully
|
|
built with the command <tt>make boot</tt>
|
|
|
|
<p<>To build MILO,
|
|
change your working directory to the MILO source directory and
|
|
invoke <tt/make/ with:
|
|
<tscreen><verb>
|
|
$ make KSRC=/usr/src/linux config
|
|
</verb></tscreen>
|
|
|
|
<p>Just like the Linux kernel, you will be asked a series of questions
|
|
|
|
<tscreen><verb>
|
|
Echo output to the serial port (MINI_SERIAL_ECHO) [y]
|
|
</verb></tscreen>
|
|
|
|
<p> It's a good idea to echo kernel printk to <tt>/dev/ttyS0</tt> if you can.
|
|
If you can (and want to), then type "y", otherwise "n".
|
|
All of the standard, pre-built, MILO images include serial port I/O using COM1.
|
|
|
|
<tscreen><verb>
|
|
Use Digital's BIOS emulation code (not free) (MINI_DIGITAL_BIOS_EMU) [y]
|
|
</verb></tscreen>
|
|
|
|
<p> This code is included as a library which is freely distributable
|
|
so long as it is used on an Alpha based system. The sources are
|
|
not available. If you answer <tt>n</tt> then the freeware
|
|
alternative BIOS emulation will be built. It's sources are included
|
|
with MILO.
|
|
Note that you cannot right now build choose Digital's BIOS emulation code in
|
|
an ELF system (the library is not yet ready) and so you must answer no to this
|
|
question.
|
|
|
|
|
|
<tscreen><verb>
|
|
Build PALcode from sources (Warning this is dangerous) (MINI_BUILD_PALCODE_FROM_SOURCES) [n]
|
|
</verb></tscreen>
|
|
|
|
<p>You should only do this if you have changed the PALcode sources, otherwise use the standard,
|
|
pre-built PALcode included with MILO.
|
|
|
|
<p>You are now all set to build the MILO image itself:
|
|
<tscreen><verb>
|
|
$ make KSRC=/usr/src/linux
|
|
</verb></tscreen>
|
|
|
|
<p>When the build has successfully completed, the MILO image is in the file called <tt>milo</tt>.
|
|
There are a lot of images called <tt>milo.*</tt>, these should be ignored.
|
|
|
|
<sect>How To Load MILO<label id="load-section">
|
|
|
|
<p>The most commonly supported method of loading MILO is from the Windows NT
|
|
ARC firmware as most shipping systems support this. However, there are
|
|
a wide variety of loading MILO. It may be loaded from:
|
|
<itemize>
|
|
<item> a failsafe boot block floppy,
|
|
<item> the Windows NT ARC firmware,
|
|
<item> Digital's SRM console,
|
|
<item> an Alpha Evaluation Board Debug Monitor,
|
|
<item> flash/ROM.
|
|
</itemize>
|
|
|
|
<sect1>Loading MILO from the Windows NT ARC firmware<label id="arc-section">
|
|
|
|
<p>Most, if not all, Alpha AXP based systems include the Windows NT
|
|
ARC firmware and this is the prefered method of booting MILO and thus
|
|
Linux. Once the Windows NT firmware is running and you have the correct
|
|
MILO image for your system, this method is completely generic.
|
|
|
|
<p>The Windows NT ARC firmware is an environment in which programs can run
|
|
and make callbacks into the firmware to perform actions. The Windows NT
|
|
OSLoader is a program that does exactly this. Linload.exe is a
|
|
much simpler program which does just enough to load and execute MILO.
|
|
It loads the appropriate image
|
|
file into memory at 0x00000000 and then makes a swap-PAL PALcall to
|
|
it.
|
|
MILO, like Linux, uses a different PALcode to Windows NT which is why the
|
|
swap has to happen.
|
|
MILO relocates itself to 0x200000 and continues on through the
|
|
PALcode reset entry point as before.
|
|
|
|
<p>Before you add a Linux boot option,
|
|
you will need to copy linload.exe and the appropriate MILO that you
|
|
wish to load to someplace that the Windows NT ARC firmware can read from.
|
|
In the following example, I assume that you are booting from a DOS format floppy
|
|
disk:
|
|
|
|
<enum>
|
|
<item> At the boot menu, select <tt/"Supplementary menu..."/
|
|
<item> At the <tt/"Supplementary menu"/, select <tt/"Set up the system..."/
|
|
<item> At the <tt/"Setup menu"/, select <tt/"Manage boot selection menu..."/
|
|
<item> In the <tt/"Boot selections menu"/, choose <tt/"Add a boot selection"/
|
|
<item> Choose <tt/"Floppy Disk 0"/
|
|
<item> Enter <tt/"linload.exe"/ as the osloader directory and name
|
|
<item> Say "yes" to the operating system being on the same partition
|
|
as the osloader
|
|
<item> Enter "\" as the operating system root directory
|
|
<item> I usually enter <tt/"Linux"/ as the name for this boot selection
|
|
<item> Say "No" you do not want to initialise the debugger at boot time
|
|
<item> You should now be back in the <tt/"Boot selections menu"/, choose the
|
|
<tt/"Change a boot selection option"/ and pick the selection you just created
|
|
as the one to edit
|
|
<item> Use the down arrow to get <tt/"OSLOADFILENAME"/ up and then type in the
|
|
name of the MILO image that you wish to use, for example <tt/"noname.arc"/
|
|
followed by return.
|
|
<item> Press ESC to get back to the <tt/"Boot Selections menu"/
|
|
<item> Choose <tt/"Setup Menu"/ (or hit ESC again) and choose <tt/"Supplementary menu,
|
|
and save changes"/ option
|
|
<item> ESC will get you back to the <tt/"Boot menu"/ and you can attempt to boot
|
|
MILO. If you do not want Linux as the first boot option, then you can
|
|
alter the order of the boot options in the <tt/"Boot selections menu"/.
|
|
</enum>
|
|
|
|
<p>At the end of all this, you should have a boot selection that looks something
|
|
like:
|
|
|
|
<tscreen><verb>
|
|
LOADIDENTIFIER=Linux
|
|
SYSTEMPARTITION=multi(0)disk(0)fdisk(0)
|
|
OSLOADER=multi(0)disk(0)fdisk(0)\linload.exe
|
|
OSLOADPARTITION=multi(0)disk(0)fdisk(0)
|
|
OSLOADFILENAME=\noname.arc
|
|
OSLOADOPTIONS=
|
|
</verb></tscreen>
|
|
|
|
<p>You can now boot MILO (and then Linux). You can load linload.exe
|
|
and MILO directly from a file system that Windows NT understands such as
|
|
NTFS or DOS on a hard disk.
|
|
|
|
<p>The contents <tt/OSLOADOPTIONS/ are passed to MILO which interprets
|
|
it as a command. So, in order to
|
|
boot Linux directly from Windows NT without pausing in MILO, you could
|
|
pass the following in <tt/OSLOADOPTIONS/:
|
|
|
|
<tscreen><verb>
|
|
boot sda2:vmlinux.gz root=/dev/sda2
|
|
</verb></tscreen>
|
|
|
|
<p>See <ref id="MILO-if-section" name="MILO's User Interface"> for more
|
|
information on the commands available.
|
|
|
|
<p>Another (rather sneaky) way of loading of loading MILO via the WNT ARC firmware
|
|
is to put MILO onto an MS-DOS floppy and call it <tt/fwupdate.exe/ and then choose
|
|
the "Upgrade Firmware" option.
|
|
|
|
<sect1>Loading MILO from the Evaluation Board Debug Monitor<label id="dbm-section">
|
|
|
|
<p>Evaluation boards (and often designs cloned from them) include
|
|
support for the Alpha Evaluation Board Debug Monitor. Consult
|
|
your system document before considering this method of booting
|
|
MILO. The following systems are <em/known/ to include Debug Monitor
|
|
support:
|
|
<itemize>
|
|
<item>AlphaPC64 (Section <ref id="pc64-section" name="AlphaPC64">)
|
|
<item>EB64+ (Section <ref id="eb64p-section" name="EB64+">)
|
|
<item>EB66+ (Section <ref id="eb66p-section" name="EB66+">)
|
|
<item>EB164 (Section <ref id="eb164-section" name="EB164">)
|
|
<item>PC164 (Section <ref id="pc164-section" name="PC164">)
|
|
</itemize>
|
|
|
|
<p>Before you consider this method, you should note that the early
|
|
versions of the Evaluation Board Debug Monitor did not include video
|
|
or keyboard drivers and so you must be prepared to connect another
|
|
system via the serial port so that you can use the Debug Monitor.
|
|
Its interface is very simple and typing help shows a whole heap
|
|
of commands. The ones that are most interesting include
|
|
the word <tt>boot</tt> or <tt>load</tt> in them.
|
|
|
|
<p>The Evaluation Board Debug Monitor can load an image either via the network
|
|
(netboot) or via a floppy (flboot). In either case, set the boot
|
|
address to 0x200000 (<tt/> bootadr 200000/) before booting the
|
|
image.
|
|
|
|
<p>If the image is on floppy (and note that only DOS formatted floppies
|
|
are supported), then you will need to type the following command:
|
|
|
|
<tscreen><verb>
|
|
AlphaPC64> flboot <MILO-image-name>
|
|
</verb></tscreen>
|
|
|
|
<sect1>Loading MILO from a Failsafe Boot Block Floppy<label id="bootblock-section">
|
|
|
|
<p>Only the AxpPCI33 is <em/known/ to include failsafe boot block
|
|
floppy support (Section < id="noname-section" name="Noname">).
|
|
|
|
<p>If you do not have a standard pre-built MILO .dd image,
|
|
then you may need to
|
|
build an SRM boot block floppy.
|
|
Once you have built MILO, you need to do the following on Digital Unix box:
|
|
|
|
<tscreen><verb>
|
|
fddisk -fmt /dev/rfd0a
|
|
cat mboot bootm > /dev/rfd0a
|
|
disklabel -rw rfd0a 'rx23' mboot bootm
|
|
</verb></tscreen>
|
|
|
|
<p>Or on a Linux box:
|
|
|
|
<tscreen><verb>
|
|
cat mboot bootm > /dev/fd0
|
|
</verb></tscreen>
|
|
|
|
<p> If you have a standard MILO image available (say <tt>MILO.dd</tt>)
|
|
then you would build a boot block floppy using the following command:
|
|
|
|
<tscreen><verb>
|
|
dd if=MILO.dd of=/dev/fd0
|
|
</verb></tscreen>
|
|
|
|
<sect1>Loading MILO from Flash<label id="flash_section">
|
|
|
|
<p>There are a number of systems where MILO can be blown into flash
|
|
and booted directly (instead of via the Windows NT ARC firmware):
|
|
<itemize>
|
|
<item>AlphaPC64 (Section <ref id="pc64-section" name="AlphaPC64">)
|
|
<item>Noname (Section <ref id="noname-section" name="Noname">)
|
|
<item>EB66+ (Section <ref id="eb66p-section" name="EB66+">)
|
|
<item>EB164 (Section <ref id="eb164-section" name="EB164">)
|
|
<item>PC164 (Section <ref id="pc164-section" name="PC164">)
|
|
</itemize>
|
|
|
|
<sect1>Loading MILO from the SRM Console<label id="srm_section">
|
|
|
|
<p>The SRM (short for System Reference Manual) Console knows nothing about filesystems or disk-partitions,
|
|
it simply expects that the secondary bootstrap loader occupies a consecutive range of
|
|
physical disk sectors starting from a given offset. The information describing
|
|
the secondary bootstrap loader (its size and offset) is given in the first 512
|
|
byte block. To load MILO via the SRM you must generate that structure on a
|
|
device which the SRM can access (such as a floppy disk).
|
|
This is what <tt/mboot/ and <tt/bootm/, <tt/mboot/ is the first block (or
|
|
boot description) and <tt/mboot/ is the <tt/MILO/ image rounded up to a
|
|
512 byte boundary.
|
|
|
|
<p> To load MILO from a boot block device, either build <tt/mboot/
|
|
and <tt/bootm/ and push them onto the boot device
|
|
using the following command:
|
|
|
|
<tscreen><verb>
|
|
$ cat mboot bootm > /dev/fd0
|
|
</verb></tscreen>
|
|
|
|
Or, grab the appropriate <tt/MILO.dd/ from a web site and write it onto the
|
|
boot device using either <tt/RAWRITE.EXE/ or <tt/dd/.
|
|
|
|
<p> Once you have done that you can boot the SRM console and use one of its
|
|
many commands to boot MILO. For example, to boot MILO from a boot block floppy
|
|
you would use the following command:
|
|
|
|
<tscreen><verb>
|
|
>>>boot dva0
|
|
(boot dva0.0.0.0.1 -flags 0)
|
|
block 0 of dva0.0.0.0.1 is a valid boot block
|
|
reading 621 blocks from dva0.0.0.0.1
|
|
bootstrap code read in
|
|
base = 112000, image_start = 0, image_bytes = 4da00
|
|
initializing HWRPB at 2000
|
|
initializing page table at 104000
|
|
initializing machine state
|
|
setting affinity to the primary CPU
|
|
jumping to bootstrap code
|
|
MILO Stub: V1.1
|
|
Unzipping MILO into position
|
|
Allocating memory for unzip
|
|
####...
|
|
</verb></tscreen>
|
|
|
|
<p>The following systems are <em/known/ to have SRM Console support:
|
|
<itemize>
|
|
<item>Noname (Section <ref id="noname-section" name="Noname">)
|
|
<item>AlphaPC64 (Section <ref id="pc64-section" name="AlphaPC64">)
|
|
<item>EB164 (Section <ref id="eb164-section" name="EB164">)
|
|
<item>PC164 (Section <ref id="pc164-section" name="PC164">)
|
|
</itemize>
|
|
|
|
<sect1>System Specific Information<label id="specific-section">
|
|
|
|
<sect2>AxpPCI33 (Noname)<label id="noname-section">
|
|
|
|
<p>The Noname board can load MILO
|
|
from the Windows NT ARC firmware
|
|
(Section <ref id="arc-section" name="booting from Windows NT ARC firmware">),
|
|
from the SRM Console
|
|
(Section <ref id="srm_section" name="Loading MILO from the SRM Console">).
|
|
and from a failsafe boot block floppy
|
|
(Section <ref id="bootblock-section" name="Loading from a Failsafe Boot Block Floppy">).
|
|
A flash management utility, runnable from MILO is available so that
|
|
once MILO is running, it can be blown into flash
|
|
(Section <ref id="MILO-fmu-section" name="running the flash management utility">).
|
|
However, be warned
|
|
that once you have done this you will lose the previous image held there
|
|
as there is only room for one image.
|
|
|
|
<p>The way that Noname boots is controlled
|
|
by a set of jumpers on the board, J29 and J28. These look like:
|
|
<tscreen><verb>
|
|
4
|
|
J29 2 x x x 6
|
|
1 x x x 5
|
|
|
|
J28 2 x x x 6
|
|
1 x x x 5
|
|
3
|
|
</verb></tscreen>
|
|
<p>The two options that we're interested in are J28, pins 1-3 which
|
|
boots the console/loader from flash and J29, pins 1-3 which boots the
|
|
console/loader from a boot block floppy. The second option is the one
|
|
that you need to first boot MILO on the Noname board.
|
|
|
|
<p>Once you've selected the boot from floppy option via the jumpers,
|
|
put the SRM boot block floppy containing MILO into the
|
|
floppy and reboot. In a few seconds (after the floppy light goes out)
|
|
you should see the screen blank to white and MILO telling
|
|
you what's going on.
|
|
|
|
<p>If you are really interested in technical stuff, the Noname loads
|
|
images off of the floppy into physical address 0x104000 and images
|
|
from flash into 0x100000. For this reason, MILO is built
|
|
with it's PALcode starting at 0x200000. When it is first loaded, it
|
|
moves itself to the correct location (see relocate.S).
|
|
|
|
<sect2>AlphaPC64 (Cabriolet)<label id="pc64-section">
|
|
|
|
<p>The AlphaPC64 includes the Windows NT ARC firmware
|
|
(Section <ref id="arc-section" name="booting from Windows NT ARC firmware">),
|
|
the SRM Console (Section <ref id="srm_section" name="Loading MILO from the SRM Console">)
|
|
and the Evaluation Debug Monitor
|
|
(Section <ref id="dbm-section" name="Loading from the Debug Monitor">).
|
|
These images are in flash and there is room to add MILO so that
|
|
you can boot MILO directly from flash.
|
|
A flash management utility, runnable from MILO is available so that
|
|
once MILO is running, it can be blown into flash
|
|
(Section <ref id="MILO-fmu-section" name="running the flash management utility">).
|
|
This system supports MILO environment variables.
|
|
|
|
<p>You select between the boot options (and MILO when it is
|
|
been put into flash) using a combination of jumpers and a boot option which
|
|
is saved in the NVRAM of the TOY clock.
|
|
|
|
The jumper is J2, SP bits 6 and 7 have the following meanings:
|
|
<itemize>
|
|
<item>SP bit 6 should always be out. If this jumper is set then the
|
|
SROM mini-debugger gets booted,
|
|
<item>SP bit 7 in is boot image selected by the boot option byte in
|
|
the TOY clock,
|
|
<item>SP bit 7 out is boot first image in flash.
|
|
</itemize>
|
|
|
|
<p>So, with bit 7 out, the Debug Monitor will be booted as it is <tt/always/
|
|
the first image in flash. With bit 7 in, the image selected by
|
|
the boot option in the TOY clock will be selected.
|
|
The Debug Monitor, the Windows NT ARC firmware and MILO all support setting
|
|
this boot option byte but you must be very careful using it.
|
|
In particular, you cannot set the boot option so that next time the system
|
|
boots MILO when you are running the Windows NT ARC firmware, it only
|
|
allows you to set Debug Monitor or Windows NT ARC as boot options.
|
|
|
|
<p> To get MILO into flash via the Evaluation Board Debug Monitor,
|
|
you will need a flashable image.
|
|
The build proceedures make MILO.rom,
|
|
but you can also make a rom image using the makerom tool in the
|
|
Debug Monitor software that comes with the board:
|
|
|
|
<verb>
|
|
> makerom -v -i7 -l200000 MILO -o mini.flash
|
|
</verb>
|
|
|
|
<p> (type makerom to find out what the arguments mean, but 7 is a
|
|
flash image id used by the srom and -l200000 gives the load address
|
|
for the image as 0x200000).
|
|
|
|
<p>Load that image into memory (via the Debug Monitor commands flload,
|
|
netload, and so on) at 0x200000 and then blow the image into flash:
|
|
|
|
<tscreen><verb>
|
|
AlphaPC64> flash 200000 8
|
|
</verb></tscreen>
|
|
|
|
<p> (200000 is where the image to be blown is in memory and 8 is the segment
|
|
number where you put the image. There are 16 1024*64 byte segments in the
|
|
flash and the Debug Monitor is at seg 0 and the Windows NT ARC firmware is at seg 4).
|
|
|
|
<p> Set up the image that the srom will boot by writing the number of
|
|
the image into the TOY clock.
|
|
|
|
<tscreen><verb>
|
|
AlphaPC64> bootopt 131
|
|
</verb></tscreen>
|
|
<p>(131 means boot the 3rd image, 129 = 1st, 130 = 2nd and so on).
|
|
|
|
<p> Power off, put jumper 7 on and power on and you should see the
|
|
MILO burst into life. If you don't then take jumper 7 back off
|
|
and reboot the Debug Monitor.
|
|
|
|
<sect2>EB66+<label id="eb66p-section">
|
|
|
|
<p>The EB66+, like all of the Alpha Evaluation Boards built by Digital
|
|
contains the Evaluation Board Debug Monitor and so this is available
|
|
to load MILO
|
|
(Section <ref id="dbm-section" name="Loading from the Debug Monitor">).
|
|
Quite often (although not always) boards whose design is derived from
|
|
these include the Debug Monitor also.
|
|
Usually, these boards include the Windows NT ARC firmware
|
|
(Section <ref id="arc-section" name="booting from Windows NT ARC firmware">).
|
|
A flash management utility, runnable from MILO is available so that
|
|
once MILO is running, it can be blown into flash
|
|
(Section <ref id="MILO-fmu-section" name="running the flash management utility">).
|
|
This system supports MILO environment variables.
|
|
|
|
<p>These systems have several boot images in flash controlled by jumpers.
|
|
The two jumper banks are J18 and J16 and are located at the bottom
|
|
of the board in the middle (if the Alpha chip is at the top).
|
|
You select between the boot options (and MILO when it is
|
|
been put into flash) using a combination of jumpers and a boot option which
|
|
is saved in the NVRAM of the TOY clock.
|
|
|
|
<p>Jumper 7-8 of J18 in means boot the image described by the
|
|
boot option. Jumper 7-8 of J18 out means boot the Evaluation Board
|
|
Debug Monitor.
|
|
|
|
<p>Blowing an image into flash via the Evaluation Board Debug Monitor
|
|
is exactly the same proceedure as
|
|
for the AlphaPC64 (Section <ref id="pc64-section" name="AlphaPC64">).
|
|
|
|
<sect2>EB64+/Aspen Alpine<label id="eb64p-section">
|
|
|
|
<p>This system is quite like the AlphaPC64 except that it does not
|
|
contain flash which MILO can be loaded from.
|
|
The EB64+ has two ROMs, one of which contains
|
|
the Windows NT ARC firmware
|
|
(Section <ref id="arc-section" name="booting from Windows NT ARC firmware">).
|
|
and the other contains the Evaluation Board Debug Monitor
|
|
(Section <ref id="dbm-section" name="Loading from the Debug Monitor">).
|
|
|
|
<p>The Aspen Alpine is a little different in that it only has one
|
|
ROM; this contains the Windows NT ARC firmware.
|
|
|
|
<sect2>Universal Desktop Box (Multia)<label id="multia-section">
|
|
|
|
<p>This is a very compact pre-packaged 21066 based system that
|
|
includes a TGA (21030) graphics device. Although you can <em/just/ fit
|
|
a half height PCI graphics card in the box you are better off waiting
|
|
for full TGA support in XFree86. It includes the Windows NT ARC
|
|
firmware and so booting from that is the prefered method
|
|
(Section <ref id="arc-section" name="Loading from Windows NT">).
|
|
|
|
<sect2>EB164<label id="eb164-section">
|
|
|
|
<p>The EB164, like all of the Alpha Evaluation Boards built by Digital
|
|
contains the Evaluation Board Debug Monitor and so this is available
|
|
to load MILO
|
|
(Section <ref id="dbm-section" name="Loading from the Debug Monitor">).
|
|
Quite often (although not always) boards whose design is derived from
|
|
these include the Debug Monitor also.
|
|
Usually, these boards include the Windows NT ARC firmware
|
|
(Section <ref id="arc-section" name="booting from Windows NT ARC firmware">).
|
|
The SRM console is also available
|
|
(Section <ref id="srm_section" name="Loading MILO from the SRM Console">).
|
|
A flash management utility, runnable from MILO is available so that
|
|
once MILO is running, it can be blown into flash
|
|
(Section <ref id="MILO-fmu-section" name="running the flash management utility">).
|
|
This system supports MILO environment variables.
|
|
|
|
<p>These systems have several boot images in flash controlled by jumpers.
|
|
The two jumper bank is J1 and is located at the bottom
|
|
of the board on the left (if the Alpha chip is at the top).
|
|
You select between the boot options (and MILO when it is
|
|
been put into flash) using a combination of jumpers and a boot option which
|
|
is saved in the NVRAM of the TOY clock.
|
|
|
|
<p>Jumper SP-11 of J1 in means boot the image described by the
|
|
boot option. Jumper SP-11 of J1 out means boot the Evaluation Board
|
|
Debug Monitor.
|
|
|
|
<p>Blowing an image into flash via the Evaluation Board Debug
|
|
Monitor is exactly the same proceedure as
|
|
for the AlphaPC64 (Section <ref id="pc64-section" name="AlphaPC64">).
|
|
|
|
<sect2>PC164<label id="pc164-section">
|
|
|
|
<p>The PC164, like all of the Alpha Evaluation Boards built by Digital
|
|
contains the Evaluation Board Debug Monitor and so this is available
|
|
to load MILO
|
|
(Section <ref id="dbm-section" name="Loading from the Debug Monitor">).
|
|
Quite often (although not always) boards whose design is derived from
|
|
these include the Debug Monitor also.
|
|
Usually, these boards include the Windows NT ARC firmware
|
|
(Section <ref id="arc-section" name="booting from Windows NT ARC firmware">).
|
|
The SRM console is also available
|
|
(Section <ref id="srm_section" name="Loading MILO from the SRM Console">).
|
|
A flash management utility, runnable from MILO is available so that
|
|
once MILO is running, it can be blown into flash
|
|
(Section <ref id="MILO-fmu-section" name="running the flash management utility">).
|
|
This system supports MILO environment variables.
|
|
|
|
<p>These systems have several boot images in flash controlled by jumpers.
|
|
The main jumper block, J30, contains the system configuration jumpers and
|
|
jumper CF6 in means that the system will boot the Debug Monitor, the default
|
|
is out.
|
|
|
|
<p>Blowing an image into flash via the Evaluation Board Debug
|
|
Monitor is exactly the same proceedure as
|
|
for the AlphaPC64 (Section <ref id="pc64-section" name="AlphaPC64">).
|
|
|
|
<sect2>XL266<label id="xl-section">
|
|
|
|
<p>The XL266 is one of a family of systems that are known as Avanti.
|
|
It has a riser card containing the Alpha chip and cache which plugs into
|
|
the main board at right angles. This board can replace the equivalent
|
|
Pentium board.
|
|
|
|
<p>Some of these systems ship with the SRM console but others, notably
|
|
the XL266 ship with only the Windows NT ARC firmware
|
|
(Section <ref id="arc-section" name="booting from Windows NT ARC firmware">).
|
|
|
|
<p>Here is my list of compatible systems:
|
|
<itemize>
|
|
<item>AlphaStation 400 (Avanti),
|
|
<item>AlphaStation 250,
|
|
<item>AlphaStation 200 (Mustang),
|
|
<item>XL. There are two flavours, XL266 and XL233 with the only
|
|
difference being in processor speed and cache size.
|
|
</itemize>
|
|
|
|
<p><bf>Note</bf> The system that I use to develop and test MILO is
|
|
an XL266 and so this is the only one that I can guarentee will work.
|
|
However, technically, all of the above systems are equivalent; they
|
|
have the same support chipsets and the same interrupt handling
|
|
mechanisms.
|
|
|
|
<sect2>Platform2000<label id="p2k-section">
|
|
|
|
<p>This is a 233Mhz 21066 based system.
|
|
|
|
<sect>MILO's User Interface<label id="MILO-if-section">
|
|
|
|
<p>Once you have correctly installed/loaded/run MILO you will see
|
|
the MILO (for MIniLOader) prompt displayed on your screen. There is a very
|
|
simple interface that you must use in order to boot a particular Linux
|
|
kernel image. Typing "help" is a good idea as it gives a useful summary
|
|
of the commands.
|
|
|
|
<sect1>The ''help'' Command<label id="MILO-help-section">
|
|
|
|
<p>Probably the most useful command that MILO has:
|
|
|
|
<tscreen><verb>
|
|
|
|
MILO> help
|
|
MILO command summary:
|
|
|
|
ls [-t fs] [dev:[dir]]
|
|
- List files in directory on device
|
|
boot [-t fs] [dev:file] [boot string]
|
|
- Boot Linux from the specified device and file
|
|
run [-t fs] dev:file
|
|
- Run the standalone program dev:file
|
|
show - Display all known devices and file systems
|
|
set VAR VALUE - Set the variable VAR to the specified VALUE
|
|
unset VAR - Delete the specified variable
|
|
reset - Delete all variables
|
|
print - Display current variable settings
|
|
help [var] - Print this help text
|
|
|
|
Devices are specified as: fd0, hda1, hda2, sda1...
|
|
Use the '-t filesystem-name' option if you want to use
|
|
anything but the default filesystem ('ext2').
|
|
Use the 'show' command to show known devices and filesystems.
|
|
Type 'help var' for a list of variables.
|
|
|
|
</verb></tscreen>
|
|
|
|
<p><bf>Note</bf> that the <tt>bootopt</tt> command only appears on AlphaPC64
|
|
(and similar) systems.
|
|
Refer to the board's dcoumentation to find out just what it means.
|
|
|
|
<p><bf>Devices.</bf> Until you
|
|
use a command that needs to make use of a device, no device
|
|
inititalisation will take place. The first <tt/show/,
|
|
<tt/ls/, <tt/boot/ or <tt/run/
|
|
commands all cause the devices within MILO to be initialised.
|
|
Devices are named
|
|
in the same way (exactly) that Linux itself will name them. So, the
|
|
first IDE disk will be called 'hda' and it's first partition will be 'hda1'.
|
|
Use the <tt/show/ command to show what devices are available.
|
|
|
|
<p><bf>File Systems.</bf> MILO supports three file systems,
|
|
MSDOS, EXT2 and ISO9660. So long as a device is available to it,
|
|
MILO can <tt/list/<tt/boot/ or <tt/run/ an image stored on
|
|
one of these file systems.
|
|
MILO's default file system is <tt/EXT2/ and so you have tell MILO that
|
|
the file system is something other than that.
|
|
All of the commands that use filenames
|
|
allow you to pass the file system using the <tt/-t [filesystem]/option.
|
|
So, if you wanted to list the contents of a SCSI CD ROM, you might type the
|
|
following:
|
|
|
|
<tscreen><verb>
|
|
MILO> ls -t iso9660 scd0:
|
|
</verb></tscreen>
|
|
|
|
<p><bf>Variables.</bf> MILO contains some settable variables that help
|
|
the boot process. If you are loading via the Windows NT ARC firmware, then
|
|
MILO makes use of the boot option environment variables set up by that
|
|
firmware.
|
|
For some systems, MILO (for example, the AlphaPC64) maintains
|
|
its own set of environment variables that do not change from boot to boot.
|
|
These variables are:
|
|
|
|
<tscreen><verb>
|
|
|
|
MILO> help var
|
|
Variables that MILO cares about:
|
|
MEMORY_SIZE - System memory size in megabytes
|
|
BOOT_DEV - Specifies the default boot device
|
|
BOOT_FILE - Specifies the default boot file
|
|
BOOT_STRING - Specifies the boot string to pass to the kernel
|
|
SCSIn_HOSTID - Specifies the host id of the n-th SCSI controller.
|
|
AUTOBOOT - If set, MILO attempts to boot on powerup
|
|
and enters command loop only on failure.
|
|
AUTOBOOT_TIMEOUT - Seconds to wait before auto-booting on powerup.
|
|
|
|
</verb></tscreen>
|
|
|
|
<sect1>Booting Linux <label id="MILO-boot-section">
|
|
|
|
<p>The <tt/boot/ command boots a linux kernel from a device.
|
|
You will need to have a linux kernel image on
|
|
an EXT2 formated disk (SCSI, IDE or floppy) or an ISO9660 formatted CD
|
|
available to MILO.
|
|
The image can be gzip'd and in this case
|
|
MILO will recognise that it is gzip'd by the .gz suffix.
|
|
|
|
<p>You should note that the version of MILO does not usually have to match
|
|
the version of the Linux kernel that you are loading.
|
|
You boot Linux using the following command syntax:
|
|
|
|
<tscreen><verb>
|
|
MILO> boot [-t file-system] device-name:file-name [[boot-option] [boot-option] ...]
|
|
</verb></tscreen>
|
|
|
|
<p>Where <tt/device-name/ is the name of the device that you wish to
|
|
use and <tt/file-name/ is the name of the file containing the Linux
|
|
kernel. All arguments supplied after the file name are passed directly
|
|
to the Linux kernel.
|
|
|
|
<p>If you are installing Red Hat, then you will need to specify a root
|
|
device and so on. So you would use:
|
|
|
|
<tscreen><verb>
|
|
MILO> boot fd0:vmlinux.gz root=/dev/fd0 load_ramdisk=1
|
|
</verb></tscreen>
|
|
|
|
<p> MILO will automatically contain the block devices that
|
|
you configure into your vmlinux. I have tested the floppy driver, the IDE
|
|
driver and a number of SCSI drivers (for example, the NCR 810), and these work fine.
|
|
Also, it is important to set the host id of the SCSI controller
|
|
to a reasonable value. By default, MILO will initialize it to the
|
|
highest possible value (7) which should normally work just fine.
|
|
However, if you wish, you can explicitly set the host id of the
|
|
<em>n</em>-th SCSI controller in the system by setting environment
|
|
variable <tt/SCSI/<em/n/<tt/_HOSTID/ to the appropriate
|
|
value. For example, to set the hostid of the first SCSI controller to
|
|
7, you can issue the following command at the MILO prompt:
|
|
|
|
<tscreen><verb>
|
|
setenv SCSI0_HOSTID 7
|
|
</verb></tscreen>
|
|
|
|
<sect1>Rebooting Linux <label id="MILO-reboot-section">
|
|
<p>You may want to reboot a running Linux system using the
|
|
<tt>shutdown -r now</tt> command. In this case, the Linux kernel
|
|
returns control to MILO (via the HALT CallPAL entrypoint).
|
|
MILO leaves a compressed copy of itself in memory for just this
|
|
reason and detects that the system is being rebooted from information
|
|
held in the HWRPB (Hardware Restart Parameter Block).
|
|
In this case it starts to reboot using exactly the same command that
|
|
was used to boot the Linux kernel the last time.
|
|
There is a 30 second timeout that allows you to interrupt this
|
|
process and boot whatever kernel you wish in whatever way you wish.
|
|
|
|
<sect1>The ''bootopt'' command <label id="MILO-bootopt-section">
|
|
|
|
<p>For flash based systems such as the AlphaPC64, EB164 and the EB66+, there
|
|
are a number of possible boot options and these are changed using the
|
|
<tt/bootopt/ command.
|
|
This has one argument, a decimal number which is the type of the
|
|
image to be booted the next time the system is power cycled or reset:
|
|
|
|
<p><bf/0/ Boot the Evaluation Board Debug Monitor,
|
|
<p><bf/1/ Boot the Windows NT ARC firmware.
|
|
|
|
<p>In order to tell the boot code to boot the MILO firmware from flash
|
|
then you need a boot option that means boot the N'th image.
|
|
For this, you need to 128 plus N, so if MILO is the third image, you
|
|
would use the command:
|
|
|
|
<tscreen><verb>
|
|
MILO> bootopt 131
|
|
</verb></tscreen>
|
|
|
|
<tt/Note:/ Be very careful with this command. A good rule is never to
|
|
set bootopt to 0 (the Evaluation Board Debug Monitor), but instead use the
|
|
system's jumpers to achieve the same thing.
|
|
|
|
<sect>Running the Flash Management Utility <label id="MILO-fmu-section">
|
|
|
|
<p>The <tt/run/ command is used to run the flash management utility.
|
|
Before you start you will need a device available to MILO that
|
|
contains the updateflash program.
|
|
This (like vmlinux) can be gzip'd. You need to run the flash management
|
|
utility program from the MILO using the (<tt/run/) command:
|
|
|
|
<tscreen><verb>
|
|
MILO> run fd0:fmu.gz
|
|
</verb></tscreen>
|
|
|
|
<p>Once it has loaded and initialised, the flash management utility
|
|
will tell you some information about the flash device and give you
|
|
a command prompt. Again the <tt/help/ command is most useful.
|
|
|
|
<p>
|
|
<tscreen><verb>
|
|
Linux MILO Flash Management Utility V1.0
|
|
|
|
Flash device is an Intel 28f008SA
|
|
16 segments, each of 0x10000 (65536) bytes
|
|
Scanning Flash blocks for usage
|
|
Block 12 contains the environment variables
|
|
FMU>
|
|
</verb></tscreen>
|
|
|
|
<p><tt/Note/ that on systems where environment variables may be stored
|
|
and where there is more than one flash block (for example, the AlphaPC64)
|
|
the flash management utility will look for a block to hold MILO's
|
|
environment variables. If such a block already exists, the flash management
|
|
utility will tell you where it is. Otherwise, you must use the <tt/environment/
|
|
command to set a block and initialise it.
|
|
In the above example, flash block 12 contains MILO's environment
|
|
variables.
|
|
|
|
<sect1> The ''help'' command
|
|
|
|
<p>
|
|
<tscreen><verb>
|
|
FMU> help
|
|
FMU command summary:
|
|
|
|
list - List the contents of flash
|
|
program - program an image into flash
|
|
quit - Quit
|
|
environment - Set which block should contain the environment variables
|
|
bootopt num - Select firmware type to use on next power up
|
|
help - Print this help text
|
|
FMU>
|
|
|
|
</verb></tscreen>
|
|
<p><em/Note/ that the <tt/environment/ and <tt/bootopt/ commands are only available on
|
|
the EB66+, the AlphaPC64, EB164 and PC164 systems (and their clones).
|
|
|
|
<sect1> The ''list'' command
|
|
|
|
<p>The ''list'' command shows the current usage of the flash memory.
|
|
Where there is more than one flash block, the usage of each flash block
|
|
is shown. In the example below you can see that Windows NT ARC is using
|
|
blocks 4:7 and block 15.
|
|
|
|
<tscreen><verb>
|
|
FMU> list
|
|
Flash blocks: 0:DBM 1:DBM 2:DBM 3:WNT 4:WNT 5:WNT 6:WNT 7:WNT 8:MILO
|
|
9:MILO 10:MILO 11:MILO 12:MILO 13:U 14:U 15:WNT
|
|
Listing flash Images
|
|
Flash image starting at block 0:
|
|
Firmware Id: 0 (Alpha Evaluation Board Debug Monitor)
|
|
Image size is 191248 bytes (3 blocks)
|
|
Executing at 0x300000
|
|
Flash image starting at block 3:
|
|
Firmware Id: 1 (Windows NT ARC)
|
|
Image size is 277664 bytes (5 blocks)
|
|
Executing at 0x300000
|
|
Flash image starting at block 8:
|
|
Firmware Id: 7 (MILO/Linux)
|
|
Image size is 217896 bytes (4 blocks)
|
|
Executing at 0x200000
|
|
FMU>
|
|
</verb></tscreen>
|
|
|
|
<sect1> The ''program'' command
|
|
|
|
<p>The flash management utility contains a compressed copy of a flash
|
|
image of MILO. The ''program'' command allows you to blow this image
|
|
into flash.
|
|
The command allows you to back out, but before you run it you should
|
|
use the ''list'' command to see where to put MILO.
|
|
If MILO is already in flash, then the flash management utility will
|
|
offer to overwrite it.
|
|
|
|
<tscreen><verb>
|
|
FMU> program
|
|
Image is:
|
|
Firmware Id: 7 (MILO/Linux)
|
|
Image size is 217896 bytes (4 blocks)
|
|
Executing at 0x200000
|
|
Found existing image at block 8
|
|
Overwrite existing image? (N/y)? y
|
|
Do you really want to do this (y/N)? y
|
|
Deleting blocks ready to program: 8 9 10 11
|
|
Programming image into flash
|
|
Scanning Flash blocks for usage
|
|
FMU>
|
|
</verb></tscreen>
|
|
|
|
<p>Wait until it has completed before powering off your system.
|
|
|
|
<p><tt/Note:/ I cannot emphasise just how careful you must be here
|
|
not to overwrite an existing flash image that you might need or
|
|
render your system useless. A very good rule is never to overwrite
|
|
the Debug Monitor.
|
|
|
|
<sect1>The ''environment'' command
|
|
<p>This selects a flash block to contain MILO's environment variables.
|
|
|
|
<sect1>The ''bootopt'' command
|
|
|
|
<p>This is just the same as MILO's ''bootopt'' command,
|
|
see (Section <ref id="MILO-bootopt-section" name="The ''bootopt'' command">).
|
|
|
|
<sect1>The ''quit'' command
|
|
|
|
<p>This is really pretty meaningless. The only way back to MILO (or
|
|
anything else) once the flash management utility has run is to reboot
|
|
the system.
|
|
|
|
<sect> Restrictions.
|
|
|
|
<p>Unfortunately this is not a perfect world and there, as always, some
|
|
restrictions that you should be aware of.
|
|
|
|
<p>MILO is not meant to load operating systems other than Linux,
|
|
although it can load images linked to run at the same place in memory as Linux
|
|
(which is 0xFFFFFC0000310000).
|
|
This is how the flash management utilities can be run.
|
|
|
|
<p> The PALcode sources included in <tt>miniboot/palcode/</tt><em>blah</em> are
|
|
correct, however there are problems when they are built using the
|
|
latest <tt/gas/. They <em>do</em> build if you use the ancient a.out gas
|
|
that's supplied in the Alpha Evaluation Board toolset (and that's how
|
|
they were built). I'm trying to get someone to fix the new gas.
|
|
Meanwhile, as a workaround, I have provided pre-built PALcode for the
|
|
supported boards and David Mosberger-Tang has a fixed gas on
|
|
his ftp site.
|
|
|
|
<sect>Problem Solving.
|
|
|
|
<p>Here are some common problems that people have seen, together with the
|
|
solutions.
|
|
|
|
<p><bf>Reading MS-DOS floppies from the Evaluation Board Debug Monitor.</bf>
|
|
<p> Some of the older versions of the Evaluation Board Debug Monitor (pre-version 2.0)
|
|
have a problem with DOS format flopies generated from Linux.
|
|
Usually, the Debug Monitor can load the first few sectors all right, but then goes
|
|
into an endless loop complaining about "bad sectors." Apparently,
|
|
there is an incompatibility between the DOS file system as expected by
|
|
the Debug Monitor and the Linux implementation of DOSFS. To make the
|
|
long story short: if you run into this problem, try using DOS to write
|
|
the floppy disk. For example, if loading the file <tt/MILO.cab/
|
|
doesn't work, use a DOS machine, insert the floppy and then do:
|
|
|
|
<tscreen><verb>
|
|
copy a:MILO.cab c:
|
|
copy c:MILO.cab a:
|
|
del c:MILO.cab
|
|
</verb></tscreen>
|
|
|
|
<p> Then try booting from that floppy again. This normally solves the problem.
|
|
|
|
<p><bf>MILO displays a long sequence of <tt/O>/ and does not accept input.</bf>
|
|
<p>This usually happens when MILO was built to use COM1 as a secondary console
|
|
device. In such a case, MILO echo output to COM1 and accepts input from
|
|
there also. This is great for debugging but not so great if you have
|
|
a device other than a terminal connected.
|
|
If this happens, disconnect the device or power it down until the Linux
|
|
kernel has booted.
|
|
Once Linux is up and running, everything will work as expected.
|
|
|
|
<p><bf>MILO complains that the kernel image has the wrong magic number</bf>
|
|
<p> Older versions of MILO did not support the ELF object file format and so
|
|
could not recognise an ELF image and this might be your problem.
|
|
If this is reported, upgrade to the latest MILO that you can find. All
|
|
2.0.20 and beyond MILOs support ELF.
|
|
On the other hand it could be that the image is indeed damaged. You should
|
|
also note that MILO does not yet automatically distinquish between GZIP'd
|
|
and non-GZIP'd images; you need to add the ".gz" suffix to the file name.
|
|
|
|
<p><bf>MILO prints "...turning on virtual addressing and jumping to the Linux Kernel" and
|
|
nothing else happens</bf>
|
|
<p>One obvious problem is that the kernel image is wrongly built or is built for another
|
|
Alpha system altogether.
|
|
Another is that the video board is a TGA (Zlxp) device and the kernel has been built
|
|
for a VGA device (or vice versa).
|
|
It is worth building the kernel to echo to COM1 and then connecting a terminal to
|
|
that serial port or retrying the kernel that came with the Linux distribution that you
|
|
installed.
|
|
|
|
<p><bf>MILO does not recognise the SCSI device</bf>
|
|
<p>The standard MILO images include as many device drivers as are known to be stable
|
|
for Alpha (as of now that includes the NCR 810, QLOGIC ISP, Buslogic and Adaptec 2940s
|
|
and 3940 cards). If your card is not included, it may be that the driver is not stable
|
|
enough on an Alpha system yet. Again, the latest MILO images are worth trying. You
|
|
can tell which SCSI devices a MILO image has built into it by using the "show" command.
|
|
|
|
<sect>Acknowledgements.
|
|
|
|
<p>I would like to thank:
|
|
<itemize>
|
|
<item>Eric Rasmussen and Eilleen Samberg the authors of
|
|
the PALcode,
|
|
<item>Jim Paradis for the keyboard driver and the original
|
|
MILO interface,
|
|
<item>Jay Estabrook for his help and bugfixes,
|
|
<item>David Mosberger-Tang for the freeware BIOS emulation
|
|
and his support and encouragement,
|
|
<item>Last (and <tt>not</tt> least) Linus Torvalds for the
|
|
timer code and his kernel.
|
|
</itemize>
|
|
|
|
<p>There are a number of things that still need doing to MILO,
|
|
if you want to add something yourself, then do let me know
|
|
<url url="mailto:david.rusling@reo.mts.dec.com"
|
|
name="david.rusling@reo.mts.dec.com">
|
|
so that we do not duplicate our efforts.
|
|
|
|
<p>Finally, a big thank you to Digital for producing such a wonderful
|
|
chip (and paying me to do this).
|
|
|
|
</article>
|