Re: mtd, mtdblock and nand ecc.

[David Daney <ddaney@avtrex.com>]

Let me start by saying that I am not trying to cause problems, but just 
to understand the best options...

Thomas Gleixner wrote:

>On Wednesday 14 April 2004 16:11, David Daney wrote:
>
>  
>
>>>NAND aware filesystem drivers provide their own oobsel structure and use
>>>the xxx_ecc functions.
>>>      
>>>
>>I am using the cramfs on a NAND partition as my root file system.
>>cramfs is not NAND aware, and I cannot be running userspace programs
>>before mounting as it is the root file system.
>>    
>>
>
>I know, but why must you use cramfs ? Why dont you use jffs2 or yaffs as your 
>root fs. Mount it r/o, so you have no hassle at all.
>  
>
With my NAND drivers, booting the linux kernel and mounting a minimal 
root file system on a 16MB flash takes 1:08 for yaffs and 1:25 for 
jffs2.  Using cramfs it boots in under 0:10.

That is why I am thinking about using a non NAND aware file system for 
things that can be read-only.

>  
>
>>I have not completely educated myself on the mtdblock driver.  Since the
>>mtdblock driver can be used by non-mtd-aware filesystems, I am proposing
>>making mtdblock NAND aware so that it uses the xxx_ecc functions iff ECC
>>is available.  Perhaps there would be a kernel/module command line
>>switch to help manage the behavior.
>>
>>Thoughts?
>>    
>>
>
>mtdblock is a block device driver and only provides an interface. It must not 
>be aware of anything. 
>
That is not quite correct.  mtdblock is well aware of the mtd backend.  
It does this:
    ret = MTD_WRITE (mtd, pos, len, &retlen, buf);

All I am suggesting is to have it do MTD_WRITE_ECC when possible.

>Using NAND unaware filesystems on NAND is nothing we want to support.
>ECC is only one part of NAND support. What about bad blocks? NAND chips can 
>have bad blocks, even when they are new. Only block 0 is guaranteed to be not 
>bad at delivery time. How want you deal with a board, where a bad block is in 
>the partition which is reserved for your cramfs ?
>

>We have two reliable working NAND aware filesystems around. I don't see any 
>reason to provide support for predictable trouble. 
>
>  
>
You already support it.  /dev/mtd and /dev/mtdblock work off-the-shelf 
with NAND devices and allow arbitrary programs/filesystems to overwrite 
bad blocks if they choose.

All I was thinking about was the ECC issue.

David Daney.