UBIFS Corrupt during power failure
Eric Holmberg
Eric_Holmberg at Trimble.com
Fri Apr 10 10:27:04 EDT 2009
> On Mon, 2009-03-30 at 13:00 -0600, Eric Holmberg wrote:
> > Here is a basic summary of my findings to date for debugging
> > corruption of the root UBIFS volume which is located on NOR flash.
> > Please comment if you have any suggestions.
> >
>
> Hi, any news? Have you tried to enable UBI/UBIFS extra checks?
Hi Artem,
I have enabled the extra checks and the failure messages and they didn't
provide any additional information. Since we have custom hardware, I
wrote some software that writes test patterns to the flash in U-Boot to
verify that we do not have an underlying problem with the NOR flash.
The software writes a test pattern to each physical erase block (PEB)
and then randomly erases and rewrites a sector with the test pattern
AA55AA## where ## is the block number. A script then performs a
hardware reset of the processor and flash using JTAG. All physical
sectors are verified after the erase and again after the write.
I did not see any issues where multiple PEB's were corrupted, but the
block being written or erased had some unexpected patterns when the
flash was reset during the middle of an operation.
Test setup:
* Using U-Boot 1.3.0
* Write buffering enabled
* S29GL256F 256Mbit NOR flash w/ 32-word write buffer
* Test software that performs read/erase/write operations
* JTAG debugger that randomly resets the board
Reset during write (unexpected test pattern written after un-programmed
values):
30352240 aa55aa0a aa55aa0a aa55aa0a aa55aa0a
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
303522e0 ffffffff ffffffff ffffffff ffffffff
Reset during erase (unexpected - 1's change to zeros during erase):
30249930 aa55aa02 aa55aa02 aa55aa02 aa55aa02
30249940 aa55aa02 aa55aa02 aa55aa02 aa55aa02
30249950 8a51aa02 aa55aa02 a855aa02 aa55aa02
30249960 00000000 00000000 00000000 00000000
30249970 00000000 00000000 00000000 00000000
30249980 00000000 00000000 00000000 00000000
30249990 00000000 00000000 00000000 00000000
302499a0 00000000 00000000 00000000 80000000
302499b0 02000001 00000000 00000000 00000000
302499c0 00040000 00000000 00000000 80000000
Reset during erase (expected erase behavior - 0 not yet changed to 1):
30248ed0 ffffffff ffffffff ffffffff ffffffff
30248ee0 ffffffef ffffffff ffffffff ffffffff
30248ef0 ffffffff ffffffff ffffffff ffffffff
Questions
---------
How are interrupted writes or erase cycles handled in UBI / UBIFS for
NOR flash? Are the unexpected PEB values that I am seeing properly
handled by the UBI/UBIFS error recovery process? Are erase and write
operations journaled to allow restarting the process upon boot-up?
As a side note, MTD_BIT_WRITEABLE is not set for the NOR flash. Is this
to be expected? Do I need to set this in the partition table? The NOR
flash does support programming a 1 to a 0, which is what I'm assuming
MTD_BIT_WRITEABLE means.
root at device:/# mtd_debug info /dev/mtd3
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 29360128 (28M)
mtd.erasesize = 131072 (128K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0
Thanks for your help and time!
Regards,
Eric Holmberg
More information about the linux-mtd
mailing list