引导加载程序BootLoader 是系统加电后运行的第一段代码。我们熟悉的PC 中的引导程序一般由BIOS 和位于硬盘MBR中的OS
bootloader（例如LILO 或者GRUB）一起组成。然而在嵌入式系统中通常没有像BIOS 那样的固件程序（有的嵌入式CPU
有），因此整个系统的加载启动任务就完全由bootloader 来完成。比如在一个基于ARM920T core
的嵌入式系统中，系统在上电或复位时都从地址0x00000000 开始执行，而在这个地址处安排的通常就是系统的BootLoader
程序。
简单地说，BootLoader
就是在操作系统内核或用户应用程序运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核或用户应用程序准备好正确的环境。
Bootloader 是依赖于硬件而实现的，特别是在嵌入式系统中。不同的体系结构需求的Bootloader
是不同的；除了体系结构，Bootloader
还依赖于具体的嵌入式板级设备的配置。也就是说，对于两块不同的嵌入式板而言，即使它们基于相同的CPU
构建，运行在其中一块电路板上的Bootloader，未必能够运行在另一块电路开发板上。
Bootloader
的启动过程可以是单阶段的，也可以是多阶段的。通常多阶段的Bootloader能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的Bootloader
大多数是二阶段的启动过程，也即启动过程可以分为stage 1 和stage 2 两部分。
2．BootLoader 操作模式
大多数bootloader
都包含两种不同的操作模式：“启动加载”模式和“下载”模式，这种区别对于开发人员才有意义。但从最终用户的角度看，Bootloader
的作用永远就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
启动加载模式：这种模式也称为“自主”模式，即Bootloader 从目标机上的某个固体存储设备上将操作系统加载到RAM
中运行，整个过程没有用户的介入。这种模式是Bootloader的正常工作模式，因此当以嵌入式产品发布的时候，Bootloader
必须工作在这种模式下。
下载模式：在这种模式下，目标机上的Bootloader
将通过串口或者网络连接或者其它通信手段从主机下载文件，比如：下载内核镜像和根文件系统镜像等。从主机下载的文件通常首先被Bootloader
保存到目标机的RAM 中，然后被Bootloader 写到目标机上的FLASH 类固态存储设备中。Bootloader
的这种模式通常在第一次安装内核与根文件系统时使用；此外，以后的系统更新也会使用Bootloader
的这种工作模式。工作于这种模式下的Bootloader 通常都会向它的中断用户提供一个简单的命令行接口。
3．bootloader 的功能说明和结构框架
在设计时，我们将Booloader 分为两个阶段：阶段1 (stage 1) 和阶段2 (stage 2)：
阶段1：主要用汇编语言，它主要进行与CPU 核以及存储设备密切相关的处理工作，进行一些必要的初始化工作，是一些依赖于CPU
体系结构的代码，为了增加效率以及因为涉及到协处理器的设置，只能用汇编编写，这部分直接在FLASH 中执行；
阶段2：一般用C 语言来实现一般的流程以及对板级的一些驱动支持，这部分会被拷贝到RAM
中执行。这样设计的话，代码具有更好的可读性与可移植性：若对于相同的CPU 以及存储设备，要增加外设支持，阶段1
的代码可以维护不变，只对阶段2 的代码进行修改；若要支持不同的CPU，则基础代码只需在阶段1 中修改。
Bootloader 的阶段1(stage1)通常包括下面的步骤(以执行的先后顺序)：
·硬件设备初始化；
·为加载Boot Loader的stage2准备 RAM 空间；
·拷贝Boot Loader的stage2 到RAM空间中；
·设置好堆栈；
·跳转到 stage2 的 C 入口点。
Bootloader 的阶段2（stage2）通常包括下面的步骤(以执行的先后顺序)：
·初始化本阶段要使用到的硬件设备；
·检测系统内存映射(memory map)；
·将kernel 映像和根文件系统映像从flash上读到 RAM 空间中；
·为内核设置启动参数；
·调用内核。
文章二
在将Linux内核移植到ARM处理器时，有一个问题不能忽视，那就是移植Bootloader，Linux内核启动部分的代码需要判断从Bootloader传递过来的寄存器值。
为什么需要Bootloader呢？这与硬件本身的启动方式有关，有了Bootloader可以方便系统的开发。通过这段Bootloader小程序，可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。
(1) Bootloader所支持的CPU和嵌入式板
每种不同的CPU体系结构都有不同的Bootloader，有些Bootloader也支持多种体系结构的CPU，如Uboot。除了依赖于CPU的体系结构外，Bootloader实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种CPU而构建的，要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上，通常也都需要修改Bootloader的源程序。
(2) Bootloader的安装媒介
系统加电或复位后，所有的CPU通常都从某个预先安排的地址上取指令。比如，基于ARM内核的CPU在复位时通常都从地址0x00000000取它的第一条指令。而基于CPU构建的嵌入式系统通常都有某种类型的固态存储设备(比如：rom、eeprom或Flash等)被映射到这个预先安排的地址上。因此在系统加电后，CPU将首先执行Bootloader程序。
(3) 用来控制Bootloader的设备或机制
主机和目标机之间一般通过串口建立连接，Bootloader软件在执行时通常会通过串口来进行I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。
(4) Bootloader的启动过程是单阶段还是多阶段
通常多阶段的boot-loader能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的Bootloader大多都是2阶段的启动过程，即启动过程可以分为stage
1和stage2两部分。
(5) Bootloader的操作模式
大多数Bootloader都包含两种不同的操作模式：“启动加载”模式和“下载”模式，这两种区别不是很大。从最终用户的角度看，Bootloader的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
启动加载模式：这种模式也称为“自主”模式。即Bootloader从目标机上的某个固态存储设备上将操作系统加载到SDRAM中运行，整个过程并没有用户的介入。这种模式是Bootloader的正常工作模式，因此在嵌入式产品发布时，Bootloader必须工作在这种模式下。
下载模式：在这种模式下，目标机上的Bootloader将通过串口连接或网络连接等通信手段从主机(Host)下载文件，比如：下载内核映像和根文件系统映像等。从主机下载的文件通常首先被Bootloader保存到目标板的SDRAM中，然后再被Bootloader写到目标板上的Flash类固态存储设备中。Bootloader的这种模式通常在第一次安装内核与根文件系统时被使用；此外，以后的系统更新也会使用Bootloader的这种工作模式。工作于这种模式下的Bootloader通常都会向它的终端用户提供一个简单的命令行接口。
(6) Bootloader与主机之间进行文件传输所用的通信设备及协议
最常见的情况就是，目标机上的Bootloader通过串口与主机之间进行文件传输，传输协议通常是xmodem/ymodem/zmodem协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助tftp协议来下载文件是个更好的选择。此外，主机方所用的软件也要考虑。比如，在通过以太网连接和tftp协议来下载文件时，主机方必须有一个软件用来提供tftp服务。
(7) Bootloader的主要任务与典型结构框架
首先做一个假定：假定内核映像与根文件系统映像都被加载到SDRAM中运行。因为，在嵌入式系统中内核映像与根文件系统映像也可以直接在ROM或Flash这样的固态存储设备中直接运行，但这种做法无疑是以运行速度的牺牲为代价的。从操作系统的角度看，Bootloader的总目标就是正确地调用内核来执行。
另外，由于Bootloader依赖于CPU的体系结构，因此大多数Bootloader都分为stage 1和stage
2两大部分。依赖于CPU体系结构的代码，比如设备初始化代码等，通常都放在stage1中，而且通常都用ARM汇编语言来实现，以达到短小精悍的目的。而stage
2则通常用C语言来实现，这样可以实现更复杂的功能，而且代码会具有更好的可读性和可移植性。
(8) 串口终端
Bootloader程序设计与实现后，串口终端就能正确地收到打印信息了。此外，向串口终端打印信息也是一个非常重要而又有效的调试手段。
但是，经常会碰到串口终端显示乱码或根本没有显示的问题。发生这样的问题主要有两种原因：(1)
Bootloader对串口的初始化设置不正确；(2)
运行在host端的终端仿真程序对串口的设置不正确，这包括波特率、奇偶校验、数据位和停止位等方面的设置。
此外，有时也会碰到这样的问题，那就是：在Bootloader的运行过程中可以正确地向串口终端输出信息，但当Bootloader启动内核后却无法看到内核的启动输出信息。对发生这一问题的原因可以从以下几个方面来考虑。
首先确认内核编译时配置了对串口终端的支持，并配置了正确的串口驱动程序。
其次Bootloader对串口的初始化设置可能会和内核对串口的初始化设置不一致，例如，Bootloader和内核对其CPU时钟频率的设置不一致。
最后，还要确认Bootloader所用的内核基地址必须和内核映像在编译时所用的运行基地址一致，尤其是对于ARM
Linux而言。假设内核映像在编译时用的基地址是0xc0028000，但Bootloader却将它加载到0xc0010000处去执行，那么内核映像就不能正确地执行。