UBIFS Corrupt during power failure

[Eric Holmberg]

> 
> On Mon, 2009-07-06 at 09:43 +0300, Artem Bityutskiy wrote:
> > On Mon, 2009-07-06 at 07:51 +0300, Artem Bityutskiy wrote:
> > > > [CCed Nicolas Pitre]
> > > > 
> > > > OK, I've written a small user-space program which first 
> fills the NOR
> > > > flash with an '0x89ABCDEF' pattern, then starts erasing 
> it, and then
> > > > I cut the power at random point.
> > > > 
> > > > And unfortunately the power cut results in eraseblocks 
> which have
> > > > 0x89ABCDEF at the beginning, and all zeroes at the end. 
> I've attached
> > > > one example.
> > > > 
> > > > So it indeed looks like NOR erasure includes writing 
> zeroes from the
> > > > end. Unfortunately UBI/UBIFS cannot handle this correctly ATM.
> > > 
> > > Although I can easily fix this by writing few zeroes at 
> the beginning of
> > > the eraseblock _before) erasing it, so that UBI will be 
> happy. But it is
> > > still interesting whether I may just ask NOR to amend 
> it's embedded
> > > erase algorithm.

This is exactly what I was seeing as well.  Here's a snippet from the
flash test code that I wrote that was very similar to your code:

Sector start:  0x3002 0000
Sector end:    0x3003 ffff
Data in block: aa55aa00

Interrupted during an erase cycle as 1's were being changed to 0's.

30204f60  aa55aa00 aa55aa00 aa55aa00 aa55aa00  <-- correct test pattern
30204f70  aa55aa00 aa55aa00 aa55aa00 aa55aa00
30204f80  aa55aa00 aa55aa00 aa55aa00 aa55aa00
30204f90  8254aa00 8841a000 a0408800 a8458000  <-- inbetween data
30204fa0  00000000 00000000 00000000 00000000  <-- zero's
30204fb0  00000000 00000000 00000000 00000000

I verified with Spansion that the embedded erase algorithm first clears
all 1's to 0's before erasing the bits to charge them back up to 1.

Essentially, the contents of the PEB are indeterminate between the start
and completion of an erase cycle.  The erase algorithm isn't
configurable, so we are stuck with this behavior.

> > 
> > This patch seems to fix the UBI issues Eric and me observed 
> (issue N2).
> > I'll test the patch for few days, but I couldn't see any 
> problem so far.

The patch to write to the header is a great solution and I think it's
the only possible solution.  Performance should be fine, since the
4-byte write should only take about 0.5ms which is insignificant
compared to a typical PEB erase time of 700ms.

I will run 4 boards through torture tests starting tonight and let you
know later this week!  Based upon the errors that I've seen and looking
at the patch, I think that should solve the problem.

Great work guys!

-Eric

> > 
> > From: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> > Subject: [PATCH] UBI: fix NOR flash recovery
> > 
> > This commit fixes NOR flash recovery issues observed with Spansion
> > S29GL512N NOR.
> > 
> > When NOR erases, it first fills PEBs with zeroes, then sets 
> all bytes
> > to 0xFF. Filling with zeroes starts from the end of the 
> PEB. And when
> > power is cut, this results in PEBs containing correct EC 
> and VID headers
> > but corrupted with zeros at the end. This confuses UBI and 
> it mistakinly
> > accepts these PEBs and associate them with LEBs.
> > 
> > Fis this issue by zeroing EC and VID magics before erasing PEBs, to
> > make UBI later refuse zem.
> > 
> > Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> 
> Yes, it fixes the issue. The device has already survived ~1500 power
> cuts and no problems. It used to die after about 50 power cuts. I'm
> pushing this to ubi-2.6.git.
> 
> So if Eric is still interested, he can try it when he is back from the
> holidays.
>