Thx for your response Alan.

 

 

I have been trying to integrate a YAFFS2 rootfs on my TI MVL ARM target while enabling the in-band

tagging option of YAFFS.  I’ve chosen to enable this option is so that it will be compatible

with the HW ECC I’ve enabled in my kernel and uboot components.  I have followed

various thread on YAFFS2 that suggest I must use SW ECC with YAFFS.  However, the

nature of my target system and its need to upgrade its sub-components (i.e. UBL, UBOOT,

KERNEL, and ROOTFS) in user space require I keep with the HW ECC.  I have followed one thread

(http://www.aleph1.co.uk/lurker/message/20110202.163806.dac21ec5.en.html) which claims

to have achieved HW ECC with YAFFS2, but after attempting to incorporate such, have not had

any success.  Perhaps I just haven’t applied its suggested patches properly or mounted the

YAFFS2 fs correctly.  Anyone else had success doing this configuration?

We were able to get HW 4bit ECC working with yaffs2. The HW ECC we use (Micron part) takes over certain portions of the OOB area where it writes the calculated 4bit ECC value which conflicts with yaffs. Yaffs can be made to work with in-band tags as previously mentioned - but there are still portions of the OOB area that need to be carefully managed - namely, the BBT markers and the BBT signatures, etc.

What part are you using?

We are currently using a Micron MT29F (2G/256M x 8) NAND part.

 

As for your point on the use of the OOB, I would like YAFFS2 to leave it alone so that it can be again used to hold BBT and ECC info for the page data it currently contains.  This means when I go to create the YAFFS2 ROOTFS image with mkyaffs2image, I hope it creates the image without any OOB TAGS data  anywhere in the image.  This way, I can write it to NAND using either UBOOT or KERNEL MTD and get the default ECC info for the pages written to the OOB automatically.    

 

I am curious which yaffs2/mkyaffs2image source you used to prepare your FS images.  I’ve noticed in previously mentioned threads that a duo of patches are required to prepare it for integration to the kernel.  I’ve tried applying these patches but with little luck.  Perhaps my sources or patches are outdated.   

My attempt was based on:

 

git clone git://www.aleph1.co.uk/yaffs2 
git co e8cfe05cf0d057f6978c37943e51b17bb14664e3 

 

Did you come up with your own solution to fixing the kernel and mkyaffs2image or did you also use the git and patches as I did?

 

In my efforts, I have also been tackling ECC layout questions w.r.t. UBOOT versus user space

upgrading of components.  My user space component upgrade application now depends

on the default OOB layout enforced by the kernel MTD driver.  I would like to keep this intact

if possible.  I am concerned but also assume that YAFFS2 will not care about which of the

different ECC OOB layouts are in place if it is mounted with the in-band tagging option enabled.

I am hoping that someone may have some further insight on how to coordinate the format

of these components.

Yes, mounting old/new formats is an issue. We had to dance very carefully around mounting. I think the short answer is you might have to move content temporarily off to some other storage (ram drive?) and then remount the yaffs with OOB, then move the data back... This may or may not work depending on your use case.

It may be possible to do it without the offline copy but we couldn't find a better solution in the amount of time we could spend looking at it. We had to sniff out the older mount partitions and mount them in "compatibility" mode so we don't trash data - the logic basically just overrides mount arguments when the older format is detected.

 

At this point, I still haven’t quite figured out how to automatically mount this YAFFS2 rootfs without tags during kernel boot, but I assume this can be achieved through some BOOTARGS mod. 

Hope this helps.

Alan