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

[Detlev Zundel]

Hi Artem,

> On Fri, 2011-04-29 at 13:58 +0200, Detlev Zundel wrote:
>> 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?
>
> I do not know why I'm in CC, but I see that the code to skip all 0xFFs
> looks like it was copied from UBI. The reason why UBI and UBI user-space
> tools skip NAND pages with all 0xFFs when writing is described here:
>
> http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
>
> If it is too long to read, in short:
>
> 1. if we write to flash, we always write to an erased eraseblock,
> obviously :-)

Yes - I simply wasn't sure if the software layers below (in U-Boot)
would do an "erase on demand" before writing.  Reading the code, this
isn't the case (I should have known this), so the skipping should really
be safe.

> 2. erased erase block contains all 0xFFs, so skipping 0xFF NAND pages is
> harmless.
> 3. writing 0xFF pages has side-effects - the ECC bytes in OOB will be
> used
> 4. If we are flashing an UBIFS image, UBIFS will use the half-filled
> eraseblocks, and if the "free" pages were written with 0xFFs, they'll
> become unusable.
>
> So we skip 0xFF pages at the end. Not all, only the last ones. E.g., if
> your eraseblock consists of 4 pages, and you write "data, 0xFFs, data,
> 0xFFs", then we'll only write "data, 0xFFs, data", so that the last NAND
> page can be used later.
>
> Sorry for my poor English, and I'm writing in a hurry - have to have to
> a pub to farewell several colleagues who are leaving the company :)

Thanks for your input.

So I still fail to see where the ECC errors come from.  The closes thing
that makes sense for me, is that Bens problem very likely wasn't ECC
connected at all but the result of the "not capable to write twice".
I.e. his NAND flashes cannot be written to twice.  When he flashed the
images in U-Boot, there were trailing empty blocks that got programmed
and UBIFS assumed that it _could_ write to them so it tried and failed
and somehow got tripped up over this.

If this is the case then we should change the commit message to point to
the real problem that this patch fixes.

Cheers
  Detlev

-- 
``The number of UNIX installations has grown to 10,
with more expected.''     Unix Programmers Manual -- 1972
The number of UNIX variants has grown to dozens,
with more expected.                               -- 2001
--
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