- 论坛徽章:
- 0
|
http://linux.omap.com/pub/
OMAP的tool chain， 2.6.8的核，1.1.1 UBoot
http://tree.celinuxforum.org/CelfPubWiki/PatchArchive
Cramfs的Patch
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=summary
new Kernel 2.6.21 with GIT
http://buildroot.uclibc.org/
quickly make a toolchain and rootfs
http://oskfordummies.hp.infoseek.co.jp/
一个Japan网站
http://tree.celinuxforum.org/CelfPubWiki/KernelXIP
KernelXIP
http://tree.celinuxforum.org/CelfPubWiki/DataReadInPlace
DRIP
http://tree.celinuxforum.org/CelfPubWiki/ApplicationXIP
App XIP
Introduction
Rationale
Downloads
Patch
Utility programs
How To Use
General
Linear CRAMFS Usage
References
Cramfs
xip2fs
Sample Results
Future Work
Sample images
1 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
1.1 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 ffectively.
2 Downloads
2.1 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_5f040503_5fRelease
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
PatchArchive
2.2 Utility programs
3 How To Use
3.1 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.
3.2 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.
4 References
4.1 Cramfs
http://sourceforge.net/projects/cramfs/
4.2 xip2fs
Arnd Bergman, on LKML Sep 9, 2004 with subject " " wrote:
On
http://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.
5 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.]
6 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.
7 Sample images
TimRiker
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
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/35281/showart_281549.html |
|
免费注册
发表于 2007-04-19 15:30