vivi分区问题，及移植时需要修改的地方（转）

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

以上就是整个分区过程了

在vivi下：

vi Makefile

1.LINUX_INCLUDE_DIR = /usr/wqw/2.4.18-rmk7/include

2.CROSS_COMPILE =/usr/local/arm/2.95.3/bin/arm-linux-

3./usr/wqw/vivi-sd/arch/s3c2410

vi smdk.c

char linux_cmd[] = "root=/dev/mtdblock2 load_ramdisk=0 init=/linuxrc console=ttyS0 mem=64M

devfs=mount mac=00:00:c0:ff:ee:08";

如果改动不起作用，在启动vivi时，按空格进入参数输入状态：

linux command line is: "root=/dev/nfs rw nfsroot=192.168.0.24:/home/myroot noinitrd init=/linuxrc

console=ttyS0 ip=192.168.0.25 devfs=mount"

移植vivi成功

移植vivi成功

今天将vivi移植到了开发版里.vivi的版本为1.4.现在讲一下具体修改的过程.首先是下载vivi源代码,解压缩.然后是修改makefile,具体是:

修改为“LINUX-INCLUDE-DIR = /usr/local/arm/2.95.3/include”,就是自己的编译器路径.

修改为“CROSS-COMPILE = /usr/local/arm/2.95.3/bin/arm-linux-”

修改为"ARM_GCC_LIBS = /usr/local/arm/2.95.3/lib/gcc-lib/arm-linux/2.95.3"

在 这里我遇到一个问题,我用3.3.2和3.4.1的编译器编译vivi会报很多错误,比如什么:invalid option "no-fpu"之类的，但是用2.95.3就没问题，一路绿灯。不知道是只有我一个人有这个问题还是大家都有，总之网上没有人提到这个问题。就是这个小 问题卡了我将尽两天，浪费了大量的精力，真是受不了。

然后是修改arch/s3c2410/smdk2410.c

修改为

#ifdef CONFIG_S3C2410_NAND_BOOT

mtd_partition_t default_mtd_partitions[] = {

       {

              name:           "vivi",

              offset:           0,

              size:              0x00030000,

              flag:              0

       }, {

              name:           "param",

              offset:           0x00030000,

              size:              0x00150000,

              flag:              0    

       }, {

              name:           "kernel",

              offset:           0x00180000,

              size:              0x00180000,

              flag:              0

       }, {

              name:           "root",

              offset:           0x00300000,

              size:              0x01e00000,

              flag:              0

              //flag:            MF_BONFS        

       }, {

              name:           "user",

              offset:           0x02100000,

              size:              0x01f00000,

              flag:              0                   

       }

};

#endif

修改cmd_line,因为我是用linux2.6的内核，还想使用ramdisk，所以设置为：

“char linux_cmd[] = "initrd root=/dev/mtdblock/3 init=/linuxrc console=ttySAC0,115200 mem=64M";”

然后make menuconfig，主要是去掉ecc。其他的设置就不细说了。

最后，make vivi 就可以的到一个名为vivi的文件，烧到nandflash里就ok了

再谈修改vivi

前几天将vivi在开发板上成功的跑了起来,于是转去做porting 2.6kernel+yaffs2的工作去了,等完成之后需要将kernel烧到nandflash里的时候出问题了.它说什么invalid mtd info.就是在使用vivi的load命令的时候出现的问题.用param save也会出现问题.总之就是不能往flash里写东西.看了一下vivi的启动信息,并且和网上其它人的启动信息比较了一下,发现在memory mapping的时候都是正常的,但是我的启动信息里没有nandflash的id,厂商等信息.于是在windows下用sourceinsight这 个软件将vivi添加到一个工程里,查看main.c(里面可以看出了vivi的启动过程),发现对mtd的初始化等依赖于smc功能,然而我在编译的时 候是把smc掉的.重新编译vivi,make menuconfig,选中smc支持.编译,出错,说什么在mtd.o里什么mtd_nand_ecc没有定义之类的,抱着瞎试的态度,把smc支持下 的关于ecc的项选中,编译通过.然后烧到板子上,启动,果然出现了nandflash的厂商信息,load命令也可以正常使用了.这些步骤看着听少的, 可是我自己做耗费的时间是以天来记的.真希望有个高手能在旁边指导一下,这样至少能省3/4的时间.其实对vivi的这一点我是感到很奇怪的,既然这两个 项你不放在一起选就会编译报错,那你为什么不把后一个设置为和前一个绑定.

首先下载一个纯净版的vivi主要修改几个地方

（1）LINUX_INCLUDE_DIR       = /kernel/include/（改成你存放linux kernel源代码的地址，因为编译vivi需要用到kernel源代码的部分头文件）----我本来是要把内核升级成2.6的,但是包含2.6的 include就是有问题,只好把他改成2.4的,我的linux就是2.4的,不过这个关系不大.

（2）CROSS_COMPILE   = arm-linux-（改成你存放交叉编译工具的路径，通常交叉编译工具的路径都已经在profile文件中声明，所以一般直接写成arm-linux-）

（3）ARM_GCC_LIBS    = /opt/crosstool/arm-linux/lib/gcc-lib/arm-linux/2.95.3（改成你安装交叉编译工具的相应路径）- ---用3.4.1的编译器会报错:说什么mshort-load-bytes选项无效,搞了好久不弄明白,只好用2.95.3,我弄了两个编译环 境!:)

然后就是配置选项了,在make menuconfig之前,建议先make clean,先把原来试验产生的目标文件清除.

make menuconfig之后,可以选用默认的配置,因为vivi对2410的支持很好,但是我们可以在串口选项下输入自己的vivi提示符(看我的,就是lidtin@HBUT>是不是很有成就感?)

保存退出.接下来,系统会提示下一步:make ,过几秒后,ls查看,就会发现新生成了一个vivi和vivi-elf两个文件,我们把vivi用sjf2410或者Jflash烧到板子里去,重启就会发先可爱的vivi了!

-----注:我的vivi不支持usb,只能用串口下载,那位知道怎么样才能支持usb,告诉我一声哈,谢谢!

启动界面:

==============================

VIVI version 0.1.4 (root@localhost.localdomain) (gcc version 2.95.3 20010315 (re

lease)) #0.1.4 三 7月 19 11:16:06 CST 2006

MMU table base address = 0x33DFC000

Succeed memory mapping.

NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung K9D1208V0M)

Could not found stored vivi parameters. Use default vivi parameters.

Press Return to start the LINUX now, any other key for vivi

type "help" for help.

lidtin@HBUT> part show

mtdpart info. (4 partitions)

name              offset                    size        flag

------------------------------------------------

vivi              : 0x00000000    0x00020000     0          128k

param         : 0x00020000    0x00010000     0           64k

kernel         : 0x00030000    0x00200000     0           2M

root            : 0x00230000    0x01f00000     4            31M

lidtin@HBUT>