Tina_Linux啟動(dòng)優(yōu)化開發(fā)指南

1 概述

編寫目的: 介紹TinaLinux下啟動(dòng)速度優(yōu)化使用方法。

2 啟動(dòng)速度優(yōu)化簡介

啟動(dòng)速度是嵌入式產(chǎn)品一個(gè)重要的性能指標(biāo)，更快的啟動(dòng)速度會(huì)讓客戶有更好的使用體驗(yàn)，在某

些方面還會(huì)節(jié)省能耗，因?yàn)榭梢灾苯雨P(guān)機(jī)而不需要休眠。

啟動(dòng)速度優(yōu)化可提升產(chǎn)品的競(jìng)爭力。對(duì)于某些系統(tǒng)來說，啟動(dòng)速度是硬性要求。

2.1 啟動(dòng)流程

TinaLinux系統(tǒng)當(dāng)前的啟動(dòng)流程如下：

brom --> boot0 --> (monitor/secure os) --> uboot --> rootfs --> app

brom固化在IC內(nèi)部，芯片出廠后就無法更改。

后續(xù)將從boot0開始分階段介紹啟動(dòng)優(yōu)化的方法。

對(duì)于某些方案，會(huì)存在monitor或secure os，這兩者耗時(shí)很短，本文略過。

下文涉及到一些配置文件，提前在此說明。

env配置文件路徑：

tina/device/config/chips//configs//env.cfg #優(yōu)先級(jí)高

tina/device/config/chips//configs//linux/env-.cfg #優(yōu)先級(jí)中

tina/device/config/chips//configs/default/env.cfg #優(yōu)先級(jí)低

sys_config.fex路徑：

tina/device/config/chips//configs//sys_config.fex

uboot-board.dts路徑：

tina/device/config/chips//configs//uboot-board.dts

! 警告：如 果 存 在 uboot-board.dts ， uboot 會(huì) 使 用 uboot-board.dts 中 配 置； 如 果 不 存 在uboot-board.dts ， uboot 會(huì)使用 sys_config.fex 中的配置。(AW1886/V853 使用了 uboot-board.dts ）

2.2 測(cè)量方法

2.2.1 printk time

打開kernel配置，使能如下選項(xiàng)：

kernel hacking --->

[*] Show timing information on printks

linux4.9

kernel hacking --->

printk and dmesg options --->

[*] Show timing information on printks

將會(huì)在內(nèi)核的log前加入時(shí)間戳。

注：此方法主要用來測(cè)量內(nèi)核啟動(dòng)過程中各個(gè)階段的耗時(shí)。

2.2.2 initcall_debug

修改env文件，在kernel的cmdline中加入參數(shù)，

# 增加initcall_debug變量

initcall_debug=1

?

#將initcall_debug=${initcall_debug}加入setargs_xxx中，如setargs_nand，setargs_mmc，setargs_nor，setatgs_nand_ubi等，

setargs_nand=setenv bootargs console=${console} earlyprintk=${earlyprintk} root=${nand_root} initcall_debug=${initcall_debug} init=${init}

開啟之后，啟動(dòng)中會(huì)打印每個(gè)initcall函數(shù)調(diào)用及其耗時(shí)。

注：此方法主要用來測(cè)量內(nèi)核initcall的耗時(shí)。

一般需同時(shí)配置上內(nèi)核符號(hào)表，即kallsyms選項(xiàng)，以打印函數(shù)名。

2.2.3 bootgraph.

在內(nèi)核源碼中自帶了一個(gè)工具(scripts/bootgraph.pl)可用于分析啟動(dòng)時(shí)間,需要把log_buff加 大，要不然會(huì)丟失最早的啟動(dòng)信息：

make kernel_menuconfig

General setup --->

(17) Kernel log buffer size (16 => 64KB, 17 => 128KB)

Kernel hacking --->

printk and dmesg options --->

[*] Show timing information on printks

kernel編譯時(shí)需要包含CONFIG_PRINTK_TIME選項(xiàng)。

在kernel cmdline加上"initcall_debug=1"。

在系統(tǒng)啟動(dòng)完畢后執(zhí)行"dmesg | perl $(Kernel_DIR)/scripts/bootgraph.pl > output.svg"。

使用SVG瀏覽器（比如Inkscape，Gimp，F(xiàn)irefox等）來查看輸出文件output.svg。

注：此方法主要用來測(cè)量內(nèi)核啟動(dòng)過程中各個(gè)階段的耗時(shí)。

2.2.4 bootchart

bootchart是一個(gè)用于linux啟動(dòng)過程性能分析的開源軟件工具，在系統(tǒng)啟動(dòng)過程自動(dòng)收集CPU 占用率、進(jìn)程等信息，并以圖形方式顯示分析結(jié)果，可用作指導(dǎo)優(yōu)化系統(tǒng)啟動(dòng)過程。

修改kernel cmdline。修改env配置文件(路徑見上文說明)，將其中的init修改為"init=/ sbin/bootchartd"。

收集信息。bootchartd會(huì)從/proc/stat，/proc/diskstat，/proc/[pid]/stat中采集信息，經(jīng) 過處理后保存為bootchart.tgz文件。

轉(zhuǎn)換圖片。在PC上通過pybootchartgui.py工具將bootchart.tgz轉(zhuǎn)換為bootchart.png， 方便分析。

注：此方法主要用來測(cè)量掛載文件系統(tǒng)到主應(yīng)用程序啟動(dòng)過程中的耗時(shí)。

2.2.5 gpio +示波器.

在適當(dāng)?shù)牡胤郊尤氩僮鱣pio的代碼，通過示波器抓取波形得到各階段耗時(shí)。

注：此方法可用來測(cè)量整個(gè)啟動(dòng)中各階段的耗時(shí)。

2.2.6 grabserial.

Grabserial是Tim Bird用python寫的一個(gè)抓取串口的工具，這個(gè)工具能夠?yàn)槭盏降拿恳恍行?息添加上時(shí)間戳。可從如下路徑下載使用：https://github.com/tbird20d/grabserial

介紹文檔：http://elinux.org/Grabserial

常見的用法：

sudo grabserial -v -S -d /dev/ttyUSB0 -e 30 -t

如果要在某個(gè)字符串重置時(shí)間戳，可以使用-m參數(shù)：

sudo grabserial -v -S -d /dev/ttyUSB0 -e 30 -t -m "Starting kernel"

-v顯示參數(shù)等信息。

-s跳過對(duì)串口的檢查。

-d指定串口，如上述為指定/dev/ttyUSB0為操作的串口。

-e參數(shù)指定時(shí)間，如上述命令表示抓取30s的串口記錄。

-t表示加上時(shí)間戳。

-m匹配到指定字符串就重置時(shí)間戳的時(shí)間，也就是從 0 開始。

更多配置可以使用-h參數(shù)查看幫助。

注：此方法可用來測(cè)量整個(gè)啟動(dòng)中各階段的耗時(shí)。

2.3 優(yōu)化方法

注：本節(jié)提供一些優(yōu)化方法以供參考，并非所有都在Tina上集成，主要原因有：

優(yōu)化沒有止境。需要根據(jù)目標(biāo)來選擇優(yōu)化方法，綜合考慮優(yōu)化效果與優(yōu)化難度。

優(yōu)化需要具有針對(duì)性。由于各方案CPU個(gè)數(shù)及頻率、flash類型及大小、kernel/rootfs壓縮 類型與尺寸、所需功能、主應(yīng)用等的不同，需要針對(duì)性的進(jìn)行優(yōu)化。

2.3.1 boot0啟動(dòng)優(yōu)化

boot0運(yùn)行在SRAM，主要功能是對(duì)DRAM進(jìn)行初始化，并將uboot、monitor、secure-os 等加載至DRAM。

2.3.1.1 非安全啟動(dòng).

boot0可優(yōu)化的地方不多，可以做的是：

關(guān)閉串口輸出。

減少檢測(cè)按鍵和檢測(cè)串口的等待時(shí)間。

加載uboot的時(shí)候，不要先加載后搬運(yùn)，直接加載到uboot的運(yùn)行地址。

對(duì)于spinor的方案，還可以直接從boot0啟動(dòng)，只需要在boot0中加載好kernel和dtb， 不需要經(jīng)過uboot ，然后直接跳轉(zhuǎn)到kernel運(yùn)行，可節(jié)省一定的時(shí)間。如果采用boot0啟 動(dòng)OS，則boot0讀取數(shù)據(jù)量較大，其flash驅(qū)動(dòng)也需要進(jìn)行優(yōu)化，如提高時(shí)鐘，開啟雙線/四 線/DMA/Cache等。

2.3.1.2 安全啟動(dòng)

對(duì)于安全方案來說，boot0還會(huì)對(duì)uboot、monitor、secure-os等進(jìn)行簽名校驗(yàn)，因?yàn)樵趩?dòng) 時(shí)需要引導(dǎo)SecoreOS,需要做一次環(huán)境切換，CPU由安全狀態(tài)切換到非安全狀態(tài)運(yùn)行，所以對(duì) 于安全方案來說，不支持直接從boot0啟動(dòng)，然后加載dtb和kernel到內(nèi)存，然后直接啟動(dòng)內(nèi) 核，主要的優(yōu)化手段較少，可以做的是：

關(guān)閉串口打印。

減少檢測(cè)按鍵和檢測(cè)串口的等待時(shí)間。

加載uboot的時(shí)候，不要先加載后搬運(yùn)，直接加載到uboot的運(yùn)行地址。

2.3.2 uboot啟動(dòng)優(yōu)化

uboot主要功能是引導(dǎo)內(nèi)核、量產(chǎn)升級(jí)、電源管理、開機(jī)音樂/logo、fastboot刷機(jī)等。

2.3.2.1 完全去掉uboot

uboot的包含很多重要功能，通常會(huì)保留。某些情況可以去掉，直接從boot0加載內(nèi)核并啟動(dòng)， 可節(jié)省一些時(shí)間。

2.3.2.2 避免burnkey的影響

對(duì)于啟用了burnkey支持，且還沒使用DragonSN工具將key燒錄進(jìn)去的板子，每次啟動(dòng)到 uboot都會(huì)嘗試跟PC端工具交互產(chǎn)生如下log，帶來延時(shí)。

[1.334]usb burn from boot ... [1.400]usb prepare ok usb sof ok [1.662]usb probe ok [1.664]usb setup ok ... [4.698]do_burn_from_boot usb : have no handshake

如果產(chǎn)品不需要 burnkey，可將 uboot-board.dts 或 sys_config.fex 中的 [target] 下 burn_key設(shè)置為 0 。

或者使用DragonSN工具，燒錄一次key，并設(shè)置燒錄標(biāo)志，以使后續(xù)啟動(dòng)可跳過檢測(cè)。

2.3.2.3 提高CPU以及flash讀取頻率

可設(shè)置uboot-board.dts或sys_config.fex中的[target]下boot_clock來修改uboot運(yùn)行 時(shí)CPU頻率( 注：不能超過SPEC最大頻率 )。

對(duì)于spinor/spinand，使用較高的時(shí)鐘頻率（一般是100M），使用四線模式或者雙線模式（看 硬件是否支持），提高加載速度。

2.3.2.4 關(guān)閉串口輸出.

可將uboot-board.dts或sys_config.fex中的[platform]下debug_mode設(shè)置為 0 來關(guān)閉 uboot的串口輸出。

可將sys_config.fex中的[platform]下debug_mode設(shè)置為 0 來關(guān)閉boot0串口輸出。

配置此項(xiàng)后，如果還有少量輸出，有兩個(gè)可能的原因：

第一是這些輸出是在獲取debug_mode流程之前產(chǎn)生。

第二是因?yàn)樵创a中直接使用了puts而沒有使用printf。

對(duì)于這兩者情況，需要修改源碼來完全關(guān)閉串口輸出。

2.3.2.5 修改kernel加載位置

如果uboot將內(nèi)核加載到DRAM的地址與內(nèi)核中l(wèi)oad address不匹配，就需要將內(nèi)核移動(dòng)到 正確位置，這樣會(huì)浪費(fèi)一定的時(shí)間。因此，可以直接修改uboot加載內(nèi)核為正確的地址。

具體是修改env文件(路徑見上文)的boot_normal與boot_recovery變量。

需要根據(jù)不同的內(nèi)核鏡像格式來設(shè)置不同的值 。

假設(shè)kernel的load address為0x40008000。

如果使用的是uImage，也就是在kernel的鏡像前加了 64 字節(jié)，所以u(píng)boot應(yīng)該將kernel 加載到0x40008000 - 0x40 = 0x40007fc0。

#uImage/raw boot_normal=sunxi_flash read 40007fc0 ${boot_partition};bootm 40007fc boot_recovery=sunxi_flash read 40007fc0 recovery;bootm 40007fc

如果使用的是boot.img，即android的kernel格式，其頭部大小為0x800，所以u(píng)boot應(yīng)該將kernel加載到0x40008000 - 0x800 = 40007800。

#boot.img/raw boot_normal=sunxi_flash read 40007800 ${boot_partition};bootm 40007800 boot_recovery=sunxi_flash read 40007800 recovery;bootm 40007800

如果uboot加載kernel地址與load address不匹配，uboot過程中串口輸出可能會(huì)有：

Loading Kernel Image ... OK

如果是匹配的，uboot過程中串口輸出可能會(huì)有：

XIP Kernel Image ... OK

2.3.2.6 修改kernel加載大小

最新代碼會(huì)根據(jù)uImage/boot.img的頭部信息，只讀取必要的大小，可忽略此優(yōu)化項(xiàng)。

對(duì)于舊代碼，uboot在加載內(nèi)核的時(shí)候，有些情況會(huì)直接將整個(gè)分區(qū)讀取出來,uboot-2018會(huì)自 讀取kernel鏡像的大小。

就是說假如內(nèi)核只有2M，而分區(qū)分了4M的話，uboot就會(huì)讀取4M。這種情況下，可以將分 區(qū)大小設(shè)置得剛好容納下內(nèi)核，這樣可避免uboot在加載內(nèi)核的時(shí)候浪費(fèi)時(shí)間。

nor方案修改sys_partiton_nor.fex的boot分區(qū)大小

nand/emmc可修改sys_partition.fex中boot分區(qū)的大小。

uboot具體讀出多少，通常會(huì)有l(wèi)og信息，可同真正內(nèi)核鏡像的size進(jìn)行比較。

2.3.2.7 關(guān)閉kernel校驗(yàn)

uboot加載了內(nèi)核以后，默認(rèn)會(huì)對(duì)內(nèi)核進(jìn)行校驗(yàn)，可以在串口輸出中看到：

Verifying Checksum ... OK

如果不想校驗(yàn)可以去掉，目前的情況是可以減少幾十毫秒(不同平臺(tái)，不同內(nèi)核大小，時(shí)間不同) 的啟動(dòng)時(shí)間。

具體修改env配置文件（路徑見上文），新增一行"verify=no"。

2.3.2.8 uboot重定位

目前的啟動(dòng)過程中，uboot在執(zhí)行過程中會(huì)進(jìn)行一次重定位，可以在串口中打印出這個(gè)值，然后 修改uboot的加載地址使得boot0將uboot加載進(jìn)DRAM的時(shí)候就直接加載到這個(gè)地址。

對(duì)于uboot-2014版本的位置為tina/lichee/brandy/u-boot/include/configs/suniwp.h 中的

c #define CONFIG_SYS_TEXT_BASE=0x

對(duì)于uboot-2018在對(duì)應(yīng)的configs/suniwp*_defconfig文件中

c CONFIG_SYS_TEXT_BASE=0x

但這個(gè)方法有個(gè)弊端，如果后續(xù)修改了uboot的代碼，則可能需要重新設(shè)置。

目前這個(gè)操作耗時(shí)很少（某平臺(tái)測(cè)得十幾毫秒），不必要的話不建議做這個(gè)修改。

2.3.2.9 裁剪uboot.

即使流程沒有簡化，uboot體積的減小也可減少加載uboot的時(shí)間。

依據(jù)具體情況，可對(duì)uboot不需要的功能的模塊進(jìn)行裁剪，避免了啟動(dòng)中執(zhí)行不必要的流程，可 減少uboot加載時(shí)間。

2.3.2.10開啟logo及音樂.

可嘗試在uboot中開啟開機(jī)logo/音樂，盡快播出第一幀/聲，提升用戶體驗(yàn)。

此操作會(huì)延緩到達(dá)OS/APP的時(shí)間，但如果產(chǎn)品定義/用戶體驗(yàn)是以第一幀/聲為準(zhǔn)的話，則有較 大價(jià)值。

2.3.3 kernel啟動(dòng)優(yōu)化.

通常來說，內(nèi)核啟動(dòng)耗時(shí)較多，需要更深入的優(yōu)化。

2.3.3.1 kernel壓縮方式.

比較不同壓縮方式的啟動(dòng)時(shí)間和flash占用情況，選擇一種符合實(shí)際情況的。

此處給出某次測(cè)試結(jié)果供參考。實(shí)際優(yōu)化的時(shí)候，需要重新測(cè)試，根據(jù)實(shí)際情況選擇。

2.3.3.2 加載位置

內(nèi)核鏡像可以由kernel自解壓，也有uboot進(jìn)行解壓的情況。

對(duì)于kernel自解壓的情況，如果壓縮過的kernel與解壓后的kernel地址沖突，則會(huì)先把自己 復(fù)制到安全的地方，然后再解壓，防止自我覆蓋。這就需要耗費(fèi)復(fù)制的時(shí)間。

比如對(duì)于運(yùn)行地址為0x40008000的內(nèi)核來說，bootloader可以將其加載到0x41008000， 當(dāng)然其他位置也可以。

2.3.3.3 內(nèi)核裁剪

裁剪內(nèi)核，帶來的加速是兩個(gè)方面的。一是體積變小，加載解壓耗時(shí)減少；二是內(nèi)核啟動(dòng)時(shí)初始

化內(nèi)容變少。

裁剪要根據(jù)產(chǎn)品的實(shí)際情況來，將不需要的功能及模塊都去掉。

具體是執(zhí)行"make kernel_menuconfig"，關(guān)閉不需要的選項(xiàng)。可參考《TinaLinux_系統(tǒng)裁剪開發(fā)指 南.pdf》。

2.3.3.4 預(yù)設(shè)置lpj數(shù)值

LPJ也就是loops_per_jiffy，每次啟動(dòng)都會(huì)計(jì)算一次，但如果沒有做修改的話，這個(gè)值每次啟動(dòng) 算出來都是一樣的，可以直接提供數(shù)值跳過計(jì)算。

如下log所示，有skipped，lpj由timer計(jì)算得來，不需要再校準(zhǔn)calibrate了。

[ 0.019918] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)

如果沒有skipped，則可以在cmdline中添加lpj=XXX進(jìn)行預(yù)設(shè)。

2.3.3.5 initcall優(yōu)化

在cmdline中設(shè)置initcall_debug=1，即可打印跟蹤所有內(nèi)核初始化過程中調(diào)用initcall的順 序以及耗時(shí)。

具體修改env配置文件（路徑見上文），新增一行"initcall_debug=1"，并在"setargs_*"后加入" initcall_debug=${initcall_debug}"，如下所示。

setargs_nand=setenv bootargs console=${console} console=tty0 root=${nand_root} init=${init} loglevel=${loglevel} partitions=${partitions} initcall_debug=${initcall_debug}

加入后，內(nèi)核啟動(dòng)時(shí)就會(huì)有類似如下的打印，對(duì)于耗時(shí)較多的initcall，可進(jìn)行深入優(yōu)化。

[ 0.021772] initcall sunxi_pinctrl_init+0x0/0x44 returned 0 after 9765 usecs [ 0.067694] initcall param_sysfs_init+0x0/0x198 returned 0 after 29296 usecs [ 0.070240] initcall genhd_device_init+0x0/0x88 returned 0 after 9765 usecs [ 0.080405] initcall init_scsi+0x0/0x90 returned 0 after 9765 usecs [ 0.090384] initcall mmc_init+0x0/0x84 returned 0 after 9765 usecs

2.3.3.6 內(nèi)核initcall module并行

內(nèi)核initcall有很多級(jí)別，其中啟動(dòng)中最耗時(shí)的就是各module的initcall，針對(duì)多核方案，可 以考慮將module initcall并行執(zhí)行來節(jié)省時(shí)間。

目前內(nèi)核do_initcalls是一個(gè)一個(gè)按照順序來執(zhí)行，可以修改成新建內(nèi)核線程來執(zhí)行。

注：當(dāng)前Tina還未加入該優(yōu)化。

2.3.3.7 減少pty/tty個(gè)數(shù)

加入initcall打印之后，部分平臺(tái)發(fā)現(xiàn)pty/tty init耗時(shí)很多，可減少個(gè)數(shù)來縮短init時(shí)間。

initcall pty_init+0x0/0x3c4 returned 0 after 239627 usecs initcall chr_dev_init+0x0/0xdc returned 0 after 36581 usecs

2.3.3.8 內(nèi)核module.

需要考慮啟動(dòng)速度的界定，對(duì)于內(nèi)核module的優(yōu)化主要有兩點(diǎn)：

對(duì)于必須要加載的模塊，直接編譯進(jìn)內(nèi)核

對(duì)于不急需的功能，可以編譯成模塊。

比如某個(gè)應(yīng)用，會(huì)開啟主界面聯(lián)網(wǎng)，啟動(dòng)速度以出現(xiàn)主界面為準(zhǔn)，那么可以考慮將disp編入內(nèi) 核，wifi編譯成模塊，后續(xù)需要時(shí)再動(dòng)態(tài)加載。

2.3.3.9 Deferred Initcalls

介紹頁面及patch：http://elinux.org/Deferred_Initcalls

打上這個(gè)patch之后，可以標(biāo)記一些initcall為Deferred_Initcall。這些被標(biāo)記的初始化函 數(shù)，在系統(tǒng)啟動(dòng)的時(shí)候不會(huì)被調(diào)用

進(jìn)入文件系統(tǒng)后，在合適的時(shí)間，比如啟動(dòng)主應(yīng)用之后，再通過文件系統(tǒng)接口，啟動(dòng)這些推遲了 的調(diào)用，徹底完成初始化。

2.3.4 rootfs啟動(dòng)優(yōu)化

rootfs啟動(dòng)優(yōu)化主要是優(yōu)化rootfs的掛載到init進(jìn)程執(zhí)行。

2.3.4.1 initramfs

initramfs是一個(gè)內(nèi)存文件系統(tǒng)，會(huì)占用較多DRAM。

部分產(chǎn)品可能會(huì)用到initramfs來過渡到rootfs，其優(yōu)化思路大體與rootfs類似。可參考本節(jié)后 續(xù)的優(yōu)化方案。

2.3.4.2 rootfs類型以及壓縮.

存儲(chǔ)介質(zhì)、文件系統(tǒng)類型，壓縮方式對(duì)rootfs掛載有很大影響。

此處給出某次測(cè)試結(jié)果供參考。實(shí)際優(yōu)化的時(shí)候，需要重新測(cè)試，根據(jù)實(shí)際情況選擇。

2.3.4.3 rootfs裁剪

文件系統(tǒng)越小，加載速度越快。裁剪的主要思路是：刪換壓，即刪除沒有用到的，用小的換大

的，選擇合適的壓縮方式。

2.3.4.4 指定文件系統(tǒng)類型

內(nèi)核在掛載rootfs時(shí)，會(huì)有一個(gè)try文件系統(tǒng)類型的過程。可以在cmdline直接指定，節(jié)省時(shí) 間。

具體是在cmdline中添加"rootfstype="，其中type為文件系統(tǒng)類型，如ext4、squashfs 等。

2.3.4.5 靜態(tài)創(chuàng)建dev節(jié)點(diǎn).

對(duì)于dev下面的節(jié)點(diǎn)，事先根據(jù)實(shí)際情況創(chuàng)建好，而不是在系統(tǒng)啟動(dòng)后動(dòng)態(tài)生成，理論上也可以 節(jié)省一定的時(shí)間。

2.3.4.6 rootfs拆分

可以將rootfs拆分成兩個(gè)部分，一個(gè)小的文件系統(tǒng)先掛載執(zhí)行，大的文件系統(tǒng)根據(jù)需要?jiǎng)討B(tài)掛 載。

2.3.5 主應(yīng)用程序啟動(dòng)優(yōu)化.

主應(yīng)用程序主要是由客戶開發(fā)，因此主導(dǎo)優(yōu)化的還是客戶，這里提一些優(yōu)化措施：

提升運(yùn)行順序。將應(yīng)用程序放在init很前面執(zhí)行。

動(dòng)態(tài)/靜態(tài)鏈接。

編譯選項(xiàng)。

暫時(shí)不使用的庫采用dlopen方式。

應(yīng)用程序拆分。

3 Tina啟動(dòng)速度優(yōu)化

Tina中啟動(dòng)優(yōu)化主要依靠宏CONFIG_BOOT_TIME_OPTIMIZATION來完成，該宏會(huì)進(jìn)行如 下工作：

調(diào)整Linux內(nèi)核鏡像的壓縮方式，調(diào)整rootfs的壓縮方式。具體如何調(diào)整需要依據(jù)具體方案進(jìn) 行預(yù)先設(shè)定。

使boot0、uboot、kernel的打印不會(huì)輸出到控制臺(tái)。具體是在scripts/pack_img.sh腳本 中完成。

uboot加載內(nèi)核時(shí)不進(jìn)行校驗(yàn)。具體是在scripts/pack_img.sh腳本中完成。

設(shè)置內(nèi)核命令行參數(shù)rootfstype，某些情況下會(huì)加快根文件系統(tǒng)的加載。具體是在scripts/- pack_img.sh腳本中完成。

部分方案會(huì)調(diào)整kernel鏡像的加載地址。具體是在scripts/pack_img.sh腳本中完成。

注：通過該宏預(yù)計(jì)可達(dá)到70%左右的優(yōu)化效果，如還需優(yōu)化，可參考第二章的內(nèi)容。

3.1 開啟Tina啟動(dòng)速度優(yōu)化.

在tina根目錄下執(zhí)行make menuconfig使能CONFIG_BOOT_TIME_OPTIMIZATION， 具體如下所示

Tina Configuration └─> Target Images └─>[*] kernel compression mode setting ---- └─>Compression (Gzip) ---> └─> ( ) Gzip ( ) LZMA ( ) XZ (X) LZO └─>[*] Boot Time Optimization

注：如果看不到該選項(xiàng)，使用？鍵搜索，會(huì)發(fā)現(xiàn)此項(xiàng)有一些依賴選項(xiàng)，使能依賴選項(xiàng)即可看到

Boot Time Optimization

3.2 實(shí)驗(yàn)結(jié)果

在某norflash方案上開啟CONFIG_BOOT_TIME_OPTIMIZATION后，啟動(dòng)速度提升效果 如下：

Linux內(nèi)核鏡像壓縮方式從GZIP換成LZO，優(yōu)化> 0.2s。

rootfs從squashfs XZ壓縮換成squashfs GZIP壓縮，優(yōu)化> 0.15s。

屏蔽boot0、uboot、kernel啟動(dòng)階段控制臺(tái)打印，優(yōu)化> 2s。

取消內(nèi)核加載時(shí)的校驗(yàn)，優(yōu)化0.3～0.4s。

注：對(duì)于不同的方案，由于CPU運(yùn)算速度、存儲(chǔ)器類型、內(nèi)核壓縮及尺寸、根文件系統(tǒng)類型及尺

寸、主應(yīng)用等的不同，優(yōu)化結(jié)果會(huì)有一定差異，請(qǐng)以實(shí)際優(yōu)化結(jié)果為準(zhǔn)。