What kind of motherboard is Taiwan’s mobile phone? Is it MTK?

Currently, most domestic mobile phones use the MTK universal operating system solidified by Taiwan’s MediaTek MTK chip. The advantages of this system are low cost and fast product development. It uses a very low-cost single chip to realize many functions. Super long standby, p3p4 handwriting, large screen, large speaker, GPS radio, Bluetooth, dual SIM card, dual standby and other functions can be easily realized. It is very suitable for China's national conditions and allows the working people to get high-quality and low-cost mobile phone products. However, there are some functions but none. How powerful! However, recently MTK has launched a new 6239 multimedia chip. This system has enhanced functions such as photography, filming, music, and running speed. It also supports a 5-megapixel camera function and achieves 30-frame video playback.

MTK is a complete mobile phone product solution that is most commonly used by all domestic mobile phone designers and manufacturers on the market, including large mobile phones. Some of the so-called desktop machines use the MTK solution, and most of the technicians who make mobile phones have contact and understanding of this. However, the entire software system of MTK is very large and complex, and many software engineers who are new to this system do not know how to configure and customize it. This article gives a brief introduction to the engineering structure and configuration of the entire MTK software system. I hope that through this article, I can share with you my experience in maintaining, modifying, and customizing the MTK software system.

MTK uses the nucleus real-time operating system 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, J2ME, etc. The MMI part here includes almost all parts above the operating system kernel, protocol stack, and file system, including WGUI.

The PC simulation 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 very large and complex project, and it has to support multiple MTK product series and customized support from multiple customers, it is no longer feasible to use an integrated development environment (IDE), and it is difficult to achieve the entire Automatic construction of projects and generation of resources and code. Therefore, MTK's software system uses the GNU development tool chain (MinGW) under Windows for project management, configuration and construction. MTK puts MinGW into a third-party tool. In addition, a perl script is used to parse the command line parameters entered by the user, so the third-party tool also includes ActivePerl (perl interpreter under windows). However, the entire software system does not use all the tools of MinGW. It seems that only the make tool is used. Several Makefiles control the construction process. When compiling and linking, VC is called separately depending on whether the PC simulation version or the ARM version is finally generated. compiler and linker or ADS1.2 compiler and linker.

Next, let’s look at MTK’s mobile software system from specific engineering practices.

1. Introduction to the directory structure of the MTK mobile software system

The main directories of the MTK mobile software system are as follows. Since the directory tree of the entire project is very large, for the sake of simplicity and reduction In order to reduce the length, directories that are relatively unimportant in the engineering structure have been removed.

.

|-- 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 is a directory for downloading related files such as binary images and resources during development. ROM is a directory of related codes and header files solidified in ROM (maybe the read-only area of ????Flash). Most of the releases to customers only have header files for exported functions, and there seems to be a jump table in it. ROMSA_FuncTable.

kal is the directory of the related files of the kernel abstraction layer mentioned above. nvram is the directory of related codes for accessing the contents in NV. Nucleus is the directory of the nucleus real-time operating system. There are only header files in the release version for customers. drv is the directory of driver-related code. fs is a directory related to the file system, and it seems to only support fat format. Tools is a directory of engineering-related tools, including MinGW. Interface is a directory of interfaces at each layer of the system, and also includes interfaces of important modules, such as bluetooth and WIFI.

config is a directory for some system and task-related header files. It does not feel like a configuration-related directory. inc is the directory of header files related to interrupt control and register addresses.

Modis is a directory related to the PC simulation version, including virtual GSM network, SIM card, etc., as well as strings, pictures and other resources required by the simulator, as well as PC simulation version libraries and VC related Project documents.

mmi is a default empty MMI application directory, which only creates an MMI task (thread) that does nothing to process messages sent by the lower layer. plutommi is the directory where the entire set of MMI applications written by the pluto organization (which may also be the code name of the original mmi application) is located. 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 mtkapp contains the mmi application later written by mtk, and the customer directory contains customized directories for resources such as pictures and strings. Most of them only modify strings, pictures, and sounds. For other projects, you only need to modify the resources in this directory.

mtk_lib contains the compiled and linked ARM version of the library. Because the entire project is too large, it would take a long time to build it completely new. In order to reduce the build time, put some libraries that have been fully debugged, stable and basically unchanged and MTK's non-open source libraries into this directory, so that each time you build, you only need to link these libraries with other compiled libraries. That's it. These libraries are generally ARM versions. If there is a thumb version, a thumb version library is added that is opposite to the ARM version. It is usually called the second library. For example, media_sec.lib is the thumb version of the multimedia library.

Custom is the directory for all customized project drivers and files related to system and MMI application customization. For example, if the size and address space of the RAM, FLASH and other memories of your mobile phone motherboard are changed, the characteristics of the MMI application are different, the configuration of Bluetooth and WAP is changed, or there are new applications related to the project, the relevant files are placed in In this directory, the directory corresponding to a specific project, such as project CUST1_6227, is placed under CUST1_6227_BB. It should be noted that custom also exists as a module, which allows it to be customized through the four files of the custom module in the make directory.

Applib, bootloader, init, media, j2me, etc. are the respective directories of relatively independent modules at each level of the system. In fact, directories such as drv and fs can also be regarded as relatively independent modules, but they are The more important ones are introduced earlier. These directories contain the C files and header files for these modules. Each directory (module) has a corresponding directory in the make directory below to save the compilation and link configuration file during build.

make is the most important directory in the project construction process. The Makefile and some intermediate configuration files used for project construction will be placed here. The Makefile will be introduced in detail when explaining the construction process. In the directory corresponding to each module, there are four files that control the process and configuration during compilation and linking. They are:

lt; module_namegt; The .def file contains the condition definitions used in the construction process of the module.

lt;module_namegt;The .inc file contains the path to the directory where all the header files used by the module are located, and is the path relative to the root directory of the entire project.

lt;module_namegt;.lis file lists all the C files of the module, and its path is also relative to the root directory of the entire project.

lt;module_namegt;The .pth file is the path to the directory where all C files of the module are located, which is the path relative to the root directory of the entire project.

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

2. Construction process of MTK mobile software system

As mentioned in the previous section, the construction of MTK mobile software system uses GNU make, so that the construction of the entire project can be carried out automatically. , and can be flexibly controlled. The entire build process is controlled by Make.bat, make2.pl, MoDIS.dsw, Gsm2.mak, Option.mak, lt;customergt;_lt;projectgt;.mak and other files. Building the PC simulation version is completed through msdev and the VC project file MoDIS.dsw. Gsm2.mak is the core Makefile for building the ARM version. The entire build process is controlled by it. Others are files for startup, option configuration, and sub-processes. The relationship diagram is shown below.

There is a batch file Make.bat in the root directory of the MTK mobile software system. This batch file starts the construction process of the entire project. Under the Windows command line, enter the command make and the corresponding parameters in the root directory of the system to start building the project. The usage of 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 (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, ...)

=gt; 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

The more commonly used actions include new, update, remake, and new_modis.

New is a new ARM version of the entire project, including images, sounds, strings and other resources that need to be redone. It relies on the most other actions and is the most thorough and longest-consuming action. This is usually done after getting a new MTK release version.

Update is to re-update the ARM version of the entire project. This action will scan the dependencies of files and libraries in the project. If the dependencies change, new dependencies will be established, and then recompiled based on the new dependencies. For the changed parts of the link, update is generally required when adding or deleting some drivers or applications.

Remake is to recompile the ARM version of the entire project. This action simply recompiles and links the changed parts without checking dependencies. It is the shortest time-consuming action and is also the most commonly used action.

new_modis is a PC simulation version of the entire project that is newly built. It calls the VC compiler and linker to get a PC simulation version that can run on Windows. MMI application software engineers can check and debug their own applications on a PC without a hardware board.

Make.bat actually only serves as a boot. It has only one line of batch statement perl make2.pl *, so after running the batch file, 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 the temporary configuration files required for make are prepared. Then different build processes are called depending on whether the generated runnable image is the PC simulation version or the ARM version.

The PC simulation version is built by calling the following command.

system("$msdev MoDIS.dsw /MAKE \"$argu - Win32 $modisDir\"

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

Here $msdev is the msdev of VC. The specific construction process is carried out through the VC project file MoDIS.dsw and the following parameters. Friends who are familiar with VC engineering should know it better, so I won’t explain it in detail. Later, we will only explain the construction process of the entire project based on the ARM version.

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, which is GNU make, ${makeFolder}${myMF} is make\Gsm2.mak, $action is new, update, remake, etc. The variables CUSTOMER and PROJECT are the customer name and project name respectively. During the build process, the project-related configuration files will be selected based on the values ??of these two variables to achieve customized customization. By specifying the core Makefile file Gsm2.mak of the ARM version to make, the build process of the ARM version is started.

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

The details are as follows.

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

Among the steps in the above build process, the two most important steps are libs and $(BIN_FILE). libs calls the ARM version of the compiler and linker to compile and link the C files in each module directory into independent libraries. $(BIN_FILE) This step links the libraries compiled and linked by each module with the libraries in the mtk_lib directory to obtain an image file, and then uses the ADS tool fromelf to generate the image file into a binary file named after the variable BIN_FILE. This file can be downloaded Run on the hardware board.

The steps for libs are as follows.

libs: cleanlib startbuildlibs $(COMPLIBLIST)

The actual compilation and linking step in libs is $(COMPLIBLIST). The libraries to be generated are listed by the variable COMPLIBLIST. In the ARM version , the variable COMPLIBLIST is obtained from the variable COMPLIST. The variable COMPLIST is assigned in Option.mak and its included Makefile. Because there are many libraries that need to be compiled and linked, the variable COMPLIBLIST contains multiple steps after expansion, and these steps are repeated, so use .lib instead when defining the build process of step $(COMPLIBLIST). .lib This step first clears some previous dependency files, writes some variable settings into the temporary file ~compbld.tmp, and then specifies the Makefile comp.mak to make to complete the compilation and linking of 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=$* gt; $(strip $(COMPLOGDIR))\$ *.log 2gt;amp;1)

\

else \

(tools\make.exe -fmake\comp.mak -r -R $ (strip $(CMD_ARGU)) COMPONENT=$* gt; $(strip $(COMPLOGDIR))\$*.log 2gt;amp;1) \

) \

else \

(if /I $(BM_NEW) EQU TRUE \

(tools\make.exe -fmake\comp.mak -k -r -R $(strip $(CMD_ARGU )) COMPONENT=$* gt; $(strip $(COMPLOGDIR))\$*.log) \

else \

(tools\make.exe -fmake\comp. mak -r -R $(strip $(CMD_ARGU)) COMPONENT=$* gt; $(strip $(COMPLOGDIR))\$*.log) \

)

Above In the command statement, the parameter -k means to continue compilation even if there is an error, and -r and -R mean that there are no default rules and variables for GNU make. COMPONENT=$*Assign the library currently to be generated to the variable COMPONENT. It should be noted that .lib matches all libraries to be generated, but this step only generates the library of one module at a time. This step will be executed once for all matched libraries.

The Makefile comp.mak controls the compilation and linking process of the module. In this file, the library to be generated by the current module (passed in by the variable COMPONENT) is first set to the variable TARGLIB. Then obtain two source file lists, SRC_LIST and CPPSRC_LIST, from the .lis file, set the list of C files, C files, assembly files, etc. to be compiled, and the list of intermediate object files to be linked. Assign the header file path, C file path, compilation link parameters, etc. in the lt;module_namegt;.inc, lt;module_namegt;.def, lt;module_namegt;.pth file to the corresponding variables. Add platform-related compilation parameters (such as 6223, 6225) to determine whether to use the ARM compiler or the thumb compiler, and whether to support the interwork mode of ARM instructions and thumb instructions. Finally enter the compilation and linking process of the library.

The compilation and linking of the library is completed by the update_lib step, which directly depends on $(TARGLIB). Target $(TARGLIB) is obtained by linking 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))) amp; \

( $(LIB) -r $(TARGLIB) $(COMPOBJS_DIR)/*.obj) \

else \

($(LIB) -create $(TARGLIB) $(COMPOBJS_DIR )/*.obj)

...

Option.mak is the master control configuration file in the entire project construction process. This file also contains lt; customergt; _lt ;projectgt;.mak and REL_CR_MMI_lt;projectgt;.mak, the two project-related configuration files, the user-defined configuration file USER_SPECIFIC.mak, and also includes some temporarily generated configuration files. These configuration files together set the compiler, linker, library and binary tools used in the project construction process, set the parameters when compiling and linking, the public header file path, and set the mtk_lib directory that needs to be included. Which existing libraries are there, and a series of related settings such as the libraries that need to be generated are set. These settings are saved by some important variables, which are explained in the next section.

3. Configuration of the MTK mobile software system

Most of the configurations of the MTK mobile software system have been determined and basically do not need to be changed. Generally, they will be changed when MTK releases a new version. Make some changes and customers won't need to worry much. The most important configuration file is Option.mak, and the two files that need to be modified for customization are lt;costomergt;_lt;projectgt;.mak and REL_CR_MMI_lt;projectgt;.mak.

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

A project is composed of multiple basic libraries in the project, third-party libraries and libraries newly compiled and linked from the source code. Finally, these libraries are linked together to obtain a complete executable image file. Which newly compiled and linked libraries form a project are determined by four key variables, one of which is the aforementioned COMPLIST, and the other three are CUS_REL_SRC_COMP, CUS_REL_PAR_SRC_COMP, and CUS_REL_MTK_COMP. The relationship between these variables is 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 of. When the internal version of MTK is built, the libraries CUS_REL_SRC_COMP, CUS_REL_PAR_SRC_COMP, and CUS_REL_MTK_COMP are included. When the customer version is built, only the libraries CUS_REL_SRC_COMP and CUS_REL_PAR_SRC_COMP are included. The versions built by mobile phone design companies are all customer versions, so you can customize your own project by simply changing the values ??of the two variables CUS_REL_SRC_COMP and CUS_REL_PAR_SRC_COMP.

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

COMPOBJS determines which libraries provided by third parties without source code are ultimately included in the project. The variable CUS_RES_OBJ_LIST is used to publish these third-party libraries with the project.

Both files Option.mak and REL_CR_MMI_lt;projectgt;.mak have values ??assigned to the two variables CUS_REL_SRC_COMP and CUS_REL_PAR_SRC_COMP. However, the Option.mak file only sets the basic libraries needed for the entire project, such as handwriting, graphics decoding, etc., and has nothing to do with the specific project. Therefore, if customers want to customize their own projects, they only need to modify the assignment of these two variables in the REL_CR_MMI_lt;projectgt;.mak file.

lt;costomergt;_lt;projectgt;.mak file also has a value assigned to COMPLIST, but this is only useful for the internal version of MTK and has no effect on the customer version. It is worth noting that most of the functional features of the project are determined in this file, such as the sensor used, which audio and video formats are supported, phone book size, LCD screen size, etc. Below is part of the file.

J2ME_SUPPORT = NONE # J2ME support: NONE, MTK_J2ME, J2ME_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

IV. Add module configuration examples

If we need to add a module like zlib (zlib contains compression and decompression functions used by many programs), we can proceed as follows.

1. Copy the zlib source code package to the root directory of your MTK software system, so that all zlib codes are in the zlib directory or zlib-1.2.3 directory (which directory name you use is up to you (determined by your preferences), which is placed in the zlib directory for simplicity.

2. Add a zlib directory under the make directory (preferably the same directory name as the root directory), and add four files, namely zlib.def, zlib.inc, and zlib.lis ,zlib.pth. Just add APCS_INTWORK to the zlib.def file, and 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 REL_CR_MMI_lt;projectgt;.mak file.

CUS_REL_SRC_COMP = zlib

4. Remake the project. If there are no errors, the zlib module has been added successfully. Other modules can call the compression and decompression functions provided by zlib.

If we need to add a third-party library that does not have source code, such as adding wifi, we can follow the steps below.

1. Copy all third-party library files of wifi to a newly created wifi directory.

2. Add the following statement to the appropriate location in 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