[U-Boot] UBIFS fails on SheevaPlug

[U-Boot] UBIFS fails on SheevaPlug

[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

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 at 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.

[U-Boot] UBIFS fails on SheevaPlug

[Marek Vasut]

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

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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
> [...]
>
> 1) Is this an upstream u-boot?
> 2) Can you NAND (driver) do subpage writes ?
>
> Best regards,
> Marek Vasut
>

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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.
>
> 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
>> [...]
>>
>> 1) Is this an upstream u-boot?
>> 2) Can you NAND (driver) do subpage writes ?
>>
>> Best regards,
>> Marek Vasut
>>
>
>

[U-Boot] UBIFS fails on SheevaPlug

[Andreas Bießmann]

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

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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
>

[U-Boot] UBIFS fails on SheevaPlug

[Andreas Bießmann]

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

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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.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
>

[U-Boot] UBIFS fails on SheevaPlug

[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

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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
>

[U-Boot] UBIFS fails on SheevaPlug

[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 at 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

[U-Boot] UBIFS fails on SheevaPlug

[Marek Vasut]

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 at 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

[U-Boot] UBIFS fails on SheevaPlug

[Andreas Bießmann]

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 at 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

[U-Boot] UBIFS fails on SheevaPlug

[Vikram Narayanan]

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

[U-Boot] UBIFS fails on SheevaPlug

[Prafulla Wadaskar]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> bounces at lists.denx.de] On Behalf Of Andreas Bie?mann
> Sent: 29 October 2012 14:41
> To: Dimax
> Cc: Marek Vasut; u-boot at 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 . . .

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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.com>wrote:

>
>
> > -----Original Message-----
> > From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> > bounces at lists.denx.de] On Behalf Of Andreas Bie?mann
> > Sent: 29 October 2012 14:41
> > To: Dimax
> > Cc: Marek Vasut; u-boot at 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 . . .
>

[U-Boot] UBIFS fails on SheevaPlug

[Vikram Narayanan]

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=5bb3505fa867ded03cbee83f7722ab5182930637;hb=5bb3505fa867ded03cbee83f7722ab5182930637

Hope this helps,
Vikram

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

> 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.com>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 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=5bb3505fa867ded03cbee83f7722ab5182930637;hb=5bb3505fa867ded03cbee83f7722ab5182930637
>
> Hope this helps,
> Vikram
>

[U-Boot] UBIFS fails on SheevaPlug

[Andreas Bießmann]

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 at andreas-pc % git describe
v2012.10-1-g65cc68e
andreas at 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

[U-Boot] UBIFS fails on SheevaPlug

[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

[U-Boot] UBIFS fails on SheevaPlug

[Vikram Narayanan]

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

[U-Boot] UBIFS fails on SheevaPlug

[Andreas Bießmann]

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

[U-Boot] UBIFS fails on SheevaPlug

[Vikram Narayanan]

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

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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.com>wrote:

> 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
>

[U-Boot] UBIFS fails on SheevaPlug

[Andreas Bießmann]

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

[U-Boot] How to enable debug information in u-boot

[Paulo Louro]

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 		 	   		  

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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
>

[U-Boot] UBIFS fails on SheevaPlug

[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:
> 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?

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 at azuregos % PATH=$ARMv5_PATH:$PATH
CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug
sheevaplug_config
Configuring for sheevaplug board...
abiessmann at azuregos % PATH=$ARMv5_PATH:$PATH
CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug all

...
abiessmann at 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

[1] http://www.denx.de/wiki/DULG/ELDK

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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:
>> 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?
>
> 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 at azuregos % PATH=$ARMv5_PATH:$PATH
> CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug
> sheevaplug_config
> Configuring for sheevaplug board...
> abiessmann at azuregos % PATH=$ARMv5_PATH:$PATH
> CROSS_COMPILE=arm-v5te-linux-gnueabi- make O=/tmp/build_sheevaplug all
>
> ...
> abiessmann at 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 at 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
>
> [1] http://www.denx.de/wiki/DULG/ELDK

[U-Boot] UBIFS fails on SheevaPlug

[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

[U-Boot] UBIFS fails on SheevaPlug

[Dimax]

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
>

[U-Boot] UBIFS fails on SheevaPlug

[Vikram Narayanan]

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 at 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

[U-Boot] UBIFS fails on SheevaPlug

[Prafulla Wadaskar]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> bounces at lists.denx.de] On Behalf Of Dimax
> Sent: 28 October 2012 20:18
> To: u-boot at 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 at 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 . . .