Intel sez: Synchronous Flash and XIP is the future -- thoughts?

Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Paul Nash]

Touting the various benefits that XIP advocates generally tout, Intel seems
to be waving the banner that XIP is the future.  Of course, it seems to me
that this is a little self-serving in that they probably charge more for
their more advanced flash parts that are suitable for this.  I know in the
past some fairly strong anti-XIP opinions have been expressed in this
community.  I myself find it far more probable that Intel is pushing this
because it happens to be what Windows CE uses rather than because it's a
clear technical winner.

I believe they claim board space as a win (though, you can't get rid of RAM
entirely, so this is tenuous).  They also claim power savings through less
RAM accesses.  I might buy this one.  It seems to me that XIP would
interfere pretty severly with systems like JFFS2, which must decompress a
block of memory anyway, so to really get the RAM reduction benefits of XIP,
you'd have to not use compression, which means you'd probably need twice as
much flash.  Is that a reasonable conclusion?

Any thoughts and opinions from the Linux experts here?

-Paul

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[David Woodhouse]

paulnash@wildseed.com said:
> so to really get the RAM reduction benefits of XIP, you'd have to not
> use compression, which means you'd probably need twice as much flash.
> Is that a reasonable conclusion? 

Yep. Especially so for those who sell flash chips, by an amazing coincidence
:)

The power saving point is fair -- flash does take less power than RAM. But
if you're _that_ short of power, you're likely to be using expensive (but
low-power) SRAM, and have the rest of the system so tightly specified that
you'll be more likely to be using something like eCos on it, not Linux.

With the chips available today and in the near future, XIP, at least for a
writable flash chip, makes virtually zero sense on Linux. Anyone who tries
to tell you otherwise is either on crack, trying to sell you something, or
both.

--
dwmw2

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Wolfgang Denk]

In message <1914.1040029662@passion.cambridge.redhat.com> you wrote:
> 
> The power saving point is fair -- flash does take less power than RAM. But
> if you're _that_ short of power, you're likely to be using expensive (but
> low-power) SRAM, and have the rest of the system so tightly specified that
> you'll be more likely to be using something like eCos on it, not Linux.

Agreed.

> With the chips available today and in the near future, XIP, at least for a
> writable flash chip, makes virtually zero sense on Linux. Anyone who tries
> to tell you otherwise is either on crack, trying to sell you something, or
> both.

Also you might find problems running recent (and future)  kernels  in
XIP  mode  -  the kernel text segment is often not exactly read-only.
Especially when you use one f the existing real-time extensions  (but
not only then). It seems the amount of tweaking that is necessary for
XIP  is  growing  with  each new kernel release - to a level where it
becomes impractical.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A list is only as strong as its weakest link.            -- Don Knuth

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[David Woodhouse]

wd@denx.de said:
> Also you might find problems running recent (and future)  kernels  in
> XIP  mode  -  the kernel text segment is often not exactly read-only.
> Especially when you use one f the existing real-time extensions  (but
> not only then). It seems the amount of tweaking that is necessary for
> XIP  is  growing  with  each new kernel release - to a level where it
> becomes impractical. 

Also true. Of course we have to distinguish between XIP of file system 
pages and of the kernel -- I was ignoring the latter because it's even less 
sane than the former. If you ever want to write to the chip, you have to 
disable all interrupts and wait while the chip is busy. For up to 20 
seconds, in the case of a slow erase.

Of course, you could poll the interrupt controller while polling the flash
for completion, and suspend the flash operation to service pending
interrupts if they happen -- but that's really not the kind of thing that
should be encouraged. Until people start making flash chips were every part 
of the chip other than the part which is being erased/written is readable 
during an erase or write operation, XIP is just a silly buzzword, for any 
writable application.

--
dwmw2

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Wolfgang Denk]

In message <2466.1040031514@passion.cambridge.redhat.com> you wrote:
> 
> Also true. Of course we have to distinguish between XIP of file system 
> pages and of the kernel -- I was ignoring the latter because it's even less 
> sane than the former. If you ever want to write to the chip, you have to 
> disable all interrupts and wait while the chip is busy. For up to 20 
> seconds, in the case of a slow erase.

Running the kernel XIP is not so insane. It can help to  reduce  boot
time.  We  still  more  than  3  seconds from power-on to application
start, which is not so  bad,  but  still  too  much  in  some  cases;
avoiding  the  memcpy()  of  some  2 MB of data is kind of attractive
then...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Just think of a computer as hardware you can program."
- Nigel de la Tierre

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[David Woodhouse]

wd@denx.de said:
> Running the kernel XIP is not so insane. It can help to  reduce  boot
> time.  We  still  more  than  3  seconds from power-on to application
> start, which is not so  bad,  but  still  too  much  in  some  cases;
> avoiding  the  memcpy()  of  some  2 MB of data is kind of attractive
> then...

