导读:
目标板要更新成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
目标板要更新成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