AXFS

From eLinux.org
Revision as of 22:13, 12 November 2008 by FransMeulenbroeks (Talk | contribs) (Utility programs)

Jump to: navigation, search

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.

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

How to validate

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

Sample Results

[Examples of use with measurement of the effects.]

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: