第二部分:通过网口下载内核映像
要实现通过网口下载文件的功能,从底层到上层需要做的工作包括:开发板上的网卡芯片的驱动程序;TCP/IP协议栈的实现;TFTP客户端应用程序的实现。我们使用的OK2440开发板配备CS8900A网卡芯片。 为了简单起见,网络数据包的发送和接收都使用轮询方式,不使用中断;协议栈只使用ARP/IP/UDP协议,不涉及TCP及其他协议;应用程序只实现最简单的TFTP客户端。
1. 全局配置信息
发送和接收的数据缓冲区,使用
全局静态缓冲区,不使用动态内存分配。第一阶段运行结束之后,CPU内部4KB的SteppingStone可以用作其它用途,我们就用它做网络数据接收、发送的缓冲区。亦可用作标准输入输出的缓冲区。
unsigned char *TxBuf = (unsigned char *)0;
unsigned char *RxBuf = (unsigned char *)1024;
使用若干个全局变量来保存网络配置信息:
unsigned char NetOurEther[6] = /* Our ethernet address */
{0x00, 0x09, 0x58, 0xD8, 0x11, 0x22};
开发板的MAC地址,这个是任意
设置的。
unsigned char NetServerEther[6] = /* Boot server enet address */
{0x00, 0x14, 0x2A, 0xA5, 0x50, 0x97};
服务器也就是主机的MAC地址,这个要跟主机MAC一致,可以在主机上运行ifconfig命令查到。
unsigned long NetOurIP = 0xC0A801FC; /* Our IP addr 192.168.1.252 */
unsigned long NetServerIP = 0xC0A801F9; /* Server IP 192.168.1.249 */
网络协议中IP地址一般是用一个4字节整型数表示的。
2. CS8900A以太网驱动程序
硬件电路决定了CS8900的物理地址是在BANK3的区间内,CS8900是16位的寄存器,故我们设置BANK3的BUS WIDTH也为16位。设置BANK3: 总线宽度16,使能nWait,使能UB/LB
BANKCON3:0x1F7C
网卡CS8900的访问基址为0x19000000,之所以再偏移0x300是由它的特性决定的
#define CS8900_BASE 0x19000300
CS8900 读写寄存器的方式有些特别。要读一个寄存器,先向CS8900_PPTR中写入该寄存器地址,再从CS8900_PDATA中读出该寄存器值;要写一个寄存器,先向CS8900PPTR中写入该寄存器地址,再向CS8900_PDATA中写入要写入的值。不管是寄存器地址还是要读写的数值,都是16位的,也就是说都是unsigned short类型的。因此,读写寄存器的函数如下:
static unsigned short get_reg (int regno) { CS8900_PPTR = regno; return CS8900_PDATA; } static void put_reg (int regno, unsigned short val) { CS8900_PPTR = regno; CS8900_PDATA = val; } |
读芯片ID: CS8900的芯片ID存放在PP_ChipID寄存器中,读该寄存器得到的正确值应该是0x630E,这可以初步判断一些地址/引脚的设置是否正确,如果读出的不是0x630E,那么CS8900肯定不能正常工作。
设置MAC地址:
MAC地址并不是固定的,可以由我们随意设置。从寄存器PP_IA开始的6个字节存放MAC地址。比如下面的代码把MAC地址设为 00 09 58 D8 11 22:
put_reg (PP_IA + 0, 0x00 | 0x09 << 8); put_reg (PP_IA + 2, 0x58 | 0xD8 << 8); put_reg (PP_IA + 4, 0x11 | 0x22 << 8); |
因为是Little Endian, 所以0x09<<8, 但是在寄存器内存中还是 0x00放在前面。
寄存器初始化: 设置CS8900的工作模式
/* 只接收目标地址为本网卡的无错误数据包 */ put_reg (PP_RxCTL, PP_RxCTL_IA | PP_RxCTL_Broadcast | PP_RxCTL_RxOK); /* 当进行接收操作时,不要产生任何中断 */ put_reg (PP_RxCFG, 0); /* 当进行发送操作时,不要产生任何中断 */ put_reg (PP_TxCFG, 0); /* 当进行缓存操作时,不要产生任何中断 */ put_reg (PP_BufCFG, 0); /* 使能发送和接收模式 */ put_reg (PP_LineCTL, PP_LineCTL_Rx | PP_LineCTL_Tx); |
发送数据包:
int eth_send (volatile void *packet, int length)
两个参数:要发送的数据包首地址、长度
TxCMD 和TxLen寄存器用来初始化数据包的发送,其具体含义见CS8900数据手册第70页。这里PP_TxCmd_TxStart_Full被定义为 0x00C0,表示直到整个数据侦都加载到CS8900内部缓存之后才开始发送,数据侦的长度为CS8900_TxLEN.
/* initiate a transmit sequence */ CS8900_TxCMD = PP_TxCmd_TxStart_Full; CS8900_TxLEN = length; |
使用TxCMD下达发送数据的命令后,再读取 PP_BusSTAT 总线状态寄存器判断是否做好发送数据的准备。当get_reg (PP_BusSTAT) & PP_BusSTAT_TxRDY 不等于零时表示可以发送了。 使用一个循环进行实际的发送操作:
for (addr = packet; length > 0; length -= 2) { CS8900_RTDATA = *addr++; } |
这里 addr 也是unsigned short类型的指针, 每次向CS8900_RTDATA写入两个字节数据。这里假设要发送的数据包长度为偶数。
最后,通过读取PP_TER寄存器可以知道是否发送完毕,是否发送成功。
接收数据包:
首先,通过读取PP_RER寄存器判断是否接收到数据。如果接收到数据,则连续两次读取 CS8900_RTDATA 的值,
status = CS8900_RTDATA; /* stat */
rxlen = CS8900_RTDATA; /* len */
rxlen 为接收到的数据长度。
然后用一个循环连续读取 rxlen 长度的数据:
for (addr = (unsigned short *) &RxBuf[0], i = rxlen >> 1; i > 0; i--) *addr++ = CS8900_RTDATA; if (rxlen & 1) *addr++ = CS8900_RTDATA; |
其中 RxBuf 为预先在内存中开辟的一块接收缓冲区。 每次循环读取两个字节,还需要处理长度为奇数的情况。
最后,把RxBuf交给上层的协议处理:net_receive( &RxBuf[0], rxlen );
3. Ethernet MAC层协议的实现
上层的数据包(如IP包、ARP包)到来时,需要添加一个14字节的MAC头, 然后再交给网卡发送出去。 MAC头包含目的MAC地址、源MAC地址、协议类型三个字段。如下图所示。数据包末尾的CRC校验我们不使用。
使用下面的代码填充MAC头。其中协议类型,对IP为0x0800, 对ARP为0x0806
struct mac_header *p = (struct mac_header*)(buf); memcpy (p->dest, NetServerEther, 6); memcpy (p->src, NetOurEther, 6); p->proto = htons(proto); |
4. ARP协议的实现
一般的方式是建立一个全局的ARP映射缓存表,随着系统的运行不断查找、更新该表。但是我们要完成的功能仅仅是从TFTP服务器下载内核和文件系统映像,而服务器的IP和MAC地址都是固定的,因此可以简化ARP映射表,只用两个变量分别保存服务器IP和MAC,再用两个变量保存开发板IP和MAC即可。并且更新映射表的功能也可以省略,只在系统初始化时把这四个地址都设置好,使用过程中不会发生改变,所以不需要更新。这样,我们的ARP协议只需要完成接受ARP请求、发送ARP应答的功能,而发送ARP请求和接受ARP应答的功能可以省略,这样大大简化了协议栈的设计。
按照维基百科上的介绍(http://en.wikipedia.org/wiki/Address_Resolution_Protocol),ARP 是一个数据链路层协议,(我感觉它应该是网络层的协议),它的作用是在只知道一个主机网络层IP地址的情况下找到它的硬件地址。在以太网上,它主要用来把 IP地址转换为以太网MAC地址。由于是链路层协议,ARP的作用范围仅限于本地局域网。
ARP数据包长度为28字节,其中各字节的含义如下图所示:
对各个段作简单的解释:
Hardware type (HTYPE) 每个数据链路层协议都被分配到一个数,比如,Ethernet 是 1
Protocol type (PTYPE) 在这个域,每个网络层协议都被分配到一个数(标号),比如,IP是0x0800
Hardware length (HLEN) 硬件地址的长度。以太网Ethernet的MAC地址长度是6个字节
Protocol length (PLEN) 维基上写的是“逻辑地址”的长度,其实也就是网络层地址的长度。IPv4地址的长度为4个字节。
Operation 表明发送者的操作,也就是数据包的类型:1表示ARP请求;2表示ARP回应;3表示RARP请求;4表示RARP回应。
Sender hardware address (SHA) 发送者的硬件地址
Sender protocol address (SPA) 发送者的协议地址,也就是发送者IP地址。
Target hardware address (THA) 目标接收者的硬件MAC地址。如果是ARP请求,这个域被忽略。
Target protocol address (TPA) 目标接收者的IP地址。
知道了包结构,我们就可以设计一个结构体:
struct arp_header{ unsigned short ar_hrd; /* Format of hardware address */ unsigned short ar_pro; /* Format of protocol address */ unsigned char ar_hln; /* Length of hardware address */ unsigned char ar_pln; /* Length of protocol address */ unsigned short ar_op; /* Operation */
unsigned char ar_sha[6]; /* Sender hardware address */ unsigned long ar_spa; /* Sender protocol address */ unsigned char ar_tha[6]; /* Target hardware address */ unsigned long ar_tpa; /* Target protocol address */ }__attribute__ ((packed));
|
属性 __attribute__((packet)) 告诉编译器使用紧缩方式存放结构体内容(1 Byte align), 不使用默认的4字节对齐, 这样就不会产生冗余字节。此时的 sizeof(struct arp_header) = 28。 如果不加packed属性, 运行 sizeof(struct arp_header) 得到 32, 而不是 28。 数据段就产生了错位。
前面已经说过,我们只实现接收ARP请求并发送ARP应答的功能,因此只用一个简单的函数就可实现:
static int arp_handle( unsigned char *buf, unsigned int len ) { struct arp_header *pRx, *pTx; pRx = (struct arp_header *)(buf); pTx = (struct arp_header *)&TxBuf[256];
switch (htons(pRx->ar_op)) { case ARP_REQUEST: if (pRx->ar_tpa == htonl(NetOurIP)) { pTx->ar_hrd = htons(0x01); pTx->ar_pro = htons(PROTO_IP); pTx->ar_hln = 0x06; pTx->ar_pln = 0x04; pTx->ar_op = htons(ARP_REPLY); memcpy(pTx->ar_sha, NetOurEther, 6); pTx->ar_spa = htonl(NetOurIP); memcpy (pTx->ar_tha, pRx->ar_sha, 6); pTx->ar_tpa = pRx->ar_spa; mac_send( (unsigned char*)pTx, sizeof(struct arp_header), PROTO_ARP); } break; case ARP_REPLY: printf("/n/rGot ARP reply/n"); break; default: printf("/n/r ar_op Not Support./n"); break; } return 0; } |
接收到的数据保存在pRx地址处,要发送的数据地址指定为pTx位于发送缓冲区中。如果接收到的是ARP请求包并且IP地址也符合,则在pTx处构造一个ARP应答包并交给mac_send()发送出去。
5. IP协议的实现
IP
数据包的格式如下表所示:
+ |
Bits 0–3 |
4–7 |
8–15 |
16–18 |
19–31 |
0 |
Version |
Header length |
Type of Service |
Total Length |
32 |
Identification |
Flags |
Fragment Offset |
64 |
Time to Live |
Protocol |
Header Checksum |
96 |
Source Address |
128 |
Destination Address |
160 |
Options |
160 or 192+ |
Data |
IP协议的简化:IP协议在网络中主要完成路由选择和网络分段的功能。起始Bit 0-3表示版本号,对IPv4来说取值为4即0100即可。Header length域指明IP数据包header的长度(不包括数据Data域),以四字节为单位,因为Options域是可选的所以IP Header的长度并不固定。我们不使用Option域,所以取最小值5,表示Header长度为20字节。服务类型域(Type of Service, TOS)是为特殊的应用如VoIP等保留的,我们不使用,赋值为零即可。接下来2个字节的Total Length域表示整个数据包的长度,包括Header和Data,以字节为单位。 标识域(Identification)用来给数据包一个唯一的编号,用于验证和跟踪等,我们不使用,直接赋值为零即可。Flags和Offset用于分段包的重组,我们不使用,把Flags的第2位设为1表示是不可分段的,Offset赋值为零即可。生存时间(Time to Live, TTL)表示该数据包在网络上的有效期,我们简单的把它设为最大值0xFF即可。协议域(Protocol)表示传输层使用什么协议,RFC790文档为每个协议都规定了唯一的编号,如UDP编号为17。Header Checksum为Header区域的校验和,在校验之前该域初始为0,然后计算整个头部的校验和,把结果存放在该域,计算校验的方法是把头部看成以16位为单位的数字组成,依次进行二进制反码求和。接下来的八个字节是源IP地址和目的IP地址,没什么可说的。
综上所述,我们只保留了IP协议中必须的关键字段,因而简化了设计,对IP数据包进行填充的代码段如下:
struct ip_header *p = (struct ip_header*)(buf); p->ver_ihl = 0x45; // 1 Byte p->tos = 0x00; // 1 Byte p->tlen = htons(len); // 2 Byte p->identification = htons(0x00); // 2 Byte p->flags_fo = htons(0x4000); // 2 Byte p->ttl = 0xFF; // 1 Byte p->proto = 17; // 1 Byte, 17 for UDP p->ip_src = htonl(NetOurIP); // 4 Byte p->ip_dest = htonl(NetServerIP); // 4 Byte p->crc = 0x0; // 2 Byte, To be p->crc = checksum( buf, sizeof(struct ip_header) ); |
CheckSum 校验和:
IP,TCP,UDP等许多协议的头部都设置了校验和项,它们采用的算法是一样的,将被校验的数据按16位进行划分(若数据字节长度为奇数,则在数据尾部补一个字节0),对每16位求反码和,然后再对和取反码。 代码如下:
unsigned short checksum(unsigned char *ptr, int len) { unsigned long sum = 0; unsigned short *p = (unsigned short *)ptr; while (len > 1) { sum += *p++; len -= 2; } if(len == 1) sum += *(unsigned char *)p; while(sum>>16) sum = (sum&0xffff) + (sum>>16); return (unsigned short)((~sum)&0xffff); } |
6. UDP协议的实现
bits |
0 - 15 |
16 - 31 |
0 |
Source Port |
Destination Port |
32 |
Length |
Checksum |
64 |
Data |
在传输层我们抛弃了复杂的TCP协议而使用简单的UDP协议。虽然UDP是无连接的协议,它不保证数据包一定能够到达目的主机,但是在嵌入式开发中,开发板跟主机通常位于同一内部局域网内,网络环境良好,数据丢失的可能性很小,并且UDP容易实现,占用资源小,因此更适合于嵌入式环境。 UDP头部包含了可选的校验和字段,而校验要涉及到伪报头,为了简化设计和减小开销,我们不使用校验,直接把该字段设为零,表示不使用校验。UDP包填充代码如下:
struct udp_header *P = (struct udp_header*)(buf); P->port_src = htons(0x8DA4); // 2 Byte P->port_dest = htons(port); // 2 Byte P->tlen = htons(len); // 2 Byte P->crc = 0x00; // Do Not Checksum, 2 Byte
|
关于源端口号和目的端口号的设定,在TFTP实现时会详细说明。
7. TFTP客户端的实现
tftp是一个很简单的文件传输协议,在传输层使用UDP协议。它有四种类型的包: 读请求RRQ包,DATA包,ACK包,ERROR包,每个包的前两个字节Opcode指定包的类型。(RRQ用于请求下载,WRQ用于请求上传,我们只用到RRQ)。
下载文件的过程分析如下: 客户端(A)从任意端口X向服务器(S)的端口69发送一个RRQ包,该包中指明了要求下载的文件名;服务器(S)找到该文件,读取文件内容组成DATA包,从任意端口Y向客户端(A)的端口X发送这个DATA包,第一个DATA包编号为1;从此以后,客户端确定使用端口X,服务器确定使用端口Y, 客户端向服务器发送ACK包,编号为1。服务器接到编号为1的ACK包之后,发送第二个DATA包,如此继续下去。
怎样判断传输结束呢? 按照规定,DATA包中的数据段为512字节, 如果小于512字节,表示这是最后一个DATA包,文件已传输完毕。
(R1) Host A requests to read
(R2) Server S sends data packet 1
(R3) Host A acknowledges data packet 1
注意在这个过程中端口的变化。开始RRQ是69,但是DATA和ACK都不是使用69,而是使用另外一个随机的端口。 服务器在接到RRQ后,不返回任何回应信息,直接发送第一个DATA包,而且DATA包编号从1开始,而不是从0开始。
编程时为简单起见,客户端使用了固定的端口号X=0x8DA4,服务器端口号Y是随机的,只能通过解析UDP数据包获得。
int tftp_download(unsigned char *addr, const char *filename) { int i=0; unsigned short curblock = 1;
tftp_send_request( &TxBuf[256], filename ); msdelay(100);
while (1) { eth_rx(); if( pGtftp == NULL ) continue; if ( ntohs(pGtftp->opcode) == TFTP_DATA ) { if (ntohs(pGtftp->u.blocknum) == curblock) { printf("/r Current Block Number = %d", curblock); for (i=0; i<iGLen-4; i++) { *(addr++) = *(pGtftp->data+i); } tftp_send_ack( &TxBuf[256], curblock); if (iGLen < TFTP_DATASIZE+4) { break; } curblock += 1; } else if (ntohs(pGtftp->u.blocknum) < curblock) { tftp_send_ack( &TxBuf[256], ntohs(pGtftp->u.blocknum)); } else { printf("/n/rBlock Number Not Match."); printf("Block Number = %d, curblock = %d/n", ntohs(pGtftp->u.blocknum), curblock); } } else if ( ntohs(pGtftp->opcode) == TFTP_ERROR ) { switch( ntohs(pGtftp->u.errcode) ) { // 此处省略 } } else if ( ntohs(pGtftp->opcode) == TFTP_RRQ ) {}// 此处省略若干 else if pGtftp = NULL; iGLen = 0; } printf("/n/rTransfer complete: %d Bytes./n/r", (curblock-1)*TFTP_DATASIZE + iGLen-4 ); return 0; } |