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

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-11 is an example GRUB configuration file. This is the configuration file from the PC on which this manuscript is being written. The GRUB configuration file is called grub.conf and is usually placed in a small partition dedicated to storing boot images. On the machine from which this example is taken, that directory is called /boot.

Listing 7-11. Example 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-11 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 zero.

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 example configuration, the root is partition number 1 on the first hard disk drive, specified as root(hd0,1). Partitions are numbered from zero; this is the second partition on the first hard disk.

The images are specified as filenames relative to the specified root. In Listing 7-11, 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.

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 PXA processor families. Micromonitor is in use by board vendors such as Cogent and others. YAMON has found popularity in MIPs circles. [60] In an acknowledgment of the number of bootloaders in existence, the YAMON user's guide bills itself as Yet Another MONitor. 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 at the end of this chapter to help make your final decisions.

• The bootloader's role in an embedded system cannot be overstated. It is the first piece of software that takes control upon applying power.

• This chapter examined the role of the bootloader and discovered the limited execution context in which a bootloader must exist.

• Das U-Boot has become a popular universal bootloader for many processor architectures. It supports a large number of processors, reference hardware platforms, and custom boards.

• U-Boot is configured using a series of configuration variables in a board-specific header file. Appendix B, contains a list of all the standard U-Boot command sets supported in a recent U-Boot release.

• Porting U-Boot to a new board based on a supported processor is relatively straightforward. In this chapter, we walked through the steps of a typical port to a board with similar support in U-Boot.

• There is no substitute for detailed knowledge of your processor and hardware platform when bootloader modification or porting must be accomplished.

• We briefly introduced additional bootloaders in use today so you can make an informed choice for your particular requirements.

Application Note: Introduction to Synchronous DRAM

Maxwell Technologies

www.maxwell.com/pdf/me/app_notes/Intro_to_SDRAM.pdf

Using LD, the GNU linker

Free Software Foundation

www.gnu.org/software/binutils/manual/ld-2.9.1/ld.html

The DENX U-Boot and Linux Guide (DLUG) for TQM8xxL

Wolfgang Denx et al., Denx Software Engineering

www.denx.de/twiki/bin/view/DULG/Manual

RFC 793, "Trivial File Transfer Protocol"

The Internet Engineering Task Force

www.ietf.org/rfc/rfc793.txt

RFC 951, "Bootstrap Protocol"

The Internet Engineering Task Force

www.ietf.org/rfc/rfc951.txt

RFC 1531, "Dynamic Host Control Protocol"

The Internet Engineering Task Force

www.ietf.org/rfc/rfc1531.txt

PowerPC 405GP Embedded Processor user's manual

International Business Machines, Inc.

Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture

Freescale Semiconductor, Inc.

Lilo Bootloader

www.tldp.org/HOWTO/LILO.html

GRUB Bootloader

www.gnu.org/software/grub/

One of the more challenging aspects of system design is partitioning functionality in a rational manner. The familiar device driver model found in UNIX and Linux provides a natural partitioning of functionality between your application code and hardware or kernel devices. In this chapter, we develop an understanding of this model and the basics of Linux device driver architecture. After reading this chapter, you will have a solid foundation for continuing your study of device drivers using one of the excellent texts listed at the end of this chapter.

This chapter begins by presenting Linux device driver concepts and the build system for drivers within the kernel source tree. We examine the Linux device driver architecture and present a simple working example driver. We introduce the user space utilities for loading and unloading kernel modules. [61] The terms module and device driver are used here interchangeably. We present a simple application to illustrate the interface between applications and device drivers. We conclude this chapter with a discussion of device drivers and the GNU Public License.

Many experienced embedded developers struggle at first with the concepts of device drivers in a virtual memory operating system. This is because many popular legacy real-time operating systems do not have a similar architecture. The introduction of virtual memory and kernel space versus user space frequently introduces complexity that is not familiar to experienced embedded developers.