背景

之前做過(guò)一次uboot的升級(jí)，當(dāng)時(shí)留下了一些記錄，本文摘錄其中比較有意思的兩個(gè)問(wèn)題。

啟動(dòng)失敗問(wèn)題

問(wèn)題簡(jiǎn)述

uboot代碼中用到了一個(gè)庫(kù)，考慮到庫(kù)本身跟uboot版本沒(méi)什么關(guān)系，就直接把舊的庫(kù)文件拷貝過(guò)來(lái)使用。結(jié)果編譯鏈接是沒(méi)問(wèn)題，啟動(dòng)卻會(huì)卡住。

消失的打印

為了明確卡住的位置，就去修改了庫(kù)的源碼，添加一些打?。ù藭r(shí)還是在舊版本uboot下編譯的），結(jié)果發(fā)現(xiàn)卡住的位置或隨著添加打印的變化而變化，且有些打印語(yǔ)句，添加后未打印出來(lái)。 我決定先從這些神秘消失的打印入手。 分析下uboot中的printf實(shí)現(xiàn)，最底層就是寫寄存器，是一個(gè)同步的函數(shù)，也沒(méi)什么可疑的地方。 為了確認(rèn)打印不出來(lái)的時(shí)候，到底有沒(méi)有調(diào)用到printf，我決定給printf增加一個(gè)計(jì)數(shù)器，在gd結(jié)構(gòu)體中，增加一個(gè)printf_count字段，初始化為0，每次打印時(shí)執(zhí)行printf_count++并打印出值。 設(shè)計(jì)這個(gè)試驗(yàn)，本意是確認(rèn)未打印出來(lái)時(shí)是否確實(shí)也調(diào)用到了printf，但卻有了別的發(fā)現(xiàn)，實(shí)驗(yàn)結(jié)果中printf_count值會(huì)異常變化，不是按打印順序遞增，而是會(huì)突變成很大的異常值。 printf_count是gd結(jié)構(gòu)體的成員，那就是gd的問(wèn)題了。進(jìn)一步將uboot全局結(jié)構(gòu)體gd的地址打印出來(lái)。確認(rèn)了原因是gd結(jié)構(gòu)體的指針變化了。 這也可以解釋部分打印消失的現(xiàn)象，原因是我們?cè)趃d中有另一個(gè)字段，用于控制打印等級(jí)。當(dāng)gd被改動(dòng)了，printf就可能解析出錯(cuò)，誤以為打印等級(jí)為0而提前返回。

gd的實(shí)現(xiàn)

那么好端端的，gd為什么會(huì)被改了呢？這就要先看看gd到底是怎么實(shí)現(xiàn)的了。 uboot中維護(hù)了一個(gè)全局的結(jié)構(gòu)體gd。在代碼中加入

DECLARE_GLOBAL_DATA_PTR; 即可使用gd指針訪問(wèn)這個(gè)全局結(jié)構(gòu)體，許多地方都會(huì)借助gd來(lái)保存?zhèn)鬟f信息。 進(jìn)一步看看這個(gè)宏的定義舊版本uboot: #defineDECLARE_GLOBAL_DATA_PTRregistervolatilegd_t*gdasm("r8") 新版本uboot: #defineDECLARE_GLOBAL_DATA_PTRregistervolatilegd_t*gdasm("r9") 居然不一樣，一個(gè)是將gd的值放到r8寄存器，一個(gè)是放在r9寄存器。 那么就可以猜測(cè)到，庫(kù)是在舊版本uboot中編譯出來(lái)的，可能使用了r9，那么放到新版本uboot中去，就會(huì)破壞r9寄存器中保存的gd值，導(dǎo)致一系列依賴gd的代碼不能正常工作。

驗(yàn)證改動(dòng)

為了求證，將庫(kù)反匯編出來(lái)，發(fā)現(xiàn)確實(shí)避開(kāi)了r8寄存器，但使用了r9寄存器。 說(shuō)明uboot在指定gd寄存器的同時(shí)，還有某種方法讓其他代碼不使用這個(gè)寄存器。 那是不是把舊uboot中的這個(gè)r8改成r9，重新編譯庫(kù)就可以了呢？試一下，還是不行。 那么禁止其他代碼使用r8寄存器肯定就是通過(guò)別的方式實(shí)現(xiàn)的了。簡(jiǎn)單粗暴地在舊版本uboot下搜索r8，去掉.c .h等類型后，很容易發(fā)現(xiàn)了

