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,
> including:
> 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
> 	David
>
>   


-- 
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