JFFS3 & performance

[Josh Boyer]

On Wed, 2005-01-12 at 16:30, Jared Hulbert wrote:
> > > Clarification on NOR technology.  Remember that the ability to run
> > > code XIP is effectively a requirement for a NOR chip.  This means no
> > > read errors can leave the chip.  I don't see this changing in the
> > > foreseeable future.  Any read errors that do occur would probably be
> > > caused by a failed/incomplete program
> > >
> > > We probably do want to be able to easily retire, reprogram, and/or
> > > test those blocks/pages that get read errors.  That would have to be
> > > done in the filesystem and the chip driver needs to be able report a
> > > read error occured.
> > 
> > What would you conclude from this (in the context of disscussion)? That
> > CRC *must* be *always* checked in case of NOR?
> 
> Retiring blocks/pages was an idea for the more lossy flash NAND, AND
> etc.  If your media goes bad with NOR you probably can't boot anyway.

That's not true.  Eraseblocks can go bad during operation.  That doesn't
mean that the whole device returns bad data.

> 
> I'm thinking the opposite conclusion.  If I understand this correctly
> most CRC's on NOR are wasted effort.  I don't claim to quite
> understand JFFS2 architecture yet but it seems to me the data CRC's
> are not needed for NOR, perhaps some of the other CRC's are not needed
> as well.

CRCs are needed.  Or rather, some form of checksum is needed.  Bits flip
during operation on NOR as well.  I've seen it happen.  It's rare, but
as David put it in an IRC conversation "it's a sanity check on the
hardware".

There's sort of multiple threads on this topic, so maybe check some of
those.  We even got Joern to agree they're needed :).

josh