MT6768平台 1.添加驱动文件 2.添加硬件配置支持 3.添加硬件配置 4.添加编译配置 5.分配空间(非必要,当代码量超过当前空间大小时将会报错,根据报错log改大小即可.) 6.兼容配置 7.特殊情况 (下面这一步基本不用自己做,厂商提供的驱动代码都写好了,万一没有,可以自己加) (FAE给的驱动有些许问题) 8.遇到的问题 1.添加驱动文件 路径:vendor\mediatek\proprietary\tinysys\freertos\source\middleware\context

mtk architactureAP和scp 两部分组成从上到下的整体的结构是 app -->framerwork-->native-->hal -->kernel -->scpapp 是java层,每一个界面都是由一个activity,是人机交互的界面framework 是为应用程序提供一个后台服务native 是承上启下的作用,是把java 转化为一个c/c++ 代码的一种机制hal  提供ap 直接访问硬件资源的接口 比如iocrol等kernel 内核层用于应用获取驱

请在Config.ftbl.flashlight.h (mediatek\custom\common\hal\flashlight\src)中. 将全部的两处凝视掉的code: //CameraParameters::FLASH_MODE_AUTO, 都打开为: CameraParameters::FLASH_MODE_AUTO,  

架构介绍 路径:vendor/mediatek/proprietary/tinysys/scp 1.[build]编译相关 2.[driver]scp 的driver,I2C,power,eint 3.[middleware]Audio VOW,contexhub 相关 lib 和driver 4.[project]不同项目的配置文件,例如编译,eint num 等 运行环境 概括 在scp,MTK 的sensorhub 是在Google 的CHRE 下开发的,所有的sensor driver

功耗优化之Sensor功耗分析 一.Sensor功耗问题分类 二.Sensor功耗问题分析方法 SSC子系统引起系统无法进入AOSD问题分析: SSC子系统频繁唤醒AP问题分析方法 SSC子系统的GPIO/PMIC配置错误导致系统漏电问题分析方法 SSC子系统的sensor工作模式异常,导致系统功耗增大问题分析方法 一.Sensor功耗问题分类 目前所遇到的sensor功耗问题主要包括以下几类: 待机功耗: SSC子系统异常,导致系统无法进入AOSD SSC子系统异常,导致频繁唤醒AP SSC子

温馨提示      建议你先了解一下上一篇博文([Android L]SEAndroid增强Androd安全性背景概要及带来的影响)所讲的内容,先对SEAndroid窥个全貌,然后再继续本节内容.   1 现象描述   基于Android L版本源码环境进行开发时,根据项目需求,APP层需要操作sys/xxx 或 proc/xxx下面的文件结点,但是会报出以下权限异常,无法直接操作这些结点 LedLightFileUtil( 4671): java.io.FileNotFoundExceptio

摘要 简述启动过程的内存分配,各个映像的烧写,加载,logo的刷新,文件系统mount. DRAM:外部RAM: ISRAM:内部RAM(128K),(PL会跑在ISRAM里面,去初始化DRAM,loadub映像到DRAM): 目录 概述-分区layout以及虚拟内存布局 一概述 首先了解mt6573nand flash的16分区结构:如下 1.preloader: 下载和程序启动引导,初始化EMI和PLL... 2.DSP_BL modem+dsp 3.NVRAM 是一个yaffs2的文件系统

转载自http://www.cnblogs.com/thjfk/p/4086001.html camera基本代码架构 Camera原理:外部光线穿过lens后,经过color filter滤波后照射到sensor面上,sensor将从lens上传到过来的光线转换成电信号,再通过内部的AD转换为数字信号,如果sensor没有集成DSP,则通过DVP的方式传输到baseband,此时的数据格式是RAW DATA.必须通过平台的isp来处理.如果集成了DSP,这RAW DATA数据经过AWB,col

1  camera基本代码架构 高通平台对于camera的代码组织,大体上还是遵循Android的框架:即上层应用和HAL层交互,高通平台在HAL层里面实现自己的一套管理策略:在kernel中实现sensor的底层驱动.但是,对于最核心的sensor端的底层设置.ISP效果相关等代码则是单独进行了抽离,放在了一个daemon进程中进行管理: 图1 Qualcomm平台camera代码架构简图 由于高通把大部分具体的设置及参数放到了daemon进程中,所以在kernel部分只是进行了V4L2的设备

调试找到的问题: 1:开始调试的时候因为之前的工程师原理图和BOM出错,导致本来是2.8V电压的焊接的是1.8V的LDO所以这个是第一个问题 2:因为FAE反应说sensor没有反应I2C没有通信,所以检查了原理图发现,I2C有读地址和写地址的选择 此处的R18是多余的,直接接R17下拉即可.至低电位,所以写地址是0x78,读地址是0X79,之后软件修改了程序但是还是不出图像. 3:检查对比方案商的OK图纸发现D9-RSTB接线错误,应该是接0.1UF的电容到地 修改之后依然是没有出图 4:继续

OSSIM布道师 李晨光 一.背景 如果运维工程师手里没有高效的管理工具支持,就很难快速处理故障.市面上有很多运维监控工具,例如商业版的 Solarwinds.ManageEngine以及WhatsUp等,开源的MRTG.Nagios.Cacti.Zabbix.OpenNMS.Ganglia等. 由于它们彼此之间所生成的数据没有关联,无法共享,即便部署了这些工具,很多运维人员并没有从中真正解脱出来,成千上万条警告信息堆积在一起,很难识别问题的根源,结果被海量日志所淹没,无法解脱出来. 另外在传统

sensor的驱动 v4l2_i2c_new_subdev_board先用client = i2c_new_device(adapter, info);创建info对应的i2c_client对象(代表着一个i2c client),并进行驱动匹配.匹配就会触发i2c sensor驱动的probe调用.现在进入到目录drivers/media/i2c/soc_camera/,我们还是看OV2640驱动吧,毕竟前面的板级文件里只有在定义了CONFIG_SOC_CAMERA_OV2640宏才会编译进去.

iSensor APP 之 摄像头调试  MT9D001 MT9P031 测试小结 iSensor app 非常适合调试各种摄像头,已测试通过的sensor有: l  OV7670.OV7725.OV9650.OV9655.OV9653.OV5642.OV5640.OV5620 l  MT9T001.MT9M001.MT9P031.MT9V032.MT9V034.MT9D001.MT9D112.MT9D111 等 今天又重新测试了下MT9D001C12STC,MT9P031C12STC特此留下文

iSensor APP 之 摄像头调试  MT9M001C12STM iSensor app 非常适合调试各种摄像头,已测试通过的sensor有: l  OV7670.OV7725.OV9650.OV9655.OV9653.OV5642.OV5640.OV5620 l  MT9T001.MT9M001.MT9P031.MT9V032.MT9V034.MT9D001.MT9D112.MT9D111 等 今天又重新测试了下MT9M001C12STM,特此留下文档,已说明整个isensor使用过程.

iSensor APP 之 摄像头调试  OV9655 iSensor app 非常适合调试各种摄像头,已测试通过的sensor有: l  OV7670.OV7725.OV9650.OV9655.OV9653.OV5642.OV5640.OV5620 l  MT9T001.MT9M001.MT9P031.MT9V032.MT9V034.MT9D001.MT9D112.MT9D111 等 今天又重新测试了下OV9655,特此留下文档,已说明整个isensor使用过程. 先看OV9655,130w像

iSensor APP 之 摄像头调试  OV3640 OV2640 MT9d112 iSensor app 非常适合调试各种摄像头,已测试通过的sensor有: l  OV7670.OV7725.OV9650.OV9655.OV9653.OV5642.OV5640 l  MT9T001.MT9M001.MT9P031 今天又测试了上述几款新的型号,之前并未用过. OV3640 OV2640 MT9d112 先看OV2640,200w像素 首先可以查到该sensor配置寄存器地址为0x60,寄存

本文转载自:http://blog.sina.com.cn/s/blog_c0de2be70102vyn1.html 1  camera基本代码架构 高通平台对于camera的代码组织,大体上还是遵循Android的框架:即上层应用和HAL层交互,高通平台在HAL层里面实现自己的一套管理策略:在kernel中实现sensor的底层驱动.但是,对于最核心的sensor端的底层设置.ISP效果相关等代码则是单独进行了抽离,放在了一个 daemon进程中进行管理: 图1 Qualcomm平台camer

目录 1 MIPI简介 2 MIPI CSI-2简介 2.1 MIPI CSI-2 的层次结构 2.2 CSI-2协议层 2.3 打包/解包层 2.4 LLP(Low Level Protocol)层 2.5 通道管理(Lane Management)层 2.6 物理层(PHY Layer) 3 MIPI CSI2的物理连接 4 MIPI CSI2的工作模式 5 MIPI CSI2的数据包格式 5.1 MIPI CSI2的长包格式 5.2 MIPI CSI2的短包格式 6 基于FPGA的MIPI

pick up bring up sensor2.0 1.SCP侧的配置 (1) 放置驱动pickup.c (2) 添加底层驱动文件编译开关 (3) 加入编译文件 (4) 增加数据上报方式 (5)修改SENS的type 2.kernel层的配置 (1) 修改hf_sensor_type.h (2) 修改mtk_nanohub.c 3.HAL层的修改 (1) 首先修改HfManager.cpp和kernel通信 (2) 添加sensortype:这个在55之前,不需要添加,应该是沿用了MTK的定义

针对一些运营商的锁网需求,MTK平台已经对其有很好的支持.绝大多数的海外需求可以通过直接配置相关文件来完成.这里简单描述一下配置方法,不做原理分析. 相关数据结构分析: Modem中与SML锁网配置相关的数据结构有: Sml_context_struct:SML上下文, cat:SML种类,目前MTK平台共支持7种锁网方式(Network Lock,Network Subset Lock,Service Provider Lock,Corporate Lock,IMSI Lock,Linked

MTK 平台sensor arch 介绍-hal 一:整体框架 二:具体流程简介 AP-HAL: (1)init & control flow 我们以前文的originchannel 的 active 为例子,梳理下: (2)data flow 一:整体框架 如上图所示:MTK 的senor 架构从大框架上分为 AP侧 与SCP 侧AP 侧 由mtk-Hal 层和 kernel 组成,其主要思想在于实现了一个HfManager 完成了对多个sensor 的control 处理由一个.cpp 处理