[U-Boot] Bricked when trying to attach UBI

[Stefan Roese]

On 12/19/2012 06:32 PM, Vikram Narayanan wrote:
>> 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?

Yes, syncing with the latest UBI/UBIFS code would be the best solution.
Even though a try with an increased malloc area as suggested by Andreas
might be a chance.

And yes, this re-sync with the latest-and-greatest Linux code version is
of course a bigger task. It has been suggest as part of booting from an
UBI volume task to the celinux forum:

http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html

But nothing has happened till now. Any volunteers? But please keep in
mind that intensive testing is required before the current (stable?)
code version can be replaced.

Thanks,
Stefan