[Yaffs-archive] RE: Latest CVS

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: 'tglx@linutronix.de', Nick Bane, yaffs list
CC: Jeffrey Lim, manningc2
Subject: [Yaffs-archive] RE: Latest CVS
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;
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:


---------------------------------------------------------------------------------------
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 with the text "unsubscribe"
(without the quotes) as the subject.