找出uboot中,对于oob的定义,比如是第几位定义的。
和如何烧写nand的,包括数据和oob,是一次性写入的,还是数据和oob分两次写的。
然后找出jffs文件系统中的函数,是如何去定义oob的,并且是如何读取和写入数据的。如何进行校验的。
目前出错的现象是
ECC读取错误,很可能是当时uboot写入的ECC校验数据,和jffs2中对于读取的数据进行ECC计算后,算出的ECC
的值不一样。
可能是ECC的位置在oob中的定义,uboot和jffs2两者定义不一样
很可能是,nand驱动中是用bch校验的,计算出来的ECC的值,和uboot中写入rootfs的数据之后,计算出来的
ECC写入到oob中的ECC,这两个不一样,所以,jffs2中读出来,就不一样了。
很可能是uboot中的没有用bch,而nand驱动中用了bch。
或者是 uboot中用了,而jffs2中没有用
或者是我们nand驱动中用了,并且uboot中也用了bch,但是jffs2中的文件系统中在读取ECC的时候,没有用
bch,好像其本身也并不支持,或说没有包含bch支持的。
尝试,重新烧写一个没有bch的kernel,然后看看是否会出现read error,return ECC error
如果是的话,则说明,错误好像不在ECC校验算法的问题上,有待继续追踪
如果没有这个错误,则很有可能是jffs2的ECC校验和nand驱动和uboot中烧写rootfs进去的时候用的ECC算法不一样。
突然想起来,nand scrub这个命令,会将nand flash上的数据和oob的信息擦除,这样的话,即使是坏块,也没有标记了,也可以使用了,所以这个命令是unsafe的。
这样的话,那uboot将rootfs写入到nand flash中的时候,然后写入计算的ECC进入oob,但是如果正好这个page是之前标记为坏的,但是被nand scrub清除了该标记,这样的坏块,之后jffs2再去读的时候,极有可能就出错了,尤其是MLC的nand flash。这样的话,每次读取该位置的数据,然后再计算ECC的值,那么肯定是和原始的,u-boot写出oob中的ECC不一样了,也就会出现:
ECC error的问题和 读出数据所计算出来的ECC和原始的ECC不一样了。(板子kernel panic时候之前出现的问题)
问题如果是这样的话,解决办法就很麻烦,貌似samsung的flash mannual中说了,那个bad block的标记,如果被擦除了,就无法恢复了。也就是出厂时候标记的坏块,但是你后来将其标记擦除了,那么这个block就用起来和好的一样了,但是实际上,肯定容易出问题的,估计属于不稳定的那种。
不过,不清除,对于其他jffs2之类的文件系统,是否有办法,检测出来这种坏块,然后再标记,那样的话,就好办了,就先让jffs2将其标记好,之后不使用这样的坏块就行了。哦,估计uboot也应该有类似功能的。有空继续查找问题的原因。。。
网上有人说了:
1. nand scrub会把坏块标志擦掉,这样误标为坏块的就可以使用了
2. 有一些命令会自动跳过坏块,比如:nand write.jffs2 ….
貌似不用担心这个问题了,不过还有待查证。。。
转载请注明:在路上 » TODO - uboot