[Solved] In yaffs2, after the MTD block device is mounted, insmod will die.

[Symptom] In Linux 2.6.22, the latest yaffs2 is added. after implementing the NAND Flash Driver, MTD test is used to test the driver. However, a strange problem was found recently: After mounting/dev/mtdblock4/mnt/usb_msc, it is automatically mounted to the yaff2 file system and then any KO in insmod will die without any output information, even the oops of the kernel, corresponding to the first line of the Ko, no. [Solution process] 1. after tests, we found that for 2 k NAND Flash with pagesize (due to special requirements (hardware hw ecc occupies too much space ), therefore, tag ECC of yaffs2 (to save space for storing hw ecc) can work normally. However, for 4 K pagesize nand, it does not work normally. The MTD test tool has been used to verify that 2 K and 4 k nand drivers can work normally. 2. I checked the MTD layer about 2 K and 4 K, what is different, found that the corresponding include/mtd-abi.h, struct nand_ecclayout, eccpos or 64, so it is changed to 128, test again to solve the problem. 3. For others, the cause is not found. Therefore, it is inferred that yaffs2 is compatible with MTD and other issues. 4. After tests, the/dev/mtdblock4 parameter was used Insmod dwc_otg.ko Insmod gadgetfs. Ko Insmod g_file_storage.ko file =/dev/mtdblock4 stall = 0 removable = 1 Mount the USB masstorage, format the USB flash disk to FAT32 in windows, then go to the board Mount/dev/mtdblock4/mnt/usb_msc-T vfat Mount it to a FAT partition. In this way, you can avoid yaffs2, but it is related to the MTD layer. The result is tested, Data Reading and writing are still correct, but mount the data first and then execute other operations. operations involving kernel data results will still die. That is, whether it is mounted to yaffs2: Mount/dev/mtdblock4/mnt/usb_msc Or Mount/dev/mtdblock4/mnt/usb_msc-T vfat The data read and write operations for the partition are OK, but the operation is performed later. Insmod ***. Ko or other loadkmap programs involving kernel operations will cause the kernel to die, Unlike General Oops and null pointers, there is no output at all. When the system crashes, it uses rvds to connect to the board and finds that the PC is always at 0xffff000c, corresponding to the exception of arm prefetch: ArmTypes of exceptions supported by the architecture Exception type When the reset level is valid, a reset exception occurs, and the program jumps to the reset handler for execution. An exception occurs when an undefined command encounters an instruction that cannot be processed. The software is interrupted to execute SWI commands and is used to call privileged operation commands in user mode. The prefetch abort processor prefetch instruction address does not exist, or the address does not allow access from the current instruction, resulting in an exception in prefetch abort. If the address of the data access command of the Data stop processor does not exist or the address does not allow access by the current command, an exception occurs. An IRQ exception occurs when the IRQ external interrupt request is valid and the I bit in CPSR is 0. FIQ exception occurs when the FIQ fast interrupt request pin is valid and the F bit in CPSR is 0. Abnormal vector table (exception Vectors) Abnormal address Entry Mode 0 x idle, reset Management Mode Ox0000, 0004 undefined command undefined Mode 0 x software interrupt Management Mode 0x0000,000 C abort (pre-storage command) Abort Mode 0 x idle, stop (data) Stop Mode 0 x, reserved 0 x random, IRQ 0x0000,001 C FIQ That is to say, the last error prefetch refers to the suspension, that is, to read the command from where the corresponding command (CODE) should be stored, The result obtained is invalid. Therefore, the prefetch is aborted and stops. 5. The problem found at last Include/Linux/MTD/NAND. h: Struct nand_buffers { Uint8_t eccc1c [mtd_nand_max_oobsize]; Uint8_t ecccode [mtd_nand_max_oobsize]; Uint8_t databuf [mtd_nand_max_pagesize + mtd_nand_max_oobsize]; }; The corresponding macro of databuf: # Define mtd_nand_max_pagesize 2048 # Define mtd_nand_max_oobsize 64 Therefore Int nand_scan_tail (struct mtd_info * MTD) { ... If (! (Chip-> options & nand_own_buffers )) Chip-> buffers =Kmalloc(Sizeof (* chip-> buffers ),Gfp_kernel ); ... } Kmalloc applies for 20 bytes of space. In this way, for 2 k pagesize nand, it must work normally, but for 4 K pagesize, if the upper layer, such as yaffs2, the MTD is used to read data. The data on a page is 4 K, which is then stored in the buffer. The system data of 2048 next to the result is washed out, if the system then uses this part of data or commands, there will be problems. The prefetch here refers to the abort exception, which means that the next 2048 bytes may contain some system-related commands (and other data) and the result system is executed here, the pointer is not normal, so it is suspended. [Solution] The solution is also very simple, that is, the corresponding macro should be large enough, such: # Define mtd_nand_max_pagesize 8192 # Define mtd_nand_max_oobsize 256 In this way, even the 8 k nand can be well supported in the future. [Reference] 1. Exception vectors of arm in bootloader (1)