辛德勒的名单开头音乐:MPC860 启动过程分析 ZT

MPC860 启动过程分析 ZT 来源: ChinaUnix博客 　日期：2007.04.09 10:35　(共有条评论) 我要评论  






   嵌入式系统应用开发不同于PC 机，其开发过程同时涉及软硬件，需要将硬件平台的设计、操作系统以及上层应用开发综合考虑；而PC 机应用开发建立在已经定制好的硬件和操作系统平台上，开发者只需调用系统提供的接口和服务完成相应的功能。由于应用和成本约束，嵌入式系统的硬件平台需根据应用量身定制，通常所用的MPU、存储器、外围设备等有多种选择余地，而且软件调试技术特殊，使平台的引导设计变得十分复杂。因此，对于嵌入式系统开发者而言，有必要深入分析系统引导过程，将软硬件开发有效地综合，即针对不同的硬件平台和软件运行模式，正确地进行底层上电初始化，进而引导操作系统执行。这个问题的核心在于对系统的引导模式的研究。
    嵌入式系统的启动代码一般由两部分构成：引导代码和操作系统执行环境的初始化代码。其中引导代码一般也由两部分构成：第一部分是板级、片级初始化代码，主要功能是通过设置寄存器初始化硬件的工作方式，如设置时钟、中断控制寄存器等，完成内存映射、初始化MMU 等；第二部分是装载程序，其功能是将操作系统和应用程序的映像从只读存储器装载或者拷贝到系统的RAM 中，并跳转到相应的代码处继续执行。操作系统执行环境的初始化代码主要由硬件抽象层HAL 代码、设备驱动程序初始化代码和操作系统执行体初始代码三部分构成。
    本文以摩托罗拉MPC860 处理器和具有自主知识产权的操作系统CRTOSII 为例，研究嵌入式系统引导程序的设计和实现技术。嵌入式软件的开发涉及调试模式和固化模式两种运行状态。调试模式主要解决如何在目标板上调试正确性未经验证的程序的问题；而固化模式主要解决如何引导已调试成功的程序的问题。相应地，引导代码的设计应针对两种模式分别进行。
1 调试模式的系统引导
1．1 调试模式引导代码的作用
    一个完整的嵌入式软件的解决方案大致包括四方面：①硬件平台配置初始化和系统引导代码；②操作系统软件执行环境的初始化代码；③操作系统；④应用程序。
    在上述四方面中，引导代码是本研究中力求解决的问题。事实上，板级初始化、操作系统硬件抽象层、设备驱动程序三者整合到一起，就构成了嵌入式系统中BSP（板级支持包）的主体。BSP 的代码与具体的目标板硬件设计相关，同时也与应用程序的设计要求相关，针对应用程序提出的不同要求，例如不同设备驱动程序、不同的中断源个数、不同的中断优先级安排、是否启用MMU 机制等，BSP 部分应作出相应的安排。上述第四
部分的应用程序是建立在前三部分正确运行的基础上，并需反复调试。
    由上述分析可知，BSP 和应用程序代码的正确性通过一次的编写不能得到保证，需要经历“调试——修改——调试”反复的过程，因此需要建立一个可靠的调试环境。该环境建立的基础正是调模式下的引导代码。
2
1．2 引导代码的调试方法
    本研究实验采用一种称作BDM（Background Debug Mode）的OCD（On Chip Debuging）调试技术。BMD 是由Motorola 公司提供的一种硬件调试方法，类似于JTAG 调试。它利用处理器提供的调试端口调试。MPC860 采用一种特殊的BDM——EPBDM，其运作相当于用处理器内嵌的调试模块接管中断及异常处理，用户通过设置调试许可寄存器（debug enable register）指定哪些中断或异常发生后处理器直接进入调试状态，而不是操作系统的处理程序。进入调试状态后，内嵌调试模块向外部调试通信接口发出信号，通知一直在通信接口监听的主机调试器，然后调试器便可通过调试模块使处理器执行系统指令（相当于特权态）。由于专用的片级调试接口装置（BDI2000）的支持，不需要目标端配备相应的调试代理（Monitor）软件。
