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

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

[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.

Data is taken from, among others, Toshiba TC58TxG4S2FBAxx

Signed-off-by: Brian Norris <norris@broadcom.com>
---
 drivers/mtd/nand/nand_base.c |    5 +++--
 drivers/mtd/nand/nand_ids.c  |   31 +++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a3c7473..ee5abab 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -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))
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index c65f190..00cf1b0 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -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
-- 
1.7.0.4

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

[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

Signed-off-by: Brian Norris <norris@broadcom.com>
---
 include/linux/mtd/nand.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 102e12c..a8921c2 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -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
-- 
1.7.0.4

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

[David Woodhouse]

On Fri, 2010-08-20 at 12:36 -0700, Brian Norris wrote:
> 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?

-- 
dwmw2

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

[Brian Norris]

On 08/20/2010 12:43 PM, David Woodhouse wrote:
> On Fri, 2010-08-20 at 12:36 -0700, Brian Norris wrote:
>> 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.

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

[David Woodhouse]

On Fri, 2010-08-20 at 14:28 -0700, Brian Norris wrote:
> 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?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [PATCH 1/2] mtd: nand: Support new Toshiba SLC

[Artem Bityutskiy]

On Fri, 2010-08-20 at 12:36 -0700, Brian Norris wrote:
> 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 <norris@broadcom.com>
> ---
>  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.

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)