uboot启动代码详解.docx
《uboot启动代码详解.docx》由会员分享，可在线阅读，更多相关《uboot启动代码详解.docx（81页珍藏版）》请在冰点文库上搜索。
uboot启动代码详解
·1引言
在专用的嵌入式板子运行GNU/Linu*系统已经变得越来越流行。
一个嵌入式Linu*系统从软件的角度看通常可以分为四个层次：
1.引导加载程序。
固化在固件（firmware）中的boot代码，也就是BootLoader，它的启动通常分为两个阶段。
2.Linu*核。
特定于嵌入式板子的定制核以及核的启动参数。
3.文件系统。
包括根文件系统和建立于Flash存设备之上文件系统，rootfs。
4.用户应用程序。
特定于用户的应用程序。
有时在用户应用程序和核层之间可能还会包括一个嵌入式图形用户界面。
常用的嵌入式GUI有：
MicroWindows和MiniGUI等。
引导加载程序是系统加电后运行的第一段软件代码。
回忆一下PC的体系构造我们可以知道，PC机中的引导加载程序由BIOS（其本质就是一段固件程序）和位于硬盘MBR中的OSBootLoader〔比方，LILO和GRUB等〕一起组成。
BIOS在完成硬件检测和资源分配后，将硬盘MBR中的BootLoader读到系统的RAM中，然后将控制权交给OSBootLoader。
BootLoader的主要运行任务就是将核映象从硬盘上读到RAM中，然后跳转到核的入口点去运行，也即开场启动操作系统。
而在嵌入式系统中，通常并没有像BIOS那样的固件程序〔注，有的嵌入式CPU也会嵌一段短小的启动程序〕，因此整个系统的加载启动任务就完全由BootLoader来完成。
比方在一个基于ARM7TDMIcore的嵌入式系统中，系统在上电或复位时通常都从地址0*00000000处开场执行，而在这个地址处安排的通常就是系统的BootLoader程序。
·2bootloader简介
应用程序
文件系统
操作系统核
BootLoader
简单地说，BootLoader〔引导加载程序〕就是在操作系统核运行之前运行的一段小程序，它的作用就是加载操作系统，它是系统加电后运行的第一段软件代码。
通过这段代码实现硬件的初始化，建立存空间的映射图，为操作系统核准备好硬件环境并引导核的启动。
如上图所示的那样在设备的启动过程中bootloader位于最底层，首先被运行来引导操作系统运行，很容易可以看出bootloader是底层程序所以它的实现严重地依赖于硬件，特别是在嵌入式世界。
因此，在嵌入式世界里建立一个通用的BootLoader几乎是不可能的。
尽管如此，一些功能强大、支持硬件环境较多的BootLoader也被广阔的使用者和爱好者所支持，从而形成了一些被广泛认可的、较为通用的的bootloader实现。
2.1BootLoader所支持的CPU和嵌入式板
每种不同的CPU体系构造都有不同的BootLoader。
有些BootLoader也支持多种体系构造的CPU，比方U-Boot就同时支持ARM体系构造和MIPS体系构造。
除了依赖于CPU的体系构造外，BootLoader实际上也依赖于具体的嵌入式板级设备的配置。
这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种CPU而构建的，要想让运行在一块板子上的BootLoader程序也能运行在另一块板子上，通常也都需要修改BootLoader的源程序。
2.2BootLoader的安装媒介〔InstallationMedium〕
系统加电或复位后，所有的CPU通常都从*个由CPU制造商预先安排的地址上取指令。
比方，基于ARM7TDMIcore的CPU在复位时通常都从地址0*00000000取它的第一条指令。
而基于CPU构建的嵌入式系统通常都有*种类型的固态存储设备（比方：
ROM、EEPROM或FLASH等）被映射到这个预先安排的地址上。
因此在系统加电后，CPU将首先执行BootLoader程序。
下列图1就是一个同时装有BootLoader、核的启动参数、核映像和根文件系统映像的固态存储设备的典型空间分配构造图：
图1固态存储设备的典型空间分配构造
2.3BootLoader的启动过程:
单阶段（SingleStage）/多阶段（Multi-Stage）
通常多阶段的BootLoader能提供更为复杂的功能，以及更好的可移植性。
从固态存储设备上启动的BootLoader大多都是2阶段的启动过程，也即启动过程可以分为stage1和stage2两局部。
而至于在stage1和stage2具体完成哪些任务将在下面讨论。
2.4BootLoader的操作模式（OperationMode）
大多数BootLoader都包含两种不同的操作模式：
"启动加载"模式和"下载"模式，这种区别仅对于开发人员才有意义。
但从最终用户的角度看，BootLoader的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
启动加载〔Bootloading〕模式：
这种模式也称为"自主"〔Autonomous〕模式。
也即BootLoader从目标机上的*个固态存储设备上将操作系统加载到RAM中运行，整个过程并没有用户的介入。
这种模式是BootLoader的正常工作模式，因此在嵌入式产品发布的时侯，BootLoader显然必须工作在这种模式下。
下载〔Downloading〕模式：
在这种模式下，目标机上的BootLoader将通过串口连接或网络连接等通信手段从主机〔Host〕下载文件，比方：
下载核映像和根文件系统映像等。
从主机下载的文件通常首先被BootLoader保存到目标机的RAM中，然后再被BootLoader写到目标机上的FLASH类固态存储设备中。
BootLoader的这种模式通常在第一次安装核与根文件系统时被使用；此外，以后的系统更新也会使用BootLoader的这种工作模式。
工作于这种模式下的BootLoader通常都会向它的终端用户提供一个简单的菜单界面或命令行接口来接收要执行的操作。
像Blob或U-Boot等这样功能强大的BootLoader通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进展切换。
比方，Blob在启动时处于正常的启动加载模式，但是它会延时10秒等待终端用户按下任意键而将blob切换到下载模式。
如果在10秒没有用户按键，则blob继续启动Linu*核。
2.5常见的BootLoader
U-BOOT：
U-Boot是DasU-Boot的简称，其含义是UniversalBootLoader，是遵循GPL条款的开放源码工程。
uboot是一个庞大的公开源码的软件。
它支持一些系列的arm体系，包含常见的外设的驱动，是一个功能强大的板极支持包。
vivi：
vivi是国mizi公司开发的bootloader,适用于ARM9处理器。
Vivi也有两种工作模式：
启动加载模式和下载模式。
启动加载模式可以在一段时间后〔这个时间可更改〕自行启动linu*核，这是vivi的默认模式。
如果修改或更新需要进入下载模式，在下载模式下，vivi为用户提供一个命令行接口通过接口可以使用vivi提供的一些命令，来实现flash的烧写、管理、操作mtd分区信息、启动系统等功能。
2.6U-BOOT的目录构造
说明
board
和开发板相关的文件，每一个开发板都以一个子目录出现在当前目录中，比方：
smdk2410。
该子目录中存放于开发板相关的配置文件，如makefile和U-Boot.lds。
其中包含SDRAM初始化代码、Flash底层驱动、板级初始化文件。
config.mk定义了TE*T_BASE是代码在存的真实地址
mon
与体系构造无关的文件，实现各种命令的C文件。
该文件主要实现uboot命令行下支持的命令，每一条命令都对应一个文件。
例如bootm命令对应就是cmd_bootm.c。
cpu
与特定CPU架构相关目录，每一款uboot下支持的CPU在该目录下对应一个子目录，比方arm920t。
每个CPU子目录中都包括cpu.c和interrupt.c、start.S。
cpu.c初始化CPU、设置指令Cache和数据Cache等interrupt.c设置系统的各种中断和异常start.S是U-boot启动时执行的第一个文件，它主要做早期系统初始化，代码重定向和设置系统堆栈
disk
Disk分区处理代码，对磁盘的支持
doc
文档目录，uboot有非常完整的文档
drivers
Uboot支持的设备驱动程序都放在该目录，例如各种网卡、支持CFI的Flash、串口、USB等
fs
支持的文件系统，目前支持cramfs、fat、fdos、jffs2和registerfs
include
头文件，还有对各种硬件平台支持的汇编文件，系统配置文件和对文件系统支持的文件等。
该目录下的configs目录有与开发板相关的配置文件，如smdk2410.h。
该目录下的asm目录有与CPU体系构造相关的头文件，比方arm对应的就是asm-arm。
net
与网络协议栈相关的代码，BOOTP协议、TFTP协议、RARP和NFS文件系统的实现等
lib_***
与ARM体系构造相关的库文件。
如与arm相关的库放在lib_arm中
tools
生成uboot的工具，如mkimage，crc等等
·3BootLoader的主要任务与典型构造框架
从操作系统的角度看，BootLoader的总目标就是正确地调用核来执行。
另外，由于BootLoader的实现依赖于CPU的体系构造，因此大多数BootLoader都分为stage1和stage2两大局部。
依赖于CPU体系构造的代码，比方设备初始化代码等，通常都放在stage1中，而且通常都用汇编语言来实现，以到达短小精悍的目的。
而stage2则通常用C语言来实现，这样可以实现给复杂的功能，而且代码会具有更好的可读性和可移植性。
以u-boot为例，它启动过程的两个阶段（stage）如下：
·第一阶段（stage1）cpu/arm920t/start.S
依赖于CPU体系构造的代码〔如设备初始化代码等〕，一般用汇编语言来实现。
主要进展以下方面的设置：
设置ARM进入SVC模式、制止IRQ和FIQ、关闭看门狗、屏蔽所有中断。
设置时钟（FCLK,HCLK,PCLK）、清空I/Dcache、清空TLB、制止MMU和cache、配置存控制器、为搬运代码做准备、搬移uboot映像到RAM中〔使用copy_loop实现〕、分配堆栈、清空bss段〔使用clbss_l实现〕。
最后通过ldrpc,_start_armboot跳转到第二阶段。
·第二阶段（stage2）lib_arm/board.c
该阶段主要都是用Ｃ语言来实现。
start_armboot（）进展一系列初始化〔cpu,板卡，中断，串口，控制台等〕，开启I/Dcache。
初始化FLASH，根据系统配置执行其他初始化操作。
打印LOG，使能中断，获取环境变量，初始化网卡。
最后进入main_loop（）函数。
综上所述，可简单的归纳两个阶段的功能如下：
·第一阶段的功能：
硬件设备初始化
加载U-Boot第二阶段代码到RAM空间
设置好栈
跳转到第二阶段代码入口
·第二阶段的功能：
初始化本阶段使用的硬件设备
检测系统存映射
将核从Flash读取到RAM中
为核设置启动参数
调用核
U-Boot启动第一阶段流程如下：
3.1u-boot的stage1详细分析
uboot的第一阶段设计的非常巧妙，几乎都是用汇编语言实现的。
首先我们来看一下它的脚本（u-boot-\board\smdk2410\u-boot.lds），通过它我们可以知道它整个程序的各个段是怎么存放的。
它定义了整个程序编译之后的连接过程，决定了一个可执行程序的各个段的存储位置。
/*指定输出可执行文件是elf格式,32位ARM指令,小端*/
OUTPUT_FORMAT（"elf32-littlearm","elf32-littlearm","elf32-littlearm"）
/*指定输出可执行文件的平台架构为ARM架构*/
OUTPUT_ARCH（arm）
/*指定输出可执行文件的起始代码段为_start*/
ENTRY（_start）
SECTIONS
{
.=0*00000000;//入口地址
.=ALIGN（4）;//四字节对齐
.te*t:
//代码段，上面3行标识是不占任何空间的
{
cpu/arm920t/start.o （.te*t）//这里将start.o放在第一位就表示把start.s编译时放在最开场，也就是uboot启动是最先执行start.S
*（.te*t）//所有的其他程序的代码段以四字节对齐放在它后面
}
.=ALIGN（4）;//前面的“.〞表示当前值
.rodata:
{*（.rodata）}//只读数据段
.=ALIGN（4）;
.data:
{*（.data）}//指定读/写数据段
.=ALIGN（4）;
.got:
{*（.got）}//指定got段，got段式是uboot自定义的一个段，非标准段
.=.;
__u_boot_cmd_start=.;//把__u_boot_cmd_start赋值为当前位置，即起始位置
.u_boot_cmd:
{*（.u_boot_cmd）}//指定u_boot_cmd段，uboot把所有的uboot命令放在该段
__u_boot_cmd_end=.;//把__u_boot_cmd_end赋值为当前位置，即完毕位置
.=ALIGN（4）;
__bss_start=.;//__bss_start赋值为当前位置，即bss段得开场位置
.bss:
{*（.bss）}
_end=.;//把_end赋值为当前位置，即bss段得完毕地址
}
从上面这段代码我们可以看出uboot运行的第一个程序是cpu/arm920t/start.S里面的第一个段_start。
我们查看start.S的源码。
3.1.1硬件设备初始化
〔1〕设置异常向量
cpu/arm920t/start.S开头有如下的代码：
//global用于声明一个符号可被其他文档引用，相当于声明了一个全局变量，.globl和.global一样。
//该局部为处理器的异常处理向量表。
地址围为0*00000000~0*00000020,刚好8条指令。
.globl_start/*u-boot启动入口*/
_start:
breset/*复位*/
ldrpc,_undefined_instruction/* 未定义指令向量*/
ldrpc,_software_interrupt/* 软件中断向量*/
ldrpc,_prefetch_abort/*预取指令异常向量*/
ldrpc,_data_abort/* 数据操作异常向量*/
ldrpc,_not_used/*未使用*/
ldrpc,_irq/*irq中断向量*/
ldrpc,_fiq/*fiq中断向量*/
/*中断向量表入口地址*/
//.word伪操作用于分配一段字存单元〔分配的单元都是字对齐的〕，并用伪操作中的e*pr初始化。
.long和.int作用与之一样。
_undefined_instruction:
.wordundefined_instruction
_software_interrupt:
.wordsoftware_interrupt
_prefetch_abort:
.wordprefetch_abort
_data_abort:
.worddata_abort
_not_used:
.wordnot_used
_irq:
.wordirq
_fiq:
.wordfiq
.balignl16,0*deadbeef
以上代码设置了ARM异常向量表，各个异常向量介绍如下：
地址
异常
进入模式
描述
0*00000000
复位
管理模式
复位电平有效时，产生复位异常，程序跳转到复位处理程序处执行
0*00000004
未定义指令
未定义模式
遇到不能处理的指令时产生未定义指令异常
0*00000008
软件中断
管理模式
执行SWI指令产生，用于用户模式下的程序调用特权操作指令
0*0000000c
预存指令
中止模式
处理器预取指令的地址不存在，或该地址不允许当前指令访问，产生指令预取中止异常
0*00000010
数据操作
中止模式
处理器数据访问指令的地址不存在或该地址不允许当前指令访问时，产生数据中止异常
0*00000014
未使用
未使用
未使用
0*00000018
IRQ
IRQ
外部中断请求有效，且CPSR中的I位为0时，产生IRQ异常
0*0000001c
FIQ
FIQ
快速中断请求引脚有效，且CPSR中的F位为0时，产生FIQ异常
在cpu/arm920t/start.S中还有这些异常对应的异常处理程序。
当一个异常产生时，CPU根据异常号在异常向量表中找到对应的异常向量，然后执行异常向量处的跳转指令，CPU就跳转到对应的异常处理程序执行。
其中复位异常向量的指令“breset〞决定了U-Boot启动后将自动跳转到标号reset处执行。
许多人都认为_start的值是0*00000000,为什么是这个地址呢"因为连接脚本上指定了。
真的是这样吗？
我们来看看我们编译好之后，在u-boot目录下有个System.map，这里面有各个变量的值,其中会告诉你，_start的值为：
0*33f80000。
注意，这里有两个地址：
编译地址和运行地址。
什么是编译地址？
什么是运行地址？
32位的处理器，它的每一条指令是4个字节，以4个字节存储顺序，进展顺序执行，CPU是顺序执行的，只要没发生什么跳转，它会顺序进展执行，编译器会对每一条指令分配一个编译地址，这是编译器分配的，在编译过程中分配的地址，我们称之为编译地址。
运行地址是指，程序指令真正运行的地址，是由用户指定的，用户将运行地址烧录到哪里，哪里就是运行的地址。
编译地址和运行地址如何来算呢？
假设有两个编译地址a=0*10，b=0*7，b的运行地址是0*300，则a的运行地址就是b的运行地址加上两者编译地址的差值，a-b=0*10-0*7=0*3，a的运行地址就是0*300+0*3=0*303。
〔2〕CPU进入SVC模式
start_code:
/*
*setthecputoSVC32mode
*/
mrsr0,cpsr
bicr0,r0,*0*1f/*工作模式位清零*/
orrr0,r0,*0*d3/*工作模式位设置为“10011”〔管理模式〕，并将中断制止位和快中断制止位置1*/
msrcpsr,r0
以上代码将CPU的工作模式位设置为管理模式，并将中断制止位和快中断制止位置一，从而屏蔽了IRQ和FIQ中断。
〔3〕设置控制存放器地址
*ifdefined（CONFIG_S3C2400）
*definepWTCON0*15300000
*defineINTMSK0*14400008
*defineCLKDIVN0*14800014
*else/*s3c2410与s3c2440下面4个存放器地址一样*/
*definepWTCON0*53000000/*WATCHDOG控制存放器地址*/
*defineINTMSK0*4A000008/*INTMSK存放器地址*/
*defineINTSUBMSK0*4A00001C/*INTSUBMSK存放器地址*/
*defineCLKDIVN0*4C000014/*CLKDIVN存放器地址*/
*endif
对于s3c2440开发板，以上代码完成了WATCHDOG，INTMSK，INTSUBMSK，CLKDIVN四个存放器的地址的设置。
〔4〕关闭看门狗
ldrr0,=pWTCON
movr1,*0*0
strr1,[r0]/*看门狗控制器的最低位为0时，看门狗不输出复位信号*/
以上代码向看门狗控制存放器写入0，关闭看门狗。
为什么需要关闭看门狗呢？
这里有个喂狗的过程，所谓的喂狗是每隔一段时间给*个存放器置位而已，在实际中会专门启动一个线程或进程会专门喂狗，当上层软件出现故障时就会停顿喂狗，停顿喂狗之后，cpu会自动复位，一般都在外部专门有一个看门狗，做一个外部的电路，不在cpu部使用看门狗，否则在U-Boot启动过程中，CPU将不断重启。
〔5〕屏蔽中断
/*
*maskallIRQsbysettingallbitsintheINTMR-default
*/
movr1,*0*ffffffff/**位被置1则对应的中断被屏蔽*/
ldrr0,=INTMSK
strr1,[r0]
INTMSK是主中断屏蔽存放器，每一位对应SRCPND〔中断源引脚存放器〕中的一位，说明SRCPND相应位代表的中断请否被CPU所处理。
INTMSK存放器是一个32位的存放器，每位对应一个中断，向其中写入0*ffffffff就将INTMSK存放器全部位置1，从而屏蔽对应的中断。
为什么要关闭中断呢？
中断处理〔ldrpc..〕是将代码的编译地址放在了指针上，而这段时间还没有搬移代码，所以不能进展跳转。
*ifdefined（CONFIG_S3C2440）
ldrr1,=0*7fff
ldrr0,=INTSUBMSK
strr1,[r0]
*endif
INTSUBMSK每一位对应SUBSRCPND中的一位，说明SUBSRCPND相应位代表的中断请否被CPU所处理。
INTSUBMSK存放器是一个32位的存放器，但是只使用了低15位。
向其中写入0*7fff就是将INTSUBMSK存放器全部有效位〔低15位〕置1，从而屏蔽对应的中断。
〔6〕设置MPLLCON,UPLLCON,CLKDIVN
*ifdefined（CONFIG_S3C2440）
*defineMPLLCON0*4C000004
*defineUPLLCON0*4C000008
ldrr0,=CLKDIVN
movr1,*5
strr1,[r0]
l
升级会员 