• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 1466 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.

Trying to use UBI with OMAPL138

Marc-Andre Hebert
Prodigy 160 points
Other Parts Discussed in Thread: OMAPL138

Hello,

I am trying to use UBI on top the NAND on the OMAPL138. But I am having problems. I am currently using TFTP and NFS to boot from the network. I enabled UBI and UBIFS in the kernel and cross compiled the ubi user tools. I then try to follow the steps from the ubifs FAQ.

Here are the mtd devices created by default on the EV

mtd0: 0x000000000000-0x000000020000 : "u-boot env"
mtd1: 0x000000020000-0x000000040000 : "UBL"
mtd2: 0x000000040000-0x0000000c0000 : "u-boot"
mtd3: 0x000000200000-0x000000600000 : "kernel"
mtd4: 0x000000600000-0x000020000000 : "filesystem"

Here are the 2 issues I observed.

1) There are errors when attaching the UBI device the second time (doing attach on a freshly erased/formatted mtd returns no error)

ubiattach /dev/ubi_ctrl -m 4
Then I get a series of error messages:
UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 0:0, read 64 bytes
[...]
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 2:512, read 512 bytes
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 21:512, read 512 bytes
UBI: run torture test for PEB 21
UBI: PEB 21 passed torture test, do not mark it a bad 
And these last 4 lines keep getting repeated.

2) Doing a ubiformat seems to screp the bad block table used by u-boot 
Ex: root# ubiformat /dev/mtd4
Then at the following boot:
NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)
Bad block table not found for chip 0
Bad block table not found for chip 0
Bad block table written to 0x1ffe0000, version 0x01
Bad block table written to 0x1ffc0000, version 0x01

From what I've gathered the BBT in u-boot uses the last 4 blocks. 
At first I was only trying with mtd4 so I figured reducing it's size by 4 blocks and defining a mtd5 for the BTT would work but it didn't. 
I then tried formatting the mtd3 and obtained the same results. 
I don't see why this is affecting the BBT table.

Any help would be appreciated
Marc
  • 0
    Prodigy 160 points

    I actually found a partial answer for my problem number 1. I needed to specify "--vid-hdr-offset 2048" when attaching the mtd device because sub pages do not seem to be supported.

    I still have the issue with the BBT being rewritten each time.

    Thanks

    Marc

  • 0 in reply to Marc-Andre Hebert
    Prodigy 160 points

    The BBT being rewritten was corrected by updating the u-boot to the latest version from the git tree (http://arago-project.org/git/people/?p=sekhar/u-boot-omapl1.git).

  • 0 in reply to Marc-Andre Hebert
    TI__Expert 5170 points

    Marc,

    I did not observe problem No. 1 reported by you if I run ubiattach/ubidetach multiple times (without any arguments) after running ubiformat on the partition.

    Regards,

    Sudhakar

  • 0 in reply to Sudhakar Rajashekhara
    Prodigy 155 points

    I'm using DaVinci-PSP-SDK-03.20.00.11 for U-Boot and Linux kernel on the TI OMAPL-138.  I am having the exact same problem as

    How were you able to solve error No. 1 from the first post?

    Thanks,

    Clif

  • 0 in reply to Clifton Barnes
    Prodigy 160 points

    Like I said in an earlier post, you need to specify the --vid-hdr-offset 2048 when attaching.

  • 0 in reply to Marc-Andre Hebert
    Prodigy 155 points

    If I specify that option I get the following:

    # ubiattach --vid-hdr-offset 2048 /dev/ubi_ctrl -m2
    UBI: attaching mtd2 to ubi0
    UBI: physical eraseblock size:   131072 bytes (128 KiB)
    UBI: logical eraseblock size:    126976 bytes
    UBI: smallest flash I/O unit:    2048
    UBI: sub-page size:              512
    UBI: VID header offset:          2048 (aligned 2048)
    UBI: data offset:                4096
    UBI error: validate_ec_hdr: bad VID header offset 512, expected 2048
    UBI error: validate_ec_hdr: bad EC header
    Backtrace:
    [<c002d5b8>] (dump_backtrace+0x0/0x110) from [<c02e4748>] (dump_stack+0x18/0x1c)
     r6:c3a14800 r5:00000000 r4:c3a5e400 r3:00000040
    [<c02e4730>] (dump_stack+0x0/0x1c) from [<c01e5e64>] (ubi_io_read_ec_hdr+0x2dc/0x34c)
    [<c01e5b88>] (ubi_io_read_ec_hdr+0x0/0x34c) from [<c01e9360>] (ubi_scan+0x134/0x7d0)
    [<c01e922c>] (ubi_scan+0x0/0x7d0) from [<c01dfe50>] (ubi_attach_mtd_dev+0x604/0xcc4)
    [<c01df84c>] (ubi_attach_mtd_dev+0x0/0xcc4) from [<c01e07b8>] (ctrl_cdev_ioctl+0xec/0x1a8)
    [<c01e06cc>] (ctrl_cdev_ioctl+0x0/0x1a8) from [<c00ae508>] (vfs_ioctl+0x34/0xb4)
     r6:40186f40 r5:bef9ac28 r4:c396fc00
    [<c00ae4d4>] (vfs_ioctl+0x0/0xb4) from [<c00aebd4>] (do_vfs_ioctl+0x554/0x5ac)
     r6:c3415ad8 r5:c396fc00 r4:bef9ac28 r3:00002000
    [<c00ae680>] (do_vfs_ioctl+0x0/0x5ac) from [<c00aec6c>] (sys_ioctl+0x40/0x64)
    [<c00aec2c>] (sys_ioctl+0x0/0x64) from [<c0029f60>] (ret_fast_syscall+0x0/0x28)
     r7:00000036 r6:00000003 r5:ffffffff r4:bef9ac28
    UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
    UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -22
    ubiattach: error!: cannot attach mtd2
               error 22 (Invalid argument)

    I should have specified that I had tried your suggestion before.  So, I didn't know if there was something else that was found to fix this problem.

  • 0 in reply to Clifton Barnes
    Prodigy 155 points

    Ok, I figured out my problem.  The NAND chip that I'm using only supported 1 bit ECC and the default from the EVM was using 4 bit ECC.  Once I changed to 1 bit ECC in the board file, I was able to attach/detach and boot to the UBI image.