在嵌入式操作系统中，BootLoader是在操作系统内核运行之前运行。可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。在嵌入式系统中，通常并没有像BIOS那样的固件程序（注，有的嵌入式CPU也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由BootLoader来完成。在一个基于ARM7TDMI core的嵌入式系统中，系统在上电或复位时通常都从地址0x00000000处开始执行，而在这个地址处安排的通常就是系统的BootLoader程序。

Bootloader是嵌入式系统在加电后执行的第一段代码，在它完成CPU和相关硬件的初始化之后，再将操作系统映像或固化的嵌入式应用程序装载到内存中然后跳转到操作系统所在的空间，启动操作系统运行。

对于嵌入式系统，Bootloader是基于特定硬件平台来实现的。因此，几乎不可能为所有的嵌入式系统建立一个通用的Bootloader，不同的处理器架构都有不同的Bootloader。Bootloader不但依赖于CPU的体系结构，而且依赖于嵌入式系统板级设备的配置。对于2块不同的嵌入式板而言，即使它们使用同一种处理器，要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上，一般也都需要修改Bootloader的源程序。

反过来，大部分Bootloader仍然具有很多共性，某些Bootloader也能够支持多种体系结构的嵌入式系统。例如，U-Boot就同时支持PowerPC、ARM、MIPS和X86等体系结构，支持的板子有上百种。通常，它们都能够自动从存储介质上启动，都能够引导操作系统启动，并且大部分都可以支持串口和以太网接口。

通常，BootLoader是严重地依赖于硬件而实现的，特别是在嵌入式平台。因此，在嵌入式平台里建立一个通用的BootLoader几乎是不可能的。尽管如此，我们仍然可以对bootloader归纳出一些通用的概念来，以指导用户特定的BootLoader设计与实现。

在专用的嵌入式板子运行GNU/Linux系统已经变得越来越流行。一个嵌入式Linux系统从软件的角度看通常可以分为四个层次：

1、 引导加载程序:包括固化在固件(firmware)中的boot代码(可选)，和BootLoader两大部分。

2、Linux内核:特定于嵌入式板子的定制内核以及内核的启动参数。

3、 文件系统:包括根文件系统和建立于Flash内存设备之上文件系统。通常用ramdisk来作为rootfs。

4、 用户应用程序:特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式GUI有：MicroWindows和MiniGUI等。

大多数Bootloader都包含两种不同的操作模式：

(1)启动加载模式

在这种模式下，Bootloader从目标机的某个固态存储设备上将操作系统加载到RAM中运行，整个过程并没有用户的介入。这种模式是Bootloader的正常工作模式，因此在嵌入式产品发布时，Bootloader必须工作在这种模式下。

(2)下载模式

在这种模式下，目标机上的Bootloader将通过串口或网络等通信手段从开发主机(Host)上下载内核映像和根文件系统映像等到RAM中，然后可再被Bootloader写到目标机上的固态存储媒质中，或者直接进行系统的引导。

启动加载模式通常用于第一次烧写内核与根文件系统到固态存储媒质时或者以后的系统更新时使用；下载模式多用于开发人员在前期开发的过程中，工作于这种模式下的Bootloader通常都会向它的终端用户提供一个简单的命令行接口。

Bootloader启动大多数都分为两个阶段。第一阶段主要包含依赖于CPU的体系结构硬件初始化的代码，通常都用汇编语言来实现。这个阶段的任务有：

基本的硬件设备初始化（屏蔽所有的中断、关闭处理器内部指令/数据Cache等）。

为第二阶段准备RAM空间。

如果是从某个固态存储媒质中，则复制Bootloader的第二阶段代码到RAM。

设置堆栈。

在第一阶段中为什么要关闭Cache？通常使用Cache以及写缓冲是为了提高系统性能，但由于Cache的使用可能改变访问主存的数量、类型和时间，因此Bootloader通常是不需要的。

跳转到第二阶段的C程序入口点。

