[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Huang Shijie]

Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    2 ++
 include/linux/mtd/gpmi-nand.h          |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 493ec2f..4d369df 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1493,6 +1493,8 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
 	chip->ecc.mode		= NAND_ECC_HW;
 	chip->ecc.size		= 1;
 	chip->ecc.layout	= &gpmi_hw_ecclayout;
+	if (pdata->enable_bbt)
+		chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
 
 	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
 	this->bch_geometry.payload_size = 1024;
diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
index 69b6dbf..04ab366 100644
--- a/include/linux/mtd/gpmi-nand.h
+++ b/include/linux/mtd/gpmi-nand.h
@@ -51,6 +51,7 @@
  * @partitions:              An optional pointer to an array of partition
  *                           descriptions.
  * @partition_count:         The number of elements in the partitions array.
+ * @enable_bbt:              Enable the BBT or not.
  */
 struct gpmi_nand_platform_data {
 	/* SoC hardware information. */
@@ -64,5 +65,6 @@ struct gpmi_nand_platform_data {
 	/* Medium information. */
 	struct		mtd_partition *partitions;
 	unsigned	partition_count;
+	unsigned int	enable_bbt:1;
 };
 #endif
-- 
1.7.0.4

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Huang Shijie]

Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    2 ++
 include/linux/mtd/gpmi-nand.h          |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 493ec2f..4d369df 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1493,6 +1493,8 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
 	chip->ecc.mode		= NAND_ECC_HW;
 	chip->ecc.size		= 1;
 	chip->ecc.layout	= &gpmi_hw_ecclayout;
+	if (pdata->enable_bbt)
+		chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
 
 	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
 	this->bch_geometry.payload_size = 1024;
diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
index 69b6dbf..04ab366 100644
--- a/include/linux/mtd/gpmi-nand.h
+++ b/include/linux/mtd/gpmi-nand.h
@@ -51,6 +51,7 @@
  * @partitions:              An optional pointer to an array of partition
  *                           descriptions.
  * @partition_count:         The number of elements in the partitions array.
+ * @enable_bbt:              Enable the BBT or not.
  */
 struct gpmi_nand_platform_data {
 	/* SoC hardware information. */
@@ -64,5 +65,6 @@ struct gpmi_nand_platform_data {
 	/* Medium information. */
 	struct		mtd_partition *partitions;
 	unsigned	partition_count;
+	unsigned int	enable_bbt:1;
 };
 #endif
-- 
1.7.0.4

Re: [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Marek Vasut]

> Add a new field to gpmi_nand_platform_data{}.
> Make the BBT support to board specific.
> 
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    2 ++
>  include/linux/mtd/gpmi-nand.h          |    2 ++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index 493ec2f..4d369df 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1493,6 +1493,8 @@ static int __devinit gpmi_nfc_init(struct
> gpmi_nand_data *this) chip->ecc.mode		= NAND_ECC_HW;
>  	chip->ecc.size		= 1;
>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
> +	if (pdata->enable_bbt)
> +		chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
> 
>  	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
>  	this->bch_geometry.payload_size = 1024;
> diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
> index 69b6dbf..04ab366 100644
> --- a/include/linux/mtd/gpmi-nand.h
> +++ b/include/linux/mtd/gpmi-nand.h
> @@ -51,6 +51,7 @@
>   * @partitions:              An optional pointer to an array of partition
>   *                           descriptions.
>   * @partition_count:         The number of elements in the partitions
> array. + * @enable_bbt:              Enable the BBT or not.
>   */
>  struct gpmi_nand_platform_data {
>  	/* SoC hardware information. */
> @@ -64,5 +65,6 @@ struct gpmi_nand_platform_data {
>  	/* Medium information. */
>  	struct		mtd_partition *partitions;
>  	unsigned	partition_count;
> +	unsigned int	enable_bbt:1;
>  };
>  #endif

Hi, we also need one more fix here /wrt subpage writes,
See: "GPMI-NAND: Wrong ECC size in driver" email.

Otherwise, this seems ok.

M

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Marek Vasut]

> Add a new field to gpmi_nand_platform_data{}.
> Make the BBT support to board specific.
> 
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    2 ++
>  include/linux/mtd/gpmi-nand.h          |    2 ++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index 493ec2f..4d369df 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1493,6 +1493,8 @@ static int __devinit gpmi_nfc_init(struct
> gpmi_nand_data *this) chip->ecc.mode		= NAND_ECC_HW;
>  	chip->ecc.size		= 1;
>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
> +	if (pdata->enable_bbt)
> +		chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
> 
>  	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
>  	this->bch_geometry.payload_size = 1024;
> diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
> index 69b6dbf..04ab366 100644
> --- a/include/linux/mtd/gpmi-nand.h
> +++ b/include/linux/mtd/gpmi-nand.h
> @@ -51,6 +51,7 @@
>   * @partitions:              An optional pointer to an array of partition
>   *                           descriptions.
>   * @partition_count:         The number of elements in the partitions
> array. + * @enable_bbt:              Enable the BBT or not.
>   */
>  struct gpmi_nand_platform_data {
>  	/* SoC hardware information. */
> @@ -64,5 +65,6 @@ struct gpmi_nand_platform_data {
>  	/* Medium information. */
>  	struct		mtd_partition *partitions;
>  	unsigned	partition_count;
> +	unsigned int	enable_bbt:1;
>  };
>  #endif

Hi, we also need one more fix here /wrt subpage writes,
See: "GPMI-NAND: Wrong ECC size in driver" email.

Otherwise, this seems ok.

M

Re: [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

On Tue, Jan 31, 2012 at 07:11:56PM +0800, Huang Shijie wrote:
> Add a new field to gpmi_nand_platform_data{}.
> Make the BBT support to board specific.
> 
> Signed-off-by: Huang Shijie <b32955@freescale.com>

Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>

I'd think you won't be able to mark blocks bad, though. Will send a
patch in a minute. Please test.

> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    2 ++
>  include/linux/mtd/gpmi-nand.h          |    2 ++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 493ec2f..4d369df 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1493,6 +1493,8 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
>  	chip->ecc.mode		= NAND_ECC_HW;
>  	chip->ecc.size		= 1;
>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
> +	if (pdata->enable_bbt)
> +		chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
>  
>  	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
>  	this->bch_geometry.payload_size = 1024;
> diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
> index 69b6dbf..04ab366 100644
> --- a/include/linux/mtd/gpmi-nand.h
> +++ b/include/linux/mtd/gpmi-nand.h
> @@ -51,6 +51,7 @@
>   * @partitions:              An optional pointer to an array of partition
>   *                           descriptions.
>   * @partition_count:         The number of elements in the partitions array.
> + * @enable_bbt:              Enable the BBT or not.
>   */
>  struct gpmi_nand_platform_data {
>  	/* SoC hardware information. */
> @@ -64,5 +65,6 @@ struct gpmi_nand_platform_data {
>  	/* Medium information. */
>  	struct		mtd_partition *partitions;
>  	unsigned	partition_count;
> +	unsigned int	enable_bbt:1;
>  };
>  #endif
> -- 
> 1.7.0.4
> 
> 

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Wolfram Sang]

On Tue, Jan 31, 2012 at 07:11:56PM +0800, Huang Shijie wrote:
> Add a new field to gpmi_nand_platform_data{}.
> Make the BBT support to board specific.
> 
> Signed-off-by: Huang Shijie <b32955@freescale.com>

Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>

I'd think you won't be able to mark blocks bad, though. Will send a
patch in a minute. Please test.

> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    2 ++
>  include/linux/mtd/gpmi-nand.h          |    2 ++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 493ec2f..4d369df 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1493,6 +1493,8 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
>  	chip->ecc.mode		= NAND_ECC_HW;
>  	chip->ecc.size		= 1;
>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
> +	if (pdata->enable_bbt)
> +		chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
>  
>  	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
>  	this->bch_geometry.payload_size = 1024;
> diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
> index 69b6dbf..04ab366 100644
> --- a/include/linux/mtd/gpmi-nand.h
> +++ b/include/linux/mtd/gpmi-nand.h
> @@ -51,6 +51,7 @@
>   * @partitions:              An optional pointer to an array of partition
>   *                           descriptions.
>   * @partition_count:         The number of elements in the partitions array.
> + * @enable_bbt:              Enable the BBT or not.
>   */
>  struct gpmi_nand_platform_data {
>  	/* SoC hardware information. */
> @@ -64,5 +65,6 @@ struct gpmi_nand_platform_data {
>  	/* Medium information. */
>  	struct		mtd_partition *partitions;
>  	unsigned	partition_count;
> +	unsigned int	enable_bbt:1;
>  };
>  #endif
> -- 
> 1.7.0.4
> 
> 

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120131/437474bc/attachment.sig>

Re: [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Bityutskiy, Artem]

[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]

On Tue, 2012-01-31 at 13:10 +0100, Wolfram Sang wrote:
> On Tue, Jan 31, 2012 at 07:11:56PM +0800, Huang Shijie wrote:
> > Add a new field to gpmi_nand_platform_data{}.
> > Make the BBT support to board specific.
> > 
> > Signed-off-by: Huang Shijie <b32955@freescale.com>
> 
> Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
> 
> I'd think you won't be able to mark blocks bad, though. Will send a
> patch in a minute. Please test.

Sorry, I have not read this and the previous related long threads, but
from the few first e-mails I got the impression that you are not aware
of the patch from Brian Norris where he modifies MTD BBT code so that it
will by default write bad block markers _both_ to the BBT and to OOB. It
sounds like you should hold on with this patch and wait when Brian's
patch gets in. Then you probably may just use the first version of this
patch.

The patch I referred to:
http://patchwork.ozlabs.org/patch/137154/

HTH.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 464 bytes --]

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Bityutskiy, Artem]

On Tue, 2012-01-31 at 13:10 +0100, Wolfram Sang wrote:
> On Tue, Jan 31, 2012 at 07:11:56PM +0800, Huang Shijie wrote:
> > Add a new field to gpmi_nand_platform_data{}.
> > Make the BBT support to board specific.
> > 
> > Signed-off-by: Huang Shijie <b32955@freescale.com>
> 
> Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
> 
> I'd think you won't be able to mark blocks bad, though. Will send a
> patch in a minute. Please test.

Sorry, I have not read this and the previous related long threads, but
from the few first e-mails I got the impression that you are not aware
of the patch from Brian Norris where he modifies MTD BBT code so that it
will by default write bad block markers _both_ to the BBT and to OOB. It
sounds like you should hold on with this patch and wait when Brian's
patch gets in. Then you probably may just use the first version of this
patch.

The patch I referred to:
http://patchwork.ozlabs.org/patch/137154/

HTH.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120202/04619b00/attachment-0001.sig>
-------------- next part --------------
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Lothar Waßmann]

Hi,

Bityutskiy, Artem writes:
> On Tue, 2012-01-31 at 13:10 +0100, Wolfram Sang wrote:
> > On Tue, Jan 31, 2012 at 07:11:56PM +0800, Huang Shijie wrote:
> > > Add a new field to gpmi_nand_platform_data{}.
> > > Make the BBT support to board specific.
> > > 
> > > Signed-off-by: Huang Shijie <b32955@freescale.com>
> > 
> > Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
> > 
> > I'd think you won't be able to mark blocks bad, though. Will send a
> > patch in a minute. Please test.
> 
> Sorry, I have not read this and the previous related long threads, but
> from the few first e-mails I got the impression that you are not aware
> of the patch from Brian Norris where he modifies MTD BBT code so that it
> will by default write bad block markers _both_ to the BBT and to OOB. It
> sounds like you should hold on with this patch and wait when Brian's
> patch gets in. Then you probably may just use the first version of this
> patch.
> 
IMO it's just silly trying to write anything, even a bad block marker,
to a known bad block in NAND flash.

The bad block markers in particular bytes in the OOB area are provided
by the manufacturer to identify "Factory Bad Blocks". That and no
more!
I don't know why everybody is trying to interpret them as a general
bad block indicator.

To keep track of bad blocks you need at least one good block that can
be reliably written and read (AKA flash based BBT). The only function
of the "Bad Block Markers" is to provide an initial list of blocks
that should be listed in the BBT.


Lothar Waßmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Lothar Waßmann]

