Execute in place.

[David Woodhouse]

On Wed, 2003-06-04 at 10:57, Charles Manning wrote:
> Is there any discussion leading up to XIP? ie. Why? ... and why not!

Why? Because your hardware designer didn't realise that RAM is cheaper
than flash, and gave you more flash than you need and not enough RAM.
Hence you want to run stuff uncompressed and use up all that nice
expensive flash space, while retaining your precious RAM.

Or, more charitably, perhaps you _really_ care about power consumption
and observe that flash takes less power than RAM.

Why not? Because it's mutually exclusive with compression and there are
interesting performance issues.

> It scares me that this adds a potentially huge interrupt latency. Some NOR 
> devices need a good 20usec or so to get into erase suspend state. There are 
> many situations (eg ARM FIQs) where this would not be a nice thing to do.  
> Thus, mixing XIP with say a file system which might cause erases at 
> (relatively) arbitrary times needs to be done with great caution. Men with 
> red flags needed up front.

True. In practice it doesn't suck anywhere near as much as I expected it
to. Mount an empty flash as JFFS2, causing the whole thing to be erased
and cleanmarkers to be written, while flood-pinging... observe IRQ
latency really isn't that bad.

If you're doing pseudo-DMA tricks with FIQ, then of course you are going
to have problems, but that's not really the common case.

> The fundamental implementation seems quite simple and elegant.IMHO.

Good. My main concern was that there would be some platform where we
can't actually poll for interrupts like this, and we have to redirect
the IRQ vectors to somewhere in RAM, etc. I suppose that can still be
hidden behind xip_cli(), xip_sti() and xip_irqpending() though.


-- 
dwmw2