copy filesystem to nand flash without ecc

copy filesystem to nand flash without ecc

[Kschoo70C at netscape.net]

Hi,
     I notice some update on the JFFS2 out of band usage in
http://www.linux-mtd.infradead.org/tech/nand.html,
whereby the offset 0x4 used to be ECC valid marker has been made obsolete. In this case, if I write a jffs image to the mtd device without adding the ECC in the out of band area, the nand driver will not know about that. The question here is, what is the consequence of writing an image without adding the ecc to the out of band area ?
Isn't it true the jffs2 file system always uses read_ecc and write_ecc when the flash type is nand ?

Thanks in advance.

regards
choo


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

copy filesystem to nand flash without ecc

[Thomas Gleixner]

On Thursday 13 February 2003 12:16, Kschoo70C at netscape.net wrote:
> Hi,
>      I notice some update on the JFFS2 out of band usage in
> http://www.linux-mtd.infradead.org/tech/nand.html,
> whereby the offset 0x4 used to be ECC valid marker has been made obsolete.
> In this case, if I write a jffs image to the mtd device without adding the
> ECC in the out of band area, the nand driver will not know about that. The
> question here is, what is the consequence of writing an image without
> adding the ecc to the out of band area ? Isn't it true the jffs2 file
> system always uses read_ecc and write_ecc when the flash type is nand ?
True.
You will get a endless bunch of ECC failure warnings. They will go away,
if you copy files around. As ECC is essential for NAND, we removed the
non ECC stuff for JFFS2 :)

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

copy filesystem to nand flash without ecc

[David Woodhouse]

On Thu, 2003-02-13 at 16:52, Thomas Gleixner wrote:
> You will get a endless bunch of ECC failure warnings. They will go away,
> if you copy files around. As ECC is essential for NAND, we removed the
> non ECC stuff for JFFS2 :)

Weren't we talking about having an ioctl or something to select whether
writes from userspace had ECC done on them or not?


-- 
dwmw2

copy filesystem to nand flash without ecc

[Thomas Gleixner]

On Friday 14 February 2003 09:59, David Woodhouse wrote:
> On Thu, 2003-02-13 at 16:52, Thomas Gleixner wrote:
> > You will get a endless bunch of ECC failure warnings. They will go away,
> > if you copy files around. As ECC is essential for NAND, we removed the
> > non ECC stuff for JFFS2 :)
>
> Weren't we talking about having an ioctl or something to select whether
> writes from userspace had ECC done on them or not?

Yep, but nobody coded it until now :)

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

copy filesystem to nand flash without ecc

[Alex Samoutin]

> if you copy files around. As ECC is essential for NAND, we removed the
> non ECC stuff for JFFS2 :)
>


Hmm
But I can see call     mtd->write()  in  jffs2_flash_write() (wbuf.c).  It
is not ECC write.
This function invoked from jffs2_garbage_collect_pristine(). and   cause a
problem.

Alex.

copy filesystem to nand flash without ecc

[Thomas Gleixner]

On Friday 14 February 2003 18:10, Alex Samoutin wrote:
> But I can see call     mtd->write()  in  jffs2_flash_write() (wbuf.c).  It
> is not ECC write.
> This function invoked from jffs2_garbage_collect_pristine(). and   cause a
> problem.
Well spotted. Thanks.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

copy filesystem to nand flash without ecc

[David Woodhouse]

On Fri, 2003-02-14 at 22:37, Thomas Gleixner wrote:
> On Friday 14 February 2003 18:10, Alex Samoutin wrote:
> > But I can see call     mtd->write()  in  jffs2_flash_write() (wbuf.c).  It
> > is not ECC write.
> > This function invoked from jffs2_garbage_collect_pristine(). and   cause a
> > problem.
> Well spotted. Thanks.

Sorry. Mea Culpa. We really shouldn't have jffs2_flash_writev() writing
into the wbuf, which jffs2_flash_write() writes directly to the flash.
It'll confuse me into writing directly to the flash just because I have
only one iovec to write :)

-- 
dwmw2

copy filesystem to nand flash without ecc

[kokseng choo]

--------------030901020400030402000706
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



tglx at linutronix.de wrote:

>On Thursday 13 February 2003 12:16, Kschoo70C at netscape.net wrote:
>  
>
>>Hi,
>>     I notice some update on the JFFS2 out of band usage in
>>http://www.linux-mtd.infradead.org/tech/nand.html,
>>whereby the offset 0x4 used to be ECC valid marker has been made obsolete.
>>In this case, if I write a jffs image to the mtd device without adding the
>>ECC in the out of band area, the nand driver will not know about that. The
>>question here is, what is the consequence of writing an image without
>>adding the ecc to the out of band area ? Isn't it true the jffs2 file
>>system always uses read_ecc and write_ecc when the flash type is nand ?
>>    
>>
>True.
>You will get a endless bunch of ECC failure warnings. They will go away,
>if you copy files around. As ECC is essential for NAND, we removed the
>non ECC stuff for JFFS2 :)
>
>  
>
I look into the nand.c code, and I found that the difficulty of ecc handling 
is due to the fact that nand has to support both YAFFS and JFFS2,
while both of the filesystem use the different oob offset to store the ecc.
Meanwhile, if the ecc_mode is set and the oobsel=0, then this will cause 
ecc error. In another word, pwrite could not do the job as we expected.

I also notice that nand.h also define the ecc location for 
oobsel=NAND_NONE_OOB, which in fact exactly the same as that of JFFS2. 
Why don't we just add those definitions in  oobconfigs[0] instead of 
zeroing it? Since a nand driver without ECC is really a bad idea which 
makes nand_write thus pwrite becomes useless. Can we just have a default 
"oobsel" during compile time?; which means explicitly 
define oobconfigs[0] to either JFFS2 or YAFFS or zero through configuration. 
By doing that, the mtd user does not have to use different API or ioctl 
to write to the flash. The "cp" utils will just work.

As a mtd user at userspace, ideally I would like to use the same pwrite() 
function for the flash, and I wish I do not have to know what is the 
flash type I am talking to. All I need to know is I am talking to a 
mtd device, and I do not have to know anything about ECC, just let 
the driver handle is implicitly.

I attach a patch which add the default entry for oobconfig[0], I think 
it will help me a bit as a mtd and JFFS2 user at userspace.

Please comment if it does not make sense, thank you.


regards
choo


-- 
Your favorite stores, helpful shopping tools and great gift ideas. 
Experience the convenience of buying online with Shop at Netscape! 
http://shopnow.netscape.com/


--------------030901020400030402000706
Content-Type: text/plain;
 name="nand_c_patch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="nand_c_patch.txt"

--- nandOrg.c   Mon Feb 17 10:59:07 2003
+++ nandPatch.c Mon Feb 17 11:06:08 2003
@@ -136,6 +136,7 @@
 #include <linux/interrupt.h>
 #include <asm/io.h>
 
+
 /*
  * Macros for low-level register control
  */
@@ -147,7 +148,8 @@
  * out of band configuration for different filesystems
  */
 static int oobconfigs[][6] = {
-   { 0,0,0,0,0,0},
+    { NAND_NOOB_ECCPOS0, NAND_NOOB_ECCPOS1, NAND_NOOB_ECCPOS2,
+      NAND_NOOB_ECCPOS3, NAND_NOOB_ECCPOS4, NAND_NOOB_ECCPOS5},
 
    { NAND_JFFS2_OOB_ECCPOS0, NAND_JFFS2_OOB_ECCPOS1, NAND_JFFS2_OOB_ECCPOS2,
    NAND_JFFS2_OOB_ECCPOS3, NAND_JFFS2_OOB_ECCPOS4, NAND_JFFS2_OOB_ECCPOS5 },
@@ -361,7 +363,8 @@
 {
    int     i, status;
    u_char  ecc_code[6], *oob_data;
-   int eccmode = oobsel ? this->eccmode : NAND_ECC_NONE;
+   //int   eccmode = oobsel ? this->eccmode : NAND_ECC_NONE;
+   int eccmode = this->eccmode;
    int     *oob_config = oobconfigs[oobsel];
 

--------------030901020400030402000706--

copy filesystem to nand flash without ecc

[kokseng choo]

>On Monday 17 February 2003 13:36, kokseng choo wrote:
>  
>
>>I also notice that nand.h also define the ecc location for
>>oobsel=NAND_NONE_OOB, which in fact exactly the same as that of JFFS2.
>>Why don't we just add those definitions in  oobconfigs[0] instead of
>>zeroing it? Since a nand driver without ECC is really a bad idea which
>>makes nand_write thus pwrite becomes useless. Can we just have a default
>>"oobsel" during compile time?; which means explicitly
>>define oobconfigs[0] to either JFFS2 or YAFFS or zero through
>>configuration. By doing that, the mtd user does not have to use different
>>API or ioctl to write to the flash. The "cp" utils will just work.
>>    
>>
>Yep, but you still do not write fs-specific information in the OOB-area, 
>except the ecc.
>This still solves not the problem to write a fs-image to the chip. Therefor we
>need a function, which includes writing of OOB data and filesystem dependent 
>oob-layout selection.
>
Yes, but as far as JFFS2 is concerned, the oob_buf is alway null, when 
it calls write_ecc().
If we use MEMWRITE ioctl, I suppose I will pass in NULL also if I am not 
interested in debugging.

>
>  
>
>>As a mtd user at userspace, ideally I would like to use the same pwrite()
>>function for the flash, and I wish I do not have to know what is the
>>flash type I am talking to. All I need to know is I am talking to a
>>mtd device, and I do not have to know anything about ECC, just let
>>the driver handle is implicitly.
>>    
>>
>That's true if you use NAND without a filesystem.
>
I thought that is true also, for JFFS2, as I can see JFFS2 pass in null 
pointer when it calls write_ecc.

>
>  
>
>>I attach a patch which add the default entry for oobconfig[0], I think
>>it will help me a bit as a mtd and JFFS2 user at userspace.
>>Please comment if it does not make sense, thank you.
>>    
>>
>I'm not happy with that, as you force it to JFFS2 layout and therefor YAFFS 
>users _CANNOT_ use it. I will think about a more flexible solution.
>
>  
>
Yes, but I mentioned before, I prefer to use compile time configuration 
to assign the oobconfig[0].
The current patch make use of what you have defined in nand.h which will 
not break anything.
I try to be neutral, othere wise I will use JFFS2 offset in the 
oobconfig[0] instead of  NONE_OOB setting.
If the YAFFS is not going to use OOB, having the ecc in the OOB area 
will not affect them, the
same apply to JFFS2 user if the eccmode is off.

regards
choo

-- 
Your favorite stores, helpful shopping tools and great gift ideas. 
Experience the convenience of buying online with Shop at Netscape! 
http://shopnow.netscape.com/

copy filesystem to nand flash without ecc

[Thomas Gleixner]

On Monday 17 February 2003 13:36, kokseng choo wrote:
> I also notice that nand.h also define the ecc location for
> oobsel=NAND_NONE_OOB, which in fact exactly the same as that of JFFS2.
> Why don't we just add those definitions in  oobconfigs[0] instead of
> zeroing it? Since a nand driver without ECC is really a bad idea which
> makes nand_write thus pwrite becomes useless. Can we just have a default
> "oobsel" during compile time?; which means explicitly
> define oobconfigs[0] to either JFFS2 or YAFFS or zero through
> configuration. By doing that, the mtd user does not have to use different
> API or ioctl to write to the flash. The "cp" utils will just work.
Yep, but you still do not write fs-specific information in the OOB-area, 
except the ecc.
This still solves not the problem to write a fs-image to the chip. Therefor we
need a function, which includes writing of OOB data and filesystem dependent 
oob-layout selection.

> As a mtd user at userspace, ideally I would like to use the same pwrite()
> function for the flash, and I wish I do not have to know what is the
> flash type I am talking to. All I need to know is I am talking to a
> mtd device, and I do not have to know anything about ECC, just let
> the driver handle is implicitly.
That's true if you use NAND without a filesystem.

> I attach a patch which add the default entry for oobconfig[0], I think
> it will help me a bit as a mtd and JFFS2 user at userspace.
> Please comment if it does not make sense, thank you.
I'm not happy with that, as you force it to JFFS2 layout and therefor YAFFS 
users _CANNOT_ use it. I will think about a more flexible solution.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

copy filesystem to nand flash without ecc

[kokseng choo]

tglx at linutronix.de wrote:

>On Monday 17 February 2003 13:36, kokseng choo wrote:
>  
>
>Yep, but you still do not write fs-specific information in the OOB-area, 
>except the ecc.
>This still solves not the problem to write a fs-image to the chip. Therefor we
>need a function, which includes writing of OOB data and filesystem dependent 
>oob-layout selection.
>
Am I right to say that, I only have to put the fix pattern value -- 
which is cleanMarker in the case of JFFS2
in the OOB?  If this assumption is true, then I was thinking about let 
the erase do the job. Because,
 we can modify erase function such that we can have "erase --jffs2-oob" 
or "erase --yaffs-oob".
On the other hand, we probably can not change cp function to have "cp 
--jffs".

regards
choo

copy filesystem to nand flash without ecc

[Charles Manning]

On Tue, 18 Feb 2003 05:02, kokseng choo wrote:
> tglx at linutronix.de wrote:
> >On Monday 17 February 2003 13:36, kokseng choo wrote:
> >
> >
> >Yep, but you still do not write fs-specific information in the OOB-area,
> >except the ecc.
> >This still solves not the problem to write a fs-image to the chip.

For YAFFS you should use

mkyaffs dev_name image_name

This formats and writes the image in one step. I do not suggest you use cp or 
erase.

-- CHarles