u-boo在S3C2440上的移植问题及解决方法集锦(一).docVIP

u-boot在S3C2440上的移植问题及解决方法集锦（一） 一、移植环境 主 机：VMWare6.5--Fedora 9 开发板：自制开发板 CPU：S3C2440； SDRAM：HY57V561620FTP-H； NOR flash：SST_39VF1601（2M）； NAND flash：K9F1G08U0B（128M）； 网卡芯片：DM9000EP 编译器：arm-linux-gcc-4.3.2 u-boot：u-boot-2009.08 linux kernel：linux-2.6.30 busybox：busybox-1.13.3 二、博客地址 HYPERLINK /liuqiqi677/liuqiqi677 如有错误，欢迎指正。 三、参考资料 主要参考了黄刚的博客HYPERLINK /u3/101649//u3/101649/ ，他的博客写得相当不错，将嵌入式开发各个阶段的知识以边做边学的方式，辅以图片、解释，清晰地呈现给读者，能够让读者把握主线，对嵌入式开发有整体的了解。强烈推荐！！！  四、问题及解决方法 1、NAND flash（K9F1G08U0B）的寻址方案 开始照着黄刚的博客进行u-boot移植，u-boot从NOR flash启动比较顺利，但是从NAND flash启动时，就遇到问题了，u-boot不能完全启动！通过在程序中插入点led灯的方法，将问题定位在了NAND flash的读取函数nand_read_ll中对NAND flash单元进行寻址的几条指令上。这时，问题大概有眉目了，黄刚所用的开发板是友善之臂的mini2440，上面的NAND flash的型号是K9F1208，容量为64M，与我所用的芯片不一样。下面比较一下这两款芯片的寻址方案： 图1 K9F1208寻址方案 图2 K9F1G08寻址方案 黄刚博客中K9F1208的寻址代码是： NFADDR = i 0xFF; NFADDR = (i 9) 0xFF; NFADDR = (i 17) 0xFF; NFADDR = (i 25) 0xFF; 而我的K9F1G08的寻址代码则是： NFADDR = 0; NFADDR = 0; NFADDR = (i 11) 0xFF; NFADDR = (i 19) 0xFF;  NFADDR = (i 27) 0xFF; 但是，这里又出现三个问题了：（1） K9F1G08的寻址方案只有4个周期，而我的代码却有5个周期；（2） 为什么前两个周期我给的值都是0；（3） 按照芯片手册，第3-5个周期起，移位操作应该分别为(i 12)、(i 20)、(i 28)，那为什么却是上面那样的呢？一开始，我也是挺纳闷的，但是通过查找资料与不断试验，终于弄懂了这些原因。 （1） 5个周期主要是为了兼容NAND flash容量大于128M的芯片。下面贴上K9F2G08的寻址方案，可以看出，它有5个寻址周期。而我们的K9F1G08在执行寻址代码的时候，会忽略掉周期大于4的部分，也就是说，只有前面4个周期才是有效的，才是它用来寻址的，第5个周期的数据就算写给它了，它也不会拿去用。 图3 K9F2G08寻址方案 （2） NAND flash进行读操作是以页为单位，前2个周期的值表示页内偏移量，因此，前两个周期传给NAND flash的值为0，表示读操作是从每页的起始单元（及页内偏移量为0）开始的。 （3） 这个问题纠结了半天，按照芯片手册，K9F1G08一页的大小是2KB，A0 --A10 就刚好能够完全寻址了。那么，这个A11 又是干什么的呢？网上有一种说法，NAND flash的每一页除了2KB的数据区，还有64 Bytes的OOB数据，这样每一页就有2112 Bytes的单元，A0 --A10 就不够了，而A0 --A11 能够寻址的单元数是4096，能够包含这64 Bytes的OOB数据。但是，我试过将偏移量改成(i 12)、(i 20)、(i 28)，但是这样无法读出NAND flash中的数据，那么，这种说法是站不住脚的。网上还有一种说法，OOB数据是用另外的指令去读的，而芯片手册上可能是三星公司的笔误，虽然这种说法看似可能性较小，但是我觉得这个是目前为止解释最合理的一种，大公司也难免会有失误嘛。 2、将