[PATCH] Make the mtdblock read/write skip the bad nand sector

[PATCH] Make the mtdblock read/write skip the bad nand sector

[Hans Zhang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

 When read/write the nandblock device, it will abort writing if
 there's a bad block, it's reasonable to skip the bad block and
 finish the data writing.
 The data reading procedure should also skip the bad block since
 there's no data write to the block.

--v2:
 use the wrapped mtd_block_isbad instand of mtd->block_isbad

Signed-off-by: Hans Zhang <zhanghonghui@innofidei.com>
---
 drivers/mtd/mtdblock.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
index 485ea75..4f6acd1 100644
--- a/drivers/mtd/mtdblock.c
+++ b/drivers/mtd/mtdblock.c
@@ -124,6 +124,13 @@ static int write_cached_data (struct mtdblk_dev *mtdblk)
 			"at 0x%lx, size 0x%x\n", mtd->name,
 			mtdblk->cache_offset, mtdblk->cache_size);
 
+retry:
+	ret = mtd_block_isbad(mtd, mtdblk->cache_offset);
+	if (ret > 0) {
+		mtdblk->cache_offset += mtdblk->cache_size;
+		goto retry;
+	}
+
 	ret = erase_write (mtd, mtdblk->cache_offset,
 			   mtdblk->cache_size, mtdblk->cache_data);
 	if (ret)
