Chinaunix首页 | 论坛 | 博客
  • 博客访问: 82235
  • 博文数量: 26
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 10
  • 用 户 组: 普通用户
  • 注册时间: 2013-05-06 17:25
文章分类

全部博文(26)

文章存档

2015年(18)

2013年(8)

我的朋友

分类: 嵌入式

2015-09-09 15:08:40

原文地址:nandflash分区 作者:youthpassion

  part add 命令用于添加一个MTD 分区。
命令的详细格式如下:
part add name offset size flag
参数name 是要添加的分区的分区名称;
参数offset 是要添加的分区的偏移(相对于整个MTD 设备的起始地址的偏移,在ARMer9 系统中不论配置的是NOR Flash,还是NAND Flash,都只注册了一个mtd_info 结构,也就是说逻辑上只有一个MTD 设备,这个MTD设备的起始地址为0x00000000);
参数size 是要添加的分区的大小,单位为字节;
参数flag 是要添加的分区的标志,参数flag 的取值只能为以下字符串(请注意必须为大写)或者通过连接符“|”将以下字符串组合起来的组合字符串。
这个标志表示了这个分区的用途
“BONFS” —— 作为BONFS 文件系统的分区;
“JFFS2” —— 作为JFFS2 文件系统的分区;
“LOCK” —— 该分区被锁定了;
“RAM” —— 该分区作为RAM 使用。
请问:
1.用part命令创建而不管flag如何的都是MTD分区吗?
2.BONFS代表什么,RAM又代表什么,是指对sdram分区还是说这个分区用于存放ramfs?
3.BONFS、JFFS2、LOCK、RAM在这里分别代表什么常数?
                bon part 命令用于建立系统的BON 分区表。
BON 分区表被保存到NANDFlash 的最后0x4000 个字节中,即在NAND Flash 的0x03FFC000 ~0x33FFFFFF 范围内,分区表起始于0x03FFC000(注意: BON 分区是只针对NAND Flash 设备的一种简单的分区管理方式)。
命令的详细格式如下:
bon part offsets1[flag] offsets2[flag] offsets3[flag] ⋯⋯
参数offsetsN 是每个BON 分区的起始地址;
flag 是跟每个BON 分区的起始地址后面的标识符,这个标识的作用是前面数值的单位,‘k’’或‘K’表示kilo,千;‘m’或‘M’表示mega,兆。
如果再跟上‘:’,后面再跟上‘m’或‘M’,表示该分区被标记为MTD 分区,
如果没有‘:’以及后面的字母‘m’ 或‘M’,则表示该分区被标记为BON 分区。
bon part 命令在建立系统的BON 分区表,会检测每个分区是否有坏块
(Samsung 的NAND Flash 芯片K9S1208U0M,一个块含32 个页,一个页有512 个字节,一个块有16K 字节,即0x4000),如果发现坏块将标记出来,并且在分区表中体现,分区的大小将减去坏快的容量,得到实际可用的分区容量。bon part info 命令执行后显示的信息中, number_of_badblock所指示的就是分区中的坏块数目。
那我们总说的mtdblock3指的是MTD分区吗?那BON分区在什么时候用到,要不要像MTD分区那样在内核做相应的配置?
有关vivi分区的问题
[ 2006-11-17 16:37:00 | By: 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>
以上就是整个分区过程了.
 
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/hongjiujing/archive/2007/09/18/1789193.aspx
阅读(4267) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~