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

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

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

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

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

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

3、 档案系统。包括根档案系统和建立于Flash记忆体设备之上档案系统。通常用ramdisk来作为rootfs。

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

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

1.自启动模式在这种模式下，bootloader从目标机上的某个固态存储设备上将作业系统载入到RAM中运行，整个过程并没有用户的介入。

2.互动模式在这种模式下，目标机上的bootloader将通过串口或网路等通行手段从开发主机（Host）上下载核心映像等到RAM中。可以被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

程式工作方式控制字，用于DS晶片上电或复位时确认该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程式来解决片外汇流排冲突的问题。