[U-Boot] [PATCH 0/5 V2] Random NAND fixes and improvements

[U-Boot] [PATCH 0/5 V2] Random NAND fixes and improvements

[Marek Vasut]

This is a resend of the NAND fixes and improvements. These are squashed
togethere here and sent as a batch.

V2: Fix the scrub.quiet command

Marek Vasut (5):
  NAND: Really ignore bad blocks when scrubbing
  NAND: Add nand read.raw and write.raw commands
  NAND: Allow per-buffer allocation
  NAND: Make page, erase, oob size available via cmd_nand
  NAND: Add scrub.quiet command option

 common/cmd_nand.c            |   64 +++++++++++++++++++++++++++++++++++++++--
 drivers/mtd/nand/nand_base.c |   32 +++++++++++++++-----
 drivers/mtd/nand/nand_util.c |   22 +++-----------
 include/linux/mtd/mtd.h      |    1 +
 include/linux/mtd/nand.h     |    7 ++--
 5 files changed, 94 insertions(+), 32 deletions(-)

-- 
1.7.5.4

[U-Boot] [PATCH 1/5] NAND: Really ignore bad blocks when scrubbing

[Marek Vasut]

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 drivers/mtd/nand/nand_base.c |    2 +-
 drivers/mtd/nand/nand_util.c |   22 +++++-----------------
 include/linux/mtd/mtd.h      |    1 +
 3 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1a95a91..d8d30e3 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2224,7 +2224,7 @@ int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
 		/*
 		 * heck if we have a bad block, we do not erase bad blocks !
 		 */
