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
(text/plain)