[OLPC-devel] Flash driver status.

[David Woodhouse]

I have the prototype board up and running, and I've implemented a basic
driver for the NAND controller on the CS5536, which will be merged into
Linus' kernel tree after the 2.6.17 release:
http://git.infradead.org/?p=mtd-2.6.git;a=commitdiff;h=179fdc3f8dec5757ddbebd95a1b493d65fa08671

It has basic functionality and I have JFFS2 mounting on it, but it's not
complete -- it doesn't yet support the hardware ECC, and it's fairly
suboptimal in a few other ways too -- especially in the number of MMIO
cycles it takes to waggle the flash command and address lines when
sending commands, and the way it reads data from the same MMIO address
byte by byte instead of just using memcpy.

Currently, it takes about 24 seconds to mount an almost-empty JFFS2 file
system covering the whole 512MiB of flash. I should be able to get it
going faster than that though, and that's before I start on improvements
in JFFS2 itself.

The first task I have before that is to get the bad block table working.
NAND flash chips ship with bad blocks which must not be used, and those
blocks are marked in a virgin chip by the fact that they have a zero
byte at certain offsets. Obviously, the chip may naturally end up with
zeroes at those locations during normal operation, so this isn't a
viable way to mark bad blocks while you're using it -- you'd get false
positives. Instead, you make a 'bad block table' with a bitmap of the
bad blocks, and store that on the flash for yourself.

This is discussed on page 14 of the chip data sheet at
http://www.samsung.com/Products/Semiconductor/NANDFlash/SLC_LargeBlock/4Gbit/K9F4G08U0M/ds_k9f4g08u0m_rev10.pdf

Linux has an implementation of this, and I just need to tie up the loose
ends and make it work for us. At that point we'll be able to use JFFS2
for real on all the prototype boards, although as I said there's still
some optimisation to do.

-- 
dwmw2