On Tuesday 13 December 2005 10:04, Michael Arm wrote:
> Hi all,
>
> I've been trying to get the latest CVS version of YAFFS2 to work with a
> Samsung K9F2GxxU0M chip which has 2k sector size. I observed the problem
> documented some months ago whereby files written to the flash would
> disappear upon the next mount.
Yup, this is a well known and much discussed problem. Lots of traffic on this
during October.
>
> I traced the problem down to the fact that the nandmtd2_QueryNANDBlock()
> function in yaffs_mtdif2.c is calling mtd->block_isbad, which is really
> nand_block_isbad() in mtd/nand.c. This function is checking if the first
> byte of OOB data is 0xFF, and if not is returning that the block is bad.
>
> However when data is written, the call traces through
> nandmtd2_WriteChunkWithTagsToNAND() in yaffs_mtdif2.c, which in turn is
> calling yaffs_PackTags2() in yaffs_packedtags2.c. This function is using a
> struct yaffs_PackedTags2 to store the OOB data for the block. This value
> is being directly written to the OOB area in the flash. However, there is
> no accomodation made for the fact that byte 0 should be 0xFF, and as a
> result this is why upon mount the data disappears - YAFFS2 mistakenly
> thinks it is reading bad blocks, because it didn't set byte 0 to 0xFF when
> it wrote the OOB data, byte 0 is instead the LSB of the sequence number.
>
> If we add a byte to the head of the yaffs_PacketTags2 struct, and set it to
> 0xFF in yaffs_PackTags2(), then everything works fine and data can be read
> and written good, apparently. However I am wondering if this is a good
> fix, or if there are hidden problems that this might be cause due to the
> new offset of the rest of OOB data and the possibility of a byte of OOB
> data being lost at the end.
The real problem comes down to an inconsistency between YAFFS and the current
mtd implementation on what the OOB alignment should be.
YAFFS2 uses AUTOPLACE which is supposed to provide a way to save/read the
unused bytes in the OOB area (ie. the bytes not used by bad block markers and
ECC). Calls to read_oob() however provide the "raw" placement.
This is generally considered to be an mtd-side issue and people are working on
it in mtd-land (especially Vitaly Wool). Hopefully this will be resolved in
the very close future. I've been hoping for a resolution for a long time now,
but I think it really is close now.
In the mean time, people just work around the problem.
>
> Since we are constrained to use Linux 2.4 I am currently using the version
> of MTD I found on husaberg.toby-churchill.com, which was referenced
> (somewhat obscurely) in earlier posts. I'm not sure if this is the best
> version, (other versions I tried showed identical symptoms) and it was in
> fact cumbersome to access as there doesn't appear to be any way to fetch
> the files except for one at a time through the web interface.
> Can anyone comment on how good a fix shifting the yaffs_PacketTags2
> structure is, or on the location of the newest MTD code which works with
> YAFFS2 under Linux 2.4?
Working with 2.4 can cause issues because it is no longer supported by mtd.
Therefore any fixes in mtd-land might not be usable in the future.
Consider it a MacGuiver fix :-). Gets you out of a mess in the short term, but
you don't want to be using it in 5 years time. However, since you're going to
have to hack mtd anyway, I'd suggest you do the hacks that side.
-- Charles
(text/plain)