1、uboot启动代码详解1 引言在专用的嵌入式板子运行 GNU/Linu* 系统已经变得越来越流行。一个嵌入式 Linu* 系统从软件的角度看通常可以分为四个层次：1. 引导加载程序。固化在固件(firmware)中的 boot 代码，也就是 Boot Loader，它的启动通常分为两个阶段。2.Linu* 核。特定于嵌入式板子的定制核以及核的启动参数。3.文件系统。包括根文件系统和建立于 Flash 存设备之上文件系统，root fs。4.用户应用程序。特定于用户的应用程序。有时在用户应用程序和核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式 GUI 有：MicroWindows 和
2、MiniGUI 等。引导加载程序是系统加电后运行的第一段软件代码。回忆一下 PC 的体系构造我们可以知道，PC 机中的引导加载程序由 BIOS(其本质就是一段固件程序)和位于硬盘 MBR 中的 OS Boot Loader比方，LILO 和 GRUB 等一起组成。BIOS 在完成硬件检测和资源分配后，将硬盘 MBR 中的 Boot Loader 读到系统的 RAM 中，然后将控制权交给 OS Boot Loader。Boot Loader 的主要运行任务就是将核映象从硬盘上读到 RAM 中，然后跳转到核的入口点去运行，也即开场启动操作系统。而在嵌入式系统中，通常并没有像 BIOS 那样的固件程
3、序注，有的嵌入式 CPU 也会嵌一段短小的启动程序，因此整个系统的加载启动任务就完全由 Boot Loader 来完成。比方在一个基于 ARM7TDMI core 的嵌入式系统中，系统在上电或复位时通常都从地址 0*00000000 处开场执行，而在这个地址处安排的通常就是系统的 Boot Loader 程序。2bootloader简介应用程序文件系统操作系统核BootLoader简单地说，Boot Loader 引导加载程序就是在操作系统核运行之前运行的一段小程序，它的作用就是加载操作系统，它是系统加电后运行的第一段软件代码。通过这段代码实现硬件的初始化，建立存空间的映射图，为操作系统核准备
4、好硬件环境并引导核的启动。如上图所示的那样在设备的启动过程中bootloader位于最底层，首先被运行来引导操作系统运行，很容易可以看出 bootloader是底层程序所以它的实现严重地依赖于硬件，特别是在嵌入式世界。因此，在嵌入式世界里建立一个通用的BootLoader几乎是不可能的。尽管如此，一些功能强大、支持硬件环境较多的BootLoader也被广阔的使用者和爱好者所支持，从而形成了一些被广泛认可的、较为通用的的bootloader实现。2.1 Boot Loader 所支持的 CPU 和嵌入式板每种不同的 CPU 体系构造都有不同的 Boot Loader。有些 Boot Loader
5、 也支持多种体系构造的 CPU，比方 U-Boot 就同时支持 ARM 体系构造和MIPS 体系构造。除了依赖于 CPU 的体系构造外，Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 而构建的，要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上，通常也都需要修改 Boot Loader 的源程序。2.2 Boot Loader 的安装媒介Installation Medium系统加电或复位后，所有的 CPU 通常都从*个由 CPU 制造商预先安排的地址上取指令。比方，基于 ARM7
6、TDMI core 的 CPU 在复位时通常都从地址 0*00000000 取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有*种类型的固态存储设备(比方：ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU 将首先执行 Boot Loader 程序。下列图1就是一个同时装有 Boot Loader、核的启动参数、核映像和根文件系统映像的固态存储设备的典型空间分配构造图：图1 固态存储设备的典型空间分配构造2.3Boot Loader 的启动过程:单阶段(Single Stage)/多阶段(Multi-Stage)通常多阶段的 Boot Lo
7、ader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1 和 stage 2 两局部。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面讨论。2.4 Boot Loader 的操作模式 (Operation Mode)大多数 Boot Loader 都包含两种不同的操作模式：启动加载模式和下载模式，这种区别仅对于开发人员才有意义。但从最终用户的角度看，Boot Loader 的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。启动加载Boo
8、t loading模式：这种模式也称为自主Autonomous模式。也即 Boot Loader 从目标机上的*个固态存储设备上将操作系统加载到 RAM 中运行，整个过程并没有用户的介入。这种模式是 Boot Loader 的正常工作模式，因此在嵌入式产品发布的时侯，Boot Loader 显然必须工作在这种模式下。下载Downloading模式：在这种模式下，目标机上的 Boot Loader 将通过串口连接或网络连接等通信手段从主机Host下载文件，比方：下载核映像和根文件系统映像等。从主机下载的文件通常首先被 Boot Loader 保存到目标机的 RAM 中，然后再被 Boot Loa
9、der 写到目标机上的FLASH 类固态存储设备中。Boot Loader 的这种模式通常在第一次安装核与根文件系统时被使用；此外，以后的系统更新也会使用 Boot Loader 的这种工作模式。工作于这种模式下的 Boot Loader 通常都会向它的终端用户提供一个简单的菜单界面或命令行接口来接收要执行的操作。像 Blob 或 U-Boot 等这样功能强大的 Boot Loader 通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进展切换。比方，Blob 在启动时处于正常的启动加载模式，但是它会延时 10 秒等待终端用户按下任意键而将 blob 切换到下载模式。如果在 10 秒
10、没有用户按键，则 blob 继续启动 Linu* 核。2.5常见的Boot LoaderU-BOOT：U-Boot是Das U-Boot的简称，其含义是Universal Boot Loader，是遵循GPL条款的开放源码工程。uboot是一个庞大的公开源码的软件。它支持一些系列的arm体系，包含常见的外设的驱动，是一个功能强大的板极支持包。vivi：vivi是国mizi 公司开发的bootloader, 适用于ARM9处理器。 Vivi也有两种工作模式：启动加载模式和下载模式。启动加载模式可以在一段时间后这个时间可更改自行启动linu*核，这是vivi的默认模式。如果修改或更新需要进入下载模
11、式，在下载模式下，vivi为用户提供一个命令行接口通过接口可以使用vivi提供的一些命令，来实现flash的烧写、管理、操作mtd分区信息、启动系统等功能。2.6U-BOOT的目录构造说明board和开发板相关的文件，每一个开发板都以一个子目录出现在当前目录中，比方：smdk2410。该子目录中存放于开发板相关的配置文件，如makefile和U-Boot.lds。其中包含SDRAM初始化代码、Flash底层驱动、板级初始化文件。config.mk定义了TE*T_BASE是代码在存的真实地址mon与体系构造无关的文件，实现各种命令的C文件。该文件主要实现uboot命令行下支持的命令，每一条命令都
12、对应一个文件。例如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启动时执行的第一个文件，它主要做早期系统初始化，代码重定向和设置系统堆栈diskDisk分区处理代码，对磁盘的支持doc文档目录，uboot有非常完整的文档driversUboot支持的设备驱动程序都放在该目录，例如各
13、种网卡、支持CFI的Flash、串口、USB等fs支持的文件系统，目前支持cramfs、fat、fdos、jffs2和registerfsinclude头文件，还有对各种硬件平台支持的汇编文件，系统配置文件和对文件系统支持的文件等。该目录下的configs目录有与开发板相关的配置文件，如smdk2410.h。该目录下的asm目录有与CPU体系构造相关的头文件，比方arm对应的就是asm-arm。net与网络协议栈相关的代码，BOOTP协议、TFTP协议、RARP和NFS文件系统的实现等lib_*与ARM体系构造相关的库文件。如与arm相关的库放在lib_arm中tools生成uboot的工具，
14、如mkimage，crc等等3Boot Loader 的主要任务与典型构造框架从操作系统的角度看，Boot Loader 的总目标就是正确地调用核来执行。另外，由于 Boot Loader 的实现依赖于 CPU 的体系构造，因此大多数 Boot Loader 都分为 stage1 和 stage2 两大局部。依赖于 CPU 体系构造的代码，比方设备初始化代码等，通常都放在 stage1 中，而且通常都用汇编语言来实现，以到达短小精悍的目的。而 stage2 则通常用C语言来实现，这样可以实现给复杂的功能，而且代码会具有更好的可读性和可移植性。以u-boot为例，它启动过程的两个阶段(stage
15、)如下：第一阶段(stage 1) cpu/arm920t/start.S依赖于CPU体系构造的代码如设备初始化代码等，一般用汇编语言来实现。主要进展以下方面的设置：设置ARM进入SVC模式、制止IRQ和FIQ、关闭看门狗、屏蔽所有中断。设置时钟(FCLK,HCLK,PCLK)、清空I/D cache、清空TLB、制止MMU和cache、配置存控制器、为搬运代码做准备、搬移uboot映像到RAM中使用copy_loop实现、分配堆栈、清空bss段使用clbss_l实现。最后通过ldr pc, _start_armboot跳转到第二阶段。第二阶段(stage 2)lib_arm/board.c该
16、阶段主要都是用语言来实现。start_armboot()进展一系列初始化cpu, 板卡，中断，串口，控制台等，开启I/D cache。初始化FLASH，根据系统配置执行其他初始化操作。打印LOG，使能中断，获取环境变量，初始化网卡。最后进入main_loop()函数。综上所述，可简单的归纳两个阶段的功能如下：第一阶段的功能： 硬件设备初始化 加载U-Boot第二阶段代码到RAM空间 设置好栈 跳转到第二阶段代码入口第二阶段的功能： 初始化本阶段使用的硬件设备 检测系统存映射 将核从Flash读取到RAM中 为核设置启动参数 调用核U-Boot启动第一阶段流程如下：3.1 u-boot 的 st
17、age1详细分析uboot的第一阶段设计的非常巧妙，几乎都是用汇编语言实现的。首先我们来看一下它的脚本(u-boot-boardsmdk2410u-boot.lds)，通过它我们可以知道它整个程序的各个段是怎么存放的。它定义了整个程序编译之后的连接过程，决定了一个可执行程序的各个段的存储位置。/* 指定输出可执行文件是elf 格式,32 位ARM 指令,小端 */OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)/* 指定输出可执行文件的平台架构为ARM架构 */OUTPUT_ARCH(arm)/* 指定输出可执行文
18、件的起始代码段为_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) /
19、指定读/写数据段. = 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段得开场位置.
20、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
21、启动入口 */_start: b reset/* 复位 */ ldr pc, _undefined_instruction /*未定义指令向量 */ ldr pc, _software_interrupt /* 软件中断向量 */ ldr pc, _prefetch_abort /* 预取指令异常向量 */ ldr pc, _data_abort /* 数据操作异常向量 */ ldr pc, _not_used /* 未使用 */ ldr pc, _irq /* irq中断向量 */ ldr pc, _fiq /* fiq中断向量 */* 中断向量表入口地址 */.word 伪操作用于分配一段
22、字存单元分配的单元都是字对齐的，并用伪操作中的e*pr 初始化。.long 和.int 作用与之一样。_undefined_instruction: .word undefined_instruction_software_interrupt: .word software_interrupt_prefetch_abort: .word prefetch_abort_data_abort: .word data_abort_not_used: .word not_used_irq: .word irq_fiq: .word fiq .balignl 16,0*deadbeef以上代码设置了AR
23、M异常向量表，各个异常向量介绍如下：地址异常进入模式描述0*00000000复位管理模式复位电平有效时，产生复位异常，程序跳转到复位处理程序处执行0*00000004未定义指令未定义模式遇到不能处理的指令时产生未定义指令异常0*00000008软件中断管理模式执行SWI指令产生，用于用户模式下的程序调用特权操作指令0*0000000c预存指令中止模式处理器预取指令的地址不存在，或该地址不允许当前指令访问，产生指令预取中止异常0*00000010数据操作中止模式处理器数据访问指令的地址不存在或该地址不允许当前指令访问时，产生数据中止异常0*00000014未使用未使用未使用0*00000018I
24、RQIRQ外部中断请求有效，且CPSR中的I位为0时，产生IRQ异常0*0000001cFIQFIQ快速中断请求引脚有效，且CPSR中的F位为0时，产生FIQ异常在cpu/arm920t/start.S中还有这些异常对应的异常处理程序。当一个异常产生时，CPU根据异常号在异常向量表中找到对应的异常向量，然后执行异常向量处的跳转指令，CPU就跳转到对应的异常处理程序执行。其中复位异常向量的指令“b reset决定了U-Boot启动后将自动跳转到标号reset处执行。许多人都认为_start的值是0*00000000,为什么是这个地址呢 因为连接脚本上指定了。真的是这样吗？我们来看看我们编译好之后
25、，在u-boot目录下有个System.map，这里面有各个变量的值,其中会告诉你，_start的值为：0*33f80000。注意，这里有两个地址：编译地址和运行地址。什么是编译地址？什么是运行地址？ 32 位的处理器，它的每一条指令是4个字节，以4个字节存储顺序，进展顺序执行，CPU是顺序执行的，只要没发生什么跳转，它会顺序进展执行，编译器会对每一条指令分配一个编译地址，这是编译器分配的，在编译过程中分配的地址，我们称之为编译地址。运行地址是指，程序指令真正运行的地址，是由用户指定的，用户将运行地址烧录到哪里，哪里就是运行的地址。编译地址和运行地址如何来算呢？假设有两个编译地址a=0*10，
26、b=0*7，b的运行地址是0*300 ，则a的运行地址就是b的运行地址加上两者编译地址的差值，a-b=0*10-0*7=0*3，a的运行地址就是0*300+0*3=0*303。2CPU进入SVC模式start_code: /* * set the cpu to SVC32 mode*/ mrs r0, cpsr bic r0, r0, *0*1f /*工作模式位清零 */ orr r0, r0, *0*d3 /*工作模式位设置为“10011”管理模式，并将中断制止位和快中断制止位置1 */msr cpsr, r0以上代码将CPU的工作模式位设置为管理模式，并将中断制止位和快中断制止位置一，从而
27、屏蔽了IRQ和FIQ中断。3设置控制存放器地址*if defined(CONFIG_S3C2400)*define pWTCON 0*15300000*define INTMSK 0*14400008 *define CLKDIVN 0*14800014 *else /* s3c2410与s3c2440下面4个存放器地址一样 */*define pWTCON 0*53000000 /* WATCHDOG控制存放器地址 */*define INTMSK 0*4A000008 /* INTMSK存放器地址 */*define INTSUBMSK 0*4A00001C/* INTSUBMSK存放器地
28、址 */*define CLKDIVN 0*4C000014 /* CLKDIVN存放器地址 */* endif对于s3c2440开发板，以上代码完成了WATCHDOG，INTMSK，INTSUBMSK，CLKDIVN四个存放器的地址的设置。4关闭看门狗ldr r0, =pWTCON mov r1, *0*0str r1, r0 /* 看门狗控制器的最低位为0时，看门狗不输出复位信号 */以上代码向看门狗控制存放器写入0，关闭看门狗。为什么需要关闭看门狗呢？这里有个喂狗的过程，所谓的喂狗是每隔一段时间给*个存放器置位而已，在实际中会专门启动一个线程或进程会专门喂狗，当上层软件出现故障时就会停顿
29、喂狗，停顿喂狗之后，cpu会自动复位，一般都在外部专门有一个看门狗，做一个外部的电路，不在cpu部使用看门狗，否则在U-Boot启动过程中，CPU将不断重启。5屏蔽中断 /* * mask all IRQs by setting all bits in the INTMR - default */ mov r1, *0*ffffffff /* *位被置1则对应的中断被屏蔽 */ ldr r0, =INTMSK str r1, r0 INTMSK是主中断屏蔽存放器，每一位对应SRCPND中断源引脚存放器中的一位，说明SRCPND相应位代表的中断请否被CPU所处理。INTMSK存放器是一个32位的
30、存放器，每位对应一个中断，向其中写入0*ffffffff就将INTMSK存放器全部位置1，从而屏蔽对应的中断。为什么要关闭中断呢？中断处理ldr pc .是将代码的编译地址放在了指针上，而这段时间还没有搬移代码，所以不能进展跳转。*if defined(CONFIG_S3C2440)ldr r1, =0*7fffldr r0, =INTSUBMSKstr r1, r0*endifINTSUBMSK每一位对应SUBSRCPND中的一位，说明SUBSRCPND相应位代表的中断请否被CPU所处理。INTSUBMSK存放器是一个32位的存放器，但是只使用了低15位。向其中写入0*7fff就是将INTSUBMSK存放器全部有效位低15位置1，从而屏蔽对应的中断。6设置MPLLCON,UPLLCON, CLKDIVN*if defined(CONFIG_S3C2440)*define MPLLCON 0*4C000004*define UPLLCON 0*4C000008ldr r0, =CLKDIVNmov r1, *5str r1, r0l
