Subject: Re: MTD devices in NetBSD
To: Garrett D'Amore <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/24/2006 08:18:46
David Laight wrote:
> On Tue, Mar 21, 2006 at 11:36:24PM -0800, Garrett D'Amore wrote:
> Another 2cents from myself...
> To my nowledge NOR flash (I don't know anything about NAND flash, except
> from reading this thread) has the following properties:
> 1) The 'erase block' size is typically 64k (128k when two 16bit parts
> are used to effect a 32bit device).
> 2) Erase is the only way to convert a bit from a '0' to a '1'.
> 3) Erase is very slow (~1 second on the devices I was using).
> 4) There is a limit of the number of erase cycles that can be done
> on each erase block before the data retention time is reduced
> below an acceptable level.
> 5) Individual bits can be written to change from '1' to '0'.
> 6) Write isn't that slow.
> 7) You can't do reads or writes while an erase is in progress.
I'm aware of all these. I've worked with NOR flash on a few different
projects myself, including extensive modification of the NOR code used
in the Sun Ray "automatic firmware update" logic.
> Any simple mapping of the flash device to a filesystem will suck due to
> the slow erase time. This can be alleviated by some simple caching
> strategies - at the cost of losing data on a power fail.
Yes. I don't want to do a "simple" mapping. As I've said before.
> Standard filesystems are 'flash unfriendly' for a variety of reasons,
> 1) Not telling the device when sectors are no longer needed
> 2) Repeated writes of metadata sectors.
> 3) Initialising data to 0 and not allowing both 0x00 and 0xff to mean
> 'nothing present'
> 4) inode atime/mtime updates
> 5) Not using single large (aligned) writes for write to large files.
> I actually suspect that if the filesystem did (1), allowed directory
> block and file allocation maps to be specified with 0xff => unused space,
> and that some other common inode updates were not done (or modified)
> the something like FFS could be used with a FTL that does a block lookup
> using data saved in a couple of flash sectors.
> (I'd write a logical_block+physical_block pair at the end of the lookup
> table every time a block has to be reallocted. Using a couple of bits
> to mark validity....)
My intent is to use "standard" filesystems in *readonly* mode. If you
want to use read/write on flash, you either need to use the device
directly (and have the logic in your own application code), or you
should use a dedicated flash file system.
I *hope* that either I or someone will create a filesystem suitable for
use on flash. No promises yet. :-)
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191