提供了：u-boot for tiny210v2 ,源代码回复可见。

本部分内容设定了隐藏,需要回复后才能看到

开发板：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<num; i++)
    {
        buf[subst] ^= pattern;
//        printf("%02X\t", 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’）  

[ 此帖被kangear在2013-06-27 17:17重新编辑 ]

呵呵，今天发一个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)
首先你的NandFlash的型号要是上边写的型号，不一样的可不行。不是同一块开发板就一定是同一块NandFlash。看看tiny210v2的淘宝首页的通知：

tiny210v2这个Flash型号是一直在换，这个u-boot可以只是极少数人能用了。
先提供一个不做ECC校验的：
tiny210v2-uboot.bin (242 K) 下载次数:45
烧写方法如图所示（只提供关键步骤）：

下边是启动截图：  

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

经过ECC校验的u-boot for tiny210v2
tiny210v2-uboot.bin (242 K) 下载次数:67
烧写方法和上边的一样，下边是启动截图：
  
 

“ECC OOB BBT”是指坏块管理了，你指的这种管理方法也是程序实现的，我还没有去了解u-boot对这方面的模型是什么。
ECC也是自己裸机实现的，如果去做BBT也会先用裸机实现一下，看硬件工作原理是什么。
可以先了解Superboot是怎么管理坏块的，然后结合裸机来实现一下。如果你直接在u-boot上去移植我觉得反倒不好，因为硬件和u-boot的BBT模型都没有太清楚会没有头绪。我现在没有这方面的需求，暂时没有做这个的打算。以做的话会发贴。

关于uboot for tiny210v2 请关注这个帖子：http://www.aiothome.net/read.php?tid-80476.html

很感谢你能发表你的意见，我好好研究再详细回复。

正在移植，请关注这里：http://www.aiothome.net/read.php?tid-80476.html

ErrByteLoc我仔细看了一下，确实应该是10位：

这个没有什么秘密，就是我算错了，算成了9位，悲哀。估计我最后得出那个“递增”的思想就不一定说的准了。估计也不需要递增了！就是没有修正完！

另外你说的“这个ECC引擎，不仅用来纠正数据错误，也用来纠正ECC错误”确实没有注意到，我还以为人工配置一下oob的ECC，才能保证ECC校验码不会出错。解开了我很多谜团。您是第一个用心分析源码的人，向您致敬！
根据你所说的，我可能在代码上要做如下纠正：
1.0x1ff 改为 0x3FF
2.去掉数组递增验证
3.友善的淡定码也有了新的理解，应该是用来标注坏块的。


感谢你的纠正！
这里会有BL1的最新进展，欢迎您的关注！
https://github.com/kangear/tiny210v2-uboot

480多参与校正 ，我也这样测试过。

感谢分享！我测试一下。