From: Tilman Sauerbeck <tilman@code-monkey.de>
To: Brian Norris <norris@broadcom.com>
Cc: Kevin Cernekee <cernekee@gmail.com>, linux-mtd@lists.infradead.org
Subject: Re: Bad assumption about ID field definition for Samsung NAND?
Date: Thu, 19 Aug 2010 19:16:11 +0200 [thread overview]
Message-ID: <20100819171558.GA8536@code-monkey.de> (raw)
In-Reply-To: <4C6C6BFC.9020408@broadcom.com>
Brian Norris [2010-08-18 16:25]:
Hi,
> I have similar problems on similar chips, however, I cannot
> determine that for sure; can you print out the full ID string (8
> bytes) from nand_base?
ID: ec dc 10 95 54 ec ec dc
> This may be an issue with an unfortunate wraparound of the ID where
> it *should* give a 5-byte string, then wraparound to give the same
> ID again, but instead it gives a 6-byte string, then wraps around
> again. This would incorrectly classify this ID string under the
I think I might have found the real problem.
Kevin's commit message says:
> This patch uses the new 6-byte scheme if the following conditions are
> all true:
> [...]
> 3) 6th byte is zero
... but what the code does is use new scheme if id_data[5] is _not_
zero.
The following diff works for me, but I cannot test with any other flash
chip but the K9F4G08U0B:
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 4a7b864..abc71cd 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2847,12 +2847,12 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
* Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32)
* New style (6 byte ID): Samsung K9GAG08U0D (p.40)
*
- * Check for wraparound + Samsung ID + nonzero 6th byte
+ * Check for wraparound + Samsung ID + zero 6th byte
* to decide what to do.
*/
if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
id_data[0] == NAND_MFR_SAMSUNG &&
- id_data[5] != 0x00) {
+ id_data[5] == 0x00) {
/* Calc pagesize */
mtd->writesize = 2048 << (extid & 0x03);
extid >>= 2;
Thanks,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
next prev parent reply other threads:[~2010-08-19 17:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 18:05 Bad assumption about ID field definition for Samsung NAND? Tilman Sauerbeck
2010-08-18 23:25 ` Brian Norris
2010-08-19 17:16 ` Tilman Sauerbeck [this message]
2010-08-19 19:46 ` Kevin Cernekee
2010-08-19 22:28 ` Brian Norris
2010-08-20 3:29 ` Kevin Cernekee
2010-08-20 5:38 ` Liu Hui-R64343
2010-08-20 13:43 ` Tilman Sauerbeck
2010-08-20 17:42 ` Brian Norris
2010-08-20 19:53 ` David Woodhouse
2010-08-20 20:51 ` Tilman Sauerbeck
2010-08-20 21:01 ` Brian Norris
2010-08-20 21:34 ` David Woodhouse
2010-08-20 22:05 ` Brian Norris
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=20100819171558.GA8536@code-monkey.de \
--to=tilman@code-monkey.de \
--cc=cernekee@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=norris@broadcom.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.