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

-rw-rw-r-- 1 chris chris 512 Mar 25 11:13 initramfs_data.cpio

-rw-rw-r-- 1 chris chris 133 Mar 25 11:13 initramfs_data.cpio.gz

-rw-rw-r-- 1 chris chris 786 Mar 25 11:13 initramfs_data.o

-rw-rw-r-- 1 chris chris 1024 Oct 27 2005 initramfs_data.S

-rw-rw-r-- 1 chris chris 113 Mar 25 11:13 initramfs_list

-rw-rw-r-- 1 chris chris 1619 Oct 27 2005 Kconfig

-rw-rw-r-- 1 chris chris 2048 Oct 27 2005 Makefile

The file initramfs_list contains a list of files that will be included in the initramfs archive. The default for recent Linux kernels looks like this:

dir /dev 0755 0 0

nod /dev/console 0600 0 0 c 5 1

dir /root 0700 0 0

This produces a small default directory structure containing the /root and /dev top-level directories, as well as a single device node representing the console. Add to this file to build your own initramfs. You can also specify a source for your initramfs files via the kernel-configuration facility. Enable INITRAMFS_SOURCE in your kernel configuration and point it to a location on your development workstation; the kernel build system will use those files as the source for your initramfs image.

The final output of this build directory is the initramfs_data_cpio.gz file. This is a compressed archive containing the files you specified (either through the initramfs_list or via the INITRAMFS_SOURCE kernel-configuration option). This archive is linked into the final kernel image. This is another advantage of initramfs over initrd : There is no need to load a separate initrd image at boot time, as is the case with initrd.

Orderly shutdown of an embedded system is often overlooked in a design. Improper shutdown can affect startup times and can even corrupt certain file system types. One of the more common complaints using the EXT2 file system (the default in many desktop Linux distributions for several years) is the time it takes for an fsck (file system check) on startup after unplanned power loss. Servers with large disk systems can take on the order of hours to properly fsck through a collection of large EXT2 partitions.

Each embedded project will likely have its own shutdown strategy. What works for one might or might not work for another. The scale of shutdown can range from a full System V shutdown scheme, to a simple script to halt or reboot. Several Linux utilities are available to assist in the shutdown process, including the shutdown, halt, and reboot commands. Of course, these must be available for your chosen architecture.

A shutdown script should terminate all userspace processes, which results in closing any open files used by those processes. If init is being used, issuing the command init 0 halts the system. In general, the shutdown process first sends all processes the SIGTERM signal, to notify them that the system is shutting down. A short delay ensures that all processes have the opportunity to perform their shutdown actions, such as closing files, saving state, and so on. Then all processes are sent the SIGKILL signal, which results in their termination. The shutdown process should attempt to unmount any mounted file systems and call the architecture-specific halt or reboot routines. The Linux shutdown command in conjunction with init exhibits this behavior.

• A root file system is required for all Linux systems. They can be difficult to build from scratch because of complex dependencies by each application.

• The File System Hierarchy standard provides guidance to developers for laying out a file system for maximum compatibility and flexibility.

• We presented a minimal file system as an example of how root file systems are created.

• The Linux kernel's final boot steps define and control a Linux system's startup behavior. Several mechanisms are available depending on your embedded Linux system's requirements.

• The init process was presented in detail. This powerful system-configuration and control utility can serve as the basis for your own embedded Linux system. System initialization based on init was presented, along with example startup script configurations.

• Initial ramdisk is a Linux kernel feature to allow further startup behavior customization before mounting a final root file system and spawning init. We presented the mechanism and example configuration for using this powerful feature.

• initramfs simplifies the initial ramdisk mechanism, while providing similar early startup facilities. It is easier to use, does not require loading a separate image, and is built automatically during each kernel build.

File System Hierarchy Standard

Maintained by freestandards.org

www.pathname.com/fhs/

Boot Process, Init and Shutdown

Linux Documentation Project

http://tldp.org/LDP/intro-linux/html/sect_04_02.html

Init man page

Linux Documentation Project

http://tldp.org/LDP/sag/html/init.html

A brief description of System V init

http://docs.kde.org/en/3.3/kdeadmin/ksysv/what-is-sysv-init.html

Booting Linux: The History and the Future

Werner Almesberger

www.almesberger.net/cv/papers/ols2k-9.ps

Previous chapters have made reference to and even provided examples of bootloader operations. A critical component of an embedded system, the bootloader provides the foundation from which the other system software is spawned. This chapter starts by examining the bootloader's role in a system. We follow this with an introduction to some common features of bootloaders. Armed with this background, we take a detailed look at a popular bootloader used for embedded systems. We conclude this chapter by introducing a few of the more popular bootloaders.

Numerous bootloaders are in use today. It would be impractical in the given space to cover much detail on even the most popular ones. Therefore, we have chosen to explain concepts and use examples based on one of the more popular bootloaders in the open source community for PowerPC, MIPS, ARM, and other architectures: the U-Boot bootloader.

When power is first applied to a processor board, many elements of hardware must be initialized before even the simplest program can run. Each architecture and processor has a set of predefined actions and configurations, which include fetching some initialization code from an on-board storage device (usually Flash memory). This early initialization code is part of the bootloader and is responsible for breathing life into the processor and related hardware components.

Most processors have a default address from which the first bytes of code are fetched upon application of power and release of reset. Hardware designers use this information to arrange the layout of Flash memory on the board and to select which address range(s) the Flash memory responds to. This way, when power is first applied, code is fetched from a well-known and predictable address, and software control can be established.

The bootloader provides this early initialization code and is responsible for initializing the board so that other programs can run. This early initialization code is almost always written in the processor's native assembly language. This fact alone presents many challenges, some of which we examine here.

Of course, after the bootloader has performed this basic processor and platform initialization, its primary role becomes booting a full-blown operating system. It is responsible for locating, loading, and passing execution to the primary operating system. In addition, the bootloader might have advanced features, such as the capability to validate an OS image, the capability to upgrade itself or an OS image, and the capability to choose from among several OS images based on a developer-defined policy. Unlike the traditional PC-BIOS model, when the OS takes control, the bootloader is overwritten and ceases to exist. [56] Some embedded designs protect the bootloader and provide callbacks to bootloader routines, but this is almost never a good design approach. Linux is far more capable than bootloaders, so there is often little point in doing so.