今天做内核移植,准备添加NAND flash的驱动,做到MTD分区时,想起在一本书上看到的一句话,说的是分区时每个区之间没有间隙,前一个区的结束地址是后一个区的起始地址。可是当我看我的开发板的教程时,分区如下:
static struct mtd_partition smdk_default_nand_part[] = {
[0] = {
.name = "uboot",
.offset = 0x00000000,
.size = 0x00040000,
},
[1] = {
.name = "kernel",
.offset = 0x00200000,
.size = 0x00300000,
},
[2] = {
.name = "yaffs2",
.offset = 0x00500000,
.size = MTDPART_SIZ_FULL
}
};
很显然,在uboot和kernel分区中存在间隙,心中产生了疑问,难道MTD分区的时候要有注意的问题?通过各方查找资料和查阅书籍,找到了原因。不对的地方还请大家指正。
首先说一下Linux下固态存储设备(NAND flash算其中一种)对系统组件的安排方式,一般为
也就是说,在NAND flash中,各部分的程序是这样安排的,但哪一端是高地址是依体系结构不同而不同的,对于ARM,引导加载程序在最低地址处,因此,无论是uboot的分区还是内核MTD分区,引导加载程序的分区都放在了最低地址处。那么,两个分区到底怎么联系起来,而我们又该怎么设置MTD分区呢?先给出我的开发板uboot的分区信息:
bootargs=noinitrd root=/dev/mtdblock2init=/linuxrc console=ttySAC0
mtdparts=mtdparts=nandflash0:256k@0(bios),128k(params),128k(toc),512k(eboot),1024k(logo),3m(kernel),-(root)
然后说一下MTD分区,这个分区是内核可以识别的分区,也就是说,内核的操作都是基于MTD分区的;而uboot的分区只是为了方便操作,例如,我想将内存中0x30000000地址处的内容写到NAND flash的偏移量为2M的地址处,即uboot分区中kernel的起始位置,一般情况,我们要写
nand write 0x30000000 0x00200000
但如果有了uboot的分区,我们可以写
nand write 0x30000000 kernel
说清上面的问题,为了进一步阐述后面的问题,这里再讲一下我对uboot引导过程的理解,当系统启动后,uboot开始执行,他分两个阶段完成工作,主要是一些初始化,然后,加载内核并传递内核参数,之后跳入内核执行,内核完成它的初始化工作,其中包括挂载文件系统。
现在,我们可以翻回头看上面程序中的MTD分区了。MTD分区中的uboot分区明显对应了uboot分区中的bios分区(从0开始,大小为128K),而MTD分区中的kernel和yaffs2分区的起始地址和大小也分别对应uboot分区中的kernel和root分区。而因为我们不需要uboot分区中的其他部分,所以在MTD分区中出现了这一部分空隙。但为什么这么安排呢?
回想我们在烧写程序时候的操作,比如我们选择烧写内核镜像,此时,uboot实际执行了一条语句,类似于
#define kernel 0x00200000
memcpy(kernel,0x30000000,SZ_3M)
这里我们烧写程序的入口地址是0x30000000,也就是说,uboot的下载模式将我们烧写到内存0x30000000处的数据,搬到了NAND flash的kernel处,保存了起来,因此,这里要清楚,我们烧写程序时,实际是将程序先烧写到了内存当中,然后由内存搬运到NAND flash中,如果此时我们的MTD分区与uboot中的分区是一致的,那么内核将来运行时可以很方便的找到内核程序所在的位置,同样,对文件系统的yaffs2分区也是如此,而且,与内核分区相比,文件系统的分区将显得更加重要,因为将直接影响到根文件系统能否挂载,这里是因为上面提到的一行
bootargs=noinitrd root=/dev/mtdblock2 init=/linuxrc console=ttySAC0
这里,uboot指定了根文件系统的代码来自于mtdblock2,也就是MTD分区的第三个分区(第一个编号为0),也就是我上面说到的,uboot完成初始化后,加载内核,而内核要完成文件系统的挂载,他从哪里找文件系统?就是这里!/dev/mtdblock2!
所以,现在我们看到,MTD分区的原因,而且最关键的在这里,其他分区如果与uboot的分区不一致还情有可原,但如果MTD分区中文件系统的分区与uboot中的root分区不一致,将会直接导致系统无法启动!
当然,之前操作的都是物理地址,当内核真正运行起来以后,将开始使用虚拟地址。
同样的,其他几个引导参数也应该得到满足,系统才可能正常运行起来
init=/linuxrc init进程的位置。
console=ttySAC0 终端对应tty设备,因此,在引导系统前,串口驱动移植应当完成
今天做内核移植,准备添加NAND flash的驱动,做到MTD分区时,想起在一本书上看到的一句话,说的是分区时每个区之间没有间隙,前一个区的结束地址是后一个区的起始地址。可是当我看我的开发板的教程时,分区如下:
static struct mtd_partition smdk_default_nand_part[] = {
[0] = {
.name = "uboot",
.offset = 0x00000000,
.size = 0x00040000,
},
[1] = {
.name = "kernel",
.offset = 0x00200000,
.size = 0x00300000,
},
[2] = {
.name = "yaffs2",
.offset = 0x00500000,
.size = MTDPART_SIZ_FULL
}
};
很显然,在uboot和kernel分区中存在间隙,心中产生了疑问,难道MTD分区的时候要有注意的问题?通过各方查找资料和查阅书籍,找到了原因。不对的地方还请大家指正。
首先说一下Linux下固态存储设备(NAND flash算其中一种)对系统组件的安排方式,一般为
也就是说,在NAND flash中,各部分的程序是这样安排的,但哪一端是高地址是依体系结构不同而不同的,对于ARM,引导加载程序在最低地址处,因此,无论是uboot的分区还是内核MTD分区,引导加载程序的分区都放在了最低地址处。那么,两个分区到底怎么联系起来,而我们又该怎么设置MTD分区呢?先给出我的开发板uboot的分区信息:
bootargs=noinitrd root=/dev/mtdblock2init=/linuxrc console=ttySAC0
mtdparts=mtdparts=nandflash0:256k@0(bios),128k(params),128k(toc),512k(eboot),1024k(logo),3m(kernel),-(root)
然后说一下MTD分区,这个分区是内核可以识别的分区,也就是说,内核的操作都是基于MTD分区的;而uboot的分区只是为了方便操作,例如,我想将内存中0x30000000地址处的内容写到NAND flash的偏移量为2M的地址处,即uboot分区中kernel的起始位置,一般情况,我们要写
nand write 0x30000000 0x00200000
但如果有了uboot的分区,我们可以写
nand write 0x30000000 kernel
说清上面的问题,为了进一步阐述后面的问题,这里再讲一下我对uboot引导过程的理解,当系统启动后,uboot开始执行,他分两个阶段完成工作,主要是一些初始化,然后,加载内核并传递内核参数,之后跳入内核执行,内核完成它的初始化工作,其中包括挂载文件系统。
现在,我们可以翻回头看上面程序中的MTD分区了。MTD分区中的uboot分区明显对应了uboot分区中的bios分区(从0开始,大小为128K),而MTD分区中的kernel和yaffs2分区的起始地址和大小也分别对应uboot分区中的kernel和root分区。而因为我们不需要uboot分区中的其他部分,所以在MTD分区中出现了这一部分空隙。但为什么这么安排呢?
回想我们在烧写程序时候的操作,比如我们选择烧写内核镜像,此时,uboot实际执行了一条语句,类似于
#define kernel 0x00200000
memcpy(kernel,0x30000000,SZ_3M)
这里我们烧写程序的入口地址是0x30000000,也就是说,uboot的下载模式将我们烧写到内存0x30000000处的数据,搬到了NAND flash的kernel处,保存了起来,因此,这里要清楚,我们烧写程序时,实际是将程序先烧写到了内存当中,然后由内存搬运到NAND flash中,如果此时我们的MTD分区与uboot中的分区是一致的,那么内核将来运行时可以很方便的找到内核程序所在的位置,同样,对文件系统的yaffs2分区也是如此,而且,与内核分区相比,文件系统的分区将显得更加重要,因为将直接影响到根文件系统能否挂载,这里是因为上面提到的一行
bootargs=noinitrd root=/dev/mtdblock2 init=/linuxrc console=ttySAC0
这里,uboot指定了根文件系统的代码来自于mtdblock2,也就是MTD分区的第三个分区(第一个编号为0),也就是我上面说到的,uboot完成初始化后,加载内核,而内核要完成文件系统的挂载,他从哪里找文件系统?就是这里!/dev/mtdblock2!
所以,现在我们看到,MTD分区的原因,而且最关键的在这里,其他分区如果与uboot的分区不一致还情有可原,但如果MTD分区中文件系统的分区与uboot中的root分区不一致,将会直接导致系统无法启动!
当然,之前操作的都是物理地址,当内核真正运行起来以后,将开始使用虚拟地址。
同样的,其他几个引导参数也应该得到满足,系统才可能正常运行起来
init=/linuxrc init进程的位置。
console=ttySAC0 终端对应tty设备,因此,在引导系统前,串口驱动移植应当完成
分享到:
相关推荐
详细的讲解uboot启动时的内存的分配问题。列举了NAND flash 的分区
学习linux下建立mtd分区必须的资料
我自己做的一个表格,基于海思hi3516C板子,MTD分区表。对于一些不会怎么修改内核大小以及文件大小后,怎么调整MTD表很有帮助哦。
2.1.4.2. mtd中的/dev/mtdN与/dev/mtdblockN的区别 14 2.2. 准备工作 15 2.2.1. 准备好要升级的文件 15 2.2.2. 拷贝文件并挂载分区 15 2.3. 利用mtd工具升级Linux系统 15 2.3.1. 升级Uboot 17 2.3.2. 升级Kernel 18 ...
美国网件 Netgear-R6800分区备份 mtd0_mtd1_mtd16 三个分区备份bin文件
MTD分区 加大手机的内存
1. mtd分区规划及其作用 uboot支持各种设备之后,接下来的工作就是烧写内核、烧写文件系统,所以需要对整块Nand Flash的空间作以规划,大致分为以下四个空间即可: bootloader空间 内核参数空间 内核空间 文件系统...
作用:用做linux运行时对uboot,kernel,rootfs在线升级。 包含文件:zlib-1[1].2.5.tar.gz,lzo-2.03.tar.gz,e2fsprogs-1.41.14.tar.gz,mtd-utils-a67747b[1].tar.gz, mtd工具编译过程.txt, flash_erase,flash_erase...
mtd-rw-MTD分区的写入启用器 在所有标记为只读的MTD分区上设置MTD_WRITEABLE标志。 卸载时,将还原只读分区。 该模块用于嵌入式设备,其中mtd分区布局可能会在固件中进行硬编码。 如果由于某种原因您必须写一个只读...
Linux2.6内核的vivi分区及内核MTD分区.pdf
linux在TQ2440上移植2--Nandflash驱动,MTD分区----经典
自定义手机分区(MTD Partition),放弃Apps2sd吧
和实际对nand flash的分区表不一致,实际上在uboot移植教程(08 – 移植uboot 2012.04到JZ2440(设置mtd分区表))中,对内核的mtd分区情况如下: 0x00000000-0x00040000 : bootloader 0x00040000-0x00060000 : ...
包含机器的主要mtd分区以及完整的jffs2和地区包备份,可用于救砖 制作固件
MTD工具的编译安装步骤如下: cd /root/build_rootfs 拷贝MTD源码到该目录下;...Uboot下设置传递给内核的命令行参数: setenv bootargs root=/dev/mtdblock2 init=/sbin/init console=ttySAC0,115200 rootfstype=jffs2
基于linux的mtd flash驱动程序,实现了多个分区。
1:先刷我编译的u-boot分区可以写的版本,对应压缩包里面的mtd_write_able.bin这个固件, 2:ssh登陆到路由器,用winscp拷贝gen_uboot.sh和tuboot.bin到/tmp文件夹中. 3:putty中执行脚本 命令是 sh gen_uboot.sh 4:会在/...
根据fs2410移植过后的mtd驱动源码,基于2.6.15内核
AR2317 UBOOT WR541G+ WR340 通用UBOOT 输入 cd ...输入 mtd write <文件名> <mtd分区名> 命令以进行刷机操作 刷入后,按住复位键开机,打开浏览器访问192.168.1.1 即可访问UBOOT,亲测。 有了它之后路由随便刷,刷不死
支持 mtd 分区jffs2 烧写 kernel yaffs 烧写 root(64nand 仅支持小页528 ) , nand 分区参数为: Creating 4 MTD partitions on "NAND 64MiB 33V 8-bit": 0x00000000-0x00040000 : "bootloader" ...