 state of nand mtd driver at start of project state of nand mtd driver at start of project current state of nand mtd the current nand mtd supports basic read write functions the code is hardwired to support the nand devices on a spia board the ecc code supports 256 byte sectors there are 3 files nandc nand support algorithms unfortunately there is no hardware abstraction ie the hardware is assumed to be the spia board but this is relatively easy to add spiac this initialises the spia hardware to set up the addresses for the hardware access eccc ecc for 256 byte pages what needs to be done at this level hardware abstraction of nandc this allows this code to be used with different hardware configurations the larger memory sizes use 512 byte pages the memory sizes supported by 256byte pages are obsolete 512byte pages are treated as two subpages of 256 bytes each the samsung code is calculation based ie maybe slow the toshiba code is table based and probably faster check if they are equivalent write a software emulation for a nand device the purpose of the software emulator is allow debugging without the need for hardware nand file systems need to be fault tolerant the hardware can t be forced to fail to test out bad block detection handling etc a software emulator can be forced to fail  overall flash system diagram a diagrammatic representation of support for smartmedia nand and nor as well as both fat16 and jffs2 might look like the above the nand flash subsystem uses common layers for hardware access ecc bad block handling and lowlevel formatting based on smart media lowlevel specs by using the same low level formatting and ecc as much as possible we gain some benefit in testing reuse etc the lowlevel formatting would differ in that fields used to store the lba and reserved fields might be used for something else journaling tags  concerns with using jffs2 on nand there are some reasons why jffs and nand might not work together that well two particular concerns re booting nand devices are typically much larger than nor eg 128mb is currently a large nand chip while 16mb would be considered a large nor chip thus the data structures associated with flash management are likely to be much larger also jffs2 scans the media on boot to build data structures representing the nodes in the system this increases the boot time nand is not random access but must be read serially this means that the scanning routine can t just merrily skip through the flash instead the whole flash must be read and ecc d first this slows scanning and hence booting thus booting a 128mb nandbased jffs2 is likely to look something like this read and ecc every last byte on the device even if we only need a few bytes per page for journaling headers and digest the contents at say 5mb second this will take 25 seconds each node requires a 16byte structure struct jffs2rawnoderef if nodes were 512bytes then that s 4mb of ram these are probably unacceptable for the product being used we therefore need to run something better than this two approaches spring to mind just run fat16 ie just treat all nand as smartmedia benefits one code base downside reliability i m reluctant to store critical files in a fat16 file system because these can be so unreliable i m convinced that a journaling file system is superior maybe what we need is a light weight journaling file system using common code with jffs modified in such a way as sidestep some of the nasty issues raised above  what i m working towards right now i m investigating the idea of trying to do something more appropriate my current avenue of exploration is to use a journaling approach as follows the journaling records are stored in fixedsize 512byte pages the journaling tags are stored in the 16byteperpage management space semiconsistent with smartmedia using the 8 bytes of reserved space and lba space to store journaling tags ie something like 20 bits of page id within inode 20 bits of inode id 9 bits length bytes used in this page 7 bits flags etc 8 bits of hamming code on this area each page id identifies where the page fits into the file when a page is replaced ie file data is overwritten a new page with the same page id is written and the old one is wiped out during garbage collection the pages containing valid data are copied and the wiped out data is discarded the benefits of this approach are nandfriendly since it works within the write limitations of nand less stuff to read to reconstruct file structures only read management data down sides no compression but is that an issue considering the target data is already compressed and nand is far less precious than nor thanks to higher densities and lower price still need to see if a new data structure is going to reduce the overhead of jffs2rawnoderef somewhat admin 23 may 2005 1250pm  