From: Jarkko Lavinen <jarkko.lavinen@nokia.com>
To: Kyungmin Park <kyungmin.park@samsung.com>
Cc: linux-mtd@lists.infradead.org
Subject: Erase verify problem with OneNAND
Date: Tue, 24 Jan 2006 14:47:10 +0200 [thread overview]
Message-ID: <20060124124710.GA29129@angel.research.nokia.com> (raw)
Hi Kyungmin
I have a strange erase verify read problem with OneNand. It occurs
strangely when crossing the 128MB border, first erasing (and
presumably verifying) a block on other side and then erasing another
block on the other side. Then verify reads garbage.
I am using CVS head for the drivers/mtd but the JFFS2 part is from the
2.6.15 kernel, before Erase Block Headers were committed. Onenand_base.c
is rev 1.15. The test board has muxed 256MB OneNand.
I see JFFS2 repeatably complaining "Newly-erased block contained
word...". This comes from fs/jffs2/erase.c:jffs2_block_check_erase()
which reads the erased block and checks all the bits are 1.
I see this occuring when I flash JFFS2 root image and boot it. Our
bootloader leaves unused erase blocks empty, without cleanmarker.
When JFFS2 sees an empty block, it has to erase it again since there
is no cleanmarker. After erasing, it reads the first page to see it
really is empty.
For some reason the first verify read at physical offset 0x7fe0000
(JFFS2 report offset 0x07b60000 relative to the partition offset
0x480000) fails but retry succeeds -- which means the block was
correctly erased but the first verify reads some garbage.
This is tricky to debug, since the problem disappears if I increase
MTD debug level. On the other hand the verify problem seems to appear
always after after flashing and booting the board.
I have modified jffs2_block_check_erase() to retry the verify read
if garbage is seen at the erased page. I am using MTD debug level
0 and changed onenand_erase to report at that level to see when it
is being called.
The repeatably occuring one:
...
onenand_erase: start = 0x08040000, len = 131072
onenand_erase: start = 0x08020000, len = 131072
onenand_erase: start = 0x08000000, len = 131072
onenand_erase: start = 0x07fe0000, len = 131072
Newly-erased block contained word 0x45e0f628 at offset 0x07b60000
Read OK after 1 retries
onenand_erase: start = 0x07fc0000, len = 131072
onenand_erase: start = 0x07fa0000, len = 131072
onenand_erase: start = 0x07f80000, len = 131072
...
Another exmaple, less frequent:
onenand_erase: start = 0x04ce0000, len = 131072
onenand_erase: start = 0x04cc0000, len = 131072
onenand_erase: start = 0x04ca0000, len = 131072
onenand_erase: start = 0x0ffe0000, len = 131072
Newly-erased block contained word 0x7ea4c at offset 0x0fb60000
Read OK after 1 retries
Jarkko Lavinen
next reply other threads:[~2006-01-24 12:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-24 12:47 Jarkko Lavinen [this message]
2006-01-25 7:32 ` Erase verify problem with OneNAND Kyungmin Park
2006-01-25 12:06 ` Jarkko Lavinen
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=20060124124710.GA29129@angel.research.nokia.com \
--to=jarkko.lavinen@nokia.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-mtd@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