OLPC Hacking Meet-up心得

經過十天的等待，於於完成了這次「OLPC Hack Meet-Up Day」的活動。活動期間，感謝jollen、jserv、PingYeh、 Andrew、...等人提供不少對活動的經驗和建議。這段期間也感謝BV1AL、KC、olv、 FourDollars、linanne、aguai、wesley、thinker、yungyuc、gaso、yuren...等人的幫忙，才能順利將活動完成。

活動開始，先是由Mat簡單介紹一下如何用QEMU模擬OLPC和測試程式。之後則是共同開發和交流討論。21:10-22:00 則是展示時間，首先是jserv展示了QEMU用於模擬系統開發的各個應用，也現場展示了他最新的成果「親手打造Tablet / WebPad」。接著，FourDollars也跟著和大家分享影音串流程式最新的發展，分析未來的驅勢。並同時展示了一個他參考pcman的程式而改出來的影音外掛程式。可以非常方便的點選網路廣播並收聽，並發想也能整合進OLPC，提高OLPC的娛樂性。

而在PCMan on OLPC這個主題上，由國內開發LiveCD(USB)系列的BV1AL將gcin在OLPC上的成果作成LiveCD的映像檔，並設定好網路等相關部分。而PCMan X開發團隊的字型好手olv ，則是解決OLPC上PCMan X中文字型顯示的問題。在經過一段時間修改，順利將兩方的成果結合起來，如下：

雖然還是有許多小缺點，但這張快照也象徵了我們用行動來實踐我們的信念，也呼應了活動發起的訴求。

在活動期間，wesley、aguai、annelin... 也嘗試利用QEMU建立多個OLPC來模擬mesh network的測試環境。而Andrew、PingYeh、BV1AL、...在Tick偶然拿到OLPC實機的root console後，也著手研究了OLPC的系統更新、開機流程，相信不久之後也能見到相關的經驗分享。

最後希望能持續將這些成果整理出來，以開放的方式回饋給upstream和社群。

build u-boot from sources

因為openmoko patch的u-boot有支援Samsung S3C24xx的stepping stone，所以build看看。

主要是follow這一篇文章 "Migration to bad block tolerant builds"，說明比u-boot那一篇仔細 (但是我apply 609的patch沒有成功，所以還是使用main stream)。

工作的目錄是 /home/openmoko

裝好subvesion，設定svn使用proxy，在~./subversion/server中加入proxy server，port :

http-proxy-host = 10.1.1.200
http-proxy-port = 3000

checkout openmoko 到 openmoko 目錄

$ svn co https://svn.openmoko.org/ openmoko

安裝git-core，改變default git tool (debian etch)

$ aptitude install git-core
$ update-alternatives --config git
== 選 "git-scm"

export 好http_proxy，checkout u-boot

$ git clone http://www.denx.de/git/u-boot.git

(需要等待一段時間)

取得cross toolchain : 因為monotone出不去proxy (雖然mailing list中聲稱新版的monotone可以經過proxy，可是我這裡還是出不去)，所以只好直接從 openmoko拿build 好的cross tool

$ wget -r -L http://buildhost.openmoko.org/tmp/cross

(需等待更長時間，且lib/下的檔案有些沒有抓回來，要確認一下，加上 "-c"抓沒抓到的folder。修改 bin 下的file，設為可執行。)

把抓下來的toolchain copy到 ..

/space/fic/openmoko/gta01/tmp/cross

設好PATH:

$ export PATH=/space/fic/openmoko/gta01/tmp/cross/bin:$PATH

u-boot - apply patch: (要先裝好quilt)

$ cd u-boot
$ export QUILT_PATCHES=/home/openmoko/openmoko/trunk/src/target/u-boot/patches
$ quilt push -a

Ok，沒有error message。

build u-boot - config and make:

$ make ARCH=arm gta01bv2_config
$ make ARCH=arm

完成。

GSM modem裝置模擬

系統模擬對於嵌入式系統開發來說，是相當重要的里程，不僅晶片層面如此，對於週邊來說，更可對應用程式開發帶來立即的效益，現在，OpenMoko-emulator也提供虛擬GSM modem的模擬。首先，依據之前的文章「透過USB連線與OpenMoko模擬裝置互動」，建立虛擬USB network連線，並透過ssh連線到虛擬硬體中，接下來就可以進行GSM modem的操作，畫面如下：(粗體字是打入的指令)

$ ssh root@192.168.0.202
root@192.168.0.202's password:
root@fic-gta01:~$ libgsmd-tool -m shell
libgsm-tool - (C) 2006 by Harald Welte
This program is Free Software and has ABSOLUTELY NO WARRANTY

O
# # Power-On
R
# Register

也可以不透過OpenMoko的工具，直接下AT command：(粗體字是打入的指令)

root@fic-gta01:~$ /etc/init.d/gsmd stop
Shutting down gsmd: Terminated
root@fic-gta01:~$ echo 1 >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on
root@fic-gta01:~$ cu -E @ -l /dev/ttySAC0
Connected.

ATE1
OK

詳情可參考Marcin Juszkiewicz的文章 "How to check does GSM modem works"，但對於openmoko-emulator也適用，甚至我們還可以模擬出各種不同的反應，卻不需要任何實體環境介入，這是相當有意思的手機軟體開發方式。

quilt - patch tools

quilt 是用來patch很多patches時使用，使用的方法是

quilt cmd

可以用

quilt cmd -h

來看可用的command有哪些。

因為是多個patch files，所以有一定的patch 順序，quilt會幫我們handle這些順序 (因為當初這些patch 也是由quilt 產生的呀）。就像stack操作一樣，push (apply) 一個patch；用pop 把sourcecode回到上一個沒patch的狀態。

所以，quilt也可以當作是簡易的Version control system用。

quilt的操作，將所有的pacth檔都放在要patch的source directory中的"patches"目錄。 (可以是symbolic link)

剛剛講的patch stack (patch 順序) 就紀錄在 "patches/series" 這個file中。

所以openmoko 的bootloader patch apply 的方法就是：

• download u-boot latest versio (svn checkout lateset version)
• download openmoko u-boot patch (是一個folder)
• 把這個patch folder copy 到 download 的u-boot folder中
• run quilt push -就會依照應有的順序apply 所有的patch.
  

That's all.

ARM模擬的狀態保存

前文「透過USB連線與OpenMoko模擬裝置互動」指出現在透過qemu來模擬openmoko已有相當便利的互動機制，我們也隨時可在Qemu Monitor中監看與控制虛擬機器的狀態，Andrzej Zaborowski最近實做了ARM模擬的狀態保存，所以現在可快速load/save vm，如此一來，應用程式的開發與驗證更加便利。目前也整合到openmoko-emulator中，取得最新的發展版本：

$ svn co https://OpenSVN.csie.org/openmoko_addons/openmoko-emulator

現在openmoko/run.sh這個script已處理qemu-img的操作，所以我們只要如往常一般編譯與執行即可。舉例來說，我們希望保存開機完成、見到整個OpenMoko UI的狀態，那麼只要按下Ctrl-Alt-2以切換到Qemu Monitor畫面，在提示符號下先暫停虛擬機器的系統模擬動作：

(qemu) stop

接著就可以保存狀態：

(qemu) savevm mainwindow

參數 "mainwindow" 只是一個識別名稱，事實上我們可以在不同的狀態給予特定的識別，這時候我們可以結束虛擬機器的執行：

(qemu) quit

然後我們重新啟動openmoko-emulator (run.sh)，立刻切換到Qemu Monitor，隨後在命令提示打入指令以查看保存的狀態：

(qemu) info snapshots

應該會得到類似以下的輸出：

Snapshot devices: mtd

Snapshot list (from mtd):
ID     TAG                  VM SIZE      DATE
1       mainwindow     22M              2006-05-23  11:11:35

要還原已保存的狀態相當直覺，只要打下指令：

(qemu) loadvm mainwindow

再按鍵Ctrl-Alt-1切回執行畫面，這時候就可以看到上次我們保存的狀態與畫面了，當然，配合前次提到的Linux gadgetfs，我們還可存取USB (emulated) network，這樣進行應用程式開發的彈性也提昇許多，若再引入自動化的機制，未來要實做「時光機器」也是相當可行的。

避免cross-compile的陷阱：libtool

在Unix系統上，有個知名的 "make" 工具，可協助開發程式，但是隨著程式開發複雜度的提昇，已經很難用有限的 "make rules" 來滿足多變的需求，所以Cygnus/RedHat的Tom Tromey就設計autoconf與automake等工具，期望大幅降低異質性平台開發的困難。這也包含所謂的cross-compile，為了克服不同平台的函式庫編譯落差， libtool也被提出，立意甚好但往往讓我們遇到不少問題，比方說知名的hacker - Casey Marshall - 就在與這些上萬行的工具程式奮戰一段時間後，寫了篇短文 "Avoiding libtool minefields when cross-compiling"。autoconf與automake等工具最核心的想法就是希望編譯過程可以簡化成如下： (以x86下進行ARM-Linux程式編譯為例)

./configure --host=arm-linux \
 --prefix=/usr \
 --enable-shared \
 --enable-Feature1 \
 --disable-Feature2

筆者參與的若干自由軟體計畫中，也陸續導入此設計，如上的組態所示，我們指定cross-compile的對象為arm-linux，automake會依據特定條件去找尋與測試編譯環境，同時我們啟用Feature1與抑制Feature2，接著一堆上萬行的Makefile就會乖乖建構了。那麼，問題在哪呢？我們很常見到以下的編譯錯誤：

/bin/sh libtool --mode=link target-gcc -c -O2 -o libbar.so ... -lfoo
target-gcc -c -O2 -o libbar.so ... /usr/lib/libfoo.so
/usr/lib/libfoo.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status

很明顯，libtool被誤導，原本該尋找arch = arm的程式檔案，沒想到抓到host (x86)上的檔案，為何如此？我們隨便挑一個描述程式連結資訊的*.la檔案：

$ cat /usr/lib/libesd.la
# libesd.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 224 $
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libesd.so.0'

# Names of this library.
library_names='libesd.so.0.2.36 libesd.so.0 libesd.so'

# The name of the static archive.
old_library='libesd.a'

# Libraries that this one depends upon.
dependency_libs=' -L/usr/lib /usr/lib/libaudiofile.la -lm'

# Version information for libesd.
current=2
age=2
revision=36

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/lib'

再清楚不過，這肇因於將libdir指向Host/x86上的目錄下，但這些*.la檔案已經置放於 "staging" (工作區)，於是我們可用GNU sed去更動。比方說 "staging" 目錄於 /tmp/rootfs，那麼：

sed -i~ -e "s;/usr;/tmp/rootfs/usr;"

這之間有頗多繁瑣的工作，還好OpenEmbedded對autoconf、automake，與libtool作了修正，所以大部分的Automake-based applications可以很容易透過OpenEmbedded去建構，但副作用則是需要re-generated，又，這樣的套件或應用程式往往佔多數，耗費的時間也相當可觀。