Hi Ben, > It was found that on da850evm, where the NAND ECC used does not map all 0xff > data to 0xff ECC, that flashing UBI and JFFS2 image from U-boot with nand > write[.e] command resulted in alot of ECC errors... for UBI the result was > an unmountable filesystem on second attach from linux. For JFFS2 the result > was > a multitude of ECC errors printed on the cosole on the second mount in Linux > -- > the filesystem remains mountable for awhile but eventually collapses.
I am not sure that I can follow you here so I have to ask you to clarify the problem for me. I understand that a page of 0xffs does _not_ have an ECC of all 0xffs. Actually I would be surprised if there was any ECC having this property, so I doubt that this is da850 specific, correct? So I am wondering about two things: - If I erase a page in NAND, will the ECC be updated by someone or will it be 0xffs? If the latter, then is it "normal" to have ECC errors on freshly erased pages? - If we (correctly) "write" 0xffs even to an erased page, a generated ECC should match this content, so I do not see where ECC errors should come from in this setting. Summarily, I do not understand where the ECC errors came from in your setup and what the faulting party in that scenario actually is/was. Can you please enlighten me? Thanks Detlev -- SWYM XYZ (Sympathize with your machinery). [..] In fact it is often called a no-op, because it performs no operation. It does, however, keep the machine running smoothly, just as real-world swimming helps to keep programmers healthy. -- Donald Knuth, Fascicle 1 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot