Introduction to MTK mobile phone software system engineering and Configuration

 

MTKIs now on the market all domesticMobile phoneA complete mobile phone product solution that is designed and used by the manufacturer most. Most mobile phone technicians have contact and knowledge about it. However, the entire MTKSoftwareThe system is very huge and complex. Many software engineers who are new to the system do not know how to configure and customize the system. This article briefly introduces the engineering structure and configuration of the entire MTK software system, and hopes to share with you the maintenance, modification, and customization experiences of the MTK software system.

MTK uses the real-time operating system of the nucleus, and encapsulates the kernel abstraction layer on it to adapt to a variety of real-time operating systems, such as oscar, ThreadX, and nucleus. The entire software system includes the nucleus operating system, platform device driver, protocol stack, file system, WGUI, MMI, and J2EE. Here, the MMI part includes almost all the parts above the operating system kernel, protocol stack, and file system, where WGUI is also included.

The PC analog version of MTK is generated using the VC compiler and linker, And the ARM version is generated using the ADS1.2 compiler and linker. Because the entire software system of MTK is a huge and complex project, it must support multiple MTK product series and customer support from multiple clients, using the integrated development environment (IDE) it is no longer competent, and it is difficult to achieve the automatic construction of the entire project and the generation of resources and code. Therefore, MTK's software system uses the GNU development tool chain (MinGW) in windows for project management, configuration, and construction. MTK puts MinGW in a third-party tool. In addition, the perl script is used to parse the command line parameters entered by the user. Therefore, the third-party tool also contains ActivePerl (perl interpreter in windows ). However, the entire software system does not use all MinGW tools. It seems that only the make tool is used, and several makefiles control the building process, during compilation and linking, the VC compiler and the linker or the ADS1.2 compiler and the linker are called based on the final generation of the PC analog version or the ARM version respectively.

Next we will look at the MTK mobile phone software system from the specific engineering practices.

I. MTKIntroduction to the directory structure of the Mobile Software System

The main directory of the MTK mobile phone software system is as follows. Because the directory tree of the entire project is very large, for the sake of simplicity and reduced space, remove directories that are relatively unimportant in the engineering structure.

.
| -- 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
| -- J2EE
| -- Kal
| -- Make
| -- Applib
| -- Applib. def
| -- Applib. inc
| -- Applib. lis
| '-- Applib. pth
| -- Bootloader
| -- Config
| -- Custom
| -- Media
| -- Mmi
| -- Lucene
| -- Mtk_lib
| '-- MT6227
| '-- S01
| '-- Gprs
| -- Abm. lib
| -- Adaptation. lib
| -- Applib_inet.lib
| -- Nucleus
| -- Nvram
| -- Plutommi
| -- Tools

Fast_DL is the directory for downloading binary images, resources, and other related files during development. ROM is the directory of the relevant code and header files in the ROM (which may be the read-only area of Flash). In the release version provided to the customer, only some header files of the exported function are available, there seems to be another thing to jump to the table, ROMSA_FuncTable.

Kal is the directory of the files related to the kernel abstraction layer mentioned above. Nvram is the directory for accessing Code related to the content in NV. Nucleus is the directory of the real-time operating system of nucleus. Only header files are available in the released version. Drv is the directory of the driver-related code. Fs is a directory related to the file system. It seems that only the fat format is supported. Tools is the directory of engineering-related tools, including MinGW. Interface is the directory of interfaces at all layers of the system, and also contains interfaces of important modules, such as bluetooth and WIFI. Config is the directory of system and task-related header files. It does not feel like a configuration-related directory. Inc is the directory of the interrupt control and register address header files.

A directory related to the PC analog version, which includes the virtual GSMNetworkAnd SIM card, as well as the strings, images, and other resources required by the simulator, as well as the library of the PC simulation version, and related project files of the VC.

Mmi is the default directory of an empty MMI application. It only creates an MMI task (thread) to process messages sent from the lower layer. Plutommi is the directory of the entire mmi application written by the pluto organization (or perhaps the code of the original MMI application). In fact, it is the MMI application that we need to customize and modify. The mmi directory contains the mmi application originally written by pluto, the mmi application written by mtk, And the custom directory of images, strings, and other resources in Customer, most of the items that modify strings, images, and sounds only need to modify the resources in this directory.

Mtk_lib is a library of the ARM version that has been compiled. Because the entire project is too large, it takes a long time to build a new project. In order to reduce the build time, put some libraries that have been fully debugged, stable, and basically no changes, and MTK libraries that do not open source code to this directory, in this way, you only need to link these libraries with other compiled libraries during each build. These libraries are generally of the ARM version. If the thumb version is available, a database of the thumb version is added, which is usually called the second database, for example, media_sec.lib is the multi-media library of thumb.

Custom is the directory of drivers and systems of all custom projects and files related to MMI application customization. For example, if the size and address space of the memory such as RAM and FLASH on your mobile phone board are changed, the features of MMI applications are different, and the configurations of Bluetooth and WAP are changed, or a new project-related application is stored in the directory corresponding to a specific project. For example, the project cust00006227 is stored in cust00006227_bb. It should be noted that m also exists as a module, so that it can be customized through the four files of the custom module in the make directory.

Applib, bootloader, init, media, and j2_are directories of relatively independent modules at various levels of the system. In fact, directories such as drv and fs can also be considered as relatively independent modules, but it is more important. These directories contain the C files and header files of these modules. Each directory (module) has a corresponding directory in the make directory below to save the build link configuration file.

Make is the most important directory in the project construction process. Makefile and some intermediate configuration files used in the project construction will be placed here. Makefile will be detailed during the construction process. In the directory corresponding to each module, there are four files that control the process and configuration of the compilation link. They are:

<Module_name> The. def file defines the conditions used in the module construction process.

<Module_name> The. inc file contains the directory of all header files used by this module, and is the path relative to the root directory of the entire project.

<Module_name> The. lis file lists all the C files of the module, and the path is relative to the entire project root directory.

<Module_name> In the. pth file, the path of the directory where all C files of the module are located is relative to the root directory of the entire project.

The build directory stores the target and library files generated during the build process, and other intermediate files.

II. MTKMobile Phone Software System Construction Process

As described in the previous section, the MTK mobile phone software system is built using GNU make, so that the entire project can be automatically built and can be flexibly controlled. The entire construction process is controlled by files such as Make. bat, make2.pl, modem.dsw, Gsm2.mak, Option. mak, and <customer >_< project>. mak. The building of the PC Simulation Version is completed through msdev and VC's engineering file modem.dsw. Gsm2.mak is the core Makefile file for building the ARM version. It controls the entire build process. Others are startup, option configuration, and sub-process files. The relationship diagram is as follows.

There is a batch file Make. bat under the root directory of the MTK mobile phone software system. This batch file starts the entire project construction process. In the windows command line, enter the make command and corresponding parameters in the root directory of the system to start the project construction. The method of using the batch file is as follows.

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 (Layer1stand-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 actionisone of (clean c remake r update u c, r c, u)
Example:
Make gsmnew (MT6205B EVBnew)
Make gprs codegen (MT6218B EVB codegen)
Make mt6219 gprs update (MT6219 EVB update)
Make firefly17_demo glasnew
Make milan_demo gprs c, u init custom
Make mt6219 gprs r init custom drv

Among them, the commonly used actions include new, update, remake, and new_modem.

New is the new ARM version for building the entire project, including images, sounds, strings, and other resources that need to be redone. Other actions that depend on the most are the most thorough and time-consuming actions, generally, a new version of MTK will be created once after it is released.

Update is to re-update the ARM version of the entire project. This action scans the dependencies between files and libraries in the project. If the dependency changes, a new dependency is created, next, recompile the link modified according to the new dependency. update is usually required when some drivers or applications are added or deleted.

Remake is to re-compile the ARM version of the entire project. This action is only a simple part of the re-compilation link that has been changed. without checking the dependency, it is the most time-consuming action, it is also the most common action.

New_modem.com is a new PC Simulation Version for building the entire project. It calls the VC compiler and linker to obtain a PC simulation version that can run on windows. MMI application software engineers can check and debug their own applications on the PC without a hardware board.

Make. bat actually only acts as a bootstrap. It only has one batch processing statement perl make2.pl % *, so after running the batch processing file, the control is transferred to the perl script make2.pl. In this perl script, the command line parameters entered by the user are parsed, variables are set, and temporary configuration files are required for preparation of make, then, different building processes are called based on whether the generated running image is a PC simulated version or an ARM version.

The Pc simulated version is built by calling the following command.

System ("$ msdev Sandra. dsw/MAKE \" $ argu-Win32 $ modisDir \"

/OUT $ {MoDISLogDir }\\$ {argu}. log ")

Here $ msdev is the msdev of VC. The construction process is carried out through the VC project file modem.dsw and the following parameters. Those who are familiar with the VC project should be clear, so they will not explain it in detail. Later, we will only use the ARM version to explain the entire project construction process.

The ARM version is built by calling the following command.

System ("$ {makeCmd}-f $ {makeFolder }$ {myMF}-r-R

CUSTOMER = $ custom PROJECT = $ project $ action ")

Here $ {makeCmd} is tools \ make.exe, that is, GNU make, $ {makeFolder }$ {myMF} is make \ Gsm2.mak, and $ action is new, update, and remake. The CUSTOMER and PROJECT variables are the CUSTOMER and PROJECT names respectively. During the construction process, the configuration files related to the PROJECT are selected based on the values of the two variables to achieve custom customization. Specify the core Makefile Gsm2.mak of the ARM version for make to start the construction process of the ARM version.

The Gsm2.mak file contains the Makefile file used for the Option. mak configuration, and some temporary configuration files generated by the perl script make2.pl with the. tmp and. bld suffixes. These temporary configuration files are mainly variable settings required for actions such as clean and remake, as well as custom and version information. Gsm2.mak controls the new, update, remake, and other actions. The details are as follows.

New: cleanall cmgen 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

The two most important steps in the above construction process are libs and $ (BIN_FILE ). Libs calls the ARM compiler and connector to compile the C files in each Module Directory into an independent library. $ (BIN_FILE) This step links the library compiled by each module with the library in the mtk_lib directory to get an image file, then, use the analyticdb tool fromelf to generate a binary file named after the variable BIN_FILE. The file can be downloaded to the hardware board for running.
The libs step is as follows.

Libs: cleanlib startbuildlibs $ (COMPLIBLIST)

The actual compilation link in libs is $ (COMPLIBLIST). The library to be generated is listed by the variable COMPLIBLIST. In ARM, the variable COMPLIBLIST is obtained from the variable COMPLIST. The variable COMPLIST is assigned a value in Option. mak and Its Makefile file. Because many libraries need to compile links, the variable COMPLIBLIST contains multiple steps after expansion, and these steps are repeated and unchanged. Therefore, % is used to define the building process of step $ (COMPLIBLIST. lib instead. %. Lib this step first clears some previous dependency files and writes some variable settings ~ Compbld. tmp in this temporary file, and then specify Makefile file comp. mak for make to compile and link the library, as shown below.

%. Lib:
...
@ If/I % OS % EQU WINDOWS_NT \
(If/I $ (BM_NEW) EQU TRUE \
(Tools \ make.exe-fmake \ comp. mak-k-r-R $ (strip $ (CMD_ARGU) COMPONENT =ent * >$ (strip $ (COMPLOGDIR) \ $ *. log 2> & 1)
\
Else \
(Tools \ make.exe-fmake \ comp. mak-r-R $ (strip $ (CMD_ARGU) COMPONENT =ent * >$ (strip $ (COMPLOGDIR) \ $ *. log 2> & 1 )\
)\
Else \
(If/I $ (BM_NEW) EQU TRUE \
(Tools \ make.exe-fmake \ comp. mak-k-r-R $ (strip $ (CMD_ARGU) COMPONENT =ent * >$ (strip $ (COMPLOGDIR) \ $ *. log )\
Else \
(Tools \ make.exe-fmake \ comp. mak-r-R $ (strip $ (CMD_ARGU) COMPONENT =ent * >$ (strip $ (COMPLOGDIR) \ $ *. log )\
)

In the preceding command statement, the-k parameter indicates that compilation must be continued if an error occurs.-r and-R refer to the default rules and variables without GNU make. COMPONENT = $ * assign the current library to the variable COMPONENT. Note that %. lib matches all libraries to be generated, but this step generates only one module library at a time. This step will be executed once for all matched libraries.
The Makefile named comp. mak controls the compilation link process of the module. In this file, first set the library to be generated by the current module (passed in by the variable COMPONENT) to the variable TARGLIB. From <module_name>. the lis file obtains the SRC_LIST and CPPSRC_LIST source file lists, and sets the list of C files, C ++ files, assembly files to be compiled, and the list of intermediate target files to be linked. Assign the <module_name>. inc, <module_name>. def, <module_name>. pth file header file path, C file path, and compilation Link parameter to the corresponding variable. Add the compilation parameters related to the platform (such as 6223 and 6225) to determine whether the interwork mode of the ARM instruction and the thumb instruction is supported using the ARM compiler or the thumb compiler. The compilation link Process for the final import and export.
The library compilation link is completed by the update_lib step, which is directly dependent on $ (TARGLIB ). The target $ (TARGLIB) is a link to all intermediate target files compiled according to. c. obj,. s. obj, %. obj: %. cpp, and other rules. The main process is as follows.

$ (TARGLIB ):
...
@ If exist $ (FIXPATH) \ $ (CUS_MTK_LIB) \ $ (COMPONENT). lib \
(Copy/z $ (FIXPATH) \ $ (CUS_MTK_LIB) \ $ (COMPONENT). lib $ (subst/, \, $ (TARGLIB )))&\
($ (LIB)-r $ (TARGLIB) $ (COMPOBJS_DIR)/*. obj )\
Else \
($ (LIB)-create $ (TARGLIB) $ (COMPOBJS_DIR)/*. obj)
...

Option. mak is the master control configuration file during the entire project construction process. It also contains <customer >_< project>. mak and REL_CR_MMI _ <project>. mak configuration files related to the two projects. The user-defined configuration file USER_SPECIFIC.mak also contains some temporary configuration files. These configuration files together set the compiler, linker, library, and binary tools used in the project construction process, set the parameters at the compilation link, and the common header file path, set the required libraries in the mtk_lib directory, and set a series of related settings such as the library to be generated. These settings are all saved by some important variables, which will be explained in the next section.

3.. MTKMobile Software System Configuration

Most of the configurations of the MTK mobile phone software system have been determined and basically do not need to be changed. Generally, some changes will be made when the MTK releases a new version, so customers do not need to worry much about it. The main configuration file is Option. mak, and the main files to be modified for custom customization are <costomer >_< project>. mak and REL_CR_MMI _ <project>. mak.

Option. the mak file sets the path and executable program name of the compiler, linker, library management, binary file generation and other tools used during project construction, and sets the basic compilation link parameters, specify the cputype (ARM7EJ-S) to determine the final library list (COMPLIST ).

A project consists of multiple basic libraries, third-party libraries, and libraries with newly compiled source code links. These libraries are linked together to obtain a complete executable image file. A project composed of libraries with newly compiled links is determined by four key variables, one of which is the COMPLIST mentioned earlier, and the other three are CUS_REL_SRC_COMP, CUS_REL_PAR_SRC_COMP, and CUS_REL_MTK_COMP. The relationships between these variables are as follows.

#*************************************** **********************************

# Custom Release Component Configuration

#*************************************** **********************************

# Be sure the following:

#1. CUS_REL_SRC_COMP + CUS_REL_PAR_SRC_COMP = COMPLIST (CUSTOM_RELEASE = True)

#2. CUS_REL_SRC_COMP + CUS_REL_PAR_SRC_COMP + CUS_REL_MTK_COMP = COMPLIST (CUSTOM_RELEASE = False)

COMPLIST determines which libraries (components) The project is ultimately composed. When building an internal version of MTK, databases such as CUS_REL_SRC_COMP, CUS_REL_PAR_SRC_COMP, and CUS_REL_MTK_COMP are included. When building a customer version, only databases such as CUS_REL_SRC_COMP and CUS_REL_PAR_SRC_COMP are included. The versions built by mobile design companies are customer versions. Therefore, you only need to change the values of the two variables cus_relc_comp and CUS_REL_PAR_SRC_COMP to customize your own projects.

MTK_LIBS determines which base libraries provided by MTK are ultimately included in the project.

COMPOBJS determines the third-party libraries provided by the project without source code. The CUS_RES_OBJ_LIST variable is used to publish these third-party libraries along with the project.

Option. mak and REL_CR_MMI _ <project>. mak both assign values to the two variables CUS_REL_SRC_COMP and CUS_REL_PAR_SRC_COMP. However, the Option. mak file only sets the basic library required by the entire project, such as handwriting and graphic decoding, and has nothing to do with a specific project. Therefore, to customize your own project, you only need to modify the value assigned to the REL_CR_MMI _ <project>. mak file.

The <costomer> _ <project>. mak file also has a value for COMPLIST, but this is only useful for the internal version of MTK and has no impact on the customer version. It is worth noting that the vast majority of features (feature) of this project are determined in this file, such as the sensor used, the audio and video formats supported, the phone book size, and the LCD screen size. Below are some of the content in this file.

J2ME_SUPPORT = NONE # j2support: NONE, mtk_j2_lib ,\
MTK_J2MEHI, J2MEHI_LIB, MTK_DUMMYVM
DRM_SUPPORT = NONE # drm vendor: NONE, MTK, BSCI
DRM_VERSION = NONE # drm version: NONE, V01, V02, ALL
AMRWB_DECODE = TRUE # TRUE/FALSE
AMRWB_ENCODE = FALSE # TRUE/FALSE
# MT6219 DSP cannot support AMRWB_ENCODE when GPRS connection
JPG_DECODE = JPG_HW # NONE, JPG_HW, JPG_SW
JPG_ENCODE = JPG_HW # NONE, JPG_HW, JPG_SW
GIF_DECODE = TRUE # TRUE/FALSE
PNG_DECODE = NONE # NONE, PNG_HW, PNG_SW
DAF_DECODE = TRUE # TRUE/FALSE
MJPG_SUPPORT = FALSE # TRUE/FALSE
MP4_CODEC = TRUE # TRUE/FALSE
AAC_DECODE = TRUE # TRUE/FALSE
ISP_SUPPORT = TRUE # TRUE/FALSE
CMOS_SENSOR = OV7660 # OV9640, PAS105, PAS302, NONE, MT9D011 ,\
MT9M111, OV9650

Thu.Add a module configuration instance

To add a zlib module (zlib contains the compression and decompression functions used by many programs), follow these steps.

1. copy the source code package of zlib to the root directory of your MTK software system, so that all zlib code is under the zlib directory or the zlib-1.2.3 directory (which directory name is determined by your preferences), put it in the zlib directory for simplicity.

2. add a zlib directory under the make directory (preferably the same as the directory name under the root directory) and add four files: zlib. def, zlib. inc, zlib. lis, zlib. pth. Add APCS_INTWORK to the zlib. def file. Add the source file, its directory, and the header file directory to the other three files.

3. Add the following statement to the appropriate location of the file REL_CR_MMI _ <project>. mak.

CUS_REL_SRC_COMP + = zlib

4. remake the project. If there is no error, the zlib module is successfully added. Other modules can call the compression and decompression functions provided by zlib.

If you want to add a third-party library without source code, such as wifi, you can follow the steps below.

1. Copy all the third-party library files of wifi to a new wifi directory.

2. Add the following statement to the proper position of the Option. mak file.

Ifeq ($ (strip $ (WIFI_SUPPORT), WIFI_LIB)

COMPOBJS + = wifi \ sslplus. lib

CUS_REL_OBJ_LIST + = wifi \ sslplus. lib

COMPOBJS + = wifi \ sb. lib

CUS_REL_OBJ_LIST + = wifi \ sb. lib

Endif

3.

Source: MTK mobile phone software system engineering and Configuration Overview-sleeping bag bear's personal Space-wangjie blog-powered by X-Space