千呼萬喚始出來，第一個開放式的行動通訊平臺 Openmoko 今天正式展開第二代手機產品 Neo FreeRunner 的線上銷售。Openmoko 的官方新聞稿已經發佈在這裡了 [Openmoko Declares Independence for the Mobile Phone]，特別選在獨立紀念日開放 Neo FreeRunner 訂購，正意味著 Openmoko 將在手機市場裡「獨立」走出自己的路，Openmoko 在行動通訊界做了一個革新，這個革新代表的是手機終於獲得真正的自由。

與之前銷售 Neo1973 不同的地方是，Openmoko 這次除了透過線上直銷外，在印度、德國、法國與英國的朋友也能向當地代理商購買 Neo FreeRunner。

距離上次 Openmoko 推出第一代產品 Neo1973 已經過了好長一段時間了，這些日子裡，行動通訊產業發生了許多大事，像是開放手機平臺（如 Android）概念的興起，以及觸控螢幕手機（如 iPhone）的流行，都讓大家有一種耳目一新的感覺。

Openmoko 呢？

這段時間，Openmoko 除了面臨外在的挑戰外，內部也有很大的調整與改變，但不管怎麼樣，我們相信結果是好的，社群開發者也更積極參與 Openmoko 平臺的開發，而且我們也看到了 Openmoko 更進一步將 Neo 手機的機構設計以 CC 授權公開了。許多革新的做法，不斷讓大家看到這個開源手機專案的獨特之處。

Openmoko 還有一個與過去不同的地方。現在的 Openmoko 特別著重學校教育，在 Openmoko 新版的網站上可以看到有一個 [University] 的頁面，Openmoko 特別關心學校方面的研究計畫，不管是軟體或是設計，都能向 Openmoko 公司或是 Openmoko 社群取得一些幫助。過去 Openmoko 在台灣也與多所大學有所接觸，許多老師與同學對於使用 Neo 手機來製作專題都表達高度興趣，目前也有一些小成績，下學期希望能夠和大家分享這些同學的研究成果。

本週進行「Linux Device Drivers」訓練課程，開始帶領學員在 JK2410 開發板上實際撰寫硬體控制的程式碼。前一階段課程費了許多功夫解釋整個架構和觀念，這部份是與硬體無關的主題，主要針對 Linux 作業系統本身的實作與機制做觀念解說，例如：scheduling（為什麼要使用 wait queue 做 I/O 排程、以及使用時機）、critical section 等等。

我們花了一點時間幫同學建立基本概念，主要都是基本功的訓練，整理如下：

1. JK2410 開發板的操作：如何下載 kernel 與 rootfs 到開發板。

2. Kernel 編譯與設定：toolchain 的取得與安裝、Linux kernel 原始碼的取得、如何設定 kernel、如何包裝成 u-boot 格式。

3. 如何將 cdata 移植到 kernel source tree：透過 Config.in（2.4 kernel）與 Makefile 的修改，將過去辛苦從零寫起的 cdata 驅動程式移植到 kernel 原始碼目錄裡。目前我們的做法是，將 cdata 範例與 kernel 編譯成一個 image 檔，理由是，現階段暫時不去碰 root filesystem。

4. 在 JK2410 開發板上實際把玩 cdata 範例，過去我們都是在 PC 端操作，這次終於能將 cdata 移植到 ARM9 開發板上，並實際操作了。

我們在編譯 kernel 的過程中，也機會教育同學如何思考並解決一些編譯時的錯誤：

5. 如何選擇正確的驅動程式，例如：JK2410 的 serial driver。

6. linking 階段的錯誤（undefined reference）以及解決問題的思考邏輯。

7. compiling 階段的錯誤，以及解決問題的思考邏輯。

這些都是課程由 host 端進入到 target 端（ARM9）時，同學必須要具備的基本功夫，大家可將以上 7 點做為基本能力檢核的 check list。

本週要繼續進行 Linux Device Driver 的教育訓練，正好上週有同學問到「process 狀態」的問題，原因是我們在講解範例時，提到 O'Reilly 的 Linux Device Driver 書上以「half sleep」來說明「手動變更 current 狀態」的做法，以及為何不直接呼叫 sleep_on() API 的原因。

當時只做了相當簡要的回答，同學也對 OS 書上講到的 process state 有些不了解。本週打算做比較深入的討論，結果發現我的 Linux Kernel 專欄休眠許久，「Process State」這個章節居然還沒有整理上來，因此在這裡補上這個部份，以免上課要講解時無料可用。

