• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 2234 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ubifs + ubinize

Arend Lapere
Intellectual 810 points

Hello,

I'm having a little difficulty with using the UBIFS image i created. I've used the following commands:

sudo mkfs.ubifs -r beaglebone/ -F -o ubifs.img -m 2048 -e 126976 -c 1580

where beaglebone is the folder containing the rootfs

sudo ubinize -o ubi.img -m 2048 -p 128KiB -s 512 -O 2048 ubinize.cfg

the ubinize.cfg

[code]

[RFS-volume]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=192MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize[/code]

with the following NAND:

 It's a 4Gb nand flash from samsung : K9F4G08U0D


I load the ubifs with uboot over TFTP. ( for production reasons I cannot do it in linux ). I write it to the correct position on my nand.

When I load the kernel, it detects the NAND, creates the partitions, and finally starts loading the FS. HOWEVER, it gives me an error right away, observe

my kernel output:

[ 1.549377] UBI: attaching mtd7 to ubi0
[ 1.553497] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 1.560089] UBI: logical eraseblock size: 126976 bytes
[ 1.565795] UBI: smallest flash I/O unit: 2048
[ 1.570739] UBI: VID header offset: 2048 (aligned 2048)
[ 1.577087] UBI: data offset: 4096
[ 1.817749] UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 217:0, read 64 bytes
[ 1.828826] UBI warning: process_eb: valid VID header but corrupted EC header at PEB 217
[ 1.837951] UBI error: process_eb: bad image sequence number 896115277 in PEB 218, expected 177001884
[ 1.847717] slab error in kmem_cache_destroy(): cache `ubi_scan_leb_slab': Can't free all objects
[ 1.857086] Backtrace:
[ 1.859710] [<c0018c00>] (dump_backtrace+0x0/0x10c) from [<c0432050>] (dump_stack+0x18/0x1c)
[ 1.868621] r7:ffffffea r6:cf34e000 r5:cf389a40 r4:cf1420c0
[ 1.874633] [<c0432038>] (dump_stack+0x0/0x1c) from [<c00a9a84>] (kmem_cache_destroy+0xc0/0x104)
[ 1.883941] [<c00a99c4>] (kmem_cache_destroy+0x0/0x104) from [<c02848dc>] (ubi_scan+0x32c/0xa34)
[ 1.893218] r5:cf389a40 r4:000000da
[ 1.897003] [<c02845b0>] (ubi_scan+0x0/0xa34) from [<c027c520>] (ubi_attach_mtd_dev+0x470/0xa54)
[ 1.906311] [<c027c0b0>] (ubi_attach_mtd_dev+0x0/0xa54) from [<c05d0738>] (ubi_init+0x210/0x324)
[ 1.915618] [<c05d0528>] (ubi_init+0x0/0x324) from [<c0008698>] (do_one_initcall+0x3c/0x190)
[ 1.924530] [<c000865c>] (do_one_initcall+0x0/0x190) from [<c05af288>] (kernel_init+0x80/0x124)
[ 1.933746] [<c05af208>] (kernel_init+0x0/0x124) from [<c0043b88>] (do_exit+0x0/0x69c)
[ 1.942108] r5:c05af208 r4:00000000
[ 1.946044] UBI error: ubi_init: cannot attach mtd7


Searching the internet didn't give me any help, fixes or ideas... I hope you can help me out :-)


Kind regards,

Arend

  • 0
    Intellectual 810 points

    Hello Again,

    I fixed it! It was quite easy to fix after all! For all you people who are having the same problem, this is what happened, followed by how I fixed it:

    When writing the ubinized data from uboot, I got an error regarding a bad block! It skipped the bad-block, what I didn't foresee was the fact that it actually skipped the data, meaning it would never get written AT ALL. So to fix this, I had to recalculate the length of the data to be written by adding the proper amount of bytes equal to the ones lost in that block.

    For my specific case, I've just doubled the amount of bytes... it wasn't clean but it shows that it doesn't really matter, as long as it is better!

    I've learned a lot about how these things work now! ^^

    Enjoy!