[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Lothar Waßmann]

Hi,

with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
encountered some problems with jffs2 when overwriting pages that have
been written with 0xff (e.g. from padding from the file system image
file).

The problem is that the ECC info for an all-0xff block is not all-0xff
and thus a newly erased block is different from a block that has been
written with 0xff.
If such a block is being altered (jffs2 thinking it can simply
overwrite it without erasing first) the ECC information will be
corrupted and will produce ECC errors upon read.

The only remedy I can think of is to prevent empty pages from actually
being written to flash, but leaving them in the erased state instead.

Any comments?


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
___________________________________________________________

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Ivan Djelic]

On Mon, Jul 18, 2011 at 02:13:27PM +0100, Lothar Wa?mann wrote:
> Hi,
> 
> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> encountered some problems with jffs2 when overwriting pages that have
> been written with 0xff (e.g. from padding from the file system image
> file).
> 
> The problem is that the ECC info for an all-0xff block is not all-0xff
> and thus a newly erased block is different from a block that has been
> written with 0xff.
> If such a block is being altered (jffs2 thinking it can simply
> overwrite it without erasing first) the ECC information will be
> corrupted and will produce ECC errors upon read.

Hello Lothar,

Can you describe more precisely what is happening ? How did you come to the
conclusion that JFFS2 "thinks it can simply overwrite a block without erasing it
first" ?

JFFS2 normally marks a block as clean just after it has erased it; it won't
blindly assume a block is erased and write to it.

I am not very familiar with how JFFS2 metadata work, but I doubt it would
confuse a blank page with a page containing a piece of file with 0xff bytes.

Are you sure your gpmi-nfc driver is not writing ECC info when JFFS2 writes its
cleanmarker, like in the issue previously discussed in
http://lists.infradead.org/pipermail/linux-mtd/2011-June/036538.html ?

BR,

Ivan

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Lothar Waßmann]

Hi,

Ivan Djelic writes:
> On Mon, Jul 18, 2011 at 02:13:27PM +0100, Lothar Wa?mann wrote:
> > Hi,
> > 
> > with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> > encountered some problems with jffs2 when overwriting pages that have
> > been written with 0xff (e.g. from padding from the file system image
> > file).
> > 
> > The problem is that the ECC info for an all-0xff block is not all-0xff
> > and thus a newly erased block is different from a block that has been
> > written with 0xff.
> > If such a block is being altered (jffs2 thinking it can simply
> > overwrite it without erasing first) the ECC information will be
> > corrupted and will produce ECC errors upon read.
> 
> Hello Lothar,
> 
> Can you describe more precisely what is happening ? How did you come to the
> conclusion that JFFS2 "thinks it can simply overwrite a block without erasing it
> first" ?
> 
I'm writing a JFFS2 image file that is padded with 0xff to eraseblock
size to flash (either from the bootloader or with the nandwrite
utility from Linux).
When mounting the filesystem everything is OK until the first file is
being written. A subsequent read of the affected flash page gives ECC
errors.

JFFS2 is giving out the first all-FF page in the last used block for
creating the new file. Since that block has a non-FF ECC pattern, the
ECC information is being corrupted on write.

> JFFS2 normally marks a block as clean just after it has erased it; it won't
> blindly assume a block is erased and write to it.
> 
The GPMI driver does not allow the OOB area to be written, so JFFS2
cannot and does not use cleanmarkers.
I applied a patch that is distributed by Freescale with their BSPs
that prevents the OOB area from being used by JFFS2:
http://git.tqc.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git;a=commitdiff;h=93c3823f2fdb889ad9a56fc4bb926f952c2c5dba

> I am not very familiar with how JFFS2 metadata work, but I doubt it would
> confuse a blank page with a page containing a piece of file with 0xff bytes.
> 
> Are you sure your gpmi-nfc driver is not writing ECC info when JFFS2 writes its
> cleanmarker, like in the issue previously discussed in
> http://lists.infradead.org/pipermail/linux-mtd/2011-June/036538.html ?
> 
No. The ECC is written by the bootloader (or nandwrite utility) when
the image file is initially programmed. I have checked that by dumping
the flash contents right after writing the image file.


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
___________________________________________________________

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Ivan Djelic]

On Tue, Jul 19, 2011 at 06:59:46AM +0100, Lothar Wa?mann wrote:
> I'm writing a JFFS2 image file that is padded with 0xff to eraseblock
> size to flash (either from the bootloader or with the nandwrite
> utility from Linux).
> When mounting the filesystem everything is OK until the first file is
> being written. A subsequent read of the affected flash page gives ECC
> errors.
> 
> JFFS2 is giving out the first all-FF page in the last used block for
> creating the new file. Since that block has a non-FF ECC pattern, the
> ECC information is being corrupted on write.

OK, thanks for the clarification. So the problem only happens on partially
programmed blocks in the JFFS2 image, that end up fully programmed on the
device because of the 0xff padding.

I think the cleaner solution is to use a non-padded image and avoid programming
pages with 0xff in the last used block; programming nand pages multiple times
should be avoided if possible, as it is not supported on all (especially the
most recent) devices.

BR,

--
Ivan

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Shawn Guo]

On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> Hi,
> 
> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I

To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).

Regards,
Shawn

> encountered some problems with jffs2 when overwriting pages that have
> been written with 0xff (e.g. from padding from the file system image
> file).
> 
> The problem is that the ECC info for an all-0xff block is not all-0xff
> and thus a newly erased block is different from a block that has been
> written with 0xff.
> If such a block is being altered (jffs2 thinking it can simply
> overwrite it without erasing first) the ECC information will be
> corrupted and will produce ECC errors upon read.
> 
> The only remedy I can think of is to prevent empty pages from actually
> being written to flash, but leaving them in the erased state instead.
> 
> Any comments?
> 
> 
> 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
> ___________________________________________________________
> 

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Huang Shijie]

hi  Lothar:
> On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
>> Hi,
>>
>> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
>
> Regards,
> Shawn
>
>> encountered some problems with jffs2 when overwriting pages that have
>> been written with 0xff (e.g. from padding from the file system image
>> file).
The GPMI driver now does not support the JFFS2 very well.
The JFFS2 will write the OOB, while the BCH of GPMI will use the OOB too.
So I have to disable the JFFS2 to use the OOB. I have not finish the 
code about it now.

I recommend you use the UBIFS. But the latest version of GPMI driver 
meets a DMA bug.
I am debugging the DMA bug now. and I will send it out when i fix it.

Best Regards
Huang Shijie

>> The problem is that the ECC info for an all-0xff block is not all-0xff
>> and thus a newly erased block is different from a block that has been
>> written with 0xff.
>> If such a block is being altered (jffs2 thinking it can simply
>> overwrite it without erasing first) the ECC information will be
>> corrupted and will produce ECC errors upon read.
>>
>> The only remedy I can think of is to prevent empty pages from actually
>> being written to flash, but leaving them in the erased state instead.
>>
>> Any comments?
>>
>>
>> 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
>> ___________________________________________________________
>>

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Lothar Waßmann]

Hi,

Huang Shijie writes:
> hi  Lothar:
> > On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> >> Hi,
> >>
> >> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> > To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
> >
> > Regards,
> > Shawn
> >
> >> encountered some problems with jffs2 when overwriting pages that have
> >> been written with 0xff (e.g. from padding from the file system image
> >> file).
> The GPMI driver now does not support the JFFS2 very well.
> The JFFS2 will write the OOB, while the BCH of GPMI will use the OOB too.
>
I have applied a patch (from the Freescale BSPs) that prevents JFFS2
from using the OOB area. But this still doesn't help.

> So I have to disable the JFFS2 to use the OOB. I have not finish the 
> code about it now.
> 
> I recommend you use the UBIFS. But the latest version of GPMI driver 
> meets a DMA bug.
> I am debugging the DMA bug now. and I will send it out when i fix it.
> 
What sort of DMA bug?


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
___________________________________________________________

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Huang Shijie]

? 2011?07?19? 14:02, Lothar Wa?mann ??:
> Hi,
>
> Huang Shijie writes:
>> hi  Lothar:
>>> On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
>>>> Hi,
>>>>
>>>> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
>>> To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
>>>
>>> Regards,
>>> Shawn
>>>
>>>> encountered some problems with jffs2 when overwriting pages that have
>>>> been written with 0xff (e.g. from padding from the file system image
>>>> file).
>> The GPMI driver now does not support the JFFS2 very well.
>> The JFFS2 will write the OOB, while the BCH of GPMI will use the OOB too.
>>
> I have applied a patch (from the Freescale BSPs) that prevents JFFS2
> from using the OOB area. But this still doesn't help.
>
Could you show the log ?

>> So I have to disable the JFFS2 to use the OOB. I have not finish the
>> code about it now.
>>
>> I recommend you use the UBIFS. But the latest version of GPMI driver
>> meets a DMA bug.
>> I am debugging the DMA bug now. and I will send it out when i fix it.
>>
> What sort of DMA bug?
>

The DMA may time-out. :(

The DMA time-out may occur in two situations:
[1] send a command DMA descriptor, see the nfc->send_command() function.
[2] read the non-ecc data from nand, see the nfc->read_data() function.

I don't know why. Maybe caused by the timing, or something else.

Best Regards
Huang Shijie

> Lothar Wa?mann

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Lothar Waßmann]

Hi,