第二阶段通常用C语言完成，以便实现更复杂的功能，也使程序有更好的可读性和可移植性。这个阶段的任务有：

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

检测系统内存映射。

将内核映像和根文件系统映像从Flash读到RAM。

为内核设置启动参数。

调用内核。

Redboot是Redhat公司随eCos发布的一个BOOT方案，是一个开源项目。

当前Redboot的最新版本是Redboot-2.0.1，Redhat公司将会继续支持该项目。

Redboot支持的处理器构架有ARM，MIPS，MN10300，PowerPC， Renesas SHx，v850，x86等，是一个完善的嵌入式系统Boot Loader。

Redboot是在ECOS的基础上剥离出来的，继承了ECOS的简洁、轻巧、可灵活配置、稳定可靠等品质优点。它可以使用X-modem或Y-modem协议经由串口下载，也可以经由以太网口通过BOOTP/DHCP服务获得IP参数，使用TFTP方式下载程序映像文件，常用于调试支持和系统初始化（Flash下载更新和网络启动）。Redboot可以通过串口和以太网口与GDB进行通信，调试应用程序，甚至能中断被GDB运行的应用程序。Redboot为管理FLASH映像，映像下载，Redboot配置以及其他如串口、以太网口提供了一个交互式命令行接口，自动启动后，REDBOOT用来从TFTP服务器或者从Flash下载映像文件加载系统的引导脚本文件保存在Flash上。当前支持单板机的移植版特性有：

- 支持ECOS，Linux操作系统引导

- 在线读写Flash

- 支持串行口kermit，S-record下载代码

- 监控(minitor)命令集:读写I/O，内存，寄存器、 内存、外设测试功能等

Redboot是标准的嵌入式调试和引导解决方案，支持几乎所有的处理器构架以及大量的外围硬件接口，并且还在不断地完善过程中。

ARMboot是一个ARM平台的开源固件项目，它特别基于PPCBoot，一个为PowerPC平台上的系统提供类似功能的姊妹项目。鉴于对PPCBoot的严重依赖性，已经与PPCBoot项目合并，新的项目为U-Boot。

ARMboot发布的最后版本为ARMboot-1.1.0，2002年ARMboot终止了维护。

ARMboot支持的处理器构架有StrongARM ，ARM720T ，PXA250 等，是为基于ARM或者StrongARM CPU的嵌入式系统所设计的。

ARMboot的目标是成为通用的、容易使用和移植的引导程序，非常轻便地运用于新的平台上。ARMboot是GPL下的ARM固件项目中唯一支持Flash闪存，BOOTP、DHCP、TFTP网络下载，PCMCLA寻线机等多种类型来引导系统的。特性为：

-支持多种类型的FLASH；

-允许映像文件经由BOOTP、DHCP、TFTP从网络传输；

-支持串行口下载S-record或者binary文件；

-允许内存的显示及修改；

-支持jffs2文件系统等。

Armboot对S3C44B0板的移植相对简单，在经过删减完整代码中的一部分后，仅仅需要完成初始化、串口收发数据、启动计数器和FLASH操作等步骤，就可以下载引导uClinux内核完成板上系统的加载。总得来说，ARMboot介于大、小型Boot Loader之间，相对轻便，基本功能完备，缺点是缺乏后续支持。

U-Boot是由开源项目PPCBoot发展起来的，ARMboot并入了PPCBoot，和其他一些arch的Loader合称U-Boot。2002年12月17日第一个版本U-Boot-0.2.0发布，同时PPCBoot和ARMboot停止维护。

U-Boot自发布以后已更新6次,最新版本为U-Boot-1.1.1，U-Boot的支持是持续性的。

U-Boot支持的处理器构架包括PowerPC (MPC5xx，MPC8xx，MPC82xx，MPC7xx，MPC74xx，4xx)， ARM （ARM7，ARM9，StrongARM，Xscale），MIPS (4Kc，5Kc)，x86等等， U-Boot（Universal Bootloader）从名字就可以看出，它是在GPL下资源代码最完整的一个通用Boot Loader。

U-Boot提供两种操作模式：启动加载（Boot loading）模式和下载（Downloading）模式,并具有大型Boot Loader的全部功能。主要特性为：

-SCC/FEC以太网支持；

-BOOTP/TFTP引导；

-IP，MAC预置功能；

-在线读写FLASH，DOC, IDE，IIC，EEROM，RTC；

-支持串行口kermit，S-record下载代码；

-识别二进制、ELF32、pImage格式的Image，对Linux引导有特别的支持；

-监控(minitor)命令集:读写I/O，内存，寄存器、内存、外设测试功能等；

-脚本语言支持（类似BASH脚本）；

-支持WatchDog，LCD logo，状态指示功能等。

U-Boot的功能是如此之强大，涵盖了绝大部分处理器构架，提供大量外设驱动，支持多个文件系统，附带调试、脚本、引导等工具，特别支持Linux,为板级移植做了大量的工作。U-Boot1.1.1版本特别包含了对SA1100和44B0芯片的移植，所以44B0移植主要是针对Board 的移植，包括FLASH、内存配置以及串口波特率等等。U-Boot的完整功能性和后续不断的支持，使系统的升级维护变得十分方便。

Blob(Boot Loader Object)是由Jan-Derk Bakker and Erik Mouw发布的，是专门为StrongARM 构架下的LART设计的Boot Loader。

Blob的最后版本是blob-2.0.5。

Blob支持SA1100的LART主板，但用户也可以自行修改移植。

Blob也提供两种工作模式，在启动时处于正常的启动加载模式，但是它会延时 10 秒等待终端用户按下任意键而将 Blob 切换到下载模式。如果在 10 秒内没有用户按键，则 Blob 继续启动 Linux内核。其基本功能为：

初始化硬件（CPU速度，存储器，中断，RS232串口）

-引导Linux内核并提供ramdisk；

- 给LART下载一个内核或者ramdisk；

-给FLASH片更新内核或者ramdisk；

-测定存储配置并通知内核；

-给内核提供一个命令行。

Blob功能比较齐全，代码较少，比较适合做修改移植，用来引导Liunx，目前大部分S3C44B0板都用Blob修改移植后来加载uClinux。

Bios-lt是专门支持三星（Samsung）公司ARM构架处理器S3C4510B的Loader，可以设置CPU/ROM/SDRAM/EXTIO，管理并烧写FLASH，装载引导uClinux内核。这是国内工程师申请GNU通用公共许可发布的。

Bios-lt的最新版本是Bios-lt-0.74，另外还提供了S3C4510B的一些外围驱动。

Bootldr是康柏（Compaq）公司发布的，类似于compaq iPAQ Pocket PC，支持SA1100芯片。它被推荐用来引导Llinux,支持串口Y-modem协议以及jffs文件系统。

Bootldr的最后版本为Bootldr-2.19。

vivi是韩国mizi 公司开发的bootloader, 适用于ARM9处理器。Vivi有两种工作模式：启动加载模式和下载模式。启动加载模式可以在一段时间后（这个时间可更改）自行启动linux内核，这是vivi的默认模式。在下载模式下，vivi为用户提供一个命令行接口，通过接口可以使用vivi提供的一些命令，如下：

命令

功能

Load　把二进制文件载入Flash或RAM

Part　操作MTD分区信息。显示、增加、删除、复位、保存MTD分区

Param　设置参数

Boot　启动系统

Flash　管理Flash，如删除Flash的数据

vivi代码分析　vivi的代码包括arch，init，lib，drivers和include等几个目录，共200多条文件。

Vivi主要包括下面几个目录：

arch：此目录包括了所有vivi支持的目标板的子目录，例如s3c2410目录。

drivers：其中包括了引导内核需要的设备的驱动程序（MTD和串口）。

MTD目录下分map、nand和nor三个目录。

init：这个目录只有main.c和version.c两个文件。和普通的C程序一样，vivi将从main函数开始执行。

lib：一些平台公共的接口代码，比如time.c里的udelay()和mdelay()。

include：头文件的公共目录，其中的s3c2410.h定义了这块处理器的一些寄存器。Platform/smdk2410.h定义了与开发板相关的资源配置参数，我们往往只需要修改这个文件就可以配置目标板的参数，如波特率、引导参数、物理内存映射等。

一般的DSP都采用常见的BootLoader程序工作方式来实现用户程序的上电自举：

1.处理器通信口(主端口)HPI方式

--通过DSP芯片与PC机或DSP芯片与其它DSP芯片之间的主机通信端口实现上电自举；

2.8位或16位并行EPROM方式

--通过DSP内核的DMA通道实现上电自举；

3.8位或16位并行I/O方式

--通过DSP芯片的片外并行I/O接口实现上电自举；

4.8位或16位串行口方式

--通过DSP芯片的串行端口实现上电自举。

在以上四种工作方式中，最常用的是16位并行EPROM方式。即在DSP芯片上电或复位时，通过DMA通道将存储在核外EPROM中的程序以16位形式存储到核内的程序空间中。

各种方式的BootLoader程序都有其固定格式的Boot表，用来实现用户程序的上电自举。16位并行EPROM方式的Boot表如表所示：

项1：存放BootLoader

程序工作方式控制字，用于DSP芯片上电或复位时确认该Boot表是否为16位并行EPROM工作方式的Boot表。该表项内容为10AAH，表示DSP内核认为该Boot表是16位并行EPROM工作方式的BootLoader程序的Boot表；否则DSP内核认为该Boot表不是16位并行EPROM的方式的Boot表；

Boot表

项2：

存放DSP特殊寄存器SWWSR在上电或复位时被赋予的初始化数值；

项3：

存放DSP特殊寄存器BSCR在上电或复位时被赋予的初始化数值；

项4：

存放用户程序将要被存放在DSP核内程序空间的页地址；

项5：

存放用户程序将要被存放到DSP核内程序空间的页内偏移地址；

项6：

开始依次存放用户程序第m段代码的长度N。用户程序第m段代码将要被存放到DSP核内程序空间的页地址，用户程序第m段代码将要被存放到DSP核内程序空间的页内偏移地址，用户程序第m段代码的第1个字，第2个字，……，第N个字；Boot表的最后表项存放Boot表结束字0000H，表示Boot表到此结束。因此DSP内核要实现BootLoader程序，在上电复位后首先要申请到片外数据、地址总线的控制权，然后再根据Boot表完成用户程序上电自举过程。

多核DSP的BootLoader程序的实现

在实现多核DSP上电自举时，每一个子核都需要申请片外总线的控制权。对于单核DSP而言，只有一个DSP内核，对应一个BootLoader程序，DSP核可以永远拥有片外总线的控制权。但对于多核DSP而言，由于只有一套片外总线，所以片外总线的控制权不允许也不可能永远被其中的某一个DSP子核所拥有。因此，多核DSP需要片外总线仲裁机制，以避免片外总线冲突。DSP核的BootLoader程序总是在DSP核上电或复位时启动，且一启动BootLoader程序，对应的DSP核就要申请核外的总线控制权。因此为了避免多核DSP的各个DSP子核启动BootLoader程序时引起的片外总线冲突，可通过控制每个DSP子核的复位过程，使每个DSP子核在不同的时间内启动自身的BootLoader程序来解决片外总线冲突的问题。

Bootloader广泛用于有操作系统的手持终端设备、智能家电及机顶盒等嵌入式设备上，它负责完成硬件初始化、操作系统引导和系统配制等，相当于PC机上的BIOS对于一个嵌入式的Linux系统而言，Bootloader是整个系统运行的基础。但是对于不同的ARM平台而言所使用的Bootloader都会有所不同。完成 Bootloader的移植是在特定的硬件平台上实现系统构建和运行的至关重要的一个步骤。