OMAP3530 WIFI 调试手记

       很久没有遇到过这么折磨人的工作了，随着昨天换了器件，设备工作正常后，折磨人的状态也可以告一段落了。调试最郁闷的阶段时，曾设想过结果，总觉得出个稳定结果是那么遥不可及，总觉得设备能正常工作了简直是天方夜谭，当时就想，要是有一天能调通了，一定得作个总结。称着现在还记得细节，把调试过程记录一下，好为以后工作时做个参考。

运行平台：OMAP3530-MINI开发板

操作系统：Linux 2.6.28

处理器：ARM ContexTM-A8

文件系统：Angstrom

调试设备：WIFI Ralink RT2571MF，摄像头 Sonix SN9C230A

调试需求：使WIFI和摄像头在 OMAP的开发板上正常运行。

调试过程：

首先进行摄像头的调试，到最后这玩意儿也没有成功，所以说这个起点的选择本身就增加了调试的难度。

设备插到无源USB HUB上，一直取不出设备ID和厂商ID值，总报错误：

                   > usb 1-1.4: device descriptor read/64, error 2

　　　　　　> usb 1-1.4: new full speed USB device using musb_hdrc and address 5

　　　　　　> usb 1-1.4: device descriptor read/8, error 2

　　　　　　> usb 1-1.4: device descriptor read/8, error 2

　　　　　　> usb 1-1.4: new full speed USB device using musb_hdrc and address 6

　　　　　　> usb 1-1.4: device descriptor read/8, error 2

　　　　　　> usb 1-1.4: device descriptor read/8, error 2

或类似错误。开始一直怀疑驱动有问题，或者内核编译有问题，起初几天一直在内核的选项上绕来绕去。由于以前没有搞过嵌入式的开发，花了近一个星期的时间熟悉了内核文件及文件系统的到OMAP开发板的转移。更换了许多次内核选项后，错误依然存在，现象稍微有点差别就是error值可能会出现-71 -110。

　　期间跟驱动的开发团队（大部分是外国人）联系，让他们帮忙找原因，得出的结论是驱动肯定支持这款摄像头，需要找其它方向的原因。当时考虑到错误信息是在USB总线控制驱动上打出的，偶尔会出现总线异常，怀疑过内核总线部分的驱动会不会有BUG，或许最新版本才修正的，曾考虑过升级内核版本，可惜因为这种内核版本的升级太复杂，搞了半天没整明白就放弃这种想法了（就算能整明白，时间上也是不允许的）。也曾有人说硬件有问题，但也说不出啥问题，只说硬件有问题，而定位不到是啥问题，或没有合理的证据证明问题所在，没法跟BOSS交待，就只能继续偿试变更内核编译选项，更换驱动来进行测试，继续偿试不同的修正方案。

　　调了很长时间摄像头没有啥结果后，就想在WIFI上试试，看能不能先把WIFI试通。虽然此时已经在使用有源USB HUB，但WIFI插到HUB上时只在第一天晚上试成功的概率比较大，以后就一直大概率发生不认识设备的现象。总体上看，调通WIFI还是有门的。

　　现在的调试思路还是以解决驱动问题作为出发点，试了很多次内核驱动没效果后，被逼无奈放弃了内核自带驱动，用了厂商提供的驱动。先前不想使用这个驱动是因为不会交叉编译，搜了一些资料后，费了很大劲编译好驱动后，现象还是没有多大改善。但完全可以排除驱动有问题，思路也就转到了从硬件上找原因了。

　　根据错误提示代码找到了提示信息大致为USB总线协议错误和超时错误。按这两个提示，猜测是经常HUB的转换，信号变弱了，试着把设备线和HUB线改短了，还是没有啥效果。想到以前把WIFI直插到板子上后，每次都能取得设备信息，就是驱不起来，此时就想从此处试着找突破口。无意间发现了下面的错误提示：

　　usb 1-1: Manufacturer: Ralink

 

　　usb 1-1: rejected 1 configuration due to insufficient available bus power

 

　　usb 1-1: no configuration chosen from 1 choice

在google上搜的时候找到了下面的链接，

http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5459

参考里面的一个命令 echo -n 1 >/sys/bus/usb/devices/1-1/bConfigurationValue居然把WIFI给驱起来了。驱起来后，马上把这个美好的情况和同事分享了。然后确定HUB有问题，就电询了一下瑞泰的技术支持，按照他们的推荐买了一个USB HUB，然后再在HUB上试WIFI，居然能完美的正常工作了。

　　此时问题的原因基本上能确认了，板子的芯片或电路有问题，可惜的是摄像头在新HUB上还是不能用，从WIFI的情况，完全可以确定这个问题是出现在硬件上，暂时就不是我能解决得了的了，让他们搞硬件的想办法去吧。

　　调试结果：近四个星期，调出一个设备；找出比较合理的证据，把另一个设备出错的原因给推到硬件层。

　　调试总结：

　　1、调试的大部分时间都放到内核的编译，驱动的编译上。如果以前对Linux熟悉得很，这部分时间能缩短。

 

　　2、问题方向的定位没找好。以前做的工作，都是在硬件的工作正常的前提下进行的，找硬件原因没有太多经验。如果早点能确认出HUB问题，完全可以很快把WIFI整出来。

 

　　3、对Linux的基本命令不熟悉。到现在为止也不知道为啥 echo -n 1 >/sys/bus/usb/devices/1-1/bConfigurationValue 命令能激活WIFI。如果早些时候就知道这个命令可以激活WIFI的话，就不用怀疑驱动有问题了，早就可以在板子的USB接口上调通WIFI了。

　　后记：

　　调试的中间那一周，是最郁闷的时刻，该试的方法都试过了，一点方向也找不到了，曾想过放弃这个任务，让BOSS换人调试，或直接取消这个方案。看到BOSS不可商量的表情下，硬着头皮进行了最后几天的偿试，其间不小心发现了救命的echo -n 1 >/sys/bus/usb/devices/1-1/bConfigurationValue命令，居然给合格的完成了这任务。郁闷的时候曾经想，这个活儿也许会成为我做过的最失败的活儿，可能会以完败而告终，虽然不想承认，但要真出现那种结果，以当时的想法来看，也只能认了。也不好说达到现在的结果是喜是忧，可能用苦尽甘来描述会恰当些吧。