使用同一个u盘安装的ubuntu-7.10操作系统的两台电脑，
一个AMD处理器（DELL OptiPlex 740)
一个Intel处理器（DELL OptiPlex 330)
安装完成后两台电脑均使用gcc4.1.3、g++4.1.3编译器对gliethttp_flash.c进行编译，
结果分别生成的gliethttp_flash.ko文件使用diff比较之后，出现不同，
ls -l发现两个文件大小竟然都不一样，
125431 AMD处理器（DELL OptiPlex 740)
125335 Intel处理器（DELL OptiPlex 330)
怎么会这样溺？
经过询问，原来两台机子，一台机子经过了ubuntu升级，另一台没有经过ubuntu升级，但是并不是这里的问题，
因为都经过升级后，依然不同，对于升级所说的lib库，因为编译的是ko内核驱动程序，所以和用户态的库并无关系，
另外因为Intel处理器（DELL OptiPlex 330)的指令cache和数据cache都比AMD处理器（DELL OptiPlex 740)大，
所以Intel处理器（DELL OptiPlex 330)上运行的程序要快很多也是正常的！！
先下载userdata.img然后烧写会消耗一定时间,接下来
下载system.img然后又会烧写消耗一定时间,最后
下载剩下的7个小文件，一般都是在下载system.img的时候出现异常，那么干脆
将userdata.img和system.img分别制作成.mff文件下载,将另外的7个小文件制作成单独的.mff文件，
这样能够临时的使用usb下载烧写文件，不查了，浪费时间，实在是找不到问题在哪了，唉！
ps：可以肯定的是pc确实已经把通信数据发送下去了,在调用read的时候,一直不能等到设备返回应该返回的状态信息，协议上可能不存在丢包后数据重发机制，所以可能确实是因为pc下发的数据包丢失了，所以设备端因为没有收到数据,以及校验包完整性措施，进而，不能和tcp/ip数据传输那样有很好的容错能力，看来marvell设计的这个通信不成熟阿，
所以在协议设计上，对丢包处理、数据干扰后的校验重传机制等对任何产品来说不是必要的，而是必须的，所以文件切包之后进行包序号标记是很有意义的,可以参考成熟的tcp/ip数据传输、校验、重传等方式！[gliethttp_20080529]
ps：所以从这里来看,所谓的设备通信不稳定，就是在于设备对丢包和误码处理不完善，虽然bulk类型端口的通信能够保证数据传输正确性，但是不能保证因
为线路干扰严重或者系统自身的问题超过bulk内定的重试次数之后引起的丢包现象！[gliethttp_20080529]
阅读(2084) | 评论(0) | 转发(0) |
