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

  


-- 
Henri Cloetens

Freescale Semiconductor Ltd
De Waal 26
5684 PH Best
The Netherlands