RE: Intel sez: Synchronous Flash and XIP is the future -- thought s?

RE: Intel sez: Synchronous Flash and XIP is the future -- thought s?

[Paul Nash]

Actually, Intel's L18/L30 series of "wireless flash" has that feature,
Read-while-erase-or-write as long as the reads are not to the 8MBit
partition being dealt with in an erase or write.

But I agree with the points made here. :-)  I'm sure the above costs even
more... ;-)

-Paul


-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Monday, December 16, 2002 1:39 AM
To: Wolfgang Denk
Cc: Paul Nash; Linux-MTD (E-mail)
Subject: Re: Intel sez: Synchronous Flash and XIP is the future --
thoughts? 



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 -- thought s?

[David Woodhouse]

paulnash@wildseed.com said:
> Actually, Intel's L18/L30 series of "wireless flash" has that feature,
> Read-while-erase-or-write as long as the reads are not to the 8MBit
> partition being dealt with in an erase or write.

1MiB is slightly saner but still not wonderful. At least I suppose it would 
allow you to have your kernel in the first MiB and hence not affected by 
changes to the file system. Doing it at an erase-block granularity would be 
better.

--
dwmw2

RE: Intel sez: Synchronous Flash and XIP is the future -- thought s?

[Paul Nash]

So what are people out there using in their designs for NAND primarily?  Raw
NAND?  NAND plus some bootable sector?  DiskOnChip?

-----Original Message-----
From: Charles Manning [mailto:manningc2@actrix.gen.nz] 
Sent: Monday, December 16, 2002 3:19 PM
To: Russ Dill; linux-mtd@lists.infradead.org
Subject: Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?


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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/