@@ -163,6 +170,11 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
 			size = len;
 
 		if (size == sect_size) {
+			ret = mtd_block_isbad(mtd, pos);
+			if (ret > 0) {
+				pos += sect_size;
+				continue;
+			}
 			/*
 			 * We are covering a whole sector.  Thus there is no
 			 * need to bother with the cache while it may still be
@@ -242,6 +254,11 @@ static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
 		    mtdblk->cache_offset == sect_start) {
 			memcpy (buf, mtdblk->cache_data + offset, size);
 		} else {
+			ret = mtd_block_isbad(mtd, pos);
+			if (ret > 0) {
+				pos += sect_size;
+				continue;
+			}
 			ret = mtd_read(mtd, pos, size, &retlen, buf);
 			if (ret)
 				return ret;
-- 
1.7.1


¡°This E-mail and its attachments may contain legally privileged or confidential information from Innofidei Corporation. Any unauthorized copy, use, disclosure or distribution of this information is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by E-mail or telephone and delete this E-mail and all its attachments immediately.
±¾Óʼþ¼°Æ丽¼þÄÚÈÝ¿ÉÄÜ°üº¬´´Ò㹫˾ÏíÓÐרÓз¨ÂÉȨÀûµÄ»òÕßÐèÒª±£ÃܵÄÐÅÏ¢¡£ÑϽûÈκÎÈËδ¾­·¢¼þÈËÐí¿ÉÒÔÈκÎÐÎʽ¸´ÖÆ¡¢Ê¹Óá¢Åû¶»òÕßÉ¢·¢´ËÏîÐÅÏ¢¡£Èç¹ûÄú²»ÊǸÃÊÕ¼þÈË£¬ÇëÄúÁ¢¼´Í¨¹ýÓʼþ»òÕߵ绰֪ͨ·¢¼þÈ˲¢Á¢¼´É¾³ý±¾Óʼþ¼°Æ丽¼þÄÚÈÝ.¡±

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Richard Genoud]

2013/11/21 Hans Zhang <zhanghonghui@innofidei.com>:
>  When read/write the nandblock device, it will abort writing if
>  there's a bad block, it's reasonable to skip the bad block and
>  finish the data writing.
>  The data reading procedure should also skip the bad block since
>  there's no data write to the block.
>
> --v2:
>  use the wrapped mtd_block_isbad instand of mtd->block_isbad
>
> Signed-off-by: Hans Zhang <zhanghonghui@innofidei.com>
> ---
>  drivers/mtd/mtdblock.c |   17 +++++++++++++++++
>  1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
> index 485ea75..4f6acd1 100644
> --- a/drivers/mtd/mtdblock.c
> +++ b/drivers/mtd/mtdblock.c
> @@ -124,6 +124,13 @@ static int write_cached_data (struct mtdblk_dev *mtdblk)
>                         "at 0x%lx, size 0x%x\n", mtd->name,
>                         mtdblk->cache_offset, mtdblk->cache_size);
>
> +retry:
> +       ret = mtd_block_isbad(mtd, mtdblk->cache_offset);
> +       if (ret > 0) {
> +               mtdblk->cache_offset += mtdblk->cache_size;
> +               goto retry;
> +       }
> +
>         ret = erase_write (mtd, mtdblk->cache_offset,
>                            mtdblk->cache_size, mtdblk->cache_data);
>         if (ret)
> @@ -163,6 +170,11 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
>                         size = len;
>
>                 if (size == sect_size) {
> +                       ret = mtd_block_isbad(mtd, pos);
> +                       if (ret > 0) {
> +                               pos += sect_size;
> +                               continue;
> +                       }
>                         /*
>                          * We are covering a whole sector.  Thus there is no
>                          * need to bother with the cache while it may still be
> @@ -242,6 +254,11 @@ static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
>                     mtdblk->cache_offset == sect_start) {
>                         memcpy (buf, mtdblk->cache_data + offset, size);
>                 } else {
> +                       ret = mtd_block_isbad(mtd, pos);
> +                       if (ret > 0) {
> +                               pos += sect_size;
> +                               continue;
> +                       }
>                         ret = mtd_read(mtd, pos, size, &retlen, buf);
>                         if (ret)
>                                 return ret;
> --
> 1.7.1
>
>

I don't think it's a good idea to skip bad blocks at mtd level.
That will definitely break the userspace.
The nanddump mtd-tool for instance has a bad block handling argument:
--bb=METHOD, where METHOD can be `padbad', `dumpbad', or `skipbad':
    padbad:  dump flash data, substituting 0xFF for any bad blocks
    dumpbad: dump flash data, including any bad blocks
    skipbad: dump good data, completely skipping any bad blocks (default)

The bad block handling is done by the upper layer (UBI/jffs2...) not by mtd.

So, if you really need to read/write the mtd layer from userspace and
jump bad block, you'll have to use the MEMGETBADBLOCK ioctl to check
if the block is bad before reading/writing.

But using UBI is usually a better option.


Richard.

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Ezequiel Garcia]

On Fri, Nov 22, 2013 at 09:22:43AM +0800, Hans Zhang wrote:
> On 2013/11/21 18:59, Richard Genoud wrote:
> 
> Here's my scenario, I want to write nand through mtdblock by dd command

You could get some better support by explaining why do you want to write
to a NAND through mtdblock. It sounds a bit ackward to me, but I'm sure
you have a good reason for it!

Let's hear it :-)
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Richard Weinberger]

On Fri, Nov 22, 2013 at 3:10 AM, Hans Zhang <zhanghonghui@innofidei.com> wrote:
> On 2013/11/22 9:52, Ezequiel Garcia wrote:
>> On Fri, Nov 22, 2013 at 09:22:43AM +0800, Hans Zhang wrote:
>>> On 2013/11/21 18:59, Richard Genoud wrote:
>>>
>>> Here's my scenario, I want to write nand through mtdblock by dd command
>> You could get some better support by explaining why do you want to write
>> to a NAND through mtdblock. It sounds a bit ackward to me, but I'm sure
>> you have a good reason for it!
>>
>> Let's hear it :-)
>
> Thanks for your reply.
> This is for my embed system upgrade, I reserved one nand partition for filesystem
> environment which will load to DDR while uboot booting.
> This filesystem.uboot file should be able to read both by uboot and kernel, and
> maybe written by uboot and kernel. There will be no filesystems upon the nand in
> case the loader may not support some filesystem types while uboot booting.
>
> Seems that the trimmed environment of OS has get rid of the mtd-tools, So the dd
> command was the most convenience tools to use by hand.

Instead of fixing your userspace you mess around int the kernel?
Sorry, that's a no-no.

-- 
Thanks,
//richard

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Ezequiel Garcia]

On Fri, Nov 22, 2013 at 10:10:19AM +0800, Hans Zhang wrote:
> On 2013/11/22 9:52, Ezequiel Garcia wrote:
> > On Fri, Nov 22, 2013 at 09:22:43AM +0800, Hans Zhang wrote:
> >> On 2013/11/21 18:59, Richard Genoud wrote:
> >>
> >> Here's my scenario, I want to write nand through mtdblock by dd command
> > You could get some better support by explaining why do you want to write
> > to a NAND through mtdblock. It sounds a bit ackward to me, but I'm sure
> > you have a good reason for it!
> >
> > Let's hear it :-)
> 
> Thanks for your reply.
> This is for my embed system upgrade, I reserved one nand partition for filesystem
> environment which will load to DDR while uboot booting.
> This filesystem.uboot file should be able to read both by uboot and kernel, and
> maybe written by uboot and kernel. There will be no filesystems upon the nand in
> case the loader may not support some filesystem types while uboot booting.
> 
> Seems that the trimmed environment of OS has get rid of the mtd-tools, So the dd
> command was the most convenience tools to use by hand.
> 

I still don't understand why are you using mtdblock. Why can't you write
through the char device?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Ezequiel Garcia]

On Mon, Nov 25, 2013 at 09:29:11AM +0800, Hans Zhang wrote:
> On 2013/11/22 19:45, Ezequiel Garcia wrote:
> >> Thanks for your reply.
> >> This is for my embed system upgrade, I reserved one nand partition for filesystem
> >> environment which will load to DDR while uboot booting.
> >> This filesystem.uboot file should be able to read both by uboot and kernel, and
> >> maybe written by uboot and kernel. There will be no filesystems upon the nand in
> >> case the loader may not support some filesystem types while uboot booting.
> >>
> >> Seems that the trimmed environment of OS has get rid of the mtd-tools, So the dd
> >> command was the most convenience tools to use by hand.
> >>
> > I still don't understand why are you using mtdblock. Why can't you write
> > through the char device?
> 
> Well, yes, write through the char device would be a solution.

But, *why* are you writing through mtdblock instead?

> I think that maybe it's an optional approach through mtdblock in case we do not have
> the mtd-tools in our environments, we do provider a simpler way to write the NAND
> through mtdblock.
> 

Uh? simpler? Writing through mtdchat is as simple as it gets:

  $ cat some_file.img > /dev/mtd0

Sorry, but I'm still confused at what are you trying to accomplish.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Richard Genoud]

2013/11/25 Ezequiel Garcia <ezequiel.garcia@free-electrons.com>:
> On Mon, Nov 25, 2013 at 09:29:11AM +0800, Hans Zhang wrote:
>> On 2013/11/22 19:45, Ezequiel Garcia wrote:
>> >> Thanks for your reply.
>> >> This is for my embed system upgrade, I reserved one nand partition for filesystem
>> >> environment which will load to DDR while uboot booting.
>> >> This filesystem.uboot file should be able to read both by uboot and kernel, and
>> >> maybe written by uboot and kernel. There will be no filesystems upon the nand in
>> >> case the loader may not support some filesystem types while uboot booting.
>> >>
>> >> Seems that the trimmed environment of OS has get rid of the mtd-tools, So the dd
>> >> command was the most convenience tools to use by hand.
>> >>
>> > I still don't understand why are you using mtdblock. Why can't you write
>> > through the char device?
>>
>> Well, yes, write through the char device would be a solution.
>
> But, *why* are you writing through mtdblock instead?
>
>> I think that maybe it's an optional approach through mtdblock in case we do not have
>> the mtd-tools in our environments, we do provider a simpler way to write the NAND
>> through mtdblock.
>>
>
> Uh? simpler? Writing through mtdchat is as simple as it gets:
>
>   $ cat some_file.img > /dev/mtd0
>
> Sorry, but I'm still confused at what are you trying to accomplish.
I think that what Hans wants to do is:
 $ cat some_file.img > /dev/mtd0
And that doesn't fail on a bad block but jumps over it.
... Which is a bad idea.
But, likeyou, I didn't figured out why mtdblock instead of mtdchar.

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Ezequiel Garcia]

On Mon, Nov 25, 2013 at 07:30:33PM +0800, Hans Zhang wrote:
> On 2013/11/25 18:23, Richard Genoud wrote:
> >
> > Well, yes, write through the char device would be a solution.
> >> But, *why* are you writing through mtdblock instead?
> >>
> >>> I think that maybe it's an optional approach through mtdblock in case we do not have
> >>> the mtd-tools in our environments, we do provider a simpler way to write the NAND
> >>> through mtdblock.
> >>>
> >> Uh? simpler? Writing through mtdchat is as simple as it gets:
> >>
> >>   $ cat some_file.img > /dev/mtd0
> >>
> >> Sorry, but I'm still confused at what are you trying to accomplish.
> > I think that what Hans wants to do is:
> >  $ cat some_file.img > /dev/mtd0
> > And that doesn't fail on a bad block but jumps over it.
> > ... Which is a bad idea.
> > But, likeyou, I didn't figured out why mtdblock instead of mtdchar.
> >
> >
> 
> I'm sorry it's my mistake, I thought the NAND need to be erased explicitly in userspace
> before written when through the mtdchar device. That's why I use the mtdblock instead of
> mtdchar.
> 

Your understanding is correct: NAND *must* be erased explictly in userspace
before writing. However, keep in mind the following additional constraints:

* Writing should be always performed using 'nandwrite',
  not tools such as 'cat' or 'dd'.

* An mtdblock shouldn't be used to access directly the NAND from
  userspace. AFAICS, the primarily usage of mtdblock is to be able to
  mount JFFS2.

Out of curiosity, what's your NAND layout? What FS are you using?
Unless you have some special requirement, you should be using UBI to
access the device (and not MTD).

Just a suggestion...
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[David Woodhouse]

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

On Mon, 2013-11-25 at 08:52 -0300, Ezequiel Garcia wrote:
> 
> Your understanding is correct: NAND *must* be erased explictly in
> userspace
> before writing. However, keep in mind the following additional
> constraints:
> 
> * Writing should be always performed using 'nandwrite',
>   not tools such as 'cat' or 'dd'.
> 
> * An mtdblock shouldn't be used to access directly the NAND from
>   userspace. AFAICS, the primarily usage of mtdblock is to be able to
>   mount JFFS2.

No. You don't need mtdblock to mount JFFS2 at all.

The mtdblock driver was used in the *very* early days of the MTD system,
on NOR flash with a "traditional" file system. Either in read-only mode
for something like cramfs, or in a very unsafe writeable mode. We
actually put ext2 on it for the Compaq iPaq for a while, before we had
JFFS.

It was used as a shortcut for mounting JFFS2, and still is by a lot of
people, but it's certainly not necessary. You can turn off CONFIG_BLOCK
entirely and still use JFFS2.

You should consider mtdblock to be the most basic, primitive, "flash
translation layer" that can possibly exist. And thus, should basically
never use it. I certainly don't approve of trying to extend it.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Ezequiel Garcia]

David,

On Mon, Nov 25, 2013 at 12:16:10PM +0000, David Woodhouse wrote:
> On Mon, 2013-11-25 at 08:52 -0300, Ezequiel Garcia wrote:
> > 
> > Your understanding is correct: NAND *must* be erased explictly in
> > userspace
> > before writing. However, keep in mind the following additional
> > constraints:
> > 
> > * Writing should be always performed using 'nandwrite',
> >   not tools such as 'cat' or 'dd'.
> > 
> > * An mtdblock shouldn't be used to access directly the NAND from
> >   userspace. AFAICS, the primarily usage of mtdblock is to be able to
> >   mount JFFS2.
> 
> No. You don't need mtdblock to mount JFFS2 at all.
> 
> The mtdblock driver was used in the *very* early days of the MTD system,
> on NOR flash with a "traditional" file system. Either in read-only mode
> for something like cramfs, or in a very unsafe writeable mode. We
> actually put ext2 on it for the Compaq iPaq for a while, before we had
> JFFS.
> 
> It was used as a shortcut for mounting JFFS2, and still is by a lot of
> people, but it's certainly not necessary. You can turn off CONFIG_BLOCK
> entirely and still use JFFS2.
> 
> You should consider mtdblock to be the most basic, primitive, "flash
> translation layer" that can possibly exist. And thus, should basically
> never use it. I certainly don't approve of trying to extend it.
> 

Thanks a lot for the insight. After reading this, I'm wondering what's
preventing us from killing MTD block support altogether. Artem, already
suggested it a while back...
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Peter Korsgaard]

>>>>> "Ezequiel" == Ezequiel Garcia <ezequiel.garcia@free-electrons.com> writes:

Hi,

 > Thanks a lot for the insight. After reading this, I'm wondering what's
 > preventing us from killing MTD block support altogether. Artem, already
 > suggested it a while back...

People using squashfs/cramfs/readonly ext2/.. on a NOR flash?

-- 
Bye, Peter Korsgaard

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[David Woodhouse]

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

On Mon, 2013-11-25 at 16:12 +0100, Peter Korsgaard wrote:
> >>>>> "Ezequiel" == Ezequiel Garcia <ezequiel.garcia@free-electrons.com> writes:
> 
> Hi,
> 
>  > Thanks a lot for the insight. After reading this, I'm wondering what's
>  > preventing us from killing MTD block support altogether. Artem, already
>  > suggested it a while back...
> 
> People using squashfs/cramfs/readonly ext2/.. on a NOR flash?

And people who *still*, after all these years, don't realise that they
don't actually need it to mount JFFS2. Even as the root file system
(although they *do* need rootfstype=jffs2).

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Pavel Machek]

Hi!

> > Hi,
> > 
> >  > Thanks a lot for the insight. After reading this, I'm wondering what's
> >  > preventing us from killing MTD block support altogether. Artem, already
> >  > suggested it a while back...
> > 
> > People using squashfs/cramfs/readonly ext2/.. on a NOR flash?
> 
> And people who *still*, after all these years, don't realise that they
> don't actually need it to mount JFFS2. Even as the root file system
> (although they *do* need rootfstype=jffs2).

I must admit I'm such person...

I guess printk("...you don't really need mtdblock...") in jffs2's
mount code would probably improve that realisation...

This certainly does not help:

pavel@amd:/data/l/linux-n900$ grep -ri mtdblock  Documentation
Documentation/frv/booting.txt:	   exec -c "console=ttySM0,115200
ip=:::::dhcp root=/dev/mtdblock2 rw"
Documentation/frv/booting.txt:	 /dev/mtdblock3	Fourth RedBoot
partition on the System Flash
Documentation/arm/SA1100/Assabet:which is the third one.  Within
Linux, this correspond to /dev/mtdblock2.
Documentation/arm/SA1100/Assabet:	exec -b 0x100000 -l 0xc0000 -c
"root=/dev/mtdblock2"

(Should not mtdblock be at least in devices.txt file?)

BTW... is there documentation of mtdblock "translation layer"
somewhere? I realize it is very simple, but it does need to keep some
data?

I guess running jffs on regular block device (USB stick, SD card) is
not feasible?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Brian Norris]

On Fri, Nov 29, 2013 at 02:26:53PM +0100, Pavel Machek wrote:
> > >  > Thanks a lot for the insight. After reading this, I'm wondering what's
> > >  > preventing us from killing MTD block support altogether. Artem, already
> > >  > suggested it a while back...
> > > 
> > > People using squashfs/cramfs/readonly ext2/.. on a NOR flash?
> > 
> > And people who *still*, after all these years, don't realise that they
> > don't actually need it to mount JFFS2. Even as the root file system
> > (although they *do* need rootfstype=jffs2).
> 
> I must admit I'm such person...

Even the Kconfig disagrees with David :)

config MTD_BLOCK
        tristate "Caching block device access to MTD devices"
...
          At the moment, it is also required for the Journalling Flash File
          System(s) to obtain a handle on the MTD device when it's mounted
          (although JFFS and JFFS2 don't actually use any of the functionality
          of the mtdblock device).

The website is more forthcoming, but it still says it's needed for the
rootfs:

  http://linux-mtd.infradead.org/faq/jffs2.html#L_mtdblock

So I suppose we really need to clean this up, eh?

...

> (Should not mtdblock be at least in devices.txt file?)

Probably.

> BTW... is there documentation of mtdblock "translation layer"
> somewhere? I realize it is very simple, but it does need to keep some
> data?

There's a bit scattered around the MTD website, but this FAQ has a
little:

  http://linux-mtd.infradead.org/faq/general.html#L_ext2_mtd

Really, the "translation" is truly dead simple; I believe it is simply
an identity mapping, where the mtd is mapped linearly to the mtdblock.
So address X in /dev/mtdY is address X in /dev/mtdblockY.

> I guess running jffs on regular block device (USB stick, SD card) is
> not feasible?

http://linux-mtd.infradead.org/faq/jffs2.html#L_stick_jffs2

Brian

[PATCH] Make the mtdblock read/write skip the bad nand sector

[Hans Zhang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

 When read/write the nandblock device, it will abort writing if
 there's a bad block, it's reasonable to skip the bad block and
 finish the data writing.
 The data reading procedure should also skip the bad block since
 there's no data write to the block.

Signed-off-by: Hans Zhang <zhanghonghui@innofidei.com>
---
 drivers/mtd/mtdblock.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
index 485ea75..66e3b23 100644
--- a/drivers/mtd/mtdblock.c
+++ b/drivers/mtd/mtdblock.c
@@ -124,6 +124,14 @@ static int write_cached_data (struct mtdblk_dev *mtdblk)
 			"at 0x%lx, size 0x%x\n", mtd->name,
 			mtdblk->cache_offset, mtdblk->cache_size);
 
+retry:
+	if (mtd->block_isbad) {
+		ret = mtd->block_isbad(mtd, mtdblk->cache_offset);
+		if (ret > 0) {
+			mtdblk->cache_offset += mtdblk->cache_size;
+			goto retry;
+		}
+	}
 	ret = erase_write (mtd, mtdblk->cache_offset,
 			   mtdblk->cache_size, mtdblk->cache_data);
 	if (ret)
@@ -163,6 +171,13 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
 			size = len;
 
 		if (size == sect_size) {
+			if (mtd->block_isbad) {
+				ret = mtd->block_isbad(mtd, pos);
+				if (ret > 0) {
+					pos += sect_size;
+					continue;
+				}
+			}
 			/*
 			 * We are covering a whole sector.  Thus there is no
 			 * need to bother with the cache while it may still be
@@ -242,6 +257,13 @@ static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
 		    mtdblk->cache_offset == sect_start) {
 			memcpy (buf, mtdblk->cache_data + offset, size);
 		} else {
+			if (mtd->block_isbad) {
+				ret = mtd->block_isbad(mtd, pos);
+				if (ret > 0) {
+					pos += sect_size;
+					continue;
+				}
+			}
 			ret = mtd_read(mtd, pos, size, &retlen, buf);
 			if (ret)
 				return ret;
-- 
1.7.1


¡°This E-mail and its attachments may contain legally privileged or confidential information from Innofidei Corporation. Any unauthorized copy, use, disclosure or distribution of this information is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by E-mail or telephone and delete this E-mail and all its attachments immediately.
±¾Óʼþ¼°Æ丽¼þÄÚÈÝ¿ÉÄÜ°üº¬´´Ò㹫˾ÏíÓÐרÓз¨ÂÉȨÀûµÄ»òÕßÐèÒª±£ÃܵÄÐÅÏ¢¡£ÑϽûÈκÎÈËδ¾­·¢¼þÈËÐí¿ÉÒÔÈκÎÐÎʽ¸´ÖÆ¡¢Ê¹Óá¢Åû¶»òÕßÉ¢·¢´ËÏîÐÅÏ¢¡£Èç¹ûÄú²»ÊǸÃÊÕ¼þÈË£¬ÇëÄúÁ¢¼´Í¨¹ýÓʼþ»òÕߵ绰֪ͨ·¢¼þÈ˲¢Á¢¼´É¾³ý±¾Óʼþ¼°Æ丽¼þÄÚÈÝ.¡±