|
wifi调试 wifi porting文件和目录，porting wifi主要分为两个部分，源码的修改和配置文件的修改，其中配置文件的修改包括源码未编译时配置文件的修改和源码编译后的配置文件修改，下面就这两部分分析：
A:android未编译时的配置文件修改和源码修改 1：/android-cupcake/build/target/board/generic/ BoardConfig.mk 确定是否存在HAVE_CUSTOM_WIFI_DRIVER_2 := true，如果没有则添加该选项 /android-eclair/external/wpa_supplicant/.config.h 确定.config.h中，是否存在以下3个选项 CONFIG_WIRELESS_EXTENSION=y CONFIG_CTRL_IFACE=y CONFIG_DRIVER_WEXT=y 以上是支持wifi驱动的选项！ 2:修改的源码文件 2.1/android-cupcake/system/wlan/ti/sta_dk_4_0_4_32/CUDK/tiwlan_loader/tiwlan_loader.c 这个文件修改的tiwlan_loader服务，这个服务在android1.5中需要返回成功，表示加载wifi的固件到eeprom中成功，而实际内核在加载wifi驱动的时候，同时加载了固件（即提供的bin文件）。但是在android2.0中，这个服务不是必须的！在编译tiwlan_loader.c时需要/android-cupcake/system/wlan/ti/sta_dk_4_0_4_32/CUDK/UtilityAdapter编译出来的库。 2.2/android-cupcake/hardware/libhardware_legacy/wifi/wifi.c 这个是porting wifi驱动的最重要的文件，其中包括驱动加载,连接wpa_supplicant服务都是在wifi.c中完成。所以要修改驱动加载的网络接口名和相关的宏。 2.3/android-cupcake/frameworks/base/wifi/java/android/net/wifi 这个目录下是wifi中相关的java代码，其中修改的WifiStateTracker.java，这个主要修改dhcp时，获取动态ip地址的网络接口名。 2.4 external/wpa_supplicant/wpa_ctrl.c 这个主要修改wpa_supplicatn连接时的权限，wpa_supplicant服务启动的时候客户端和服务端通过unix socket通信，JAVA UI 界面是通过此socket文件与驱动联系，此服务生成的socket在/data/system/wpa_supplicant/目录下,如果涉及到权限问题，则需要修改 external/wpa_supplicant/wpa_ctrl.c中相关的目录的权限 2.5 frameworks/base/services/java/com/android/server/WifiService.java 这个在android1.5中，上传到BSSID，ISSID,java代码无法识别。在android2.0中无需修改。 B:android编译后的相关配置文件的修改 3.1/system/etc/wifi/wpa_supplicant.conf 看目录下是否存在该文件，如果不存在，则添加;并且添加wpa_supplicant服务socket的服务接口，如下所示： ctrl_interface=/data/system/wpa_supplicant//默认的mlan0无线网络接口的目录 update_config=1 //这个可能是更新的配置，但不确认 3.2/system/etc/dhcpcd/dhcpcd.conf 看是否存在改文件，不存在则添加，并且修改无线网络接口的网络名字，如android默认的是tiwlan0 ,而我的无线网络接口是mlan0，则把interface 后面的接口改成mlan0 3.3 init.rc service wpa_supplicant /system/bin/wpa_supplicant -imlan0 -c/system/etc/wifi/wpa_supplicant.conf disable oneshot service dhcpcd /system/bin/dhcpcd -d -f /system/etc/dhcpcd/dhcpcd.conf mlan0 disable oneshot 以上是添加在wifi的服务。 mkdir /data/misc/wifi 0777 wifi wifi mkdir /data/misc/wifi/sockets 0777 wifi wifi mkdir /data/system/wpa_supplicant 0777 wifi wifi mkdir /data/misc/dhcp 0777 dhcp dhcp chown dhcp dhcp /data/misc/dhcp 新建以上的目录。 如果你不的平台不出稀奇古怪的问题的话，现在你已经可以ping通你想用的ip地址咯. Qc FB驱动 以及 LCD调试过程 欢迎转载，请注明出处 首先说说QC的片子，QC这块片子使用MDP3.0作为图像处理器，下面支持MDDI，LCDC，以及EBI3种显示接口，MDP3.0不支持overlay，因为不管是camera或者视频播放都必须使用surfaceflinger来进行处理。3种接口这里我们使用到的是LCDC，使用RGB接口接一个同步屏。MDP会根据PANEL的type(比如LCDC_PANEL)来选择适当的接口，而panel本身必须注册适当的设备，比如说LCDC屏必须在后面注册一个LCDC设备而不是MDDI设备。 从FB的结构来上，QC注册了4个设备：MSM_FB，MDP，LCDC，panel。MSM_FB是fb.c的本地实现，其他的都是各个设备接口的驱动。系统启动的时候board.c会首先注册4个ID为1的设备，然后probe完成最基本的一些硬件的初始化，最后panel的驱动注册的时候会重新注册一个ID为1的panel设备，并将panel相关的参数(比如margin，pclk，resolution等等)传到LCDC，并重新注册一个ID不为0的lcdc设备，LCDC的probe又会重新注册一个ID不为0的MDP设备，MDP的probe又会根据传过来的参数注册一个FB设备。(插播点小广告：linux设备注册的时候会寻找相应的驱动，如果有相应的驱动就会调用相应的驱动的probe，同时驱动注册的时候也会寻找相应的设备，找不到会报错，找到了会调用相应的probe，一个驱动可以被多个设备使用，但是一个设备不能同时使用多个驱动。另外FB相关的设备一般注册成platform device，关于这个名词可以去参照linux的doc文件夹) FB的数据类型有RGB565，RGB888和ARGB8888四种，LCDC下被写死了只能是RGB565。 要了解上面的一个过程必须对内核运行的一套机制有所了解，这样才知道这个数据流程是如何走下来的，尤其是panel的参数最后是如何被FB给接收的，以及open device的时候一套on是如何下来的。这里最重要的几个文件一个是arch/arm/mach-msm下面的board相关文件，另外一个就是drvier/video/msm下面的driver相关文件。 也许咱看的内核代码还太少，觉得QC这套FB的流程真是清晰流畅，相当的经典阿，可以作为以后自己写FB的典型范例阿，不过得有机会写才行－ －! 除了上面的一套设备和驱动注册过程之外，最重要的就是从设备的open开始的这么一套流程了，FB是一个字符设备，当打开设备的时候就会调用FB的open函数，这个open函数的实现是很重要的。QC在FB的open里面先后调用各个设备的open完成对MDP，LCDC，PANEL的初始化，并在最后点亮背光。这个backlight设备也是个很高深的学问，QC实现的自己一套，而android则是注册了一个LED设备，暂时没有深研究这个设备的运作过程，以后一定得仔细弄清楚～～背光控制不好最常见的就是白屏，花点了。除了open以为还有一个就是release/off以及set_backlight了，这3个函数基本实现了FB的全部功能。 了解了FB一套大体的实现，下面就是具体的如何来调试这个LCD了。觉得真要调一个屏的话，一定要了解TFT-LCD的一个最基本的工作原理，不需要了解太深，但至少从硬件上知道他显示一个什么原理，网上有很多资料，这里只是简略说一下。TFT-LCD的基本原理就是两个电极板驱动液晶流向，然后光穿透并进入滤光板显示出颜色。这里有几个概念是必须清楚的： 1、common极的电压(Vcom/VcomH/VcomL)和source driver(DDVDH)之间的电压控制液晶的方向，因为液晶不能常时间朝向一个方向，不然会造成液晶的损坏，因此这里就存在一个反转的问题，就是两个电极之间的电压必须反转以让液晶的流向反转。可以通过改变两个电极的电压来反转，反转的方式有很多种：帧反转，行反转，列反转以及像素反转。不同的反转方式可能造成屏的flicker(闪烁)以及crosstalk(相邻像素互相影响)，因此根据电压反转的方式必须选择适当的反转方式。 2、调节common的电压可以调节屏幕的对比度，因为它和source driver之间的电压控制着液晶中能通过的光量。 3、gate driver(VGH/VGL)与source driver之间的电压控制着TFT的开关 了解了一些最基本的物理原理，现在我们看看具体的调试LCD的过程。除了可以参照网上一些达人的成功经验之外，我觉得更主要的还是要仔细看清楚datasheet，因为不同的屏同一个现象的原因并不是唯一的，因此了解一个基本的调屏的过程之后最重要的还是仔细阅读datasheet。 调屏之前首先必须确认Driver IC 的datasheet的正确性，咱这个可怜人两次厂家给的datasheet都是错误的，害得咱两次都瞎折腾半天却总不对。一定要和厂家确认Driver IC的正确性。基本现在的屏都是上电 --> reset --> 初始化这么一个过程，初始化现在一般是使用的SPI接口，那么我们就来说说这个基本的过程： 1、上电 有些屏对上电的顺序有比较严格的要求，一定要根据datasheet要求的时序来； 2、reset reset一般都是高低高的一个过程，而且一般都有时序上的要求。一定要注意这个reset的脚是否专用的，侧曾经碰到过reset还被其他的驱动使用造成reset脚不停地被拉高拉低 3、初始化 现在一般使用三线spi接口(clk,data,cs)来发送初始化命令，各种屏对发送命令的格式和参数都有一种要求，比如说command以0开头或者其他的十六进制数开头等等。另外还要确认MCU物理spi或者模拟spi的时序与屏相匹配。一般来说初始化成功以后屏应该就亮起来了，只是可能显示的是花彩。 4、RGB接口的配置 RGB接口包含HSYNC VSYNC PCLK 3根线，有些屏还多一根DATA_EN线。这里一般最重要的是让MCU与屏的极性一致，通过配置主芯片相关寄存器或者屏的相关寄存器使两者的极性相匹配。4跟线的极性正确以后再配置相关的margin的数据，屏幕应该就正常亮起来了。 如果这时候显示还有问题，那么就差不多应该怀疑初始化代码的微调了。初始化代码里面比较重要的一般有：VCOM/VGL/DDVDH之类的电压配置；工作模式的选择；RGB接口的极性；RGB的顺序；DATA的数据位数；开始扫描的坐标；极性反转的方式； 基本上通过上面的调试LCD应该是没有什么问题了，再有问题就仔细看datasheet并联系厂家的FE了～～ 点滴积累： 1、LCD残影一般是由panel的液晶特性决定的，处于规格以内就好了，如果频繁出现就要查电压了 2、闪烁以及相邻像素之间的互相影响一般是由极性反转的方式不正确导致的 3、造成颜色不正常的因素很多，除了数据位数，RGB的顺序，PCLK的极性之外，PCLK的频率，极性反转的方式都会造成颜色的不正常 4、图像的对比度可以通过调节VCOM/VCOMH/VCOML来实现 5、造成LCD白屏的原因有很多，但根本的原因就是背光亮了但是没有RGB数据过来或者背光亮了PANEL确不能正确显示数据。从这个根本的原因去寻找其他的原因，比如是否正常初始化，是否背光点得太早等等； 另外有时候如果寄存器的延时不够的话也可能造成一定情况下的白屏，尤其是那些启动屏幕，开始数据传输，或者读写之类的寄存器。 6、启动时候的花屏一般可以通过点背光之前的一个清data操作来完成，比如将FB的数据全部写0 7、图像出现上下或者左右不对齐一般是margin的参数不对, 抖动一般是sync的信号不稳定造成的 8、图像出现水波纹类似于抖动闪烁的现象可能跟极性反转有关系，也有可能和gate driver和source driver的电压有关系 9、硬件的时序参数有时候不一定与datasheet上的参数完全匹配，所以一般的开始的时候都让时间稍微长一点，比如reset的时间，数据的设置时间和保持时间等等，调通以后再来优化速度 10、关于LCD背光，一般都有一个偏差，比如说背光偏暖就会使得图像偏黄，如果背光偏冷就会使得图像偏紫。这里补充一点小知识，太阳光的七色光谱红、橙、黄、绿、蓝、靛、紫，红光波长最长为暖色，紫光波长最短偏冷色，色温的单位是K(开尔文)，越高就越偏冷，越低就越便暖。色温上的喜好是因人而定的，这跟我们日常看到景物景色有关，例如在接近赤道的人，日常看到的平均色温是在11000K(8000K(黄昏)～17000K(中午))，所以比较喜欢高色温(看起来比较真实)，相反的，在纬度较高的地区(平均色温约6000K)的人就比较喜欢低色温的(5600K或6500K)，也就是说如果您用一台高色温的电视去表现北极的风景，看起来就感觉偏青；相反的若您用低色温的电视去看亚热带的风情，您会感觉有点偏红， 电视或者显示屏的色温是如何界定的呢?因为在中国的景色一年四季平均色温约在8000K～9500K之间，所以电视台在节目的制作都以观众的色温为9300K去摄影的。但是欧美因为平时的色温和我们有差异，以一年四季的平均色温约6000K为制作的参考的，所以我们再看那些外来的片子时，就会发现5600K～6500K最适合观看。一般来说色温偏低给人的感觉是比较偏暗，比如偏黄给人的感觉就是偏暗，如果偏蓝给人的感觉就是偏亮。 11、几个LCD的光学参数，这里只是粗暴地说说，具体地可以参考一些资料说得很详细。一个就是LCD的亮度参数mcd，m是毫的意思，其实真的参数是cd(坎贝拉)，现在手机上的LED一般都是用的1500－1700mcd的。还有一个就是LCD的色度参数，衡量的参数很多，这里只说色度系xyz3坐标，代表红绿蓝，相应的降低就会偏另外一种色，比如说x/y降低就会便蓝，主要用在调颜色的偏差上，和上面的色温是联系在一起的 12、lcd debug的时候有两个很重要的技能，一个是用来debug颜色的问题，刷单色条；还一个就是debug初始化过程的回读函数。刷色条的问题很简单，按照RGB的格式分别在将R、G、B的位上置1就好了；至于回读寄存器，一般datasheet上都有相关的时序，按照时序来读就好了，这里稍微说一下使用GPIO模拟SPI的话只需要将GPIO设成输入然后读寄存器就好了。回读寄存器是必须的debug手段，可以检查数据是否下进去，如果下进去了说明指令本身有问题，如果读出来为全0或者全1之类的就要考虑一数据是否输出？二数据输出了但是确没进panel，有两种可能情况，一种是可能打样没打好，panel和板子的连接没连好，还有一种就是指令的格式不正确～～ 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yili_xie/archive/2010/04/07/5459205.aspx 高通Android平台硬件调试之Camera篇 之前一段时间有幸在高通android平台上调试2款camera sensor，一款是OV的5M YUV sensor，支持jpeg out，同时也支持AF，调试比较比较简单，因为别的项目已经在使用了，只是把相关的驱动移植过来就好；另一款是Samsung的一款比较新的3M YUV FF sensor，在最新项目中要使用的，本文以调试该sensor为例，从底层驱动的角度分享一下高通android平台下调试camera的经验，而对于高通平台camera部分的架构以及原理不做过多的介绍。 User空间部分： 二、调试环境准备（板子出来了，但sensor sample还没到位） 将sensor接到板子上，开机后，ADB中运行调试程序，preview画面并没有出来，失败，有点小失望，本来觉得可以一气呵成的，但毕竟这是一个全新的sensor，任何一个地方没有想到位做到位都会导致失败。那就找原因吧。 1、首先从trace得知，I2C已经读到了sensor的ID：0x05CA,这可以说明I2C通讯是没有问题的 2、接着检查Sensor的电源配置，测量了供给sensor的3个电源，都是OK的。 3、测量MCLK，这个是提供给sensor使用的，正常（24MHZ） 4、测量PCLK，这个是sensor输出的，正常（58MHZ，高通上限为96MHZ），和寄存器中配置的一致。 5、测量H/V同步信号，这个是sensor输出的，正常。和FPS和分辨率一致。 6、测量数据信号，这个是sensor输出的，正常。（数据信号，示波器上可以看到） 这样看来，sensor已经在正常工作了，但为何preview画面没有出来呢？继续检查高通这边的设定。 从trace看，高通的VFE已经reset并且start了，但一直接没有输出preview数据，这就奇怪了，sensor明明已经输出了，为什么VFE接收后并没有把数据吐出来呢，难道这个sensor输出的数据VFE无法识别？为了验证这个问题，我在另一块板子上测量了OV sensor输出数据的波形，主要是M/P clk、H/V同步信号，然后再拿来对比，不过并没有发现异常，只是H/V同步信号有所不同，主要高低的占空比不太一致，会不会是这样信号的问题呢？为了进一步验证，我同时测量了H/V 信号和数据信号，这时发现OV sensor输出的数据信号是包在V帧同步信号的低电平中；而Samsung 5CA输出的数据信号是包在V帧同步信号的高电平中，会不会是因为V信号极性设置不对导致VFE没有读取到sensor输出的数据呢？重新检查了一下高通VFE的设定，果然有一个参数是用来设定V信号极性的，这个参数默认是Active Low的，我这边并没有去修改它。接着把这个参数修改为Active High，重新build、download后，开机运行，Ok了，preview画面可以正常显示了。到这里为止sensor的硬件调试可以算作完成了，后续的其他功能也可以慢慢完善了。 Note：V同步即帧同步信号，代表一帧数据的开始，VFE会根据该信号来读取一帧数据。 H同步即行同步信号，代表一行数据的开始，VFE会根据该信号来读取一行数据。H信号一定是包在V同步中的。 |
|
|
