2007年5月31日星期四

組字技術與手持式裝置的新機會

專注於中文技術的剎那搜尋工坊推出新版 (2007.05.26) 的「剎那字引」軟體,其概念相當特別,以「部件」來分析漢字 (泛指中日韓漢字) 進而可做出正向或反向的資訊化操作。就完整的中文處理系統來說,不僅要考慮畫面或裝置輸出,還有繁瑣的輸入法,但受限於異體字、錯別字,或可用性等考量 (特別是手持式裝置來說,得提供一定程度的「漢字容錯」處理),每每挑戰著設計者的技術水準,但這方面的議題並不是建立大量的state machine就可克服的,我們得從漢字本質去思考。

剎那字引」的執行畫面如下: (Win32/Delphi Application running via WINE/Linux)
我們可一目了然得知特定部件與其對應的漢字,這可用一致性的數學模式去表示,不過這裡就不贅述了,可參考Foxman前輩發表的一系列文章。對於手持式裝置來說,漢字的輸出與輸入之間即有一定程度的關聯,比方說手寫辨識就與組字在概念上有共通處,而漢字構形資料可作反拆或逆向查詢與推斷,意味著可運用於輸入法的輔助索引處理的機制,是此,即使是手寫辨識的操作,甚至可簡化為只需書寫偏旁,系統反推並決定候選字 (與其組合),大幅降低辨識的複雜度,或考慮到傳統的輸入法,這就是一個相當有效率的「過濾器」。

再來我們可回頭思考漢字系統長久以來的缺字問題,儘管桌面應用已經逐步改善此議題,對於手持裝置來說,仍是極大的衝擊。當然,國際大廠注意到這類需要對資源錙銖必較的裝置上,做完整中日韓多國語文處理的議題,本身就是兼顧技術、可用性、價格成本,與後端交換碼種種妥協的設計,所以IICore (International Ideograph Core) 標準被提出,預期成為手機、PDA等移動通訊產品的重要規格,原則上不超過一萬字,是Unicode的子集 (碼位大幅調整)。問題是,我們應著眼於深入更多觸角的移動通訊運算,不該僅用常用的表意文字來限制資訊系統的使用。人們都有使用行動通訊裝置的自由,卻往往受限於種種預設立場的桎梏,這是相當不合理的事情,勢必,技術上得有所突破。

基於以上考量,動態組字技術於手持式裝置的需求,越來越顯見其重要性,正如之前文章「紀錄:可攜式造字引擎專利釋放暨成果發表會」所提及的概念,我們可發現運算技術、文化需求,以及M化等因素的交錯即將邁入臨界點,未來將以何種方式呈現?不得而知,但我們實在有必要將基礎建設完善化。

2007年5月30日星期三

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.

2007年5月26日星期六

GCC Visibility與軟體最佳化

以前在blog文章「Qt Library 的精簡」提到GCC的C++ Visibility,其實官方的wiki已經描述相當清楚,引述如下:

"Why is the new C++ visibility support so useful?

Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. This means:

  • It very substantially improves load times of your DSO (Dynamic Shared Object). For example, a huge C++ template-based library which was tested (the TnFOX Boost.Python bindings library) now loads in eight seconds rather than over six minutes!

  • It lets the optimiser produce better code. PLT indirections (when a function call or variable access must be looked up via the Global Offset Table such as in PIC code) can be completely avoided, thus substantially avoiding pipeline stalls on modern processors and thus much faster code. Furthermore when most of the symbols are bound locally, they can be safely elided (removed) completely through the entire DSO. This gives greater latitude especially to the inliner which no longer needs to keep an entry point around "just in case".

  • It reduces the size of your DSO by 5-20%. ELF's exported symbol table format is quite a space hog, giving the complete mangled symbol name which with heavy template usage can average around 1000 bytes. C++ templates spew out a huge amount of symbols and a typical C++ library can easily surpass 30,000 symbols which is around 5-6Mb! Therefore if you cut out the 60-80% of unnecessary symbols, your DSO can be megabytes smaller!

  • Much lower chance of symbol collision. The old woe of two libraries internally using the same symbol for different things is finally behind us with this patch. Hallelujah! "


事實上,對於許多採用C語言撰寫的專案也適用,而且效果很不錯。嵌入式系統開發時常常得控制程式空間使用量,咱們就來看看具體的案例,包含Nokia 770/800與OpenMoko在內的許多專案,採用X Window System,server端的實做是KDrive,而client端雖然只要能跟X Protocol即可,不限定程式語言與實做,但往往我們會透過libX11。就如筆者之前的演講與blog提及,X本身的效率其實很好,但問題在於複雜的軟體實做,其中有許多改進的空間,libX11就是一例。

剛剛做了些hacking,發現光是利用GCC的C++ Visibility來隱藏非公開的API/ELF symbol,即可大幅降低空間使用量,並提昇載入應用程式速度。

在Ubuntu 7.04上進行測試,同樣的libX11套件,施加我的修改:libX11-visibility.patch後重新編譯,比較兩者的差異: (stripped)
  • /usr/lib/libX11.so.6.2.0 (原本) - 964K
  • dist/usr/lib/libX11.so.6.2.0 (修改過) - 839K
相當顯著的差異,接著比較兩者透過size指令的落差:
textures datatype bss_seg decided hexunfilenamefilename
966896 14496 1596 982988 effcc/usr/lib/libX11.so.6.2.0 (原本)

textures datatype bss_seg decided hexunfilename
827962 11336 1224 840522 cd34adist/usr/lib/libX11.so.6.2.0 (修改過)

於是乎,我們可參照wiki上對於DSO的描述,這之間的意義不僅是空間的降低,對於Code optimizer來說,也允許更多積極的處理方式,最重要的是,符號解析的速度提昇,也避免潛在的符號衝突。這是很簡單的修改,但影響卻相當顯著,我們也可看到整個Gtk+/GNOME的架構仍有最佳化的空間。

2007年5月25日星期五

OpenMoko演講影片上線


psilotum的協助下,5/8在Tossug聚會所演講的「Free your phone! OpenMoko」過程都完整的錄影下來了,在 Google Video 上甚至還可以清楚看到簡報內容。請享用!

Credits:

