文件系统
F2FS

嵌入式 Linux 知识库

From: eLinux.org

AXFS

Contents

Description

The Advanced XIP File System is a Linux kernel filesystem driver that enables files to be executed directly from flash or ROM memory rather than being copied into RAM.

This project was started by engineers working at Intel. Since that the key developers have moved over to Numonyx. AXFS is intended to be a replacement for Linear XIP CRAMFS, and combines features from CRAMFS and SquashFS. The advantage over existing solutions is that it can provide reduced RAM with less flash because it is possible to compress only those pages that contribute to RAM savings. It includes tools to identify pages that should be uncompressed. It is Beta quality as of July 2006.

Rationale

This feature is important because XIP is a very common method of conserving RAM on an embedded system.

Furthermore some boot time reduction can be achieved.

Resources

Project site and contacts

The main project site is at: axfs

Those interested can send an email using the interface at axfs contact and they will be informed when the final version is released.

Documents

Specifications

See Kernel XIP Specification R2

Downloads

Patch

See http://axfs.sourceforge.net/.

Utility programs

There are two utility programs:

  • mkfs.axfs described here is a simple filesystem builder. It compresses using 4K blocks and accepts profile data in .csv format (and perhaps also in xml format). This differs from what is described in the document. The program generates a single image file with both the compressed and uncompressed data. Upon mounting the image the uncompressed XIP data are copied to RAM. This program is GPL.
  • A Numonyx proprietary image builder described here. Judging from the documentation (-c option) this builder provides larger pages (and hence better compression) similar to the larger pages that are used by SquashFS. Apparently it can also generate two output files (-b and -o options). I assume that way you get two images. One with the compressed data, one with the XIP data. That would allow e.g. putting the compressed data in NAND flash and the XIP data in NOR flash or RAM.

How To Use

  • Download the patches from the svn archive as described on this project page.
  • Apply the patches as described here.
  • In the config file two new configuration options will show up. One is called CONFIG_AXFS and includes the AXFS filesytem. The second one is called CONFIG_AXFS_PROFILING and enables the profiling. You need to enable both at first.
  • Make an axfs filesystem (using mkfs.axfs) and write that image to flash. (e.g. using nandwrite).
  • Boot your new kernel.
  • Run whatever applications (from the AFXS partition) you want to have in XIP. If you are interested in boot improvement these are typically the things run from init.
  • Internally AXFS records the page accesses. Once you ran all programs you want to have in XIP, you can copy /proc/axfs/volumeX to a file (where X is typically 0).
  • If desired you can remove things from the file. Note that the file consists of lines with a filename, an offset and a counter. This describes the page that is put in XIP. You'll notice that not all of the file is put in XIP. Only those pages that are actually called are put in the XIP section.
  • Use the file from the previous version as input for mkfs.axfs. This will generate a file with both XIP and non-XIP data (the former uncompressed, the latter compressed).
  • Write this file to flash, and use it. You'll see an increase in mount time, as the XIP data is copied to RAM at mount time. However the executables should start faster as no data need to be read from flash or copied in RAM. B.t.w. it is possible to have your root filesystem as axfs filesytem by using the kernel boot parameter "rootfstype=axfs".
  • To reduce size and increase performance rebuild the kernel with profiling (CONFIG_AXFS_PROFILING) turned off.

How to validate

[put references to test plans, scripts, methods, etc. here]

Sample Results

No sample results are available yet.

However from studying the documentation and knowing how XIP works, a boot peformance gain can be expected when running from NOR flash. The amount of gain cannot really be qualified because it depends on how often the code is executed. E.g. consider an often executed loop in NOR. The advantage with NOR flash and XIP is that you do not need to load the page (so you save some time). However as NOR is slower there will be a small penalty during every instruction executed from NOR. So if you have a loop that is executed very often the cumulative penalty will exceed the gain from not having to load the page. Of course if you know that this is the case you can exclude this page from XIP.

mkfs.axfs does not support generating two separate images. Therefore in the open source scenario the only way to test this is by putting both the XIP and non-XIP data in NOR.

Alternatively it is possible to put the generated image in NAND. In that case the XIP data is loaded during mounting. Effectively this does not gain much. You only shift the reading from program execution to mounting. Of course there can be a small saving since no in-memory copying is needed. Benchmarks need to be performed to actually quantify the gain.

With the proprietary image builder it seems possible to create two images, one with XIP and one without XIP. This allows for situations where the XIP data is in NOR and the non-XIP data is in NAND. Alternately the XIP data could be in RAM and loaded by the boot loader. It might be possible that this gives some gain (as the boot loader might have less overhead reading a file than linux has). Again this need to be benchmarked.

Case Study 1

Case Study 2

Status

Jared Hulbert of Intel writes (in July 2006):

The filesystem is working well. We optimized an Opie Linux build using cramfs and axfs. The resulting images where 49MB XIP cramfs, XIP axfs used only 39MB, and 34MB for a fully compressed cramfs. We're polishing it up for release hopefully in the next couple weeks. We are also debugging a 2.4 port which we will make available as well.

In august 2008, the project submitted to LKML for the second time. On mid nov 2008, the project svn archive contained patches for 2.4.21 and 2.6.10 to 2.6.27.

  • Status: [not started??]
    • (one of: not started, researched, implemented, measured, documented, accepted)
  • Architecture Support:
    • (for each arch, one of: unknown, patches apply, compiles, runs, works, accepted)
      • i386: unknown
      • ARM: unknown
      • PPC: unknown
      • MIPS: mostly works (some open issues and more testing needed)
      • SH: unknown

Future Work/Action Items

Here is a list of things that could be worked on for this feature:

  • More testing/maturing
  • An improved open source mkfs.axfs that provides separate images and compression using larger blocks than 4K.
  • Benchmarking

Category:

书籍推荐