From: "Matthew L. Creech" <mlcreech@gmail.com>
To: linuxppc-dev@lists.ozlabs.org
Subject: NAND BBT corruption on MPC83xx
Date: Fri, 17 Jun 2011 16:54:27 -0400 [thread overview]
Message-ID: <BANLkTikyKObukzVw+c10HyDz+Q=PH4jozA@mail.gmail.com> (raw)
Hi, I posted this on the Linux-MTD list but haven't gotten any hits.
Since it looks like it could be MPC83xx-specific, I'm reposting here.
Rick Johnson noted a problem in fsl_elbc_nand.c back in May which
might be related:
http://lists.infradead.org/pipermail/linux-mtd/2011-May/035372.html
We've gotten some devices back from the field which all suffer from
this same problem on bootup when attaching UBI (these messages are
from U-Boot):
...
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
nand_bbt: ECC error while reading bad block table
...(long stream of bogus bad blocks)...
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI error: vtbl_check: volume table check failed: record 0, error 9
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
UBI init error -22
Full console dumps from 2 devices are here:
http://mcreech.com/work/bbt-ecc-error.txt
http://mcreech.com/work/bbt-ecc-error2.txt
Another device encountered a slightly different error, but which I
assume is due to the same underlying problem:
UBI error: init_volumes: not enough PEBs, required 8061, available 8059
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (-2, need 1)
A full dump from that one is here:
http://mcreech.com/work/bbt-ecc-error3.txt
Are there any known issues that could cause the BBT to
become corrupt like this?
I noticed that the reported bad blocks were all aligned at multiples
of 0x80000 (with one exception). Dump #1 shows:
- one BBT with lots of bytes that have their lower 1 or 2 bits
un-set (e.g. 0xfe instead of 0xff): this explains all the
each-4th-block alignment.
- the other BBT shows only one factory-marked bad block at
0x062e0000, which is presumably correct. This is preserved in the
bogus BBT, and is the only non-0x80000-aligned bad block in the table.
- Only the first 1024 bytes of the BBT contain bogus info - the
latter half of the BBT is all correct
It seems like the original BBT somehow had 0-2 bits corrupted at the
low end of each of its bytes, either while in memory or when the BBT
was written to NAND. Any ideas on what I can do to isolate the
problem? Thanks in advance!
More info on this board:
- MPC 8313 SoC
- 1GB Samsung NAND flash (K9K8G08U0B)
- Linux 2.6.31
- U-Boot 2009.06
--
Matthew L. Creech
next reply other threads:[~2011-06-17 20:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-17 20:54 Matthew L. Creech [this message]
2011-06-17 21:34 ` NAND BBT corruption on MPC83xx Scott Wood
2011-06-18 17:55 ` Mike Hench
2011-06-20 11:22 ` Atlant Schmidt
2011-06-23 8:31 ` Artem Bityutskiy
2011-06-20 15:20 ` Matthew L. Creech
2011-07-05 19:58 ` Matthew L. Creech
2011-07-05 19:59 ` [PATCH] mtd: eLBC NAND: remove bogus ECC read-back Matthew L. Creech
2011-07-05 20:15 ` Scott Wood
2011-07-05 22:35 ` [PATCH v2] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi Matthew L. Creech
2011-07-05 23:01 ` Scott Wood
2011-07-05 23:14 ` Matthew L. Creech
2011-07-05 23:14 ` [PATCH v3] " Matthew L. Creech
2011-07-06 7:23 ` Artem Bityutskiy
2011-07-11 15:30 ` NAND BBT corruption on MPC83xx Matthew L. Creech
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='BANLkTikyKObukzVw+c10HyDz+Q=PH4jozA@mail.gmail.com' \
--to=mlcreech@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.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).