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

4690+1 records in

4690+1 records out

# mkdir /mnt/flash

# mount -t jffs2 /dev/mtdblock0/mnt/flash

# ls -l /mnt/flash

total 0

drwxr-xr-x 2 root root 0 Sep 17 22:02 bin

drwxr-xr-x 2 root root 0 Sep 17 21:59 dev

drwxr-xr-x 7 root root 0 Sep 17 15:31 etc

drwxr-xr-x 2 root root 0 Sep 17 15:31 home

drwxr-xr-x 2 root root 0 Sep 17 22:02 lib

drwxr-xr-x 2 root root 0 Sep 17 15:31 proc

drws------ 2 root root 0 Sep 17 15:31 root

drwxr-xr-x 2 root root 0 Sep 17 22:02 sbin

drwxrwxrwt 2 root root 0 Sep 17 15:31 tmp

drwxr-xr-x 9 root root 0 Sep 17 15:31 usr

drwxr-xr-x 14 root root 0 Sep 17 15:31 var

#

From Listing 10-3, first we install the loadable modules that the Linux kernel requires to support JFFS2 and the MTD subsystem. We load the JFFS2 module followed by the mTDblock and mtdram modules. After the necessary device drivers are loaded, we use the Linux dd command to copy our JFFS2 file system image into the MTD RAM test driver using the mTDblock device. In essence, we are using system RAM as a backing device to emulate an MTD block device.

After we have copied our JFFS2 file system image into the MTD block device, we can mount it using the mount command, in the manner shown in Listing 10-3. After the MTD pseudo-device has been mounted, we can work with the JFFS2 file system image in any way we choose. The only limitation using this method is that we can't enlarge the image. The size of the image is limited by two factors. First, when we configured the MTD RAM test device, we gave it a maximum size of 8MB. [75] The size was fixed in the kernel configuration when we enabled the MTD RAM test device in the Linux kernel configuration. Second, when we created the JFFS2 image, we fixed the size of the image using the mkfs.jffs2 utility. The image size was determined by the contents of the directory we specified when we created it. Refer back to Listing 9-9, in Chapter 9, to recall how our jffs2.bin image was built.

It is important to realize the limitations of using this method to examine the contents of a JFFS2 file system. Consider what we did: We copied the contents of a file (the JFFS2 file system binary image) into a kernel block device (/dev/mtdblock0). Then we mounted the kernel block device (/dev/mtdblock) as a JFFS2 file system. After we did this, we could use all the traditional file system utilities to examine and even modify the file system. Tools such as ls, df, dh, mv, rm, and cp can all be used to examine and modify the file system. However, unlike the loopback device, there is no connection between the file we copied and the mounted JFFS2 file system image. Therefore, if we unmount the file system after making changes, the changes will be lost. If you want to save the changes, you must copy them back into a file. One such method is the following:

# dd if=/dev/mtdblock0 of=./your-modified-fs-image.bin

This command creates a file called your-modified-fs-image.bin that is the same size as the mtdblock0 device which was specified during configuration. In our example, it would be 8MB. Lacking suitable JFFS2 editing facilities, this is a perfectly valid way to examine and modify a JFFS2 file system. More important, it illustrates the basics of the MTD subsystem on our development system without real Flash memory. Now let's look at some hardware that contains Flash physical devices.

To use MTD with the Flash memory on your board, you must have MTD configured correctly. The following list contains the requirements that must be satisfied to configure MTD for your board, Flash, and Flash layout.

• Specify the partitioning on your Flash device

• Specify the type of Flash and location

• Configure the proper Flash driver for your chosen chip

• Configure the kernel with the appropriate driver(s)

Each of these steps is explored in the following sections.

Most Flash devices on a given hardware platform are divided into several sections, called partitions, similar to the partitions found on a typical desktop workstation hard drive. The MTD subsystem provides support for such Flash partitions. The MTD subsystem must be configured for MTD partitioning support. Figure 10-2 illustrates the configuration options for MTD partitioning support.

Figure 10-2. Kernel configuration for MTD partitioning support

Several methods exist for communicating the partition data to the Linux kernel. The following methods are currently supported. You can see the configuration options for each in Figure 10-2 under MTD Partitioning Support.

• Redboot partition table parsing

• Kernel command-line partition table definition

• Board-specific mapping drivers

MTD also allows configurations without partition data. In this case, MTD simply treats the entire Flash memory as a single device.

One of the more common methods of defining and detecting MTD partitions stems from one of the original implementations: Redboot partitions. Redboot is a bootloader found on many embedded boards, especially ARM XScale boards such as the ADI Engineering Coyote Reference Platform.

The MTD subsystem defines a method for storing partition information on the Flash device itself, similar in concept to a partition table on a hard disk. In the case of the Redboot partitions, the developer reserves and specifies a Flash erase block that holds the partition definitions. A mapping driver is selected that calls the partition parsing functions during boot to detect the partitions on the Flash device. Figure 10-2 shows the mapping driver for our example board; it is the final highlighted entry defining CONFIG_MTD_IXP4xx.

As usual, taking a detailed look at an example helps to illustrate these concepts. We start by looking at the information provided by the Redboot bootloader for the Coyote platform. Listing 10-4 captures some of the output of the Redboot bootloader upon power-up.

Listing 10-4. Redboot Messages on Power-Up

Platform: ADI Coyote (XScale)

IDE/Parallel Port CPLD Version: 1.0

Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

RAM: 0x00000000-0x04000000, 0x0001f960-0x03fd1000 available

FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.

...

This tells us that RAM on this board is physically mapped starting at address 0x00000000 and that Flash is mapped at physical address 0x50000000 through 0x51000000. We can also see that the Flash has 128 blocks of 0x00020000 (128KB) each.

Redboot contains a command to create and display partition information on the Flash. Listing 10-5 contains the output of the fis list command, part of the Flash Image System family of commands available in the Redboot bootloader.

Listing 10-5. Redboot Flash Partition List

RedBoot> fis list

Name FLASH addr Mem addr Length Entry point

RedBoot 0x50000000 0x50000000 0x00060000 0x00000000

RedBoot config 0x50FC0000 0x50FC0000 0x00001000 0x00000000