Hmm... with everything everyone is saying about NAND, maybe I really
should just punt on it.

I need services for NOR flash that are much more likely to be reliable. 
They need wear-leveling, but in general you have to expose direct access
to certain offsets of flash to guarantee e.g. that a boot loader can
find your data at that offset.

I guess NAND devices that are used for media storage don't care about an
occasional bad bit, but in the applications I'm considering I can't
tolerate that behavior -- we need to know that once a bit is written and
verified with a read, it will stay *good* with a level of failure that
is commensurate with other kinds of device failure.

    -- Garrett

Charles M. Hannum wrote:
> On Thu, Mar 23, 2006 at 12:38:32PM -0800, Garrett D'Amore wrote:
>   
>> For NOR, absolutely.  Many NOR systems are actually mapped *directly*
>> into system memory.  I presume this to be true (that you can read less
>> than a sector, not the mapping bit) for NAND, but I confess I'm still
>> largely ignorant of NAND.
>>     
>
> All the NAND parts I've used can be read in 256- or 512-byte sectors.
> These are the sizes for the common NAND flash protocol that many vendors
> use (which, mysteriously, happens to be the same as SmartMedia).  This
> protocol also does overwrites (but not erases) with the same size
> sectors.  If you're truly writing less than a block, you'll need to
> buffer the old contents, erase, and rewrite.  Given that writes are
> really slow on many devices, avoiding erase/rewrite cycles when possible
> is a huge performance win -- not to mention that it will prolong the
> life of the media.
>
> Also note that with NAND flash it's generally a good idea to do a read/
> verify after writing, because the parts are notoriously low quality.
> This is also an opportunity to notice that you're losing with
> opportunistic overwrites and retry with a full erase/write/verify cycle
> before marking the block bad.
>
> Lastly, note that there is some moderately unavoidable attach-time
> overhead with NAND devices.  To be able to do random sector reads, you
> need to map where the logical blocks really are, which involves reading
> all the metadata.  This makes your {attach,mount,first access} time
> somewhat dependent on the size of the device.
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191