最近为改板的AM1808移植了u-boot,kernel,使用am1808开发低成本m2m设备,支持3G,Wifi, zigbee,gps,rtc,SD/microSD,目的第一个版本已发布。
NAND的ECC校验较上以版本有所改善,并使用ubifs作为新的文件系统,支持sd卡更新系统。
下面是一些整理的资料,有些来自TI,有些来自论坛
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?
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 4Then 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
-
Posted by Marc-Andre HebertProdigy 160points
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
-
Posted by Marc-Andre HebertProdigy 160points
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).
-
Posted by Sudhakar RajashekharaExpert 5070points
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.
-
Posted by Clifton BarnesProdigy 90points
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
-
Posted by Marc-Andre HebertProdigy 160points
Like I said in an earlier post, you need to specify the --vid-hdr-offset 2048 when attaching.
-
Posted by Clifton BarnesProdigy 90points
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.