⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 阿冰blog 嵌入式系统 boot loader 技术内幕.htm

📁 arm体系结构和编程,一份很好的ARM汇编编程资料
💻 HTM
📖 第 1 页 / 共 5 页
字号:
      Linux 系统从软件的角度看通常可以分为四个层次: </P>
      <P>1. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">引导加载程序。</B>包括固化在固件(firmware)中的 
      boot 代码(可选),和 Boot Loader 两大部分。 </P>
      <P>2. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Linux 
      内核。</B>特定于嵌入式板子的定制内核以及内核的启动参数。 </P>
      <P>3. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">文件系统。</B>包括根文件系统和建立于 
      Flash 内存设备之上文件系统。通常用 ram disk 来作为 root fs。 </P>
      <P>4. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">用户应用程序。</B>特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式 
      GUI 有:MicroWindows 和 MiniGUI 懂。 </P>
      <P>引导加载程序是系统加电后运行的第一段软件代码。回忆一下 PC 的体系结构我们可以知道,PC 机中的引导加载程序由 
      BIOS(其本质就是一段固件程序)和位于硬盘 MBR 中的 OS Boot Loader(比如,LILO 和 GRUB 等)一起组成。BIOS 
      在完成硬件检测和资源分配后,将硬盘 MBR 中的 Boot Loader 读到系统的 RAM 中,然后将控制权交给 OS Boot 
      Loader。Boot Loader 的主要运行任务就是将内核映象从硬盘上读到 RAM 中,然后跳转到内核的入口点去运行,也即开始启动操作系统。 
      </P>
      <P>而在嵌入式系统中,通常并没有像 BIOS 那样的固件程序(注,有的嵌入式 CPU 
      也会内嵌一段短小的启动程序),因此整个系统的加载启动任务就完全由 Boot Loader 来完成。比如在一个基于 ARM7TDMI core 
      的嵌入式系统中,系统在上电或复位时通常都从地址 0x00000000 处开始执行,而在这个地址处安排的通常就是系统的 Boot Loader 程序。 
      </P>
      <P>本文将从 Boot Loader 的概念、Boot Loader 的主要任务、Boot Loader 的框架结构以及 Boot Loader 
      的安装等四个方面来讨论嵌入式系统的 Boot Loader。 </P>
      <P><A name=2><SPAN class=atitle2><STRONG><FONT size=4>2. Boot Loader 
      的概念</FONT></STRONG></SPAN></A><BR>简单地说,Boot Loader 
      就是在操作系统内核运行之前运行的一段小程序。通过这段小程序,我们可以初始化硬件设备、建立内存空间的映射图,从而将系统的软硬件环境带到一个合适的状态,以便为最终调用操作系统内核准备好正确的环境。 
      </P>
      <P>通常,Boot Loader 是严重地依赖于硬件而实现的,特别是在嵌入式世界。因此,在嵌入式世界里建立一个通用的 Boot Loader 
      几乎是不可能的。尽管如此,我们仍然可以对 Boot Loader 归纳出一些通用的概念来,以指导用户特定的 Boot Loader 设计与实现。 
      </P>
      <P><A name=N1007B><SPAN class=atitle3><STRONG>1. Boot Loader 所支持的 CPU 
      和嵌入式板</STRONG></SPAN></A><BR>每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot 
      Loader 也支持多种体系结构的 CPU,比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。除了依赖于 CPU 
      的体系结构外,Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说,对于两块不同的嵌入式板而言,即使它们是基于同一种 CPU 
      而构建的,要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上,通常也都需要修改 Boot Loader 的源程序。 
</P>
      <P><A name=N10084><SPAN class=atitle3><STRONG>2. Boot Loader 
      的安装媒介(Installation Medium)</STRONG></SPAN></A><BR>系统加电或复位后,所有的 CPU 通常都从某个由 
      CPU 制造商预先安排的地址上取指令。比如,基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000 
      取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设备(比如:ROM、EEPROM 或 FLASH 
      等)被映射到这个预先安排的地址上。因此在系统加电后,CPU 将首先执行 Boot Loader 程序。 </P>
      <P>下图1就是一个同时装有 Boot Loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。 </P>
      <P><A name=N10092><B>图1 固态存储设备的典型空间分配结构</B></A><BR><IMG alt="" 
      src="阿冰BLOG  嵌入式系统 Boot Loader 技术内幕.files/image001.gif" 
      xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> </P>
      <P><A name=N1009D><SPAN class=atitle3><STRONG>3. 用来控制 Boot Loader 
      的设备或机制</STRONG></SPAN></A><BR>主机和目标机之间一般通过串口建立连接,Boot Loader 
      软件在执行时通常会通过串口来进行 I/O,比如:输出打印信息到串口,从串口读取用户控制字符等。 </P>
      <P><A name=N100A6><SPAN class=atitle3><STRONG>4. Boot Loader 
      的启动过程是单阶段(Single Stage)还是多阶段(Multi-Stage)</STRONG></SPAN></A><BR>通常多阶段的 
      Boot Loader 能提供更为复杂的功能,以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 
      阶段的启动过程,也即启动过程可以分为 stage 1 和 stage 2 两部分。而至于在 stage 1 和 stage 2 
      具体完成哪些任务将在下面讨论。 </P>
      <P><A name=N100AF><SPAN class=atitle3><STRONG>5. Boot Loader 的操作模式 
      (Operation Mode)</STRONG></SPAN></A><BR>大多数 Boot Loader 
      都包含两种不同的操作模式:"启动加载"模式和"下载"模式,这种区别仅对于开发人员才有意义。但从最终用户的角度看,Boot Loader 
      的作用就是用来加载操作系统,而并不存在所谓的启动加载模式与下载工作模式的区别。 </P>
      <P><B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">启动加载(Boot 
      loading)模式:</B>这种模式也称为"自主"(Autonomous)模式。也即 Boot Loader 
      从目标机上的某个固态存储设备上将操作系统加载到 RAM 中运行,整个过程并没有用户的介入。这种模式是 Boot Loader 
      的正常工作模式,因此在嵌入式产品发布的时侯,Boot Loader 显然必须工作在这种模式下。 </P>
      <P><B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">下载(Downloading)模式:</B>在这种模式下,目标机上的 
      Boot Loader 
      将通过串口连接或网络连接等通信手段从主机(Host)下载文件,比如:下载内核映像和根文件系统映像等。从主机下载的文件通常首先被 Boot 
      Loader 保存到目标机的 RAM 中,然后再被 Boot Loader 写到目标机上的FLASH 类固态存储设备中。Boot Loader 
      的这种模式通常在第一次安装内核与根文件系统时被使用;此外,以后的系统更新也会使用 Boot Loader 的这种工作模式。工作于这种模式下的 
      Boot Loader 通常都会向它的终端用户提供一个简单的命令行接口。 </P>
      <P>像 Blob 或 U-Boot 等这样功能强大的 Boot Loader 
      通常同时支持这两种工作模式,而且允许用户在这两种工作模式之间进行切换。比如,Blob 在启动时处于正常的启动加载模式,但是它会延时 10 
      秒等待终端用户按下任意键而将 blob 切换到下载模式。如果在 10 秒内没有用户按键,则 blob 继续启动 Linux 内核。 </P>
      <P><A name=N100C7><SPAN class=atitle3><STRONG>6. BootLoader 
      与主机之间进行文件传输所用的通信设备及协议</STRONG></SPAN></A><BR>最常见的情况就是,目标机上的 Boot Loader 
      通过串口与主机之间进行文件传输,传输协议通常是 xmodem/ymodem/zmodem 
      协议中的一种。但是,串口传输的速度是有限的,因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。 </P>
      <P>此外,在论及这个话题时,主机方所用的软件也要考虑。比如,在通过以太网连接和 TFTP 协议来下载文件时,主机方必须有一个软件用来的提供 
      TFTP 服务。 </P>
      <P>在讨论了 BootLoader 的上述概念后,下面我们来具体看看 BootLoader 的应该完成哪些任务。 </P>
      <P><A name=3><SPAN class=atitle2><STRONG><FONT size=4>3. Boot Loader 
      的主要任务与典型结构框架</FONT></STRONG></SPAN></A><BR>在继续本节的讨论之前,首先我们做一个假定,那就是:假定内核映像与根文件系统映像都被加载到 
      RAM 中运行。之所以提出这样一个假设前提是因为,在嵌入式系统中内核映像与根文件系统映像也可以直接在 ROM 或 Flash 
      这样的固态存储设备中直接运行。但这种做法无疑是以运行速度的牺牲为代价的。 </P>
      <P>从操作系统的角度看,Boot Loader 的总目标就是正确地调用内核来执行。 </P>
      <P>另外,由于 Boot Loader 的实现依赖于 CPU 的体系结构,因此大多数 Boot Loader 都分为 stage1 和 
      stage2 两大部分。依赖于 CPU 体系结构的代码,比如设备初始化代码等,通常都放在 stage1 
      中,而且通常都用汇编语言来实现,以达到短小精悍的目的。而 stage2 
      则通常用C语言来实现,这样可以实现给复杂的功能,而且代码会具有更好的可读性和可移植性。 </P>
      <P>Boot Loader 的 stage1 通常包括以下步骤(以执行的先后顺序): </P>
      <UL xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <LI>硬件设备初始化。 <BR><BR>
        <LI>为加载 Boot Loader 的 stage2 准备 RAM 空间。 <BR><BR>
        <LI>拷贝 Boot Loader 的 stage2 到 RAM 空间中。 <BR><BR>
        <LI>设置好堆栈。 <BR><BR>
        <LI>跳转到 stage2 的 C 入口点。 <BR><BR></LI></UL>
      <P>Boot Loader 的 stage2 通常包括以下步骤(以执行的先后顺序): </P>
      <UL xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <LI>初始化本阶段要使用到的硬件设备。 <BR><BR>
        <LI>检测系统内存映射(memory map)。 <BR><BR>
        <LI>将 kernel 映像和根文件系统映像从 flash 上读到 RAM 空间中。 <BR><BR>
        <LI>为内核设置启动参数。 <BR><BR>
        <LI>调用内核。 </LI></UL>
      <P><A name=N10133><SPAN class=atitle3><STRONG>3.1 Boot Loader 的 
      stage1</STRONG></SPAN></A><BR><STRONG>3.1.1 基本的硬件初始化</STRONG> </P>
      <P>这是 Boot Loader 一开始就执行的操作,其目的是为 stage2 的执行以及随后的 kernel 
      的执行准备好一些基本的硬件环境。它通常包括以下步骤(以执行的先后顺序): </P>
      <P>1. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">屏蔽所有的中断。</B>为中断提供服务通常是 
      OS 设备驱动程序的责任,因此在 Boot Loader 的执行全过程中可以不必响应任何中断。中断屏蔽可以通过写 CPU 
      的中断屏蔽寄存器或状态寄存器(比如 ARM 的 CPSR 寄存器)来完成。 </P>
      <P>2. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">设置 CPU 的速度和时钟频率。</B> 
      </P>
      <P>3. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">RAM 
      初始化。</B>包括正确地设置系统的内存控制器的功能寄存器以及各内存库控制寄存器等。 </P>
      <P>4. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">初始化 LED。</B>典型地,通过 
      GPIO 来驱动 LED,其目的是表明系统的状态是 OK 还是 Error。如果板子上没有 LED,那么也可以通过初始化 UART 向串口打印 
      Boot Loader 的 Logo 字符信息来完成这一点。 </P>
      <P>5. <B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">关闭 CPU 内部指令/数据 
      cache。</B> </P>
      <P><B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">3.1.2 为加载 stage2 准备 
      RAM 空间</B> </P>
      <P>为了获得更快的执行速度,通常把 stage2 加载到 RAM 空间中来执行,因此必须为加载 Boot Loader 的 stage2 
      准备好一段可用的 RAM 空间范围。 </P>
      <P>由于 stage2 通常是 C 语言执行代码,因此在考虑空间大小时,除了 stage2 
      可执行映象的大小外,还必须把堆栈空间也考虑进来。此外,空间大小最好是 memory page 大小(通常是 4KB)的倍数。一般而言,1M 的 
      RAM 空间已经足够了。具体的地址范围可以任意安排,比如 blob 就将它的 stage2 可执行映像安排到从系统 RAM 起始地址 
      0xc0200000 开始的 1M 空间内执行。但是,将 stage2 安排到整个 RAM 空间的最顶 1MB(也即(RamEnd-1MB) - 
      RamEnd)是一种值得推荐的方法。 </P>
      <P>为了后面的叙述方便,这里把所安排的 RAM 
      空间范围的大小记为:stage2_size(字节),把起始地址和终止地址分别记为:stage2_start 和 stage2_end(这两个地址均以 
      4 字节边界对齐)。因此: </P>
      <TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#cccccc 
        border=1><TBODY>
        <TR>
          <TD><PRE><CODE>
<FONT face=Courier size=2>stage2_end=stage2_start+stage2_size
</FONT></CODE></PRE></TD></TR></TBODY></TABLE>
      <P>另外,还必须确保所安排的地址范围的的确确是可读写的 RAM 空间,因此,必须对你所安排的地址范围进行测试。具体的测试方法可以采用类似于 
      blob 的方法,也即:以 memory page 为被测试单位,测试每个 memory page 
      开始的两个字是否是可读写的。为了后面叙述的方便,我们记这个检测算法为:test_mempage,其具体步骤如下: </P>
      <P>1. 先保存 memory page 一开始两个字的内容。 </P>
      <P>2. 向这两个字中写入任意的数字。比如:向第一个字写入 0x55,第 2 个字写入 0xaa。 </P>
      <P>3. 然后,立即将这两个字的内容读回。显然,我们读到的内容应该分别是 0x55 和 0xaa。如果不是,则说明这个 memory page 
      所占据的地址范围不是一段有效的 RAM 空间。 </P>
      <P>4. 再向这两个字中写入任意的数字。比如:向第一个字写入 0xaa,第 2 个字中写入 0x55。 </P>
      <P>5. 然后,立即将这两个字的内容立即读回。显然,我们读到的内容应该分别是 0xaa 和 0x55。如果不是,则说明这个 memory page 
      所占据的地址范围不是一段有效的 RAM 空间。 </P>
      <P>6. 恢复这两个字的原始内容。测试完毕。 </P>
      <P>为了得到一段干净的 RAM 空间范围,我们也可以将所安排的 RAM 空间范围进行清零操作。 </P>
      <P><B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">3.1.3 拷贝 stage2 到 
      RAM 中</B> </P>
      <P>拷贝时要确定两点:(1) stage2 的可执行映象在固态存储设备的存放起始地址和终止地址;(2) RAM 空间的起始地址。 </P>
      <P><B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">3.1.4 设置堆栈指针 sp</B> 
      </P>
      <P>堆栈指针的设置是为了执行 C 语言代码作好准备。通常我们可以把 sp 的值设置为(stage2_end-4),也即在 3.1.2 
      节所安排的那个 1MB 的 RAM 空间的最顶端(堆栈向下生长)。 </P>
      <P>此外,在设置堆栈指针 sp 之前,也可以关闭 led 灯,以提示用户我们准备跳转到 stage2。 </P>
      <P>经过上述这些执行步骤后,系统的物理内存布局应该如下图2所示。 </P>
      <P><B xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">3.1.5 跳转到 stage2 的 C 
      入口点</B> </P>
      <P>在上述一切都就绪后,就可以跳转到 Boot Loader 的 stage2 去执行了。比如,在 ARM 系统中,这可以通过修改 PC 
      寄存器为合适的地址来实现。 </P>
      <P><A name=N101AE><B>图2 bootloader 的 stage2 可执行映象刚被拷贝到 RAM 
      空间时的系统内存布局</B></A><BR><IMG alt="" 
      src="阿冰BLOG  嵌入式系统 Boot Loader 技术内幕.files/image002.gif" 
      xmlns:dw="http://www.ibm.com/developerworks/" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> </P>
      <P><A name=N101B9><SPAN class=atitle3><STRONG>3.2 Boot Loader 的 stage2 
      </STRONG></SPAN></A><BR>正如前面所说,stage2 的代码通常用 C 
      语言来实现,以便于实现更复杂的功能和取得更好的代码可读性和可移植性。但是与普通 C 语言应用程序不同的是,在编译和链接 boot loader 
      这样的程序时,我们不能使用 glibc 库中的任何支持函数。其原因是显而易见的。这就给我们带来一个问题,那就是从那里跳转进 main() 
      函数呢?直接把 main() 函数的起始地址作为整个 stage2 
      执行映像的入口点或许是最直接的想法。但是这样做有两个缺点:1)无法通过main() 函数传递函数参数;2)无法处理 main() 
      函数返回的情况。一种更为巧妙的方法是利用 trampoline(弹簧床)的概念。也即,用汇编语言写一段trampoline 小程序,并将这段 
      trampoline 小程序来作为 stage2 可执行映象的执行入口点。然后我们可以在 trampoline 汇编小程序中用 CPU 跳转指令跳入 
      main() 函数中去执行;而当 main() 函数返回时,CPU 执行路径显然再次回到我们的 trampoline 
      程序。简而言之,这种方法的思想就是:用这段 trampoline 小程序来作为 main() 函数的外部包裹(external wrapper)。 
      </P>
      <P>下面给出一个简单的 trampoline 程序示例(来自blob): </P>
      <TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#cccccc 
        border=1><TBODY>
        <TR>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -