Part 1/2 is an improved version of my previous submission.  Additional
checks were added to ensure that certain "5-byte" Micron and Samsung
parts are not falsely detected as having 6-byte IDs.  I also rolled in
the 256B NAND_MAX_OOBSIZE change.

Part 2/2 is a resubmission/rebase of Reuben Dowle's 2009/02/03 patch:

http://lists.infradead.org/pipermail/linux-mtd/2009-February/024473.html

I am trying to compile a table of NAND IDs to make sure the detection
algorithm correctly handles all known cases.  If you could send me the
following information for any NAND chips you have access to (via
private email), it would be appreciated:

1) Part number

2) ID code (please read 8 bytes so I can see where it wraps around)

3) Device size, block size, page size, OOB bytes per page, bus width,
and bad block marker location

4) Datasheet, if available

Thanks.
--

[ message continues ]

Some of the newer MLC devices have a 6-byte ID sequence in which
several field definitions differ from older chips in a manner that is
not backward compatible.  For instance:

Samsung K9GAG08U0M (5-byte sequence): ec d5 14 b6 74
4th byte, bits 1:0 encode the page size: 0=1KiB, 1=2KiB, 2=4KiB, 3=8KiB
4th byte, bits 5:4 encode the block size: 0=64KiB, 1=128KiB, ...
4th byte, bit 6 encodes the OOB size: 0=8B/512B, 1=16B/512B

Samsung K9GAG08U0D (6-byte sequence): ec d5 94 29 34 41
4th byte, bits 1:0 encode the page size: 0=2KiB, 1=4KiB, 3=8KiB, 4=rsvd
4th byte, bits 7;5:4 encode the block size: 0=128KiB, 1=256KiB, ...
4th byte, bits 6;3:2 encode the OOB size: 1=128B/page, 2=218B/page

This patch uses the new 6-byte scheme if the following conditions are
all true:

1) The ID code wraps around after exactly 6 bytes

2) Manufacturer is Samsung

3) 6th byte is zero

The patch also extends the maximum OOB size from 128B to 256B.

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
 drivers/mtd/nand/nand_base.c |   64 ++++++++++++++++++++++++++++-------------
 include/linux/mtd/nand.h     |    2 +-
 2 files changed, 45 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index b9dc65c..85891dc 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2774,8 +2774,8 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
 						  int busw, int *maf_id,
 						  struct nand_flash_dev *type)
 {
-	int dev_id, maf_idx;
-	int tmp_id, tmp_manf;
+	int i, dev_id, maf_idx;
+	u8 id_data[8];
 
 	/* Select the device */
 	chip->select_chip(mtd, 0);
@@ -2801,15 +2801,15 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
 
 	chip->cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);
 
-	/* Read manufacturer and device IDs */
+	/* Read entire ID string */
 
-	tmp_manf = chip->read_byte(mtd);
-	tmp_id = chip->read_byte(mtd);
+	for (i = 0; i < 8; i++)
+		id_data[i] = ...
[ message continues ]

Hi,

Doesn't these nand support ONFI "Read Parameter Page" (cmd 0xec) ?
If yes it will be a more generic way to detect new nand features.




--

[ message continues ]

On Wed, May 5, 2010 at 12:34 AM, Matthieu CASTET

Unfortunately, Samsung and Toshiba do not support ONFI:

http://onfi.org/membership/

http://www.hantat.com/News-Read-281-1.html
--

[ message continues ]

This is a slightly modified version of a patch submitted last year by
Reuben Dowle <reuben.dowle@navico.com>.  His original comments follow:

This patch adds support for some MLC NAND flashes that place the BB
marker in the LAST page of the bad block rather than the FIRST page used
for SLC NAND and other types of MLC nand.

Lifted from Samsung datasheet for K9LG8G08U0A (1Gbyte MLC NAND):
"
Identifying Initial Invalid Block(s)
All device locations are erased(FFh) except locations where the initial
invalid block(s) information is written prior to shipping. The initial
invalid block(s) status is defined by the 1st byte in the spare area.
Samsung makes sure that the last page of every initial invalid block has
non-FFh data at the column address of 2,048.
...
"

As far as I can tell, this is the same for all Samsung MLC nand, and in
fact the samsung bsp for the processor used in our project (s3c6410)
actually contained a hack similar to this patch but less portable to
enable use of their NAND parts. I discovered this problem when trying to
use a Micron NAND which does not used this layout - I wish samsung would
put their stuff in main-line to avoid this type of problem.

Currently this patch causes all MLC nand with manufacturer codes from
Samsung and ST(Numonyx) to use this alternative location, since these
are the manufactures that I know of that use this layout.

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
 drivers/mtd/nand/nand_base.c |   15 +++++++++++++++
 drivers/mtd/nand/nand_bbt.c  |    3 +++
 include/linux/mtd/nand.h     |    2 ++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 85891dc..4a7b864 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -347,6 +347,9 @@ static int nand_block_bad(struct mtd_info *mtd, loff_t ofs, int getchip)
 	struct nand_chip *chip = mtd->priv;
 	u16 bad;
 
+	if (chip->options & NAND_BB_LAST_PAGE)
+		ofs += ...
[ message continues ]

Removed older patches and taken these ones to l2-mtd-2.6 / dunno.

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

--

[ message continues ]