Process 的狀態（state）紀錄在 process descriptor 的 state 欄位。如果您對 process、fork（process creation）以及 preemptive 不熟悉的話，建議您先從頭依序閱讀「Linux Kernel 專欄」裡的文章，才能對以下的 process state 轉換圖產生一點感覺。

Linux 系統透過 fork system call 建立新的 process，當 process 被生出來後，他的狀態就是「執行中狀態」，也就是 TASK_RUNNING。不過 process 產生後，並不是馬上就能執行，必須被排程器挑選後做 context switch 才是「正在執行中」的 process。我們以 current 代表「正在執行中」的那一個 process，前面所謂的執行中狀態指的是被放在 task queue / run queue（OS 叫 ready queue）中的 process。當 current 正在執行時，很可能被其他 priority 更高的 process 搶奪執行權，這時 current 就會被放回 ready queue 裡，這是因為 Linux 是一個可搶先（preemptive）排程的作業系統。

好了，今天 current 要存取硬體，這時如果硬體裝置出現問題，無法讀寫資料，此時「Linux 驅動程式必須把 current 放到 wait queue 裡睡覺（等待）」。

Wait queue 就是用來讓 current 睡覺的 kernel API。

Process 被放到 wait queue 時的狀態為 TASK_INTERRUPTIBLE 或是 TASK_UNINTERRUPTIBLE。這個時候因為我們的 process 在睡覺了（被放到 wait queue），所以 scheduler 就會再由 ready queue 裡挑一個 process 來執行。

Wait queue 裡的 process 怎麼辦？

睡著的 process 必須被叫醒（wake up），這個動作一般是在 interrupt handler 裡做的。當 process 被叫起來後，狀態再度切換成 TASK_RUNNING 了，於是，又得到被 scheduler 挑選執行的權力了。

Process state 的定義可以在 include/linux/sched.h 裡找到（以下適用 2.6.24 版本以前）：

#define TASK_RUNNING 0
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2

Kernel 也提供了一個 API 可用來設定 current 的狀態：

set_current_state(state_value)

在驅動程式裡手動變更 process state 的目的是為了將 process 放到 wait queue 並達到 critical section 的效果。

最近在和朋友在討論 Embedded Linux 課程的規劃事宜，希望可以歸納過去所收集的學員意見，以及就助教所提出的課堂問題，對現有課程做調整以及精進。二個星期前，和 thinker 以及 dennis 在聊課程時，興起了一個念頭，我們想要規劃一門「作業系統」的課程。

過去的教育訓練發現，有些學員對於作業系統的背景知識不足，也有些學員對於 Linux kernel 的原理很有興趣，更有些學員對如何寫一個 OS 感興趣，但，由於沒有系統化的文件提供這方面的資訊，因此，讓大家只能由片斷的文件（googling）自己拼湊相關知識，不但沒有效率，而且也經常徒勞無功。

我們想要做的「作業系統」課程，可不是把「恐龍書」搬出來教一教就行了，而是希望走「實務」路線，因此，thinker 提出了一個想法：教大家做一個「只能開機」的 OS。我跟 dennis 都覺得這是一個很不錯的構想，透過「建構式」教學，讓大家從無到有自己寫一個作業系統，這個作業系統也不需要很完整，只要能做到「可以開機」就好了。

昨天晚上，大家再次聚會，再討論了這個「boot only」的 OS。「從無到有自己寫」是一個不太可行的做法，畢竟訓練時數有限，況且「有現成的 Linux kernel」可以用，因此，「從 Linux kernel 剪貼程式碼來做一個新的 OS」是一個最具體可行的做法，也是大家的共識。

透過由 Linux kernel「copy-and-paste」程式碼，拼裝出一個 OS，是一件有意義的事情。雖然是一個拼裝的 OS，但是要讓它可以動，就要了解處理器架構，以及整個開機流程，而且也要知道「要讓一個 OS 可以開機，至少要實作什麼單元。」這是一件有趣的事，大家興趣都來了，一陣技術討論後，很快地，在不到一個小時內，我們就把主題都抓出來了。初步的構想如下。

