[U-Boot] [PATCH 0/5] introduce nand write.ubi, and drop ffs for jffs2 too

[Detlev Zundel]

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: dzu at denx.de