Re: [U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip

2011-12-15 Thread Scott Wood
On 12/15/2011 04:53 AM, Liu Shengzhou-B36685 wrote:
 -Original Message-
 From: Wood Scott-B07421
 Sent: Tuesday, December 13, 2011 4:14 AM
 To: Liu Shengzhou-B36685
 Cc: u-boot@lists.denx.de; Gala Kumar-B11780; Liu Shuo-B35362
 Subject: Re: [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to
 support 4k pagesize Nand chip

 + nand-ecc.layout = (priv-fmr  FMR_ECCM) ?
 +fsl_elbc_oob_lp_eccm1 : fsl_elbc_oob_lp_eccm0;
 + nand-badblock_pattern = largepage_memorybased;

 Those oob layouts won't be quite right for larger page sizes.

 -Scott
 [Shengzhou] It's the same with what Linux does. What's the right?

 I think we need to explicitly define 4096 and 8192 variants, with the
 extra eccpos/oobfree.  Or generate them programatically.

 -Scott
 
 [Shengzhou]
 You mean we should define something like below?
 static struct nand_ecclayout fsl_elbc_oob_lp_4k_eccm0 = {
 .eccbytes = 24,
 .eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56,
  70, 71, 72, 86, 87, 88, 102, 103, 104, 118, 119, 120},
 .oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7},.. },
 };
 static struct nand_ecclayout fsl_elbc_oob_lp_8k_eccm0 = {};

Yes.

 eLBC RM says:
 ECC is checked/calculated over 512-Byte blocks. A 24-bit ECC is assigned to 
 spare region bytes at offsets
 (N × 16) + 6 through (N × 16) + 8 for spare region N, N = 0–3.   (for ECCM=0 
 case)
 
 Here RM just says N is 0–3, but it should be 0-7 for 4096 case, 

Well, yes, this is a hack to do things that the hardware doesn't
officially support.

 hardware ECC doesn't generate ECC in position of N=4,5,6,7. 

It will.  It just thinks that N=0,1,2,3.

 fsl_elbc_oob_lp_eccm0 and fsl_elbc_oob_lp_eccm1 are controller-associated, 
 not device-associated,

Then why do we have separate small and large page versions?

 I think we don't need define 4096 and 8192 variants, it's emulating 4096/8192 
 case by 
 the existing 2K layout of fsl_elbc_oob_lp_eccm0 and fsl_elbc_oob_lp_eccm1.
 Please correct me if any wrong understanding.

It's supporting 4096/8192 by repeating the 2048 layout multiple times.
This repetition is not captured by the existing nand_ecclayout.

-Scott

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip

2011-12-14 Thread Scott Wood
On 12/14/2011 01:30 AM, Liu Shengzhou-B36685 wrote:
 
 
 -Original Message-
 From: Wood Scott-B07421
 Sent: Tuesday, December 13, 2011 4:14 AM
 To: Liu Shengzhou-B36685
 Cc: u-boot@lists.denx.de; Gala Kumar-B11780; Liu Shuo-B35362
 Subject: Re: [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to
 support 4k pagesize Nand chip

 I've asked you several times what you're planning on doing for bad block
 marker migration.  I am not going to let you ignore this.  NACK until you
 have a migration tool, and a scheme for marking the flash as having been
 migrated.

 
 [Shengzhou] 
 This is the first time that you asked me about bad block marker migration.
 You asked LiuShuo several times in Linux mail list, as I am not in that thread
 And not known about it until Liushuo told me. 
 As LiuShuo will do it, so I am not planning on it.

Ah, sorry about that.

Still, I'd like to see it done, whoever does it, before this gets
merged.  I don't want people to be able to accidentally start using it
without doing migration.

 +   nand-ecc.layout = (priv-fmr  FMR_ECCM) ?
 +  fsl_elbc_oob_lp_eccm1 : fsl_elbc_oob_lp_eccm0;
 +   nand-badblock_pattern = largepage_memorybased;

 Those oob layouts won't be quite right for larger page sizes.

 -Scott
 [Shengzhou] It's the same with what Linux does. What's the right?

I think we need to explicitly define 4096 and 8192 variants, with the
extra eccpos/oobfree.  Or generate them programatically.

-Scott

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip

2011-12-12 Thread Shengzhou Liu
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip with pagesize larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Liu Shuo b35...@freescale.com
---
 drivers/mtd/nand/fsl_elbc_nand.c |  283 +
 1 files changed, 252 insertions(+), 31 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 99d1061..a2d8067 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -64,7 +64,6 @@ struct fsl_elbc_mtd {
struct device *dev;
int bank;   /* Chip select bank number   */
u8 __iomem *vbase;  /* Chip select base virtual address  */
-   int page_size;  /* NAND page size (0=512, 1=2048)*/
unsigned int fmr;   /* FCM Flash Mode Register value */
 };
 
@@ -85,6 +84,8 @@ struct fsl_elbc_ctrl {
unsigned int mdr;/* UPM/FCM Data Register value   */
unsigned int use_mdr;/* Non zero if the MDR is to be set  */
unsigned int oob;/* Non zero if operating on OOB data */
+   char *buffer;/* Just used when pagesize is greater*/
+/* than FCM RAM 2K limitation*/
 };
 
 /* These map to the positions used by the FCM hardware ECC generator */
@@ -159,6 +160,35 @@ static struct nand_bbt_descr bbt_mirror_descr = {
.pattern = mirror_pattern,
 };
 
+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+   struct nand_chip *chip = mtd-priv;
+   struct fsl_elbc_mtd *priv = chip-priv;
+   struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+   void *src, *dst;
+   int len = oob ? 64 : 2048;
+
+   /* for emulating 4096+ bytes NAND using 2048-byte FCM RAM */
+   dst = ctrl-buffer + (oob ? mtd-writesize : 0) + subpage * len;
+   src = ctrl-addr + (oob ? 2048 : 0);
+   memcpy_fromio(dst, src, len);
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+   struct nand_chip *chip = mtd-priv;
+   struct fsl_elbc_mtd *priv = chip-priv;
+   struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+   void *src, *dst;
+   int len = oob ? 64 : 2048;
+
+   src = ctrl-buffer + (oob ? mtd-writesize : 0) + subpage * len;
+   dst = ctrl-addr + (oob ? 2048 : 0);
+   memcpy_toio(dst, src, len);
+   /* See the in_8() in fsl_elbc_write_buf() */
+   in_8(ctrl-addr);
+}
+
 /*=*/
 
 /*
@@ -175,7 +205,7 @@ static void set_addr(struct mtd_info *mtd, int column, int 
page_addr, int oob)
 
ctrl-page = page_addr;
 
-   if (priv-page_size) {
+   if (mtd-writesize = 2048) {
out_be32(lbc-fbar, page_addr  6);
out_be32(lbc-fpar,
 ((page_addr  FPAR_LP_PI_SHIFT)  FPAR_LP_PI) |
@@ -194,7 +224,7 @@ static void set_addr(struct mtd_info *mtd, int column, int 
page_addr, int oob)
 
/* for OOB data point to the second half of the buffer */
if (oob)
-   ctrl-index += priv-page_size ? 2048 : 512;
+   ctrl-index += mtd-writesize;
 
vdbg(set_addr: bank=%d, ctrl-addr=0x%p (0x%p), 
 index %x, pes %d ps %d\n,
@@ -256,13 +286,14 @@ static int fsl_elbc_run_command(struct mtd_info *mtd)
return ctrl-status == LTESR_CC ? 0 : -EIO;
 }
 