Huang Shijie writes:
> ? 2011?07?19? 14:02, Lothar Wa?mann ??:
> > Hi,
> >
> > Huang Shijie writes:
> >> hi  Lothar:
> >>> On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> >>>> Hi,
> >>>>
> >>>> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> >>> To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
> >>>
> >>> Regards,
> >>> Shawn
> >>>
> >>>> encountered some problems with jffs2 when overwriting pages that have
> >>>> been written with 0xff (e.g. from padding from the file system image
> >>>> file).
> >> The GPMI driver now does not support the JFFS2 very well.
> >> The JFFS2 will write the OOB, while the BCH of GPMI will use the OOB too.
> >>
> > I have applied a patch (from the Freescale BSPs) that prevents JFFS2
> > from using the OOB area. But this still doesn't help.
> >
> Could you show the log ?
> 
On the host:
  mkfs.jffs2 -o ../rootfs.img -n -e 0x20000 -p -r .
The last block gets padded with a stretch of 91840 bytes of 0xff.
On the target:
  flash_eraseall  /dev/mtd2
  nandwrite /dev/mtd2 /rootfs-jffs2.image
The raw data of the last used block in flash looks like this
afterwards:
  nanddump -n -p -l 0x800 -s 0x889800 /dev/mtd2
|Block size 131072, page size 2048, OOB size 64
|Dumping data starting at 0x00889800 and ending at 0x0088a000...
|0x00889800: ff ff ff ff ff ff ff ff ff ff b7 00 00 00 f2 00
|0x00889810: 00 00 06 00 00 00 7f ca a1 e3 e4 1f e9 24 78 5e
|0x00889820: 34 8f 41 0e 83 30 0c 04 ef 7d 85 25 ae 6d f3 8e
|0x00889830: de fb 81 10 0c b1 08 76 e4 18 10 bf af 83 d4 93
|0x00889840: 2d 6b 67 77 3d c0 37 53 83 99 0a 82 cf 76 6d 85
|0x00889850: 78 c5 09 4c 20 a0 a5 a0 d8 a4 1c ef 24 3c 3f 06
|0x00889860: f8 58 57 ad 58 7d 32 84 23 6a d0 9d c3 94 53 4d
|0x00889870: a1 33 23 42 1c dd cb d7 4d 76 36 b0 8c a0 22 36
|0x00889880: 37 c7 15 e3 f4 12 2e 17 9c b9 27 56 77 47 3d 88
|0x00889890: 97 5b 57 a5 35 1a a9 90 5d dd 20 c7 c3 4b 99 53
|0x008898a0: a7 92 19 b2 3b 8c 17 dc 61 d3 13 68 be 21 46 3b
|0x008898b0: 45 57 e8 0d 69 d9 35 1a 09 f7 96 ff 83 3f f3 13
|0x008898c0: 40 69 f9 45 0a 2e 1e ce 01 7a 5c ca 5c 00 01 06
|0x008898d0: 00 2b 56 54 c6 ff 85 19 01 e0 2f 00 00 00 b1 f9
|0x008898e0: 44 f2 c2 03 00 00 d5 03 00 00 c8 03 00 00 a7 ac
|0x008898f0: e3 4d 07 08 00 00 55 81 af 84 e8 5f 94 39 79 70
|0x00889900: 2e 63 6f 6e 66 ff 85 19 02 e0 44 00 00 00 1d fb
|0x00889910: f7 98 c8 03 00 00 01 00 00 00 a4 81 00 00 00 00
|0x00889920: 00 00 00 00 00 00 a7 ac e3 4d a7 ac e3 4d a7 ac
|0x00889930: e3 4d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|0x00889940: 00 00 00 00 00 00 13 77 d1 ba ff ff ff ff ff ff
|0x00889950: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[...]
|0x00889a00: ff ff ff ff ff ff ff ff ff ff 27 21 37 1b 06 87
|0x00889a10: 70 f1 00 0e 6a 8e 57 ff ff ff ff ff ff ff ff ff
|0x00889a20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[...]
|0x00889c10: ff ff ff ff ff ff ff 08 75 8b 6f 48 36 a6 bc 16
|0x00889c20: 61 58 db 52 ff ff ff ff ff ff ff ff ff ff ff ff
|0x00889c30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[...]
|0x00889e20: ff ff ff ff 08 75 8b 6f 48 36 a6 bc 16 61 58 db
|0x00889e30: 52 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|0x00889e40: 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
|  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|  OOB Data: ff 08 75 8b 6f 48 36 a6 bc 16 61 58 db 52 00 00

The remaining pages of this block are all-FF except for the ecc
pattern as above.

Checking the readability of the whole flash partition shows no errors:
  dd if=/dev/mtdblock2 of=/dev/null
|32768+0 records in
|32768+0 records out
|16777216 bytes (17 MB) copied, 18.6754 s, 898 kB/s

Mounting the partition and writing some file produces ecc errors upon
successive reads:
  mount -t jffs2 /dev/mtdblock2 /mnt
  touch /mnt/xxx
  umount /mnt
  dd if=/dev/mtdblock2 of=/dev/null
