Flash Filesystems for Embedded Linux Systems

With the falling cost of 32-bit
processors containing a memory management unit (MMU), Flash memory
and SDRAM, a new class of embedded devices is evolving in the
networking, internet appliance and PDA markets. Typically
consisting of a 32-bit processor with an MMU, 4-32MB of Flash
memory and 8-32MB of SDRAM, these devices now have the storage
capacity needed to take advantage of the many advanced features
applications require. The popular Compaq iPaq handheld computer is
a good example of such a system.
When implementing a Linux operating system on these devices,
the critical issue of how to create a filesystem without a hard
drive arises. A number of different types of Flash memory are
designed specifically for data storage, such as NAND Flash devices
and disk-on-chip devices. However, this article will focus on NOR
Flash-based solutions for the iPaq system mentioned above.Since NOR Flash is usually required for code storage,
implementing a filesystem in existing NOR Flash devices is often
the most cost-effective solution and conserves PCB board real
estate. Several technologies are available for efficiently
implementing filesystems on NOR Flash. Before examining these
technologies, however, let us examine the critical issues driving
the design of NOR Flash filesystems.The first of these issues is that conventional filesystems,
such as the default Linux standard ext2, cannot be efficiently used
on Flash because the block size of a Flash device is relatively
large (64K to 256K), compared to the 4k block size typically used
for ext2 filesystems. Additionally, NOR Flash has a limited number
of erase cycles per block, typically in the range of 100,000.
Secondly, the cost of NOR Flash is prohibitive, about three times
as expensive as SDRAM. For this reason a filesystem with
compression is highly desirable. Finally, journaling is an issue
with a Flash filesystem, if file writes are to be supported,
because it eliminates the need to go through a lengthy power-down
procedure.Another frequently discussed topic related to Flash
filesystems is execute in place (XIP), which is often used in
embedded operating systems. XIP is a mode of operation where the
processor maps pages from the application in Flash directly to its
virtual address space, without coping the pages to RAM first. This
process can reduce the amount of RAM required in a system. The
problem with XIP is that compression cannot be used, and it is very
difficult to make a filesystem that is writable. The fact that the
processor will only load the working set of pages into RAM for an
application also reduces the need for XIP.There are a number of Linux technologies that work together
to implement a filesystem in a Flash-based embedded Linux system.
Figure 1 illustrates the relationships between some of the standard
components.
Figure 1. Components of a Filesystem in a Flash-Based System
initrdIn the early days of embedded Linux, the
initrd (initial ram disk)
mechanism was often used to store a compressed filesystem in Flash.
The initrd mechanism was originally developed so a small Linux
system could be booted from a floppy disk that, in turn, would
install a full-featured Linux system to a hard disk. The boot
sequence of a system using an initrd is:

1. Bootloader copies compressed Linux kernel and
   initrd image from Flash to RAM and jumps to kernel.
2. The kernel decompresses itself to the correct
   location and starts the initialization sequence.
3. The kernel decompresses the initrd image in RAM and
   mounts it using the ramdisk driver.

