linux mtd层ecc详解

ECC的全称是Error Checking and Correction，是一种用于 Nand 的差错检测和修正算法。如果操作时序和电路稳定性不存在问题的话， NAND Flash 出错的时候一般不会造成整个 Block 或是 Page 不能读取或是全部出错，而是整个 Page （例如 512Bytes ）中只有一个或几个 bit 出错。 ECC 能纠正1 个比特错误和检测2 个比特错误，而且计算速度很快，但对 1 比特以上的错误无法纠正，对 2 比特以上的错误不保证能检测。
校验码生成算法：ECC 校验每次对 256 字节的数据进行操作，包含列校验和行校验。对每个待校验的 Bit 位求异或，若结果为 0 ，则表明含有偶数个 1 ；若结果为 1 ，则表明含有奇数个 1 。列校验规则如表 1 所示。 256 字节数据形成 256 行、 8 列的矩阵，矩阵每个元素表示一个 Bit 位。

其中CP0 ~ CP5  为六个 Bit 位，表示 Column Parity （列极性），
CP0 为第 0 、 2 、 4 、 6 列的极性， CP1 为第 1 、 3 、 5 、 7 列的极性，
CP2 为第0、 1 、 4 、 5 列的极性， CP3 为第2、 3 、 6 、 7 列的极性，
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 位，表示 Row Parity （行极性），
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/nand_ecc.c，其实现有新、旧两种，在2.6.27及更早的内核中使用的程序，从2.6.28开始已经不再使用，而换成了效率更高的程序。可以在Documentation/mtd/nand_ecc.txt 文件中找到对新程序的详细介绍。


首先分析一下2.6.27内核中的ECC实现，源代码见:
http://lxr.linux.no/linux+v2.6.27/drivers/mtd/nand/nand_ecc.c
43 /*
44  * Pre-calculated 256-way 1 byte column parity
45  */
46 static const  u_char
nand_ecc_precalc_table [] = {
47    0x00, 0x55, 0x56, 0x03, 0x59, 0x0c, 0x0f, 0x5a, 0x5a, 0x0f, 0x0c, 0x59, 0x03, 0x56, 0x55, 0x00,
48    0x65, 0x30, 0x33, 0x66, 0x3c, 0x69, 0x6a, 0x3f, 0x3f, 0x6a, 0x69, 0x3c, 0x66, 0x33, 0x30, 0x65,
49    0x66, 0x33, 0x30, 0x65, 0x3f, 0x6a, 0x69, 0x3c, 0x3c, 0x69, 0x6a, 0x3f, 0x65, 0x30, 0x33, 0x66,
50    0x03, 0x56, 0x55, 0x00, 0x5a, 0x0f, 0x0c, 0x59, 0x59, 0x0c, 0x0f, 0x5a, 0x00, 0x55, 0x56, 0x03,
51    0x69, 0x3c, 0x3f, 0x6a, 0x30, 0x65, 0x66, 0x33, 0x33, 0x66, 0x65, 0x30, 0x6a, 0x3f, 0x3c, 0x69,
52    0x0c, 0x59, 0x5a, 0x0f, 0x55, 0x00, 0x03, 0x56, 0x56, 0x03, 0x00, 0x55, 0x0f, 0x5a, 0x59, 0x0c,
53    0x0f, 0x5a, 0x59, 0x0c, 0x56, 0x03, 0x00, 0x55, 0x55, 0x00, 0x03, 0x56, 0x0c, 0x59, 0x5a, 0x0f,
54    0x6a, 0x3f, 0x3c, 0x69, 0x33, 0x66, 0x65, 0x30, 0x30, 0x65, 0x66, 0x33, 0x69, 0x3c, 0x3f, 0x6a,
55    0x6a, 0x3f, 0x3c, 0x69, 0x33, 0x66, 0x65, 0x30, 0x30, 0x65, 0x66, 0x33, 0x69, 0x3c, 0x3f, 0x6a,
56    0x0f, 0x5a, 0x59, 0x0c, 0x56, 0x03, 0x00, 0x55, 0x55, 0x00, 0x03, 0x56, 0x0c, 0x59, 0x5a, 0x0f,
57    0x0c, 0x59, 0x5a, 0x0f, 0x55, 0x00, 0x03, 0x56, 0x56, 0x03, 0x00, 0x55, 0x0f, 0x5a, 0x59, 0x0c,
58    0x69, 0x3c, 0x3f, 0x6a, 0x30, 0x65, 0x66, 0x33, 0x33, 0x66, 0x65, 0x30, 0x6a, 0x3f, 0x3c, 0x69,
59    0x03, 0x56, 0x55, 0x00, 0x5a, 0x0f, 0x0c, 0x59, 0x59, 0x0c, 0x0f, 0x5a, 0x00, 0x55, 0x56, 0x03,
60    0x66, 0x33, 0x30, 0x65, 0x3f, 0x6a, 0x69, 0x3c, 0x3c, 0x69, 0x6a, 0x3f, 0x65, 0x30, 0x33, 0x66,
61    0x65, 0x30, 0x33, 0x66, 0x3c, 0x69, 0x6a, 0x3f, 0x3f, 0x6a, 0x69, 0x3c, 0x66, 0x33, 0x30, 0x65,
62

0x00, 0x55, 0x56, 0x03, 0x59, 0x0c, 0x0f, 0x5a, 0x5a, 0x0f, 0x0c, 0x59, 0x03, 0x56, 0x55, 0x00
63 };



为了加快计算速度，程序中使用了一个预先计算好的列极性表。这个表中每一个元素都是 unsigned char 类型，表示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 = Bit 0^Bit1 ^ Bit2^ Bit3^ Bit4^ Bit5^ Bit6^ Bit7 =  1 ；
则nand_ecc_ precalc_table[  13  ]  处存储的值应该是  0101 0110 ，即0x 56.
注意，数组nand_ecc_ precalc_table 的下标其实是我们要校验的一个字节数据。
理解了这个表的含义，也就很容易写个程序生成这个表了。程序见附件中的  MakeEccTable.c 文件。



有了这个表，对单字节数据dat，可以直接查表  nand_ecc_precalc_table[ dat ]  得到 dat的行校验值和列校验值。 但是ECC实际要校验的是256字节的数据，需要进行256次查表，对得到的256个查表结果进行按位异或，最终结果的  Bit0 ~ Bit5  即是 256 字节数据的 CP0 ~ CP5.
/* Build up column parity */
  81         for( i  = 0;  i  < 256;  i ++) {
  82
/* Get CP0 - CP5 from table */
  83
idx  =  nand_ecc_precalc_table [* dat ++];
  84
reg1  ^= ( idx  & 0x3f);
  85
  86             // 这里省略了一些，后面会介绍
  91         }



R eg1





在这里，计算列极性的过程其实是先在一个字节数据的内部计算 CP0 ~ CP5,  每个字节都计算完后再与其它字节的计算结果求异或。而表1中是先对一列Bit 0 求异或，再去异或一列 Bit2 。 这两种只是计算顺序不同，结果是一致的。 因为异或运算的顺序是可交换的。



行极性的计算要复杂一些。
nand_ecc_ precalc_table[]  表中的 Bit6 已经保存了每个单字节数的行极性值。对于待校验的256字节数据，分别查表，如果其行极性为1，则记录该数据所在的行索引（也就是for循环的i值），这里的行索引是很重要的，因为RP 0 ~ RP15  的计算都是跟行索引紧密相关的，如RP0只计算偶数行，RP1只计算奇数行，等等。

/* Build up column parity */
  81         for( i  = 0;  i  < 256;  i ++) {
  82
/* Get CP0 - CP5 from table */
  83
idx  =  nand_ecc_precalc_table [* dat ++];
  84
reg1  ^= ( idx  & 0x3f);
  85
  86
/* All bit XOR = 1 ? */
  87                 if ( idx  & 0x40) {
  88
reg3  ^= ( uint8_t )  i ;
  89
reg2  ^= ~(( uint8_t )  i );
  90                 }
  91         }


这里的关键是理解第88和89行。 Reg3 和 reg2 都是 unsigned char  型的变量，并都初始化为零。
行索引（也就是for循环里的i）的取值范围为0~255，根据表2可以得出以下规律：


RP0只计算行索引的 Bit0 为0的行，RP1只计算行索引的Bit0为1的行；
RP2只计算行索引的 Bit 1为0的行，RP3只计算行索引的Bit1为1的行；
RP4只计算行索引的 Bit 2为0的行，RP5只计算行索引的Bit2为1的行；
RP6只计算行索引的 Bit 3为0的行，RP7只计算行索引的Bit3为1的行；
RP8只计算行索引的 Bit 4为0的行，RP9只计算行索引的Bit4为1的行；
RP10只计算行索引的 Bit 5为0的行，RP11只计算行索引的Bit5为1的行；
RP12只计算行索引的 Bit 6为0的行，RP13只计算行索引的Bit6为1的行；
RP14只计算行索引的 Bit 7为0的行，RP15只计算行索引的Bit7为1的行；

 

已经知道，异或运算的作用是判断比特位为1的个数，跟比特位为0的个数没有关系。如果有偶数个1则异或的结果为0，如果有奇数个1则异或的结果为1。
那么，程序第88行，对所有行校验为1的行索引按位异或运算，作用便是：

判断在所有行校验为1的行中，
属于RP1计算范围内的行有多少个------由 reg3 的Bit 0指示，0表示有偶数个，1表示有奇数个；
属于RP 3 计算范围内的行有多少个------由 reg3 的Bit  1 指示，0表示有偶数个，1表示有奇数个；
属于RP 5 计算范围内的行有多少个------由 reg3 的Bit  2 指示，0表示有偶数个，1表示有奇数个；
属于RP 7 计算范围内的行有多少个------由 reg3 的Bit  3 指示，0表示有偶数个，1表示有奇数个；
属于RP 9 计算范围内的行有多少个------由 reg3 的Bit  4 指示，0表示有偶数个，1表示有奇数个；
属于RP 1 1计算范围内的行有多少个------由 reg3 的Bit  5 指示，0表示有偶数个，1表示有奇数个；
属于RP1 3 计算范围内的行有多少个------由 reg3 的Bit  6 指示，0表示有偶数个，1表示有奇数个；
属于RP1 5 计算范围内的行有多少个------由 reg3 的Bit  7 指示，0表示有偶数个，1表示有奇数个；


所以， reg3 每个Bit位的作用如下表所示：
R eg3




第89行，对所有行校验为1的行索引按位取反之后，再按位异或，作用就是判断比特位为0的个数。比如reg2的Bit0为0表示：所有行校验为1的行中，行索引的Bit0为0的行有偶数个，也就是落在RP0计算范围内的行有偶数个。所以得到结论：


在所有行校验为1的行中，
属于RP0计算范围内的行有多少个------由 reg 2的Bit 0指示，0表示有偶数个，1表示有奇数个；
属于RP2计算范围内的行有多少个------由 reg 2的Bit  1 指示，0表示有偶数个，1表示有奇数个；
属于RP4计算范围内的行有多少个------由 reg 2的Bit  2 指示，0表示有偶数个，1表示有奇数个；
属于RP6计算范围内的行有多少个------由 reg 2的Bit  3 指示，0表示有偶数个，1表示有奇数个；
属于RP8计算范围内的行有多少个------由 reg 2的Bit  4 指示，0表示有偶数个，1表示有奇数个；
属于RP 1 0计算范围内的行有多少个------由 re g2的Bit  5 指示，0表示有偶数个，1表示有奇数个；
属于RP12计算范围内的行有多少个------由 reg2 的Bit  6 指示，0表示有偶数个，1表示有奇数个；
属于RP14计算范围内的行有多少个------由 reg2 的Bit  7 指示，0表示有偶数个，1表示有奇数个；


所以， reg2 每个Bit位的作用如下表所示：
R eg 2



至此，只用了一个查找表和一个for循环，就把所有的校验位 CP0 ~ CP5  和RP 0 ~ RP15 全都计算出来了。下面的任务只是按照表3的格式，把这些比特位重新排列一下顺序而已。
从 reg2 和 reg3 中抽取出  RP8~RP15 放在tmp1中，抽取出 RP0~RP7 放在tmp2中，
Reg1 左移两位，低两位置1，
然后把 tmp2, tmp1, reg1  放在 ECC码的三个字节中。

 

补充：

当Line5的Line Parity为1的时候，
首先最简单的理解，也是最直接的理解，那就是，要把所有RP0~RP14中，对应包含着此行的那些最后要计算的值找出来，
我们可以先手动地根据下图：

一点点，掰手指头，慢慢地写出来， 那就是：
RP1，RP2，RP5，RP6，RP8，RP10，RP12，RP14

换句话说，如果Line5的Line Parity为1的时候，
我们应该要计算RP1，RP2，RP5，RP6，RP8，RP10，RP12，RP14。
关于这点，我想大家没有什么好疑问的吧，因为这就是按照其规则的最简单，最通俗的理解。

所以，不论你用什么复杂的算法，反正是要记录并且计算这些RP的值，以便和后面的值进行计算。
但是，程序在此处，并没有将这些RP找出来，而只是直接对行号进行XOR异或：
reg3 ^= (uint8_t) i;

表面上看，这和我们要找出来，并计算的那些RP，并没啥关系，这也是我开始很困惑的问题。
按理来说，应该是找出那些行号，然后计算对应的RP的值，并保存，这样才对。

而此处之所以可以这么处理，主要是有以下原因：
1.        行与位的有如下对应关系：
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的行；

2.        某一行号的二进制分解的对应bit，对应了所要计算的RP：

比如是第6行，也就是Line5，5的二进制是：

Bit7	Bit6	Bit5	Bit4	Bit3	Bit2	Bit1	Bit0
0	0	0	0	0	1	0	1

5的二进制值
而根据上面别人分析出来的，行与位的对应关系，我们可以找出，此二进制的每一位所对应了哪些RP：
bit为1的位，分别是0，2，对应代表的是RP1，RP5
bit为0的位，分别是1，3，4，5，6，7，对应代表的是RP2，RP6，RP8，RP10，RP12，RP14
用表格表示为：

Bit7	Bit6	Bit5	Bit4	Bit3	Bit2	Bit1	Bit0
0	0	0	0	0	1	0	1
RP14	RP12	RP10	RP8	RP6	RP5	RP2	RP1

5的二进制值和二进制对应的行

上表中，比如bit2是1，而别人说了“RP5只计算行索引的Bit2为1的行”，
所以，此处如果bit2为1，对应着RP5将要被计算，
那么我们可以肯定地得出来的是，
如果此行，Line5，的Line Parity是1的话，RP5是要被计算的。
而仔细观察就会发现，RP5，就包含在我们上面自己手动找出来的那些LP中：
RP1，RP2，RP5，RP6，RP8，RP10，RP12，RP14
而，剩下的bit位，也依次对应着这些LP。比如bit0为1，对应RP1.

这就是我们上面说的“某一行号的二进制分解的对应bit，对应了所要计算的RP”
也是理解如此处理的关键点之一。

同样地，除了bit为1的bit0，bit2，对应的RP1，RP5之外，
剩下的几个bit对应的RP2，RP6，RP8，RP10，RP12，RP14，由于对应位是0，所以，即使拿过来抑或，也还是0，无法记住这些bit的值，所以，采用将其取反，这样，对应这些为0的bit，就变成1了，就可以记住这些对应的bit了：
reg2 ^= ~((uint8_t) i);

这样，当从0到255检测的过程中，如果发现某行的Line Parity是1，
那么就将其行号数值进行抑或，以存储奇数的LP，将行号取反，以保存偶数的LP，
也就是：
Reg3对应的就是RP1，RP3，RP5，。。。，RP15
Reg2对应的就是RP0，RP2，RP4，。。。，RP14

然后再调用函数nand_trans_result(reg2, reg3, ecc_code);去将reg3和reg2中存储的信息，
重新组织到ecc[1]和ecc[2]中去。

最后的感慨是：
此处仅仅是通过对行号的数值抑或，以保存所要求的各个RP的值，之所以让人很难理解：
一是由于我们之前不知道上面的那个规则：“行与位的对应关系”
二是我们不知道，行号按位分解后，对应的bit位对应着所要计算的那些RP，“某一行号的二进制分解的对应bit，对应了所要计算的RP”