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重新编译一遍，可以参看这里：
https://wiki.beyondlogic.org/index.php/Cross_Compiling_MTD_Utils_for_ARM
不过编译过程中也遇到一些BUG，比如找不到GLIBC_2.14，解决见 https://blog.csdn.net/cpplang/article/details/8462768。MTD-utils-1.5.0编译失败，解决见https://blog.csdn.net/ternence_hsu/article/details/71194893
经过了这些坎，可以把UBIFS需要的工具编译出来了，放入rootfs中/usr/bin中吧。
3、内核配置
除了rootfs中添加工具，编译内核的时候也需要启用UBIFS，主要启用两处，一处在驱动中，一处在文件系统中，见下图
如果不想每次使用菜单，直接在config文件中增加2行即可。
4、UBIFS使用
UBIFS中的使用可以参看这里，讲的很全，MTD里面所有的命令都讲了。
http://www.cnblogs.com/pengdonglin137/p/3415663.html
对我来说，只需要下面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包：