[Yaffs-archive] Re: Latest CVS

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Nick Bane
Date:  
To: tglx, yaffs list
Subject: [Yaffs-archive] Re: Latest CVS
> You can also select NAND_ECC_SW as long as your filesystem driver is using
> either mtd->read /write or mtd->read/write_ecc with NAND_NONE_OOB, which

is
> the case for YAFFS.mtd->read defaults to mtd_read_ecc (.......,
> NAND_NONE_OOB). Same for mtd->write.
>

Ok. This is not part of 2.4.19-rmk4 yet so I'll wait on Charles to decide to
move the yaffs mtdinterface to use it. This is clearly the way to do it one
everyome has caught up.

> Multiple flesystems are supported since version 1.30, which was committed

to
> mtd-cvs on 8-29-02. I have running a JFFS2 partition and a YAFFS partition

on
> the same chip without any modifications to nand driver, JFFS2 and YAFFS..
> JFFS2 uses nand driver builtin ECC and YAFFS uses it's own.
>

Ok. Same answer as above.

> The driver supports runtime per partition selection, but not for the

ECC_MODE.
> It supports the selection of ECC data placement in the oob area. Currently
> there are 3 placements supported:
> NAND_NONE_OOB: No ECC is calculated and placed in oob area
> NAND_JFFS2_OOB: calc ECC using the selected ECC-Mode and place the ECC

data
> in the appropriate place for JFFS2
> NAND_YAFFS_OOB: calc ECC using the selected ECC-Mode and place the ECC

data in
> the appropriate place for YAFFS
>

Understood.

> It makes _NO_ sense to select different ECC-Modes for one chip. If you

have
> Hardware-ECC you will use it for your hole chip and you _CANNOT_ switch
> between the different hardware ECC modes, as your ECC generator has one

fixed
> algorithm to build ECC. The only exception is a ECC, which is supplied by

the
> filesystem and for that you can select NAND_NONE_OOB.
>

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.

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.

As you say, NAND_NONE_OOB is the right choice in these cases.

Nick
> --
> 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.