-		if (nand_block_checkbad(mtd, ((loff_t) page) <<
+		if (!instr->scrub && nand_block_checkbad(mtd, ((loff_t) page) <<
 					chip->page_shift, 0, allowbbt)) {
 			printk(KERN_WARNING "nand_erase: attempt to erase a "
 			       "bad block at page 0x%08x\n", page);
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 81bf366..0c3b7f7 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -57,12 +57,6 @@ typedef struct mtd_info	  mtd_info_t;
 #define cpu_to_je16(x) (x)
 #define cpu_to_je32(x) (x)
 
-/*****************************************************************************/
-static int nand_block_bad_scrub(struct mtd_info *mtd, loff_t ofs, int getchip)
-{
-	return 0;
-}
-
 /**
  * nand_erase_opts: - erase NAND flash with support for various options
  *		      (jffs2 formating)
@@ -82,10 +76,10 @@ int nand_erase_opts(nand_info_t *meminfo, const nand_erase_options_t *opts)
 	int bbtest = 1;
 	int result;
 	int percent_complete = -1;
-	int (*nand_block_bad_old)(struct mtd_info *, loff_t, int) = NULL;
 	const char *mtd_device = meminfo->name;
 	struct mtd_oob_ops oob_opts;
 	struct nand_chip *chip = meminfo->priv;
+	struct nand_chip *priv_nand = meminfo->priv;
 
 	if ((opts->offset & (meminfo->writesize - 1)) != 0) {
 		printf("Attempt to erase non page aligned data\n");
@@ -110,11 +104,9 @@ int nand_erase_opts(nand_info_t *meminfo, const nand_erase_options_t *opts)
 	 * and disable bad block table while erasing.
 	 */
 	if (opts->scrub) {
-		struct nand_chip *priv_nand = meminfo->priv;
-
-		nand_block_bad_old = priv_nand->block_bad;
-		priv_nand->block_bad = nand_block_bad_scrub;
-		/* we don't need the bad block table anymore...
+		erase.scrub = opts->scrub;
+		/*
+		 * We don't need the bad block table anymore...
 		 * after scrub, there are no bad blocks left!
 		 */
 		if (priv_nand->bbt) {
@@ -204,12 +196,8 @@ int nand_erase_opts(nand_info_t *meminfo, const nand_erase_options_t *opts)
 	if (!opts->quiet)
 		printf("\n");
 
-	if (nand_block_bad_old) {
-		struct nand_chip *priv_nand = meminfo->priv;
-
-		priv_nand->block_bad = nand_block_bad_old;
+	if (opts->scrub)
 		priv_nand->scan_bbt(meminfo);
-	}
 
 	return 0;
 }
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index d36d584..141c960 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -55,6 +55,7 @@ struct erase_info {
 	u_long priv;
 	u_char state;
 	struct erase_info *next;
+	int scrub;
 };
 
 struct mtd_erase_region_info {
-- 
1.7.5.4

[U-Boot] [PATCH 1/5] NAND: Really ignore bad blocks when scrubbing

[Scott Wood]

On Mon, Sep 12, 2011 at 06:04:06AM +0200, Marek Vasut wrote:
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  drivers/mtd/nand/nand_base.c |    2 +-
>  drivers/mtd/nand/nand_util.c |   22 +++++-----------------
>  include/linux/mtd/mtd.h      |    1 +
>  3 files changed, 7 insertions(+), 18 deletions(-)

Applied to u-boot-nand-flash next with this change to remove the
chip/priv_nand redundancy:

diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 0c3b7f7..60c778e 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -79,7 +79,6 @@ int nand_erase_opts(nand_info_t *meminfo, const nand_erase_options_t *opts)
 	const char *mtd_device = meminfo->name;
 	struct mtd_oob_ops oob_opts;
 	struct nand_chip *chip = meminfo->priv;
-	struct nand_chip *priv_nand = meminfo->priv;
 
 	if ((opts->offset & (meminfo->writesize - 1)) != 0) {
 		printf("Attempt to erase non page aligned data\n");
@@ -109,10 +108,10 @@ int nand_erase_opts(nand_info_t *meminfo, const nand_erase_options_t *opts)
 		 * We don't need the bad block table anymore...
 		 * after scrub, there are no bad blocks left!
 		 */
-		if (priv_nand->bbt) {
-			kfree(priv_nand->bbt);
+		if (chip->bbt) {
+			kfree(chip->bbt);
 		}
-		priv_nand->bbt = NULL;
+		chip->bbt = NULL;
 	}
 
 	for (erased_length = 0;
@@ -197,7 +196,7 @@ int nand_erase_opts(nand_info_t *meminfo, const nand_erase_options_t *opts)
 		printf("\n");
 
 	if (opts->scrub)
-		priv_nand->scan_bbt(meminfo);
+		chip->scan_bbt(meminfo);
 
 	return 0;
 }

-Scott

[U-Boot] [PATCH 2/5] NAND: Add nand read.raw and write.raw commands

[Marek Vasut]

These commands should work around various "hardware" ECC and BCH methods.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 66e06a5..a1c8dfd 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -606,6 +606,20 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 				ret = nand->read_oob(nand, off, &ops);
 			else
 				ret = nand->write_oob(nand, off, &ops);
+		} else if (!strcmp(s, ".raw")) {
+			/* Raw access */
+			mtd_oob_ops_t ops = {
+				.datbuf = (u8 *)addr,
+				.oobbuf = ((u8 *)addr) + nand->writesize,
+				.len = nand->writesize,
+				.ooblen = nand->oobsize,
+				.mode = MTD_OOB_RAW
+			};
+
+			if (read)
+				ret = nand->read_oob(nand, off, &ops);
+			else
+				ret = nand->write_oob(nand, off, &ops);
 		} else {
 			printf("Unknown nand command suffix '%s'.\n", s);
 			return 1;
-- 
1.7.5.4

[U-Boot] [PATCH 2/5] NAND: Add nand read.raw and write.raw commands

[Scott Wood]

On 09/11/2011 11:04 PM, Marek Vasut wrote:
> These commands should work around various "hardware" ECC and BCH methods.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  common/cmd_nand.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 66e06a5..a1c8dfd 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -606,6 +606,20 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
>  				ret = nand->read_oob(nand, off, &ops);
>  			else
>  				ret = nand->write_oob(nand, off, &ops);
> +		} else if (!strcmp(s, ".raw")) {
> +			/* Raw access */
> +			mtd_oob_ops_t ops = {
> +				.datbuf = (u8 *)addr,
> +				.oobbuf = ((u8 *)addr) + nand->writesize,
> +				.len = nand->writesize,
> +				.ooblen = nand->oobsize,
> +				.mode = MTD_OOB_RAW
> +			};
> +
> +			if (read)
> +				ret = nand->read_oob(nand, off, &ops);
> +			else
> +				ret = nand->write_oob(nand, off, &ops);
>  		} else {
>  			printf("Unknown nand command suffix '%s'.\n", s);
>  			return 1;

Update help text and doc/README.nand.

Should we support doing multiple pages at once?

-Scott

[U-Boot] [PATCH 2/5 V2] NAND: Add nand read.raw and write.raw commands

[Marek Vasut]

These commands should work around various "hardware" ECC and BCH methods.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |   19 +++++++++++++++++--
 doc/README.nand   |    9 +++++++++
 2 files changed, 26 insertions(+), 2 deletions(-)

V2: Add documentation.

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 66e06a5..72d418c 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -606,6 +606,20 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 				ret = nand->read_oob(nand, off, &ops);
 			else
 				ret = nand->write_oob(nand, off, &ops);
+		} else if (!strcmp(s, ".raw")) {
+			/* Raw access */
+			mtd_oob_ops_t ops = {
+				.datbuf = (u8 *)addr,
+				.oobbuf = ((u8 *)addr) + nand->writesize,
+				.len = nand->writesize,
+				.ooblen = nand->oobsize,
+				.mode = MTD_OOB_RAW
+			};
+
+			if (read)
+				ret = nand->read_oob(nand, off, &ops);
+			else
+				ret = nand->write_oob(nand, off, &ops);
 		} else {
 			printf("Unknown nand command suffix '%s'.\n", s);
 			return 1;
@@ -695,10 +709,11 @@ U_BOOT_CMD(
 	"NAND sub-system",
 	"info - show available NAND devices\n"
 	"nand device [dev] - show or set current device\n"
-	"nand read - addr off|partition size\n"
-	"nand write - addr off|partition size\n"
+	"nand read[.raw] - addr off|partition size\n"
+	"nand write[.raw] - addr off|partition size\n"
 	"    read/write 'size' bytes starting at offset 'off'\n"
 	"    to/from memory address 'addr', skipping bad blocks.\n"
+	"    Use read.raw/write.raw to avoid ECC and write the block as-is.\n"
 #ifdef CONFIG_CMD_NAND_TRIMFFS
 	"nand write.trimffs - addr off|partition size\n"
 	"    write 'size' bytes starting at offset 'off' from memory address\n"
diff --git a/doc/README.nand b/doc/README.nand
index 751b693..084223a 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -94,6 +94,15 @@ Commands:
       of data for one 512-byte page or 2 256-byte pages. There is no check
       for bad blocks.
 
+   nand read.raw addr ofs|partition size
+      Read `size' bytes from `ofs' in NAND flash to `addr'. This reads the raw
+      block, so ECC is avoided and the OOB area is read as well.
+
+   nand write.raw addr ofs|partition size
+      Write `size' bytes from `addr' to `ofs' in NAND flash. This writes the raw
+      block, so ECC is avoided and the OOB area is written as well, making the
+      whole block written as-is.
+
 Configuration Options:
 
    CONFIG_CMD_NAND
-- 
1.7.5.4

[U-Boot] [PATCH 2/5 V2] NAND: Add nand read.raw and write.raw commands

[Scott Wood]

On 09/21/2011 08:55 PM, Marek Vasut wrote:
> These commands should work around various "hardware" ECC and BCH methods.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  common/cmd_nand.c |   19 +++++++++++++++++--
>  doc/README.nand   |    9 +++++++++
>  2 files changed, 26 insertions(+), 2 deletions(-)
> 
> V2: Add documentation.
> 
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 66e06a5..72d418c 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -606,6 +606,20 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
>  				ret = nand->read_oob(nand, off, &ops);
>  			else
>  				ret = nand->write_oob(nand, off, &ops);
> +		} else if (!strcmp(s, ".raw")) {
> +			/* Raw access */
> +			mtd_oob_ops_t ops = {
> +				.datbuf = (u8 *)addr,
> +				.oobbuf = ((u8 *)addr) + nand->writesize,
> +				.len = nand->writesize,
> +				.ooblen = nand->oobsize,
> +				.mode = MTD_OOB_RAW
> +			};
> +
> +			if (read)
> +				ret = nand->read_oob(nand, off, &ops);
> +			else
> +				ret = nand->write_oob(nand, off, &ops);
>  		} else {
>  			printf("Unknown nand command suffix '%s'.\n", s);
>  			return 1;
> @@ -695,10 +709,11 @@ U_BOOT_CMD(
>  	"NAND sub-system",
>  	"info - show available NAND devices\n"
>  	"nand device [dev] - show or set current device\n"
> -	"nand read - addr off|partition size\n"
> -	"nand write - addr off|partition size\n"
> +	"nand read[.raw] - addr off|partition size\n"
> +	"nand write[.raw] - addr off|partition size\n"
>  	"    read/write 'size' bytes starting at offset 'off'\n"
>  	"    to/from memory address 'addr', skipping bad blocks.\n"
> +	"    Use read.raw/write.raw to avoid ECC and write the block as-is.\n"

This says that .raw takes a size parameter, but you assume one page instead.

> diff --git a/doc/README.nand b/doc/README.nand
> index 751b693..084223a 100644
> --- a/doc/README.nand
> +++ b/doc/README.nand
> @@ -94,6 +94,15 @@ Commands:
>        of data for one 512-byte page or 2 256-byte pages. There is no check
>        for bad blocks.
>  
> +   nand read.raw addr ofs|partition size
> +      Read `size' bytes from `ofs' in NAND flash to `addr'. This reads the raw
> +      block, so ECC is avoided and the OOB area is read as well.
> +
> +   nand write.raw addr ofs|partition size
> +      Write `size' bytes from `addr' to `ofs' in NAND flash. This writes the raw
> +      block, so ECC is avoided and the OOB area is written as well, making the
> +      whole block written as-is.

The current implementation reads/writes a page, not a block, and not
'size' bytes.

Should mention that the OOB is expected to immediately follow the main
area in memory.

-Scott

[U-Boot] [PATCH 2/5 V3] NAND: Add nand read.raw and write.raw commands

[Marek Vasut]

These commands should work around various "hardware" ECC and BCH methods.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |   21 +++++++++++++++++++--
 doc/README.nand   |    9 +++++++++
 2 files changed, 28 insertions(+), 2 deletions(-)

V2: Add documentation.
V3: Drop size param.

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 66e06a5..92b6280 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -606,6 +606,22 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 				ret = nand->read_oob(nand, off, &ops);
 			else
 				ret = nand->write_oob(nand, off, &ops);
+		} else if (!strcmp(s, ".raw")) {
+			/* Raw access */
+			mtd_oob_ops_t ops = {
+				.datbuf = (u8 *)addr,
+				.oobbuf = ((u8 *)addr) + nand->writesize,
+				.len = nand->writesize,
+				.ooblen = nand->oobsize,
+				.mode = MTD_OOB_RAW
+			};
+
+			rwsize = nand->writesize + nand->oobsize;
+
+			if (read)
+				ret = nand->read_oob(nand, off, &ops);
+			else
+				ret = nand->write_oob(nand, off, &ops);
 		} else {
 			printf("Unknown nand command suffix '%s'.\n", s);
 			return 1;
@@ -695,10 +711,11 @@ U_BOOT_CMD(
 	"NAND sub-system",
 	"info - show available NAND devices\n"
 	"nand device [dev] - show or set current device\n"
-	"nand read - addr off|partition size\n"
-	"nand write - addr off|partition size\n"
+	"nand read[.raw] - addr off|partition\n"
+	"nand write[.raw] - addr off|partition\n"
 	"    read/write 'size' bytes starting at offset 'off'\n"
 	"    to/from memory address 'addr', skipping bad blocks.\n"
+	"    Use read.raw/write.raw to avoid ECC and write the block as-is.\n"
 #ifdef CONFIG_CMD_NAND_TRIMFFS
 	"nand write.trimffs - addr off|partition size\n"
 	"    write 'size' bytes starting at offset 'off' from memory address\n"
diff --git a/doc/README.nand b/doc/README.nand
index 751b693..62c077e 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -94,6 +94,15 @@ Commands:
       of data for one 512-byte page or 2 256-byte pages. There is no check
       for bad blocks.
 
+   nand read.raw addr ofs|partition
+      Read block from `ofs' in NAND flash to `addr'. This reads the raw block,
+      so ECC is avoided and the OOB area is read as well.
+
+   nand write.raw addr ofs|partition
+      Write block from `addr' to `ofs' in NAND flash. This writes the raw block,
+      so ECC is avoided and the OOB area is written as well, making the whole
+      block written as-is.
+
 Configuration Options:
 
    CONFIG_CMD_NAND
-- 
1.7.5.4

[U-Boot] [PATCH 2/5 V3] NAND: Add nand read.raw and write.raw commands

[Scott Wood]

On 09/22/2011 01:36 PM, Marek Vasut wrote:
> @@ -695,10 +711,11 @@ U_BOOT_CMD(
>  	"NAND sub-system",
>  	"info - show available NAND devices\n"
>  	"nand device [dev] - show or set current device\n"
> -	"nand read - addr off|partition size\n"
> -	"nand write - addr off|partition size\n"
> +	"nand read[.raw] - addr off|partition\n"
> +	"nand write[.raw] - addr off|partition\n"
>  	"    read/write 'size' bytes starting at offset 'off'\n"
>  	"    to/from memory address 'addr', skipping bad blocks.\n"
> +	"    Use read.raw/write.raw to avoid ECC and write the block as-is.\n"

Only the .raw version lacks size -- please do not remove it from the
help text for the normal read/write.

> diff --git a/doc/README.nand b/doc/README.nand
> index 751b693..62c077e 100644
> --- a/doc/README.nand
> +++ b/doc/README.nand
> @@ -94,6 +94,15 @@ Commands:
>        of data for one 512-byte page or 2 256-byte pages. There is no check
>        for bad blocks.
>  
> +   nand read.raw addr ofs|partition
> +      Read block from `ofs' in NAND flash to `addr'. This reads the raw block,
> +      so ECC is avoided and the OOB area is read as well.
> +
> +   nand write.raw addr ofs|partition
> +      Write block from `addr' to `ofs' in NAND flash. This writes the raw block,
> +      so ECC is avoided and the OOB area is written as well, making the whole
> +      block written as-is.

Again, it's operating on a page, not a block.

-Scott

[U-Boot] [PATCH 2/5 V4] NAND: Add nand read.raw and write.raw commands

[Marek Vasut]

These commands should work around various "hardware" ECC and BCH methods.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |   19 +++++++++++++++++++
 doc/README.nand   |    9 +++++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

V2: Add documentation.
V3: Drop size param.
V4: Dont drop size of read/write commands, operate on pages

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 66e06a5..14c7c09 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -606,6 +606,22 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 				ret = nand->read_oob(nand, off, &ops);
 			else
 				ret = nand->write_oob(nand, off, &ops);
+		} else if (!strcmp(s, ".raw")) {
+			/* Raw access */
+			mtd_oob_ops_t ops = {
+				.datbuf = (u8 *)addr,
+				.oobbuf = ((u8 *)addr) + nand->writesize,
+				.len = nand->writesize,
+				.ooblen = nand->oobsize,
+				.mode = MTD_OOB_RAW
+			};
+
+			rwsize = nand->writesize + nand->oobsize;
+
+			if (read)
+				ret = nand->read_oob(nand, off, &ops);
+			else
+				ret = nand->write_oob(nand, off, &ops);
 		} else {
 			printf("Unknown nand command suffix '%s'.\n", s);
 			return 1;
@@ -699,6 +715,9 @@ U_BOOT_CMD(
 	"nand write - addr off|partition size\n"
 	"    read/write 'size' bytes starting at offset 'off'\n"
 	"    to/from memory address 'addr', skipping bad blocks.\n"
+	"nand read.raw - addr off|partition\n"
+	"nand write.raw - addr off|partition\n"
+	"    Use read.raw/write.raw to avoid ECC and write the page as-is.\n"
 #ifdef CONFIG_CMD_NAND_TRIMFFS
 	"nand write.trimffs - addr off|partition size\n"
 	"    write 'size' bytes starting at offset 'off' from memory address\n"
diff --git a/doc/README.nand b/doc/README.nand
index 751b693..023740e 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -94,6 +94,15 @@ Commands:
       of data for one 512-byte page or 2 256-byte pages. There is no check
       for bad blocks.
 
+   nand read.raw addr ofs|partition
+      Read page from `ofs' in NAND flash to `addr'. This reads the raw page,
+      so ECC is avoided and the OOB area is read as well.
+
+   nand write.raw addr ofs|partition
+      Write page from `addr' to `ofs' in NAND flash. This writes the raw page,
+      so ECC is avoided and the OOB area is written as well, making the whole
+      page written as-is.
+
 Configuration Options:
 
    CONFIG_CMD_NAND
-- 
1.7.5.4

[U-Boot] [PATCH 2/5 V4] NAND: Add nand read.raw and write.raw commands

[Scott Wood]

On Fri, Sep 23, 2011 at 03:43:10PM +0200, Marek Vasut wrote:
> These commands should work around various "hardware" ECC and BCH methods.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  common/cmd_nand.c |   19 +++++++++++++++++++
>  doc/README.nand   |    9 +++++++++
>  2 files changed, 28 insertions(+), 0 deletions(-)
> 
> V2: Add documentation.
> V3: Drop size param.
> V4: Dont drop size of read/write commands, operate on pages

Applied to u-boot-nand-flash next

> +	"nand read.raw - addr off|partition\n"
> +	"nand write.raw - addr off|partition\n"
> +	"    Use read.raw/write.raw to avoid ECC and write the page as-is.\n"

...with s/write the page/access the page/

-Scott

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Marek Vasut]

Don't allocate NAND buffers as one block, but allocate them separately. This
allows systems where DMA to buffers happen to allocate these buffers properly
aligned.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 drivers/mtd/nand/nand_base.c |   30 +++++++++++++++++++++++-------
 include/linux/mtd/nand.h     |    7 ++++---
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index d8d30e3..3093067 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2749,13 +2749,27 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
  */
 int nand_scan_tail(struct mtd_info *mtd)
 {
-	int i;
+	int i, bufsize;
+	uint8_t *buf;
 	struct nand_chip *chip = mtd->priv;
 
-	if (!(chip->options & NAND_OWN_BUFFERS))
-		chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL);
-	if (!chip->buffers)
-		return -ENOMEM;
+	if (!(chip->options & NAND_OWN_BUFFERS)) {
+		chip->buffers = malloc(sizeof(struct nand_buffers));
+		if (!chip->buffers)
+			return -ENOMEM;
+
+		bufsize = NAND_MAX_PAGESIZE + (3 * NAND_MAX_OOBSIZE);
+		buf = malloc(bufsize);
+		if (!buf) {
+			free(chip->buffers);
+			return -ENOMEM;
+		}
+
+		chip->buffers->buffer = buf;
+		chip->buffers->ecccalc = buf;
+		chip->buffers->ecccode = buf + NAND_MAX_OOBSIZE;
+		chip->buffers->databuf = buf + (2 * NAND_MAX_OOBSIZE);
+	}
 
 	/* Set the internal oob buffer location, just after the page data */
 	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
@@ -2996,6 +3010,8 @@ void nand_release(struct mtd_info *mtd)
 
 	/* Free bad block table memory */
 	kfree(chip->bbt);
-	if (!(chip->options & NAND_OWN_BUFFERS))
-		kfree(chip->buffers);
+	if (!(chip->options & NAND_OWN_BUFFERS)) {
+		free(chip->buffers->buffer);
+		free(chip->buffers);
+	}
 }
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 987a2ec..c3449a9 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -370,9 +370,10 @@ struct nand_ecc_ctrl {
  * consecutive order.
  */
 struct nand_buffers {
-	uint8_t	ecccalc[NAND_MAX_OOBSIZE];
-	uint8_t	ecccode[NAND_MAX_OOBSIZE];
-	uint8_t databuf[NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE];
+	uint8_t *buffer;
+	uint8_t	*ecccalc;
+	uint8_t	*ecccode;
+	uint8_t *databuf;
 };
 
 /**
-- 
1.7.5.4

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Scott Wood]

On 09/11/2011 11:04 PM, Marek Vasut wrote:
> Don't allocate NAND buffers as one block, but allocate them separately. This
> allows systems where DMA to buffers happen to allocate these buffers properly
> aligned.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  drivers/mtd/nand/nand_base.c |   30 +++++++++++++++++++++++-------
>  include/linux/mtd/nand.h     |    7 ++++---
>  2 files changed, 27 insertions(+), 10 deletions(-)

Is this hardware going to be supported in Linux?  It would be nice if we
could keep this code in sync.

-Scott

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Wolfgang Denk]

Dear Scott Wood,

In message <4E7A320D.1030002@freescale.com> you wrote:
>
> Is this hardware going to be supported in Linux?  It would be nice if we
> could keep this code in sync.

Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
so yes, this hardware going to be supported in mainline Linux, too.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mr. Cole's Axiom:
        The sum of the intelligence on the planet is a constant;
        the population is growing.

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Scott Wood]

On 09/21/2011 02:49 PM, Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <4E7A320D.1030002@freescale.com> you wrote:
>>
>> Is this hardware going to be supported in Linux?  It would be nice if we
>> could keep this code in sync.
> 
> Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
> so yes, this hardware going to be supported in mainline Linux, too.
> 
> Best regards,
> 
> Wolfgang Denk
> 

How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?

I'd like to see this change be submitted to Linux first, or else have an
explanation of why a divergence for U-Boot is warranted.

-Scott

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Wolfgang Denk]

Dear Stefano & Marek,

can you please provide the requested information?


In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
>
> > In message <4E7A320D.1030002@freescale.com> you wrote:
> >>
> >> Is this hardware going to be supported in Linux?  It would be nice if we
> >> could keep this code in sync.
> > 
> > Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
> > so yes, this hardware going to be supported in mainline Linux, too.
> 
> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
> 
> I'd like to see this change be submitted to Linux first, or else have an
> explanation of why a divergence for U-Boot is warranted.


Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Without facts, the decision cannot be made logically. You  must  rely
on your human intuition.
	-- Spock, "Assignment: Earth", stardate unknown

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Marek Vasut]

On Wednesday, September 21, 2011 10:16:35 PM Wolfgang Denk wrote:
> Dear Stefano & Marek,
> 
> can you please provide the requested information?
> 
> In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
> > > In message <4E7A320D.1030002@freescale.com> you wrote:
> > >> Is this hardware going to be supported in Linux?  It would be nice if
> > >> we could keep this code in sync.
> > > 
> > > Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
> > > so yes, this hardware going to be supported in mainline Linux, too.
> > 
> > How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
> > 
> > I'd like to see this change be submitted to Linux first, or else have an
> > explanation of why a divergence for U-Boot is warranted.
> 
> Thanks.
> 
> Wolfgang Denk

This patch is actually optional and right now isn't used by M28. Though someone 
might find this helpful.

Cheers

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Stefano Babic]

On 09/21/2011 10:16 PM, Wolfgang Denk wrote:
> Dear Stefano & Marek,
> 
> can you please provide the requested information?
> 
> 

Hi Scott,

> In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
>>
>>> In message <4E7A320D.1030002@freescale.com> you wrote:
>>>>
>>>> Is this hardware going to be supported in Linux?  It would be nice if we
>>>> could keep this code in sync.
>>>
>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
>>> so yes, this hardware going to be supported in mainline Linux, too.
>>
>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
>>
>> I'd like to see this change be submitted to Linux first, or else have an
>> explanation of why a divergence for U-Boot is warranted.

I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije:

	http://www.spinics.net/lists/arm-kernel/msg139526.html

However, I have not seen the option NAND_OWN_BUFFERS in his patches.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Marek Vasut]

On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote:
> On 09/21/2011 10:16 PM, Wolfgang Denk wrote:
> > Dear Stefano & Marek,
> > 
> > can you please provide the requested information?
> 
> Hi Scott,
> 
> > In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
> >>> In message <4E7A320D.1030002@freescale.com> you wrote:
> >>>> Is this hardware going to be supported in Linux?  It would be nice if
> >>>> we could keep this code in sync.
> >>> 
> >>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
> >>> so yes, this hardware going to be supported in mainline Linux, too.
> >> 
> >> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
> >> 
> >> I'd like to see this change be submitted to Linux first, or else have an
> >> explanation of why a divergence for U-Boot is warranted.
> 
> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije:
> 
> 	http://www.spinics.net/lists/arm-kernel/msg139526.html
> 
> However, I have not seen the option NAND_OWN_BUFFERS in his patches.
> 
> Best regards,
> Stefano

Like I said, this patch is not needed anymore. It's just a convenience measure 
now. I don't need to for mx28.

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Scott Wood]

On 09/22/2011 03:51 AM, Marek Vasut wrote:
> On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote:
>> On 09/21/2011 10:16 PM, Wolfgang Denk wrote:
>>> Dear Stefano & Marek,
>>>
>>> can you please provide the requested information?
>>
>> Hi Scott,
>>
>>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
>>>>> In message <4E7A320D.1030002@freescale.com> you wrote:
>>>>>> Is this hardware going to be supported in Linux?  It would be nice if
>>>>>> we could keep this code in sync.
>>>>>
>>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
>>>>> so yes, this hardware going to be supported in mainline Linux, too.
>>>>
>>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
>>>>
>>>> I'd like to see this change be submitted to Linux first, or else have an
>>>> explanation of why a divergence for U-Boot is warranted.
>>
>> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije:
>>
>> 	http://www.spinics.net/lists/arm-kernel/msg139526.html
>>
>> However, I have not seen the option NAND_OWN_BUFFERS in his patches.
>>
>> Best regards,
>> Stefano
> 
> Like I said, this patch is not needed anymore. It's just a convenience measure 
> now. I don't need to for mx28.
> 

Let's hold off on this patch until it's actually needed, then.

-Scott

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Marek Vasut]

On Friday, September 23, 2011 07:35:15 PM Scott Wood wrote:
> On 09/22/2011 03:51 AM, Marek Vasut wrote:
> > On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote:
> >> On 09/21/2011 10:16 PM, Wolfgang Denk wrote:
> >>> Dear Stefano & Marek,
> >>> 
> >>> can you please provide the requested information?
> >> 
> >> Hi Scott,
> >> 
> >>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
> >>>>> In message <4E7A320D.1030002@freescale.com> you wrote:
> >>>>>> Is this hardware going to be supported in Linux?  It would be nice
> >>>>>> if we could keep this code in sync.
> >>>>> 
> >>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
> >>>>> so yes, this hardware going to be supported in mainline Linux, too.
> >>>> 
> >>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
> >>>> 
> >>>> I'd like to see this change be submitted to Linux first, or else have
> >>>> an explanation of why a divergence for U-Boot is warranted.
> >> 
> >> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije:
> >> 	http://www.spinics.net/lists/arm-kernel/msg139526.html
> >> 
> >> However, I have not seen the option NAND_OWN_BUFFERS in his patches.
> >> 
> >> Best regards,
> >> Stefano
> > 
> > Like I said, this patch is not needed anymore. It's just a convenience
> > measure now. I don't need to for mx28.
> 
> Let's hold off on this patch until it's actually needed, then.

Very well then, mind merging the rest then ?

Cheers
> 
> -Scott

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Scott Wood]

On 09/24/2011 07:37 AM, Marek Vasut wrote:
> On Friday, September 23, 2011 07:35:15 PM Scott Wood wrote:
>> On 09/22/2011 03:51 AM, Marek Vasut wrote:
>>> On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote:
>>>> On 09/21/2011 10:16 PM, Wolfgang Denk wrote:
>>>>> Dear Stefano & Marek,
>>>>>
>>>>> can you please provide the requested information?
>>>>
>>>> Hi Scott,
>>>>
>>>>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
>>>>>>> In message <4E7A320D.1030002@freescale.com> you wrote:
>>>>>>>> Is this hardware going to be supported in Linux?  It would be nice
>>>>>>>> if we could keep this code in sync.
>>>>>>>
>>>>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
>>>>>>> so yes, this hardware going to be supported in mainline Linux, too.
>>>>>>
>>>>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
>>>>>>
>>>>>> I'd like to see this change be submitted to Linux first, or else have
>>>>>> an explanation of why a divergence for U-Boot is warranted.
>>>>
>>>> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije:
>>>> 	http://www.spinics.net/lists/arm-kernel/msg139526.html
>>>>
>>>> However, I have not seen the option NAND_OWN_BUFFERS in his patches.
>>>>
>>>> Best regards,
>>>> Stefano
>>>
>>> Like I said, this patch is not needed anymore. It's just a convenience
>>> measure now. I don't need to for mx28.
>>
>> Let's hold off on this patch until it's actually needed, then.
> 
> Very well then, mind merging the rest then ?

Yes, I'll try to get to it soon.

-Scott

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Marek Vasut]

On Monday, September 26, 2011 08:33:56 PM Scott Wood wrote:
> On 09/24/2011 07:37 AM, Marek Vasut wrote:
> > On Friday, September 23, 2011 07:35:15 PM Scott Wood wrote:
> >> On 09/22/2011 03:51 AM, Marek Vasut wrote:
> >>> On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote:
> >>>> On 09/21/2011 10:16 PM, Wolfgang Denk wrote:
> >>>>> Dear Stefano & Marek,
> >>>>> 
> >>>>> can you please provide the requested information?
> >>>> 
> >>>> Hi Scott,
> >>>> 
> >>>>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote:
> >>>>>>> In message <4E7A320D.1030002@freescale.com> you wrote:
> >>>>>>>> Is this hardware going to be supported in Linux?  It would be nice
> >>>>>>>> if we could keep this code in sync.
> >>>>>>> 
> >>>>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK
> >>>>>>> board, so yes, this hardware going to be supported in mainline
> >>>>>>> Linux, too.
> >>>>>> 
> >>>>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
> >>>>>> 
> >>>>>> I'd like to see this change be submitted to Linux first, or else
> >>>>>> have an explanation of why a divergence for U-Boot is warranted.
> >>>> 
> >>>> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang 
Shije:
> >>>> 	http://www.spinics.net/lists/arm-kernel/msg139526.html
> >>>> 
> >>>> However, I have not seen the option NAND_OWN_BUFFERS in his patches.
> >>>> 
> >>>> Best regards,
> >>>> Stefano
> >>> 
> >>> Like I said, this patch is not needed anymore. It's just a convenience
> >>> measure now. I don't need to for mx28.
> >> 
> >> Let's hold off on this patch until it's actually needed, then.
> > 
> > Very well then, mind merging the rest then ?
> 
> Yes, I'll try to get to it soon.

Thanks Scott, and thanks for your patience while reviewing, I know I had my 
moments where I wasn't too nice / was whiny ;-)

Cheers
> 
> -Scott

[U-Boot] [PATCH 4/5] NAND: Make page, erase, oob size available via cmd_nand

[Marek Vasut]

The "nand info" and "nand device" now set shell/environment variables:
	nand_writesize ... nand page size
	nand_oobsize ..... nand oob area size
	nand_erasesize ... nand erase block size

The shell variables are only set if HUSH is enabled.

Also, the "nand info" command now displays this info.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |   42 +++++++++++++++++++++++++++++++++++++++---
 1 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index a1c8dfd..5b7e83d 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -27,6 +27,9 @@
 #include <asm/byteorder.h>
 #include <jffs2/jffs2.h>
 #include <nand.h>
+#ifdef	CONFIG_SYS_HUSH_PARSER
+#include <hush.h>
+#endif
 
 #if defined(CONFIG_CMD_MTDPARTS)
 
@@ -362,15 +365,48 @@ usage:
 
 #endif
 
-static void nand_print_info(int idx)
+static void nand_print_and_set_info(int idx)
 {
 	nand_info_t *nand = &nand_info[idx];
 	struct nand_chip *chip = nand->priv;
+	const int bufsz = 32;
+	char buf[bufsz];
+
 	printf("Device %d: ", idx);
 	if (chip->numchips > 1)
 		printf("%dx ", chip->numchips);
 	printf("%s, sector size %u KiB\n",
 	       nand->name, nand->erasesize >> 10);
+	printf("  Page size  %8d b\n", nand->writesize);
+	printf("  OOB size   %8d b\n", nand->oobsize);
+	printf("  Erase size %8d b\n", nand->erasesize);
+
+	/* Set geometry info */
+#ifdef	CONFIG_SYS_HUSH_PARSER
+	memset(buf, 0, bufsz);
+	sprintf(buf, "nand_writesize=%x", nand->writesize);
+	set_local_var(buf, 0);
+
+	memset(buf, 0, bufsz);
+	sprintf(buf, "nand_oobsize=%x", nand->oobsize);
+	set_local_var(buf, 0);
+
+	memset(buf, 0, bufsz);
+	sprintf(buf, "nand_erasesize=%x", nand->erasesize);
+	set_local_var(buf, 0);
+#else
+	memset(buf, 0, bufsz);
+	sprintf(buf, "%x", nand->writesize);
+	setenv("nand_writesize", buf);
+
+	memset(buf, 0, bufsz);
+	sprintf(buf, "%x", nand->oobsize);
+	setenv("nand_oobsize", buf);
+
+	memset(buf, 0, bufsz);
+	sprintf(buf, "%x", nand->erasesize);
+	setenv("nand_erasesize", buf);
+#endif
 }
 
 int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
@@ -407,7 +443,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 		putc('\n');
 		for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
 			if (nand_info[i].name)
-				nand_print_info(i);
+				nand_print_and_set_info(i);
 		}
 		return 0;
 	}
@@ -418,7 +454,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 			if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE)
 				puts("no devices available\n");
 			else
-				nand_print_info(dev);
+				nand_print_and_set_info(dev);
 			return 0;
 		}
 
-- 
1.7.5.4

[U-Boot] [PATCH 4/5] NAND: Make page, erase, oob size available via cmd_nand

[Scott Wood]

On 09/11/2011 11:04 PM, Marek Vasut wrote:
> The "nand info" and "nand device" now set shell/environment variables:
> 	nand_writesize ... nand page size
> 	nand_oobsize ..... nand oob area size
> 	nand_erasesize ... nand erase block size
> 
> The shell variables are only set if HUSH is enabled.
> 
> Also, the "nand info" command now displays this info.

"writesize" is what the internals use for this, but nand_pagesize would
be more obvious.

> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  common/cmd_nand.c |   42 +++++++++++++++++++++++++++++++++++++++---
>  1 files changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index a1c8dfd..5b7e83d 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -27,6 +27,9 @@
>  #include <asm/byteorder.h>
>  #include <jffs2/jffs2.h>
>  #include <nand.h>
> +#ifdef	CONFIG_SYS_HUSH_PARSER
> +#include <hush.h>
> +#endif

I don't think you need this ifdef.

> +	/* Set geometry info */
> +#ifdef	CONFIG_SYS_HUSH_PARSER
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "nand_writesize=%x", nand->writesize);
> +	set_local_var(buf, 0);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "nand_oobsize=%x", nand->oobsize);
> +	set_local_var(buf, 0);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "nand_erasesize=%x", nand->erasesize);
> +	set_local_var(buf, 0);
> +#else
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->writesize);
> +	setenv("nand_writesize", buf);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->oobsize);
> +	setenv("nand_oobsize", buf);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->erasesize);
> +	setenv("nand_erasesize", buf);
> +#endif

