首页 > 代码库 > S5P210-uboot源码分析-uboot如何启动内核
S5P210-uboot源码分析-uboot如何启动内核
uboot如何启动内核
7、1、uboot和内核到底是什么?
1、uboot是一个裸机程序
(1)uboot的本质就是一个复杂点的裸机程序,和我们arm裸机中写的程序没有什么本质上的区别。
(2)uboot最像我们在arm裸机中的最后写的那个shell,它其实就是一个迷你型的uboot。
2、linux内核本身也是一个"裸机程序"
(1)操作系统内核本身就是一个裸机程序,和uboot并没有本质区别。
(2)区别在于,操作系统运行起来后在软件层次上可以分为内核层和应用层,分层后两层的权限不同,内存访问和设备操作管理上更加精细(内核可以随便访问各种硬件,而应用程序只能被限制的访问硬件和内存地址)。
(3)直观来看,uboot的镜像是u-boot.bin,linux系统的镜像是zImage,这两个东西其实都是两个裸机程序镜像。从系统的启动角度来讲,内核就是一个大的复杂点的裸机程序。
3、部署在SD卡的特定分区内
(1)一个完成的软件和硬件的嵌入式系统,静止时(未上电时)bootloader、kernel、rootfs等必须的软件都以镜像的形式存储在启动介质中(x210中是iNand,或者是SD卡)。运行时都是在DDR内存中运行的,与存储介质无关。上面两个状态都是稳定状态的。第三个状态是动态过程,从静止态到运行态的过程,也就是启动过程。
(2)动态过程就是一个从SD卡逐步搬移到内存DDR中,并且运行启动代码进行相关硬件软件架构的建立,最终达到一个稳定的运行状态。
(3)静止时,u-boot.bin、zImage rootfs都在SD卡中,他们不可能随意存在SD卡的任意位置(因为我的代码要将在SD卡我们规定放这些内容的扇区,把这些内容加载到DDR中运行),因此我们需要对SD卡进行一个分区,然后将各种镜像各自存储在各自的分区中,然后在启动过程中,uboot、内核等就知道到哪里去找谁。(uboot和kernel中的分区表要一致,并且要和我们SD卡中实际使用的分区一致。)
4、运行时必须先加载到DDR链接地址处
(1)uboot第一阶段中进行重定位将uboot的第二阶段(整个uboot镜像)加载到DDR中的0x33e00000地址去,这个地址就是uboot的链接地址。
(2)内核也有类似的要求,在uboot启动内核的过程中,将内核从SD卡中读取到DDR中(其实就是重定位的过程),不能随意放在DDR中,必须放在内核的链接地址处,否则是启动不起来的。比如我们用的内核,链接地址是0x30008000.
5、内核启动的时候需要必要的启动参数
(1)uboot是无条件启动,完全从零开始启动的,内核是不能开机自动完全从零开始启动的,内核启动需要别人帮忙,uboot要帮助内核进行重定位(从SD卡重定位到DDR)。所以内核自己本身不需要考虑自己是怎么从SD卡到内存中的,内核刚开始运行的时候就是DDR中,是uboot帮内核从SD卡搬移到DDR中的,就好像uboot是富一代,内核是富二代。
(2)uboot还要给内核提供一个启动参数。
7、2、启动内核的第一步:加载内核到DDR中
(1)uboot启动内核分为两个步骤:第一步将我们的内核从启动介质中加载到DDR中。第二步去DDR中启动内核镜像
内核代码根本就没考虑重定位,因为内核知道会有uboot之类的帮忙的,把自己加载到DDR中链接地址处。所以内核直接就是从连接地址处开始运行的。
7、3、静态内核镜像在哪里?(一般是fastboot命令在uboot命令行下,将内核等镜像烧录到iNand中)
(1)SD卡/iNand/nand/norflash等:raw分区(原始分区)
常规启动时,我们的各种镜像烧录存放在iNand中,因此uboot只需要从iNand中的存放kernel分区去读取内核镜像到DDR中即可。
(2)读取的时候要使用uboot的命令来读取。(如x210iNand版本的movi命令,x210nand版本的nand命令)
movi read kernel 0x30008000 从iNand的kernel分区将内核镜像读取到DDR的0x30008000地址去(内核的链接地址)。
bootm 0x30008000 意思是去DDR的0x30008000处启动内核。
(3)其中movi read kernel 0x30008000 中的kernel指的是uboot中的kernel分区(就是uboot中规定的iNand中的一个区域范围,这区域范围被设计来存放kernel镜像,就是所谓的kernel分区)
(2)tftp、nfs等网络下载方式从远端服务器获取镜像
uboot还支持远程启动,也就内核镜像不直接烧录到开发板的启动介质中,而是放在主机的服务器中底下,然后需要启动时,我们uboot通过网络从服务器中下载镜像到开发板的DDR中。
tftp 0x30008000 zImage-qt 下载到DDR中的0X30008000 前提是主机Ubuntu和uboot ping通
然后bootm 0x30008000去DDR的这个地址去启动内核,因为内核在这个地址了
分析总结:目的是让内核镜像到DDR中,不管用什么方式,只要让内核镜像到DDR中即可。一般的情况下,我们的产品出厂时是从启动介质中启动,所以我们要将镜像烧录到iNand中,如果我们是开发的话,最好是用tftp的方式去将内核的镜像下载到DDR中运行,如果能运行的话,我们在将镜像烧录到开发板中。
7、4、镜像放到DDR中的什么地址?
(1)内核一定要放在内核的链接地址处,链接地址去内核源代码的链接脚本或者makefile中去查找。在x210中内核在DDR的链接地址是0x30008000
7、5、zImage和uImage的区别联系
1、boot命令对应do_bootm函数
(1)命令名前加do_即可构成对应这个命令的函数,因此当我们bootm这个命令执行时,直接执行的是do_bootm这个函数,在cmd_bootm.c这个文件中了。
(2)do_bootm定义了一些变量,用宏来条件编译执行了SECURE_BOOT的一些代码,就是安全启动,但是我们的这个宏没有定义。主要是进行一些签名的认证,我们可以不管
(3)然后进行了一些细节的操作,我们也不用管他,然后到了这个宏CONFIG_ZIMAGE_BOOT,用这个宏来控制进行条件编译一段代码。这段代码是用来支持zImage格式的内核启动的。
2、vmlinuz和zImage和uImage
(1)uboot 经过编译链接生成的elf格式的可执行程序u-boot。这个程序类似于Windows下的exe格式。在操作系统下是可以直接执行的,但是这种格式不能用来烧录下载。我们用来烧录下载的是u-boot.bin,这个东西是由u-boot(elf格式),经过一个工具arm-linux-objcopy,由ELF格式加工处理(去掉一些无用的东西)成可烧录下载的镜像的。这个u-boot.bin就叫镜像(image),镜像就是用来烧录到iNand中执行的。
(2)linux内核经过编译后也会生成一个ELF格式的可执行程序,叫vmlinuz或vmlinux,这个就是原始的未经任何加工处理的原版的内核elf文件,嵌入式系统部署时一般烧录的不是这个vimlinuz,而是要用objcopy工具去制作成的镜像格式(u-boot.bin这种),但是内核镜像没有这个.bin的后缀,有没有后缀没有什么区别只是名字不一样。
由vimlinuz格式的,也就是elf格式的内核可执行程序,经过objcopy工具加工成可以烧录的镜像就叫做Image(制作过程,把78M打的vimlinuz可执行程序,精简成了7.5M,因此这个工具制作烧录镜像的主要的目的就是缩减大小,节省磁盘)
(3)原则上,Image就可以直接烧录到flash上直接启动执行(类似于u-boot.bin)。但是实际上并不是这么简单的,实际上linux的作者们,觉得Image还是太大了,所以对Image进行了压缩,并且在Image压缩后的文件的前段附加了一部分解压缩的代码。构成了一个压缩格式的镜像,就叫zImage(这个压缩文件的前段附加了解压缩的代码),因为操作系统还没启动起来,是不可能让操作系统去解压缩的。而且也没有用uboot去代码实现zImage的解压缩,而是zImage本身的前面一部分有解压缩代码,叫做自解压的方法。
(4)uboot为了启动linux内核,还发明了一种内核格式叫uImage,uImage是由zImage加工得到的,uboot中有一个工具可以将zImage加工生成uImage。注意:uImage不关linux内核的事,linux内核只管生成zImage即可。uboot中的mkimage工具将zImage加工生成uImage来给uboot启动,这个加工过程就是在zImage前面加上64字节的头信息,形成了uImage。专门给从uboot启动内核镜像使用的内核镜像。
(5)但是实际上uboot也可以支持zImage的镜像,是否支持就要看x210_sd.h中是否定义了LINUX_ZIMAGE_MAGIC这个宏
(6)有的uboot支持启动zImage格式的镜像,有的uboot不支持,但是所有的uboot肯定支持uImage格式的内核镜像
3、编译内核得到uImage镜像
(1)我们在kernel的文件夹下,直接make uImage 是通不过的,会报错,因为少了这个mkimage这个工具,这个工具就是用来讲zImage的镜像加工成(在zImage的前面加了64KB的头)uImage格式的镜像的。
(2)这个mkimage工具,在我们uboot编译会得到的,是有mkimage.c和mkimage.h这两个文件生成得到的。在uboot的根目录下的/tools中。所以我们要将这个在uboot/tools/下的mkimage工具复制到我们Ubuntu默认的用户工具的目录下/usr/local/bin/下。
(3)这时我们在kernel下进行编译时就OK了,因为用到了mkimage工具,但是却没有找到,只要将这个工具复制到系统默认寻找工具的位置下就行。 在uboot/tools目录下 cp mkimage /usr/local/bin
7、4、zImage启动的细节
1、
(1)、do_bootm中一直到397行after_header_check这个符号处都是在做镜像的头部信息校验,校验时就要根据不同种类的image进行不同的校验。zImage和uImage本身都是有头信息的,uImage又在zImage的基础之上又加了头信息,在正式的文件中,我们的开始的部分都会有头信息,我们在用时,要进行头部信息的校验,头部之后的信息才是正式的内容。
(2)所以do_bootm函数的核心内容就是分辨出传进来的image是什么类型的,然后按照这种类型的头信息格式进行头检验。
如果检验通过了,则下一步准备启动内核,如果检验失败,则认为镜像是有问题的,所以不能进行启动。
(3)do_bootm函数中的第197行到223行是zImage镜像的头校验。
2、LINUX_ZIMAGE_MAGIC
(1)这是定义了一个魔数(这个数表示一种特定含义),定义的数是0x016f2818,这个数表示这个镜像是zImage,也就是说,在zImage镜像的头部的一个固定位置存放了这个数作为格式标志。
(2)如果我们拿到了一个image,去他的那个放魔数的固定位置读取四个字节的内容,看是否等于这个LINUX_ZIMAGE_MAGIC数,则可以知道这个镜像是不是一个zImage
3、do_bootm函数的参数中有int argc 和char *argv[]两个参数,当我们bootm 0x30008000时, argc = 2. argv[0] = boom argv[1] = 0x30008000这个,注意穿进来的值都是字符串格式的
(1)从do_bootm函数中可以看出来,zImage头部的第37字节开始的连续四个字节中放的是代表是什么类型镜像的魔数信息。可以用阅读软件打开zImage这个文件,来看着个zImage文件的这个位置放的是不是这个魔数来证实。很多软件可以打开二进制文件,如:winhex
4、image_header_t
(1)这个结构体就是zImage的标准头,就是这个镜像的实际地址,将这个地址转换成了这个结构体类型的指针,赋值给了同类型的结构体指针变量,也就是说zImage前面有一段头信息,这段头信息就是按照这个结构体来封装的,其中LINUX_ZIMAGE_MAGIC这个魔数就包含在这个结构体中,在实际运行启动之前,要进行一些改造,hdr->ih_os = IH_OS_LINUX;
hdr->ih_ep = ntohl(addr);这两句代码就是在进行改造
(2)images是一个全局变量,在do_bootm函数中使用,用来完成启动过程的,zImage的校验过程就是先校验是不是zImage,通过这个魔数,校验好后在将相关的信息进行改造,最后初始化到这个images全局变量里
7、5、uImage启动
1、uImage启动
(1)do_bootm函数的227行到397行是
(2)IMAGE_FORMAT_LEGACY中的legacy意思是遗留的,在do_bootm函数这种方式指的就是uImage的方式
(3)uImage本身是uboot发明用来启动linux内核镜像的格式,但是后来这种方式设备树这种新的方式替代了。在do_bootm中叫FIT,所以有CONFIG_FIT这个宏,但是这些老师不讲这种新的设备树的方式。
(4)uImage的启动校验主要在这个boot_get_kernel函数中,主要任务就校验uImage的头信息,并且得到kernel的真正的起始位置去启动。
(5)剩下的源码自己去分析。
总结:uboot开始时只是支持uImage格式的镜像启动,但是后来有了新的方式fdt设备树的方式进行启动。所以在uboot源码中,这个do_bootm函数中添加了一对#if #endif ,但是有些人又想uboot支持启动zImage镜像的内核,所以又添加了一对#if #endif
uboot启动内核的第一步是将内核镜像从我们烧录到的设备中,iNand中搬移到DDR中。第二步是进行镜像的头信息和CRC校验来判断是哪种格式的镜像。第三步就是去启动内核了。我们启动的是linux内核,所以调用的是这个do_bootm_linux函数来完成启动linux内核。
7、6、do_bootm_linux函数
1、找到do_bootm_linux函数
(1)在uboot/lib_atm/bootm.c中,
2、镜像的entrypoint
(1)ep就是entrypoint的缩写,就是程序的入口。一个镜像文件起始执行部分不是镜像的开头(镜像的开头部分是N个字节的头信息),一个镜像的文件真正执行的时候,第一句代码是在镜像文件的中部某个字节处,相当于镜像的头是有一定的偏移量的,然而这个偏移量是记录在头信息中的,
(2)一般执行一个镜像的时候,是先从镜像的头信息的特定位置中找MAGIC_NUM,由此来确定镜像的种类;第二步对镜像进行CRC校验,目的是看镜像是否是完整的。第三步再一次的读取镜像的头信息,在头信息的特定位置知道这个镜像的各种信息(镜像的长度,镜像种类,镜像的入口地址);第四步就是去entrypoint处执行镜像。所以ep中记录的是镜像的入口执行代码地址,镜像的头加上了一个偏移量。
(3)bootm.c的92行
theKernel = (void (*)(int, int, uint))ep;
//将ep这个镜像在内存中真正的代码执行的内存地址,并将这个地址强制类型转换成了函数指针类型,进行赋值,thekernel 在上面定义的,是一个函数指针类型的变量
ep将镜像在内存中的第一句真正的代码执行地址,赋值给了thekernel这个函数指针,这个函数指针就指向了在内存中真正镜像OS操作系统内核的起始代码地址。
总结:所以uboot最终是通过一个函数指针的方式,实现的推动我们内核的启动。这个函数指针执行时,带来三个参数,
theKernel (0, machid, bd->bi_boot_params); 机器码、uboot在内存中放的为内核准备的启动参数的内存的地址。
3、再次确定机器码
(1)uboot在启动内核的时候,要将机器码传递给内核,那么uboot传递给内核的机器码是怎么确定的呢?
第一顺序的选择,是从uboot中环境变量macid中获取,第二种顺序选择是从gd->bi->bi_arch_num(x210_sd.h中用一个宏配置的,赋值给了这个结构体成员)中的记录的机器码。
4、传参并启动概述
(1)110行到145行就是uboot给linux内核准备传参参数的处理。
(2)之后,uboot在最后最后打印出来的东西就是starting kernel...这句信息如果出来了,说明uboot整个是成功的,内核镜像是成功加载到内存中的,因为头信息的校验,CRC校验都通过了,说明镜像是完成的,也找到了内核镜像的真正的第一句代码的执行地址,也试图去执行了,如果这句信息后,后面就没有别的东西了,说明我们的内核并没有被成功的执行。原因:一般是传参的原因(能占百分之80的可能),内核在DDR中被加载到的地址(因为可能你将镜像下载到DDR中的地址是这个地址,你bootm时,也是bootm的这个地址,在uboot阶段一切都顺利,但是可能因为uImage的头校验信息和其他zImage开始的解压缩代码的原因,ep保存的相对于镜像头的偏移量不同,导致真正的内核镜像第一句起始代码的地址不同,所以启动不起来内核,这里只是猜测)。
7、7、传参详解
1、110行到145行就是uboot给linux内核准备传参参数的处理。
2、tag传参方式(tag是一个数据结构)
(1)struct tag,tag是一个数据结构,这个数据结构在uboot中和在linux kernel中都有定义,而且定义都是一样的。
tag的结构体类型的封装在uboot/include/asm-arm/setup.h中。
(2)struct tag_header hdr;
定义了一个tag的头tag_header,这个头中有一个成员叫做tag和size的类型编码,这个tag将来会被赋予一个值,这个值是一个魔数,来区分当前使用的是哪个tag的,linux内核读取这个tag中的魔数值和大小,来知道当前传过来的tag是哪一个,这个struct tag封装中,下面的union共用体是用的哪个类型的union,也就是把剩余的部分当做一个tag_xxx来处理。
tag_xxx是什么东西,就取决于linux读取到的tag是一个什么类型的,linux内核是按照这种方式来处理的,那么我们的uboot也就要按照这种方式来放。
(3)tag_start和tag_end,kernel接收到的参数是由若干个tag构成的。这个tag由tag_start开始到tag_end结束。所以uboot在给linux内核传参后,linux内核会首先到那个地方找tag_start,如果找到了,linux内核就知道下一个tag就是要传递的参数了,完了一直接收,知道找到了tag_end了,linux内核就知道,所传递的参数没有了。
(4)tag的传参方式,不是由uboot发明的,而是由linux kernel发明的,kernel中定义了向我传递参数时的方式,uboot只是实现了这种传参方式,从而支持给kernel进行传参。
7、8、x210_sd.h中配置传参宏
1、CONFIG_SETUP_MEMORY_TAGS对应struct tag中的tag_mem,传参传的内容是内存的配置信息。(uboot掌握了我开发板上有几片内存,没片有多大,起始地址分别是多少,但是linux内核本身是不知道这些信息的,linux内核是不知道内存本身是怎么分布的,但是uboot把这些信息维护到那个gd->bd当中的数据结构里了,所以uboot需要让linux内核知道这些事情,所以uboot就会使用tag_mem这个tag将这些信息传递给linux内核)
2、CONFIG_CMDLINE_TAG对应struct tag这个封装中的tag_cmdline,传参的内容是启动命令行参数,就是bootargs,也就是uboot的环境变量bootargs,目的是告诉linux中的命令行应该怎么启动。
3、CONFIG_INITRD_TAG跟什么磁盘相关,老师没讲。。。。
4、CONFIG_MTDPARTITION,传参内容是iNand的分区表
总结:分析代码知道,起始tag是ATAG_CORE.结束tag是ATAG_NONE,其他的tag种类,ATAG_XXX都是有效信息的tag。
思考:内核是如何拿到这些tag的?
uboot最终调用了thekernel这个函数来执行linux内核,这个函数是一个函数指针,指向的那个内存地址就是linux内核第一句代码的起始地址,这个函数在执行linux内核的时候,给linux内核传递了三个参数,这三个参数很重要,第一个参数放在了r0中,第二个参数放在了r1中,第三个参数放在了r2中。
其中第一个参数固定为0。第二个参数是机器码,第三个参数就是uboot大片传给linux内核的参数的首地址,就是uboot放在内存中的那一片参数,给linux启动的参数的首地址,linux内核知道这个参数,就可以去那个地址去处找tag了,也就是找uboot给传过来的一系列的参数。
总结:uboot在启动内核的时候,uboot是使用了一个tag传参的方式,将将来要告诉给linux内核传参的内存地址赋值给了这个tag,所以tag就指向了linux内核去那个内存找寻参数的地址,所以uboot使用tag指向的内存地址,用这种数据结构将一些要传给linux内核的参数进行打包。打包完成后,uboot就调用thekernel这函数去Linux内核的第一句代码处执行,并且传了三个参数,其中的放在r2寄存器中的参数,就是放给内核传参的内存地址。
uboot移植时的注意:在移植一般情况下,只需要改x210_sd.h中的宏配置就可以了,如果你的内核启动不起来,在uboot本身其他地方没有问题的情况下,那么就要去看,uboot在启动内核时,传递的参数对不对,看bootargs这个环境变量的值设置的对不对,这个环境变量是uboot来告诉Linux内核命令行改怎么启动的,如果参数什么的都没有问题,那就要看宏配置是否配置的正确。主要是这样。
uboot启动内核的总结:
第一步:将内核搬移到DDR中,从内核在flash部署的地方,我们的可是在iNand中,从iNand中属于内核的分区搬移DDR中((0x30008000),也可以从主机Ubuntu中的tftp服务器直接下载到DDR中,属于内核的链接地址的放,也就是内核在DDR中的属于内核的分区,这个是实现uboot和linux内核约定好的。
第二部:对内核镜像格式的校验,CRC校验,看该内核属于哪种的内核格式,是zImage,uImage,fdt的哪一种格式,在进行CRC校验,看内核镜像是否是正确的。
第三步:uboot给内核进行传参的准备,uboot用tag的方式进行给内核传参,事先uboot将要给linux内核传参的所放参数的地址中,一个tag的数据结构,将uboot要给linux内核传参的参数,打包到这个数据结构中,tag的头正好指向了这个给内核传参的内存地址,uboot也只需要在执行thekernel这个函数的时候,给linux内核传一个参数所在的地址(0x30000100)告诉linux内核就行。
第四步:uboot执行thekernel函数指针,所指向的linux kernel实际代码第一句所在的位置去运行。
涉及到的函数是do_bootm和do_bootm_linux;do_bootm函数对应在我们命令下那个bootm 0x30008000,主要对应的是前两个步骤。
本文出自 “whylinux” 博客,请务必保留此出处http://whylinux.blog.51cto.com/10900429/1898787
S5P210-uboot源码分析-uboot如何启动内核