自己写Tiny6410的Bootloader总结！

　　1、由于Tiny6410 2G版的Nand flash(K9GAG08U0E)的页大小是8K的，但是s3c6410芯片设置为nand flash启动时先从nand flash复制8K代码到片内内存中去，这个复制不是直接复制nand flash 的第0页的8K而是从前四页中分别取出2K代码到片内内存（这是硬件决定的，为了兼容所有nand flash）。所以友善之臂就使下载uboot到nand flash时每页只用前2K的空间而后面6K的空间装载的内容和前2K是一样的！而从nand flash 复制代码到sdram中去时只复制每页的前2K内容。（通过uboot命令读取nand flash的内容知道的）

　　Tiny6410 2G版的Linux内核存放在Nand Flash的地址为:  0x400000（1G版的地址为0x80000）

　　用SD卡烧写系统时会在nandflash上写一个bootargs（相当于cmdline）此地址为：0x200000（1G版的地址为0x40000）

　　BootLoader将内核复制到SDRAM中的地址为 ： 0x50008000

　　BootLoader向内核传递的tag参数在SDRAM中的位置为：0x50000100

　　S3C6410的机器码为 ：2520

　　BootLoader向内核传递的cmdline为：

　　root=/dev/mtdblock2 rootfstype=yaffs2 init=/linuxrc console=ttySAC0,115200 lcd=S70（Yaffs文件系统）

　　或root=ubi0:FriendlyARM-root ubi.mtd=2 rootfstype=ubifs init=/linuxrc console=ttySAC0,115200 lcd=S70（ubifs文件系统）

　　2、Tiny6410 2G版Nand flash K9GAG08U0E适合1KBytes/12 bit 硬件ECC校验，而6410 最大支持 512 Bytes/8 bit 硬件ECC校验，

　　所以S3C6410在硬件上根本就不支持K9GAG08U0E，然而为什么友善之臂的superboot为什么能成功启动系统？因为他们使用了软件和硬件结合的ECC校验算法，所以大部分情况下可以启动成功！但是这个软件算法友善之臂没有开源（理由是这个算法只有他们公司能够做到，哎，太小气了，建议初学者千万不要买这个版本），所以如果想在这块板子上跑自己的bootloader基本上是不可能成功启动整个Linux系统的，除非你够牛逼能够自己写出这个ECC算法！！

　　（这是花了我几天的时间得出的教训，即使你的的bootloader是对的，但是每次复制内核到SDRAM时都会出现各种各样的错误！而在1G版的Tiny6410上能正常运行！）

　　3、原来Uboot还可以通过命令读去S3C6410寄存器的值，只要用内存读取命令然后地址设为你要读的寄存器的值就行！

　　（这样调试就更加方便了！今天突然想到Uboot既然能读内存数据，为什么不能读寄存器的值了，然后我就试了一下，尽然成功了，哈哈！！）

　　4、Uboot 最终跳转到内存固定地址到Linux内核入口：

　　    void (*theKernel)(int zero, int arch, unsigned int params);  // 定义一个函数指针

　　    theKernel = (void (*)(int,int,unsigned int))0x50008000;     // 将函数指针赋值为内存地址 0x50008000 

　　    theKernel(0,2520,0x50000100);//go to linux kernel           // 跳转到 0x50008000 运行

　　5、当一切问题都解决后，我的Uboot终于能够启动Linux内核后，能够运行Linux的shell程序了，但是当我执行例如 cp mv 等这种需要分配内存才能执行的命令时候，会出现提示说不能分配内存，并且命令执行失败，这个问题是几个月后我在看书的时候突然知道了到底是什么原因出现这种情况的：所有需要动态分配的内存空间都是在堆中分配的，操作系统中的内存管理模块在初始化时，需要知道它所管理的内存空间的起始地址是什么，这需要通过连接脚本的配合来获取，连接脚本的__end__符号就是表示堆的开始地址，堆的结束地址是内存的剩余所有空间。

就是因为我在写连接脚本的时候没有__end__这个符号，所以操作系统不知道从哪里分配内存！