That's true, although even if you have the kernel on a separate flash chip
to which you don't ever write, it does cost you later because you then run
from flash which is slower than RAM. I wonder if we could copy the kernel
from flash to RAM at runtime and fix up the page tables as we go, to get the
best of both worlds?

--
dwmw2

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Nicolas Pitre]

On Mon, 16 Dec 2002, David Woodhouse wrote:

> 
> wd@denx.de said:
> > Running the kernel XIP is not so insane. It can help to  reduce  boot
> > time.  We  still  more  than  3  seconds from power-on to application
> > start, which is not so  bad,  but  still  too  much  in  some  cases;
> > avoiding  the  memcpy()  of  some  2 MB of data is kind of attractive
> > then...
> 
> That's true, although even if you have the kernel on a separate flash chip
> to which you don't ever write, it does cost you later because you then run
> from flash which is slower than RAM. I wonder if we could copy the kernel
> from flash to RAM at runtime and fix up the page tables as we go, to get the
> best of both worlds?

On ARM this has no value since the kernel takes up at most 1 or 2 page table 
entries (1MB section descriptors that is).

Fortunately on ARM the kernel seems to be sane with .text and .rodata 
actually being read-only.

/me who incidentally just finished hacking a XIP kernel and filesystem patch
on ARM for a customer named Intel...


Nicolas

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[David Woodhouse]

nico@cam.org said:
>  On ARM this has no value since the kernel takes up at most 1 or 2
> page table  entries (1MB section descriptors that is).

But you could still start up quickly from flash without having to memcpy 
the entire kernel into RAM first, then once you're running copy the kernel 
text into RAM and alter the page tables so you're running from the RAM copy 
instead of the flash.

This gives you the fast startup of XIP without the runtime pain of XIP. But 
it's probably overkill.

--
dwmw2

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Nicolas Pitre]

On Mon, 16 Dec 2002, David Woodhouse wrote:

> 
> nico@cam.org said:
> >  On ARM this has no value since the kernel takes up at most 1 or 2
> > page table  entries (1MB section descriptors that is).
> 
> But you could still start up quickly from flash without having to memcpy 
> the entire kernel into RAM first, then once you're running copy the kernel 
> text into RAM and alter the page tables so you're running from the RAM copy 
> instead of the flash.
> 
> This gives you the fast startup of XIP without the runtime pain of XIP. But 
> it's probably overkill.

Well at that point I prefer the penalty of about half a second with storing
a compressed kernel in flash and let it decompress to RAM directly.  Oh and
btw we've made the ARM kernel decompressor XIP from flash long time ago.


Nicolas

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Wolfgang Denk]

In message <Pine.LNX.4.44.0212161215550.25780-100000@xanadu.home> you wrote:
> 
> Fortunately on ARM the kernel seems to be sane with .text and .rodata 
> actually being read-only.

Well, on PowerPC the .text and .rodata is read-only, too (normally) -
but only after the patching took place :-(


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Computers are not intelligent.  They only think they are.

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Nicolas Pitre]

On Mon, 16 Dec 2002, Wolfgang Denk wrote:

> In message <Pine.LNX.4.44.0212161215550.25780-100000@xanadu.home> you wrote:
> > 
> > Fortunately on ARM the kernel seems to be sane with .text and .rodata 
> > actually being read-only.
> 
> Well, on PowerPC the .text and .rodata is read-only, too (normally) -
> but only after the patching took place :-(

... which is the same as saying it's not read-only with regard to XIP.


Nicolas

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Charles Manning]

Ooooh flash, my favourite subject.

Yup, our Intel reps also put the hard sell on us too... Remember, Intel own 
NOR flash and are losing market share as more people switch to NAND. Already, 
most new WinCE devices are using NAND instead - at least for the bulk of 
their bytes.

In general, NOR flash is expensive, slow and not very dense. 

Because it is slow, you typically need to copy the image into RAM to get 
performance. This does not apply to synchronous flash which provides better 
bandwidth.

If you're going XIP and want performance, then you need a full bus-width of 
flash. The dollars and the board space start to stack up.

Intel's flash is expensive. Figure somwhere over $1 per MB.  NAND costs 
approx 30c/MB + SDRAM approx 20c/MB.  Intel's flash thus costs approx twice 
what a NAND/RAM image does.

One NAND flash footprint can give you up to 256MB of storage. 

NOR fully sucks for any sort of writeable file system performance. NAND runs 
a very usable fs with YAFFS or JFFS2.

The only benefit I can see in NOR is a faster boot. This is becoming less of 
an issue as more designs switch to sleep/resume models.

Now that the newer NAND devices support limited direct execution of code 
we're going to see the emergence of devices that have no NOR at all. 

IMHO, XIP is the past, not the future.

-- CHarles

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Russ Dill]

On Mon, 2002-12-16 at 14:02, Charles Manning wrote:

