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