Subject: Re: MTD devices in NetBSD
To: Charles M. Hannum <mycroft@MIT.EDU>
From: Garrett D'Amore <>
List: tech-kern
Date: 03/23/2006 14:15:43
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
Phone: 951 325-2134  Fax: 951 325-2191