OMAPL138/AM1808支持NAND及其ECC出现的问题回复

最近为改板的AM1808移植了u-boot，kernel，使用am1808开发低成本m2m设备，支持3G，Wifi, zigbee,gps,rtc,SD/microSD,目的第一个版本已发布。

NAND的ECC校验较上以版本有所改善,并使用ubifs作为新的文件系统，支持sd卡更新系统。

下面是一些整理的资料，有些来自TI，有些来自论坛

OMAP-L138 NAND_ECC_HW and U-Boot

I'm a little bit confused about how OMAP-L138hardware supports 4-bit ECC for NAND devices. NAND device in question is:

SAMSUNG K9F2G08UXA
- Page Program : (2K + 64)Byte
- Block Erase : (128K + 4K)Byte

By default, DaVinci-PSP-SDK-03.20.00.06 is configured in terms of NAND ECC as follows:

U-Boot:
#undef CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_NAND_4BIT_HW_ECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CFG_DAVINCI_STD_NAND_LAYOUT

Linux:
static struct davinci_nand_pdata da850_evm_nandflash_data = {
    .parts        = da850_evm_nandflash_partition,
    .nr_parts    = ARRAY_SIZE(da850_evm_nandflash_partition),
    .ecc_mode    = NAND_ECC_HW,
    .ecc_bits    = 4,
    .options    = NAND_USE_FLASH_BBT,
};

However, it turns out that these definitions are not compatible with  each other. When I flash a JFFS2 root filesystem on the NAND device,  mounting it fails. Changing the above options to:

U-Boot:
#define CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_NAND_USE_FLASH_BBT
#define CFG_DAVINCI_STD_NAND_LAYOUT

Linux:
static struct davinci_nand_pdata da850_evm_nandflash_data = {
    .parts        = da850_evm_nandflash_partition,
    .nr_parts    = ARRAY_SIZE(da850_evm_nandflash_partition),
    .ecc_mode    = NAND_ECC_HW,
    .ecc_bits    = 1,
    .options    = NAND_USE_FLASH_BBT,
};

Allows my system to boot. Unfortunately, there is one problem with  this. My device needs to be able to program the boot area (UBL etc.)  directly from Linux. OMAP-L138hardware boot supports only 4-bit ECC. Thus, my workaround is useless  as programming the bootsector with 1-bit ECC won't work. My conclusions  are:

- U-Boot porgrams the NAND Flash with 4bit ECC correctly (I'm able to flash the bootsector from U-Boot with no problems)
- Linux configuration/implementation for 4-bit ECC is broken

How canI solve my issue? Linux and U-Boot codes are based on  DaVinci-PSP-SDK-03.20.00.06 software. Were there any patches in the more  recent versions?

Trying to use UBI with OMAPL138

This question is not answered         

Posted by Marc-Andre Hebert

on Apr 21, 2010 6:24 PM

Prodigy160points

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

u-bootOMAP L138 NANDOMAP L138MTDNANDLinux Drivers

Report Abuse

Reply

All Replies

• Posted by Marc-Andre Hebert

  onApr 21, 2010 7:09 PM

  Prodigy160points

  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

  Report Abuse

  Reply

• Posted by Marc-Andre Hebert

  onApr 22, 2010 7:40 PM

  Prodigy160points

  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).

  Report Abuse

  Reply

• Posted by Sudhakar Rajashekhara

  onApr 26, 2010 12:36 PM

  Expert5070points

  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

  Does this help with your question? If not, please send back more information. If it answers your question, please click the Verify Answer button below.

  Report Abuse

  Reply

• Posted by Clifton Barnes

  onAug 31, 2010 7:56 PM

  Prodigy90points

  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 No.  1 from Marc-Andre Hebert.  I can do "ubiformat /dev/mtd2 -f rfs" to  format the NAND partition and flash my UBI root filesystem.  I can then  "ubiattach /dev/ubi_ctrl -m2" and everything works fine with no errors.   However, if I then run "ubidetach /dev/ubi_ctrl -m2" and then run  "ubiattach /dev/ubi_ctrl -m2" again, it is not successful.  I get the  following:

  # ubiattach /dev/ubi_ctrl -m2
  UBI: attaching mtd2 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_io_read: error -74 while reading 64 bytes from PEB 237:0, read 64 bytes
  Backtrace:
  [<c002d5b8>] (dump_backtrace+0x0/0x110) from [<c02e4748>] (dump_stack+0x18/0x1c)
   r6:c3a31000 r5:ffffffb6 r4:00000040 r3:00000000
  [<c02e4730>] (dump_stack+0x0/0x1c) from [<c01e5604>] (ubi_io_read+0x1a8/0x244)
  [<c01e545c>] (ubi_io_read+0x0/0x244) from [<c01e5bfc>] (ubi_io_read_ec_hdr+0x74/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:bec0ec48 r4:c3906400
  [<c00ae4d4>] (vfs_ioctl+0x0/0xb4) from [<c00aebd4>] (do_vfs_ioctl+0x554/0x5ac)
   r6:c3415ad8 r5:c3906400 r4:bec0ec48 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:bec0ec48
  

  <repeated many times>

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

  Thanks,

  Clif

  
  

  Report Abuse

  Reply

• Posted by Marc-Andre Hebert

  onAug 31, 2010 8:01 PM

  Prodigy160points

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

  Report Abuse

  Reply

• Posted by Clifton Barnes

  onAug 31, 2010 8:12 PM

  Prodigy90points

  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.