BootLoader和内核image的关系

昨晚听舍友说起编译linux内核这个事情，作为计算机专业毕业的人，对这个东西完全不了解，太郁闷了。经过多方了解，总算是有了一个比较模糊的概念。在linux中内核image一般放在boot/grub或者boot/lilo中，经过舍友的讲解，大致了解了这个image的左右，但是谁来读这个grub.conf呢？舍友也不晓得。躺在床上想来想去，BootLoader！这个东西一定是比image加载更早的！联系工作中的一些开发流程，更加确定了这个东西，兴奋。。今天上午过来就查了一下BootLoader，下面是找到的一个比较入门的解说，大概跟我想的差不多。继续学习，交换机作为嵌入式系统的一种，一样是需要BootLoader来加载image运行的。
BootLoader是系统加电后运行的第一段代码。一般它只在系统启动时非常短的时间内运行。对于由DaVinci构成的嵌入式系统来说，这是至关重要的一步。
在PC中，整个BootLoader由BIOS（主板上固化的一段程序）、位于硬盘MBR区的OS
Loader一起组成。BIOS完成第一级引导加载工作，OS
Loader完成第二级引导加载工作（可能有些系统不只两级加载）。上电后，系统开始执行BIOS中的代码，这段代码负责进行硬件检测和资源分配，完成这步工作后，将按照CMOS中设定的顺序检索硬盘。BIOS将第一个检索到的硬盘上MBR中的内容读到系统RAM中，然后将系统控制权交给相应的OS
Loader。最后由OS
Loader负责将所要引导的操作系统的内核映象从硬盘上读到系统RAM中，然后跳转到内核的入口点上。
在由DaVinci平台构成的嵌入式系统中，通常不存在BIOS那样的一段固定内容的固化的程序。原因是PC平台尽管品牌等有差异，但通常都有相近甚至是相同的体系结构，遵循一个共同的工业标准，因而可以使用同一个BIOS代码来引导。而通常对嵌入式系统来说，即使是使用相同的架构，甚至是同一个CPU如都是DM6446来构建，但因为并不能遵的一个共同的工业标准。因而基于DaVinci平台构建的嵌入式系统上除非两者的各方面与引导过程相关设计完成一致，否则不能使用同一个BootLoader。
可以说BootLoader是一个由DaVinci平台构成的嵌入式系统的钥匙。没有这把钥匙就无法进入系统的大门。也就是说在完成自己的硬件研发后，首要的工作就是BootLoader的移植。
BootLoader的概念
BootLoader是系统加电启运行的第一段软件代码．回忆一下PC的体系结构我们可以知道，PC机中的引导加载程序由BIOS（其本质就是一段固件程序）和位于硬盘MBR中的引导程序一起组成。BIOS在完成硬件检测和资源分配后，将硬盘MBR中的引导程序读到系统的RAM中，然后将控制权交给引导程序。引导程序的主要运行任务就是将内核映象从硬盘上读到RAM中
然后跳转到内核的入口点去运行，也即开始启动操作系统。
而在嵌入式系统中，通常并没有像BIOS那样的固件程序（有的嵌入式系统也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由BootLoader来完成．比如在一个基于
ARM7TDMI core的嵌入式系统中，系统在上电或复位时都从地址
0x00000000开始执行．而在这个地址处安排的通常就是系统的BootLoader程序。
简单地说BootLoader就是在操作系统内核或用户应用程序运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图（有的CPU没有内存映射功能如
S3C44B0），从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核或用户应用程序准备好正确的环境。对于一个嵌入式系统来说，可能有的包括操作系统，有的小型系统也可以只包括应用程序，但是在这之前都需要BootLoader为它准备一个正确的环境。通常，BootLoader是依赖于硬件而实现的，特别是在嵌入式领域，为嵌入式系统建立一个通用的BootLoader是很困难的。当然，我们可以归纳出一些通用的概念来，以便我们了解特定BootLoader的设计与实现。
u BootLoader的移植和修改
每种不同的CPU体系结构都有不同的BootLoader。除了依赖于CPU的体系结构外，BootLoader实际上也依赖于具体的嵌入式板级设备的配置，比如板卡的硬件地址分配，RAM芯片的类型，其他外设的类型等。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种CPU而构建的，如果他们的硬件资源和配置不一致的话，要想让运行在一块板子上的BootLoader程序也能运行在另一块板子上，也还是需要作一些必要的修改。
u BootLoader的安装
系统加电或复位后，所有的CPU通常都从CPU制造商预先安排的地址上取指令。比如，S3C44B0在复位的都从地址0x00000000取它的第一条指令。而嵌入式系统通常都有某种类型的固态存储设备（比如：ROM、EEPROM或FLASH等）被安排这个起始地址上，因此在系统加电后，CPU将首先执行BootLoader程序。也就是说对于基于S3C44B0的这套系统，我们的BootLoader是从0地址开始存放的，而这块起始地址需要采用可引导的固态存储设备如FLASH。
u 用来控制BootLoader的设备或机制
串口通讯是最简单也是最廉价的一种双机通讯设备，所以往往在BootLoader中主机和目标机之间都通过串口建立连接，BootLoader程序在执行时通常会通过串口来进行
I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。当然如果认为出口通讯速度不够，也可以采用网络或者USB通讯，那么相应的在BootLoader中就需要编写各自的驱动
u BootLoader的启动过程
多阶段的BootLoader能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的
BootLoader大多都是2阶段的启动过程，也即启动过程可以分为 stase1和stase
2两部分，具体功能将在下一节介绍。
u Boot Loader的操作模式
大多数BootLoader都包含两种不同的操作模式。"启动加载"模式和"下载"模式，这种区别仅对于开发人员才有意义。但从最终用户的角度看，BootLoader的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
启动加载（Boot
loading）模式：这种模式也称为"自主"（Autonomous）模式，也即BootLoader从目标机上的某个固态存储设备上将操作系统加载到RAM中运行，整个过程并没有用户的介入。这种模式是BootLoader的正常工作模式。因此在嵌入式产品发布的时候，BootLoader显然必须工作在这种模式下．
下载（Down loading）模式：在这种模式下
目标机上的BootLoader将通过串口连接或网络连接等通信手段从主机下载文件，比如：下载应用程序、数据文件、内核映像等．从主机下载的文件通常首先被BootLoader保存到目标机的RAM中然后再被BootLoader写到目标机上的固态存储设备中。BootLoader的这种模式通常在系统更新时使用。工作于这种模式下的BootLoader通常都会向它的终端用户提供一个简单的命令行接口。
在教学系统中提供的BootLoader中没有实现自主模式，可以通过修改代码来实现该功能。
u BootLoader与主机之间进行文件传输所用的通信设备及协议
最常见的情况就是，目标机上的BootLoader通过串口与主机之间进行文件传输，传输可以简单的采用直接数据收发，当然在串口上也可以采用xmode／ymode／zmode协议以及在以太网上采用TPTP协议。
此外，在论及这个话题时，主机方所用的软件也要考虑。比如，在通过以太网连接和TFTP协议来下载文件时，主机方必须有一个软件用来提供TFTP服务。