ECC纠错算法Word格式.docx
《ECC纠错算法Word格式.docx》由会员分享,可在线阅读,更多相关《ECC纠错算法Word格式.docx(9页珍藏版)》请在冰点文库上搜索。
CP4为第0、1、2、3列的极性,CP5为第4、5、6、7列的极性。
用公式表示就是:
CP0=Bit0^Bit2^Bit4^Bit6,表示第0列内部256个Bit位异或之后再跟第2列256个Bit位异或,再跟第4列、第6列的每个Bit位异或,这样,CP0其实是256*4=1024个Bit位异或的结果。
CP1~CP5依此类推。
行校验如下图所示
其中RP0~RP15为十六个Bit位,表示RowParity(行极性),
RP0为第0、2、4、6、….252、254个字节的极性
RP1-----1、3、5、7……253、255
RP2----0、1、4、5、8、9…..252、253(处理2个Byte,跳过2个Byte)
RP3----2、3、6、7、10、11…..254、255(跳过2个Byte,处理2个Byte)
RP4----处理4个Byte,跳过4个Byte;
RP5----跳过4个Byte,处理4个Byte;
RP6----处理8个Byte,跳过8个Byte
RP7----跳过8个Byte,处理8个Byte;
RP8----处理16个Byte,跳过16个Byte
RP9----跳过16个Byte,处理16个Byte;
RP10----处理32个Byte,跳过32个Byte
RP11----跳过32个Byte,处理32个Byte;
RP12----处理64个Byte,跳过64个Byte
RP13----跳过64个Byte,处理64个Byte;
RP14----处理128个Byte,跳过128个Byte
RP15----跳过128个Byte,处理128个Byte;
可见,RP0~RP15每个Bit位都是128个字节(也就是128行)即128*8=1024个Bit位求异或的结果。
综上所述,对256字节的数据共生成了6个Bit的列校验结果,16个Bit的行校验结果,共22个Bit。
在Nand中使用3个字节存放校验结果,多余的两个Bit位置1。
存放次序如下表所示:
以K9F1208为例,每个Page页包含512字节的数据区和16字节的OOB区。
前256字节数据生成3字节ECC校验码,后256字节数据生成3字节ECC校验码,共6字节ECC校验码存放在OOB区中,存放的位置为OOB区的第0、1、2和3、6、7字节。
校验码生成算法的C语言实现
在Linux内核中ECC校验算法所在的文件为drivers/mtd/nand/,其实现有新、旧两种,在及更早的内核中使用的程序,从开始已经不再使用,而换成了效率更高的程序。
可以在Documentation/mtd/文件中找到对新程序的详细介绍。
首先分析一下内核中的ECC实现,源代码见:
/*
Pre-calculated256-way1bytecolumnparity
*/
staticconstu_char
nand_ecc_precalc_table[]={
0x00,0x55,0x56,0x03,0x59,0x0c,0x0f,0x5a,0x5a,0x0f,0x0c,0x59,0x03,0x56,0x55,0x00,
0x65,0x30,0x33,0x66,0x3c,0x69,0x6a,0x3f,0x3f,0x6a,0x69,0x3c,0x66,0x33,0x30,0x65,
0x66,0x33,0x30,0x65,0x3f,0x6a,0x69,0x3c,0x3c,0x69,0x6a,0x3f,0x65,0x30,0x33,0x66,
0x03,0x56,0x55,0x00,0x5a,0x0f,0x0c,0x59,0x59,0x0c,0x0f,0x5a,0x00,0x55,0x56,0x03,
0x69,0x3c,0x3f,0x6a,0x30,0x65,0x66,0x33,0x33,0x66,0x65,0x30,0x6a,0x3f,0x3c,0x69,
0x0c,0x59,0x5a,0x0f,0x55,0x00,0x03,0x56,0x56,0x03,0x00,0x55,0x0f,0x5a,0x59,0x0c,
0x0f,0x5a,0x59,0x0c,0x56,0x03,0x00,0x55,0x55,0x00,0x03,0x56,0x0c,0x59,0x5a,0x0f,
0x6a,0x3f,0x3c,0x69,0x33,0x66,0x65,0x30,0x30,0x65,0x66,0x33,0x69,0x3c,0x3f,0x6a,
0x00,0x55,0x56,0x03,0x59,0x0c,0x0f,0x5a,0x5a,0x0f,0x0c,0x59,0x03,0x56,0x55,0x00
};
为了加快计算速度,程序中使用了一个预先计算好的列极性表。
这个表中每一个元素都是unsignedchar类型,表示8位二进制数。
表中8位二进制数每位的含义:
这个表的意思是:
对0~255这256个数,计算并存储每个数的列校验值和行校验值,以数作数组下标。
比如nand_ecc_precalc_table[13]存储13的列校验值和行校验值,13的二进制表示为00001101,其CP0=Bit0^Bit2^Bit4^Bit6=0;
CP1=Bit1^Bit3^Bit5^Bit7=1;
CP2=Bit0^Bit1^Bit4^Bit5=1;
CP3=Bit2^Bit3^Bit6^Bit7=0;
CP4=Bit0^Bit1^Bit2^Bit3=1;
CP5=Bit4^Bit5^Bit6^Bit7=0;
其行极性RP=Bit0^Bit1^Bit2^Bit3^Bit4^Bit5^Bit6^Bit7=1;
则nand_ecc_precalc_table[13]处存储的值应该是01010110,即0x56.
注意,数组nand_ecc_precalc_table的下标其实是我们要校验的一个字节数据。
理解了这个表的含义,也就很容易写个程序生成这个表了。
程序见附件中的文件。
有了这个表,对单字节数据dat,可以直接查表nand_ecc_precalc_table[dat]得到dat的行校验值和列校验值。
但是ECC实际要校验的是256字节的数据,需要进行256次查表,对得到的256个查表结果进行按位异或,最终结果的Bit0~Bit5即是256字节数据的CP0~CP5.
/*Buildupcolumnparity*/
for(i=0;
i<
256;
i++){
/*GetCP0-CP5fromtable*/
idx=nand_ecc_precalc_table[*dat++];
reg1^=(idx&
0x3f);
//这里省略了一些,后面会介绍
}
Reg1
在这里,计算列极性的过程其实是先在一个字节数据的内部计算CP0~CP5,每个字节都计算完后再与其它字节的计算结果求异或。
而表1中是先对一列Bit0求异或,再去异或一列Bit2。
这两种只是计算顺序不同,结果是一致的。
因为异或运算的顺序是可交换的。
行极性的计算要复杂一些。
nand_ecc_precalc_table[]表中的Bit6已经保存了每个单字节数的行极性值。
对于待校验的256字节数据,分别查表,如果其行极性为1,则记录该数据所在的行索引(也就是for循环的i值),这里的行索引是很重要的,因为RP0~RP15的计算都是跟行索引紧密相关的,如RP0只计算偶数行,RP1只计算奇数行,等等。
i++)
{
/*AllbitXOR=1*/
if(idx&
0x40){
reg3^=(uint8_t)i;
reg2^=~((uint8_t)i);
这里的关键是理解第88和89行。
Reg3和reg2都是unsignedchar型的变量,并都初始化为零。
行索引(也就是for循环里的i)的取值范围为0~255,根据表2可以得出以下规律:
RP0只计算行索引的Bit0为0的行,RP1只计算行索引的Bit0为1的行;
RP2只计算行索引的Bit1为0的行,RP3只计算行索引的Bit1为1的行;
RP4只计算行索引的Bit2为0的行,RP5只计算行索引的Bit2为1的行;
RP6只计算行索引的Bit3为0的行,RP7只计算行索引的Bit3为1的行;
RP8只计算行索引的Bit4为0的行,RP9只计算行索引的Bit4为1的行;
RP10只计算行索引的Bit5为0的行,RP11只计算行索引的Bit5为1的行;
RP12只计算行索引的Bit6为0的行,RP13只计算行索引的Bit6为1的行;
RP14只计算行索引的Bit7为0的行,RP15只计算行索引的Bit7为1的行;
已经知道,异或运算的作用是判断比特位为1的个数,跟比特位为0的个数没有关系。
如果有偶数个1则异或的结果为0,如果有奇数个1则异或的结果为1。
那么,程序第88行,对所有行校验为1的行索引按位异或运算,作用便是:
判断在所有行校验为1的行中,
属于RP1计算范围内的行有多少个------由reg3的Bit0指示,0表示有偶数个,1表示有奇数个;
属于RP3计算范围内的行有多少个------由reg3的Bit1指示,0表示有偶数个,1表示有奇数个;
属于RP5计算范围内的行有多少个------由reg3的Bit2指示,0表示有偶数个,1表示有奇数个;
属于RP7计算范围内的行有多少个------由reg3的Bit3指示,0表示有偶数个,1表示有奇数个;
属于RP9计算范围内的行有多少个------由reg3的Bit4指示,0表示有偶数个,1表示有奇数个;
属于RP11计算范围内的行有多少个------由reg3的Bit5指示,0表示有偶数个,1表示有奇数个;
属于RP13计算范围内的行有多少个------由reg3的Bit6指示,0表示有偶数个,1表示有奇数个;
属于RP15计算范围内的行有多少个------由reg3的Bit7指示,0表示有偶数个,1表示有奇数个;
所以,reg3每个Bit位的作用如下表所示:
Reg3
第89行,对所有行校验为1的行索引按位取反之后,再按位异或,作用就是判断比特位为0的个数。
比如reg2的Bit0为0表示:
所有行校验为1的行中,行索引的Bit0为0的行有偶数个,也就是落在RP0计算范围内的行有偶数个。
所以得到结论:
在所有行校验为1的行中,
属于RP0计算范围内的行有多少个------由reg2的Bit0指示,0表示有偶数个,1表示有奇数个;
属于RP2计算范围内的行有多少个------由reg2的Bit1指示,0表示有偶数个,1表示有奇数个;
属于RP4计算范围内的行有多少个------由reg2的Bit2指示,0表示有偶数个,1表示有奇数个;
属于RP6计算范围内的行有多少个------由reg2的Bit3指示,0表示有偶数个,1表示有奇数个;
属于RP8计算范围内的行有多少个------由reg2的Bit4指示,0表示有偶数个,1表示有奇数个;
属于RP10计算范围内的行有多少个------由reg2的Bit5指示,0表示有偶数个,1表示有奇数个;
属于RP12计算范围内的行有多少个------由reg2的Bit6指示,0表示有偶数个,1表示有奇数个;
属于RP14计算范围内的行有多少个------由reg2的Bit7指示,0表示有偶数个,1表示有奇数个;
所以,reg2每个Bit位的作用如下表所示:
Reg2
至此,只用了一个查找表和一个for循环,就把所有的校验位CP0~CP5和RP0~RP15全都计算出来了。
下面的任务只是按照表3的格式,把这些比特位重新排列一下顺序而已。
从reg2和reg3中抽取出RP8~RP15放在tmp1中,抽取出RP0~RP7放在tmp2中,
Reg1左移两位,低两位置1,
然后把tmp2,tmp1,reg1放在ECC码的三个字节中。
程序中还有CONFIG_MTD_NAND_ECC_SMC,又进行了一次取反操作,暂时还不知为何。
当往NANDFlash的page中写入数据的时候,每256字节我们生成一个ECC校验和,称之为原ECC校验和,保存到PAGE的OOB(out-of-band)数据区中。
当从NANDFlash中读取数据的时候,每256字节我们生成一个ECC校验和,称之为新ECC校验和。
将从OOB区中读出的原ECC校验和新ECC校验和按位异或,若结果为0,则表示不存在错(或是出现了ECC无法检测的错误);
若3个字节异或结果中存在11个比特位为1,表示存在一个比特错误,且可纠正;
若3个字节异或结果中只存在1个比特位为1,表示OOB区出错;
其他情况均表示出现了无法纠正的错误。
假设ecc_code_raw[3]保存原始的ECC校验码,ecc_code_new[3]保存新计算出的ECC校验码,其格式如下表所示:
对ecc_code_raw[3]和ecc_code_new[3]按位异或,得到的结果三个字节分别保存在s0,s1,s2中,如果s0s1s2中共有11个Bit位为1,则表示出现了一个比特位错误,可以修正。
定位出错的比特位的方法是,先确定行地址(即哪个字节出错),再确定列地址(即该字节中的哪一个Bit位出错)。
确定行地址的方法是,设行地址为unsignedcharbyteoffs,抽取s1中的Bit7,Bit5,Bit3,Bit1,作为byteoffs的高四位,抽取s0中的Bit7,Bit5,Bit3,Bit1作为byteoffs的低四位,则byteoffs的值就表示出错字节的行地址(范围为0~255)。
确定列地址的方法是:
抽取s2中的Bit7,Bit5,Bit3作为bitnum的低三位,bitnum其余位置0,则bitnum的表示出错Bit位的列地址(范围为0~7)。
下面以一个简单的例子探索一下这其中的奥妙。
假设待校验的数据为两个字节,0x45(二进制为01000101)和0x38(二进制为00111000),其行列校验码如下表所示:
从表中可以计算出CP5~CP0的值,列在下表的第一行(原始数据)。
假设现在有一个数据位发生变化,0x38变为0x3A,也就是Byte1的Bit1由0变成了1,计算得到新的CP5~CP0值放在下表第2行(变化后数据)。
新旧校验码求异或的结果放在下表第三行。
可见,当Bit1发生变化时,列校验值中只有CP1,CP2,CP4发生了变化,而CP0,CP3,CP5没变化,也就是说6个Bit校验码有一半发生变化,则求异或的结果中有一半为1。
同理,行校验求异或的结果也有一半为1。
这就是为什么前面说256字节数据中的一个Bit位发生变化时,新旧22Bit校验码求异或的结果中会有11个Bit位为1。
再来看怎么定位出错的Bit位。
以列地址为例,若CP5发生变化(异或后的CP5=1),则出错处肯定在Bit4~Bit7中;
若CP5无变化(异或后的CP5=0),则出错处在Bit0~Bit3中,这样就筛选掉了一半的Bit位。
剩下的4个Bit位中,再看CP3是否发生变化,又选出2个Bit位。
剩下的2Bit位中再看CP1是否发生变化,则最终可定位1个出错的Bit位。
下面的树形结构更清晰地展示了这个判决过程:
图表1出错Bit列地址定位的判决树
注意:
图中的CP指的是求异或之后的结果中的CP
为什么只用CP4,CP2,CP0呢其实这里面包含冗余信息,因为CP5=1则必有CP4=0,CP5=0则必有CP4=1,也就是CP5跟CP4一定相反,同理,CP3跟CP2一定相反,CP1跟CP0一定相反。
所以只需要用一半就行了。
这样,我们从异或结果中抽取出CP5,CP3,CP1位,便可定位出错Bit位的列地址。
比如上面的例子中CP5/CP3/CP1=001,表示Bit1出错。
同理,行校验RP1发生变化,抽取RP1,可知Byte1发生变化。
这样定位出Byte1的Bit0出错。
当数据位256字节时,行校验使用RP0~RP15,抽取异或结果的RP15,RP13,RP11,RP9,RP7,RP5,RP3,RP1位便可定位出哪个Byte出错,再用CP5,CP3,CP1定位哪个Bit出错。
//////////////////////////////完/////////////////////////////////////////////
现在,我的疑问就出来了。
看下面一段原话:
而其对应的ECC纠错代码里面,有个纠错函数intnand_correct_data(u_char*read_ecc,u_char*calc_ecc),里面有如下的一个判断:
if(((s0^(s0>
>
1))&
0x55)==0x55&
&
((s1^(s1>
((s2^(s2>
0x54)==0x54)
{。
。
这个判断的作用应该就是,判断s0s1s2中是否共有11个Bit位为1我就看不明白,为什么判断这s0s1s2是否有11个1,上面的if条件就可以判断出来里面有什么玄机呢望高手指点,呵呵!