1．3 调试模式引导代码实现
    调试模式引导代码的核心在于使用BDM 协议解析微指令，通过调试接口向MPC860发送信号，初始化调试环境。由于MPC860 采用RISC 结构，所以初始化部分主要是设置处理器内部寄存器，这个过程包括三方面内容：
1）对处理器相关寄存器进行初始化：主要是关于处理器状态的寄存器（MSR、SRR1、SIUMCR等），中断、时钟相关模块（SYPCR、SCCR、PLPRCR、TBSCR 等）。
2）对BDM 调试端口的初始化：包括调试使能寄存器DER、支持指令断点的寄存器ICTRL等。
3）对片级、板级内存映射的初始化：包括内部内存映射寄存器IMMR，内存控制相关寄存器OR0～0R7、BR0～BR7 等。它们主要功能是地址映射、片选信号选择、内存控制器选择（UMPA、UMPB、GPCM）。如果选择UPM，由于UPM 控制采用微指令方式，而这些微指令根据内存的不同（SRAM、SDRAM、DRAM 等），需要设计人员自行编写代码写入MPC860内部存储区相应位置。对于需要实时刷新的内存（如SDRAM），还需设置刷新控制微指令。
    上述初始化代码得以执行，一方面依赖于目标机MPC860 提供的调试接口支持，另一方面也需要宿主机GDB 的支持。对于宿主机系统，可能选择Linux，在其下配置GBD；也可以选择Windows2000，使用可视化的调试工具LambdaTools GDB（Coretek 公司产品，不支持硬件断点），或者使用BDI2000（支持硬件断点的仿真器）。不管使用哪种调试工具，都可以使用该调试器能够识别的脚本文伯存放初始化指令。这些脚本在功能上是等效的，指令的描述一般都采用如下格式：
     操作码 寄存器 数值
如在嵌入式Linux 下SDRAM 初始化的代码片断为：
mpcbdm spr MDR=0x1FF77C35
mpcbdm spr MDR=0xEFEABC34
mpcbdm spr MDR=0x1FB57C35
……
而在Windows2000 下使用BDI2000 代码为：
WUPM 0x00000005 0x1FF77C35
WUPM 0x00000006 0xEFEABC34
WUPM 0x00000007 0x1FB57C35
……
3
    脚本描述的指令执行后，MPC860 按照预先的设想进入一个可以正常工作的状态，可
以用装载器将程序下载到SDRAM 中调试执行。这个程序主要包含中断表、操作系统和应
用程序映象两部分，其格式可以为bin、elf、coff 等。图1 给出了下载完毕后的内存
映象。
    当程序下载完成后，PC 指针指向Image 代码段（text 段）的首条指令，可以利用
调试器提供的命令开始调试。
2 固化模式的系统引导
2．1 概述
    经过调试后，OS 和上层应用程序构成的Image 的正确性得到了保证，但是这个Image不能自主运行。因为调试模式下，是通过BDM 接口初始化处理器，并且通过BDM 接口将程序下载到RAM 中去运行。实际应用环境中，Image 必须被存储在非易失性存储器中，如Flash、EPROM 等，本文选择Flash。系统启动时，处理器执行一段引导程序替代调试模式下的调试脚本和装载程序的功能。启动代码主要考虑以下几个问题：
（1）系统上电和复位时程序如何执行，需要初始化哪些寄存器，重点仍然是内存映射相关部分；
（2）启动代码为几部分，每部分代码应该全部还是部分放到Flash 或者RAM 中执行；
（3）在时间效率和空间效率的折衷。
2．2 上电初始化
    在两种引导模式下，上电初始化总是必要步骤。它涉及各种核心寄存器初始化、地址映射等问题的处理。
2．2．1 地址映射
    MPC860 的复位是通过一种异常中断来处理的（可理解为CPU 自己产生的中断），向量号为0x100。异常向量表的基地址加上复位向量号即为复位向量，也就是CPU 开始执行指令的地方。异常向量表在内存空间的可能位置有两个：0x0000000 和0xFFF00000。
    所以PowerPC 复位向量为0x00000100 或0xFFF00100。假设复位向量为0xFFF00100，系统有128K 字节的Flash，并准备把它映射到CPU 内存空间0xFE000000 开始的地址。
    MPC860 内部的CS0 片选信号是默认的系统启动片选信号，已被连接到Flash 的片选线上。上电时，内存控制器会忽略所有参与正选逻辑的地址线的高17 位（也就是说只有15bit的空间，32KB），CS0 总是有效。这样，Flash 总会被选中，CPU 从Flash 偏移0x100的地方取指令，此时CPU 的4GB 内存空间的每个128KB 的块都被映射到Flash。
    Boot chip-select operation allows address decoding for a boot ROM before ystem initialization occurs.
    The CS0 signal is the boot chip-select output and its operation differs from the other external chip-select outputs on system reset. When the MPC860 internal core begins accessing memory at system reset, CS0 is asserted for every address, unless an internal register is accessed.
2．2．2 寄存器初始化
    固化方式下的大致相同，但是不再采用脚本文件编写，而是直接将一段MPC860 汇编程序存放在一个start.s 文件中。与调试模式初始化程序一样，主要完成以下处理：
（1）初始化CPU 核心寄存器；
（2）设置机器状态寄存器；
（3）禁止cache；
（4）初始化IMMR；
（5）初始化系统接口单元（SIU）；
（6）初始化时钟和中断控制寄存器；
（7）初始化通信处理机（CPM）；
（8）初始化内存控制器（UPM）；
（9）初始化C 语言堆栈。
2．2．3 地址空间重映射
    上电时，由于只有一个片选信号CS0 有效，它选通了Flash，而RAM 和其它存储设备地址无效，需要经过地址空间重映射Remap 才能访问。MPC860 的地址空间重映射是通过设置0R0～OR7、BR0～BR7 这16 个寄存器完成的。由于上电时4GB 的地址空间均被Flash 占用，所以0xFFF00100 这个地址仍在Flash 的偏移0x100 处。在寄存器初始化过程中，需要把SDRAM、MPC860 内部寄存器空间以及外设等也映射进来。在进行这些操作前，需要把Flash 的位置固定下来，例如映射到0xFE000000，这个操作是通过设置OR0和BR0 寄存器实现的。但在写OR0 时，CPU 仍然在0xFFF00000 的那一块取指令，而Flash即将被映射到0xFE000000，所以程序必定出现“跑飞”的现象，必须对程序计数器（PC）进行调整，然而PC 指针对程序员是不可见的，必须用绝对跳转指令修改它。在Flash地址映射完成后，通过设置OR1～OR7、BR1～BR7 可以完成对所有存储器空间的映射，各种存储设备可映射在CPU 地址空间中的任意位置，但相互之间不能冲突。
而Uboot 中是这么实现的，既然任何运行地址都可以寻址到flash 中的代码，所以就先改变运行地址（或者说环境）为0xfe00xxxx,然后再把flash remap 到0xfe000000,避免了先remap 引起的地址混乱，因为remap 后CPU 就不再按照上电初始的方式来寻址了。
/* Calculate absolute address in FLASH and jump there---*/
lis r3,
[email=CFG_MONITOR_BASE@h]CFG_MONITOR_BASE@h[/email]
ori r3, r3,
[email=CFG_MONITOR_BASE@l]CFG_MONITOR_BASE@l[/email]
addi r3, r3, in_flash - _start + EXC_OFF_SYS_RESET
mtlr r3
blr
in_flash:
2．3 引导代码的构成和运行
    系统启动所涉及的代码由寄存器初始化汇编文件start.s、一个Load 程序以及操作系统与应用程序的Image 三部分构成，引导代码则只包含start.s 和Load 程序。Load程序的作用是将操作系统与应用程序的构成的Image 从Flash 拷贝到SDRAM 中，并跳转到Image 的首条指令。调试完成后的Image 有两种运行模式：
    1)Flash-resident image: Load 程序仅仅 把Image 中的数据段（data bss）复制到RAM中，代码段（text）在Flash 中直接运行。
    2)Flash-based image: Load 程序把Image 完全搬到RAM 中执行，包括image 中的代码段（text）和数据段（data bss）。
    图2 和图3 分别描述了两种Image 的存贮映象，以及从Flash 到SDRAM 的装载过程。


   
2．4 时间效率和空间效率上的折衷
    在嵌入式系统的应用过程中，针对不同的应用环境，对时间效率和空间效率有不同的要求，基于MPC860 的启动代码对此有比较充分的解决方案。
2．4．1 时间限制
    时间限制主要包括两种情况：系统要求快速启动和系统启动后要求程序高速执行。对于要求快速启动的系统，应该使在Flash 中执行的初始化程序尽量简短，诸如循环语句之类的语法应该尽量减少，尽快将程序装载到RAM 中执行，这样做的原因在于Flash的访存时间与RAM 的访存时间存在数量级上的差距。但是必须根据代码量以及存储器的特片进行权衡。因为，虽然RAM 中捃速度快，但是将Flash 中的代码复制到RAM 中的操
作会带来一定的开销。由于可见，启动时间由Flash 中引导代码的运行时间、代码从Flash 拷贝到RAM 的时间以及RAM 中后续启动代码的运行时间三部分组成。启动时间的最小值是这三者和的最小值。
    对于启动后要求程序高速执行的系统，主要受处理器、存储器特性以及I/O 速度等的影响。在软件方面，应该采用了上述Flash-based image 方式，使得代码段在RAM 中运行，提高运行速度。
2．4．2 空间限制
    空间限制主要包括两种情况：Flash 等非易失性存储空间有限和RAM 等易失性空间有限两种系统。
对于采用高性能非易失性存储器的系统，出于成本因素，Flash 等存储设备不能太大，然而它又是系统存放启动代码和操作系统Image 的地方。在存放Image 时，可以先使用gzip 等压缩工具进行压缩，在将Image 加载到RAM 时采用逆向的解压缩算法解压。同时，出于实时性考虑，压缩算法不能过于复杂，否则压缩解压过程消耗大量时间将与启动时间限制发生严重冲突。采用压缩策略并不一定会增加系统启动时间，因为压缩解压过程虽然消息了一定的时间，但是由于Image 体积减小，由Flash 复制到RAM 中的时间相应减少，有可能反而减少了时间消耗。
    对于采用高性能RAM 的系统，同样出于成本因素，RAM 空间有一定限制，此时一般采用前文描述的Flash resident image 方式：Load 程序把Image 中的数据段复制到RAM 中，代码段在Flash 中运行。折衷同样存在，因为code 段在低速的Flash 中运行，在节省空间的同时，却牺牲了时间。
    本文介绍了基于嵌入式处理器的操作系统引导方法，重点研究嵌入式系统的引导模式以及不同类别的引导方法。以在MPC860C 处理器上引导CRTOSII 操作系统为例，阐述了调试模式和固化模式下引导代码的构成、作用以及执行方式，并对不同引导模式下的时空效率的折衷进行了分析。最终，借助BDI2000 仿真器对编写的引导代码进行调试，成功实现了调试模式和固化模式下操作系统的引导。后续工作包括：继续研究在不同硬
件平台上的操作系统引导方法，例如最流行的ARM、X86 系列；在同一平台上，可以研究不同操作系统的启动方法，例如嵌入式Linux、Vxworks、WinCE 等。同时，可以引入数字模型对时间、空间性能进行量化分析，以便在不同环境下采取比较合适的引导方案。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/20871/showart_273797.html