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 the Miniloader does on an Alpha based system, however there are several interesting differences between BIOS firmware and the Miniloader, not least of which is that the Miniloader includes and uses standard Linux device drivers unmodified. The Miniloader is firmware, unlike LILO, which relies on the BIOS firmware to get itself loaded. The main functional parts of the Miniloader are:
The following paragraphs describe these functional parts in more detail.
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 the Miniloader uses (and therefore Linux itself) is, like the rest of the Miniloader, 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.
For the Miniloader 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. It effectively discards itself as it passes control to Linux and tells Linux just what memory is available. This means that the Miniloader is very frugal with memory and only reserves enough memory for the PALcode (8 pages) and the HWRPB and page tables (3 pages). This leaves *most* of the memory in the system for Linux itself.
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.
You have the choice of two forms of VGA initialisation. There is standard, very simple ISA VGA initialisation code which is somewhat restrictive. The Miniloader also contains BIOS emulation code which allows it to run the on-board BIOS from video cards in order to properly initialise them.
David M-T, would you like to add a few words here?
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.
The Miniloader'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. The Miniloader 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()).
The only supported file system at the moment is the EXT2 filesystem. This means that the Miniloader can load Linux (or flash update utilities) directly off of real file systems rather than from boot blocks and other strange places. Gzip'd files are supported and these are recommended particularly if you are loading from floppy which is a rather slow medium.
Built into the Miniloader 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.
The Miniloader 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.
Next Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter