嵌入式系统ARM的通用bootloader的设计与实现 第9页

嵌入式系统ARM的通用bootloader的设计与实现 第9页
本文中静态地文护一个命令数组，数组成员都是monCommand结构的，将要支持的命令以及相关处理保存在该数组中。Bootloader进入命令行状态后，一直等待串口的输入（即命令），当终端有输入时，读取数据，然后上面提过的数组中查找看是否有注册过，如果有立即执行对应的执行函数，如果没有，则继续等待。
这样，以用户通过敲击键盘作为数据输入，bootloader通过串口接收到数据为触发，bootloader就进入等待命令状态，也同时进入下载模式；紧接着通过用户的命令，bootloader的执行完成相关的下载操作或者其它的处理。
（3） 通过串口使用XMODEM协议进行下载内核镜像
通过串口的接收功能可以进行内核镜像的下载，由于硬件串口以及相应软件上的支持使
得硬件以及链路层可以完全支持，关键的问题在于上层的通信协议以及要顾及到PC端的实现（下载内核镜像一般放在PC端）。由于bootloader中调试信息也是通过串口输出，如果上层协议处理不当，两者会有冲突。考虑到PC端都使用WINDOWS操作系统，它自带的超级终端（可以使用多种传输协议）非常方便，因此本课题在bootloader中使用XMODEM协议来作为串口传输的上一层协议，PC端就直接使用超级终端。
 下面简单介绍一下XMODEM协议：
XMODEM协议是一种使用拨号调制解调器的个人计算机通信中广泛使用的异步文件运输协议。这种协议以128字节块的形式传输数据，并且每个块都使用一个校验和过程来进行错误检测。如果接收方关于一个块的校验和与它在发送方的校验和相同时，接收方就向发送方发送一个认可字节。然而，这种对每个块都进行认可的策略将导致低性能，特别是具有很长传播延迟的卫星连接的情况时，问题更加严重。因此延伸出与XMODEM想似的协议。使用循环冗余校验的与XMODEM相应的一种协议称为XMODEM－CRC。还有一种是XMODEM－1K，它以1024字节一块来传输数据[14]。
具体的数据包格式如表4.1[14]所示（按低字节开始）：

<soh>表示为标准xmod本文来自辣文论文网em协议，每次传送128字节
或者
<stx>表示为1k xmodem协议，每次传送1024个字节 占1个字节
数据块号，第一个数据块为01h 占1个字节
数据毕业论文http://www.Lwfree.cn和和CRC校验 占1个或者2个字节
         表4.1

定义：<soh> 01H,  <stx> 02H,  <eot> 04H ， <ack> 06H  ，<nak> 15H ， <can> 18H
具体的数据流如下：
    发送端     接受端
         <---  <nak>
<soh> 01 FE -data- <xx> --->
         <---  <ack>
<soh> 02 FD -data- xx ---> （未成功）
         <---  <nak>
<soh> 02 FD -data- xx --->
         <---  <ack>
<soh> 03 FC -data- xx --->
             <---     <ack>
<eot>   --->
         <---  <ack>
        图4.3
实现上，首先在命令数组注册命令“xmodem”，以及相应的执行函数Xmdoem，帮助函数xmodemhelp。当bootloader进入等待命令状态后一直等待接收串口数据，用户端键入“xmodem –d”，则串口接收到数据后，在表中查找到命令“xmodem”，立刻执行函数int Xmodem(int argc,char *argv[])，然后确认参数为“-d”，说明是下载功能，代码就利用xmodem协议通过串口与PC端利用超级终端通过串口进行数据传输。
为了防止冲突，最终传输的内核镜像仍然存放在物理地址的0xa0300000处，与设计中的一致。

（4） 通过USB接口进行镜像下载
通过串口进行内核镜像的下载，受到速度的限制，当开发者以后使用ramdisk（linux中的概念）时，通常要下载若干兆的数据，这时串口的速度劣势更加明显地表现出来了。本课题使用的硬件环境中，CPU PXA255芯片内置了一个USB 1.1设备端的控制模块，因此可以在bootloader中增加对USB传输的支持。
通过USB进行传输，硬件底层以及链路层都通过USB1.1协议，但是传输是双方面的，双方如何进行通信，如何进行同步，则成为关键问题。由于bootloader中增加该功能扩展，有着很强的目的性，就是为了下载内核镜像，因此在本课题中自己定义了一套简单的传输协议，包括通信流程以及具体的数据包格式。在本功能中，主机对应PC，从机对应本文的硬件系统。

本文中通信双方数据传输都使用数据包（packet）格式，具体格式如下：
数据包格式：
数据包头 Header 数据块 block

每个packet都有一个packet header，其定义如下：

typedef struct tagUSB_PACKET_HEADER
{
    毕业论文http://www.Lwfree.cn;
    USHORT payloadSize;  
} USB_PACKET_HEADER, *PUSB_PACKET_HEADER;

其中headerSig为头标志，本课题设为“kITL”，payloadSize为后面数据块Block Data的长度，以字节为单位。

pktType为数据包类型，表明Header后面所跟的Block Data的类型。我们定义了三种类型：
 Boot Request：此时pktType=0xBB，后面数据块Block Data为USB_BOOT_REQUEST类型，它是由从机向主机发送，请求开始传输数据，定义为：
typedef struct tagUSB_BOOT_REQUEST
{本文来自辣文论文网
        char PlatformId[KITL_MAX_DEV_NAMELEN+1];
        char DeviceName[KITL_MAX_DEV_NAMELEN+1];
        short reserved;
} USB_BOOT_REQUEST, *PUSB_BOOT_REQUEST;

 Boot ACK：此时pktType=0xDD，后面的数据块Block Data为USB_BOOT_ACK类型。它是主机接收到Boot Request请求后向从机发送的，表明主机已准备好向从机发送数据，定义为：

typedef struct tagUSB_BOOT_ACK
{
         DWORD fJumping;
} USB_BOOT_ACK, *PUSB_BOOT_ACK;

 Data：此时pktType= 0xCC，后面的数据块Block Data为传输数据块，它是由主机发送给从机的。它的前四个字节为USB_BLOCK_HEADER，后面为真正的传输数据。
Block Data：
USB_BLOCK_HEADER DATA

其中USB_BLOCK_HEADER定义如下：

typedef struct tagUSB_BLOCK_HEADER
{
    DWORD uBlockNum;    /*本数据块编号。第一个数据块为1*/
} USB_BLOCK_HEADER, *PUSB_BLOCK_HEADER;

具体的通信过程为:
1. 客户端(即从机)调用USBSendBootRequest()函数向主机端发送Boot请求；
2. 主机端程序USBBoot一旦收到Boot请求，立即向客户端发送Boot ACK应答，表示主机端已准备好；
3. 客户端接受到Boot ACK后，进入数据传输阶段；
4. 客户端向主机端发送数据请求包(Data request)，在包中指明所要数据包号(第一个数据包号为0)；
5. 主机端程序接收到数据请求包(Data request)，则向客户端发送数据包；重复过程4、5，直到数据传送结束。

在bootloader中增加USB传输支持，与串口有一点不同的是：串口的独特作用被默认为bootloader的基本功能，因此串口直接进行初始化，无需任何的触发；而为了bootloader最终生成的镜像文件不至于太大，只有在bootloader进入等待命令行状态后，用户敲入“USB”

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] 下一页

嵌入式系统ARM的通用bootloader的设计与实现 第9页下载如图片无法显示或论文不完整，请联系qq752018766