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.
(text/plain)