|end_request: I/O error, dev mtdblock2, sector 17488
|Buffer I/O error on device mtdblock2, logical block 2186
|end_request: I/O error, dev mtdblock2, sector 17488
|Buffer I/O error on device mtdblock2, logical block 2186
|dd: reading `/dev/mtdblock2': Input/output error
|17488+0 records in
|17488+0 records out
|8953856 bytes (9.0 MB) copied, 10.243 s, 874 kB/s

Remounting the file system:
  mount -t jffs2 /dev/mtdblock2 /mnt
|mtd->read(0x1fdfc bytes from 0x880204) returned ECC error
|mtd->read(0x166bc bytes from 0x889944) returned ECC error
|Empty flash at 0x00889940 ends at 0x0088a000

> >> So I have to disable the JFFS2 to use the OOB. I have not finish the
> >> code about it now.
> >>
> >> I recommend you use the UBIFS. But the latest version of GPMI driver
> >> meets a DMA bug.
> >> I am debugging the DMA bug now. and I will send it out when i fix it.
> >>
> > What sort of DMA bug?
> >
> 
> The DMA may time-out. :(
> 
> The DMA time-out may occur in two situations:
> [1] send a command DMA descriptor, see the nfc->send_command() function.
> [2] read the non-ecc data from nand, see the nfc->read_data() function.
> 
> I don't know why. Maybe caused by the timing, or something else.
> 
Maybe you are missing this patch:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/049105.html
I sent it in April, but apparently it has not been integrated in
mainline or the pengutronix git.


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
___________________________________________________________

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Wolfram Sang]

> > >> I am debugging the DMA bug now. and I will send it out when i fix it.
> > >>
> > > What sort of DMA bug?
> > >
> > 
> > The DMA may time-out. :(
> > 
> > The DMA time-out may occur in two situations:
> > [1] send a command DMA descriptor, see the nfc->send_command() function.
> > [2] read the non-ecc data from nand, see the nfc->read_data() function.
> > 
> > I don't know why. Maybe caused by the timing, or something else.

I am confused. The send-command DMA timeout prevents any write for me.
You guys surely would have noticed if you have been bitten as well. Does
it depend on the NAND chip?

> Maybe you are missing this patch:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/049105.html
> I sent it in April, but apparently it has not been integrated in
> mainline or the pengutronix git.

Well, just resend them; might be worth trying Shawn's comment, too (if
that reset is really needed). BTW they didn't help for my case :(

Regards,

   Wolfram

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

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Huang Shijie]

Hi Wolfram:
>>>>> I am debugging the DMA bug now. and I will send it out when i fix it.
>>>>>
>>>> What sort of DMA bug?
>>>>
>>> The DMA may time-out. :(
>>>
>>> The DMA time-out may occur in two situations:
>>> [1] send a command DMA descriptor, see the nfc->send_command() function.
>>> [2] read the non-ecc data from nand, see the nfc->read_data() function.
>>>
>>> I don't know why. Maybe caused by the timing, or something else.
> I am confused. The send-command DMA timeout prevents any write for me.
> You guys surely would have noticed if you have been bitten as well. Does
> it depend on the NAND chip?
I think It does not depend on the NAND chip.
My test chip is Samsung K9G8G08U0M.
Sometimes, I can run a long time while there is no DMA timeout occurring;
Sometimes, the bug appears right away.


>> Maybe you are missing this patch:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/049105.html
>> I sent it in April, but apparently it has not been integrated in
>> mainline or the pengutronix git.
> Well, just resend them; might be worth trying Shawn's comment, too (if
> that reset is really needed). BTW they didn't help for my case :(
I also tested the patch. It did not work too.

Best Regards
Huang Shijie
> Regards,
>
>     Wolfram
>

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Wolfram Sang]

> >>>>>I am debugging the DMA bug now. and I will send it out when i fix it.
> >>>>>
> >>>>What sort of DMA bug?
> >>>>
> >>>The DMA may time-out. :(
> >>>
> >>>The DMA time-out may occur in two situations:
> >>>[1] send a command DMA descriptor, see the nfc->send_command() function.
> >>>[2] read the non-ecc data from nand, see the nfc->read_data() function.
> >>>
> >>>I don't know why. Maybe caused by the timing, or something else.
> >I am confused. The send-command DMA timeout prevents any write for me.
> >You guys surely would have noticed if you have been bitten as well. Does
> >it depend on the NAND chip?
> I think It does not depend on the NAND chip.
> My test chip is Samsung K9G8G08U0M.
> Sometimes, I can run a long time while there is no DMA timeout occurring;
> Sometimes, the bug appears right away.

For me, the bug always happens right away. So, if you need logs or debug
output or can give me a pointer into some direction, I am glad to
assist.

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

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Huang Shijie]

Hi,
> Hi,
>
> Huang Shijie writes:
>> ? 2011?07?19? 14:02, Lothar Wa?mann ??:
>>> Hi,
>>>
>>> Huang Shijie writes:
>>>> hi  Lothar:
>>>>> On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
>>>>> To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
>>>>>
>>>>> Regards,
>>>>> Shawn
>>>>>
>>>>>> encountered some problems with jffs2 when overwriting pages that have
>>>>>> been written with 0xff (e.g. from padding from the file system image
>>>>>> file).
>>>> The GPMI driver now does not support the JFFS2 very well.
>>>> The JFFS2 will write the OOB, while the BCH of GPMI will use the OOB too.
>>>>
>>> I have applied a patch (from the Freescale BSPs) that prevents JFFS2
>>> from using the OOB area. But this still doesn't help.
>>>
>> Could you show the log ?
>>
> On the host:
>    mkfs.jffs2 -o ../rootfs.img -n -e 0x20000 -p -r .
> The last block gets padded with a stretch of 91840 bytes of 0xff.
> On the target:
>    flash_eraseall  /dev/mtd2
>    nandwrite /dev/mtd2 /rootfs-jffs2.image
> The raw data of the last used block in flash looks like this
> afterwards:
>    nanddump -n -p -l 0x800 -s 0x889800 /dev/mtd2
> |Block size 131072, page size 2048, OOB size 64
> |Dumping data starting at 0x00889800 and ending at 0x0088a000...
> |0x00889800: ff ff ff ff ff ff ff ff ff ff b7 00 00 00 f2 00
> |0x00889810: 00 00 06 00 00 00 7f ca a1 e3 e4 1f e9 24 78 5e
> |0x00889820: 34 8f 41 0e 83 30 0c 04 ef 7d 85 25 ae 6d f3 8e
> |0x00889830: de fb 81 10 0c b1 08 76 e4 18 10 bf af 83 d4 93
> |0x00889840: 2d 6b 67 77 3d c0 37 53 83 99 0a 82 cf 76 6d 85
> |0x00889850: 78 c5 09 4c 20 a0 a5 a0 d8 a4 1c ef 24 3c 3f 06
> |0x00889860: f8 58 57 ad 58 7d 32 84 23 6a d0 9d c3 94 53 4d
> |0x00889870: a1 33 23 42 1c dd cb d7 4d 76 36 b0 8c a0 22 36
> |0x00889880: 37 c7 15 e3 f4 12 2e 17 9c b9 27 56 77 47 3d 88
> |0x00889890: 97 5b 57 a5 35 1a a9 90 5d dd 20 c7 c3 4b 99 53
> |0x008898a0: a7 92 19 b2 3b 8c 17 dc 61 d3 13 68 be 21 46 3b
> |0x008898b0: 45 57 e8 0d 69 d9 35 1a 09 f7 96 ff 83 3f f3 13
> |0x008898c0: 40 69 f9 45 0a 2e 1e ce 01 7a 5c ca 5c 00 01 06
> |0x008898d0: 00 2b 56 54 c6 ff 85 19 01 e0 2f 00 00 00 b1 f9
> |0x008898e0: 44 f2 c2 03 00 00 d5 03 00 00 c8 03 00 00 a7 ac
> |0x008898f0: e3 4d 07 08 00 00 55 81 af 84 e8 5f 94 39 79 70
> |0x00889900: 2e 63 6f 6e 66 ff 85 19 02 e0 44 00 00 00 1d fb
> |0x00889910: f7 98 c8 03 00 00 01 00 00 00 a4 81 00 00 00 00
> |0x00889920: 00 00 00 00 00 00 a7 ac e3 4d a7 ac e3 4d a7 ac
> |0x00889930: e3 4d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |0x00889940: 00 00 00 00 00 00 13 77 d1 ba ff ff ff ff ff ff
> |0x00889950: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [...]
> |0x00889a00: ff ff ff ff ff ff ff ff ff ff 27 21 37 1b 06 87
> |0x00889a10: 70 f1 00 0e 6a 8e 57 ff ff ff ff ff ff ff ff ff
> |0x00889a20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [...]
> |0x00889c10: ff ff ff ff ff ff ff 08 75 8b 6f 48 36 a6 bc 16
> |0x00889c20: 61 58 db 52 ff ff ff ff ff ff ff ff ff ff ff ff
> |0x00889c30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [...]
> |0x00889e20: ff ff ff ff 08 75 8b 6f 48 36 a6 bc 16 61 58 db
> |0x00889e30: 52 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |0x00889e40: 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
> |  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |  OOB Data: ff 08 75 8b 6f 48 36 a6 bc 16 61 58 db 52 00 00
>
> The remaining pages of this block are all-FF except for the ecc
> pattern as above.
>
> Checking the readability of the whole flash partition shows no errors:
>    dd if=/dev/mtdblock2 of=/dev/null
> |32768+0 records in
> |32768+0 records out
> |16777216 bytes (17 MB) copied, 18.6754 s, 898 kB/s
>
> Mounting the partition and writing some file produces ecc errors upon
> successive reads:
>    mount -t jffs2 /dev/mtdblock2 /mnt
>    touch /mnt/xxx
It seems the writing of JFFS2 corrupted something.
So the following commands will fail.

You can add some log in the functions 
mil_ecc_write_page()/mil_ecc_read_page()
to check what kind of error occurs.


Best Regards
Huang Shijie



>    umount /mnt
>    dd if=/dev/mtdblock2 of=/dev/null
> |end_request: I/O error, dev mtdblock2, sector 17488
> |Buffer I/O error on device mtdblock2, logical block 2186
> |end_request: I/O error, dev mtdblock2, sector 17488
> |Buffer I/O error on device mtdblock2, logical block 2186
> |dd: reading `/dev/mtdblock2': Input/output error
> |17488+0 records in
> |17488+0 records out
> |8953856 bytes (9.0 MB) copied, 10.243 s, 874 kB/s
>
> Remounting the file system:
>    mount -t jffs2 /dev/mtdblock2 /mnt
> |mtd->read(0x1fdfc bytes from 0x880204) returned ECC error
> |mtd->read(0x166bc bytes from 0x889944) returned ECC error
> |Empty flash at 0x00889940 ends at 0x0088a000
>
>>>> So I have to disable the JFFS2 to use the OOB. I have not finish the
>>>> code about it now.
>>>>
>>>> I recommend you use the UBIFS. But the latest version of GPMI driver
>>>> meets a DMA bug.
>>>> I am debugging the DMA bug now. and I will send it out when i fix it.
>>>>
>>> What sort of DMA bug?
>>>
>> The DMA may time-out. :(
>>
>> The DMA time-out may occur in two situations:
>> [1] send a command DMA descriptor, see the nfc->send_command() function.
>> [2] read the non-ecc data from nand, see the nfc->read_data() function.
>>
>> I don't know why. Maybe caused by the timing, or something else.
>>
> Maybe you are missing this patch:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/049105.html
> I sent it in April, but apparently it has not been integrated in
> mainline or the pengutronix git.
>
>
> Lothar Wa?mann

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Lothar Waßmann]

Hi,

Huang Shijie writes:
> Hi,
> > Hi,
> >
> > Huang Shijie writes:
> >> ? 2011?07?19? 14:02, Lothar Wa?mann ??:
> >>> Hi,
> >>>
> >>> Huang Shijie writes:
> >>>> hi  Lothar:
> >>>>> On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> >>>>> To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
> >>>>>
> >>>>> Regards,
> >>>>> Shawn
> >>>>>
> >>>>>> encountered some problems with jffs2 when overwriting pages that have
> >>>>>> been written with 0xff (e.g. from padding from the file system image
> >>>>>> file).
> >>>> The GPMI driver now does not support the JFFS2 very well.
> >>>> The JFFS2 will write the OOB, while the BCH of GPMI will use the OOB too.
> >>>>
> >>> I have applied a patch (from the Freescale BSPs) that prevents JFFS2
> >>> from using the OOB area. But this still doesn't help.
> >>>
> >> Could you show the log ?
> >>
> > On the host:
> >    mkfs.jffs2 -o ../rootfs.img -n -e 0x20000 -p -r .
> > The last block gets padded with a stretch of 91840 bytes of 0xff.
> > On the target:
> >    flash_eraseall  /dev/mtd2
> >    nandwrite /dev/mtd2 /rootfs-jffs2.image
> > The raw data of the last used block in flash looks like this
> > afterwards:
> >    nanddump -n -p -l 0x800 -s 0x889800 /dev/mtd2
> > |Block size 131072, page size 2048, OOB size 64
> > |Dumping data starting at 0x00889800 and ending at 0x0088a000...
> > |0x00889800: ff ff ff ff ff ff ff ff ff ff b7 00 00 00 f2 00
> > |0x00889810: 00 00 06 00 00 00 7f ca a1 e3 e4 1f e9 24 78 5e
> > |0x00889820: 34 8f 41 0e 83 30 0c 04 ef 7d 85 25 ae 6d f3 8e
> > |0x00889830: de fb 81 10 0c b1 08 76 e4 18 10 bf af 83 d4 93
> > |0x00889840: 2d 6b 67 77 3d c0 37 53 83 99 0a 82 cf 76 6d 85
> > |0x00889850: 78 c5 09 4c 20 a0 a5 a0 d8 a4 1c ef 24 3c 3f 06
> > |0x00889860: f8 58 57 ad 58 7d 32 84 23 6a d0 9d c3 94 53 4d
> > |0x00889870: a1 33 23 42 1c dd cb d7 4d 76 36 b0 8c a0 22 36
> > |0x00889880: 37 c7 15 e3 f4 12 2e 17 9c b9 27 56 77 47 3d 88
> > |0x00889890: 97 5b 57 a5 35 1a a9 90 5d dd 20 c7 c3 4b 99 53
> > |0x008898a0: a7 92 19 b2 3b 8c 17 dc 61 d3 13 68 be 21 46 3b
> > |0x008898b0: 45 57 e8 0d 69 d9 35 1a 09 f7 96 ff 83 3f f3 13
> > |0x008898c0: 40 69 f9 45 0a 2e 1e ce 01 7a 5c ca 5c 00 01 06
> > |0x008898d0: 00 2b 56 54 c6 ff 85 19 01 e0 2f 00 00 00 b1 f9
> > |0x008898e0: 44 f2 c2 03 00 00 d5 03 00 00 c8 03 00 00 a7 ac
> > |0x008898f0: e3 4d 07 08 00 00 55 81 af 84 e8 5f 94 39 79 70
> > |0x00889900: 2e 63 6f 6e 66 ff 85 19 02 e0 44 00 00 00 1d fb
> > |0x00889910: f7 98 c8 03 00 00 01 00 00 00 a4 81 00 00 00 00
> > |0x00889920: 00 00 00 00 00 00 a7 ac e3 4d a7 ac e3 4d a7 ac
> > |0x00889930: e3 4d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > |0x00889940: 00 00 00 00 00 00 13 77 d1 ba ff ff ff ff ff ff
> > |0x00889950: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [...]
> > |0x00889a00: ff ff ff ff ff ff ff ff ff ff 27 21 37 1b 06 87
> > |0x00889a10: 70 f1 00 0e 6a 8e 57 ff ff ff ff ff ff ff ff ff
> > |0x00889a20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [...]
> > |0x00889c10: ff ff ff ff ff ff ff 08 75 8b 6f 48 36 a6 bc 16
> > |0x00889c20: 61 58 db 52 ff ff ff ff ff ff ff ff ff ff ff ff
> > |0x00889c30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [...]
> > |0x00889e20: ff ff ff ff 08 75 8b 6f 48 36 a6 bc 16 61 58 db
> > |0x00889e30: 52 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > |0x00889e40: 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
> > |  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > |  OOB Data: ff 08 75 8b 6f 48 36 a6 bc 16 61 58 db 52 00 00
> >
> > The remaining pages of this block are all-FF except for the ecc
> > pattern as above.
> >
> > Checking the readability of the whole flash partition shows no errors:
> >    dd if=/dev/mtdblock2 of=/dev/null
> > |32768+0 records in
> > |32768+0 records out
> > |16777216 bytes (17 MB) copied, 18.6754 s, 898 kB/s
> >
> > Mounting the partition and writing some file produces ecc errors upon
> > successive reads:
> >    mount -t jffs2 /dev/mtdblock2 /mnt
> >    touch /mnt/xxx
> It seems the writing of JFFS2 corrupted something.
> So the following commands will fail.
> 
It doesn't only seem so.
JFFS2 overwrites the all-FF page without erasing the block containing
that page, but since the ECC pattern for an all-FF page is NOT all-FF
the ECC information cannot be written correctly and ECC errors occur
on a subsequent read.


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
___________________________________________________________

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Artem Bityutskiy]

