S3C6410硬件模块分析

手头的上课s3c6410开发板,带了SDIO接口的WiFi模块,但是没有Linux下的驱动,因此在上网络驱动时课参考s3c2440的实现试着分析和调试一下SDIO的WiFi驱动。


   我手头使用模块是WM-G-MR-09模块,其主控实际采用了marvell8686的IC来作为主控芯片,是由台湾环隆出的模块。网上能找到最接近的Linux驱动是针对 s3c2440的官方出的 GSPI-8686-LINUX26-BULVERDE-9.70.3.p29-26409.P50.tar

      官方的源码包提供的动态模块形式的驱动和命令行工具。经过简单修改Makefile,并且调步几个iw_函数的调用后,成功的在linux 2.6.28下编译成功,但是其中部分代码拷贝自s3c2440,因此这个驱动必然不会正常运行。因此必须要分析其模块的来改写成s3c6410的模块。


  首先这个模块是WiFi+Bluetooth 的2合一的模块。并且带了SDIO/G-SPI的接口与CPU进行交互.

S3C6410硬件模块分析


    

      

    SDIO接口比较明白,是源于SD卡的交互接口,后来扩展到多个硬件模块的对接,比如SDIO的蓝牙,WIFI模块等。

    G-SPI是一个什么接口呢?它实际上是SPI总线的扩展。原来在早期推广SDIO接口,为了取得更大兼容性,在设计硬件接口时,留出几个PIN脚完全兼容SPI的接口。这样就能让只带SPI的总线接口的CPU上也能使用SD卡。

   SPI是一个三线工业控制总线,它分别是 SPICLK(时钟线),MOSI(主设备发送/从设备接收线),MISO(主设备接收/从设备发送),完全的SPI还有一根片选线 (CS线),如果缺省这一根,则只能主设备固定为某一个设备。

   

    而G-SPI在这四根线上再进入扩展了一个CLK_REQ线和 一个外部中断线 G-SPI_SINTn

其中外部中断脚分析驱动象是用于唤醒和休眠的功能,而CLK_REQ是休眠时的时钟频率线(?)

两种接口的对应关系如下。


S3C6410硬件模块分析



  而CPU采用哪一种接口完全取决于硬件设计,在模块的说明到,取决于IF_SEL_1和IF_SEL_2两个pin脚的接法,即23/24号脚的接线,如果想配成SDIO的接口,两个脚悬空,否则则成焊上两个100K的下拉电阻.


S3C6410硬件模块分析


在模块原理图也说得更清楚,即是否焊上r8,r9两个电阻就决定软件使用哪一个接口。

   

S3C6410硬件模块分析


 虽然模块支持两个接口,但是所有代码提供都是G-SPI的实始化代码,硬件上也是如下设计.

S3C6410硬件模块分析

 不巧的是手头的模块,以及学员手中模块居然全是没有焊r8/r9两个电阻的模块,即只能用使用SDIO接口。在打电话询问了做Marvell的FAE的学员,他也无法确定SDIO接口的命令格式与G-SPI的命令格式完全一致,因此用SDIO直接初始化模块的方案就放弃了。只采用G-SPI的接口来工作。

   

  接收下来确定S3C6410 上是否也支持这种SDIO的管脚上复用SPI的用法。因为S3c6410同时支持SDIO和SPI的模块,但是如果 SDIO的PIN不能被SPI控制器接管,只能采用自行模拟时序的方法来通讯,这样无疑大大增加了工作量,因此我查询s3c6410的GPIO的配置,在GPIO的配置上,SPI的管脚是和SDIO复用的。但仔细分仔发现SDIO的管脚并没有完全与SPI的复用。如果想使用G-SPI,必须在接线直接接在SPI的管脚上,并且把G-SPI外部中断脚接在某一个外部中断的GPIO之中。


  

S3C6410硬件模块分析


而且关于模块的中断脚,这只是一个简单低电平有效的外部中断.

   

S3C6410硬件模块分析

而这个管脚按照原理图,它正好接在了GPH4上,即是第6组的第4个中断脚


S3C6410硬件模块分析


至此,在s3c6410下的模块驱动移植工作就变成了如下两个工作.

   1.实现SPI S3c6410的驱动

   2.按对外部中断脚,实现wan_interrupt响应


其余工作重用官方驱动即可

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wwfgjj.html