MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips
Subsystems (2)
PATCH 1/1 MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips
For large page chips, nand_bbt is looking into OOB area, and checking for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.
But ELBC driver is specifying ecclayout so that oobfree area starts at offset 1, so only one byte left for the bbt purposes.
This causes problems with any OOB users, namely JFFS2: after first mount JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:
OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
And on the next boot, NAND core will rescan for bad blocks, then will see "0xff 0x19" pattern, and will mark all blocks as bad ones.
To fix the issue we should implement our own bad block pattern: just one byte at OOB start.
---
The patch that fixes oobfree will follow, but you have to choice which you'll want to apply (if any), not both.
drivers/mtd/nand/fsl_elbc_nand.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
drivers/mtd/nand/fsl_elbc_nand.c +15 -0
@@ -116,6 +116,20 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = { .oobavail = 48, }; +/* +* fsl_elbc_oob_lp_eccm* specify for LP NANDs that OOB starts at offset 1, so +* we have to adjust bad block pattern (this is for compatiblitywith already +* reflashed devices, otherwise we could fix ecclayout.oobfree instead). +*/ +static u8 scan_ff_pattern[] = {0xff , }; + +static struct nand_bbt_descr largepage_memorybased = { + .options =0 , + .offs =0 , + .len =1 , + .pattern = scan_ff_pattern, +}; +/*=================================*/ /*
@@ -687,6 +701,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd) chip->ecc.layout = (priv->fmr &FMR_ECCM ) ? &fsl_elbc_oob_lp_eccm1 : &fsl_elbc_oob_lp_eccm0; + chip->badblock_pattern = &largepage_memorybased; mtd->ecclayout = chip->ecc.layout; mtd->oobavail = chip->ecc.layout->oobavail; }
Signature · 1 line
1.5.5.4
Quoted 3 lines · Anton Vorontsov
For large page chips,
nand_bbtis looking into OOB area, and checking for "0xff0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.
Interesting... both the 8313 manual and the manual for a random large page NAND chip say that the bad block indicator is one byte.
BTW, I was just looking at NAND boot on this chip, and it seems that it expects ECCM=1 for large page devices, so we should make that the default (preferably at the same time as we fix this problem, so that we don't break compatibility with a working version).
-Scott
Quoted 7 lines · Scott Wood
Quoted 3 lines · Anton Vorontsov
For large page chips,
nand_bbtis looking into OOB area, and checking for "0xff0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.Interesting... both the 8313 manual and the manual for a random large page NAND chip say that the bad block indicator is one byte.
Ok, great. If I understood David correctly, second byte is used (by some chips?) for redundancy, thus should not be a big problem if we'll ignore it. So, would you ack this part? Then I'll resend it with some typos fixed. ;-)
Quoted 4 lines
BTW, I was just looking at NAND boot on this chip, and it seems that it expects ECCM=1 for large page devices, so we should make that the default (preferably at the same time as we fix this problem, so that we don't break compatibility with a working version).
Ugh. I think driver should support both. If we'll change (force) this in Linux, we'll break older u-boots (especially FSL U-Boots with NAND support enabled). I believe that simply changing ECCM to 1 in the newer community u-boots would be less pain for everybody, no?
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Scott Wood
Acked-byQuoted 11 lines · Anton Vorontsov
Quoted 5 lines · Scott Wood
Quoted 3 lines · Anton Vorontsov
For large page chips,
nand_bbtis looking into OOB area, and checking for "0xff0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.Interesting... both the 8313 manual and the manual for a random large page NAND chip say that the bad block indicator is one byte.
Ok, great. If I understood David correctly, second byte is used (by some chips?) for redundancy, thus should not be a big problem if we'll ignore it. So, would you ack this part? Then I'll resend it with some typos fixed. ;-)
Quoted 5 lines
Quoted 1 line
BTW, I was just looking at NAND boot on this chip, and it seems that it expects ECCM=1 for large page devices, so we should make that the default (preferably at the same time as we fix this problem, so that we don't break compatibility with a working version).
Ugh. I think driver should support both. If we'll change (force) this in Linux, we'll break older u-boots (especially FSL U-Boots with NAND support enabled).
I'm not aware of a Freescale board with large page NAND...
Quoted 2 lines
I believe that simply changing ECCM to 1 in the newer community u-boots would be less pain for everybody, no?
OK, though we'll have to load the existing FMR[ECCM] into priv->fmr on init, rather than starting with zero.
-Scott
Quoted 9 lines · Scott Wood
Quoted 8 lines · Anton Vorontsov
Quoted 6 lines · Scott Wood
Quoted 3 lines · Anton Vorontsov
For large page chips,
nand_bbtis looking into OOB area, and checking for "0xff0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.Interesting... both the 8313 manual and the manual for a random large
page NAND chip say that the bad block indicator is one byte.
Quoted 6 lines
Quoted 4 lines
Ok, great. If I understood David correctly, second byte is used (by some chips?) for redundancy, thus should not be a big problem if we'll ignore it. So, would you ack this part? Then I'll resend it with some typos fixed. ;-)
Acked-by Scott Wood <[email protected]>
Thanks, but it seems we can't ignore the second byte. :-( See the patch I just sent.
Quoted 10 lines
Quoted 8 lines
Quoted 4 lines
BTW, I was just looking at NAND boot on this chip, and it seems that it expects ECCM=1 for large page devices, so we should make that the
default (preferably at the same time as we fix this problem, so that
we don't break compatibility with a working version).Ugh. I think driver should support both. If we'll change (force) this in Linux, we'll break older u-boots (especially FSL U-Boots with NAND support enabled).
I'm not aware of a Freescale board with large page NAND...
MPC8610HPCD comes with 1*4GB LP NAND.
Quoted 5 lines
Quoted 2 lines
I believe that simply changing ECCM to 1 in the newer community u-boots would be less pain for everybody, no?
OK, though we'll have to load the existing FMR[ECCM] into
priv->fmron init, rather than starting with zero.
Yeah. But this is another issue.
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Quoted 15 lines · Anton Vorontsov
For large page chips,
nand_bbtis looking into OOB area, and checking for "0xff0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.But ELBC driver is specifying ecclayout so that oobfree area starts at offset 1, so only one byte left for the bbt purposes.
This causes problems with any OOB users, namely JFFS2: after first mount JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:
OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Quoted 7 lines
And on the next boot, NAND core will rescan for bad blocks, then will see "
0xff0x19" pattern, and will mark all blocks as bad ones.To fix the issue we should implement our own bad block pattern: just one byte at OOB start.
Anton,
the problem with bad block markers is that if they are set, _nothing_ is guaranteed to work with that block. You cannot assume that it is possible to relocate the BB marker into the first byte, if the second one is set. If you don't relocate it, your new pattern will fail to find the bad block.
Most manufacturers use the first OOB byte in one of the first two pages in a block as the BB marker. Others use, as you noticed, the first two OOB bytes of the first and possibly second page of a block.
The point is that if the marker is set, nothing can be done with that block. You must not touch it.
To make things worse, some hardware NAND controllers *require* you to place the ECC immediately after the data area. That's right, straight over the BB marker locations.
The solution to your and other similar problems is to use a Bad Block Table (BBT) at the end of the NAND. When your device comes up for the first time, it must scan the NAND for bad blocks, and then write this information into the BBT.
In all consecutive boots, the device must always use the BBT and not scan again.
The algorithm, as implemented e.g. in U-Boot and the Linux kernel is to look for a valid BBT first and only go scanning if it doesn't exist. After the scan, the BBT is written and available next time.
You just need to set the correct flags in your low-level NAND driver.
Kind regards,
Iwo
PATCH 1/1 MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT
This patch implements support for flash-based BBT for chips working through ELBC NAND controller, so that NAND core will not have to re-scan for bad blocks on every boot.
Because ELBC controller may provide HW-generated ECCs we should adjust bbt pattern and bbt version positions in the OOB free area.
The patch is mandatory for JFFS2 to work on large page NANDs connected through the ELBC, since it workarounds ecclayout.oobfree first value:
after BBT has been created, BBT tracking code will not look for bad block pattern anymore.
---
Quoted 23 lines · Iwo Mergler
Quoted 15 lines · Anton Vorontsov
For large page chips,
nand_bbtis looking into OOB area, and checking for "0xff0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.But ELBC driver is specifying ecclayout so that oobfree area starts at offset 1, so only one byte left for the bbt purposes.
This causes problems with any OOB users, namely JFFS2: after first mount JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:
OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Quoted 7 lines
And on the next boot, NAND core will rescan for bad blocks, then will see "
0xff0x19" pattern, and will mark all blocks as bad ones.To fix the issue we should implement our own bad block pattern: just one byte at OOB start.
Quoted 7 lines
Anton,
the problem with bad block markers is that if they are set, _nothing_ is guaranteed
to work with that block. You cannot assume that it is possible to relocate the BB
marker into the first byte, if the second one is set.
Just looked into x16 LP NAND spec, and it says that block should be considered as bad when the first _Word_ isn't 0xff. So we indeed should not ignore the second byte. Ouch.
How about this patch?
drivers/mtd/nand/fsl_elbc_nand.c | 34 +++++++++++++++++++++++++++++++++- 1 files changed, 33 insertions(+), 1 deletions(-)
drivers/mtd/nand/fsl_elbc_nand.c +33 -1
@@ -116,6 +116,34 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = { .oobavail = 48, }; +/* +* ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt, +* interfere with ECC positions, that's why we implement our own descriptors. +* OOB {11, 5}, works for both SP and LP chips, with ECCM = 1 and ECCM = 0. +*/ +static u8 bbt_pattern[] = {'B' ,'b' ,'t' ,'0' }; +static u8 mirror_pattern[] = {'1' ,'t' ,'b' ,'B' }; + +static struct nand_bbt_descr bbt_main_descr = { + .options =NAND_BBT_LASTBLOCK |NAND_BBT_CREATE |NAND_BBT_WRITE | +NAND_BBT_2BIT |NAND_BBT_VERSION , + .offs =11 , + .len =4 , + .veroffs =15 , + .maxblocks =4 , + .pattern = bbt_pattern, +}; + +static struct nand_bbt_descr bbt_mirror_descr = { + .options =NAND_BBT_LASTBLOCK |NAND_BBT_CREATE |NAND_BBT_WRITE | +NAND_BBT_2BIT |NAND_BBT_VERSION , + .offs =11 , + .len =4 , + .veroffs =15 , + .maxblocks =4 , + .pattern = mirror_pattern, +}; +/*=================================*/ /*
@@ -752,8 +780,12 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv) chip->cmdfunc = fsl_elbc_cmdfunc; chip->waitfunc = fsl_elbc_wait; + chip->bbt_td = &bbt_main_descr; + chip->bbt_md = &bbt_mirror_descr; +/* set up nand options */ - chip->options =NAND_NO_READRDY |NAND_NO_AUTOINCR ; + chip->options =NAND_NO_READRDY |NAND_NO_AUTOINCR | +NAND_USE_FLASH_BBT ; chip->controller = &ctrl->controller; chip->priv = priv;
Signature · 1 line
1.5.5.4
Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT
Quoted 3 lines · Anton Vorontsov
Just looked into x16 LP NAND spec, and it says that block should be considered as bad when the first _Word_ isn't
0xff. So we indeed should not ignore the second byte. Ouch.
The FCM doesn't support 16-bit devices.
Quoted 1 line
How about this patch?
ACK
-Scott
Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT
Quoted 6 lines · Scott Wood
Quoted 3 lines · Anton Vorontsov
Just looked into x16 LP NAND spec, and it says that block should be considered as bad when the first _Word_ isn't
0xff. So we indeed should not ignore the second byte. Ouch.The FCM doesn't support 16-bit devices.
And will never support? Then maybe, in addition, we could apply the first patch that you've acked so we'll unbreak NANDs for pour souls that tried to reflash the JFFS2 into NAND, so that they'll will not have to "nand scrub" their NANDs?
Quoted 3 lines
Quoted 1 line
How about this patch?
ACK
Thanks,
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT
Quoted 8 lines · Anton Vorontsov
Quoted 5 lines · Scott Wood
Quoted 3 lines · Anton Vorontsov
Just looked into x16 LP NAND spec, and it says that block should be considered as bad when the first _Word_ isn't
0xff. So we indeed should not ignore the second byte. Ouch.The FCM doesn't support 16-bit devices.
And will never support?
It's a hardware limitation in current chips (see the manual description of BRn[PS]), though upon further looking it seems that it may be supported in the future.
Quoted 4 lines
Then maybe, in addition, we could apply the first
patch that you've acked so we'll unbreak NANDs for pour souls that tried to reflash the JFFS2 into NAND, so that they'll will not have to "nand scrub" their NANDs?
OK -- we can limit it to 8-bit chips once 16-bit support is added to the driver.
-Scott
Re: [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT
Quoted 14 lines · Scott Wood
Quoted 8 lines · Anton Vorontsov
Quoted 5 lines · Scott Wood
Quoted 3 lines · Anton Vorontsov
Just looked into x16 LP NAND spec, and it says that block should be considered as bad when the first _Word_ isn't
0xff. So we indeed should not ignore the second byte. Ouch.The FCM doesn't support 16-bit devices.
And will never support?
It's a hardware limitation in current chips (see the manual description of BRn[PS]), though upon further looking it seems that it may be supported in the future.
Quoted 7 lines
Quoted 4 lines
Then maybe, in addition, we could apply the first
patch that you've acked so we'll unbreak NANDs for pour souls that tried to reflash the JFFS2 into NAND, so that they'll will not have to "nand scrub" their NANDs?OK -- we can limit it to 8-bit chips once 16-bit support is added to the driver.
Great. So.. the final patchset.
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
PATCH 1/3 MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips
For large page chips, nand_bbt is looking into OOB area, and checking for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be reserved for bbt means.
But ELBC driver is specifying ecclayout so that oobfree area starts at offset 1, so only one byte left for the bbt purposes.
This causes problems with any OOB users, namely JFFS2: after first mount JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:
OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
And on the next boot, NAND core will rescan for bad blocks, then will see "0xff 0x19" pattern, and will mark all blocks as bad ones.
To fix the issue we should implement our own bad block pattern: just one byte at OOB start. Though, this will work only for x8 chips. For x16 chips two bytes must be checked. Since ELBC driver does not support x16 NANDs (yet), we're safe for now.
--- drivers/mtd/nand/fsl_elbc_nand.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
drivers/mtd/nand/fsl_elbc_nand.c +15 -0
@@ -116,6 +116,20 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = { .oobavail = 48, }; +/* +* fsl_elbc_oob_lp_eccm* specify that LP NAND's OOB free area starts at offset +* 1, so we have to adjust bad block pattern. This pattern should be used for +* x8 chips only. So far hardware does not support x16 chips anyway. +*/ +static u8 scan_ff_pattern[] = {0xff , }; + +static struct nand_bbt_descr largepage_memorybased = { + .options =0 , + .offs =0 , + .len =1 , + .pattern = scan_ff_pattern, +}; +/*=================================*/ /*
@@ -687,6 +701,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd) chip->ecc.layout = (priv->fmr &FMR_ECCM ) ? &fsl_elbc_oob_lp_eccm1 : &fsl_elbc_oob_lp_eccm0; + chip->badblock_pattern = &largepage_memorybased; mtd->ecclayout = chip->ecc.layout; mtd->oobavail = chip->ecc.layout->oobavail; }
Signature · 1 line
1.5.5.4
PATCH 2/3 MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT
In reply to Anton VorontsovThis patch implements support for flash-based BBT for chips working through ELBC NAND controller, so that NAND core will not have to re-scan for bad blocks on every boot.
Because ELBC controller may provide HW-generated ECCs we should adjust bbt pattern and bbt version positions in the OOB free area.
--- drivers/mtd/nand/fsl_elbc_nand.c | 34 +++++++++++++++++++++++++++++++++- 1 files changed, 33 insertions(+), 1 deletions(-)
drivers/mtd/nand/fsl_elbc_nand.c +33 -1
@@ -130,6 +130,34 @@ static struct nand_bbt_descr largepage_memorybased = { .pattern = scan_ff_pattern, }; +/* +* ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt, +* interfere with ECC positions, that's why we implement our own descriptors. +* OOB {11, 5}, works for both SP and LP chips, with ECCM = 1 and ECCM = 0. +*/ +static u8 bbt_pattern[] = {'B' ,'b' ,'t' ,'0' }; +static u8 mirror_pattern[] = {'1' ,'t' ,'b' ,'B' }; + +static struct nand_bbt_descr bbt_main_descr = { + .options =NAND_BBT_LASTBLOCK |NAND_BBT_CREATE |NAND_BBT_WRITE | +NAND_BBT_2BIT |NAND_BBT_VERSION , + .offs =11 , + .len =4 , + .veroffs =15 , + .maxblocks =4 , + .pattern = bbt_pattern, +}; + +static struct nand_bbt_descr bbt_mirror_descr = { + .options =NAND_BBT_LASTBLOCK |NAND_BBT_CREATE |NAND_BBT_WRITE | +NAND_BBT_2BIT |NAND_BBT_VERSION , + .offs =11 , + .len =4 , + .veroffs =15 , + .maxblocks =4 , + .pattern = mirror_pattern, +}; +/*=================================*/ /*
@@ -767,8 +795,12 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv) chip->cmdfunc = fsl_elbc_cmdfunc; chip->waitfunc = fsl_elbc_wait; + chip->bbt_td = &bbt_main_descr; + chip->bbt_md = &bbt_mirror_descr; +/* set up nand options */ - chip->options =NAND_NO_READRDY |NAND_NO_AUTOINCR ; + chip->options =NAND_NO_READRDY |NAND_NO_AUTOINCR | +NAND_USE_FLASH_BBT ; chip->controller = &ctrl->controller; chip->priv = priv;
Signature · 1 line
1.5.5.4
PATCH 3/3 MTD: NAND: fsl_elbc_nand: ecclayout cleanups
In reply to Anton VorontsovThis patch deletes oobavail assignments, they're calculated by the nand core code in nand_scan_tail, plus current oobavail values are wrong for the LP NANDs.
Also remove mtd->ecclayout and mtd->oobavail assignments, mtd core handles this all by itself.
--- drivers/mtd/nand/fsl_elbc_nand.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)
drivers/mtd/nand/fsl_elbc_nand.c +0 -6
@@ -89,7 +89,6 @@ static struct nand_ecclayout fsl_elbc_oob_sp_eccm0 = { .eccbytes = 3, .eccpos = {6, 7, 8}, .oobfree = { {0, 5}, {9, 7} }, - .oobavail = 12, };/* Small Page FLASH with FMR[ECCM] = 1 */
@@ -97,7 +96,6 @@ static struct nand_ecclayout fsl_elbc_oob_sp_eccm1 = { .eccbytes = 3, .eccpos = {8, 9, 10}, .oobfree = { {0, 5}, {6, 2}, {11, 5} }, - .oobavail = 12, };/* Large Page FLASH with FMR[ECCM] = 0 */
@@ -105,7 +103,6 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm0 = { .eccbytes = 12, .eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56}, .oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7} }, - .oobavail = 48, };/* Large Page FLASH with FMR[ECCM] = 1 */
@@ -113,7 +110,6 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = { .eccbytes = 12, .eccpos = {8, 9, 10, 24, 25, 26, 40, 41, 42, 56, 57, 58}, .oobfree = { {1, 7}, {11, 13}, {27, 13}, {43, 13}, {59, 5} }, - .oobavail = 48, };/*
@@ -730,8 +726,6 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd) &fsl_elbc_oob_lp_eccm1 : &fsl_elbc_oob_lp_eccm0; chip->badblock_pattern = &largepage_memorybased; - mtd->ecclayout = chip->ecc.layout; - mtd->oobavail = chip->ecc.layout->oobavail; } }else { dev_err(ctrl->dev,
Signature · 1 line
1.5.5.4
Re: [PATCH 3/3] MTD: NAND: fsl_elbc_nand: ecclayout cleanups
Quoted 8 lines · Anton Vorontsov
This patch deletes oobavail assignments, they're calculated by the nand core code in
nand_scan_tail, plus current oobavail values are wrong for the LP NANDs.Also remove
mtd->ecclayoutandmtd->oobavailassignments, mtd core handles this all by itself.Signed-off-by Anton Vorontsov <[email protected]>
ACK
-Scott