找出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