文章一:
1.BootLoader 的介绍
引导加载程序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处去执行,那么内核映像就不能正确地执行。