mtd/gpmi : add BBT support to gpmi nand driver
Subsystems (2)
PATCH v3 1/1 mtd/gpmi : add BBT support to gpmi nand driver
Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.
--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 2 ++ include/linux/mtd/gpmi-nand.h | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-)
drivers/mtd/nand/gpmi-nand/gpmi-nand.c +2 -0
@@ -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 ;
include/linux/mtd/gpmi-nand.h +2 -0
@@ -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
Signature · 1 line
1.7.0.4
PATCH v3 1/1 mtd/gpmi : add BBT support to gpmi nand driver
Quoted 35 lines
Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.Signed-off-by Huang Shijie <[email protected]>--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 2 ++ include/linux/mtd/gpmi-nand.h | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-)(quoted diff) +0
-0
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.cindex 493ec2f..4d369df 100644drivers/mtd/nand/gpmi-nand/gpmi-nand.c +2
-0@@ -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 ;include/linux/mtd/gpmi-nand.h +0
-0@@ -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.
*/
structgpmi_nand_platform_data{include/linux/mtd/gpmi-nand.h +0
-0/* SoC hardware information. */
include/linux/mtd/gpmi-nand.h struct gpmi_nand_platform_data { · line 70
Quoted 6 lines
include/linux/mtd/gpmi-nand.h +1
-0@@ -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 1/1 mtd/gpmi : add BBT support to gpmi nand driver
In reply to Huang ShijieQuoted 4 lines · Huang Shijie
Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.Signed-off-by Huang Shijie <[email protected]>
I'd think you won't be able to mark blocks bad, though. Will send a patch in a minute. Please test.
Quoted 41 lines
--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 2 ++ include/linux/mtd/gpmi-nand.h | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-)drivers/mtd/nand/gpmi-nand/gpmi-nand.c +2
-0@@ -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 ;include/linux/mtd/gpmi-nand.h +2
-0@@ -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 Signature · 1 line
1.7.0.4
Signature · 9 lines
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>
PATCH v3 1/1 mtd/gpmi : add BBT support to gpmi nand driver
Quoted 10 lines · Wolfram Sang
Quoted 4 lines · Huang Shijie
Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.Signed-off-by Huang Shijie <[email protected]>Reviewed-by Wolfram Sang <[email protected]>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.
Signature · 20 lines
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.
PATCH v3 1/1 mtd/gpmi : add BBT support to gpmi nand driver
Hi,
Quoted 12 lines · Artem
Quoted 10 lines · Wolfram Sang
Quoted 4 lines · Huang Shijie
Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.Signed-off-by Huang Shijie <[email protected]>Reviewed-by Wolfram Sang <[email protected]>I'd think you won't be able to mark blocks bad, though. Will send a patch in a minute. Please test.
Quoted 8 lines
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
Signature · 9 lines
___________________________________________________________ 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 ___________________________________________________________
PATCH v3 1/1 mtd/gpmi : add BBT support to gpmi nand driver
Quoted 9 lines · Lothar Wa?mann
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
Signature · 3 lines
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 1/1 mtd/gpmi : add BBT support to gpmi nand driver
Hi,
Quoted 8 lines · Ricard Wanderlof
Quoted 5 lines · Lothar Wa?mann
Hi,
IMO it's just silly trying to write anything, even a bad block marker,to a known bad block in NAND flash.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
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
Signature · 9 lines
___________________________________________________________ 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 ___________________________________________________________