專利名稱:以故障保險方式向非易失存儲應用自定義軟件映象更新的制作方法
技術領域:
本發(fā)明一般涉及計算裝置,尤其涉及更新計算裝置的非易失存儲。
背景技術:
諸如個人數(shù)字助理、當代移動電話和手持式及袖珍計算機等移動計算設備正在變?yōu)橹匾伊餍械挠脩艄ぞ摺R话愣?,它們變得足夠小,使得它們極度方便,而消耗較少的電池功率,且在同時變得能夠運行更強大的應用程序。
在制造這類設備的過程中,嵌入式操作系統(tǒng)映象通常被構建到每一設備的單塊映象文件中,并儲存在非易失存儲中(如,NAND或NOR閃存、硬盤等等)。作為結果,迄今為止,更新這類設備是一個相當復雜且資源密集型問題,它一般需要自定義的解決方案。
例如,更新這類設備通常涉及下載整個新單塊映象文件,它包括所開發(fā)并發(fā)行的在設備集合上運行的單個靜態(tài)映象??梢匀菀椎乩斫?,無論改變了什么,都需要非常大量的系統(tǒng)資源(如,用于臨時保存更新映象的存儲、用于接收整個映象文件的網絡帶寬等等),由此,設備更新過程通常需要一次性的自定義解決方案。
需要一種比現(xiàn)有更新機制更靈活、動態(tài)且有效,而仍是故障保險的更新計算設備的非易失存儲的更好的方法。
發(fā)明內容
簡單而言,本發(fā)明針對一種以故障保險的方式向嵌入式設備的非易失存儲應用自包含、安全實體形式的軟件更新的系統(tǒng)和方法??蓱酶鞣N類型的軟件更新,包括可僅包含對前一更新的改變的更新。此外,軟件更新可包含可執(zhí)行代碼和數(shù)據兩者。
在一個實現(xiàn)中,在重啟之后,初始程序加載器確定更新何時被請求或在進行中,如果是,則引導到更新加載器而非正常的操作系統(tǒng)代碼。更新加載器操作以確認任何待決的更新,用于在適當時向閃存(或其它存儲媒質)應用更新。為了安全和控制,更新加載器是系統(tǒng)中對受保護的存儲(如,NK分區(qū)和系統(tǒng)分區(qū))具有寫訪問權限的唯一實體。應當注意,更新應用程序也具有對閃存中保留區(qū)域的寫權限。
為了更新,更新包(可以是各種形式)被下載到系統(tǒng)上,并由包確認過程確認,該過程包括為安全原因檢查每一包是否被正確簽署、及總體檢查包是否被正確構造。如果有效,則更新被排隊,并且為初始程序加載器設置一標志以檢測期望更新。然后重啟設備。
在重啟之后,初始程序加載器看見更新標志被設置,并例如通過將更新加載器解壓(如果被壓縮)到RAM并跳至更新加載器代碼來促使更新加載器運行。以內核包(如果存在這樣一個的話)開始,對每一包,更新加載器處理該包、重新確認它們、基于閃存考慮事項在需要時修正RAM段中的文件、并將這些文件寫入其對應的分區(qū)中。注意,初始程序加載器保持閃存未鎖定,使得它可被更新加載器寫入。
為解釋包內容,每一包包含具有關于該包的詳細信息的設備清單文件,更新加載器讀取其內容,包括包標識的全局唯一ID、包版本、與其它包相關的依賴信息、各種設置以及包括在包內的文件和文件版本的列表。該清單文件包括在包內,由此令包為自描述的,并且在安裝之后最終儲存在設備中。設備上清單文件的集合包括設備上包的安裝狀態(tài)的數(shù)據庫,它可被枚舉。
更新加載器通過從分區(qū)/映象中檢索關于映象的各種信息,將映象解壓到RAM中,來處理壓縮和非壓縮映象。如果未壓縮,則可簡單地讀取信息,如通過提供要更新的活動分區(qū)的位置的主引導記錄駐留在何處的現(xiàn)有知識來讀取。
在一個實現(xiàn)中,首先以故障保險方式應用任何內核更新,主要通過經將其讀入RAM中并將其壓縮到用戶存儲中來備份現(xiàn)有內核。更新對分區(qū)是一個整體,如果成功,則刪除備份的內核,而如果不成功,則解壓并回復備份的內核。
系統(tǒng)分區(qū)一般大于內核分區(qū),因此,它通常太大,以至于無法為故障保險相關原因而備份。相反,使用IMGFS文件系統(tǒng)來向個別的模塊和文件應用更新,每次應用一個。個別的模塊和文件可能太大,以至于無法作為整體來完成,因此,可通過較小的塊來應用更新。
IMGFS可首先模擬更新過程,這需要兩次通過該過程,即在第一遍中,IMGFS和更新應用程序將不向閃存提交任何內容。如果模擬成功,則運行第二遍,以實際提交變化。如果模擬失敗,在重新運行包確認器之后重試模擬,并傳入不包括失敗的包的包列表。然后用包確認器返回的新列表再次運行模擬。重試模擬,直到模擬成功,或者沒有可應用的任何包。這預防了在盡管發(fā)生了破壞但仍被簽署的包中所出現(xiàn)的數(shù)據破壞。
當使用現(xiàn)有的設備清單文件重復通過IMGFS中的模塊時,該過程檢查來看文件是否在該包的新設備清單文件中出現(xiàn)。如果不是,則從IMGFS分區(qū)刪除該文件,過程繼續(xù)下一文件。如果是,則從新設備清單文件獲取新模塊標志,并且將模塊頭部加載到模塊結構中。
為執(zhí)行更新,更新應用程序過程在嵌套的循環(huán)中循環(huán)通過每一包分組,以個別地處理包中的每一文件。如果在該過程中丟失電源,則一日志文件可精確地告知該過程停留在哪一包以及該包中的哪一文件上,當恢復電源時,更新可從該處繼續(xù)進行。上述處理的一部分包括(對于可執(zhí)行代碼)更新對更新模塊的虛擬地址分配。
更新可以是規(guī)范形式或二進制差(增量)形式。非模塊不需要虛擬地址修正,并且一旦執(zhí)行二進制更新時可被寫入到存儲中。如果文件是模塊,則每次處理每一分段的一個;每一分段被寫入新流中(其中,流是作為IMGFS一部分的文件系統(tǒng)概念)。如果文件是常規(guī)數(shù)據文件,則數(shù)據被寫入默認流中。
如果模塊是規(guī)范更新,則處理該模塊中的每一分段,包括向由虛擬分配器分配的地址重新定位整個分段,以及將整個分段作為新的流寫入新的IMGFS文件中。在原地更新舊模塊,當寫入新塊時,將舊存儲塊解除分配。在規(guī)范的情況下,通過獲取被寫出的新文件中的每一流的大小執(zhí)行對電源故障的恢復,并將其與規(guī)范文件中該分段的大小進行比較。如果新文件中的流小于規(guī)范文件,則那就是過程所停留之處,并且可繼續(xù)進行在數(shù)據上復制。
在二進制差的情況下,每次在一個塊上執(zhí)行打補丁過程,其中,塊可等于頁/扇區(qū)大小。這是因為可能沒有足夠的閃存空間來同時保留分段的舊版本和新版本。當創(chuàng)建新塊時,可將舊塊解除分配,因為它們已不再需要。對于二進制差異更新,對該分段在新模塊文件中創(chuàng)建稀疏流,并將舊分段讀入RAM中。將整個舊分段重新定位回原始的基地址。對于二進制差文件中的每一新塊,基于二進制差異命令構建新塊,并將新塊重新定位到由虛擬地址分配器所分配的地址,并將其寫出到稀疏流。來自舊文件流的不再需要的任何舊塊被解除分配。
在二進制差的情況下,通過將流大小與頭部中指定的大小相比較來縮小停留在哪一分段的范圍,以處理電源故障。一旦確定了該分段,補丁順序返回下一塊,并檢查該塊是否被提交。如果塊已被提交,則執(zhí)行核實以檢查適當?shù)呐f塊已被提交。一旦找到所停留的塊,(即,尚未被提交的塊),則過程如常繼續(xù)。
對于更新保留的存儲器分段,以與內核分區(qū)更新類似的方式,使用同一更新組件完成保留分段更新(如,在分區(qū)之外)。通過處理包中的每一文件,并確定該文件是否為二進制差模塊,處理每一保留相關的包更新。如果不是,則只要從文件中讀出文件數(shù)據并寫入保留的區(qū)域中。如果是二進制差模塊,則讀取現(xiàn)有的區(qū)域(如,到RAM)中,并在將更新的數(shù)據寫回保留的區(qū)域之前向其應用二進制差。
當結合附圖閱讀以下詳細描述時,可以清楚其它優(yōu)點。
圖1是一般表示可在其中結合本發(fā)明的計算機系統(tǒng)的框圖;圖2是表示依照本發(fā)明的一個方面用于方便故障保險組件更新的分區(qū)的操作系統(tǒng)映象和加載器組件的框圖;圖3是表示依照本發(fā)明的一個方面向設備的存儲應用更新包的框圖;圖4是表示依照本發(fā)明的一個方面描述包的設備清單文件的格式的框圖;圖5A和5B包括表示依照本發(fā)明的一個方面確定更新模式的初始程序加載器引導過程的示例邏輯的流程圖;圖6是表示依照本發(fā)明的一個方面的整體更新過程的示例邏輯的流程圖;圖7A和7B包括表示依照本發(fā)明的一個方面更新內核分區(qū)的示例邏輯的流程圖;圖8A和8B包括表示依照本發(fā)明的一個方面更新操作系統(tǒng)分區(qū)的示例邏輯的流程圖;圖9是表示依照本發(fā)明的一個方面通過依賴圖以塊向設備應用更新的框圖;以及圖10是表示依照本發(fā)明的一個方面更新保留的存儲器分段的示例邏輯的流程圖。
具體實施例方式
示例性操作環(huán)境圖1示出了一個這樣的手持式計算設備120的功能組件,包括處理器122、存儲器124、顯示屏126和鍵盤128(可以是物理或虛擬鍵盤,或表示兩者)??纱嬖邴溈孙L129以接收音頻輸入。存儲器124一般包括易失存儲器(如,RAM)和非易失存儲器(如,ROM、PCMCIA卡等等)。操作系統(tǒng)130駐留在存儲器124中,并在處理器122上執(zhí)行,如微軟公司的Windows操作系統(tǒng)或另一操作系統(tǒng)。
一個或多個應用程序132被加載到存儲器124中,并在操作系統(tǒng)130上運行。應用程序的示例包括電子郵件程序、調度程序、PIM(個人信息管理)程序、文字處理程序、電子表格程序、因特網瀏覽器程序等等。手持式個人計算機120也可包括加載到存儲器124中的通知管理器134,它在處理器122上執(zhí)行。通知管理器134處理如來自應用程序132的通知請求。同樣,如下所述,手持式個人計算機120包括適用于將手持式個人計算機120連接到網絡(包括作出電話呼叫)的網絡軟件136(如,硬件驅動程序等)和網絡組件138(如,無線電和天線)。
手持式個人計算機120具有電源140,它被實現(xiàn)為一個或多個電池。電源140還可包括忽略內置電池或對其重新充電的外部電源,如AC適配器或加電對接托架。
圖1所示的示例性手持式個人計算機120被示出為具有三種類型的外部通知機制一個或多個發(fā)光二極管(LED)142和音頻生成器144。這些設備可直接耦合至電源140,使得當被激活時,即使手持式個人計算機處理器122或其它組件被關閉以保存電池能量時,它們也保留一段由通知機制指示的持續(xù)時間。LED 142較佳地不確定地保留,直到用戶采取行動。注意,音頻生成器144的當代版本使用當今手持式個人計算機電池的太多能量,因此它被配置成當系統(tǒng)的剩余部分被關閉時,或者在激活后的一段確定持續(xù)時間之后被關閉。
注意,盡管示出了基本手持式個人計算機,然而,為實現(xiàn)本發(fā)明的目的,實際上能夠以可由程序使用的某一方式接收數(shù)據通信和處理數(shù)據的任何設備都是等效的。
自定義軟件映象更新的故障保險應用本發(fā)明一般針對安裝和/或更新儲存在諸如基于微軟的WindowsCE.NET的便攜式設備等小型移動計算設備上的軟件,包括在其中向嵌入式設備的非易失存儲器,如閃存寫入初始軟件或軟件更新的那些設備。盡管如此,本發(fā)明提供了在總體上計算的益處,并由此可應用到其它計算設備和其它類型的存儲,包括各種類型的存儲器和/或其它類型的存儲媒質,如硬盤驅動器。為簡化目的,術語“閃存”在后文參考設備的可更新存儲來使用,盡管可以理解,任一存儲機制都是等效的。此外,術語“映象”一般包括初始軟件安裝映象以及對該映象的隨后的軟件更新的概念,即使僅更新該映象的一部分。
依照本發(fā)明的一個方面,以故障保險的方式向嵌入式設備的非易失存儲應用自包含、安全實體形式的軟件更新。可應用各種類型的軟件更新,包括僅包含對前一更新的改變的更新。此外,軟件更新可包含可執(zhí)行代碼和數(shù)據兩者??梢岳斫?,可執(zhí)行代碼在安裝時被定制到嵌入式設備的虛擬地址空間環(huán)境。依照本發(fā)明,軟件更新以故障保險的方式安裝,并根據更新的階段,允許卷進(roll-forward)和卷回(roll-back)恢復選項。
下表提供了本發(fā)明所描述的某些術語和文件類型的通用、非限制定義術語
文件類型
如上述名為“以存儲技術抽象方式在文件內創(chuàng)建文件系統(tǒng)”的美國專利中所描述的,可從組件部分構建初始映象(包括包、下文描述),并在制造過程中以自定義方式將其安裝到設備上。該映象用單獨的分區(qū)構建,一般在圖2中表示,并可如后文所描述的被部分更新,而不需要替換單塊映象。
分區(qū)模式方便了未來的嵌入式設備以及已有的設備上的軟件的可靠更新。與意味著在一組設備上運行的在軟件開發(fā)和發(fā)行過程中生成單個靜態(tài)映象相反,本發(fā)明提供了一種方便可更新映象的更好組件化,而同時仍是故障保險的更動態(tài)的映象更新機制。為此,本發(fā)明提供了一種將操作系統(tǒng)映象分裂成可單獨更新的單獨的可更新組件,而保持任何跨組件依賴性的更靈活的機制。為支持這一概念,初始操作系統(tǒng)映象用某些關鍵體系結構特征來構造。
圖2示出了用于安裝在閃存和/或其它合適的非易失存儲媒質上的操作系統(tǒng)映象202的示例分區(qū)模式。為儲存內核映象的目的,提供了內核分區(qū)204作為受限制/受保護的分區(qū)。內核/NK分區(qū)為操作系統(tǒng)映象的核心片段(內核、文件系統(tǒng)等)提供了存儲,并包含在引導過程中執(zhí)行的代碼。提供了受限制/受保護的系統(tǒng)分區(qū)206用于儲存系統(tǒng)組件應用程序和操作系統(tǒng)映象的其它部分(驅動程序、應用程序、數(shù)據文件等)。如后文所描述的,這些分區(qū)204和206的內容由文件系統(tǒng)驅動程序管理,它們抽象存儲的物理映射,并服務以支持系統(tǒng)分區(qū)206中組件的已處理更新,由此啟用了一種依照本發(fā)明的故障保險/恢復解決方案。對受保護的內核分區(qū)的內容的訪問通過二進制文件系統(tǒng)(BINFS)來控制,而對受保護的系統(tǒng)分區(qū)的內容的訪問通過映象文件系統(tǒng)(IMGFS)來控制。
圖2也示出了(盡管實際上并非操作系統(tǒng)202的一部分)系統(tǒng)/用戶可在需要時使用的用戶存儲分區(qū)210,它本質上可以是任何文件系統(tǒng)格式(如,TFAT)。如后文所描述的,除其它可能的使用之外,該分區(qū)可用于臨時儲存要在更新過程中安裝的某些包。注意,書寫主引導記錄以定義這些分組,如其偏移/大小。
圖2也提供了加載器環(huán)境的功能示圖。一般而言,加載器負責以程序引導嵌入式系統(tǒng)到可作出關于是作出正常的操作系統(tǒng)引導還是更新引導的決策的一點上(通過初始程序加載器222,它可結合預先存在的引導加載器224一起工作,如果存在的話)。注意,“預先存在”的引導加載器對新設備并非必需,然而設備制造商可任選地決定它應當存在。
對于更新引導,加載器的一部分包括擔當任一閃存更新的監(jiān)控者(gatekeeper)的更新加載器(UL 220)。更新加載器220負責確認任何待決的更新,并且一旦被確認,在適當時將更新應用到閃存。為安全性和控制,更新加載器220是系統(tǒng)中具有對受保護的存儲(如,NK分區(qū)和系統(tǒng)分區(qū))具有寫訪問權限的唯一實體,并由此提供了負責保護系統(tǒng)存儲的完整性的單個點。注意,更新加載器相對較大,并僅在應用更新時使用,由此,在一個實現(xiàn)中,它以壓縮形式存儲,并在需要時被解壓到RAM中。
圖3表示更新安裝機制/過程。注意,圖3從更新的觀點開始,在設備先前被用初始程序加載器、主引導記錄(MBR)、和更新加載器(UL)組件初始地填充(如,通過JTAG接口或在制造過程中的程序員群體)之后。同樣,規(guī)范包(后文描述)從持久存儲/RAM應用到內核和系統(tǒng)分區(qū)中。
在圖3中,將更新包302(可以是規(guī)范、增量更新或超級包,如后文所描述的)下載到系統(tǒng)RAM 304和/或用戶數(shù)據存儲210中,有可能在向設備用戶通知更新可用的情況下,以手動或自動方式下載。這一般在圖3中由標簽為帶圈的數(shù)字1的箭頭表示。
由此,一旦在設備上安裝了初始制造映象,通過更新被封裝成包的映象的離散部分來完成對映象將來的更新。一般而言,包是映象文件(代碼、數(shù)據、腳本等)的自描述集合,并且在一個實現(xiàn)中,它包括被簽署并被包裝用于分發(fā)的組件的集合。包提供了操作系統(tǒng)映象軟件文件被分裂成文件的較小功能組的方法。在一個實現(xiàn)中,整個操作系統(tǒng)映象包括一個或多個包(不包括加載器組件),并且然后可僅作為較小的包的總和來處理,這些較小的包可被個別地管理、構建和更新,其每一個都可個別地或與其它包組合地更新,取決于每一包的需求。由此,依照本發(fā)明,映象更新不再需要作為整個操作系統(tǒng)映象區(qū)域來完成。
包可以各種方式來配置,包括“規(guī)范”、“增量/差”和“超級”形式,其每一個都服務關于軟件更新的各種目的。例如,規(guī)范包包含包內每一文件的完整副本,而增量/差包包含僅包含基于該文件的較早版本的二進制差的一個或多個文件。增量/差包通常相對于其它包較小,并且由此在試圖優(yōu)化下載成本和下載時間時使用。超級包包含其它包,并在需要下載一個以上包(如,對于互相依賴的包)時為方便而使用。在一個實現(xiàn)中,包文件是Win32 CAB文件,它們包含清單文件(后文描述)以及定義諸如要安裝的包的文件。
規(guī)范包在構建過程中通過將操作系統(tǒng)特征和元數(shù)據(如,特定應用程序的可執(zhí)行代碼和所有關聯(lián)的數(shù)據和配置信息)與包定義相關聯(lián)來生成。增量/差包通過向兩個規(guī)范包的內容應用二進制差算法,并捕捉增量/差包在基線規(guī)范包版本上具有的依賴關系,從規(guī)范包生成。一旦操作系統(tǒng)映象特征和元數(shù)據被映射到個別的包,如上述美國專利申請“自描述軟件映象更新組件”中一般描述的,通過使用包裝工具來枚舉包的內容,并通過處理可執(zhí)行文件(用稱為RelMerge的重定位工具)以令它們能夠在將來被更新用于存儲器相關的修正更新,創(chuàng)建每一包。
當用戶引導更新過程時,包確認器核實包,如上述相關的名為“確定對安裝有效的最大依賴軟件更新集”和“確保軟件更新僅在特定的設備或設備類別上安裝或運行”的專利申請中所描述的。如果被確認,系統(tǒng)在閃存中設置更新標志,并重啟。注意,如后文所描述的,保存更新標志,使得在丟失電源的情況下,一旦更新加載器代碼引導,設備可重新進入更新模式。
在重啟之后,初始程序加載器222看見更新標志被設置,并將壓縮的更新加載器解壓到RAM 304中,如圖3中通過未壓縮的更新加載器代碼308所表示的,并將控制傳遞到更新加載器代碼308。這一般在圖3中由標簽為帶圈的數(shù)字2的箭頭表示。注意,當更新加載器開始更新應用程序時,更新應用程序使用文件列表,或由updagebin.exe應用程序在設備重啟前設置的一組目錄規(guī)范重新運行確認過程。重新運行確認過程以預防包的惡意替換。
以內核包(如果有的話)開始,對于每一包,更新加載器處理該包、在需要時基于閃存考慮事項修正RAM分段310中的文件、并使用BINFS服務將文件寫入其對應的分區(qū)中,如圖3中通過標簽為3到6的箭頭所示的。修正在下文一般描述,并也在上述名為“自描述軟件映象更新組件”的相關專利申請中有描述。
每一包包含設備清單文件400,它包含關于該包的詳細信息,如圖4中一般表示的。清單文件本質上是每一包的規(guī)范文件,并包含諸如包標識的全局唯一ID、包版本、與其它包有關的依賴信息、設置、包括在包內的文件列表和文件版本以及其它共享的公用特征等信息。清單文件400包括在包內,由此令包為自描述的,它在安裝過程中被審閱,并最終儲存在設備上。設備上清單文件的集合包括可枚舉的設備上的包安裝狀態(tài)的數(shù)據庫。
在對應于包含在圖4所示的設備清單文件中的格式和信息的一個實現(xiàn)中,設備清單文件也用以下結構定義來描述
所創(chuàng)建的每一包為安全原因被簽署,然后可用于下載/安裝。如上述名為“自描述軟件映象更新組件”的相關美國專利申請中所描述的,包生成過程/包生成器自動化了包含由包描述文件所定義的文件的完整版本的包文件的創(chuàng)建。一般而言,包生成器輸入包定義文件(如,由命令行自變量指定);其它輸入文件基于指定的包定義文件內容來確定。包生成器分析包定義文件(如,包括一個或多個包定義,每一包作為一XML文檔條目編碼),并可分析包含涉及與用于諸如注冊表設置等設置的其它包有關的優(yōu)先順序的數(shù)據的包陰影文件。此外,包生成器分析構建清單文件以找出其中指定的每一文件,然后確定該文件的類型。對于可執(zhí)行文件類型,包生成器調用執(zhí)行重定位相關操作以及執(zhí)行格式化(如,將可執(zhí)行文件轉換成WindowsCE文件格式)的過程(RelMerge)。
在一個實現(xiàn)中,包生成器包括使用名為如PkgCommon的.NET類庫的應用程序。包生成器應用程序創(chuàng)建多個子目錄,所創(chuàng)建的子目錄的數(shù)量等于命令行中指定的包集合文件中的有效包的數(shù)量。每一包具有在包生成過程中為其創(chuàng)建的唯一的子目錄。另外,包生成器在每一子目錄中使用包定義內找到的信息創(chuàng)建另外的文件。對于每一包,創(chuàng)建一設備清單文件,該設備清單文件的名字從該包的GUID導出。對于每一有效的包定義,創(chuàng)建一包文件以包含包括該包的文件,包括設備清單文件。這些包文件符合微軟的CAB文件1.3版格式。
安裝過程大量使用設備清單文件的內容,既用于已安裝在設備上的那些包,又用于被排隊用于設備上的可能安裝的那些包。包信息API被設計成提供查詢包信息的抽象方法,并既在設備又在構建主機上使用。API在上述名為“確定對安裝有效的最大依賴軟件更新集”的相關專利申請中有詳細描述。
管理對內核或系統(tǒng)分區(qū)的更新并將其傳送到使用包機制的設備上。包被傳送到設備、儲存在臨時存儲中、并被排隊用于通過任一合適的方法來安裝,如通過現(xiàn)有的操作系統(tǒng)映象的組件。可使用用于將包傳送到設備的任一合適的傳輸方法(物理和/或接口協(xié)議),并且方法可根據要更新的包而變化(如,對智能電話為無線,對智能顯示屏為USB,對某些臺式機更新應用通過某一物理連接,等等)。終端用戶界面感受將根據所更新的設備的類型,以及由設備制造商定制的更新過程而變化。依照本發(fā)明的故障保險方面,每一臨時包儲存在持久存儲中,使得在丟失電源的情況下,系統(tǒng)能夠恢復并繼續(xù)安裝。
當調用包確認器庫時,觸發(fā)更新過程。在一個實現(xiàn)中,名為UpdateBin.exe的可執(zhí)行文件與.pkg.cab、.pku.cab和.pks.cab文件擴展名相關聯(lián)。這一可執(zhí)行文件利用包確認器庫來確定更新設備所使用的包的組。
包確認器檢查包上的簽名、確認包內容、核實版本等等。一旦更新包被認為是適當?shù)?,它們被排隊用于安裝,并且確認器設置更新標志以向設備發(fā)信號通知更新可用,然后重啟系統(tǒng)。
在重啟時,初始程序加載器222是從CPU的復位矢量起運行的第一個代碼片段(盡管在某些設備中,初始程序加載器可由現(xiàn)有的引導加載器映象進行程序引導)。初始程序加載器222負責確定設備是否處于更新模式,或者設備是否處于正常引導模式。如果設備處于正常引導模式,則初始程序加載器定位并用程序引導操作系統(tǒng)映象,否則,初始程序加載器定位、解壓并用程序引導解壓的更新加載器映象308。圖5A和5B描述了初始程序加載器引導過程。如圖5A所示,在步驟502某些初始化之后(如,初始化CPU,如果是NAND則初始化控制器、初始化SDRAM等等),初始程序加載器通過步驟504和506確定復位的原因。更具體地,某些CPU體系結構在從掛起的狀態(tài)繼續(xù)執(zhí)行時模仿重啟序列。然后,引導代碼通常基于CPU寄存器值將繼續(xù)執(zhí)行與“正?!币龑^(qū)別開來。初始程序加載器調節(jié)繼續(xù)執(zhí)行操作,并且為了完整性示出步驟504-508。
如果不是繼續(xù)執(zhí)行,則步驟506分支到步驟510-528,如所見到的,檢測更新模式,并且如果是更新,則掃描更新加載器分區(qū)(步驟520),否則在步驟518掃描操作系統(tǒng)分區(qū)。如通過522所見的,在初始程序加載器無法定位設備上的操作系統(tǒng)映象的情況下,初始程序加載器試圖加載并運行更新加載器。如果未找到適當?shù)姆謪^(qū),則輸出錯誤(步驟532);注意在這一時刻,設備未使用正常的顯示驅動程序等運行,由此,在這一時刻所顯示的任何圖像都是來自數(shù)據存儲的位圖。
此外,當引導到操作系統(tǒng)時,通過步驟524鎖定閃存,該步驟在引導到更新加載器時不執(zhí)行。過程然后繼續(xù)到圖5B的步驟538,以處理壓縮和非壓縮映象。注意,圖5B可用于更新加載器或操作系統(tǒng)。更新加載器(在典型的設備上)以壓縮形式儲存,而操作系統(tǒng)可以壓縮或不以壓縮形式存儲,取決于該設備是否是允許代碼在原地執(zhí)行的設備(如果是,則不能被壓縮)。
如果被壓縮,則從分區(qū)/映象檢索關于該映象的各種信息,并且將該映象解壓到RAM中,并通過步驟540-546開始執(zhí)行。注意,可使用任一合適的壓縮算法,只要壓縮類型和壓縮數(shù)據的格式是初始程序加載器所已知的。如果未被壓縮,則步驟538在步驟544從分區(qū)扇區(qū)讀取關于該映象的信息、從該扇區(qū)查找目錄(TOC)、偏移和簽名。為此,初始程序加載器具有主引導記錄駐留在何處(初始程序加載器映象之后的下一好閃存塊的起始)的先驗知識,并在儲存在主引導記錄中的分區(qū)表中查找活動分區(qū)。由此,初始程序加載器依賴于具有正確地同時位于操作系統(tǒng)映象的原地執(zhí)行區(qū)域以及更新加載器映象中的目錄(TOC)的ROM映象/盤映象。在一個實現(xiàn)中,以下作為位置提供在字節(jié)偏移(映象起始+0x40)UNIT32 ROMSignature;UNIT32*pTOC;該信息由操作系統(tǒng)映象用于查找TOC(如由ROM映象/盤映象所放置的)。指針僅在存儲器管理單元(MMU)被打開,且映射與對其構建操作系統(tǒng)映象的地址兼容時有意義。一種替換方案是如下實現(xiàn)在字節(jié)偏移(映象起始+0x40)UINT32 ROMSignature;UINT32*pTOC;UINT32 TOCOffset;其中,TOCOffset是從映象起始位置到TOC的字節(jié)偏移,并可由初始程序加載器(或更新加載器應用程序)用于在不知道該映象被構建于何處來運行的情況下查找TOC。
初始程序加載器也可檢查簽名,如步驟548所表示的。如果在步驟548無效,則引導過程在步驟550暫停,否則通過步驟552和554讀取目錄以找出映象起始、映象長度,并從目錄跳至該地址。步驟558在必要時基于制造商供應的數(shù)據表修正該地址。更具體地,初始程序加載器通常運行在設備的物理地址空間(或有時候在不同于操作系統(tǒng)映象或更新加載器映象的虛擬地址空間中)。該例程負責將任何映象專用虛擬地址(如,操作系統(tǒng)映象TOC值)轉換成與初始程序加載器兼容的地址。如果制造商的引導例程未啟用存儲器管理單元,這意味著將虛擬地址轉換成物理地址。如果啟用了存儲器管理單元,并且映射與如何構建操作系統(tǒng)或更新加載器映象兼容,則不需要任何轉換。
步驟558測試映象是需要被加載到RAM中(如果是,則在步驟562出現(xiàn)),還是可在原地執(zhí)行。然后如步驟564所示的跳轉至映象(加載的或原地)開始執(zhí)行。采用活動分區(qū)的位置,初始程序加載器(如所設計的)在NAND(或可能是NOR)的情況下將活動分區(qū)(內核分區(qū))的內容加載在RAM中,或者如果它是NOR(原地執(zhí)行)內核,則跳至分區(qū)內的引導地址。如果是正常引導,則內核開始并繼續(xù)加載同樣位于內核分區(qū)內的操作系統(tǒng)組件,以指出操作系統(tǒng)能夠從系統(tǒng)分區(qū)中讀取。在這一點上不位于內核分區(qū)內的任何內容被從系統(tǒng)分區(qū)中取出(或者加載或者在原地執(zhí)行),直到操作系統(tǒng)映象被完全引導。
在一個實現(xiàn)中,初始程序加載器是相對非常小尺寸的軟件組件,它由CPU的復位矢量作程序引導,并負責有條件地加載/開始操作系統(tǒng)映象或更新加載器映象。如上所述,初始程序加載器需要能夠讀各種寄存器,包括RAM標志、閃存/非易失標志、以及硬件開關,以確定它是應當引導正常的操作系統(tǒng)映象還是更新加載器映象。更具體地,初始程序加載器需要檢查由UpdateBIN應用程序(如,在確認之后)或由更新加載器應用程序設置的任何標志,因為通常操作系統(tǒng)映象以只讀閃存文件系統(tǒng)運行。為適應電源故障條件,更新模式標志應當是非易失的,由此,如果無法在重啟前儲存非易失標志,則更新加載器應用程序在第一次運行時設置非易失標志,并在成功地完成安裝之后清除該標志,由此令該標志跨電源故障得以持久保存。
此外,初始程序加載器需要以各種類型的存儲技術分析存儲分區(qū)結構,以查找映象,并能夠處理壓縮映象類型以及閃存XIP(在閃存中原地執(zhí)行)和RAM映象(復制到RAM來執(zhí)行)。一般而言,初始程序加載器抽象存儲屬性,如分區(qū)結構、保留的塊、壞塊等等,以及用于任一OEM提供的代碼的任何存儲技術的細節(jié)(如,NOR閃存、NAND閃存、HDD、DOC等等)。初始程序加載器可在以程序引導映象之前確認操作系統(tǒng)映象和/或更新加載器映象的完整性(如,通過執(zhí)行校驗和和簽名核實),如檢測惡意更新并由此提供核實用于數(shù)字權限管理的可信代碼的方法,它需要信任從內核映象返回的UUID由未被惡意地篡改的代碼提供。
由此,如圖5所見的并如圖3所示出的,當在更新模式時,初始程序加載器222將壓縮的更新加載器220解壓到RAM 304中作為解壓縮的更新加載器308、保留閃存未鎖定以給予解壓縮的更新加載器308對系統(tǒng)閃存的寫訪問權限、并跳至解壓縮的加載器代碼以開始執(zhí)行。當由初始程序加載器第一次以程序引導時,更新加載器應用程序需要在非易失存儲中儲存指示該設備處于更新模式的標志。這是因為操作系統(tǒng)映象可能具有只讀閃存文件系統(tǒng),并且無法設置該標志,而這對電源丟失恢復是重要的。初始程序加載器在確定是加載更新加載器映象還是操作系統(tǒng)映象時檢查RAM標志以及這一非易失標志的存在;RAM標志由UpdateBIN應用程序(直接或間接)設置。
轉向更新過程的解釋,如上所述,用于更新內核或系統(tǒng)分區(qū)內容的過程在更新加載器被完全引導并加載到RAM之后執(zhí)行,并操作以找出用戶存儲中所確認的包(如由確認器所指定的)。注意,更新加載器包含必要的文件系統(tǒng)驅動程序,并一次開始一個包的更新過程。用于更新包的包信息記錄在文件系統(tǒng)中,由確認器在將來的更新中使用。依照本發(fā)明的一個方面,為提供故障保險更新,初始程序加載器能夠從隨機電源故障中在加載過程中的任一點上恢復。為此,在事務日志中跟蹤更新進展,以允許萬一在更新過程中出現(xiàn)電源故障能夠進行卷進更新。
在更新模式中,更新加載器運行并開始更新應用程序,它是作為更新加載器映象308(圖3)的一部分的可執(zhí)行文件,并負責將包內容應用到NK/內核分區(qū)204和系統(tǒng)分區(qū)206。換言之,在更新過程中由初始程序加載器加載的更新應用程序負責將包更新應用到映象。注意,更新加載器映象包含更新應用程序所需的最小模塊集,如nk、filesys、閃存驅動程序、coredll、IMGFS等等。
圖6-8分別描述了整體更新過程、NK/內核分區(qū)更新的應用程序以及系統(tǒng)分區(qū)更新。更新應用程序與包確認器一起工作以確認包,并與ROMIMAGE模塊一起工作以處理虛擬和物理分配、修正和安排功能。如圖6所見的,更新應用程序在步驟600檢索包安裝列表(如,從注冊表)、通過確認器確認包(步驟602)。在更新模式中,更新應用程序負責將包內容應用到NK/分區(qū)和系統(tǒng)分區(qū)。
在更新應用程序將包內容應用到非易失存儲之前,確認包,這(尤其)包括簽名檢查以核實包來自可信源等等。如可容易地理解的,知道包更新來自可信源并確保存在對閃存有可寫訪問權限的單個可信監(jiān)控者在試圖包括設備的閃存的完整性時是重要的。更新包在構建過程中簽署、并假定它們是由更新的許多可能不同的每一包可信源之一簽署的、并允許繼續(xù)通過上述包確認過程。如果它們未被簽署或者不是由可信源簽署的,則包確認失敗并且由此不被更新。
注意,系統(tǒng)的設計是使得被允許更新閃存的內容的唯一軟件組件也是負責檢查被排隊來安裝(更新加載器)的任一包的有效性(包括檢查簽名)的同一組件。同樣注意,更新加載器不能包括任何不可信或第三方代碼,如通用操作系統(tǒng)。由此,該系統(tǒng)僅運行可信代碼,并不易受篡改的影響。當未運行更新加載器時,該設計利用了禁止向閃存部分寫入的硬件鎖機制(在硬件層),而無需首先復位該部分(它通常依賴于CPU,并由此需要同時復位)。此外,操作系統(tǒng)映象包含文件系統(tǒng)的只讀版本,由此進一步確保閃存的內容是不可更新的,除非系統(tǒng)處于更新加載器環(huán)境內,其中,確保包確認和安全檢查得以執(zhí)行。
核實也包括檢查包內容的正確性、將設備清單文件中的信息與包內容相關、并確保文件(按名字)在一個且僅一個包內存在。確認也核實包的必要版本已安裝在系統(tǒng)上或已被排隊來安裝。例如,如果包A的版本1.0已安裝在系統(tǒng)上,并且增量/差包A將版本2.0變?yōu)榘姹?.0,則需要一個將包A變?yōu)榘姹?.0的包被排隊來安裝,以使該增量/差包得以安裝。還滿足包括核實必要的包依賴性的其它核實。例如,如果包A的版本2.0依賴于包B的版本3.0的內容,則核實檢查后一包已被安裝或已被排隊并確認來安裝。包確認過程也在上述名為“確定對安裝有效的最大依賴軟件更新集”的美國專利申請中有描述。
設備上確認過程的結果是可安裝在設備上的包(及其文件)的列表,因為它們滿足了確認需求。確認過程也生成不能連同關于對每一具體包確認過程為何失敗的數(shù)據一起安裝的包列表。安裝過程的剩余部分僅利用通過確認的那些包。
返回到圖6,更新加載器負責將任何更新應用到內核分區(qū)(步驟604和606),并將任何系統(tǒng)更新應用到系統(tǒng)分組(步驟608和610)。如果有其它更新,如存儲器的保留的無線電分段(存在于分區(qū)的范圍之外,即,唯一地位于閃存中的指定位置,其分區(qū)結構被定義為在保留區(qū)域“周圍”),則它們通過步驟612和614被類似地處理,如參考圖10所描述的。
包可通過步驟616來刪除。在步驟618將標志設置成一個值(如cleared),以引導操作系統(tǒng)映象,當作出內核更新或系統(tǒng)更新時更新該系統(tǒng)映象,并重啟系統(tǒng)(步驟620)。
圖7A和7B示出了內核更新的一般邏輯,其中(假定原地執(zhí)行),通過將現(xiàn)有的內核讀入RAM中,并將其壓縮到用戶存儲中,備份該內核。這由步驟700表示,其中,通過文件系統(tǒng)展示為具有一個默認文件的XIP文件夾的XIP分區(qū)獲取其用于將整個映象讀入本地緩沖器的句柄。在用戶存儲中創(chuàng)建新文件、調用壓縮例程來壓縮映象、并然后將壓縮的文件數(shù)據寫入新文件中。
步驟702讀取頭部和其它元數(shù)據。為此,該過程走查(walk)pToc(目錄結構)以確定每一分段的位置、用模塊信息填充舊模塊列表、并設置分段數(shù)據指針以指向為備份所創(chuàng)建的RAM內副本中的適當位置。現(xiàn)有TOC的一部分被保存并被復制到接近NK/XIP分區(qū)更新的末端附近的新TOC中。注意,當讀模塊的頭部時,該過程也讀舊設備清單文件以查找額外的標志(壓縮、內核模塊、插槽1忽略[L標志]等等)。
通過步驟704和722,隨后通過處理包中的每一模塊(步驟706和720)、確定該文件是否為bindiff(二進制差)模塊來處理每一包。這涉及循環(huán)通過每一包中的每一模塊,并應用規(guī)范更新,其中提供了新文件的整個副本;或應用二進制差更新,其中僅提供文件的二進制差。應用二進制差的過程被稱為patchbin(打二進制補丁);單獨的二進制差在每一分段中完成,每次完成一個。新模塊的頭部以原始的規(guī)范形式提供。當逐個更新文件時,它們被添加到(以文件對象的形式)新文件列表。在該步驟的最后,存在包含更新模塊和文件的未修正版本的新文件列表。如果它們是現(xiàn)有文件,則將它們從舊列表中移除,使得在該步驟的最后,舊列表僅包含對其沒有更新的文件。注意,該過程基于該分區(qū)中包清單文件的存在知道哪一(些)包與該分區(qū)相關聯(lián)。尚未在設備上安裝的任何新包被保存在IMGFS分區(qū)中。
由此,在步驟708,如果不是二進制差模塊,則只要在步驟718將該模塊添加到新列表。如果是二進制差模塊,則需要向舊代碼應用這些差,對每一分段各個挨次地執(zhí)行步驟710-716。
更具體地,如上所述,增量/差包包含一個或多個二進制差文件,每一二進制差文件對應于一特定的文件/模塊。該差文件基于它在安裝時刻被更新的特定基線版本,并且二進制差文件通常小于所得版本的整個正規(guī)文件,由此,它改進了下載時間/成本,并減少了安裝過程中需要的臨時存儲額外開銷。二進制差文件在構建時刻基于檢測兩個不同的規(guī)范包之間的文件/模塊的差異來生成。如果文件是可執(zhí)行模塊,則它們由鏈接器處理,并位于鏈接器定義的地址中。它們尚未被重定位到最終的位置,這如上所述地將在安裝時刻在設備上完成。
為使可執(zhí)行模塊的二進制差能夠應用到已在設備上的基線版本,該基線版本需要被解除重定位,返回到從其計算該二進制差的鏈接器生成的基地址。一旦向模塊的解除重定位版本應用了該二進制差,它可被重新定位到適當?shù)幕A虛擬地址。解除重定位和重定位的過程是相同的,并通過將模塊的基地址移位到特定的位置來完成。
當處理了每一包之后,內核更新繼續(xù)到圖7B的步驟724,其中,尚未被修改的任何模塊被添加到新模塊列表。在這一點上,舊文件列表包含將不被更新的模塊和文件;這些需要被解除修正,返回到原始基地址,使得存在可被整體處理的未修正模塊和文件的一個統(tǒng)一列表。舊文件列表中出現(xiàn)在新設備清單文件中的對象被轉移到新文件列表。注意,如果文件要被刪除,則它不在新設備清單文件中出現(xiàn),并因此不被放入新模塊列表中。
存儲器分配和修正在步驟726和728執(zhí)行,并且在步驟730將新的原地執(zhí)行內核映象寫回閃存中,這也由盤映象工具完成,并在romimage.dll中實現(xiàn)(如下所述)。romimage中存在一個功能,它采用模塊列表,并通過分配新緩沖器構建新映象、循環(huán)通過模塊列表以復制由數(shù)據指針指定的適當位置處的分段數(shù)據并將頭部和文件名串復制到目錄(TOC)中指定的正確的位置,來構建新映象。如后文所描述的,在映象的末端寫新TOC,并更新pTOC指針以指向放置新TOC的位置。同樣如后文所描述的,跟蹤插槽0中的數(shù)據分段帶用于NK/XIP映象,它與IMGFS帶連接,并在IMGFS更新過程中被輸出到包含ROMINFO結構的IMGFS文件中。
在向閃存寫出任何內容時,該過程在日志文件中記錄寫正在進行中。一旦寫完成,它被記錄,由此,如果在刪除備份文件之前丟失電源,也知道正確的狀態(tài)。
如果整個過程都是成功的,則在步驟732刪除備份文件,這包括在刪除該文件之后向日志文件寫入XIP分區(qū)完成。如果在NK/XIP更新過程的任一步驟出現(xiàn)了錯誤,諸如如果映象增長超過了分區(qū)的大小,則恢復該映象的備份版本,且合適的用戶界面指示在更新過程中出現(xiàn)錯誤并恢復原始映象。如果不能成功地寫入備份版本(如,在閃存錯誤中),則提供一個不同的UI消息以指示在更新過程中出現(xiàn)了錯誤,但是原始映象無法被恢復并可能被破壞。
同樣,記錄更新的狀態(tài)用于UpdateBin。注意,這是不同的,更新應用程序所使用的日志文件是內部地用于事務記錄的。
在這一點上,存在組成該映象的模塊和文件的單個文件列表。這與由盤映象工具結合romimage.dll所執(zhí)行的初始安裝相同,如在上述名為“以存儲技術抽象方式在文件內創(chuàng)建文件系統(tǒng)”的美國專利申請中所描述的。
在較高的級別上,包安裝過程涉及提取包內容并將其應用到設備。然而,這些機制包括主要圍繞代碼修正或代碼重定位的概念的若干步驟。本發(fā)明在安裝時刻在設備上執(zhí)行修正和重定位,而非在構建時刻在構建系統(tǒng)中執(zhí)行。一個益處是對特定系統(tǒng)的包安裝能力,因為安裝不需要整個設備映象在構建時刻可用。相反,它允許包更新被作為從安裝在設備上的特定操作系統(tǒng)映象配置很大程度隔離的實體來處理。
為使可執(zhí)行模塊可被重定位,模塊需要包含指導定位器在模塊的基地址定位改變時在需要被更新的模塊內尋址的信息。映象更新模塊利用重定位信息編碼模式以在可執(zhí)行模塊本身內以壓縮的形式提供這一信息。
如在上述美國專利申請“自描述軟件映象更新組件”中所一般描述的,RelMerge工具將模塊(.EXe或.DLL)轉化成適合包括在包內,并因此可被安裝到設備的格式。這包括將重定位信息轉化成更適合在設備上長期儲存的壓縮格式,并將文件頭部轉化成由設備上的ROMFS文件系統(tǒng)使用的_rom變量。另外,當重新布置時,任何過剩的填充也被從文件的所有分段中移除。
一旦用這一信息編碼,可改變可執(zhí)行模塊的基礎虛擬地址,并可修改模塊內所有相關的地址引用,以解決基地址中的變化。重定位過程利用在設備和臺式機之間共享的代碼庫。在后一情況下,它用于創(chuàng)建初始制造映象,使得在代碼模塊上執(zhí)行實際的重定位,并也用于創(chuàng)建當安裝每一更新模塊時所使用的虛擬地址空間的列表,由此,允許API的消費者相信模塊重定位不會重疊。通過盤映象工具和romimage.dll組件創(chuàng)建初始制造映象在上述名為“以存儲技術抽象方式在文件內創(chuàng)建文件系統(tǒng)”的相關的美國專利申請中有描述。
一般而言,虛擬/物理分配和修正與盤映象工具相同地工作,即,定位來自NK/XIP映象的舊目錄(TOC)并定位舊ROMINFO。在映象中的固定位置(如,偏移0x44)上定位指向TOC的指針。從稱為“.rom”的IMGFS文件中讀取舊ROMINFO結構。
為分配虛擬地址,插槽0分配器以插槽0的頂端開始,并基于IMGFSROMINFO結構中的值dwSlot_0_DllBase結束。插槽1分配器以插槽1的頂端開始,并基于IMGFS ROMINFO結構中的值dwSlot_1_DllBase的值結束。然后將代碼和數(shù)據修正成新的VA分配,并且令整個模塊列表可用。壓縮被標記成壓縮的分段,并將其大小記錄在模塊對象中。
為向映象分配物理空間,對RAM使用RAMIMAGE,并對閃存使用ROMIMAGE。對于RAM,RAMIMAGE物理分配器使用舊TOC的physfirst作為物理分配器的起始地址。物理分配器的末端最初被指定為舊TOC的ulRAMEnd。對于RAMIMAGE,由物理分配器返回RamStart=PhysFirst+PhysLength(映象所需的實際長度);確定副本分段的虛擬地址位置從RamStart開始,并且從那里開始,涉及副本分段的文本/數(shù)據被修正。
對于ROM,ROMIMAGE物理分配器使用舊TOC的physfirst用于物理分配器的起始地址,而物理分配器的末端通過使用GetPartitionInfo獲取閃存上的分區(qū)的長度來確定。
注意,更新的TOC在物理分配過程中生成。
與XIP分區(qū)不同,在IMGFS分區(qū)中,不重新作出整個映象,因為這太大以至于無法備份。相反,IMGFS文件系統(tǒng)用于向個別的模塊和文件應用更新,每次更新一個。此外,注意,個別的模塊和文件可能太大,以至于無法作為一個整體來完成,則可通過較小的塊應用更新,如后文參考圖9所描述的。
IMGFS更新使用NT更新所使用的同一文件列表,盡管當過程前進時一個列表將被更新。如后文所描述的,IMGFS首先模擬更新進程,需要兩次通過該過程。在第一遍中,IMGFS和更新應用程序都不向閃存提交任何內容。如果模擬成功,則運行第二遍以實際提交改變。如果模擬失敗,則在重新運行包確認器之后重試模擬,并傳入不包括失敗的包的包列表。然后用包確認器返回的新列表再次運行模擬。重試模擬,直到模擬成功,或者沒有可應用的任何包為止。這預防可能在盡管有破壞但仍被簽署的包內出現(xiàn)的數(shù)據破壞。
圖8A和8B示出了系統(tǒng)分區(qū)更新的一般邏輯,其中,更新應用程序與映象文件系統(tǒng)驅動程序(IMGFS)的讀/寫版本接口,以管理系統(tǒng)分區(qū)。注意,在典型系統(tǒng)的正常(非更新)操作中,系統(tǒng)分區(qū)對于IMGFS驅動程序是只讀的(并且閃存被鎖定)。此外,注意,與內核更新不同,系統(tǒng)更新不作為整體來備份,盡管事務日志可將設備恢復到故障(如電源故障)之前它在系統(tǒng)更新過程中的位置,并且系統(tǒng)更新可以從那一點上繼續(xù)進行。
在步驟800,掃描系統(tǒng)分區(qū)(imgfs區(qū)域)中的現(xiàn)有模塊,并將它們添加到虛擬地址(VA)分配器。在掃描過程中,該過程也檢測刪除情況。更具體地,當使用現(xiàn)有設備清單文件反復通過IMGFS中的模塊時,該過程檢查來看文件是否在該包的新設備清單文件中出現(xiàn)。如果不是,則將該文件從IMGFS分區(qū)中刪除,并且過程繼續(xù)下一文件。如果是,則從新設備清單文件獲取新模塊標志,并且使用IOCTL_BIN_GET_E32和IOCTL_BIN_GET_O32將模塊頭部加載到模塊結構中。注意,在此時,不讀入用于模塊和文件數(shù)據的數(shù)據,因為并不需要。一旦讀入了每一模塊頭部,則將該模塊列表傳遞到分配器以保留虛擬地址(包括從存儲在閃存中的保留表中得知的保留的分段)。
一旦掃描了現(xiàn)有模塊,并且定義了當前分配的虛擬地址,該過程已準備好開始更新。為此,過程循環(huán)通過每一包(通過步驟802和828),并循環(huán)(通過步驟804和826)通過包內的每一文件,逐個處理每一文件。文件以大小的凈增益的順序來處理,從收縮最多的文件開始,并以增長最多的文件結束。文件大小的增量通過將舊設備清單文件與新設備清單文件相比較來確定。
如果在該過程中丟失電源,則日志文件將確切地告知該過程停留在哪一包以及包內的哪一文件上。該過程在所停留的文件處繼續(xù)進行,在電源故障這一點上已完成的更新文件被作為現(xiàn)有文件處理。為恢復,更新過程中的任何新模塊不被包括在初始保留中,而舊模塊在保留中。舊模塊虛擬地址空間被如常地解除分配。如果新頭部已被寫出,則它將包含用于該新模塊的虛擬地址空間分配。在這一情況下,使用Reserve(保留)函數(shù)將其添加到虛擬地址空間分配器。如果新頭部尚未被寫出,則使用Allocate(分配)函數(shù)如常地分配新虛擬地址空間。
上述處理的一部分包括(對于可執(zhí)行文件,而非數(shù)據文件)更新用于更新模塊的虛擬地址分配,這通過確定虛擬地址是否改變,并且如果是,則如步驟806所示,解除分配舊虛擬地址空間并且用于新模塊分配虛擬地址空間來完成。如果虛擬地址大小改變,則調用Deallocate(解除分配)函數(shù)從分配器移除舊虛擬地址空間,并調用Allocate(分配)函數(shù)為新模塊分配新虛擬地址空間,根據代碼或數(shù)據傳入適當?shù)膶R要求。解除分配可對應于刪除模塊的命令,在這一情況下,通過步驟808和824刪除舊模塊,(但是如果它是剛安裝的新模塊,則不刪除)。如果不是刪除命令,則步驟810在IMGFS調用CreageFile(創(chuàng)建文件)函數(shù),例如在命名新文件時使用new_<module_name>.<module_extension>,以在映象文件系統(tǒng)中創(chuàng)建新文件;(為在電源在這一操作附近故障時恢復,如果該文件已存在,則不再創(chuàng)建它)。
對于可執(zhí)行文件,步驟812通過使用IOCTL_BIN_SET_E32和IOCTL_BIN_SET_O32將新頭部讀入模塊對象中,并用新虛擬地址空間分配更新該頭部來向可執(zhí)行文件寫入適當?shù)念^部,如步驟812所示的。每一操作在IMGFS中是原子的。在這一點上,頭部應當是完整的。不管數(shù)據指針(dataptr)(為0),因為當內核請求E32/O32時IMGFS偽造該值。頭部是規(guī)范形式,甚至是在二進制差文件中。
如果在寫頭部時丟失電源,如果兩個頭部都存在,則不需要完成任何恢復。如果僅寫出了E32頭部,則僅需要再次寫出O32頭部。每一頭部的存在可通過IOCTL_BIN_GET_E32和IOCTL_BIN_GET_O32來知道。
為應用更新,注意到對文件的更新可以是規(guī)范形式或二進制差形式。如果更新的文件不是模塊,則以與個別分段相同的方式處理該文件的數(shù)據。如果該文件是模塊,則以凈增益的順序處理每一分段,每次處理一個,以收縮最多的分段開始。首先處理.creloc分段。每一分段被寫到一個新流。如果文件是常規(guī)數(shù)據文件,則該數(shù)據被寫入默認流中。
如果如在步驟814所評估的,模塊是規(guī)范更新,則步驟816-822處理模塊中的每一分段,包括將整個分段重定位到由虛擬分配器所分配的地址(步驟818),并將整個分段作為新的流寫入新IMGFS文件中(步驟820)。然后在步驟824刪除舊模塊,除非舊模塊實際上是新模塊。
在規(guī)范的情況下,通過獲取被寫出的文件中的每一流的大小,并將其與規(guī)范文件中的該分段的大小相比較,來執(zhí)行對電源故障的恢復。如果新文件中的流小于規(guī)范文件,則這就是過程所停留之處,并可繼續(xù)進行在數(shù)據上復制。
在二進制差的情況下,每次對一個塊完成patchbin(打二進制補丁)程序(如后文參考圖9所描述的),其中,一個塊等于頁/扇區(qū)大小。這是由于可能沒有足夠的閃存空間來同時保留分段的舊和新版本??梢匀缬啥M制差文件所指定的任何順序創(chuàng)建新文件的塊,使得可以通過優(yōu)先使用閃存空間來完成patchbin的過程。當創(chuàng)建新塊時,舊塊可被解除分配,因為它們不再需要。
為此,如果在步驟814,模塊不是規(guī)范更新,則過程分支到圖8B的步驟832,其中,結合步驟852,循環(huán)通過該模塊中的每一分段,以在逐塊的基礎上應用二進制更新。更具體地,步驟834為該分段在新模塊文件中創(chuàng)建稀疏流,并且將舊分段讀入RAM中(步驟836)。整個舊分段被重新定位回到原始的基地址(步驟838)。
對于二進制差文件中的每一新塊(步驟840和850),基于二進制差命令構建新塊(步驟842)。新塊在步驟844被重定位到由虛擬地址分配器分配的地址上,并且在步驟846被寫出到稀疏流中。舊文件流中不再需要的任何舊塊被解除分配,如由步驟848所示的。塊更新的概念也在下文參考圖9描述。
在二進制差的情況下,電源故障通過縮小停留在哪一分段的范圍來處理,這通過將流大小與頭部中所指定的大小相比較來完成。一旦確定了分段,如常創(chuàng)建patchbin的實例。當順序返回下一塊時(patchbin輸出必需是可再現(xiàn)/可確定的),檢查該塊是否被提交。由于塊寫是原子的,無法提交部分塊。如果塊已被提交,則丟棄從patchbin返回的數(shù)據,并且執(zhí)行核實以檢查適當?shù)呐f塊已被解除提交。一旦找到所停留的塊,(即,尚未被提交的塊),則過程如常繼續(xù)。
為結束,如果這是現(xiàn)有的文件或塊,并且是二進制差情況,則刪除舊模塊(在規(guī)范情況下,該文件已被刪除),并且日志文件記錄該模塊已完成。如果包已被完成,則代之以記錄這一情況。當完成了所有的包時,用更新的ROMINFO結構更新.rom文件,它包含插槽0基礎、插槽1基礎和用于NK/XIP和IMGFS映象兩者的插槽0數(shù)據帶。
如果在IMGFS更新過程的任一步驟中出現(xiàn)錯誤,如,如果二進制差沒有足夠的閃存塊可用,則取消更新過程,并且不嘗試恢復,因為它可能是無法恢復的,并且顯示適當?shù)南ⅰW⒁?,預先運行模擬可避免這一問題。
如所見的,對內核分區(qū)的更新從更新到系統(tǒng)分區(qū)被不同地處理,盡管從構建和包裝觀點來看,它們是相同的。更具體地,當更新內核分區(qū)時,從閃存中取出某些NK.NB0(簽署的內核分區(qū)映象)文件到RAM中、在適當時更新并修正成分組件、然后將修改的.NB0內容以連續(xù)的塊寫回閃存中。這允許在需要時跳過任何壞塊。
依照本發(fā)明的另一方面,如上所述,這些機制考慮如何應用二進制差文件的優(yōu)化順序的概念。如所理解的,需要某些臨時填充存儲器,以向基線映象應用二進制差文件,并由此生成所得的更新的模塊/文件。在構建時,當生成二進制差文件時,在所得的映象上運行排列過程,以排列更新二進制差文件中的塊的順序,使得保留必要的可用臨時填充存儲器到某一指定的最大值。通過在構建系統(tǒng)上執(zhí)行這一優(yōu)化操作,本發(fā)明確保了如果設備具有足夠的存儲器用于映象的整體增長(或收縮),并且它具有必要的臨時填充空間,則設備一定具有足夠的存儲器來完成更新過程。在開始更新之前,在確認過程中執(zhí)行大小檢查。
圖9一般表示了塊更新概念。一般而言,系統(tǒng)文件較大,并且由此,如果整體創(chuàng)建新文件,并且向舊文件整體應用二進制差,則會消耗大量的臨時存儲(大于可用的臨時存儲)。相反,向要更新的文件的現(xiàn)有塊應用差更新,能獲得新的更新的塊,將更新的塊復制到更新的文件流中,并在不再需要時解除分配舊塊。
為實現(xiàn)塊更新,構建舊塊和新塊之間的依賴圖,這由圖9的圖900來一般表示。如所理解的,差文件902將被應用到由該圖中的節(jié)點所表示的數(shù)據的實際塊中。在一個實現(xiàn)中,塊為四千字節(jié)大小,并且任一時刻最多允許32個塊,這意味著僅需要128千字節(jié)可用來確保系統(tǒng)可被更新。注意,上述的示例塊大小和整體限制是任意值,但是需要由系統(tǒng)更新和設備的更新應用程序的提供者同意。在特定更新無法滿足所同意的限制的情況下,在銷售商處構建更新的過程中,需要由銷售商斷開依賴鏈接(對這樣的塊不需要非差更新)。
如圖9所示,單個舊更新塊可提供一個或多個新更新塊的依賴數(shù)據(向這些數(shù)據應用差文件),并且新更新塊可依賴于一個或多個舊更新塊。一般而言,更新通過向舊塊應用適當?shù)囊粋€或多個差文件,直到應用了該舊塊的每一差文件來進展。在這一時刻,可斷開依賴鏈接(如,如由圖9所示,通過斷開舊塊X和新塊Y之間的鏈接),由于舊塊不再為新塊所需。由于這是與舊塊X相關聯(lián)的唯一鏈接,因此可解除分配舊塊X以釋放空間用于另一塊。同樣,由于在向舊塊應用了差文件之后斷開依賴鏈接,當新塊沒有到舊塊的依賴鏈接時,即,當新塊完全通過差更新過程被寫入時,該新塊可在適當時被復制到閃存,并從RAM中解除分配,以釋放空間用于另一塊。注意,可在同一時刻解除分配多個塊。
如可容易地理解的,應用差更新的順序可幫助存儲器的釋放。一般而言,該順序為首先向對具有最多依賴鏈接的新塊具有最少依賴鏈接的舊塊應用差更新。一種算法對具有最高計數(shù)新塊的最低計數(shù)舊塊執(zhí)行二級搜索(如,鏈接計數(shù)器數(shù)組的搜索)。
對于對塊更新執(zhí)行預閃存模擬,由于整個文件可能不在模擬中在任意時刻存在,因此基于要寫入的每一塊計算校驗和,并且對照每一更新的校驗和核實所得的校驗和。如果該模擬生成的校驗和通過,則可執(zhí)行對閃存的實際更新。
轉向更新保留分段,圖10示出了保留分段更新(如,在分區(qū)之外)以類似于NK分區(qū)更新的方式使用同一更新組件完成。通過步驟1000和1016,通過處理包中的每一文件(步驟1002和1014)來處理每一保留相關包更新,確定該文件是否為bindiff(二進制差)模塊。如果不是,則只要在步驟1010和1012將文件數(shù)據從文件讀出并寫入保留的區(qū)域中。如果是二進制差模塊,則讀現(xiàn)有的區(qū)域(如,讀入RAM)中并在向保留的區(qū)域寫回更新數(shù)據之前向其應用二進制差,如由步驟1006、1008和1012一般表示的。
當以適當?shù)捻樞?按照包版本)應用每一排隊的包的包內容,并且更新完成時,包文件可任選地從用戶存儲中移除,或被標記為完成。在這一時刻,一旦確認的包的內容被安裝到適當?shù)拈W存分區(qū)中,更新應用程序通過禁用更新模式(清除閃存更新標志)完成其工作,并且重啟設備。在以前,初始程序加載器檢測當前系統(tǒng)模式,但是此次,由于清除的標志,以鎖定的閃存來如上所述地引導更新的操作系統(tǒng)映象,并且安裝完成。
依照本發(fā)明的一個方面,提供了故障保險/恢復更新方法。為此,映象更新設計的一部分提供了如由于意外的電源丟失而使更新過程被中斷的情況下的故障保險恢復。實現(xiàn)故障保險恢復的方法包括通過記入日志和文件系統(tǒng)人為因素(如,卷進恢復)使得重新進入令更新加載器和更新應用程序,并能夠決定更新操作停留在何處。同時調節(jié)的是支持向文件寫入更新而無需完全解除提交舊副本直到向存儲提交了新更新(這以系統(tǒng)分區(qū)中的子文件增量完成,如,塊)的事務文件系統(tǒng)。可執(zhí)行到提交到存儲這一點上的整個安裝過程的模擬以確保已實行了幾乎所有相關的代碼路徑,而將實際更新上的故障模式降低到硬件(如,閃存故障)中的故障或低級閃存軟件例程中的可能故障。提供NK/內核的備份和保留的(如,無線電)區(qū)域,使得在更新失敗的情況下,在某些具體數(shù)量的重試之后,可恢復原始映象分區(qū)內容的備份,并中止安裝(即,卷回恢復)。
更新應用程序跟蹤安裝進展、在意外中斷的情況下重新獲得它所停留之處、并備份(并可能恢復)NK/內核和保留的區(qū)域。更新應用程序更新RAMIMAGE、ROMIMAGE、IMGFS和保留的映象。RAMIMAGE和ROMIMAGE分區(qū)以與臺式機盤映象工具生成分區(qū)的同一方式生成,即,IMGFS分區(qū)通過用現(xiàn)有的布局工作以及對IMGFS和分配器作出調用以虛擬和物理地正確排列更新的模塊來更新。上文參考圖10所描述的保留更新通過覆寫整個區(qū)域來作出。
在一個實現(xiàn)中,當更新應用程序開始時,它假定要安裝的包位于臨時保存目錄中,如用戶存儲中的更新應用程序輸入文件中所指定的,它包含用于更新應用程序的輸入。更新應用程序輸入文件的路徑在注冊表中指定。更新應用程序不關注包存儲在何處,無論它是內部數(shù)據存儲還是外部存儲卡,只要提供了完整的路徑用于保存目錄。同時提供的是到用于更新的位圖文件的路徑;注意,正常的操作系統(tǒng)代碼不在運行,并由此,為用戶界面目的提供了位圖(如,示出進度條、正在更新哪些文件、錯誤消息等等)。
更新應用程序通過將保存目錄路徑傳遞到包確認器開始,它返回指定安裝包的順序的列表,如在上述名為“確定對安裝有效的最大依賴軟件更新集”的相關美國專利申請中所描述的。然后,更新加載器處理重復通過每一包,并應用適當?shù)母?XIP、IMGFS和/或保留,如上文參考圖6所描述的。
更新應用程序可被認為具有若干進程/組件,包括負責對NK/XIP分區(qū)的更新的NK/XIP更新進程。該分區(qū)中的映象可以是ROMIMAGE或RAMIMAGE(其中,ROMIMAGE是直接從閃存中執(zhí)行并需要NOR閃存的映象,而RAMIMAGE是被加載到RAM并可儲存在NOR或NAND閃存中的映象)。無論映象的類型如何,在讀和寫時,區(qū)域更新直接與塊驅動程序接口。
映象的另一進程/組件是IMGFS更新,它負責對操作系統(tǒng)分區(qū)的更新,由映象文件系統(tǒng)(IMGFS)管理。保留更新進程負責對無線電或其它保留區(qū)域的更新。保留區(qū)域更新在讀和寫時直接與塊驅動程序接口。
Romimage是當制造設備時提供初始安裝映象的共享組件(與臺式機盤映象工具共享),并負責虛擬和物理(存儲)分配和模塊修正。Romimage.dll包含用于創(chuàng)建并管理多個分配器的Allocator(分配器)類分層結構和功能、用于創(chuàng)建并管理文件列表的File(文件)類分層結構(用于儲存關于文件或模塊的元數(shù)據)和功能、以及支持更新和構建過程的功能。Patchbin組件提供應用二進制差更新來生成新文件的過程。舊模塊數(shù)據和二進制差作為輸入提供給該組件,并且其輸出是用于新模塊的數(shù)據。可提供UI組件以在更新過程中顯示適當?shù)挠脩艚缑鏀?shù)據。注意,可視內容可基于操作系統(tǒng)地區(qū)設置預先生成。
NK/XIP更新過程可以是由更新應用程序的主函數(shù)調用的函數(shù),它采用NK/XIP包的列表來應用。對NK/XIP分區(qū)的更新需要更新應用程序重新作出完整的映象(實際上為設備上的盤映象工具過程)。在NK/XIP更新過程中,維護舊文件列表和新文件列表。舊文件列表用NK/XIP分區(qū)中的當前模塊來初始化,該信息結合包一起使用來創(chuàng)建新文件列表作為最終結果。新文件列表包含創(chuàng)建映象所需的信息(頭部、分段數(shù)據、標志等等),并且該列表被傳遞到虛擬和物理分配器來重新執(zhí)行分配過程。
上文描述的圖7A和7B輸出示出了內核區(qū)域如何被更新。為概括圖7A和7B的步驟,該過程將整個XIP(或其它)區(qū)域讀入RAM中并將其備份為用戶存儲中的壓縮文件、掃描XIP區(qū)域中的現(xiàn)有模塊以讀取頭部和其它元數(shù)據并構建更新模塊和文件的未修正版本。該過程然后將未被修改的模塊和文件的剩余部分添加到新模塊列表、執(zhí)行虛擬/物理分配和模塊修正、并將新XIP映象寫回閃存中。
該步驟中的故障保險方法是相當明了的,因為不向閃存提交任何內容直到過程結束。因此,如果在寫入新映象之前出現(xiàn)電源故障,只需重新執(zhí)行該過程。如果在寫出新映象時出現(xiàn)電源故障,舊映象的備份副本仍存在,并可用于恢復映象(如果日志文件指定新映象處于被寫出的過程中,則可使用壓縮的備份文件來恢復舊映象的副本)。日志文件記錄事務中的步驟,令其明了以知道過程在何處失敗。
權利要求
1.在計算設備中,一種方法,其特征在于,它包括確定是將所述設備引導到操作系統(tǒng)模式還是更新模式;以及當所述設備被引導到所述更新模式時,對所述設備存儲中的映象執(zhí)行至少一個更新,同時將所述更新的狀態(tài)記入日志,以便能夠從每一更新過程中可能出現(xiàn)的任一故障中恢復。
2.如權利要求1所述的方法,其特征在于,確定是將所述設備引導到操作系統(tǒng)模式還是更新模式包括檢查一在重啟之前設置的標志。
3.如權利要求1所述的方法,其特征在于,所述映象被劃分成至少兩個分區(qū),并且其中,通過為一選擇的分區(qū)構建一替換映象、并將所述替換映象覆寫到所述分區(qū)中的現(xiàn)有映象上,更新所選擇的分區(qū)。
4.如權利要求3所述的方法,其特征在于,它還包括將所述分區(qū)中的所述現(xiàn)有映象備份成一備份映象,確定寫所述替換映象是否成功地完成,如果不是,則從所述備份映象恢復所述現(xiàn)有映象。
5.如權利要求4所述的方法,其特征在于,備份所述現(xiàn)有映象包括以壓縮形式儲存所述備份映象。
6.如權利要求1所述的方法,其特征在于,所述映象被劃分成至少兩個分區(qū),并且其中,通過單獨地更新所述映象中的至少兩個組件來更新一選擇的分區(qū)。
7.如權利要求6所述的方法,其特征在于,所述分區(qū)之一是系統(tǒng)分區(qū),并且其中,單獨地更新所述映象中的至少兩個組件包括將操作系統(tǒng)文件寫入所述分區(qū)中。
8.如權利要求1所述的方法,其特征在于,執(zhí)行所述至少一個更新包括向一現(xiàn)有組件應用一二進制差文件。
9.如權利要求8所述的方法,其特征在于,向現(xiàn)有組件應用二進制差文件包括向所述現(xiàn)有組件的一個子集應用所述二進制差文件的一個子集。
10.如權利要求9所述的方法,其特征在于,所述子集包括一具有確定大小的數(shù)據塊。
11.如權利要求9所述的方法,其特征在于,執(zhí)行對映象的至少一個更新包括在提交所述更新之前模擬一更新過程、及確定所述模擬成功。
12.如權利要求1所述的方法,其特征在于,一組更新中的所述更新在包中的文件和文件上個別地執(zhí)行,并且所述個別包和文件信息被記入日志,使得在任一故障之后,訪問所述日志文件確定所述故障出現(xiàn)在哪一包以及包中哪一文件上。
13.一個或多個具有計算機可執(zhí)行指令的計算機可讀媒質,當所述指令被執(zhí)行時,執(zhí)行權利要求1所述的方法。
14.在計算環(huán)境中,一種方法,其特征在于,它包括將一操作系統(tǒng)映象分裂成單獨可更新的分區(qū);以及與另一分區(qū)隔離地更新至少一個分區(qū)。
15.如權利要求14所述的方法,其特征在于,更新至少一個分區(qū)包括將計算設備引導到更新模式。
16.如權利要求14所述的方法,其特征在于,與另一分區(qū)隔離地更新至少一個分區(qū)包括為第一分區(qū)構建一替換映象并將所述替換映象覆寫到所述第一分區(qū)中的現(xiàn)有映象上、及通過單獨地更新第二分區(qū)中的映象的至少兩個組件來更新所述第二分區(qū)。
17.如權利要求16所述的方法,其特征在于,它還包括將所述第一分區(qū)中的所述現(xiàn)有映象備份成一備份映象,確定寫所述替換映象是否成功完成,如果不是,則從所述備份映象恢復所述映象。
18.如權利要求17所述的方法,其特征在于,備份所述現(xiàn)有映象包括以壓縮的形式儲存所述備份映象。
19.如權利要求16所述的方法,其特征在于,更新所述第二分區(qū)包括將所述每一更新的組件的身份記入一日志文件中,使得如果出現(xiàn)故障,訪問所述日志文件確定所述故障出現(xiàn)在哪一組件上。
20.如權利要求16所述的方法,其特征在于,更新所述第二分區(qū)包括向一現(xiàn)有組件應用一二進制差文件。
21.如權利要求20所述的方法,其特征在于,向現(xiàn)有組件應用二進制差文件包括向所述現(xiàn)有組件的一個子集應用所述二進制差文件的一個子集。
22.如權利要求21所述的方法,其特征在于,所述子集包括一具有確定大小的數(shù)據塊。
23.如權利要求16所述的方法,其特征在于,更新所述第二分區(qū)包括在向所述第二分區(qū)提交更新之前模擬更新過程、及確定所述模擬成功。
24.一個或多個具有計算機可執(zhí)行指令的計算機可讀媒質,當所述指令被執(zhí)行時,執(zhí)行權利要求14所述的方法。
25.在計算設備中,一種系統(tǒng),其特征在于,它包括一引導機制;以及一更新加載器,在檢測到一待決更新時所述引導機制引導到所述更新加載器,所述更新加載器包括所述設備代碼中對所述設備的受保護存儲器具有寫訪問權限的唯一實體,所述受保護的存儲器包括至少兩個分區(qū),并且所述更新加載器單獨地更新每一分區(qū)。
26.如權利要求25所述的系統(tǒng),其特征在于,它還包括一確認進程,其中,在引導到所述更新加載器之前,所述確認進程確認至少一個更新包,如果所述至少一個更新包有效,則所述確認進程將每一有效包排隊來更新,并設置一所述引導機制用于檢測所述待決更新的機制。
27.如權利要求26所述的系統(tǒng),其特征在于,所述確認進程通過核查每一包被正確地簽署來確認所述至少一個更新包。
28.如權利要求26所述的系統(tǒng),其特征在于,所述確認進程通過核查每一包被正確地構造來確認所述至少一個更新包。
29.如權利要求25所述的系統(tǒng),其特征在于,所述引導機制基于一在重啟之前設置的標志值將所述設備引導到所述更新模式。
30.如權利要求25所述的系統(tǒng),其特征在于,所述設備的受保護的存儲器被劃分成多個分區(qū),并且其中,由所述更新組件通過為一選擇的分區(qū)構建一替換映象,并將所述替換映象覆寫到所選擇的分區(qū)的現(xiàn)有映象上,更新所選擇的分區(qū)。
31.如權利要求30所述的系統(tǒng),其特征在于,所述更新組件將所選擇的分區(qū)中的所述現(xiàn)有映象備份成一備份映象,用于如果所述替換映象未被成功地寫入所選擇的分區(qū)時恢復到所選擇的分區(qū)。
32.如權利要求31所述的系統(tǒng),其特征在于,所述更新組件以壓縮的形式備份所述現(xiàn)有映象。
33.如權利要求30所述的系統(tǒng),其特征在于,所述設備的受保護的存儲器被劃分成多個分區(qū),并且其中,通過由所述更新組件單獨地更新一選擇的分區(qū)中的至少兩個組件,更新所選擇的分區(qū)。
34.如權利要求33所述的系統(tǒng),其特征在于,所述更新加載器通過向一現(xiàn)有組件應用一二進制差文件更新所選擇的分區(qū)中的組件的至少一個。
35.如權利要求34所述的系統(tǒng),其特征在于,所述更新加載器通過向所述現(xiàn)有組件的一個子集應用所述二進制差文件的一個子集來應用所述二進制差文件。
36.如權利要求33所述的系統(tǒng),其特征在于,所述更新加載器在提交所述更新之前模擬至少一個更新。
全文摘要
所描述的是一種系統(tǒng)和方法,其中,以故障保險的方式向一嵌入式設備的失非易失存儲應用自包含、安全實體形式的軟件更新??蓱酶鞣N類型的軟件更新,并且更新可包含可執(zhí)行代碼和/或數(shù)據。在重啟之后,初始程序加載器確定更新模式,如果是更新,則引導到一特殊的更新加載器。該更新加載器處理更新包來應用更新??捎谜麄€文件或二進制差文件來更新內核分區(qū)、系統(tǒng)分區(qū)和保留分區(qū),對每一類型的更新提供故障處理機制??稍谔峤桓虑澳M更新。更新可在對設備適當時在存儲器內重定位。
文檔編號G06F9/445GK1641582SQ20041010201
公開日2005年7月20日 申請日期2004年12月16日 優(yōu)先權日2003年12月16日
發(fā)明者A·羅杰斯, J·格羅姆, M·普拉格, M·同科洛維茨, M·馬克雷, S·帕特爾, S·謝爾 申請人:微軟公司