MTK mobile phoneSoftwareSystemThe building process is the content to be introduced in this article, mainly for understanding and learning.MTK mobile phoneSoftwareSystemFirst, build an applicationMTK mobile phoneApplicationSystemPlatform. For more information, see this article.
MTK mobile phoneSoftwareSystemThe build of the project uses GNU make, so that the entire project can be automatically built and can be flexibly controlled. The entire construction process includes Make. bat, make2.pl, modem.dsw, Gsm2.mak, Option. mak, _ . Mak and other file control. 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.
InMTK mobile phoneSoftwareSystemThere is a batch processing file Make. bat under the root directory of. This batch processing file starts the entire project construction process. In windowsSystemEnter the make command and corresponding parameters in the root directory of to start project construction. The method of using the batch processing file is as follows.
- Usage:
- make["customer"|"mt62xx"]"project""action"["modules"]
- Description:
- customer=mtk(Defaultcustomer)
- =firefly17_demo(FIREFLY17_DEMOproject)
- =[mt6217|mt6219|mt6226|mt6227|mt6228|mt6229](EVBonly)
- =...
- project=l1s(Layer1stand-alone)
- =gsm(GSMonly)
- =gprs(GPRSonly)
- =basic(BasicFramework)
- action=new(codegen,resgen,clean,update)(default)
- =updateoru(scan,compile,link)
- =remakeorr(compile,link)
- =cleanorc(clean)
- =resgen(resgen)
- =c,u(cleanthenupdate)
- =c,r(cleanthenremake)
- =codegen(codegen)
- =viewlog(openedittoviewbuildlog)
- =emigen(emigen)
- =emiclean(emiclean)
- module(s)=modules'name(kal,l1,...)
- =>OPTIONALwhenactionisoneof(cleancremakerupdateuc,rc,u)
Example:
- makegsmnew(MT6205BEVBnew)
- makegprscodegen(MT6218BEVBcodegen)
- makemt6219gprsupdate(MT6219EVBupdate)
- makefirefly17_demogprsnew
- makemilan_demogprsc,uinitcustom
- makemt6219gprsrinitcustomdrv
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 perlmake2.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("$msdevMoDIS.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=$customPROJECT=$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:cleanallcmmgenmmi_feature_checkasngencodegenasnregen\
- operator_check_liteupdate
- update:cleanlogcleanbinmcddll_updatecodegenresgencksysdrvremake
- remake:cleanlogcleanbingenvernolibs$(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:cleanlibstartbuildlibs$(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%EQUWINDOWS_NT\
- (if/I$(BM_NEW)EQUTRUE\
- (tools\make.exe-fmake\comp.mak-k-r-R$(strip$(CMD_ARGU))COMPONENT=$*>$(strip$(COMPLOGDIR))\$*.log2>&1)
- \
- else\
- (tools\make.exe-fmake\comp.mak-r-R$(strip$(CMD_ARGU))COMPONENT=$*>$(strip$(COMPLOGDIR))\$*.log2>&1)\
- )\
- else\
- (if/I$(BM_NEW)EQUTRUE\
- (tools\make.exe-fmake\comp.mak-k-r-R$(strip$(CMD_ARGU))COMPONENT=$*>$(strip$(COMPLOGDIR))\$*.log)\
- else\
- (tools\make.exe-fmake\comp.mak-r-R$(strip$(CMD_ARGU))COMPONENT=$*>$(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 GNUmake. 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 pass in the library to be generated by the current module by the variable COMPONENT) to the variable TARGLIB. From In the. lis file, you can obtain the SRC_LIST and CPPSRC_LIST source files, set the list of C files, C ++ files, assembly files, and the list of intermediate target files to be linked. Set . Inc, . Def, The header file path, C file path, and compilation link parameters in the. pth file are assigned to corresponding variables. Add the compilation parameters related to the platform, such as 6223 and 6225) to determine whether the interwork mode of the ARM and thumb commands is supported by 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):
- ...
- @ifexist$(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 configuration file during the entire project construction process. It also contains _ . Mak and REL_CR_MMI _ . 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 saved by some important variables.
Summary: AnalysisMTK mobile phoneSoftwareSystemThe content of the build process has been introduced.MTK mobile phoneSoftwareSystemIs helpful to you.