定位了RTEMS移植CS8900驱动的时候产生的 data abort exception 问题

之前是照葫芦画瓢，修改了几个结构体的定位，但是我一直觉得，不应该这样去处理的，今天有点时间，又继续研究

这个问题，我感觉是对齐问题，研究结论如下：

确定对齐问题，参考了 freeBSD 8.4 的代码

首先，以太网的头部因为只有14个字节，对于ARM来说，这肯定会出现问题的，所以需要添加 packed属性，让它
按照字节对齐，这样sizeof(ether_header) 的时候是 14，而不加属性的话是 16。freeBSD 8.4的代码中同样是需要
添加这个属性的，rtems不知道为什么这里没有更新。
struct ether_header {
} __packed;


其次是 ip包头结构，这个因为理论上都是4个字节对齐的所以不需要添加也没啥，但是参考 freeBSD 8.4 代码，这里
也添加了吧
struct ip {
} __packed __aligned(4);


最后
-mstructure-size-boundary=32 保持 32bit对齐，这样指令比较高效。


这样还不行，因为原来的驱动有点问题，其实主要是对齐出的问题，不是对齐的话这样写是没有问题的，libchip的其他
网络代码也是这样写，但是这个平台需要点特殊吧。
eh = mtod (m, struct ether_header *);
m->m_data += sizeof (struct ether_header);
首先以太头部指向所有接收缓冲，然后数据指针移动 sizeof (struct ether_header)，也就是 14字节了。得到的是 IP
指针，也就是说，如果mbuf本身是对齐的话， IP 偏移了14字节，指针变成了 +0E 这个地址上了，这个地址并不是4字节对齐
在ARM平台上访问结构体成员，会产生错误，data abort exception。这个问题困扰了我很久，我阅读了 ether_input 和 
ip_input 函数，对比了 freeBSD，和实验才得出的结果，看来真正的问题应该是这里了。
 
我的处理办法是将以太网头用一个独立的buffer保存，然后移动IP数据实现4个字节对齐，就不会产生问题了，当然了，
这里只是实验成功，还真的需要好好写驱动。
static char eh_buf[16];


        // debug
        memcpy(eh_buf, eh, sizeof(struct ether_header));
        m->m_data -= 2;
        memcpy(m->m_data, m->m_data+2, m->m_len);
        
        eh = (struct ether_header*)eh_buf;
        //
        ether_input (ifp, eh, m);


目前测试 ping，tcp，http 都是正常的，压力测试还没有做，因为驱动还不是做的很好，ping200次就irq锁死，具体问题
还在定位中，感觉是驱动的问题，和协议栈无关。