On Tue, 2011-07-19 at 10:12 +0800, Huang Shijie wrote:
> hi  Lothar:
> > On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> >> Hi,
> >>
> >> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> > To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
> >
> > Regards,
> > Shawn
> >
> >> encountered some problems with jffs2 when overwriting pages that have
> >> been written with 0xff (e.g. from padding from the file system image
> >> file).
> The GPMI driver now does not support the JFFS2 very well.
> The JFFS2 will write the OOB, while the BCH of GPMI will use the OOB too.
> So I have to disable the JFFS2 to use the OOB. I have not finish the 
> code about it now.
> 
> I recommend you use the UBIFS. But the latest version of GPMI driver 
> meets a DMA bug.
> I am debugging the DMA bug now. and I will send it out when i fix it.

This is a different issue. You refer to the "GPMI-controlled flash has
no space in OOB for JFFS2". Lothar's issue is about "GPMI-controlled
flash does not allow writing 0xFFs and then writing something else",
which is very normal.

-- 
Best Regards,
Artem Bityutskiy

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Artem Bityutskiy]

On Wed, 2011-07-20 at 08:16 +0300, Artem Bityutskiy wrote:
> This is a different issue. You refer to the "GPMI-controlled flash has
> no space in OOB for JFFS2". Lothar's issue is about "GPMI-controlled
> flash does not allow writing 0xFFs and then writing something else",
> which is very normal.

