On Tuesday 23 October 2012 12:36:24 Willie Mah wrote: > Thx for your response Alan. > > From: yaffs-bounces@lists.aleph1.co.uk > [mailto:yaffs-bounces@lists.aleph1.co.uk] On Behalf Of Alan Moore Sent: > Monday, October 22, 2012 1:18 PM > To: yaffs@lists.aleph1.co.uk > Subject: Re: [Yaffs] yaffs2 with hw ecc enabled > > On 10/22/2012 10:13 AM, Willie Mah wrote: > 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. > > The threading markers seem to have been lost. I would like to just make is very clear that Yaffs2 does not care what ECC strategy you use or if you use one at all. Find a way to use jelly beans and duct tape and Yaffs does not care. Some HWECC strategies use more of oob/spare area and make it harder to use the spare area to store tags. If so, then use inband tags. I just helped to set up someone doing this a few weeks back and it all just worked straight out of the box. I was mounting after boot, but I think there is some way to pass root mount options on the command like. If not, it should be easy enough to patch the yaffs vfs glue code to do what you need. -- CHarles -- Charles