專利名稱：：Bf561的雙核協(xié)調(diào)工作方法
技術(shù)領(lǐng)域：
：本發(fā)明屬于特定芯片上的雙核軟件協(xié)調(diào)工作方法。
背景技術(shù)：
：以單顆ADSPBF561船00MHz實現(xiàn)H.264Dl網(wǎng)絡(luò)攝像(IPCAMERA)產(chǎn)品系統(tǒng)所需的嵌入式LINUX的主控系統(tǒng)、H.264BPDl的視頻實時編碼和基于標準RTP的流媒體傳輸協(xié)議軟件。根本原因緣自ADSPBF561的對稱雙核構(gòu)架正是由于ADSPBF561的這種對稱雙核構(gòu)架，阻礙了它單芯片實現(xiàn)H.264DlIPCAMERA產(chǎn)品。雙核我們稱之為COREA跟COREB，COREA只能用來跑嵌入式操作系統(tǒng)，我們采用的是嵌入式LINUX操作系統(tǒng)，而COREB則是用來跑視頻壓縮編碼算法(H.264)，用ADI提供的集成開發(fā)環(huán)境Visual05++來進行編譯和運行測試。目前業(yè)界存在的問題是，COREA運行的LINUX軟件跟COREB運行的VDSP編譯出來的軟件是不同的，彼此完全不兼容，跑嵌入式LINUX操作系統(tǒng)的COREA是無法運行VDSP編譯的軟件的；而以COREB單核提供的計算能力(MIPS)是遠不能滿足H.264BP柳1實時編碼的計算量的，除非另外一個核COREA也能分擔(dān)一部分編碼的計算，但編碼的算法軟件是獨立的VDSP編譯出來的程序，COREA的嵌入式LINUX操作系統(tǒng)是無法執(zhí)行的。COREA無法為COREB分擔(dān)視頻壓縮編碼算法所需的大量的計算，造成雙核負載的不均衡，使得系統(tǒng)實現(xiàn)失敗，這便是問題的根本癥結(jié)所在。問題的關(guān)鍵在于CORERA跟COREB運行的軟件完全不同，一個是基于LINUX操作系統(tǒng)下的應(yīng)用軟件，而另一個則是完全沒有操作系統(tǒng)下的算法軟件，彼此不兼容，所以不能互相分擔(dān)任務(wù)。那么可以的嘗試就不外乎解決這個兼容性問題，這個則又可歸結(jié)到一個編譯器的問題上，如果兩邊采用同樣的編譯器，則就可解決兼容性的問題。但無論嵌入式LINUX操作系統(tǒng)還是H.264視頻編碼算法都不是一套簡單的軟件系統(tǒng)，都非常復(fù)雜，更換編譯器帶來的編譯問題、解決編譯后的穩(wěn)定性問題、性能損失問題等，都很多。下面的嘗試均不可避免的遭遇這些難題。COREA采用嵌入式LINUX操作系統(tǒng)，編譯器為GNUCC，簡稱gcc;COREB的軟件用VDSP編譯，編譯器為ADI提供的編譯器。VDSP攜帶的編譯器生成的代碼效率要遠遠高于gcc生成的代碼，所以，對于性能優(yōu)化要求極高的視頻壓縮編碼算法而言，采用VDSP編譯環(huán)境才能獲得最佳的性能。嘗試l:COREA采用嵌入式LINUX操作系統(tǒng)，將H.264編碼算法移植到嵌入式LINUX下面，整合到例如FFMPEG等軟件里面去，采用gcc統(tǒng)一進行編譯，則可統(tǒng)一由嵌入式LINUX操作系統(tǒng)進行控制以及視頻壓縮編碼的計算。這樣做有兩個最大的問題(1)嵌入式LINUX對B核的管理，因為這種方式由嵌入式LINUX統(tǒng)一管理雙核，那其實就是一個對稱多處理(SMP)系統(tǒng)，而SMP的實現(xiàn)需要對目前穩(wěn)定的嵌入式LINUX操作系統(tǒng)做大量的改動，這個的實現(xiàn)難度太大，而且日后的穩(wěn)定性不可保證；(2)Gcc編譯出來的H.264視頻壓縮算法的效率低下，比VDSP下生成的代碼需要更多的MIPS來完成同樣的工作，不可取。鑒于此，目前此方法無一成功。嘗試2:COREA采用嵌入式LINUX操作系統(tǒng)，但將其移植到VDSP環(huán)境下，用VDSP的編譯器取代gcc來進行編譯。這樣，雙核的軟件統(tǒng)一在VDSP環(huán)境下統(tǒng)一編譯，可實現(xiàn)相互調(diào)用。這種方式存在的問題目前我司已可完成嵌入式LINUX內(nèi)核在VDSP下的編譯，并可下載到COREA運行起來；但尚未解決對LINUX下應(yīng)用程序(ELF-FLAT可執(zhí)行文件格式)加載的難關(guān)，目前只能通過直接修改ELF-FLAT可執(zhí)行文件的二進制文件的方式來加載最基本的init/shell等進程，而對于IPCAMERA產(chǎn)品所需的更多復(fù)雜的應(yīng)用軟件和協(xié)議軟件則尚無法加載。嘗試3:COREA采用更為精簡的RTOS:uCOS-II,它己經(jīng)由micrium公司完成對blackfin的移植支持，采用VDSP開發(fā)環(huán)境進行編譯，己開放在其官方網(wǎng)站供下載，那么這種方式也是將雙核的軟件統(tǒng)一在VDSP下編譯開發(fā)，則可順利的實現(xiàn)軟件的互通調(diào)用，并完成雙核的負載均衡。這種方式存在的問題uCOS-II以精簡而著稱，故可很方便的移植到VDSP環(huán)境下進行編譯；但精簡帶來的問題就是軟件資源的匱乏。IPCAMERA產(chǎn)品需要大量的網(wǎng)絡(luò)軟件的支撐，包括DDNS、PPP協(xié)議棧、PPPoE協(xié)議軟件、HTTP/WEBSERVER、FTPSERVER、DHCPC/S等等;此外還有文件系統(tǒng)的需求，而這些都是uC0S-II所缺乏的，雖然uC0S-I1也有一些TCP/IP協(xié)議棧、uC-FS等外掛軟件包，但它們的支持還是遠遠不夠的，還需要大量的移植、完善和穩(wěn)定性測試，這個工作量非常大；而對于嵌入式LINUX系統(tǒng)，這些都是久經(jīng)測試，穩(wěn)定可靠的，而且由于其開放性，資源豐富，軟件擴展性遠高于ucos-n;
發(fā)明內(nèi)容本發(fā)明針對現(xiàn)有技術(shù)的不足，克服單核滿足不了H.264BPDl編碼的計算量而雙核又無法協(xié)同工作負載均衡的難題，從而使得單BLACKFIN芯片實現(xiàn)DlH.264嵌入式網(wǎng)絡(luò)攝像機成為可能。本發(fā)明是通過以下技術(shù)方案實現(xiàn)的基于BF561的嵌入式LINUX下H.264柳1視頻實時編碼方法，其特征在于包括以下步驟(1)、通過分析對比BF561芯片內(nèi)COREA上運行的嵌入式LINUX操作系統(tǒng)的可執(zhí)行文件格式(ELF)以及COREB上運行的VDSP編譯生成的H.264視頻壓縮編碼算法軟件程序格式(DXE)，得出二者可執(zhí)行程序格式的差異性和相似性；(2)、通過修改VDSP編譯生成的H.264算法軟件DXE程序中的加載地址的方法，將原本用于COREB執(zhí)行的軟件轉(zhuǎn)化為COREA運行的嵌入式LINUX下的可執(zhí)行程序，從而解決軟件互通性的問題。(3)、在實現(xiàn)COREA可加載COREB的VDSP算法程序后，將H.264柳1視頻實時編碼算法所需的計算負載合理的分配到COREA跟COREB去，使得雙核共同分擔(dān)H.264柳1實時編碼所需的高運算量，并同時保證了COREA原有嵌入式LINUX系統(tǒng)及其通信協(xié)議軟件的順利運行。本發(fā)明鑒于BF561芯片內(nèi)部的兩個核COREA跟COREB分別運行嵌入式LINUX操作系統(tǒng)跟H.264柳1視頻壓縮編碼算法軟件，而H.264@D1的視頻實時壓縮編碼算法的計算復(fù)雜度遠遠超出了COREB單核所能提供的計算能力(MIPS),COREA運行的嵌入式LINUX操作系統(tǒng)則有計算能力的空余，因此本發(fā)明實現(xiàn)了COREA的LINUX系統(tǒng)能分擔(dān)一部分COREB的H.264編碼任務(wù)，實現(xiàn)負載均衡；解決了COREA與COREB軟件的互通性和兼容性。從而克服blackfin單核滿足不了H.264BPDl編碼的計算量而雙核又無法協(xié)同工作負載均衡的難題。在blackfin平臺上可實現(xiàn)Dl(704x576)分辨率的視頻監(jiān)控，使單顆BLACKFIN芯片實現(xiàn)DlH.264嵌入式網(wǎng)絡(luò)攝像機可提供更高的清晰度，滿足日益增長的監(jiān)控安防行業(yè)對圖像清晰度的要求；為我國平安城市工程提供更優(yōu)質(zhì)的視頻監(jiān)控圖像和錄像，并可達到監(jiān)控行業(yè)對分辨率要求的行業(yè)標準，有著重大的經(jīng)濟效益和社會效益。具體實施例方式在COREA的嵌入式LINUX操作系統(tǒng)下，為COREB的視頻編碼算法定制了一個加載器，并通過獨創(chuàng)優(yōu)化的負載均衡的算法，使得雙核各自分擔(dān)一部分編碼算法所需的MIPS,同時COREA還在穩(wěn)定運行嵌入式LINUX操作系統(tǒng)、外圍設(shè)備的驅(qū)動以及流媒體傳輸協(xié)議棧軟件，從而滿足了一個H.264DlIPCAMERA的系統(tǒng)資源需求?，F(xiàn)分述如下1)首先解釋下COREA運行的LINUX操作系統(tǒng)下的可執(zhí)行文件格式_一ELF格式每個操作系統(tǒng)都會有自己的可執(zhí)行文件的格式，比如以前的Unix⑧是用a.out格式的，現(xiàn)代的Unix/Linux類系統(tǒng)均使用elf格式，沐^(1(^3訂@是使用基于COFF格式的可執(zhí)行文件。ELF文件有三種類型可重定位文件也就是通常稱的目標文件，后綴為.o。共享文件也就是通常稱的庫文件，后綴為.SO。可執(zhí)行文件本文主要討論的文件格式，總的來說，可執(zhí)行文件的格式與上述兩種文件的格式之間的區(qū)別主要在于觀察的角度不同一種稱為連接視圖(LinkingView),—種稱為執(zhí)行視圖(ExecutionView)。幾個重要的概念relocations的概念動態(tài)連接技術(shù)，a.out格式不能支持動態(tài)鏈接，ELF可支持。elf的動態(tài)連接庫是內(nèi)存位置無關(guān)的，就是說你可以把這個庫加載到內(nèi)存的任何位置都沒有影響。這就叫做positionind印endent。而a.out的動態(tài)連接庫是內(nèi)存位置有關(guān)的，它一定要被加載到規(guī)定的內(nèi)存地址才能工作。在編譯內(nèi)存位置無關(guān)的動態(tài)連接庫時，要給編譯器加上-fpic選項，讓編譯器產(chǎn)生的目標文件是內(nèi)存位置無關(guān)的還會盡量減少對變量引用時使用絕對地址。把庫編譯成內(nèi)存位置無關(guān)會帶來一些花費，編譯器會保留一個寄存器來指向全局偏移量表(globaloffsettable(orGOTforshort)),這就會導(dǎo)致編譯器在優(yōu)化代碼時少了一個寄存器可以使用，但是在最壞的情況下這種性能的減少只有3%，在其他情況下是大大小于3%的。Elf的另一個特點是它的動態(tài)連接庫是在運行時處理符號的，這是通過用符號表和再布置(relocation)表來實現(xiàn)的。在載入文件時并不能立即執(zhí)行，要在處理完符號表把所有的地址都relocation完后才可以執(zhí)行。當(dāng)從動態(tài)連接庫中讀一個全局變量時與從非-fpic編譯的目標文件讀是不同的。讀動態(tài)連接的庫中的變量是通過GOT來尋找到目標變量的，GOT己經(jīng)由某一個寄存器指向了。GOT本生就是一個指針列表，找到GOT中的某一個指針就可以讀到所要的全局變量了，有了GOT我們要讀出一個變量只要做一次relocation。下面是對LINUX操作系統(tǒng)對ELF文件加載過程的一個簡單描述1:內(nèi)核首先讀ELF文件的頭部，然后根據(jù)頭部的數(shù)據(jù)指示分別讀入各種數(shù)據(jù)結(jié)構(gòu)，找到標記為可加載(loadable)的段，并調(diào)用函數(shù)mmap()把段內(nèi)容加載到內(nèi)存中。在加載之前，內(nèi)核把段的標記直接傳遞給mmap()，段的標記指示該段在內(nèi)存中是否可讀、可寫，可執(zhí)行。顯然，文本段是只讀可執(zhí)行，而數(shù)據(jù)段^是可讀可寫。這種方式是利用了現(xiàn)代操作系統(tǒng)和處理器對內(nèi)存的保護功能。2:內(nèi)核分析出ELF文件標記為PT_INTERP的段中所對應(yīng)的動態(tài)連接器名稱，并加載動態(tài)連接器?，F(xiàn)代LINUX系統(tǒng)的動態(tài)連接器通常是/lib/Id-li而x.so.2。3:內(nèi)核在新進程的堆棧中設(shè)置一些標記-值對，以指示動態(tài)連接器的相關(guān)操作。4:內(nèi)核把控制傳遞給動態(tài)連接器。5:動態(tài)連接器檢査程序?qū)ν獠课募?共享庫)的依賴性，并在需要時對其進行加載。6:動態(tài)連接器對程序的外部引用進行重定位，通俗的講，就是告訴程序其引用的外部變量/函數(shù)的地址，此地址位于共享庫被加載在內(nèi)存的區(qū)間內(nèi)。動態(tài)連接還有一個延遲(Lazy)定位的特性，即只在〃真正〃需要引用符號時才重定位，這對提高程序運行效率有極大幫助。7:動態(tài)連接器執(zhí)行在ELF文件中標記為.init的節(jié)的代碼，進行程序運行的初始化。在早期系統(tǒng)中，初始化代碼對應(yīng)函數(shù)—init(void)(函數(shù)名強制面定)。8:動態(tài)連接器把控制傳遞給程序，從ELF文件頭部中定義的程序進入點開始執(zhí)行。在a.out格式和ELF格式中，程序進入點的值是顯式存在的，在C0FF格式中則是由規(guī)范隱含定義。從上面的描述可以看出，加載文件最重要的是完成兩件事情加載程序段和數(shù)據(jù)段到內(nèi)存;進行外部定義符號的重定位。重定位是程序連接中一個重要概念。一個可執(zhí)行程序通常是由一個含有main()的主程序文件、若干目標文件、若干共享庫(SharedLibraries)組成。(注采用一些特別的技巧，也可編寫沒有main函數(shù)的程序，請參閱參考資料2)—個C程序可能引用共享庫定義的變量或函數(shù)，換句話說就是程序運行時必須知道這些變量/函數(shù)的地址。2)關(guān)于COREB下運行的VDSP編譯生成的H.264算法程序的可執(zhí)行文件格式一一DXE文件格式DXE文件是VDSP下編譯的軟件的可執(zhí)行文件格式，它實際上是ELF格式的一種變種。鏈接描述文件(.LDF)定義了整個系統(tǒng)的存儲器配置和程序中數(shù)據(jù)及代碼的具體存放位置。加載核文件(.DXE)是指加載引導(dǎo)核程序，其大小為32bit，放在加載文件的起始部分，其功能是用來實現(xiàn)ADSPBlackfin的正確引導(dǎo)。加載文件是由引導(dǎo)加載器(elfloader)將可執(zhí)行文件進行一定的格式變化，并在起始位置附加上加載核文件生成的。DXE文件是在elf文件格式的基礎(chǔ)上添加了一些VDSP特有的配置，如elf文件頭中的e—type設(shè)置，還有一些特殊的調(diào)試段.annotations,.attributs等等。但是在這其中只有幾個段是必須的空段這是elf文件中的第一個段，其中不包含任何信息，其段頭配置全為O。至少一個保存字符串的段這個段通常為第二個段，用以存放段名稱等字符串。程序段就是程序代碼，每個段不超過65535個字節(jié)。processor:這個段不是必須的，VisualDSP通過這個段來識別程序所針對的DSP類型。它的內(nèi)容是一個字符串，如"ADSP-BF531"、"ADSP-BF561"等等。如果沒有這個段，VisualDSP將認為DXE程序就是針對設(shè)置好的session開發(fā)的。將￥05++編譯生成[].264算法軟件的可執(zhí)行文件(.dxe文件)，利用VDSP提供的elf2flt工具將這個dxe文件轉(zhuǎn)換成fit格式。嵌入式LINUX是一種特殊的Linux，叫uClinux，它的可執(zhí)行文件的格式是由ELF經(jīng)轉(zhuǎn)換生成的FLAT格式。在uclinux中，對FLAT可執(zhí)行文件的加載是由fs/binfmt—flat,c這個文件來完成的，所需要做的是在這個文件的合適位置斷下來，并取得相關(guān)的指針，進行數(shù)據(jù)分析，以求獲得.dxe與FLAT格式的差異，為轉(zhuǎn)換提供支持。經(jīng)過對此文件的分析，可以在load_flat_file這個函數(shù)中設(shè)置斷點，并進行單步跟蹤。在此過程中還發(fā)現(xiàn)VDSP會將轉(zhuǎn)換生成的fit格式文件的rev字段設(shè)置為5，而uclinux只支持2和4的版本，在此處還需要將rev的值改為4。我們就可以取得這個FLT文件在內(nèi)存中的分布位置了，將code，data,bss這三個段的起始位置和結(jié)束位置記錄下來。為了保證VDSP中生成的DXE文件中的調(diào)試信息地址與uclinux加載的地址一致，還需要回過頭修改VDSP工程LDF文件中的幾個地址。把COREB的DXE可執(zhí)行文件中的加載地址改為uclinux實際加載的地址，并重新編譯生成一個DXE文件，則這個.dxe文件就是可為uclinux執(zhí)行的與FLAT兼容的可執(zhí)行文件。關(guān)于負載均衡算法相比網(wǎng)絡(luò)通信等應(yīng)用領(lǐng)域的負載均衡算法，我們這里的負載均衡算法就要簡單很多，主要目的就是將優(yōu)化過的H.264算法所需的MIPS合理的分配到COREA跟COREB去，使得單芯片BF561可在COREA運行嵌入式LINUX操作系統(tǒng)進行外圍控制和網(wǎng)絡(luò)協(xié)議棧的同時，可順利完成視頻流的H.264Dl實時編碼。權(quán)利要求1、BF561的雙核協(xié)調(diào)工作方法，其特征在于包括以下步驟(1)、通過分析對比BF561芯片內(nèi)COREA上運行的嵌入式LINUX操作系統(tǒng)的可執(zhí)行文件格式(ELF)以及COREB上運行的VDSP編譯生成的H.264視頻壓縮編碼算法軟件程序格式(DXE)，得出二者可執(zhí)行程序格式的差異性和相似性；(2)、通過修改VDSP編譯生成的H.264算法軟件DXE程序中的加載地址的方法，將原本用于COREB執(zhí)行的軟件轉(zhuǎn)化為COREA運行的嵌入式LINUX下的可執(zhí)行程序；(3)、在實現(xiàn)COREA可加載COREB的VDSP算法程序后，將H.264@D1視頻實時編碼算法所需的計算負載合理的分配到COREA跟COREB去，使得雙核共同分擔(dān)H.264@D1實時編碼所需的高運算量。全文摘要本發(fā)明涉及BF561的雙核協(xié)調(diào)工作方法，包括以下步驟得到COREA的格式為ELF，得到COREB的格式為DXE，對比字段，得到可執(zhí)行文件格式的差異；把COREB程序格式轉(zhuǎn)化為COREA可執(zhí)行的程序格式；把COREB的DXE可執(zhí)行文件中的加載地址改為uclinux實際加載的地址，并重新編譯生成一個DXE文件，這個DXE文件就是可為uClinux執(zhí)行的與FLAT兼容的可執(zhí)行文件；H.264算法所需的MIPS合理的分配到COREA跟COREB去。本發(fā)明解決了blackfin單核滿足不了H.264BPD1編碼的計算量而雙核又無法協(xié)同工作負載均衡的難題。文檔編號H04N7/26GK101378509SQ200810107249公開日2009年3月4日申請日期2008年10月6日優(yōu)先權(quán)日2008年10月6日發(fā)明者劉昌進,磊王,趙玉春,陳明智,寧黃,黃守卓申請人:合肥優(yōu)視嵌入式技術(shù)有限責(zé)任公司