Huang, to be more precise, I think Lothar's issue is the same as
described here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo

Although the description is about UBI and UBIFS - this is applicable
for JFFS2 as well.

-- 
Best Regards,
Artem Bityutskiy

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Lothar Waßmann]

Hi,

Shawn Guo writes:
> On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> > Hi,
> > 
> > with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> 
> To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
> 
Sorry, I confused the names.


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
___________________________________________________________

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Huang Shijie]

Hi Lothar:
> On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
>> Hi,
>>
>> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
>
> Regards,
> Shawn
>
>> encountered some problems with jffs2 when overwriting pages that have
>> been written with 0xff (e.g. from padding from the file system image
>> file).
>>
>> The problem is that the ECC info for an all-0xff block is not all-0xff
>> and thus a newly erased block is different from a block that has been
>> written with 0xff.
>> If such a block is being altered (jffs2 thinking it can simply
>> overwrite it without erasing first) the ECC information will be
>> corrupted and will produce ECC errors upon read.
>>
>> The only remedy I can think of is to prevent empty pages from actually
>> being written to flash, but leaving them in the erased state instead.
Did you mean that:
If the gpmi have to write a page which is full of 0xff,
the gpmi driver should skip the writting, and leave the page in the 
erased state.

Am I right?

Huang Shijie
>> Any comments?
>>
>>
>> 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
>> ___________________________________________________________
>>

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Lothar Waßmann]

Hi,

Huang Shijie writes:
> Hi Lothar:
> > On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> >> Hi,
> >>
> >> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> > To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
> >
> > Regards,
> > Shawn
> >
> >> encountered some problems with jffs2 when overwriting pages that have
> >> been written with 0xff (e.g. from padding from the file system image
> >> file).
> >>
> >> The problem is that the ECC info for an all-0xff block is not all-0xff
> >> and thus a newly erased block is different from a block that has been
> >> written with 0xff.
> >> If such a block is being altered (jffs2 thinking it can simply
> >> overwrite it without erasing first) the ECC information will be
> >> corrupted and will produce ECC errors upon read.
> >>
> >> The only remedy I can think of is to prevent empty pages from actually
> >> being written to flash, but leaving them in the erased state instead.
> Did you mean that:
> If the gpmi have to write a page which is full of 0xff,
> the gpmi driver should skip the writting, and leave the page in the 
> erased state.
> 
> Am I right?
> 
Exactly. But it seems others think this should be handled by userspace
tools rather than in the kernel driver.


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
___________________________________________________________

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Artem Bityutskiy]

On Wed, 2011-07-20 at 14:44 +0800, Huang Shijie wrote:
> Hi Lothar:
> > On Mon, Jul 18, 2011 at 03:13:27PM +0200, Lothar Wa?mann wrote:
> >> Hi,
> >>
> >> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> > To be clear, the author of gpmi-nfc driver is Huang Shijie (Cc-ed).
> >
> > Regards,
> > Shawn
> >
> >> encountered some problems with jffs2 when overwriting pages that have
> >> been written with 0xff (e.g. from padding from the file system image
> >> file).
> >>
> >> The problem is that the ECC info for an all-0xff block is not all-0xff
> >> and thus a newly erased block is different from a block that has been
> >> written with 0xff.
> >> If such a block is being altered (jffs2 thinking it can simply
> >> overwrite it without erasing first) the ECC information will be
> >> corrupted and will produce ECC errors upon read.
> >>
> >> The only remedy I can think of is to prevent empty pages from actually
> >> being written to flash, but leaving them in the erased state instead.
> Did you mean that:
> If the gpmi have to write a page which is full of 0xff,
> the gpmi driver should skip the writting, and leave the page in the 
> erased state.
> 
> Am I right?

Please, no! The driver should just write what it is asked to write. Your
driver has a limitation - a NAND page can be written only _once_. If a
piece of software writes a page twice (1st with all 0xFFs, then with
something else) - this is a problem in _that piece of software_.


Additionally, all 0xFFs are just data, it needs ECC corrections in case
of bit-flips just like any other data. Eve you decided to do that
horrible "skip all 0xFFs" hack, you'd need to make sure bit-flips in
"skipped" pages are still corrected. Indeed, there is not reason why a
never written NAND page would not have bit-flips.

-- 
Best Regards,
Artem Bityutskiy

[i.MX28 GPMI] problem overwriting all-0xff data in NAND

[Artem Bityutskiy]

On Mon, 2011-07-18 at 15:13 +0200, Lothar Wa?mann wrote:
> Hi,
> 
> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> encountered some problems with jffs2 when overwriting pages that have
> been written with 0xff (e.g. from padding from the file system image
> file).
> 
> The problem is that the ECC info for an all-0xff block is not all-0xff
> and thus a newly erased block is different from a block that has been
> written with 0xff.
> If such a block is being altered (jffs2 thinking it can simply
> overwrite it without erasing first) the ECC information will be
> corrupted and will produce ECC errors upon read.
> 
> The only remedy I can think of is to prevent empty pages from actually
> being written to flash, but leaving them in the erased state instead.
> 
> Any comments?

Hi,

I think Ivan is right, the only issue is how you flash your images. This
problem is not JFFS2-specific, you'd have it with UBIFS as well.

For UBIFS users, I described this issue here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo

You might find it useful, because this basically applies to JFFS2 as
well, but for JFFS2 the problem can be solved by simply making sure your
images are not padded to the eraseblock size and that your flasher does
not do the padding.

For "I cannot change my industrial flasher" case we nowadays have a
solution in the UBIFS level:
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_free_space_fixup

Similar thing could be implemented for JFFS2, I guess, but not sure.

HTH

-- 
Best Regards,
Artem Bityutskiy