From: rabin@rab.in (Rabin Vincent)
To: linux-arm-kernel@lists.infradead.org
Subject: Problem with mxc_nand driver
Date: Wed, 30 Sep 2009 15:37:44 +0530 [thread overview]
Message-ID: <20090930100727.GA2365@debian> (raw)
In-Reply-To: <a57e67db0909280241w61f8d8bbm88ff5d749cc946c2@mail.gmail.com>
On Mon, Sep 28, 2009 at 11:41:39AM +0200, Jernej Turnsek wrote:
> after writing root fs image into nand partition, running the image and
> then checking the first empty block I've got following OOB data which
> is suspicious to me:
>
> OOB:
> ff ff 85 19 03 20 ff ff
> ff 65 02 08 00 00 00 ff
> ff ff ff ff ff ff ff ff
> ff ff 03 ff ff ff ff ff
> ff ff ff ff ff ff ff ff
> ff ff 03 ff ff ff ff ff
> ff ff ff ff ff ff ff ff
> ff ff 03 ff ff ff ff ff
>
> One can see that bytes on offset 2 to 5 are not empty and when using
> the smallpage_memorybased badblock_pattern byte 6 is not FF like it
> should be.
>
> Anyone knows what is going on here?
85 19 03 20 08 00 00 00 is the JFFS2 cleanmarker; it's written to
indicate that the block is empty. This is being stored in the OOB area
in the positions specified by oobfree in your ecclayout.
Your ecclayout has this:
static struct nand_ecclayout nand_hw_eccoob_64 = {
.eccbytes = 20,
.eccpos = {6, 7, 8, 9, 10, 22, 23, 24, 25, 26,
38, 39, 40, 41, 42, 54, 55, 56, 57, 58},
.oobfree = {{2, 4}, {11, 10}, {27, 10}, {43, 10}, {59, 5}, }
};
The {2, 4} element in oobfree says that 4 bytes from position 2 (i.e,
positions 2, 3, 4, 5) are free to be used to store any OOB data.
If bad block information is supposed to be in position 5, that position
should not be included in oobfree.
Rabin
prev parent reply other threads:[~2009-09-30 10:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 6:41 Problem with mxc_nand driver Jernej Turnsek
2009-09-28 7:39 ` Eric Bénard
2009-09-28 8:56 ` Jernej Turnsek
2009-09-28 9:20 ` Eric Bénard
2009-09-28 9:41 ` Jernej Turnsek
2009-09-28 9:43 ` Eric Bénard
2009-09-28 10:30 ` Jernej Turnsek
2009-09-30 10:07 ` Rabin Vincent [this message]
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=20090930100727.GA2365@debian \
--to=rabin@rab.in \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).