Subject: Re: MTD devices in NetBSD
To: Eduardo Horvath <eeh@netbsd.org>
From: David Brownlee <abs@NetBSD.org>
List: tech-kern
Date: 03/22/2006 18:45:08
On Wed, 22 Mar 2006, Eduardo Horvath wrote:

>
> Time to ask annoying questions.
>
> On Tue, 21 Mar 2006, Garrett D'Amore wrote:
>
>> Okay, I'm ready to start getting *serious* about supporting MTD (flash!)
>> devices in NetBSD.
>>
>> I've been doing a lot of research.   I want to sum it up here, along
>> with my thoughts.  I'm *particularly* interested in what core@ has to
>> say, so that perhaps we can move to actually implementing something
>> "real".  I am aware that others are starting to work on this problem,
>> but I think there is a lack of hard technical direction, and I think it
>> is important to get the "framework" right:
>>
>> MTD devices differ from regular "block" devices in some important aspects:
>>
>>    1. you have to erase a block before you write it (read-modify-write
>>       cycle)
>>    2. They need wear-leveling (writes "wear" the bits out) to prolong
>>       device life
>>    3. Many NOR devices can map directly into system memory while in read
>>       mode
>>    4. Generally NAND devices cannot do this, and usually need special
>>       handling
>>    5. You may have to to do bad block management (some block devices
>>       have to do this)
>>    6. Generally, most filesystems designed for use with block devices
>>       won't work so well
>>    7. Some devices support "execute in place", while some do not
>>    8. CompactFlash doesn't count, because it looks like an IDE disk. :-)
>
> How does the above differ from `regular "block" devices'?
>
> The erasure issue is only visible if you allow sub-block writes.  Is that
> something you're relly thinking about doing?  Is there any reason why you
> would want to leave a block erased without immediately writing useful data
> to it?

 	From a hardware perspective you should be able to perform
 	sub-block writes down to the word level. A perfect example
 	of that usage would be a an app performing synchronous
 	appending writes to a logfile. Providing you are not
 	_clearing_ any bit in the current block you can just 'write
 	over' the current values (assuming standard flash).

 	Its only during erase that the whole block becomes an issue.

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --