Can jffs2 support XIP extensions?

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?

Much thanks in advance...
Chris B.

P.S.
Thanks for the replies re: my CVS question (and ipv6). I was hoping that ipv4 would have been restored by now, but I think this will give me the excuse to finally upgrade to ipv6. Also, thanks for the howto link David...!

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

Unfortunately, boot time is my primary concern. However, I'm planning on booting an uncompressed linux kernel which should save quite a bit of boot time. I'd be curious to know how much of an improvement is gained by using XIP in an uncompressed kernel without XIP - versus - uncompressed kernel _with_ XIP.

I would tend to think the difference is quite small, or OLS wouldn't have benchmarked with a compressed kernel against an uncompressed one. I think I'll steer clear of XIP for now...

Since we're on the topic, does anyone have any pointers, website links or kernel patches that have tips on accelerating kernel boot time?

Thanks!
-CB

On Tue, Aug 24, 2004 at 02:27:01PM -0400, Christopher M Bergeron wrote:
<snip>

http://tree.celinuxforum.org/pubwiki/moin.cgi/BootupTimeWorkingGroup

<snip>

--
Regards,
George

A debate of the merits of various OS technologies for battery-powered portable devices would be interesting, but a number of awfully bright product designers are choosing Linux for *some* reason. ;) Makers of cell phones do really really care about power. And periodic timer ticks are being worked on (such as the Variable Scheduling Timeouts technology of George Anzinger's High Res Timers project).

For the kernel boot time it's true that boot times tend to be dominated by the decompression step. I measured this on a couple platforms at one point (some of my measurements may have been in the OLS presentation, not sure). I didn't directly measure kernel boot times of an uncompressed non-XIP kernel, but would roughly guess an uncompressed non-XIP kernel would boot to /sbin/init in only about a few tens of milliseconds more time (I'm guessing about the increased time to copy an uncompressed tetx image to RAM) than an XIP kernel on a 266MHz PowerPC 405LP, and 168MHz OMAP ARM 926T is probably similar (it seems to better deal with the cache effects).

Application startup times non-XIP vs. XIP, compared to either CramFS compressed or ROMFS uncompressed, can add up to a more significant savings -- about 2 seconds for a TinyX startup and app start in the configuration I tried. I have more data on kernel boot time, application startup, system sizing, and runtime performance benchmarks that I can send to anyone interested.

And yes, lower-overhead alternative technologies to help reduce SDRAM needs and sub-second startup times for consumer electronics would be welcome and are the subject of various other projects...

Todd Poynor
MontaVista Software

Also remember that on many systems, flash is a lot slower than RAM, so it is entirely possible that an XIP kernel would actually be _SLOWER_ than non-XIP!

joshua

there are a number of examples of boot times and runtime performance posted on the web and ALL of them show that the boot times of XIP enabled kernels are primarily lower due to the kernel
not being decompressed and other steps actually being slower.

Table of bootup times:

   Boot Stage                         Non-XIP  Time XIP Time
   Copy kernel to RAM                 85 ms    12 ms 
   Decompress kernel                  453 ms   0 ms
   Kernel time to initialize
   (time to first user space program) 819 ms   882 ms
   Total kernel boot time             1357 ms  894 ms
   Reduction:                         -        463 ms

(from: http://tree.celinuxforum.org/pubwiki/moin.cgi/KernelXIP)

The execution times of most system calls are clearly longer (not sure if it was a 405/266 or a OMAP/168) fork was reported at 7.1 vs 4.8 us , trivial system calls will be about the same time (did not find the reference - if of interest I can dig it out).

The only (?) real argument for XIP is system RAM requirements on very small systems (see: http://www.denx.de/twiki/publish/DULG/ConfigureLinuxForXIP.htm)

hofrat

Yes, those are the numbers I measured on a PPC405LP. The step of copying the necessary kernel image is also slower non-XIP, since XIP copies only the initialized data sections. If an uncompressed non-XIP image is used then that particular number will increase, partially offseting the gain due to skipping the decompression. Depending on the sizes involved XIP will likely be faster by a few tens or hundreds of milliseconds. When combined with application XIP of several executables and shared libraries from a CramFS filesystem this can add up to a significant gain; if ROMFS is used to avoid compression then the difference is less but still significant.

Should be 7.1ms vs. 4.7ms, on OMAP (and 4.1ms vs. 1.1ms on PPC405LP, which seems to have a lower locality of reference or some other uninvestigated disadvantage running XIP). I've got the full LMbench runs and some additional experimentation that produced those numbers as well. The system will definitely run overall slower due to the slower memory, but certain operations such as the first exec of an image will be faster -- subsequent exec's of the same image may be as fast or faster after the block cache is warmed.

System startup time reduction (including applications) is certainly a consideration as well. After evaluating unit production cost, power consumption, startup time, and performance, some cell phone designers have chosen to go the XIP route, although no word on whether they'd choose it again the next time. ;)

Todd Poynor
MontaVista Software