********************************LoongEmbedded********************************

作者：LoongEmbedded(kandi)

時間：2011.7.31

類別：WINCE bootloader開發(fā)

********************************LoongEmbedded********************************

?

備注：本文基于Real6410開發(fā)板，采用的是MLC型的NAND Flash K9G8G08，在此學習下載stepldr階段的鏡像文件block0img.nb0。

?

Windows CE的開發(fā)工具Platform Build編譯生成的Windows CE操作系統(tǒng)及Bootloader的鏡像文件主要由兩種格式類型——以.bin為文件名后綴的記錄型鏡像文件和以.nb0為后綴的原始型（raw）鏡像文件，前者以記錄（Record）為單位組織鏡像的數(shù)據(jù)，后者則是鏡像在嵌入式系統(tǒng)中運行時的二進制數(shù)據(jù)快照。

?

Windows CE鏡像文件在文件數(shù)據(jù)的起始位置都有一個7字節(jié)的特征碼（magic number）,它與鏡像文件的格式一一對應如下：

“N000FF\X0A”——BL_IMAGE_TYPE_MANIFEST

“X000FF\X0A”——BL_IMAGE_TYPE_MULTIXIP

“B000FF\X0A”——BL_IMAGE_TYPE_BIN

“S000FF\X0A”——BL_IMAGE_TYPE_SIGNED_BIN

“R000FF\X0A”——BL_IMAGE_TYPE_SIGNED_NB0

無特征碼——BL_IMAGE_TYPE_UNKNOWN

其中BL_IMAGE_TYPE_SIGNED_NB0代表原始型鏡像文件格式，根據(jù)DownloaderImage函數(shù)的實現(xiàn)部分，在沒有要求較高的安全性的情況下(沒有定義宏SECURE_BOOTLOADER，這也是默認的情況)，DownloaderImage函數(shù)把無特征碼的BL_IMAGE_TYPE_UNKNOWN類型也當作原始型鏡像來處理。但是在安全性較高的情況下（定義了宏SECURE_BOOTLOADER）無特征碼的鏡像文件是不應該被Bootloader接受的。

原始型鏡像文件的處理方法最簡單，BootLoader只需從下載端口中讀出全部的鏡像數(shù)據(jù)并且存放到相應的存儲位置，而且無需處理校驗。原始型鏡像文件的數(shù)據(jù)在物理存儲中的起始地址和長度都取決于Manifest數(shù)據(jù)，因而.nb0型的鏡像文件不能單獨下載(如果定義了宏SECURE_BOOTLOADER，DownloaderImage函數(shù)是支持單獨下載的當個nb0文件的。)，BootLoader必須先下載作為它的前導屬性信息的BL_IMAGE_TYPE_MANIFEST類型的鏡像文件。

?

BL_IMAGE_TYPE_MANIFEST類型的鏡像文件的數(shù)據(jù)是多區(qū)段的記錄型鏡像文件的區(qū)段（Region）信息。多區(qū)段的鏡像，簡單地說，就是操作系統(tǒng)或者BootLoader的二進制運行時二進制數(shù)據(jù)分散在不連續(xù)的物理存儲區(qū)間。Manifest的字面意思是“載貨單”，該類型的鏡像文件并不是真正的Windows CE操作系統(tǒng)的或者BootLoader的二進制運行時數(shù)據(jù)，只是供下載多區(qū)段型鏡像所使用的頭信息。由于鏡像數(shù)據(jù)的性質特殊，“N000FF\X0A”——BL_IMAGE_TYPE_MANIFEST類型的鏡像文件——也稱作Manifest數(shù)據(jù)——與一般的鏡像文件數(shù)據(jù)的存放位置不同，它使用專門的DowloadManifest型全局變量g_DownloadManifest來存放。

DowloadManifest結構體類型在頭文件\PUBLIC\COMMON\OAK\INC\blcommon.h中定義如下：

圖1

多區(qū)段意味著多文件，即一個操作系統(tǒng)或者BootLoader的二進制運行時數(shù)據(jù)存放在多個鏡像文件中，這多個鏡像文件的數(shù)據(jù)對應于可以連續(xù)也可以不連續(xù)的多個物理存儲區(qū)域。DowloadManifest結構體的成員dwNumRegion就是多區(qū)段鏡像的區(qū)段個數(shù)，也即是后續(xù)多個鏡像文件的文件個數(shù)。Region數(shù)組成員負責具體存放各區(qū)段的信息，BL_MAX_BIN_REGIONS在頭文件%_WINCEROOT%\PUBLIC\COMMON\OAK\INC\blcommon.h中定義為25，意味著多區(qū)段的鏡像區(qū)段數(shù)最大不超過25。Region數(shù)組成員的元素類型RegionInfo又是一個在頭文件blcommon.h中定義的結構體：

見圖1

RegionInfo結構體的3個成員dwRegionStart、dwRegionLength、szFileName含義分別是一個鏡像區(qū)段在物理存儲中的起始地址、以字節(jié)為單位的區(qū)段長度和與鏡像區(qū)段相對應的鏡像文件名。

對于BL_IMAGE_TYPE_MANIFEST類型的鏡像文件，文件數(shù)據(jù)中緊隨7字節(jié)的格式類型特征碼之后下載端口讀出的是4字節(jié)的校驗數(shù)據(jù)，繼之是4字節(jié)的區(qū)段個數(shù)。區(qū)段個數(shù)數(shù)據(jù)理所當然存放在g_DownloaderManifest全局變量的dwNumRegions成員中，隨后依次讀出的是鏡像的g_DownloaderManifest.dwNumRegions個區(qū)段的屬性數(shù)據(jù)——起始地址、區(qū)段長度、區(qū)段數(shù)據(jù)的鏡像文件名，按順序存放在g_DownloaderManifest.dwNumRegions數(shù)組的各個元素中。DownloaderImage函數(shù)調用CheckImageManifest函數(shù)讀取4字節(jié)校驗數(shù)據(jù)和隨后的全部Manifest數(shù)據(jù)，然后CheckImageManifest函數(shù)調用VerifyChecksum函數(shù)對Manifest數(shù)據(jù)執(zhí)行校驗，不過校驗范圍僅限于存放在g_DownloaderManifest.Regions數(shù)組中的區(qū)段頭信息的數(shù)據(jù)，不包括4字節(jié)的g_DownloaderManifest.dwNumRegions的數(shù)據(jù)。

BL_IMAGE_TYPE_MANIFEST類型在所有的鏡像文件格式類型中比較另類，它只是供下載其他類型的鏡像文件而是用的前導信息，本身并不包含有效的Windows CE操作系統(tǒng)或者BootLoader的二進制運行時數(shù)據(jù)。如果操作系統(tǒng)的鏡像只有一個區(qū)段，或者使用自身包含有存儲位置等頭信息的記錄型鏡像文件格式，也可以不使用Manifest前導數(shù)據(jù)。BL_IMAGE_TYPE_MANIFEST類型的鏡像文件下載完成以后，DownloaderImage函數(shù)并不立即執(zhí)行返回，還要依據(jù)全局變量g_DownloaderManifest中的Manifest數(shù)據(jù)所提供的信息繼續(xù)下載裝載有真實的操作系統(tǒng)二進制數(shù)據(jù)的鏡像文件。

下面就根據(jù)bootloader的代碼來學習如何下載block0img.nb0，bootloader的下載主流程函數(shù)BootloaderMain的主要部分如下圖：

圖2

下面就圍繞DownloadImage函數(shù)和OEMLaunch函數(shù)展開學習下載流程。

1.???? DownloadImage函數(shù)

1.1讀取鏡像文件的Manifest前導數(shù)據(jù)

圖3

1.1.1 GetImageType函數(shù)

DownloadImage函數(shù)首先調用GetImageType()來獲取下載的鏡像文件的類型，這個是根據(jù)鏡像文件的頭7個字節(jié)的特征碼來判斷的

圖4

1.1.2 OEMReadData函數(shù)

我們知道是根據(jù)OEMReadData函數(shù)來讀取鏡像文件的數(shù)據(jù)，因為我們是通過USB來下載數(shù)據(jù)的，所以是通過調用UbootReadData函數(shù)來實現(xiàn)的，下面來分析此函數(shù)：

圖5

1.1.3 CheckImageManifest函數(shù)讀取packet校驗碼、RegionInfo結構體數(shù)據(jù)及核實packet的校驗碼

圖6

1.2 根據(jù)Manifest前導數(shù)據(jù)讀取實際的鏡像文件數(shù)據(jù)

圖7

1.2.1 DownloadNB0函數(shù)

此函數(shù)體第一部分，

圖8

1)???? OEMMultiBINNotify函數(shù)

圖9

2)???? OEMVerifyMemory函數(shù)

圖10

DownloadNB0函數(shù)體的第二部分：

圖11

到此我們知道下載的block0img.nb0先緩存在RAM的0x80100000開始的地址處，下載NK.bin是一樣是緩存在這個地址處，而我們通過圖5知道通過USB下載鏡像的時候是先下載到RAM的0x83000000開始的地址處，所以我們就只能正常把0x83000000-0x80100000=0x2F00000，也即47MB的鏡像文件，如果要下載更大的鏡像文件就改大0x83000000，當然了，這時候也要考慮實際用的RAM（在此我們使用mobile DDR）的大小了。

1)???? OEMMapMemAddr函數(shù)

圖12

如果目標系統(tǒng)的需求是要能支持把鏡像文件下載到FLASH中去，就必須調用本函數(shù)。由于FLASH操作速度比RAM慢，在片擦除的時候甚至會使讀寫操作停滯，而OEMMapMemAddr使用了RAM緩沖鏡像文件的方式，使得用戶在下載鏡像文件時感覺不到停滯，這個函數(shù)將FLASH地址映射到RAM地址，這樣向FLASH寫的數(shù)據(jù)實際上先被緩沖到RAM中，然后再寫到FLASH中。

?

1.2.2 ComputeChecksum函數(shù)

見圖7，ComputeChecksum函數(shù)是用于對鏡像文件的數(shù)據(jù)計算校驗碼。

1.2.3 WriteImageToFlash函數(shù)

圖13

到此DownloadImage函數(shù)已介紹完，下面介紹OEMLaunch函數(shù)

?

2.???? OEMLaunch函數(shù)

圖14

此部分主要是通過調用WriteRawImageToBootMedia函數(shù)把鏡像文件寫到Flash中。

?

總結

以上是生活随笔為你收集整理的基于WINCE6.0+S3C6410通过USB下载stepldr的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。