Speakers: Sean Moss-Pultz/Harald Welte
Host: Tossug/Ping Yeh
Organizer: Rex Tsai
Producer: psilotum


備註: 我們不是在甚麼奇怪的地方,背景是天邊一朵雲的法國版海報,Cafe Lumiere 只是一家貼滿海報的咖啡店而已。


Source: http://people.debian.org.tw/~chihchun/2007/05/25/talk-of-openmoko-is-online/

串連WIFLY與FON AP

四元(4$) 一直對小巧可愛的路由器非常感興趣,他寫了一篇關於 「Linux絕對有支援的無線網路卡」提到了ASUS WL-330gD-Link DWL-G730APBelkin Wireless G Travel Router 等非常省電容易攜帶的產品。

4$動了一個主意,想把可愛的La Fonera改裝成類似上述的產品,可以透過Ethernet 連上WiFi AP,再透過WiFi AP連上外部的網路。由於4$Hackathon的時,在cclien的協助下,成功的編譯了OpenWrt的開發版 Kamikaze,並燒進FON La Fonera中,因此他需要做的只是再把設定寫進去即可。

Hacking La fonera

2007年5月23日星期三

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,這樣進行應用程式開發的彈性也提昇許多,若再引入自動化的機制,未來要實做「時光機器」也是相當可行的。

2007年5月21日星期一

OpenMoko at Tossug

Sean Moss-Pultz

5/8在Tossug舉辦的分享活動算是相當成功,當天總共來了超過五十位聽眾。許多朋友也留下聯絡資訊,或許可以加入開發社群或即將成立的OpenMoko公司

演講分為兩節,Sean Moss-Pultz介紹關於OpenMoko的背景故事、起源與目標。而 Harald Welte 則介紹軟硬體等技術細節。

Harald Welte

演講完整錄影,影片將上傳至網路,簡報一併於稍後提供。謝謝psilotum攝影,以及Tossug工作人員的辛苦籌備。

原文: http://people.debian.org.tw/~chihchun/2007/05/17/openmoko-at-tossug/

Working on Neo1973

Working on Neo1973

這是4/14在Mix coffee & tee的工作畫面 (工作紀錄, Minicom log for reflash images on Neo 1973),我們將Neo1973拆解,並試著reflash與裝上debug board。我很喜歡這張照片,謝謝psilotum的攝影。

原文: http://people.debian.org.tw/~chihchun/2007/05/17/working-on-neo1973/

Cheapest ttl2usb converter for la fonera

本來是想一起參加台灣黑客鬆的聚會,因為Jserv跟幾位朋友想在La Fonera上動動手腳,試著在La Fonera上玩玩AJAX/Web Server for embedded system。然而因為會議太忙,兩天都沒辦法出席,真是對不住。cclien寫了一篇相當不錯的文章,紀錄了黑客鬆的過程。最後他們是將Wt移植到La Foera 上,Jserv於OSDC中也針對此議題給了一個 lighting talk

EGLIBC初探

在Embedded的環境下,我們有許多C Library的選擇,從BSD libcuClibcglibcdietlibc,甚至是klibc (配合initramfs),過去我們考量到footprint,往往會捨棄發展活躍的GNU C Library (glibc),轉而以uClibcdietlibc來建構系統,正如uClibc的FAQ網頁提及的項目 "What's wrong with glibc?" 所說:

"The GNU C library is a great piece of software, make no mistake. It is compliant with just about every standard ever created, and runs on just about every operating system and architecture -- no small task! But there is a price to be paid for that. It is quite a large library, and keeps getting larger with each release. It does not even pretend to target embedded systems. To quote from Ulrich Drepper, the maintainer of GNU libc: "...glibc is not the right thing for [an embedded OS]. It is designed as a native library (as opposed to embedded). Many functions (e.g., printf) contain functionality which is not wanted in embedded systems." 24 May 1999"
以及下一條 "So uClibc is smaller then glibc? Doesn't that mean it completely sucks? How could it be smaller and not suck?" 所說:
"uClibc and glibc have different goals. glibc strives for features and performance, and is targeted for desktops and servers with (these days) lots of resources. It also strives for ABI stability. On the other hand, the goal of uClibc is to provide as much functionality as possible in a small amount of space, and it is intended primarily for embedded use. It is also highly configurable in supported features, at the cost of ABI differences for different configurations."

所以很明顯,glibc考量到通用性系統的需求,許多部份會考量到效能的最佳化處理,所以光是字串函式往往就可能拆成許多程序來實做,以針對不同的資料量給予最佳效能的處理方式,但往往也必須付出大量的footprint衝擊。Greg Alexander甚至寫了一篇用詞尖銳的文章 "GLIBC SUCKS" 來闡述他的觀察:就算是簡單只用printf()函式的 "Hello World" 程式,竟然也不成比例的龐大,引述如下:

Let's perform some more GLIBC2 vs. BSD libc comparisons:

[greg@linux] ~$ gcc -static -o hello hello.c; strip hello
[greg@linux] ~$ du -sk hello
416 hello
compared to:
[greg@freebsd] ~$ gcc -static -o hello hello.c; strip hello
[greg@freebsd] ~$ du -sk hello
44 hello
Yeah, that's right, when statically linked GLIBC2's printf() and support routines are about 10x as big as BSD's. We're on computers, a 15% improvement is considered worth looking at so you can copy their techniques. An "order of magnitude" is 2x. You simply aren't expecting 10x differences between extremely simple code that hasn't advanced, technologically, in more than two decades.
可見如此簡單的應用程式,其空間使用竟然達十倍之譜,在筆者的「深入淺出Hello World」系列演講也提及許多glibc與gcc潛藏的神秘性質,這些對於有特定目標、空間侷限的系統來說,是很難允許的。但採用非glibc的解決方案雖可大幅降低footprint與系統複雜度,卻可能因而限制可用的應用程式,最有名的例子就是Mozilla一直無法在uClibc上正確編譯與執行,這也辜負了採用GNU/Linux作為Embedded system作業系統的美意。過去我們得因應需求與彈性考量,多方取捨並周旋於前述的C Library實做中。

