mtd, mtdblock and nand ecc.

[David Daney]

Thomas Gleixner wrote:

>Why did you modify nand.c ? 
>Almost everything in nand.c can be overridden by the board driver. Therefor we 
>call all the functions through chip->xxx().
>  
>
We need almost everything in nand.c, but the physical access to the NAND 
is through a hardware state machine that hides the raw chip registers 
that nand.c uses.  So we made a copy of nand.c and hacked it to work.

>>When ever jffs2 or yaffs are mounted, they both seem to read many
>>pages.  Perhaps the ECC overhead of reading all that data.
>>I suppose I could turn off ECC and see how fast it is...
>>    
>>
>
>Sure, that would give an estimation.
>
>  
>
>>>>That is why I am thinking about using a non NAND aware file system for
>>>>things that can be read-only.
>>>>        
>>>>
>>>But this does not answer my question how you want to deal with bad blocks
>>>?
>>>      
>>>
>>I want a file system very much like cramfs, but that can have holes in
>>it so that it works on NAND.
>>When mounted it would start scanning blocks starting from the beginning
>>of the NAND partition until it found a valid superblock (or what ever
>>you would call it).  Then it would be done because all of the indexes
>>would be built to work around the bad blocks.  Since this filesystem
>>would be read-only with a static structure, you would never have to read
>>more than necessary.
>>    
>>
>
>OK, so you are going to write a fs driver, which is NAND aware and behaves 
>similar to cramfs. 
>
I MAY do it, but would rather that someone else did all the hard work :)

>Whatfor then the discussion about making mtdblock nand aware ?
>If you write a nand aware fs then you just call the appropriate functions. 
>This fs will be specific for nand or selectable for nand, so what ?
>No need to touch anything in mtdblock.c
>  
>
I guess I am abandoning that for now...

David Daney.