Compared with current technologies, there are several
disadvantages with the initrd approach. First, the size of the
initrd is fixed. It wastes system RAM when it is not full, and the
size cannot be increased when additional storage is required.
Second, changes made are lost on the next reboot.
Even with its limitations, the initrd mechanism is useful for
booting a system before a true Flash filesystem is working. More
information on the initrd mechanism can be found in the
Documentation/initrd.txt file in the Linux kernel source.cramfscramfs is a compressed
read-only filesytem originally developed by Linus Torvalds and
included in recent Linux kernels. In the cramfs filesystem, each
page is individually compressed, allowing random page
access.A cramfs image is usually placed in system Flash but can also
be placed on another filesystem and mounted using the loopback
device. cramfs is useful in its
efficiency, and it often is desirable to have system files in a
read-only partition to prevent file corruption and improve system
reliability.A cramfs image is created using the
mkcramfs utility, which creates an
image from the contents of a specified directory.
mkcramfs can be found in the
scripts/cramfs directory of the Linux source tree.ramfsramfs is a filesystem that
keeps all files in RAM and is often used with a Flash filesystem to
store temporary data or data that changes often. The major
advantage of ramfs is it grows and shrinks to accommodate the files
it contains, unlike a ramdisk, which is fixed in size. The ramfs
filesystem was originally written by Linus Torvalds and is included
in recent kernels.jffs2jffs2 is a read/write,
compressed, journaling Flash filesystem that is designed to be used
on Flash memory devices rather than RAM devices. The jffs2
filesystem is currently in development but is extremely useful; it
should be stable by publication of this article.The jffs filesystem was
originally developed for the 2.0 kernel by Axix Communications in
Sweden. David Woodhouse and others improved jffs and developed
jffs2, which supports compression.
jffs2 addresses most of the issues
of Flash filesystems, in that it provides compression, read/write
access, automatic leveling and a hard power-down safe
filesystem.The journaling aspect of jffs2 is quite dynamic and works
very well on Flash. The jffs2 filesystem is simply a list of nodes
or log entries that contain information about a file. Each node may
contain data to be inserted into a file or instructions to be
deleted from a file. When a jffs2 filesystem is mounted, the entire
log is scanned to determine how a file is to be created. Nodes are
written to Flash sequentially starting at the first block. If
additional writes are needed, blocks are consecutively written to
until the end of Flash is reached, then starts at the beginning
again. jffs2 includes a garbage
collection thread that combines and copies valid nodes in one block
to another block, then erases partially used blocks. Valid data is
never erased until it has been copied to another block, which keeps
existing data from ever being lost or corrupted. The process of
sequentially erasing and writing Flash blocks provides
wear-leveling, as it distributes the Flash writes over the entire
Flash device.The jffs2 filesystem is new and in the process of being
integrated into the kernel sources. The most recent copy can be
obtained via anonymous CVS at
http://www.linux-mtd.infradead.org/.MTD DriverThe memory technology device (MTD) subsystem for Linux is a
generic interface to memory devices such as Flash and RAM,
providing simple read, write and erase access to physical memory
devices. mtdblock devices can be mounted by jffs, jffs2 and cramfs
filesystems. The MTD driver provides extensive support for NOR
Flash devices that support common flash interfaces (CFIs), such as
Intel, Sharp, AMD and Fujitsu. The width of the Flash bus and
number of chips required to implement the bus width can be
configured or automatically detected. The MTD driver layer also
supports multiple Flash partitions on one set of Flash
devices.System Design IssuesOften, the best solution when designing a system is to divide
different parts of the root filesystem into different filesystem
partitions. The following is one possible implementation
scheme:

• Put anything that does not need to be updated at
  runtime in a cramfs filesystem.
  cramfs typically achieves over a
  2:1 compression ratio and is very efficient.
• Directories that are written to often, such as
  /var, should be placed in a ramfs filesystem to minimize write
  cycles to Flash. Note that the contents of the ramfs partition are
  not preserved between system power cycles or operating system
  reboots.
• Any part of the filesystem that requires read/write
  access and must preserve information between reboots is placed in a
  jffs2 filesystem.

A 16MB Flash system might be partitioned like the one in
Table 1.
Table 1. Sample Partition of a 16MB
Flash SystemOne disadvantage of this configuration is unused space in the
MTD1 and MTD2 partitions is wasted. Implementing a system with only
jffs2 and ramfs is also efficient if there is no concern about
overwriting system files. The normal Linux file access permissions
apply to files in a jffs or jffs2 filesystem, so read-only
attributes can be assigned to selected files and directories to
enhance system integrity.Table 2 shows the typical Flash space required for
implementing a full-featured Linux root filesystem that includes
networking support and many system utilities. The jffs
implementation is given for reference to illustrate the space
required if compression is not used.Table 2. Flash Space for a
Full-Featured Root FilesystemWith the recent open-source developments of Flash filesystem
technology, Accelent Systems has been able to implement embedded
Linux systems that have a very robust read/write filesystem on
standard NOR Flash. By using the jffs2 filesystem, the Accelent
system software solution allows units to be powered off at any
time, yet allows the user to write data to the filesystem that is
preserved between reboots.

Cliff Brake is a
senior engineer for Accelent Systems. He is involved in designing
hardware and software for embedded systems and specializes in
embedded Linux on the ARM architecture. Cliff welcomes your
comments or questions and can be reached at
cbrake@accelent.com.

Jeff Sutherland
has over 20 years of experience with a wide variety of embedded
computer systems. In addition to his expertise with embedded Linux
and the ARM architecture, Jeff has extensive experience in
low-power portable handheld computer design. Jeff can be reached
for questions or comments at jsutherland@accelent.com.

email: cbrake@accelent.com