标题的意思简单的而说，其实就是搞清楚superboot210将boot.bin,kernel和根文件系统分别下载到了什么地方。
首先看一下内核的启动信息? （superboot210.bin + linux3.0.8），其中有这么一段：
[??????????? ] S3C NAND Driver is using hardware ECC.
[??????????? ] NAND device: Manufacturer ID: 0xec,Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
[??????????? ] Creating 5 MTD partitions on "s5pv210-nand":
[??????????? ] 0x0000000c0000-0x000000100000 : "misc"
[??????????? ] 0x000000100000-0x000000600000 : "recovery"
[??????????? ] 0x000000600000-0x000000b00000 : "kernel"
[??????????? ] 0x000000b00000-0x000000e00000 : "ramdisk"
[??????????? ] 0x000000e00000-0x000020000000 : "system"
这是在内核当中的分区信息，通常情况下，对于一个追求完美的程序员来说，最好将内核的分区信息和uboot当中的分区信息设置一致，毕竟看起来更舒服一些。但是实际上来说，只要内核的根文件系统的分区和uboot的对应的下载根文件的地址一致即可。这是由启动参数（又叫环境变量）bootargs决定的，开发板提供的这个参数值为：
bootargs=root=/dev/mtdblock4 rootfstype=yaffs2 console=ttySAC0,115200 init=/linuxrc androidboot.console=ttySAC0 skipcali=yes ctp=2
可以看出，根文件系统被放在了mtdblock4的分区上，也就是第4+1个分区，即上面的system分区。
所以从上面的启动信息来看，最后一项system分区肯定是正确的，但是以上四个是正确的吗？在我看来，至少第一个分区就错了，"misc"分区肯定是用来存放boot.bin，这是由ARM启动过程BL0决定的，但是boot.bin一定要放在0x00的位置，上面的启动信息居然是从c0000开始的，这是开哪门子国际玩笑。只有一种解释，这个分区信息和uboot真正的分区信息并不完全对应。
?????? 那么"kernel"分区是否对应呢？我们知道，uboot想要引导内核，首先就要从nand flash中将内核读入到SDRAM里，如果我们连kernel存放在nand flash的哪个位置都不知道的话，那根本就没有必要去尝试引导了。
????? 首先在uboot的命令行模式下输入：
? ? ? nand read 0x20000000 0x600000 0x10000
? ?? 然后便出现了网上流传很广的那个错误：
? ? ?NAND read from offset 600000 failed -74
? ? ? 0 bytes read: ERROR
???? 这说明，在0x600000那个位置里，我们没有读出数据来。其实数据已经读出来了，不信可以用md 0x20000000看一下。发生这样的错误原因应该是我自己的uboot使用的ecc机制和superboot210使用的ecc机制不一致造成的。本来我就是想看看kernel在不在0x600000那里，却又引出来一个ecc的问题，挺闹心的。干脆ecc我先放一放，等先确定好内核位置后再着重搞定ecc。但是话又说回来了，这个错误反而给我提供了思路来追终kernel的真正位置。
? ? ? 接下来我先在uboot中执行nand flash擦出工作。
????? nand srcub.chip
???? 完全擦除nand后，uboot就可以随意正确读取nand flash上的任何位置的数据了。当然读出来的数肯定都是ff ff ff ff ，类似与下面的样子
[ZBL210]# nand read 0x20000000 0x200000 0x800
NAND read: device 0 offset 0x200000,size 0x800
?2048 bytes read: OK
[ZBL210]# md 0x20000000
20000000: ffffffff ffffffff ffffffff ffffffff??? ................
20000010: ffffffff ffffffff ffffffff ffffffff??? ................
20000020: ffffffff ffffffff ffffffff ffffffff??? ................
20000030: ffffffff ffffffff ffffffff ffffffff??? ................
20000040: ffffffff ffffffff ffffffff ffffffff??? ................
20000050: ffffffff ffffffff ffffffff ffffffff??? ................
20000060: ffffffff ffffffff ffffffff ffffffff??? ................
20000070: ffffffff ffffffff ffffffff ffffffff??? ................
20000080: ffffffff ffffffff ffffffff ffffffff??? ................
20000090: ffffffff ffffffff ffffffff ffffffff??? ................
200000a0: ffffffff ffffffff ffffffff ffffffff??? ................
200000b0: ffffffff ffffffff ffffffff ffffffff??? ................
200000c0: ffffffff ffffffff ffffffff ffffffff??? ................
200000d0: ffffffff ffffffff ffffffff ffffffff??? ................
200000e0: ffffffff ffffffff ffffffff ffffffff??? ................
200000f0: ffffffff ffffffff ffffffff ffffffff??? ................
而当我将kernel下载到nand flash当中后，假如我读到了kernel的数据，这时候就会显示错误，就是用这种笨方法，我终于确定了superboot210将kernel实际下载到了0x40000~0x900000的位置。
接下来确定一下uboot将环境变量下载到哪了呢。这个可以直接从uboot源码中找到这样一个宏定义
#define CONFIG_ENV_OFFSET?????????????? 0x100000
这个宏定义就是说，当我们在uboot中使用save命令的话，它会将程序当中的环境变量保存到nand flash的0x100000的位置上。
所以现在基本上可以确定分区了
0~1M?? bootloader
1M~4M?? parameters
4M~9M? kernel
9M~14M? ramdisk
14M~???? rootfs
接下来，重点解决uboot读取内核的ecc问题。