專注於GNU開發工具研發與客制化的CodeSourcery公司與若干嵌入式系統大廠,諸如MontaVista、Freescale,及WindRiver等廠商合作,針對glibc的改進計畫 (自2.5版開始),實做出更適合Embedded環境的C Library實做 -- EGLIBC,並承諾與glibc的binary/source compatibility,其明確的目標可參考EGLIBC::Mission網頁:
" Expand and enhance the capabilities of the GNU C Library (GLIBC) to support embedded systems for diverse environments, and maintain an open development environment encouraging broad, cooperative developer participation."
所以採取同樣的codebase (svn merged from FSF),同時也確保是Free Software (copyright holder為FSF),在mailing-list也可見到「借力使力」的發展模式,如Joseph S. Myers的post "[patches] EGLIBC 2.6 created"。Jollen兄日前在「Embedded Device 等於 PC」一文提及以下概念:
「就現代的硬體來說,embedded device 和 PC 的界線是越來越小了,雖然有時參與的 project 是 'embedded device',但是技術本質上就好像在做 PC 一樣。」
這是非常有趣、值得思索的趨勢,拜硬體蓬勃發展所賜,我們得以在此時間點大量採用原本桌面系統的軟體建設,知名的OpenMoko計畫就是最好的明證,但畢竟嵌入式系統的考量仍有差異,所以今日我們有以下發展理念:
  • 銜接活躍的自由軟體開發
  • 不只採用開放的系統,更要有開放的發展心態
  • 將力量集中於刀鋒上,創造核心價值
這使得採用EGLIBC成為多贏的解決方案,於是OrzLab也開始評估這些嶄新技術。延續之前的分析與模擬驗證 (詳見「視覺化系統模擬與偵錯」一文),最近的重心放於ARM Embedded ABI、GCC 4.2,與EGLIBC等最新的技術,為了簡化進行流程,我改了簡單的script:toolchain-eglibc.sh,這可自動擷取原始程式碼並建構。執行方式很簡單:
./toolchain-eglibc.sh arm
成功編譯後,會在$HOME/cross-build/arm-none-linux-gnueabi目錄下建立以下子目錄:
  • obj : 建構過程的目的檔,可忽略
  • tools : 包含GNU Toolchain
  • sysroot : 置入target的Runtime (root file system)
稍後筆者會探討如何利用系統模擬器來驗證,並探討整體效能與記憶體使用的提昇。

Update: Jick的更新與修正可參考「EGLIBC: Embedded GLIBC 体验

2007年5月19日星期六

避免cross-compile的陷阱:libtool

在Unix系統上,有個知名的 "make" 工具,可協助開發程式,但是隨著程式開發複雜度的提昇,已經很難用有限的 "make rules" 來滿足多變的需求,所以Cygnus/RedHat的Tom Tromey就設計autoconfautomake等工具,期望大幅降低異質性平台開發的困難。這也包含所謂的cross-compile,為了克服不同平台的函式庫編譯落差, libtool也被提出,立意甚好但往往讓我們遇到不少問題,比方說知名的hacker - Casey Marshall - 就在與這些上萬行的工具程式奮戰一段時間後,寫了篇短文 "Avoiding libtool minefields when cross-compiling"。autoconfautomake等工具最核心的想法就是希望編譯過程可以簡化成如下: (以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;"
這之間有頗多繁瑣的工作,還好OpenEmbeddedautoconfautomake,與libtool作了修正,所以大部分的Automake-based applications可以很容易透過OpenEmbedded去建構,但副作用則是需要re-generated,又,這樣的套件或應用程式往往佔多數,耗費的時間也相當可觀。

透過USB連線與OpenMoko模擬裝置互動

前幾篇文章介紹如何透過qemu來模擬openmokoPoky,這部份的開發逐漸穩定,而qemu現在對於硬體的模擬也頗完整,很多時候我們可直接指定Ethernet模擬來作PXE/BOOTP/TFTP開機或DHCP,於是Host與(Emulated) Target互動就相當簡單。但,如果是openmoko Neo1973/GTA01這類沒有Ethernet (頂多只有Wifi或Bluetooth)的硬體裝置,該如何互動呢?最近加入USB gadget模擬的支援,可將USB slave轉包到Linux 2.6的gadgetfs,如此一來,我們就可建立USB (emulated) network,兩端也可用NFS或sshfs來作檔案分享存取。

在Ubuntu 7.04上操作的方式如下,注意,建議使用一般權限進行,並善用sudo的機制。

取得Linux Kernel原始程式碼:

$ apt-get install linux-source-2.6.20
解開檔案並給予目前的組態:
$ cd /usr/src
$ tar jxf linux-source-2.6.20.tar.bz2 && cd linux-source-2.6.20
$ cp /boot/config-`uname -r` .config
因為Ubuntu預設的USB Gadget/Peripheral controller是實體裝置,但我們需要dummy_hcd (Dummy/Loopback USB host and device emulator driver),所以我們得調整設定:
$ patch -p0 < dotconfig_dummy_hcd.patch
然後建構我們需要的核心模組:
$ make MODVERDIR=drivers/usb/gadget \
drivers/usb/gadget/dummy_hcd.ko \
drivers/usb/gadget/gadgetfs.ko
順利的話就會有兩個 .ko檔,接著就安裝:
$ sudo insmod drivers/usb/gadget/dummy_hcd.ko
$ sudo insmod drivers/usb/gadget/gadgetfs.ko default_uid=`id -u`
Host端需要一個名為/dev/gadget的目錄,以掛載gadgetfs:
$ sudo mkdir -p /dev/gadget
$ sudo mount -t gadgetfs gadget /dev/gadget -o noauto,user,group
核心的部份告一段落,接著我們要來建構qemu,取得最新的openmoko-emulator:
$ svn co https://OpenSVN.csie.org/openmoko_addons/openmoko-emulator
編譯時期需指定kernel header (Ubuntu預設沒有打包全部USB gadget的header):
$ cd openmoko-emulator
$./configure --cc="gcc-3.4 -I/usr/src/linux-source-2.6.20/include"

在最後一行輸出應該要有以下字樣:
USB Gadgetfs support yes
接著就打 "make",順利的話會在arm-softmmu目錄產生名為qemu-system-arm的執行檔。我們可透過script自動下載u-boot、kernel,與rootfs等images並「燒」入我們的模擬硬體中,操作如下:
$ ./openmoko/download.sh
$ ./openmoko/flash.sh
正確的話,畫面會提示run.sh的script檔案被生成,咱們就來跑看看:
$ ./openmoko/run.sh
操作方式在前文「OpenMoko/Neo1973硬體模擬」已提及,不贅述。等X Window的畫面都出現後,就是運用gadgetfs的時機。按下Ctrl-Alt-2組合鍵切入Qemu Monitor,我們可監控與管理Qemu的狀態,當我們打入"info usbslave"指令時,應該有如下的輸出:
USB2.2 device 1457:5122:
Manufacturer: Linux 2.6.20.7-moko8/s3c2410_udc
Product: RNDIS/Ethernet Gadget
Configuration 0: RNDIS
Configuration 1: CDC Ethernet
因為openmoko在啟動X的時候會順便將USB network帶起,這時候我們就可透過gadgetfs去讓Host與(emulated) target互動。同樣在Qemu Monitor畫面,打入 "usb_add gadget:1" 指令,若無錯誤訊息,表示已成功。在Host上的終端機檢查USB gadgetfs的狀態:
$ lsusb -v | grep -A10 -B12 s3c2410
應該會有以下輸出:
Bus 004 Device 003: ID 1457:5122
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1457
idProduct 0x5122
bcdDevice 2.12
iManufacturer 1 Linux 2.6.21.1-moko8/s3c2410_udc
iProduct 2 RNDIS/Ethernet Gadget
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 80
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 7 CDC Ethernet
這時候就可透過CDC Ethernet操作USB network,openmoko在啟動該裝置時就設定IP與route,所以我們只要在Host設定必要的網路組態,即可連線到模擬的裝置:
$ ifconfig usb0 inet 192.168.0.200 netmask 255.255.255.0
$ ssh root@192.168.0.202
順利的話就會看到命令提示畫面:
root@fic-gta01:~$
當然,拿到shell後,什麼事情都可以作。

注意,在關閉openmoko-emulator前,請切換到Qemu Monitor,並打入"usb_del gadget"的指令,要求將gadgetfs的存取關閉,否則很可能會kernel panic。這時候Host的dmesg輸出應該類似以下:
[ 4751.700000] dummy_udc dummy_udc: unregister gadget driver 'gadgetfs'
[ 4751.700000] gadgetfs: disconnected
[ 4751.700000] dummy_hcd dummy_hcd: port status 0x00010100 has changes
[ 4751.700000] dummy_hcd dummy_hcd: port status 0x00010100 has changes
[ 4751.700000] usb 4-1: USB disconnect, address 3
[ 4751.700000] usb0: unregister 'cdc_ether' usb-dummy_hcd-1, CDC Ethernet Device
[ 4753.856000] usb usb4: dummy_bus_suspend
另外,Win32的USB redirection實做我也開始進行,希望不久後也可在Win32進行openmoko的模擬與開發工作。本文內容僅供參考與進度展示,後續的更新會發佈於openmoko官方的wiki: OpenMoko_under_QEMU

2007年5月14日星期一

Install Poky from scratch

Poky是一套建立於OpenEmbedded上的Embedded Linux build system, distribution and developer environment,與專注於GNOME Embedded type platforms (X11/Matchbox/GTK+)。我們可直接使用官方已編好的Image與Kernel,但在此我們將自已動手做 :)

實作過程:
1. 下載原始程式碼:

$ svn co http://svn.o-hand.com/repos/poky/trunk poky
2. 安裝必要之套件
$ apt-get install patch diffstat texi2html cvs svn bzip2 tar gzip gawk makeinfo qemu
2.1. 如果你要自行編譯qemu for poky還須安裝
$ apt-get install gcc-3.4 libsdl1.2-dev zlib1g-dev
3. 設定環境
$ source poky-init-build-env
確定/bin/sh指向bash,如果為dash則在編譯perl-native時會有問題
4. 編譯 Image
$ bitbake oh-image-pda
5. Try it :)
$ cd $OEROOT/build/tmp/deploy/images
$ poky-qemu zImage-qemuarm.bin oh-image-pda-qemuarm.ext2
6. 編譯qemu
$ bitbake -c build qemu
PS:如需移除套件可使用 bitbake -c clean $packname
7. 編譯完qemu之後,會放在 $OEROOT/build/tmp/work/armv5te-poky-linux-gnueabi內,使用自行編譯的qemu執行poky
$ sudo $OEROOT/build/tmp/work/armv5te-poky-linux-gnueabi/qemu-0.8.2+cvs20060723-r4/install/qemu/usr/bin/qemu-system-arm -kernel zImage-qemuarm.bin -append "root=/dev/sda console=ttyAMA0 console=tty0 mem=64M" -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=/home/blue119/poky/scripts/poky-qemu-ifup -M versatilepb -hda oh-image-pda-qemuarm.ext2 -usb -usbdevice wacom-tablet


Install OpenMoKo from MokoMakefile

如果你想安裝OpenMoKo from scratch有二種方法,除了直接下載SVN來編譯之後,我們還可使用 Rod Whitby 所編寫的 MokoMakefile Makefile,好處是我們可以利用簡單的make指令取代一些煩雜的指令 。以下為我的安裝過程:

1. 確認建構主機安裝必要的套件:

$ apt-get install python patch m4 make python-psyco ccache perl diffstat \
wget curl ftp cvs subversion git
2. 於建構系統安裝Openembedded
i. 在apt檔案庫追加Openembedded所需的套件:
$ echo "deb http://www.openembedded.org/dl/ packages/" >> /etc/apt/sources.list
ii. 安裝monotone 0.32
$ wget http://monotone.ca/downloads/0.32/monotone_0.32-0.1_i386.deb
#版本若不一樣可能會造成問題,此版本是我使用過沒問題的

$ update-alternatives --config git
#選擇 /usr/bin/git-scm來提供git的實做,而非用/usr/bin/git.transition
3. 安裝輔助性的套件:
$ apt-get install libxml2-utils xmlto passivetex
$ apt-get install docbook
4. 建立專屬的$OMDIR目錄:
$ export OMDIR=$HOME/moko ; mkdir $OMDIR ; cd $OMDIR
5. 取得MokoMakefile:
$ wget http://www.rwhitby.net/files/openmoko/Makefile
6. 設定環境
$ make setup
PS: 請確定/bin/sh指向bash,如為dash則編譯perl-native時會有問題
7. 開始建構:
$ make openmoko-devel-image
8. 以模擬環境來執行:
$ make build-qemu
$ make flash-qemu-local
$ make run-qemu
以下是參考的執行畫面:





