免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 690 | 回复: 0
打印 上一主题 下一主题

Flash Filesystems for Embedded Linux Systems [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2006-09-13 15:50 |只看该作者 |倒序浏览

               
                本文转载自:
http://linuxdevices.com/articles/AT7478621147.html
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:   
  •         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
    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.
    ramfs
    ramfs
    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.
    jffs2
    jffs2 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
    www.linux-mtd.infradead.org
    .
    MTD Driver
    The
    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 Issues
    Often, 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.
    PARTITION NAME                DESCRIPTION                FILESYSTEM TYPE                SIZE
    -----------------------------------------------------------------------------------------
    MTD0                        Bootloader                None                        256K
    -----------------------------------------------------------------------------------------
    MTD1                        Linux kernel                None                        1M
    -----------------------------------------------------------------------------------------
    MTD2                        Root filesystem                cramfs                        8M
    -----------------------------------------------------------------------------------------
    MTD3                        /usr/local and                jffs2                        6.75M
                            home directories
    -----------------------------------------------------------------------------------------
    Table 1. Sample Partition of a 16MB Flash System
    One
    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.
    FILESYSTEM TYPE                        SPACE REQUIRED
    ------------------------------------------------------------------
    jffs                                5.93MB
    ------------------------------------------------------------------
    jffs2                                3.09MB
    ------------------------------------------------------------------
    cramfs                                2.85MB
    ------------------------------------------------------------------
    Table 2. Flash Space for a Full-Featured Root Filesystem
    With
    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.
    另外, 可参考下述文章:
    1,
    http://www-128.ibm.com/developerworks/cn/linux/embed/embdev/
    2,
    http://www-128.ibm.com/developerworks/cn/linux/l-jffs2/
    3,
    http://www-128.ibm.com/developerworks/cn/linux/l-initrd.html
    4,
    http://www.cyberguard.info/snapgear/tb20020917.html
                   
                   
                   
                   
                   
                   
                   

    本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u/13991/showart_170587.html
  • 您需要登录后才可以回帖 登录 | 注册

    本版积分规则 发表回复

      

    北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
    未成年举报专区
    中国互联网协会会员  联系我们:huangweiwei@itpub.net
    感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

    清除 Cookies - ChinaUnix - Archiver - WAP - TOP