Nick
A few points:
* YAFFS applies its own ecc, so the mtd level ecc (CONFIG_MTD_ECC or
whatever) should be off. I believe this is documented in the
yaffs_on_mtd.html doc. If this is not clear enough, I will clarify the doc.
* Unlike NOR, you can attempt to write 1's on top of 0's without the
operation failing. The result is the logical AND of the two. ie. programming
0xFE on top of 0x07 should yiled 0x06. Well that's my current belief anyway
(and how I have implemented the writes in the nandemul layer). I will
investigate further to check.
The idea to associate the ECC/OOB mapping with the partition is a good one,
since the ECC location issue does not just apply to YAFFS and it is very
likely that people might want to put different file sytems on different
partitions.
-- CHarles
On Fri, 31 May 2002 07:02, Nick Bane wrote:
> Copy of a post to Charles/Wookey and a followup.
>
> Using the latest yaffs driver with 2.4.18-rmk4-tcl1 on balloon rev#2 yields
> a problem with
> ecc.
>
> Yaffs tries to write a 512 byte nand page and then write 16 bytes of yaffs
> oob data. The act of writing the full 512 byte page updates the oob data
> which then is unable to be overwritten by the yaffs oob data. This failure
> causes repeating retries.
>
> I confirmed this by getting yaffs_mtdif.c to display the oob data before
> and after the 512 byte write (all 0xffs => 0xffs plus ecc updated) and the
> oob write (incompatible ecc fields).
>
> It seems (see dump below) that the oob data is written twice but that the
> data is different and that the last oob data element on the second pass is
> 0xff where the previous data had 0x57 - clearly this cannot succeed without
> an erase.
>
> After all of this, do I take it that MTD_ECC needs to be turned off for
> yaffs? If so then it makes other use of nand for other fs use (eg jffs2 or
> cramfs) unable to use ecc which has serious data integrity issues. Thomas
> Gleixner's 2.4.18 nand.c code has the possibility of changing the
> ecc locations but not at runtime. If it could be specified at
> runtime -including no ecc- and select the locations from a table on a
> per-partition basis then yaffs could coexist nicely.
>
> Nick Bane
>
> -----------------------
> modified yaffs_mtdif.c output
> yaffs oob existing data prior to writing data:
> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
> 0xff
> yaffs: writing 512 bytes data to 16384
> yaffs: writing 0x10 bytes data to 0x4000:
> yaffs oob current data:
> 0xff 0xf0 0xf 0xaa 0x59 0x57 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
> 0xff
> yaffs oob data to be written:
> 0x0 0x0 0xd0 0xff 0xff 0xff 0x3 0x1 0xff 0xf0 0xf 0x10 0xc0 0xaa 0x59 0x57
> nand_write_oob: Failed write verify, page 0x00000020
> yaffs: writing 0x10 bytes data to 0x4000:
> yaffs oob current data:
> 0x0 0x0 0x0 0xaa 0x59 0x57 0x3 0x1 0xff 0xf0 0xf 0x10 0xc0 0xaa 0x59 0x57
> yaffs oob data to be written:
> 0x0 0x0 0x10 0x0 0xff 0xff 0x0 0x0 0xff 0xff 0xff 0xac 0xc0 0xff 0xff 0xff
> nand_write_oob: Failed write verify, page 0x00000020
>
>
> ---------------------------------------------------------------------------
>- ---------------
> Followup post.
>
> Commenting out ecc on page writes gives me a persistant yaffs fs for the
> first time but ... with zero filesize for the copied files on remounting.
> This might be due to an ecc failure on read as the ecc bytes expected are
> not those written by yaffs but ... there were no nand_read_ecc whinges
> (MTD_DEBUG level 2). A mystery still.
>
> Ecc in general.
>
> We need to be able to turn this on and off on a per-partition basis so that
> we can co-exist with other partitions.
>
> May I suggest that the mtd_info.ecctype can be used? We can make nand ecc
> usage conditional on various checks such as ecctype==MTD_ECC_SW_YAFFS.
> Extending the partition structure to add a flag for ecctype means that the
> master->slave transformation in mtdpart.c can override the ecctype of each
> mtd_info set up for each chip on a partition by partition basis just as one
> can alter the MTD_WRITEABLE flag to make a partition read-only. This could
> of course be extended to code for the native and jffs2 ecc types too with a
> table based lookup maybe?
>
> An aside: At present there seems to be no config support for raw nand using
> some fpga for ecc calculation that would mean the ecctype would not be
> MTD_ECC_SW yet ecc support of some kind would be needed.
>
> Nick Bane
> cc Thomas Gleixner (nand mtd maintainer)
>
>
>
> ---------------------------------------------------------------------------
>------------ 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.
---------------------------------------------------------------------------------------
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.
(text/plain)