Re: ECC byte 4 and 5 not equal to what have just been writen

Re: ECC byte 4 and 5 not equal to what have just been writen

[Thomas Gleixner]

On Tuesday 20 April 2004 11:40, Shen Aaron-r62966 wrote:
> >
> > Which kernel version ?
> > Which MTD version are you using ?
> > Is this a userspace application ?
> > Which oob layout is selected ?
>
> Actually, I'm adding ECC part into the spl code for NAND flash bootloader.
> Most of the algorithm and the interfaces to calculate ecc code and to
> read/write a page is copied from driver/mtd/nand/. The version of linux
> kernel is 2.4.18. The oob layout is 16 byte size.

So you are debugging your bootloader code and not kernel code ?
Did you copy the code from 2.4.18 ? If yes, use code from actual MTD CVS.
If no, which version of MTD code did you use to copy from ?

> >
> > Where is the ECC correction done ?
>
> ECC correction should be done after reading each page. But here I
> only need to read out the OOB data of a page after writing to it.
> The obvious problem is that ecc data is writen into spare[0~3] and
> spare[6~7], but only spare[0~5] is what we expected when read out.
> The spare[6~7] has changed and some unexpected data is writen
> into spare[8~A]. I still can't find out the reason. Any more suggestion?

The page write function is the right place to look

-- 
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: ECC byte 4 and 5 not equal to what have just been writen

[Thomas Gleixner]

On Tuesday 20 April 2004 12:37, Shen Aaron-r62966 wrote:
> > -----Original Message-----
> > On Tuesday 20 April 2004 11:40, Shen Aaron-r62966 wrote:
> > So you are debugging your bootloader code and not kernel code ?
> > Did you copy the code from 2.4.18 ? If yes, use code from
> > actual MTD CVS.
> > If no, which version of MTD code did you use to copy from ?
>
> Yes, right. I'm debugging my bootloader code. I'm using the 2.4.18 kernel,
> so I didn't use the code from actual MTD CVS. There're many differences for
> the actual CVS, for example, the nand_ecc.h and other head files are added
> into linux/mtd/. I don't think it's a good choice to use the mtd code from
> actual CVS if it's not a known problem. And I'm not sure whether such
> update will do harm to my system. I think the code in 2.4.18 should work
> for it. But I need to find out what's the problem.

Hmm, known problem is a nice phrase. The code in 2.4.18 was not used in 
production AFAIK. 

All you need is pageprogramming which is quite straight forward:
Write the start programm command
Write out 512 byte data + 16 byte oob
Write the programm command 
Wait for ready

> > The page write function is the right place to look
>
> Yes, The only step before I re-read the oob data is the page write
> function. But I have added more debugging information into this function
> and still can't find the causing. Is it possible that the Nand Flash
> Controller does some operation after a page has been writen?

Is this the builtin controller on iMX2 ?
I dont know, what this does, as I have no datasheet. The product brief tells 
something about automatic ECC...
Maybe you have to check this first

-- 
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

ECC byte 4 and 5 not equal to what have just been writen

[Shen Aaron-r62966]

Hi,

  Is there anyone aware of such problem about ECC?
  When I read back the OOB data after writing to a page, I find the offset 06 and 07 are not equal to what have just been writen into the page.

  The part of codes are :
==========================================
  ......
  // char spare[16] is for oob data in spare area
  mx2_write_ecc((char*)p, spare, last);		// My function to set the spare[16] before write a page
  printOut("The spare[ ] to write in flash is :\n");	// Messege printed out
  printOut(spare);					// Print out the spare[ ]
  if(NAND_Write_OnePage(page, (char*)p, spare))	// Write the page with spare[ ] into NAND flash
	return;
  NAND_Read_OOB(0, page, spare, 16);		// Read back the oob data into spare[ ]
  printOut("The spare[ ] to read back from flash is :\n");
  printOut(spare);					// Print out the spare[ ]
  ......
===========================================

  While, I got the follow output:
===========================================
......
The spare[ ] to write in flash is :
spare[00] = 56
spare[01] = 5A
spare[02] = 6B
spare[03] = 66
spare[04] = 00
spare[05] = FF
spare[06] = A6
spare[07] = 9B
spare[08] = FF
spare[09] = FF
spare[0A] = FF
spare[0B] = FF
spare[0C] = FF
spare[0D] = FF
spare[0E] = FF
spare[0F] = FF
The spare[ ] to read back from flash is :
spare[00] = 56
spare[01] = 5A
spare[02] = 6B
spare[03] = 66
spare[04] = 00
spare[05] = FF
spare[06] = C0
spare[07] = 33
spare[08] = C3
spare[09] = A9
spare[0A] = 02
spare[0B] = FF
spare[0C] = FF
spare[0D] = FF
spare[0E] = FF
spare[0F] = FF
......
===========================================

  As you may have found out, the spare[0]~spare[5] are the same as writen. But spare[6] and spare[7] are different, while spare[8], spare[9] and spare[A] are so strange.

  This will cause the failure of ecc correction for the upper 256 bytes of data in each page. Can you give me some comments?

  Is this a known problem of NAND_Read_OOB( )?