-static void fsl_elbc_do_read(struct nand_chip *chip, int oob)
+static void fsl_elbc_do_read(struct mtd_info *mtd, int oob)
 {
+   struct nand_chip *chip = mtd-priv;
struct fsl_elbc_mtd *priv = chip-priv;
struct fsl_elbc_ctrl *ctrl = priv-ctrl;
fsl_lbc_t *lbc = ctrl-regs;
 
-   if (priv-page_size) {
+   if (mtd-writesize = 2048) {
out_be32(lbc-fir,
 (FIR_OP_CW0  FIR_OP0_SHIFT) |
 (FIR_OP_CA   FIR_OP1_SHIFT) |
@@ -295,6 +326,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned 
int command,
struct fsl_elbc_mtd *priv = chip-priv;
struct fsl_elbc_ctrl *ctrl = priv-ctrl;
fsl_lbc_t *lbc = ctrl-regs;
+   int i, nps = mtd-writesize / 2048;
 
ctrl-use_mdr = 0;
 
@@ -319,8 +351,28 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, 
unsigned int command,
ctrl-read_bytes = mtd-writesize + mtd-oobsize;
ctrl-index += column;
 
-   fsl_elbc_do_read(chip, 0);
+   fsl_elbc_do_read(mtd, 0);
fsl_elbc_run_command(mtd);
+
+   if (mtd-writesize = 2048)
+   return;
+
+   /* Continue to read the rest bytes if writesize  2048 */
+   io_to_buffer(mtd, 0, 0);
+   io_to_buffer(mtd, 0, 1);
+   /*
+* Maybe there are 

Re: [U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip

2011-12-12 Thread Scott Wood
On 12/12/2011 03:49 AM, Shengzhou Liu wrote:
 Freescale FCM controller has a 2K size limitation of buffer RAM. In order
 to support the Nand flash chip with pagesize larger than 2K bytes,
 we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
 them to a large buffer.
 
 Signed-off-by: Shengzhou Liu shengzhou@freescale.com
 Signed-off-by: Liu Shuo b35...@freescale.com
 ---
  drivers/mtd/nand/fsl_elbc_nand.c |  283 +
  1 files changed, 252 insertions(+), 31 deletions(-)

I've asked you several times what you're planning on doing for bad block
marker migration.  I am not going to let you ignore this.  NACK until
you have a migration tool, and a scheme for marking the flash as having
been migrated.

Also please mention below the --- what has changed since v1.

 @@ -393,9 +468,28 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, 
 unsigned int command,
page_addr, column);
  
   ctrl-column = column;
 - ctrl-oob = 0;
 + if (column = mtd-writesize) {
 + /* OOB area */
 + column -= mtd-writesize;
 + ctrl-oob = 1;
 + } else {
 + ctrl-oob = 0;
 + }
[snip]
 @@ -432,12 +524,19 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, 
 unsigned int command,
   }
  
   out_be32(lbc-fcr, fcr);
 - set_addr(mtd, column, page_addr, ctrl-oob);
 + if (column = mtd-writesize  mtd-writesize  2048) {

How can column = mtd-writesize be true at this point?  You've already
subtracted it out.

   if (ctrl-oob || ctrl-column != 0 ||
 - ctrl-index != mtd-writesize + mtd-oobsize)
 - out_be32(lbc-fbcr, ctrl-index);
 - else
 + ctrl-index != mtd-writesize + mtd-oobsize) {
 + if (ctrl-oob  mtd-writesize  2048) {
 + out_be32(lbc-fbcr, 64);
 + } else {
 + out_be32(lbc-fbcr, ctrl-index -
 + ctrl-column);
 + }
 + } else {
   out_be32(lbc-fbcr, 0);
 + }

Again, if we're going to make an API assumption that we get either a
full page access or a full OOB access, then make the assumption fully.
Don't half-implement partial accessses.

 +int board_nand_init_tail(struct mtd_info *mtd)
 +{
 + struct nand_chip *nand = mtd-priv;
 + struct fsl_elbc_mtd *priv = nand-priv;
 + struct fsl_elbc_ctrl *ctrl = priv-ctrl;
 +
 + /* adjust Option Register and ECC to match Flash page size */
 + if (mtd-writesize == 512) {
 + clrbits_be32(ctrl-regs-bank[priv-bank].or, OR_FCM_PGS);
 + } else if (mtd-writesize = 2048  mtd-writesize = 8192) {
 + setbits_be32(ctrl-regs-bank[priv-bank].or, OR_FCM_PGS);
 + /* adjust ecc setup if needed */
 + if ((in_be32(ctrl-regs-bank[priv-bank].br)  BR_DECC) ==
 + BR_DECC_CHK_GEN) {
 + nand-ecc.size = 512;

Please find some way to indent the continuation line so it doesn't line
up with the if-body.

 + nand-ecc.layout = (priv-fmr  FMR_ECCM) ?
 +fsl_elbc_oob_lp_eccm1 : fsl_elbc_oob_lp_eccm0;
 + nand-badblock_pattern = largepage_memorybased;

Those oob layouts won't be quite right for larger page sizes.

-Scott

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot