Welcome to Kision

导读：
　　
　　目标板要更新成2.6的内核,以前板子vivi上的flash分区不合理,kernel分区只有1M的空间,而2.6的核编译出来一不小心就会超过1M,因此还是研究下vivi的flash分区,增大kernel分区.
　　这里先转发一下网络上看到的有关vivi分区问题分析,然后整理出自己的分区过程.
　　问题：
　　##################################################################################
　　您好:
　　看了你blog上的一篇文章,我是刚接触NAND flash分区的问题,所以请教与你.
　　flash分区一般分为5个:
　　bootloader,param,kernel,root,usr
　　这几个分区对应应该是mtdblock/0到mtdblock/4对吧?我常见到的bon/x又什么呢?他和mtdblock有啥关系讷?然后就是这几个分区对应的文件系统,我一般是在root烧cramfs,前四个分区32M,64Mflash后面的32M还没用,cramfs是个只读的,那这个yaffs又是怎么回事?网上说的cramfs和yaffs一起使用又是怎么回事?你说的后面几个分区以yaffs制作文件系统,怎么制作啊?
　　谢谢,我才开始, 对这些有点迷惑.谢谢你的帮助.
　　##################################################################################
　　回答：
　　##################################################################################
　　你好，
　　首先申明我的理解仅限于参考（我也很菜的说，^_^）。
　　1、>>flash分区一般分为5个
　　这个理解是不对的，至少不完全对。flash想分成几个区完全由于你自己的需要决定，然后在make menuconfig时间进行配置。
　　2、>>bootloader,param,kernel,root,usr
　　这个和上面的问题有关系，不过个人觉得你的理解还是有点问题。一般来说param不会单独去占一个分区（如果你的param是指内核启动参数的话），这个一般都是在编译内核时间就已经指定了，会放在内核image的较前位置，内核自解压的时候检测到并使用。而root与usr我不知道你的理解是什么，我的概念里不需要这样分，直接将文件系统使用yaffs或者cramfs或者jffs等使用即可，干嘛区分root和usr呢？一般我们把文件系统部分分到几个不同的flash分区存放是为了方便，但是最后使用的时候是感觉不出来的，因为逻辑上他们都回挂到根分区的某一个目录上，所以看起来和将所有的东西打成一个包挂在根下是一样的。举个例子。
　　使用三个分区情况：/dev/mtdblock/0 bootloader
　　/dev/mtdblock/1 kernel
　　/dev/mtdblock/2 cramfs (假设cramfs中有multimedia，guilib， etc，usr， extdata等)
　　这样之需要在kernel加载后使用下面的命令（放在初始化脚本linuxrc中）
　　mount -t yaffs /dev/mtdblock/2 / 即可。
　　
　　那么可能我觉得这个cranfs太大，尤其是其中的multimedia和extdata，想把他们分开怎么办呢？
　　使用五个分区： /dev/mtdblock/0 bootloader
　　/dev/mtdblock/1 kernel
　　/dev/mtdblock/2 yaffspart1(将guilib， etc，usr以及其他一些文件制作成yaffs文件系统)
　　/dev/mtdblock/3 yaffspart2 (将multimedia制作成yaffs文件系统）
　　/dev/mtdblock/4 yaffspart3（将extdata制作成yaffs文件系统）
　　那么kernel起来后，需要做这样的动作（可以放在linuxrc中，也可以放在比较早执行的脚本里面）： mount -t yaffs /dev/mtdblock/2 /
　　mkdir /multimedia
　　mkdir /extdata
　　mount -t yaffs /dev/mtdblock/3 /multimedia
　　mount -t yaffs /dev/mtdblock/4 /extdata
　　为此时选择yaffs而不是cramfs呢？我想你知道答案，因为cramfs只读，没办法mkdir。当然，其他的可读写文件系统比如jffs也是可以的。当然，如果你的/下面老早就有两个空目录，multimedia和extdata，那么根文件系统也就是/dev/mtdblock/2使用cramfs也是可以的，而multimedia和extdata本身在"/"分区使用cramfs和yaffs时都可以使 用任意的其他文件系统，不一定非是yaffs，当然，前提是你得知道你究竟是不是需要在使用时在这里面进行写操作。
　　3、关于bon分区和mtd分区，请参考一种bootloader（vivi）的bon分区功能，它分区时通过是否带m选项来指定是不是能和mtd分区共存。还有，一个mtd分区可以包含几个bon分区。
　　4、如果你不了解yaffs，可能需要查找一下资料。简单点说，他就是一个可读写的文件系统，而且具有nand的纠错功能，在某些方面比较cramfs来说具有优势。但是他的缺点也很明显，就是不如cramfs有空间效率，因为它是不压缩的（反而会变大），也就是说一个64M的文件夹，如果你mkyaffs，可能得到80M的yaffs文件系统，但是如果使用mkcramfs，可能就是只有50M了。
　　yaffs文件系统的制作和cramfs一样，需要工具，mkyaffs，就如同制作cramfs需要工具mkcramfs一样。具体在哪里找，我想你只要google一下就可以了。
　　5、至于文件系统的共存，其实比较好理解。不仅仅yaffs和cramfs共存，一般还有ramfs和他们共存，这样就能在使用cramfs的文件系统中提供一个可读写的文件系统，适合用在调试阶段。方法很简单，回顾一下2里面使用5个分区的情况就知道了。
　　
　　以上是我个人的一点点理解和建议，肯定有不正确的地方，如果你发现什么错误了，请指出来告诉我。谢谢。
　　
　　changejoy
　　##################################################################################
　　
　　很感谢上面这位网友的一番分析和讲解,解答了我的某些困惑的地方.
　　
　　通过多次实验,以下为自己具体的分区过程:
　　
　　1.如果首先板子上没有烧进去vivi,则可以通过JTAG口以及jflash烧写工具软件把vivi烧进目标板上,当然有的开发板也可以在ADS1.2的环境用JTAG仿真器(如Multi-ICE),通过某个烧写程序把vivi烧进目标板,这里具体第一次怎么把vivi烧写进去就不再多述了.
　　
　　2.当把vivi烧进去后,可以通过输入part show查看MTD分区情况,这个分区表应该和后面kernel中的MTD分区保持一致,我的2.6内核源码中修改后的MTD分区表为:
　　0x00000000-0x00020000 : "boot"
　　0x00020000-0x00030000 : "param"
　　0x00030000-0x001f0000 : "kernel"
　　0x00200000-0x00400000 : "root"
　　0x00400000-0x04000000 : "user"
　　那么这里,我们应该将通过修改vivi的源码把MTD分区表修改成一样,修改/vivi/arch/s3c2410/smdk.c文件:
　　将里面的
　　#ifdef CONFIG_S3C2410_NAND_BOOT
　　mtd_partition_t default_mtd_partitions[] = {
　　{
　　name: "vivi",
　　offset: 0,
　　size: 0x00020000,
　　flag: 0
　　}, {
　　name: "param",
　　offset: 0x00020000,
　　size: 0x00010000,
　　flag: 0
　　}, {
　　name: "kernel",
　　offset: 0x00030000,
　　size: 0x00100000,
　　flag: 0
　　}, {
　　name: "root",
　　offset: 0x00130000,
　　size: 0x00200000,
　　flag: MF_BONFS
　　}
　　};
　　#endif
　　
　　修改成如下:
　　
　　#ifdef CONFIG_S3C2410_NAND_BOOT
　　mtd_partition_t default_mtd_partitions[] = {
　　{
　　name: "vivi",
　　offset: 0,
　　size: 0x00020000,
　　flag: 0
　　}, {
　　name: "param",
　　offset: 0x00020000,
　　size: 0x00010000,
　　flag: 0
　　}, {
　　name: "kernel",
　　offset: 0x00030000,
　　size: 0x001f0000,
　　flag: 0
　　}, {
　　name: "root",
　　offset: 0x00200000,
　　size: 0x00400000,
　　flag: MF_BONFS
　　}, {
　　name: "user",
　　offset: 0x00400000,
　　size: 0x04000000,
　　flag: 0
　　}
　　};
　　#endif
　　保存文件,并重新make,生成新的vivi文件;
　　
　　3. 重新bon分区flash,这是十分必要的,相当于重新分区并格式化了整个flash区,当bon分区后flash里面的数据将全部丢失,所以要再把前面新生成的vivi烧入目标板上,当然现在就可以只通过串口把vivi烧写进去,不用像第1步那样操作烧写vivi,但是注意bon命令重新分区后千万不要断电了再烧写vivi,否则就不能通过串口烧vivi了,具体步骤如下:
　　(1)这里将flash分成4个区(vivi和param只占一个区),输入bon分区命令:
　　#bon part 0 192K 2M 4M
　　解释一下上面的命令:
　　第1个分区从0开始;
　　第2个分区从0x30000(即192K)开始;
　　第3个分区从0x200000(即2M)开始;
　　第4个分区从0x400000(即4M)开始.
　　(2)分区成功后,可以通过命令bon part info或者bon part show来查看bon分区信息,接下来不要断电,直接通过串口下载vivi,但是要注意的是,在linux下用xmodem协议下载文件很有可能出现传输过程中断线或者连不上的情况,但是在windowsXP的附件中的超级终端下通过xmodem传输文件过程却是十分的理想,所以我建议从前面的第3步一开始就都在windowsXP环境下的超级终端里进行操作,输入命令:
　　#load flash vivi x
　　然后点击终端窗口中的传送下的发送文件,采用xmodem协议,选择要下载的vivi码即可.
　　(3)等待文件传输完毕后,输入boot重启目标板,并按住空格键重新进入vivi模式下,输入命令:
　　#part show
　　即可看到重新的分区表:
　　vivi> part show
　　mtdpart info. (5 partitions)
　　name offset size flag
　　------------------------------------------------
　　vivi : 0x00000000 0x00020000 0 128k
　　param : 0x00020000 0x00010000 0 64k
　　kernel : 0x00030000 0x001f0000 0 1M+960k
　　root : 0x00200000 0x00400000 4 4M
　　user : 0x00400000 0x04000000 0 64M
　　vivi>

本文转自
http://www.mcublog.com/blog/user1/9854/archives/2006/17901.html