要知道 Linux kernel 的開機流程，就要有一個學習環境，我們一致認為，透過 Qemu 模擬器與 gdb 進行 source-level debug 會是一個很不錯的做法，而且也可以在拼湊的同時，透過 Qemu 來測試與除錯；最後再將拼裝好的 OS 實際放到開發板上做測試。我們自己的 JK2410 開發板，同時也提供 JK2410 模擬器，所以可以繼續延用我們的「Jollen-Kit! 嵌入式系統專用學習平臺」。

有了學習環境後，就可以開始討論「最小型的作業系統」需要實作什麼功能。理論來說，實作出 clock、IRQ handler、virtual memory 以及 context-switch 就可以讓 OS 開機，並且提供「最最最」簡單的功能，比如「Hello, World!」。要能成功 copy-and-paste 出可放到 ARM9 開發板開機的 OS，除了要對 Linux kernel 的 BSP 本身很熟悉外，也要對這些技術的實作細節掌握得很好，所以，用 Linux kernel 來從無到有打造一個自己的 OS 可說是一舉三得的方法：

1. 可以了解 Linux 的 BSP（board-support package）做法，以及開機流程。
2. 可以了解 ARM architecture。
3. 可以學習最根本的 OS 理論與技術。

目前，我們已經完成課程的規劃，不久後也會完成講義的初步規劃。這是一個頗有意義的主題，而且也是一個很好的學習途徑，希望對這個主題有興趣的朋友，可以提供意見或想法給我們。

自從 Openmoko 在7月4日正式發佈新版的 Neo FreeRunner 後，便不斷受到許多西方媒體的矚目與報導，各種聲音也出現在 Openmoko 社群，以及每一個人的網誌上。許多媒體都給予相當正面的評價與報導，對 Openmoko 團隊來說，這絕對是一大鼓舞。當然，好聲音不少，壞聲音也有。像是，Boing Boing 便刊登了一篇對 Openmoko 相當正面的報導：

Openmoko open-source cell phone beats Android to the punch

不久前，Internetling 也刊登了一則有關Openmoko 的評論，標題是「3 Reasons Why Everyone will buy one iPhone and not OpenMoko」。一開始的開場白實在犀厲：

But unfortunately, people probably wont buy it...

作者並不是在批評或是「唱衰」Openmoko，反而是以比較中性的來度來看待Openmoko 的努力與成果，我認為這是一篇很有價值的文章，同時也能讓我們能以更多元的角度來思考 Openmoko 的未來。這些不同的聲音與看法，反而是 Openmoko 更應該要正視與關心的。

作者由 marketing、software 以及 users 的角度來評論。首先，以 marketing 的角度來看，Apple 有一個優秀的行銷團隊，但 Openmoko 只有社群，雖然我們都喜歡Openmoko，可是沒有什麼驅動力讓一般大眾購買 Openmoko 手機，大家會買的是iPhone。Openmoko 只能透過口耳相傳（word of mouth）的模式進行。

接著，由 software 的角度來看，FreeRunner 比起之前的 Neo1973 好很多了，但仍然「unreliable」。「Openmoko 並不是 Nokia，他們名號不大。」作者提到。「要有大變革，不要賣一個無法和 iPhone 相比的產品。」

最後是由 users 的角度來看，Linux 很令人敬畏，「但有誰告訴過他外婆，這個長相可疑的手機，比 iPhone 還好？」iPhone 做到了完全創新，也有好看的介面。「這些潛在的信眾（Linux 愛好者）並不信任你並且也不在乎。」這是一場辛苦的戰爭，但Linux 最終會立足於 hand-held 市場。「我們需要的是時間，只是現在時機不對。」但作者最後還是給予 Openmoko 團隊正面的評價：

but let us still cheer the OpenMoko team on for making a brave step forward.

從作者的口吻來看，他似乎希望大家等待 Linux 手機時代的到來。「why wait for the Year of the Linux Phone…」。

或許，大家也發現了，Neo FreeRunner 現階段還是定位給開發者使用的手機，並不符合與該作者的論述出發點。但是，不管作者是否了解 Openmoko 的商業模式，也不管這些論點是否符合 Openmoko 的 roadmap，出現在網路上的看法，就是外界對 Openmoko 的看法。因此，如果這些觀點與 Openmoko 的想法不符，那麼對 Openmoko 團隊來說，更重要的工作就不是做手機，而是「更正確地傳達理念」。

英勇的第一步已經邁出，希望 Openmoko 往當初的理想與目標繼續邁進。加油。