[U-Boot] UbiFS recovery

[U-Boot] UbiFS recovery

[Karsten Jeppesen]

Hi there,

I have a (to me) serious problem.
When U-Boot encounters a UbiFS system that needs cleaning, then it is not always capable of it despite the kernel (I understand it's the same code)  having no problems cleaning the filesystem.
I think I have traced it to super.c where U-Boot only opens the filesystem MS_RDONLY.
Needless to say it's a catch 22 since my kernel resides within the UbiFS.

How can this issue be solved? Some posts suggest that upping the memory allocation should solve this, but my attempts to solve it this way have been short of successful.
Would it be a solution to have an option to access the UbiFS read-write?


Karsten Jeppesen, D.D.S;  Bsc. CS
Senior Software Engineer
Ext.: +45 72 17 56 69
Mobile phone: +45 25 66 00 23
______________________________________
SKOV A/S
Hedelund 4, Glyngoere, 7870 Roslev, Denmark
Tel.: +45 72 17 55 55 - Fax: +45 72 17 59 59
www.skov.com<http://www.skov.com/>

[KJP-QR]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 18537 bytes
Desc: image001.jpg
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130613/34321ca3/attachment.jpg>

[U-Boot] UbiFS recovery

[Henrik Bork Steffensen]

On 13/06/13 07:37, Karsten Jeppesen wrote:
> I have a (to me) serious problem.
> When U-Boot encounters a UbiFS system that needs cleaning, then it is not always capable of it despite the kernel (I understand it's the same code)  having no problems cleaning the filesystem.
> I think I have traced it to super.c where U-Boot only opens the filesystem MS_RDONLY.
> Needless to say it's a catch 22 since my kernel resides within the UbiFS.
>
> How can this issue be solved? Some posts suggest that upping the memory allocation should solve this, but my attempts to solve it this way have been short of successful.
> Would it be a solution to have an option to access the UbiFS read-write?
>
Hi!
I work with Karsten on this issue, and I just want to add a few details:

It is a "u-boot 2012.10" version of u-boot.
It runs on a custom at91sam9263 platform. This particular platform is 
rather close to the at91sam9263ek.
This target currently boots from NOR flash, but this will be changed in 
near future to NAND.

Under normal circumstances u-boot loads the Linux kernel from ubifs 
without any problems.
But when the ubifs partition needs work before mounting - it fails like 
the this example:
SKOV A/S> boot
NOR BOOT
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nor0":
0x0000000a0000-0x000004000000 : "mtd=2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    130944 bytes
UBI: smallest flash I/O unit:    1
UBI: VID header offset:          64 (aligned 64)
UBI: data offset:                128
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=2"
UBI: MTD device size:            63 MiB
UBI: number of good PEBs:        507
UBI: number of bad PEBs:         0
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: 507
UBI: number of PEBs reserved for bad PEB handling: 0
UBI: max/mean erase counter: 12/1
UBIFS error (pid 0): ubifs_recover_master_node: failed to recover master 
node
UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume 
'ubi:Rootfs1' errno=-12!

This log was from before Karsten increased CONFIG_SYS_MALLOC_LEN from 
700 KB to 8 MB, so it might be a bit outdated.
Karsten: will You post a update on this?

We would like to get any hints on this issue.
Info on how Your guys see the maturity of this ubi implementation will 
be appreciated too.

Thanks in advance  :-)


best regard,
Henrik Bork Steffensen
Rose Technology A/S