Flash Filesystems for Embedded Linux Systems

Flash isn't only a hard disk with no moving parts. This article shows you how to combine filesystem technologies to make the best use of Flash.

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

initrd

In 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.

cramfs

cramfs 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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

nice article.

Anonymous's picture

i gonna use this stuff in my beagleboard

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix