呵呵,今天发一个2.0版本。 分析一下tiny210v2的16bitECC校验(说说OOB)
1.知彼知己方能百战不殆,窥测一下Superboot有多么牛逼CONFIG_SYS_TEXT_BASE :=0x23E00000
测试方法:
(1)写一个裸机代码led.bin,程序的功能是将DRAM的CONFIG_SYS_TEXT_BASE地址(这个也同样是程序的链接地址)处开始的256k左右的数据通过串口输出,这里且称这个程序为led.bin。
(2)制作一个里边全是‘AA’的二进制文件(大小256k左右)贴到led.bin的后边。这个“结合体”命名为ledABCD.bin。然后
用MiniTools以下载裸机程序到NandFlash的方法下载到NandFlash中去。
(3)从NandFlash启动,这个“结合体”会被Superboot启动拷贝拷贝到CONFIG_SYS_TEXT_BASE处。
(4)超级终端我用的是scrt,可以保存为文本文件。然后编定一个文件操作的程序,将这个文件中的“16进制数”转化为真正的16进制数到一个二进制文件中,这里为bin.bin。
(5)这样原文件有了,从NandFlash拷贝的数据文件也有了,用一个二进制文件对比工具bcampare对比一下就见分晓了。(后边我自己的拷贝程序也是这样测试的)。截个图:
(开头是文本文件的头自动产生了信息,最后是多输出的内容。
中间的‘AA 。。。AA’有256K一个位翻转都没有,这应该有多么牛逼)
2.关于“淡定码” :E2 3E FE B5 6F F2 CD 78 A9 6E CD 57 09 F4 0E D8 9E 2E 8F 77 90 A9 85 E9 0A 74
在经过Main区的校验后,开发着手研究OOB区的校验,每页16x512Byte用了16条ECC校验码,后边还有一个第17条(从上文的tiny210v2 oob内容可以看出)。开始我还以为这个是OOB的检验码。着手研究它的变化规律,我把8K的‘AA’中最后一个Byte换成了‘
AB’。第16条ECC校验码(图中红线)已经变的不成样了。不过第17条我认为的OOB区的校验码(高亮显示的),似乎没有变化。
我就再进一步,看一个u-boot中的这个条码是什么:
OOB区的内容已经变化,但是这个“码”,始终没有变化。我本来以为它是OOB区的校验码,结果失望了。这个“码”到底是什么,我暂且这样称呼“淡定码”吧。
3.死马当活马医 对着那串“淡定码”我真是一筹莫展,我想过要放弃接下来的校验,因为当“Main区的ECC校验码”也出现了翻转时,我唯一能想到的方法就是进行OOB(SPARE)区的ECC校验。数据手册上也是这个引导着做的。但是“淡定码”真心淡定,它似乎不能胜任这个工作了。好好睡了一晚上,第二天,我像警察叔叔破案一样,一遍一遍重启开发板,看“Main区的校验码”翻转的情况。最终我的观察结果也是乐观的。因为我发现了一些蛛丝马迹。
我虽至今明白16bit的ECC校验码是怎么计算出来的,但是通过反复观察,我发现正确的校验码最终反应给表示翻转Byte位置的NFECCERL(0~7)寄存器的值都是
递增的(如上图)。如果出现Main区的ECC码也翻转的情况。那么它的值会跑到前边来,也就是说就打破了“
递增”了规律。
4.软件来实现 在3中已经找到了规律。转换成软件来解说就是先将翻转BYTE的位置存到一个数组中,num为翻转BYTE的数量。存完后,来检测这个数组的前num项是否为“递增”,如果是说明没有出现误判断,如果不是则num--;也就是说最后一样是误判断的,不进行修正。
通过1里边提到的测试方法进行测试:这样已经将最后误差减小到了1厘米(1个BYTE翻转)
但是就是这一厘米的误差,让其启动u-boot的时候也会卡在这里:
这里用的u-boot是:
http://www.cnblogs.com/lihaiping/archive/2013/04/17/tiny210v2uboot.html(陈孝正的“我的人生是一栋只能建造一次的楼房,我必须让它精确无比,
不能有一厘米差池”,看来我要研究一下这一厘米的差池是从哪里来的,下次解决它!)
[ 此帖被kangear在2013-06-06 15:22重新编辑 ]