Embedded Linux Primer: A Practical, Real-World Approach

modifications.

• Several kernel configuration editors exist. We chose one and examined how it is driven and how to modify the menus and menu items within. These concepts apply to all the graphical front ends.

• The kernel itself comes with an entire directory structure full of useful kernel documentation. This is a helpful resource for understanding and navigating the kernel and its operation.

• This chapter concluded with a brief introduction to the options available for obtaining an embedded Linux distribution.

4.5.1. Suggestions for Additional Reading

Linux Kernel HOWTO:

www.tldp.org/HOWTO/Kernel-HOWTO

Kernel Kbuild documentation:

http://sourceforge.net/projects/kbuild/

The Linux Documentation Project:

www.tldp.org/

Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification,

Version 1.2

TIS Committee, May 1995

Linux kernel source tree:

…/Documentation/kbuild/makefiles.txt

Linux kernel source tree:

…/Documentation/kbuild/kconfig-language.txt

Linux Kernel Development,

2nd Edition Rovert Love

Novell Press, 2005

Chapter 5. Kernel Initialization

When the power is applied to an embedded Linux system, a complex sequence of events is started. After a few seconds, the Linux kernel is operational and has spawned a series of application programs as specified by the system init scripts. A significant portion of these activities are governed by system configuration and are under the control of the embedded developer.

This chapter examines the initial sequence of events in the Linux kernel. We take a detailed look at the mechanisms and processes used during kernel initialization. We describe the Linux kernel command line and its use to customize the Linux environment on startup. With this knowledge, you will be able to customize and control the initialization sequence to meet the requirements of your particular embedded system.

5.1. Composite Kernel Image: Piggy and Friends

At power-on, the bootloader in an embedded system is first to get processor control. After the bootloader has performed some low-level hardware initialization, control is passed to the Linux kernel. This can be a manual sequence of events to facilitate the development process (for example, the user types interactive load/boot commands at the bootloader prompt), or an automated startup sequence typical of a production environment. We have dedicated Chapter 7, 'Bootloaders,' to this subject, so we defer any detailed bootloader discussion to that chapter.

In Chapter 4, 'The Linux Kernel: A Different Perspective,' we examined the components that make up the Linux kernel image. Recall that one of the common files built for every architecture is the ELF binary named vmlinux. This binary file is the monolithic kernel itself, or what we have been calling the kernel proper. In fact, when we looked at its construction in the link stage of vmlinux, we pointed out where we might look to see where the first line of code might be found. In most architectures, it is found in an assembly language source file called head.S or similar. In the PowerPC (ppc) branch of the kernel, several versions of head.S are present, depending on the processor. For example, the AMCC 440 series processors are initialized from a file called head_44x.S.

Some architectures and bootloaders are capable of directly booting the vmlinux kernel image. For example, platforms based on PowerPC architecture and the U-Boot bootloader can usually boot the vmlinux image directly[36] (after conversion from ELF to binary, as you will shortly see). In other combinations of architecture and bootloader, additional functionality might be needed to set up the proper context and provide the necessary utilities for loading and booting the kernel.

Listing 5-1 details the final sequence of steps in the kernel build process for a hardware platform based on the ADI Engineering Coyote Reference Platform, which contains an Intel IXP425 network processor. This listing uses the quiet form of output from the kernel build system, which is the default. As pointed out in Chapter 4, it is a useful shorthand notation, allowing more focus on errors and warnings during the build.

Listing 5-1. Final Kernel Build Sequence: ARM/IXP425 (Coyote)

$ make ARCH=arm CROSS_COMPILE=xscale_be- zImage
...   < many build steps omitted for clarity>
  LD          vmlinux
  SYSMAP      System.map
  OBJCOPY     arch/arm/boot/Image
  Kernel:     arch/arm/boot/Image is ready
  AS          arch/arm/boot/compressed/head.o
  GZIP        arch/arm/boot/compressed/piggy.gz
  AS          arch/arm/boot/compressed/piggy.o
  CC          arch/arm/boot/compressed/misc.o
  AS          arch/arm/boot/compressed/head-xscale.o
  AS          arch/arm/boot/compressed/big-endian.o
  LD          arch/arm/boot/compressed/vmlinux
  OBJCOPY     arch/arm/boot/zImage
  Kernel:     arch/arm/boot/zImage is ready
  Building modules, stage 2.