value of XIP? and whether it works with 2.6 kernel?

  working with a recent post to the MTD mailing list, and reading the
wiki part on XIP over at www.denx.de, i'm curious about who's using
XIP with the 2.6 kernel, specifically with the 8xx boards.

  as i read it from david w's post on the MTD list, XIP has limited
value since flash is noticeably more expensive than RAM anyway.

  so, thoughts?  who's actually using this?  and it's not clear from
the DENX page that there's a patch for the 2.6 kernel -- that page
refers specifically to 2.4.

  anyway, i'm just curious, wondering whether it would be worth giving
it a try, just for the entertainment value.

rday

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

   as i read it from david w's post on the MTD list, XIP has limited
value since flash is noticeably more expensive than RAM anyway.

The main value, I believe, is as part of a rapid boot setup - you can
avoid the decompress and copy phase.

Mark Chambers

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Aug 25, 2004, at 7:22 AM, Mark Chambers wrote:

The main value, I believe, is as part of a rapid boot setup - you can
avoid the decompress and copy phase.

The XIP has little effect on this.  Wolfgang hit the important points.
I originally did XIP on the 8xx many years ago for an embedded
appliance that was DRAM challenged.  It saved a little memory,
but along with it came the pinned TLB which helped a little with
performance.

The kernel code was tightly integrated with the initialization
code.  This is where the start up time was reduced.  The
initialization code was minimal, and it also immediately put
up some graphics on the screen which made the user
aware the appliance was "doing something."  After minimal
part set up, the kernel then started running was modified
to continue the screen update as it booted.  In the end, it
really didn't boot much faster, but at least the activity on
the screen was psychologically useful :-)

The three big things that slow down the boot process are
serial console output (which can be many seconds), timeouts
in the boot code waiting for user input, and diagnostic
tests (testing memory, checksum of images in flash, etc.)

With the large amount of memory in all systems these days,
XIP does nothing to help that.  The XIP on its own doesn't
do anything to speed up the operation of the system.   In
the whole of a system design XIP can be a useful tool, but
just enabling the option without any larger problem to
solve is just entertaining, not very useful :-)

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Aug 25, 2004, at 7:22 AM, Mark Chambers wrote:

quoted

The main value, I believe, is as part of a rapid boot setup - you can
avoid the decompress and copy phase.

Dan Malek responded:

The XIP has little effect on this.  Wolfgang hit the important points.
I originally did XIP on the 8xx many years ago for an embedded
appliance that was DRAM challenged.  It saved a little memory,
but along with it came the pinned TLB which helped a little with
performance.

I guess I wasn't basing my comment exclusively on 8xx, but thinking
more of the general linux quick boot work being done, as in this
paper from the linux 2004 symposium (see section 4):
http://www.finux.org/Reprints/Reprint-Bird-OLS2004.pdf
So, in other words, maybe XIP will come back again?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Aug 25, 2004, at 12:10 PM, Mark Chambers wrote:

http://www.finux.org/Reprints/Reprint-Bird-OLS2004.pdf

That's a very misleading paper, and if you read it carefully
actually supports what I said.

In total, XIP saved them about 80 mS, which is the time it
takes to copy a kernel to RAM.  Nothing else in the
paper is related to XIP.  You don't have to use a compressed
kernel in any environment, and most of the paper talked
about reducing other boot up delays.  the XIP is an
insignificant player in boot up time, it does have other
value as Wolfgang pointed out.

The kernel XIP from Flash isn't very hard to implement,
it is just very board configuration dependent.  All you
need is a proper linker command file for your board
and a couple of start up MMU hacks......for PowerPC.

Thanks.

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Wed, 2004-08-25 at 13:01 -0400, Dan Malek wrote:

The kernel XIP from Flash isn't very hard to implement,
it is just very board configuration dependent.  All you
need is a proper linker command file for your board
and a couple of start up MMU hacks......for PowerPC.

It's a little bit harder than that if you want to actually write to the
same flash chip you're running from. :)

Not a _lot_ harder though -- you just put the flash-mangling routines
into a separate section in RAM and disabling interrupts while you're in
them (you can poll for interrupts, suspend pending writes/erases and
handle the interrupts without particularly evil latencies).

I did it a long time ago -- just couldn't ever see the point in merging
it.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Aug 25, 2004, at 9:27 PM, David Woodhouse wrote:

It's a little bit harder than that if you want to actually write to the
same flash chip you're running from. :)

Many of the "modern" parts will let you do that.  Load a buffer,
start the update, come back later to check it.  The MTD may
need some updates to do that, but I'm sure you're up for it :-)
Software upgrade of embedded systems is a totally different
discussion.  Having multiple images that you need to choose
based upon validity, dates, failure to boot previously, etc. are
all things that significantly increase the boot time. :-)

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/