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

1、基于MT6752的Android系统启动流程分析报告1、Bootloader引导22、Linux内核启动233、Android系统启动23报告人：日 期：2016.09.03对于Android整个启动过程来说，基本可以划分成三个阶段：Bootloader引导、Linux kernel启动、Android启动。但根据芯片架构和平台的不同，在启动的Bootloader阶段会有所差异。本文以MTK的MT6752平台为例，分析一下基于该平台的Android系统启动流程。1、Bootloader引导1.1、Bootloader基本介绍BootLoader是在操作系统运行之前运行的一段程序，它可以将系统的

2、软硬件环境带到一个合适状态，为运行操作系统做好准备，目的就是引导linux操作系统及Android框架(framework)。它的主要功能包括设置处理器和内存的频率、调试信息端口、可引导的存储设备等等。在可执行环境创建好之后，接下来把software装载到内存并执行。除了装载software，一个外部工具也能和bootloader握手(handshake)，可指示设备进入不同的操作模式，比如USB下载模式和META模式。就算没有外部工具的握手，通过外部任何组合或是客户自定义按键，bootloader也能够进入这些模式。由于不同处理器芯片厂商对arm core的封装差异比较大，所以不同的arm处

3、理器，对于上电引导都是由特定处理器芯片厂商自己开发的程序，这个上电引导程序通常比较简单，会初始化硬件，提供下载模式等，然后才会加载通常的bootloader。下面是几个arm平台的bootloader方案：marvell(pxa935) :              bootROM + OBM + BLOBinformax(im9815) :             bootR

4、OM + 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

5、)  第2部分bootloader，是LK（little kernel的缩写，作用同常见的u-boot差不多），这部分依赖操作系统，负责引导linux操作系统和Android框架。1.2、bootloader的工作流程1.2.1 bootloader正常的启动流程先来看启动流程图：正常启动的主要工作如下：(1)  设备上电后，Boot ROM开始运行。(2)  BootROM初始化软件堆栈(software stack)、通信端口和可引导存储设备(比如NAND/EMMC)。(3)  BootROM从存储器中加载pr

6、e-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从存储器中加载引导镜像(boot image)，包括linux内核和ramdisk(Android呢？)(8)  U-Boot跳转到linux内

7、核并执行。1.2.2 bootloader正常的下载流程先来看正常的下载流程图：正常的下载主要工作如下：(1)  设备上电后，Boot ROM开始运行。(2)  BootROM初始化软件堆栈(software stack)、通信端口和可引导存储设备(比如NAND/EMMC)。(3)  BootROM通过UART/USB和flash工具握手。(4)  BootROM通过UART下载pre-loader镜像到NAND flash/EMMC中，然后重启。(5)  BootROM加载pre-loader

8、到内部SRAM汇总，因为DRAM还没有初始化。(6)  BootROM跳转到pre-loader并执行。(7)  Pre-loader初始化DRAM和通过USB与flash工具握手。(8)  Pre-loader通过USB下载其余镜像文件，比如U-Boot、boot image、recovery image、android system image、user data到NAND FLASH/EMMC中。1.2.3 Bootloader备用的下载流程(emergency download procedure)(1)  

9、;设备上电后，Boot ROM开始运行。(2)  BootROM初始化软件堆栈(software stack)、通信端口和可引导存储设备(比如NAND/EMMC)。(3)  BootROM在emergency DL按键按下后，通过USB和flash工具握手。(4)  BootROM通过USB把指定的镜像文件下载到NAND FLASH/EMMC中。1.3、Pre-loader启动过程1.3.1 Pre-loader的功能pre-loader是MTK内置的loader，它的主要功能如下：(1)  负责在芯片组平台(ch

10、ipset platform)上准备好可执行的环境(2)  如果外部工具有效，它会试图通过UART或是USB来和外部工具握手。(3)  从NAND/EMMC加载U-Boot，并跳转到U-Boot。(4)  使用工具握手，设备能够触发进入下载模式来下载需要的镜像，或是进入工厂/测试模式，比如META模式和ATE工厂模式，在这些模式下可以测试模块，或是通过传递引导参数给U-Boot和linux内核来校准设备(device calibration)1.3.2 Pre-loader中涉及的硬件部分当系统启动时，芯片组(chipset)内部的可

11、引导ROM开始执行，并从可引导存储设备(NAND/EMMC等等)上拷贝pre-loader。所以，需要通过初始化一些硬件模块来为软件创造必要的可执行环境(essential execution environment)，所有这些硬件模块在接下来描述。(1)   PLL模块1) PLL模块用于调整处理器和外部内存的频率。2) 在PLL模块初始化后，处理器和外部内存的频率可由26MHZ/26MHZ增加到1GHZ/192MHZ。(2)  UART模块1) UART模块用于调试或是META模式下的握手。2) 默认情况下，UART4初始化波特率为9216000bp

12、s和用于调试信息的输出，UART1初始化为115200bps和作为UART META默认端口。但也可以使用UART1作为调试或是UART META端口。(3)  计时器(timer)模块这是个基本的模块，用来计算硬件模块所需要的延时或是超时时间。(4)  内存模块1) Pre-loader由boot ROM加载和在芯片组内部的SRAM中执行，因为外部的DRAM还没有初始化。2) 为了准备软件整个可执行环境，pre-loader采用内置的内存设置来初始化DRAM(DRAM is initialized upon pre-loader b

13、uilt-inmemory settigns)。这样，U-Boot就能够被加载到DRAM中并执行。(5)  GPIO模块(6)  PMIC模块为了提供一些基本的硬件功能，比如控制外设电源，pre-loader初始化上层模块(upper modules)。(7)  RTC模块1) 当通过power按键开机后，pre-loader拉高RTC的PWBB来保持设备一直有电(keep the device alive)和继续引导U-Boot。2) RTC闹钟(alarm)有可能是设备开机的启动源，对于这种情况，设备部需要按power按

14、键就可自动启动。(8)  USB模块当USB线插入时，它初始化来和外部工具通信，比如用于升级系统的下载工具或是META模式触发器的META工具。(9)  NAND模块(10) MSDC模块Pre-loader可以从NAND flash或是EMMC中加载U-Boot，这两者只能选择其中一种来启动。1.3.3 Pre-loader的过程(procedure)和流程(flow)1.3.4 pre-loader的上电情景当检测到按下power按键或是USB/充电线插入，pre-loader调用rtc_bbpu_power_on()函数来锁存RTC的PWBB来保持

15、设备的一直供电，这样就算是松开power按键设备也不会关机。 函数位置在：mediatekplatformmt6752preloadersrcdriversrtc.c文件第681行定义。1.3.5 下载过程(download procedure)Pre-loader检查下面的条件：(1)  充电器已连接(charger is connected)(2)  USB已连接(3)  Flash工具的握手是否通过如果满足上面这几种要求，pre-loader就会开始下载镜像。下载镜像的主函数usbdl_handlerPre-loader接收到从

16、flash工具传递进来的“DOWNLOAD”字符串时，usbdl_handler函数开始下载镜像：函数位置在：mediatekplatformmt6752preloadersrccoredownload.c定义。1.3.6 具体的代码分析过程代码位置：mediatekplatformmt6752preloadersrccoremain.c代码位置：mediatekplatformmt6752preloadersrccorehandshake_usb.c代码位置：mediatekplatformmt6752preloadersrcsrcdriversusbtty.c代码位置：mediatekpl

17、atformmt6752preloadersrccorehandshake_usb.c代码位置：mediatekplatformmt6752preloadersrccoredownload.c从Bus_hound分析工具，可以看到usb与flash tool工具的握手情况。1.4、LK启动过程LK是little kernel的简称，是一种bootloader（作用同常见的u-boot差不多），是Travis Geiselbrecht开发的一个开源项目，github地址为git:/ 它由pre-loader引导并执行。从根本上来说(basically)，pre-loader已经初始化了相关的硬件

18、模块，而不需要在LK中重新配置这些模块了。但一些模块在LK中被重新复位来配置硬件寄存器，这样可创造一个干净的环境。比如计时器模块，在LK中，计时器重新复位清零硬件计数来对计时进行复位。所有在LK中需要初始化的列在下面：(1)  计时器模块通过复位硬件寄存器来复位计时。(2)  串口模块LK采用串口模块来配置它的输入/输出系统，在这个模块初始化后，我们可以使用LK提供的“printf()”等函数来使用串口功能。(3)  I2C模块(4)  PWM模块(5)  PMIC模块(6) 

19、0;RTC模块和计时器模块一样，在LKt中，I2C/PMIC/RTC重新复位寄存器来复位这些模块。(7)  LED模块通过这power off charging个模块，设备能够通知用户当前的充电状态。(8)  充电模块这个模块负责关机充电(power off charging)、低电压充电(lower charging in the system)。(9)  LCD模块使用这个模块，设备能够显示logo或是任何通知的消息。(10) NAND模块因为LK也需要从flash读取镜像(比如内核或是ramdisk)，所以有必要在LK中初始化N

20、AND相关的功能。(11) MSDC模块支持MSDC启动1.4.1 LK的启动过程(procedure)和流程(flow)1.4.2 上电情景(power on scenario)-长按启动(long press to boot)当启动LK，电池将检查是否有power按键已按下，如果当前的启动原因是USB充电器，而不是按power按键，电池模块将等待用户按下power按键来启动(请注意，如果充电器插入，设备会自动上电，这是因为RTC PWBB由HW自动锁存) BOOL mtk_detect_key(unsigned short key)/* key: HW keycode */参数k

21、ey表示要检查的按键码，返回值表示这个按键是否按下，此函数来判断指定的按键是否按下。此函数代码位置：在mediatekplatformmt6752lkmtk _key.c定义，power按键的按键码为0x08。1.4.3 启动充电情景(boot charging scenario)1.4.4 LK模式选择情景(mode selection scenario)支持3种主要的启动模式：(1)  出厂/原厂模式(Factory mode)用于批量生产(mass product)时的出厂测试。(2)  META模式(移动工程师测试架构模式)用于批量生产时功能性测

22、试。(3)  恢复模式(recovery mode)用于SD卡镜像升级(upgrade)(这是由Android提供的镜像升级方案，用户能够从SD卡升级Android系统镜像)。(4)  高级的META模式(Advanced META mode)批量生产时的功能性测试(不像META模式，这种模式和正常的android启动共存，一般用来测试多媒体功能)。(5)  自动测试环境出厂模式(ATE Factory boot)通过PC端的ATE工具发送命令来测试产品的特性(feature)。(6)  闹钟启动(Alarm bo

23、ot)启动的原因是RTC闹钟。(7)  Fastboot启动(Fast boot)进入Fastboot刷机模式(8)  下载启动(download boot)当下载时，支持logo显示。(9)  软件重启(SW reboot)启动原因是重启，（ex. adb reboot）1.4.5 LK具体的代码分析过程代码位置：bootablebootloaderlkkernelmain.c代码位置：mediatekplatformmt6752lkplatform.c代码位置：bootablebootloaderlkappapp.c代码位置：bo

24、otablebootloaderlkappmt_bootmt_boot.c代码位置：mediatekplatformmt6752lkincludeplatformmt_reg_base.h2、Linux内核启动Linux内核启动一般由外部的bootloader引导，也可以在内核头部嵌入一个loader，这部分同硬件紧密相关，一般由汇编写。（1）内核zImage解压缩。 head.S首先初始化自解压相关的如内存等环境，接下来调用decompress_kernel进行解压(./arch/arm/boot/compressed/misc.c)（2）解压完成后，调用start_kernel启动内核(.

25、/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内核启动之后就到And

26、roid Init进程，进而启动Android相关的服务和应用。3.1、Init进程的启动 init进程，它是一个由内核启动的用户级进程。内核自行启动（已经被载入内存，开始运行， 并已初始化所有的设备驱动程序和数据结构等）之后，就通过启动一个用户级程序init的方式，完成引导进程。init始终是第一个进程。 启动过程就是代码init.c中main函数执行过程：systemcoreinitinit.c 在函数中执行了：文件夹建立，挂载，rc文件解析，属性设置，启动服务，执行动作，socket监听 循环调用service_start，将状态SVC_RESTARTING启动， 将启动后的servic

27、e状态设置为SVC_RUNNING。 pid=fork();execve(); 在消息循环中：Init进程执行了Android的Command，启动了Android的NativeService，监听Service的变化需求，Signal处理。 Init进程是作为属*（Property service），维护这些NativeService。 下面看两个重要的过程：rc文件解析和服务启动。 （1） rc文件解析 .rc文件是Android使用的初始化脚本文件 （System/Core/Init/readme.txt中有描述： four broad classes of statements whi

28、ch are Actions, Commands, Services, and Options.） 其中Command 就是系统支持的一系列命令，如：export，hostname，mkdir，mount，等等，其中一部分是 linux 命令， 还有一些是 android 添加的，如：class_start <serviceclass>： 启动服务，class_stop <serviceclass>：关闭服务，等等。 其中Options是针对 Service 的选项的。 系统初始化要触发的动作和要启动的服务及其各自属性都在rc脚本文件中定义。 具体看一下启动脚本：sys

29、temcorerootdirinit.rc        在解析rc脚本文件时，将相应的类型放入各自的List中： systemcoreinitInit_parser.c  ：init_parse_config_file( )存入到 action_queue、   action_list、 service_list中，解析过程可以看一下parse_config函数，类似状态机形式挺有意思。 这其中包含了服务：adbd、servicemanager、vold、ril-daemon、debuggerd、sur

30、faceflinger、zygote、media （2）服务启动        文件解析完成之后将service放入到service_list中。 文件解析完成之后将service放入到service_list中。        Service的启动是在do_class_start函数中完成： 代码位置：systemcoreinitbuiltins.c遍历所有名称为classname，状态不为SVC_DISABLED的Service启动 代码位置：systemcoreinit

31、init_parser.c代码位置：systemcoreinitbuiltins.cdo_class_start对应的命令： KEYWORD(class_start, COMMAND, 1, do_class_start) init.rc文件中搜索class_start：class_start main 、class_start core、 main、core即为do_class_start参数classname init.rc文件中Service class名称都是main：        service drm /system/b

32、in/drmserver class main service surfaceflinger /system/bin/surfaceflinger     class main 于是就能够通过main名称遍历到所有的Service，将其启动。 do_class_start调用：        init.rc中 on boot/action class_start core/执行command 对应 do_class_start      class_sta

33、rt main 3.2、ServiceManager启动 在init.rc脚本文件中ServiceManager的描述： ServiceManager用来管理系统中所有的binder service，不管是本地的c+实现的还是java语言实现的都需要这个进程来统一管理，最主要的管理就是，注册添加服务，获取服务。所有的Service使用前都必须先在servicemanager中进行注册。 do_find_service( ) do_add_service( ) svcmgr_handler( ) 代码位置：frameworksbasecmdsservicemanagerService_manag

34、er.c3.3、Zygote进程的启动Zygote这个进程是非常重要的一个进程，Zygote进程的建立是真正的Android运行空间，初始化建立的Service都是Navtive service. （1） 在.rc脚本文件中zygote的描述： 参数：-zygote -start-system-server上面的参数在这里就会用上，决定是否要启动和启动那些进程。 代码位置：frameworks/base/cmds/app_process/app_main.cpp（2）接着到了AndroidRuntime类中：代码位置：frameworksbasecorejniAndroidRuntime.cp

35、p/ start the virtual machine Java在虚拟机中运行的/向刚刚新建的虚拟机注册JNI本地接口/ jni 调用 java 方法，获取对应类的静态main方法/ jni调用 java方法，调用到ZygoteInit类的main函数到了ZygoteInit.java中的静态main函数中，从C+ JAVA （3）ZygoteInit真正Zygote进程: 代码位置：frameworksbasecorejavacomandroidinternalosZygoteInit.java/Registers a server socket for zygote command co

36、nnectionsZygote就建立好了，利用Socket通讯，接收请求，Fork应用程序进程，进入Zygote进程服务框架中。 3.4、SystemServer启动（1）在Zygote进程进入循环之前，调用了startSystemServer( ); （2）RuntimeInit中：代码位置：frameworksbasecorejavacomandroidinternalosRuntimeInit.javaprivate static void applicationInit(int targetSdkVersion, String argv)invokeStaticMain(args.startClass, args.startArg