From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vikram Narayanan <vikram186@gmail.com>
Date: Wed, 19 Dec 2012 23:02:09 +0530
Subject: [U-Boot] Bricked when trying to attach UBI
In-Reply-To: <50D1A4C2.6020207@comelit.it>
References: <50D1A4C2.6020207@comelit.it>
Message-ID: <50D1FA19.7020602@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 12/19/2012 4:58 PM, Luca Ceresoli wrote:
> Hi all,
>
<snip>
> On "bricked" devices the output of the "ubi part nand0,3" command is:
>
> Creating 1 MTD partitions on "nand0":
> 0x000000100000-0x000010000000 : "mtd=3"
> 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 error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

Just curious, What does the above command say when you try to attach an 
empty partition. Does it result in the same error?

> Now the device is totally blocked, and power cycling does not change
> the result.
>
> The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
> board support patches) via TFTP and boot it with bootm, it correctly
> attaches UBI (fixing any problem it may have) and boots correctly.
> After that the board is unbricked: U-Boot can boot again normally from
> NAND.
>
> Without the ambition of understanding all UBI internals, I tried to
> visually inspect the UBI code around the line where the error is
> produced and compare it to the corresponding Linux sources. They looked
> extremely similar, so I haven't and obvious hint of why U-Boot and
> Linux produce different results.
>
> I also tried with an updated U-Boot master, but the error is still
> there.
>
> Obviously I have changed nothing in the UBI and MTD code, both in
> U-Boot and in Linux.
>
> Can you suggest a proper way to track the root of the problem, or to
> bypass it?

I think its the right time to sync the UBI code with the current kernel 
tree. But it seems like a huge work. Any suggestions?

Regards,
Vikram