基於linux的數字電視機頂盒幾種升級方式的設計與實現

摘要：

本文主要闡述了基於linux操做系統的數字電視機頂盒的經常使用幾種升級方式：OTA,USB,網絡，結合經常使用的bootloader：cfe,u-boot實現升級作了簡述，並綜合對比其各自的優劣。

關鍵詞：

數字電視機頂盒，升級方式，linux，u-boot, cfe ,OTA ,bootloader

隨着技術的突飛猛進，以及爲了知足用戶對功能和使用的要求，須要對機頂盒進行升級來知足需求，升級不只能解決程序的BUG，還能增長新功能，可是升級考慮不全面將會形成不少問題，本文就機頂盒的常見幾種升級方式的設計與實現來進行探討，目前經常使用的升級方式有，OTA升級，USB升級，網絡升級，以及串口升級，因爲目前程序愈來愈大，電腦對串口的支持，尤爲是筆記本電腦通常沒有串行接口，雖然有USB轉串口之類的設備，串口的傳輸速度也是很慢的，因此串口對整個程序的的升級已經愈來愈少。這裏的OTA升級是討論針對數字電視的有線數據傳輸來進行的升級。後面兩種升級方式基本上是嵌入式終端設備的通用升級方式，不限制於具體的設備。

目前的升級，一種方案是直接在bootloader中實現，另一種是bootloader+應用層實現。前者實現難度相對較大，人機界面不是很友好，但能節省部分空間，代碼相對獨立。後者實現難度較低，人際界面也友好，擴展性強，但須要額外的空間，仍然依賴bootloader。

摘自《嵌入式系統BootLoader技術內幕》

對於目前大多數嵌入式操做系統的機頂盒，須要升級的部分大體能夠分爲bootloader，kernel,rootfs+app，有的可能劃分更細。升級程序和bootloader息息相關，通常bootloader起到引導和升級，就須要在機頂盒出廠前已經固化並保證數據安全，爲後續的升級作準備和鋪墊。針對目前經常使用的linux機頂盒環境，bootloader通常有u-boot，cfe，redboot以及其餘一些bootloader。U-boot做爲一種通用的bootloader已經成熟的應用到各類嵌入式設備中，CFE是broadcom公司針對其芯片作的一個通用固件環境，基於MIPS架構。咱們公司擁有目前主流的架構arm架構，super-h架構,mips架構和powerpc，主要用到u-boot和cfe，我主要也就以上兩種bootloader作一些升級方面的討論。

USB升級:

優勢：實現難度小，依賴性小，適合單個升級。

缺點：大批量升級效率較低，須要額外U盤設備。

USB升級針對不一樣的平臺能夠有不一樣的方法，主要的實現方法有底層實現和應用層實現兩種方法。由於如今不一樣平臺的bootloader都提供了對usb存儲設備的支持。有通用bootloader如u-boot,以及某些公司的私有bootloader如broadcom的cfe。

通常狀況下，能夠將升級直接作到bootloader裏面，這樣的好處就是能夠保證安全以及數據依賴性小，缺點就是實現難度相對來講要大一點。USB升級以及tftp升級方式徹底能夠在bootloader裏面來實現，由於其依賴性小，以上的bootloader已經作了這方面的相關驅動，實現起來難度較小，對bootloader環境命令的依賴性較大，有的可能須要修改bootloader的源代碼，添加部分適合升級的命令和程序。後面將提到的OTA升級，因爲其依賴調制解調器，在bootloader中移植難度較大，通常不在bootloader中作。對於大多數NANDFlash，爲了保證數據的安全性，許多廠商都是將bootloader裁剪到128K以內，以知足對bootloader數據的安全性，這就須要從其餘方面來實現以上所說的升級。
針對U-boot的USB升級，U-boot已經對USB設備以及fat分區有了良好的支持，u-boot啓動後，進入到芯片代碼主函數：start_XXXboot,以上XXX能夠是sh4,arm等，根據實際的架構找到相對應的函數。一般咱們能夠在u-boot的引導kernel的以前作相關升級處理。

void start_XXXboot (void)

{

……………

//在這裏添加咱們的USB升級判斷程序。

Usb_init()

Usb_stor_san(1)

//判斷是否須要升級

If(1 == need_update)

{

//置位升級標誌

……………

}

/* main_loop() can return to retryautoboot, if so just run it again. */

for (;;) {

main_loop ();

}

/* NOTREACHED - no way out of commandloop except booting */

}

在main_loop函數中添加具體的升級程序

voidmain_loop (void)

{

…………省略前面代碼……………….

//添加USB升級的具體函數

usb_update_file();

s= getenv ("bootcmd");

debug("### main_loop: bootcmd=\"%s\"\n", s ? s :"<UNDEFINED>");

if(bootdelay >= 0 && s && !abortboot (bootdelay))

……………….

}

這樣就在U-boot下面完成了一個USB升級方案。須要開啓相應的宏開關，如USB，FAT。編譯後能夠將U-boot裁剪到128K以內。這種方式主要先從usb讀取升級文件到內存，再調用u-boot自己的nandwrite的相應燒寫命令來實現的，支持範圍廣，因爲其開源和通用性，因此支持很高，能夠對各類文件系統直接進行燒寫，甚至有些網友移植了在u-boot下直接燒寫ubifs文件系統的命令。是一個很好的擴展，目前U-BOOT支持主流程序的燒寫。

Cfe相對於u-boot來講具備很強的針對性，只針對broadcom的mips架構，cfe對usb進行了封裝，使用各類燒寫都是用統一的flash命令，在CFE中使用USB比u-boot還要方便方便，默認就能夠直接支持tftp,usb燒寫程序，還能夠直接經過網絡或者USB存儲設備直接從內存中啓動，這也爲咱們在CFE下作升級提供了很好的基礎。Cfe封裝了以分區的形式來燒寫程序，但不支持ubifs的直接燒寫。因此在使用CFE燒寫不支持直接文件系統時，能夠有兩種思路：

1. 在CFE中添加對相應文件系統的燒寫支持，此方案的優勢是節省了總的升級時間，缺點是實現難道太大，不一樣的文件系統須要添加不一樣的代碼來適應，增長了CFE代碼量。

2. 在CFE中從內存啓動帶busybox的內核，這塊broadcom有實現，而後經過linux的命令來實現文件系統的燒寫，此方案的優勢是對文件系統支持較大，擴展性很強，缺點是須要用到臨時系統，總的升級時間較第一種長60秒左右。

實現僞代碼以下：

void cfe_main(int a,int b)
{

…………………..//省略CFE初始化代碼

If(TRUE == check_usb_update())

{

exe_usb_update();

}

//下面就是引導內核仍是進入CFE命令行，在這以前添加。

if( !(sflags & NO_STARTUP) )

cfe_auto_sysinit(sflags &FORCE_SYSINIT);

if( !(sflags & NO_STARTUP) )

cfe_autostart();

cfe_command_loop();

}

以上代碼在CFE的兩種方案的USB升級都須要添加，只是具體實如今exe_usb_update中不一樣。Check_usb_update()主要是檢測U盤是否有升級文件和是否須要升級，exe_usb_update()是從U盤中讀寫升級文件並燒寫，完成升級功能。

以上是USB升級的經常使用兩種舉例，通用性較強，只須要根據本身廠商適合的方式來實現代碼便可，也能夠稍微修改做爲工廠批量生產方式，實現徹底自動化。

OTA升級

優勢：用戶參與少，直接由前端控制，適合大批量升級

缺點：依賴前端碼流，依賴機頂盒tuner。

OTA升級（OnTheAir）,又稱空中升級，是指用戶終端直接經過信號通道接收下載方式來升級軟件。是廠家最重要的一種升級方式，用於大批量用戶升級。在手機，以及其餘一些移動終端也有用到，它們主要是經過3G或者Gprs等無線升級方式，也能夠整體歸納到網絡升級中。只是具體區別於一般所說的電信網絡以及這裏的無線網絡和咱們將討論的數字電視網絡。機頂盒的OTA升級數據能夠根據不一樣廠商本身的方式封裝，打包成TS流，而後播放，機頂盒終端接收到流，經過解析NIT等相關表來獲取升級信息。NIT表中主要包括升級頻點的參數信息，如頻率，符號率，調製方式等。在OTA數據的處理上，採用DSM-CC規範。ISO-IEC13818-6裏有對DSM-CC規範的詳細說明。DSM－CC是爲在異構網絡環境下傳送多媒體寬帶業務開發的ISO／IEC標準，特別適合廣播電視網絡。DSM－CC是與傳輸層無關的協議。這樣任何編寫好的使用DSM－CC的應用程序不須要關心其下面的服務器和客戶機之間使用的傳輸層，從純MPEG－2傳輸流網絡到核心ATM網和各類ATM或非ATM的接入網，甚至包括高速局域網，到端到端的ATM網絡的多數寬帶網絡，均可以傳遞使用同一個應用程序。碼流機播出碼流，機頂盒經過解析NIT表獲取到相應的升級信息，傳遞給tuner來進行鎖定，若是鎖定好，則經過dmx來獲取數據，這樣咱們新建一個線程來處理接收到的數據，根據接收數據的起始地址，咱們判斷是DSI仍是DII或者是DDB，咱們必須首要要獲取到DII的信息，由於這裏有DDB數據的總體說明，這有獲取了DII的信息後，咱們才能對所接收的數據是否完整進行判斷。對於不一樣廠家的OTA升級有可能不須要徹底實現DSI,DII,DDB三種，但至少須要實現DII和DDB。這裏面咱們涉及到數據校驗，來保證數據的完整性，若是是對數據進行了加密或者封裝，還須要作相應的解析。咱們一般是將全部升級的全部部分合併成爲一個bin文件，最後再一次性獲取整個bin文件保存到內存中，再分解出各個部分，燒寫到每一個文件制定的地址上去，完成整個升級過程。整個過程只有燒寫程序的時候若是斷電沒法恢復，但因爲燒寫程序的時間很短，概率幾乎爲0，因此安全性仍是能夠保證的。

不一樣平臺的OTA實現也不盡相同，但思路都是須要針對具體平臺對鎖頻，接收和解析碼流，最後燒寫到flash中。

TFTP升級

優勢：簡單。

缺點：依賴於網絡，須要服務端支持。

相信作開發的人都或多或少用過TFTP,NFS，咱們在開發中使用TFTP來作燒寫處理，被認爲是最簡單的方式，一樣只要用戶終端有網絡，並被獲知須要升級，和已知TFTP服務端及文件名，便能很容易的實現升級，在TFTP升級中，咱們不須要額外修改tftp的代碼，只須要爲自動參數傳遞升級的命令便可。

在uboot中須要先設置serverip參數，而後使用

tftp內存地址服務端的文件名如：tftp80000000 vmlinux.ub

在CFE中能夠直接使用

flash–noheader服務器IP：文件路徑分區

如：flsah–noheader 192.168.1.100:/vmlinuz flash0.kernel

考慮到網絡的連通的不肯定性以及丟包的問題，通常咱們在內網中使用或者能夠在工廠批量升級使用。

固然升級方式還有多種多樣，能夠硬盤升級，http,ftp，串口升級等等，串口升級因爲其傳輸速率問題已經不考慮在作整個升級文件的燒寫，目前經常使用串口升級來更新序列號，MAC地址，廠家ID以及版本信息等，其餘的方式不外乎就是經過USB接口或者網口，萬變不離其中，都幾乎能夠從以上三類來進行變種。

參考文獻：

1.《嵌入式系統BootLoader技術內幕》http://www.ibm.com/developerworks/cn/linux/l-btloader/

2.《數字電視系統數據廣播規範》

3.《ISO-IEC13818-6 Mpeg-2 Digital Storage Media Command & Control》