今天把u-boot,linux,yaffs2文件系统的移植全部搞定了，在我的mini2440板子上跑起来了，呵呵，兴奋啊！现在回头看看自己花了这么长时间所作的工作，结论就是，只要坚持下去就一定会成功的。
下面就把我移植过程中的步骤记录下来，留着以后看看，也许还会用到的。
先是u-boot部分：
我用的是
开发环境：fedora 14
开发板：mini2440 256M NandFlash 64M SDRAM
交叉编译器：arm-linux-gcc 4.4.3
BusyBox版本：busybox-1.7.0
yaffs制作工具：mkyaffsimage
yaffs2制作工具:mkyaffs2image（适合64M）、mkyaffs2image-128（适合128M以上，我的256M的用这个）
对于u-boot的修改有很多，参考了韦东山大神写的那本《嵌入式Linux应用开发完全手册》一步步做的，建议这部分大家也都自己动手做做，会有不少收获，对于那种文件的树形结构分布，程序设计的能力都会有很大的提高。
当u-boot移植能够在板子跑了，在看下面内容：
我一直困惑在MTD那部分，对于NAND flash分区那一直不是很清楚，先看我现在的mtd分区：
Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
0x000000000000-0x000000500000 : "kernel"
0x000000500000-0x000000d00000 : "jffs2"
0x000000d00000-0x000010000000 : "yaffs"
我创建了3的分区，分别作为 uImage,jffs2,yaffs2文件存放的地址，在u-boot运行后，使用tftp下载kernel及文件系统到内存，接着写入flash中，具体如下：
tftp 0x31000000 uImage
nand erase 0 0x500000
nand write.jffs2 0x31000000 0 0x300000
要注意的是，这里写到flash中的地址对应着我们的MTD分区表地址，我的0地址处存放的是kernel，所以下载到0地址处。
static struct mtd_partition friendly_arm_default_nand_part[] = {
[0] = { .name = "supervivi", .size = 0x00040000, .offset = 0, },
[1] = { .name = "param", .offset = 0x00040000, .size = 0x00020000, },
[2] = { .name = "Kernel", .offset = 0x00060000, .size = 0x00500000, },
[3] = { .name = "root", .offset = 0x00560000, .size = 1024 * 1024 * 1024, },
[4] = { .name = "nand", .offset = 0x00000000, .size = 1024 * 1024 * 1024, }
};
这是之前的mtd分区，修改后如下：(在 arch/arm/mach-s3c2440/mach-mini2440.c中)
static struct mtd_partition friendly_arm_default_nand_part[] = {
[0] = { .name = "kernel", .size = 0x00050000, .offset = 0, },
[1] = { .name = "jaffs", .offset = MTDPART_OFS_APPEND, .size = 0x00080000, },
[2] = { .name = "yaffs", .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL,
}
};
当然在写入flash之前最后先下载到内存里跑一下，看能否运行，不然来回擦除flash太费事，而且也有损于它。
使用：
tftp 0x32000000 uImage bootm 0x32000000
看看能不能打印出这句：
Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
0x000000000000-0x000000500000 : "kernel"
0x000000500000-0x000000d00000 : "jffs2"
0x000000d00000-0x000010000000 : "yaffs"
如果可以那说明这一步实现了。由于开发板上还没有写入文件系统，也没有设置nfs挂接网络文件系统，所以内核启动后还会出现panic信息。不急， 我们下一步来解决它。 在这之前，先解释一下几个概念：
1.uImage
使用 make uImage编译 我们编译linux结束后会在arch/arm/boot/目录下生成zImage,uImage内核文件，这有什么区别呢？ 之前一直没有去研究他们，现在明白了，简单的说一下区别： uImage是U-boot专用的映像文件，它是在zImage之前加上一个长度为0x40的tag。vmlinuz是bzImage/zImage文件的拷贝或指向bzImage/zImage的 链接。initrd是“initialramdisk”的简写。一般被用来临时的引导硬件到实际内核vmlinuz能够接管并继续引导的状态。 vmlinux是内核文件，zImage是一般情况下默认的压缩内核映像文件，压缩vmlinux，加上一段解压启动代码得到，只能从0X0地址运行。 uImage是u-boot使用bootm命令引导的Linux压缩内核映像文件格式，使用工具mkimage对普通的压缩内核映像文件（zImage）加工而得。 可以由bootm命令从任意地址解压启动内核。由于bootloader一般要占用0X0地址，所以，uImage相比zImage的好处就是可以和bootloader共存。 当我们使用ls -l 查看这两个文件大小时会发现，uImage比zImage大了64字节，也就是多了0x40长度的tag.
2.bootm
下载到内存后，使用bootm引导uImage,那为什么不用go命令呢？ 原因是，我们上面所说的多出64字节的uImage,bootm你可以把它理解为专为它引导的命令。go命令是用来跳转的二进制可执行文件的命令。这些，我们 在mini2440裸机开发那想必大多数人都接触过，不再细说了!
3.MTDPART_OFS_APPEND
是代表着接着上一个分区地址向下分区，offset偏移。
4.MTDPART_SIZ_FULL flash
分区剩下的所有大小空间都分配出去。
接着上面说的，写入flash后，保存引导参数。我这里是在u-boot中代码固定的。
#define CONFIG_BOOTDELAY 5
#define CONFIG_BOOTARGS "noinitrd root=/dev/mtdblock2 init=/linuxrc console=ttySAC0"
#define CONFIG_ETHADDR 08:00:3e:26:0a:5b
#define CONFIG_NETMASK 255.255.255.0
#define CONFIG_IPADDR 192.168.1.230
#define CONFIG_SERVERIP 192.168.1.10 /*#define CONFIG_BOOTFILE "elinos-lart" */
#define CONFIG_BOOTCOMMAND "nboot 0x31000000 0 0; bootm 0x31000000"
这样开机后,不打断便可进入kernel。
下一节介绍文件系统部分！
)
