UBoot启动过程详细版的完全分析Word下载.docx
《UBoot启动过程详细版的完全分析Word下载.docx》由会员分享，可在线阅读，更多相关《UBoot启动过程详细版的完全分析Word下载.docx（63页珍藏版）》请在冰点文库上搜索。
第四个分区：
则是根文件系统
如下图所示：
u-boot是一种普遍用于嵌入式系统中的Bootloader。
Bootloader介绍
Bootloader是进行嵌入式开发必然会接触的一个概念，它是嵌入式学院<
嵌入式工程师职业培训班>
二期课程中嵌入式linux系统开发方面的重要内容。
本篇文章主要讲解Bootloader的基本概念以及内部原理，这部分内容的掌握将对嵌入式linux系统开发的学习非常有帮助！
Bootloader的定义：
Bootloader是在操作系统运行之前执行的一小段程序，通过这一小段程序，我们可以初始化硬件设备、建立内存空间的映射表，从而建立适当的系统软硬件环境，为最终调用操作系统内核做好准备。
意思就是说如果我们要想让一个操作系统在我们的板子上运转起来，我们就必须首先对我们的板子进行一些基本配置和初始化，然后才可以将操作系统引导进来运行。
具体在Bootloader中完成了哪些操作我们会在后面分析到，这里我们先来回忆一下PC的体系结构：
PC机中的引导加载程序是由BIOS和位于硬盘MBR中的OSBootLoader（比如LILO和GRUB等）一起组成的，BIOS在完成硬件检测和资源分配后，将硬盘MBR中的BootLoader读到系统的RAM中，然后将控制权交给OSBootLoader。
BootLoader的主要运行任务就是将内核映象从硬盘上读到RAM中，然后跳转到内核的入口点去运行，即开始启动操作系统。
在嵌入式系统中，通常并没有像BIOS那样的固件程序（注：
有的嵌入式cpu也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由BootLoader来完成。
比如在一个基于ARM7TDMIcore的嵌入式系统中，系统在上电或复位时通常都从地址0x00000000处开始执行，而在这个地址处安排的通常就是系统的BootLoader程序。
（先想一下，通用PC和嵌入式系统为何会在此处存在如此的差异呢？
）
Bootloader是基于特定硬件平台来实现的，因此几乎不可能为所有的嵌入式系统建立一个通用的Bootloader，不同的处理器架构都有不同的Bootloader，Bootloader不但依赖于cpu的体系结构，还依赖于嵌入式系统板级设备的配置。
对于2块不同的板子而言，即使他们使用的是相同的处理器，要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上，一般也需要修改Bootloader的源程序。
Bootloader的启动方式
Bootloader的启动方式主要有网络启动方式、磁盘启动方式和Flash启动方式。
1、网络启动方式
图1
Bootloader网络启动方式示意图
如图1所示，里面主机和目标板，他们中间通过网络来连接，首先目标板的DHCP/BIOS通过BOOTP服务来为Bootloader分配IP地址，配置网络参数，这样才能支持网络传输功能。
我们使用的u-boot可以直接设置网络参数，因此这里就不用使用DHCP的方式动态分配IP了。
接下来目标板的Bootloader通过TFTP服务将内核映像下载到目标板上，然后通过网络文件系统来建立主机与目标板之间的文件通信过程，之后的系统更新通常也是使用BootLoader的这种工作模式。
工作于这种模式下的BootLoader通常都会向它的终端用户提供一个简单的命令行接口。
2、磁盘启动方式
这种方式主要是用在台式机和服务器上的，这些计算机都使用BIOS引导，并且使用磁盘作为存储介质，这里面两个重要的用来启动linux的有LILO和GRUB，这里就不再具体说明了。
3、Flash启动方式
这是我们最常用的方式。
Flash有NORFlash和NANDFlash两种。
NORFlash可以支持随机访问，所以代码可以直接在Flash上执行，Bootloader一般是存储在Flash芯片上的。
另外Flash上还存储着参数、内核映像和文件系统。
这种启动方式与网络启动方式之间的不同之处就在于，在网络启动方式中，内核映像和文件系统首先是放在主机上的，然后经过网络传输下载进目标板的，而这种启动方式中内核映像和文件系统则直接是放在Flash中的，这两点在我们u-boot的使用过程中都用到了。
U-boot的定义
U-boot，全称UniversalBootLoader，是由DENX小组的开发的遵循GPL条款的开放源码项目，它的主要功能是完成硬件设备初始化、操作系统代码搬运，并提供一个控制台及一个指令集在操作系统运行前操控硬件设备。
U-boot之所以这么通用，原因是他具有很多特点：
开放源代码、支持多种嵌入式操作系统内核、支持多种处理器系列、较高的稳定性、高度灵活的功能设置、丰富的设备驱动源码以及较为丰富的开发调试文档与强大的网络技术支持。
另外u-boot对操作系统和产品研发提供了灵活丰富的支持，主要表现在：
可以引导压缩或非压缩系统内核，可以灵活设置/传递多个关键参数给操作系统，适合系统在不同开发阶段的调试要求与产品发布，支持多种文件系统，支持多种目标板环境参数存储介质，采用CRC32校验，可校验内核及镜像文件是否完好，提供多种控制台接口，使用户可以在不需要ICE的情况下通过串口/以太网/USB等接口下载数据并烧录到存储设备中去（这个功能在实际的产品中是很实用的，尤其是在软件现场升级的时候），以及提供丰富的设备驱动等。
u-boot源代码的目录结构
1、board中存放于开发板相关的配置文件，每一个开发板都以子文件夹的形式出现。
2、Commom文件夹实现u-boot行下支持的命令，每一个命令对应一个文件。
3、cpu中存放特定cpu架构相关的目录，每一款cpu架构都对应了一个子目录。
4、Doc是文档目录，有u-boot非常完善的文档。
5、Drivers中是u-boot支持的各种设备的驱动程序。
6、Fs是支持的文件系统，其中最常用的是JFFS2文件系统。
7、Include文件夹是u-boot使用的头文件，还有各种硬件平台支持的汇编文件，系统配置文件和文件系统支持的文件。
8、Net是与网络协议相关的代码，bootp协议、TFTP协议、NFS文件系统得实现。
9、Tooles是生成U-boot的工具。
对u-boot的目录有了一些了解后，分析启动代码的过程就方便多了，其中比较重要的目录就是/board、/cpu、/drivers和/include目录，如果想实现u-boot在一个平台上的移植，就要对这些目录进行深入的分析。
什么是《编译地址》？
什么是《运行地址》？
（一）编译地址：
32位的处理器，它的每一条指令是4个字节，以4个字节存储顺序，进行顺序执行，CPU是顺序执行的，只要没发生什么跳转，它会顺序进行执行行，编译器会对每一条指令分配一个编译地址，这是编译器分配的，在编译过程中分配的地址，我们称之为编译地址。
（二）运行地址：
是指程序指令真正运行的地址，是由用户指定的，用户将运行地址烧录到哪里，哪里就是运行的地址。
比如有一个指令的编译地址是0x5，实际运行的地址是0x200，如果用户将指令烧到0x200上，那么这条指令的运行地址就是0x200，
当编译地址和运行地址不同的时候会出现什么结果？
结果是不能跳转，编译后会产生跳转地址，如果实际地址和编译后产生的地址不相等，那么就不能跳转。
C语言编译地址：
都希望把编译地址和实际运行地址放在一起的，但是汇编代码因为不需要做C语言到汇编的转换，可以认为的去写地址，所以直接写的就是他的运行地址这就是为什么任何bootloader刚开始会有一段汇编代码，因为起始代码编译地址和实际地址不相等，这段代码和汇编无关，跳转用的运行地址。
编译地址和运行地址如何来算呢？
1.
假如有两个编译地址a=0x10，b=0x7，b的运行地址是0x300，那么a的运行地址就是b的运行地址加上两者编译地址的差值，a-b=0x10-0x7=0x3，
a的运行地址就是0x300+0x3=0x303。
2.
假设uboot上两条指令的编译地址为a=0x33000007和b=0x33000001，这两条指令都落在bank6上，现在要计算出他们对应的运行地址，要找出运行地址的始地址，这个是由用户烧录进去的，假设运行地址的首地址是0x0，则a的运行地址为0x7，b为0x1，就是这样算出来的。
为什么要分配编译地址？
这样做有什么好处，有什么作用？
比如在函数a中定义了函数b，当执行到函数b时要进行指令跳转，要跳转到b函数所对应的起始地址上去，编译时，编译器给每条指令都分配了编译地址，如果编译器已经给分配了地址就可以直接进行跳转，查找b函数跳转指令所对应的表，进行直接跳转，因为有个编译地址和指令对应的一个表，如果没有分配，编译器就查找不到这个跳转地址，要进行计算，非常麻烦。
什么是《相对地址》？
以NORFlash为例，NORFalsh是映射到bank0上面，SDRAM是映射到bank6上，uboot和内核最终是在SDRAM上面运行，最开始我们是从NorFlash的零地址开始往后烧录，uboot中至少有一段代码编译地址和运行地址是不一样的，编译uboot或内核时，都会将编译地址放入到SDRAM中，他们最终都会在SDRAM中执行，刚开始uboot在NorFlash中运行，运行地址是一个低端地址，是bank0中的一个地址，但编译地址是bank6中的地址，这样就会导致绝对跳转指令执行的失败，所以就引出了相对地址的概念。
那么什么是相对地址呢？
至少在bank0中uboot这段代码要知道不能用b+编译地址这样的方法去跳转指令，因为这段代码的编译地址和运行地址不一样，那如何去做呢？
要去计算这个指令运行的真实地址，计算出来后再做跳转，应该是b+运行地址，不能出现b+编译地址，而是b+运行地址，而运行地址是算出来的。
_TEXT_BASE:
.wordTEXT_BASE//0x33F80000,在board/config.mk中
这段话表示，用户告诉编译器编译地址的起始地址
-------------------------------------------------------------------------------------------------------------------------------------------
U-Boot工作过程
大多数BootLoader都包含两种不同的操作模式:
"
启动加载"
模式和"
下载"
模式,这种区别仅对于开发人员才有意义。
但从最终用户的角度看,BootLoader的作用就是:
用来加载操作系统,而并不存在所谓的启动加载模式与下载工作模式的区别。
（一）启动加载（Bootloading）模式:
这种模式也称为"
自主"
（Autonomous）模式。
也即BootLoader从目标机上的某个固态存储设备上将操作系统加载到RAM中运行,整个过程并没有用户的介入。
这种模式是BootLoader的正常工作模式,因此在嵌入式产品发布的时侯,BootLoader显然必须工作在这种模式下。
（二）下载（Downloading）模式:
在这种模式下,目标机上的BootLoader将通过串口连接或网络连接等通信手段从主机（Host）下载文件,比如:
下载内核映像和根文件系统映像等。
从主机下载的文件通常首先被BootLoader保存到目标机的RAM中,然后再被BootLoader写到目标机上的FLASH类固态存储设备中。
BootLoader的这种模式通常在第一次安装内核与根文件系统时被使用;
此外,以后的系统更新也会使用BootLoader的这种工作模式。
工作于这种模式下的BootLoader通常都会向它的终端用户提供一个简单的命令行接口。
这种工作模式通常在第一次安装内核与跟文件系统时使用。
或者在系统更新时使用。
进行嵌入式系统调试时一般也让bootloader工作在这一模式下。
UBoot这样功能强大的BootLoader同时支持这两种工作模式,而且允许用户在这两种工作模式之间进行切换。
大多数bootloader都分为阶段1（stage1）和阶段2（stage2）两大部分,uboot也不例外。
依赖于CPU体系结构的代码（如CPU初始化代码等）通常都放在阶段1中且通常用汇编语言实现,而阶段2则通常用C语言来实现,这样可以实现复杂的功能,而且有更好的可读性和移植性。
第一、大概总结性得的分析
系统启动的入口点。
既然我们现在要分析u-boot的启动过程，就必须先找到u-boot最先实现的是哪些代码，最先完成的是哪些任务。
另一方面一个可执行的image必须有一个入口点，并且只能有一个全局入口点，所以要通知编译器这个入口在哪里。
由此我们可以找到程序的入口点是在/board/lpc2210/u-boot.lds中指定的，其中ENTRY（_start）说明程序从_start开始运行，而他指向的是cpu/arm7tdmi/start.o文件。
因为我们用的是ARM7TDMI的cpu架构，在复位后从地址0x00000000取它的第一条指令，所以我们将Flash映射到这个地址上，
这样在系统加电后，cpu将首先执行u-boot程序。
u-boot的启动过程是多阶段实现的，分了两个阶段。
依赖于cpu体系结构的代码（如设备初始化代码等）通常都放在stage1中，而且通常都是用汇编语言来实现，以达到短小精悍的目的。
而stage2则通常是用C语言来实现的，这样可以实现复杂的功能，而且代码具有更好的可读性和可移植性。
下面我们先详细分析下stage1中的代码，如图2所示：
图2
Start.s程序流程
代码真正开始是在_start，设置异常向量表，这样在cpu发生异常时就跳转到/cpu/arm7tdmi/interrupts中去执行相应得中断代码。
在interrupts文件中大部分的异常代码都没有实现具体的功能，只是打印一些异常消息，其中关键的是reset中断代码，跳到reset入口地址。
reset复位入口之前有一些段的声明。
1.在reset中，首先是将cpu设置为svc32模式下，并屏蔽所有irq和fiq。
2.在u-boot中除了定时器使用了中断外，其他的基本上都不需要使用中断，比如串口通信和网络等通信等，在u-boot中只要完成一些简单的通信就可以了，所以在这里屏蔽掉了所有的中断响应。
3.初始化外部总线。
这部分首先设置了I/O口功能，包括串口、网络接口等的设置，其他I/O口都设置为GPIO。
然后设置BCFG0~BCFG3，即外部总线控制器。
这里bank0对应Flash，设置为16位宽度，总线速度设为最慢，以实现稳定的操作；
Bank1对应DRAM，设置和Flash相同；
Bank2对应RTL8019。
4.接下来是cpu关键设置，包括系统重映射（告诉处理器在系统发生中断的时候到外部存储器中去读取中断向量表）和系统频率。
5.lowlevel_init，设定RAM的时序，并将中断控制器清零。
这些部分和特定的平台有关，但大致的流程都是一样的。
下面就是代码的搬移阶段了。
为了获得更快的执行速度，
通常把stage2加载到RAM空间中来执行，因此必须为加载BootLoader的stage2准备好一段可用的RAM空间范围。
空间大小最好是memorypage大小（通常是4KB）的倍数
一般而言，1M的RAM空间已经足够了。
flash中存储的u-boot可执行文件中，代码段、数据段以及BSS段都是首尾相连存储的，
所以在计算搬移大小的时候就是利用了用BSS段的首地址减去代码的首地址，这样算出来的就是实际使用的空间。
程序用一个循环将代码搬移到0x81180000，即RAM底端1M空间用来存储代码。
然后程序继续将中断向量表搬到RAM的顶端。
由于stage2通常是C语言执行代码，所以还要建立堆栈去。
在堆栈区之前还要将malloc分配的空间以及全局数据所需的空间空下来，他们的大小是由宏定义给出的，可以在相应位置修改。
基本内存分布图：
图3
搬移后内存分布情况图
下来是u-boot启动的第二个阶段，是用c代码写的，
这部分是一些相对变化不大的部分，我们针对不同的板子改变它调用的一些初始化函数，并且通过设置一些宏定义来改变初始化的流程，
所以这些代码在移植的过程中并不需要修改，也是错误相对较少出现的文件。
在文件的开始先是定义了一个函数指针数组，通过这个数组，程序通过一个循环来按顺序进行常规的初始化，并在其后通过一些宏定义来初始化一些特定的设备。
在最后程序进入一个循环，main_loop。
这个循环接收用户输入的命令，以设置参数或者进行启动引导。
本篇文章将分析重点放在了前面的start.s上，是因为这部分无论在移植还是在调试过程中都是最容易出问题的地方，要解决问题就需要程序员对代码进行修改，所以在这里简单介绍了一下start.s的基本流程，希望能对大家有所帮助
第二、代码分析
2.2阶段1介绍
uboot的stage1代码通常放在start.s文件中,它用汇编语言写成,其主要代码部分如下:
2.2.1定义入口
由于一个可执行的Image必须有一个入口点,并且只能有一个全局入口,通常这个入口放在ROM（Flash）的0x0
地址,因此,必须通知编译器以使其知道这个入口,该工作可通过修改连接器脚本来完成。
1.board/crane2410/uboot.lds:
ENTRY（_start）
==>
cpu/arm920t/start.S:
.globl_start
2.uboot代码区（TEXT_BASE=0x33F80000）定义在board/crane2410/config.mk
U-Boot启动内核的过程可以分为两个阶段，两个阶段的功能如下：
（1）第一阶段的功能
Ø
升级会员 