From: eLinux.org

Application XIP

Contents

Introduction

This page describes the feature Application XIP. This is a method of
storing and executing applications directly from the file system,
instead of first loading them into RAM. With Application XIP, the text
(or code) pages of the application are never loaded into RAM. Instead,
the (?? incomplete text)

Rationale

This feature is important for these reasons:

  • reduction in RAM footprint
  • faster first invocation
  • reduction in RAM fragmentation (for non-MMU systems)
  • reduced power consumption of flash vs. SDRAM

Greg Ungerer said this on the ksummit-discuss list (July 2004):
“Application XIP provides a win of keeping the application code in flash
even when that is shared. Can make a difference on small memory systems.

It also helps alleviate the contiguous memory problem (or memory
fragmentation if you prefer) when you don’t have an MMU. We need to be
able to allocate a big enough contigous memory region to load the text
into. Can be a problem on systems that have been running for a while and
free memory is fragmented. If the application can be run XIP from flash
then you at least don’t need to worry about that. (This is a very real
problem on small RAM systems).

The argument isn’t so much RAM is cheaper than flash either. Small
embedded systems will have flash and it comes in discrete sizes (1, 2,
4, 8 MB, etc). Sometimes it just makes sense to use what flash you have
more effectively.”

Downloads

Patch

  • Code for Linear CramFS and XIP for 2.4.20 is in the base patch
    (base-2.4.20-8.patch) in the CELF 1.0 release. The code is not
    isolated into its own patch, but can be found pretty easily by
    grepping for CRAMFS_LINEAR. See the
    CELinux_040503_Release
    page for the source.
  • Patches for Linear Cramfs feature for 2.6.9, 2.6.10, 2.6.12 and
    2.6.14 are in the Patch Archive

Utility programs

How To Use

General

To use application XIP, you have to use a file system which supports it.
One file system known to support it is Cramfs, described below.

Note that on an MMU-less system, the flash pages cannot be remapped to
arbitrary locations in the memory space. Therefore, the text pages must
be stored in flash contiguously and in order. Thus, only a file system
which stores meta-data (directory nodes and index tables) separate from
file data, and which allows a file to be saved as a single linear image,
can support XIP under these conditions.

Linear CRAMFS Usage

The “cramfs-linear-xip” patch for kernel.org linux-2.6.9 enables a
kernel to perform XIP of applications from CramFS filesystems. The code
is derived from the source base of
Montavista Software’s
products and has copyrights by Shane Nay and Robert Leslie. I’m not sure
if these are actively maintained anywhere, nor whether the
Montavista versions have
deviated from other versions.

To use this feature…

You’ll need a version of mkcramfs that does not compress files with
sticky bit (chmod t) set (some versions require option -x to enable this
behavior). I believe various versions are floating about, or I can look
into sending a version of this as well.

Copy the resulting image to a flash partition on your board.

Build a kernel with:

  1. CONFIG_CRAMFS_LINEAR=y
  2. CONFIG_CRAMFS_LINEAR_XIP=y

and if it is the root filesystem:

  1. CONFIG_ROOT_CRAMFS_LINEAR=y

When mounting the filesystem specify flags physaddr=0xNNNNNNNN, where
NNNNNNNN is the physical address at which the flash partition appears.
The dmesg output of the mtd probe and map drivers will show this.

For example, on my OMAP1510 Innovator mtd partition #3 is at 0x240000,
as shown in the boot log:

  1. Creating 5 MTD partitions on "omap_nor_cs0":
  3. 0x00000000-0x00020000 : "bootloader"
  4. 0x00020000-0x00040000 : "params"
  5. 0x00040000-0x00240000 : "kernel"
  6. 0x00240000-0x01000000 : "rootfs"
  7. 0x01000000-0x02000000 : "filesystem"

To mount that as root I set U-Boot bootargs as:

setenv bootargs console=ttyS0,115200n8 noinitrd root=/dev/null rootflags=physaddr=0x240000 rootfstype=cramfs

Or can mount non-root with:

mount -t cramfs -o physaddr=0x240000 none /mnt/mtd

Note that this patch bypasses the MTD subsystem and generally assumes
all flash chips backing the XIP partition are wholly dedicated to
serving XIP images, and that the flash chips are never in any state
other than read mode (for example, no writeable partitions that are
backed by the same chip). You’ll need to understand the flash chip
topology of your board to correctly partition the mtd devices. Also note
that certain flash chips are able to independently read and write
different areas and the MTD layer may support this, so the restriction
might not apply to your board.

This hasn’t been tested very much at this point (Nov 8th 2004) so please
let us all know if any problems or suggestions.

What I will guess is that the MTD_XIP stuff (which is in linux-mtd but
only for certain flash types and platforms) will eventually supplant
Linear CramFS and only the XIP portions of the patch will then be
needed, which might be more palatable to the kernel maintainers. I’ll
talk to some folks about this. CELF might then be interested in
contributing to (or advocacy of) support for more flash types and
platforms for MTD_XIP.

References

Cramfs

CRAMFS

xip2fs

Arnd Bergman, on LKML Sep 9, 2004 with subject “ “ wrote: On
linuxvm.org/patches, you can find a file
system called xip2fs, that uses an ext2 read-only fs for XIP. The code
there works only if the backing memory is a zSeries DCSS memory segment,
but it should be fairly easy to port to some other low-level memory
provider.

Sample Results

Here are some rough numbers: Time to run shell script which starts TinyX
X server and “xsetroot -solid red”, then shuts down:





















InvocationNon-XIPXIP
First time3.195 seconds2.035 seconds
Second time1.744 seconds1.765 seconds

It was measured on a 168MHz ARM 925T TI OMAP 1510. In both cases the
filesystem was in flash. Note that once the Non-XIP application pages
are in RAM in the page cache, the Non-XIP case beats the XIP case
(probably due to the penalty to access flash memory).

So the only performance win is on the first invocation of the
application. The biggest benefit from Application XIP is from saving the
RAM required for the text section of the program.

\<\>

Future Work

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

  • Cooperate with MTD to allow XIP from partitions managed by the usual
    MTD interfaces.
  • Or at least not require the physical address to be supplied
    (filesystem can look it up).
  • Cooperate with writeable MTD partitions on the same flash chip:
    suspend write/erase in progress to allow XIP reads.
  • Support additional filesystems.

Sample images

Tim Riker built some sample images for
a TI OMAP 1510 Innovator that use XIP kernel with XIP user space. The
kernel is a Montavista kernel
with XIP enabled. The filesystem uses uClibc and
busybox and does a dhcp request on boot. inetd and telnetd are enabled
on boot up. He uses rrload to boot with the following as kernel
arguments:

noinitrd console=ttyS0,115200n8 root=/dev/null rootflags=physaddr=0x00260000 ip=none init=/linuxrc

Categories: