基于MT6752的-android-系统启动流程分析报告

基于MT6752的Android系统启动流程分析报告TOC\o"1-1"\h\z\u1、Bootloader引导 22、Linux内核启动 233、Android系统启动 23报告人：日期：2016.09.03对于Android整个启动过程来说，基本可以划分成三个阶段：Bootloader引导、Linuxkernel启动、Android启动。但依据芯片架构和平台的不同，在启动的Bootloader阶段会有所差异。本文以MTK的MT6752平台为例，分析一下基于该平台的Android系统启动流程。1、Bootloader引导1.1、Bootloader基本介绍BootLoader是在操作系统运行之前运行的一段程序，它可以将系统的软硬件环境带到一个合适状态，为运行操作系统做好打算，目的就是引导linux操作系统及Android框架(framework)。它的主要功能包括设置处理器和内存的频率、调试信息端口、可引导的存储设备等等。在可执行环境创建好之后，接下来把software装载到内存并执行。除了装载software，一个外部工具也能和bootloader握手(handshake)，可指示设备进入不同的操作模式，比如USB下载模式和META模式。就算没有外部工具的握手，通过外部任何组合或是客户自定义按键，bootloader也能够进入这些模式。由于不同处理器芯片厂商对armcore的封装差异比较大，所以不同的arm处理器，对于上电引导都是由特定处理器芯片厂商自己开发的程序，这个上电引导程序通常比较简洁，会初始化硬件，供应下载模式等，然后才会加载通常的bootloader。下面是几个arm平台的bootloader方案：marvell(pxa935):

bootROM+OBM+BLOBinformax(im9815):

bootROM+barbox+U-bootmediatek(mt6517):

bootROM+pre-loader+U-bootbroadcom(bcm2157):

bootROM+boot1/boot2+U-boot而对MT6752平台，MTK对bootloader引导方案又进行了调整，它将bootloader分为以下两个部分：(1)

第1部分bootloader，是MTK内部(in-house)的pre-loader，这部分依靠平台。(2)

第2部分bootloader，是LK（littlekernel的缩写，作用同常见的u-boot差不多），这部分依靠操作系统，负责引导linux操作系统和Android框架。1.2、bootloader的工作流程1.2.1bootloader正常的启动流程先来看启动流程图：正常启动的主要工作如下：(1)

设备上电后，BootROM起先运行。(2)

BootROM初始化软件堆栈(softwarestack)、通信端口和可引导存储设备(比如NAND/EMMC)。(3)

BootROM从存储器中加载pre-loader到内部SRAM(ISRAM)中，因为这时候还没有初始化外部的DRAM。(4)

BootROM跳转到pre-loader的入口处并执行。(5)

Pre-loader初始化DRAM和加载U-Boot到RAM中。(6)

Pre-loader跳转到U-Boot中并执行，然后U-Boot做一些初始化，比如显示的初始化等。(7)

U-Boot从存储器中加载引导镜像(bootimage)，包括linux内核和ramdisk(Android呢？)(8)

U-Boot跳转到linux内核并执行。1.2.2bootloader正常的下载流程先来看正常的下载流程图：正常的下载主要工作如下：(1)

设备上电后，BootROM起先运行。(2)

BootROM初始化软件堆栈(softwarestack)、通信端口和可引导存储设备(比如NAND/EMMC)。(3)

BootROM通过UART/USB和flash工具握手。(4)

BootROM通过UART下载pre-loader镜像到NANDflash/EMMC中，然后重启。(5)

BootROM加载pre-loader到内部SRAM汇总，因为DRAM还没有初始化。(6)

BootROM跳转到pre-loader并执行。(7)

Pre-loader初始化DRAM和通过USB与flash工具握手。(8)

Pre-loader通过USB下载其余镜像文件，比如U-Boot、bootimage、recoveryimage、androidsystemimage、userdata到NANDFLASH/EMMC中。1.2.3Bootloader备用的下载流程(emergencydownloadprocedure)(1)

设备上电后，BootROM起先运行。(2)

BootROM初始化软件堆栈(softwarestack)、通信端口和可引导存储设备(比如NAND/EMMC)。(3)

BootROM在emergencyDL按键按下后，通过USB和flash工具握手。(4)

BootROM通过USB把指定的镜像文件下载到NANDFLASH/EMMC中。1.3、Pre-loader启动过程1.3.1Pre-loader的功能pre-loader是MTK内置的loader，它的主要功能如下：(1)

负责在芯片组平台(chipsetplatform)上打算好可执行的环境(2)

假如外部工具有效，它会试图通过UART或是USB来和外部工具握手。(3)

从NAND/EMMC加载U-Boot，并跳转到U-Boot。(4)

运用工具握手，设备能够触发进入下载模式来下载须要的镜像，或是进入工厂/测试模式，比如META模式和ATE工厂模式，在这些模式下可以测试模块，或是通过传递引导参数给U-Boot和linux内核来校准设备(devicecalibration)1.3.2Pre-loader中涉及的硬件部分当系统启动时，芯片组(chipset)内部的可引导ROM起先执行，并从可引导存储设备(NAND/EMMC等等)上拷贝pre-loader。所以，须要通过初始化一些硬件模块来为软件创建必要的可执行环境(essentialexecutionenvironment)，全部这些硬件模块在接下来描述。(1)

PLL模块1)PLL模块用于调整处理器和外部内存的频率。2)在PLL模块初始化后，处理器和外部内存的频率可由26MHZ/26MHZ增加到1GHZ/192MHZ。(2)

UART模块1)UART模块用于调试或是META模式下的握手。2)默认状况下，UART4初始化波特率为9216000bps和用于调试信息的输出，UART1初始化为115200bps和作为UARTMETA默认端口。但也可以运用UART1作为调试或是UARTMETA端口。(3)

计时器(timer)模块这是个基本的模块，用来计算硬件模块所须要的延时或是超时时间。(4)

内存模块1)

Pre-loader由bootROM加载和在芯片组内部的SRAM中执行，因为外部的DRAM还没有初始化。2)

为了打算软件整个可执行环境，pre-loader采纳内置的内存设置来初始化DRAM(DRAMisinitializeduponpre-loaderbuilt-inmemorysettigns)。这样，U-Boot就能够被加载到DRAM中并执行。(5)

GPIO模块(6)

PMIC模块为了供应一些基本的硬件功能，比如限制外设电源，pre-loader初始化上层模块(uppermodules)。(7)

RTC模块1)

当通过power按键开机后，pre-loader拉高RTC的PWBB来保持设备始终有电(keepthedevicealive)和接着引导U-Boot。2)RTC闹钟(alarm)有可能是设备开机的启动源，对于这种状况，设备部须要按power按键就可自动启动。(8)

USB模块当USB线插入时，它初始化来和外部工具通信，比如用于升级系统的下载工具或是META模式触发器的META工具。(9)

NAND模块(10)MSDC模块Pre-loader可以从NANDflash或是EMMC中加载U-Boot，这两者只能选择其中一种来启动。1.3.3Pre-loader的过程(procedure)和流程(flow)1.3.4pre-loader的上电情景当检测到按下power按键或是USB/充电线插入，pre-loader调用rtc_bbpu_power_on()函数来锁存RTC的PWBB来保持设备的始终供电，这样就算是松开power按键设备也不会关机。函数位置在：mediatek\platform\mt6752\preloader\src\drivers\rtc.c文件第681行定义。1.3.5下载过程(downloadprocedure)Pre-loader检查下面的条件：(1)

充电器已连接(chargerisconnected)(2)

USB已连接(3)

Flash工具的握手是否通过假如满意上面这几种要求，pre-loader就会起先下载镜像。下载镜像的主函数usbdl_handlerPre-loader接收到从flash工具传递进来的“DOWNLOAD”字符串时，usbdl_handler函数起先下载镜像：函数位置在：\mediatek\platform\mt6752\preloader\src\core\download.c定义。1.3.6详细的代码分析过程代码位置：\mediatek\platform\mt6752\preloader\src\core\main.c代码位置：mediatek\platform\mt6752\preloader\src\core\handshake_usb.c代码位置：mediatek\platform\mt6752\preloader\src\src\drivers\usbtty.c代码位置：\mediatek\platform\mt6752\preloader\src\core\handshake_usb.c代码位置：\mediatek\platform\mt6752\preloader\src\core\download.c从Bus_hound分析工具，可以看到usb与flashtool工具的握手状况。1.4、LK启动过程LK是littlekernel的简称，是一种bootloader（作用同常见的u-boot差不多），是TravisGeiselbrecht开发的一个开源项目，github地址为git://github/travisg/lk.git，而mtk的代码中就用到了LK。它由pre-loader引导并执行。从根本上来说(basically)，pre-loader已经初始化了相关的硬件模块，而不须要在LK中重新配置这些模块了。但一些模块在LK中被重新复位来配置硬件寄存器，这样可创建一个干净的环境。比如计时器模块，在LK中，计时器重新复位清零硬件计数来对计时进行复位。全部在LK中须要初始化的列在下面：(1)

计时器模块通过复位硬件寄存器来复位计时。(2)

串口模块LK采纳串口模块来配置它的输入/输出系统，在这个模块初始化后，我们可以运用LK供应的“printf(…)”等函数来运用串口功能。(3)

I2C模块(4)

PWM模块(5)

PMIC模块(6)

RTC模块和计时器模块一样，在LKt中，I2C/PMIC/RTC重新复位寄存器来复位这些模块。(7)

LED模块通过这poweroffcharging个模块，设备能够通知用户当前的充电状态。(8)

充电模块这个模块负责关机充电(poweroffcharging)、低电压充电(lowercharginginthesystem)。(9)

LCD模块运用这个模块，设备能够显示logo或是任何通知的消息。(10)NAND模块因为LK也须要从flash读取镜像(比如内核或是ramdisk)，所以有必要在LK中初始化NAND相关的功能。(11)MSDC模块支持MSDC启动LK的启动过程(procedure)和流程(flow)1.4.2上电情景(poweronscenario)长按启动(longpresstoboot)当启动LK，电池将检查是否有power按键已按下，假如当前的启动缘由是USB充电器，而不是按power按键，电池模块将等待用户按下power按键来启动(请留意，假如充电器插入，设备会自动上电，这是因为RTCPWBB由HW自动锁存)

BOOLmtk_detect_key(unsignedshortkey) /*key:HWkeycode*/参数key表示要检查的按键码，返回值表示这个按键是否按下，此函数来推断指定的按键是否按下。此函数代码位置：在\mediatek\platform\mt6752\lk\mtk_key.c定义，power按键的按键码为0x08。启动充电情景(bootchargingscenario)1.4.4LK模式选择情景(modeselectionscenario)支持3种主要的启动模式：(1)

出厂/原厂模式(Factorymode)用于批量生产(massproduct)时的出厂测试。(2)

META模式(移动工程师测试架构模式)用于批量生产时功能性测试。(3)

复原模式(recoverymode)用于SD卡镜像升级(upgrade)(这是由Android供应的镜像升级方案，用户能够从SD卡升级Android系统镜像)。(4)

高级的META模式(AdvancedMETAmode)批量生产时的功能性测试(不像META模式，这种模式和正常的android启动共存，一般用来测试多媒体功能)。(5)

自动测试环境出厂模式(ATEFactoryboot)通过PC端的ATE工具发送吩咐来测试产品的特性(feature)。(6)

闹钟启动(Alarmboot)启动的缘由是RTC闹钟。(7)

Fastboot启动(Fastboot)进入Fastboot刷机模式(8)

下载启动(downloadboot)当下载时，支持logo显示。(9)

软件重启(SWreboot)启动缘由是重启，（ex.adbreboot）1.4.5LK详细的代码分析过程代码位置：\bootable\bootloader\lk\kernel\main.c代码位置：\mediatek\platform\mt6752\lk\platform.c代码位置：\bootable\bootloader\lk\app\app.c代码位置：bootable\bootloader\lk\app\mt_boot\mt_boot.c代码位置：mediatek\platform\mt6752\lk\include\platform\mt_reg_base.h2、Linux内核启动Linux内核启动一般由外部的bootloader引导，也可以在内核头部嵌入一个loader，这部分同硬件紧密相关，一般由汇编写。（1）内核zImage解压缩。head.S首先初始化自解压相关的如内存等环境，接下来调用decompress_kernel进行解压(./arch/arm/boot/compressed/misc.c)（2）解压完成后，调用start_kernel启动内核(./init/main.c)start_kernel是任何版本linux内核的通用初始化函数，它会初始化许多东西，输出linux版本信息，设置体系结构相关的环境，页表结构初始化，设置系统自陷入口，初始化系统IRQ，初始化核心调度器等等。最终会调用rest_init。（3）rest_init会调用kernel_init启动init进程（缺省是/init）。然后执行schedule起先任务调度。这个init是由android的./system/core/init下的代码编译出来的，由此进入了android的代码。3、Android系统启动首先Android框架架构图：Linux内核启动之后就到AndroidInit进程，进而启动Android相关的服务和应用。3.1、Init进程的启动init进程，它是一个由内核启动的用户级进程。内核自行启动（已经被载入内存，起先运行，并已初始化全部的设备驱动程序和数据结构等）之后，就通过启动一个用户级程序init的方式，完成引导进程。init始终是第一个进程。启动过程就是代码init.c中main函数执行过程：system\core\init\init.c在函数中执行了：文件夹建立，挂载，rc文件解析，属性设置，启动服务，执行动作，socket监听……循环调用service_start，将状态SVC_RESTARTING启动，将启动后的service状态设置为SVC_RUNNING。pid=fork();execve();在消息循环中：Init进程执行了Android的Command，启动了Android的NativeService，监听Service的改变需求，Signal处理。Init进程是作为属**（Propertyservice），维护这些NativeService。下面看两个重要的过程：rc文件解析和服务启动。（1）rc文件解析.rc文件是Android运用的初始化脚本文件（System/Core/Init/readme.txt中有描述：fourbroadclassesofstatementswhichareActions,Commands,Services,andOptions.）其中Command就是系统支持的一系列吩咐，如：export，hostname，mkdir，mount，等等，其中一部分是linux吩咐，还有一些是android添加的，如：class_start<serviceclass>：启动服务，class_stop<serviceclass>：关闭服务，等等。其中Options是针对Service的选项的。系统初始化要触发的动作和要启动的服务及其各自属性都在rc脚本文件中定义。详细看一下启动脚本：\system\core\rootdir\init.rc

