2020年03月31日 | S5PV210的16bit硬件ECC校验

说明：本文是以前研究的“S5PV210的16bitECC校验”写的一系列的帖子，原帖发在了这里。再用博客记录一下。

开发板：tiny210v2

NandFlash：K9GAG08U0F

网上的针对这个板子的u-boot大多都不太好用，很多都是启动的时候从NandFlash往DRAM中拷贝没有进行ECC校验，导致只能启动不完整。

就决定自己做BL1代码，初始化DRAM了什么的都可以从u-boot中提取，没有什么区别。

BL1有代码主要是实现ECC16bit校验，具体用的什么算法，我到目前还不清楚，但是我已经实现了Main区的校验。因为S5PV210的手册上都是傻瓜式的，按照它的做就完全可以实现校验。主要说明步骤在这里：

数据手册转换为代码：

测试方法是制作一个里边全是‘A’的bin文件，贴到上边的代码的后边。这个用MiniTools+SuperBoot以下载bootloader的方法下载此程序的时候，这个bin文件会被下载到第4页的地方，然后我的程序从第4页开始拷贝，拷贝到内存中并打印出来。

这中间的拷贝就用了16bit，ECC校验的方式进行读取的。从下图的第4页的OOB区的内容可以推测出来，SuperBoot是怎么放置这些校验码的：

根据这些校验码的位置，和上边三星提供的步骤，得出了上边的代码。

下面实例分析一下出现一位翻转的情况：

Main区的修改函数是按照三星提供的第4步进行写的：

/*

* 修复Main区的反转位

*

*/

int fixEcc(uchar* buf, int num, int flag)

{

    uint subst[16];

    uchar pattern[16];

    int i = 0;

    // 数组赋值为0

    for(i=0; i<16; i++)

    {

        subst=pattern=0;

    }

#if 1

    subst[0] = (NFECCERL0_REG>>0) & 0x1ff;

    pattern[0] = (NFECCERP0_REG>>0) & 0xff;

    subst[1] = (NFECCERL0_REG>>16) & 0x1ff;

    pattern[1] = (NFECCERP0_REG>>8) & 0xff;

    subst[2] = (NFECCERL1_REG>>0) & 0x1ff;

    pattern[2] = (NFECCERP0_REG>>16) & 0xff;

    subst[3] = (NFECCERL1_REG>>16) & 0x1ff;

    pattern[3] = (NFECCERP0_REG>>24) & 0xff;

    subst[4] = (NFECCERL2_REG>>0) & 0x1ff;

    pattern[4] = (NFECCERP1_REG>>0) & 0xff;

    subst[5] = (NFECCERL2_REG>>16) & 0x1ff;

    pattern[5] = (NFECCERP1_REG>>8) & 0xff;

    subst[6] = (NFECCERL3_REG>>0) & 0x1ff;

    pattern[6] = (NFECCERP1_REG>>16) & 0xff;

    subst[7] = (NFECCERL3_REG>>16) & 0x1ff;

    pattern[7] = (NFECCERP1_REG>>24) & 0xff;

    subst[8] = (NFECCERL4_REG>>0) & 0x1ff;

    pattern[8] = (NFECCERP2_REG>>0) & 0xff;

    subst[9] = (NFECCERL4_REG>>16) & 0x1ff;

    pattern[9] = (NFECCERP2_REG>>8) & 0xff;

    subst[10] = (NFECCERL5_REG>>0) & 0x1ff;

    pattern[10] = (NFECCERP2_REG>>16) & 0xff;

    subst[11] = (NFECCERL5_REG>>16) & 0x1ff;

    pattern[11] = (NFECCERP2_REG>>24) & 0xff;

    subst[12] = (NFECCERL6_REG>>0) & 0x1ff;

    pattern[12] = (NFECCERP3_REG>>0) & 0xff;

    subst[13] = (NFECCERL6_REG>>16) & 0x1ff;

    pattern[13] = (NFECCERP3_REG>>8) & 0xff;

    subst[14] = (NFECCERL7_REG>>0) & 0x1ff;

    pattern[14] = (NFECCERP3_REG>>16) & 0xff;

    subst[15] = (NFECCERL7_REG>>16) & 0x1ff;

    pattern[15] = (NFECCERP3_REG>>24) & 0xff;

#endif

    if(flag)

    {    

        for(i=0; i<512; i++)

        {

            puthex(buf);

            putc(' ');

        }

    }

    putc('n');putc('r');

    for(i=0; i    {

        buf[subst] ^= pattern;

//        printf("%02Xt", buf[subst]);

        if(flag)

        {    

            put32bits(subst);putc(' ');puthex(pattern);

            putc('n');putc('r');

        }

    }

    if(flag)

    {    

        for(i=0; i<512; i++)

        {

            puthex(buf);

            putc(' ');

        }

    }

    putc('n');putc('r');

    return 0;

}

其实到这里已经完整的实现了Main区的16bit的ECC校验，但是还有一个问题是校验码也是从NandFlash中读取的，校验码也会发生翻转，这就需要进行数据手册上的第6步检验SPACE区的ECC。

下边给一下ECC码也发生的翻转的实例：

同样是全是‘A’，这个校验码读错了，造成原来对的就会改成了错误的(高亮那Byte正确的应该是‘03’)。

（可以看到它把原来的第6Byte的‘AA’，根据错误的校验码改成了‘BA’）  

分析一下tiny210v2的16bitECC校验(说说OOB)

呵呵，今天发一个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

（陈孝正的“我的人生是一栋只能建造一次的楼房，我必须让它精确无比，不能有一厘米差池”，看来我要研究一下这一厘米的差池是从哪里来的，下次解决它！）

u-boot for tiny210v2 (NandFlash:K9GAG08U0F)

是在《分析一下tiny210v2的16bitECC校验》基础上得到的结果。

网上的针对这个板子的u-boot大多都不太好用，很多都是启动的时候从NandFlash往DRAM中拷贝没有进行ECC校验，导致只能启动不完整。就决定自己做BL1代码,BL1有代码主要是实现ECC16bit校验,u-boot并没有做移植，直接采用论坛里边http://arm9home.net/read.php?tid-28771.html提供的。

先提供一个不做ECC校验的：

 tiny210v2-uboot_no_ecc.bin (242 K) 下载次数:1 

烧写方法如图所示（只提供关键步骤）： 

下边是启动截图：  

温馨提示，由于没有进行ECC校验，优点是启动快，但会经常出现这样的情况： 

经过ECC校验的u-boot for tiny210v2 版本：130609

bin文件和源代码：

bin文件： tiny210v2-uboot.bin (242 K) 下载次数:4 

源代码：  uboot_for_tiny210v2Ver130609.tar.gz (130 K) 下载次数:7

烧写方法和上边的一样，下边是启动截图：

最大的问题莫过于启动慢的问题了，现在看来是我在NandFlash读数据时候采用的是1Byte 1Byte有读取的，因为是ECC校验。我再看一遍NandFlash手册应该会有更好的方法。

================================================我是分割线====================================================

冷静分析一下问题后，发现问题并不难，就着手改了。

很快就移植好了，速度提升的10倍，现在3秒就能够启动了。

（130610版本）bin文件和源代码：

 tiny210v2-uboot.bin (242 K) 下载次数:7  uboot_for_tiny210v2Ver130610.tar.gz (130 K) 下载次数:14

=================================================================================================================

20130625更新：

整理了一下代码结构，更清晰：

http://download.csdn.net/detail/kangear/5648661

==================================================================================================================

2013-06-27更新：

当我对NandFlash的ECC校验和从NandFlash拷贝以及SD卡拷贝了如指掌后，就想着手实现将这些东西移植到u-boot中。经过简单的移植后，从SD卡启动没有一点问题。但是从NandFlash就不行，启动半截。用我以前的BL1.bin和u-boot.bin拼到一起。在NandFlash的启动也一样成功。我就推导出u-boot.bin是没有问题的。就定位到了spl中的nand_cp.c。我暂时不能确定是怎么回事，就用对比我自己的“BL1.bin”和这个启动的区别。不曾想看到一点区别，当时没有看重它，但是就是它的问题。就是我自己的“BL1.bin”中是没有提升主频的,启动时打印的是400MHz。新移植好的tiny210v2-u-boot.bin中显示的是1000MHz。如下红色部分，原来是200，这样频率提升了，相对的延时时间也就变短了。 提升后。id获取失败的情况就没有见到了。这个问题是我以前未曾考虑过的。

    NAND_CONTROL_ENABLE();

    NAND_ENABLE_CE();

    NFCMD_REG = NAND_CMD_READID;

    NFADDR_REG =  0x00;

    /* wait for a while (此时主频已经1GHz了延时扩大了5倍)*/

    for (i=0; i<1000; i++);

    id = NFDATA8_REG;

    id = NFDATA8_REG;

    if (id > 0x80)

        large_block = 1;

    if(id == 0xd5)

    {

        //page_size = 8k

        large_block = 3;

    }