一.简介
回忆一下 PC 的体系结构我们可以知道，PC 机中的引导加载程序由 BIOS(其本质就是一段固件程序)和位于硬盘 MBR 中的OS Boot Loader(比如，LILO 和GRUB 等)一起组成。BIOS 在完成硬件检测和资源分配后，将硬盘 MBR 中的 Boot Loader 读到系统的 RAM 中，然后将控制权交给 OS Boot Loader。Boot Loader 的主要运行任务就是将内核映象从硬盘上读到 RAM 中，然后跳转到内核的入口点去运行，也即开始启动 *** 作系统。而在嵌入式系统中，通常并没有像 BIOS 那样的固件程序(注，有的嵌入式 CPU 也会内嵌一段短小的启动程序)，因此整个系统的加载启动任务就完全由 Boot Loader 来完成。比如在一个基于 ARM7TDMI core 的嵌入式系统中，系统在上电或复位时通常都从地址0x00000000 处开始执行，而在这个地址处安排的通常就是系统的 Boot Loader 程序。
引导加载程序 。包括固化在固件 (firmware) 中的 boot 代码 ( 可选 ) ，和 Boot Loader 两大部分。
Linux 内核 。特定于嵌入式板子的定制内核以及内核的启动参数。
引导加载程序是系统加电后运行的第一段软件代码。
本文将从 BootLoader 的概念、BootLoader 的主要任务、BootLoader 的框架结构以及 BootLoader 的安装等四个方面来讨论嵌入式系统的 BootLoader。
二.Boot Loader 的概念
简单地说，Boot Loader 就是在 *** 作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用 *** 作系统内核准备好正确的环境。
1. Boot Loader 所支持的 CPU 和嵌入式板
每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot Loader 也支持多种体系结构的 CPU，比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。除了依赖于CPU 的体系结构外，BootLoader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 而构建的，要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上，通常也都需要修改Boot Loader 的源程序。
2. Boot Loader 的安装媒介(InstallaTIon Medium)
系统加电或复位后，所有的 CPU 通常都从某个由 CPU 制造商预先安排的地址上取指令。比如，基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000 取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设备(比如：ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU 将首先执行 Boot Loader 程序。
3. 用来控制 Boot Loader 的设备或机制
4. Boot Loader 的启动过程
Boot Loader 的启动过程是单阶段(Single Stage)还是多阶段(MulTI-Stage)通常多阶段的 Boot Loader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1 和stage 2 两部分。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面讨论。
5. BootLoader 与主机之间进行文件传输所用的通信设备及协议
最常见的情况就是，目标机上的 Boot Loader 通过串口与主机之间进行文件传输，传输协议通常是 xmodem/ymodem/zmodem 协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。在讨论了 BootLoader 的上述概念后，下面我们来具体看看 BootLoader 的应该完成哪些任务。
三. Boot Loader 的主要任务与典型结构框架
在继续本节的讨论之前，首先我们做一个假定，那就是：假定内核映像与根文件系统映像都被加载到 RAM 中运行。之所以提出这样一个假设前提是因为，在嵌入式系统中内核映像与根文件系统映像也可以直接在 ROM 或 Flash 这样的固态存储设备中直接运行。但这种做法无疑是以运行速度的牺牲为代价的。
从 *** 作系统的角度看，Boot Loader 的总目标就是正确地调用内核来执行。另外，由于 Boot Loader 的实现依赖于 CPU 的体系结构，因此大多数 Boot Loader 都分为 stage1 和 stage2 两大部分。依赖于 CPU 体系结构的代码，比如设备初始化代码等，通常都放在 stage1 中，而且通常都用汇编语言来实现，以达到短小精悍的目的。
而 stage2 则通常用C语言来实现，这样可以实现给复杂的功能，而且代码会具有更好的可读性和可移植性。
Boot Loader 的 stage1 通常包括以下步骤(以执行的先后顺序)：
硬件设备初始化。
为加载 Boot Loader 的 stage2 准备 RAM 空间。
拷贝 Boot Loader 的 stage2 到 RAM 空间中。
设置好堆栈。
跳转到 stage2 的 C 入口点。
Boot Loader 的 stage2 通常包括以下步骤(以执行的先后顺序)：
初始化本阶段要使用到的硬件设备。
检测系统内存映射(memory map)。
将 kernel 映像和根文件系统映像从 flash 上读到 RAM 空间中。
为内核设置启动参数。
调用内核。
3.1 Boot Loader 的 stage1
3.1.1基本的硬件初始化
这是 Boot Loader 一开始就执行的 *** 作，其目的是为 stage2 的执行以及随后的 kernel 的执行准备好一些基本的硬件环境。它通常包括以下步骤(以执行的先后顺序)：
屏蔽所有的中断。为中断提供服务通常是 OS 设备驱动程序的责任，因此在 BootLoader 的执行全过程中可以不必响应任何中断。中断屏蔽可以通过写CPU 的中断屏蔽寄存器或状态寄存器(比如ARM 的 CPSR 寄存器)来完成。
设置 CPU 的速度和时钟频率。
RAM 初始化。包括正确地设置系统的内存控制器的功能寄存器以及各内存库控制寄存器等。
初始化 LED。典型地，通过 GPIO 来驱动 LED，其目的是表明系统的状态是 OK 还是 Error。如果板子上没有 LED，那么也可以通过初始化 UART 向串口打印 Boot Loader 的 Logo 字符信息来完成这一点。
关闭 CPU 内部指令/数据 cache。
3.1.2 为加载 stage2 准备 RAM 空间
为了获得更快的执行速度，通常把 stage2 加载到 RAM 空间中来执行，因此必须为加载Boot Loader 的 stage2 准备好一段可用的 RAM 空间范围。由于 stage2 通常是 C 语言执行代码，因此在考虑空间大小时，除了 stage2 可执行映象的大小外，还必须把堆栈空间也考虑进来。此外，空间大小最好是 memory page 大小(通常是 4KB)的倍数。一般而言，1M的 RAM 空间已经足够了。具体的地址范围可以任意安排，比如 blob 就将它的 stage2 可执行映像安排到从系统 RAM 起始地址 0xc0200000 开始的1M空间内执行。
但是，将 stage2 安排到整个 RAM 空间的最顶 1MB(也即(RamEnd-1MB) - RamEnd)是一种值得推荐的方法。
为了后面的叙述方便，这里把所安排的 RAM 空间范围的大小记为：stage2_size(字节) ，把起始地址和终止地址分别记为：stage2_start 和 stage2_end(这两个地址均以 4 字节边界对齐)。因此： stage2_end=stage2_start+stage2_size
另外，还必须确保所安排的地址范围的的确确是可读写的 RAM 空间，因此，必须对你所安排的地址范围进行测试。
具体的测试方法可以采用类似于 blob 的方法，也即：以 memory page 为被测试单位，测试每个 memory page 开始的两个字是否是可读写的。为了后面叙述的方便，我们记这个检测算法为：test_mempage，其具体步骤如下：
先保存 memory page 一开始两个字的内容。
向这两个字中写入任意的数字。比如：向第一个字写入 0x55，第 2 个字写入 0xaa。
然后，立即将这两个字的内容读回。显然，我们读到的内容应该分别是 0x55 和 0xaa。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM 空间。
再向这两个字中写入任意的数字。比如：向第一个字写入 0xaa，第 2 个字中写入0x55。
然后，立即将这两个字的内容立即读回。显然，我们读到的内容应该分别是 0xaa和 0x55。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM空间。
恢复这两个字的原始内容。测试完毕。
为了得到一段干净的 RAM 空间范围，我们也可以将所安排的 RAM 空间范围进行清零 *** 作。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）