Is there no existing abstraction to add a variable to both the shell (if
present) and the environment, without needing such an ifdef in the
caller?  If not, should one be added?

-Scott

[U-Boot] [PATCH 4/5] NAND: Make page, erase, oob size available via cmd_nand

[Wolfgang Denk]

Dear Scott Wood,

In message <4E7A332C.5000705@freescale.com> you wrote:
>
> > +#ifdef	CONFIG_SYS_HUSH_PARSER
> > +#include <hush.h>
> > +#endif
> 
> I don't think you need this ifdef.

It should be omitted alltogether.

> > +#ifdef	CONFIG_SYS_HUSH_PARSER
> > +	memset(buf, 0, bufsz);
> > +	sprintf(buf, "nand_writesize=%x", nand->writesize);
> > +	set_local_var(buf, 0);
...
> 
> Is there no existing abstraction to add a variable to both the shell (if
> present) and the environment, without needing such an ifdef in the
> caller?  If not, should one be added?

While it's a good idea to keep such dynamic variables out of the
(persistently stored) environment, I don't want to see such a solitary
approach.  If we start thinking about this it should be implemented
differently, and for all dynamic variables (including things like
filesize etc.).


Marek, please get rid of the hush special case and always use plain
env variables like we do elsewhere, too.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He was so narrow minded he could see through  a  keyhole  with  both
eyes ..."

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Marek Vasut]

