基于MT6752的android系統(tǒng)啟動(dòng)流程分析報(bào)告

1、基于MT6752的Android系統(tǒng)啟動(dòng)流程分析報(bào)告1、Bootloader引導(dǎo)22、Linux內(nèi)核啟動(dòng)233、Android系統(tǒng)啟動(dòng)23報(bào)告人：日 期：2016.09.03對(duì)于Android整個(gè)啟動(dòng)過(guò)程來(lái)說(shuō)，基本可以劃分成三個(gè)階段：Bootloader引導(dǎo)、Linux kernel啟動(dòng)、Android啟動(dòng)。但根據(jù)芯片架構(gòu)和平臺(tái)的不同，在啟動(dòng)的Bootloader階段會(huì)有所差異。本文以MTK的MT6752平臺(tái)為例，分析一下基于該平臺(tái)的Android系統(tǒng)啟動(dòng)流程。1、Bootloader引導(dǎo)1.1、Bootloader基本介紹BootLoader是在操作系統(tǒng)運(yùn)行之前運(yùn)行的一段程序，它可以將系統(tǒng)的

2、軟硬件環(huán)境帶到一個(gè)合適狀態(tài)，為運(yùn)行操作系統(tǒng)做好準(zhǔn)備，目的就是引導(dǎo)linux操作系統(tǒng)及Android框架(framework)。它的主要功能包括設(shè)置處理器和內(nèi)存的頻率、調(diào)試信息端口、可引導(dǎo)的存儲(chǔ)設(shè)備等等。在可執(zhí)行環(huán)境創(chuàng)建好之后，接下來(lái)把software裝載到內(nèi)存并執(zhí)行。除了裝載software，一個(gè)外部工具也能和bootloader握手(handshake)，可指示設(shè)備進(jìn)入不同的操作模式，比如USB下載模式和META模式。就算沒(méi)有外部工具的握手，通過(guò)外部任何組合或是客戶自定義按鍵，bootloader也能夠進(jìn)入這些模式。由于不同處理器芯片廠商對(duì)arm core的封裝差異比較大，所以不同的arm處

3、理器，對(duì)于上電引導(dǎo)都是由特定處理器芯片廠商自己開(kāi)發(fā)的程序，這個(gè)上電引導(dǎo)程序通常比較簡(jiǎn)單，會(huì)初始化硬件，提供下載模式等，然后才會(huì)加載通常的bootloader。下面是幾個(gè)arm平臺(tái)的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而對(duì)MT6752平臺(tái)，MTK對(duì)bootloader引導(dǎo)方案又進(jìn)行了調(diào)整，它將bootloader分為以下兩個(gè)部分： (1)  第1部分bootloader，是MTK內(nèi)部(in-house)的pre-loader，這部分依賴平臺(tái)。(2

5、)  第2部分bootloader，是LK（little kernel的縮寫，作用同常見(jiàn)的u-boot差不多），這部分依賴操作系統(tǒng)，負(fù)責(zé)引導(dǎo)linux操作系統(tǒng)和Android框架。1.2、bootloader的工作流程1.2.1 bootloader正常的啟動(dòng)流程先來(lái)看啟動(dòng)流程圖：正常啟動(dòng)的主要工作如下：(1)  設(shè)備上電后，Boot ROM開(kāi)始運(yùn)行。(2)  BootROM初始化軟件堆棧(software stack)、通信端口和可引導(dǎo)存儲(chǔ)設(shè)備(比如NAND/EMMC)。(3)  BootROM從存儲(chǔ)器中加載pr

6、e-loader到內(nèi)部SRAM(ISRAM)中，因?yàn)檫@時(shí)候還沒(méi)有初始化外部的DRAM。(4)  BootROM跳轉(zhuǎn)到pre-loader的入口處并執(zhí)行。(5)  Pre-loader初始化DRAM和加載U-Boot到RAM中。(6)  Pre-loader跳轉(zhuǎn)到U-Boot中并執(zhí)行，然后U-Boot做一些初始化，比如顯示的初始化等。(7)  U-Boot從存儲(chǔ)器中加載引導(dǎo)鏡像(boot image)，包括linux內(nèi)核和ramdisk(Android呢？)(8)  U-Boot跳轉(zhuǎn)到linux內(nèi)

7、核并執(zhí)行。1.2.2 bootloader正常的下載流程先來(lái)看正常的下載流程圖：正常的下載主要工作如下：(1)  設(shè)備上電后，Boot ROM開(kāi)始運(yùn)行。(2)  BootROM初始化軟件堆棧(software stack)、通信端口和可引導(dǎo)存儲(chǔ)設(shè)備(比如NAND/EMMC)。(3)  BootROM通過(guò)UART/USB和flash工具握手。(4)  BootROM通過(guò)UART下載pre-loader鏡像到NAND flash/EMMC中，然后重啟。(5)  BootROM加載pre-loader

8、到內(nèi)部SRAM匯總，因?yàn)镈RAM還沒(méi)有初始化。(6)  BootROM跳轉(zhuǎn)到pre-loader并執(zhí)行。(7)  Pre-loader初始化DRAM和通過(guò)USB與flash工具握手。(8)  Pre-loader通過(guò)USB下載其余鏡像文件，比如U-Boot、boot image、recovery image、android system image、user data到NAND FLASH/EMMC中。1.2.3 Bootloader備用的下載流程(emergency download procedure)(1)  

9、;設(shè)備上電后，Boot ROM開(kāi)始運(yùn)行。(2)  BootROM初始化軟件堆棧(software stack)、通信端口和可引導(dǎo)存儲(chǔ)設(shè)備(比如NAND/EMMC)。(3)  BootROM在emergency DL按鍵按下后，通過(guò)USB和flash工具握手。(4)  BootROM通過(guò)USB把指定的鏡像文件下載到NAND FLASH/EMMC中。1.3、Pre-loader啟動(dòng)過(guò)程1.3.1 Pre-loader的功能pre-loader是MTK內(nèi)置的loader，它的主要功能如下：(1)  負(fù)責(zé)在芯片組平臺(tái)(ch

10、ipset platform)上準(zhǔn)備好可執(zhí)行的環(huán)境(2)  如果外部工具有效，它會(huì)試圖通過(guò)UART或是USB來(lái)和外部工具握手。(3)  從NAND/EMMC加載U-Boot，并跳轉(zhuǎn)到U-Boot。(4)  使用工具握手，設(shè)備能夠觸發(fā)進(jìn)入下載模式來(lái)下載需要的鏡像，或是進(jìn)入工廠/測(cè)試模式，比如META模式和ATE工廠模式，在這些模式下可以測(cè)試模塊，或是通過(guò)傳遞引導(dǎo)參數(shù)給U-Boot和linux內(nèi)核來(lái)校準(zhǔn)設(shè)備(device calibration)1.3.2 Pre-loader中涉及的硬件部分當(dāng)系統(tǒng)啟動(dòng)時(shí)，芯片組(chipset)內(nèi)部的可

11、引導(dǎo)ROM開(kāi)始執(zhí)行，并從可引導(dǎo)存儲(chǔ)設(shè)備(NAND/EMMC等等)上拷貝pre-loader。所以，需要通過(guò)初始化一些硬件模塊來(lái)為軟件創(chuàng)造必要的可執(zhí)行環(huán)境(essential execution environment)，所有這些硬件模塊在接下來(lái)描述。(1)   PLL模塊1) PLL模塊用于調(diào)整處理器和外部?jī)?nèi)存的頻率。2) 在PLL模塊初始化后，處理器和外部?jī)?nèi)存的頻率可由26MHZ/26MHZ增加到1GHZ/192MHZ。(2)  UART模塊1) UART模塊用于調(diào)試或是META模式下的握手。2) 默認(rèn)情況下，UART4初始化波特率為9216000bp

12、s和用于調(diào)試信息的輸出，UART1初始化為115200bps和作為UART META默認(rèn)端口。但也可以使用UART1作為調(diào)試或是UART META端口。(3)  計(jì)時(shí)器(timer)模塊這是個(gè)基本的模塊，用來(lái)計(jì)算硬件模塊所需要的延時(shí)或是超時(shí)時(shí)間。(4)  內(nèi)存模塊1) Pre-loader由boot ROM加載和在芯片組內(nèi)部的SRAM中執(zhí)行，因?yàn)橥獠康腄RAM還沒(méi)有初始化。2) 為了準(zhǔn)備軟件整個(gè)可執(zhí)行環(huán)境，pre-loader采用內(nèi)置的內(nèi)存設(shè)置來(lái)初始化DRAM(DRAM is initialized upon pre-loader b

13、uilt-inmemory settigns)。這樣，U-Boot就能夠被加載到DRAM中并執(zhí)行。(5)  GPIO模塊(6)  PMIC模塊為了提供一些基本的硬件功能，比如控制外設(shè)電源，pre-loader初始化上層模塊(upper modules)。(7)  RTC模塊1) 當(dāng)通過(guò)power按鍵開(kāi)機(jī)后，pre-loader拉高RTC的PWBB來(lái)保持設(shè)備一直有電(keep the device alive)和繼續(xù)引導(dǎo)U-Boot。2) RTC鬧鐘(alarm)有可能是設(shè)備開(kāi)機(jī)的啟動(dòng)源，對(duì)于這種情況，設(shè)備部需要按power按

14、鍵就可自動(dòng)啟動(dòng)。(8)  USB模塊當(dāng)USB線插入時(shí)，它初始化來(lái)和外部工具通信，比如用于升級(jí)系統(tǒng)的下載工具或是META模式觸發(fā)器的META工具。(9)  NAND模塊(10) MSDC模塊Pre-loader可以從NAND flash或是EMMC中加載U-Boot，這兩者只能選擇其中一種來(lái)啟動(dòng)。1.3.3 Pre-loader的過(guò)程(procedure)和流程(flow)1.3.4 pre-loader的上電情景當(dāng)檢測(cè)到按下power按鍵或是USB/充電線插入，pre-loader調(diào)用rtc_bbpu_power_on()函數(shù)來(lái)鎖存RTC的PWBB來(lái)保持

15、設(shè)備的一直供電，這樣就算是松開(kāi)power按鍵設(shè)備也不會(huì)關(guān)機(jī)。 函數(shù)位置在：mediatekplatformmt6752preloadersrcdriversrtc.c文件第681行定義。1.3.5 下載過(guò)程(download procedure)Pre-loader檢查下面的條件：(1)  充電器已連接(charger is connected)(2)  USB已連接(3)  Flash工具的握手是否通過(guò)如果滿足上面這幾種要求，pre-loader就會(huì)開(kāi)始下載鏡像。下載鏡像的主函數(shù)usbdl_handlerPre-loader接收到從

16、flash工具傳遞進(jìn)來(lái)的“DOWNLOAD”字符串時(shí)，usbdl_handler函數(shù)開(kāi)始下載鏡像：函數(shù)位置在：mediatekplatformmt6752preloadersrccoredownload.c定義。1.3.6 具體的代碼分析過(guò)程代碼位置：mediatekplatformmt6752preloadersrccoremain.c代碼位置：mediatekplatformmt6752preloadersrccorehandshake_usb.c代碼位置：mediatekplatformmt6752preloadersrcsrcdriversusbtty.c代碼位置：mediatekpl

17、atformmt6752preloadersrccorehandshake_usb.c代碼位置：mediatekplatformmt6752preloadersrccoredownload.c從Bus_hound分析工具，可以看到usb與flash tool工具的握手情況。1.4、LK啟動(dòng)過(guò)程LK是little kernel的簡(jiǎn)稱，是一種bootloader（作用同常見(jiàn)的u-boot差不多），是Travis Geiselbrecht開(kāi)發(fā)的一個(gè)開(kāi)源項(xiàng)目，github地址為git:/ 它由pre-loader引導(dǎo)并執(zhí)行。從根本上來(lái)說(shuō)(basically)，pre-loader已經(jīng)初始化了相關(guān)的硬件

18、模塊，而不需要在LK中重新配置這些模塊了。但一些模塊在LK中被重新復(fù)位來(lái)配置硬件寄存器，這樣可創(chuàng)造一個(gè)干凈的環(huán)境。比如計(jì)時(shí)器模塊，在LK中，計(jì)時(shí)器重新復(fù)位清零硬件計(jì)數(shù)來(lái)對(duì)計(jì)時(shí)進(jìn)行復(fù)位。所有在LK中需要初始化的列在下面：(1)  計(jì)時(shí)器模塊通過(guò)復(fù)位硬件寄存器來(lái)復(fù)位計(jì)時(shí)。(2)  串口模塊LK采用串口模塊來(lái)配置它的輸入/輸出系統(tǒng)，在這個(gè)模塊初始化后，我們可以使用LK提供的“printf()”等函數(shù)來(lái)使用串口功能。(3)  I2C模塊(4)  PWM模塊(5)  PMIC模塊(6) 

19、0;RTC模塊和計(jì)時(shí)器模塊一樣，在LKt中，I2C/PMIC/RTC重新復(fù)位寄存器來(lái)復(fù)位這些模塊。(7)  LED模塊通過(guò)這power off charging個(gè)模塊，設(shè)備能夠通知用戶當(dāng)前的充電狀態(tài)。(8)  充電模塊這個(gè)模塊負(fù)責(zé)關(guān)機(jī)充電(power off charging)、低電壓充電(lower charging in the system)。(9)  LCD模塊使用這個(gè)模塊，設(shè)備能夠顯示logo或是任何通知的消息。(10) NAND模塊因?yàn)長(zhǎng)K也需要從flash讀取鏡像(比如內(nèi)核或是ramdisk)，所以有必要在LK中初始化N

20、AND相關(guān)的功能。(11) MSDC模塊支持MSDC啟動(dòng)1.4.1 LK的啟動(dòng)過(guò)程(procedure)和流程(flow)1.4.2 上電情景(power on scenario)-長(zhǎng)按啟動(dòng)(long press to boot)當(dāng)啟動(dòng)LK，電池將檢查是否有power按鍵已按下，如果當(dāng)前的啟動(dòng)原因是USB充電器，而不是按power按鍵，電池模塊將等待用戶按下power按鍵來(lái)啟動(dòng)(請(qǐng)注意，如果充電器插入，設(shè)備會(huì)自動(dòng)上電，這是因?yàn)镽TC PWBB由HW自動(dòng)鎖存) BOOL mtk_detect_key(unsigned short key)/* key: HW keycode */參數(shù)k

21、ey表示要檢查的按鍵碼，返回值表示這個(gè)按鍵是否按下，此函數(shù)來(lái)判斷指定的按鍵是否按下。此函數(shù)代碼位置：在mediatekplatformmt6752lkmtk _key.c定義，power按鍵的按鍵碼為0x08。1.4.3 啟動(dòng)充電情景(boot charging scenario)1.4.4 LK模式選擇情景(mode selection scenario)支持3種主要的啟動(dòng)模式：(1)  出廠/原廠模式(Factory mode)用于批量生產(chǎn)(mass product)時(shí)的出廠測(cè)試。(2)  META模式(移動(dòng)工程師測(cè)試架構(gòu)模式)用于批量生產(chǎn)時(shí)功能性測(cè)

22、試。(3)  恢復(fù)模式(recovery mode)用于SD卡鏡像升級(jí)(upgrade)(這是由Android提供的鏡像升級(jí)方案，用戶能夠從SD卡升級(jí)Android系統(tǒng)鏡像)。(4)  高級(jí)的META模式(Advanced META mode)批量生產(chǎn)時(shí)的功能性測(cè)試(不像META模式，這種模式和正常的android啟動(dòng)共存，一般用來(lái)測(cè)試多媒體功能)。(5)  自動(dòng)測(cè)試環(huán)境出廠模式(ATE Factory boot)通過(guò)PC端的ATE工具發(fā)送命令來(lái)測(cè)試產(chǎn)品的特性(feature)。(6)  鬧鐘啟動(dòng)(Alarm bo

23、ot)啟動(dòng)的原因是RTC鬧鐘。(7)  Fastboot啟動(dòng)(Fast boot)進(jìn)入Fastboot刷機(jī)模式(8)  下載啟動(dòng)(download boot)當(dāng)下載時(shí)，支持logo顯示。(9)  軟件重啟(SW reboot)啟動(dòng)原因是重啟，（ex. adb reboot）1.4.5 LK具體的代碼分析過(guò)程代碼位置：bootablebootloaderlkkernelmain.c代碼位置：mediatekplatformmt6752lkplatform.c代碼位置：bootablebootloaderlkappapp.c代碼位置：bo

24、otablebootloaderlkappmt_bootmt_boot.c代碼位置：mediatekplatformmt6752lkincludeplatformmt_reg_base.h2、Linux內(nèi)核啟動(dòng)Linux內(nèi)核啟動(dòng)一般由外部的bootloader引導(dǎo)，也可以在內(nèi)核頭部嵌入一個(gè)loader，這部分同硬件緊密相關(guān)，一般由匯編寫。（1）內(nèi)核zImage解壓縮。 head.S首先初始化自解壓相關(guān)的如內(nèi)存等環(huán)境，接下來(lái)調(diào)用decompress_kernel進(jìn)行解壓(./arch/arm/boot/compressed/misc.c)（2）解壓完成后，調(diào)用start_kernel啟動(dòng)內(nèi)核(.

25、/init/main.c)start_kernel是任何版本linux內(nèi)核的通用初始化函數(shù)，它會(huì)初始化很多東西，輸出linux版本信息，設(shè)置體系結(jié)構(gòu)相關(guān)的環(huán)境，頁(yè)表結(jié)構(gòu)初始化，設(shè)置系統(tǒng)自陷入口，初始化系統(tǒng)IRQ，初始化核心調(diào)度器等等。最后會(huì)調(diào)用rest_init。（3）rest_init會(huì)調(diào)用kernel_init啟動(dòng)init進(jìn)程（缺省是/init）。然后執(zhí)行schedule開(kāi)始任務(wù)調(diào)度。這個(gè)init是由android的./system/core/init下的代碼編譯出來(lái)的，由此進(jìn)入了android的代碼。3、Android系統(tǒng)啟動(dòng)首先Android框架架構(gòu)圖：Linux內(nèi)核啟動(dòng)之后就到And

26、roid Init進(jìn)程，進(jìn)而啟動(dòng)Android相關(guān)的服務(wù)和應(yīng)用。3.1、Init進(jìn)程的啟動(dòng) init進(jìn)程，它是一個(gè)由內(nèi)核啟動(dòng)的用戶級(jí)進(jìn)程。內(nèi)核自行啟動(dòng)（已經(jīng)被載入內(nèi)存，開(kāi)始運(yùn)行， 并已初始化所有的設(shè)備驅(qū)動(dòng)程序和數(shù)據(jù)結(jié)構(gòu)等）之后，就通過(guò)啟動(dòng)一個(gè)用戶級(jí)程序init的方式，完成引導(dǎo)進(jìn)程。init始終是第一個(gè)進(jìn)程。 啟動(dòng)過(guò)程就是代碼init.c中main函數(shù)執(zhí)行過(guò)程：systemcoreinitinit.c 在函數(shù)中執(zhí)行了：文件夾建立，掛載，rc文件解析，屬性設(shè)置，啟動(dòng)服務(wù)，執(zhí)行動(dòng)作，socket監(jiān)聽(tīng) 循環(huán)調(diào)用service_start，將狀態(tài)SVC_RESTARTING啟動(dòng)， 將啟動(dòng)后的servic

27、e狀態(tài)設(shè)置為SVC_RUNNING。 pid=fork();execve(); 在消息循環(huán)中：Init進(jìn)程執(zhí)行了Android的Command，啟動(dòng)了Android的NativeService，監(jiān)聽(tīng)Service的變化需求，Signal處理。 Init進(jìn)程是作為屬*（Property service），維護(hù)這些NativeService。 下面看兩個(gè)重要的過(guò)程：rc文件解析和服務(wù)啟動(dòng)。 （1） rc文件解析 .rc文件是Android使用的初始化腳本文件 （System/Core/Init/readme.txt中有描述： four broad classes of statements whi

28、ch are Actions, Commands, Services, and Options.） 其中Command 就是系統(tǒng)支持的一系列命令，如：export，hostname，mkdir，mount，等等，其中一部分是 linux 命令， 還有一些是 android 添加的，如：class_start <serviceclass>： 啟動(dòng)服務(wù)，class_stop <serviceclass>：關(guān)閉服務(wù)，等等。 其中Options是針對(duì) Service 的選項(xiàng)的。 系統(tǒng)初始化要觸發(fā)的動(dòng)作和要啟動(dòng)的服務(wù)及其各自屬性都在rc腳本文件中定義。 具體看一下啟動(dòng)腳本：sys

29、temcorerootdirinit.rc        在解析rc腳本文件時(shí)，將相應(yīng)的類型放入各自的List中： systemcoreinitInit_parser.c  ：init_parse_config_file( )存入到 action_queue、   action_list、 service_list中，解析過(guò)程可以看一下parse_config函數(shù)，類似狀態(tài)機(jī)形式挺有意思。 這其中包含了服務(wù)：adbd、servicemanager、vold、ril-daemon、debuggerd、sur

30、faceflinger、zygote、media （2）服務(wù)啟動(dòng)        文件解析完成之后將service放入到service_list中。 文件解析完成之后將service放入到service_list中。        Service的啟動(dòng)是在do_class_start函數(shù)中完成： 代碼位置：systemcoreinitbuiltins.c遍歷所有名稱為classname，狀態(tài)不為SVC_DISABLED的Service啟動(dòng) 代碼位置：systemcoreinit

31、init_parser.c代碼位置：systemcoreinitbuiltins.cdo_class_start對(duì)應(yīng)的命令： KEYWORD(class_start, COMMAND, 1, do_class_start) init.rc文件中搜索class_start：class_start main 、class_start core、 main、core即為do_class_start參數(shù)classname init.rc文件中Service class名稱都是main：        service drm /system/b

32、in/drmserver class main service surfaceflinger /system/bin/surfaceflinger     class main 于是就能夠通過(guò)main名稱遍歷到所有的Service，將其啟動(dòng)。 do_class_start調(diào)用：        init.rc中 on boot/action class_start core/執(zhí)行command 對(duì)應(yīng) do_class_start      class_sta

33、rt main 3.2、ServiceManager啟動(dòng) 在init.rc腳本文件中ServiceManager的描述： ServiceManager用來(lái)管理系統(tǒng)中所有的binder service，不管是本地的c+實(shí)現(xiàn)的還是java語(yǔ)言實(shí)現(xiàn)的都需要這個(gè)進(jìn)程來(lái)統(tǒng)一管理，最主要的管理就是，注冊(cè)添加服務(wù)，獲取服務(wù)。所有的Service使用前都必須先在servicemanager中進(jìn)行注冊(cè)。 do_find_service( ) do_add_service( ) svcmgr_handler( ) 代碼位置：frameworksbasecmdsservicemanagerService_manag

34、er.c3.3、Zygote進(jìn)程的啟動(dòng)Zygote這個(gè)進(jìn)程是非常重要的一個(gè)進(jìn)程，Zygote進(jìn)程的建立是真正的Android運(yùn)行空間，初始化建立的Service都是Navtive service. （1） 在.rc腳本文件中zygote的描述： 參數(shù)：-zygote -start-system-server上面的參數(shù)在這里就會(huì)用上，決定是否要啟動(dòng)和啟動(dòng)那些進(jìn)程。 代碼位置：frameworks/base/cmds/app_process/app_main.cpp（2）接著到了AndroidRuntime類中：代碼位置：frameworksbasecorejniAndroidRuntime.cp

35、p/ start the virtual machine Java在虛擬機(jī)中運(yùn)行的/向剛剛新建的虛擬機(jī)注冊(cè)JNI本地接口/ jni 調(diào)用 java 方法，獲取對(duì)應(yīng)類的靜態(tài)main方法/ jni調(diào)用 java方法，調(diào)用到ZygoteInit類的main函數(shù)到了ZygoteInit.java中的靜態(tài)main函數(shù)中，從C+ JAVA （3）ZygoteInit真正Zygote進(jìn)程: 代碼位置：frameworksbasecorejavacomandroidinternalosZygoteInit.java/Registers a server socket for zygote command co

36、nnectionsZygote就建立好了，利用Socket通訊，接收請(qǐng)求，F(xiàn)ork應(yīng)用程序進(jìn)程，進(jìn)入Zygote進(jìn)程服務(wù)框架中。 3.4、SystemServer啟動(dòng)（1）在Zygote進(jìn)程進(jìn)入循環(huán)之前，調(diào)用了startSystemServer( ); （2）RuntimeInit中：代碼位置：frameworksbasecorejavacomandroidinternalosRuntimeInit.javaprivate static void applicationInit(int targetSdkVersion, String argv)invokeStaticMain(args.startClass, args.startArg