第二部分：通过网口下载内核映像
要实现通过网口下载文件的功能，从底层到上层需要做的工作包括：开发板上的网卡芯片的驱动程序；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协议的实现
| Source Port |
Destination Port |
| Length |
Checksum |
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;
}
|
