跳至主要内容

【转】MTK手机软件系统工程和目录结构简介

MTK手机软件系统工程和目录结构简介
2008-03-26 21:40

MTK使用了nucleus实时操作系统,在其上做了个内核抽象层的封装,以适应多种实时操作系统,如oscarThreadXnucleus。整个软件系统包括nucleus操作系统、平台设备驱动、协议栈、文件系统、WGUIMMIJ2ME等。在这里MMI部分几乎包括了操作系统内核、协议栈、文件系统之上的所有部分,其中WGUI也在其中。

    MTKPC模拟版使用VC的编译器和链接器生成,ARM版使用ADS1.2的编译器和链接器生成。因为MTK的整个软件系统是一个很庞大而且复杂的工程,并且要支持多个MTK的产品系列和多家客户的客户化支持,使用集成开发环境(IDE)已经无法胜任,而且很难做到整个工程的自动构建和资源、代码的生成。所以MTK的软件系统使用了windows下的GNU开发工具链(MinGW)来进行工程的管理、配置和构建,MTKMinGW放到了第三方工具中。另外还使用了perl脚本来解析用户输入的命令行参数,因此第三方工具中还包含了ActivePerl(windows下的perl解释器)。不过,整个软件系统并没有使用MinGW的全部工具,好象只使用了make这个工具,由几个Makefile控制了构建的过程,在编译和链接时根据最终生成PC模拟版还是ARM版而分别调用VC的编译器和链接器或ADS1.2的编译器和链接器。

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中的内容的相关代码的目录。nucleusnucleus实时操作系统的目录,在给客户的发布版中只有头文件。drv是驱动相关的代码的目录。fs是文件系统相关的目录,好像只支持fat格式的。tools是工程相关工具的目录,包括MinGWinterface是系统各层的接口的目录,还包含重要模块的接口,如bluetoothWIFIconfig是一些系统和任务(task)相关头文件的目录,感觉不像是配置相关的目录。inc是中断控制和寄存器地址相关头文件的目录。

    modisPC模拟版的相关目录,包括了虚拟的GSM网络、SIM卡等,以及模拟器需要的字符串、图片等资源,还有PC模拟版的库、VC的相关工程文件。

    mmi是一个缺省的空的MMI应用的目录,其中只是创建了一个什么也不干的MMI任务(线程),处理下层发送上来的消息。plutommipluto组织(也可能是原本的mmi应用的代号)所写的整套MMI应用所在的目录,而实际上也就是我们需要定制和修改的MMI应用。其中的mmi目录中是pluto原本写好的mmi应用,mtkapp中是mtk后来所写的mmi应用,而Customer中是图片、字符串等资源的定制目录,大部分只是修改了字符串和图片、声音等的项目只要修改这个目录下的资源即可。

    mtk_lib中是已经编译链接好的ARM版的库。因整个工程过于庞大,若完整的全新构建一次需要很长的时间。为了减少构建的时间,将一些已经完全调试稳定且基本不再改动的库和MTK不开放源代码的库放到这个目录,这样每次构建时只需要将这些库和其他编译好的库链接起来就可以了。这些库一般是ARM版的,若有thumb版的,则再增加一个和ARM版相对的thumb版的库,一般叫第二个库,如media_sec.lib就是thumb版的多媒体库。

    custom是所有客户化项目的驱动程序及系统和MMI应用定制相关的文件的目录。如你的手机主板的RAMFLASH等存储器的尺寸和地址空间有改动,MMI应用的特性有不同,蓝牙、WAP的配置有变化,或是有项目相关的新应用,其相关文件都是放在这个目录中和特定项目对应的目录下,如项目CUST1_6227,则放在CUST1_6227_BB下。要注意的是custom也作为一个模块存在,这使得其可以通过make目录中的custom模块的四个文件进行客户化的一些定制。

    applibbootloaderinitmediaj2me等是这个系统各个层次的相对独立的模块各自的目录,其实drvfs等目录也可以看成是相对独立的模块,只不过其更重要些而在前面介绍。这些目录包含了这些模块的C文件和头文件。每个目录(模块)都在下面的make目录中有相对应的目录保存构建时的编译链接配置文件。

    make是工程构建过程中最重要的一个目录了,工程构建用的Makefile和一些中间配置文件将放在这里,Makefile在讲解构建过程时再具体介绍。在每个模块对应的目录下,都有四个文件控制了编译链接时的过程和配置。分别是:

      <module_name>.def文件中是该模块构建过程中用的条件定义。

      <module_name>.inc文件中是该模块所有用到的头文件所在目录的路径,是相对整个工程根目录的路径。

      <module_name>.lis文件中列出了该模块的所有C文件,其路径也是相对整个工程根目录的。

      <module_name>.pth文件中是该模块的所有C文件所在目录的路径,是相对整个工程根目录的路径。

   build目录中保存了构建过程中产生的目标文件和库文件,及其他一些中间文件。

评论

此博客中的热门博文

【转】VxWorks中的地址映射

在运用嵌入式系统VxWorks和MPC860进行通信系统设计开发时,会遇到一个映射地址不能访问的问题。 缺省情况下,VxWorks系统已经进行了如下地址的映射:   memory地址、bcsr(Board Control and Status)地址、PC_BASE_ADRS(PCMCIA)地址、Internal Memory地址、rom(Flach memory)地址等,但是当你的硬件开发中要加上别的外设时,如(falsh、dsp、FPGA等),对这些外设的访问也是通过地址形式进行读写,如果你没有加相应的地址映射,那么是无法访问这些外设的。   和VxWorks缺省地址映射类似,你也可以进行相应的地址映射。   如下是地址映射原理及实现:   1、 地址映射结构 在Tornado\target\h\vmLib.h文件中 typedef struct phys_mem_desc { void *virtualAddr; void *physicalAddr; UINT len; UINT initialStateMask; /* mask parameter to vmStateSet */ UINT initialState; /* state parameter to vmStateSet */ } PHYS_MEM_DESC; virtualAddr:你要映射的虚拟地址 physicalAddr:硬件设计时定义的实际物理地址 len;要进行映射的地址长度 initialStateMask:可以初始化的地址状态: 有如下状态: #define VM_STATE_MASK_VALID 0x03 #define VM_STATE_MASK_WRITABLE 0x0c #define VM_STATE_MASK_CACHEABLE 0x30 #define VM_STATE_MASK_MEM_COHERENCY 0x40 #define VM_STATE_MASK_GUARDED 0x80 不同的CPU芯片类型还有其特殊状态 initialState:实际初始化的地址状态: 有如下状态: #define VM_STATE_VALID 0x01 #define VM_STATE_VALID_NOT 0x00 #define VM_STATE_WRITA

【转】多迷人Gtkmm啊

前边已经说过用glade设计界面然后动态装载,接下来再来看看怎么改变程序的皮肤(主题)     首先从 http://art.gnome.org/themes/gtk2 下载喜欢的主题,从压缩包里提取gtk-2.0文件夹让它和我们下边代码生成的可执行文件放在同一个目录下,这里我下载的的 http://art.gnome.org/download/themes/gtk2/1317/GTK2-CillopMidnite.tar.gz     然后用glade设计界面,命名为main.glade,一会让它和我们下边代码生成的可执行程序放在同一个目录下边     然后开始写代码如下: //main.cc #include <gtkmm.h> #include <libglademm/xml.h> int main(int argc, char *argv[]) {     Gtk::Main kit(argc,argv);         Gtk::Window *pWnd;        gtk_rc_parse("E:\\theme-viewer\\themes\\gtk-2.0\\gtkrc");       Glib::RefPtr<Gnome::Glade::Xml> refXml;     try     {         refXml = Gnome::Glade::Xml::create("main.glade");     }     catch(const Gnome::Glade::XmlError& ex)     {         Gtk::MessageDialog dialog("Load glade file failed!", false,       \                                   Gtk::MESSAGE_ERROR, Gtk::BUTTONS_OK);         dialog.run();               return 1;     }         refXml->get_widget("main", pWnd);     if(pW

【转】https客户端的实现(libcurl)

一、              概念 1.         为什么要使用libcurl 1)        作为http的客户端,可以直接用socket连接服务器,然后对到的数据进行http解析,但要分析协议头,实现代理…这样太麻烦了。 2)        libcurl是一个开源的客户端url传输库,支持FTP,FTPS,TFTP,HTTP,HTTPS,GOPHER,TELNET,DICT,FILE和LDAP,支持Windows,Unix,Linux等平台,简单易用,且库文件占用空间不到200K 2.         get和post方式 客户端在http连接时向服务提交数据的方式分为get和post两种 1)        Get方式将所要传输的数据附在网址后面,然后一起送达服务器,它的优点是效率比较高;缺点是安全性差、数据不超过1024个字符、必须是7位的ASCII编码;查询时经常用此方法。 2)        Post通过Http post处理发送数据,它的优点是安全性较强、支持数据量大、支持字符多;缺点是效率相对低;编辑修改时多使用此方法。 3.         cookie与session 1)        cookie cookie是发送到客户浏览器的文本串句柄,并保存在客户机硬盘上,可以用来在某个Web站点会话之间持久地保持数据。cookie在客户端。 2)        session session是访问者从到达某个特定主页到离开为止的那段时间。每一访问者都会单独获得一个session,实现站点多个用户之间在所有页面中共享信息。session在服务器上。 3)        libcurl中使用cookie 保存cookie, 使之后的链接与此链接使用相同的cookie a)         在关闭链接的时候把cookie写入指定的文件 curl_easy_setopt(curl, CURLOPT_COOKIEJAR, "/tmp/cookie.txt"); b)        取用现在有的cookie,而不重新得到cookie curl_easy_setopt(curl, CURLOPT_COOKIEFILE, "/tmp/cookie.txt"); b)        ht