spi flash jffs2异常解决

在替换spi flash时出现了两个问题：

1.没有业务的时候在挂载app和usr分区时出现了如下的打印：

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d9004: 0x14f2 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d9008: 0x8b8b instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d900c: 0x1553 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d9010: 0x6c14 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d9014: 0x0c0d instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d9018: 0x1474 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d901c: 0x2a53 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d9020: 0xf352 instead

这个问题在set_4byte添加了一个case，恢复了正常

第二个问题排查得比较久，需要教长篇幅来说明一下过程：

在解决了第一个问题的后，我们想把完整的业务烧录进去，进行长拷测试。在启动后，发现仍然有挂载不上去的问题，最终将问题定位到nor flash的能力集的参数上面：

在这个"0"的位置上，本身是SECT_4K，把它改成0之后，app分区挂载正常了，可以正常读取启动业务脚本；

之后便出来了第二个问题：

在业务启动后，不停地出现这些打印：

jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x000000c0)
jffs2: Newly-erased block contained word 0x20031985 at offset 0x00859000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x00857000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x00854000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x00852000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x00851000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x0084f000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x0084e000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x0084c000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x0084b000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x00849000
jffs2: Newly-erased block contained word 0x20031985 at offset 0x00846000
jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x00000048)
jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x00000048)
jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x00000048)
jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x00000048)

1）猜测可能是芯片本身问题

在测试中在关闭业务后，发现无法删除usr下地某一个文件；

在替换芯片之后仍然出现这个问题，排除单颗芯片问题；

2）spi flash引脚信号不对

与fae沟通后，会不会是硬件配置不对，因为fae有同样的demo板，换上同样的芯片后，使用正常，想验证一下spi 的 wp 和 hold引脚是否功能正常；

经过测量也没有任何异常，时钟频率也一致，但是在boot下时钟频率是10M左右，内核下时钟频率为20M，因为在boot下读写flash正常，因为app和ios分区功能正常；

但是修改频率的方式仍然出问题：1.在驱动中强制配置成9.75M，仍然会出现问题；2.spi20M时钟频率下，在app分区读写文件仍然可以；

3）确认无法读写位置

发现app分区读写位置可以，想排除一下usr是哪里开始不能读写，最后排查到是usr分区最后4M，
0x000001700000-0x000002000000 : "usr"

可以看到usr分区也是在flash的最后，也就是说flash的最后4M区域出现问题；

读到status register(sr)数据为0x1c，根据器件手册可以看到，对应的block protect位是bp0 bp1 bp2为1，导致的异常；

我们在spi flash初始化的时候，把这个寄存器给设置0，flash被保护的区域可以正常读写了；

4）最终解决

在发现是操作了sr之后，于是我在flash的驱动中查找操作sr寄存器的操作，在lock函数中找到了对sr进行操作，于是我在想是不是这个地方会导致sr的异常操作：

于是在probe函数里发现了lock和unlock的注册，我尝试将此处屏蔽，

没想到真起了作用，没有报错了，问题解决了；

5）查找问题原因

既然知道了调用了lock，我查找到了mtd_lock函数会调用到这个接口，我便在mtd_lock中加入debug，查看如何调用到这个位置，添加的debug函数和调用栈信息打印如下：

从堆栈信息的跟踪发现，传入了MEMLOCK这个参数，最终定位到了我们调用的接口，问题原因已经查明；