Hi,

Bityutskiy, Artem writes:
> On Tue, 2012-01-31 at 13:10 +0100, Wolfram Sang wrote:
> > On Tue, Jan 31, 2012 at 07:11:56PM +0800, Huang Shijie wrote:
> > > Add a new field to gpmi_nand_platform_data{}.
> > > Make the BBT support to board specific.
> > > 
> > > Signed-off-by: Huang Shijie <b32955@freescale.com>
> > 
> > Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
> > 
> > I'd think you won't be able to mark blocks bad, though. Will send a
> > patch in a minute. Please test.
> 
> Sorry, I have not read this and the previous related long threads, but
> from the few first e-mails I got the impression that you are not aware
> of the patch from Brian Norris where he modifies MTD BBT code so that it
> will by default write bad block markers _both_ to the BBT and to OOB. It
> sounds like you should hold on with this patch and wait when Brian's
> patch gets in. Then you probably may just use the first version of this
> patch.
> 
IMO it's just silly trying to write anything, even a bad block marker,
to a known bad block in NAND flash.

The bad block markers in particular bytes in the OOB area are provided
by the manufacturer to identify "Factory Bad Blocks". That and no
more!
I don't know why everybody is trying to interpret them as a general
bad block indicator.

To keep track of bad blocks you need at least one good block that can
be reliably written and read (AKA flash based BBT). The only function
of the "Bad Block Markers" is to provide an initial list of blocks
that should be listed in the BBT.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________

Re: [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Ricard Wanderlof]

On Thu, 2 Feb 2012, Lothar Waßmann wrote:

> Hi,

> IMO it's just silly trying to write anything, even a bad block marker,to 
> a known bad block in NAND flash.
>
> The bad block markers in particular bytes in the OOB area are providedby 
> the manufacturer to identify "Factory Bad Blocks". That and no more! I 
> don't know why everybody is trying to interpret them as a general bad 
> block indicator.

Why not? It's just another byte within the block.

It depends on what you mean by the concept 'bad block'. In the data sheets 
manufacturers usually state that 'additional bad blocks can develop over 
time', and this basically means that a block becomes worn out so that they 
don't meet the specifications regarding data retention etc, but the block 
is not defective in the sense that there's been a destructive change in 
the silicon structure.

In contrast, factory bad blocks can be both blocks with physical defects 
preventing their use, as well as blocks which don't meet the 
specifications. In my experience with 1 GB SLC flashes, the latter type of 
'bad' dominates, so that in many cases it is possible to erase the bad 
block markers on factory bad blocks and use them just as any other block. 
Since they were marked bad from the factory it is not a wise idea and 
should definitely not be used for production but can be very handy for 
'unbricking' a device where something has gone wrong with the flash 
management and all blocks have been marked as 'bad' with no information as 
to whether they were factory bad or not.

(In fact in a test concluded by NASA the factory marked bad blocks did not 
seem to correlate with the blocks having the worst characteristics; I 
think the relevant document is 
http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/40761/1/08-07.pdf but 
I'm not completely sure).

The Flash chip reports an error on a write or erase operation if the 
operation does not complete successfully within certain time constraints, 
which are grounds for marking a block as unusable, i.e. bad, but usually 
the block is worn out long before the on-chip write/erase algorithms 
report errors. Hence a block should really be marked 'bad' while it still 
is 'good', in a sense.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Ricard Wanderlof]

On Thu, 2 Feb 2012, Lothar Wa?mann wrote:

> Hi,

> IMO it's just silly trying to write anything, even a bad block marker,to 
> a known bad block in NAND flash.
>
> The bad block markers in particular bytes in the OOB area are providedby 
> the manufacturer to identify "Factory Bad Blocks". That and no more! I 
> don't know why everybody is trying to interpret them as a general bad 
> block indicator.

Why not? It's just another byte within the block.

It depends on what you mean by the concept 'bad block'. In the data sheets 
manufacturers usually state that 'additional bad blocks can develop over 
time', and this basically means that a block becomes worn out so that they 
don't meet the specifications regarding data retention etc, but the block 
is not defective in the sense that there's been a destructive change in 
the silicon structure.

In contrast, factory bad blocks can be both blocks with physical defects 
preventing their use, as well as blocks which don't meet the 
specifications. In my experience with 1 GB SLC flashes, the latter type of 
'bad' dominates, so that in many cases it is possible to erase the bad 
block markers on factory bad blocks and use them just as any other block. 
Since they were marked bad from the factory it is not a wise idea and 
should definitely not be used for production but can be very handy for 
'unbricking' a device where something has gone wrong with the flash 
management and all blocks have been marked as 'bad' with no information as 
to whether they were factory bad or not.

(In fact in a test concluded by NASA the factory marked bad blocks did not 
seem to correlate with the blocks having the worst characteristics; I 
think the relevant document is 
http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/40761/1/08-07.pdf but 
I'm not completely sure).

The Flash chip reports an error on a write or erase operation if the 
operation does not complete successfully within certain time constraints, 
which are grounds for marking a block as unusable, i.e. bad, but usually 
the block is worn out long before the on-chip write/erase algorithms 
report errors. Hence a block should really be marked 'bad' while it still 
is 'good', in a sense.

/Ricard
-- 
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Lothar Waßmann]

Hi,

Ricard Wanderlof writes:
> 
> On Thu, 2 Feb 2012, Lothar Waßmann wrote:
> 
> > Hi,
> 
> > IMO it's just silly trying to write anything, even a bad block marker,to 
> > a known bad block in NAND flash.
> >
> > The bad block markers in particular bytes in the OOB area are providedby 
> > the manufacturer to identify "Factory Bad Blocks". That and no more! I 
> > don't know why everybody is trying to interpret them as a general bad 
> > block indicator.
> 
> Why not? It's just another byte within the block.
> 
But on a block that is known to have failed erasure or programming you
cannot rely on being able to program anything reliably. Thus it is
vain to try storing the info that the block is bad within that block
itself.

> The Flash chip reports an error on a write or erase operation if the 
> operation does not complete successfully within certain time constraints, 
> which are grounds for marking a block as unusable, i.e. bad, but usually 
> the block is worn out long before the on-chip write/erase algorithms 
> report errors. Hence a block should really be marked 'bad' while it still 
> is 'good', in a sense.
> 
How do you know that a worn out block will still retain the 'This
block is bad' information?


Lothar Waßmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________

[PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver

[Lothar Waßmann]

Hi,

Ricard Wanderlof writes:
> 
> On Thu, 2 Feb 2012, Lothar Wa?mann wrote:
> 
> > Hi,
> 
> > IMO it's just silly trying to write anything, even a bad block marker,to 
> > a known bad block in NAND flash.
> >
> > The bad block markers in particular bytes in the OOB area are providedby 
> > the manufacturer to identify "Factory Bad Blocks". That and no more! I 
> > don't know why everybody is trying to interpret them as a general bad 
> > block indicator.
> 
> Why not? It's just another byte within the block.
> 
But on a block that is known to have failed erasure or programming you
cannot rely on being able to program anything reliably. Thus it is
vain to try storing the info that the block is bad within that block
itself.

> The Flash chip reports an error on a write or erase operation if the 
> operation does not complete successfully within certain time constraints, 
> which are grounds for marking a block as unusable, i.e. bad, but usually 
> the block is worn out long before the on-chip write/erase algorithms 
> report errors. Hence a block should really be marked 'bad' while it still 
> is 'good', in a sense.
> 
How do you know that a worn out block will still retain the 'This
block is bad' information?


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________