UBIFS Corrupt during power failure
Artem Bityutskiy
dedekind at infradead.org
Tue Apr 14 02:11:40 EDT 2009
On Fri, 2009-04-10 at 12:33 -0600, Eric Holmberg wrote:
> > On Fri, 2009-04-10 at 11:00 -0600, Eric Holmberg wrote:
> > > Thank you very much for your help so far.
> > NP, this is all I can do now without having real NOR and much time :-)
> >
> > > I am going to do two things:
> > > 1. Turn off write buffering which converts the NOR minimum
> > I/O size from 1 to effectively 32 16-bit words (64 bytes) and
> > re-run all of the tests.
> >
> > Err, which buffering? Is this something at the flash driver level?
>
> This is for the CFI flash interface. The
> drivers/mtd/chips/cfi_cmdset_0002.c driver has write buffers which is
> uses to do a "block" write to the NOR flash which for my chip allows
> writing up to 32 16-bit words.
Oh, this is something from the CFI standard? Then we may just add this
knowledge to UBIFS: if this is NOR, then UBIFS knows that the up to 64
bytes may contain garbage.
> This is what I used for the tests with
> U-Boot and it is why you see patterns such as the one below. The code I
> used to write this pattern to flash wrote the entire block in 1 write.
> The CFI driver then broke up the writes into 64-byte writes.
> Apparently, it didn't do them in order (or the flash chip didn't), which
> is why you have aa55aa0a values after ffffffff values. Turning off the
> write buffering in the CFI driver by setting FORCE_WORD_WRITE to 1
> should solve this (although it will now probably be somewhere between
> 10x and 32x slower).
Yes, it is worth disabling this and test. If it helps, we can add
some CFI/NOR-awareness to UBIFS.
> 30352250 aa55aa0a aa55aa0a aa55aa0a aa55aa0a
> 30352260 aa55aa0a aa55aa0a aa55aa0a aa55aa0a
> 30352270 aa55aa0a aa55aa0a aa55aa0a aa55aa0a
> 30352280 ffffffff ffffffff ffffffff ffffffff
> 30352290 ffffffff ffffffff ffffffff ffffffff
> 303522a0 ffffffff ffffffff ffffffff ffffffff
> 303522b0 aa55aa0a aa55aa0a aa55aa0a aa55aa0a
> 303522c0 ffffffff ffffffff ffffffff ffffffff
> 303522d0 ffffffff ffffffff ffffffff ffffffff
>
> Does that make sense now, or am I on the wrong path?
Yes, makes perfect sense for me.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
More information about the linux-mtd
mailing list