The "nand info" and "nand device" now set shell/environment variables:
	nand_writesize ... nand page size
	nand_oobsize ..... nand oob area size
	nand_erasesize ... nand erase block size

Also, the "nand info" command now displays this info.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |   25 ++++++++++++++++++++++---
 1 files changed, 22 insertions(+), 3 deletions(-)

V2: Remove setup of HUSH local vars.

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 72d418c..2f8723f 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -362,15 +362,34 @@ usage:
 
 #endif
 
-static void nand_print_info(int idx)
+static void nand_print_and_set_info(int idx)
 {
 	nand_info_t *nand = &nand_info[idx];
 	struct nand_chip *chip = nand->priv;
+	const int bufsz = 32;
+	char buf[bufsz];
+
 	printf("Device %d: ", idx);
 	if (chip->numchips > 1)
 		printf("%dx ", chip->numchips);
 	printf("%s, sector size %u KiB\n",
 	       nand->name, nand->erasesize >> 10);
+	printf("  Page size  %8d b\n", nand->writesize);
+	printf("  OOB size   %8d b\n", nand->oobsize);
+	printf("  Erase size %8d b\n", nand->erasesize);
+
+	/* Set geometry info */
+	memset(buf, 0, bufsz);
+	sprintf(buf, "%x", nand->writesize);
+	setenv("nand_writesize", buf);
+
+	memset(buf, 0, bufsz);
+	sprintf(buf, "%x", nand->oobsize);
+	setenv("nand_oobsize", buf);
+
+	memset(buf, 0, bufsz);
+	sprintf(buf, "%x", nand->erasesize);
+	setenv("nand_erasesize", buf);
 }
 
 int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
@@ -407,7 +426,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 		putc('\n');
 		for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
 			if (nand_info[i].name)
-				nand_print_info(i);
+				nand_print_and_set_info(i);
 		}
 		return 0;
 	}
@@ -418,7 +437,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 			if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE)
 				puts("no devices available\n");
 			else
-				nand_print_info(dev);
+				nand_print_and_set_info(dev);
 			return 0;
 		}
 
-- 
1.7.5.4

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Scott Wood]

On Thu, Sep 22, 2011 at 03:57:26AM +0200, Marek Vasut wrote:
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 72d418c..2f8723f 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -362,15 +362,34 @@ usage:
>  
>  #endif
>  
> -static void nand_print_info(int idx)
> +static void nand_print_and_set_info(int idx)
>  {
>  	nand_info_t *nand = &nand_info[idx];
>  	struct nand_chip *chip = nand->priv;
> +	const int bufsz = 32;
> +	char buf[bufsz];
> +
>  	printf("Device %d: ", idx);
>  	if (chip->numchips > 1)
>  		printf("%dx ", chip->numchips);
>  	printf("%s, sector size %u KiB\n",
>  	       nand->name, nand->erasesize >> 10);
> +	printf("  Page size  %8d b\n", nand->writesize);
> +	printf("  OOB size   %8d b\n", nand->oobsize);
> +	printf("  Erase size %8d b\n", nand->erasesize);
> +
> +	/* Set geometry info */
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->writesize);
> +	setenv("nand_writesize", buf);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->oobsize);
> +	setenv("nand_oobsize", buf);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->erasesize);
> +	setenv("nand_erasesize", buf);

Why the memsets?

-Scott

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Marek Vasut]

On Tuesday, September 27, 2011 09:01:53 PM Scott Wood wrote:
> On Thu, Sep 22, 2011 at 03:57:26AM +0200, Marek Vasut wrote:
> > diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> > index 72d418c..2f8723f 100644
> > --- a/common/cmd_nand.c
> > +++ b/common/cmd_nand.c
> > 
> > @@ -362,15 +362,34 @@ usage:
> >  #endif
> > 
> > -static void nand_print_info(int idx)
> > +static void nand_print_and_set_info(int idx)
> > 
> >  {
> >  
> >  	nand_info_t *nand = &nand_info[idx];
> >  	struct nand_chip *chip = nand->priv;
> > 
> > +	const int bufsz = 32;
> > +	char buf[bufsz];
> > +
> > 
> >  	printf("Device %d: ", idx);
> >  	if (chip->numchips > 1)
> >  	
> >  		printf("%dx ", chip->numchips);
> >  	
> >  	printf("%s, sector size %u KiB\n",
> >  	
> >  	       nand->name, nand->erasesize >> 10);
> > 
> > +	printf("  Page size  %8d b\n", nand->writesize);
> > +	printf("  OOB size   %8d b\n", nand->oobsize);
> > +	printf("  Erase size %8d b\n", nand->erasesize);
> > +
> > +	/* Set geometry info */
> > +	memset(buf, 0, bufsz);
> > +	sprintf(buf, "%x", nand->writesize);
> > +	setenv("nand_writesize", buf);
> > +
> > +	memset(buf, 0, bufsz);
> > +	sprintf(buf, "%x", nand->oobsize);
> > +	setenv("nand_oobsize", buf);
> > +
> > +	memset(buf, 0, bufsz);
> > +	sprintf(buf, "%x", nand->erasesize);
> > +	setenv("nand_erasesize", buf);
> 
> Why the memsets?

To clear the memory from previous usage ?

> 
> -Scott

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Scott Wood]

On 09/27/2011 02:38 PM, Marek Vasut wrote:
> On Tuesday, September 27, 2011 09:01:53 PM Scott Wood wrote:
>> On Thu, Sep 22, 2011 at 03:57:26AM +0200, Marek Vasut wrote:
>>> +	/* Set geometry info */
>>> +	memset(buf, 0, bufsz);
>>> +	sprintf(buf, "%x", nand->writesize);
>>> +	setenv("nand_writesize", buf);
>>> +
>>> +	memset(buf, 0, bufsz);
>>> +	sprintf(buf, "%x", nand->oobsize);
>>> +	setenv("nand_oobsize", buf);
>>> +
>>> +	memset(buf, 0, bufsz);
>>> +	sprintf(buf, "%x", nand->erasesize);
>>> +	setenv("nand_erasesize", buf);
>>
>> Why the memsets?
> 
> To clear the memory from previous usage ?

What part of the previous usage will both survive the sprintf() and be
looked at by setenv()?

-Scott

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Marek Vasut]

On Tuesday, September 27, 2011 09:51:09 PM Scott Wood wrote:
> On 09/27/2011 02:38 PM, Marek Vasut wrote:
> > On Tuesday, September 27, 2011 09:01:53 PM Scott Wood wrote:
> >> On Thu, Sep 22, 2011 at 03:57:26AM +0200, Marek Vasut wrote:
> >>> +	/* Set geometry info */
> >>> +	memset(buf, 0, bufsz);
> >>> +	sprintf(buf, "%x", nand->writesize);
> >>> +	setenv("nand_writesize", buf);
> >>> +
> >>> +	memset(buf, 0, bufsz);
> >>> +	sprintf(buf, "%x", nand->oobsize);
> >>> +	setenv("nand_oobsize", buf);
> >>> +
> >>> +	memset(buf, 0, bufsz);
> >>> +	sprintf(buf, "%x", nand->erasesize);
> >>> +	setenv("nand_erasesize", buf);
> >> 
> >> Why the memsets?
> > 
> > To clear the memory from previous usage ?
> 
> What part of the previous usage will both survive the sprintf() and be
> looked at by setenv()?

The part of data that are copied in _do_set_env() ?

> 
> -Scott

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Scott Wood]

On 09/27/2011 03:07 PM, Marek Vasut wrote:
> On Tuesday, September 27, 2011 09:51:09 PM Scott Wood wrote:
>> On 09/27/2011 02:38 PM, Marek Vasut wrote:
>>> On Tuesday, September 27, 2011 09:01:53 PM Scott Wood wrote:
>>>> On Thu, Sep 22, 2011 at 03:57:26AM +0200, Marek Vasut wrote:
>>>>> +	/* Set geometry info */
>>>>> +	memset(buf, 0, bufsz);
>>>>> +	sprintf(buf, "%x", nand->writesize);
>>>>> +	setenv("nand_writesize", buf);
>>>>> +
>>>>> +	memset(buf, 0, bufsz);
>>>>> +	sprintf(buf, "%x", nand->oobsize);
>>>>> +	setenv("nand_oobsize", buf);
>>>>> +
>>>>> +	memset(buf, 0, bufsz);
>>>>> +	sprintf(buf, "%x", nand->erasesize);
>>>>> +	setenv("nand_erasesize", buf);
>>>>
>>>> Why the memsets?
>>>
>>> To clear the memory from previous usage ?
>>
>> What part of the previous usage will both survive the sprintf() and be
>> looked at by setenv()?
> 
> The part of data that are copied in _do_set_env() ?

I don't see _do_set_env anywhere -- what tree are you looking at?

In any case, sprintf() produces a zero-terminated string.  setenv()
consumes a zero-terminated string.  setenv() doesn't even know that the
buffer containing the string happens to be 32 bytes, much less have any
business poking around in that area.

-Scott

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Marek Vasut]

On Tuesday, September 27, 2011 10:53:56 PM Scott Wood wrote:
> On 09/27/2011 03:07 PM, Marek Vasut wrote:
> > On Tuesday, September 27, 2011 09:51:09 PM Scott Wood wrote:
> >> On 09/27/2011 02:38 PM, Marek Vasut wrote:
> >>> On Tuesday, September 27, 2011 09:01:53 PM Scott Wood wrote:
> >>>> On Thu, Sep 22, 2011 at 03:57:26AM +0200, Marek Vasut wrote:
> >>>>> +	/* Set geometry info */
> >>>>> +	memset(buf, 0, bufsz);
> >>>>> +	sprintf(buf, "%x", nand->writesize);
> >>>>> +	setenv("nand_writesize", buf);
> >>>>> +
> >>>>> +	memset(buf, 0, bufsz);
> >>>>> +	sprintf(buf, "%x", nand->oobsize);
> >>>>> +	setenv("nand_oobsize", buf);
> >>>>> +
> >>>>> +	memset(buf, 0, bufsz);
> >>>>> +	sprintf(buf, "%x", nand->erasesize);
> >>>>> +	setenv("nand_erasesize", buf);
> >>>> 
> >>>> Why the memsets?
> >>> 
> >>> To clear the memory from previous usage ?
> >> 
> >> What part of the previous usage will both survive the sprintf() and be
> >> looked at by setenv()?
> > 
> > The part of data that are copied in _do_set_env() ?
> 
> I don't see _do_set_env anywhere -- what tree are you looking at?
> 
> In any case, sprintf() produces a zero-terminated string.  setenv()
> consumes a zero-terminated string.

Correct

> setenv() doesn't even know that the
> buffer containing the string happens to be 32 bytes, much less have any
> business poking around in that area.

True ... but the stuff you call setenv() on is copied to environment. That's 
about it, it doesn't get lost anywhere.

[U-Boot] [PATCH 4/5 V2] NAND: Make page, erase, oob size available via cmd_nand

[Scott Wood]

On Thu, Sep 22, 2011 at 03:57:26AM +0200, Marek Vasut wrote:
> The "nand info" and "nand device" now set shell/environment variables:
> 	nand_writesize ... nand page size
> 	nand_oobsize ..... nand oob area size
> 	nand_erasesize ... nand erase block size
> 
> Also, the "nand info" command now displays this info.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  common/cmd_nand.c |   25 ++++++++++++++++++++++---
>  1 files changed, 22 insertions(+), 3 deletions(-)
> 

Applied to u-boot-nand-flash next

> +	/* Set geometry info */
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->writesize);
> +	setenv("nand_writesize", buf);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->oobsize);
> +	setenv("nand_oobsize", buf);
> +
> +	memset(buf, 0, bufsz);
> +	sprintf(buf, "%x", nand->erasesize);
> +	setenv("nand_erasesize", buf);

...with memsets removed.

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

This allows the scrub command to scrub without asking the user if he really
wants to scrub the area. Useful in scripts.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 5b7e83d..6d66e5d 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -502,6 +502,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 		int clean = argc > 2 && !strcmp("clean", argv[2]);
 		int o = clean ? 3 : 2;
 		int scrub = !strncmp(cmd, "scrub", 5);
+		int scrub_quiet;
 		int part = 0;
 		int chip = 0;
 		int spread = 0;
@@ -516,6 +517,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 			} else if (!strcmp(&cmd[5], ".chip")) {
 				chip = 1;
 				args = 0;
+			} else if (!strncmp(cmd, "scrub.quiet", 11)) {
+				scrub_quiet = 1;
 			} else {
 				goto usage;
 			}
