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