Just Linux

之前提過的 , 要進入Embedded Linux系統 , 有太多可以進入的管道. 譬如寫寫API , 像是gtk+, Qt,  Mini Gui等 , 要不就玩玩Kernel build , 替核心加些新玩意什麼的 , 但就我個人而言 , 最有趣的莫過於是拿一個可以接在系統上的周邊 , 替它寫隻驅動程式 , 就像是在玩LEGO NXP機器人時, 藉由一些指令 , 可以讓機器人擺擺手 , 點點燈 , 感覺像是賦與其生命一樣的令人感動.   只是相較於機器人的簡易逗趣 , 驅動程式的撰寫 , 就顯得複雜許多 , 再加上使用的系統硬體 , 以及Linux 版本 , 往往讓一開始想進入的初學者摸不著邊際 , 而顯得挫折滿滿. 如果你也有這樣的問題的話 , 下面剖析一些進入Linux Device driver的方式 , 或許對你就能有些幫助.
一開始 , 我想你必須有一台能build linux image的電腦. 不管你是用vm ware , cygwin或是另外備一台電腦 ,要不就是切partition , 這都不管 , 只要你能在電腦上 , 建置一套已經有 gcc , glibc 等工具的系統 , 就能開始寫些linux image. 不過 , 以我個人建議 , 如果你身邊有一台個人電腦 , 你可以直接找一套市面上 linux distribution來安裝. 像是Fedora , SUSE , UBUTN ...., 當然這些Distribution 一定會有不同的版本 , 理所當然的會建議找越新的版本 , 對你手頭上硬體的支援性也就越高. 等一下 , 我所demo的程式片段 , 都是以Fedora 8 的版本來執行. 至於怎麼安裝 , 坊間有太多的資訊 , 就請自行翻閱查找囉.
有些同好初學者 , 曾經有這麼一個問題 , 一開始進入Device driver的領域時 , 倒底要選那一個版本的作業系統做開始呢? 2.4.x? or 2.6.x ? 我個人是覺得 , 2.6.x相對的成熟 , 周邊應用程式的支援性也比較高 , 許多Distribution 的人機介面 , 做的也比較理想 ; 或著是說比較像是熟悉的windows , 能一邊在上面寫程式 , 一邊聽mp3 , 會不會比較人性呢? 比較不會顯得枯燥呢? 前者的答案是肯定的. 但至於枯燥這一檔事 , 我只覺得 , 如果你是windows programmer ,  可能長期習慣在windows黑盒子周邊生存 , 遇到問題時, 你也只能摸著鼻子束手無策 ,所以難免會有寫code寫得既悶且煩的問題. 但如果你是linux的愛好者 , 你就會發現 , 隨著你對系統的熟捻度越高 , 遇到問題時 , 你可以隨心所欲的在核心瀚海裏查找 , 反正code是open的 , 除了你可以有mail forum的眾多高手可以問不說 , 你要是對原始的code不爽 , 那就自己動手改嘛. 完全by youself. 當然 , 要是動到核心的部份 ,可得遵手GPL的規定. 這是Linux當初創建的精髓. 最後回到我們一開始討論初學者進入的角度. 在你還沒有把功力練到一定的的層級前 , 我個人會認為 , 2.6.x版本 , 會讓出學者比較容易入手 . Fedora 系統都是base on Linux 2.6.x 版本開發的 , 相對的符合我們等會介紹的需求.
接下來 , 假設大家都已經準備好一台可以build linux code 的電腦 了, 也大概知道 "make Makefile" 是怎麼一回事 , 如果你對基本的語法仍是一頭霧水的話 , 很抱歉 , 你可能得先離席 , 先去k點這方面的資料後再回來. 坊間有許多書籍可供參考 , 像是歐萊禮的 "建構嵌入式系統" , 就算是一本不錯的入門書.
開始介紹Device driver前 , 我習慣將內容分成下列幾部份:

        在主機(Host)建立一個主機系統 , 其實該說是很容易的. 坊間有太多的開發套件(distribution) , 像是早期的RedHat , 或是Fedora , Mandrake , Suse等 , 多的不勝枚舉. 通常只有follow安裝光碟的步驟 , 就能很清楚的將一個帶有GUI(Graphic User Interface) 給安裝在你的電腦主機上. 但想要進入Linux 嵌入式系統(Embedded System) , 這只是一個最基本的課題而已.....
我們將面臨到的有:
1. 選定什麼樣的Target Board , 作為實現嵌入式的系統的平台.
        2. 想將什麼樣的系統  , Built到Target Board上.
        3. 選定何種Bootload 來起動你的核心(zImage)

好久沒上來寫寫Linux的玩意兒 ~ 除了忙著公事外 , 其實也花上了大半的時間 , 在研究Google的手機開放平台--Android.
其實 , 如果一開始 , 就要把Android定為手機開放程式的平台 , 只能說是因為Google想藉著這日趨成熟的Smart Phone市場 , 大力的推廣其Google社群的魅力所在. 但其實 , 按未來最大的可能 , 應該是要將Android定位在MID(Mobile Internet Device)的類別 , 也就是說 , 只要是一個可攜式的通信裝置 , 多可以藉由Android的開放平台大力的開發. 所以 , 隨著未來無線網路通信設備的更加普及 , 數據傳輸的廣泛度更加成熟 , 幾乎可以預期會有許多的相關的周邊產品 , 使用該平台的SDK來撰寫應用程式及作業系統.
如大家所知的的 Android是Linux background的產品. 在玩了好一陣子的Embedded Linux , 終於見到有一個比較完整的社群在大力的推廣. 我想有興趣著墨這一塊的 , 該是共襄盛舉的好時機.
----以下是IP設計商 , 正大力的將Android這套作業系統 ,給po在其IP能建置的各項不同的處理器及衍生的電子產品上. 可以預期的 , 越來越多的商品 , 被"Android化"是指日可待的.

fuser 這指令, 乍看之下都會讓人解讀為 "fuse --保險絲 " , 但在Linux中, 應該是解釋為 File using

什麼時後會用到fuser這指令呢, 大體是你想知道有那一個程序 , 正使用著系統的某些接口. 像是那一個網路介面 , 或是那一個檔案系統掛載等.  由其是當我們想卸載某一檔案系統 , 如 umount /dev/win_d ,  卻一直出現 "Device is Busy" 的訊息, 就可以使用 fuser , 把正佔住該資源的程序給找出來.

例如

#fuser -m -v /mnt/win_d       會出現
                      USER       PID    .... COMMAND

常用 Windows的user 一定很習慣 , 當系統出現藍色之死時 , 我們會同時按 " Alt" + "Ctrl " +"Del " , 來起動工作管理員 ,好來看看倒底是那一隻程式當掉了,  或著是死命的佔住系統資源. 然後點選刪除或停用.

這樣的問題 , 在Linux上也是會發生 , 當系統因為某些程序 crash時 , 會出現系統無法釋放資源等現像, 例如我們要umount /dev/win_d , 但老是出現 Device is busy這檔事. 我們就可以使永 "ps " 這指令 , 來好好的觀察到底是那一隻process , 偷偷的在內層搞鬼.

#ps         可以列出目前user 所執行的程式

#ps -u     則是列出所有user 所執行的程序.

但上面所提的 , 指的都是由前台console所鍵入的程序 , 但像是一開機所啟動的程序 , 則會被暗藏在後台中. 這時我們可以利用

有好一陣子沒來更新這裏的文章. 主要是公司的案子一忙 ,再加上有時沒有把k進腦袋裏的 , 消化成文章. 慢慢的日子一積久了, 動筆敲鍵盤的意願 , 也就懶了許多. 學習其實也就是這麼一回事 , 社會新知不會因為你停止學習的當下 , 也跟著停滯的. 所以 , 完Linux的夥伴們, 可得堅持下去. 有時後可以懶一下 , 墮落一下. 但那種想窺探Linux究竟的好奇心 , 可得一直努力的保存下去.

        越來越多的嵌入式開發人員正轉向採用開放原始碼工具，以建構可靠與靈活的系統及軟體。開放原始碼既可提供建構系統軟體和應用程式所需的原材料，也能提供開發工具。特別是像Eclipse和GNU工具組等開放原始碼開發工具，開發人員可對其進行定製與擴展，以滿足精確的計劃要求。不僅如此，許多嵌入式開發商採用了多種開放原始碼工具，以作為更全面的開發環境基礎。

Eclipse是一種可擴大並推動嵌入式工具生態環境成長的整合開發環境(IDE)。Eclipse基金會正從事Eclipse平台及相關技術的開發，該基金會是一個由軟體公司組成的非盈利組織，目標是促進技術的共享。

在嵌入式設計與開發領域中，Eclipse平台主要受到平台的成本與靈活性；以及共享技術貢獻者與外掛程式供應商的社群規模這兩大因素推動。今天的嵌入式供應商若不是搶搭Eclipse列車，就必須為他們為何不投入提出理由。但一旦置身其中，他們就會設法運用免費的開放原始碼軟體賺取更多營收。

業界對快速開發系統的渴望為Eclipse平台帶來了一些複雜的問題，而一種計劃在今年夏天問世的Callisto整合型系統則可望解決這些問題。該系統牽涉到由多家公司領導的多個專案、數百個委員會以及數以千計參與其中的人員之間的協調。

Eclipse開發工作圍繞著數個不同專案展開，包括設備工具專案(Device Tools Project)、數據工具專案(Data Tools Project)和網路工具專案(Web Tools Project)。這些專案的啟動時間各不相同，版本編號也不一致，在過去的開發中彼此極少協調。例如，某家供應商可針對其特殊版本的組件進行測試並推出工具，但這將面臨極大壓力，因為該供應商擁有的外掛程式必須能與其他具有不同基本要求的外掛程式相容，或是必須與Eclipse平台的後續版本相容。

        玩 Linux 似乎很難避掉 Server 這一塊 , 由其當我們要利用cross platform , 讓在i686系統上編譯出來的核心檔案 , 能夠直接透過網路 , 讓 target board 運作 , 就很難避掉這一塊.         在O'reilly 的 Building Embedded Linux Sytem 一書的 bootloader 章節中 , 一共提到了 DHCP , NFS , TFTP

         最近開始著手在 Linux 2.6的plarform 上 , 撰寫一些產品的Device driver.  結果當然一開始必定是摔個一踏糊塗. 有很多時後連怎麼死的都不曉得. 這要是在兩年前 , 那時剛碰linux的我來說  , 必定是束手無測 , 壓根不曉得從那下手. 但畢竟練功不是練假的啦....在經過一段時間的學習 , 慢慢的對linux的系統開竅了 , 就比較容易有些珠絲馬跡可尋 , 這就像是在玩 " TOMB Rider " 一樣 , 在前面的訓練關卡熟練後 , 後面就很自然的會去找一些 , 可能的線索 , 然後再不斷的 try % error , 找尋可能的解答.

        我想 , 乍看到這樣的主題時 , 大概多數人一定或摸不清楚 , 這是在說什麼吧. 其實, 我自己要下這標題也是挺爭扎的. 想了很久 , 最後還是以這樣的標題為名.         問題的起源是 , 在 Embedded Linux 上 , 在製作核心後 , 開發PC 必須想辦法把 Kernel image

        話說之前po U-boot到Kaise的sbc2410x開發板受阻後 , 可能大家就發現我似互沒有再繼續進行有關移植U-boot的相關動作 , 或是發表相關文章呢? 放棄了嗎? 實則不然!!  主要原因是我暫時打消把U-boot po到sbc2410x 的idea , 而是轉向直接將U-boot po 到一塊新到手的開發的平台上~ 而經過近三個禮拜的時間 , 歷經新的cpu 移植 , 系統重定位 , 周邊系統規劃 , 以及進入ArmBoot後 , 系統的設定等........終於在上禮拜 , 完成了!!!    Das U-boot 可以順利的在手中的新平台上運作了....         當然在過程中, 除了參考U-boot 裏頭的 README 文件外 , 也參考了幾本相關的書目. 不過最有用的莫過於在U-boot下 , 利用cross_compile-prefix-objdump 的指令 , 將binary file反組譯後來進行debug.  有效的幫助我排除了一些相關的問題....真的很有用.         不過 , 礙於這次的開發牽涉到相關的商業機密 , 所以相關的過程不便在blog上公佈 , 但仍歡迎遇到有問題的朋友們 , 可以留言發問 , 我會提供相關經驗與大家分享的.        談到U-boot , 看過幾本坊間的書 , 大概都只是只大略的提到有關於系統怎麼重定位及相關目錄是什麼? 讓人覺得有那麼點的點到為止 , 隔靴搔癢般的 , 讓人不快. 所以接下來的時間中, 有機會我會把我在po 完U-boot中 , 在調適一些U-boot架構的經驗 , 慢慢的發表出來 , 或許可以讓正在努力這一塊的人 , 也能一起研究Debug.