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

www.redhat.com/support/wpapers/redhat/ext3/

ReiserFS Home Page

www.namesys.com/

"JFFS: The Journaling Flash File System"

David Woodhouse

http://sources.redhat.com/jffs2/jffs2.pdf

README file from cramfs project

Unsigned (assumed to be the project author)

http://sourceforge.net/projects/cramfs/

NFS home page

http://nfs.sourceforge.net

The /proc file system documentation

www.tldp.org/LDP/lkmpg/2.6/html/c712.htm

File System Performance: The Solaris OS, UFS, Linux ext3, and ReiserFS

A technical whitepaper

Dominic Kay

www.sun.com/software/whitepapers/solaris10/fs_performance.pdf

The Memory Technology Devices (MTD) subsystem grew out of the need to support a wide variety of memory-like devices such as Flash memory chips. Many different types of Flash chips are available, along with numerous methods to program them, partly because of the many specialized and high-performance modes that are supported. The MTD layer architecture enables the separation of the low-level device complexities from the higher-layer data organization and storage formats that use memory devices.

In this chapter, we introduce the MTD subsystem and provide some simple examples of its use. First we look at what is required of the kernel to support MTD services. We introduce some simple operations on a development workstation with MTD enabled, as a means to understand the basics of this subsystem. In this chapter, we integrate MTD and the JFFS2 file system.

We next introduce the concept of partitions as they relate to the MTD layer. We examine the details of building partitions from a bootloader and how they are detected by the Linux kernel. The chapter continues with a brief introduction to the MTD utilities. We conclude by putting it all together and booting a target board using an in-Flash JFFS2 file system image.

To use MTD services, your kernel must be configured with MTD enabled. Many configuration options exist for MTD, some of which can be confusing. The best way to understand the myriad choices is simply to begin working with them. To illustrate the mechanics of the MTD subsystem and how it fits in with the system, we begin with some very simple examples that you can perform on your Linux development workstation. Figure 10-1 shows the kernel configuration (invoked per the usual make ARCH= gconfig) necessary to enable the bare-minimum MTD functionality. Listing 10-1 displays the .config file entries resulting from the selections shown in Figure 10-1.

Listing 10-1. Basic MTD Configuration from .config

CONFIG_MTD=y

CONFIG_MTD_CHAR=y

CONFIG_MTD_BLOCK=y

CONFIG_MTD_MTDRAM=m

CONFIG_MTDRAM_TOTAL_SIZE=8192

CONFIG_MTDRAM_ERASE_SIZE=128

The MTD subsystem is enabled via the first configuration option, which is selected via the first check box shown in Figure 10-1, Memory Technology Device (MTD) Support. The next two entries from the configuration shown in Figure 10-1 enable special device-level access to the MTD devices, such as Flash memory, from user space. The first one (CONFIG_MTD_CHAR) enables character device mode access, essentially a sequential access characterized by byte-at-a-time sequential read and write access. The second (CONFIG_MTD_BLOCK) enables access to the MTD device in block device mode, the access method used for disk drives, in which blocks of multiple bytes of data are read or written at a time. These access modes allow the use of familiar Linux commands to read and write data to the Flash memory, as you shall shortly see.

Figure 10-1. MTD configuration

The CONFIG_MTD_MTDRAM element enables a special test driver that enables us to examine the MTD subsystem even if we don't have any MTD devices (such as Flash memory) available. Coupled with this configuration selection are two parameters associated with the RAM-based test driver: the device size and the erase size. For this example, we have specified 8192KB total size and 128KB erase size. The objective of this test driver is to emulate a Flash device, primarily to facilitate MTD subsystem testing and development. Because Flash memory is architected using fixed-size erase blocks, the test driver also contains the concept of erase blocks. You will see how these parameters are used shortly.

MTD is included in any recent snapshot of the Linux kernel. However, if you need to take advantage of MTD features that have been added since your kernel version was released, you must download and build the MTD drivers and utilities. Because the MTD package contains both kernel components and user space programs, it is useful to keep the MTD package in a separate project directory and connect it to your kernel source tree. The simplest way to integrate the MTD and your kernel source tree(s) is to use the scripts provided by the MTD package.

Download the MTD package from the location given at the end of this chapter. Unpack the archive into a directory of your choice using the tar utility. Enter the directory and run the patchkernel.sh script. This script provides several options. Execute the script with no parameters for a detailed usage. Listing 10-2 shows how to install the kernel components.

Listing 10-2. Patching Your Kernel for MTD

$ ./patchkernel.sh -2 ../sources/linux-2.6.10-mtd

Patching ../sources/linux-2.6.10-mtd/

Include JFFS2 file system: jffs2

Include JFFS3 file system (experimental): no

Method: ln << Will actually create symbolic links

Can we start now ? [y/N] y

$

Invoking the patchkernel.sh script with the -2 parameter indicates that we want support for the JFFS2 file system. We provide the path to the kernel source directory as ../sources/linux-2.6.10-mtd. By default, patchkernel.sh does not copy any files into the kernel source directory. Instead, it creates symbolic links from the kernel source tree pointing into the MTD subdirectory itself. In this way, you can maintain a common source tree for MTD for any number of kernels that you happen to have on your development workstation. This allows the MTD kernel drivers to be built with the kernel build system, including information about your specific kernel configuration.

Now that we have enabled a simple MTD configuration in our kernel, we can examine how this subsystem works on our Linux development workstation. Using the test RAM driver we just configured in the previous section, we can mount a JFFS2 image using an MTD device. Assuming that you created a JFFS2 image as detailed in Chapter 9, "File Systems," you might want to mount it and examine it. The Linux kernel does not support mounting a JFFS2 file system image directly on a loopback device, such as is possible with ext2 and other file system images. So we must use a different method. This can be achieved using the MTD RAM test driver on our development Linux workstation with MTD enabled, as in Figure 10-1. Listing 10-3 illustrates the steps.

Listing 10-3. Mounting JFFS2 on an MTD RAM Device

# modprobe jffs2

# modprobe mtdblock

# modprobe mtdram

# dd if=jffs2.bin of=/dev/mtdblock0