【嵌入式Linux学习七步曲之第三篇 Linux系统bootlaoder移植】U-BOOT全线移植分析系列之一－－BOOTLOADER介绍

 

 

U-BOOT全线移植分析系列之一

――――BOOTLOADER介绍

Sailor_forever  sailing_9806@163.com 转载请注明

http://blog.csdn.net/sailor_8318/archive/2008/08/04/2768049.aspx

 

 

【摘要】本节介绍了bootloader的基本概念。首先分析了为什么要针对特定的CPU和开发板移植bootloader的必要性。然后介绍了两种如何在裸板中烧写bootloader的方法以及如何确定烧写地址。其次介绍了产品发布的启动加载模式和开发使用的下载模式（更新内核文件系统及bootloader自身）。最后介绍了bootloader的两个通用启动阶段的流程及代码特性和运行位置。

 

【关键词】bootloader，烧写，复位地址，固化loader，启动加载，stage1，位置无关

 

一 bootloader介绍

1.1 Bootloader移植的必要性

Bootloader是与系统硬件环境高度相关的初始化软件，它担负着初始化硬件和引导操作系统的双重责任。一些ARM平台可以共用同一种Bootloader，但是总的说来，每一个特定系统的Bootloader都会有所不同。Bootloader广泛用于有操作系统的手持终端设备、智能家电及机顶盒等嵌入式设备上，它负责完成硬件初始化、操作系统引导和系统配制等。Bootloader移植是在特定硬件平台上操作系统移植至关重要的一步。

 

1.2 BootLoader所支持的CPU和嵌入式系统板

每种不同的CPU体系结构都有不同的BootLoader。有些BootLoader也支持多种体系结构的CPU，比如U-BOOT就同时支持ARM、MIPS、POWERPC等体系结构。除了依赖于CPU的体系结构外，BootLoader实际上也依赖于具体的嵌入式板级设备的配置。也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种CPU而构建的，要想让运行在一块板子上的BootLoader程序也能运行在另一块板子上，通常也都需要修改BootLoader的源程序。

 

1.3. Boot Loader的烧录和存储

系统加电或复位后，所有的CPU通常都从某个由CPU制造商预先安排的地址上取指令。比如，at91rm9200的CPU在复位时通常都从地址0x00000000取它的第一条指令。而MPC8260高端启动则时从0xfff00000开始取指。这个地址依据特定的CPU而定。通常片外启动时，基于CPU构建的嵌入式系统通常都有某种类型的固态存储设备（EEPROM或FLASH等，at91rm9200是0x10000000)被映射到这个预先安排的地址上。因此在系统加电后，CPU将首先执行Boot Loader程序。

 

那么bootloader最初是怎么烧写到flash中的呢？对于一个裸板怎么让它跑起来呢?有两种方式：

²      通过片内固化的loader加载bootloader：通常某些CPU内部ROM中固化了一段程序可以用于最初的程序下载，如AT91RM9200。这时下载的程序是在内部RAM中运行的，大小有一定限制，然后由这段程序继续交互下载真正要烧写到flash中的程序，将其保存在外部RAM中，最终烧写到flash中。

²      通过JTAG或者仿真器下载：通常这些烧录工具可以直接操作flash，对其进行编程烧录。需要专门的工具。这种情况多用于那些没有固化loader的CPU，如三星系列。

 

上图是一个同时装有Boot Loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。上述顺序是可变的，但bootloader首地址一定要在CPU复位取指的地址上。

 

1.4 Boot Loader的操作模式(Operation Mode)

主机和目标机之间一般通过串口建立连接，BootLoader软件在执行时通常会通过串口来进行数据传输，如输出打印信息到串口，从串口读取用户控制字符。

 

大多数Boot Loader都包含两种不同的操作模式：启动加载模式和下载模式，这种区别仅对于开发人员才有意义。从最终用户的角度看，BootLoader的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。

²      启动加载(Boot loading)模式：这种模式也称为自主模式bootstrap。也即Boot Loader将存储在目标板Flash中的内核和文件系统的镜像装载到SDRAM中，整个过程无需用户的介入。这种模式是BootLoader的正常工作模式，因此在嵌入式产品发布的时候，BootLoader显然必须工作在这种模式下。

²      下载Downloading模式：在这种模式下，目标机上的BootLoader将通过串口连接或网络连接等通信手段从宿主机Host下载文件，比如下载内核映像和根文件系统映像等。从主机下载的文件通常首先被BootLoader保存到目标机的RAM中，然后再被BootLoader写到目标机上的FLASH类固态存储设备中。BootLoader的这种模式通常在第一次安装内核与根文件系统时被使用；此外，以后的系统更新（bootloader自身也可以这样更新）也会使用Boot Loader的这种工作模式。工作于这种模式下的BootLoader通常都会向它的终端用户提供一些简单的命令行接口。

 

像U-BOOT等这样功能强大的BootLoader通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进行切换。比如，U-BOOT在启动时处于正常的启动加载模式，但是它会延时几秒(在配置文件中可以设定)等待终端用户按下任意键而将其切换到下载模式（相当于bios下按del键可进入系统配置界面一样，设置从光盘启动可进行重装），如果在给定时间内没有用户按键，则U-BOOT继续启动，进行正常的启动加载。

 

1.5 Bootloader与主机之间进行文件传输所用的通信设备及协议

最常见的情况就是，目标机上的BootLoader通过串口与主机之间进行文件传输，传输协议通常是kermit / xmodem / ymodem协议中的一种。但是，串口传输的速度是有限的，因此如果该Bootloader对目标板的网卡支持良好，还可以通过以太网连接并借助TFTP (Trivial File Transfer Protocol)协议来下载文件是个更好的选择。此时，主机方所用的软件也要考虑，比如，在通过以太网连接和TFTP协议来下载文件时，主机方必须有一个软件用来提供TFTP服务，如Windows平台上的tftpd.exe等或Linux下面的tftp服务器。

 

1.6 Bootloader的通用执行流程

从操作系统的角度看，Bootloader的总目标就是正确地调用内核来执行。另外，由于Bootloader的实现依赖于 CPU的体系结构，因此大多数Bootloader都分为stagel和stage2两大部分。依赖于CPU体系结构的代码，比如设备初始化代码等，通常都放在stagel中，而且通常都用汇编语言来实现，以达到短小精悍和高效的目的。而stage2则通常用C语言来实现，这样可以实现更复杂的功能，而且代码会具有更好的可读性和可移植性。

 

Bootloader的stagel为位置无关代码，通常在FLASH中运行。所有的指令为相对寻址，可以在任何位置运行。通常包括以下步骤(以执行的先后顺序)：

Ø       硬件设备初始化（配置SDRAM存储控制器及IO），中断初始化；

Ø       为加载Bootloader的stage2准备RAM空间（这个地址由链接脚本指定，为运行域地址，通常为RAM的高端地址），测试内存空间是否有效；

Ø       拷贝Bootloader的stage2到RAM空间中；

Ø       设置好堆栈；

Ø       跳转到stage2的C入口点。

 

Bootloader的stage2通常被拷贝到RAM中运行，这样可以提高运行速度。通常包括以下步骤(以执行的先后顺序)：

Ø       初始化本阶段要使用到的硬件设备；

Ø       检测系统内存映射(memory map)；

Ø       没有用户干预时将kernel映像和根文件系统映像从flash读到RAM空间中；

Ø       为内核设置启动参数；

Ø       调用内核。