Re: [Yaffs] [PATCH] make yaffs2 work with 2.6.17+ kernels

On Sunday 17 September 2006 01:34, Vitaly Wool wrote:
> Hello folks,
>
> okay, here's the patch which should basically work not only in native
> YAFFS2 mode but in YAFFS1 compatibility mode as well. Please note that
> due to the reasons described in my previous letter, some
> implementation steps are hacks rather than solutions, so it's kind of
> 'proof of concept' in a way.
>
> Well, however it received some limited testing on nandsim w/ 512b page
> size configured and looks like it works.
> Jonathan, can you please try this version and report the problems, if any?

Hi Vitaly

Thanx for these patches and your work in mtd driver land. I think they will be
of enormous benefit to everyone.

I know you don't have a 512-byte board, so maybe someone with a 512-byte board
could chase the yaffs1 stuff.

I don't have a 2.6.x board at present (and am a bit short of time) so have
not tried out the changes. I thus can't submit a back-patch. However, I'll
make a few comments that you might be able to consider:

In yaffs_mtdif2.c:
1. For yaffs2 (ie what yaffs_mtdif2.c is there for), useNANDECC is always set.
Thus there is no need for the MTD_OOB_RAW case. YAFFS2 assumes that all the
byte placement ugliness is in the driver. I know the original code has
references to useNANDECC, but both paths are the same.
2. The code says that it is OK to write data with no tags, but it is a bug to
write tags with no data. For yaffs2, there should be both tags and data.
Anything else is a bug (and certainly writing anything without tags is). The
only occasion when I expect tags to be written with no data is bad block
marking, but that is also hidden within the driver.
3. In the reading path, yaffs2 can read any combination of data only, tags
only or both tags and data. I assume it is OK for ops.datbuff to be NULL.



in yaffs_mtdif.c:
1) The tags packing seems tyo no longer to ECC on the tags area. Is this done
elsewhere (in the driver). If not, some robustness is lost. I admit that the
original ECC was not very strong, but it was something...
2) The code uses single bits for both the page status and block status. This
is a loss of robustness vs the previous (SmartMedia) layout. In the original
layout, the block and page status used a whole byte with bit counting as a
voting mechanism. Moving to a single bit is more likely to invite tags
corruption.
3) Page status and block status values seem to have been swapped. Block status
is the one that gets set to 'Y'.
4) The code always does seperate writes for data and spare. Can these be
combined into a single write to make the writing faster?

-- CHarles