From: Bill Pringlemeir <bpringlemeir@nbsps.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Unreadable UBIFS partition after power cuts
Date: Fri, 16 Jan 2015 10:42:20 -0500 [thread overview]
Message-ID: <87iog63f6r.fsf@nbsps.com> (raw)
In-Reply-To: 150521CB44B50A4A98049E9C7BAFB0F30D9C15C8@DETENEXMB01.delta.corp
On 16 Jan 2015, Anton.Habegger at delta-es.com wrote:
> What does a "dangling branch" and "dangling match" mean? Are those
> situations handled differently under U-Boot?
... I don't know about this. However, it is easy to think that the
issue is with the UbiFs layer as it doesn't mount. However, it can be
several layer; the MTD driver, MTD, UBI and UbiFS. I guess you have
some raw image captured? If you have a raw NAND image you can try
different analysis.
Here is a nandsim mount to emulate on a PC.
# nandsim with Micron 3.3V 256MiB, 2048 bytes page.
modprobe nandsim first_id_byte=0x2c second_id_byte=0xda third_id_byte=0x90 fourth_id_byte=0x95 parts=2,64,64
flash_erase /dev/mtd3 0 0
ubiformat /dev/mtd3 -f rootfs.ubi # rootfs.ubi is the flash dump
#modprobe ubi mtd=3
#mount -t ubifs -o ro /dev/ubi0_3 /mnt/ubifs
You can put the flash id sequence for your boards flash in the 'id_byte'
and setup different partitions to emulate your actual device (ie, your
parts=... is different).
The last two lines will mount the partition using the Linux PC code.
Grab 'git://git.infradead.org/mtd-utils.git'. There is a file in
ubi-utils called ubinfo.c and it maybe helpful. Also, hujian yang has
been trying to get a 'ubidump' program merged to mtd-utils.
See:
http://lists.infradead.org/pipermail/linux-mtd/2014-December/056828.html
http://lists.infradead.org/pipermail/linux-mtd/2014-December/056829.html
and many others. The program might be helpful. I think there aren't
functional issue with the current patches, but structural issues
(fitting with mtd-utils).
In this message I attached a much simpler parser of just the UBI layer
(this is really dumb, but should be easy to modify).
http://lists.infradead.org/pipermail/linux-mtd/2014-July/054712.html
They might be useful to identify injured blocks/pages. Obviously, the
'recovery needed' shows that fixing some partial write/erase is the
issue. If UBI passes a damaged page/info to UbiFS, then it will act on
bad info.
Fwiw,
Bill Pringlemeir.
next prev parent reply other threads:[~2015-01-16 15:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 12:52 [U-Boot] Unreadable UBIFS partition after power cuts Anton Habegger
2015-01-14 14:57 ` Heiko Schocher
2015-01-14 17:12 ` Anton Habegger
2015-01-15 7:28 ` Heiko Schocher
2015-01-16 15:10 ` Anton Habegger
2015-01-16 15:21 ` Anton Habegger
2015-01-16 15:42 ` Bill Pringlemeir [this message]
2015-01-16 17:47 ` Anton Habegger
2015-01-17 16:06 ` Anton Habegger
2015-01-18 10:07 ` Heiko Schocher
2015-01-19 11:29 ` Anton Habegger
2015-01-20 7:26 ` Heiko Schocher
-- strict thread matches above, loose matches on Subject: below --
2015-01-16 15:38 Anton Habegger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87iog63f6r.fsf@nbsps.com \
--to=bpringlemeir@nbsps.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.