On Wednesday 07 March 2007 11:35, Johnson, Charles F wrote:
> I'm new to the game regarding flash file systems.  So no, I'm
> not that familiar with the consequences.
> I'm trying to learn enough to keep the hardware designers
> honest.

NAND chips designers need to incorporate all the logic necessary 
to provide reliable block access within the device -- the whole 
ECC business sucks.  They don't have to solve the issue of bad 
blocks, but that would be nice. But don't get too fancy like 
SD/MMC and compact flash, we want a regular chip package.  Look 
and RAM ECC designs for ideas, syndrome etc.

Having a new, but industry standard, low pin count interface 
would be nice.  Make this usable in a software bit-bang 
configuration, but also design it such that a h/w controller 
could off-load the i/o. (cf. i2c, spi), but remember 
performance/throughput counts.

Make asynchronous erase easy.
Make asynchronous write-behind easy.
Yes, some chips already have some limited capabilities.

Provide some non-volatile registers that can hold some
state for use by the host NAND drivers, something that
can be written rapidly and perhaps some for use by the NAND chip 
to record things such as "erase of block X in progress", and the 
like.  If this requires an additional low current backup supply 
(battery) so be it; we already have one for the RTC anyway.  
Mechanisms for fast recovery after powerfail are needed.

I'm sure to have more wishes once these problems are solved!

-imcd