Re: Should flash hardware look like UBI?

[Bill Gatliff <bgat@billgatliff.com>]

David Woodhouse wrote:
> But I've also been thinking about exactly what we _do_ want. We
> certainly want something a little more capable than the raw interface to
> NAND flash that ONFI provides.
>   

Actually, I prefer that we make the hardware as dumb as possible.  I'm 
ok with the chip timing its own flash erase and programming cycles, but 
everything else I want to keep up in our software.  That way we can 
adapt the functionality to whatever level of control that we want.

ECC can be difficult to get right, and the specific algorithm chosen can 
be application- and environment-dependent.  If it's baked into the chip 
then the algorithm decision is already made, and any bugs in the 
implementation are impossible to correct.  Also, like other posters have 
mentioned regarding SD/MMC firmware, any firmware running in a NAND 
flash will require thorough documentation so that users of the chip can 
accommodate its needs for power management, etc.

And on top of that, one really needs to know if the bits that they are 
reading back have required ECC to recover.  If a region of flash is 
failing, a sudden increase in the amount of error correction needed will 
tell you that some evasive action is necessary.  By its very nature, ECC 
can never be completely transparent to the user.

I don't see any substantial benefit to a chip having an inbuilt, 
hardware "memcpy" to allow one to move data around without reading it 
out.  That just sounds like more undocumented stuff to go wrong.  :)  
And more design decisions that have been made without the user's consent.


Just my US$0.02.


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com