First off, please forgive the lack of indentation. One day I will figure out how this horrible M$ mail browser works. It's great to see this discussion happening. I must admit that my first mtd interface was minimalistic, some NAND things seemed to be in flux at the time. The main aim in keeping the nand interface distinct from yaffs_guts was to facilitate this kind of tweaking etc. It seems though that I should have scooped off a bit more (eg including ECC and verify). I will do this in YAFFS2. Thomas is correct in what he says below. YAFFS's preferred way of doing things is to do the data and oob writes in one hit. Thomas' patches to use write_ecc do this (I believe) and probably provide a significant speed-up since two programming operations are replaced with one. I will look at the use of verify too. My current stuff is built on 2.4.18 (we used that as a springboard for YAFFS). Maybe it is time to move and apply mtd patches. Suggestions? I am a bit concerned that moving too fast on mtd might mean that YAFFS would then require new features and lose backward compatibility. Thoughts? -- Charles -----Original Message----- From: Thomas Gleixner [mailto:tglx@linutronix.de] Sent: Monday, 25 November 2002 11:01 a.m. To: Nick Bane; yaffs list Cc: Jeffrey Lim; manningc2@actrix.gen.nz Subject: Re: Latest CVS On Sunday 24 November 2002 20:00, Nick Bane wrote: > Well I might offer one more instance - and that relates to yaffs too. That > is when the fs uses other parts of the oob data and is running on chips > that only accept two writes to the oob area. Under those circumstances we > want the fs and not the mtd layer to do the writing assuming that a second > write to the oob is part of the fs's bad block strategy. If I understand YAFFS correctly, then the OOB data are written in one go together with data. So the fs supplies all oob data except ECC and the driver fills in either SW or HW generated ECC at the appropriate place for the calling fs. So fs supplied OOB data and ECC are written in one cycle. It's not a two step procedure. > Also, if I am being picky, I believe that hardware assisted ecc can be > implemented where the hardware just does the arithmetic. It is then up to > the driver to read that data and write it out to the oob. If it *really* > wanted to, an fs could ignore the results and write something else. This > would make it reasonable for fs's on different partitions to use/ignore the > Hardware ECC. Yep, but I assume, that somebody, who has HW ECC is willing to use it. And all NAND aware filesystems will use ECC. I was curious and modified YAFFS to use nand ecc. It works. The modifications are really small. I copied files around with nandecc enabled and verified it afterwards with nandecc disabled. Enable/disable is in YAFFS only, not in nand.c, where NAND_SW_ECC is selected for the hole chip, as I have a JFFS2 root partition on the same chip. This runs on top of current MTD-CVS without any modification. The NAND driver HW-ECC support is therefore available for YAFFS out of the box. A penalty is that I have to copy oob data around on read, because NAND driver returns 16Byte OOB data and 2 x 4 Byte ECC correction result. This was a request of Charles, when we discussed some YAFFS issues before I did the big nand.c overhaul. This behaviour is a subject, which could be changed, as the only user would be YAFFS at the moment, AFAIK. A further improvement would be to use the NAND driver write verify function and skip this function in YAFFS. Therefor the return value from mtd->write_ecc has to be evaluated inside YAFFS. This would be recommended, if you intend to use JFFS2 and YAFFS together and want to have the write verify for both filesystems. At the moment a double checking is done for YAFFS, if it is enabled in the nand driver. JFFS2 does not support write verify in the fs layer. It relies on the write verify of the nand driver and handles the results. Patch attached. Jeffrey: Forgive me, that I did not change the if statements. I was to lazy :) I have added a section about this issue to http://www.linux-mtd.infradead.org/tech/nand.html. -- Thomas ____________________________________________________ linutronix - competence in embedded & realtime linux http://www.linutronix.de mail: tglx@linutronix.de --------------------------------------------------------------------------------------- This mailing list is hosted by Toby Churchill open software (www.toby-churchill.org). If mailing list membership is no longer wanted you can remove yourself from the list by sending an email to yaffs-request@toby-churchill.org with the text "unsubscribe" (without the quotes) as the subject.