[U-Boot] UbiFS recovery
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.comhttp://www.skov.com/
[KJP-QR]
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
participants (2)
-
Henrik Bork Steffensen -
Karsten Jeppesen