【文章內(nèi)容簡(jiǎn)介】 成了 。 因?yàn)榇藭r(shí)的系統(tǒng)還沒(méi)有任何的用戶應(yīng)用程序，但是下載到開(kāi)發(fā)板可與看到自己的根文件系統(tǒng)目錄了。 典型 的Bootloader、 bootloader 參數(shù)、內(nèi)核映像和嵌入式根文件系統(tǒng)在 FLASH 上的存儲(chǔ) 如下圖所示。 圖 41嵌入式最小系統(tǒng)構(gòu)成 GUI 圖形用戶界面 、通信協(xié)議棧和 音視頻解碼器 mppalyer 三個(gè) 主要 模塊 集 成在一起就構(gòu)成了論文的嵌入式用戶應(yīng)用程序 。 與 前面的最小 嵌入式系統(tǒng)結(jié)合一起 就構(gòu)成了視頻點(diǎn)播系統(tǒng) 體系 。 體系結(jié)構(gòu) 如圖 42 所示。 9 圖 42 嵌入式流媒體播放系統(tǒng) 體系結(jié)構(gòu) 實(shí)現(xiàn)模式： C/S模型 嵌入式視頻點(diǎn)播系統(tǒng)要實(shí)現(xiàn)本地播放和網(wǎng)絡(luò)播放的功能，本地播放是讀取 U盤(pán) 中預(yù)先存在的視頻文件進(jìn)行播放。網(wǎng)絡(luò)播放時(shí)在播放時(shí)連接服務(wù)器，連接成功后，讀取服務(wù)器的視頻資源，更新網(wǎng)絡(luò)播放列表 ，點(diǎn)擊相應(yīng)的視頻文件后， QT視頻播放 客戶端會(huì)調(diào)用 開(kāi) 源軟件 mplayer 進(jìn)行音視頻解碼將視頻顯示在播放器播放窗口， 并且在播放的狀態(tài)下 支持隨機(jī)訪問(wèn)，可以進(jìn)行暫停、快進(jìn)、快退等交互式操作 。 C/S 工作模型如圖 43所示。 應(yīng)用層 ： 內(nèi)核層 ： 引導(dǎo)層 ： 硬件層 ： 通信協(xié)議棧 音視頻解碼 GUI 嵌入式應(yīng)用程序 Linux內(nèi)核 根文件系統(tǒng) Bootloader 硬 件 平 臺(tái) 嵌入式微處理器 外 圍 設(shè) 備 10 圖 43 VOD 服務(wù) 模型 在用戶進(jìn)行播放點(diǎn)播 的過(guò)程中 ，服務(wù)器 必須 要 開(kāi)啟 服務(wù) 和流媒體傳輸兩個(gè)服務(wù) [10]， 通過(guò) 協(xié)議， 用戶可以向服務(wù)器端發(fā)送視頻點(diǎn)播的請(qǐng)求 ， 通過(guò) RTP/RTSP 進(jìn)行視頻數(shù)據(jù)流的傳輸和控制 。 播放器的 RTSP 服務(wù)器工作流程 [11]主要步驟如圖 44 所 示 。 圖 44服務(wù)器工作流程 開(kāi)始 監(jiān)聽(tīng) TCP 端口 等待客戶連接 請(qǐng)求連接 接受連接 創(chuàng)建新連接 接受客戶消息 關(guān)閉連接 執(zhí)行客戶消息 響應(yīng)客戶消息 結(jié)束 N N VOD Server Client RTSP 控制信息（ TCP） RTP 音、視頻（ UDP） RTCP 分組 (UDP) HTTP 點(diǎn)播請(qǐng)求 11 5 系統(tǒng)的詳細(xì)設(shè)計(jì) 及實(shí)現(xiàn) 該部分介紹了系統(tǒng)的實(shí)施細(xì)節(jié)，包括嵌入式系統(tǒng)開(kāi)發(fā)環(huán)境的搭建， uboot、kernel 移植以及視頻播放主界面的設(shè)計(jì)。 嵌入式系統(tǒng)開(kāi)發(fā)環(huán)境的 搭建 建立工作目錄 mkdir p /opt/FriendltARM/mini2440 //mini2440 工作目錄 mkdie p /tmp/linux //各種所需源文件都拷貝到該目錄下 建立交叉編譯環(huán)境 cd /opt/FriendltARM/mini2440 解壓 安裝 編譯器 tar xvzf /tmp/linux/ – C / 添加系統(tǒng)環(huán)境變量如下 gedit /root/.bashrc export PATH=$PATH: /opt/FriendlyARM/toolschain/ 解壓安裝 內(nèi)核源代碼 tar xvzf /tmp/linux/ 解壓安裝嵌入式圖形系統(tǒng) armqtopia 和 x86qtopia 源代碼 tar xvzf /tmp/linux/ tar xvzf /tmp/linux/ 解壓安裝嵌入式圖形系統(tǒng) tar xvzf /tmp/linux/ 解壓安裝 源代碼 tar xvzf /tmp/linux/ 解壓安裝 Linux 示例程序 tar xvzf /tmp/linux/ 解壓安裝 uboot 工作目錄 12 tar xvzf /tmp/linux/ 創(chuàng)建 bootloader 工作 目錄，里 有 vivi 和 uboot 源代碼 tar xvzf /tmp/linux/ – C / 改變工作目錄后會(huì) 被安裝到 /usr/sbin 目錄下， 自動(dòng) 生成 mkyaffs2image 和 mkyaffs2image128M。 解壓安裝 LogoMaker 開(kāi)機(jī)啟動(dòng)畫(huà)面制作工具 tar xvzf /tmp/linux/ – C / 在開(kāi)發(fā)時(shí)經(jīng)常用到 NFS、 TFTP 和 SMB 服務(wù)，所以系統(tǒng)服務(wù) 要 事先配置好并且保證正常運(yùn)行。 所建立的 mini2440 工作目錄如 51所示。 圖 51 虛擬機(jī)下工作目錄 嵌入式 linux 的 uboot移植 bootloader 介紹 嵌入式 系統(tǒng)的引導(dǎo)加載程序是系統(tǒng)必不可少的一部分，引導(dǎo)加載程序是系統(tǒng)加電后運(yùn)行的第一段軟件代碼 。 其作用 類似于 PC 中的 BIOS,BootLoader 就是在 13 操作系統(tǒng)內(nèi)核運(yùn)行之前運(yùn)行的一段小程序。 這段程序 主要作用就是 初始化硬 件設(shè)備、生成 內(nèi)存 映射圖等，為最后 調(diào)用嵌入式 內(nèi)核 做好充足的 前期 準(zhǔn)備 。 Bootloader 一般有兩種啟動(dòng)模式即啟動(dòng)加載模式和下載模式。下載模式主要是針對(duì)嵌入式開(kāi)發(fā)人員的 ，因?yàn)榍度胧揭浦策^(guò)程中的各種調(diào)試基本都是這種模式來(lái)實(shí)現(xiàn)的，下載模式可以通過(guò)串口、 NFS、 TFTP 等方式實(shí)現(xiàn)。 在下載模式下， uboot為用戶提供一個(gè)命令行接口，通過(guò)接口可以使用 uboot 提供的一些命令進(jìn)行相應(yīng)操作 。 啟動(dòng)加 載模式是產(chǎn)品發(fā)布時(shí)必須置為的模式，在這種模式下啟動(dòng)系統(tǒng)不需要用戶的干涉，自動(dòng)從目標(biāo)主機(jī)的存儲(chǔ)設(shè)備上將操作系統(tǒng)加載到內(nèi)存中運(yùn)行。 在嵌入式 Linux 中 BootLoader 的重要性 由于 BootLoader 需要直接操作硬件， 所以 想在嵌入式世界建立一個(gè)通用的引導(dǎo) 加載 程序是很困難的，因?yàn)橐话悴煌挠布脚_(tái)不同的操作系統(tǒng)所需的加載引導(dǎo)程序不同。所能做的就是讓一種加載引導(dǎo)程序支持盡量多的平臺(tái)，賦予它良好的移植性。 Uboot 就是支持多平臺(tái)多操作系統(tǒng)的 優(yōu)秀 引導(dǎo) 加載 程序，這也 是Uboot 的優(yōu)勢(shì) 。因而針對(duì)不同的嵌入式平臺(tái)要進(jìn)行 加載引導(dǎo)程序 相關(guān)的修改以滿足項(xiàng)目需求。 uboot 引導(dǎo)流程 Bootloader啟動(dòng)流程大多經(jīng)過(guò)兩個(gè)階段，即啟動(dòng)可以分為 stage1和 stage2。stage1 完成初始化 硬件的工作 ，為 stage2 準(zhǔn)備 足夠的 內(nèi)存空間，并將 stage2可執(zhí)行映像 復(fù)制到內(nèi)存中，設(shè)置堆棧，然后轉(zhuǎn)調(diào)到 stage2 的 C入口。 Stage2 一般包括以下幾個(gè) 步驟，初始化本階段要用到的硬件設(shè)備，將 制作好的 內(nèi)核映像和根文件系統(tǒng)從 Flash 讀到 RAM 中，調(diào)用內(nèi)核 ， 跳轉(zhuǎn)到 MEMSTART+0x8000地址處，一般是 使用 x030008000 地址。 啟動(dòng)的 stagel 一般 用匯編語(yǔ)言來(lái)實(shí)現(xiàn) ， 匯編語(yǔ)言能更加高效的實(shí)現(xiàn)對(duì)底層硬件的操作且代碼量小， 對(duì)應(yīng)的是 文件。 而stage2 則一般 用 C 語(yǔ)言來(lái)實(shí)現(xiàn)，這樣 做 不僅可以實(shí)現(xiàn)更加 復(fù)雜的功能，而且具有 良好的可讀性和 移植性。 啟動(dòng)代碼中 C 語(yǔ)言的主函數(shù)是 在 lib_arm/中的 start_armboot。 兩個(gè)階段的引導(dǎo)的主要流程如下所示。 14 圖 52 兩個(gè)階段啟動(dòng)流程圖 uboot 移植步 驟 移植就是根據(jù)開(kāi)發(fā)板和系統(tǒng)需求做相應(yīng)的修改 。 UBoot 還 沒(méi)有支持 三星S3C2440 微處理器 ，移植仍是用 UBoot 支持的友善之臂 SBC2410 的文件作藍(lán)本來(lái)移植，因?yàn)?SBC2410 和 mini2440 硬件配置最為接近 ，使用一個(gè)模板可以加快移植的速度和效率 。 所以移植所要做的就是針 S3C2440 和 SBC2410 的不同，以及 SBC2410 和 mini2440 開(kāi)發(fā)板的外設(shè)不同作相應(yīng)的修改，并增加新的功能。S3C2440 和 S3C2410 的區(qū)別主要是 S3C2440 的主頻更高 ， 其他 內(nèi)部 寄存器基本都 是兼容 的。 本系統(tǒng)中，使用 mini2440 開(kāi)發(fā)板，采用 uboot 作為 S3C2440 處理器 的BootLoader。 設(shè)置 CPU 為 SVC 關(guān)閉看門(mén)狗 /禁所有中斷 /設(shè)置 cpu 頻率 復(fù)制 stage2 可執(zhí)行 映像 到 SDRAM 中 設(shè)置堆棧指針 跳轉(zhuǎn) stage2 c 入口 Stage2： 加載內(nèi)核和根文件 設(shè)置內(nèi)核的啟動(dòng)參數(shù)。 調(diào)用內(nèi)核 Stage1： 檢測(cè) 內(nèi)存映射 15 建立開(kāi)發(fā)板文件并 測(cè)試編譯環(huán)境 修改頂層 Makefile 目的：定義交叉編譯工具鏈和開(kāi)發(fā)板配置選項(xiàng)。 約定：代碼中 +和 號(hào)表示增刪 vi Makefile +CROSS_COMPILE = armnonelinuxgnueabi +mini2440_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t mini2440 andywsg s3c24x0 在 /board 中建立 mini2440 目錄和文件 在 /board 目錄中建立開(kāi)發(fā)板 mini2440 的目錄，并復(fù)制 sbc2410x 的文件到此，做適當(dāng)修改。目的：以 sbc2410x 為藍(lán)本，因?yàn)?sbc2410 和 mini2440 配置最接近， 代碼復(fù)用，這樣可以 加快移植進(jìn)度。 cd board mkdir andywsg/mini2440 cp arf sbc2410x/* andywsg/mini2440/ cd andywsg/mini2440/ mv 在 include/configs/中建立開(kāi)發(fā)板配置文件 目的 :制作 mini2440 所需頭文件 cp include/configs/ include/configs/ 測(cè)試編譯環(huán)境 在 uboot 頂層目錄執(zhí)行 make mini2440_config make 編譯通過(guò) 如 圖 53 所示 。以上測(cè)試通 過(guò)后，說(shuō)明編譯環(huán)境和基本的開(kāi)發(fā)板 代碼創(chuàng) 16 建都沒(méi)有問(wèn)題。下面所做 工作就是針對(duì) mini2440 進(jìn)行修改，以滿足項(xiàng)目需求 。Uboot 修改主要經(jīng)歷四 個(gè)階段，第一階段修改啟動(dòng)代碼，包括初始化 CPU頻率，代碼重定向等。第二階段修改初始化代碼 ，主要是 mini2440 平臺(tái)初始化。第三階段是初始化外設(shè)，包括 LCD、網(wǎng)卡和 YAFFS2 文件 系統(tǒng) 支持等。 第四階段修改編譯配置文件，在所有有編譯條件的地方加入對(duì) mini2440 的編譯 支持 ，這樣前面修改的代碼才會(huì)在編譯時(shí)編譯進(jìn)來(lái)。 下面是對(duì) uboot 源碼修改后 編譯 的結(jié)果。 圖 53 uboot 編譯結(jié)果 linux 內(nèi)核配置與編譯 內(nèi)核 簡(jiǎn)介 內(nèi)核是所有 linux 系統(tǒng)的核心軟件組件，其性能很大程度上決定了整個(gè)系統(tǒng)的性能。本系統(tǒng)中，嵌入式 Linux 內(nèi)核選擇 。 本身已經(jīng)提供了對(duì) mini2440 的部分支持。 內(nèi)核移植 就是根據(jù)開(kāi)發(fā) 系統(tǒng)的需要對(duì)已有的系統(tǒng)進(jìn)行裁減，保留需要的模塊去掉不需要的模塊， 生成一個(gè)適合目標(biāo)嵌入式系統(tǒng)的過(guò)程。 17 建立 目標(biāo)平臺(tái) 指定 平臺(tái) 交叉編譯變量 cd vi Makefile ARCH ?= $(SUBARCH) CROSS_COMPILE ?= +ARCH ?= arm +CROSS_COMPILE ?= armlinux 這里面的 ARCH ?= arm 是指定目標(biāo)平臺(tái)為 arm 平臺(tái) ， CROSS_COMPILE ?= armlinux是指定交叉編譯器是 。 添加 自己的 開(kāi)發(fā)板信息 cd rm rf arch/arm/machs3c2440/ cp arf arch/arm/machs3c2440/ arch/arm/machs3c2440/mach vi arch/arm/machs3c2440/ 把 MACHINE_START(S3C2440, SMDK2440) ， 修改成 MACHINE_START(MINI2440, FriendlyARM Mini2440 development board)。 修定 開(kāi)發(fā)板 時(shí)鐘源頻率 在 ( 就是 剛剛通過(guò)復(fù)制 得到的 )static void __init smdk2440_map_io(void)函數(shù)中，把原來(lái) 的 16934400(代表原 SMDK2440 目標(biāo)板上的晶振是 )改為 mini2440 開(kāi)發(fā)板上實(shí)際使用的 12021000(代表 mini2440 開(kāi)發(fā)板上的晶振 12MHz)。 克隆 SMDK2440 成 MINI2440 平臺(tái) 克隆 自己的 mini2440 平臺(tái)，需要 把 中所有的 smdk2440 字符串改為 mini2440 。