[PATCH] mtd/nand: Support Micron chips, 4KB page
Brian Norris
norris at broadcom.com
Mon Jul 26 16:04:13 EDT 2010
The following parts exhibit some interesting patterns in their ID strings.
Their ID strings are not fully compatible with the current nand_base.c
detection algorithm. In order to detect them properly, I have taken the
liberty to develop a heuristic algorithm. None of these chips have a *good*
detection pattern listed in their datasheets, although MT29F16G08MAA has a
table on p.24 of its data sheet (not included here).
Part ID String Block Page OOB
MT29F16G08ABABA 2C 48 00 26 89 00 00 512K 4K 224
MT29F16G08CBABA 2C 48 04 46 85 00 00 1024K 4K 224
MT29F16G08MAA 2C D5 94 3E 74 00 00 512K 4K 218
I have attached a table logging most of the relevant data for the many chips
I have researched. The three chips are highlighted red, although there are
variants of the chips listed as well. I believe this patch should correctly
identify all the 5-byte ID Micron chips.
And before the question is asked: I realize that these chips support ONFI,
so that should be the primary means by which to identify them, but I would
still like to be able to detect these properly without ONFI if necessary,
especially considering some of the older NAND controllers we still use do not
support reading ONFI data.
Feedback on my logic is appreciated.
Signed-off-by: Brian Norris <norris at broadcom.com>
---
drivers/mtd/nand/nand_base.c | 34 +++++++++++++++++++++++++---------
drivers/mtd/nand/nand_ids.c | 1 +
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 4a7b864..1ca230d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2846,6 +2846,9 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
* Field definitions are in the following datasheets:
* Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32)
* New style (6 byte ID): Samsung K9GAG08U0D (p.40)
+ * Micron (5 byte ID): Micron MT29F16G08MAA (p.24)
+ * Note: Micron rule is based on heuristics for
+ * newer chips
*
* Check for wraparound + Samsung ID + nonzero 6th byte
* to decide what to do.
@@ -2867,15 +2870,28 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
/* Calc pagesize */
mtd->writesize = 1024 << (extid & 0x03);
extid >>= 2;
- /* Calc oobsize */
- mtd->oobsize = (8 << (extid & 0x01)) *
- (mtd->writesize >> 9);
- extid >>= 2;
- /* Calc blocksize. Blocksize is multiples of 64KiB */
- mtd->erasesize = (64 * 1024) << (extid & 0x03);
- extid >>= 2;
- /* Get buswidth information */
- busw = (extid & 0x01) ? NAND_BUSWIDTH_16 : 0;
+ /* Check for 5 byte ID + Micron + read more 0x00 */
+ if (id_data[0] == NAND_MFR_MICRON && id_data[4] != 0x00
+ && mtd->writesize >= 4096
+ && id_data[5] == 0x00
+ && id_data[6] == 0x00) {
+ mtd->oobsize = ((extid & 0x03) == 0x03) ? 218
+ : 224;
+ extid >>= 3;
+ mtd->erasesize = (256 * 1024) << (extid & 0x03);
+ /* All Micron have busw x8? */
+ busw = 0;
+ } else {
+ /* Calc oobsize */
+ mtd->oobsize = (8 << (extid & 0x01)) *
+ (mtd->writesize >> 9);
+ extid >>= 2;
+ /* Calc blocksize (multiples of 64KiB) */
+ mtd->erasesize = (64 * 1024) << (extid & 0x03);
+ extid >>= 2;
+ /* Get buswidth information */
+ busw = (extid & 0x01) ? NAND_BUSWIDTH_16 : 0;
+ }
}
} else {
/*
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 89907ed..25f6be2 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -107,6 +107,7 @@ struct nand_flash_dev nand_flash_ids[] = {
/* 16 Gigabit */
{"NAND 2GiB 1,8V 8-bit", 0xA5, 0, 2048, 0, LP_OPTIONS},
{"NAND 2GiB 3,3V 8-bit", 0xD5, 0, 2048, 0, LP_OPTIONS},
+ {"NAND 2GiB 3,3V 8-bit", 0x48, 0, 2048, 0, LP_OPTIONS},
{"NAND 2GiB 1,8V 16-bit", 0xB5, 0, 2048, 0, LP_OPTIONS16},
{"NAND 2GiB 3,3V 16-bit", 0xC5, 0, 2048, 0, LP_OPTIONS16},
--
1.7.0.4
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: NAND_Data_mail.csv
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20100726/19604a69/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NAND_Data_mail.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 24482 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20100726/19604a69/attachment-0001.ods>
More information about the linux-mtd
mailing list