Use ubifs on Linux-2.6.31

Some time ago I transplanted the Linux-2.6.31 TO THE lpc3250, but encountered some problems when using ubifs. At 2.7.27.8, ubifs started running without any problems, but why is it not possible here? After half a day of exploration, I finally got it done. below is the process. The main phenomenon is in linux-2.6.27, ubi information is: creating 1 MTD partitions on "nand0": 0x000000600000-0x000001600000: "MTD = 3" device_name0: MTD = 3ubi: attaching mtd1 to ubi0ubi: physical eraseblock size: 131072 bytes (128 kib) ubi: Logical eraseblock size: 129024 bytesubi: smallest flash I/O unit: 2048ubi: Sub-page size: 512ubi: vid header offset: 512 (aligned 512) ubi: Data offset: 2048 scanning error 0ubi: attached mtd1 Ubi0ubi: MTD device name: "MTD = 3" Ubi: MTD device size: 16 mibubi: Number of good pebs: Invalid ubi: Number of bad pebs: 1ubi: Max. allowed volumes: 128ubi: Wear-leveling threshold: Capacity: number of internal volumes: 1ubi: number of user volumes: 1ubi: available pebs: 0ubi: Total number of reserved pebs: descriubi: number of pebs reserved for bad peb handling: 2ubi: Max/mean erase counter: 4/1 on 2.6.27, UBI recognizes sub-page, and the vid header offset is 512. [1.191000] ubi: attaching mtd3 to ubi0 [1.195000] ubi: Physical eraseblock size: 131072 bytes (128 kib) [1.201000] ubi: Logical eraseblock size: 126976 bytes [1.207000] ubi: smallest flash I/O unit: 2048 [1.212000] ubi: vid header offset: 2048 (aligned 2048) [1.218000] ubi: Data offset: 4096 [1.407000] ubi: attached mtd3 to ubi0 [1.411000] ubi: MTD device na Me: "safefs" [1.416000] ubi: MTD device size: 16 MIB [1.421000] ubi: Number of good pebs: 128 [1.426000] ubi: Number of bad pebs: 0 [1, 1.430000] ubi: Max. allowed volumes: 128 [1.435000] ubi: Wear-leveling threshold: 4096 [1.440000] ubi: number of internal volumes: 1 [1.444000] ubi: number of user volumes: 1 [1.449000] ubi: available pebs: 0 [1.453000] ubi: Total number of reserved pebs: 128 [1.4580 00] ubi: Number of pebs reserved for bad peb handling: 2 [1.464000] ubi: Max/mean erase counter: 2125/17 [1.469000] ubi: Image Sequence Number: 0 [1.473000] ubi: Background thread "ubi_bgt0d" started, PID 325 is not identified on the linux-2.6.31 but on the sub-page, vid header offset is 2048. But the same NAND Flash is used. How is the difference so big? It should be the cause of the MTD driver. Of course, the above comparison information is the complete information after the correct start. The initial ubi error message is: [1.168000] ubi: attaching mtd3 to ubi0 [1.172000] ubi: Physical eraseblock size: 131072 bytes (128 kib) [1.179000] ubi: Logical eraseblock size: 126976 bytes [1.184000] ubi: smallest flash I/O unit: 2048 [1.189000] ubi: vid header offset: 2048 (aligned 2048) [1.195000] ubi: Data offset: 4096 [1.201000] ubi error: validate_ec_hdr: Bad vid header offset 512, expected 2048 [1.209000] ubi Error: validate_ec_hdr: Bad EC header [1.214000] ubi error: ubi_io_read_ec_hdr: Validation failed for peb 0 [1.221000] ubi error: ubi_init: cannot attach mtd3 [1.228000] ubi error: ubi_init: UBI error: Cannot initialize ubi, error-22 solution process: (1) After u- boot generates ubi partitions and adds vid offset of 2048: ubi part safefs 2048, the information displayed is: but the kernel still cannot get up. However, the error is: [1.122000] creating 5 MTD partitions on "NAND 256mib, 3 V 8-bit": [1.129000] 0x0000000000000000-0x000000180000: "Boot" [1.141000] 0x000000180000-0x0000001c0000: "PRMS" [1.152000] 0x000000200000-0x000000600000: "kernel" [1.163000] 0x000000600000-0x000001600000: "safefs" [1.174000] 0x000001600000-0x00000000000: "rootfs" [1.191000] ubi: attaching mtd3 to ubi0 [1.195000] ubi: Physical eras Eblock size: 131072 bytes (128 kib) [1.202000] ubi: Logical eraseblock size: 126976 bytes [1.207000] ubi: smallest flash I/O unit: 2048 [1.212000] ubi: vid header offset: 2048 (aligned 2048) [1.218000] ubi: Data offset: 4096 [1.408000] ubi: attached mtd3 to ubi0 [1.412000] ubi: MTD device name: "safefs" [1.417000] ubi: MTD device size: 16 MIB [1.422000] ubi: Number of good pebs: 128 [1.426000] ubi: Number of bad pebs: 0 [1.431000] ubi: Max. allowed volumes: 128 [1.435000] ubi: Wear-leveling threshold: 4096 [1.440000] ubi: number of internal volumes: 1 [1.445000] ubi: number of user volumes: 1 [1.449000] ubi: available pebs: 0 [1.454000] ubi: Total number of reserved pebs: 128 [1.458000] ubi: Number of pebs reserved for bad peb handling: 2 [1, 1.465000] ubi: Max/mean erase counter: 4/1 [1.4690 00] ubi: Image Sequence Number: 0 [1.473000] ubi: Background thread "ubi_bgt0d" started, PID 325 [2.431000] ubifs error (PID 1): validate_sb: LEB size mismatch: 129024 in superblock, 126976 real [2.440000] ubifs error (PID 1): validate_sb: Bad superblock, error 1 obviously, ubi is no problem, and now it is ubifs, the problem occurs when the ubifs parameter is incorrect. The kernel prompts 126976 instead of 512 at the time of 129024! (2) modify the parameters for creating an ubi image by changing the command to mkfs. ubifs-r safefs-M 2048-e 126976-C 128-O safefs. UBI re-creates a security file system. The security file system starts normally! Create an ubi image: mkfs. ubifs-r rootfs-M 2048-e 126976-C 1872-O rootfs. imgubinize-O ubi. IMG-M 2048-P 128kib-s 2048 ubi. CFG (3) modify the parameter for burning the ubi image: ubiformat/dev/mtd4-s 2048-F ubi. after img>/dev/null 2> & 1, the problem is solved and the system is started successfully.