./arch/arm/cpu/armv7/config.mkPLATFORM_RELFLAGS+=-fno-common-ffixed-r8-msoft-floa 將-ffixed-r8修改為-ffixed-r9，重新編譯出庫(kù)，這回就可以正常工作了，打印正常，啟動(dòng)正常。反匯編出來(lái)也可以看到，新編譯出來(lái)的庫(kù)用了r8沒(méi)有用r9。 當(dāng)然更好的改法，是直接在新版本的uboot中編譯，這是最可靠的。

追本溯源

話說(shuō)回來(lái)，為什么兩個(gè)版本的uboot，會(huì)使用不同的寄存器呢？難道有什么坑？ 這就得去翻一下git記錄了。

commitfe1378a961e508b31b1f29a2bb08ba1dac063155 Author:JeroenHofstee Date:SatSep2114412013+0200 ARM:user9forgd TobemoreEABIcompliantandasapreparationforbuilding withclang,usetheplatform-specificr9registerforgd insteadofr8. note:TheFIQisnotupdatedsinceitisnotusedinu-boot, andunderdiscussionforthetimebeing. Thefollowingcheckpatchwarningisignored: WARNING:Useofvolatileisusuallywrong:see Documentation/volatile-considered-harmful.txt Signed-off-by:JeroenHofstee cc:AlbertARIBAUD 從git記錄中，也可以確認(rèn)完整地將r8切換到r9，都需要做哪些修改diff--gita/arch/arm/config.mkb/arch/arm/config.mk index16c2e3d1e0..d0cf43ff41100644 ---a/arch/arm/config.mk +++b/arch/arm/config.mk @@-17,7+17,7@@endif LDFLAGS_FINAL+=--gc-sections PLATFORM_RELFLAGS+=-ffunction-sections-fdata-sections --fno-common-ffixed-r8-msoft-float +-fno-common-ffixed-r9-msoft-float #SupportgenericboardonARM __HAVE_ARCH_GENERIC_BOARD:=y diff--gita/arch/arm/cpu/armv7/lowlevel_init.Sb/arch/arm/cpu/armv7/lowlevel_init.S index82b2b86520..69e3053a42100644 ---a/arch/arm/cpu/armv7/lowlevel_init.S +++b/arch/arm/cpu/armv7/lowlevel_init.S @@-22,11+22,11@@ENTRY(lowlevel_init) ldrsp,=CONFIG_SYS_INIT_SP_ADDR bicsp,sp,#7/*8-bytealignmentforABIcompliance*/ #ifdefCONFIG_SPL_BUILD -ldrr8,=gdata +ldrr9,=gdata #else subsp,#GD_SIZE bicsp,sp,#7 -movr8,sp +movr9,sp #endif /* *Savetheoldlr(passedinip)andthecurrentlrtostack diff--gita/arch/arm/include/asm/global_data.hb/arch/arm/include/asm/global_data.h index79a9597419..e126436093100644 ---a/arch/arm/include/asm/global_data.h +++b/arch/arm/include/asm/global_data.h @@-47,6+47,6@@structarch_global_data{ #include -#defineDECLARE_GLOBAL_DATA_PTRregistervolatilegd_t*gdasm("r8") +#defineDECLARE_GLOBAL_DATA_PTRregistervolatilegd_t*gdasm("r9") #endif/*__ASM_GBL_DATA_H*/ diff--gita/arch/arm/lib/crt0.Sb/arch/arm/lib/crt0.S index960d12e732..ac54b9359a100644 ---a/arch/arm/lib/crt0.S +++b/arch/arm/lib/crt0.S @@-69,7+69,7@@ENTRY(_main) bicsp,sp,#7/*8-bytealignmentforABIcompliance*/ subsp,#GD_SIZE/*allocateoneGDaboveSP*/ bicsp,sp,#7/*8-bytealignmentforABIcompliance*/ -movr8,sp/*GDisaboveSP*/ +movr9,sp/*GDisaboveSP*/ movr0,#0 blboard_init_f @@-81,15+81,15@@ENTRY(_main) *'here'butrelocated. */ -ldrsp,[r8,#GD_START_ADDR_SP]/*sp=gd->start_addr_sp*/ +ldrsp,[r9,#GD_START_ADDR_SP]/*sp=gd->start_addr_sp*/ bicsp,sp,#7/*8-bytealignmentforABIcompliance*/ -ldrr8,[r8,#GD_BD]/*r8=gd->bd*/ -subr8,r8,#GD_SIZE/*newGDisbelowbd*/ +ldrr9,[r9,#GD_BD]/*r9=gd->bd*/ +subr9,r9,#GD_SIZE/*newGDisbelowbd*/ adrlr,here -ldrr0,[r8,#GD_RELOC_OFF]/*r0=gd->reloc_off*/ +ldrr0,[r9,#GD_RELOC_OFF]/*r0=gd->reloc_off*/ addlr,lr,r0 -ldrr0,[r8,#GD_RELOCADDR]/*r0=gd->relocaddr*/ +ldrr0,[r9,#GD_RELOCADDR]/*r0=gd->relocaddr*/ brelocate_code here: @@-111,8+111,8@@clbss_l:cmpr0,r1/*whilenotatendofBSS*/ blred_led_on /*callboard_init_r(gd_t*id,ulongdest_addr)*/ -movr0,r8/*gd_t*/ -ldrr1,[r8,#GD_RELOCADDR]/*dest_addr*/ +movr0,r9/*gd_t*/ +ldrr1,[r9,#GD_RELOCADDR]/*dest_addr*/ /*callboard_init_r*/ ldrpc,=board_init_r/*thisisauto-relocated!*/

