public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vitaly Wool <vwool@ru.mvista.com>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: NAND/ HW ECC problem
Date: Tue, 20 Sep 2005 13:19:29 +0400	[thread overview]
Message-ID: <432FD421.2090508@ru.mvista.com> (raw)
In-Reply-To: <1127162439.24044.235.camel@tglx.tec.linutronix.de>

Thomas Gleixner wrote:

>>The serious problem we came across also was that nand_write_page doesn't 
>>follow the free bytes reference for OOB to write ECC data what was 
>>obviously wrong. As far as I understand, the DoC flashes have specific 
>>mechanism for handling that, so he legacy variant was left for the DoC, 
>>dunno whether it's right.
>>    
>>
>
>Err, the oobfree reference is the place where file systems can put their
>data in. The ECC is put into the byte positions given by eccpos.
>
>http://www.linux-mtd.infradead.org/tech/mtdnand/x215.html
>
>eccpos
>
>The eccpos array holds the byte offsets in the spare area where the ecc
>codes are placed. 
>
>  * oobfree
>
>The oobfree array defines the areas in the spare area which can be used
>for automatic placement. The information is given in the format {offset,
>size}. offset defines the start of the usable area, size the length in
>bytes. More than one area can be defined. The list is terminated by an
>{0, 0} entry. 
>
>
>I never bothered to implement the support for HW_ECC with a scattered
>byte layout as I never seen a controller doing such nonsense. All I have
>seen do
>
>data - ecc - fsoobdata (512byte/page)
>data - ecc -data - ecc -data - ecc -data - ecc - fsoobdata (2k/page)
>
>as this is the most efficient way to handle it.
>
>If your chip does it different, please use the correct parts of the data
>structure to implement it. 
>
Well, after having a fresh look at it I lost the feeling that I was 
doing something wrong.

Let's look at the patch again:

<snip>

 	/* Write out OOB data */
-	if (this->options & NAND_HWECC_SYNDROME)
-		this->write_buf(mtd, &oob_buf[oobsel->eccbytes], mtd->oobsize - oobsel->eccbytes);
-	else 
+	if (this->options & NAND_HWECC_SYNDROME) 
+		if (mtd->ecctype != MTD_ECC_RS_DiskOnChip ) 
+			for (i = 0; oobsel->oobfree[i][1]; i++ ) 
+		    		this->write_buf (mtd, 
+						 oob_buf+oobsel->oobfree[i][0],
+			    			 oobsel->oobfree[i][1] );
+		else /* DiskOnChip legacy ECC */
+			this->write_buf(mtd, &oob_buf[oobsel->eccbytes], mtd->oobsize - oobsel->eccbytes);
+	else  
 		this->write_buf(mtd, oob_buf, mtd->oobsize);
 

<snip>

So, the subject of change is exactly the areas in the spare area which 
can be used for automatic placement (fsoobdata), i. e. oobfree. In my 
case, oobfree is not at oob+buf + oobsel->eccbytes but spread across the 
block in a way

data - ecc - fsoobdata - data - ecc - fsoobdata - data - ecc - fsoobdata - data - ecc - fsoobdata


Therefore the assumption that fsoobdata is at the end of the block 
doesn't work, and that's what this part of the patch is about.
Please correct me if I'm wrong,

Thanks,
   Vitaly

  parent reply	other threads:[~2005-09-20  9:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-19 13:40 NAND/ HW ECC problem Vitaly Wool
2005-09-19 20:40 ` Thomas Gleixner
2005-09-19 21:40   ` Vitaly Wool
2005-09-19 21:43     ` Thomas Gleixner
2005-09-20  9:19   ` Vitaly Wool [this message]
2005-09-20 10:04     ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=432FD421.2090508@ru.mvista.com \
    --to=vwool@ru.mvista.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox