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

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState