isp1761 usb2.0 host controller driver 开发

开发日记

从2009年12月下旬开始，开发isp1761 usb2.0 host controller driver，到现在已经有一个月的时间。

遇到一个奇怪的问题：

   通过总线读写isp1761内部存储区63K(地址空间：0x400 ~0xFFFF)时，对同一地址，读出的数据与写入的数据不一致。 
  我们的设计中，isp1761作为一个USB主口控制器，读写EHCI寄存器和硬件寄存器(0x400地址以下的空间)均正常，而且可以过对portsc1寄存器的操作， 实现复位isp1761内部root hub，并且能够读出该寄存器的正确信息(0x1005,给internal hub供电，internal hub连接在port上)，现在开始枚举internal hub，但是在枚举过程中，发现对PTD及payload 区编程，并写入atl last PTD map寄存器后，USB总线上无变化，为了验证对PTD及payload写入了正确的数据，我便将写入的数据，读出，结果发现，读出的数据全部为0。 
   在读写memory过程中，测量isp1761读写控制信号CS，WR#，RD#，这三个信号均存在，而且，因读写寄存器可以，因此读写memory的时序也应该满足要求。
在对isp1761的memory进行读操作时，需要对isp1761的memory寄存器进行编程，写入要读取的地址，我也按照手册的要求，进行了相应操作，但仍不正确。 
  已经确认的问题有： 
  首先，isp1761内部memory区，是可以通过软件进行的读写的么？手册没有明确这一点，我假定memory是可同写的。从一个师兄处及代理商的AE处得知，memory是可读写的。
  其次，我是通过PIO模式读写isp 1761的memory区的，如果采用PIO模式读写isp1761，需要先将isp1761的操作模式设定为PIO模式么？从其手册上看，isp1761的memory读写有DMA 模式，需要配置DMA相关的寄存器，并使能DMA传输，PIO模式，应是默认的工作模式。

   isp1761的地址线A16,A17怎样使用，因为isp1761仅有64KB的地址空间，16根地址线足够，那么A16,A17是否可以直接接地。isp1761的memory寄存器Bit0-15存放读操作的memory的地址，bit16，bit17是memory操作的虚拟段地址，A16与A17上的信号是否只要和bit16，bit17一致即可？(未确认)

   和代理商Arrowasia 的技术支持联系过了几次，确认了一些问题，但让他给建议的时候，他就不干啦，只是说你在详细的检查一下吧，之前却反复的问我芯片大概需要量，还要向他保证，以后订单要他那儿下。呵呵，神呀，我该咋办。

   这个问题我已用了一周的时间，该看的手册，都已看过，该测量的信号也已量过，呵呵，明天看来又要换片子了。

   路漫漫其修远兮，吾将上下而求索；美女身材窈窕兮，吾将上下而。。。。

 

2010年1月27日(重大发现)

   今天去将isp1761芯片换了了另外一批次的片子，试了一下结果同上。不过，通过这次更换，让我更我不再怀疑芯片本身。

   再从硬件到软件操作流程上找问题。。。

   郁闷中，无意中将CS#和RD#信号短接了一下，从串口处就画画的打印出了成功信息！！！

   重复上述过程，居然很具有重复性。又在另一块板上实验，同样的现象复现。至少确认了，软件的流程没错。

   今天又一次相信了，苹果掉在地上是触发牛顿联想到万有引力的绝对是个偶然，山穷水尽疑无路，柳暗花明又一村。

   明天终于又有了寻找的方向。

2010年1月28日

   昨天已基本确定了是PBI总线上的提供的读写时序与isp1761要求的不一致造成的。这个时候，体现了领导的威力。将问题汇报给领导后，领导果断的说，“将CS#与W\R#信号或一下，作为isp1761的RD#信号”

，之前我也想过是否可以对现有信号，简单处理，得到一个近似的RD#信号，不过没想到合适的路子。用了半天找了个或门飞了上去，果真好使。没有追求的我，想着问题总算过去了。领导又有个想法，“咱们只是找到了现象，没有找到问题的根源，要找到问题的根源后，看看能否通过软件的方式，将该问题绕过去，不要去动硬件”，要知其所以然。从驱动开发的角度，将芯片读写过去，就是解决问题了，但从产品研发的角度，对一个接近定型的产品，通过飞线是解决不了问题的。

  硬件算是最终走通了，简单试了一下USB发送setup包，结果不像预期的出结果。人生难逃两大波呀。

 

2010年2月8日

   终于通过直接填写PTD方式将外部port的电源使能了，但在结合submit_urb调试时，又遇到了null了指针，找了半天，usb_start_wait_urb中定义的等待队列项的变量指针神不知鬼不觉的变成了0，导致null pointer，春节之前还能向前走多少。。

 

2010年3月9日

   问题总是比预想中的多，春节后经过几天的折腾，终于可以对U盘进行枚举了，但是，走到mass storage

 

 

2010年3月11日

    发现3月9号与3月10写的没有保存住，庆幸，伤心。

    今天在将要放弃的时候，取得了一点进展，通过直接操作PTD，纯软件的查询操作，1761终于可以对一组CBW，CSW收发成功了。说明，硬件可能没有问题，问题出在软件上，后面的路还很长。。。 

2010年10月14日

    今天是个不寻常的日子。我今天终于可以宣布成功为GRUB移植了EHCI的驱动。对于USB bulk 传输的认识也算明了了，USB bulk传输是通过数据包的发送实现的，也就是通过DATA0/DATA1包的发送。主和从USB设备通信时，最基本的原则有个SYNC，也即是说：在bulk传输时，主设备和从设备都会从DATA0开始计数，只有主设备发出DATA0，且从设备正在接收DATA0时，这次传输才会正确的执行，同理，主设备等待接收的是DATA0，从设备返回的是DATA0时，主设备才可能收到数据。因此，这就会出现一个现象：当主设备和从设备不同步时，就会造成发送的数据出现在数据总线上，但是，数据不会被接收方理睬。（此处可参考“USB 那些事，我是UHCI”上面讲的data toggle，bulk和control传输时，用到的DATA0，DATA1数据包相关了）

    这个问题在与3月份困扰我良久的事情，发送一组CBW，CSW成功，但再后续再次发送CBW，发送的数据出现在总线上，但接收方毫不理睬一样了。