[U-Boot] Bricked when trying to attach UBI
Luca Ceresoli
luca.ceresoli at comelit.it
Wed Dec 19 12:28:02 CET 2012
Hi all,
I am facing a problem with some boards that do not boot after some
weeks or months of normal usage, being unable to attach UBI. They do
not boot anymore event after a power cycle, in other words they are
totally bricked.
I don't know exactly what problem UBI has, but it is recoverable by
Linux, but apparently not by U-Boot.
The boards are DIG297 (dig297 board in mainline U-Boot), based on
OMAP3530 and equipped with a NAND flash (Micron MT29F2G16ABBEAHC) as
their unique permanent storage.
U-Boot v2012.04.01 starts correctly. The bootcmd tries to load the
kernel from UBI, starting with the following commands:
echo Booting from nand ...
setenv bootargs console=ttyO2,115200n8
mtdparts=omap2-nand.0:768k(uboot),128k(reserved),128k(uboot-env),-(ubi)
ubi.mtd=3 root=ubi0:rootfs ro rootfstype=ubifs ip=....
ubi part nand0,3
...
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)
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?
Big thanks in advance,
Luca
More information about the U-Boot
mailing list