@@ -543,7 +546,9 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 		opts.quiet  = quiet;
 		opts.spread = spread;
 
-		if (scrub) {
+		if (scrub && scrub_quiet) {
+			opts.scrub = 1;
+		} else if (scrub) {
 			puts("Warning: "
 			     "scrub option will erase all factory set "
 			     "bad blocks!\n"
@@ -569,6 +574,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 				return -1;
 			}
 		}
+
 		ret = nand_erase_opts(nand, &opts);
 		printf("%s\n", ret ? "ERROR" : "OK");
 
-- 
1.7.5.4

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Mike Frysinger]

On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> This allows the scrub command to scrub without asking the user if he really
> wants to scrub the area. Useful in scripts.

"quiet" and "skip user input" are two different things.  can you use a more 
clean option like accepting "-y" to the "scrub" subcommand ?

> @@ -569,6 +574,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char
> * const argv[]) return -1;
>  			}
>  		}
> +
>  		ret = nand_erase_opts(nand, &opts);
>  		printf("%s\n", ret ? "ERROR" : "OK");

unrelated whitespace changes are frowned upon
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110912/d6d9c825/attachment.pgp 

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
> On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> > This allows the scrub command to scrub without asking the user if he
> > really wants to scrub the area. Useful in scripts.
> 
> "quiet" and "skip user input" are two different things.  can you use a more
> clean option like accepting "-y" to the "scrub" subcommand ?

I'd prefer to have this hidden from common users as much as possible.

> 
> > @@ -569,6 +574,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc,
> > char * const argv[]) return -1;
> > 
> >  			}
> >  		
> >  		}
> > 
> > +
> > 
> >  		ret = nand_erase_opts(nand, &opts);
> >  		printf("%s\n", ret ? "ERROR" : "OK");
> 
> unrelated whitespace changes are frowned upon
> -mike

Thanks for finding this.

Cheers

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

On 09/12/2011 12:45 PM, Marek Vasut wrote:
> On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
>> On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
>>> This allows the scrub command to scrub without asking the user if he
>>> really wants to scrub the area. Useful in scripts.
>>
>> "quiet" and "skip user input" are two different things.  can you use a more
>> clean option like accepting "-y" to the "scrub" subcommand ?
> 
> I'd prefer to have this hidden from common users as much as possible.

What's the use case for needing to script this, BTW?

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Monday, September 12, 2011 08:06:27 PM Scott Wood wrote:
> On 09/12/2011 12:45 PM, Marek Vasut wrote:
> > On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
> >> On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> >>> This allows the scrub command to scrub without asking the user if he
> >>> really wants to scrub the area. Useful in scripts.
> >> 
> >> "quiet" and "skip user input" are two different things.  can you use a
> >> more clean option like accepting "-y" to the "scrub" subcommand ?
> > 
> > I'd prefer to have this hidden from common users as much as possible.
> 
> What's the use case for needing to script this, BTW?

Update a block in NAND that's not handled by BCH accelerator in the MX28 chip.

The problem is, block 0 has it's own ECC done by bootrom software. That kind of 
ECC is incompatible with BCH-produced ECC. That's also a reason for needing that 
write.raw command.

Now, if you try erasing that block, the BCH reads and writes some of it's 
metadata there. Obviously, since there is different kind of ECC, the metadata 
aren't there and it chokes, claiming the block is bad and refuses to erase it.

And before you ask why -- that's because the BCH accelerator puts the metadata 
at random places in the block (every 512 bytes, it puts a few bytes of it's ECC) 
instead of putting them only to the ECC area. On the other hand, the bootrom ECC 
puts the whole ECC at offset (1024 + 12) bytes from the start of the block 0.

And finally, we obviously don't want to bother the user by asking "do you really 
want to scrub your nand" in the update process.

Cheers
> 
> -Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

On 09/12/2011 01:24 PM, Marek Vasut wrote:
> On Monday, September 12, 2011 08:06:27 PM Scott Wood wrote:
>> On 09/12/2011 12:45 PM, Marek Vasut wrote:
>>> On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
>>>> On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
>>>>> This allows the scrub command to scrub without asking the user if he
>>>>> really wants to scrub the area. Useful in scripts.
>>>>
>>>> "quiet" and "skip user input" are two different things.  can you use a
>>>> more clean option like accepting "-y" to the "scrub" subcommand ?
>>>
>>> I'd prefer to have this hidden from common users as much as possible.
>>
>> What's the use case for needing to script this, BTW?
> 
> Update a block in NAND that's not handled by BCH accelerator in the MX28 chip.
> 
> The problem is, block 0 has it's own ECC done by bootrom software. That kind of 
> ECC is incompatible with BCH-produced ECC. That's also a reason for needing that 
> write.raw command.
> 
> Now, if you try erasing that block, the BCH reads and writes some of it's 
> metadata there. Obviously, since there is different kind of ECC, the metadata 
> aren't there and it chokes, claiming the block is bad and refuses to erase it.
> 
> And before you ask why -- that's because the BCH accelerator puts the metadata 
> at random places in the block (every 512 bytes, it puts a few bytes of it's ECC) 
> instead of putting them only to the ECC area. On the other hand, the bootrom ECC 
> puts the whole ECC at offset (1024 + 12) bytes from the start of the block 0.

Would it make sense to have the driver code treat block 0 specially
(possibly conditioned on an hwconfig or compile-time config), rather
than have it be user-driven?

I'm curious why anything is written on an erase, though, regardless of
data format.

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Monday, September 12, 2011 08:31:12 PM Scott Wood wrote:
> On 09/12/2011 01:24 PM, Marek Vasut wrote:
> > On Monday, September 12, 2011 08:06:27 PM Scott Wood wrote:
> >> On 09/12/2011 12:45 PM, Marek Vasut wrote:
> >>> On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
> >>>> On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> >>>>> This allows the scrub command to scrub without asking the user if he
> >>>>> really wants to scrub the area. Useful in scripts.
> >>>> 
> >>>> "quiet" and "skip user input" are two different things.  can you use a
> >>>> more clean option like accepting "-y" to the "scrub" subcommand ?
> >>> 
> >>> I'd prefer to have this hidden from common users as much as possible.
> >> 
> >> What's the use case for needing to script this, BTW?
> > 
> > Update a block in NAND that's not handled by BCH accelerator in the MX28
> > chip.
> > 
> > The problem is, block 0 has it's own ECC done by bootrom software. That
> > kind of ECC is incompatible with BCH-produced ECC. That's also a reason
> > for needing that write.raw command.
> > 
> > Now, if you try erasing that block, the BCH reads and writes some of it's
> > metadata there. Obviously, since there is different kind of ECC, the
> > metadata aren't there and it chokes, claiming the block is bad and
> > refuses to erase it.
> > 
> > And before you ask why -- that's because the BCH accelerator puts the
> > metadata at random places in the block (every 512 bytes, it puts a few
> > bytes of it's ECC) instead of putting them only to the ECC area. On the
> > other hand, the bootrom ECC puts the whole ECC at offset (1024 + 12)
> > bytes from the start of the block 0.
> 
> Would it make sense to have the driver code treat block 0 specially
> (possibly conditioned on an hwconfig or compile-time config), rather
> than have it be user-driven?

No! What if (very possible situation actually) the user wants to use the whole 
NAND because the user is booting from SD/SPI/... ?

> 
> I'm curious why anything is written on an erase, though, regardless of
> data format.

Badblock markers (some FSL invention) are written always.

> 
> -Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

On 09/12/2011 01:36 PM, Marek Vasut wrote:
> On Monday, September 12, 2011 08:31:12 PM Scott Wood wrote:
>> Would it make sense to have the driver code treat block 0 specially
>> (possibly conditioned on an hwconfig or compile-time config), rather
>> than have it be user-driven?
> 
> No! What if (very possible situation actually) the user wants to use the whole 
> NAND because the user is booting from SD/SPI/... ?

Well, that's why I suggested it be configurable.

>> I'm curious why anything is written on an erase, though, regardless of
>> data format.
> 
> Badblock markers (some FSL invention) are written always.

What's it doing with them?  Migrating them is something that should only
happen on the first use, as there will later be data in the factory bad
block area, right?  So it shouldn't be "always".  Migration should be an
explicitly requested option.  Like scrub. :-)

Where is the code that does this?  Which driver?

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
> On 09/12/2011 01:36 PM, Marek Vasut wrote:
> > On Monday, September 12, 2011 08:31:12 PM Scott Wood wrote:
> >> Would it make sense to have the driver code treat block 0 specially
> >> (possibly conditioned on an hwconfig or compile-time config), rather
> >> than have it be user-driven?
> > 
> > No! What if (very possible situation actually) the user wants to use the
> > whole NAND because the user is booting from SD/SPI/... ?
> 
> Well, that's why I suggested it be configurable.
> 
> >> I'm curious why anything is written on an erase, though, regardless of
> >> data format.
> > 
> > Badblock markers (some FSL invention) are written always.
> 
> What's it doing with them?  Migrating them is something that should only
> happen on the first use, as there will later be data in the factory bad
> block area, right?  So it shouldn't be "always".  Migration should be an
> explicitly requested option.  Like scrub. :-)
> 
> Where is the code that does this?  Which driver?

The BCH accelerator does this.

> 
> -Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

On 09/12/2011 02:28 PM, Marek Vasut wrote:
> On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
>> What's it doing with them?  Migrating them is something that should only
>> happen on the first use, as there will later be data in the factory bad
>> block area, right?  So it shouldn't be "always".  Migration should be an
>> explicitly requested option.  Like scrub. :-)
>>
>> Where is the code that does this?  Which driver?
> 
> The BCH accelerator does this.

In hardware?  What chip is this, and where is the code that drives this
chip?

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Monday, September 12, 2011 09:36:49 PM Scott Wood wrote:
> On 09/12/2011 02:28 PM, Marek Vasut wrote:
> > On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
> >> What's it doing with them?  Migrating them is something that should only
> >> happen on the first use, as there will later be data in the factory bad
> >> block area, right?  So it shouldn't be "always".  Migration should be an
> >> explicitly requested option.  Like scrub. :-)
> >> 
> >> Where is the code that does this?  Which driver?
> > 
> > The BCH accelerator does this.
> 
> In hardware?  What chip is this, and where is the code that drives this
> chip?

I think it does something to it, yes. i.MX287, see the patchset [PATCH 00/15 V2] 
Support for the DENX M28 SoM, [PATCH 09/15] iMX28: Add GPMI NAND driver .

> 
> -Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

On 09/12/2011 02:42 PM, Marek Vasut wrote:
> On Monday, September 12, 2011 09:36:49 PM Scott Wood wrote:
>> On 09/12/2011 02:28 PM, Marek Vasut wrote:
>>> On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
>>>> What's it doing with them?  Migrating them is something that should only
>>>> happen on the first use, as there will later be data in the factory bad
>>>> block area, right?  So it shouldn't be "always".  Migration should be an
>>>> explicitly requested option.  Like scrub. :-)
>>>>
>>>> Where is the code that does this?  Which driver?
>>>
>>> The BCH accelerator does this.
>>
>> In hardware?  What chip is this, and where is the code that drives this
>> chip?
> 
> I think it does something to it, yes. i.MX287, see the patchset [PATCH 00/15 V2] 
> Support for the DENX M28 SoM, [PATCH 09/15] iMX28: Add GPMI NAND driver .

I looked at the code and the datasheet, and without getting into it too
deeply, I don't see how BCH is involved in an erase operation.  What
specifically are you seeing happen?

The "Raw NAND Boot Mode" section (12.12 in my copy of the i.MX28 manual)
says that it uses BCH for ECC -- is this not the case?  Is it some
special configuration of BCH?

I tried reading the "Bad Block Handling in the ROM" section and got a
headache.

I work for the PowerPC side of Freescale, in case you're wondering why
I'm unfamiliar with this. :-)

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Tuesday, September 13, 2011 01:24:22 AM Scott Wood wrote:
> On 09/12/2011 02:42 PM, Marek Vasut wrote:
> > On Monday, September 12, 2011 09:36:49 PM Scott Wood wrote:
> >> On 09/12/2011 02:28 PM, Marek Vasut wrote:
> >>> On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
> >>>> What's it doing with them?  Migrating them is something that should
> >>>> only happen on the first use, as there will later be data in the
> >>>> factory bad block area, right?  So it shouldn't be "always". 
> >>>> Migration should be an explicitly requested option.  Like scrub. :-)
> >>>> 
> >>>> Where is the code that does this?  Which driver?
> >>> 
> >>> The BCH accelerator does this.
> >> 
> >> In hardware?  What chip is this, and where is the code that drives this
> >> chip?
> > 
> > I think it does something to it, yes. i.MX287, see the patchset [PATCH
> > 00/15 V2] Support for the DENX M28 SoM, [PATCH 09/15] iMX28: Add GPMI
> > NAND driver .
> 
> I looked at the code and the datasheet, and without getting into it too
> deeply, I don't see how BCH is involved in an erase operation.  What
> specifically are you seeing happen?
> 
> The "Raw NAND Boot Mode" section (12.12 in my copy of the i.MX28 manual)
> says that it uses BCH for ECC -- is this not the case?  Is it some
> special configuration of BCH?
> 
> I tried reading the "Bad Block Handling in the ROM" section and got a
> headache.

12.12.1.8 is exactly it. See fig. 12-11. Also section 12.12.1.9 is interesting 
(at least for the block 0 problem).

For the other problem, you should read chapter 15 and 16. Though they are not 
completely beefed with information on that matter either.

I got most of these information from the source code FSL provided in their MX28 
BSP. The usual flow is the driver uses DMA to send the commands/data to the GPMI 
NAND driver. The GPMI NAND controller diverts the data to the BCH, which does 
the bit obscurisation. Then the data are taken from the BCH and written to NAND.

And the other way in the read process ... GPMI NAND controller reads data back 
from NAND, pushes them through the BCH and then presents them to the user.

The problem with erase here is that the block's ECC is updated on erase. But we 
want to write a block in our own format, so we need to scrub (wipe the block 
completely).

> 
> I work for the PowerPC side of Freescale, in case you're wondering why
> I'm unfamiliar with this. :-)

Interesting ... does everyone work for the PowerPC side of Freescale or is there 
some other reason why I never met anyone working for the ARM side of Freescale ? 
;-)
> 
> -Scott

Cheers

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Wolfgang Denk]

Dear Marek Vasut,

In message <201109130302.16991.marek.vasut@gmail.com> you wrote:
>
> Interesting ... does everyone work for the PowerPC side of Freescale or is there 
> some other reason why I never met anyone working for the ARM side of Freescale ? 
> ;-)

Keep in mind that the i.MX28 is actually not a Freescale design...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Tuesday, September 13, 2011 06:25:42 AM Wolfgang Denk wrote:
> Dear Marek Vasut,
> 
> In message <201109130302.16991.marek.vasut@gmail.com> you wrote:
> > Interesting ... does everyone work for the PowerPC side of Freescale or
> > is there some other reason why I never met anyone working for the ARM
> > side of Freescale ? ;-)
> 
> Keep in mind that the i.MX28 is actually not a Freescale design...

I was just curious here.

Cheers

> 
> Best regards,
> 
> Wolfgang Denk

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

On 09/12/2011 08:02 PM, Marek Vasut wrote:
> On Tuesday, September 13, 2011 01:24:22 AM Scott Wood wrote:
>> On 09/12/2011 02:42 PM, Marek Vasut wrote:
>>> On Monday, September 12, 2011 09:36:49 PM Scott Wood wrote:
>>>> On 09/12/2011 02:28 PM, Marek Vasut wrote:
>>>>> On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
>>>>>> What's it doing with them?  Migrating them is something that should
>>>>>> only happen on the first use, as there will later be data in the
>>>>>> factory bad block area, right?  So it shouldn't be "always". 
>>>>>> Migration should be an explicitly requested option.  Like scrub. :-)
>>>>>>
>>>>>> Where is the code that does this?  Which driver?
>>>>>
>>>>> The BCH accelerator does this.
>>>>
>>>> In hardware?  What chip is this, and where is the code that drives this
>>>> chip?
>>>
>>> I think it does something to it, yes. i.MX287, see the patchset [PATCH
>>> 00/15 V2] Support for the DENX M28 SoM, [PATCH 09/15] iMX28: Add GPMI
>>> NAND driver .
[snip]
> The problem with erase here is that the block's ECC is updated on erase.

I don't understand this -- wouldn't that stop you from being able to
later write a different ECC (when you write the actual data)?  Is the
controller snooping the command bytes you issue for erase, and then
generating a program sequence?  How would the hardware even know that
you told U-Boot to scrub?

>>> I looked at the code and the datasheet, and without getting into it too
>>> deeply, I don't see how BCH is involved in an erase operation.  What
>>> specifically are you seeing happen?
>>>
>>> The "Raw NAND Boot Mode" section (12.12 in my copy of the i.MX28 manual)
>>> says that it uses BCH for ECC -- is this not the case?  Is it some
>>> special configuration of BCH?
>>>
>>> I tried reading the "Bad Block Handling in the ROM" section and got a
>>> headache.
>> 
>> 12.12.1.8 is exactly it. See fig. 12-11.

I think we have different versions, that's "Layout of Boot Page
containing FCB" in my copy, which shows a fixed spare/data/ECC layout
that may not match what is programmed for normal BCH operations, but it
doesn't say anything about bad block markers.

The bad block marker stuff is in 12.12.1.12 (figure 12-13) in my copy.
It says:

> In order to preserve the BI (bad block information), flash updater or gang programmer
> applications need to swap Bad Block Information (BI) data to byte 0 of metadata area for
> every page before programming NAND Flash.

Before first programming the flash, you'll need to make sure that all
blocks that are marked bad in the normal way get marked bad in the new
layout, but you don't need to *swap* anything.  The block's bad, the
rest of the block doesn't matter.  But anyway...

> ROM when loading firmware, copies back
> the value at metadata[0] to BI offset in page data. The following figure shows how the
> factory bad block marker is preserved.

...this is insane.  It seems that they want you to swap this byte even
in good blocks, so that you put the byte of real data that should go
somewhere in the middle of the last 512-byte ECC chunk at offset zero in
the page.  This means that it will show up as a bad block when normal
(but new-layout-using) software looks at it, which is why you need
scrub.  Ew.

How many blocks are being loaded by this mechanism?  Just block zero
(which is normally supposed to be guaranteed good anyway...)?  Or
multiple blocks?

Any chance you could blow the NAND_MEMBLOCK_MARKER_RESERVE fuse? :-)
Otherwise, I guess you do need to scrub.  Have you complained to
Freescale sales/support?

> But we want to write a block in our own format, so we need to scrub (wipe the block 
> completely).

Erase always wipes the block completely, if it erases at all.  Scrub in
this context just means that U-Boot ignores the bad block indications
(marker or table).  Otherwise it would avoid erasing bad blocks, so that
they stay bad, and you won't have scrubbed the entire region requested.

>> I work for the PowerPC side of Freescale, in case you're wondering why
>> I'm unfamiliar with this. :-)
> 
> Interesting ... does everyone work for the PowerPC side of Freescale or is there 
> some other reason why I never met anyone working for the ARM side of Freescale ? 
> ;-)

They exist, but don't seem to engage Open Source development communities
to the same degree.

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

[...]

> > ROM when loading firmware, copies back
> > the value at metadata[0] to BI offset in page data. The following figure
> > shows how the factory bad block marker is preserved.
> 
> ...this is insane.  It seems that they want you to swap this byte even
> in good blocks, so that you put the byte of real data that should go
> somewhere in the middle of the last 512-byte ECC chunk at offset zero in
> the page.  This means that it will show up as a bad block when normal
> (but new-layout-using) software looks at it, which is why you need
> scrub.  Ew.
> 
> How many blocks are being loaded by this mechanism?  Just block zero
> (which is normally supposed to be guaranteed good anyway...)?  Or
> multiple blocks?

The first block, then the 64th block, 128th block and 192th block (in default 
layout).
> 
> Any chance you could blow the NAND_MEMBLOCK_MARKER_RESERVE fuse? :-)

No, they are one-time programable. Delivering a "damaged" chip isn't a good 
practice.

> Otherwise, I guess you do need to scrub.  Have you complained to
> Freescale sales/support?

In fact no. The BootROM is "broken" and I doubt they will be willing to do 
anything about it.

> 
> > But we want to write a block in our own format, so we need to scrub (wipe
> > the block completely).
> 
> Erase always wipes the block completely, if it erases at all.  Scrub in
> this context just means that U-Boot ignores the bad block indications
> (marker or table).  Otherwise it would avoid erasing bad blocks, so that
> they stay bad, and you won't have scrubbed the entire region requested.
> 
> >> I work for the PowerPC side of Freescale, in case you're wondering why
> >> I'm unfamiliar with this. :-)
> > 
> > Interesting ... does everyone work for the PowerPC side of Freescale or
> > is there some other reason why I never met anyone working for the ARM
> > side of Freescale ? ;-)
> 
> They exist, but don't seem to engage Open Source development communities
> to the same degree.
> 
> -Scott

Cheers

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

On 09/13/2011 05:41 PM, Marek Vasut wrote:
>> Any chance you could blow the NAND_MEMBLOCK_MARKER_RESERVE fuse? :-)
> 
> No, they are one-time programable. Delivering a "damaged" chip isn't a good 
> practice.

I'd call it "fixed" rather than "damaged" -- they did throw in that fuse
in case of "any defective ROM code in handling bad block marker byte
swapping", and the entire concept is defective.

