專利名稱：以故障保險(xiǎn)方式向非易失存儲應(yīng)用自定義軟件映象更新的制作方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及計(jì)算裝置，尤其涉及更新計(jì)算裝置的非易失存儲。
背景技術(shù)：
諸如個人數(shù)字助理、當(dāng)代移動電話和手持式及袖珍計(jì)算機(jī)等移動計(jì)算設(shè)備正在變?yōu)橹匾伊餍械挠脩艄ぞ摺Ｒ话愣?，它們變得足夠小，使得它們極度方便，而消耗較少的電池功率，且在同時變得能夠運(yùn)行更強(qiáng)大的應(yīng)用程序。
在制造這類設(shè)備的過程中，嵌入式操作系統(tǒng)映象通常被構(gòu)建到每一設(shè)備的單塊映象文件中，并儲存在非易失存儲中(如，NAND或NOR閃存、硬盤等等)。作為結(jié)果，迄今為止，更新這類設(shè)備是一個相當(dāng)復(fù)雜且資源密集型問題，它一般需要自定義的解決方案。
例如，更新這類設(shè)備通常涉及下載整個新單塊映象文件，它包括所開發(fā)并發(fā)行的在設(shè)備集合上運(yùn)行的單個靜態(tài)映象。可以容易地理解，無論改變了什么，都需要非常大量的系統(tǒng)資源(如，用于臨時保存更新映象的存儲、用于接收整個映象文件的網(wǎng)絡(luò)帶寬等等)，由此，設(shè)備更新過程通常需要一次性的自定義解決方案。
需要一種比現(xiàn)有更新機(jī)制更靈活、動態(tài)且有效，而仍是故障保險(xiǎn)的更新計(jì)算設(shè)備的非易失存儲的更好的方法。

發(fā)明內(nèi)容
簡單而言，本發(fā)明針對一種以故障保險(xiǎn)的方式向嵌入式設(shè)備的非易失存儲應(yīng)用自包含、安全實(shí)體形式的軟件更新的系統(tǒng)和方法?？蓱?yīng)用各種類型的軟件更新，包括可僅包含對前一更新的改變的更新。此外，軟件更新可包含可執(zhí)行代碼和數(shù)據(jù)兩者。
在一個實(shí)現(xiàn)中，在重啟之后，初始程序加載器確定更新何時被請求或在進(jìn)行中，如果是，則引導(dǎo)到更新加載器而非正常的操作系統(tǒng)代碼。更新加載器操作以確認(rèn)任何待決的更新，用于在適當(dāng)時向閃存(或其它存儲媒質(zhì))應(yīng)用更新。為了安全和控制，更新加載器是系統(tǒng)中對受保護(hù)的存儲(如，NK分區(qū)和系統(tǒng)分區(qū))具有寫訪問權(quán)限的唯一實(shí)體。應(yīng)當(dāng)注意，更新應(yīng)用程序也具有對閃存中保留區(qū)域的寫權(quán)限。
為了更新，更新包(可以是各種形式)被下載到系統(tǒng)上，并由包確認(rèn)過程確認(rèn)，該過程包括為安全原因檢查每一包是否被正確簽署、及總體檢查包是否被正確構(gòu)造。如果有效，則更新被排隊(duì)，并且為初始程序加載器設(shè)置一標(biāo)志以檢測期望更新。然后重啟設(shè)備。
在重啟之后，初始程序加載器看見更新標(biāo)志被設(shè)置，并例如通過將更新加載器解壓(如果被壓縮)到RAM并跳至更新加載器代碼來促使更新加載器運(yùn)行。以內(nèi)核包(如果存在這樣一個的話)開始，對每一包，更新加載器處理該包、重新確認(rèn)它們、基于閃存考慮事項(xiàng)在需要時修正RAM段中的文件、并將這些文件寫入其對應(yīng)的分區(qū)中。注意，初始程序加載器保持閃存未鎖定，使得它可被更新加載器寫入。
為解釋包內(nèi)容，每一包包含具有關(guān)于該包的詳細(xì)信息的設(shè)備清單文件，更新加載器讀取其內(nèi)容，包括包標(biāo)識的全局唯一ID、包版本、與其它包相關(guān)的依賴信息、各種設(shè)置以及包括在包內(nèi)的文件和文件版本的列表。該清單文件包括在包內(nèi)，由此令包為自描述的，并且在安裝之后最終儲存在設(shè)備中。設(shè)備上清單文件的集合包括設(shè)備上包的安裝狀態(tài)的數(shù)據(jù)庫，它可被枚舉。
更新加載器通過從分區(qū)/映象中檢索關(guān)于映象的各種信息，將映象解壓到RAM中，來處理壓縮和非壓縮映象。如果未壓縮，則可簡單地讀取信息，如通過提供要更新的活動分區(qū)的位置的主引導(dǎo)記錄駐留在何處的現(xiàn)有知識來讀取。
在一個實(shí)現(xiàn)中，首先以故障保險(xiǎn)方式應(yīng)用任何內(nèi)核更新，主要通過經(jīng)將其讀入RAM中并將其壓縮到用戶存儲中來備份現(xiàn)有內(nèi)核。更新對分區(qū)是一個整體，如果成功，則刪除備份的內(nèi)核，而如果不成功，則解壓并回復(fù)備份的內(nèi)核。
系統(tǒng)分區(qū)一般大于內(nèi)核分區(qū)，因此，它通常太大，以至于無法為故障保險(xiǎn)相關(guān)原因而備份。相反，使用IMGFS文件系統(tǒng)來向個別的模塊和文件應(yīng)用更新，每次應(yīng)用一個。個別的模塊和文件可能太大，以至于無法作為整體來完成，因此，可通過較小的塊來應(yīng)用更新。
IMGFS可首先模擬更新過程，這需要兩次通過該過程，即在第一遍中，IMGFS和更新應(yīng)用程序?qū)⒉幌蜷W存提交任何內(nèi)容。如果模擬成功，則運(yùn)行第二遍，以實(shí)際提交變化。如果模擬失敗，在重新運(yùn)行包確認(rèn)器之后重試模擬，并傳入不包括失敗的包的包列表。然后用包確認(rèn)器返回的新列表再次運(yùn)行模擬。重試模擬，直到模擬成功，或者沒有可應(yīng)用的任何包。這預(yù)防了在盡管發(fā)生了破壞但仍被簽署的包中所出現(xiàn)的數(shù)據(jù)破壞。
當(dāng)使用現(xiàn)有的設(shè)備清單文件重復(fù)通過IMGFS中的模塊時，該過程檢查來看文件是否在該包的新設(shè)備清單文件中出現(xiàn)。如果不是，則從IMGFS分區(qū)刪除該文件，過程繼續(xù)下一文件。如果是，則從新設(shè)備清單文件獲取新模塊標(biāo)志，并且將模塊頭部加載到模塊結(jié)構(gòu)中。
為執(zhí)行更新，更新應(yīng)用程序過程在嵌套的循環(huán)中循環(huán)通過每一包分組，以個別地處理包中的每一文件。如果在該過程中丟失電源，則一日志文件可精確地告知該過程停留在哪一包以及該包中的哪一文件上，當(dāng)恢復(fù)電源時，更新可從該處繼續(xù)進(jìn)行。上述處理的一部分包括(對于可執(zhí)行代碼)更新對更新模塊的虛擬地址分配。
更新可以是規(guī)范形式或二進(jìn)制差(增量)形式。非模塊不需要虛擬地址修正，并且一旦執(zhí)行二進(jìn)制更新時可被寫入到存儲中。如果文件是模塊，則每次處理每一分段的一個；每一分段被寫入新流中(其中，流是作為IMGFS一部分的文件系統(tǒng)概念)。如果文件是常規(guī)數(shù)據(jù)文件，則數(shù)據(jù)被寫入默認(rèn)流中。
如果模塊是規(guī)范更新，則處理該模塊中的每一分段，包括向由虛擬分配器分配的地址重新定位整個分段，以及將整個分段作為新的流寫入新的IMGFS文件中。在原地更新舊模塊，當(dāng)寫入新塊時，將舊存儲塊解除分配。在規(guī)范的情況下，通過獲取被寫出的新文件中的每一流的大小執(zhí)行對電源故障的恢復(fù)，并將其與規(guī)范文件中該分段的大小進(jìn)行比較。如果新文件中的流小于規(guī)范文件，則那就是過程所停留之處，并且可繼續(xù)進(jìn)行在數(shù)據(jù)上復(fù)制。
在二進(jìn)制差的情況下，每次在一個塊上執(zhí)行打補(bǔ)丁過程，其中，塊可等于頁/扇區(qū)大小。這是因?yàn)榭赡軟]有足夠的閃存空間來同時保留分段的舊版本和新版本。當(dāng)創(chuàng)建新塊時，可將舊塊解除分配，因?yàn)樗鼈円巡辉傩枰?。對于二進(jìn)制差異更新，對該分段在新模塊文件中創(chuàng)建稀疏流，并將舊分段讀入RAM中。將整個舊分段重新定位回原始的基地址。對于二進(jìn)制差文件中的每一新塊，基于二進(jìn)制差異命令構(gòu)建新塊，并將新塊重新定位到由虛擬地址分配器所分配的地址，并將其寫出到稀疏流。來自舊文件流的不再需要的任何舊塊被解除分配。
在二進(jìn)制差的情況下，通過將流大小與頭部中指定的大小相比較來縮小停留在哪一分段的范圍，以處理電源故障。一旦確定了該分段，補(bǔ)丁順序返回下一塊，并檢查該塊是否被提交。如果塊已被提交，則執(zhí)行核實(shí)以檢查適當(dāng)?shù)呐f塊已被提交。一旦找到所停留的塊，(即，尚未被提交的塊)，則過程如常繼續(xù)。
對于更新保留的存儲器分段，以與內(nèi)核分區(qū)更新類似的方式，使用同一更新組件完成保留分段更新(如，在分區(qū)之外)。通過處理包中的每一文件，并確定該文件是否為二進(jìn)制差模塊，處理每一保留相關(guān)的包更新。如果不是，則只要從文件中讀出文件數(shù)據(jù)并寫入保留的區(qū)域中。如果是二進(jìn)制差模塊，則讀取現(xiàn)有的區(qū)域(如，到RAM)中，并在將更新的數(shù)據(jù)寫回保留的區(qū)域之前向其應(yīng)用二進(jìn)制差。
當(dāng)結(jié)合附圖閱讀以下詳細(xì)描述時，可以清楚其它優(yōu)點(diǎn)。


圖1是一般表示可在其中結(jié)合本發(fā)明的計(jì)算機(jī)系統(tǒng)的框圖；圖2是表示依照本發(fā)明的一個方面用于方便故障保險(xiǎn)組件更新的分區(qū)的操作系統(tǒng)映象和加載器組件的框圖；圖3是表示依照本發(fā)明的一個方面向設(shè)備的存儲應(yīng)用更新包的框圖；圖4是表示依照本發(fā)明的一個方面描述包的設(shè)備清單文件的格式的框圖；圖5A和5B包括表示依照本發(fā)明的一個方面確定更新模式的初始程序加載器引導(dǎo)過程的示例邏輯的流程圖；圖6是表示依照本發(fā)明的一個方面的整體更新過程的示例邏輯的流程圖；圖7A和7B包括表示依照本發(fā)明的一個方面更新內(nèi)核分區(qū)的示例邏輯的流程圖；圖8A和8B包括表示依照本發(fā)明的一個方面更新操作系統(tǒng)分區(qū)的示例邏輯的流程圖；圖9是表示依照本發(fā)明的一個方面通過依賴圖以塊向設(shè)備應(yīng)用更新的框圖；以及圖10是表示依照本發(fā)明的一個方面更新保留的存儲器分段的示例邏輯的流程圖。
具體實(shí)施例方式
示例性操作環(huán)境圖1示出了一個這樣的手持式計(jì)算設(shè)備120的功能組件，包括處理器122、存儲器124、顯示屏126和鍵盤128(可以是物理或虛擬鍵盤，或表示兩者)?？纱嬖邴溈孙L(fēng)129以接收音頻輸入。存儲器124一般包括易失存儲器(如，RAM)和非易失存儲器(如，ROM、PCMCIA卡等等)。操作系統(tǒng)130駐留在存儲器124中，并在處理器122上執(zhí)行，如微軟公司的Windows操作系統(tǒng)或另一操作系統(tǒng)。
一個或多個應(yīng)用程序132被加載到存儲器124中，并在操作系統(tǒng)130上運(yùn)行。應(yīng)用程序的示例包括電子郵件程序、調(diào)度程序、PIM(個人信息管理)程序、文字處理程序、電子表格程序、因特網(wǎng)瀏覽器程序等等。手持式個人計(jì)算機(jī)120也可包括加載到存儲器124中的通知管理器134，它在處理器122上執(zhí)行。通知管理器134處理如來自應(yīng)用程序132的通知請求。同樣，如下所述，手持式個人計(jì)算機(jī)120包括適用于將手持式個人計(jì)算機(jī)120連接到網(wǎng)絡(luò)(包括作出電話呼叫)的網(wǎng)絡(luò)軟件136(如，硬件驅(qū)動程序等)和網(wǎng)絡(luò)組件138(如，無線電和天線)。
手持式個人計(jì)算機(jī)120具有電源140，它被實(shí)現(xiàn)為一個或多個電池。電源140還可包括忽略內(nèi)置電池或?qū)ζ渲匦鲁潆姷耐獠侩娫?，如AC適配器或加電對接托架。
圖1所示的示例性手持式個人計(jì)算機(jī)120被示出為具有三種類型的外部通知機(jī)制一個或多個發(fā)光二極管(LED)142和音頻生成器144。這些設(shè)備可直接耦合至電源140，使得當(dāng)被激活時，即使手持式個人計(jì)算機(jī)處理器122或其它組件被關(guān)閉以保存電池能量時，它們也保留一段由通知機(jī)制指示的持續(xù)時間。LED 142較佳地不確定地保留，直到用戶采取行動。注意，音頻生成器144的當(dāng)代版本使用當(dāng)今手持式個人計(jì)算機(jī)電池的太多能量，因此它被配置成當(dāng)系統(tǒng)的剩余部分被關(guān)閉時，或者在激活后的一段確定持續(xù)時間之后被關(guān)閉。
注意，盡管示出了基本手持式個人計(jì)算機(jī)，然而，為實(shí)現(xiàn)本發(fā)明的目的，實(shí)際上能夠以可由程序使用的某一方式接收數(shù)據(jù)通信和處理數(shù)據(jù)的任何設(shè)備都是等效的。
自定義軟件映象更新的故障保險(xiǎn)應(yīng)用本發(fā)明一般針對安裝和/或更新儲存在諸如基于微軟的WindowsCE.NET的便攜式設(shè)備等小型移動計(jì)算設(shè)備上的軟件，包括在其中向嵌入式設(shè)備的非易失存儲器，如閃存寫入初始軟件或軟件更新的那些設(shè)備。盡管如此，本發(fā)明提供了在總體上計(jì)算的益處，并由此可應(yīng)用到其它計(jì)算設(shè)備和其它類型的存儲，包括各種類型的存儲器和/或其它類型的存儲媒質(zhì)，如硬盤驅(qū)動器。為簡化目的，術(shù)語“閃存”在后文參考設(shè)備的可更新存儲來使用，盡管可以理解，任一存儲機(jī)制都是等效的。此外，術(shù)語“映象”一般包括初始軟件安裝映象以及對該映象的隨后的軟件更新的概念，即使僅更新該映象的一部分。
依照本發(fā)明的一個方面，以故障保險(xiǎn)的方式向嵌入式設(shè)備的非易失存儲應(yīng)用自包含、安全實(shí)體形式的軟件更新?？蓱?yīng)用各種類型的軟件更新，包括僅包含對前一更新的改變的更新。此外，軟件更新可包含可執(zhí)行代碼和數(shù)據(jù)兩者?？梢岳斫?，可執(zhí)行代碼在安裝時被定制到嵌入式設(shè)備的虛擬地址空間環(huán)境。依照本發(fā)明，軟件更新以故障保險(xiǎn)的方式安裝，并根據(jù)更新的階段，允許卷進(jìn)(roll-forward)和卷回(roll-back)恢復(fù)選項(xiàng)。
下表提供了本發(fā)明所描述的某些術(shù)語和文件類型的通用、非限制定義術(shù)語


文件類型

如上述名為“以存儲技術(shù)抽象方式在文件內(nèi)創(chuàng)建文件系統(tǒng)”的美國專利中所描述的，可從組件部分構(gòu)建初始映象(包括包、下文描述)，并在制造過程中以自定義方式將其安裝到設(shè)備上。該映象用單獨(dú)的分區(qū)構(gòu)建，一般在圖2中表示，并可如后文所描述的被部分更新，而不需要替換單塊映象。
分區(qū)模式方便了未來的嵌入式設(shè)備以及已有的設(shè)備上的軟件的可靠更新。與意味著在一組設(shè)備上運(yùn)行的在軟件開發(fā)和發(fā)行過程中生成單個靜態(tài)映象相反，本發(fā)明提供了一種方便可更新映象的更好組件化，而同時仍是故障保險(xiǎn)的更動態(tài)的映象更新機(jī)制。為此，本發(fā)明提供了一種將操作系統(tǒng)映象分裂成可單獨(dú)更新的單獨(dú)的可更新組件，而保持任何跨組件依賴性的更靈活的機(jī)制。為支持這一概念，初始操作系統(tǒng)映象用某些關(guān)鍵體系結(jié)構(gòu)特征來構(gòu)造。
圖2示出了用于安裝在閃存和/或其它合適的非易失存儲媒質(zhì)上的操作系統(tǒng)映象202的示例分區(qū)模式。為儲存內(nèi)核映象的目的，提供了內(nèi)核分區(qū)204作為受限制/受保護(hù)的分區(qū)。內(nèi)核/NK分區(qū)為操作系統(tǒng)映象的核心片段(內(nèi)核、文件系統(tǒng)等)提供了存儲，并包含在引導(dǎo)過程中執(zhí)行的代碼。提供了受限制/受保護(hù)的系統(tǒng)分區(qū)206用于儲存系統(tǒng)組件應(yīng)用程序和操作系統(tǒng)映象的其它部分(驅(qū)動程序、應(yīng)用程序、數(shù)據(jù)文件等)。如后文所描述的，這些分區(qū)204和206的內(nèi)容由文件系統(tǒng)驅(qū)動程序管理，它們抽象存儲的物理映射，并服務(wù)以支持系統(tǒng)分區(qū)206中組件的已處理更新，由此啟用了一種依照本發(fā)明的故障保險(xiǎn)/恢復(fù)解決方案。對受保護(hù)的內(nèi)核分區(qū)的內(nèi)容的訪問通過二進(jìn)制文件系統(tǒng)(BINFS)來控制，而對受保護(hù)的系統(tǒng)分區(qū)的內(nèi)容的訪問通過映象文件系統(tǒng)(IMGFS)來控制。
圖2也示出了(盡管實(shí)際上并非操作系統(tǒng)202的一部分)系統(tǒng)/用戶可在需要時使用的用戶存儲分區(qū)210，它本質(zhì)上可以是任何文件系統(tǒng)格式(如，TFAT)。如后文所描述的，除其它可能的使用之外，該分區(qū)可用于臨時儲存要在更新過程中安裝的某些包。注意，書寫主引導(dǎo)記錄以定義這些分組，如其偏移/大小。
圖2也提供了加載器環(huán)境的功能示圖。一般而言，加載器負(fù)責(zé)以程序引導(dǎo)嵌入式系統(tǒng)到可作出關(guān)于是作出正常的操作系統(tǒng)引導(dǎo)還是更新引導(dǎo)的決策的一點(diǎn)上(通過初始程序加載器222，它可結(jié)合預(yù)先存在的引導(dǎo)加載器224一起工作，如果存在的話)。注意，“預(yù)先存在”的引導(dǎo)加載器對新設(shè)備并非必需，然而設(shè)備制造商可任選地決定它應(yīng)當(dāng)存在。
對于更新引導(dǎo)，加載器的一部分包括擔(dān)當(dāng)任一閃存更新的監(jiān)控者(gatekeeper)的更新加載器(UL 220)。更新加載器220負(fù)責(zé)確認(rèn)任何待決的更新，并且一旦被確認(rèn)，在適當(dāng)時將更新應(yīng)用到閃存。為安全性和控制，更新加載器220是系統(tǒng)中具有對受保護(hù)的存儲(如，NK分區(qū)和系統(tǒng)分區(qū))具有寫訪問權(quán)限的唯一實(shí)體，并由此提供了負(fù)責(zé)保護(hù)系統(tǒng)存儲的完整性的單個點(diǎn)。注意，更新加載器相對較大，并僅在應(yīng)用更新時使用，由此，在一個實(shí)現(xiàn)中，它以壓縮形式存儲，并在需要時被解壓到RAM中。
圖3表示更新安裝機(jī)制/過程。注意，圖3從更新的觀點(diǎn)開始，在設(shè)備先前被用初始程序加載器、主引導(dǎo)記錄(MBR)、和更新加載器(UL)組件初始地填充(如，通過JTAG接口或在制造過程中的程序員群體)之后。同樣，規(guī)范包(后文描述)從持久存儲/RAM應(yīng)用到內(nèi)核和系統(tǒng)分區(qū)中。
在圖3中，將更新包302(可以是規(guī)范、增量更新或超級包，如后文所描述的)下載到系統(tǒng)RAM 304和/或用戶數(shù)據(jù)存儲210中，有可能在向設(shè)備用戶通知更新可用的情況下，以手動或自動方式下載。這一般在圖3中由標(biāo)簽為帶圈的數(shù)字1的箭頭表示。
由此，一旦在設(shè)備上安裝了初始制造映象，通過更新被封裝成包的映象的離散部分來完成對映象將來的更新。一般而言，包是映象文件(代碼、數(shù)據(jù)、腳本等)的自描述集合，并且在一個實(shí)現(xiàn)中，它包括被簽署并被包裝用于分發(fā)的組件的集合。包提供了操作系統(tǒng)映象軟件文件被分裂成文件的較小功能組的方法。在一個實(shí)現(xiàn)中，整個操作系統(tǒng)映象包括一個或多個包(不包括加載器組件)，并且然后可僅作為較小的包的總和來處理，這些較小的包可被個別地管理、構(gòu)建和更新，其每一個都可個別地或與其它包組合地更新，取決于每一包的需求。由此，依照本發(fā)明，映象更新不再需要作為整個操作系統(tǒng)映象區(qū)域來完成。
包可以各種方式來配置，包括“規(guī)范”、“增量/差”和“超級”形式，其每一個都服務(wù)關(guān)于軟件更新的各種目的。例如，規(guī)范包包含包內(nèi)每一文件的完整副本，而增量/差包包含僅包含基于該文件的較早版本的二進(jìn)制差的一個或多個文件。增量/差包通常相對于其它包較小，并且由此在試圖優(yōu)化下載成本和下載時間時使用。超級包包含其它包，并在需要下載一個以上包(如，對于互相依賴的包)時為方便而使用。在一個實(shí)現(xiàn)中，包文件是Win32 CAB文件，它們包含清單文件(后文描述)以及定義諸如要安裝的包的文件。
規(guī)范包在構(gòu)建過程中通過將操作系統(tǒng)特征和元數(shù)據(jù)(如，特定應(yīng)用程序的可執(zhí)行代碼和所有關(guān)聯(lián)的數(shù)據(jù)和配置信息)與包定義相關(guān)聯(lián)來生成。增量/差包通過向兩個規(guī)范包的內(nèi)容應(yīng)用二進(jìn)制差算法，并捕捉增量/差包在基線規(guī)范包版本上具有的依賴關(guān)系，從規(guī)范包生成。一旦操作系統(tǒng)映象特征和元數(shù)據(jù)被映射到個別的包，如上述美國專利申請“自描述軟件映象更新組件”中一般描述的，通過使用包裝工具來枚舉包的內(nèi)容，并通過處理可執(zhí)行文件(用稱為RelMerge的重定位工具)以令它們能夠在將來被更新用于存儲器相關(guān)的修正更新，創(chuàng)建每一包。
當(dāng)用戶引導(dǎo)更新過程時，包確認(rèn)器核實(shí)包，如上述相關(guān)的名為“確定對安裝有效的最大依賴軟件更新集”和“確保軟件更新僅在特定的設(shè)備或設(shè)備類別上安裝或運(yùn)行”的專利申請中所描述的。如果被確認(rèn)，系統(tǒng)在閃存中設(shè)置更新標(biāo)志，并重啟。注意，如后文所描述的，保存更新標(biāo)志，使得在丟失電源的情況下，一旦更新加載器代碼引導(dǎo)，設(shè)備可重新進(jìn)入更新模式。
在重啟之后，初始程序加載器222看見更新標(biāo)志被設(shè)置，并將壓縮的更新加載器解壓到RAM 304中，如圖3中通過未壓縮的更新加載器代碼308所表示的，并將控制傳遞到更新加載器代碼308。這一般在圖3中由標(biāo)簽為帶圈的數(shù)字2的箭頭表示。注意，當(dāng)更新加載器開始更新應(yīng)用程序時，更新應(yīng)用程序使用文件列表，或由updagebin.exe應(yīng)用程序在設(shè)備重啟前設(shè)置的一組目錄規(guī)范重新運(yùn)行確認(rèn)過程。重新運(yùn)行確認(rèn)過程以預(yù)防包的惡意替換。
以內(nèi)核包(如果有的話)開始，對于每一包，更新加載器處理該包、在需要時基于閃存考慮事項(xiàng)修正RAM分段310中的文件、并使用BINFS服務(wù)將文件寫入其對應(yīng)的分區(qū)中，如圖3中通過標(biāo)簽為3到6的箭頭所示的。修正在下文一般描述，并也在上述名為“自描述軟件映象更新組件”的相關(guān)專利申請中有描述。
每一包包含設(shè)備清單文件400，它包含關(guān)于該包的詳細(xì)信息，如圖4中一般表示的。清單文件本質(zhì)上是每一包的規(guī)范文件，并包含諸如包標(biāo)識的全局唯一ID、包版本、與其它包有關(guān)的依賴信息、設(shè)置、包括在包內(nèi)的文件列表和文件版本以及其它共享的公用特征等信息。清單文件400包括在包內(nèi)，由此令包為自描述的，它在安裝過程中被審閱，并最終儲存在設(shè)備上。設(shè)備上清單文件的集合包括可枚舉的設(shè)備上的包安裝狀態(tài)的數(shù)據(jù)庫。
在對應(yīng)于包含在圖4所示的設(shè)備清單文件中的格式和信息的一個實(shí)現(xiàn)中，設(shè)備清單文件也用以下結(jié)構(gòu)定義來描述



所創(chuàng)建的每一包為安全原因被簽署，然后可用于下載/安裝。如上述名為“自描述軟件映象更新組件”的相關(guān)美國專利申請中所描述的，包生成過程/包生成器自動化了包含由包描述文件所定義的文件的完整版本的包文件的創(chuàng)建。一般而言，包生成器輸入包定義文件(如，由命令行自變量指定)；其它輸入文件基于指定的包定義文件內(nèi)容來確定。包生成器分析包定義文件(如，包括一個或多個包定義，每一包作為一XML文檔條目編碼)，并可分析包含涉及與用于諸如注冊表設(shè)置等設(shè)置的其它包有關(guān)的優(yōu)先順序的數(shù)據(jù)的包陰影文件。此外，包生成器分析構(gòu)建清單文件以找出其中指定的每一文件，然后確定該文件的類型。對于可執(zhí)行文件類型，包生成器調(diào)用執(zhí)行重定位相關(guān)操作以及執(zhí)行格式化(如，將可執(zhí)行文件轉(zhuǎn)換成WindowsCE文件格式)的過程(RelMerge)。
在一個實(shí)現(xiàn)中，包生成器包括使用名為如PkgCommon的.NET類庫的應(yīng)用程序。包生成器應(yīng)用程序創(chuàng)建多個子目錄，所創(chuàng)建的子目錄的數(shù)量等于命令行中指定的包集合文件中的有效包的數(shù)量。每一包具有在包生成過程中為其創(chuàng)建的唯一的子目錄。另外，包生成器在每一子目錄中使用包定義內(nèi)找到的信息創(chuàng)建另外的文件。對于每一包，創(chuàng)建一設(shè)備清單文件，該設(shè)備清單文件的名字從該包的GUID導(dǎo)出。對于每一有效的包定義，創(chuàng)建一包文件以包含包括該包的文件，包括設(shè)備清單文件。這些包文件符合微軟的CAB文件1.3版格式。
安裝過程大量使用設(shè)備清單文件的內(nèi)容，既用于已安裝在設(shè)備上的那些包，又用于被排隊(duì)用于設(shè)備上的可能安裝的那些包。包信息API被設(shè)計(jì)成提供查詢包信息的抽象方法，并既在設(shè)備又在構(gòu)建主機(jī)上使用。API在上述名為“確定對安裝有效的最大依賴軟件更新集”的相關(guān)專利申請中有詳細(xì)描述。
管理對內(nèi)核或系統(tǒng)分區(qū)的更新并將其傳送到使用包機(jī)制的設(shè)備上。包被傳送到設(shè)備、儲存在臨時存儲中、并被排隊(duì)用于通過任一合適的方法來安裝，如通過現(xiàn)有的操作系統(tǒng)映象的組件?？墒褂糜糜趯鼈魉偷皆O(shè)備的任一合適的傳輸方法(物理和/或接口協(xié)議)，并且方法可根據(jù)要更新的包而變化(如，對智能電話為無線，對智能顯示屏為USB，對某些臺式機(jī)更新應(yīng)用通過某一物理連接，等等)。終端用戶界面感受將根據(jù)所更新的設(shè)備的類型，以及由設(shè)備制造商定制的更新過程而變化。依照本發(fā)明的故障保險(xiǎn)方面，每一臨時包儲存在持久存儲中，使得在丟失電源的情況下，系統(tǒng)能夠恢復(fù)并繼續(xù)安裝。
當(dāng)調(diào)用包確認(rèn)器庫時，觸發(fā)更新過程。在一個實(shí)現(xiàn)中，名為UpdateBin.exe的可執(zhí)行文件與.pkg.cab、.pku.cab和.pks.cab文件擴(kuò)展名相關(guān)聯(lián)。這一可執(zhí)行文件利用包確認(rèn)器庫來確定更新設(shè)備所使用的包的組。
包確認(rèn)器檢查包上的簽名、確認(rèn)包內(nèi)容、核實(shí)版本等等。一旦更新包被認(rèn)為是適當(dāng)?shù)?，它們被排?duì)用于安裝，并且確認(rèn)器設(shè)置更新標(biāo)志以向設(shè)備發(fā)信號通知更新可用，然后重啟系統(tǒng)。
在重啟時，初始程序加載器222是從CPU的復(fù)位矢量起運(yùn)行的第一個代碼片段(盡管在某些設(shè)備中，初始程序加載器可由現(xiàn)有的引導(dǎo)加載器映象進(jìn)行程序引導(dǎo))。初始程序加載器222負(fù)責(zé)確定設(shè)備是否處于更新模式，或者設(shè)備是否處于正常引導(dǎo)模式。如果設(shè)備處于正常引導(dǎo)模式，則初始程序加載器定位并用程序引導(dǎo)操作系統(tǒng)映象，否則，初始程序加載器定位、解壓并用程序引導(dǎo)解壓的更新加載器映象308。圖5A和5B描述了初始程序加載器引導(dǎo)過程。如圖5A所示，在步驟502某些初始化之后(如，初始化CPU，如果是NAND則初始化控制器、初始化SDRAM等等)，初始程序加載器通過步驟504和506確定復(fù)位的原因。更具體地，某些CPU體系結(jié)構(gòu)在從掛起的狀態(tài)繼續(xù)執(zhí)行時模仿重啟序列。然后，引導(dǎo)代碼通?；贑PU寄存器值將繼續(xù)執(zhí)行與“正常”引導(dǎo)區(qū)別開來。初始程序加載器調(diào)節(jié)繼續(xù)執(zhí)行操作，并且為了完整性示出步驟504-508。
如果不是繼續(xù)執(zhí)行，則步驟506分支到步驟510-528，如所見到的，檢測更新模式，并且如果是更新，則掃描更新加載器分區(qū)(步驟520)，否則在步驟518掃描操作系統(tǒng)分區(qū)。如通過522所見的，在初始程序加載器無法定位設(shè)備上的操作系統(tǒng)映象的情況下，初始程序加載器試圖加載并運(yùn)行更新加載器。如果未找到適當(dāng)?shù)姆謪^(qū)，則輸出錯誤(步驟532)；注意在這一時刻，設(shè)備未使用正常的顯示驅(qū)動程序等運(yùn)行，由此，在這一時刻所顯示的任何圖像都是來自數(shù)據(jù)存儲的位圖。
此外，當(dāng)引導(dǎo)到操作系統(tǒng)時，通過步驟524鎖定閃存，該步驟在引導(dǎo)到更新加載器時不執(zhí)行。過程然后繼續(xù)到圖5B的步驟538，以處理壓縮和非壓縮映象。注意，圖5B可用于更新加載器或操作系統(tǒng)。更新加載器(在典型的設(shè)備上)以壓縮形式儲存，而操作系統(tǒng)可以壓縮或不以壓縮形式存儲，取決于該設(shè)備是否是允許代碼在原地執(zhí)行的設(shè)備(如果是，則不能被壓縮)。
如果被壓縮，則從分區(qū)/映象檢索關(guān)于該映象的各種信息，并且將該映象解壓到RAM中，并通過步驟540-546開始執(zhí)行。注意，可使用任一合適的壓縮算法，只要壓縮類型和壓縮數(shù)據(jù)的格式是初始程序加載器所已知的。如果未被壓縮，則步驟538在步驟544從分區(qū)扇區(qū)讀取關(guān)于該映象的信息、從該扇區(qū)查找目錄(TOC)、偏移和簽名。為此，初始程序加載器具有主引導(dǎo)記錄駐留在何處(初始程序加載器映象之后的下一好閃存塊的起始)的先驗(yàn)知識，并在儲存在主引導(dǎo)記錄中的分區(qū)表中查找活動分區(qū)。由此，初始程序加載器依賴于具有正確地同時位于操作系統(tǒng)映象的原地執(zhí)行區(qū)域以及更新加載器映象中的目錄(TOC)的ROM映象/盤映象。在一個實(shí)現(xiàn)中，以下作為位置提供在字節(jié)偏移(映象起始+0x40)UNIT32 ROMSignature；UNIT32*pTOC；該信息由操作系統(tǒng)映象用于查找TOC(如由ROM映象/盤映象所放置的)。指針僅在存儲器管理單元(MMU)被打開，且映射與對其構(gòu)建操作系統(tǒng)映象的地址兼容時有意義。一種替換方案是如下實(shí)現(xiàn)在字節(jié)偏移(映象起始+0x40)UINT32 ROMSignature；UINT32*pTOC；UINT32 TOCOffset；其中，TOCOffset是從映象起始位置到TOC的字節(jié)偏移，并可由初始程序加載器(或更新加載器應(yīng)用程序)用于在不知道該映象被構(gòu)建于何處來運(yùn)行的情況下查找TOC。
初始程序加載器也可檢查簽名，如步驟548所表示的。如果在步驟548無效，則引導(dǎo)過程在步驟550暫停，否則通過步驟552和554讀取目錄以找出映象起始、映象長度，并從目錄跳至該地址。步驟558在必要時基于制造商供應(yīng)的數(shù)據(jù)表修正該地址。更具體地，初始程序加載器通常運(yùn)行在設(shè)備的物理地址空間(或有時候在不同于操作系統(tǒng)映象或更新加載器映象的虛擬地址空間中)。該例程負(fù)責(zé)將任何映象專用虛擬地址(如，操作系統(tǒng)映象TOC值)轉(zhuǎn)換成與初始程序加載器兼容的地址。如果制造商的引導(dǎo)例程未啟用存儲器管理單元，這意味著將虛擬地址轉(zhuǎn)換成物理地址。如果啟用了存儲器管理單元，并且映射與如何構(gòu)建操作系統(tǒng)或更新加載器映象兼容，則不需要任何轉(zhuǎn)換。
步驟558測試映象是需要被加載到RAM中(如果是，則在步驟562出現(xiàn))，還是可在原地執(zhí)行。然后如步驟564所示的跳轉(zhuǎn)至映象(加載的或原地)開始執(zhí)行。采用活動分區(qū)的位置，初始程序加載器(如所設(shè)計(jì)的)在NAND(或可能是NOR)的情況下將活動分區(qū)(內(nèi)核分區(qū))的內(nèi)容加載在RAM中，或者如果它是NOR(原地執(zhí)行)內(nèi)核，則跳至分區(qū)內(nèi)的引導(dǎo)地址。如果是正常引導(dǎo)，則內(nèi)核開始并繼續(xù)加載同樣位于內(nèi)核分區(qū)內(nèi)的操作系統(tǒng)組件，以指出操作系統(tǒng)能夠從系統(tǒng)分區(qū)中讀取。在這一點(diǎn)上不位于內(nèi)核分區(qū)內(nèi)的任何內(nèi)容被從系統(tǒng)分區(qū)中取出(或者加載或者在原地執(zhí)行)，直到操作系統(tǒng)映象被完全引導(dǎo)。
在一個實(shí)現(xiàn)中，初始程序加載器是相對非常小尺寸的軟件組件，它由CPU的復(fù)位矢量作程序引導(dǎo)，并負(fù)責(zé)有條件地加載/開始操作系統(tǒng)映象或更新加載器映象。如上所述，初始程序加載器需要能夠讀各種寄存器，包括RAM標(biāo)志、閃存/非易失標(biāo)志、以及硬件開關(guān)，以確定它是應(yīng)當(dāng)引導(dǎo)正常的操作系統(tǒng)映象還是更新加載器映象。更具體地，初始程序加載器需要檢查由UpdateBIN應(yīng)用程序(如，在確認(rèn)之后)或由更新加載器應(yīng)用程序設(shè)置的任何標(biāo)志，因?yàn)橥ǔ２僮飨到y(tǒng)映象以只讀閃存文件系統(tǒng)運(yùn)行。為適應(yīng)電源故障條件，更新模式標(biāo)志應(yīng)當(dāng)是非易失的，由此，如果無法在重啟前儲存非易失標(biāo)志，則更新加載器應(yīng)用程序在第一次運(yùn)行時設(shè)置非易失標(biāo)志，并在成功地完成安裝之后清除該標(biāo)志，由此令該標(biāo)志跨電源故障得以持久保存。
此外，初始程序加載器需要以各種類型的存儲技術(shù)分析存儲分區(qū)結(jié)構(gòu)，以查找映象，并能夠處理壓縮映象類型以及閃存XIP(在閃存中原地執(zhí)行)和RAM映象(復(fù)制到RAM來執(zhí)行)。一般而言，初始程序加載器抽象存儲屬性，如分區(qū)結(jié)構(gòu)、保留的塊、壞塊等等，以及用于任一OEM提供的代碼的任何存儲技術(shù)的細(xì)節(jié)(如，NOR閃存、NAND閃存、HDD、DOC等等)。初始程序加載器可在以程序引導(dǎo)映象之前確認(rèn)操作系統(tǒng)映象和/或更新加載器映象的完整性(如，通過執(zhí)行校驗(yàn)和和簽名核實(shí))，如檢測惡意更新并由此提供核實(shí)用于數(shù)字權(quán)限管理的可信代碼的方法，它需要信任從內(nèi)核映象返回的UUID由未被惡意地篡改的代碼提供。
由此，如圖5所見的并如圖3所示出的，當(dāng)在更新模式時，初始程序加載器222將壓縮的更新加載器220解壓到RAM 304中作為解壓縮的更新加載器308、保留閃存未鎖定以給予解壓縮的更新加載器308對系統(tǒng)閃存的寫訪問權(quán)限、并跳至解壓縮的加載器代碼以開始執(zhí)行。當(dāng)由初始程序加載器第一次以程序引導(dǎo)時，更新加載器應(yīng)用程序需要在非易失存儲中儲存指示該設(shè)備處于更新模式的標(biāo)志。這是因?yàn)椴僮飨到y(tǒng)映象可能具有只讀閃存文件系統(tǒng)，并且無法設(shè)置該標(biāo)志，而這對電源丟失恢復(fù)是重要的。初始程序加載器在確定是加載更新加載器映象還是操作系統(tǒng)映象時檢查RAM標(biāo)志以及這一非易失標(biāo)志的存在；RAM標(biāo)志由UpdateBIN應(yīng)用程序(直接或間接)設(shè)置。
轉(zhuǎn)向更新過程的解釋，如上所述，用于更新內(nèi)核或系統(tǒng)分區(qū)內(nèi)容的過程在更新加載器被完全引導(dǎo)并加載到RAM之后執(zhí)行，并操作以找出用戶存儲中所確認(rèn)的包(如由確認(rèn)器所指定的)。注意，更新加載器包含必要的文件系統(tǒng)驅(qū)動程序，并一次開始一個包的更新過程。用于更新包的包信息記錄在文件系統(tǒng)中，由確認(rèn)器在將來的更新中使用。依照本發(fā)明的一個方面，為提供故障保險(xiǎn)更新，初始程序加載器能夠從隨機(jī)電源故障中在加載過程中的任一點(diǎn)上恢復(fù)。為此，在事務(wù)日志中跟蹤更新進(jìn)展，以允許萬一在更新過程中出現(xiàn)電源故障能夠進(jìn)行卷進(jìn)更新。
在更新模式中，更新加載器運(yùn)行并開始更新應(yīng)用程序，它是作為更新加載器映象308(圖3)的一部分的可執(zhí)行文件，并負(fù)責(zé)將包內(nèi)容應(yīng)用到NK/內(nèi)核分區(qū)204和系統(tǒng)分區(qū)206。換言之，在更新過程中由初始程序加載器加載的更新應(yīng)用程序負(fù)責(zé)將包更新應(yīng)用到映象。注意，更新加載器映象包含更新應(yīng)用程序所需的最小模塊集，如nk、filesys、閃存驅(qū)動程序、coredll、IMGFS等等。
圖6-8分別描述了整體更新過程、NK/內(nèi)核分區(qū)更新的應(yīng)用程序以及系統(tǒng)分區(qū)更新。更新應(yīng)用程序與包確認(rèn)器一起工作以確認(rèn)包，并與ROMIMAGE模塊一起工作以處理虛擬和物理分配、修正和安排功能。如圖6所見的，更新應(yīng)用程序在步驟600檢索包安裝列表(如，從注冊表)、通過確認(rèn)器確認(rèn)包(步驟602)。在更新模式中，更新應(yīng)用程序負(fù)責(zé)將包內(nèi)容應(yīng)用到NK/分區(qū)和系統(tǒng)分區(qū)。
在更新應(yīng)用程序?qū)鼉?nèi)容應(yīng)用到非易失存儲之前，確認(rèn)包，這(尤其)包括簽名檢查以核實(shí)包來自可信源等等。如可容易地理解的，知道包更新來自可信源并確保存在對閃存有可寫訪問權(quán)限的單個可信監(jiān)控者在試圖包括設(shè)備的閃存的完整性時是重要的。更新包在構(gòu)建過程中簽署、并假定它們是由更新的許多可能不同的每一包可信源之一簽署的、并允許繼續(xù)通過上述包確認(rèn)過程。如果它們未被簽署或者不是由可信源簽署的，則包確認(rèn)失敗并且由此不被更新。
注意，系統(tǒng)的設(shè)計(jì)是使得被允許更新閃存的內(nèi)容的唯一軟件組件也是負(fù)責(zé)檢查被排隊(duì)來安裝(更新加載器)的任一包的有效性(包括檢查簽名)的同一組件。同樣注意，更新加載器不能包括任何不可信或第三方代碼，如通用操作系統(tǒng)。由此，該系統(tǒng)僅運(yùn)行可信代碼，并不易受篡改的影響。當(dāng)未運(yùn)行更新加載器時，該設(shè)計(jì)利用了禁止向閃存部分寫入的硬件鎖機(jī)制(在硬件層)，而無需首先復(fù)位該部分(它通常依賴于CPU，并由此需要同時復(fù)位)。此外，操作系統(tǒng)映象包含文件系統(tǒng)的只讀版本，由此進(jìn)一步確保閃存的內(nèi)容是不可更新的，除非系統(tǒng)處于更新加載器環(huán)境內(nèi)，其中，確保包確認(rèn)和安全檢查得以執(zhí)行。
核實(shí)也包括檢查包內(nèi)容的正確性、將設(shè)備清單文件中的信息與包內(nèi)容相關(guān)、并確保文件(按名字)在一個且僅一個包內(nèi)存在。確認(rèn)也核實(shí)包的必要版本已安裝在系統(tǒng)上或已被排隊(duì)來安裝。例如，如果包A的版本1.0已安裝在系統(tǒng)上，并且增量/差包A將版本2.0變?yōu)榘姹?.0，則需要一個將包A變?yōu)榘姹?.0的包被排隊(duì)來安裝，以使該增量/差包得以安裝。還滿足包括核實(shí)必要的包依賴性的其它核實(shí)。例如，如果包A的版本2.0依賴于包B的版本3.0的內(nèi)容，則核實(shí)檢查后一包已被安裝或已被排隊(duì)并確認(rèn)來安裝。包確認(rèn)過程也在上述名為“確定對安裝有效的最大依賴軟件更新集”的美國專利申請中有描述。
設(shè)備上確認(rèn)過程的結(jié)果是可安裝在設(shè)備上的包(及其文件)的列表，因?yàn)樗鼈儩M足了確認(rèn)需求。確認(rèn)過程也生成不能連同關(guān)于對每一具體包確認(rèn)過程為何失敗的數(shù)據(jù)一起安裝的包列表。安裝過程的剩余部分僅利用通過確認(rèn)的那些包。
返回到圖6，更新加載器負(fù)責(zé)將任何更新應(yīng)用到內(nèi)核分區(qū)(步驟604和606)，并將任何系統(tǒng)更新應(yīng)用到系統(tǒng)分組(步驟608和610)。如果有其它更新，如存儲器的保留的無線電分段(存在于分區(qū)的范圍之外，即，唯一地位于閃存中的指定位置，其分區(qū)結(jié)構(gòu)被定義為在保留區(qū)域“周圍”)，則它們通過步驟612和614被類似地處理，如參考圖10所描述的。
包可通過步驟616來刪除。在步驟618將標(biāo)志設(shè)置成一個值(如cleared)，以引導(dǎo)操作系統(tǒng)映象，當(dāng)作出內(nèi)核更新或系統(tǒng)更新時更新該系統(tǒng)映象，并重啟系統(tǒng)(步驟620)。
圖7A和7B示出了內(nèi)核更新的一般邏輯，其中(假定原地執(zhí)行)，通過將現(xiàn)有的內(nèi)核讀入RAM中，并將其壓縮到用戶存儲中，備份該內(nèi)核。這由步驟700表示，其中，通過文件系統(tǒng)展示為具有一個默認(rèn)文件的XIP文件夾的XIP分區(qū)獲取其用于將整個映象讀入本地緩沖器的句柄。在用戶存儲中創(chuàng)建新文件、調(diào)用壓縮例程來壓縮映象、并然后將壓縮的文件數(shù)據(jù)寫入新文件中。
步驟702讀取頭部和其它元數(shù)據(jù)。為此，該過程走查(walk)pToc(目錄結(jié)構(gòu))以確定每一分段的位置、用模塊信息填充舊模塊列表、并設(shè)置分段數(shù)據(jù)指針以指向?yàn)閭浞菟鶆?chuàng)建的RAM內(nèi)副本中的適當(dāng)位置?，F(xiàn)有TOC的一部分被保存并被復(fù)制到接近NK/XIP分區(qū)更新的末端附近的新TOC中。注意，當(dāng)讀模塊的頭部時，該過程也讀舊設(shè)備清單文件以查找額外的標(biāo)志(壓縮、內(nèi)核模塊、插槽1忽略[L標(biāo)志]等等)。
通過步驟704和722，隨后通過處理包中的每一模塊(步驟706和720)、確定該文件是否為bindiff(二進(jìn)制差)模塊來處理每一包。這涉及循環(huán)通過每一包中的每一模塊，并應(yīng)用規(guī)范更新，其中提供了新文件的整個副本；或應(yīng)用二進(jìn)制差更新，其中僅提供文件的二進(jìn)制差。應(yīng)用二進(jìn)制差的過程被稱為patchbin(打二進(jìn)制補(bǔ)丁)；單獨(dú)的二進(jìn)制差在每一分段中完成，每次完成一個。新模塊的頭部以原始的規(guī)范形式提供。當(dāng)逐個更新文件時，它們被添加到(以文件對象的形式)新文件列表。在該步驟的最后，存在包含更新模塊和文件的未修正版本的新文件列表。如果它們是現(xiàn)有文件，則將它們從舊列表中移除，使得在該步驟的最后，舊列表僅包含對其沒有更新的文件。注意，該過程基于該分區(qū)中包清單文件的存在知道哪一(些)包與該分區(qū)相關(guān)聯(lián)。尚未在設(shè)備上安裝的任何新包被保存在IMGFS分區(qū)中。
由此，在步驟708，如果不是二進(jìn)制差模塊，則只要在步驟718將該模塊添加到新列表。如果是二進(jìn)制差模塊，則需要向舊代碼應(yīng)用這些差，對每一分段各個挨次地執(zhí)行步驟710-716。
更具體地，如上所述，增量/差包包含一個或多個二進(jìn)制差文件，每一二進(jìn)制差文件對應(yīng)于一特定的文件/模塊。該差文件基于它在安裝時刻被更新的特定基線版本，并且二進(jìn)制差文件通常小于所得版本的整個正規(guī)文件，由此，它改進(jìn)了下載時間/成本，并減少了安裝過程中需要的臨時存儲額外開銷。二進(jìn)制差文件在構(gòu)建時刻基于檢測兩個不同的規(guī)范包之間的文件/模塊的差異來生成。如果文件是可執(zhí)行模塊，則它們由鏈接器處理，并位于鏈接器定義的地址中。它們尚未被重定位到最終的位置，這如上所述地將在安裝時刻在設(shè)備上完成。
為使可執(zhí)行模塊的二進(jìn)制差能夠應(yīng)用到已在設(shè)備上的基線版本，該基線版本需要被解除重定位，返回到從其計(jì)算該二進(jìn)制差的鏈接器生成的基地址。一旦向模塊的解除重定位版本應(yīng)用了該二進(jìn)制差，它可被重新定位到適當(dāng)?shù)幕A(chǔ)虛擬地址。解除重定位和重定位的過程是相同的，并通過將模塊的基地址移位到特定的位置來完成。
當(dāng)處理了每一包之后，內(nèi)核更新繼續(xù)到圖7B的步驟724，其中，尚未被修改的任何模塊被添加到新模塊列表。在這一點(diǎn)上，舊文件列表包含將不被更新的模塊和文件；這些需要被解除修正，返回到原始基地址，使得存在可被整體處理的未修正模塊和文件的一個統(tǒng)一列表。舊文件列表中出現(xiàn)在新設(shè)備清單文件中的對象被轉(zhuǎn)移到新文件列表。注意，如果文件要被刪除，則它不在新設(shè)備清單文件中出現(xiàn)，并因此不被放入新模塊列表中。
存儲器分配和修正在步驟726和728執(zhí)行，并且在步驟730將新的原地執(zhí)行內(nèi)核映象寫回閃存中，這也由盤映象工具完成，并在romimage.dll中實(shí)現(xiàn)(如下所述)。romimage中存在一個功能，它采用模塊列表，并通過分配新緩沖器構(gòu)建新映象、循環(huán)通過模塊列表以復(fù)制由數(shù)據(jù)指針指定的適當(dāng)位置處的分段數(shù)據(jù)并將頭部和文件名串復(fù)制到目錄(TOC)中指定的正確的位置，來構(gòu)建新映象。如后文所描述的，在映象的末端寫新TOC，并更新pTOC指針以指向放置新TOC的位置。同樣如后文所描述的，跟蹤插槽0中的數(shù)據(jù)分段帶用于NK/XIP映象，它與IMGFS帶連接，并在IMGFS更新過程中被輸出到包含ROMINFO結(jié)構(gòu)的IMGFS文件中。
在向閃存寫出任何內(nèi)容時，該過程在日志文件中記錄寫正在進(jìn)行中。一旦寫完成，它被記錄，由此，如果在刪除備份文件之前丟失電源，也知道正確的狀態(tài)。
如果整個過程都是成功的，則在步驟732刪除備份文件，這包括在刪除該文件之后向日志文件寫入XIP分區(qū)完成。如果在NK/XIP更新過程的任一步驟出現(xiàn)了錯誤，諸如如果映象增長超過了分區(qū)的大小，則恢復(fù)該映象的備份版本，且合適的用戶界面指示在更新過程中出現(xiàn)錯誤并恢復(fù)原始映象。如果不能成功地寫入備份版本(如，在閃存錯誤中)，則提供一個不同的UI消息以指示在更新過程中出現(xiàn)了錯誤，但是原始映象無法被恢復(fù)并可能被破壞。
同樣，記錄更新的狀態(tài)用于UpdateBin。注意，這是不同的，更新應(yīng)用程序所使用的日志文件是內(nèi)部地用于事務(wù)記錄的。
在這一點(diǎn)上，存在組成該映象的模塊和文件的單個文件列表。這與由盤映象工具結(jié)合romimage.dll所執(zhí)行的初始安裝相同，如在上述名為“以存儲技術(shù)抽象方式在文件內(nèi)創(chuàng)建文件系統(tǒng)”的美國專利申請中所描述的。
在較高的級別上，包安裝過程涉及提取包內(nèi)容并將其應(yīng)用到設(shè)備。然而，這些機(jī)制包括主要圍繞代碼修正或代碼重定位的概念的若干步驟。本發(fā)明在安裝時刻在設(shè)備上執(zhí)行修正和重定位，而非在構(gòu)建時刻在構(gòu)建系統(tǒng)中執(zhí)行。一個益處是對特定系統(tǒng)的包安裝能力，因?yàn)榘惭b不需要整個設(shè)備映象在構(gòu)建時刻可用。相反，它允許包更新被作為從安裝在設(shè)備上的特定操作系統(tǒng)映象配置很大程度隔離的實(shí)體來處理。
為使可執(zhí)行模塊可被重定位，模塊需要包含指導(dǎo)定位器在模塊的基地址定位改變時在需要被更新的模塊內(nèi)尋址的信息。映象更新模塊利用重定位信息編碼模式以在可執(zhí)行模塊本身內(nèi)以壓縮的形式提供這一信息。
如在上述美國專利申請“自描述軟件映象更新組件”中所一般描述的，RelMerge工具將模塊(.EXe或.DLL)轉(zhuǎn)化成適合包括在包內(nèi)，并因此可被安裝到設(shè)備的格式。這包括將重定位信息轉(zhuǎn)化成更適合在設(shè)備上長期儲存的壓縮格式，并將文件頭部轉(zhuǎn)化成由設(shè)備上的ROMFS文件系統(tǒng)使用的_rom變量。另外，當(dāng)重新布置時，任何過剩的填充也被從文件的所有分段中移除。
一旦用這一信息編碼，可改變可執(zhí)行模塊的基礎(chǔ)虛擬地址，并可修改模塊內(nèi)所有相關(guān)的地址引用，以解決基地址中的變化。重定位過程利用在設(shè)備和臺式機(jī)之間共享的代碼庫。在后一情況下，它用于創(chuàng)建初始制造映象，使得在代碼模塊上執(zhí)行實(shí)際的重定位，并也用于創(chuàng)建當(dāng)安裝每一更新模塊時所使用的虛擬地址空間的列表，由此，允許API的消費(fèi)者相信模塊重定位不會重疊。通過盤映象工具和romimage.dll組件創(chuàng)建初始制造映象在上述名為“以存儲技術(shù)抽象方式在文件內(nèi)創(chuàng)建文件系統(tǒng)”的相關(guān)的美國專利申請中有描述。
一般而言，虛擬/物理分配和修正與盤映象工具相同地工作，即，定位來自NK/XIP映象的舊目錄(TOC)并定位舊ROMINFO。在映象中的固定位置(如，偏移0x44)上定位指向TOC的指針。從稱為“.rom”的IMGFS文件中讀取舊ROMINFO結(jié)構(gòu)。
為分配虛擬地址，插槽0分配器以插槽0的頂端開始，并基于IMGFSROMINFO結(jié)構(gòu)中的值dwSlot_0_DllBase結(jié)束。插槽1分配器以插槽1的頂端開始，并基于IMGFS ROMINFO結(jié)構(gòu)中的值dwSlot_1_DllBase的值結(jié)束。然后將代碼和數(shù)據(jù)修正成新的VA分配，并且令整個模塊列表可用。壓縮被標(biāo)記成壓縮的分段，并將其大小記錄在模塊對象中。
為向映象分配物理空間，對RAM使用RAMIMAGE，并對閃存使用ROMIMAGE。對于RAM，RAMIMAGE物理分配器使用舊TOC的physfirst作為物理分配器的起始地址。物理分配器的末端最初被指定為舊TOC的ulRAMEnd。對于RAMIMAGE，由物理分配器返回RamStart＝PhysFirst+PhysLength(映象所需的實(shí)際長度)；確定副本分段的虛擬地址位置從RamStart開始，并且從那里開始，涉及副本分段的文本/數(shù)據(jù)被修正。
對于ROM，ROMIMAGE物理分配器使用舊TOC的physfirst用于物理分配器的起始地址，而物理分配器的末端通過使用GetPartitionInfo獲取閃存上的分區(qū)的長度來確定。
注意，更新的TOC在物理分配過程中生成。
與XIP分區(qū)不同，在IMGFS分區(qū)中，不重新作出整個映象，因?yàn)檫@太大以至于無法備份。相反，IMGFS文件系統(tǒng)用于向個別的模塊和文件應(yīng)用更新，每次更新一個。此外，注意，個別的模塊和文件可能太大，以至于無法作為一個整體來完成，則可通過較小的塊應(yīng)用更新，如后文參考圖9所描述的。
IMGFS更新使用NT更新所使用的同一文件列表，盡管當(dāng)過程前進(jìn)時一個列表將被更新。如后文所描述的，IMGFS首先模擬更新進(jìn)程，需要兩次通過該過程。在第一遍中，IMGFS和更新應(yīng)用程序都不向閃存提交任何內(nèi)容。如果模擬成功，則運(yùn)行第二遍以實(shí)際提交改變。如果模擬失敗，則在重新運(yùn)行包確認(rèn)器之后重試模擬，并傳入不包括失敗的包的包列表。然后用包確認(rèn)器返回的新列表再次運(yùn)行模擬。重試模擬，直到模擬成功，或者沒有可應(yīng)用的任何包為止。這預(yù)防可能在盡管有破壞但仍被簽署的包內(nèi)出現(xiàn)的數(shù)據(jù)破壞。
圖8A和8B示出了系統(tǒng)分區(qū)更新的一般邏輯，其中，更新應(yīng)用程序與映象文件系統(tǒng)驅(qū)動程序(IMGFS)的讀/寫版本接口，以管理系統(tǒng)分區(qū)。注意，在典型系統(tǒng)的正常(非更新)操作中，系統(tǒng)分區(qū)對于IMGFS驅(qū)動程序是只讀的(并且閃存被鎖定)。此外，注意，與內(nèi)核更新不同，系統(tǒng)更新不作為整體來備份，盡管事務(wù)日志可將設(shè)備恢復(fù)到故障(如電源故障)之前它在系統(tǒng)更新過程中的位置，并且系統(tǒng)更新可以從那一點(diǎn)上繼續(xù)進(jìn)行。
在步驟800，掃描系統(tǒng)分區(qū)(imgfs區(qū)域)中的現(xiàn)有模塊，并將它們添加到虛擬地址(VA)分配器。在掃描過程中，該過程也檢測刪除情況。更具體地，當(dāng)使用現(xiàn)有設(shè)備清單文件反復(fù)通過IMGFS中的模塊時，該過程檢查來看文件是否在該包的新設(shè)備清單文件中出現(xiàn)。如果不是，則將該文件從IMGFS分區(qū)中刪除，并且過程繼續(xù)下一文件。如果是，則從新設(shè)備清單文件獲取新模塊標(biāo)志，并且使用IOCTL_BIN_GET_E32和IOCTL_BIN_GET_O32將模塊頭部加載到模塊結(jié)構(gòu)中。注意，在此時，不讀入用于模塊和文件數(shù)據(jù)的數(shù)據(jù)，因?yàn)椴⒉恍枰?。一旦讀入了每一模塊頭部，則將該模塊列表傳遞到分配器以保留虛擬地址(包括從存儲在閃存中的保留表中得知的保留的分段)。
一旦掃描了現(xiàn)有模塊，并且定義了當(dāng)前分配的虛擬地址，該過程已準(zhǔn)備好開始更新。為此，過程循環(huán)通過每一包(通過步驟802和828)，并循環(huán)(通過步驟804和826)通過包內(nèi)的每一文件，逐個處理每一文件。文件以大小的凈增益的順序來處理，從收縮最多的文件開始，并以增長最多的文件結(jié)束。文件大小的增量通過將舊設(shè)備清單文件與新設(shè)備清單文件相比較來確定。
如果在該過程中丟失電源，則日志文件將確切地告知該過程停留在哪一包以及包內(nèi)的哪一文件上。該過程在所停留的文件處繼續(xù)進(jìn)行，在電源故障這一點(diǎn)上已完成的更新文件被作為現(xiàn)有文件處理。為恢復(fù)，更新過程中的任何新模塊不被包括在初始保留中，而舊模塊在保留中。舊模塊虛擬地址空間被如常地解除分配。如果新頭部已被寫出，則它將包含用于該新模塊的虛擬地址空間分配。在這一情況下，使用Reserve(保留)函數(shù)將其添加到虛擬地址空間分配器。如果新頭部尚未被寫出，則使用Allocate(分配)函數(shù)如常地分配新虛擬地址空間。
上述處理的一部分包括(對于可執(zhí)行文件，而非數(shù)據(jù)文件)更新用于更新模塊的虛擬地址分配，這通過確定虛擬地址是否改變，并且如果是，則如步驟806所示，解除分配舊虛擬地址空間并且用于新模塊分配虛擬地址空間來完成。如果虛擬地址大小改變，則調(diào)用Deallocate(解除分配)函數(shù)從分配器移除舊虛擬地址空間，并調(diào)用Allocate(分配)函數(shù)為新模塊分配新虛擬地址空間，根據(jù)代碼或數(shù)據(jù)傳入適當(dāng)?shù)膶R要求。解除分配可對應(yīng)于刪除模塊的命令，在這一情況下，通過步驟808和824刪除舊模塊，(但是如果它是剛安裝的新模塊，則不刪除)。如果不是刪除命令，則步驟810在IMGFS調(diào)用CreageFile(創(chuàng)建文件)函數(shù)，例如在命名新文件時使用new_<module_name>.<module_extension>，以在映象文件系統(tǒng)中創(chuàng)建新文件；(為在電源在這一操作附近故障時恢復(fù)，如果該文件已存在，則不再創(chuàng)建它)。
對于可執(zhí)行文件，步驟812通過使用IOCTL_BIN_SET_E32和IOCTL_BIN_SET_O32將新頭部讀入模塊對象中，并用新虛擬地址空間分配更新該頭部來向可執(zhí)行文件寫入適當(dāng)?shù)念^部，如步驟812所示的。每一操作在IMGFS中是原子的。在這一點(diǎn)上，頭部應(yīng)當(dāng)是完整的。不管數(shù)據(jù)指針(dataptr)(為0)，因?yàn)楫?dāng)內(nèi)核請求E32/O32時IMGFS偽造該值。頭部是規(guī)范形式，甚至是在二進(jìn)制差文件中。
如果在寫頭部時丟失電源，如果兩個頭部都存在，則不需要完成任何恢復(fù)。如果僅寫出了E32頭部，則僅需要再次寫出O32頭部。每一頭部的存在可通過IOCTL_BIN_GET_E32和IOCTL_BIN_GET_O32來知道。
為應(yīng)用更新，注意到對文件的更新可以是規(guī)范形式或二進(jìn)制差形式。如果更新的文件不是模塊，則以與個別分段相同的方式處理該文件的數(shù)據(jù)。如果該文件是模塊，則以凈增益的順序處理每一分段，每次處理一個，以收縮最多的分段開始。首先處理.creloc分段。每一分段被寫到一個新流。如果文件是常規(guī)數(shù)據(jù)文件，則該數(shù)據(jù)被寫入默認(rèn)流中。
如果如在步驟814所評估的，模塊是規(guī)范更新，則步驟816-822處理模塊中的每一分段，包括將整個分段重定位到由虛擬分配器所分配的地址(步驟818)，并將整個分段作為新的流寫入新IMGFS文件中(步驟820)。然后在步驟824刪除舊模塊，除非舊模塊實(shí)際上是新模塊。
在規(guī)范的情況下，通過獲取被寫出的文件中的每一流的大小，并將其與規(guī)范文件中的該分段的大小相比較，來執(zhí)行對電源故障的恢復(fù)。如果新文件中的流小于規(guī)范文件，則這就是過程所停留之處，并可繼續(xù)進(jìn)行在數(shù)據(jù)上復(fù)制。
在二進(jìn)制差的情況下，每次對一個塊完成patchbin(打二進(jìn)制補(bǔ)丁)程序(如后文參考圖9所描述的)，其中，一個塊等于頁/扇區(qū)大小。這是由于可能沒有足夠的閃存空間來同時保留分段的舊和新版本。可以如由二進(jìn)制差文件所指定的任何順序創(chuàng)建新文件的塊，使得可以通過優(yōu)先使用閃存空間來完成patchbin的過程。當(dāng)創(chuàng)建新塊時，舊塊可被解除分配，因?yàn)樗鼈儾辉傩枰?br> 為此，如果在步驟814，模塊不是規(guī)范更新，則過程分支到圖8B的步驟832，其中，結(jié)合步驟852，循環(huán)通過該模塊中的每一分段，以在逐塊的基礎(chǔ)上應(yīng)用二進(jìn)制更新。更具體地，步驟834為該分段在新模塊文件中創(chuàng)建稀疏流，并且將舊分段讀入RAM中(步驟836)。整個舊分段被重新定位回到原始的基地址(步驟838)。
對于二進(jìn)制差文件中的每一新塊(步驟840和850)，基于二進(jìn)制差命令構(gòu)建新塊(步驟842)。新塊在步驟844被重定位到由虛擬地址分配器分配的地址上，并且在步驟846被寫出到稀疏流中。舊文件流中不再需要的任何舊塊被解除分配，如由步驟848所示的。塊更新的概念也在下文參考圖9描述。
在二進(jìn)制差的情況下，電源故障通過縮小停留在哪一分段的范圍來處理，這通過將流大小與頭部中所指定的大小相比較來完成。一旦確定了分段，如常創(chuàng)建patchbin的實(shí)例。當(dāng)順序返回下一塊時(patchbin輸出必需是可再現(xiàn)/可確定的)，檢查該塊是否被提交。由于塊寫是原子的，無法提交部分塊。如果塊已被提交，則丟棄從patchbin返回的數(shù)據(jù)，并且執(zhí)行核實(shí)以檢查適當(dāng)?shù)呐f塊已被解除提交。一旦找到所停留的塊，(即，尚未被提交的塊)，則過程如常繼續(xù)。
為結(jié)束，如果這是現(xiàn)有的文件或塊，并且是二進(jìn)制差情況，則刪除舊模塊(在規(guī)范情況下，該文件已被刪除)，并且日志文件記錄該模塊已完成。如果包已被完成，則代之以記錄這一情況。當(dāng)完成了所有的包時，用更新的ROMINFO結(jié)構(gòu)更新.rom文件，它包含插槽0基礎(chǔ)、插槽1基礎(chǔ)和用于NK/XIP和IMGFS映象兩者的插槽0數(shù)據(jù)帶。
如果在IMGFS更新過程的任一步驟中出現(xiàn)錯誤，如，如果二進(jìn)制差沒有足夠的閃存塊可用，則取消更新過程，并且不嘗試恢復(fù)，因?yàn)樗赡苁菬o法恢復(fù)的，并且顯示適當(dāng)?shù)南?。注意，預(yù)先運(yùn)行模擬可避免這一問題。
如所見的，對內(nèi)核分區(qū)的更新從更新到系統(tǒng)分區(qū)被不同地處理，盡管從構(gòu)建和包裝觀點(diǎn)來看，它們是相同的。更具體地，當(dāng)更新內(nèi)核分區(qū)時，從閃存中取出某些NK.NB0(簽署的內(nèi)核分區(qū)映象)文件到RAM中、在適當(dāng)時更新并修正成分組件、然后將修改的.NB0內(nèi)容以連續(xù)的塊寫回閃存中。這允許在需要時跳過任何壞塊。
依照本發(fā)明的另一方面，如上所述，這些機(jī)制考慮如何應(yīng)用二進(jìn)制差文件的優(yōu)化順序的概念。如所理解的，需要某些臨時填充存儲器，以向基線映象應(yīng)用二進(jìn)制差文件，并由此生成所得的更新的模塊/文件。在構(gòu)建時，當(dāng)生成二進(jìn)制差文件時，在所得的映象上運(yùn)行排列過程，以排列更新二進(jìn)制差文件中的塊的順序，使得保留必要的可用臨時填充存儲器到某一指定的最大值。通過在構(gòu)建系統(tǒng)上執(zhí)行這一優(yōu)化操作，本發(fā)明確保了如果設(shè)備具有足夠的存儲器用于映象的整體增長(或收縮)，并且它具有必要的臨時填充空間，則設(shè)備一定具有足夠的存儲器來完成更新過程。在開始更新之前，在確認(rèn)過程中執(zhí)行大小檢查。
圖9一般表示了塊更新概念。一般而言，系統(tǒng)文件較大，并且由此，如果整體創(chuàng)建新文件，并且向舊文件整體應(yīng)用二進(jìn)制差，則會消耗大量的臨時存儲(大于可用的臨時存儲)。相反，向要更新的文件的現(xiàn)有塊應(yīng)用差更新，能獲得新的更新的塊，將更新的塊復(fù)制到更新的文件流中，并在不再需要時解除分配舊塊。
為實(shí)現(xiàn)塊更新，構(gòu)建舊塊和新塊之間的依賴圖，這由圖9的圖900來一般表示。如所理解的，差文件902將被應(yīng)用到由該圖中的節(jié)點(diǎn)所表示的數(shù)據(jù)的實(shí)際塊中。在一個實(shí)現(xiàn)中，塊為四千字節(jié)大小，并且任一時刻最多允許32個塊，這意味著僅需要128千字節(jié)可用來確保系統(tǒng)可被更新。注意，上述的示例塊大小和整體限制是任意值，但是需要由系統(tǒng)更新和設(shè)備的更新應(yīng)用程序的提供者同意。在特定更新無法滿足所同意的限制的情況下，在銷售商處構(gòu)建更新的過程中，需要由銷售商斷開依賴鏈接(對這樣的塊不需要非差更新)。
如圖9所示，單個舊更新塊可提供一個或多個新更新塊的依賴數(shù)據(jù)(向這些數(shù)據(jù)應(yīng)用差文件)，并且新更新塊可依賴于一個或多個舊更新塊。一般而言，更新通過向舊塊應(yīng)用適當(dāng)?shù)囊粋€或多個差文件，直到應(yīng)用了該舊塊的每一差文件來進(jìn)展。在這一時刻，可斷開依賴鏈接(如，如由圖9所示，通過斷開舊塊X和新塊Y之間的鏈接)，由于舊塊不再為新塊所需。由于這是與舊塊X相關(guān)聯(lián)的唯一鏈接，因此可解除分配舊塊X以釋放空間用于另一塊。同樣，由于在向舊塊應(yīng)用了差文件之后斷開依賴鏈接，當(dāng)新塊沒有到舊塊的依賴鏈接時，即，當(dāng)新塊完全通過差更新過程被寫入時，該新塊可在適當(dāng)時被復(fù)制到閃存，并從RAM中解除分配，以釋放空間用于另一塊。注意，可在同一時刻解除分配多個塊。
如可容易地理解的，應(yīng)用差更新的順序可幫助存儲器的釋放。一般而言，該順序?yàn)槭紫认驅(qū)哂凶疃嘁蕾囨溄拥男聣K具有最少依賴鏈接的舊塊應(yīng)用差更新。一種算法對具有最高計(jì)數(shù)新塊的最低計(jì)數(shù)舊塊執(zhí)行二級搜索(如，鏈接計(jì)數(shù)器數(shù)組的搜索)。
對于對塊更新執(zhí)行預(yù)閃存模擬，由于整個文件可能不在模擬中在任意時刻存在，因此基于要寫入的每一塊計(jì)算校驗(yàn)和，并且對照每一更新的校驗(yàn)和核實(shí)所得的校驗(yàn)和。如果該模擬生成的校驗(yàn)和通過，則可執(zhí)行對閃存的實(shí)際更新。
轉(zhuǎn)向更新保留分段，圖10示出了保留分段更新(如，在分區(qū)之外)以類似于NK分區(qū)更新的方式使用同一更新組件完成。通過步驟1000和1016，通過處理包中的每一文件(步驟1002和1014)來處理每一保留相關(guān)包更新，確定該文件是否為bindiff(二進(jìn)制差)模塊。如果不是，則只要在步驟1010和1012將文件數(shù)據(jù)從文件讀出并寫入保留的區(qū)域中。如果是二進(jìn)制差模塊，則讀現(xiàn)有的區(qū)域(如，讀入RAM)中并在向保留的區(qū)域?qū)懟馗聰?shù)據(jù)之前向其應(yīng)用二進(jìn)制差，如由步驟1006、1008和1012一般表示的。
當(dāng)以適當(dāng)?shù)捻樞?按照包版本)應(yīng)用每一排隊(duì)的包的包內(nèi)容，并且更新完成時，包文件可任選地從用戶存儲中移除，或被標(biāo)記為完成。在這一時刻，一旦確認(rèn)的包的內(nèi)容被安裝到適當(dāng)?shù)拈W存分區(qū)中，更新應(yīng)用程序通過禁用更新模式(清除閃存更新標(biāo)志)完成其工作，并且重啟設(shè)備。在以前，初始程序加載器檢測當(dāng)前系統(tǒng)模式，但是此次，由于清除的標(biāo)志，以鎖定的閃存來如上所述地引導(dǎo)更新的操作系統(tǒng)映象，并且安裝完成。
依照本發(fā)明的一個方面，提供了故障保險(xiǎn)/恢復(fù)更新方法。為此，映象更新設(shè)計(jì)的一部分提供了如由于意外的電源丟失而使更新過程被中斷的情況下的故障保險(xiǎn)恢復(fù)。實(shí)現(xiàn)故障保險(xiǎn)恢復(fù)的方法包括通過記入日志和文件系統(tǒng)人為因素(如，卷進(jìn)恢復(fù))使得重新進(jìn)入令更新加載器和更新應(yīng)用程序，并能夠決定更新操作停留在何處。同時調(diào)節(jié)的是支持向文件寫入更新而無需完全解除提交舊副本直到向存儲提交了新更新(這以系統(tǒng)分區(qū)中的子文件增量完成，如，塊)的事務(wù)文件系統(tǒng)?？蓤?zhí)行到提交到存儲這一點(diǎn)上的整個安裝過程的模擬以確保已實(shí)行了幾乎所有相關(guān)的代碼路徑，而將實(shí)際更新上的故障模式降低到硬件(如，閃存故障)中的故障或低級閃存軟件例程中的可能故障。提供NK/內(nèi)核的備份和保留的(如，無線電)區(qū)域，使得在更新失敗的情況下，在某些具體數(shù)量的重試之后，可恢復(fù)原始映象分區(qū)內(nèi)容的備份，并中止安裝(即，卷回恢復(fù))。
更新應(yīng)用程序跟蹤安裝進(jìn)展、在意外中斷的情況下重新獲得它所停留之處、并備份(并可能恢復(fù))NK/內(nèi)核和保留的區(qū)域。更新應(yīng)用程序更新RAMIMAGE、ROMIMAGE、IMGFS和保留的映象。RAMIMAGE和ROMIMAGE分區(qū)以與臺式機(jī)盤映象工具生成分區(qū)的同一方式生成，即，IMGFS分區(qū)通過用現(xiàn)有的布局工作以及對IMGFS和分配器作出調(diào)用以虛擬和物理地正確排列更新的模塊來更新。上文參考圖10所描述的保留更新通過覆寫整個區(qū)域來作出。
在一個實(shí)現(xiàn)中，當(dāng)更新應(yīng)用程序開始時，它假定要安裝的包位于臨時保存目錄中，如用戶存儲中的更新應(yīng)用程序輸入文件中所指定的，它包含用于更新應(yīng)用程序的輸入。更新應(yīng)用程序輸入文件的路徑在注冊表中指定。更新應(yīng)用程序不關(guān)注包存儲在何處，無論它是內(nèi)部數(shù)據(jù)存儲還是外部存儲卡，只要提供了完整的路徑用于保存目錄。同時提供的是到用于更新的位圖文件的路徑；注意，正常的操作系統(tǒng)代碼不在運(yùn)行，并由此，為用戶界面目的提供了位圖(如，示出進(jìn)度條、正在更新哪些文件、錯誤消息等等)。
更新應(yīng)用程序通過將保存目錄路徑傳遞到包確認(rèn)器開始，它返回指定安裝包的順序的列表，如在上述名為“確定對安裝有效的最大依賴軟件更新集”的相關(guān)美國專利申請中所描述的。然后，更新加載器處理重復(fù)通過每一包，并應(yīng)用適當(dāng)?shù)母?XIP、IMGFS和/或保留，如上文參考圖6所描述的。
更新應(yīng)用程序可被認(rèn)為具有若干進(jìn)程/組件，包括負(fù)責(zé)對NK/XIP分區(qū)的更新的NK/XIP更新進(jìn)程。該分區(qū)中的映象可以是ROMIMAGE或RAMIMAGE(其中，ROMIMAGE是直接從閃存中執(zhí)行并需要NOR閃存的映象，而RAMIMAGE是被加載到RAM并可儲存在NOR或NAND閃存中的映象)。無論映象的類型如何，在讀和寫時，區(qū)域更新直接與塊驅(qū)動程序接口。
映象的另一進(jìn)程/組件是IMGFS更新，它負(fù)責(zé)對操作系統(tǒng)分區(qū)的更新，由映象文件系統(tǒng)(IMGFS)管理。保留更新進(jìn)程負(fù)責(zé)對無線電或其它保留區(qū)域的更新。保留區(qū)域更新在讀和寫時直接與塊驅(qū)動程序接口。
Romimage是當(dāng)制造設(shè)備時提供初始安裝映象的共享組件(與臺式機(jī)盤映象工具共享)，并負(fù)責(zé)虛擬和物理(存儲)分配和模塊修正。Romimage.dll包含用于創(chuàng)建并管理多個分配器的Allocator(分配器)類分層結(jié)構(gòu)和功能、用于創(chuàng)建并管理文件列表的File(文件)類分層結(jié)構(gòu)(用于儲存關(guān)于文件或模塊的元數(shù)據(jù))和功能、以及支持更新和構(gòu)建過程的功能。Patchbin組件提供應(yīng)用二進(jìn)制差更新來生成新文件的過程。舊模塊數(shù)據(jù)和二進(jìn)制差作為輸入提供給該組件，并且其輸出是用于新模塊的數(shù)據(jù)?？商峁︰I組件以在更新過程中顯示適當(dāng)?shù)挠脩艚缑鏀?shù)據(jù)。注意，可視內(nèi)容可基于操作系統(tǒng)地區(qū)設(shè)置預(yù)先生成。
NK/XIP更新過程可以是由更新應(yīng)用程序的主函數(shù)調(diào)用的函數(shù)，它采用NK/XIP包的列表來應(yīng)用。對NK/XIP分區(qū)的更新需要更新應(yīng)用程序重新作出完整的映象(實(shí)際上為設(shè)備上的盤映象工具過程)。在NK/XIP更新過程中，維護(hù)舊文件列表和新文件列表。舊文件列表用NK/XIP分區(qū)中的當(dāng)前模塊來初始化，該信息結(jié)合包一起使用來創(chuàng)建新文件列表作為最終結(jié)果。新文件列表包含創(chuàng)建映象所需的信息(頭部、分段數(shù)據(jù)、標(biāo)志等等)，并且該列表被傳遞到虛擬和物理分配器來重新執(zhí)行分配過程。
上文描述的圖7A和7B輸出示出了內(nèi)核區(qū)域如何被更新。為概括圖7A和7B的步驟，該過程將整個XIP(或其它)區(qū)域讀入RAM中并將其備份為用戶存儲中的壓縮文件、掃描XIP區(qū)域中的現(xiàn)有模塊以讀取頭部和其它元數(shù)據(jù)并構(gòu)建更新模塊和文件的未修正版本。該過程然后將未被修改的模塊和文件的剩余部分添加到新模塊列表、執(zhí)行虛擬/物理分配和模塊修正、并將新XIP映象寫回閃存中。
該步驟中的故障保險(xiǎn)方法是相當(dāng)明了的，因?yàn)椴幌蜷W存提交任何內(nèi)容直到過程結(jié)束。因此，如果在寫入新映象之前出現(xiàn)電源故障，只需重新執(zhí)行該過程。如果在寫出新映象時出現(xiàn)電源故障，舊映象的備份副本仍存在，并可用于恢復(fù)映象(如果日志文件指定新映象處于被寫出的過程中，則可使用壓縮的備份文件來恢復(fù)舊映象的副本)。日志文件記錄事務(wù)中的步驟，令其明了以知道過程在何處失敗。
權(quán)利要求
1.在計(jì)算設(shè)備中，一種方法，其特征在于，它包括確定是將所述設(shè)備引導(dǎo)到操作系統(tǒng)模式還是更新模式；以及當(dāng)所述設(shè)備被引導(dǎo)到所述更新模式時，對所述設(shè)備存儲中的映象執(zhí)行至少一個更新，同時將所述更新的狀態(tài)記入日志，以便能夠從每一更新過程中可能出現(xiàn)的任一故障中恢復(fù)。
2.如權(quán)利要求1所述的方法，其特征在于，確定是將所述設(shè)備引導(dǎo)到操作系統(tǒng)模式還是更新模式包括檢查一在重啟之前設(shè)置的標(biāo)志。
3.如權(quán)利要求1所述的方法，其特征在于，所述映象被劃分成至少兩個分區(qū)，并且其中，通過為一選擇的分區(qū)構(gòu)建一替換映象、并將所述替換映象覆寫到所述分區(qū)中的現(xiàn)有映象上，更新所選擇的分區(qū)。
4.如權(quán)利要求3所述的方法，其特征在于，它還包括將所述分區(qū)中的所述現(xiàn)有映象備份成一備份映象，確定寫所述替換映象是否成功地完成，如果不是，則從所述備份映象恢復(fù)所述現(xiàn)有映象。
5.如權(quán)利要求4所述的方法，其特征在于，備份所述現(xiàn)有映象包括以壓縮形式儲存所述備份映象。
6.如權(quán)利要求1所述的方法，其特征在于，所述映象被劃分成至少兩個分區(qū)，并且其中，通過單獨(dú)地更新所述映象中的至少兩個組件來更新一選擇的分區(qū)。
7.如權(quán)利要求6所述的方法，其特征在于，所述分區(qū)之一是系統(tǒng)分區(qū)，并且其中，單獨(dú)地更新所述映象中的至少兩個組件包括將操作系統(tǒng)文件寫入所述分區(qū)中。
8.如權(quán)利要求1所述的方法，其特征在于，執(zhí)行所述至少一個更新包括向一現(xiàn)有組件應(yīng)用一二進(jìn)制差文件。
9.如權(quán)利要求8所述的方法，其特征在于，向現(xiàn)有組件應(yīng)用二進(jìn)制差文件包括向所述現(xiàn)有組件的一個子集應(yīng)用所述二進(jìn)制差文件的一個子集。
10.如權(quán)利要求9所述的方法，其特征在于，所述子集包括一具有確定大小的數(shù)據(jù)塊。
11.如權(quán)利要求9所述的方法，其特征在于，執(zhí)行對映象的至少一個更新包括在提交所述更新之前模擬一更新過程、及確定所述模擬成功。
12.如權(quán)利要求1所述的方法，其特征在于，一組更新中的所述更新在包中的文件和文件上個別地執(zhí)行，并且所述個別包和文件信息被記入日志，使得在任一故障之后，訪問所述日志文件確定所述故障出現(xiàn)在哪一包以及包中哪一文件上。
13.一個或多個具有計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)可讀媒質(zhì)，當(dāng)所述指令被執(zhí)行時，執(zhí)行權(quán)利要求1所述的方法。
14.在計(jì)算環(huán)境中，一種方法，其特征在于，它包括將一操作系統(tǒng)映象分裂成單獨(dú)可更新的分區(qū)；以及與另一分區(qū)隔離地更新至少一個分區(qū)。
15.如權(quán)利要求14所述的方法，其特征在于，更新至少一個分區(qū)包括將計(jì)算設(shè)備引導(dǎo)到更新模式。
16.如權(quán)利要求14所述的方法，其特征在于，與另一分區(qū)隔離地更新至少一個分區(qū)包括為第一分區(qū)構(gòu)建一替換映象并將所述替換映象覆寫到所述第一分區(qū)中的現(xiàn)有映象上、及通過單獨(dú)地更新第二分區(qū)中的映象的至少兩個組件來更新所述第二分區(qū)。
17.如權(quán)利要求16所述的方法，其特征在于，它還包括將所述第一分區(qū)中的所述現(xiàn)有映象備份成一備份映象，確定寫所述替換映象是否成功完成，如果不是，則從所述備份映象恢復(fù)所述映象。
18.如權(quán)利要求17所述的方法，其特征在于，備份所述現(xiàn)有映象包括以壓縮的形式儲存所述備份映象。
19.如權(quán)利要求16所述的方法，其特征在于，更新所述第二分區(qū)包括將所述每一更新的組件的身份記入一日志文件中，使得如果出現(xiàn)故障，訪問所述日志文件確定所述故障出現(xiàn)在哪一組件上。
20.如權(quán)利要求16所述的方法，其特征在于，更新所述第二分區(qū)包括向一現(xiàn)有組件應(yīng)用一二進(jìn)制差文件。
21.如權(quán)利要求20所述的方法，其特征在于，向現(xiàn)有組件應(yīng)用二進(jìn)制差文件包括向所述現(xiàn)有組件的一個子集應(yīng)用所述二進(jìn)制差文件的一個子集。
22.如權(quán)利要求21所述的方法，其特征在于，所述子集包括一具有確定大小的數(shù)據(jù)塊。
23.如權(quán)利要求16所述的方法，其特征在于，更新所述第二分區(qū)包括在向所述第二分區(qū)提交更新之前模擬更新過程、及確定所述模擬成功。
24.一個或多個具有計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)可讀媒質(zhì)，當(dāng)所述指令被執(zhí)行時，執(zhí)行權(quán)利要求14所述的方法。
25.在計(jì)算設(shè)備中，一種系統(tǒng)，其特征在于，它包括一引導(dǎo)機(jī)制；以及一更新加載器，在檢測到一待決更新時所述引導(dǎo)機(jī)制引導(dǎo)到所述更新加載器，所述更新加載器包括所述設(shè)備代碼中對所述設(shè)備的受保護(hù)存儲器具有寫訪問權(quán)限的唯一實(shí)體，所述受保護(hù)的存儲器包括至少兩個分區(qū)，并且所述更新加載器單獨(dú)地更新每一分區(qū)。
26.如權(quán)利要求25所述的系統(tǒng)，其特征在于，它還包括一確認(rèn)進(jìn)程，其中，在引導(dǎo)到所述更新加載器之前，所述確認(rèn)進(jìn)程確認(rèn)至少一個更新包，如果所述至少一個更新包有效，則所述確認(rèn)進(jìn)程將每一有效包排隊(duì)來更新，并設(shè)置一所述引導(dǎo)機(jī)制用于檢測所述待決更新的機(jī)制。
27.如權(quán)利要求26所述的系統(tǒng)，其特征在于，所述確認(rèn)進(jìn)程通過核查每一包被正確地簽署來確認(rèn)所述至少一個更新包。
28.如權(quán)利要求26所述的系統(tǒng)，其特征在于，所述確認(rèn)進(jìn)程通過核查每一包被正確地構(gòu)造來確認(rèn)所述至少一個更新包。
29.如權(quán)利要求25所述的系統(tǒng)，其特征在于，所述引導(dǎo)機(jī)制基于一在重啟之前設(shè)置的標(biāo)志值將所述設(shè)備引導(dǎo)到所述更新模式。
30.如權(quán)利要求25所述的系統(tǒng)，其特征在于，所述設(shè)備的受保護(hù)的存儲器被劃分成多個分區(qū)，并且其中，由所述更新組件通過為一選擇的分區(qū)構(gòu)建一替換映象，并將所述替換映象覆寫到所選擇的分區(qū)的現(xiàn)有映象上，更新所選擇的分區(qū)。
31.如權(quán)利要求30所述的系統(tǒng)，其特征在于，所述更新組件將所選擇的分區(qū)中的所述現(xiàn)有映象備份成一備份映象，用于如果所述替換映象未被成功地寫入所選擇的分區(qū)時恢復(fù)到所選擇的分區(qū)。
32.如權(quán)利要求31所述的系統(tǒng)，其特征在于，所述更新組件以壓縮的形式備份所述現(xiàn)有映象。
33.如權(quán)利要求30所述的系統(tǒng)，其特征在于，所述設(shè)備的受保護(hù)的存儲器被劃分成多個分區(qū)，并且其中，通過由所述更新組件單獨(dú)地更新一選擇的分區(qū)中的至少兩個組件，更新所選擇的分區(qū)。
34.如權(quán)利要求33所述的系統(tǒng)，其特征在于，所述更新加載器通過向一現(xiàn)有組件應(yīng)用一二進(jìn)制差文件更新所選擇的分區(qū)中的組件的至少一個。
35.如權(quán)利要求34所述的系統(tǒng)，其特征在于，所述更新加載器通過向所述現(xiàn)有組件的一個子集應(yīng)用所述二進(jìn)制差文件的一個子集來應(yīng)用所述二進(jìn)制差文件。
36.如權(quán)利要求33所述的系統(tǒng)，其特征在于，所述更新加載器在提交所述更新之前模擬至少一個更新。
全文摘要
所描述的是一種系統(tǒng)和方法，其中，以故障保險(xiǎn)的方式向一嵌入式設(shè)備的失非易失存儲應(yīng)用自包含、安全實(shí)體形式的軟件更新?？蓱?yīng)用各種類型的軟件更新，并且更新可包含可執(zhí)行代碼和/或數(shù)據(jù)。在重啟之后，初始程序加載器確定更新模式，如果是更新，則引導(dǎo)到一特殊的更新加載器。該更新加載器處理更新包來應(yīng)用更新?？捎谜麄€文件或二進(jìn)制差文件來更新內(nèi)核分區(qū)、系統(tǒng)分區(qū)和保留分區(qū)，對每一類型的更新提供故障處理機(jī)制。可在提交更新前模擬更新。更新可在對設(shè)備適當(dāng)時在存儲器內(nèi)重定位。
文檔編號G06F9/445GK1641582SQ20041010201
公開日2005年7月20日 申請日期2004年12月16日 優(yōu)先權(quán)日2003年12月16日
發(fā)明者A·羅杰斯, J·格羅姆, M·普拉格, M·同科洛維茨, M·馬克雷, S·帕特爾, S·謝爾 申請人:微軟公司