Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

+++ u-boot-ep405/board/ep405/Makefile

+++ u-boot-ep405/board/ep405/u-boot.lds

+++ u-boot-ep405/include/config.h

+++ u-boot-ep405/include/config.mk

+++ u-boot-ep405/include/configs/EP405.h

+++ u-boot-ep405/include/ppc405.h

+++ u-boot-ep405/Makefile

Recall that we derived all the files in the .../board/ep405 directory from another directory. Indeed, we didn't create any files from scratch for this port. We borrowed from the work of others and customized where necessary to achieve our goals.

Now that we have a working bootloader for our EP405 board, we can load and run programs on it. Ideally, we want to run an operating system such as Linux. To do this, we need to understand the image format that U-Boot requires. U-Boot expects a small header on the image file that identifies several attributes of the image. U-Boot uses the mkimage tool (part of the U-Boot source code) to build this image header.

Recent Linux kernel distributions have built-in support for building images directly bootable by U-Boot. Both the ARM and PPC branches of the kernel source tree have support for a target called uImage. Let's look at the PPC case. The following snippet from the Linux kernel PPC makefile .../arch/ppc/boot/images/Makefile contains the rule for building the U-Boot target called uImage :

quiet_cmd_uimage = UIMAGE $@

cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc \

-O linux -T kernel -C gzip -a 00000000 -e 00000000 \

-n 'Linux-$(KERNELRELEASE)' -d $< $@

Ignoring the syntactical complexity, understand that this rule calls a shell script identified by the variable $(MKIMAGE). The shell script executes the U-Boot mkimage utility with the parameters shown. The mkimage utility creates the U-Boot header and prepends it to the supplied kernel image. The parameters are defined as follows:

-A Specifies the target image architecture

-O Species the target image OSin this case, Linux

-T Specifies the target image typea kernel, in this case

-C Specifies the target image compression typehere, gzip

-a Sets the U-Boot loadaddress to the value specifiedin this case, 0

-e Sets the U-Boot image entry point to the supplied value

-n A text field used to identify the image to the human user

-d The executable image file to which the header is prepended

Several U-Boot commands use this header data both to verify the integrity of the image (U-Boot also puts a CRC signature in the header) and to instruct various commands what to do with the image. U-Boot has a command called iminfo that reads the image header and displays the image attributes from the target image. Listing 7-9 contains the results of loading a uImage (bootable Linux kernel image formatted for U-Boot) to the EP405 board via U-Boot's tftpboot command and executing the iminfo command on the image.

Listing 7-9. U-Boot iminfo Command

=> tftpboot 400000 uImage-ep405

ENET Speed is 100 Mbps - FULL duplex connection

TFTP from server 192.168.1.9; our IP address is 192.168.1.33

Filename 'uImage-ep405'.

Load address: 0x400000

Loading: ########## done

Bytes transferred = 891228 (d995c hex)

=> iminfo

## Checking Image at 00400000 ...

Image Name: Linux-2.6.11.6

Image Type: PowerPC Linux Kernel Image (gzip compressed)

Data Size: 891164 Bytes = 870.3 kB

Load Address: 00000000

Entry Point: 00000000

Verifying Checksum ... OK

=>

Here we introduce the more popular bootloaders, describe where they might be used, and give a summary of their features. This is not intended to be a thorough tutorial because to do so would require a book of its own. The interested reader can consult the "Suggestions for Additional Reading" at the end of this chapter for further study.

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. [59] This is mostly for historical reasons. From the early days of PCs, BIOS programs loaded only the first sector of a disk drive and passed control to it. 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 partitions and does most of the work of the bootloader.

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-10 is an example of a simple lilo.conf configuration file describing a typical dual-boot Linux and Windows installation.

Listing 7-10. Example 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 gives the system operator the choice 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 the example presented in Listing 7-10, the primary (default) image is a Linux kernel image with a file name 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.

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.