啟動(dòng)慢問(wèn)題

問(wèn)題簡(jiǎn)述

填了幾個(gè)坑之后，新的uboot可以啟動(dòng)到內(nèi)核了，但發(fā)現(xiàn)啟動(dòng)速度非常慢，內(nèi)核啟動(dòng)速度慢了接近10倍！明明是同一個(gè)內(nèi)核，為什么差異這么大。

排查寄存器

初步排查了下設(shè)備樹(shù)配置，以及uboot跳轉(zhuǎn)內(nèi)核前的一些關(guān)鍵寄存器，確實(shí)在兩個(gè)版本的uboot中有所不同，但具體去看這些不同，發(fā)現(xiàn)都不會(huì)影響速度，將一些驅(qū)動(dòng)對(duì)齊之后寄存器差異基本就消失了。

差異的分界

那再細(xì)看，kernel的速度有差異，uboot呢？在哪個(gè)時(shí)間點(diǎn)之后，速度開(kāi)始產(chǎn)生差異？ 嘗試在兩個(gè)版本的uboot中插入一些操作，對(duì)比時(shí)間戳，發(fā)現(xiàn)兩個(gè)uboot在某個(gè)節(jié)點(diǎn)之后的速度確實(shí)有區(qū)別。 進(jìn)一步排查，原來(lái)是在打開(kāi)cache操作之后，舊uboot的速度就會(huì)比新uboot快。嘗試將舊uboot的cache關(guān)掉，則二者基本一致。嘗試將舊uboot操作cache的代碼，移植到新uboot，未發(fā)生改變。 此時(shí)可確認(rèn)新uboot的開(kāi)cache有問(wèn)題。但覺(jué)得這個(gè)跟kernel啟動(dòng)慢沒(méi)關(guān)系。因?yàn)閡boot進(jìn)入kernel之前都會(huì)關(guān)cache，由kernel自己去重新打開(kāi)。 也就是不管是用哪份uboot，也不管uboot中是否開(kāi)了cache，對(duì)kernel階段都應(yīng)該沒(méi)有影響才對(duì)。 于是記錄下來(lái)uboot的這個(gè)問(wèn)題，待后續(xù)修復(fù)。先繼續(xù)找kernel啟動(dòng)慢的原因。（注：現(xiàn)在看來(lái)當(dāng)時(shí)的做法是有問(wèn)題的，這里的異常這么明顯，應(yīng)該設(shè)法追蹤下去找出原因才對(duì)）

鎖定uboot

uboot的嫌疑非常大，但還不能完全確認(rèn)，因?yàn)閡boot之前還有一級(jí)spl。是否會(huì)是spl的問(wèn)題呢？ 嘗試改用新spl+舊uboot，啟動(dòng)速度正常。而新spl+新uboot的啟動(dòng)速度則很慢，其他因素都不變，說(shuō)明問(wèn)題確實(shí)出在uboot階段。

多做or少做

當(dāng)時(shí)到這一步就卡住了，直接比較兩份uboot的代碼不太現(xiàn)實(shí)，差異太大了。 后來(lái)我就給自己提了個(gè)問(wèn)題，到底新uboot是多做了某件事情，還是少做了某件事情？ 換個(gè)說(shuō)法，目前已知

