Section 8.2. Boot Loaders
8.2. Boot LoadersBoot loaders are programs that reside on the boot device of a computer. The first boot device is usually the first hard disk in the system. A boot loader is called by BIOS (x86) or firmware (PPC) after enough system initialization has occurred to support the memory, interrupts, and I/O required to load the kernel. Once loaded, the kernel initializes and configures the operating system. For x86 systems, the BIOS allows the user to set the order of boot devices for their system. These boot devices are typically the floppy, CD-ROM, and the hard drive. Formatting a disk (with fdisk, for example) creates the Master Boot Record (MBR), which resides in the first sector (sector 0, cylinder 0, head 0) of the boot device. The MBR contains a small program and a four-entry partition table. The end of the boot sector has a hex marker 0xAA55 at location 510. Table 8.1 shows the components of the MBR.
The MBR's partition table holds information pertinent to each of the hard disk primary partitions. Table 8.2 shows what each 16-byte entry of the MBR's partition table looks like:
At the end of self-test and hardware identification, the system initialization code (Firmware or BIOS) accesses the hard drive controller to read the MBR. After the type of boot drive is identified, one can follow a documented interface (for example, on an IDE drive) to access head 0, cylinder 0, and sector 0. After the boot device is located, the MBR is copied to memory address 0x7c00 and executed. The small program at the head of the MBR moves itself out of the way and searches its partition table for the location of the active boot partition. The MBR then copies the code from the active boot partition to address 0x7c00 and begins executing it. From this point, DOS is usually booted on an x86 system. However, the active boot partition can have a bootloader that, in turn, loads the operating system. We now discuss some of the most common bootloaders that Linux uses. Figure 8.2 shows what memory looks like at bootup time. Figure 8.2. View of Memory at Bootup Time 8.2.1. GRUBThe Grand Unified Bootloader (GRUB) is an x86-based bootloader that's used to load Linux. GRUB 2 is in the process of being ported to PPC at the time of writing. Ample documentation exists on www.gnu.org/software/grub, including its history and future designs. GRUB recognizes filesystems on the boot drives, and the kernel can be loaded by specifying the filename, drive, and partition where the kernel resides. GRUB is a two-stage bootloader.[1] Stage 1 is installed in the MBR and is called by BIOS. Stage 2 is partially loaded by Stage 1 and then finishes loading itself from the filesystem. The breakdown of events ocurring in each of the stages is the following:
GRUB can be accessed through an interactive command line or a menu-driven interface. When using the menu interface, a configuration file must be created. Here is a stanza from the GRUB configuration file that loads the Linux kernel:
The options are title, which holds a label for the setup; root, which sets the current root device to hd0, partition 0; and kernel, which loads the primary boot image of the kernel from the specified file. The rest of the information in the kernel entry is passed as boot time parameters to the kernel. Certain aspects of booting, such as the location of where the kernel image is loaded and uncompressed, are configured in the architecture-specific sections of the Linux kernel code. Let's look at arch/i386/boot/setup.S where this is done for x86: ---------------------------------------------------------------------- arch/i836/boot/setup.S 61 INITSEG = DEF_INITSEG # 0x9000, we move boot here, out of the way 62 SYSSEG = DEF_SYSSEG # 0x1000, system loaded at 0x10000 (65536). 63 SETUPSEG = DEF_SETUPSEG # 0x9020, this is the current segment ----------------------------------------------------------------------- This configuration specifies that Linux boots and loads the executable image to linear address 0x9000 and jumps to 0x9020. At this point, the uncompressed part of the Linux kernel decompresses the compressed portion to address 0x10000 and kernel initialization begins. GRUB is based on the Multiboot Specification. At the time of this writing, Linux does not have all the structures in place to be multiboot-compliant, but it is worth discussing multiboot requirements. 8.2.1.1. Multiboot SpecificationThe Multiboot Specification describes an interface between any potential bootloader and any potential operating system. The Multiboot Specification does not say how a bootloader should work, but how it must interface with the operating system being loaded. Currently targeted at x86 architectures and free 32-bit operating systems, it provides a standard means for a bootloader to pass configuration information to an operating system. The OS image can be of any type (ELF or special), but must contain a multiboot header in the first 8K of the image, as well as the magic number 0x1BADB002. The multiboot-compliant loader should also provide a method for auxiliary boot modules or drivers to be used by the OS at boot time as certain OSes do not load all the programs necessary for operation into the bootable kernel image. This is often done to modularize boot kernels and keep the boot kernel to a manageable size. The Multiboot Specification dictates that, when the bootloader invokes the OS, the system must be in a specific 32-bit real mode state such that the OS can successfully make calls back into BIOS if desired. Finally, the bootloader must present the OS with a data structure filled with essential machine data. We now look at the multiboot information data structure. ----------------------------------------------------------------------- typedef struct multiboot_info { ulong flags; // indicate following fields ulong mem_lower; // if flags[0],amnt of mem < 1M ulong mem_upper; // if flags[0],amnt of mem > 1M ulong boot_device; // if flags[1],drive,part1,2,3 ulong cmdline; // if flags[2],addr of cmd line ulong mods_count; // if flags[3],#of boot modules ulong mods_addr; // if flags[3],addr of first boot module. union { aout_symbol_table_t aout_sym; // if flags[4], symbol table from a.out kernel image elf_section_header_table_t elf_sec;// if flags[5], header from ELF kernel. } u; ulong mmap_length; // if flags[6],BIOS mem map len ulong mmap_addr; // if flags[6],BIOS map addr ulong drives_length; // if flags[7],BIOS drive info structs ulong drives_length; // if flags[7],first BIOS drive info struct. ulong config_table // if flags[8],ROM config table ulong boot_loader_name // if flags[9],addr of string ulong apm_table // if flags[10],addr of APM info table ulong vbe_control_info // if flags[11],video mode settings ulong vbe_mode_info ulong vbe_mode ulong vbe_interface_seg ulong vbe_interface_off ulong vbe_interface_len }; ----------------------------------------------------------------------- A pointer to this structure is passed in EBX when control is passed to the OS. The first field, flags, indicates which of the following fields are valid. Unused fields must be 0. You can learn more about the Multiboot Specification at www.gnu.org/software/grub/manual/multiboot/multiboot.html. 8.2.2. LILOThe LInux LOader (LILO) has been used for years as an x86 loader for Linux. It was one of the earliest boot-loading programs available to assist in the configuration and loading of the Linux kernel. LILO is similar to GRUB in the sense that it is a two-stage bootloader. LILO uses a configuration file and does not have a command-line interface. Again, we start with BIOS initializing the system and loading the MBR (Stage 1) into memory and transferring control to it. The breakdown of the events occurring in each of LILO's stages is as follows:
A stanza from the LILO configuration file looks like this: ---------------------------------------------------------------------- /etc/lilo.conf image=/boot/bzImage-2.6.7-mytestkernel label=Kernel 2.6.7, my test kernel root=/dev/hda6 read-only ----------------------------------------------------------------------- The parameters are image, which indicates the pathname of the kernel; label, which is a string describing the configuration; root, which indicates the partition where the root filesystem resides; and read-only, which indicates that the root partition cannot be altered during boot. Here is a list of the differences between GRUB and LILO:
Let's review what happens when LILO is the bootloader. First, the MBR (which contains LILO) is copied to 0x7c00 and begins execution. LILO begins by copying the kernel image referenced in /etc/lilo.conf from the hard drive. This image, created by build.c, is made up of the init sector (loaded at 0x90000), the setup sector (loaded at 0x90200), and the compressed image (loaded at 0x10000). LILO then jumps to label start_of _setup at address 0x90200. 8.2.3. PowerPC and YabootYaboot is a bootloader based on the Open Firmware (OF) of New World PowerPC machines. Similar to LILO and GRUB, Yaboot uses a configuration file and a utility such as ybin or ybootconfig to set up a bootstrap partition containing Yaboot. Similar to the x86 BIOS, OF allows configuration of the boot device. However, in the OF case, it varies by system. OF settings can be usually found by pressing "Command+Option/Alt+o+f..?" Yaboot uses the following steps to boot:
As you can see, the kernel-loading stanza for Yaboot is similar to LILO and GRUB: ---------------------------------------------------------------------- yaboot.conf label=Linux root=/dev/hda11 sysmap=/boot/System.map read-only ----------------------------------------------------------------------- As in LILO, ybin installs Yaboot to the boot partition. Any updates/changes to the Yaboot configuration require rerunning ybin. Documentation on Yaboot can be found at www.penguinppc.org. |
specifications at boot time by way of the kernel command line. This is a string describing 
EAN: N/A
Pages: 134