MTK是现在市场上所有国内手机设计、制造商使用的最多的一个完整的手机产品解决方案，大部分做手机的技术人员都对此有接触和了解。不过，MTK的整套软件系统十分庞大且复杂，很多刚接触这套系统的软件工程师一时不知如何进行配置和客户化定制。本文在此对整个MTK软件系统的工程结构和配置进行了简单介绍，希望通过此文和大家相互交流MTK软件系统的维护和修改、定制方面的心得。
MTK使用了nucleus实时操作系统，在其上做了个内核抽象层的封装，以适应多种实时操作系统，如oscar、ThreadX、nucleus。整个软件系统包括nucleus操作系统、平台设备驱动、协议栈、文件系统、WGUI、MMI、J2ME等。在这里MMI部分几乎包括了操作系统内核、协议栈、文件系统之上的所有部分，其中WGUI也在其中。
MTK的PC模拟版使用VC的编译器和链接器生成，ARM版使用ADS1.2的编译器和链接器生成。因为MTK的整个软件系统是一个很庞大而且复杂的工程，并且要支持多个MTK的产品系列和多家客户的客户化支持，使用集成开发环境(IDE)已经无法胜任，而且很难做到整个工程的自动构建和资源、代码的生成。所以MTK的软件系统使用了windows下的GNU开发工具链(MinGW)来进行工程的管理、配置和构建，MTK将MinGW放到了第三方工具中。另外还使用了perl脚本来解析用户输入的命令行参数，因此第三方工具中还包含了ActivePerl(windows下的perl解释器)。不过，整个软件系统并没有使用MinGW的全部工具，好象只使用了make这个工具，由几个Makefile控制了构建的过程，在编译和链接时根据最终生成PC 模拟版还是ARM版而分别调用VC的编译器和链接器或ADS1.2的编译器和链接器。
接下来我们从具体的工程实践来看MTK的手机软件系统。
一. MTK手机软件系统的目录结构简介
MTK手机软件系统的主要目录如下所示，因整个工程的目录树非常庞大，为简单起见和减小篇幅，去除了在工程结构中相对不重要的目录。
.
|-- Fast_DL
|-- ROM
|-- adaptation
|-- applib
|-- bootloader
|-- config
|-- custom
|  |-- app
|  |  `-- TOP_6227_BB
|  |-- common
|  |-- drv
|  |  |-- LCD
|  |  |  `-- TOP_6227_LCM
|  |  `-- image_sensor
|  |      `-- MT9D011
|-- drv
|-- fs
|-- inc
|-- init
|-- interface
|-- j2me
|-- kal
|-- make
|  |-- applib
|  |  |-- applib.def
|  |  |-- applib.inc
|  |  |-- applib.lis
|  |  `-- applib.pth
|  |-- bootloader
|  |-- config
|  |-- custom
|-- media
|-- mmi
|-- modis
|-- mtk_lib
|  `-- MT6227
|      `-- S01
|          `-- gprs
|              |-- abm.lib
|              |-- adaptation.lib
|              |-- applib_inet.lib
|-- nucleus
|-- nvram
|-- plutommi
|-- tools
Fast_DL是开发时下载二进制映像和资源等的相关文件的目录。ROM是固化在ROM(可能是Flash的只读区)中的相关代码和头文件的目录，在给客户的发布版中大都只有一些导出函数的头文件，其中似乎还有一个跳转表的东西ROMSA_FuncTable。
kal是上面所说的内核抽象层的相关文件的目录。nvram是存取NV中的内容的相关代码的目录。nucleus 是nucleus实时操作系统的目录，在给客户的发布版中只有头文件。drv是驱动相关的代码的目录。fs是文件系统相关的目录，好像只支持fat格式的。tools是工程相关工具的目录，包括MinGW。interface是系统各层的接口的目录，还包含重要模块的接口，如bluetooth、WIFI。config是一些系统和任务(task)相关头文件的目录，感觉不像是配置相关的目录。inc是中断控制和寄存器地址相关头文件的目录。
modis是PC模拟版的相关目录，包括了虚拟的GSM网络、SIM卡等，以及模拟器需要的字符串、图片等资源，还有PC模拟版的库、VC的相关工程文件。
mmi是一个缺省的空的MMI应用的目录，其中只是创建了一个什么也不干的MMI任务(线程)，处理下层发送上来的消息。plutommi是pluto组织(也可能是原本的mmi应用的代号)所写的整套MMI应用所在的目录，
而实际上也就是我们需要定制和修改的MMI应用。其中的mmi目录中是pluto原本写好的mmi应用，mtkapp中是mtk后来所写的mmi应用，而Customer中是图片、字符串等资源的定制目录，大部分只是修改了字符串和图片、声音等的项目只要修改这个目录下的资源即可。
mtk_lib中是已经编译链接好的ARM版的库。因整个工程过于庞大，若完整的全新构建一次需要很长的时间。为了减少构建的时间，将一些已经完全调试稳定且基本不再改动的库和MTK不开放源代码的库放到这个目录，这样每次构建时只需要将这些库和其他编译好的库链接起来就可以了。这些库一般是ARM 版的，若有thumb版的，则再增加一个和ARM版相对的thumb版的库，一般叫第二个库，如media_sec.lib 就是thumb版的多媒体库。
custom是所有客户化项目的驱动程序及系统和MMI应用定制相关的文件的目录。如你的手机主板的RAM、FLASH等存储器的尺寸和地址空间有改动，MMI应用的特性有不同，蓝牙、WAP的配置有变化，或是有项目相关的新应用，其相关文件都是放在这个目录中和特定项目对应的目录下，如项目CUST1_6227，则放在CUST1_6227_BB下。要注意的是custom也作为一个模块存在，这使得其可以通过make目录中的custom模块的四个文件进行客户化的一些定制。
applib、bootloader、init、media、j2me等是这个系统各个层次的相对独立的模块各自的目录，其实drv 和fs等目录也可以看成是相对独立的模块，只不过其更重要些而在前面介绍。这些目录包含了这些模块
的C文件和头文件。每个目录(模块)都在下面的make目录中有相对应的目录保存构建时的编译链接配置文件。
make是工程构建过程中最重要的一个目录了，工程构建用的Makefile和一些中间配置文件将放在这里，Makefile在讲解构建过程时再具体介绍。在每个模块对应的目录下，都有四个文件控制了编译链接时的过程和配置。分别是：
<module_name>.def文件中是该模块构建过程中用的条件定义。
<module_name>.inc文件中是该模块所有用到的头文件所在目录的路径，是相对整个工程根目录的路径。
<module_name>.lis文件中列出了该模块的所有C文件，其路径也是相对整个工程根目录的。
<module_name>.pt件中是该模块的所有C文件所在目录的路径，是相对整个工程根目录的路径。
build目录中保存了构建过程中产生的目标文件和库文件，及其他一些中间文件。
二. MTK手机软件系统的构建过程
如前面一节所述，MTK手机软件系统的构建使用了GNU的make，使得整个工程的构建可以自动进行，且可以灵活控制。整个构建过程由Make.bat、make2.pl、MoDIS.dsw、Gsm2.mak、Option.mak、<customer>_<project>.mak等文件控制。构建PC模拟版是通过msdev和VC的工程文件MoDIS.dsw来完成的。Gsm2.mak是构建ARM版的核心Makefile文件，整个构建过程由其控制，其他是一些启动、选项配置、子过程的文件。其关系图如下所示。
在MTK手机软件系统的根目录下有一个批处理文件Make.bat，这个批处理文件启动了整个工程的构建过程。在windows的命令行下，在该系统的根目录下输入命令make和相应的参数即可开始工程的构建，该批处理文件的使用方法如下所示。
Usage:
make ["customer"|"mt62xx"] "project" "action" ["modules"]
Description:
customer  = mtk            (Default customer)
= firefly17_demo  (FIREFLY17_DEMO project)
= [mt6217|mt6219|mt6226|mt6227|mt6228|mt6229] (EVB only)
= ...
project    = l1s            (Layer 1 stand-alone)
= gsm            (GSM only)
= gprs            (GPRS only)
= basic          (Basic Framework)
action    = new            (codegen, resgen, clean, update) (default)
= update or u    (scan, compile, link)
= remake or r    (compile, link)
= clean or c      (clean)
= resgen          (resgen)
= c,u            (clean then update)
= c,r            (clean then remake)
= codegen        (codegen)
= viewlog        (open edit to view build log)
= emigen          (emigen)
= emiclean        (emiclean)
module(s)  = modules' name  (kal, l1, ...)
=> OPTIONAL when action is one of (clean c remake r update u c,r c,u)
Example:
make gsm new                        (MT6205B EVB new)
make gprs codegen                    (MT6218B EVB codegen)
make mt6219 gprs update              (MT6219 EVB update)
make firefly17_demo gprs new
make milan_demo gprs c,u init custom
make mt6219 gprs r init custom drv
其中较常用的action有new、update、remake、new_modis这几个。
new是全新开始构建整个工程的ARM版，包括图片、声音、字符串等资源都要重做，依赖的其他动作最多，是最彻底也是耗时最长的一个动作，一般得到一个新的MTK发布版本后要做一次。
update是重新更新整个工程的ARM版，该动作会扫描工程中文件和库的依赖关系，若依赖关系有变化会建立新的依赖关系，随后根据新的依赖关系重新编译链接有改动的部分，一般在增加或删除一些驱动或应用的情况下需要用update。
remake是重新编译整个工程的ARM版，该动作只是简单的重新编译链接有改动的部分，不检查依赖关系，是耗时最短的一个动作，也是最常用的动作。
new_modis是全新构建整个工程的PC模拟版，其调用VC的编译器和链接器得到一个可以在windows 上运行的PC模拟版。MMI应用软件工程师可以在没有硬件板的情况下在PC上检查和调试自己写好的应用。
Make.bat实际上只起引导作用，其只有一行批处理语句perl make2.pl %*，于是运行该批处理文件后控制权转给了perl脚本make2.pl。在这个perl脚本中解析了用户输入的命令行参数，设置变量，准备make时需要的临时配置文件，随后根据生成的可运行映像是PC模拟版还是ARM版而分别调用不同的构建过程。
Pc模拟版的构建通过调用如下命令实现。
system("$msdev MoDIS.dsw /MAKE \"$argu - Win32 $modisDir\"字符串函数strip的作用
/
OUT ${MoDISLogDir}\\${argu}.log")
在这里$msdev就是VC的msdev，通过VC的工程文件MoDIS.dsw和后面的参数进行具体的构建过程。熟悉VC工程的朋友应该比较清楚，因此就不再具体解释了。之后将只以ARM版为主来讲解整个工程的构建过程。
ARM版的构建通过调用如下命令实现。
system("${makeCmd} -f${makeFolder}${myMF} -r -R
CUSTOMER=$custom PROJECT=$project $action")
在这里${makeCmd}是，即GNU的make，${makeFolder}${myMF}是make\Gsm2.mak，$action是new、update、remake等。变量CUSTOMER和PROJECT分别是客户名和项目名，在构建过程中将根据此两个变量的值选定项目相关的配置文件，从而实现客户化的定制。通过给make指定ARM版的核心Makefile文件Gsm2.mak，开始了ARM版的构建过程。
Gsm2.mak文件中包含了Option.mak这个配置用的Makefile文件，另外还包含了一些以.tmp和.bld为后缀的由perl脚本make2.pl生成的临时配置文件。这些临时配置文件主要是一些action如clean、remake等所需的变量设置，及客户化和版本号等的一些信息。Gsm2.mak控制了new、update、remake等动作的过
程。具体分别如下所示。
new : cleanall cmmgen mmi_feature_check asngen codegen asnregen \
operator_check_lite update
update : cleanlog cleanbin mcddll_update codegen resgen cksysdrv remake
remake : cleanlog cleanbin genverno libs $(BIN_FILE) done
上面的构建过程的几个步骤中，最重要的两个步骤是libs、$(BIN_FILE) 。libs调用ARM版的编译器和连
接器将各个模块目录下的C文件编译链接为独立的库。$(BIN_FILE)这个步骤将各个模块编译链接得到的库和mtk_lib目录下的库一起链接起来得到一个映像文件，然后使用ADS的工具fromelf将映像文件生成以变量BIN_FILE命名的二进制文件，该文件可以下载到硬件板上运行。
libs这个步骤如下所示。
libs: cleanlib startbuildlibs $(COMPLIBLIST)
libs中真正进行编译链接的步骤是$(COMPLIBLIST)，要生成的库由变量COMPLIBLIST列出，在ARM 版中，变量COMPLIBLIST从变量COMPLIST得到。变量COMPLIST是在Option.mak及其包含的Makefile 文件中赋值的。因有很多库需要编译链接，变量COMPLIBLIST展开后包含多个步骤，而这些步骤都是重复不变的，因此在定义步骤$(COMPLIBLIST)的构建过程时使用%.lib代替。%.lib这个步骤先清除了之前的一些依赖关系文件，将一些变量的设置写入~p这个临时文件中，然后给make指定Makefile文件comp.mak，完成库的编译和链接，如下所示。
%.lib:
…
@if /I %OS% EQU WINDOWS_NT \

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。