spl-->舊uboot-->kernel(速度快) spl-->新uboot-->kernel(速度快) 但到底是以下的情況A還是情況B呢？A:spl（速度慢）-->舊uboot(做了某個(gè)會(huì)提升速度的操作)-->kernel(速度快) spl（速度慢）-->新uboot(少做了某個(gè)會(huì)提升速度的操作)-->kernel(速度慢) B:spl（速度快）-->舊uboot(沒(méi)做特殊操作)-->kernel(速度快) spl（速度快）-->新uboot(多做了某個(gè)會(huì)限制速度的操作)-->kernel(速度慢) 為了驗(yàn)證，我決定讓spl直接啟動(dòng)內(nèi)核，看看內(nèi)核到底是快是慢。 支持過(guò)程碰到了一些小問(wèn)題 1.spl沒(méi)有能力加載這么大的kernel 解決：此時(shí)不需要kernel能完全啟動(dòng)，只需要能加載啟動(dòng)一段，足以體現(xiàn)出啟動(dòng)速度是否正常即可，于是裁剪出一個(gè)非常小kernel來(lái)輔助實(shí)驗(yàn)。 2.kernel需要dtb 解決：內(nèi)核有一個(gè)CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE選項(xiàng)。選上重新編譯。編譯后再用dd將kernel和dtb拼接到一起，作為新的kernel。這樣，spl就只需要加載一個(gè)文件并跳轉(zhuǎn)過(guò)去即可。 試驗(yàn)結(jié)果，spl啟動(dòng)的kernel和使用新uboot啟動(dòng)的kernel速度一致，均比舊uboot啟動(dòng)的kernel慢。 說(shuō)明，舊uboot中做了某個(gè)關(guān)鍵操作，而新uboot沒(méi)做。

找出關(guān)鍵操作

那接下來(lái)的任務(wù)就是，找出舊uboot中的這個(gè)關(guān)鍵操作了。 怎么找呢？有了上一步的成果，我們可以使用以下方法來(lái)排查

spl加載kernel和舊uboot

spl跳轉(zhuǎn)到舊uboot，此時(shí)kernel其實(shí)已經(jīng)在dram中準(zhǔn)備好了，隨時(shí)可以啟動(dòng)

在舊uboot的啟動(dòng)流程各個(gè)階段，嘗試直接跳轉(zhuǎn)到kernel，觀察啟動(dòng)速度

如果在舊uboot的A點(diǎn)跳轉(zhuǎn)kernel啟動(dòng)慢，B點(diǎn)跳轉(zhuǎn)啟動(dòng)快，則說(shuō)明關(guān)鍵操作位于AB點(diǎn)之間。

方法有了，很快就鎖定到start.S，進(jìn)一步在start.S中揪出了這段代碼

#ifdefined(CONFIG_ARM_A7) @setSMPbit mrcp15,0,r0,c1,c0,1 orrr0,r0,#(1<<6) ????mcr????????p15,?0,?r0,?c1,?c0,?1 #endif 新uboot的start.S中沒(méi)有這段代碼，嘗試在新uboot的start.S中添加此操作，速度立馬恢復(fù)正常了。 再全局搜索下，原來(lái)這個(gè)新版本uboot中，套路是在board_init中進(jìn)行此項(xiàng)設(shè)置的，而這個(gè)平臺(tái)從舊版本移植過(guò)來(lái)，就沒(méi)有設(shè)置 SMP bit, 補(bǔ)上即可。

SMP bit是什么

SMP 是指對(duì)稱多處理器，看起來(lái)這個(gè) bit 會(huì)影響多核的 cache一致性，此處沒(méi)有再深入研究。 但可以知道，對(duì)于單處理器的情況，也需要設(shè)置這個(gè)bit才能正常使用cache。 貼下arm的圖和描述：

[6]SMP SignalsiftheCortex-A9processoristakingpartincoherencyornot. Inuniprocessorconfigurations,ifthisbitisset,thenInnerCacheableSharedistreatedasCacheable.Theresetvalueiszero. 搜下kernel的代碼，發(fā)現(xiàn)也是有地方調(diào)用了的。不過(guò)這個(gè)芯片是單核的，根本就沒(méi)配置CONFIG_SMP。#ifdefCONFIG_SMP ALT_SMP(mrcp15,0,r0,c1,c0,1) ALT_UP(movr0,#(1<

總結(jié)

整理出來(lái)一方面是記錄這兩個(gè)bug，另一方面也是想記錄下當(dāng)時(shí)的一些操作。 畢竟同樣的bug可能以后都不會(huì)碰到了，但解bug的方法和思路卻是可以積累復(fù)用的。