[U-Boot] UBIFS fails on SheevaPlug
HI, After power short u-boot fails to mount UBIFS and board stuck. Below is a trace of u-boot
Marvell>> boot
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nand0":
0x000000500000-0x000020000000 : "mtd=2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=2"
UBI: MTD device size: 507 MiB
UBI: number of good PEBs: 4055
UBI: number of bad PEBs: 1
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: 4055
UBI: number of PEBs reserved for bad PEB handling: 40
UBI: max/mean erase counter: 1/0
UBIFS: recovery needed
Error reading superblock on volume 'ubi:rootfs'!
UBIFS not mounted, use ubifs mount to mount volume first!
UBIFS not mounted, use ubifs mount to mount volume first!
Wrong Image Format for bootm command
ERROR: can't get kernel image! Marvell>>
To recover from this situation I boot from USB stick and simply mounts the same UBIFS partition:
root@debian:~# mount -t ubifs ubi0:rootfs /mnt [ 306.205029] UBIFS: recovery needed [ 309.341987] UBIFS: recovery completed [ 309.345705] UBIFS: mounted UBI device 0, volume 0, name "rootfs" [ 309.351738] UBIFS: file system size: 515192832 bytes (503118 KiB, 491 MiB, 3993 LEBs) [ 309.359789] UBIFS: journal size: 25804800 bytes (25200 KiB, 24 MiB, 200 LEBs) [ 309.367495] UBIFS: media format: w4/r0 (latest is w4/r0) [ 309.373352] UBIFS: default compressor: lzo [ 309.377479] UBIFS: reserved for root: 4952683 bytes (4836 KiB)
As you can see mount manage to recover partition. Is where any way to make u-boot to recover UBIFS partition as well? What else can I do to make my system stable and survive power shorts?
Thanks.
Dear Dimax,
HI, After power short u-boot fails to mount UBIFS and board stuck. Below is a trace of u-boot
Marvell>> boot
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nand0":
0x000000500000-0x000020000000 : "mtd=2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
[...]
1) Is this an upstream u-boot? 2) Can you NAND (driver) do subpage writes ?
Best regards, Marek Vasut
Hi. 1) Is this an upstream u-boot?
Marvell>> version
U-Boot 2011.12 (Jan 08 2012 - 21:53:47) Marvell-Sheevaplug - eSATA - SD/MMC gcc (Debian 4.6.2-9) 4.6.2 GNU ld (GNU Binutils for Debian) 2.22
I will try latest one today.
2) Can you NAND (driver) do subpage writes ?
How can I know it?
On Mon, Oct 29, 2012 at 12:54 AM, Marek Vasut marex@denx.de wrote:
Dear Dimax,
HI, After power short u-boot fails to mount UBIFS and board stuck. Below is a trace of u-boot
Marvell>> boot
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nand0":
0x000000500000-0x000020000000 : "mtd=2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
[...]
- Is this an upstream u-boot?
- Can you NAND (driver) do subpage writes ?
Best regards, Marek Vasut
Tried latest available version for SheevaPlug:
Marvell>> version U-Boot 2012.04.01 (Jun 01 2012 - 02:27:06) Marvell-Sheevaplug - eSATA - SD/MMC gcc (Debian 4.6.3-5) 4.6.3 GNU ld (GNU Binutils for Debian) 2.22
Same result. Do you know if u-boot has a functionality to recover ubifs partitions?
On Mon, Oct 29, 2012 at 7:25 AM, Dimax dimax.main@gmail.com wrote:
Hi.
- Is this an upstream u-boot?
Marvell>> version
U-Boot 2011.12 (Jan 08 2012 - 21:53:47) Marvell-Sheevaplug - eSATA - SD/MMC gcc (Debian 4.6.2-9) 4.6.2 GNU ld (GNU Binutils for Debian) 2.22
I will try latest one today.
- Can you NAND (driver) do subpage writes ?
How can I know it?
On Mon, Oct 29, 2012 at 12:54 AM, Marek Vasut marex@denx.de wrote:
Dear Dimax,
HI, After power short u-boot fails to mount UBIFS and board stuck. Below is
a
trace of u-boot
Marvell>> boot
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nand0":
0x000000500000-0x000020000000 : "mtd=2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
[...]
- Is this an upstream u-boot?
- Can you NAND (driver) do subpage writes ?
Best regards, Marek Vasut
Dear Dimax,
On 29.10.12 07:38, Dimax wrote:
Tried latest available version for SheevaPlug:
Marvell>> version U-Boot 2012.04.01 (Jun 01 2012 - 02:27:06) Marvell-Sheevaplug - eSATA - SD/MMC gcc (Debian 4.6.3-5) 4.6.3 GNU ld (GNU Binutils for Debian) 2.22
Same result. Do you know if u-boot has a functionality to recover ubifs partitions?
It should work. AFAIR there is a problem when the malloc arena is to small. I do currently not know if [1] made it into mainline. However, can you please check if expanding the CONFIG_SYS_MALLOC_LEN fixes your problem?
Best regards
Andreas Bießmann
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/124769
HI, So you say I have to rebuild u-boot with expanded CONFIG_SYS_MALLOC_LEN. So far I have used rebuild images from: http://people.debian.org/~tbm/u-boot/2011.12-3/sheevaplug/u-boot.kwb
I see following files in the parrent directory:
[image: [ ]] u-boot_2012.04.01-2.debian.tar.gz http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01-2.debian.tar.gz[image: [ ]] u-boot_2012.04.01-2_armel.deb http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01-2_armel.deb[image: [ ]] u-boot_2012.04.01.orig.tar.bz2 http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01.orig.tar.bz2
Is it all I need to rebuild? Are there any general instructions?
On Mon, Oct 29, 2012 at 8:48 AM, Andreas Bießmann < andreas.devel@googlemail.com> wrote:
Dear Dimax,
On 29.10.12 07:38, Dimax wrote:
Tried latest available version for SheevaPlug:
Marvell>> version U-Boot 2012.04.01 (Jun 01 2012 - 02:27:06) Marvell-Sheevaplug - eSATA - SD/MMC gcc (Debian 4.6.3-5) 4.6.3 GNU ld (GNU Binutils for Debian) 2.22
Same result. Do you know if u-boot has a functionality to recover ubifs partitions?
It should work. AFAIR there is a problem when the malloc arena is to small. I do currently not know if [1] made it into mainline. However, can you please check if expanding the CONFIG_SYS_MALLOC_LEN fixes your problem?
Best regards
Andreas Bießmann
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/124769
Dear Dimax,
On 29.10.2012 07:55, Dimax wrote:
HI, So you say I have to rebuild u-boot with expanded CONFIG_SYS_MALLOC_LEN. So far I have used rebuild images from: http://people.debian.org/~tbm/u-boot/2011.12-3/sheevaplug/u-boot.kwb http://people.debian.org/%7Etbm/u-boot/2011.12-3/sheevaplug/u-boot.kwb
I see following files in the parrent directory:
[ ] u-boot_2012.04.01-2.debian.tar.gz http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01-2.debian.tar.gz [ ] u-boot_2012.04.01-2_armel.deb http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01-2_armel.deb [ ] u-boot_2012.04.01.orig.tar.bz2 http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01.orig.tar.bz2
so if you are using a distributed version of u-boot, why don't file a bug there?
Is it all I need to rebuild?
Yes, after increasing the size of malloc arena (supposed my suspicion is correct).
Are there any general instructions?
Does <u-boot-src>/README section 'Building the Software' fit your needs? BEWARE! If you never built u-boot you should know you may brick your device, see the countless de-bricking guides for sheevaplug and prove you can de-brick it before you brick it ;)
Best regards
Andreas Bießmann
Hi, What if I compile a new u-boot but to try it I will load and flash new created image after original u-boot and will run it from withing original reboot manually just pointing a new image address? Can it work?
On Mon, Oct 29, 2012 at 10:38 AM, Andreas Bießmann < andreas.devel@googlemail.com> wrote:
Dear Dimax,
On 29.10.2012 07:55, Dimax wrote:
HI, So you say I have to rebuild u-boot with expanded CONFIG_SYS_MALLOC_LEN. So far I have used rebuild images from: http://people.debian.org/~tbm/u-boot/2011.12-3/sheevaplug/u-boot.kwb http://people.debian.org/%7Etbm/u-boot/2011.12-3/sheevaplug/u-boot.kwb
I see following files in the parrent directory:
[ ] u-boot_2012.04.01-2.debian.tar.gz <
http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01-2.debi...
[ ] u-boot_2012.04.01-2_armel.deb <
http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01-2_arme...
[ ] u-boot_2012.04.01.orig.tar.bz2 <
http://people.debian.org/%7Etbm/u-boot/2012.04.01-2/u-boot_2012.04.01.orig.t...
so if you are using a distributed version of u-boot, why don't file a bug there?
Is it all I need to rebuild?
Yes, after increasing the size of malloc arena (supposed my suspicion is correct).
Are there any general instructions?
Does <u-boot-src>/README section 'Building the Software' fit your needs? BEWARE! If you never built u-boot you should know you may brick your device, see the countless de-bricking guides for sheevaplug and prove you can de-brick it before you brick it ;)
Best regards
Andreas Bießmann
Dear Dimax,
please do not TOFU.
On 29.10.2012 09:50, Dimax wrote:
Hi, What if I compile a new u-boot but to try it I will load and flash new created image after original u-boot and will run it from withing original reboot manually just pointing a new image address? Can it work?
well, you mean to run a u-boot out of a running u-boot? U-Boot is not designed to do so. But some devices may allow you to just run a newer u-boot from a running one (at91;). You need to know that u-boot set up your SDRAM timings which destroys the content of the DRAM. So if your new u-boot is located there it can not be executed. I dunno if the kirkwood can do so, but I think they can not. You will need a) a JTAG b) another boot device, for example USB, MMC, whichever device the kirwood SoC can read from its ROM code (I do not know) to de-brick it.
Please ask some kirkwood specialist or google, there are a lot of sheevaplug hackers out there, one of them may be able to help you here.
Best regards
Andreas Bießmann
On Mon, Oct 29, 2012 at 11:11 AM, Andreas Bießmann < andreas.devel@googlemail.com> wrote:
Dear Dimax,
please do not TOFU.
Sorry don't know what you mean?
On 29.10.2012 09:50, Dimax wrote:
Hi, What if I compile a new u-boot but to try it I will load and flash new created image after original u-boot and will run it from withing original reboot manually just pointing a new image address? Can it work?
I'm not going to run new-u-boot from RAM. I will flash it. Can I ask original u-boot to JMP to a flash address and run a new-u-boot from where?
I once debricked SheevaPlug with USB stick. Have to recall how it was done. But as far as I remember I've found it in the internet so it should be still where. I understand that I first have to make sure I can debrick my board before I start playing with u-boot.
I also want to look back at my original problem of non-recovered UBIFS. Want to make sure my effort will not be useless. Let's say I've increased the memory allocation size. But are you sure u-boot implementation of ubifs really can recover partitions just like original Linux driver does? Is it implemented at all? If yes I have another doubt. In one forum I've read that u-boot treats UBIFS partition as read only (while it actually is rw for Linux). And thus u-boot does not even try to take any action that required writes. What you think?
well, you mean to run a u-boot out of a running u-boot? U-Boot is not designed to do so. But some devices may allow you to just run a newer u-boot from a running one (at91;). You need to know that u-boot set up your SDRAM timings which destroys the content of the DRAM. So if your new u-boot is located there it can not be executed. I dunno if the kirkwood can do so, but I think they can not. You will need a) a JTAG b) another boot device, for example USB, MMC, whichever device the kirwood SoC can read from its ROM code (I do not know) to de-brick it.
Please ask some kirkwood specialist or google, there are a lot of sheevaplug hackers out there, one of them may be able to help you here.
Best regards
Andreas Bießmann
Dear Dimax,
On 29.10.2012 10:27, Dimax wrote:
On Mon, Oct 29, 2012 at 11:11 AM, Andreas Bießmann <andreas.devel@googlemail.com mailto:andreas.devel@googlemail.com> wrote:
Dear Dimax, please do not TOFU.Sorry don't know what you mean?
you did it right ;) http://en.wikipedia.org/wiki/Top-posting#Top-posting
On 29.10.2012 09:50, Dimax wrote: > Hi, > What if I compile a new u-boot but to try it I will load and flash new > created image after original u-boot and will run it from withing > original reboot manually just pointing a new image address? Can it work?I'm not going to run new-u-boot from RAM. I will flash it. Can I ask original u-boot to JMP to a flash address and run a new-u-boot from where?
well, NAND is no XIP media, you need to move the stuff _always_ from NAND to RAM to use it.
I once debricked SheevaPlug with USB stick. Have to recall how it was done. But as far as I remember I've found it in the internet so it should be still where. I understand that I first have to make sure I can debrick my board before I start playing with u-boot.
Ok.
I also want to look back at my original problem of non-recovered UBIFS. Want to make sure my effort will not be useless. Let's say I've increased the memory allocation size. But are you sure u-boot implementation of ubifs really can recover partitions just like original Linux driver does? Is it implemented at all? If yes I have another doubt. In one forum I've read that u-boot treats UBIFS partition as read only (while it actually is rw for Linux). And thus u-boot does not even try to take any action that required writes. What you think?
In fact the u-boot port is copied from linux kernel. It may lack some newest fixes but in general it has the same features as the linux kernel has. The link I posted in my first mail did mention that the error message for ubifs_get_sb() in ubifs_mount() is useless cause we may have different root causes here. If your error message had displayed ENOMEM (or -12) you may have got the root cause by yourself. However, it may be another reason on your side, looking forward to see your solution.
Best regards
Andreas Bießmann
Dear Andreas Bießmann,
Dear Dimax,
On 29.10.2012 10:27, Dimax wrote:
On Mon, Oct 29, 2012 at 11:11 AM, Andreas Bießmann
<andreas.devel@googlemail.com mailto:andreas.devel@googlemail.com> wrote: Dear Dimax,
please do not TOFU.Sorry don't know what you mean?
you did it right ;) http://en.wikipedia.org/wiki/Top-posting#Top-posting
Or read here http://www.ietf.org/rfc/rfc1855.txt
[...]
Best regards, Marek Vasut
Dear Marek Vasut,
On 29.10.2012 11:19, Marek Vasut wrote:
Dear Andreas Bießmann,
Dear Dimax,
On 29.10.2012 10:27, Dimax wrote:
On Mon, Oct 29, 2012 at 11:11 AM, Andreas Bießmann
<andreas.devel@googlemail.com mailto:andreas.devel@googlemail.com> wrote: Dear Dimax,
please do not TOFU.Sorry don't know what you mean?
you did it right ;) http://en.wikipedia.org/wiki/Top-posting#Top-posting
Or read here http://www.ietf.org/rfc/rfc1855.txt
thank you for the RFC, but I can not find the TOFU abbreviation in it ;) However you are right, that should be the pointer for formal correctness.
Best regards
Andreas Bießmann
Hello Dimax,
On 10/29/2012 2:57 PM, Dimax wrote:
I also want to look back at my original problem of non-recovered UBIFS. Want to make sure my effort will not be useless. Let's say I've increased the memory allocation size. But are you sure u-boot implementation of ubifs really can recover partitions just like original Linux driver does? Is it implemented at all?
AFAIK, u-boot can't recover your partition. u-boot just mounts it read-only.
~Vikram
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Andreas Bießmann Sent: 29 October 2012 14:41 To: Dimax Cc: Marek Vasut; u-boot@lists.denx.de Subject: Re: [U-Boot] UBIFS fails on SheevaPlug
Dear Dimax,
please do not TOFU.
On 29.10.2012 09:50, Dimax wrote:
Hi, What if I compile a new u-boot but to try it I will load and flash
new
created image after original u-boot and will run it from withing original reboot manually just pointing a new image address? Can it
work?
well, you mean to run a u-boot out of a running u-boot? U-Boot is not designed to do so. But some devices may allow you to
It will not work.
just run a newer u-boot from a running one (at91;). You need to know that u-boot set up your SDRAM timings which destroys the content of the DRAM. So if your new u-boot is located there it can not be executed. I dunno if the kirkwood can do so, but I think they can not. You will need a) a JTAG b) another boot device, for example USB, MMC, whichever device the kirwood SoC can read from its ROM code (I do not know) to de-brick it.
Please ask some kirkwood specialist or google, there are a lot of sheevaplug hackers out there, one of them may be able to help you here.
You will need a JTAG key (amontec on any other) and OpenOCD s/w tool. Then you can build and test your code on Kirkwood w/o flashing on the device (i.e. running from RAM)
You may look for developer guidelines on the google or plugcomputer forum.
Regards... Prafulla . . .
I remember I have unbricked sheevaplug with USB key. But I'm still not sure if effort is not useless as I see no conclusion about u-boot ability to recover UBIFS partition (at least to try). Can anybody tell it for sure?
On Mon, Oct 29, 2012 at 2:15 PM, Prafulla Wadaskar prafulla@marvell.comwrote:
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Andreas Bießmann Sent: 29 October 2012 14:41 To: Dimax Cc: Marek Vasut; u-boot@lists.denx.de Subject: Re: [U-Boot] UBIFS fails on SheevaPlug
Dear Dimax,
please do not TOFU.
On 29.10.2012 09:50, Dimax wrote:
Hi, What if I compile a new u-boot but to try it I will load and flash
new
created image after original u-boot and will run it from withing original reboot manually just pointing a new image address? Can it
work?
well, you mean to run a u-boot out of a running u-boot? U-Boot is not designed to do so. But some devices may allow you to
It will not work.
just run a newer u-boot from a running one (at91;). You need to know that u-boot set up your SDRAM timings which destroys the content of the DRAM. So if your new u-boot is located there it can not be executed. I dunno if the kirkwood can do so, but I think they can not. You will need a) a JTAG b) another boot device, for example USB, MMC, whichever device the kirwood SoC can read from its ROM code (I do not know) to de-brick it.
Please ask some kirkwood specialist or google, there are a lot of sheevaplug hackers out there, one of them may be able to help you here.
You will need a JTAG key (amontec on any other) and OpenOCD s/w tool. Then you can build and test your code on Kirkwood w/o flashing on the device (i.e. running from RAM)
You may look for developer guidelines on the google or plugcomputer forum.
Regards... Prafulla . . .
On 10/29/2012 10:55 PM, Dimax wrote:
I remember I have unbricked sheevaplug with USB key. But I'm still not sure if effort is not useless as I see no conclusion about u-boot ability to recover UBIFS partition (at least to try). Can anybody tell it for sure?
This is what I've got from the code [1].
Code flow --------- common/cmd_ubifs.c: do_ubifs_mount calls ubifs_mount
fs/ubifs/super.c, In ubifs_mount() (line 1167) flags = MS_RDONLY; (line 1188) calls ubifs_get_sb (with flags as a param) ubifs_get_sb (line 1018) The flags get updated here. sb->s_flags = flags; (line 1057)
Calls ubifs_fill_super sb gets assigned, so are the flags. c->vfs_sb = sb; (line 962)
Calls mount_ubifs mount_ubifs(c); (line 983)
In mount_ubifs() (line 582)
struct super_block *sb = c->vfs_sb; int err, mounted_read_only = (sb->s_flags & MS_RDONLY);
sb taken from the assigned ptr @ line 962. Flags extracted from the assigned flags @ 1188. Just see where the variable 'mounter_read_only' gets referred and you'll get the answer. U-boot will _not_ recover your UBIFS partition like the Linux kernel. CMIIW.
[1] http://git.denx.de/?p=u-boot.git;a=tree;h=5bb3505fa867ded03cbee83f7722ab5182...
Hope this helps, Vikram
U-boot will _not_ recover your UBIFS partition like the Linux kernel.
CMIIW. In other words it is not possible to use UBIFS on embedded Linux boards with u-boot unless you can provide unterminated power supply.
I'm going to another solution - Split flash in two UBIFS partitions. Make the first one read only and put kernel and all critical data where. And have logs and user data on second RW partition. This way kernel should always start and if required recover second RW partition.
Do you have any suggestions on how to do it or where to start? More likely I have to look at mtd utilities?
On Mon, Oct 29, 2012 at 8:53 PM, Vikram Narayanan vikram186@gmail.comwrote:
On 10/29/2012 10:55 PM, Dimax wrote:
I remember I have unbricked sheevaplug with USB key. But I'm still not sure if effort is not useless as I see no conclusion about u-boot ability to recover UBIFS partition (at least to try). Can anybody tell it for sure?
This is what I've got from the code [1].
Code flow
common/cmd_ubifs.c: do_ubifs_mount calls ubifs_mount
fs/ubifs/super.c, In ubifs_mount() (line 1167) flags = MS_RDONLY; (line 1188) calls ubifs_get_sb (with flags as a param) ubifs_get_sb (line 1018) The flags get updated here. sb->s_flags = flags; (line 1057)
Calls ubifs_fill_super sb gets assigned, so are the flags. c->vfs_sb = sb; (line 962)
Calls mount_ubifs mount_ubifs(c); (line 983)
In mount_ubifs() (line 582)
struct super_block *sb = c->vfs_sb; int err, mounted_read_only = (sb->s_flags & MS_RDONLY);sb taken from the assigned ptr @ line 962. Flags extracted from the assigned flags @ 1188. Just see where the variable 'mounter_read_only' gets referred and you'll get the answer. U-boot will _not_ recover your UBIFS partition like the Linux kernel. CMIIW.
[1] http://git.denx.de/?p=u-boot.git;a=tree;h=5bb3505fa867ded03cbee83f7722ab5182...
Hope this helps, Vikram
Dear Dimax,
On 29.10.2012 20:05, Dimax wrote:
U-boot will _not_ recover your UBIFS partition like the Linux kernel.
CMIIW. In other words it is not possible to use UBIFS on embedded Linux boards with u-boot unless you can provide unterminated power supply.
NAK
I invested some time to reproduce this, however see following scenario:
---8<--- DockStar> ubi part root; ubifsmount root Creating 1 MTD partitions on "nand0": 0x000000100000-0x000010000000 : "mtd=1" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=1" UBI: MTD device size: 255 MiB UBI: number of good PEBs: 2040 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: 20 UBI: total number of reserved PEBs: 2020 UBI: number of PEBs reserved for bad PEB handling: 20 UBI: max/mean erase counter: 4/2 UBIFS: recovery needed UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume 'ubi:root' errno=-12!
ubifsmount - mount UBIFS volume
Usage: ubifsmount <volume-name> - mount 'volume-name' volume DockStar> ver
U-Boot 2012.10 (Oct 30 2012 - 00:46:13) Seagate FreeAgent DockStar arm-v5te-linux-gnueabi-gcc (OSELAS.Toolchain-2011.11.0) 4.6.2 GNU ld (GNU Binutils) 2.21.1 DockStar> --->8---
---8<--- DockStar> ubi part root; ubifsmount root Creating 1 MTD partitions on "nand0": 0x000000100000-0x000010000000 : "mtd=1" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=1" UBI: MTD device size: 255 MiB UBI: number of good PEBs: 2040 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: 20 UBI: total number of reserved PEBs: 2020 UBI: number of PEBs reserved for bad PEB handling: 20 UBI: max/mean erase counter: 4/2 UBIFS: recovery needed UBIFS: recovery deferred UBIFS: mounted UBI device 0, volume 0, name "root" UBIFS: mounted read-only UBIFS: file system size: 255854592 bytes (249858 KiB, 244 MiB, 1983 LEBs) UBIFS: journal size: 12773376 bytes (12474 KiB, 12 MiB, 99 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 5182151 bytes (5060 KiB) DockStar> ver
U-Boot 2012.10-00001-g65cc68e (Oct 30 2012 - 00:50:51) Seagate FreeAgent DockStar arm-v5te-linux-gnueabi-gcc (OSELAS.Toolchain-2011.11.0) 4.6.2 GNU ld (GNU Binutils) 2.21.1 DockStar> --->8---
---8<--- andreas@andreas-pc % git describe v2012.10-1-g65cc68e andreas@andreas-pc % git show | commit 65cc68eb06df0c957a17a611bc3f3756e91108b2 (HEAD, test-malloc) | Author: Andreas Bießmann andreas.devel@googlemail.com | Date: Mon Oct 29 21:36:53 2012 +0100 | | mv-common.h: increase malloc arena to 4MiB | | Signed-off-by: Andreas Bießmann andreas.devel@googlemail.com | | diff --git a/include/configs/mv-common.h b/include/configs/mv-common.h | index 7086d1d..405a842 100644 | --- a/include/configs/mv-common.h | +++ b/include/configs/mv-common.h | @@ -92,7 +92,7 @@ | /* | * Size of malloc() pool | */ | -#define CONFIG_SYS_MALLOC_LEN (1024 * 1024) /* 1MiB for malloc() */ | +#define CONFIG_SYS_MALLOC_LEN (1024 * 1024 * 4) /* 4MiB for malloc() */ | | /* | * Other required minimal configurations --->8---
Best regards
Andreas Bießmann
Dear Vikram Narayanan,
first of all you are right. u-boot ubifs implementation will never recover the ubifs on media, cause it is mounted read only.
On 29.10.2012 19:53, Vikram Narayanan wrote:
On 10/29/2012 10:55 PM, Dimax wrote:
I remember I have unbricked sheevaplug with USB key. But I'm still not sure if effort is not useless as I see no conclusion about u-boot ability to recover UBIFS partition (at least to try). Can anybody tell it for sure?
This is what I've got from the code [1].
Code flow
common/cmd_ubifs.c: do_ubifs_mount calls ubifs_mount
fs/ubifs/super.c, In ubifs_mount() (line 1167) flags = MS_RDONLY; (line 1188) calls ubifs_get_sb (with flags as a param) ubifs_get_sb (line 1018) The flags get updated here. sb->s_flags = flags; (line 1057)
calls sget() (line 1043) which in turn calls kzalloc() (line 67) which may return -ENOMEM
But u-boot will manage to get the data out of the unordered ubifs (if no error like this ENOMEM occur). That is the same process as in kernel if it is mounted read-only (recovery deferred). So if the kernel can manage to mount the unordered ubifs u-boot should do so. If it can't (but the kernel can) there is an error that should be fixed.
Best regards
Andreas Bießmann
Hello Andreas,
On 10/30/2012 4:32 AM, Andreas Bießmann wrote:
Dear Vikram Narayanan,
first of all you are right. u-boot ubifs implementation will never recover the ubifs on media, cause it is mounted read only.
<snip>
calls sget() (line 1043) which in turn calls kzalloc() (line 67) which may return -ENOMEM
I agree. But in Dimax's case this isn't. Right?
But u-boot will manage to get the data out of the unordered ubifs (if no error like this ENOMEM occur). That is the same process as in kernel if it is mounted read-only (recovery deferred).
I can't comment on this, unless I know the specifics.
So if the kernel can manage to mount the unordered ubifs u-boot should do so. If it can't (but the kernel can) there is an error that should be fixed.
But in the kernel, the read-only isn't hardcoded. So, the kernel code can try to recover and even update the corrupted data back to the media and mount it. (It's my guess. The kernel may/mayn't do this way).
But if the same fails to happen in u-boot code, I'd say the feature is missing and it needs to be pulled in from the kernel code.
Regards, Vikram
Dear Vikram Narayanan,
On 31.10.2012 17:27, Vikram Narayanan wrote:
Hello Andreas,
On 10/30/2012 4:32 AM, Andreas Bießmann wrote:
Dear Vikram Narayanan,
first of all you are right. u-boot ubifs implementation will never recover the ubifs on media, cause it is mounted read only.
<snip>
calls sget() (line 1043) which in turn calls kzalloc() (line 67) which may return -ENOMEM
I agree. But in Dimax's case this isn't. Right?
I dunno cause he has an old version which do not print the error code (patch f75325e1927398f7e18e15f186b1fc52174cc19f is missing).
But u-boot will manage to get the data out of the unordered ubifs (if no error like this ENOMEM occur). That is the same process as in kernel if it is mounted read-only (recovery deferred).
I can't comment on this, unless I know the specifics.
Please read mount_ubifs() in fs/ubifs/super.c:582
Even if it is mounted read only and recovery is needed it will ubifs_lpt_init(), ubifs_replay_journal(), ubifs_mount_orphans(), ... If recovery is needed it will ubifs_recover_size() and if it is mounted read only it will print at last 'recovery deferred' (in the other case it would be still repaired here cause the steps before do it). So at least a read only fs which needs recovery can be successfully mounted (if no other error occurs; the most likely error is a ENOMEM cause the ubifs does a lot of k(z)alloc).
So if the kernel can manage to mount the unordered ubifs u-boot should do so. If it can't (but the kernel can) there is an error that should be fixed.
But in the kernel, the read-only isn't hardcoded. So, the kernel code can try to recover and even update the corrupted data back to the media and mount it. (It's my guess. The kernel may/mayn't do this way).
Well bootargs can have 'ro' so the root partition will be mounted read only, wouldn't it? Wouldn't this 'ro' root partition not mounted by the kernel then?
But if the same fails to happen in u-boot code, I'd say the feature is missing and it needs to be pulled in from the kernel code.
Regards, Vikram
Best regards
Andreas Bießmann
Hello Andreas,
On 10/31/2012 10:20 PM, Andreas Bießmann wrote:
Dear Vikram Narayanan,
On 31.10.2012 17:27, Vikram Narayanan wrote:
Hello Andreas,
On 10/30/2012 4:32 AM, Andreas Bießmann wrote:
Dear Vikram Narayanan,
first of all you are right. u-boot ubifs implementation will never recover the ubifs on media, cause it is mounted read only.
<snip>
calls sget() (line 1043) which in turn calls kzalloc() (line 67) which may return -ENOMEM
I agree. But in Dimax's case this isn't. Right?
I dunno cause he has an old version which do not print the error code (patch f75325e1927398f7e18e15f186b1fc52174cc19f is missing).
But u-boot will manage to get the data out of the unordered ubifs (if no error like this ENOMEM occur). That is the same process as in kernel if it is mounted read-only (recovery deferred).
I can't comment on this, unless I know the specifics.
Please read mount_ubifs() in fs/ubifs/super.c:582
Even if it is mounted read only and recovery is needed it will ubifs_lpt_init(), ubifs_replay_journal(), ubifs_mount_orphans(), ... If recovery is needed it will ubifs_recover_size() and if it is mounted read only it will print at last 'recovery deferred' (in the other case it would be still repaired here cause the steps before do it). So at least a read only fs which needs recovery can be successfully mounted (if no other error occurs; the most likely error is a ENOMEM cause the ubifs does a lot of k(z)alloc).
Thanks. I'll look at this.
So if the kernel can manage to mount the unordered ubifs u-boot should do so. If it can't (but the kernel can) there is an error that should be fixed.
But in the kernel, the read-only isn't hardcoded. So, the kernel code can try to recover and even update the corrupted data back to the media and mount it. (It's my guess. The kernel may/mayn't do this way).
Well bootargs can have 'ro' so the root partition will be mounted read only, wouldn't it? Wouldn't this 'ro' root partition not mounted by the kernel then?
Got your point here. Then no feature could be claimed as 'missing' in the u-boot's ubifs compared to the kernel's, except for the well known fact that u-boot's ubi layer is old code.
Regards, Vikram
HI guys. I'm sorry I had other jobs to do and did not have time to dig it. I have tried SheevaPlug port from http://people.debian.org/~tbm/u-boot/2012.04.01-2/ and it fails and gave me no error code. Not sure it is because of old version or error just did not happen.
I still keep a box with broken ubifs to try new u-boot on it. Is where any chance someone will help me to build a latest u-boot port for SheevaPlug? Actually someone is doing it. I took latest version here: http://people.debian.org/~tbm/u-boot/2012.04.01-2/
Also can you tell me if this version has error printing patch or not?
On Wed, Oct 31, 2012 at 6:55 PM, Vikram Narayanan vikram186@gmail.comwrote:
Hello Andreas,
On 10/31/2012 10:20 PM, Andreas Bießmann wrote:
Dear Vikram Narayanan,
On 31.10.2012 17:27, Vikram Narayanan wrote:
Hello Andreas,
On 10/30/2012 4:32 AM, Andreas Bießmann wrote:
Dear Vikram Narayanan,
first of all you are right. u-boot ubifs implementation will never recover the ubifs on media, cause it is mounted read only.
<snip>
calls sget() (line 1043)
which in turn calls kzalloc() (line 67) which may return -ENOMEM
I agree. But in Dimax's case this isn't. Right?
I dunno cause he has an old version which do not print the error code (patch f75325e1927398f7e18e15f186b1fc**52174cc19f is missing).
But u-boot will manage to get the data out of the unordered ubifs (if no
error like this ENOMEM occur). That is the same process as in kernel if it is mounted read-only (recovery deferred).
I can't comment on this, unless I know the specifics.
Please read mount_ubifs() in fs/ubifs/super.c:582
Even if it is mounted read only and recovery is needed it will ubifs_lpt_init(), ubifs_replay_journal(), ubifs_mount_orphans(), ... If recovery is needed it will ubifs_recover_size() and if it is mounted read only it will print at last 'recovery deferred' (in the other case it would be still repaired here cause the steps before do it). So at least a read only fs which needs recovery can be successfully mounted (if no other error occurs; the most likely error is a ENOMEM cause the ubifs does a lot of k(z)alloc).
Thanks. I'll look at this.
So if the kernel can manage to mount the unordered ubifs u-boot should
do so. If it can't (but the kernel can) there is an error that should be fixed.
But in the kernel, the read-only isn't hardcoded. So, the kernel code can try to recover and even update the corrupted data back to the media and mount it. (It's my guess. The kernel may/mayn't do this way).
Well bootargs can have 'ro' so the root partition will be mounted read only, wouldn't it? Wouldn't this 'ro' root partition not mounted by the kernel then?
Got your point here. Then no feature could be claimed as 'missing' in the u-boot's ubifs compared to the kernel's, except for the well known fact that u-boot's ubi layer is old code.
Regards, Vikram
Dear Dimax,
On 31.10.12 18:23, Dimax wrote:
HI guys. I'm sorry I had other jobs to do and did not have time to dig it. I have tried SheevaPlug port from http://people.debian.org/~tbm/u-boot/2012.04.01-2/ and it fails and gave me no error code. Not sure it is because of old version or error just did not happen.
I still keep a box with broken ubifs to try new u-boot on it. Is where any chance someone will help me to build a latest u-boot port for SheevaPlug?
well as said before, if the <u-boot-src>/README (section 'Building the Software') does not help you I could answer concrete questions.
Actually someone is doing it. I took latest version here: http://people.debian.org/~tbm/u-boot/2012.04.01-2/
So maybe can you ping Martin Michlmayr to release a new version?
Also can you tell me if this version has error printing patch or not?
Presumably not, it is in v2012.10.
Best regards
Andreas Bießmann
Hello all, Is there any ways to activate more debugging information during SPL and u-boot process? I´m trying to boot u-boot for the Hackberry using Henrik source code but im only getting the following via serial console: U-Boot SPL 2012.10-04714-gc9a957f-dirty (Oct 31 2012 - 20:30:47)Board: sunxi
Regards,Paulo
Well so far no luck, Actually I'm not sure how to start. But I will try to go on "with a little help from my friends".
I) The first question that raised is a compiler. I see two options: 1. Use the cross compiler - this is what more likely most of the people are doing. 2. I wonder if I can use native compiler? I actually have a number of running SheevaPlugs with gcc installed on them. Do you think it will work?
II) After extracting files I have following tree:
u-boot_2012.04.01-2_armel.deb debian: README.Debian control env-configs/ manpages/ rules* targets changelog copyright lintian.overrides patches/ source/ watch u-boot-2012.04.01
According to README all I have to do is to run make NAME_config The sheevaplug is listed in boards.cfg so there should be no problem to make sheevaplug_config.
In this case I do not get what are the other two directory and file: u-boot_2012.04.01-2_armel.deb debian/
To my understanding debian/ is some port but I do not see any makefile where. So not sure hot to use it?
On Wed, Oct 31, 2012 at 7:56 PM, Andreas Bießmann < andreas.devel@googlemail.com> wrote:
Dear Dimax,
On 31.10.12 18:23, Dimax wrote:
HI guys. I'm sorry I had other jobs to do and did not have time to dig it. I have tried SheevaPlug port from http://people.debian.org/~tbm/u-boot/2012.04.01-2/ and it fails and gave me no error code. Not sure it is because of old version or error just did not happen.
I still keep a box with broken ubifs to try new u-boot on it. Is where any chance someone will help me to build a latest u-boot port for SheevaPlug?
well as said before, if the <u-boot-src>/README (section 'Building the Software') does not help you I could answer concrete questions.
Actually someone is doing it. I took latest version here: http://people.debian.org/~tbm/u-boot/2012.04.01-2/
So maybe can you ping Martin Michlmayr to release a new version?
Also can you tell me if this version has error printing patch or not?
Presumably not, it is in v2012.10.
Best regards
Andreas Bießmann
Dear Dimax,
On 06.11.2012 08:51, Dimax wrote:
Well so far no luck, Actually I'm not sure how to start. But I will try to go on "with a little help from my friends".
I) The first question that raised is a compiler. I see two options:
- Use the cross compiler - this is what more likely most of the people
are doing. 2. I wonder if I can use native compiler? I actually have a number of running SheevaPlugs with gcc installed on them. Do you think it will work?
Both should work, if you need an cross compiler have a look at ELDK [1]
II) After extracting files I have following tree:
u-boot_2012.04.01-2_armel.deb
Wrong file! Please use the source from denx.de, either git from git://git.denx.de/u-boot.git or a released version from ftp://ftp.denx.de/pub/u-boot
<snip debian package content>
According to README all I have to do is to run make NAME_config The sheevaplug is listed in boards.cfg so there should be no problem to make sheevaplug_config.
Thats true for native build (never tested, may not work)
You will need some compiler flags: CROSS_COMPILE (prefix for 'gcc' when cross compiling) PATH (should contain your toolchain)
I would build it that way:
---8<--- abiessmann@azuregos % PATH=$ARMv5_PATH:$PATH CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug sheevaplug_config Configuring for sheevaplug board... abiessmann@azuregos % PATH=$ARMv5_PATH:$PATH CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug all
... abiessmann@azuregos % ls -l /tmp/build_sheevaplug/u-boot* -rwxr-xr-x 1 abiessmann abiessmann 1893165 Nov 6 10:09 /tmp/build_sheevaplug/u-boot* -rw-r--r-- 1 abiessmann abiessmann 378492 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.bin -rw-r--r-- 1 abiessmann abiessmann 1043 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.lds -rw-r--r-- 1 abiessmann abiessmann 127109 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.map -rw-r--r-- 1 abiessmann abiessmann 1088268 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.srec abiessmann@azuregos % PATH=$ARMv5_PATH:$PATH CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug /tmp/build_sheevaplug/u-boot.kwb ... Preparing kirkwood boot image to boot from nand Nand ECC mode = default Nand page size = 0x800 Image Type: Kirkwood Boot from NAND Flash Image Data Size: 378492 Bytes = 369.62 kB = 0.36 MB Load Address: 00600000 Entry Point: 00600000 --->8---
In this case I do not get what are the other two directory and file: u-boot_2012.04.01-2_armel.deb debian/
To my understanding debian/ is some port but I do not see any makefile where. So not sure hot to use it?
Well, that is a pre-compiled debian package for armel. The debian directory contains some information for the debian package system.
Best regards
Andreas Bießmann
HI, I have managed to build latest image and apply MALLOC patch. After that system is fully working:
UBIFS: recovery needed UBIFS: recovery deferred UBIFS: mounted UBI device 0, volume 0, name "rootfs" UBIFS: mounted read-only UBIFS: file system size: 515708928 bytes (503622 KiB, 491 MiB, 3997 LEBs) UBIFS: journal size: 25804800 bytes (25200 KiB, 24 MiB, 200 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 5182151 bytes (5060 KiB) Loading file '/boot/uInitrd' to addr 0x01100000 with size 5472032 (0x00537f20)... Done Loading file '/boot/uImage' to addr 0x00800000 with size 1435120 (0x0015e5f0)... Done ## Booting kernel from Legacy Image at 00800000 ... ....
If someone need u-boot image I can provide it
On Tue, Nov 6, 2012 at 11:12 AM, Andreas Bießmann andreas.devel@googlemail.com wrote:
Dear Dimax,
On 06.11.2012 08:51, Dimax wrote:
Well so far no luck, Actually I'm not sure how to start. But I will try to go on "with a little help from my friends".
I) The first question that raised is a compiler. I see two options:
- Use the cross compiler - this is what more likely most of the people
are doing. 2. I wonder if I can use native compiler? I actually have a number of running SheevaPlugs with gcc installed on them. Do you think it will work?
Both should work, if you need an cross compiler have a look at ELDK [1]
II) After extracting files I have following tree:
u-boot_2012.04.01-2_armel.deb
Wrong file! Please use the source from denx.de, either git from git://git.denx.de/u-boot.git or a released version from ftp://ftp.denx.de/pub/u-boot
<snip debian package content>
According to README all I have to do is to run make NAME_config The sheevaplug is listed in boards.cfg so there should be no problem to make sheevaplug_config.
Thats true for native build (never tested, may not work)
You will need some compiler flags: CROSS_COMPILE (prefix for 'gcc' when cross compiling) PATH (should contain your toolchain)
I would build it that way:
---8<--- abiessmann@azuregos % PATH=$ARMv5_PATH:$PATH CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug sheevaplug_config Configuring for sheevaplug board... abiessmann@azuregos % PATH=$ARMv5_PATH:$PATH CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug all
... abiessmann@azuregos % ls -l /tmp/build_sheevaplug/u-boot* -rwxr-xr-x 1 abiessmann abiessmann 1893165 Nov 6 10:09 /tmp/build_sheevaplug/u-boot* -rw-r--r-- 1 abiessmann abiessmann 378492 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.bin -rw-r--r-- 1 abiessmann abiessmann 1043 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.lds -rw-r--r-- 1 abiessmann abiessmann 127109 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.map -rw-r--r-- 1 abiessmann abiessmann 1088268 Nov 6 10:09 /tmp/build_sheevaplug/u-boot.srec abiessmann@azuregos % PATH=$ARMv5_PATH:$PATH CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug /tmp/build_sheevaplug/u-boot.kwb ... Preparing kirkwood boot image to boot from nand Nand ECC mode = default Nand page size = 0x800 Image Type: Kirkwood Boot from NAND Flash Image Data Size: 378492 Bytes = 369.62 kB = 0.36 MB Load Address: 00600000 Entry Point: 00600000 --->8---
In this case I do not get what are the other two directory and file: u-boot_2012.04.01-2_armel.deb debian/
To my understanding debian/ is some port but I do not see any makefile where. So not sure hot to use it?
Well, that is a pre-compiled debian package for armel. The debian directory contains some information for the debian package system.
Best regards
Andreas Bießmann
Dear Dimax,
On 12.11.2012 06:33, Dimax wrote:
HI, I have managed to build latest image and apply MALLOC patch.
great, congrats.
After that system is fully working:
UBIFS: recovery needed UBIFS: recovery deferred UBIFS: mounted UBI device 0, volume 0, name "rootfs" UBIFS: mounted read-only UBIFS: file system size: 515708928 bytes (503622 KiB, 491 MiB, 3997 LEBs) UBIFS: journal size: 25804800 bytes (25200 KiB, 24 MiB, 200 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 5182151 bytes (5060 KiB) Loading file '/boot/uInitrd' to addr 0x01100000 with size 5472032 (0x00537f20)... Done Loading file '/boot/uImage' to addr 0x00800000 with size 1435120 (0x0015e5f0)... Done ## Booting kernel from Legacy Image at 00800000 ... ....
If someone need u-boot image I can provide it
Can you please add your credits to the patch that fixes your problem? Please read http://www.denx.de/wiki/view/U-Boot/Patches#Review_Process_Git_Tags and add a proper Tested-by tag to the '[PATCH] mv-common.h: increase malloc arena to 4MiB' mail.
Best regards
Andreas Bießmann
I read the page but not sure how exactly to do it. I'm not familiar with git. I have gust used source from ftp.
On Mon, Nov 12, 2012 at 10:33 AM, Andreas Bießmann andreas.devel@googlemail.com wrote:
Dear Dimax,
On 12.11.2012 06:33, Dimax wrote:
HI, I have managed to build latest image and apply MALLOC patch.
great, congrats.
After that system is fully working:
UBIFS: recovery needed UBIFS: recovery deferred UBIFS: mounted UBI device 0, volume 0, name "rootfs" UBIFS: mounted read-only UBIFS: file system size: 515708928 bytes (503622 KiB, 491 MiB, 3997 LEBs) UBIFS: journal size: 25804800 bytes (25200 KiB, 24 MiB, 200 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 5182151 bytes (5060 KiB) Loading file '/boot/uInitrd' to addr 0x01100000 with size 5472032 (0x00537f20)... Done Loading file '/boot/uImage' to addr 0x00800000 with size 1435120 (0x0015e5f0)... Done ## Booting kernel from Legacy Image at 00800000 ... ....
If someone need u-boot image I can provide it
Can you please add your credits to the patch that fixes your problem? Please read http://www.denx.de/wiki/view/U-Boot/Patches#Review_Process_Git_Tags and add a proper Tested-by tag to the '[PATCH] mv-common.h: increase malloc arena to 4MiB' mail.
Best regards
Andreas Bießmann
On 11/12/2012 10:25 PM, Dimax wrote:
I read the page but not sure how exactly to do it. I'm not familiar with git. I have gust used source from ftp.
You don't need a git for it. Mail access should be fine.
Find the below mail in your inbox and reply to that, http://www.mail-archive.com/u-boot@lists.denx.de/msg97893.html with the tag
Tested-by: Dimax dimax.main@gmail.com
<snip>
Can you please add your credits to the patch that fixes your problem? Please read http://www.denx.de/wiki/view/U-Boot/Patches#Review_Process_Git_Tags and add a proper Tested-by tag to the '[PATCH] mv-common.h: increase malloc arena to 4MiB' mail.
Regards, Vikram
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Dimax Sent: 28 October 2012 20:18 To: u-boot@lists.denx.de Subject: [U-Boot] UBIFS fails on SheevaPlug
HI, After power short u-boot fails to mount UBIFS and board stuck. Below is a trace of u-boot
Marvell>> boot
UBI: mtd1 is detached from ubi0
Creating 1 MTD partitions on "nand0":
0x000000500000-0x000020000000 : "mtd=2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=2"
UBI: MTD device size: 507 MiB
UBI: number of good PEBs: 4055
UBI: number of bad PEBs: 1
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: 4055
UBI: number of PEBs reserved for bad PEB handling: 40
UBI: max/mean erase counter: 1/0
UBIFS: recovery needed
Error reading superblock on volume 'ubi:rootfs'!
UBIFS not mounted, use ubifs mount to mount volume first!
UBIFS not mounted, use ubifs mount to mount volume first!
Wrong Image Format for bootm command
ERROR: can't get kernel image! Marvell>>
To recover from this situation I boot from USB stick and simply mounts the same UBIFS partition:
root@debian:~# mount -t ubifs ubi0:rootfs /mnt [ 306.205029] UBIFS: recovery needed [ 309.341987] UBIFS: recovery completed [ 309.345705] UBIFS: mounted UBI device 0, volume 0, name "rootfs" [ 309.351738] UBIFS: file system size: 515192832 bytes (503118 KiB, 491 MiB, 3993 LEBs) [ 309.359789] UBIFS: journal size: 25804800 bytes (25200 KiB, 24 MiB, 200 LEBs) [ 309.367495] UBIFS: media format: w4/r0 (latest is w4/r0) [ 309.373352] UBIFS: default compressor: lzo [ 309.377479] UBIFS: reserved for root: 4952683 bytes (4836 KiB)
As you can see mount manage to recover partition. Is where any way to make u-boot to recover UBIFS partition as well? What else can I do to make my system stable and survive power shorts?
Dear Dimax
Thanks for reporting this issue, I am not UBIFS expert, but I will check this problem at my end.
Regards... Prafulla . . .
participants (6)
-
Andreas Bießmann -
Dimax -
Marek Vasut -
Paulo Louro -
Prafulla Wadaskar -
Vikram Narayanan