Thanks.
Aaron

Re: ECC byte 4 and 5 not equal to what have just been writen

[Charles Manning]

A lot of what happens here will depend on what ECC options you have enabled. 
Likely the mtd is applying ECC and stomping on what you have written.

Also note that NAND flash writes result in the AND of the previous data 
pattern and the newly written pattern. You might like to do a read before the 
write to check that everything is FF first.

-- CHarles

On Tuesday 20 April 2004 19:35, Shen Aaron-r62966 wrote:
> Hi,
>
>   Is there anyone aware of such problem about ECC?
>   When I read back the OOB data after writing to a page, I find the offset
> 06 and 07 are not equal to what have just been writen into the page.
>
>   The part of codes are :
> ==========================================
>   ......
>   // char spare[16] is for oob data in spare area
>   mx2_write_ecc((char*)p, spare, last);		// My function to set the
> spare[16] before write a page printOut("The spare[ ] to write in flash is
> :\n");	// Messege printed out printOut(spare);					// Print out the spare[
> ]
>   if(NAND_Write_OnePage(page, (char*)p, spare))	// Write the page with
> spare[ ] into NAND flash return;
>   NAND_Read_OOB(0, page, spare, 16);		// Read back the oob data into spare[
> ] printOut("The spare[ ] to read back from flash is :\n");
>   printOut(spare);					// Print out the spare[ ]
>   ......
> ===========================================
>
>   While, I got the follow output:
> ===========================================
> ......
> The spare[ ] to write in flash is :
> spare[00] = 56
> spare[01] = 5A
> spare[02] = 6B
> spare[03] = 66
> spare[04] = 00
> spare[05] = FF
> spare[06] = A6
> spare[07] = 9B
> spare[08] = FF
> spare[09] = FF
> spare[0A] = FF
> spare[0B] = FF
> spare[0C] = FF
> spare[0D] = FF
> spare[0E] = FF
> spare[0F] = FF
> The spare[ ] to read back from flash is :
> spare[00] = 56
> spare[01] = 5A
> spare[02] = 6B
> spare[03] = 66
> spare[04] = 00
> spare[05] = FF
> spare[06] = C0
> spare[07] = 33
> spare[08] = C3
> spare[09] = A9
> spare[0A] = 02
> spare[0B] = FF
> spare[0C] = FF
> spare[0D] = FF
> spare[0E] = FF
> spare[0F] = FF
> ......
> ===========================================
>
>   As you may have found out, the spare[0]~spare[5] are the same as writen.
> But spare[6] and spare[7] are different, while spare[8], spare[9] and
> spare[A] are so strange.
>
>   This will cause the failure of ecc correction for the upper 256 bytes of
> data in each page. Can you give me some comments?
>
>   Is this a known problem of NAND_Read_OOB( )?
>
> Thanks.
> Aaron
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: ECC byte 4 and 5 not equal to what have just been writen

[Thomas Gleixner]

On Tuesday 20 April 2004 09:35, Shen Aaron-r62966 wrote:
> Hi,
>
>   Is there anyone aware of such problem about ECC?
>   When I read back the OOB data after writing to a page, I find the offset
> 06 and 07 are not equal to what have just been writen into the page.
>
>   The part of codes are :
> ==========================================
>   ......
>   // char spare[16] is for oob data in spare area
>   mx2_write_ecc((char*)p, spare, last);		// My function to set the
> spare[16] before write a page printOut("The spare[ ] to write in flash is
> :\n");	// Messege printed out printOut(spare);					// Print out the spare[
> ]
>   if(NAND_Write_OnePage(page, (char*)p, spare))	// Write the page with
> spare[ ] into NAND flash return;
>   NAND_Read_OOB(0, page, spare, 16);		// Read back the oob data into spare[
> ] printOut("The spare[ ] to read back from flash is :\n");
>   printOut(spare);					// Print out the spare[ ]
>   ......

Which kernel version ?
Which MTD version are you using ?
Is this a userspace application ?
Which oob layout is selected ?

>   As you may have found out, the spare[0]~spare[5] are the same as writen.
> But spare[6] and spare[7] are different, while spare[8], spare[9] and
> spare[A] are so strange.
>
>   This will cause the failure of ecc correction for the upper 256 bytes of
> data in each page. Can you give me some comments?

Where is the ECC correction done ? 

>  Is this a known problem of NAND_Read_OOB( )?

No

-- 
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de