zynq linux内核出错,Zynq-Linux移植学习笔记（二十五）——新内核JFFS2文件系统CRC错误解决...

1、背景介绍

最近为了使用PCIe驱动，对Linux内核进行了升级，目前ZYNQ发布的最新版内核为2017.4(对应内核版本4.9)，升级虽然解决了PCIe驱动问题，但却引入了另一个奇怪的问题-挂载JFFS2文件系统时会出现如下错误：

jffs2: jffs2_scan_eraseblock(): Node at 0x0000225c {0x1985, 0xe002, 0xe002e002) has invalid CRC 0x84d1586d (calculated 0x1d56aca6)

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002260: 0xe002 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002264: 0x586d instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002268: 0x0002 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000226c: 0x05b4 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002270: 0x81a4 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002278: 0x7c00 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000227c: 0x91dc instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002280: 0x584f instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002284: 0x91f3 instead

jffs2: Further such events for this erase block will not be printed

jffs2: jffs2_scan_eraseblock(): Node at 0x0002012c {0x1985, 0xe002, 0xe002e002) has invalid CRC 0x528c90e9 (calculated 0x1d56aca6)

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020130: 0xe002 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020134: 0x90e9 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020138: 0x0002 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002013c: 0x0597 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020140: 0x81a4 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020148: 0x4000 instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002014c: 0x91dc instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020150: 0x584f instead

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020154: 0x91f2 instead

jffs2: Further such events for this erase block will not be printed

jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000206e4: Read 0x8e8855a0, calculated 0x8a540cb6

jffs2: jffs2_scan_eraseblock(): Node at 0x0004598c {0x1985, 0xe002, 0xe002e002) has invalid CRC 0x84d1586d (calculated 0x1d56aca6)

这个问题在老版本的内核(3.14)中是不存在的，具体参看我之前发布的ZYNQ下NOR FLASH文件系统挂载。

询问AVNET工程师，在Xilinx论坛上发帖(链接地址)，发现他们都误以为是我的rootfs镜像问题，让我用mkfs.jffs2工具生成rootfs时设置正确的erasesize和pad，其实我的问题与rootfs一毛钱关系没有，我的nor flash存放的是应用，qspi flash才存放rootfs，这完全是两个不同的地方。不过Xilinx论坛上面的老外提到了新版的内核可能存在BUG，这与我GOOGLE到的结果存在一致性，于是最终决定更换文件系统。EX2? EX3?EX4?都试过，貌似只支持硬盘，NOR FLASH这种东西不支持。

最后还是感谢万能的GOOGLE，让我发现了UBIFS。

2、UBIFS准备工作

为了使用UBIFS，需要在rootfs中添加UBIFS文件系统所需的工具，也就是下图列出来的这些

由于我之前把rootfs文件系统升级到了petalinux2016.4，文件系统中的工具都是采用arm-linux-gnueabihf进行编译的，为了保持一致性，需要用arm-linux-gnueabihf将mtd-utils重新编译一遍，可以参看这里：

经过了这些坎，可以把UBIFS需要的工具编译出来了，放入rootfs中/usr/bin中吧。

3、内核配置

除了rootfs中添加工具，编译内核的时候也需要启用UBIFS，主要启用两处，一处在驱动中，一处在文件系统中，见下图

如果不想每次使用菜单，直接在config文件中增加2行即可。

4、UBIFS使用

UBIFS中的使用可以参看这里，讲的很全，MTD里面所有的命令都讲了。

对我来说，只需要下面4个命令，

1. ubiformat /dev/mtdX //擦除mtdX

2. ubiattach /dev/ubi_ctrl -m Y //和mtdY关联，/dev/ubi_ctrl需要自己创建

3. ubimkvol /dev/ubi0 -N ubifs -m //创建一个volume，volume才是最终挂载文件系统的地方， /dev/ubi0需要自己创建

4. mount -t ubifs ubi0_0 /mnt/ubifs //挂载UBIFS

注意：上述步骤的1、3项只在Linux下第一次挂载UBIFS时会用到，后续只要直接执行2、4即可。

实验结果如下

这里我创建了一个文件夹123，挂载在MTD1分区，然后通过FTP上传了一个文件上去。

umount之后再次mount，发现文件还在，文件系统一切正常。

最后可以在脚本中增加命令，让操作系统启动后自动挂载UBIFS文件系统

5、总结

被JFF2文件系统mount时CRC校验出错这个问题折腾了差不多有一周，很是煎熬。自己对比了新老内核的源码，还是找不到原因，也做了不少对比试验，增加了打印，依然无解。最后只好换成了UBIFS，希望未来linux内核能解决这个问题吧。不过话说回来，这个过程也让我学到了不少知识，也发现UBIFS比JFFS2要好用一些，算是痛并快乐着吧。分享在这里，希望和我碰见相同问题的童鞋们少走弯路。如果交叉编译器和我一样，可以从这里下载我编译好的tar包：

https://download.csdn.net/download/jj12345jj198999/10349462

文章来源：Felven的博客

注：本文为授权转载文章，如需转载请联系作者授权