> Intel's flash is expensive. Figure somwhere over $1 per MB.  NAND costs 
> approx 30c/MB + SDRAM approx 20c/MB.  Intel's flash thus costs approx twice 
> what a NAND/RAM image does.
> 
> One NAND flash footprint can give you up to 256MB of storage. 
> 
> NOR fully sucks for any sort of writeable file system performance. NAND runs 
> a very usable fs with YAFFS or JFFS2.
> 
> The only benefit I can see in NOR is a faster boot. This is becoming less of 
> an issue as more designs switch to sleep/resume models.

It really depends on how much data you store, and how you use that data. 
Sure, for you, with a dynamic file system, and 256M of storage, NAND is an
easy choice. But many designs out there have static file systems, use 2M or
4M of flash, and for such designs, NOR offers a lot more simplicity for around
the same cost as a NAND + boot logic. With NOR flash, I can put a couple
cramfs filesystems on there, and use the boot block for storing a simple
journalled config, reliably. I don't have to worry about setting aside blocks
in case one goes bad.

I think this is the market intel is targeting, just change 2M or 4M to 4M or 8M
(no more compressed fs).

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Charles Manning]

On Tue, 17 Dec 2002 10:21, you wrote:
> On Mon, 2002-12-16 at 14:02, Charles Manning wrote:
> > Intel's flash is expensive. Figure somwhere over $1 per MB.  NAND costs
> > approx 30c/MB + SDRAM approx 20c/MB.  Intel's flash thus costs approx
> > twice what a NAND/RAM image does.
> >
> > One NAND flash footprint can give you up to 256MB of storage.
> >
> > NOR fully sucks for any sort of writeable file system performance. NAND
> > runs a very usable fs with YAFFS or JFFS2.
> >
> > The only benefit I can see in NOR is a faster boot. This is becoming less
> > of an issue as more designs switch to sleep/resume models.
>
> It really depends on how much data you store, and how you use that data.
> Sure, for you, with a dynamic file system, and 256M of storage, NAND is an
> easy choice. But many designs out there have static file systems, use 2M or
> 4M of flash, and for such designs, NOR offers a lot more simplicity for
> around the same cost as a NAND + boot logic. With NOR flash, I can put a
> couple cramfs filesystems on there, and use the boot block for storing a
> simple journalled config, reliably. I don't have to worry about setting
> aside blocks in case one goes bad.
>
> I think this is the market intel is targeting, just change 2M or 4M to 4M
> or 8M (no more compressed fs).

True, flexibility is the key. If 2-4MB with a static fs is all you need, then 
no need to take on all the extra drama.

However, to get back to the start of this thread, Intels big push is for the 
larger sizes (8MB+) where NOR is less palatable.

-- CHarles

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Michal Schulz]

On Mon, 16 Dec 2002, Wolfgang Denk wrote:

> > With the chips available today and in the near future, XIP, at least for a
> > writable flash chip, makes virtually zero sense on Linux. Anyone who tries
> > to tell you otherwise is either on crack, trying to sell you something, or
> > both.
>
> Also you might find problems running recent (and future)  kernels  in
> XIP  mode  -  the kernel text segment is often not exactly read-only.
> Especially when you use one f the existing real-time extensions  (but
> not only then). It seems the amount of tweaking that is necessary for
> XIP  is  growing  with  each new kernel release - to a level where it
> becomes impractical.

With the XIP in kernel it is relatively simple with 2.2.x serie of
kernels. I have managed to put most of 2.2.18 kernel onto flash, where it
was executing from. The most problems are with .rodata section, which is
not read-only for kernel. It is so because some structures (one passed to
procfs for example) are created dynamically during function call, so they
can be later found in .rodata section.

After some play with arch/i386/vmlinux.lds.S it is possible to divide the
kernel into two parts. One is really read-only one and may reside anywhere
in memory (so for example in rom or in Flash) and the other one must be
copied from rom/flash into ram.

with XIP and runable applications, it makes sence when one operates with
2.5MB of real RAM or less. but it doesn't save too much because tons of
data are in writable sections. It is possible to fix romfs driver and
implement XIP there.

Please also note, that many flash memories are unreadable during write
cycles, so it makes no sence to execute linux kernel from them and using
some parts as a writable fs, because it causes immediate lock.

-- 
Michal Schulz

Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?

[Wolfgang Denk]

In message <Pine.GSO.4.44.0212161155540.15280-100000@rose.man.poznan.pl> you wrote:
>
> With the XIP in kernel it is relatively simple with 2.2.x serie of
> kernels. I have managed to put most of 2.2.18 kernel onto flash, where it

We also tested this with 2.4.4 on PowerPC.

> was executing from. The most problems are with .rodata section, which is
> not read-only for kernel. It is so because some structures (one passed to

With recent kernels, at least on PPC, there are also places where the
.text  segment  is  written  into.  Some  people  even  find  "binary
patching" a cool idea.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
FORTRAN? The syntactically incorrect statement "DO 10 I = 1.10"  will
parse  and  generate  code  creating  a  variable, DO10I, as follows:
"DO10I = 1.10" If that doesn't terrify you, it should.