在解析rc脚本文件时，将相应的类型放入各自的List中：\system\core\init\Init_parser.c

：init_parse_config_file()存入到action_queue、

action_list、service_list中，解析过程可以看一下parse_config函数，类似状态机形式挺有意思。这其中包含了服务：adbd、servicemanager、vold、ril-daemon、debuggerd、surfaceflinger、zygote、media……（2）服务启动

文件解析完成之后将service放入到service_list中。文件解析完成之后将service放入到service_list中。

Service的启动是在do_class_start函数中完成：代码位置：\system\core\init\builtins.c遍历所出名称为classname，状态不为SVC_DISABLED的Service启动代码位置：\system\core\init\init_parser.c代码位置：\system\core\init\builtins.cdo_class_start对应的吩咐：KEYWORD(class_start,COMMAND,1,do_class_start)init.rc文件中搜寻class_start：class_startmain、class_startcore、……main、core即为do_class_start参数classnameinit.rc文件中Serviceclass名称都是main：

servicedrm/system/bin/drmserverclassmainservicesurfaceflinger/system/bin/surfaceflinger

classmain于是就能够通过main名称遍历到全部的Service，将其启动。do_class_start调用：

init.rc中onboot //actionclass_startcore//执行command对应

do_class_start

class_startmain3.2、ServiceManager启动在init.rc脚本文件中ServiceManager的描述：ServiceManager用来管理系统中全部的binderservice，不管是本地的c++实现的还是java语言实现的都须要这个进程来统一管理，最主要的管理就是，注册添加服务，获得服务。全部的Service运用前都必需先在servicemanager中进行注册。do_find_service()do_add_service()svcmgr_handler()代码位置：frameworks\base\cmds\servicemanager\Service_manager.c3.3、Zygote进程的启动Zygote这个进程是特别重要的一个进程，Zygote进程的建立是真正的Android运行空间，初始化建立的Service都是Navtiveservice.（1）在.rc脚本文件中zygote的描述：参数：--zygote--start-system-server上面的参数在这里就会用上，确定是否要启动和启动那些进程。代码位置：frameworks/base/cmds/app_process/app_main.cpp（2）接着到了AndroidRuntime类中：代码位置：frameworks\base\core\jni\AndroidRuntime.cpp//startthevirtualmachineJava在虚拟机中运行的//向刚刚新建的虚拟机注册JNI本地接口//jni调用java方法，获得对应类的静态main方法//jni调用java方法，调用到ZygoteInit类的main函数到了ZygoteInit.java中的静态main函数中，从C++——》JAVA（3）ZygoteInit真正Zygote进程:代码位置：frameworks\base\core\java\com\android\internal\os\ZygoteInit.java//RegistersaserversocketforzygotecommandconnectionsZygote就建立好了，利用Socket通讯，接收恳求，Fork应用程序进程，进入Zygote进程服务框架中。3.4、SystemServer启动（1）在Zygote进程进入循环之前，调用了startSystemServer();（2）RuntimeInit中：代码位置：frameworks\base\core\java\com\android\internal\os\RuntimeInit.javaprivatestaticvoidapplicationInit(inttargetSdkVersion,String[]argv){invokeStaticMain(args.startClass,args.startArgs);}//获得SystemServer的main方法，抛出MethodAndArgsCaller异样（3）从startSystemServer起先执行并没有去调用SystemServer的任何方法，只是通过反射获得了main方法，赋给了Metho