* Clarification on PLACE -vs- AUTO with JFFS2 cleanmarkers.
@ 2006-11-02 18:10 Pete MacKay
2006-11-03 9:26 ` Artem Bityutskiy
0 siblings, 1 reply; 3+ messages in thread
From: Pete MacKay @ 2006-11-02 18:10 UTC (permalink / raw)
To: linux-mtd
Hi,
I've written a custom driver for the ST 512R3A 8-bit NAND under 2.6.16 and
ported it to 2.6.18. Because of some chip and system peculiarities I was
unable to use the NAND framework and wrote it using solely MTD (except for
software ECC). The problem occurs when mounting a JFFS2 file system: the
cleanmarker is written to bytes 0-7 (ECC, bad block marker) instead of
8-15 of the OOB, as instructed by the write_ops call with ooboffs=0,
ooblen=8, and mode=MTD_OOB_PLACE. My understanding is that MTD_OOB_AUTO
should be used to put the cleanmarker into the the free bytes; am I
mistaken? I've corrected what we thought were other problems with len and
ooblen in wbuf.c but it looks like that patch came out Monday.
Thanks for any clarification,
Pete MacKay
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Clarification on PLACE -vs- AUTO with JFFS2 cleanmarkers.
2006-11-02 18:10 Clarification on PLACE -vs- AUTO with JFFS2 cleanmarkers Pete MacKay
@ 2006-11-03 9:26 ` Artem Bityutskiy
0 siblings, 0 replies; 3+ messages in thread
From: Artem Bityutskiy @ 2006-11-03 9:26 UTC (permalink / raw)
To: Pete MacKay; +Cc: linux-mtd
On Thu, 2006-11-02 at 13:10 -0500, Pete MacKay wrote:
> I've written a custom driver for the ST 512R3A 8-bit NAND under 2.6.16 and
> ported it to 2.6.18. Because of some chip and system peculiarities I was
> unable to use the NAND framework and wrote it using solely MTD (except for
> software ECC). The problem occurs when mounting a JFFS2 file system: the
> cleanmarker is written to bytes 0-7 (ECC, bad block marker) instead of
> 8-15 of the OOB, as instructed by the write_ops call with ooboffs=0,
> ooblen=8, and mode=MTD_OOB_PLACE. My understanding is that MTD_OOB_AUTO
> should be used to put the cleanmarker into the the free bytes; am I
> mistaken? I've corrected what we thought were other problems with len and
> ooblen in wbuf.c but it looks like that patch came out Monday.
In my opinion you have hit a bug which seems to be introduced at May
2006 by commit 8593fbc68b0df1168995de76d1af38eb62fd6b62.
I think it assumed to be MTD_OOB_AUTO.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Clarification on PLACE -vs- AUTO with JFFS2 cleanmarkers.
@ 2006-11-02 1:20 linux
0 siblings, 0 replies; 3+ messages in thread
From: linux @ 2006-11-02 1:20 UTC (permalink / raw)
To: linux-mtd
Hi,
I've written a custom driver for the ST 512R3A 8-bit NAND under 2.6.16 and
ported it to 2.6.18. Because of some chip and system peculiarities I was
unable to use the NAND framework and wrote it using solely MTD (except for
software ECC). The problem occurs when mounting a JFFS2 file system: the
cleanmarker is written to bytes 0-7 (ECC, bad block marker) instead of
8-15 of the OOB, as instructed by the write_ops call with ooboffs=0,
ooblen=8, and mode=MTD_OOB_PLACE. My understanding is that MTD_OOB_AUTO
should be used to put the cleanmarker into the the free bytes; am I
mistaken? I've corrected what we thought were other problems with len and
ooblen in wbuf.c but it looks like that patch came out Monday.
Thanks for any clarification,
Pete MacKay
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-11-03 9:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-02 18:10 Clarification on PLACE -vs- AUTO with JFFS2 cleanmarkers Pete MacKay
2006-11-03 9:26 ` Artem Bityutskiy
-- strict thread matches above, loose matches on Subject: below --
2006-11-02 1:20 linux
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox