Bad assumption about ID field definition for Samsung NAND?
Tilman Sauerbeck
tilman at code-monkey.de
Thu Aug 19 13:16:11 EDT 2010
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?
More information about the linux-mtd
mailing list