I can confirm your thinking on the yaffs side, but I have not checked out the 
BCH side of your reasoning as I am unsure of that.

SLCs do normally have 64 bytes of spare per 2k of data. Once you take away the 
yaffs tags and a bad block marker you still get left with more than enough 
for a reasonable strategy. On SLC BCH is probably overkill, but I would do 
that anyway if you are doing it in hardware.

MLC is far less standardised. Some MLCs only provide 64 bytes/2k (like SLC). 
Some provide more. I would suggest using BCH on MLC. It is wise to correct as 
many bits as you can, particularly if it is being done by hardware and 
is "free".

Reporting errors to the software is simple with single-bit correction:
0 errors = no errors, 1 error = corrected. more == failed.

The software can then take action if an error was detected and corrected (eg. 
rewrite data).

With multi-bit correction you probably want to report things differently. For 
example, let's say you can correct 8 bits. Then maybe something like the 
following is a good approach:
0..5 bits: report "no error"
6..8 bits: report "corrected"
more: failed.

-- CHarles


On Thursday 12 November 2009 21:26:47 Henri Cloetens wrote:
>  Hi ,
>
>  So, I looked in the code. yaffs_PackedTags2TagsPart is a 16-byte struct (4
> unsigned longs). Together with the 2 byte bad block marker, this means
> total 18 spare byte consumption per 2 kbyte block ?.
>  If I do the math, for a 15-bit BCH code (uses 15 spare bits per error
> correctable) -> For SLC flash, with 16 spare bytes/512 bytes: 46 bytes
> available for ECC, max. 24 bit correction / 2kbyte sector. -> For MLC
> flash, I dont find the spare area size on the web. I think its larger,
> permitting stronger ECC.
>
>  Regards,
>
>
>  Henri Cloetens.
>
>
>  Charles Manning wrote:
> It depends on what you're protecting
>
> sizeof (yaffs_PackedTags2) is a full set of tags + ecc on the tags
> themselves. if your ecc system is going to cover the spare area too, then
> youonly need to store sizeof(yaffs_PackedTags2TagsPart).
>
> You will also need a bad block marker. Say 2 bytes.
>
> -- Charles
>
>
>
> On Thursday 12 November 2009 05:28:45 Henri Cloetens wrote:
>
>  Hi,
>
>  I am looking at ways to do ECC for MLC nand flash.
>  I have a question in this regards on the Yaffs file system:
>
>  When used together with a NAND flash with 2kbyte sectors, how many spare
> bytes are needed for the Yaffs headers ?. (#bytes / 2kbyte sector).
>
>  I need this number, so I can figure out how many bytes can be used by the
> ECC. I want to design my ECC to use up all spares not needed by Yaffs.
>
>  Best Regards,
>
>
>  Henri Cloetens.
>
>
>  Charles Manning wrote:
> Fixed something...
>
> On Wednesday 11 November 2009 12:59:07 Charles Manning wrote:
>
> Hi Ross
>
> Thanks for that patch.
>
> I had a look and have come up with an alternative solution to the problem:
> instead of trying to unwind a half created object if the string or tnode
> malloc fail it is a lot cleaner to reverse the order of allocation. ie
> forst create the tnode or string, then create the object if that succeeds.
>
> I also had a sniff around and found a few other areas where tnode creation
> failures would cause issues.
>
> The fixed stuff has been running in a stress test for almost 24 hours and
> I've just checked that in.
> http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yaffs_guts.c?r1=1.93&r2=
> 1.94
>
> Look at:
>
> http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yaffs_guts.c?r1=1.95&r2=
> 1.93
>
> I also put a day or so into extending low mem testing and will expand the
> tests more.
>
> Thanks
>
> -- Charles
>
> On Friday 30 October 2009 06:35:32 Ross Younger wrote:
>
> Whilst doing some stress testing on a board with limited RAM, I tripped
> over an assertion failure.
>
> In yaffs_CreateNewObject, YAFFS would sometimes successfully
> AllocateEmptyObject but not be able to allocate a new tnode, so GetTnode
> returned 0. It would then immediately attempt to FreeObject, but the
> freshly allocated object already has a parent so it hits the YBUG trap at
> line 1992 of yaffs_guts.c.
>
> I attach a patch which fixes this assertion (and a similar case I spotted
> in yaffs_MknodObject) by calling DoGenericObjectDeletion instead of
> FreeObject, though it might instead be reasonable for AllocateEmptyObject
> to not try to add the object to the rootDir or lostNFoundDir.
>
>
> Ross
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
>
>
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
>
>
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs