MTK驱动调试经验
更新时间:2024-03-05 00:33:01 阅读量: 综合文库 文档下载
- Mtk驱动推荐度:
- 相关推荐
MTK 6735M项目F100驱动调试报告
一 配置EMMC
按照硬件的选择配置新的flash,因为第一版都是按照MTK认证列表使用,所有一般如果不行有两个可能: 1 配置不正确,需要确定alps\\bootable\\bootloader\\preloader\\tools\\emigen\\MT6735下的flash配置文件的时序是否正确,修改配置文件
alps\\bootable\\bootloader\\preloader\\custom\\f100\\inc的文件custom_MemoryDevice.h 2 需要硬件配合查看是否EMMC元器件未能贴好,造成不能烧录
二 调试LCD
调试步骤:
1 确定LCD的连接方式; 1 确定dws配置正确; 2 确定电源是否正确;
3 确定配置参数的读写方式类型,包括:
LCM_setting_table模式读写: struct LCM_setting_table { unsigned cmd;
unsigned char count;
unsigned char para_list[64]; };
LCM_setting_table_V3模式读写: typedef struct {
unsigned char id; unsigned char cmd; unsigned char count;
unsigned char para_list[128]; } LCM_setting_table_V3;
4 确定开关机的时序和读取初始化参数的方法; 5 确定DSI的配置是否正确,此配置函数为
static void lcm_get_params(LCM_PARAMS *params) 6 如果做屏兼容,需要配置 .compare_id = lcm_compare_id, 此项为读取LCD ID进行判断;
调试碰到问题:
1 参数的读写方式不正确,造成屏花屏,换一种读写方式正确;
2 suspend时未能写正确,在待机时出现kernel crash,需要特别注意; 3 未能配置lcm_compare_id,造成做屏兼容时未能自动识别; 4 TE的配置需要特别注意,此引脚MTK的补丁默认TE中断不开;
三 调试TP
TP连接的接口为I2C模式 调试步骤:
1 确定dws配置正确; 2 确定中断,电源正确; 3 确定I2C读写正确;
4 确定报点没有断点,TP没有坏点; 5 配置虚拟按键时注意键值范围;
调试碰到问题:
调试的TP为GT9157,出现很奇怪的问题,就是I2C的初始化读写没有报错,但是读写数据就是不成功,最后查找到问题为:
I2C加了下拉的防静电电阻,造成实际上的下拉,但是根据规格书配置要求,必须要做上拉处理,否则容易出现读写不正常,所有此处造成I2C没有正常工作;
三 调试sensor system
调试步骤:
一 accelerometer
1 确定dws配置正确; 2 确定中断,电源正确; 3 确定I2C读写正确; 4 确定好旋转的方向;
调试碰到的问题:
调试accelerometer出现没有报点,然后换了驱动就可以了,判断为原驱动内的读取x.y.z的方式不对;
二 alsps
1 确定dws配置正确; 2 确定中断,电源正确; 3 确定I2C读写正确; 4 确定好旋转的方向;
调试碰到的问题:
调试光感出现距离不对的问题,调试距离判断参数,成功;
四 调试camera
调试步骤:
1 确定主副摄像头的型号,在配置文件配置好,添加好驱动代码;
(注意:需要配置alps\\device\\huaying\\f100里的ProjectConfig.mk,此文件为主要配置文件,配置alps\\kernel-3.10\\arch\\arm64\\configs里的f100_debug_defconfig) 2 确定dws配置正确;
3 确定摄像头的开关机的时序,按照摄像头的规格书来配置; 4 根据硬件配置好MCLK;
5 确定好是否支持AF,闪光灯功能;
五 调试Audio
调试步骤:
1 按照驱动开发资料进行驱动配置,确定好是内置功放还是外置功放;
2 配置好音频功放的输入时序,按照喇叭的功率进行配置,外置功放配置路径为 alps\\kernel-3.10\\sound\\soc\\mediatek\\mt_soc_audio_v3\\mt_soc_codec_63xx.c 3 按照硬件配置mic为单/双;
六 调试HEADSET
调试步骤:
按照驱动开发资料配置即可。
调试碰到的问题:
配置dws时需要注意配置好中断;
七 调试MSDC
调试步骤:
1 确定硬件是否支持热插拔,进行配置dws; 2 确定硬件的电源是否正确;
调试碰到问题:
调试时一直不读卡,刚开始的时候因为不支持热插拔,怀疑配置不正确,但按照配置文档查找后发现并没有错误,然后开始确定T卡的电源是否正确,强行打开后,也没有识别到T卡,最后让硬件帮忙查找硬件问题,发现是卡座本身和板子的地短路,所以识别不到T卡。
八 调试Battery
调试步骤:
1 确定dws配置正确; 2 确定电源正确; 3 确定I2C读写正确;
4 确定OTG功能的配置正确; 调试碰到的问题:
在初始调试的时候,就发现不插USB不能开机,一直报低电。初始认为是没有配置好,但是在抓取串口信息时发现硬件工作正常,后查看硬件发现电池检测的一个配置电阻没有贴,造成不能得到正确的fuel gauge值。后又发现OTG功能不正常,后通过硬件确定引脚不正确造成,此中断脚应该配置为IDDIG,但在硬件上只是配置为ID脚。
九 调试connectivity
调试步骤:
1 确定dws配置正确; 2 确定电源正确; 3 确定I2C读写正确; 调试碰到的问题:
一般来说,FM,BT,GPS不需要调试,只需要按照硬件配置好相关的引脚就可以,所以调试的时候只测试了芯片工作是否正常,但调试这几个元器件时,需要确认的并不只是芯片工作是否正常,还需要测试性能,确定外围天线那块是否工作正常,测试性能时发现FM不能收到台,只有杂音,BT的连接距离短,GPS只是搜到两颗星,并未能定位。经过硬件的配置调试发现FM,BT,GPS的匹配没有调试好,造成这种结果。
调试碰到的一些需要注意的问题:
1 摄像头配置时序需要按照datasheet的需求配置;
2 调试一个灯控制程序,hal层不能调用底层的dev设备,花了大量的时间去确定那个地方引起,最后发现是android 5.1的权限管理比4.4的严格,处理如下: [Description]
android KK 4.4 版本后,Google 默认启用了SELinux, 并会把SELinux 审查异常打印在kernel log 或者 android log(L 版本)中,对应的关键字是: \ denied\或者\如一行LOG:
<5>[ 17.285600].(0)[503:idmap]type=1400 audit(1356999072.320:202): avc: denied { create } for pid=503 comm=\name=\scontext=u:r:zygote:s0 tcontext=u:object_r:resource_cache_data_file:s0 tclass=file
即表明idmap 这个process, 使用zygote 的source context, 访问/data/resource_cache 目录,并创建文件时,被SELinux 拒绝访问。
[Keyword]
android, SELinux, avc: denied, audit
[Solution]
KK 版本, Google 只有限制的启用SELinux, 即只有针对netd, installd, zygote, vold 以及它们直接fork 出的child process 使用enforcing mode, 但不包括zygote fork的普通app.
L 版本, Google 全面开启SELinux, 几乎所有的process 都使enforcing mode, 影响面非常广.
目前所有的SELinux check 失败,在kernel log 或者android log(L版本后)中都有对应的\ denied\或者 \的LOG 与之对应。反过来,有此LOG,并非就会直接失败,还需要确认当时SELinux 的模式, 是enforcing mode 还是 permissve mode.
首先, 务必确认对应进程访问系统资源是否正常, 是否有必要 ?如果本身是异常非法访问,那么就要自行消除访问。
其次, 如果确认访问是必要,并且正常的,那么就要对对应的process/domain 增加新的policy.
1). 简化方法
1.1 提取所有的avc LOG. 如 adb shell \
1.2 使用 audit2allow tool 直接生成policy. audit2allow -i avc_log.txt 即可自动输出生成的policy
1.3 将对应的policy 添加到selinux policy 规则中,对应MTK Solution, 您可以将它们添加在KK: mediatek/custom/common/sepolicy, L: device/mediatek/common/sepolicy 下面,如 allow zygote resource_cache_data_file:dir rw_dir_perms; allow zygote resource_cache_data_file:file create_file_perms; ===> mediatek/custom/common/sepolicy/zygote.te (KK) ===> device/mediatek/common/sepolicy/zygote.te (L)
注意audit2allow 它自动机械的帮您将LOG 转换成policy, 而无法知道你操作的真实意图,有可能出现权限放大问题,经常出现policy 无法编译通过的情况。
2). 按需确认方法
此方法需要工程人员对SELinux 基本原理,以及SELinux Policy Language 有了解.
2.1 确认是哪个进程访问哪个资源,具体需要哪些访问权限,read ? write ? exec ? create ? search ?
2.2 当前进程是否已经创建了policy 文件? 通常是process 的执行档.te,如果没有,并且它的父进程即source context 无须访问对应的资源,则创建新的te 文件.
在L 版本上, Google 要求维护关键 security context 的唯一性, 比如严禁zygote, netd, installd, vold, ueventd 等关键process 与其它process 共享同一个security context. 2.3 创建文件后,关联它的执行档,在file_contexts 中, 关联相关的执行档. 比如 /system/bin/idmap 则是 /system/bin/idmap u:object_r:idmap_exec:s0 2.4 填写policy 到相关的te 文件中
如果沿用原来父进程的te 文件,则直接添加. 如果是新的文件,那么首先:
#============================================== # Type Declaration
#============================================== type idmap, domain;
type idmap_exec, exec_type, file_type;
#============================================== # Android Policy Rule
#==============================================
#permissive idmap;
domain_auto_trans(zygote, idmap_exec, idmap);
然后添加新的policy
# new policy
allow idmap resource_cache_data_file:dir rw_dir_perms; allow idmap resource_cache_data_file:file create_file_perms;
3). 权限放大情况处理
如果直接按照avc: denied 的LOG 转换出SELinux Policy, 往往会产生权限放大问题. 比如因为要访问某个device, 在这个device 没有细化SELinux Label 的情况下, 可能出现:
<7>[11281.586780] avc: denied { read write } for pid=1217 comm=\name=\dev=\ino=4385 scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=0
如果直接按照此LOG 转换出SELinux Policy: allow mediaserver device:chr_file {read write}; 那么就会放开mediaserver 读写所有device 的权限. 而Google 为了防止这样的情况, 使用了neverallow 语句来约束, 这样你编译sepolicy 时就无法编译通过.
为了规避这种权限放大情况, 我们需要细化访问目标(Object) 的SELinux Label, 做到按需申请. 通常会由三步构成
3.1 定义相关的SELinux type.
比如上述案例, 在 device/mediatek/common/sepolicy/device.te 添加 type tfa9897_device, dev_type; 3.2 绑定文件与SELinux type.
比如上述案例, 在 device/mediatek/common/sepolicy/file_contexts 添加 /dev/tfa9897(/.*)? u:object_r:tfa9897_device:s0 3.3 添加对应process/domain 的访问权限.
比如上述案例, 在 device/mediatek/common/sepolicy/mediaserver.te 添加 allow mediaserver tfa9897_device:chr_file { open read write };
那么哪些访问对象通常会遇到此类呢?(以L 版本为例) * device
-- 类型定义: external/sepolicy/device.te;device/mediatek/common/sepolicy/device.te
-- 类型绑定: external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts
* File 类型:
-- 类型定义: external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te
-- 绑定类型: external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts
* 虚拟File 类型:
-- 类型定义: external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te -- 绑定类型: external/sepolicy/genfs_contexts;device/mediatek/common/sepolicy/genfs_contexts
* Service 类型:
-- 类型定义: external/sepolicy/service.te; device/mediatek/common/sepolicy/service.te -- 绑定类型
external/sepolicyservice_contexts;device/mediatek/common/sepolicy/service_contexts
:
* Property 类型:
-- 类型定义: external/sepolicy/property.te;device/mediatek/common/sepolicy/property.te -- 绑定类型: external/sepolicy/property_contexts;device/mediatek/common/sepolicy/property_contexts;
通常我们强烈反对更新google default 的policy, 大家可以更新mediatek 下面的相关的policy.
[相关FAQ]
[FAQ11414] android KK 4.4 版本后,user 版本su 权限严重被限制问题说明 [FAQ11485] 权限(Permission denied)问题如何确认是Selinux 约束引起 [FAQ11484] 如何设置确认selinux 模式
[FAQ11483] 如何快速Debug SELinux Policy 问题
3 待机电流不正常,一直有20ma左右的电流不能下来,看串口log信息系统已经睡下来了,查看各个设备都已经进入suspend模式,最后发现是开启了mtk的log功能引起。 查找功耗问题,可以参考以下资料:
如果贵司测试的时候,发现平均功耗高, 1》
首先请去掉所有的APK测试,看平均功耗是否有问题, 如果跟去掉APK之前一样,说明跟APK没有关系
如果跟去掉APK之前相比,功耗有所降低,说明跟APK有一定的关系 跟APK有关系,请自行分析APK。 2》
另外,请抓取相应的待机的mobilelog, 从kernel_log中分析, 如果log中可以查找到 wake up by RTC
请在相应的main_log中查找关键字
Alarm triggering, 其后面对应的type 0, type 2所对应的APk就是唤醒系统的唤醒源, 同样请去掉以后测试,
但是com.android.phone例外,
这个APK是ICS android4.0加上的一个google default的机制, 是一个每隔6分钟起来check数据连接是否有问题的机制, 检查是否只有TX没有RX的行为,
一旦检查到系统数据连接有问题,就会做相应的recovery动作 3》
从kernel_log中分析, 如果log中可以查找到 wake up by CCIF_MD
请查找后面一句log相应的CCIF_MD wakeup source: 如果是在您没有打开modemlog的基础上面出现此问题,
请帮忙同时抓取待机时候的mobilelog以及modemlog并附上modem对应的database 便于我司查找问题
如果是 CCIF_MD wakeup source: Mdlogger_RX 说明是因为打开modemlog引起的问题,正常 4》
从kernel_log中分析, 如果log中可以查找到
wake up by EINT
一般情况下是由于press power key引起的,
在后面的log中可以看到有wakeup的字样,就说明是power key 其他的情况应当是异常的中断引起的问题 您可以在中断例程中查找此中断的来源
4 卡2单插一张4G移动卡,读卡后出现信号显示一下有,一下没有问题。
出现这个的原因是没有写IMEI号,4G的移动卡一定需要写入IMEI号才能正常注册。
5 需要注意,配置dws的地方有三个。一定都需要配置正确才不会有问题。 第一个路径:
alps\\bootable\\bootloader\\lk\\target\\f100\\dct\\dct 第二个路径:
alps\\bootable\\bootloader\\preloader\\custom\\f100\\dct\\dct
第三个路径:
alps\\kernel-3.10\\drivers\\misc\\mediatek\\mach\\mt6735\\f100\\dct\\dct
如果有一个地方没有配置正确,会出现驱动出现异常。
正在阅读:
MTK驱动调试经验03-05
自动检测试卷二及答案07-08
右心室流入道与流出道的分界是1(DOC)04-25
鼎信诺审计软件常见问题汇总 - 图文03-11
2013电大信息管理网上作业12-18
河南省八市重点高中2015届高三教学质量监测考试 文综含答案05-22
管理学基础复习12-19
电力系统短路故障分析计算的基本知识07-24
- 多层物业服务方案
- (审判实务)习惯法与少数民族地区民间纠纷解决问题(孙 潋)
- 人教版新课标六年级下册语文全册教案
- 词语打卡
- photoshop实习报告
- 钢结构设计原理综合测试2
- 2014年期末练习题
- 高中数学中的逆向思维解题方法探讨
- 名师原创 全国通用2014-2015学年高二寒假作业 政治(一)Word版
- 北航《建筑结构检测鉴定与加固》在线作业三
- XX县卫生监督所工程建设项目可行性研究报告
- 小学四年级观察作文经典评语
- 浅谈110KV变电站电气一次设计-程泉焱(1)
- 安全员考试题库
- 国家电网公司变电运维管理规定(试行)
- 义务教育课程标准稿征求意见提纲
- 教学秘书面试技巧
- 钢结构工程施工组织设计
- 水利工程概论论文
- 09届九年级数学第四次模拟试卷
- 调试
- 驱动
- 经验
- MTK
- 园林树木养护技术规程规范
- 全等三角形经典模型总结
- 音频信号光纤传输技术实验
- 液压与气压传动技术及应用(田勇、高长银)课后习题答案
- 浅谈如何保证混凝土的施工质量
- 2013外贸业务考试基础理论试题及答案(A)
- 模拟电子技术第6章放大电路中的反馈
- 16.电磁感应习题思考题
- 2005年甘肃省中考数学试卷(6)
- 洛阳市2012年“慈善一日捐”活动宣传提纲
- 内科病历范文入院记录
- 烟包全息定位烫印箔关键参数计算方法分析 - 图文
- 色谱课习题作业
- 公卫参考题答案(1)
- 2010-2011(3)算法语言与程序设计笔试试卷A(试卷)
- 黄河三角洲高效生态经济区发展规划
- 商务英语口译参考答案
- 2008年宁波市国民经济和社会发展统计公报
- 大学普通物理复习题(10套)带答案
- 练习题汇总1