Skip to contentSkip to conversation

mtd: nand: Support new Toshiba SLC

PATCH In review Brian Norris 3 participants 6 messages Aug 20, 2010 – Aug 30, 2010

Subsystems (2)
Memory technology devices (MTD) NAND flash
lore
Share & tools
lore

Brian Norris

author
#0 lore raw

PATCH 1/2 mtd: nand: Support new Toshiba SLC

Toshiba does not use ONFI for their NAND flash. So we have to continue to add new IDs used by Toshiba devices as well as heuristic detection for scanning the 2nd page for a BBM. This is a relatively harmless start at supporting many of them.

These chips mostly follow the same ID fields of previous generations, but there is a need for a few tweaks:

* These chips introduce a strange 576 byte OOB (that's 36 bytes per 512 bytes of page). In the preliminary data, Toshiba has not defined exactly how their ID strings should decode. In the future, a new tweak must be added.
* NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE should be increased soon.

Data is taken from, among others, Toshiba TC58TxG4S2FBAxx

Signed-off-by Brian Norris <[email protected]>
---
 drivers/mtd/nand/nand_base.c |    5 +++--
 drivers/mtd/nand/nand_ids.c  |   31 +++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 2 deletions(-)
drivers/mtd/nand/nand_base.c +3 -2
index a3c7473..ee5abab 100644
@@ -2962,8 +2962,8 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
 	 * Bad block marker is stored in the last page of each block
 	 * on Samsung and Hynix MLC devices; stored in first two pages
 	 * of each block on Micron devices with 2KiB pages and on
-	 * SLC Samsung, Hynix, and AMD/Spansion. All others scan only
-	 * the first page.
+	 * SLC Samsung, Hynix, Toshiba and AMD/Spansion. All others scan
+	 * only the first page.
 	 */
 	if ((chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
 			(*maf_id == NAND_MFR_SAMSUNG ||

@@ -2972,6 +2972,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
 	else if ((!(chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
 				(*maf_id == NAND_MFR_SAMSUNG ||
 				 *maf_id == NAND_MFR_HYNIX ||
+				 *maf_id == NAND_MFR_TOSHIBA ||
 				 *maf_id == NAND_MFR_AMD)) ||
 			(mtd->writesize == 2048 &&
 			 *maf_id == NAND_MFR_MICRON))
drivers/mtd/nand/nand_ids.c +31 -0
index c65f190..00cf1b0 100644
@@ -75,9 +75,13 @@ struct nand_flash_dev nand_flash_ids[] = {
 
 	/*512 Megabit */
 	{"NAND 64MiB 1,8V 8-bit",	0xA2, 0,  64, 0, LP_OPTIONS},
+	{"NAND 64MiB 1,8V 8-bit",	0xA0, 0,  64, 0, LP_OPTIONS},
 	{"NAND 64MiB 3,3V 8-bit",	0xF2, 0,  64, 0, LP_OPTIONS},
+	{"NAND 64MiB 3,3V 8-bit",	0xD0, 0,  64, 0, LP_OPTIONS},
 	{"NAND 64MiB 1,8V 16-bit",	0xB2, 0,  64, 0, LP_OPTIONS16},
+	{"NAND 64MiB 1,8V 16-bit",	0xB0, 0,  64, 0, LP_OPTIONS16},
 	{"NAND 64MiB 3,3V 16-bit",	0xC2, 0,  64, 0, LP_OPTIONS16},
+	{"NAND 64MiB 3,3V 16-bit",	0xC0, 0,  64, 0, LP_OPTIONS16},
 
 	/* 1 Gigabit */
 	{"NAND 128MiB 1,8V 8-bit",	0xA1, 0, 128, 0, LP_OPTIONS},

@@ -112,7 +116,34 @@ struct nand_flash_dev nand_flash_ids[] = {
 	{"NAND 2GiB 3,3V 16-bit",	0xC5, 0, 2048, 0, LP_OPTIONS16},
 
 	/* 32 Gigabit */
+	{"NAND 4GiB 1,8V 8-bit",	0xA7, 0, 4096, 0, LP_OPTIONS},
 	{"NAND 4GiB 3,3V 8-bit",	0xD7, 0, 4096, 0, LP_OPTIONS},
+	{"NAND 4GiB 1,8V 16-bit",	0xB7, 0, 4096, 0, LP_OPTIONS16},
+	{"NAND 4GiB 3,3V 16-bit",	0xC7, 0, 4096, 0, LP_OPTIONS16},
+
+	/* 64 Gigabit */
+	{"NAND 8GiB 1,8V 8-bit",	0xAE, 0, 8192, 0, LP_OPTIONS},
+	{"NAND 8GiB 3,3V 8-bit",	0xDE, 0, 8192, 0, LP_OPTIONS},
+	{"NAND 8GiB 1,8V 16-bit",	0xBE, 0, 8192, 0, LP_OPTIONS16},
+	{"NAND 8GiB 3,3V 16-bit",	0xCE, 0, 8192, 0, LP_OPTIONS16},
+
+	/* 128 Gigabit */
+	{"NAND 16GiB 1,8V 8-bit",	0x1A, 0, 16384, 0, LP_OPTIONS},
+	{"NAND 16GiB 3,3V 8-bit",	0x3A, 0, 16384, 0, LP_OPTIONS},
+	{"NAND 16GiB 1,8V 16-bit",	0x2A, 0, 16384, 0, LP_OPTIONS16},
+	{"NAND 16GiB 3,3V 16-bit",	0x4A, 0, 16384, 0, LP_OPTIONS16},
+
+	/* 256 Gigabit */
+	{"NAND 32GiB 1,8V 8-bit",	0x1C, 0, 32768, 0, LP_OPTIONS},
+	{"NAND 32GiB 3,3V 8-bit",	0x3C, 0, 32768, 0, LP_OPTIONS},
+	{"NAND 32GiB 1,8V 16-bit",	0x2C, 0, 32768, 0, LP_OPTIONS16},
+	{"NAND 32GiB 3,3V 16-bit",	0x4C, 0, 32768, 0, LP_OPTIONS16},
+
+	/* 512 Gigabit */
+	{"NAND 64GiB 1,8V 8-bit",	0x1E, 0, 65536, 0, LP_OPTIONS},
+	{"NAND 64GiB 3,3V 8-bit",	0x3E, 0, 65536, 0, LP_OPTIONS},
+	{"NAND 64GiB 1,8V 16-bit",	0x2E, 0, 65536, 0, LP_OPTIONS16},
+	{"NAND 64GiB 3,3V 16-bit",	0x4E, 0, 65536, 0, LP_OPTIONS16},
 
 	/*
 	 * Renesas AND 1 Gigabit. Those chips do not support extended id and
Signature · 1 line
1.7.0.4
author
#1 lore raw

PATCH 2/2 mtd: nand: Increase NAND_MAX_OOBSIZE

An increase in NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE is necessary in order to support many new chips. Among those:

Toshiba TC58TxG4S2FBAxx 8KB page, 576B OOB
Micron MT29F64G08CBAAA 8KB page, 448B OOB

Signed-off-by Brian Norris <[email protected]>
---
 include/linux/mtd/nand.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
include/linux/mtd/nand.h +2 -2
index 102e12c..a8921c2 100644
@@ -53,8 +53,8 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len);
  * is supported now. If you add a chip with bigger oobsize/page
  * adjust this accordingly.
  */
-#define NAND_MAX_OOBSIZE	256
-#define NAND_MAX_PAGESIZE	4096
+#define NAND_MAX_OOBSIZE	576
+#define NAND_MAX_PAGESIZE	8192
 
 /*
  * Constants for hardware specific CLE/ALE/NCE function
Signature · 1 line
1.7.0.4
#2 lore raw

Re: [PATCH 2/2] mtd: nand: Increase NAND_MAX_OOBSIZE

Quoted 5 lines · Brian Norris

An increase in NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE is necessary in order to support many new chips. Among those:

Toshiba TC58TxG4S2FBAxx 8KB page, 576B OOB
Micron MT29F64G08CBAAA 8KB page, 448B OOB

Ick, don't we have a better fix for this in the works?

Signature · 1 line
dwmw2
author
#3 lore raw

Re: [PATCH 2/2] mtd: nand: Increase NAND_MAX_OOBSIZE

Quoted 9 lines · David Woodhouse
Quoted 5 lines · Brian Norris

An increase in NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE is necessary in order to support many new chips. Among those:

Toshiba TC58TxG4S2FBAxx 8KB page, 576B OOB
Micron MT29F64G08CBAAA 8KB page, 448B OOB

Ick, don't we have a better fix for this in the works?

For the MAX macros? I have no idea. There were comments there telling me to do this whenever newer chips are supported.

#4 lore raw

Re: [PATCH 2/2] mtd: nand: Increase NAND_MAX_OOBSIZE

Quoted 2 lines · Brian Norris

For the MAX macros? I have no idea. There were comments there telling me to do this whenever newer chips are supported.

I was thinking of the nand_ecc_layout stuff, I think.

Perhaps these buffers should be dynamically allocated and we should ditch the MAX macros altogether?

Signature · 2 lines
David Woodhouse                            Open Source Technology Centre
[email protected]                              Intel Corporation
#5 lore raw
In reply to Brian Norris
Quoted 14 lines · Brian Norris

Toshiba does not use ONFI for their NAND flash. So we have to continue to add new IDs used by Toshiba devices as well as heuristic detection for scanning the 2nd page for a BBM. This is a relatively harmless start at supporting many of them.

These chips mostly follow the same ID fields of previous generations, but there is a need for a few tweaks:

* These chips introduce a strange 576 byte OOB (that's 36 bytes per 512 bytes of page). In the preliminary data, Toshiba has not defined exactly how their ID strings should decode. In the future, a new tweak must be added.
* NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE should be increased soon.

Quoted 7 lines

Data is taken from, among others, Toshiba TC58TxG4S2FBAxx

Signed-off-by Brian Norris <[email protected]>
---
 drivers/mtd/nand/nand_base.c |    5 +++--
 drivers/mtd/nand/nand_ids.c  |   31 +++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 2 deletions(-)

Pushed both patches to my l2-mtd-2.6.git / master, but in reverse order, which seems to be more logical.

Signature · 2 lines
Best Regards,
Artem Bityutskiy (Битюцкий Артём)