- 论坛徽章:
- 1
|
nand驱动从512兆升级2G, 升级后第一次启动,UBI文件系统有CRC错误：
UBI: attaching mtd7 to ubi0
UBI: scanning is finished
UBI error: vtbl_check: bad CRC at record 11: 0x9063ba41, not 0xf116c36b
Volume table record 11 dump:
reserved_pebs 0
alignment 0
data_pad 0
vol_type 0
upd_marker 0
name_len 0
name NULL
UBI error: vtbl_check: bad CRC at record 11: 0x9063ba41, not 0xf116c36b
Volume table record 11 dump:
reserved_pebs 0
alignment 0
data_pad 0
vol_type 0
upd_marker 0
name_len 0
name NULL
UBI error: process_lvol: both volume tables are corrupted
UBI error: ubi_attach_mtd_dev: failed to attach mtd7, error -22
ubiattach: error!: cannot attach "/dev/mtd7"
error 22 (Invalid argument)
UBIFS error (pid 1073): ubifs_mount: cannot open "/dev/ubi0_0", error -22
mount: mounting /dev/ubi0_0 on /opt/ failed: Invalid argument
Creating of the UBI filesystem
ubidetach: error!: cannot detach "/dev/mtd7"
error 19 (No such device)
Erasing 128 Kibyte @ 0 -- 0 % complete
。。。。。。。。。
Erasing 128 Kibyte @ 1f680000 -- 98 % complete
flash_erase: Skipping bad block at 1ffa0000
flash_erase: Skipping bad block at 1ffc0000
flash_erase: Skipping bad block at 1ffe0000
Erasing 128 Kibyte @ 1ffe0000 -- 100 % complete
UBI: scanning is finished
UBI: empty MTD device detected
UBI: attached mtd7 (name "nand.user", size 512 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 4088, bad PEBs: 8, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 1833581601
UBI: available PEBs: 4012, total reserved PEBs: 76, PEBs reserved for bad PEB handling: 72
UBI: background thread "ubi_bgt0d" started, PID 1083
UBI device number 0, total 4088 LEBs (527450112 bytes, 503.0 MiB), available 4012 LEBs (517644288 bytes, 493.7 MiB), LEB size 129024 bytes (126.0 KiB)
Set volume size to 517644288
Volume ID 0, size 4012 LEBs (517644288 bytes, 493.7 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "optfs", alignment 1
UBIFS: default file-system created
UBIFS: background thread "ubifs_bgt0_0" started, PID 1088
UBIFS: mounted UBI device 0, volume 0, name "optfs"
UBIFS: LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 515579904 bytes (491 MiB, 3996 LEBs), journal size 25804800 bytes (24 MiB, 200 LEBs)
UBIFS: reserved for root: 4952683 bytes (4836 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 02C5B8D5-51DE-40BA-A8FC-9895F2A6D0D8, small LPT model
重新格式化后下次启动就一切正常。重新格式化只在第一次升级驱动时发生。我把全部volume table 读出来分析了一下。
系统只用一个volume, ubi_vtbl_record 结构内容解读如下：
reserved_pebs 00 00 0f ac 4012 à 4012*128*1024 =527040512 bytes
alignment 00 00 00 01 1
data_pad 00 00 00 00 0
vol_type 01 1
udp_marker 00 0
name_len 00 05 5
name 6f 70 74 66 73 optfs
4012个blocks在这个vol ptfs，文件系统预留76个块，8个坏块
对于512M的nand, 我们只用了一个volume : optfs
optfs的信息无论正常启动，还是有CRC错误，这个optfs的记录都正确。
系统中最多允许有128个vol，虽然不用，系统保留ubi_vtbl_record结构。
正常启动，所有不用的vol的ubi_vtbl_record结构内容均为0
启动出现CRC错误时 ，有几个不用的vol的ubi_vtbl_record结构内容不全为0
vol 11, 23, 35, … ubi_vtbl_record结构内容有0xff出现,导致CRC失败，重新格式化。
问题：
为什么不用的vol的ubi_vtbl_record结构内有0xff ? 怀疑两个驱动版本的oob处理有偏差
为什么ubi对不用的vol也作CRC测试？
|
|
免费注册
发表于 2014-11-10 10:32
