Summary of jffs2_scan_eraseblock issues

Summarize the problems encountered before:
1. For similar problems:
mtd->read(0x44 bytes from 0x68cf44) returned ECC error
jffs2_get_inode_nodes(): CRC failed on node at 0x0068c684: Read 0xe8b9b3b0, calculated 0x9402829b
, it is an error when writing the file system. You can use nand write to cramfs, but you need to use nand write.jffs2 command to write jffs2 file system.

2. For similar problems:
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0050e154: 0xfbeb instead
, it is an error when using mkfs.jffs2 command to make the file system. The nand flash of FS2410 board is Samsung's K9F1208U0B. The command used is:
mkfs.jffs2 -r /source/rootfs -o rootfs.jffs2 -e 0x4000 --pad=0x800000 -n

The meaning of each parameter:
(1)-r: specifies the source folder to be made into an image.
(2)-o: specifies the file name of the output image file.
(3)-e: the block size of each block to be erased, the default is 64KB. Please note that different flash memories have different block sizes. Mine is Samsung's K9F1208U0B.
(4)--pad (-p): uses hexadecimal to indicate the size of the file to be output, that is, the size of root.jffs2. It is very important that in order not to waste flash space, this value should be consistent with the block size planned by the flash driver. Here we use 8MB.
(5) If a warning similar to "CLEANMARKER node found at 0x0042c000 has totlen 0xc != normal 0x0" appears after mounting, add -n and it will disappear.
(6) For other options, please read the help yourself! -hSummarize

the process of making jffs2 file system on FS2410:
For detailed process, please refer to: "Realizing JFFS2 root file file system on nand flash"
1. Download mtd-snapshot-20050519.tar.bz2 and generate the tool of mkfs.jffs2;
[fs2410@home]$ tar –jxvf mtd-snapshot-20050519.tar.bz2
[fs2410@home]$ cd mtd/util
[fs2410@home]$ makeUse
ls command to view the mkfs.jffs2 file;
2. Generate JFFS2 file image
[fs2410@home]$ mkfs.jffs2 -r /source/rootfs -o rootfs.jffs2 -e 0x4000 --pad=0x800000 -n
3. Set uboot startup parameters:
FS2410#setenv bootargs root=/dev/mtdblock/2 rootfstype=jffs2 rw console=ttySAC0,115200 init=/linuxrc mem=64M
4. Download rootfs.jffs2 image
Download to the second partition of Nand Flash.
FS2410#nand erase 200000 800000
FS2410#nand write.jffs2 300008000 200000 800000

Method 2:
[fs2410@home]#mkfs.jffs2 -r /source/rootfs -o rootfs.jffs2 -e 0x4000 -n

Start the development board and burn the rootfs.jffs2 image
FS2410#nand erase 200000 800000 //(Note that the entire partition storing the file system should be erased).
FS2410#nand write.jffs2 30008000 200000 31a28c //(It must be the actual size of rootfs.jffs2. If you write 4M, the rest of the partition will not be recognized by the JFFS2 file system).

Attached is the kernel configuration of jffs2:
File systems ---> Miscellaneous filesystems --->
<*>JournallingFlash File System v2 (JFFS2) support
[*]JFFS2write-bufferingsupport
[*]AdvancedcompressionoptionsforJFFS2
[*]JFFS2ZLIBcompressionsupport
[*]JFFS2RTIMEcompressionsupport
[* ] JFFS2 RUBIN compression support

Note:
When configuring the kernel, I did not select:
NAND Flash Kevice Drivers--->
[] S3C2410 NAND Hardware ECC
The ecc check in drivers/mtd/nand/s3c2410.c uses:
chip->eccmod = NAND_ECC_SOFT

There are related questions, and the solutions to my own situations are given:
jffs2 file system under redboot
http://blog.sina.com.cn/s/blog_4a082210010005dq.html
http://www.smth.edu.cn/pc/pccon.php?id=2150&nid=129263&p=n
There are two main problems here, which are explained separately.
6.1.2 Notes on creating jffs2 file system
The dozens of lines of "jffs2_scan_eraseblock(): Magic bitmask 0x198 5 not found..." that appear during the boot process
indicate that there is a problem with the jffs2 file system. In addition, if I first use the remote NFS root file
system to boot, and then directly mount -t jffs2 /dev/mtdblock/2 /mnt in the target system, I will also
get the same warning message, but I can see the correct file system content under /mnt.
To solve this problem, I first carefully read the manual page of mkfs.jffs2 and found that the --eraseblock
parameter seemed to be more important, but I did not use it. So I found the parameter value 0x20000 and used it
to regenerate the image file. Tests showed that the problem still existed.
Looking up information, I found that someone emphasized the use of the -p option when mkfs.jffs2, which is to
fill 0xFF from the end of the file to the last erase block. At this time, I realized that the unallocated space of FLASH must
be filled with 0xFF. But my previous approach could not guarantee this. First, the -p option was not specified; second, because the -l parameter
specified a length that was much larger than the actual image file size, a large amount of garbage data in the memory area was written
to the FLASH.
Therefore, I re-created the jffs2 file system image with the -p parameter and changed -l 0x200000 to 0x140000 to write
FLASH. Then, mounting the device again was OK, and no warning message appeared again. But kernel panic
still exists, which is another problem.

6.1.3 /dev/mtdblock/2 or /dev/mtdblock2
(First of all, '2' is just an example. /dev/mtdblock/n, n=0,1,2,3,...)
It seems that these two device nodes should be completely equivalent. At least I thought so.
In the materials I saw, some used /dev/mtdblock/2 and some used /dev/mtdblock2. The difference that can be seen is that
if multiple MTD block device nodes are needed, putting these nodes in a separate /dev/mtdblock directory
instead of putting them all under /dev can make /dev look more refreshing. Therefore, when I made the root file system
, I chose the former, that is, I created 8 device nodes 0-7 under the /dev/mtdblock directory.

However, the error "Kernel panic: VFS: Unable to mount root fs on 1f:00" indicates that
the kernel did not correctly locate the root file system from the boot parameter "root=/dev/mtdblock/2" (even though
the previous problem has been solved to ensure that there is no problem with the jffs2 file system).
After considering and eliminating many possibilities, I decided to try "root=/dev/mtdblock
2" out of desperation. A miracle happened, and the boot was successful! Special attention should be paid to the fact that I did not modify the /dev device node at this time, but only
modified the writing of the boot parameter. In other words, no matter whether the MTD device node you created is /dev/mtdblock
/2 or /dev/mtdblock2, the kernel boot parameter should be "root=/dev/mtdblock2"!
In order not to cause more confusion, I still changed the device node to /dev/mtdblock2
. So can the kernel boot parameter use the /dev/mtdblock/2 format? Later, I guessed that
if the kernel supports devfs, it should be possible. Isn't the purpose of devfs to change /dev from a messy flat
structure to a clear hierarchical structure? But I haven't verified it yet. In addition, it is also possible
to use the "major device number, minor device number" format in the kernel boot parameters to specify the location of the root file system . As shown below, "root=1f02" also specifies /dev/mtdblock2. 0x1f=31 is the major device number of the MTD block device, and 0x02=2 is the minor device number, that is, mtdblock2.