我对MTK的一点点认识

一、 目的
来到这里近两月，更近距离的接近了MTK。身处基于MTK平台的产品开发浪潮之中，让我对MTK有更多的了解，不光是在平台技术本身。就技术上，从软件角度、系统角度，对MTK我应该能给出深度而全面的评价或看法。就产品上，我也有自己的一些见解和思考。总之，对于MTK我所产生的思考及结论，希望能在这里同大家分享。如果能抛砖引玉，引发大家更有意义及价值的思考，是我此文最大的愿望。
二、 适用范围
全体
三、 定义
无
四、 前言
MTK是一个伟大的公司。在舆论批评山寨，并间接批评MTK的时候，我们只能认为这是产业成功而引起的喧闹中的一种形式。 MTK在手机市场快速发展的时候，我投身所谓在振兴民族通信产业的TD领域。那时我经常提及MTK，MTK在01年起步，在04年面向市场，花了3年时间。在一个已经成熟的GSM网络，完成一个终端平台的商用，花了3年时间。而对于一个还处于实验室阶段的TD平台，它的成熟花个3年时间是起码的。这是我经常向别人解释为什么TD终端还不成熟的理由或者借口。在努力促使TD终端商用化的过程中，经受了3年各种各样的煎熬，有网络、平台、应用、项目、市场等方方面面，让我更感觉MTK方案设计有很多可取之处。下面，我就将我所了解到的与MTK平台有关的任何细节的东西，都一一列举出来，重点还是在软件部分。
五、 MTK方案
04年，多媒体手机开始兴起。MTK方案的技术核心就是基带芯片支持多媒体功能，降低了成本，加速了多媒体手机产品的上市时间。MTK方案的服务核心就是turnkey模式，一改ADI、infineon等方案那种“能在我的方案上做什么卖给用户”的思维方式，而是“我的方案能直接卖给什么用户”。
MTK在基带芯片中集成LCD控制器、CAMERA控制器、多媒体CODEC。这种方式，自然是外带多媒体协处理器从成本及开发周期上无法比拟的。ADI、infineon、agere、TI等方案的出局就成必然。但为什么这些欧美公司在方案上不做调整呢？可能的原因是，在失去技术核心竞争力以及领跑优势后，和中国公司站在同一起跑线竞争太难。中国人能吃苦，老外要渡假。
MTK将能做的功能，基本上都给客户做好。这大大缩短了客户的研发周期，也就是所谓的降低了技术门槛。从节约社会劳动力，提高社会整体效益的角度讲，MTK的方式是合理的。它避免了N个客户的重复劳动，重复的走弯路。从这个角度讲，TI方案最次，连BASIC MMI都没有，还停留在早期做GSM手机的模式。
MTK这种直面客户的模式，也最大力度的支持着手机终端生产者，花最大的精力在如何降低成本及创新去迎合消费者需求，提升他们本来就缺乏的核心竞争力。山寨机的存在，说明有这样一群消费者需要成本低廉、多样性的手机产品，并容忍产品的细节性缺陷。


六、            MTK软件平台
做过的手机平台有好几个，但都是Feature phone。目前做手机，可以说是在高科技产品光环下的系统集成，需要一定的技术实力，但更多的是平台积累的经验。特别是软件，平台之间的切换很麻烦。越是更多的依赖积累于某一平台的经验，切换到其他平台就更麻烦。越是做过多的平台具体工作，切换到其他平台就越麻烦。因此，我非常看好智能手机的前景，尽管现在市场存在问题，未来几年的市场仍然存在问题。在未来，支撑智能操作系统的硬件配置成本不再可怕的时候，智能手机必然是首选，是MTK turnkey模式发展方向的终极模式。

我了解MTK软件平台，主要是先看支撑软件平台的硬件方案。方案之间的差异化竞争，核心还是在硬件方案的差异化。但是所有的方案，从框架上来讲，都是大同小异。最大的同，都是基于同一个ARM核，可能有基于基带应用的不同，在PLL、CACHE、协处理器以及外围控制器上的小异。即使使用C166的infineon方案，性能虽然有差异，但从使用角度讲，原理是一样的。

针对MTK软件平台，我看过它的启动过程、内存分配机制、编译机制、GUI机制、RTOS、文件系统以及非常重要的基带芯片资料（主要是6225）。在阅读MTK方案的过程中，关键之处我都做了记录，一直就想找个机会对这些做一整理。

6.1              启动过程
MT6305上电给基带芯片供电，在一定时序条件后，给基带芯片复位信号，开始了ARM核的启动过程。要谈启动，我们必须熟悉Scatter file、基带资料的Memory mapping章节。Scatter file定义了load region和excecute region，我们要关心系统运行时代码、数据的地址分布。

Bootarm.s是一个重要的文件，与启动过程有关，其中的INT_Initialize函数是ARM启动开始执行的代码。BSP所做的事情主要包括:

1、配置PLL，配置基带芯片的EMI参数，以让系统能够以最大的速度读取外部存储设备数据，让CPU以最大速度运行，从而缩短启动过程。

2、做好runtime代码及数据的准备，确保excecute region的代码及数据到位。

3、配置好ARM七种异常模式的堆栈，进入RTOS nucleus的初始化。

4、nucleus留给客户的初始化函数Application_Initialize，做了平台该做的初始化工作，比如外部控制器的初始化等等。

6.2              RTOS
在分析系统问题，开发跨线程应用时，必须熟悉RTOS。目前使用的RTOS是nucleus，尽管在BSP中看到了它对ThreadX的支持。不同的RTOS，实际上也是大同小异，但是具体的API或者参数会有不同，因此我们需要下载nucleus的API文档，在需要了解细节时，可以翻阅此文档。同时，TRACE32支持基于RTOS级别的调试，因此对RTOS的了解，有助于提高调试能力。

有点特殊的是，nucleus有 LISR,HISR的概念，实际上它是一种给开发者的印象。它告诉开发者，中断处理函数LISR要尽量的耗时短，以确保其它中断能有机会及时响应。HISR再处理略为次要些的工作，但耗时也不能太长，因为HISR比任何TASK的优先级都高，我们应该让真正需要实时的工作获取CPU的机会。

Application_Initialize中的mainp函数，负责任务的创建。我们在代码中见不到任务创建的函数，只需要维护任务初始化参数数据结构。对于系统的那些task信息，都保存在sys_comp_config_tbl变量中，我们看不到。但是MTK提供给客户的custom_comp_config_tbl，客户是可以修改的，在这里用户可以定义自己的task。

关于任务，需要关心数据结构comptask_handler_struct。关于comptask_handler_struct成员的执行顺序，应该是：comp_init_func 在系统还未 schedule 即在Application_Initialize中完成，然后task schedule后执行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我认为无太多意义。

task和module有什么区别？可以肯定的是，task 是操作系统层面的概念，module是软件平台设计者因为某种需要而设计的，可能大家比我更清楚，但这种概念在具体工作中可能还是需要弄清楚。

到此，基于RTOS的各个TASK应该都已经调度起来。首先毫无疑问，idle task必须是优先级最低的task。按照常理，系统会从最高优先级的任务开始调度，至于如何跑到MMI显示LOGO界面，在必要时，我们可以去研究。

6.3              GUI机制
至于MMI framewok，我未做太多了解，但任何GUI系统面对的都是最终的LCD bufffer。但不同的是，MTK的基带芯片搞了个LCD控制器，并加了layer的概念，从硬件上支持2D function和加速LCD的刷屏。对于上层的GUI，要做的是选择哪个layer是active。

LCD控制器的刷屏机制。以6225为例，支持4 layer。MTK资料对LCD控制器未做详细的描述，如图1是其对LCD接口块图的描述。但通过LCD控制器驱动，我们可以对LCD控制器内部结构做更多的假设。图1中的Overlay，我们可以设想为一个专有的DMA控制器通道，目标地址为LCD，源地址是layer buffer。系统通过配置要刷哪几层，配置alpha值来控制2D效果。这一目的的达到，硬件上有它的考虑，我们也没有必要做太多确定性的假想。


图1  LCD接口块图

       需要说明的是，仅仅是这样一张图，我们应该有更多的联想。Layer buffer都是从外部RAM开辟的内存空间，LCD的访问时序完全决定于如何配置LCD控制器。对Layer buffer的读写，需要占用系统总线，即使再做总线上的区域规划，外部RAM的数据总线是公共资源。对公共资源的访问，就意味着并发，意味着仲裁ARBITER。为什么在以前的项目中，出现一些关于LCD的莫名其妙的问题，不能说这里是根本原因，但我们应该从系统的角度去注意到这点。我对资源的占有，就意味着别人的失去。以往被掩盖的缺陷，可能会因为系统运行时的变化，暴露出来。这就是我认为，有些系统问题，不能从代码表面去分析，而要从ARM核的角度，从同cache,BUS,controller等外围设备之间的联系来系统的分析问题。

关注一下开机LOGO的显示，是在uem_poweron_timer_expiry_hdlr函数中，同时这里做了latch power的动作。还有潜力，提前显示出LOGO。

6.4              内存分配机制
在MTK的资料中，介绍了它的内存管理机制，有3种：ADM、Control buffer、System Memory。后两个是系统使用的，与上层应用无关。但是我对kal_system_alloc也做了初步分析。

sys_mem_ptr,其估计应该指向的是 System_Mem_Pool，       debug_mem_ptr,其估计应该指向的是 debug_Mem_Pool。       经过初步分析，kal_system_alloc就是从System_Mem_Pool做简单的加法操作，sys_mem_left_size就是System_Mem_Pool还剩下多少。kal_system_alloc从sys_mem_ptr开始来计算要取的内存。ctrl_buf是通过kal_system_alloc的内存，然后再通过NU_Create_Partition_Pool创建POOL。系统的一些task stack.等也都是通过kal_system_alloc来分配的。

也就是说，Control buffer、System Memory用的都是System_Mem_Pool的空间。而System_Mem_Pool可以查到，是在custom_configmem函数中配置。

ADM就完全没有使用操作系统提供的内存管理算法，是平台自创了一套。开发者，可以自己开辟一个POOL,自己在这个池用ADM提供的内存管理API完成内存的动态管理。具体的分配算法，就没有再细看，跟一些通用的内存分配算法应该一致。但是在以前调试一个问题的时候，应该是可以断定，ADM在每一个alloc node前后都加了GAP调试区，来判断是否被overwrite。

至于系统中，到底是用了多少块内存用于ADM，各块内存又是让哪些应用在共享，开发者可能更清楚。在系统中是否建立了对内存动态分配的监控机制，比如查询内存泄漏、动态内存使用效率等等。

6.5              文件系统
文件系统用的是FAT格式，最关键的是如何MOUNT存储设备，如何匹配文件系统读写接口。MTK通过表格的形式来让客户选择支持的flash，真的是很方便，考虑太周到。

6.6              编译机制
MTK的makefile,写的很复杂，有perl脚本，也有make脚本，但框架结构很好。虽然我对makefile结构通读了一遍，但没有仔细花时间对此形成文档。

6.7              方案印象
MTK软件平台，接触了一年，总体感觉其底层代码写的很工整，结构很清晰。越到上层，代码就显的庞大凌乱，结构性和可读性都不强。如果把芯片设计也说上，我觉得MTK的基带芯片设计很智慧，针对特定的多媒体手机应用，设计出专门的控制器嵌入芯片内部。像uart控制virtrual fifo 和camera的resizer以及lcd controller，用低成本控制器来快速完成逻辑，从而减轻CPU的负担，提高芯片的整体性能。在其他多媒体处理器中，都是不多见的。

与业界认为从事MTK平台开发的技术含量低恰恰相反，我认为MTK方案技术含量非常高。MTK软件平台的代码开放程度也不低，MTK的技术支持也非常有力而迅速，以MTK平台为基础的终端承载了最丰富多样的应用。MTK方案给希望对手机平台有深入而全面了解的同事提供了机会。

七、            基于MTK平台的产品开发
有那么多的公司在做基于MTK平台的产品，竞争那么激烈，研发上如何在竞争中体现优势？硬件上，大家都一样。软件上，也是一样。你可以有，别人也可以有或者偷，别人可以有，我们也可以有或者偷。最多是差个把月，怎么办。一个中心两个基本点。以服务好客户为中心，保证两个基本点，一是要快，二是差异。

拉不到客户什么就不要做了。在大家都差不多的情况下，我们以客户为中心，快速的满足客户需求，提供产品。这样能拉住客户，让客户找不到离开的理由。第二是产品差异，是创新。如果有产品创新最好，要么降低了成本，要么吸引了消费者。但这两点中，还是快字最重要，这是可以通过团队专业实力和激情来保证的。但是创新，有运气的成分，需要研发同市场碰撞出火花。鼓励和激励创新，但不能只靠产品创新一定会出现。

总结起来，又回到管理二字上。依靠内部项目和质量管理保证产品研发速度、保证客户服务质量。

转至：http://www.rd3721.com/bbs/dispbbs.asp?BoardID=88&ID=21200