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.
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:
Bootloader copies compressed Linux kernel and initrd image from Flash to RAM and jumps to kernel.
The kernel decompresses itself to the correct location and starts the initialization sequence.
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 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.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development