On 7 March 2012 14:42, Alex Zeffertt <azeffe...@cambridgesys.com> wrote:
> Hi u-booters,
>
> I have a short script in my u-boot environment which chooses which of
> two ubifs partitions to boot
> by attempting to read a release file in each one.
>
> Unfortunately, after an unclean shutdown sometimes the ubifsmount
> fails. (By "unclean shutdown"
> I mean that the board was power cycled while doing some low bandwidth
> logging.)
>
> The strange thing is that Linux has no problem mounting the partition
> as its root filesystem. This is
> very confusing because it looks like the ubifs implementation in
> u-boot is just a copy of the one in Linux.
>
> Has anyone else seen this problem?
>
> Regards,
>
> Alex
>
> PS My kernel is linux-3.0.0/armv5tel and the full u-boot trace is below:
>
>
>> U-Boot 2011.06 (Feb 10 2012 - 12:29:06)
>> OpenRD-Base
>> SoC: Kirkwood 88F6281_A1
>> DRAM: 128 MiB
>> NAND: 512 MiB
>> *** Warning - bad CRC, using default environment
>> In: serial
>> Out: serial
>> Err: serial
>> Net: egiga0
>> 88E6351 Initialized on egiga0
>> Hit any key to stop autoboot: 0
>> Creating 1 MTD partitions on "nand0":
>> 0x000001000000-0x000010000000 : "mtd=2"
>> UBI: attaching mtd1 to ubi0
>> UBI: physical eraseblock size: 131072 bytes (128 KiB)
>> UBI: logical eraseblock size: 126976 bytes
>> UBI: smallest flash I/O unit: 2048
>> UBI: sub-page size: 512
>> UBI: VID header offset: 2048 (aligned 2048)
>> UBI: data offset: 4096
>> UBI: attached mtd1 to ubi0
>> UBI: MTD device name: "mtd=2"
>> UBI: MTD device size: 240 MiB
>> UBI: number of good PEBs: 1913
>> UBI: number of bad PEBs: 7
>> UBI: max. allowed volumes: 128
>> UBI: wear-leveling threshold: 4096
>> UBI: number of internal volumes: 1
>> UBI: number of user volumes: 1
>> UBI: available PEBs: 0
>> UBI: total number of reserved PEBs: 1913
>> UBI: number of PEBs reserved for bad PEB handling: 19
>> UBI: max/mean erase counter: 7/1
>> UBIFS: recovery needed
>> Error reading superblock on volume 'ubi:rootfs'!
>> UBI: mtd1 is detached from ubi0
I've been comparing the linux and u-boot implementations, and it looks
like the following fix is in the kernel
but not in u-boot. I don't really understand it, but it looks like a
candidate. Might porting this change to
u-boot fix the issue?
- Alex
commit 2ef13294d29bcfb306e0d360f1b97f37b647b0c0
Author: Artem Bityutskiy <artem.bityuts...@nokia.com>
Date: Sun Sep 19 18:34:26 2010 +0300
UBIFS: introduce new flags for RO mounts
Commit 2fde99cb55fb9d9b88180512a5e8a5d939d27fec "UBIFS: mark VFS SB RO too"
introduced regression. This commit made UBIFS set the 'MS_RDONLY'
flag in the
VFS superblock when it switches to R/O mode due to an error. This was done
to make VFS show the R/O UBIFS flag in /proc/mounts.
However, several places in UBIFS relied on the 'MS_RDONLY' flag
and assume this
flag can only change when we re-mount. For example, 'ubifs_put_super()'.
This patch introduces new UBIFS flag - 'c->ro_mount' which changes only when
we re-mount, and preserves the way UBIFS was originally mounted
(R/W or R/O).
This allows us to de-initialize UBIFS cleanly in 'ubifs_put_super()'.
This patch also changes all 'ubifs_assert(!c->ro_media)' assertions to
'ubifs_assert(!c->ro_media && !c->ro_mount)', because we never should write
anything if the FS was mounter R/O.
All the places where we test for 'MS_RDONLY' flag in the VFS SB were changed
and now we test the 'c->ro_mount' flag instead, because it preserves the
original UBIFS mount type, unlike the 'MS_RDONLY' flag.
Signed-off-by: Artem Bityutskiy <artem.bityuts...@nokia.com>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
