mtd/nand : Add function board_nand_init_tail() for some special NAND controllers

- fix NAND_CMD_READID command for ONFI detect.
- add NAND_CMD_PARAM command to read the ONFI parameter page.

Signed-off-by Shengzhou Liu <[email protected]>

---
 drivers/mtd/nand/fsl_elbc_nand.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

drivers/mtd/nand/fsl_elbc_nand.c +4 -1

index 4d1e527..476fdd3 100644
@@ -350,7 +350,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		out_be32(&lbc->fbcr, 5);
 		ctrl->read_bytes = 5;
 		ctrl->use_mdr = 1;
-		ctrl->mdr = 0;
+		ctrl->mdr = column;
 
 		set_addr(mtd, 0, 0, 0);
 		fsl_elbc_run_command(mtd);

@@ -480,6 +480,20 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		fsl_elbc_run_command(mtd);
 		return;
 
+	case NAND_CMD_PARAM:
+		dbg("fsl_elbc_cmdfunc: NAND_CMD_PARAM.\n");
+		out_be32(&lbc->fir, (FIR_OP_CM0 << FIR_OP0_SHIFT) |

Quoted 36 lines

-----Original Message-----
From: Wood Scott-B07421
Sent: 2011?12?3? 2:45
To: Liu Shengzhou-B36685
Cc: u-boot at lists.denx.de; Gala Kumar-B11780
Subject: Re: [PATCH 4/4] mtd/nand: Add ONFI support for FSL NAND controller

drivers/mtd/nand/fsl_elbc_nand.c static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, · line 495

Quoted 13 lines · Shengzhou Liu

drivers/mtd/nand/fsl_elbc_nand.c +13 -0

+	case NAND_CMD_PARAM:
+		dbg("fsl_elbc_cmdfunc: NAND_CMD_PARAM.\n");
+		out_be32(&lbc->fir, (FIR_OP_CM0 << FIR_OP0_SHIFT) |
+				    (FIR_OP_UA  << FIR_OP1_SHIFT) |
+				    (FIR_OP_RBW << FIR_OP2_SHIFT));
+		out_be32(&lbc->fcr, NAND_CMD_PARAM << FCR_CMD0_SHIFT);
+		out_be32(&lbc->fbcr, 256);
+		ctrl->read_bytes = 256;
+		ctrl->use_mdr = 1;
+		ctrl->mdr = column;
+		set_addr(mtd, 0, 0, 0);
+		fsl_elbc_run_command(mtd);
+		return;

This could share code with NAND_CMD_READID -- always read 256 bytes (we'll need to read more than 5 bytes for non-ONFI as well, when we pull
in the newer Linux NAND code), and use "command << FCR_CMD0_SHIFT" for FCR.

BTW, has anyone tested the eLBC driver with 16-bit NAND? I think our read_byte() implementation is not going to do the right thing here -- it
needs to read a 16-bit word when the chip is 16-bit, and discard the upper half.

Quoted 1 line

-Scott

There was already NAND_CMD_PARAM command which is called in mtd/nand/nand_base.c, it's not new created. NAND_CMD_PARAM is defined in spec, we should not share it with NAND_CMD_READID, if so, we'll have to intrusive to nand_base.c.

There was a bug logically in the order of nand_flash_detect_onfi and checking nand_flash_ids. We should get NAND devices related informations first by ONFI method instead of querying nand_flash_ids table, if ONFI fails, then query nand_flash_ids table.

Quoted 18 lines

-----Original Message-----
From: Wood Scott-B07421
Sent: 2011?12?3? 2:32
To: Liu Shengzhou-B36685
Cc: u-boot at lists.denx.de; Gala Kumar-B11780
Subject: Re: [PATCH 2/4] mtd/nand: Fixup for support ONFI detect

Quoted 3 lines · Shengzhou Liu

There was a bug logically in the order of nand_flash_detect_onfi and checking nand_flash_ids. We should get NAND devices related informations first by ONFI method instead of querying nand_flash_ids

table,

Quoted 1 line

if ONFI fails, then query nand_flash_ids table.

ONFI issues should be taken care of with the patchset to sync NAND with Linux that was recently posted. It has some minor issues, which hopefully will be addressed by the next merge window.

Quoted 6 lines

I disagree that we should check ONFI first -- this is not what Linux does. U-Boot's problem is that it aborts before ever checking ONFI, if the device is not found in the table (and the Linux code suggests that ONFI devices won't be found in the table).

-Scott

Currently in Linux, ONFI is detected first, if ONFI fails, then detect nand_flash_ids table.

But in u-boot, it first detects nand_flash_ids table, if not found in the table, it aborts, so ONFI never works.

I think we should still check ONFI first to accord to what Linux does, because there many new NAND chips which not listed in the nand_flash_ids table before known, if check ONFI first, it can automatically find related info without manual intervention.

In some NAND controllers there is a size limitation of RAM buffer(2K bytes). To support large-page NAND chips with greater than 2K pagesize, we need a large buffer, but we don't know pagesize before calling nand_scan_ident(), for more flexible and to identify different cases of large-page greater than 2K bytes, we have a board_nand_init_tail() between nand_scan_ident() and nand_scan_tail().

Signed-off-by Shengzhou Liu <[email protected]>

---
 drivers/mtd/nand/nand.c |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

drivers/mtd/nand/nand.c +0 -0

index d987f4c..2bafe47 100644

drivers/mtd/nand/nand.c +6 -1

 static void nand_init_chip(struct mtd_info *mtd, struct nand_chip *nand,
 			   ulong base_addr)
 {

@@ -51,7 +58,12 @@ static void nand_init_chip(struct mtd_info *mtd, struct nand_chip *nand,
 
 	nand->IO_ADDR_R = nand->IO_ADDR_W = (void  __iomem *)base_addr;
 	if (board_nand_init(nand) == 0) {
-		if (nand_scan(mtd, maxchips) == 0) {
+		if (!nand_scan_ident(mtd, maxchips, NULL)) {
+			board_nand_init_tail(mtd, nand);
+			if (nand_scan_tail(mtd)) {
+				mtd->name = NULL;
+				return;
+			}
 			if (!mtd->name)
 				mtd->name = (char *)default_nand_name;
 #ifdef CONFIG_NEEDS_MANUAL_RELOC