nand flash与烧录器

总结一下关于烧录器与nand的情缘

记得上家公司，每发生产版本，测试完后，都需要将flash拆下来，用烧录器读出里面的内容

后面的生产都要用这个文件来烧录

同样的，在这家公司，每当uboot改动发新版本后，都需要先用仿真器将ram版uboot带起来，再通过tftp将nand uboot

down下来，用命令nand write将uboot写入nand，将芯片拆下来，使用烧录器读出，读出的文件还要再用烧录器烧进芯片进行验证

这个过程相当复杂，不断拆焊芯片，而且烧录器有时候不稳定，读出的文件会有问题。

这么复杂的过程，看上去就很不合理，为什么不能直接用烧录器将nand uboot烧入nand flash呢

做了如下实验

1.将uboot-nand.bin直接烧入nand，板子上电起不来

将flash内容读出，uboot-read1.txt,与uboot-nand.bin对比，基本相同

2.将uboot-nand.bin通过仿真器BDI3000带起的uboot，然后通过uboot命令行nand write将uboot-nand.bin写入flash

板子上电可以起来，读出flash的内容如下,uboot-read2.txt（其中的一个页），可以看到最下面部分，比uboot-nand.bin多出了129-132这4行

27 05 19 56 55 2D 42 6F 6F 74 20 33 20 2E 30 31-----------------1
20 20 28 44 65 63 20 30 39 20 32 30 31 35 20 2D-----------------2
20 31 30 3A 35 35 3A 35 32 29 00 00 00 00 00 00-----------------3
3C 20 FF D0 60 21 3F 90 38 00 00 00 94 01 FF FC
94 01 FF FC 94 21 FF F8 3C 00 FF FF 60 00 FF FC
94 21 FF F8 90 01 00 0C 48 00 00 05 7D 88 02 A6
80 0C 01 D8 7D 80 62 14 48 00 02 49 3C 60 00 02
60 63 12 00 7C 60 01 24 4C 00 01 2C 48 00 02 A9
48 00 06 CD 4C 00 01 2C 7C 70 9B A6 7C 91 9B A6
7C B2 9B A6 7C D3 9B A6 7C F0 EB A6 38 60 00 00

7D 6B 01 D6 60 84 20 00 81 3E 80 00 3C 60 FF E0
60 63 45 00 3F 80 FF E0 7C 8B 23 96 91 69 00 00
3F A0 FF E0 63 9C F0 00 63 BD F0 08 3F 60 00 20
3B 40 00 00 48 00 02 09 80 7E 80 04 4B FF FD 71
3D 20 FF E0 61 29 F0 04 3C 00 02 20 38 60 03 E8
90 1C 00 00 93 69 00 00 93 5D 00 00 48 00 03 A5
93 7D 00 00 38 60 03 E8 48 00 03 99 93 5C 00 00-------------------128
FF FF FF FF FF FF FF FF 65 A6 6A FF FF FF FF FF-------------------129
FF FF FF FF FF FF FF FF C0 33 33 FF FF FF FF FF-------------------130
FF FF FF FF FF FF FF FF FF 30 F0 FF FF FF FF FF-------------------131
FF FF FF FF FF FF FF FF CC F3 FF FF FF FF FF FF-------------------132

我们使用的K9K8G08U0B flash，datasheet里面介绍的组织存储是这样的

每一个页是由2048B+64Byte组成的，再看uboot-read.txt的第一页

128*16+4*16

=2048+64

正好吻合，这个64B的区域叫做OOB area。

NAND flashes store per-NAND page ECC codes in the OOB area,which means that whole NAND page has to be written at once to calculate the ECC code,and whole NAND page has to be read at once to check the ECC code.

nand flash将每一个页的ECC（错误检查和纠正）码存储在OOB区域，这就意味着每次写入必须以一个nand 页的形式并计算出ECC码，每次读必须以一个nand页的形式并检查ECC码。

很明显，直接将软件编译出来的uboot-nand.bin是不包含ECC码的，通过烧录器写入nand，cpu读取的时候找不到ECC，导致无法正确load data

关于ECC是有一个比较复杂的算法的，一开始，我以为是与nand相关，后来与烧录器厂家联系，说是跟cpu相关

其实不用考虑这些问题

排除硬件或cpu nand控制器实现ECC的可能，还有一种就是软件来实现的，目前ECC校验使用软件来校验的比较多

通过uboot中nand write将uboot-nand.bin写入nand时，烧录器读出是带有ECC的，

而使用烧录器将uboot-nand.bin写入nand，烧录器读出是不带ECC的

nand write命令可能带有ECC码的算法，于是追踪nand write命令的实现

入口：

U_BOOT_CMD(
nand,CONFIG_SYS_MAXARGS,1,do_nand,

...

}

函数：

int do_nand(cmd_tbl_t * cmdtp,int flag,int argc,char * const argv[])
{

if (read)
ret = nand_read_skip_bad(nand,off,&rwsize,?(u_char *)addr);
else
ret = nand_write_skip_bad(nand,?(u_char *)addr,0);

｝

intnand_write_skip_bad(nand_info_t *nand,loff_t offset,size_t *length,

???????????????????? u_char *buffer,int flags)

{

???????????????????? for (page = 0; page <pages; page++) {

??????????????????????????? rval =nand->write_oob(nand,offset,&ops);

???????????????????? }

最后调用了write_oob将oob信息写入flash，中间省去了ECC码的生成算法，这一块内容较多，将会专门写一篇文档

一开始的想法是提取这个算法，写一个工具，或者通过nand命令行将oob读出来，

Uboot下有命令=> nand dump 0可将flash page页和oob一起打印出来

Page 00000000 dump:

???????27 05 19 56 55 2d 42 6f? 6f 74 2033 20 2e 31 30

???????20 20 28 44 65 63 20 31? 37 20 3230 31 35 20 2d

???????20 31 37 3a 32 36 3a 32? 30 29 0000 00 00 00 00

??? ????….

???????3d 20 ff e0 61 29 f0 04? 3c 00 0220 38 60 03 e8

???????90 1c 00 00 93 69 00 00? 93 5d 0000 48 00 03 a5

???????93 7d 00 00 38 60 03 e8? 48 00 0399 93 5c 00 00

OOB:

???????ff ff ff ff ff ff ff ff

???????5a a6 56 ff ff ff ff ff

???????ff ff ff ff ff ff ff ff

???????c0 33 33 ff ff ff ff ff

???????ff ff ff ff ff ff ff ff

???????ff 30 f0 ff ff ff ff ff

???????ff ff ff ff ff ff ff ff

???????cc f3 ff ff ff ff ff ff

但因命令行限制，不能将所有oob打印出来，即使修改命令行，将全部oob取出，也不容易导出到PC，毕竟不是在linux中，可以以将信息文件的形式来导出。

想到这里，我便查找busybox的命令行，而且找到了一个命令，nanddump，可以将mtd分区信息导出到文件。

在kernel中，通过如下命令

[root@Huahuan:/root]#cat /proc/mtd

dev:??? size??erasesize? name

mtd0: 00080000 00020000 "u-boot"

mtd1: 00020000 00020000"u-boot-env"

mtd2: 3a000000 00020000 "ubifs"

mtd3: 05f60000 00020000"reserved"

?

[root@Huahuan:/root]#nanddump -fuboot.bin? /dev/mtd0

?

可将uboot分区mtd0全部导出

导出的文件与uboot下通过命令打印出来的oob信息完全一致，由此判断导出的文件可作为烧录文件，后面使用烧录器烧录也证实了这一判断