This chapter is from the book
This chapter is from the book
This chapter is from the book
7.6 Other Bootloaders
Here we introduce the more popular bootloaders, describe where they might be used, and summarize their features. This is not intended to be a thorough tutorial; doing so would require a book of its own. Consult the last section of this chapter for further study.
7.6.1 Lilo
The Linux Loader, or Lilo, was widely used in commercial Linux distributions for desktop PC platforms; as such, it has its roots in the Intel x86/IA32 architecture. Lilo has several components. It has a primary bootstrap program that lives on the first sector of a bootable disk drive.5 The primary loader is limited to a disk sector size, usually 512 bytes. Therefore, its primary purpose is simply to load and pass control to a secondary loader. The secondary loader can span multiple sectors and does most of the bootloader's work.
Lilo is driven by a configuration file and utility that is part of the Lilo executable. This configuration file can be read or written to only under control of the host operating system. That is, the configuration file is not referenced by the early boot code in either the primary or secondary loaders. Entries in the configuration file are read and processed by the Lilo configuration utility during system installation or administration. Listing 7-17 shows a simple lilo.conf configuration file describing a typical dual-boot Linux and Windows installation.
Listing 7-17. Sample Lilo Configuration: lilo.conf
# This is the global lilo configuration section
# These settings apply to all the "image" sections
boot = /dev/hda
timeout=50
default=linux
# This describes the primary kernel boot image
# Lilo will display it with the label 'linux'
image=/boot/myLinux-2.6.11.1
label=linux
initrd=/boot/myInitrd-2.6.11.1.img
read-only
append="root=LABEL=/"
# This is the second OS in a dual-boot configuration
# This entry will boot a secondary image from /dev/hda1
other=/dev/hda1
optional
label=that_other_os
This configuration file instructs the Lilo configuration utility to use the master boot record of the first hard drive (/dev/hda). It contains a delay instruction to wait for the user to press a key before the timeout (5 seconds, in this case). This allows the system operator to select from a list of OS images to boot. If the system operator presses the Tab key before the timeout, Lilo presents a list to choose from. Lilo uses the label tag as the text to display for each image.
The images are defined with the image tag in the configuration file. In Listing 7-17, the primary (default) image is a Linux kernel image with a filename of myLinux-2.6.11.1. Lilo loads this image from the hard drive. It then loads a second file to be used as an initial ramdisk. This is the file myInitrd-2.6.11.1.img. Lilo constructs a kernel command line containing the string "root=LABEL=/" and passes this to the Linux kernel upon execution. This instructs Linux where to get its root file system after boot.
7.6.2 GRUB
Many current commercial Linux distributions now ship with the GRUB bootloader. GRUB, or GRand Unified Bootloader, is a GNU project. It has many enhanced features not found in Lilo. The biggest difference between GRUB and Lilo is GRUB's capability to understand file systems and kernel image formats. Furthermore, GRUB can read and modify its configuration at boot time. GRUB also supports booting across a network, which can be a tremendous asset in an embedded environment. GRUB offers a command-line interface at boot time to modify the boot configuration.
Like Lilo, GRUB is driven by a configuration file. Unlike Lilo's static configuration, however, the GRUB bootloader reads this configuration at boot time. This means that the configured behavior can be modified at boot time for different system configurations.
Listing 7-18 is a sample GRUB configuration file. This is the configuration file from the PC on which this book was written. The GRUB configuration file is called grub.conf 6 and usually is placed in a small partition dedicated to storing boot images. On the machine from which this example was taken, that directory is called /boot.
Listing 7-18. Sample GRUB Configuration File: grub.conf
default=0
timeout=3
splashimage=(hd0,1)/grub/splash.xpm.gz
title Fedora Core 2 (2.6.9)
root (hd0,1)
kernel /bzImage-2.6.9 ro root=LABEL=/ rhgb proto=imps quiet
initrd /initrd-2.6.9.img
title Fedora Core (2.6.5-1.358)
root (hd0,1)
kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/ rhgb quiet
title That Other OS
rootnoverify (hd0,0)
chainloader +1
GRUB first presents the user with a list of images that are available to boot. The title entries from Listing 7-18 are the image names presented to the user. The default tag specifies which image to boot if no keys have been pressed in the timeout period, which is 3 seconds in this example. Images are counted starting from 0.
Unlike Lilo, GRUB can actually read a file system on a given partition to load an image from. The root tag specifies the root partition from which all filenames in the grub.conf configuration file are rooted. In this sample configuration, the root is partition number 1 on the first hard disk drive, specified as root(hd0,1). Partitions are numbered from 0; this is the second partition on the first hard disk.
The images are specified as filenames relative to the specified root. In Listing 7-18, the default boot image is a Linux 2.6.9 kernel with a matching initial ramdisk image called initrd-2.6.9.img. Notice that the GRUB syntax has the kernel command-line parameters on the same line as the kernel file specification.
7.6.3 Still More Bootloaders
Numerous other bootloaders have found their way into specific niches. For example, Redboot is another open source bootloader that Intel and the XScale community have adopted for use on various evaluation boards based on the Intel IXP and Marvel PXA processor families. Micromonitor is in use by board vendors such as Cogent and others. YAMON7 has found popularity in MIPs circles. LinuxBIOS is used primarily in X86 environments. In general, when you consider a boot loader, you should consider some important factors up front:
- Does it support my chosen processor?
- Has it been ported to a board similar to my own?
- Does it support the features I need?
- Does it support the hardware devices I intend to use?
- Is there a large community of users where I might get support?
- Are there any commercial vendors from which I can purchase support?
These are some of the questions you must answer when considering what bootloader to use in your embedded project. Unless you are doing something on the "bleeding edge" of technology using a brand-new processor, you are likely to find that someone has already done the bulk of the hard work in porting a bootloader to your chosen platform. Use the resources listed at the end of this chapter to help make your final decisions.