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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