轉換OpenEmbedded的repository為Subversion系統

Marcin Juszkiewicz日前在blog "3 years of OpenEmbedded and me" 提到OpenEmbedded這個專案計畫已有超過三年的開發歷程,也廣泛的被自由軟體專案甚至是商業公司所採用,知名的OpenMoko即採用此系統提供所需的套件與基礎建設。OpenEmbedded採用的版本控制系統是具有分散式開發的monotone,這是一套很優秀的系統,也得以藉此處理眾多套件與硬體組態的維護,但其難度不算低,所以開發者又要學一套新系統。

之前的文章「SVK與嵌入式系統開發」提及我正在做的 "openmoko-builder",透過SVK來管理多方的版本控制系統檔案庫 (repository),目標是建立最小OpenMoko建構系統。SVK已經替我們處理很多問題,但目前沒辦法操作monotone系統,這讓我的進度遲滯不前。還好Lele Gaifax撰寫了一個好用的工具Tailor,提供多種版本控制系統互轉的能力,這也讓我一舉克服維護與同步處理的議題。

在使用Tailor之前,請確認依據OpenEmbedded的文件 "Getting Started",取得並更新 "/stuff/OE.mtn" 這個資料庫檔案。接著我們需要安裝Tailor最新的開發版本,其使用darcs系統,所以請用apt-get一類的工具安裝套件,以下是取得程式碼的操作:

darcs get http://darcs.arstecnica.it/tailor/
Tailor使用Python開發,安裝也很簡單:
cd tailor ; sudo setup.py install
我們需要編輯一份Tailor所需的專案檔案,描述monotone轉換到Subversion的細節,舉例來說我們建立一個名為 "task.project" 的檔案,以下是其內容:
[DEFAULT]
verbose = True
debug = True

[project]
target = svn:target
start-revision = HEAD
root-directory = /src/repos
state-file = tailor.state
source = monotone:source
subdir = .

[monotone:source]
repository = /stuff/OE.mtn
module = org.openembedded.dev

[svn:target]
module = /openembedded
repository = file:///src/repos
SVN的檔案庫 "file:///src/repos" 自然就是存放轉換後的版本系統所用,我們應該事先建立,操作程序如下:
$ mkdir -p /src/repos
$ svnadmin create --fs-type fsfs /src/repos
注意,建立時必須選擇FSFS的型態,否則Tailor處理可能會遇到問題。最後就是執行Tailor的操作,使用方式如下:
$ tailor task.project
沒意外的話,我們就可以看到這之間的轉換過程,最後會轉換輸出於檔案庫 "file:///src/repos/openembedded" 之中,這時候可以用SVN自己的merge工具或SVK的smerge進行套件的更新維護,畢竟我們感興趣的套件就那幾個而已。

2007年5月10日星期四

SVK與嵌入式系統開發

為什麼我們考慮要採用Linux與一系列自由軟體?姑且不論軟體品質,保持更新與強大的QA就是其中關鍵因素,但就個人的經驗來說,過去看到太多公司僅知曉自由軟體的「自由下載與使用」,卻不清楚其體用或本質,於是,仍以過去封閉的方式開發,也就是說,只是把自由軟體當作書本的「範例程式」,當然,這樣的確可行,但在這個 "Programming 2.0" 的新紀元,我們有必要改變思維。

首先,所謂「流水不腐」,這就是自由軟體的精神其中一個面向,蓬勃發展的計畫如Linux kernel,隨時都引入新的技術與硬體支援,我們當然該緊密跟上這些脈動,但開發產品不是兒戲,往往得先挑選一個堪用的軟硬體設計,然後依據功能需求,進行調整與改寫,這是我們相當清楚的。但過去的問題就是,這樣的軟體設計往往無法再銜接到日新月異的社群發展,也就難以跟新的開發版本銜接,於是乎,我們得認真的思考分散式版本控制系統 (Distributed Version Control System),對過去集中式的系統做了反撲。在多方的評估與實驗下,我們的建議是採用SVK,大幅降低許多嵌入式系統開發的維護難度。

2004年在Asia BSD Conference就聽過clkao (高嘉良) 前輩介紹SVK,也在一些專案用過,不過後來都不了了之,總是卡在技術問題上。今年二月份為了維護 PXA27x Linux計畫,又使用了SVK。在之前的blog "Qemu patches" 可看到系統模擬所做了修改,但事實上那還是一部分,更別考慮到qemu的活躍發展所導致頻繁的API changes,還好,我們有SVK

參考 "Using SVK As A Repository Mirroring System" 一文提供了簡要的SVK用法,可輕鬆的維護發展分支,PXA27x Linux計畫的子項目PXAemu就是以qemu為基礎的設計,要保持跟upstream (Qemu官方) 同步發展,可以很簡單,以下是運作的輸出畫面:

jserv@work:~/virt/pxaemu$ svk pull
svk: $ cvs login # for 'anonymous'
CVS password:
svk: $ cvs ... checkout qemu # establish local CVS workspace
svk: appending required ChangeSets, StringEdit filters
svk: running cvs log qemu
svk: found 587 rev(s) with 1073 tag applications
svk: no revisions to write
svk: sorting by change_id
svk: committed 0 revisions
自動合併(2812, 2814)/mirrors/qemu/trunk 到 /projects/pxaemu(源頭為 /mirrors/qemu/trunk:2812)
U target-sparc/op.c
U target-sparc/cpu.h
U target-sparc/translate.c
新的合併歷史紀錄:b2c12b54-451a-302e-ae34-065fcc141066:qemu/.../trunk:2814
已送交編號 2815 的更動。
同步化 //projects/pxaemu(/projects/pxaemu)於 /home/jserv/virt/pxaemu 到第 2815 版。
target-sparc - 略過
target-sparc/op.c - 略過
target-sparc/cpu.h - 略過
target-sparc/translate.c - 略過
在 Debian 中需要安裝兩個套件:svklibvcp-dest-svk-perl。如上所示,這就是智慧型的 merge,因為PXAemu本身已移除ARM以外的target,所以即便upstream的qemu有其他架構的更新,也會自動忽略。如此一來,建立特定需求的版本分支可以相當輕鬆,卻可擁有強大的離線版本控制能力,對於許多Embedded Linux專案來說,其Know-How其實就是「如何基於原本的原始程式碼,針對需求去調整」,那麼,我們就可以善用SVK,當然,上面只展示一部分特性,事實上,在SVK 2.0又提出一堆強大的功能。

