Application..
Asynchronou..

嵌入式 Linux 知识库

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:

CONFIG_CRAMFS_LINEAR=y
CONFIG_CRAMFS_LINEAR_XIP=y

and if it is the root filesystem:

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:

Creating 5 MTD partitions on "omap_nor_cs0":

0x00000000-0x00020000 : "bootloader"
0x00020000-0x00040000 : "params"
0x00040000-0x00240000 : "kernel"
0x00240000-0x01000000 : "rootfs"
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:

Invocation Non-XIP XIP
First time 3.195 seconds 2.035 seconds
Second time 1.744 seconds 1.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.

<<Need some data on that.>>

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:

书籍推荐