一个嵌入式 Linux 系统从软件的角度看通常可以分为四个层次： 1. 引导加载程序。包括固化在固件(firmware)中的 boot 代码(可选)，和 Boot Loader 两大部分。 2. Linux 内核。特定于嵌入式板子的定制内核以及内核的启动参数。 3. 文件系统。包括根文件系统和建立于 Flash 内存设备之上文件系统。通常用 ram disk 来作为 root fs。 4. 用户应用程序。特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式 GUI 有：MicroWindows 和 MiniGUI 等。

BootLoader的概念

BootLoader是系统加电启运行的第一段软件代码．回忆一下PC的体系结构我们可以知道，PC机中的引导加载程序由BIOS（其本质就是一段固件程序）和位于硬盘MBR中的引导程序一起组成。BIOS在完成硬件检测和资源分配后，将硬盘MBR中的引导程序读到系统的RAM中，然后将控制权交给引导程序。引导程序的主要运行任务就是将内核映象从硬盘上读到RAM中 然后跳转到内核的入口点去运行，也即开始启动操作系统。     而在嵌入式系统中，通常并没有像BIOS那样的固件程序（有的嵌入式系统也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由BootLoader来完成．比如在一个基于 ARM7TDMI core的嵌入式系统中，系统在上电或复位时都从地址 0x00000000开始执行．而在这个地址处安排的通常就是系统的BootLoader程序。     简单地说，BootLoader就是在操作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。每种不同的 CPU体系结构都有不同的BootLoader。有些BootLoader也支持多种体系结构的 CPU，比如U-Boot就同时支持 ARM体系结构和MIPS体系结构。除了依赖于CPU的体系结构外，BootLoader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU而构建的，要想让运行在一块板子上的BootLoader程序也能运行在另一块板子上，通常也都需要修改BootLoader的源程序。系统加电或复位后，所有的 CPU通常都从某个由 CPU 制造商预先安排的地址上取指令。比如，基于 ARM7TDMI核的CPU在复位时通常都从地址 0x00000000取它的第一条指令。而基于 CPU构建的嵌入式系统通常都有某种类型的固态存储设备(比如：ROM、EEPROM或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU将首先执行BootLoader 程序。
下图就是一个同时装有 Boot Loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。 固态存储设备的典型空间分配结构   一般情况下，内核映像与根文件系统映像都被加载到 RAM 中运行，在嵌入式系统中内核映像与根文件系统映像也可以直接在 ROM 或 Flash 这样的固态存储设备中直接运行。但这种做法无疑是以运行速度的牺牲为代价的。 “Boot parameters”分区中存放一些可设置的参数，比如IP地址、串口波特率、要传递给内核的命令行参数等。正常启动过程中，Bootloader首先运行，然后它将内核复制到内存中(也有些内核可以在固态存储设备上直接运行)，并且在内存某个固定的地址设置好要传递给内核的参数，最后运行内核。内核启动之后，它会挂接(mount)根文件系统(“Root filesystem”)，启动文件系统中的应用程序。
     对于一个嵌入式系统来说，可能有的包括操作系统，有的小型系统也可以只包括应用程序，但是在这之前都需要BootLoader为它准备一个正确的环境。通常，BootLoader是依赖于硬件而实现的，特别是在嵌入式领域，为嵌入式系统建立一个通用的BootLoader是很困难的。

BootLoader的烧写

BootLoader被安排在固态存储设备（比如Flash）的地址上，因此在启动之前需要烧写到Flash中。 通常有两种方式： 1.通过片内固化的loader加载bootloader：通常某些CPU内部ROM中固化了一段程序可以用于最初的程序下载，如AT91RM9200。这时下载的程序是在内部RAM中运行的，大小有一定限制，然后由这段程序继续交互下载真正要烧写到flash中的程序，将其保存在外部RAM中，最终烧写到flash中。
2.通过JTAG或者仿真器下载：通常这些烧录工具可以直接操作flash，对其进行编程烧录。需要专门的工具。这种情况多用于那些没有固化loader的CPU，如三星系列。

Boot Loader的操作模式

大多数BootLoader都包含两种不同的操作模式。“启动加载”模式和“下载”模式，这种区别仅对于开发人员才有意义。但从最终用户的角度看，BootLoader的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。     启动加载（Boot loading）模式：这种模式也称为“自主”（Autonomous）模式，也即BootLoader从目标机上的某个固态存储设备上将操作系统加载到RAM中运行，整个过程并没有用户的介入。这种模式是BootLoader的正常工作模式。因此在嵌入式产品发布的时候，BootLoader显然必须工作在这种模式下．     下载（Down loading）模式：在这种模式下 目标机上的BootLoader将通过串口连接或网络连接等通信手段从主机下载文件，比如：下载应用程序、数据文件、内核映像等．从主机下载的文件通常首先被BootLoader保存到目标机的RAM中然后再被BootLoader写到目标机上的固态存储设备中。BootLoader的这种模式通常在系统更新时使用。工作于这种模式下的BootLoader通常都会向它的终端用户提供一个简单的命令行接口。       （像U-BOOT，Blob，ViVI等功能强大的BootLoader通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进行切换。比如，U-BOOT在启动时处于正常的启动加载模式，但是它会延时几秒(在配置文件中可以设定)等待终端用户按下任意键而将其切换到下载模式（相当于bios下按del键可进入系统配置界面一样，设置从光盘启动可进行重装），如果在给定时间内没有用户按键，则U-BOOT继续启动，进行正常的启动加载。）

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

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

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空间中；

Ø       为内核设置启动参数；

Ø       调用内核。
常用的BootLoader有U-Boot，Blob，ViVi等，更细致的分析需要解析具体BootLoader的源码。