But I agree that if you're delivering them to other developers, rather
than as part of a final product, they might want to make that choice
themselves.  And who knows, blowing the fuse might expose other defects.

>> Otherwise, I guess you do need to scrub.  Have you complained to
>> Freescale sales/support?
> 
> In fact no. The BootROM is "broken" and I doubt they will be willing to do 
> anything about it.

Probably not, but they should still hear about it, if only for the
chance they'll do it right next time.

-Scott

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Wolfgang Denk]

Dear Marek Vasut,

In message <201109121945.17407.marek.vasut@gmail.com> you wrote:
> On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
> > On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> > > This allows the scrub command to scrub without asking the user if he
> > > really wants to scrub the area. Useful in scripts.
> > 
> > "quiet" and "skip user input" are two different things.  can you use a more
> > clean option like accepting "-y" to the "scrub" subcommand ?
> 
> I'd prefer to have this hidden from common users as much as possible.

This is probably well-intentioned, but keep in mind old (and good!)
Unix rules like:

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

Don't try hiding stuff - others might find it useful.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I can't say I've ever been lost, but I was bewildered once for  three
days.                                     - Daniel Boone (Attributed)

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Monday, September 12, 2011 08:37:47 PM Wolfgang Denk wrote:
> Dear Marek Vasut,
> 
> In message <201109121945.17407.marek.vasut@gmail.com> you wrote:
> > On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
> > > On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> > > > This allows the scrub command to scrub without asking the user if he
> > > > really wants to scrub the area. Useful in scripts.
> > > 
> > > "quiet" and "skip user input" are two different things.  can you use a
> > > more clean option like accepting "-y" to the "scrub" subcommand ?
> > 
> > I'd prefer to have this hidden from common users as much as possible.
> 
> This is probably well-intentioned, but keep in mind old (and good!)
> Unix rules like:
> 
> "UNIX was not designed to stop you from doing stupid things,  because
> that would also stop you from doing clever things."       - Doug Gwyn
> 
> Don't try hiding stuff - others might find it useful.

You can use the usual scrub command, noone is preventing you from anything.

Using this kind of a scrub.quiet command is really an arguable practice.

> 
> Best regards,
> 
> Wolfgang Denk

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Mike Frysinger]

On Monday, September 12, 2011 13:45:17 Marek Vasut wrote:
> On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
> > On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> > > This allows the scrub command to scrub without asking the user if he
> > > really wants to scrub the area. Useful in scripts.
> > 
> > "quiet" and "skip user input" are two different things.  can you use a
> > more clean option like accepting "-y" to the "scrub" subcommand ?
> 
> I'd prefer to have this hidden from common users as much as possible.

ok, but i dont follow why that makes a difference to my feedback.  "quiet" 
does not mean "do not prompt the user".  however, "scrub -y" does mean "assume 
yes to the sanity prompts".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110912/2633d85f/attachment.pgp 

[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Marek Vasut]

On Monday, September 12, 2011 10:33:16 PM Mike Frysinger wrote:
> On Monday, September 12, 2011 13:45:17 Marek Vasut wrote:
> > On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote:
> > > On Monday, September 12, 2011 00:04:10 Marek Vasut wrote:
> > > > This allows the scrub command to scrub without asking the user if he
> > > > really wants to scrub the area. Useful in scripts.
> > > 
> > > "quiet" and "skip user input" are two different things.  can you use a
> > > more clean option like accepting "-y" to the "scrub" subcommand ?
> > 
> > I'd prefer to have this hidden from common users as much as possible.
> 
> ok, but i dont follow why that makes a difference to my feedback.  "quiet"
> does not mean "do not prompt the user".  however, "scrub -y" does mean
> "assume yes to the sanity prompts".
> -mike

Ok, you convinced me ... I added a -y option.

[U-Boot] [PATCH 5/5] NAND: Add -y option to nand scrub command

[Marek Vasut]

This allows the scrub command to scrub without asking the user if he really
wants to scrub the area. Useful in scripts.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 common/cmd_nand.c |   34 +++++++++++++++++++---------------
 1 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 5b7e83d..c2a5623 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -500,12 +500,23 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 		nand_erase_options_t opts;
 		/* "clean" at index 2 means request to write cleanmarker */
 		int clean = argc > 2 && !strcmp("clean", argv[2]);
-		int o = clean ? 3 : 2;
+		int scrub_yes = argc > 2 && !strcmp("-y", argv[2]);
+		int o = (clean || scrub_yes) ? 3 : 2;
 		int scrub = !strncmp(cmd, "scrub", 5);
 		int part = 0;
 		int chip = 0;
 		int spread = 0;
 		int args = 2;
+		const char *scrub_warn =
+			"Warning: "
+			"scrub option will erase all factory set bad blocks!\n"
+			"         "
+			"There is no reliable way to recover them.\n"
+			"         "
+			"Use this command only for testing purposes if you\n"
+			"         "
+			"are sure of what you are doing!\n"
+			"\nReally scrub this NAND flash? <y/N>\n";
 
 		if (cmd[5] != 0) {
 			if (!strcmp(&cmd[5], ".spread")) {
@@ -544,19 +555,12 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
 		opts.spread = spread;
 
 		if (scrub) {
-			puts("Warning: "
-			     "scrub option will erase all factory set "
-			     "bad blocks!\n"
-			     "         "
-			     "There is no reliable way to recover them.\n"
-			     "         "
-			     "Use this command only for testing purposes "
-			     "if you\n"
-			     "         "
-			     "are sure of what you are doing!\n"
-			     "\nReally scrub this NAND flash? <y/N>\n");
-
-			if (getc() == 'y') {
+			if (!scrub_yes)
+				puts(scrub_warn);
+
+			if (scrub_yes)
+				opts.scrub = 1;
+			else if (getc() == 'y') {
 				puts("y");
 				if (getc() == '\r')
 					opts.scrub = 1;
@@ -768,7 +772,7 @@ U_BOOT_CMD(
 	"nand erase.chip [clean] - erase entire chip'\n"
 	"nand bad - show bad blocks\n"
 	"nand dump[.oob] off - dump page\n"
-	"nand scrub off size | scrub.part partition | scrub.chip\n"
+	"nand scrub [-y] off size | scrub.part partition | scrub.chip\n"
 	"    really clean NAND erasing bad blocks (UNSAFE)\n"
 	"nand markbad off [...] - mark bad block(s) at offset (UNSAFE)\n"
 	"nand biterr off - make a bit error at offset (UNSAFE)"
-- 
1.7.5.4

[U-Boot] [PATCH 5/5] NAND: Add -y option to nand scrub command

[Mike Frysinger]

On Tuesday, September 13, 2011 18:20:35 Marek Vasut wrote:
> This allows the scrub command to scrub without asking the user if he really
> wants to scrub the area. Useful in scripts.

Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110913/962a6cd3/attachment.pgp 

[U-Boot] [PATCH 5/5] NAND: Add -y option to nand scrub command

[Scott Wood]

On Wed, Sep 14, 2011 at 12:20:35AM +0200, Marek Vasut wrote:
> This allows the scrub command to scrub without asking the user if he really
> wants to scrub the area. Useful in scripts.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
>  common/cmd_nand.c |   34 +++++++++++++++++++---------------
>  1 files changed, 19 insertions(+), 15 deletions(-)

Applied to u-boot-nand-flash next

-Scott

[U-Boot] [PATCH 0/5] Random NAND fixes and improvements

[Marek Vasut]

This is a resend of the NAND fixes and improvements. These are squashed
togethere here and sent as a batch.

Marek Vasut (5):
  NAND: Really ignore bad blocks when scrubbing
  NAND: Add nand read.raw and write.raw commands
  NAND: Allow per-buffer allocation
  NAND: Make page, erase, oob size available via cmd_nand
  NAND: Add scrub.quiet command option

 common/cmd_nand.c            |   70 +++++++++++++++++++++++++++++++++++++++--
 drivers/mtd/nand/nand_base.c |   32 ++++++++++++++-----
 drivers/mtd/nand/nand_util.c |   22 +++----------
 include/linux/mtd/mtd.h      |    1 +
 include/linux/mtd/nand.h     |    7 ++--
 5 files changed, 100 insertions(+), 32 deletions(-)

-- 
1.7.5.4

[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

[Marek Vasut]

Don't allocate NAND buffers as one block, but allocate them separately. This
allows systems where DMA to buffers happen to allocate these buffers properly
aligned.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
---
 drivers/mtd/nand/nand_base.c |   30 +++++++++++++++++++++++-------
 include/linux/mtd/nand.h     |    7 ++++---
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index d8d30e3..3093067 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2749,13 +2749,27 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
  */
 int nand_scan_tail(struct mtd_info *mtd)
 {
-	int i;
+	int i, bufsize;
+	uint8_t *buf;
 	struct nand_chip *chip = mtd->priv;
 
-	if (!(chip->options & NAND_OWN_BUFFERS))
-		chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL);
-	if (!chip->buffers)
-		return -ENOMEM;
+	if (!(chip->options & NAND_OWN_BUFFERS)) {
+		chip->buffers = malloc(sizeof(struct nand_buffers));
+		if (!chip->buffers)
+			return -ENOMEM;
+
+		bufsize = NAND_MAX_PAGESIZE + (3 * NAND_MAX_OOBSIZE);
+		buf = malloc(bufsize);
+		if (!buf) {
+			free(chip->buffers);
+			return -ENOMEM;
+		}
+
+		chip->buffers->buffer = buf;
+		chip->buffers->ecccalc = buf;
+		chip->buffers->ecccode = buf + NAND_MAX_OOBSIZE;
+		chip->buffers->databuf = buf + (2 * NAND_MAX_OOBSIZE);
+	}
 
 	/* Set the internal oob buffer location, just after the page data */
 	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
@@ -2996,6 +3010,8 @@ void nand_release(struct mtd_info *mtd)
 
 	/* Free bad block table memory */
 	kfree(chip->bbt);
-	if (!(chip->options & NAND_OWN_BUFFERS))
-		kfree(chip->buffers);
+	if (!(chip->options & NAND_OWN_BUFFERS)) {
+		free(chip->buffers->buffer);
+		free(chip->buffers);
+	}
 }
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 987a2ec..c3449a9 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -370,9 +370,10 @@ struct nand_ecc_ctrl {
  * consecutive order.
  */
 struct nand_buffers {
-	uint8_t	ecccalc[NAND_MAX_OOBSIZE];
-	uint8_t	ecccode[NAND_MAX_OOBSIZE];
-	uint8_t databuf[NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE];
+	uint8_t *buffer;
+	uint8_t	*ecccalc;
+	uint8_t	*ecccode;
+	uint8_t *databuf;
 };
 
 /**
-- 
1.7.5.4