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

# ls -l rootfs.ext2

-rw-r--r-- 1 root root 6291456 Nov 19 16:21 rootfs.ext2

Now let's convert this file system image to JFFS2 using the mkfs.jffs2 utility found in the MTD package. Listing 10-15 shows the command and results.

Listing 10-15. Converting RootFS to JFFS2

# mount -o loop rootfs.ext2/mnt/flash/

# mkfs.jffs2 -r /mnt/flash -e 128 -b -o rootfs.jffs2

# ls -l rootfs.jffs2

-rw-r--r-- 1 root root 2401512 Nov 20 10:08 rootfs.jffs2

#

First we mount the ext2 file system image on a loopback device on an arbitrary mount point on our development workstation. Next we invoke the MTD utility mkfs.jffs2 to create the JFFS2 file system image. The -r flag tells mkfs.jffs2 where the root file system image is located. The -e instructs mkfs.jffs2 to build the image while assuming a 128KB block size. The default is 64KB. JFFS2 does not exhibit its most efficient behavior if the Flash device contains a different block size than the block size of the image. Finally, we display a long listing and discover that the resulting JFFS2 root file system image has been reduced in size by more than 60 percent. When you are working with limited Flash memory, this is a substantial reduction in precious Flash resource usage.

Take note of an important command-line flag passed to mkfs.jffs2 in Listing 10-15. The -b flag is the -big-endian flag. This instructs the mkfs.jffs2 utility to create a JFFS2 Flash image suitable for use on a big-endian target. Because we are targeting the ADI Engineering Coyote board, which contains an Intel IXP425 processor running in big-endian mode, this step is crucial for proper operation. If you fail to specify big endian, you will get several screens full of complaints from the kernel as it tries to negotiate the superblock of a JFFS2 file system that is essentially gibberish. [76] The kernel can be configured to operate with a wrong-endian MTD file system, at the cost of reduced performance. In some configurations (such as multiprocessor designs), this can be a useful feature. Anyone care to guess how I remembered this important detail?

In a similar manner to the previous example, we can copy this image to our Redboot RootFS Flash partition using the flashcp utility. Then we can boot the Linux kernel using a JFFS2 root file system. Listing 10-16 provides the details, running the MTD utilities on our target hardware.

Listing 10-16. Copying JFFS2 to RootFS Partition

root@coyote:~# cat /proc/mtd

dev: size erasesize name

mtd0: 00060000 00020000 "RedBoot"

mtd1: 00160000 00020000 "MyKernel"

mtd2: 00600000 00020000 "RootFS"

mtd3: 00001000 00020000 "RedBoot config"

mtd4: 00020000 00020000 "FIS directory"

root@coyote:~# flash_erase /dev/mtd2

Erase Total 1 Units

Performing Flash Erase of length 131072 at offset 0x0 done

root@coyote:~# flashcp /rootfs.jffs2 /dev/mtd2

root@coyote:~#

It is important to note that you must have the JFFS2 file system enabled in your kernel configuration. Execute make ARCH= gconfig and select JFFS2 under File Systems, Miscellaneous File Systems. Another useful hint is to use the -v (verbose) flag on the MTD utilities. This provides progress updates and other useful information during the Flash operations.

We have already seen how to boot a kernel with the Redboot exec command. Listing 10-17 details the sequence of commands to load and boot the Linux kernel with our new JFFS2 file system as root.

Listing 10-17. Booting with JFFS2 as Root File System

RedBoot> load -r -v -b 0x01008000 coyote-zImage

Using default protocol (TFTP)

Raw file loaded 0x01008000-0x0114decb, assumed entry at 0x01008000

RedBoot> exec -c "console=ttyS0,115200 rootfstype=jffs2 root=/dev/mtdblock2"

Using base address 0x01008000 and length 0x00145ecc

Uncompressing Linux...... done, booting the kernel.

...

• The Memory Technology Devices (MTD) subsystem provides support for memory devices such as Flash memory in the Linux kernel.

• MTD must be enabled in your Linux kernel configuration. Several figures in this chapter detailed the configuration options.

• As part of the MTD kernel configuration, the proper Flash driver(s) for your Flash chips must be selected. Figure 10-4 presented the collection of chip drivers supported in a recent Linux kernel snapshot.

• Your Flash memory device can be managed as a single large device or can be divided into multiple partitions.

• Several methods are available for communicating the partition information to the Linux kernel. These include Redboot partition information, kernel command-line parameters, and mapping drivers.

• A mapping driver, together with definitions supplied by your architecture-specific board support, defines your Flash configuration to the kernel.

• MTD comes with a number of user space utilities to manage the images on your Flash devices.

• The Journaling Flash File System 2 (JFFS2) is a good companion to the MTD subsystem for small, efficient Flash-based file systems. In this chapter, we built a JFFS2 image and mounted it as root on our target device.

MTD Linux home page

www.linux-mtd.infradead.org/

Redboot user documentation

http://ecos.sourceware.org/ecos/docs-latest/redboot/redboot-guide.html

Common Flash Memory Interface Specification

AMD Corporation

www.amd.com/us-en/assets/content_type/DownloadableAssets/cfi_r20.pdf

The man page for BusyBox declares that BusyBox is "The Swiss Army Knife of Embedded Linux." This is a fitting description, for BusyBox is a small and efficient replacement for a large collection of standard Linux command line utilities. It often serves as the foundation for a resource-limited embedded platform. This chapter introduces BusyBox and provides a good starting point for customizing your own BusyBox installation.

We previously alluded to BusyBox in multiple locations. In this chapter, we present the details of this useful package. After a brief introduction to BusyBox, we explore the BusyBox configuration utility. This is used to tailor BusyBox to your particular requirements. We then discuss the requirements for cross-compiling the BusyBox package.

BusyBox operational issues are considered, including how it is used in an embedded system. We examine the BusyBox initialization sequence and explain how this departs from the standard System V initialization. In this section, we also present an example initialization script. After seeing the steps for installing BusyBox on a target system, you will learn about some of the BusyBox commands and their limitations.

BusyBox has gained tremendous popularity in the embedded Linux community. It is remarkably easy to configure, compile, and use, and it has the potential to significantly reduce the overall system resources required to support a wide collection of common Linux utilities. BusyBox provides compact replacements for many traditional full-blown utilities found on most desktop and embedded Linux distributions. Examples include the file utilities such as ls, cat, cp, dir, head, and tail; general utilities such as dmesg, kill, halt, fdisk, mount, umount; and many more. BusyBox also provides support for more complex operations, such as ifconfig, netstat, route, and other network utilities.