Can jffs2 support XIP extensions?

David Woodhouse dwmw2 at infradead.org
Tue Aug 24 11:10:20 EDT 2004


On Tue, 2004-08-24 at 10:43 -0400, Christopher M Bergeron wrote:
> Does anyone know if jffs2 can utilize/support XIP (eXecute In Place)?  
> I've read that only CramFS can work wit it.  I'm a little unclear about 
> how XIP works and it's implications with jffs2 / CramFS.
> Can anyone shed any light on this for me?

If you want Linux rather than something smaller, like eCos, then you
almost certainly don't want XIP.

XIP is for obvious reasons mutually exclusive with compression. You
throw away flash space in order to save RAM and to make data and code
access by the CPU slower.

Flash is more expensive than RAM -- your board will be cheaper if you
use half the flash and compress its contents, than it would be if you
use half the _RAM_ and XIP instead.

If you really really really care about power, then you might care that
RAM actually takes more power at runtime than flash does. But then we'd
just laugh at you for using Linux instead of something much smaller and
in particular without a periodic timer tick :)

In order to use XIP, you muck with the MMU to make mmap() of files on
the file system actually set up page tables to point at the flash chip.
You then have to care a lot about leaving the flash chip in read mode at
all times when userspace might be looking at it. 

Because cramfs is a read-only file system, it's easy enough to do this.
The files which are marked for XIP are carefully arranged so that each
logical page is physically page-aligned on the medium to allow the MMU
to map it. It would be a lot harder to achieve that in JFFS2, and
largely pointless. 

The only reason for using XIP under Linux which is even vaguely sane is
to improve boot time. But since the figures shown at OLS were comparing
apples and oranges -- compressed non-XIP kernel vs. uncompressed XIP
kernel, with a lot of the time taken being the actual decompression, I'm
not entirely convinced. There may well be better alternatives, without
the runtime and hardware overhead.

-- 
dwmw2





More information about the linux-mtd mailing list