最近我也利用SVK來管理Build system,我們都知道OpenEmbedded有豐富的支援,但入門不容易,又常常無法順利建構套件或系統,OpenedHand則建立Poky這個特製的系統,試圖去降低OpenEmbedded的難度,於是,我有個簡單的想法:
「能否把原本依賴OpenEmbedded的OpenMoko建構系統,改成Poky為基礎的形式?」
想法很單純,但實現有很大的難度,這相當跨越了OpenEmbedded、Poky,以及OpenMoko這三個repository。過去我們往往得訴諸大量人工介入,但有了SVK,一切都改觀了,以下是操作畫面:
~/openmoko-builder$ svk mirror --list
Path Source
============================================================
//mirror/openmoko http://svn.openmoko.org/trunk
//mirror/poky http://svn.o-hand.com/repos/poky/trunk
~/openmoko-builder$ svk pull
Syncing http://svn.o-hand.com/repos/poky/trunk
Auto-merging (3059, 3149) /mirror/poky to /project/openmoko-builder (base /mirror/poky:3059).
U meta/conf/distro/include/preferred-xorg-versions.inc
meta/conf/distro/poky.conf - skipped
U meta/classes/cpan.bbclass
U meta/packages/avahi/avahi_0.6.15.bb
...
A meta/packages/xorg-xserver/xserver-kdrive-common.inc
meta/packages/mozilla - skipped
meta/packages/mozilla/minimo_0.016+cvs.bb - skipped
New merge ticket: 311d38ba-8fff-0310-9ca6-ca027cbcb966:/trunk:1691
Committed revision 3151.
Syncing //mirror/openmoko in /home1/jserv/openmoko-builder to 3151.
U meta/conf/distro/include/preferred-xorg-versions.inc
U meta/classes/cpan.bbclass
...
上述的動作,僅有svk pull,就輕易的把Poky與OpenMoko的SVN repository的更動「拉」下來,並自動與本地端 (openmoko-builder) 整合進去,不再有無謂的人為介入,當然,最重要的是開發者與功能需求,但良好的工具讓工作變得輕鬆,也得以專注於處理問題本身。

未來如果有機會,或許也可以分享這方面的經驗,並導入既有的系統開發中。

OpenMoko的OpenGL/ES實做

兩年前我建立名為PicoGL的專案計畫,目標是建立高可攜性、高彈性,且輕量級的OpenGL實做,日前展開OpenGL ES的初步支援,現在已可在OpenMoko/GTA01上順暢的執行。週二晚上的活動「【5/8 TOSSUG 心得分享】 Sean, LaForge: Free your phone! OpenMoko」,我展示這些進展給Sean Moss-PultzHarald Welte看過,結果Harald Welte還一眼就認出這是PicoGL。以下是執行的畫面:

這是OpenGL知名的齒輪展示程式,原本由Mesa 3D Graphics的老大Brian Paul撰寫,現在移植到OpenGL ES API,另外一張:

展示OpenGL ES的Texture Objects (EGL_TEXTURE_2D),等做了些performance tuning後,應該就可以準備新的釋出版本。此外,之前的文章「當Java遇到OpenMoko」提過我正在進行的OpenMokoCacao/CLDC移植,現在也有新進展,這是展示畫面:
我的途徑是直接跳過X Window System,直接在Linux framebuffer上作影像輸出,現在Java ME/CLDC的效能已經可接受,但細部的處理如Graphics renderer則還有很大的進步空間,而我也正在與MIDPath專案開發者合作。

2007年5月9日星期三

TOSSUG心得分享:Free your phone! OpenMoko

魔法設計師是位對OpenMoko很有興趣的朋友,日前他耳聞TOSSUG的新聞「【5/8 TOSSUG 心得分享】 Sean, LaForge: Free your phone! OpenMoko」,興致高昂的參與,隨後他則做了一份簡要的紀錄與感想,取得同意轉貼如下:


昨天,跟阿江、yap一起去土虱社群的第五場心得分享聚會活動,這次是加開的分享場次,是openmoko計劃的兩員大將:Sean Moss-Pultz(任職於大眾電腦)、Harald Welte(是個hacker,也是linux kernel的iptable維護人)分享,這麼難得的機會,當然要去的囉。

Sean 的娓娓道來openmoko計劃,透過開放系統與封閉系統的過去發展,當是開放的體制時,像internet,本來的設計,是國防科技的用途,但在開放以 後,一飛沖天,衍生出許許都多當初原始設計所無的應用,個人電腦更是不用說了,在1983年,IBM推出的Personal Computer開放架構,結束了之前個人電腦數個封閉系統各自稱王的時代。然而手機呢,從發明的那一天開始到現在,想要一支使用者有完整掌控力的手機根 本是緣木求魚,因為他們都是封閉式系統。

想要有完整掌控力?別說笑了,不要說手機發展了那麼多年,到了近年,已經有手機的硬體能力已經逼 近Desktop,Desktop軟體理論上可以毫無困難的在手機上使用,但這幾年最主要的給使用者控制手機權力,不談基本的電話、簡訊、電話簿等機能, 其實沒什麼進步,ok給你變變桌布、變變鈴音的權力,再多一點,給了你java執行環境、或是讓你可以安裝一些原生程式,但是我的手機實際上能取得哪些軟 體?能讓我的手機有什麼新的機能?很遺憾的,幾乎是手機商不然就是系統商給你定義好的,這對發展手機軟體的人與廠商也很苦手,想發展一個軟體,且推到終端 消費者手上,只有電信系統商下載、手機隨機bundle,幾乎沒什麼獨立通路。更甚,近幾年也有很多廠家在特種的Linux核心上做出了號稱的Linux 手機,最近幾年Linux手機發光發亮,光是在中國大陸的智慧手機市場,Linux手機有30%的佔有率(symbian居首,微軟平台居末),只可惜雖 然系統核心是Linux,可是Linux上面堆出來的不同層次系統服務,一點也不open,而那個特種Linux核心呢?很抱歉,原廠只會給你那舊舊他們 覺得夠用的系統核心,新核心?想都別想,手機公司要維護那麼多的手機產品線,怎麼可能光顧你那麼一個「特定」需要呢?反正手機用久大家都會換的嘛,我做手 機公司的,只要顧著把手機賣出去就好啦,再來就是推出新手機勸你換更好的一台,幹嘛一台一台去幫你維護手機系統軟體的更新呢?

然 而今天openmoko這個新平台完全打破了這個封閉性,openmoko手機從最底層一直到最表面的應用層,完全都是opensource,而且還不是 普通的opensource,而是對應PC桌面軟體的應用!openmoko軟體stack大致是linux kernel-glibc-X11-GTK+-matchbox桌面,簡而言之,PC的GTK系的應用程式,只要開發者重新拉拉介面調成適合手機的版面, 然後編譯成arm的cpu平台,就可以放到openmoko手機上跑,簡單說Desktop的Gnome系有什麼可以跑的程式,就可以很容易放到 openmoko上去(這個大家可能還沒什麼感覺,但要是說到即時通超級瑞士刀:gaim,msn/yahoo messenger/icq/msn/jabber/gtalk/irc 就因此可以在手機上....、用手機做簡報....),甚至更新系統核心等等,而怎麼安裝程式、更新程式呢?就是Debian、Ubuntu使用者耳熟能 詳的apt-get,使用者要怎麼用手機、要用什麼軟體、甚至說自己有能力寫寫命令稿語言,要做量身而定的運用時,完全是使用者的自由,對軟體開發者而 言,不用經過系統業者、手機廠商,也能有自己自由的發佈通路!這讓人很有想像空間,例如說自己把手機外接usb的智慧卡讀卡機,用手機就可以查帳、自動打 電話給指定名單公告特定事情、手機照完相後相片自動上傳到特定網路相簿、密文簡訊、也許還可以做自製電話答錄系統(按1聽我的個人介紹、按2直接跟我說) 呢,這讓人有許多想像空間,從硬體到軟體都可以hack。從某種角度而言,openmoko其實應該也算是一種Linux distribution,只不過是給手機這種迷你電腦用的。

待續

2007年5月7日星期一

DIET-PC的ARM移植

注意DIET-PC專案有一段時間了,當我還在老東家作Linux thin-client時就耳聞此專案,不過因為某種原因,一直沒有嘗試。以下是DIET-PC 網頁上提供的簡介:

DIET-PC (DIskless Embedded Technology Personal Computer) is a Do-It-Yourself open source thin client software kitset, allowing IT professionals to construct generic- or special-purpose thin clients, or other network appliances, using commodity x86 PC or PowerPC Mac hardware. Experimental support is also available for ARM hardware.
雖然是單人計畫,但規模也日益增加,現在也提供ARM與PowerPC的移植。與其他Thin client或嵌入式計畫不同之處是,儘管「小而美」是重要訴求,但DIET-PC並沒有因此改用uClibcdietlibc,而是採用GNU C Library與Xorg,保持PC上的相容性。DIET-PCARM移植版本所採用的參考硬體是Hot-e HL200,這是ARMv4t/ARM920T的架構,也可以透過qemu去模擬執行。取得相關的檔案後,透過以下方式去啟動系統:
qemu-system-arm \
-M integratorcp926 \
-kernel zImage.integrator \
-initrd initrd.img \
-append "ramdisk_size=20480 root=/dev/ram0 rw ip=dhcp" \
-redir tcp:2222::22 -redir tcp:5910::5910
以qemu提供的user mode network stack轉向功能,將模擬環境的port 22 (SSH)對應到host的port 2222、port 5910則是VNC port。root帳號與VNC密碼都是"foobar",系統啟動後,會執行Xvnc,於是可透過VNC client去操作DIET-PC,以下是執行畫面:

視窗管理程式與桌面是我熟悉的Qvwm,執行中的應用程式是RDP (Windows Terminal Service)程式rdesktop,整體來說,這是個很精巧的系統。

2007年5月6日星期日

反組譯 OpenMoko Steppingstone Code

在正式的內文之前,先來說個小故事。前一陣子在Atmel AT91RM9200這顆ARM9微處理器的實驗板上寫了一個簡單又迷你的kernel,後來想想認識的人裡面都沒人玩這顆,不免有點孤單。於是打算把它移植到比較多人玩並且有模擬器可用的平台,剛好jserv推薦OpenMoko,OpenMoko 的第一支手機Neo1973/GTA01所使用的微處理器是Samsung S3C2410也是 ARM9,我想應該不難移植,還有jserv掛保證的模擬器可用,所以就決定來玩OpenMoko/S3C2410啦!

既然我的出發點是要開發kernel,那麼對於處理器的啟動程序就不可不知。S3C2410啟動時,會從NAND flash的開頭複製4KB 內容到內部的SRAM,然後跳到SRAM開始執行,這4KB SRAM就稱為Steppingstone。這段小程式就是處理器最先執行的程式,但4KB空間當然放不下U-Boot,於是我們只把這段小程式當作踏腳石(steppingstone),由它來幫忙載入完整的U-Boot bootloader。

在好奇心作祟之下,想來看看這段steppingstone code寫些什麼(其實也沒什麼,真的很無聊吧 XD)。在 http://buildhost.openmoko.org/tmp/deploy/images/ 抓了lowlevel_foo開頭檔名的".bin" 檔,問題是我只知道可以用arm-linux-objdump來反組譯 ELF 格式的程式,那麼binary檔怎麼反組譯呢?上網Google了一下沒有找到ARM反組譯器(其實是前幾個連結沒有就懶得繼續找了),網友說IDA Pro這套軟體可以反組譯ARM程式,但我懶得安裝這麼龐大的東西。只好換個關鍵字繼續 Google 看看,結果找到了這個網頁:

firmware_reverse_engeneering_methodology
原來可以把binary檔轉成ELF檔再進行反組譯,方法如下:

先把binary轉成ELF格式:
$ arm-linux-objcopy -I binary -O elf32-littlearm foo.bin foo.elf
再進行反組譯:
$ arm-linux-objdump -marm9 -D foo.elf > foo.asm
輸出結果foo.asm是個純文字檔,內容就是反組譯出來的組合語言。簡單吧?不需要安裝其它軟體,只要利用toolchain就能辦到。學會這招後,手邊如果有實驗板沒開放bootloader原始碼,或者想hack PDA bootloader,都不是問題啦(當然得有耐心去trace組合語言程式碼)!

OKL4在gumstix的測試結果

之前的文章「Open Kernel Labs公司成立,強化L4與虛擬技術應用」提過新成立公司的 "Open Kernel Labs" 提供一系列以L4 microkernel為基礎的embedded與virtualization技術,而即使在邁入商業應用的今日,仍以BSD License (3-clauses)釋出成果,態度相當可取。"Open Kernel Labs" 提供一個針對開發者的Portal site:portal.ok-labs.com,目前開放下載的版本為okl4 release-1.4.1.1,支援IA32與ARM (arm926ejs, xscale, arm1136js, arm1176js)等架構,若以平台來看的話,通用IA32架構,也就是PC99,以及gumstix (based on PXA255)兩項有支援。

gumstix的應用很廣,許多機器人與控制系統都可見其蹤跡,同時也是採用我比較熟悉的Xscale架構,去年也開始相關的qemu模擬工作,自然引起我的高度關注。okl4 release-1.4.1.1相較於NICTA的版本,實在簡單許多。首先,得準備好工具,python2.4、Skyeye (用以模擬與偵錯gumstix),以及ARM toolchain,剛剛已在台大做了mirror如下:

在進行之前,我們來複習NICTA規範的L4 Microkernel / Embedded & Virtualization的架構,Iguana是個運作於L4 microkernel的server,提供作業系統所需的系統服務,像是記憶體管理、權限控管,與驅動程式等等;Kenge概念上類似L4Env,也是提供虛擬執行環境所需的基礎建設;Wombat就相當有意思,也是本架構的賣點,Wombat是個修改過的Linux kernel (目前版本 2.6.10),運作於L4 Microkernel與Iguana之上,如此一來,既可透過Wombat來達成原本Linux應用程式的相容性,又可在L4 Microkernel達到Realtime最佳的效能。OKL4 release提供以上元件的實做,附加具體而微的Linux系統,基本上,只要設定toolchain與Skyeye的路徑後,直接執行以下指令即可建構:
./tools/build.py machine=gumstix project=iguana wombat=True simulate
需注意的是,預設的安裝script忽略了libgcc_s.so.1,所以記得自ARM toolchain複製一份到 build/linux/install/lib/ 目錄。

透過模擬環境的執行畫面如下:
我在圖中以紅色箭頭標注了此virtualization環境的變化。首先是L4 Microkernel,再來是IguanaKenge,最後就是Wombat,最後會跑完Linux booting flow,切入Linux user-space。對了,剛剛也試著用qemu去執行,但似乎會卡在igms0的處理。

2007年5月2日星期三

Xorz/Embedded作為Phone UI

之前在「動態組字技術於Embedded領域」提過我們最近實做的動態組字技術基礎建設,與其適用的場合和思維方向,其中也提到Xorz/Embedded (展示1/展示2)。整合動態組字技術,對於原本即以向量繪圖為核心架構的Xorz/Embedded來說,是今年的規劃,可作為低階裝置的UI (User Interface) 或者是進行能源管理處理時的圖形操作,甚至可以植入kernel space或boot loader。

最近又對Xorz/Embedded做了refactoring與改進,現在backend有SDLX11,與Linux framebuffer。在週二晚上與OpenMokoSean Moss-Pultz & Harald WelteJollenChihchun等人聚會時,展示了最新的成果,以下是運作於Neo1973 GTA01的畫面:

關鍵技術有:向量繪圖、快速座標轉換、半透明處理、動態字型描繪、輕量級視窗管理等,近期內會開放實做,允許創造更多應用。同時也與Sean Moss-Pultz談及Linux-based feature phone的可能性,就技術上本身來說是可行的,而且他也給予正面回應。我想,如果這些基礎建設都穩固後,自身對GreenPhonegpephonOpenMoko的設計有更好的掌握後,或許我可在OpenMoko的基礎上建構以Xorz/Embedded為核心的Phone (UI) stack,或許可稱為"OpenMoko-Lite"。

憶及之前閱讀的報導「Linux well-positioned in feature phones, Trolltech founders say」,雖然已過一年,但其中有些觀點仍是值得思考的。我們不僅得思考BOM (Bill-Of-Materials) cost,Trolltech的兩位創辦人Eirek Chambe-Eng與Havaard Nord也提醒我們:

"The line between smartphones and feature phones will be totally blurred."
訪談也談及single-chip、virtualization,與系統複雜度等議題,所以在設計的同時,也得有清楚的思維與定位。

iThome電子報對於黑客鬆的報導

之前提過「OrzLab::黑客鬆紀錄」,以輕鬆的口吻介紹了我們在「台灣黑客鬆」進行的Hacking,本週則收到iThome所寄來的刊物,裡面有對此活動作詳盡的報導,當然也包含OrzLab。台灣黑客鬆有篇紀錄「iThome 電腦報 292 期的報導」可作為參考,取得同意轉載如下:


謝謝iThome及其所屬記者王宏仁先生。有趣的是,原先我們並未邀請任何媒體。:)

另外,「首次」這樣的帽子有些沉重,頂多只能說是小小地在「跨社群」(也未必啦)上拋磚引玉罷了。最重要的是謝謝所有與會者的付出。m(_ _)m

Taiwan Hackathon - iThome News, No. 292

跑新聞出雜誌總是很辛苦的,還請有興趣看內文的人花點小錢到書店買一本囉!



週二下午跟iThome的編輯小談片刻,看來他們的報導很用心,雖然版面不大,但基本意思都點到了,或許待日後OrzLab有更多成果時,也來分享一些經驗與想法。