Planet OrzLab

從 OrzLab 移轉到 0xlab

2009-06-22T04:51:00.004+08:00

2007年的愚人節，我們做了一個小實驗，藉由號召熱衷於電腦技術的朋友，透過OrzLab的成立，嘗試聚焦作些有趣的Hacking。儘管所有成員都是出於自願並得挪用下班與課後的有限空檔時間，但仍累積一些成果，並在這個過程中，無私地分享與交流，的確已達到當初的期望，並建立初步的人際互動。

不過礙於現實的考量，成員們要不從學校畢業，就是邁入新的工作里程碑，既然當初聚焦作些Hacking的目標已達成，接著就該讓台灣本土的軟體創作走入國際，嘗試與全球多元的環境互動。在寂靜了好長一段時間後，我們有機會從剛創立的 0xlab，得到新的希望，我們之中，開始有人能全職作free and open source software，也有人試著與台灣的電子產業建立聯繫，並試著將這些聲音，以行動的方式，傳遞到更遠更廣的區域。回首來時路，只能用愛因斯坦的話語，來表達我們的初衷：「對一個人來說，所斯望的不是別的，而僅僅是他能全力以赴和獻身於一種美好事業」。

目前，0xlab不僅從過去開發的專案中累積經驗，也積極地透過自由軟體的力量，追尋更多元、益於嵌入式與移動裝置開發的協同創作模式，除了已釋出的原始程式碼之外，也可一併參照開發日誌Planet 0xlab。相當榮幸能跟這群熱血並才華洋溢的朋友共事，彼此也能融洽的合作，一同獻身於自由軟體與嵌入式系統開發的美好事業，但，這一切只是開端。

本文不是宣告OrzLab的終止，而是聲明正面的蛻變，在許多人不看好台灣軟體產業的同時，其實一小群執著的人們，不斷地爭取嶄新的舞台，以不同的視角觀望著資訊產業的巨變。因此，從OrzLab移轉到0xlab，不僅是從業餘走向專業的過程，更可以說從實驗到實際的體驗，希望舊雨新知能繼續指導，更感謝所有為OrzLab付出、參與討論與開發的朋友們。

關於0xlab的資訊與動態，可參考以下：

而原本OrzLab的資源仍會公開存取 (只要hosting沒出問題)，但更新與軟硬體整合的部份，會全面移往0xlab，再次感謝！

WebKit/QT & WebKit/GTK+ on Ubuntu Linux初體驗

2007-12-11T22:46:00.000+08:00

前兩篇「WebKit的Gtk+支援」與「OWB：以WebKit為基礎的嵌入式網路瀏覽器」介紹了些 WebKit的開發現況後，這邊大概講一下在Ubuntu Linux底下如何無痛進行初體驗。依據官方首頁的訊息，WebKit 簡介如下：

WebKit是一種開放原始碼瀏覽器引擎，同時也是 Mac OS X 底下的Safari 、 Dashboard、Mail、與其他Apple Mac OS X所使用的系統框架版本。WebKit所使用的KDE函式庫KHTML與KJS是屬於HTML與JavaScript實做的分支。

先來體驗一下原生於Qt的WebKit瀏覽器，動手打造個「仿Safari」。以Ubuntu Linux 7.10為例，操作程序如下：
1. 先安裝編譯時所需的軟體與套件庫

sudo apt-get install libqt4-dev libxslt-dev gperf bison libsqlite3-dev flex build-essential subversion

2.取得Subversion中的原始碼 (筆者花了近20分鐘才下載完畢，所以請保持耐心)

svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit

3.建立一個Qt for WebKit的瀏覽器
(安裝的機器 Intel CoreDue L2300@1.5GHZ 跑了近45 min )

QTDIR=/usr/share/qt4/ WebKit/WebKitTools/Scripts/build-webkit

4.安裝完後，打以下指令開啟剛剛建立的瀏覽器。

WebKit/WebKitBuild/Release/bin/QtLauncher

有圖有真相!!

接著，嘗試原生於Gtk+的WebKit，不過這次就直接介紹個剛成立的一個新軟體專案 Midori來體驗一下 WebKit/Gtk+。Midori 是一個輕量化的瀏覽器，有以下特點：

完全採用Gtk+ 2.x打造
以WebKit 進行快速網頁繪製
分頁、視窗與任務對話管理
書籤的儲存採用XBEL
搜尋框則基於OpenSearch
可自訂前後選單動作
支援使用者腳本與樣式自訂
可透過 Lua scripts 擴充

然而，這個專案目前還是屬於alpha測試版的狀態，所以可能會比較不穩定些，而且有些功能還沒實做出來。

Midori目前則可透過apt的方式去安裝預先編譯的套件，但得先編輯設定：

sudo gedit /etc/apt/sources.list

然後加入以下兩行：

deb http://ppa.launchpad.net/stemp/ubuntu gutsy main deb-src http://ppa.launchpad.net/stemp/ubuntu gutsy main

儲存後離開，並進行更新：

sudo apt-get update

然後就可安裝Midori：

sudo apt-get install midori

跑完後，就可以直接從「應用程式」裡的「網際網路」選單開啟Midori ，其執行時期的快照如下：

本文改寫於以下兩篇文章：

svn http, user-password and access control

2007-11-20T09:13:00.000+08:00

使用http protocol作為Subversion的URL，可利用apache的dav_svn module達成。

dav是distribution authorization and versioning，為http協定的一個擴充

AuthUserFile  /etc/apache2/dav_svn.passwd
AuthzSVNAccessFile /etc/apache2/dav_svn.authz

所以：

要先準備好這兩個擋案，並依據.conf 的內容，擺在對應的路徑中
user-passwd file的內容是用 htpasswd 操作的，add user、change password都要用htpasswd來作
svn下各個目錄的存取權限就由dav_svn.authz設定，該檔案為純文字檔

Add User :

htpasswd  'target .passwd file' user-name

這裡'target.passwd file'就是/etc/apache2/dav_svn.passwd.

權限設定方式：

[/]
* =
guest = r
svntest = rw
charles-chang = rw

意思是對 [/] 目錄的權限設定：
* - 所有人 - 無法access
guest - 僅能讀取，無法修改
svntest, charles-chang 都是一般user，可以讀取、修改。

當然，要用htpasswd把 guest, svntest, charles-chang都加到 user-passwd file 中

僅能讀取的user一樣可作check-out、add file等操作，但在commit時會出現error，svn log上也不會有該user的更動紀錄。

使用hg內建的web server

2007-11-20T08:59:00.000+08:00

hg( Mercurial)內建 web server。

一般使用方式如下：

到已開啟好(hg init完畢)的repository (例如 c:\writeMLC)目錄下，執行以下指令：

hg serve -p 8002

然後開啟web browser，開啟以下網址：

http://127.0.0.1:8002/

即可看到該repository的資訊：

此功能一方面可以作為command line模式的"friendly front end" ，另一方面，可以跟合作夥伴共享程式碼。

若有多個repository ，就要用webdir-conf 這個選項。使用方式先編輯一個設定檔，指定web server path和repository的關聯性：
編輯一個檔案 (假設為webdirconf)

[paths]
writeMLC = C:\Whimery\DownloadWriteMLC
UseYagarto = C:\Yagarto\UseYagarto
BootRun = C:\BootRun\BootRun_Robert

在啟動hg server時，加上以下參數：

hg serve -p 8002 --webdir-conf webdirconf

然後在web browser上的顯示會像是以下：

每個 repository 可以自行設定一些特徵，諸如：web style、authorization、zip download support，指定方式即利用每個 repository 下.hg目錄裡的hgrc 檔 (要自行建立與編輯）。

以下就是為了方便所寫的hgrc內容：

[web]
style = gitweb
allow_archive = bz2 gz zip
push_ssl = false
allow_push = *

說明：

改用git style 的wen interface (較詳細)
增加 bz2、gz、zip的source snapshoot下載
不使用ssl (因為不知道在windows command 下怎麼用 :P)
允許經由http作push的動作 (允許他人check-in)

OWB：以WebKit為基礎的嵌入式網路瀏覽器

2007-11-13T03:46:00.000+08:00

幾個月前介紹了「WebKit的Gtk+支援」新進展，現在openmoko已正式採納為web engine，提供為網頁瀏覽與RSS reader使用。Origyn Web Browser (OWB)則是另一個以WebKit為基礎的開放原始碼網路瀏覽器 (BSD license + LGPL + misc)，針對嵌入式環境做了許多微調與修正，引入一層簡化描繪與底層操作的軟體層，稱為OWB Abstraction Layer (OwBal)，得以銜接WebKit與消費性電子產品需求。具體來說，原本的WebKit需要heavyweight UI toolkit去作widget/font描繪，但OWB以OwBAL巧妙地補齊介面部份，並允許lightweight UI呈現，也就是 "render itself by its own toolkit"。詳細的技術介紹可參考「Introducing OWB, an open-source browser for consumer devices」一文。

建構方式如下：

取得開發中的程式碼：

svn checkout http://www.sand-labs.org/svn/trunk owb

以CMake調整組態設定：

cd owb && ccmake .

具體情況如下圖：按下[c]則可進行組態設定，過程中會提示缺乏的開發套件。
最後按下[g]即可產生必要的Makefile

開始建構，當然是執行make

目錄下應該會有名為"owb"的執行檔。注意，建議安裝CJKUnifonts以支援中日韓文顯示支援，並且需作以下修正：

Index: BAL/Implementations/Fonts/freetype/BTFont.cpp
===================================================================
--- BAL/Implementations/Fonts/freetype/BTFont.cpp       (revision 147)
+++ BAL/Implementations/Fonts/freetype/BTFont.cpp       (working copy)
@@ -114,7 +114,7 @@
int size = static_cast<int>(m_fontDescription.specifiedSize());

if (m_fontMap[size] == 0)
-        m_fontMap[size] = d->open("/usr/share/fonts/owb.ttf", size, 0);
+        m_fontMap[size] = d->open("/usr/share/fonts/truetype/arphic/ukai.ttf", size, 0);
d->m_ttfFont = m_fontMap[size];
if (d->m_ttfFont == NULL)
   logml(MODULE_FONTS, LEVEL_EMERGENCY, make_message("open : \n"));

以「Jserv's blog」為例，OWB的呈現效果如下：

在組態設定時，指定了以FreeType作為字型描繪引擎 (即 "WEBKIT_USE_FONTS_FREETYPE" 選項)，以取得更加的顯示效果。可發現網頁周圍沒有視覺捲軸 (但可使用方向鍵或PageUp/Down)，而且HTML按鈕則是OWB自行描繪的，輸入框亦然。

OWB現在的空間使用量與網頁呈現正確度相當不錯，除了使用curl的方式還需要效能調整外，整體已相當穩定，目前的參考圖形引擎實做為SDL，官方網頁提供相當好的移植文件「OWBAL Porting Guide to Embedded Systems」。依據發展方向，OWB適合應用於Set-Top Box、數位電視、Kiosk等環境，並且對DirectFB的支援也開始進行。

EGLIBC於S3C2410 ARM SoC的體驗

2007-10-21T22:47:00.000+08:00

稍早於「EGLIBC初探」提過CodeSourcery與諸多系統廠商合作，針對glibc的改進計畫 (自2.5版開始)，實做出更適合Embedded環境的C Library實做 ── EGLIBC，前文也提及快速建構的script，而OpenEmbedded也正式納入對EGLIBC的支援。所以現在要建構與測試都可以相當快速，以下是參考的option groups組態：

jserv@venux:/home/moko/build$ cat ../org.openembedded.dev/packages/glibc/eglibc-svn/option-groups.config
# This file sets default values for all option group variables
# mentioned in option-groups.def; see that file for a description of
# each option group.

OPTION_EGLIBC_ADVANCED_INET6 = n
OPTION_EGLIBC_BSD = n
OPTION_EGLIBC_CATGETS = n
OPTION_EGLIBC_CHARSETS = n
OPTION_EGLIBC_DB_ALIASES = n
OPTION_EGLIBC_ENVZ = n
OPTION_EGLIBC_FSTAB = n
OPTION_EGLIBC_GETLOGIN = n
OPTION_EGLIBC_INET = y
OPTION_EGLIBC_LIBM = y
OPTION_EGLIBC_LOCALES = n
OPTION_EGLIBC_LOCALE_CODE = n
OPTION_EGLIBC_NIS = n
OPTION_EGLIBC_NSSWITCH = y
OPTION_EGLIBC_RCMD = n
OPTION_EGLIBC_SPAWN = n
OPTION_EGLIBC_SUNRPC = n
OPTION_EGLIBC_UTMP = y
OPTION_EGLIBC_UTMPX = n
OPTION_EGLIBC_WORDEXP = n
OPTION_POSIX_REGEXP = y

具體的細節可參考Jim Blandy發表於mailing-list的文章「EGLIBC size measurements for option groups」，EGLIBC透過option groups可讓C runtime的建構更加模組化，可輕易挑選Embedded環境所需的特徵，大幅降低code size與memory footprint，以常見組態來說，後者相較於glibc縮減為85%。筆者實際在openmoko GTA01bv4硬體 (based on S3C2410 ARM SoC)測試，在Smartphone的使用情境中，free memory從原本58444 bytes (glibc) 增加到67404 bytes (eglibc)，幅度達13%，功能卻沒有因此打折，這與uClibc或其他小型的C Runtime來說，是很大的優勢。

取得筆者建構的EGLIBC-based openmoko 2007.2 image：http://people.openmoko.org/jserv/images/

教學：透過screen + irssi使用IRC

2007-08-27T22:20:00.000+08:00

最近身旁許多在上 IRC (Internet Relay Chat)的朋友都問我哪個IRC client 比較好用？其實，只要問過我的，而且又是UNIX-like的系統使用者時，基本上都會被我推薦irssi這個command mode的純文字IRC程式。若有server可用的朋友們，更是會被我力推screen + irssi的組合。好處是，可以遠端持續掛著IRC，到哪邊都可以ssh進去繼續看IRC log，這樣真的很方便，也不用擔心因為沒開自己的電腦，就看不到別人的對話或別人要留給自己的訊息。

以下是針對irssi這軟體所寫的簡易基本介紹與使用和一些需要使用到IRC與GNU screen的基本指令，如需IRC或screen的其他更詳細指令與資料，文末會補上相關連結，如有不足，歡迎補充。

irssi的程式安裝不贅述，可由apt-get或yum等工具自套件庫裡面找尋並安裝。

先在這邊建立第一次使用screen + irssi操作IRC的朋友們觀念，確定遇到的問題跟操作，該是由screen還是由irssi的程式部份來處理，或者本身只是IRC上的指令操作罷了。screen只是方便讓使用者可以利用server不關機的優勢，讓irssi可以連續開著不中斷，使得下次再透過screen來接軌回到上次開啟還未被關閉的irssi來繼續IRC這樣子。所以，這樣看下面的簡介操作後比較不會搞混狀況，如果請教朋友也比較能問到問題處。

以下例子皆以irssi 0.8.10或以上版本，經實驗都可順利執行，且都以在FreeNode上的#orzlab IRC channel 為例。

(如果不掛 screen 者，這一段請直接跳過) 首先ssh login到server後，請輸入：

screen -RD
-R Reattach if possible, otherwise start a new session.
-D (-r) Detach and logout remote (and reattach here).

然後會進入到新開啟的screen，並且screen會自動開啟一個新的window讓我們使用，接下來直接輸入：
irssi
就會在screen底下的第一個視窗執行irssi這隻程式。

如果沒有要掛著screen執行irssi的朋友，那直接輸入
irssi
就可以直接執行 irssi 這隻程式。

進入irssi後，直接在提示輸入字元處輸入
/connect irc_server
就會直接連到該個IRC server，例如：
/connect irc.freenode.net
這樣就會直接連接到freenode的IRC server上，此時，可以先在這邊修改自己要在該IRC server 上的暱稱，如果要修改，則輸入以下格式：
/nick you_want_nickname
例如當我輸入
/nick lzy
時，那我顯示出來的暱稱將會是「lzy」的字樣( irssi 預設的暱稱會是 login 的使用者名稱)。
搞定暱稱後，接著我們就可以加入其他頻道了。
只要輸入
/j #channel_name
就可以直接加入了，例如：
/j #orzlab
這樣就完成加入#orzlab這個IRC channel(即OrzLab的主要IRC channel)，如果該IRC channel需要key/password的話，則輸入：
/j #channel_name password
如果要離開單一IRC channel ，則直接輸入
/wc
就可以離開這個IRC頻道。
若是要離開一個IRC server的連線，則輸入
/disconnect irc_server_name

剛剛是教如何連線，現在則是教一些常用的熱鍵與功能。
先來看圖說故事一下：

上面的這張圖，我們在
[Act: 1,2,4,6,9,10]
這邊發現了幾個不一樣的標示數字，Act這一欄位會提示你在第幾編號的channel上對話狀況，而你還沒切換到該IRC channel 上觀看。顏色對應的意思如下：

灰色一般體的是代表有人登入或登出此 irc channel (如 1,9,10)
白色粗體的是代表有人正在此 irc channel 上談話(如 4,6)
灰色粗體的則是有人在對話中提起你的名字或者呼叫你，總之就是有出現你的名字(如 2)

這是基本識別，再來是知道哪個channel有什麼狀況後，就是切換到該IRC channel上查看：

Alt + 1~0 對應 1~10 的 irc channel 編號；
Alt + q~p 對應 11~20 的 irc channel 編號；
Ctrl + n/p 可切換上/下一個 irc channel；
按鍵盤上的 PageUP/PageDn 可以直接切換上/下頁訊息。

如發現有編碼上的問題，需要轉編碼的話，則可輸入
/recode add #channel_name code_type
例如要把#orzlab的UTF-8格式加入，則輸入
/recode add #orzlab utf8
即可加入此頻道的編碼格式。
然後輸入
/recode
就可以看到加入的編碼列表。
(註：因 /recode add會寫入到設定檔裡，所以僅需要寫入一次即可)

Ｑ＆Ａ TIME：

Ｑ：如何同時有連接多個IRC server呢？又該怎樣切換不同IRC server來加入該server的IRC channel呢？
Ａ：

請直接再下一次 /connect irc_server 就可以再連接一個新的 irc server ，然後按Alt + 1切換到第一個的特殊頻道上，再按 Ctrl + x來切換目前要下達指令的 IRC server名稱。

Ｑ：如何查看該頻道的所有人呢？
Ａ：

請下達/who的IRC指令即可，然後也是一樣按Alt + 1切換到第一個伺服器狀態頻道上觀看

Ｑ：如何查看單一網友的基本連線資料呢？
Ａ：

請下達/whois nickname的IRC指令即可，然後也是一樣按Alt + 1切換到第一個伺服器狀態頻道上觀看

Ｑ：如何傳送私人訊息到指定的朋友暱稱呢？
Ａ：

請下達/msg nickname即可開啟一個名為指定暱稱的訊息頻道，一樣用alt + 1~0/q~p 來選擇(注意：某些IRC server 會限制此功能，傳訊前請先確認是否有權限，如FreeNode)。

Ｑ：已使用上面所講的方式操作screen + irssi ，那我離開時，是否得下達任何參數或指令？又下次ssh login 後，需要打什麼指令呢？
Ａ：

為了簡化登入與記憶上的方面，採用-RD的參數，所以每次要離開irssi時，直接關閉該視窗就好，不需下達任何參數或指令。然後下一次ssh login後，只要打screen -RD 這樣就可以接軌回上次開啟的irssi了。

Ｑ：如果遠端連線到編碼為Big5 的主機掛screen + irssi，且client端是採用UTF-8編碼時，編碼的亂碼問題如何處理？
Ａ：

首先，先處理screen的編碼問題，從utf8端要檢視big5 server時，先Ctrl + a，然後輸入 :encoding big5 utf8 ，把從server將送出的Big5編碼先轉成UTF-8後再送出，然後輸入 "/recode" 觀看頻道編碼是否指定正確，照上述設定，理應能順利顯示。

Ｑ：如果不小心按到Ctrl + z或鍵盤上的Pause時， irssi被suspend了，該如何恢復？
Ａ：

請直接輸入fg後按Enter ，就可以把剛剛被suspend的irssi給喚醒。

Ｑ：如果我要關閉一個irssi，該如何下達指令？
Ａ：

請直接關閉開啟irssi的screen ，請按Ctrl + k來關閉screen window，然後可以再重新開啟一個全新的 rssi出來。

Ｑ：要如何自動儲存IRC log ？
Ａ：

在需要auto irc log的IRC channel上輸入/SET autolog ON，即可打開autolog功能。

Ｑ：要如何指定當開啟irssi後，自動連接IRC server與自動連接IRC channel ？
Ａ：

直接看例子會比較快，先假設我要讓他自動用 lzy 的暱稱連接到Freenode的IRC server 上的#orzlab：
/network add -nick lzy Freenode /server add -auto -network Freenode irc.freenode.net 7000 /channel add -auto #orzlab Freenode
如果是需要key/password的IRC channel的話，則把最後一行改為
/channel add -auto #irc_channel_name irc_server_name password
也就是直接把密碼接在後面就可以了
如果需要自動對註冊的暱稱進行認證登入的話 (設口令為abcde)：
/network add -autosendcmd "/^msg nickserv ident abcde;wait 2000" Freenode

Ｑ：如何讓irssi發出有人提起自己暱稱時的訊息警告(或響鈴)？
Ａ：

在irssi裡輸入以下指令，讓irssi適時發出聲音訊號：
/set beep_when_window_active ON /set beep_when_away ON /set beep_msg_level MSGS NOTICES DCC DCCMSGS HILIGHT /set bell_beeps ON
在screen中按下Ctrl +a , Ctrl + g的按鍵，讓screen把irssi發出來的聲音訊號傳出來
或參考Jedi的blog一文「會響的 PuTTY + screen + irssi」

Ｑ：如何更換irssi的theme ？
Ａ：

把抓好的 theme(可從官網選擇偏好的)，然後複製該theme的檔案到~/.irssi/路徑，並下達/SET theme theme_name來更改該 theme 。

Ｑ：如何自訂irssi的IRC訊息熱鍵？
Ａ：

因為設定比較繁雜，故只提供官網網址，讓有興趣的朋友可以自己去翻閱。

提供幾個額外補充的網站，沒標示語言者，皆為中文

※本文另有較鄉民版本：「用 screen + irssi 上 irc 之鄉民版教學 (含Q&A)」

SLC ECC Correction in S3C2440

2007-07-31T08:51:00.000+08:00

S3C24xx都內建有NAND Flash Controller，而且都支援NAND Flash Boot。NAND Flash 和NOR Flash 相比，除了不能用linear addressing的方式來access外，就是NAND Flash有「允許bit error」的特性，所以在實際的使用上，就要配合ECC 來correct。

NAND Flash Controller中NFECCSAT0就NFESTAT0 (0x4E000024) ，用來表示以下：

Main Area
Spare Area

兩個區域的「哪個byte中的哪個bit是錯的」，這就是NAND flash Controller提供的hardware ECC 功能。

S3C2440只支援SLC，因為只有內建1 bite ECC，也就是說只能correct 1 bit的錯誤。S3C2443則內建4 bit的ECC，最多可以correct到4 bit的錯誤，所以可以support MLC。

SLC和MLC除了1 time programming的限制外，就是容易產生的Error bit 數。

SLC保證 99.9999% 的chip 只會產生最多 1 bit的error。
MLC要到99.9999%的程度，會有 4 bit error。

(以上的% 是僅供參考)

回到NFESTAT0，要correct bit error，首先要check一下 error的狀態，以bit[1.0],[3.2] 分別代表兩個區域的error狀態：

00 : No Error - Lucky
01 : 1 bit error - Correct 回來
10 : Multiple error - 沒救了
11 : ECC area error - 沒救 (?)

所以，需要作ECC correct的，只有在 01 的時候。

然後讀出 Error bit 所在的byte位置和bit位置，分別是

Byte 位置 bit[17:7], bit[24:21]
Bit 位置 bit[6:4], bit[20:18]

所以correction 的動作

 *(ReadBuf + ByteNo) ^= ( 1 << BitNo ) 

SECCD 就是 Spare-area ECC Data
MECCD 就是 Main-area ECC Data

Baudrate set in S3C2443

2007-07-30T08:49:00.000+08:00

S3C2442 的UART Baurdate可設定的更細微，提供兩個register :

UBDIV : 整數部份
UDIVSLOT : 小數部份

設定的計算為：

整數 + 小數 = SRCCLK/ (baudratex16) - 1

以115200, SRCCLK=40MHz為例

整數 + 小數 = 40000000/(115200 x 16) - 1 = 20.7

所以

整數 = 20
小數 = 0.7

因此，UBRDIV = 20

小數部份與UDIVSLOT的關係是

小數 = UDIVSLOT 中 bit是1的數量 / 16

所以

0.7 = 1's number in UDIVSLOT / 16
1's number in UDIVSOLT = 11

UDIVSLOT有很多種組合，只要讓1的個數是11即可，Samsung建議，個數為11時，UDIVSOLT用 0xDDDD。

筆記：Into Idle

2007-07-28T11:57:00.000+08:00

在設定完chip register，進入idle mode後，還要program co-processor：
這一篇 http://nocash.emubase.de/gbatek.htm 有說明到ARM CP15 Cache Control。

Cn,Cm,Op2 Rd   Command
C7,C0,4   0    Wait For Interrupt (Halt)

另外在linux kernel code中也有：

/*
* cpu_arm926_do_idle()
*/
.align 5
ENTRY(cpu_arm926_do_idle)
#if defined(CONFIG_CPU_ARM926_CPU_IDLE)
mcr p15, 0, r0, c7, c0, 4  @ Wait for interrupt
#endif
mov pc, lr

ref SystemIdle Function:
MMU_WaitInterrupt(void)

mov  r0,#0x0
mcr  p15,0,r0,c7,c0,4
mov pc,lr

所以，這是要cache 進入idle mode，等待interrupt 的意思 ?

S3C2412有三種Power mode:

IDLE
STOP
SLEEP

是利用PWRMODECON 這個register來設定。

說是這樣說，但是Samsung的BSP code卻沒有這樣作，完全沒用PWRMODECON，反而是用 PWRCFG。其中的STANDBYWFI 佔2 bit，設定後，可以進入：

IDLE : 01b
STOP : 10b
SLEEP : 11b

這種利用寫入 PWRMODECON 的STANDBYWFIbit 的作法，在datasheet 中稱作是 "mcr p15, 0, r0, c7, c0, 4"。

datasheet 中「很好心」地為大家提供一個 "alternat method to set STANDBYWFI" :就是用剛剛的cp15 command:

mcr  p15,0,r0,c7,c0,4

但是沒有說明相當於command的哪一個信號? 01b, 10b, 11b ?

對照datasheet和BSP code：

STANDBYWFI 進入IDLE是 01b。
BSP code用 mcr cp15 command 進入時，Rd (在此用r0)，卻是設定成 #0x0。

而且這是datasheet中有關"進入STOP Mode"的說明中寫的，BSP code卻是在進入idle mode 的code中使用的。

接著有一個table，說明進入三個mode的方法：

IDLE - STANDBYWFI
STOP - CMD or STANDBYWFI
SLEEP - CMD or STANDBYWFI

STANDBYWFI 的意思大概可瞭解，雖然有點不清楚，那麼"CMD"是什麼 ?是寫入command到PWRMODECON的MODESLEEP 嗎?

External Interrupt in S3C2440

2007-07-27T08:33:00.000+08:00

S3C2440的EINT (Extend INT)中斷示意

EINT也算是SUB INTERRUPT，但是完全沒有相似於SUBSRCPND的解說。只有register 說明，而且是安排在GPIO的部份... (好吧，該GPIO的mux function有Interrupt，所以算OK吧)。

偉大的EINT的registerg的說明中，EINTMASK、EINTPEND這兩個register只有table，沒有多餘的說明。

本來以為EINTPEND是指「經過mask後的interrupt」，結果不是，是mask前。所以要處理 EINT時要這注意，要將 EINTPEND和EINTMASK「處理」後，才是真正產生中斷的中斷源。

跟trigger mode有關係，當是外部controller觸發，設定成edge trigger時，因為未回應外部controller時，trigger signal不會改變，不會再有一次edge波形發生，所以即使先ACK這個INT也沒關係。反而是未能要能正確，無漏失的catch next edge，ISR要儘快的ACK這個interrupt，免得edge 出現時，interrupt還未ACK而miss。

.. 真是麻煩呀...

這樣的連動是不是要用class包裝起來？當設定edge trigger，該isr先ACK。當設定level triiger，作post ACK?

回到上面的圖，SRCPND經過priority arbitration，Mask後，選出一個bit 到INTPND。實際產生中斷。

INTPND和SRCPND都是要「手動」清除的。
DataSheet (14. Interrupt Controller - Interrupt Pending Register) 是說..

Like the SRCPND register, this reister has to be cleaned in interrupt service routine after cleaning the SRCPND register.

所以，中斷發生後，一定要clear SRCPND和INTPND。而且順序是

SRCPND
INTPND

原因和上面說的一樣..如果先clear到INTPND，但是SRCPND還沒清，則同一個中斷馬上又從SRCPND浮上來，導致一樣的INTPND。

SMS PDU

2007-07-26T09:49:00.000+08:00

ETSI (GSM 03.40 and GSM 03.38)中規範SMS的encoding可有以下幾類：

7 bit encoding：最多可以包含160個characters，其中每個character只用一個或兩個byte的 7-bit data來作encoding。7 - bit encoding table 在.. http://www.dreamfabric.com/sms/default_alphabet.html 和ASCII Code比較後，除了0123456789、A-Z、a-z，和%$!*& ' ' 相同外，其他都不一樣。
8 bits encoding：最多可以包含140 個字。通常用作非文字SMS，而拿來當作Data傳輸使用。
16 bit encoding：最多只可以有 70 個'字'，是用來傳送Unicode text messages。可以當作文字讀取。

另外，還規範傳送的方式(Mode)：

Text Mode
Pdu Mode

PDU (Protocol Description Unit)

PDU封包中，除了內文外，還包含其他的information，像是：

Sender
SMS service center
time stamp

傳送的data是以"hexa-decimal" or "decimal semi-octents"。

這個encoding有點麻煩，採用7 bit encoding是為了減少資料量。所以一個「字」就佔不滿一個byte，多的bit，就拿下一個「字」的bit，拿法是：

從下一個「字」中，從後算起，還沒被拿走的bit 拿起。

這一篇文章，有很好的示範.. http://www.dreamfabric.com/sms/hello.html

OLPC Hacking Meet-up心得

2007-06-29T23:18:00.000+08:00

經過十天的等待，於於完成了這次「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和社群。

親手打造Tablet / WebPad

2007-06-28T02:44:00.000+08:00

從事嵌入式系統開發，很大層面就是想體會「親手打造」的成就感。以往最大的問題就是進入的門檻較高，不僅得有開發硬體，還得要耗費大量的時間進行驗證測試，然而，這些繁瑣的過程會讓我們失焦，是的，最重要的部份，還是賦予硬體生命的軟體，這才是具備長遠價值的產物，一旦有了足夠的經驗與系統軟體，要在相容的硬體移植或加強功能設計，那就如魚得水了。

之前選定一個用以「練功」的題目「構想：Embedded Linux + Mozilla」，作法可有很多種，不過筆者嘗試以系統模擬的途徑，驗證「視覺化系統模擬與偵錯」一文中提出的概念：引入針對嵌入式裝置的基礎建設，作以system prototype、進階分析，以及快速軟體開發之用。上個月則於討論群組提出具體的想法「RFC: Tablet/WebPad 參考設計」，目前已稍有成果，在Google Code Hosting上申請了新專案「mind - MIND stands for "Mind Is Not a Device"」，可透過OpenEmbedded的迷你子集合去建構整個Embedded Linux作業系統，並調整為Tablet / WebPad的系統組態，以Xscale與x86作為參考開發的硬體平台，本階段已可使用Qemu為基礎的系統模擬進行驗證 (GNU Toolchain、Emulator，與Debugger均移植到Win32)，以下是運作中的展示畫面：

這呈現了我們Embedded Linux平台的應用程式，即精簡版的Mozilla web browser，輔以XUL打造進階的使用者介面。這個系統主要是作概念性呈現，所以其他應用程式則相對單純，程式主畫面如下：
待作事項：

針對ARM平台規範新的虛擬硬體組態，加入Wifi / Bluetooth裝置模擬
加入網路管理程式，如Linetconf
透過內建的OProfile進行深入的效能調校
提供x86 LiveCD

在Ubuntu / Debian上啟動kqemu加速OLPC的執行

2007-06-27T00:09:00.000+08:00

Mat 已經寫了一篇簡單的文件「Hello World for OLPC」，只要照著做就可以很容易的把 OLPC 利用 qemu 模擬跑起來了。不過如果可以先把kqemu的kernel module裝起來的話，那麼執行OLPC的模擬會更加的快速順暢。以下簡單介紹Debian/Ubuntu上啟動kqemu的方法：

1. 首先把相關的套件裝好

# sudo aptitude install module-assistant

2. 然後利用module-assistant編譯出kqemu的kernel module並且安裝到系統中

# sudo module-assistant auto-install kqemu-source

3. 最後載入模組並建立裝置節點

# sudo modprobe kqemu major=250
# sudo mknod /dev/kqemu c 250 0
# sudo chmod 666 /dev/kqemu

然後就可以照著Mat寫的文件跟著做即可。

另外~ 目前OLPC底層的作業系統是Fedora Core 6 (zod)，所以啦，知道FC6怎麼玩的，基本上OLPC也是一樣地玩。

模擬Linux on Palm 5

2007-06-25T02:41:00.000+08:00

Palm產品家族自第五代開始，部份採用Intel Xscale處理器，日前qemu的CVS tree也正式納入支援，於是熱血的hackers又開始鑽研是否可模擬Palm 5的硬體，並在其上運作Linux。在一番嘗試後，Alex很高興跟大家宣佈這個訊息，請見「Testing Linux4Palm on qemu」一文。他在 Hack&Dev計畫 (目標即是將Linux移植到原本運作PalmOS的硬體環境) 的程式碼加入以qemu為基礎的Palm 5的硬體模擬器，目前支援的硬體列表如下：

palmtc - Palm Tungsten|C (PXA255)
palmz72 - Palm Zire72 (PXA270)
palmtx - Palm TX (PXA270)
palmld - Palm LifeDrive (PXA270)

取得與編譯方式如下：

# svn co https://hackndev.svn.sourceforge.net/svnroot/hackndev/qemu/trunk qemu-hnd
# cd qemu-hnd
# ./configure --target-list=arm-softmmu --cc=gcc-3.4
# make -j2

預先取得必要的核心與檔案系統影像檔，假設解開壓縮檔後位於./palm/0.0.3-fnw目錄，則可透過以下方式執行： (其中一個hardware model)

$ cat RUN.sh
#!/bin/sh
BASE_DIR=`pwd`/palm/0.0.3-fnw
./arm-softmmu/qemu-system-arm \
-M palmld \
-kernel $BASE_DIR/zImage \
-sd $BASE_DIR/Angstrom-opie-image-palmld-0.0.3-alpha.rootfs.ext2 \
-append "root=/dev/mmcblk0 psplash=false"

啟動畫面如下：
過程中可透過qemu作LCD panel與終端機顯示 (serial) 的切換，也就是 Ctrl-Alt-[13]。以下是終端機操作畫面：
系統模擬越來越多元了。

Hello World for OLPC

2007-06-21T00:31:00.000+08:00

許多朋友好奇前天的螢幕快照怎麼來的，其實過程並沒有想像中的那麼難。小弟就以作一個Hello World的程式作範例。

在開始之前，先假設你手邊已俱備下列幾個主要的工具：

QEMU i386 ( OLPC的平台是x86 )

操作步驟如下：

1. 首先取得OLPC的映像檔：按這裡下載

2. 啟動qemu

qemu -redir tcp:2222::22 olpc-redhat-stream-development-devel_ext3.img

其中 "-redir tcp:2222::22"的意思是將 QEMU中的OLPC的:22 Port和本機端的:2222 Port接在一起。

3. 取得終端機

進入到OLPC視窗環境後，在OLPC的模擬環境按 “Ctrl-Alt-3”，就會進到console模式（要回到視窗模式請按 “Ctrl-Alt-1” ）。接著用root登入（預設沒有密碼），就可以順利取得root console。記得順便設定一下root的密碼。

4. 下一步?

根據官網上的說明，下一步應該就可以直接連線進去，但是實際上卻不行，為什麼呢?因為這時候的OLPC還沒有將網路啟動，需要先設定網路才行。

5. 設定網路

在root console下執行

ifup eth0

或是

echo ifup eth0 >> /etc/rc.local

設成下次自動啟動

6. 確定啟動sshd

/etc/init.d/sshd start

執行到這裡，我們已經有能力可以連線到QEMU中的OLPC了。

7. 連線到OLPC

ssh -X -o NoHostAuthenticationForLocalhost=yes -p 2222 root@localhost

其中 "-X" 是設定視窗轉送的參數。（可以執行xterm看看，所產生的視窗會將送到本機端來）。進行到這裡，我們已經有操控整個OLPC系統的能力，可以像使用一般Linux的方式去使用。

8. 如何作一個最簡單的Hello World?

目前OLPC並沒有內建gcc等開發工具。不過uname一下，可以發現OLPC的平台是i686。也就是說，我們可以先在本機端開發好程式，編譯好了再上傳執行即可。

而在OLPC裡的視窗程式執行環境為gtk、pygtk。我們不妨利用現在的pygtk來作為試驗。在這裡我們就直接引用pygtk給的官方範例。

9. 如何上傳?

最直接的方式就是透過scp的方式上傳。

scp -o NoHostAuthenticationForLocalhost=yes -P 2222 ./helloworld.py \ root@localhost:/home/olpc/hello_world.py

10. 如何執行：

由於OLPC的XWindow是用olpc這個使用者的身份執行。所以在執行前記得切換成olpc這個使用者

su - olpc

之後用視窗轉送的方式來執行

DISPLAY=:0.0 ./helloworld.py

就可以看到簡單的Hello World的畫面了

多國語言支援的圖形化kboot

2007-06-20T14:41:00.000+08:00

上週二 (Jun 12) 在TOSSUG聚會活動「2007 年第 7 場心得分享 - 組字的核心：字的結構」時，展示「Xorz/Embedded的動態組字實做」並提及可能的應用形式，我舉了關於boot loader的例子，作為說明動態組字技術在嵌入式系統的重要性。的確，隨著虛擬化技術與能源管理技術的突破，boot loader越來越多元，針對前者，得配合virtualization executive做出不同的啟動程序，而對後者來說，動態進階能源管理所建立的「中間資訊」(suspend to RAM / suspend to Disk)，也需要作合理的處理，這都需要高度彈性的boot loader涉入。另外，我們可從DSLinux (port Linux to the Nintendo DS gaming console) 與PS3 Linux (SONY PlayStation 3的Linux移植) 等計畫發現，其移植的途徑不同以往，而是大膽採用kboot/kexec的機制來降低移植的難度，並提供多樣的應用方式，詳情可參考之前的文章「kboot初探與模擬驗證」。

早上在hack OLPC時，又想到上述議題，所以我決定作個概念性驗證的實做，驗證kboot這個「功能強大的Linux boot loader」對OLPC的影響。以往的boot loader雖然實做了圖形介面，但功能是很侷限的，頂多只能產生靜態選單與底圖，筆者的想法就是，用一個簡單的圖形系統取而代之，提供真正有彈性的使用者互動機制，而我們有Xorz/Embedded。另外一個議題是，我們應該允許不同的開機方式，比方說透過網路或USB隨身碟，而且可在任何時間切換，使用情境很直覺，可以假設一開始運作缺乏中文系統的OLPC預設Sugar UI，等有需要的時候，插入USB隨身碟，系統會彈出一個boot畫面，提示使用者是否要重新開機，因為透過kexec系統呼叫，這一切將會非常快速 (跳過BIOS與硬體初始化)，而USB隨身碟上面的系統當然就可以有中文或者其他客制化的環境。

同時，筆者也想藉此彰顯在「組字技術與手持式裝置的新機會」一文表達的想法，為何我們千方百計想把CJK (中日韓) 語文整合到嵌入式系統設計呢？或許我們會犧牲美觀，但是可帶來對於多國語文最基本的顯示能力，這大可整合到boot loader或kernel中。聽起來很玄，俗語說：「一圖勝千言」，看看現在的進度：
以上呈現的想法就是動態讀取裝置列表 (透過udev與FreeDesktop HAL)，讓OLPC的軟體建設得以作基本的probing處理，進而在小型的圖形環境中產生對應的動態選單與動作描述。圖片展示了讀取USB Disk，並取出其中的中文標籤，以選單方式讓使用者決定系統的啟動與否，甚至，我們可透過網路來啟動或更新整個OLPC，這一切將可相當有彈性。

附帶一提，右下角的圖示就是「OrzLab的吉祥物」：「囧囧」，正準備跳出傳統的PC，走向多種嵌入式系統裝置的新應用。

OLPC Hack Meet-Up Day

2007-06-20T12:19:00.000+08:00

Mat稍早寫了「PCManX on OLPC」一文，提到他最近對OLPC所作的修改，並試圖移植知名的BBS連線程式PCManX到該平台上，不過礙於OLPC底層未能提供足夠的基礎建設，所以Mat發起一個活動「OLPCHackMeetUp」，邀請更多同好齊聚hacking。以下引述介紹文字：

== 活動宗旨 ==
國際知名的OLPC（One Latop Per Child，百元電腦）計劃正在進行，硬體製造的業務也由國內的廣達代工。然而國內社群對OLPC相關的知識並不多，軟體方面也參與的很少。因此希望能藉著發起這個活動，引介自由軟體愛好者實際參與OLPC的軟體開發，同時能互相交流軟體開發的經驗和心得，並以開放的方式回饋給OLPC計劃與自由軟體社群。
== 活動目標 ==
在目標的選定上，我們希望能以一個近程目標來秀出我們的特有的特色軟體。於是我們選定開放的BBS軟體PCManX作為目標，同時也希望能在實作過程中，找出OLPC的中文支援的方法：
將PCManX放進OLPC環境執行，並調整成符合Sugar (OLPC的外觀風格) 的應用程式風格
實作glibc locale + Fontconfig data + TTF + SCIM以提供中文顯示、輸入環境

時間預定於June 28, 2007 (四)，晚間19:00~22:00舉辦，歡迎參與OrzLab的討論「OLPC Hack Meet-Up Day」。至少有以下議題需要思考：

輸入法的型態：傳統的GTK+ IM module或Ajax web IM
OLPC的軟體開發方式與模擬器的整合
底層i18/L10n基礎建設

期待您的參與及指教！

PCManX on OLPC

2007-06-18T03:46:00.000+08:00

感謝jollen前輩的幫忙，讓我有進一步接觸OLPC（傳說中的百元電腦）的機會。

去年年底時就聽了好幾次OLPC的新聞，能真的用到實品，興奮之情真是難以言喻。期待歸期待，真實世界的OLPC用起來感覺倒還不是很順暢。可能是裡頭的軟體版本還沒跟到最新版，或是還不夠成熟，沒有完全發揮硬體完全的效能的原因吧。

想要更新到最新的版本，然而手邊又沒有工具也是沒輒。幸好，拜模擬器之賜，軟體的開發不再死死侷限在硬體上。

OLPC的組織已經有提供好相關的軟體模擬環境和開發工具，讓參與者即使沒有機器也能進行軟體測試與開發的工作。其相關的聯結如下：

Emulating the XO/Help and tips

幸運的是，OLPC的本質就是Linux系統，只有表面的介面看起來不太一樣，其他的系統設定跟程式環境都一樣。只要拿到OLPC裡的super-user，理論上幾乎可以作到任何在Linux上的事。

「理論上？！」

我們總是需要作一些嘗試來堅定我們的信念。
BBS可說是咱在地特有的文化，適逢(Open-) PCMan於日前釋出2007的最新版本。何不移稙一個BBS軟體到OLPC上呢？經過幾天的嘗試，終於有了初步的成果如下：

kboot初探與模擬驗證

2007-06-16T20:11:00.000+08:00

kboot本質上是個小型Linux作業系統，但功能卻是個boot loader，何解？kboot本身提供簡單的系統工具，支援檔案與網路操作，可自外界取得kernel image或其他檔案，進而kboot利用了kexec的機制，讓Linux kernel可快速重新啟動，於是具備boot loader的功能。

kexec是一組新的系統呼叫，包含在2.6 kernel中 (視支援架構而定)，搭配其user-space的工具kexec-tools，則可在既有的Linux kernel (支援kexec系統呼叫) 中載入其他的kernel (不需要有kexec支援)，並給予必要之參數或檔案，如kernel command line與initrd等，這方面的資訊可參考以下文章：

使用 kexec 快速重啟 Linux (DeveloperWorks)
kexec (LWN)

目前，kexec的硬體支援不限定x86，包含ARM與PPC都已有patch現身。那麼，如此的機制到底有什麼價值呢？以往的boot程序是很單純，清一色就是boot loader載入kernel，然後跳到user-mode或者是特定的工作，但現在的系統設計往往不是單一硬體、單一架構就可勝任的，諸如RAID或高負載的備援系統設計，都需要相當繁複的規劃，很顯然就非普通的boot loader可以應付，也很難修改Etherboot去圓滿符合需求，這時候，我們聯想到Linux，搭配到上述的kexec，不就是最美妙的boot loader嗎？在載入新的kernel之前，我們可作任何Linux能做的事情，像是載入firmware並進行設定、掛載NFS、掛載NTFS (透過Linux-NTFS)、... 等等，只要能提供新kernel給kexec-tools工具作載入，最後再透過kexec系統呼叫，就可完成這個「功能強大的boot loader」的終極任務。

kboot就是這樣的概念驗證實做品，使用的情境相當多元。舉例來說，kboot想進行遠端開機 (Diskless)，但只有Wireless LAN或3G network可用，這時候就掛載對應的kernel module (包附在kboot中)，然後透過user-space的應用程式進行設定，等待連線建立並確保檔案擷取成功，接著就在裝置上執行自遠端取得核心。另一種情境也很有趣，以往Linux distribution都得作通用性與最佳化的妥協，前者往往得將系統劃分諸多核心模組與大量的設定程式，後者往往得針對硬體作多次嘗試，那麼，透過kboot可先啟動generic kernel，然後進行硬體偵測，參考所需的硬體與最佳化組態，重新編譯核心，最後將該核心載入，而這個過程可透過一些設計得當的效能評估工具，一次又一次的重複自動微調，有別於以往的boot loader。關於kboot的應用，可參考以下簡報：

kboot - A Boot Loader Based on Kexec (kboot作者提供的slides)
於Linux Conference AU的演講錄影
HTTP-FUSE PS3 Linux : an internet boot framework with kboot (PS3 Linux hackers)

後者給予我們極大的想像空間，當我們在新的硬體進行核心與週邊移植時，的確可先把能運作的最低限度核心置入kboot，然後再從不同的開發分支取得新核心並啟動，而這些過程都是透明的，而且不需要燒錄到傳統儲存裝置中，只要資源允許，可在RAM中做到繁瑣的事情。

昨天做了一個小hack，將原本的kboot (Version 11) 進行調整，更動紀錄如下：

Enhancements:
. Provided qemu specific configurations for verifying kboot
. Enable Visibility for gcc-3.4 (symbol hidden)
. Perform size optimizations against user-space packages.
Upgraded:
. kernel - 2.6.21
. binutils - 2.17.50.0.16
. uClibc - 0.9.29

我們甚至不需要單獨的x86機器，就能測試kexec與kboot，只要有能夠運作Qemu的環境即可。首先，取得OrzLab修改的版本：kboot-11-orzlab.tar.bz2，解開後直接打 "make" 就會建構整個系統，包含下載必要的套件、工具，以及編譯與安裝等。搭載於kboot的Linux kernel是精簡的版本，只提供TCP/IP stack、procfs、initrd/initramfs、ne2k NIC driver、VESA VGA framebuffer console等，但足以讓我們作許多應用。

Qemu提供DHCP與TFTP server的模擬，完全省下我們佈署的難度，所以在模擬環境中，所需的操作甚至大幅少於實體。筆者提供了簡單的script名為 "qemu-launcher.sh"，直接執行即可，kboot啟動後的畫面如下：
依據Qemu的操作文件，預設透過模擬的DHCP server取得的IP是10.0.2.15，而server自己則是10.0.2.2，上面的畫面展示kboot已經載入一個小型的Linux kernel並出現提示訊息，等待命令操作，我們可打一些指令如下：
看到kernel version 2.6.21與ping連線的狀況，除此之外，還有ssh/sshd可用，所以大可連線到某台server，重新編譯核心程式碼，然後放到某個網路伺服器上。接著我們就要來驗證kexec/kboot的功能。Qemu內建的TFTP server相當好用，直接對應於host上的目錄架構，而就Debian/Ubuntu來說，host的核心會在根目錄建立symbolic link，而vmlinuz與initrd.img就指向目前運作的核心與initrd。

於是，我們在模擬的環境只要下簡單的一行指令即可載入並重新啟動： (鍵入粗體字部份)

kboot: tftp://10.0.2.2/vmlinuz

然後我們會看到 "Start Kernel" 的字樣跳過，然後我們就在Qemu的模擬環境看到啟動目前host上的核心：
因為在之前提供的qemu啟動script中省略root file system的指派，所以會停在kernel panic的畫面，不過這也達到我們的目的，驗證kexec/kboot，有了這個便利的模擬測試環境，未來也可作不同的變化。

WebKit的Gtk+支援

2007-06-14T03:46:00.000+08:00

khtml是在KDE 2中，集合檔案檢視系統與網頁瀏覽器於一身的Konqueror內部主幹，是極為精美細膩的設計，如果說為一窺 KDE 技術最佳的進入點，那真是一點都不為過。由於khtml卓越的設計，很快就出現以khtml為基礎的網路瀏覽器專案，比方說運作於Qtopia (Core)之下的Konqueror/Embedded，而Apple Inc.也採納khtml，部分重新設計與最佳化就變成WebCore (MacOS X內建瀏覽器Safari的核心基礎建設)。而業界的應用也很廣泛，像是韓國嵌入式系統廠商Mizi Research就曾將Konqueror/Embedded經過一番調整，成為相當強悍的瀏覽器。

Apple Inc.提供了大量的修改，讓khtml的品質獲得極大的提昇，又在KDE開發者的斡旋下，Apple Inc.終於採納了社群開放發展的模式，於是KDE與Apple Inc.兩組開發人馬傾向共享WebKit的程式碼基礎 (codebase)。接著，Nokia也宣佈WebKit為基礎的S60WebKit (針對S60手機平台)與gtk+-webcore (針對Gtk+/X11環境)，並依循LGPL與BSD License的方式，將修改貢獻回WebKit專案。

WebKit在這三年內蓬勃發展，提供了許多不同軟硬體平台的移植，值得一提的是新出現的GDK (Gtk+的低階圖形處理部份) 移植，這意味著WebKit可運作於GDK支援的環境，就嵌入式系統來說，我們會關注linux-fb與DirectFB兩個Gtk+/GDK所支援的backend。在近半年來的發展，WebKit的Gtk+/GDK移植已到堪用的地步，針對Nokia770/Maemo與OpenMoko的硬體移植也出現成功案例。

為了降低建構WebKit/Gtk+的難度，我做了簡單的建構系統 (檔案：webkit-build-script.tar.bz2)，允許從Subversion取出最新的發展版本，並作必要的設定，最後進行編譯。下載並解開後，直接執行以下script：

# ./BUILD.sh

中間會透過apt-get取得必要的開發套件。建構完畢後，大致的執行畫面如下：
(1) wiki.openmoko.org
(2) Google Maps WebKit在OpenMoko GTA01也開始運作了，但還是有很多需要調整之處，這也是今年Google Summer of Code的項目之一，期待這方面的新進展。

從Chrasis談手寫辨識引擎在移動裝置的機會

2007-06-11T03:33:00.000+08:00

Gentoo Taiwan的Palatis日前公開他發展中的手寫辨識引擎與訓練程式，可參考blog文章「Chrasis 0.1.0 alpha!」，專案發展紀錄可參考「 Chrasis - Chinese Handwriting Recognition As-Is」，正如版本號所宣示的，現在還有很大的改進空間，不過已經初步可運作，以下是其訓練手寫辨識程式的執行畫面：
程式碼可透過Subversion存取：

# svn co svn://svn.berlios.de/chrasis/Engine/libchrasis/trunk libchrasis
# svn co svn://svn.berlios.de/chrasis/Linux/ChrasisTrainer/trunk ChrasisTrainer

libchrasis為手寫辨識引擎，其相依性有： (以Ubuntu 7.04為例)

libxml++2.6-dev
libsqlite3-dev
sqlite3
libboost-dev

ChrasisTrainer顧名思義就是訓練程式，以Gtk+打造，其相依性如下：

libgtkmm-2.4-dev
llibxml++-2.6-dev

測試了幾個簡單的中文字，都能正確辨識，算是不錯了。當然，手寫辨識的議題很複雜，以下是筆者在wiki - ChineseInformationProcessing的「手寫輸入」段落紀錄的部份資訊l：

Kanji Pad - Japanese Handwriting recognition http://www.gtk.org/~otaylor/kanjipad/
Kanji Pad 的新網頁 (演算法不變，新增 GTK2 的移植) http://fishsoup.net/software/kanjipad/
以下為 rabit 的個人見解 (Modified by User:jserv)：

KanjiPad 本身使用的辨識方法是很簡單的字典法，當使用者透過手寫版或滑鼠寫出字時，程式辨識出筆劃種類，並紀錄每個筆劃的順序，然後根據字典查出候選字。也因此，KanjiPad 根本不考慮寫出來的字形貌是否相似，只求筆劃順序相符。

以 Cinput (修改自 Kanji Pad) 的圖為例，「林」這個字辨識出來的候選字有「林、杯、枝、板、茂」，這幾個字右半邊的「木、不、支、反」筆劃順序都是跟「木」是相似的。這樣的演算法辨識率是不高的，一但筆順不對，就很難辨識出來，不過話說回來，也不能太苛求 KanjiPad，因為它原本的用途就是日本人寫來學習漢字用的，可以說本來就是當作字典使用。
中文手寫辨識是難度相當高的, 困難的地方有二：
就技術而言，在辨識方面會用到許多數學模型，如 Baysian Decision Theory hidden Markov models、類神經網路等，而辨識中文還必須對中文字作分析，找出每個中文字的特徵 (筆形、筆順等)，若要更精準，需拆解中文字成基本的部件，來作分析 (有點像漢字跡因工程)，這時就要處理寫字上連筆的問題，技術上有實現的複雜度，但或許還不是最困難的。
必須對每一個字的分析，建立資料庫，這是需要大量的成本 (包含時間、人力等)，中文字尤其複雜，除了大量的漢字，還有異體字、罕用字等，我想這對 open source 是最困難之處，這跟 open source license 中文字型的狀況有些類似。

看似這是NP-Hard的問題，但如果我們思考Mobile 2.0對我們的衝擊，可以發現，大多數的手持裝置都需要手寫、筆跡、觸碰軌跡辨識的技術，而且也依賴原本在桌面系統的軟體元件與操作習慣，此時，危機反而就是轉機。具體來說，我們可思考「新酷音」一類智慧型輸入法如何移植到手持式裝置如PDA或SmartPhone一類的裝置，基本上，運算速度與儲存裝置都不是大問題 (早在兩年前，「新酷音」輸入法系統就證明在某隻SmartPhone上正確運作)，真正的難題反而是輸入法的「輸入」本身。是的，以「新酷音」來說，支援兩種基本符號：

注音符號
拼音字母

這兩者背後也有學問，光是注音符號對照的鍵盤排列就可玩許多花樣，諸如許氏注音、倚天26鍵等等，拼音系統就不必多說，在台灣根本就是多頭馬車。以往，「新酷音」的開發者花了很大的心力去維護這些子系統的可用性與正確度，整合到libchewing (核心函式) 中，但如今要整合到手持式裝置，就面臨新問題：

「如何將傳統鍵盤的行為導入輸入法系統？」

我們首先會想到手寫辨識，就目前的系統來說，多半會內建OSK (On-Screen Keyboard)，所以「新酷音」理所當然可架構於OSK之上，不過這與我們中文打字者的思維有很大的落差。何以此說？試想，「新酷音」的中文簡介是什麼？就是「智慧型注音輸入法」，透過統計與預測方式，大幅降低同音字詞的出現率，進而改善注音輸入的速度，使用鍵盤只是一種過度，真正使用者腦海中的思維，仍是「注音」(或拼音）本身，所以，日前筆者也跟Palatis聊到一種新途徑：

「何不直接辨識注音符號，然後導入新酷音輸入法引擎去作猜字處理？」

這種技術難度對於Chrasis一類的簡化手寫辨識引擎來說，算是綽綽有餘，如果不討論太複雜的連寫與草寫議題的話。某種角度來說，這說明了Mobile 2.0的思維方式：「過去的桌面技術有機會走入移動裝置之中」與「打破過去封閉技術的藩籬，個人也得以貢獻新的技術元素到移動裝置設計」，如今，我們有完全開放程式碼並開放手機規格與實做的openmoko、有高效率的動態組字技術，以及最寶貴的資源，也就是富有高度創意的自由軟體開發者，其整體的影響將會很有趣，手持裝置才正要作更有意義的應用，咱們拭目以待。

Xorz/Embedded的動態組字實做

2007-06-11T00:12:00.000+08:00

之前的文章「Xorz/Embedded作為Phone UI」與「組字技術與手持式裝置的新機會」提到輕量級視窗圖形系統的實做進度，同時也思考組字技術帶來的新契機，無論是技術與實務規劃面來說，都還有很大的商議空間，但筆者認為這是必要的基礎建設。利用週末，終於在Xorz/Embedded實做出基本的中文動態組字功能，執行畫面如下：

以上展示「黃」(Unicode 0x9EC3)與其搭配不同組件 (部首) 的呈現方式。原本single.fnt (剎那單線體) 定義為：

!009EC300|黃0=0000162E0001F02E00005A1100015A5E0000A8110001A85F0000595F0001AC5F00000A5F0001F55F00003C7300013CCE00003D7B0001CA7B0001CACF00003B9E0001C99E00008066000180C1000062D6000242EB000116FA00009AD00002D0E50001DEF700003CC00001CAC0

又，考慮美觀，我從文鼎楷體轉出了stroked font，從而做了細部的調整，這方面還得與剎那搜尋工坊討論如何整合，但基本上組字的概念是可以延續的。「黈」這字在single.fnt是如此定義：

009EC800|黈0=黃0131272E1主0811078D9

相當明顯就是「黃」與「主」兩部件的左右結合，同理，「黌」則定義如下：

009ECC00|黌0=00D07E66B黃0156AD78A

改為上下部件的結合。當然，目前的實做還很陽春，但已經看得出效益，以目前的stroked font engine來說，只要先描述以上三個組件，如「黃」與「主」：

/* 0x9ec3 (黃) */
3, 66, 56, 0,
'm', 28, -36,
'2', 29, -36, 29, -36,
'2', 33, -37, 39, -37,
...

接著就採用single.fnt所定義的組字表示，去作遞迴表示即可，大幅省下儲存空間，也可避免許多維護成本，更重要的是，這一舉克服以往字型檔與程式碼不對稱的問題。除了中文動態組字外，其實Xorz/Embedded的繪字引擎也允許一些變化，比方說「Q版」的呈現，有點像是塗鴉文字，行文甚至有互相疊合的效果，這是為了配合某些特殊的應用，如廣告文字，所特別設計的系統，畢竟Xorz/Embedded一開始的定位就是針對嵌入式系統的特製輕量級圖形系統。

恰好TOSSUG在本週二也請到國內在動態組字學有專精的前輩，為我們分享中文缺字議題、動態組字技術，以及進行中的變革，詳情可參考「Tossug 2007 年第 7 場心得分享」，如果當天有空檔，或許筆者也可來作些介紹與展示。

build u-boot from sources

2007-06-01T11:53:00.000+08:00

因為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

完成。

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

2007-05-31T00:55:00.000+08:00

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

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

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

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

GSM modem裝置模擬

2007-05-30T17:27:00.000+08:00

系統模擬對於嵌入式系統開發來說，是相當重要的里程，不僅晶片層面如此，對於週邊來說，更可對應用程式開發帶來立即的效益，現在，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

2007-05-30T08:16:00.000+08:00

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.

GCC Visibility與軟體最佳化

2007-05-26T23:02:00.000+08:00

以前在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的架構仍有最佳化的空間。

OpenMoko演講影片上線

2007-05-25T01:09:00.000+08:00

在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

2007-05-25T01:07:00.000+08:00

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

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

很不幸的 4$ 改爛了設定檔，開了幾個 VLan，結果沒辦法透過無線或有線網路進入，把自己關在 AP 外面。因此週二帶了條傳輸線到 Tossug 聚會，幫忙進到 Console，並把相關的設定修正，以便讓他可以再 ssh 進 AP 裡。

根據 OpenWrt Kamikaze 的設定方式，我們只消更改 /etc/config/network與/etc/config/wireless檔案，開兩個WiFi Interfaces，一個作為STA，另一個作為AP，並將Ethernet port與STA wireless interface "bridge" 在一起。

改後檔案像這樣
/etc/config/wireless

config wifi-device  wifi0
     option type     atheros
     option channel  5
     option diversity 0
     option txantenna 1
     option rxantenna 1
#       option distance  2000
# disable radio to prevent an open ap after reflashing:
     option disabled 0

config wifi-iface
     option device   wifi0
     option network  wan
     option mode     sta
     option ssid     "WIFLY"
     option hidden   0
#       option txpower  15
#       option bgscan   enable
     option encryption none

config wifi-iface
     option device   wifi0
     option network  lan
     option mode     ap
     option ssid     "FON_AP"
     option hidden   0
     option encryption none

/etc/config/network


# Copyright (c) 2006 OpenWrt.org

config interface loopback
     option ifname   lo
     option proto    static
     option ipaddr   127.0.0.1
     option netmask  255.0.0.0

config interface lan
     option ifname   eth0
     option type     bridge
     option proto    static
     option ipaddr   192.168.1.1
     option netmask  255.255.255.0
     option gateway  ''
     option dns      ''
     option network  ath0

config interface wan
     option ifname ath1
     option proto dhcp

如此一來，你就可以一邊連上WIFLY，另外一方面以FON_AP將WIFIY提供的網際網路連線分享給其他人用啦。:-)

接下來要做的是應該是改一條USB Cable，讓La Fonera可以直接吃USB的電源。;-)

Credits:
設備 - FON Taiwan
軟體開發 - cclian, 4$, jserv
攝影 - psilotum

Source: http://people.debian.org.tw/~chihchun/2007/05/25/leverage-wifly-and-fon/

ARM模擬的狀態保存

2007-05-23T11:27:00.000+08:00

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

OpenMoko at Tossug

2007-05-21T16:28:00.001+08:00

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

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

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

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

Working on Neo1973

2007-05-21T16:26:00.000+08:00

這是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

2007-05-21T16:14:00.000+08:00

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

事後，有一些朋友詢問該如何購買或製作黑La Fonera一定會用到的Serial Port Cable。事實上，現在有好幾種方法可以進到La Fonera中，Stefans Datenbruch 針對不同版本提供了開啟ssh的數個方法 (Hacking the La Fonera) 。基本上，開啟ssh後，你大約可以進行reflash或各式各樣的惡搞。然而，偶爾你還是需要用到console，因為說不準什麼時候會搞壞，讓路由器再起不能。

要連上La Fonera的 Console，你需要的是TTL Converter，利用J2的Pinout，就可以進到console或redboot prompt 。cclien利用他自己的手機線路做一條TTL2Rs232的線路。他用的是DLR-3的傳輸線，現在大約不怎麼好買。

其實，如果看得懂電路圖，利用前輩做的線路圖，到市場場買顆MAX232或相容的chip，再加上其他一些配件，大約只花費6.72 €。但是像我這樣通常只用筆記型電腦的傢伙，若做了RS232接頭還得再找一條RS232轉USB的轉接頭來，這樣的花費大約也要5~10€。

最簡單的作法就是使用手機傳輸線了，例如支援Nokia手機的CA-42傳輸線，在Yahoo拍賣上大約是NT$ 90 ~ NT$ 200。它本身利用PL-2303或ARK3116將UART轉成USB，所以你要做的就是找到正確的Pinout即可。

我買過兩個版本的CA-42傳輸線，分別是用PL-2303或ARK3116的晶片，不同的版本顯然用的晶片不同，而線路顏色所代表的意義也不同，所以你或許得自己以電錶等工具摸索一番。你也可以依據腳位，知道每條線路的功能，可參考Nokia Pop-port pinout。根據我的經驗，近期可以在市場上買到的是ARK3116，這款的GND是紅色，RX是綠色，TX是白色。

你可以在電子材料行買到一些簡易的線材，稍加修剪後接上線路後即可。有了Serial Console，你就可以存取redboot, 並可試著把新的boot image/kernel image/rootfs燒進去。Happy hacking ;-)

本文發佈於 http://people.debian.org.tw/~chihchun/2007/05/17/cheapest-ttl2usb-converter-for-la-fonera/

EGLIBC初探

2007-05-21T14:52:00.000+08:00

在Embedded的環境下，我們有許多C Library的選擇，從BSD libc、uClibc、glibc、dietlibc，甚至是klibc (配合initramfs)，過去我們考量到footprint，往往會捨棄發展活躍的GNU C Library (glibc)，轉而以uClibc或dietlibc來建構系統，正如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 体验」

避免cross-compile的陷阱：libtool

2007-05-19T22:03:00.000+08:00

在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，又，這樣的套件或應用程式往往佔多數，耗費的時間也相當可觀。

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

2007-05-19T03:26:00.000+08:00

前幾篇文章介紹如何透過qemu來模擬openmoko與Poky，這部份的開發逐漸穩定，而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。

Install Poky from scratch

2007-05-14T15:48:00.000+08:00

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

2007-05-14T15:44:00.000+08:00

如果你想安裝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系統

2007-05-14T08:51:00.000+08:00

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進行套件的更新維護，畢竟我們感興趣的套件就那幾個而已。

SVK與嵌入式系統開發

2007-05-10T12:59:00.000+08:00

為什麼我們考慮要採用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 中需要安裝兩個套件：svk與libvcp-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實做

2007-05-10T11:27:00.000+08:00

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

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

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

TOSSUG心得分享：Free your phone! OpenMoko

2007-05-09T20:22:00.000+08:00

魔法設計師是位對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，只不過是給手機這種迷你電腦用的。

待續張貼者：魔法設計師 at 上午 5:40

DIET-PC的ARM移植

2007-05-07T21:41:00.000+08:00

注意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並沒有因此改用uClibc或dietlibc，而是採用GNU C Library與Xorg，保持PC上的相容性。DIET-PC的ARM移植版本所採用的參考硬體是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，整體來說，這是個很精巧的系統。

反組譯 OpenMoko Steppingstone Code

2007-05-06T22:06:00.000+08:00

在正式的內文之前，先來說個小故事。前一陣子在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的測試結果

2007-05-06T19:50:00.000+08:00

之前的文章「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如下：

arm-linux.tar.bz2 (toolchain)
okl4_release_1.4.1.1.tar.bz2 (OKL4 release)

在進行之前，我們來複習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，再來是Iguana與Kenge，最後就是Wombat，最後會跑完Linux booting flow，切入Linux user-space。對了，剛剛也試著用qemu去執行，但似乎會卡在igms0的處理。

Xorz/Embedded作為Phone UI

2007-05-02T01:18:00.000+08:00

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

最近又對Xorz/Embedded做了refactoring與改進，現在backend有SDL、X11，與Linux framebuffer。在週二晚上與OpenMoko的Sean Moss-Pultz & Harald Welte、Jollen、Chihchun等人聚會時，展示了最新的成果，以下是運作於Neo1973 GTA01的畫面：

關鍵技術有：向量繪圖、快速座標轉換、半透明處理、動態字型描繪、輕量級視窗管理等，近期內會開放實做，允許創造更多應用。同時也與Sean Moss-Pultz談及Linux-based feature phone的可能性，就技術上本身來說是可行的，而且他也給予正面回應。我想，如果這些基礎建設都穩固後，自身對GreenPhone、 gpephon與OpenMoko的設計有更好的掌握後，或許我可在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電子報對於黑客鬆的報導

2007-05-02T00:52:00.000+08:00

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

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

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

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

張貼者： Mike Tian-Jian Jiang at 下午 5:03

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

當Java遇到OpenMoko

2007-04-30T16:25:00.000+08:00

對許多人來說，openmoko真是個令人驚奇的平台，這不僅是個開放系統，而且也引入許多原生於桌面環境的技術，甫成立的GMAE (GNOME Mobile & Embedded Initiative) 就是個極佳的切入點。作為一個Free Java (VM) hacker，最大的樂趣就是廣泛讓Java技術散佈到世界上不同的角落，當然，也包含了openmoko，考量到openmoko的行為模式比較類似桌面系統，而非傳統的CDC/CLDC執行環境，所以我選擇了Kaffe與Cacao這兩個以GNU GPL發佈的Java Virtual Machine實做，這兩者都以GNU Classpath作為Class Library實做，所以有不錯的相容度。

經過一番努力，Kaffe與Cacao這兩個Free JVM都可在openmoko上運作，而我則對後者予以很大的關注，因為其ARM jit engine日前已經以GPL釋出，而且Cacao這兩年內的效能提昇幅度相當不錯。我在Planet Classpath寫了一篇紀錄「Cacao VM running on openmoko」，節錄如下：

Then, back to Free Java world, I met several hackers around the world in #kaffe, #classpath, and #cacao IRC channel. Since I had portd Kaffe to Xscale-based mobile phones, I decide to take Cacao for a try. After some slight modifications (with the help from twisti), Cacao works on OpenMoko GTA01, and here is the output for typical "Hello World" application in Java:

root@fic-gta01:/var/tmp/cacao$ ls *.class
fp.class     hello.class
root@fic-gta01:/var/tmp/cacao$ cd bin
root@fic-gta01:/var/tmp/cacao/bin$ ./cacao -cp .. hello
Hello world
root@fic-gta01:/var/tmp/cacao/bin$ uname -a
Linux fic-gta01 2.6.20.7-moko8 #1 PREEMPT Sat Apr 14
07:40:05 UTC 2007 armv4tl unknown

It is based on Cacao SVN (along with GPL'd ARM jit engine) + GNU Classpath version 0.95. However, I still manage to let gtk-peer work on Cacao inside GTA01 device. But I am of the opinion that it is really a good start point for joint of the power from Free Java (GNU Classpath, Cacao, Kaffe, etc.), OpenMoko, and Embedded Linux.

Also, I met guillaum1 in #cacao, who is the developer of MIDPath, and he suggested me to try the combination of cacao-cldc (cacao without GNU Classpath) + MIDPath. The design of MIDPath is very flexible, and it allows to have MIDP2 working on top of cacao-cldc (without Classpath) or standard cacao (i.e with Classpath). I will do that later.

很快收到許多回應：

Mark Wielaard的blog「OpenMoko free java support with GNU Classpath & Cacao」
Dalibor Topic的blog「All in a day's work」
openmoko-app討論群組「Cacao jvm on openmoko 」

當然，這只是個出發點，可說是銜接桌面技術到OpenMoko這類裝置的概念驗證，我仍在評估Sun的PhoneME (逐漸以GNU GPL釋出) 的整合性，同時也希望AWT/Swing仍可「有限度」使用。

Have fun with OpenMoko/Neo1973

2007-04-30T16:02:00.000+08:00

chihchun今天早上寫了一篇關於OpenMoko/Neo1973的blog文章「Have fun with OpenMoko/Neo1973」，取得同意轉載如下：

自從我寫了「I Want A Personalized Phone」後，就持續注意TuxPhone、GreenPhone、OpenEZX、 gpephon的消息。當然還包含了OpenMoko，OpenMoko是真的令人興奮的計畫，因為除了此計畫是真實使用自由軟體的開發平台，而非採用多授權或非商業授權的平台產品外：也完全採用有GPL驅動程式的硬體元件，如「挑選 WiFi 模組」。而且OpenMoko與FIC的合作模式使量產上市變成可能，你不需要逐一的「自行 DIY」，大幅降低自訂軟體的門檻。

話說Jserv是周遭朋友第一個拿到Neo1973的人，當然要跟他凹來把玩一番，於是就在4/14 OSDC結束後的晚上，把Jserv拉到Mix coffee & tee進行了一場小型的 BoF。

目前FIC/Neo1973的硬體功能是：

120.7 x 62 x 18.5 (mm)
2.8" VGA (480×640) TFT Screen
Samsung s3c2410 SoC @ 266 MHz
Global Locate AGPS chip
Ti GPRS (2.5G not EDGE)
Unpowered USB 1.1
Touchscreen
micro-sd slot
2.5mm audio jack
2 additional buttons
1200 mAh battery (charged over USB)
128 MB SDRAM
64 MB NAND Flash
Bluetooth (2.0)

OpenMoko的wiki網站上有著驚人豐富的資訊，甚至連如何拆解機器的步驟都詳實記載，依照站上的資訊逐一進行，很快的就一步一步的把機器拆開，順道也reflash一下最新版的kernel與rootfs，感興趣的話請參考我倒出來的一些資訊： ipkg list,dmesg,cpuinfo。但顯然硬體與應用軟體尚有許多項目待完成，急需開發者的參與。

有意思的是 Gnome 基金會在幾天前於Embedded Linux Conference上宣佈 GMAE 計畫 (Gnome Mobile & Embedded Initiative)，引起產業與社群的極大迴響。忠實希望與期待可以在此平台上，建立一個共用的開放嵌入式系統應用軟體架構。

在此感謝Jserv借玩手機 (照片男方是Jserv，女方為不知名，但Jserv很願意主動搭訕認識的女生。~~其實我也很願意認識，啊！只要是女生我都願意認識~~)。週末很榮幸的與Sean Moss-Pultz、 Harald Welte、Jserv、Jollen與大眾電腦的幾位長輩/前輩們聚餐，收穫甚多。Jollen在自己的的 blog上撰寫了相當深入的OpenMoko報導與嵌入式系統的開發知識，值得一讀。現在只希望我能夠拿到下一波生產的手機，這樣才有機會 happy hacking。

BTW，我正在安排Sean與Harald於Tossug聚會上提供演講，Sean Moss-Pultz是OpenMoko的產品經理，而Harald Welte是OpenMoko首席軟體架構師，也是Netfilter/iptables的開發者，同時也是gpl-violations.org的創辦人。如對此聚會感興趣，請告知我吧。:-)

OrzLab的吉祥物

2007-04-20T02:56:00.000+08:00

OrzLab很多資源都仰賴於社群，不僅軟硬體建設，連同美工亦然。之前已有眾多「OrzLab的圖示」，作為應用程式的logo或開機的圖片使用，算是相當充分了，但缺少吉祥物。在「構想：Embedded Linux + Mozilla」一文提到與Mozilla Taiwan的朋友互動，會談當日，KKFox作者C.H.Weng的女友LitGrass就在聚會討論中，悄悄繪製出一系列可愛的造型，爾後lzy將手繪版本透過inkscape轉換為向量圖，現在我們的吉祥物大致如下圖：
維基百科的Orz條目給予許多精闢的說明，那麼，姑且稱這個由Grass貢獻的這個可愛的吉祥物為「囧囧」(讀音：「炯炯」)。雖然OrzLab是探討軟硬體整合與系統設計的實驗室，但真正的標的環境是生活化的種種資訊裝置，如PDA、手機、Home Gateway、... 等，上圖可看出"Orz"走出電腦，試圖朝向更多元的領域發展，很不錯 :-)

參考資訊：ckhung - 「向量繪圖軟體 inkscape 簡介」

OrzLab::黑客鬆紀錄

2007-04-20T00:19:00.000+08:00

以下轉錄自cclien的紀錄「台北行: 台灣黑客鬆」，以輕鬆的口吻介紹OrzLab成員4/12-4/13兩日於黑客鬆的參與活動內容：

亂入

在 hackathon 舉辦的前兩天，意外知道 Jserv 將在這次 hackathon 活動中以 La Fonera 當作 ajax/embedded 的平台。由於之前拆 La Fonera 拆到有興趣，於是狗膽請 Jserv 邀請我一起參加 Hackathon。就在這樣的臨時決定下，趕緊把行李打包上台北。

迷路

搭上十一點從台中出發往台北的巴士，如預期的一點整到達台北市。坐上捷運，到了會場附近，肚子咕嚕咕嚕的叫，只好先隨便找了一間 Mos 坐進去，填飽肚子先。剛好我忘記把地圖存檔，靠著漢堡店附近的好鄰居無線網路上了網查地圖，吃飽後直接往南海藝廊移動。

南海藝廊

到了活動網頁所示的地址-南海藝廊，是一間看起來像古早平房的建築物，一度還以為是走錯地方。後來看到二樓陽台上有穿著白色短T的阿宅(?!)，才確定我沒走錯路阿。到了會場，已經有很多長輩到了，擺滿貼滿貼紙 laptop 的桌子充滿了 hacker 的味道。

認親

因為不太熟悉與會的長輩，所以在放下行李之後，就在活動地點亂晃。晃來晃去，終於等到了四元大大 (雖然也是素未謀面，但至少有在網路上聊過天)，聽完 mikimoto 爆料 talk 之後, ajax/embedded team 的成員: Jserv 大牛、Mat 紛紛到齊。

開工

在成員到期之後，變馬上開始動工，先把 La Fonera 大卸八塊準備連接 serial console，結果馬上中招。我帶了一條傳輸線，但是只有 RS232 接頭，大家的 laptop 都太新了，沒有人的機器上面有 rs232 的接頭，後來 fourdollar 大大終於生了一條 USB to RS232 出來。打開了 sshd 之後，便把 Fonera 接到一台 hub 上，此 Lan 就當作 hacking Fonera 專用的 Lan 啦。

又中招

Jserv 事前準備了一份 toolchain，編了一隻小程式之後馬上丟到 Fonera 試試看，怎麼跑都跑不起來，突然想到這個招我之前也中過。利用 file 工具看一下生出來的 binary，啊哈!果然是 LSB 的問題。大部分 openwrt 的硬體都是 mipsel (MIPS, Little Endian) 的架構，使用 Atheros chip 的 Fonera 就是跟人家不太一樣，是使用 MSB。再來就是 build 程式 build 到死,不過等待時也不會閒著，因為旁邊有 opcafe 提供的美味餐點。

氣氛

正當我還在跟 toolchain 奮鬥時，隔壁桌 RoR 組的劉燈突然興奮的大喊了一聲 "works!"，哈，突然回憶起以前跟砲王、朱立三個人關在一起趕專題的時光阿，原來數年前我們就進行過一個小小 Hackathon 了！Working hard 的時間總是過的特別快，不知不覺就到了七點多，一行人到建中附近吃了還蠻實惠的晚餐後，繼續回南海藝廊奮戰。

效率

光 build 一個 lighttpd 到 mips 平台上就花了我不少時間，lighttpd 雖然對 server 來說是 light，但是在 embedded 系統上仍屬於大噸位的程式，後來大家討論之後的結論是把 lighttpd 把整個 ajax/embedded 中抽離，推翻舊架構只在幾小時之中，Hackathon 的效率果然驚人！原本預定九點半就結束的活動，一直拖到十點大家才心甘情願的離開。

結束活動之後，馬上搭上捷運往小強的宿舍奔去，原來政大有單人房的宿舍耶，真高級。

Day2: working working working

我真的忘了第二天我在幹嘛，就是一直改 code、bulild、查資料、中招.. blahblah，表示真的有融入，所以啥都忘了？所幸有帶了相機，所以我還記得我中午吃了牛排 XD；背包裡的 google 紀念品，提醒我我留了 E-mail address 給 google 的 HR 大嬸。

就這樣，不知不覺就到了活動結束的時間，移往師大附近的 morelax 吃晚餐，由於一次湧入的鄉民太多，對吧台造成了 DOS ，所以在我吃完了我覺得等很久的晚餐之後，四元大大還在那邊餓肚子，哈。吃飯時跟 Ingy 聊了一下天，原來他也喜歡騎機車，在美國有一台 Ducati Monster。

總結

感謝辛苦主辦 Hackathon 的大大們，讓我有這次機會跟高手們一起窩在一個小房間，為了同一個目標一起 hacking，好久沒有這麼熱血了，真爽。希望之後還能有這種活動，如果時間更長就最好了(希望到時候我還有空參加)。

Link: 活動時拍的照片

OSDC.TW 二三事

2007-04-19T11:48:00.000+08:00

4/14-4/15兩天的OSDC.TW活動終於結束了。

OSDC.TW 2007 終於結束了，這幾天陸續看了魔法設計師、BlueCat、leoth、Yuren和一些相關的部落格後，覺得自己也該寫篇心得和大家分享一下這次的活動心得。

今年是第一次參加這麼大型的活動，個人感覺是相當新鮮的回憶。相較以往參加的活動，OSDC.TW所聚集的人氣相當旺。這次活動還吸引了許多國外知名的Developer遠道前來共襄勝舉。演講內容的深度和廣度都很棒。

這兩天聽到的講席有：

jserv - RT Nanokernel for Embedded Linux
Audrey Tang - Jifty
clkao - svk: version control without the headaches then pushmi
Shu-Chun Weng - The Value of Everything But the Cost of Nothing -- a Tutorial to Haskell
Marek Lindner - Wireless Meshing - the future of infrastructuring
Macpaul Lin - Porta2030
MGdesigner - 2D fonts generator
Lightening talk

一個議程約莫是80分鐘左右，所以講者所準備的題材大多是以介紹概念和展示為主。最大的收獲無非就是能一睹傳說中的Developer的風采，甚至有機會能和長輩面對面聊天。

RT nanokernel這個場當然一定要先捧一下。每次聽jserv的演講都有幾個不錯的地方，除了都會有令人XD的笑話，另外就是一定會有Orz的Demo。 jserv戰鬥力真驚人，前一天還在CodeJam衝鋒陷陣，隔天還能馬上就準備好質量俱佳的報告。

生平第一次見到傳說中，被喻為「台灣電腦十大高手」的AudreyT，台風穩健，人看起來也非常有氣質。整個Talk的內容非常流暢，一個步驟接一個步驟的解說如何用Jifty來作出doxory這樣的網站。能用程式碼為主的內容作投影片，作簡短扼要的解說，還能保持內容的趣味，真的非常厲害。

第一次見到clkao是前一天在多鬆和參加CodeJam的人吃飯時看到的，他比我想像中的還要親切許多。在當天的議程，他即介紹他著手寫SVK的源點和過程，還有一些設計理念。 svk我用得不久，大約才一個月的光景，然而svk所帶來的便利，已經成為「日常生活」中不可或缺的一部分。而clkao他可以為了寫一個程式，空出整整一年的時間去Cook它 (而且也只花一年)，真是令人佩服不已。

Shu-Chun Weng的Talk是介紹Haskell，一個我完全沒有聽過的程式語言。短時間內要接受新的語言概念，對我來說還是太難。聽到一半我就聽不懂了，感覺這東西用來作計算的功能似乎不錯。

Marek Lindner和Macpaul Lin則是介紹行動Wireless的概念。也就是利用AP和AP互聯，以建立網路通訊。 Marek用簡單的觀念來介紹這個架構的原理，而這個領域其實很難，應用非常廣。我們國內前陣子TOSSUG社群發起像Porta2030這樣的Project來玩這些東西。最有趣的是Marek所秀出的他們在柏林市Wireless AP之間連線圖，感覺真的非常棒。而Macpaul就是接著介紹和展示一些Porta2030的一些成果，還帶了很炫的Porta2030的衣服，相當有趣。

MGdesigner的Talk是關於漢字顯示的最新技術，在此之前就聽過他的演講，印象相當深刻。用組字的方式來顯示漢字，每一個人多多少少都想過。然而這個想法一直沒辦法落實到整個資訊系統上。今天這個成果被開發出來，而且能開放專利並用自由軟體的來發展。對整個文字文化的影響非常深遠。連閩南語暨客家語輸入法的開發者Arne Goetje(高盛華) 也自百忙中抽空來聆聽，可見得其重要性。

Lightening Talk大概這次大會裡最活潑的節目了，自由報名，每個表演限時七分鐘。每個上台的人得在這個時間內把要講的內容講完，否則就會被主持人殘酷的搶走麥克風了。很酷炫的東西像是可以計算筆電傾斜度來操縱玩具大炮，虛擬的Flicker框架。jserv用C/C++實做Ajax/embedded，還可以用gdb來debug，此外，還有高橋征義 (也就是高橋流簡報法的創始者) 本人的簡報，最後再加上MGdesigner的組字Demo。Lightening Talk不論是效果或是笑果都非常棒，真的是一個特別的節目。

第一天晚上後來有跟Ping他們去古亭那裡吃飯。去了好幾個人，像是jserv、chihchun、yurenju、fourdollars、Marek等等。可惜我掛心於第二天的Talk，沒能好好放鬆心情的跟大家一起聊天。不過後來還是跟Marek的朋友聊起來了。他的朋友的英文不是很好，就用德文找我聊天。結果就是不斷的查線上字典伸單字。不過有趣的事後來他Demo了很炫的3D桌面程式給我們看，才知道他們就是s3d的Developers 。平常是很少有機會看到3D的程式師的，而且還是Developer。沒想到在這裡遇到了，真是相當驚奇。

第二天晚上則是跟一群講師還有工作人員吃個飯。大家都很high，因為這次活動辦得真的不錯。hcchien找的餐廳很不錯，吃飯前psilotum還是一直拿相機猛拍。不過我覺得晚餐吃得好快啊，原來後來我累得睡著了。

除了這些聽講的心得外，最大的好處就是能和傳說中的Developer面對面聊天。這幾天我除了講師之外，還遇到jesse、yurenuc、Tsung、descent...等一些來自各方的愛好自由軟體朋友，聊聊最近在作什麼，交換心得。

今年活動辦得真的很好，希望OSDC.TW明年還能繼續再接再厲。

相關連結：

Open Kernel Labs公司成立，強化L4與虛擬技術應用

2007-04-18T19:21:00.000+08:00

今天閱讀LinuxDevices.com時瞥見一則新聞「Startup touts virtualizing microkernel」，提及原本NICTA(澳洲的產學合作機構) 中專注於L4 microkernel為基礎的虛擬化 (virtualization) 技術的研究單位，正式成立公司 "Open Kernel Labs"，看來即將在2008年為資訊產業帶來新的震撼。雖然L4 microkernel之父Jochen Liedtke已於2001年六月10日去世，但L4 microkernel設計與我們同在，並深深影響這個世紀的作業系統。

L4採用第二的micro-kernel設計，在kernel本身只提供十來個system call，相較於第一代的micro-kernel的Mach有一百多個而言，L4的設計相當精簡，有文獻指出，適當的規劃micro-kernel system call可提升系統效率，L4正是基於此一理念的實作。德國Dresden科技大學基於L4 microkernel提出L4Linux的設計，那是運作於L4 Micro-kernel的之上Linux server(修改過的Linux kernel，所以在該server上可運作一般的Linux應用程式)，揭開L4在虛擬化技術的序幕，研發團隊率先將Linux Kernel 2.4移植到L4 Kernel Family (泛指 V.2、X.0 與 X.2 規格者)，於是，原本的Linux程式可在不需修改的前提下，在L4 Micro-Kernel運作。幾乎在同一時間，德國Karlsruhe大學也成立L4Ka小組，與澳洲的New South Wales大學合作開發針對嵌入式系統的L4最佳化實做，後來也不約而同切入虛擬化技術的領域。

NICTA在澳洲扮演產學合作的角色，早在兩年前即與通訊大廠Qualcomm合作開發基於L4與虛擬化技術的3G手機設計，在MSM6550晶片組的硬體上，提供虛擬化執行平台，允許Linux (在其上運作豐富的應用程式) 與BREW RTOS (進行資訊處理與操作3G Modem之用) 並行存在，這是個相當成功的展示。不僅如此，NICTA也跟澳洲當地的FancyPaints合作開發提供給Qualcomm 3G CDMA平台的絢麗手機人機介面。今日，這些成果將由專業商業公司進行維護與開創新價值，"Open Kernel Labs"也表示將繼續原本開放原始碼的實做(以BSD License釋出)，相當值得關注。

在今年OSDC.tw研討會上，OrzLab揭露了RT nanokernel for Embedded Linux的設計，儘管途徑與L4 microkernel不同，但許多資源是可以共享的，同時我們也提出LOVER的口號，也就是 "Linux Optimized for Virtualization, Embedded, and Realtime" 這個概念的落實。

OpenMoko/Neo1973硬體模擬::Win32平台

2007-04-16T14:30:00.000+08:00

紀錄「OpenMoko/Neo1973硬體模擬」後，收到許多迴響，cclien兄還因此徹夜未眠、提交patch，Jollen兄也寫了一篇「qemu-neo1973 / openmoko-emulator / jk2410-emulator」，分享Jollen-Pro Kit! (based on S3C2410)的硬體模擬，而前幾天則在通信論壇看到更紗的post「openmoko on winxp」，讓我也對Win32的移植感興趣。趁OSDC.tw結束的空檔，也來改看看，似乎沒遇到什麼問題，於是打包一個執行檔： openmoko-emulator-win32-bin-20070416.zip
已將昨天建構的u-boot、Linux kernel，以及rootfs等image置入，以下是執行畫面：
基本上解開Zip壓縮檔案後，直接跑qemu-system-arm.exe即可，模擬器外觀的支援還沒整合進去，但仍可從附帶的command window看到LCD Panel與GSM的資訊，同樣是按Enter鍵切換選單項目，Space鍵選擇。

附帶一提，OpenMoko/Neo1973的模擬器UI與GNU gdb整合的程式碼我已經作一段落，但現在遇到個非技術議題，因為該裝置是狹長型，而LCD Panel (VGA解析度)下上方都有頗大的空間，所以一旦模擬器的外觀載入後，就會超過螢幕解析度，勢必得作些裝置外觀的調整，所以可能需要美工專長的朋友協助。

UCIMF 2.0預計時程

2007-04-12T09:06:00.000+08:00

Mat日前在UCIMF的mailing-list上公告「UCIMF預計時程」，宣告即將在OSDC.tw上釋出UCIMF stable release 2.0.0，以下是訊息摘錄：

目前正在整理UCIMF的程式碼，同時準備4/15的OSDC.TW講稿。
主要修改內容為，加強外觀的調整，和穩定度的提升。
預計在4/15發佈2.0.0的tarball，並希望能邀請社群幫忙打包和開發。
目前希望的功能主要是：
字型、顏色，能客製化。
OpenVanilla、IIIMF的支援
sincerely, Mat.

這個計畫已經進行一段時間，很高興即將邁入新的里程碑，未來也是Embedded i18n (Internationalization) / L10n (Localization)的解決方案之一。嗯，預祝順利！

構想：Embedded Linux + Mozilla

2007-04-11T14:13:00.000+08:00

多年前曾在LinuxDevices.com閱讀The Embedded Java+Linux Quick Reference Guide系列文章，正值研究Java Virtual Machine最熱衷的時期，那時候深信此概念不移，而在後網路時代的今日，我開始思考不同的觀點。就跟Forth一般，VM只是一種途徑，重點是資訊技術能解決什麼問題、得以帶來什麼新的想法，是此，我又回頭思索過去投入的Web Browser設計項目。

週日(Apr 8)約了來自Mozilla Taiwan的朋友出來討論OrzLab的計畫，其中包含結合Embedded Linux與Mozilla runtime的整合執行環境，簡單來說，就是系統簡約到Linux與Mozilla兩部份，後者可取代傳統的應用程式。這樣的概念不算新，在《Rapid Application Development with Mozilla》一書第一章〈Fundamental Concepts〉可看到許多實例，其中有個來自OEone Corporation的HomeBase desktop，其展示畫面如下：

OEone HomeBase desktop是個很優秀的Linux桌面環境，整合許多應用程式與軟體元件到Mozilla的Framework中，諸如文書處理工具、多媒體程式、線上通訊、TV瀏覽等等，並以 XML interface (XUL + Javascript + XBL) 作為顯示與輸入的基礎，與使用者互動，詳細的報導可參考：

以下是個別元件執行的畫面：
(主瀏覽畫面)
(通訊錄)
(郵件程式)這些都是以XUL 去描繪的，相當令人驚艷。OEone HomeBase的Application Framework稱為 Penzilla，雖然立意不錯，但推出的時間點不佳。在當時，Linux下文書處理與多媒體都不甚良好，可想而知，直接挑戰桌面應用會是充滿無數困難，所以，OEone不幸於2003年停止發展並售出其產品線。

然而，如果我們從嵌入式系統的角度來看Penzilla，這反而是個新機會，特別在Web 2.0的時代，許多服務強調高度整合，許多針對特定需求的裝置也被提出，如 PMP (Portable Media Player) 或Web tablet一類。同時我們也可看到過去我們使用 PC 建構的裝置，如Kiosk (擺放於捷運站的導覽系統或提款機一類) 與遠距教學系統，其裝置往往用Windows 2000加上VB或Delphi開發的前端介面，不僅缺乏彈性，也造成維護的困難。

是此，OrzLab 成立的本意就是希望藉由「平台導向」的開發，將open source與既有的資源整合起來，並且以更好的軟硬體整合，創造新的價值，所以今年會試著用ARM或MIPS一類的低價硬體裝置作為開發驗證之硬體，將Embedded Linux與Mozilla整合起來，並建立一系列XPCOM/XUL 為基礎的元件。

相當幸運的，OEone雖然已結束產品線，其原始程式碼仍被保留，存放於SourceForge.net，其專案名稱為Penzilla Desktop，最近著手將這些舊的軟體建設移植到Firefox 2.x上，當然，沒有必要全部移植，只要將我們感興趣的部份，也是真正有需求的項目即可。

OrzLab的圖示

2007-04-07T12:19:00.000+08:00

因為本實驗室陸續開發若干嵌入式系統軟體與韌體，諸如硬體模擬器與視覺化介面等，總需要一些logo、Linux/BSD boot screen，或者Application splash screen等，所以在「OrzLab正式公開」一文也特別提到歡迎對美工擅長的朋友貢獻。非常感謝Yuren Ju、penk的學妹ramihaha、阿怪(aguai) 與其朋友，及ct等人貢獻了許多精美的圖示，整理如下：(某些圖示因尺寸考量，先行刪除，待日後wiki上線再補)

OpenMoko/Neo1973硬體模擬

2007-04-05T01:24:00.000+08:00

上個月底有幸能與OpenMoko團隊互動，做了簡要的紀錄「遇上OpenMoko」，雖然語焉不詳，但心中的感動實在是很難一語道盡的。週二去竹科替某單位進行教育訓練後，技術交流的過程讓我有種感觸，為數眾多的開發工具往往給予我們頗大的挫折感，就如以前聽過的一句話：「現代人的問題不在於沒有工具、缺乏資源，相反地，資源五花八門、工具也多到令人無所適從」，我想，針對嵌入式系統開發與整合的OrzLab，應該提出一些解決方案，就如之前提過的「視覺化系統模擬與偵錯」一般，我們可善用既有的工具，進一步延伸為更直覺且多元的開發模式。

之前主要在PXA27x的硬體平台進行開發，最近則因為Jollen兄提供其最新的「Jollen-Kit! 開發板」與OpenMoko/FIC提供「Neo1973 Hardware」，讓我對這兩款同是S3C2410為基礎的平台有高度興趣。除了「Intel/Marvell PXA27x的系統模擬」外，Neo1973 (目前硬體為GTA01) 的硬體模擬也進行中，openmoko採用的bootloader是U-Boot，wiki的 "Bootloader" 做了很詳盡的解說，系統模擬器的畫面如下：

U-Boot允許自訂選單，在我們這個以qemu為基礎的模擬器中，選單項目可按下Enter鍵作切換，當按下Space鍵時就執行指令，當然，還等什麼，咱們就boot系統，模擬器的畫面如下：
熟悉的小企鵝就現身，當Linux走出PC，進入移動裝置如手機時，給予我們相當大的揮灑空間。OpenMoko的軟體架構採用X Window System，並使用OpenedHand維護的應用程式套件，以下是進行觸碰螢幕校正的模擬器畫面：
為了要符合觸碰螢幕的運作行為，這個以qemu為基礎的模擬器做了些許的修改，避免被grab，最後我們終於看到openmoko的軟體環境：
透過OpenEmbedded，我們可以快速建構整個system image，OpenMoko官方也有個build host，提供最新的image與ipkg feed。這個模擬環境暫時命名為 "openmoko-emulator"，原始程式碼與相關資源可在此取得：http://mdk.linux.org.tw/~jserv/openmoko/。以下是 "openmoko-emulator" 的README內容：

== Introduction ==

The package includes the modified qemu for emulating Neo1973 phone aka FIC GTA01 aka OpenMoko based on S3C2410A.

== Requirements ==

Software:
1. Linux distribution. Tested in Debian Sarge and Ubuntu 6.06/7.04
2. Packages: gcc-3.4, lynx, libsdl1.2-dev, python, perl

== Usage ==

After extracting the snapshot of this emulator, change to source directory. Then, perfom the following instructions:

(1) Build from source
# ./configure
# make
(2) Download OpenMoko images from nightly build
# ./openmoko/download.sh
(3) Install OpenMoko to NAND Flash
# ./openmoko/flash.sh
(4) Run the emulator
# ./openmoko/run.sh

週邊的部份，GSM modem與AGPS會紀錄其enable/disable狀態，其餘則算是堪用，這當然只是個起點。未來或許會比照「深入淺出Hello World」系列演講的模式，對這類在Embedded Linux開發過程中，引入硬體模擬器的突破，探討如何更深入掌握系統與加速開發流程，同時這也彰顯整合開發工具的需求，所以最近會繼續尋求合作的機會。

2007年四月上旬行程

2007-04-01T23:16:00.000+08:00

應該採用社群行事曆的機制，不過先紀錄一下今年四月上旬的暫定行程：

Apr 3 (二) - 教育訓練與TOSSUG社群聚會
Apr 12-13 (四、五) - TaiwanCodeJam (即Code Jam 2007，詳情可見「Coding Jam 2007的宣傳開個頭」)

以Ajax/Embedded為提案參與，詳情可見「Ajax/Embedded」與「lwkhttpd : Lightweight kHTTPd for Linux Kernel」

Apr 14 - 15 (六、日) - OSDC.tw，本實驗室的議程：

jserv -RT nanokernel for Embedded Linux
Mat - Unicode Console InputMethod Framework
具體提案內容可見「OSDC.tw 2007 is coming」

OrzLab已正式公開，硬體設備可望陸續到位，現在就是展現我們「自由」與「創意」的時機 :-)

OrzLab正式公開

2007-04-01T00:52:00.000+08:00

OrzLab是什麼？即便參考其全名"Open RazzmatazZ Laboratory"也很難令人聯想到這樣的實驗室到底是為了什麼目標成立。身處於台灣，每年都可看到為數可觀的電子產品出貨，這絕對是台灣的驕傲，同時在質與量都有傲人的表現，然而，當自己實地參與PDA、SmartPhone、數位電視、Wireless router，及儀控系統的設計後，才發現不少工程成本是耗費於那些重複的工作中，又因為缺乏產品特色，就陷入惡質的成本價格戰中，原本產品的特色與創意早已不知去處，更慘的是工程人員終日處理無趣的技術問題中度過，逐漸喪失熱情與創意，這絕對不是我們樂見的。

OrzLab作為一個非營利的組織，沒辦法改變上述的情況，但我們有能力可為硬體帶來新的生命，並且重現那份熱情與創意，其出發點就是善用自由軟體 (Free software / Open source software)。於是乎，這個實驗室的基本想法是能讓更多創意透過自由軟體，落實於嵌入式裝置或者特定的硬體中，具體來說，就是避免重複的專案開發，並針對嵌入式系統或系統整合廠商需求，提出有價值的解決方案，建構一系列自由軟體為基礎的系統架構。

上述的文字乍看似乎很難抓到重點，但回頭過來思索：何以電子裝置生產如此蓬勃的地方，人們常苦於缺乏可用以驗證想法的裝置？原因很單純，不是沒有硬體，是缺乏開放的軟體與韌體。就如我們所知，軟體賦予硬體新的生命，倘若裝置中的軟體趨於封閉，這也意味著其生命週期有著天生的障礙，這也是我們往往得退而求其次，用相對高價、高功耗的個人電腦來驗證自己的想法，有時候我們的要求就是單純到「能否把MP3 Player軟體放到硬體裝置中，當作床頭音響使用？」技術上絕對可行，而且可能根本不需更動任何一行程式碼，這之中沒有什麼魔法，但我們往往不得其門而入，更別說只是滿足 "Orz" 這類無釐頭文化的呈現。

這是取名為"OrzLab"的主因：只要我們能讓裝置中的軟體獲得「解放」，轉化為自由軟體，再如何奇特無比、只能訴諸 "Orz" 形容的嘗試 (即OrzLab裡面的"RazzmatazZ") 都是可行，是的，我們絕對可以做到，而且享有台灣低廉的硬體成本優勢，當然，要創造潛在的嶄新產品更是大有機會。

Linux/BSD以及大量的自由軟體廣泛被移植到不同的硬體架構，激發出我們的熱情與使命感，驅使這個「創作型」實驗室產生，其中「自由」與「創意」可說是最大的精髓。現有的專案計畫都是針對嵌入式系統的應用，伴隨著關鍵性的技術議題，我們可透過開放的網路資源與協同合作，在一定程度上克服既有議題，提出可累積的自由軟體解決方案。

所以，換言之，OrzLab就是個創作平臺，允許任何創意化為具體的專案項目，最終可落實於硬體裝置中，目前OrzLab 成員來自台灣的自由軟體貢獻者，以 Linux/BSD 為主要的開發環境，對嵌入式系統開發、多國語文處理、Web 應用程式，或者是低階系統控制皆有一定的掌握度。相當感謝FON Taiwan與OpenMoko在本實驗室初期作了最具體的資助：提供可修改的硬體裝置，並具備開放規格，這意味著，我們立刻即可將「自由」與「創意」這兩大精神注入原本死板的硬體。想像一下，我們可把Ajax引擎移植到FON WiFi Access Point裡面，然後死板的設定介面就瞬間變成變化多端的Web Application，我們當然可直接連線到FON中寫blog或編修wiki，而且享受最直觀的介面，為什麼不作呢？

請查閱OrzLab開發者日誌，以取得最新開發動向：
http://orzlab.blogspot.com/

現階段的開發方向有：

Realtime Linux/BSD
Embedded i18n
Embedded Web/Ajax framework
System emulation & Optimization

基於既定的開發方向，OrzLab希望能取得硬體廠商的支持，提供硬體與技術支援，當然最終成果也會是以自由軟體的形式釋出。選擇在四月一日公開，一方面是基於對"Orz"的戲謔，另一方面來說，企盼在台灣透過自由軟體，為硬體帶來新的生命，如此的行為可能會被視為愚人之舉，所以就待時間來考驗我們。我們歡迎各方面的朋友加入，不見得要對技術領域有深入掌握者，事實上，對於美工 (logo / icon / splash screen)、文字素描、溝通協商 (OrzLab常有與硬體製造商洽談的機會) 有能力者，也相當歡迎。至於學生族群，如能與OrzLab合作，可說是兼具學習技術、培養技能，並學以致用的好機會。

聯絡資訊：

協調人暨聯絡人：Jim Huang (黃敬群 / jserv)，透過email取得聯繫：jserv.tw (at) gmail (dot) com
討論群組：http://groups.google.com/group/orzlab
IRC線上討論：#orzlab (FreeNode.net)，採用UTF-8編碼

遇上OpenMoko

2007-03-31T23:31:00.000+08:00

週五晚上當我正在tune某個裝置時，收到一則訊息，提及與OpenMoko創辦人Sean Moss-Pultz聚餐的機會，於是週六就邀約Jollen、Mat，以及FourDollars一同前往。關於OpenMoko的報導不少，不過寫得最生動的大概就是Jollen兄的blog：

同時也是FIC (大眾電腦集團) Product Manager的Sean Moss-Pultz，得與同仁面對內外不同的意見，對於這個略有年紀的企業來說，實在是種挑戰。而我有幸在這面對面的對話中，讓原本在我心中的疑惑，透過詳盡的闡述與互動，逐漸獲得解答。其實可參閱mailing-list上的討論"New site about open mobiles: ideas and suggestions"，這可搭配OpenMoko於FOSDEM 2007的演講："OpenMoko"，在台灣大學做了一份錄影存檔："OpenMoko_speech_FOSDEM2007_video.avi" (342Mb)。

OpenMoko作為開放原始碼的手機，有許多堅持，首先就是強調kernel-space的部份必須依據Linux kernel的授權方式，採用GPLv2，這無可避免會造成尋求硬體供應商的困難，但開發團隊正試圖克服。再來就是依據社群需求去制定產品規格，三月底的GTA001就是在初步雛型發表後，廣泛接受各方意見，逐步調整的設計，其SVN版本控制系統也可見到對應的軟體建設。依據wiki指出，主要的軟體項目有：

boot loader - u-boot
kernel - Linux kernel
gsmd - 管理GSM modem的GSM背景程式
gpsd - AGPS (Assisted GPS) 背景程式
OpenMoko - The OpenMoko distribution

其中OpenMoko distribution又分成若干application與library，而UI的架構部份主要OpenedHand協助開發，後者協助Nokia成功推出Nokia 770系列的產品，而在OpenMoko現在的實做也看出高水準的表現，其LCD panel大膽採用VGA 640x480解析度，顯示頗為細緻，但這也衍生對於多國語文的技術挑戰：輸出與輸入法的支援。

過去顯示的解析度小，所以可以直接用點陣字或者所謂的"pre-rendered font"，但是一旦解析度提昇時，就不可能只用兩三套固定尺寸的字體來滿足，勢必需要TrueType的向量字型，不過，這對於這類手持式裝置來說，不僅佔用大量的儲存空間，還需要複雜的運算，也得消耗寶貴的記憶體空間，長期來說，頻繁的儲存空間存取，將可能降低使用年限。稍早於「紀錄：可攜式造字引擎專利釋放暨成果發表會」特別強調的技術困境，既然剎那搜尋工坊 (前身為易符智慧科技)已相當有誠意地釋放專利，並提供社群相關的自由軟體實做與部件字庫，這就是一個極佳的契機，OrzLab的成員在參與自由軟體開發的過程中，奠定對於多國語文處理的能力，所以技術上的分析與實做也已經展開，OpenMoko可說是極佳的技術展現平台，希望近期即可展現這部份的成果。

當然，這次的會晤有尚有許多值得一書的討論，就留在日後詳談了，我也從這個困難度極高、周旋於理想與現實考驗的OpenMoko計畫中，獲得莫大的鼓舞，也希望OrzLab能秉持這些精神，為台灣的硬體創造出更大的價值。

UCIMF正式成為OrzLab專案項目

2007-03-20T18:58:00.000+08:00

日前Mat完成了OrzLab的paper work，自此，UCIMF正式成為OrzLab的專案項目之一。UCIMF是個創新的計畫，引入IIIMF與OpenVanilla輸入法架構 (未來會有SCIM) 的終端機輸入環境，但不受限於輸入法，事實上，在開發的過程中，已經補足Unicode輸出顯示能力、視窗管理，以及多種字型描繪機制。以下是UCIMF的授權宣告：

/*
* UCIMF - Unicode Console InputMethod Framework
*
* Copyright (c) 2006-2007 Open RazzmatazZ Laboratory (OrzLab)
* Maintained by Chun-Yu Lee (Mat)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/

隨著資訊交換的多元化，在我們的觀察，嵌入式系統的多國語文支援有提昇的趨勢，又因為嵌入系統不僅得考慮到效能，也得將成本與穩定性列入考量，所以往往受制於有限的軟體建設。UCIMF則帶來一個新的途徑，得以在低成本需求的Embedded Linux/BSD上，提供豐富的多國語文處理能力，涵蓋顯示、輸入法，未來也會有印表的支援，更重要的是，符合Unicode標準，所以可消除許多相容性議題。

另外，考量到UCIMF應用的多元性，其IMF (Input Method Framework) 的介面部份採用BSD License釋出，這意謂著其上的輸入法引擎不僅可抽換，也可採用非GPL授權，去除商業應用的困擾。

紀錄：可攜式造字引擎專利釋放暨成果發表會

2007-03-20T14:31:00.000+08:00

稍早提及可攜式造字引擎專利釋放暨成果發表會，日前已在中研院資訊所圓滿落幕，雖然許多技術性與實用性的議題尚待克服，但剎那搜尋工坊這項釋放專利的創舉，可望驅使漢字與資訊的整合邁入新的契機。OrzLab也順利展示內建動態組字技術的Linux mobile phone概念機，未來將逐步釋出其原始程式碼。

議程方面，自下午三點，由剎那搜尋工坊 (前身為易符智慧科技) 的大家長陳昌江先生在「專利釋放現場公告」揭露「可攜式造字引擎專利公眾授權條款書」，並有存證信函與拍照留影，為漢字資訊處理界劃下新的一頁，自此，此類動態組字技術將不再受限於特定單位，而能以自由軟體之形式，廣泛流通於新的應用中，感謝與會的貴賓與我們見證這一刻。葉健欣先生 (yap，前朱邦復實驗室成員) 則在「組字研究的簡史」給予清晰的介紹，提及何以漢字系統會面臨窘境、古文訓詁的難題、過去幾十年內相關漢字技術的變遷，以及從易符智慧科技至剎那搜尋工坊所面臨的挑戰與技術應用的轉變。

張正一 (魔法設計師) 隨後給予精彩的「組字標準與觀念解說」議程，先由昔日「萬碼奔騰」的時代點題，雖然今日我們已清楚知曉Unicode標準的重要性，但實務應用上難免有所不足，其中以漢字缺字為最，為此，Unicode 3.0以降，引入新的IDS與IDC機制 (Ideographic Description Sequence/Character)，剎那搜尋工坊則以此為基礎並整合以部件為基礎的動態組字技術，張正一先生則率先撰寫符合自由軟體規範的組字示範程式，在議程中發表與展示，藉此為與會的貴賓建立概念。

由於專利釋放之舉也需要配套的自由軟體社群支援，才得以彰顯價值，所以本會也邀請到來自中研院資訊所的林誠夏與胡崇偉 (marr) 探討授權與專案開發的須知，詳見「公眾授權條款簡介」與「開源計畫要如何參與」。最後是OrzLab的議程「應用動態組字於手持式裝置」，首先分析手機一類的移動裝置在成本與多國語文上面臨的難題，再者是來自裝置端與後端的訊息交換議題，再深入探究系統設計，可發現以往的點陣字系統是一大衝擊，不僅增加成本也造成潛在的裝置壽命問題，同時輸出與輸入系統彼此是獨立的。OrzLab引入全向量繪圖系統，試圖克服上述技術難題，目前已經有高效能且低儲存需求的ASCII字型引擎，正銜接Unicode IDS需求，在議程尾聲，展示了一款內建動態組字技術的Linux mobile phone概念機，得以在QCIF解析度 (176x220) 迅速呈現全螢幕漢字輸出。

由於與會賢達來自古文研究、電子產業、出版業、佛經文化、文書處理等領域，所以議程後的討論時間中，激盪了深入的技術與人文性思考。首先是漢書軟體作者施得勝先生提問：「動態組字美觀度可否精進？」yap的回應是：

組字七萬字約佔1MB ，而 TTF 要40~50MB 。美觀是用空間和時間來換取的
常用字只有兩三千字，這些字沒有必要動態組出來，使用既有的方式即可
動態組字使用的場合為呈現系統不存在的字，此時，組字再醜，也遠比空白或亂碼來得好

另一則是關於自由軟體授權的議題，這由中研院資訊所的葛冬梅小姐給予簡要的分析。臺灣師範大學國文系亓婷婷教授則提出美觀度、手寫辨識與組字的整合等問題，就動態組字本質來說，形同一個可提供無窮字形的字型檔，與輸入法沒有關連，亦即可沿用任何既有的輸入法，來輸入構形部件，當然，對於手寫辨識來說，將會有潛在的優勢，因為已經預先作部件的分析。

東海大學資管系林正偉教授提出澄清專利涵蓋的議題，陳昌江先生則重申專利字號與適用範圍，以茲與眾多漢字學者研究區別，這也引發關於動態組字需要唯一或標準表示的討論，以「好」這個中文字為例，其部件為左邊的「女」與「子」，再行左右組合，但對複雜的字來說，構成方式不唯一，Unicode IDS只是探究其表示法，該如何確認有一致的交換性？多方討論的結果來看，剎那搜尋工坊表示會另行規範，但不在本研討會的議程中。最後是Mat (UCIMF作者) 就實務上詢問動態組字能否與Unicode相容，基本上只要依據Unicode IDS作對應，即可符合相容性，這也意味著，OrzLab未來可能從Unicode console/terminal與FreeType整合的方式，切入動態組字技術的應用。

會後就是BoF時間，也激盪了許多想法，相關的自由軟體實做與部件字庫也會在近日釋出，所以，儘管三十年前謝清俊教授等人就提出構字式的具體研究，但真正能夠讓成果累積並且跨入電腦以外的項目，這是個起點，但我們終於跨出了。

相關資訊：

Unicode版のTeX

2007-03-15T20:09:00.000+08:00

TeX 是一套重量級的排版軟體，目前在國際流通的論文，大半是以TeX 所製成，其文件品質有目共睹。XeTeX 是Unicode版的TeX，具有功能特色如下：

使用FreeType和Fontconfig的方式讀取系統字型，直接支援True Type和OpenType字型，不用再作繁複的設定。引入ImageMagick支援，可直接套用JPG、PNG、BMP的圖檔，大幅增加引圖的彈性。語法上，繼承TeX和LaTeX的語法，而不再用\usepackage形式上來處理CJK文字，文件相容性高。

目前XeTeX的使用環境以Mac為主，不過目前已有Linux和Windows的支援。圖上所顯示的正是在Gentoo Linux上所製成文件。

視覺化系統模擬與偵錯

2007-03-15T10:18:00.000+08:00

稍早撰寫短文「透過 User-Mode-Linux 來學習核心設計」(Part I / Part II)，隨後在「Intel/Marvell PXA27x的系統模擬」提出OrzLab所實做系統層面的模擬環境 (以qemu計畫的qemu-system-arm為基礎)，暫定名稱為PXAemu，這些基礎建設對於嵌入式系統開發都有其價值，諸如system prototype、進階分析，以及快速軟體開發，未來我們會增加多種硬體平台的模擬。除了系統模擬器外，視覺化的呈現與偵錯能力也相當重要，在今年一月份，已經成功整合User-Mode Linux與Insight/GDB，大略的呈現如下圖：
當時開發的平台是IA32，引入User-Mode Linux的優點是可快速分析與平台無關的Linux kernel機制，諸如記憶體管理、排程，以及網路堆疊部份。另外，上週於台中一中舉辦的「深入淺出 Hello World 」系列演講第三場，已經公開展示PXAemu與gdb整合的操作，可相當便利的進行分析與偵錯，其運作畫面如下：
以上展示透過Remote GDB連線，設定中斷點於sys_execve函式，這將會觸發於首次由kernel-mode切入user-mode的時機，也就是/sbin/init程序執行之時，當然，gdb強大的命令與功能可以輔助來對kernel作更深入的追蹤，必要時也可改變其執行時期的行為，稍後我將會試著整合PXAemu與Insight/GDB。因為Insight/GDB內建的Tcl/Tk版本老舊，在Linux下對於字型處理不雅觀且不當的XIM處理也容易讓系統崩潰，所以我動手補強並加入Xft的支援，可自行取得patch。

除了以上透過既有軟體組合的視覺化環境外，我正在進行一個全新的項目，以Qt4作為GUI library (盡可能減少Win32與Linux平台移植的技術議題)，為PXAemu開發frontend，也著手開發相容於GDB Machine Interface的GUI Debugger，如此一來，就可以輕易更換GNU Toolchain，即使是商業版本的MontaVista Consumer Electronics Edition (mvlcee) 也得以使用。

可攜式造字引擎專利釋放暨成果發表會

2007-03-14T00:20:00.000+08:00

本週二下午至中研院資訊所，參與「可攜式造字引擎專利釋放既成果發表會」的行前會，確立許多細節，新聞稿已出爐，摘錄如下：

3月17日剎那搜尋工坊將假中央研究院舉行可攜式造字引擎專利釋放暨成果發表會
對於出版、文史研究、教育、甚至科技行業，漢字重重的缺字問題始終是永遠的痛，在經歷30餘年產、官、學的努力下，終於萌生全面性解決方案－部件組字。
部件組字在邁向成熟實用化的道路上，剎那搜尋工坊扮演了相當的角色。過去專注於開發漢字搜尋技術，也鑽研缺字問題的全面解決之道，在吸納中央研究院謝清俊教授、朱邦復先生等等諸前人的成果後，研發出「可攜式造字引擎」。該技術內涵為基於漢字字形本質的動態組字，使跳脫以往人為一字一碼的武斷，回復漢字本有的活性架構。不但解決了缺字困難，也同時相容於unicode標準，為一條無痛的漢字數位進化之路。
剎那搜尋工坊鑑於此重大數位漢字基礎技術，乃「站在巨人肩膀上」的成果，為謀求對社會大眾的最大利益，遂藉此會公示將此專利技術無償開放公眾運用，歡迎各界使用與繼續發揚。
會中將說明本技術的沿革簡史、組字的觀念、以及如何參與發展的作法。

OrzLab也提供了十五分鐘的介紹「應用動態組字於手持式裝置」，延續之前blog「動態組字技術於Embedded領域」的觀點，將以實際的案例探討嵌入式系統領域如何由此受益，相當感謝剎那工作坊釋出專利，經過多次的討論後，也看到許多機會，作為華人的工程背景人員，我們有相當大的伸展舞台，同時開放的胸襟加上open source，所激盪出的變革更值得我們關注。

舉辦單位

主辦：剎那搜尋工坊
協辦：中央研究院自由軟體鑄造場
贊助：資訊工業策進會雜誌社

時間地點

3/17/2007 下午3:00~5:00 中央研究院資訊科學研究所新館 101會議室

lwkhttpd : Lightweight kHTTPd for Linux Kernel

2007-03-13T23:28:00.000+08:00

昨天在SourceForge.net註冊了新專案Ajax/Embedded，做了必要的設定後，開始將之前Proof-of-Concept的程式碼check-in到SVN中。今天開放的項目是子計畫：lwkhttpd，也就是 "Lightweight kHTTPd for Linux Kernel" 之意，以下是該子計畫簡介：

lwkhttpd : Lightweight kHTTPd for Linux Kernel 2.6 series

Copyright (c) 2007 Open RazzmatazZ Laboratory (OrzLab).
Maintained by Jim Huang
Development page: http://sourceforge.net/projects/ajaxembed

[-] Overview

Ajax/Embedded is an experimental design dedicated to perform Ajax applications on embedded systems, such as Wirelss routers. To fit the web traffic on these devices, lwkhttpd is developed as the full kernel-mode HTTP daemon for Linux kernel 2.6 series. Besides handling static requests, lwkhttpd redirects dynamic requests to the user-mode webserver (used for Ajax engine) for extensibility.

儘管Web 2.0並未帶來相當革命性的技術移轉，但我們可以看到Web engine卻有調整與最佳化的空間。在lighttpd開發者的blog有一篇名為 "Faster Web 2.0" 的文章，提出三個方向對Web 2.0應用程式提供更好的效能：

Large Response content
Pre-generating content
Read Ahead

簡單來說，FastCGI的執行模型雖然對OpenWebMail一類的Perl-based Web application有相當程度的效能提昇，但對於Ajax導向的模式來說，還是沒有切中問題核心。Ajax/Embedded底層提供如此一個kernel-mode HTTP daemon，以處理大量的static data，同時也提供 redirect to user-space的機制，讓動態網頁資料 (主要是XMLHttpRequest) 得以「轉包」到我們的Ajax engine，在這之上有豐富的C/C++ Web UI widget set可用。整體效益就如之前blog「Ajax/Embedded」所提，得以建構兼具效能、功能，以及安全性的native Web framework。

對了，Ajax/Embedded計畫項目會參加今年的Coding Jam 2007活動，已提交簡要的Proposal到TaiwanCodeJam的wiki page中。希望能快點拿到我們的參考硬體，ARM-based的硬體已開始運作，現在要試試Wifi相關的部份，開發的過程中讓我發現很有趣的現象：現在的computing model逐漸「M化」，不僅是mobile化，也是朝向兩個極端的演化，就Ajax/Embedded專案的適用範疇來看，事實上就是「client比server快上許多」的模式，同時server-side產生相對少量的資料，讓client-side盡情去描繪多采多姿的內容，也對使用者互動方面有了更多的需求。

OpenVanilla套件打包二三事

2007-03-13T00:57:00.000+08:00

在寫UCIMF的趨使下，對OpenVanilla的安裝方法並不陌生。雖然手動安裝不難，但總是希望能直接用套件的方式來安裝程式和模組。繼前陣子包了給Debian的實驗包之後，一直也很想試Gentoo的打包。經過幾天的嘗試，幸運的得到初步的成果。一開始的時候，煩惱要怎麼指定程式碼的位置，一般都是給一個tar.gz的URL然後下載解壓縮。不過OpenVanilla主要是用SVN作為存放的方式，所以行不通，於是就暫時寄望在Tarball出現上。這時候剛好遇到psilotum秀了FreeBSD上的OpenVanilla的Ports給我看，才發現Ports已經有人包好這些套件，我便想，Portage上也有類似的工具才對。有了靈感後，很快就找到Portage對於SVN這類的處理方式了。主要的作法是，先 inherit subversion 這個eclass, 然後再用ESVN_REPO_URI的參數來指定位置。遇到比較分散的檔案，則可以改寫src_unpack()以符合需求。不熟悉的地方則可以先參考已經寫好的ebuild，像是uim-svn。

回顧這兩次作Debian和Gentoo的Package的經驗，發現製作原理有很多共同的地方。作Debian的包裝時，發現整個OpenVanilla Modules的目錄只要設好一個套件產生的規則，就能把整個目錄下所有的模組都打包成個別的套件。因此原本以為要作10幾個重複的工作，居然一次就作完了。這讓我印象非常非常的好。能在套件的維護者只需要維護一個Source Package的情況下，產生許多Sub Binary Package供使用者選擇，是極大的優點。而Gentoo特別的地方(也是FreeBSD Ports的特色)，則是直接抓源本的原始碼來編譯的風格。這個風格的好處是在我開始作UCIMF之後才慢慢有感覺的。因為我體會到，對許多還在發展中的專案，維護一份Tarball是一件很困擾的事。最主要的原因是，許多地方都還在增減修補，很難取捨出一個點作為一個穩定的釋出，而要等套件的製作，更是一個漫長的過程。這時候能夠透過CVS、SVN這一類的方式取得原始碼來編譯，對許多發展中的專案來說，真的是一個很棒的特色。

從一開始的User，到寫專案後學了一些Developer東西，在今天作了這些東西之後，感覺又多了一個Packager的角色。對我來說，在這三者的使用情境中轉換，並不是那麼方便。是不是有個套件機制可以將這三者融合在一起呢? 像是我今天想改一個程式的功能，我能很方便的取得源本的原始碼，在本機修改後，能直接套用在套件裡作編譯和安裝，完成後並能輕易的釋出和分享。今天看來，相關的環境條件都蠻成熟了，說不定已經有這樣子的整合式套件系統架構存在也說不定。

或許在可見的將來，這些開發平台的整合，也能像Wiki對文件發展所帶來2.0的影響一樣，提供開發者一個互動性更高、更流暢的開發環境。

Package 2.0 ? 嗯...

Intel/Marvell PXA27x的系統模擬

2007-03-09T03:36:00.000+08:00

上一篇blog「PXA27x Linux計畫」提及在SourceForge.net建立名為PXA27x Linux的新專案，包含系統層面的模擬環境，現行實做以qemu計畫的qemu-system-arm為基礎，暫定此分支命名為PXAemu，主要的參考標的是市面上的PDA或者SmartPhone，當然也不排除開發中的硬體裝置，畢竟模擬環境的彈性較高，要作前期驗證或者針對特定需求的模擬分析 (如：能源變化、網路通訊的異常)，都是可行的。剛剛已經將kernel patches置入SVN (/kernel/linux-2.6.20)，以PXAemu作系統模擬的畫面如下：
很令人振奮的畫面，稍後會補上一個PXAemu專屬的frontend，並改善LCD controller的處理。對了，RT nanokernel for Embedded Linux也可用PXAemu來進行多項實驗，這也是近期進行的項目。

PXA27x Linux計畫

2007-03-05T22:51:00.000+08:00

使用Intel PXA27x (已於2006年七月售出予Marvell，相關產品線資訊可見Wikipedia - Xscale) 進行產品開發大約兩年，接觸了BSP、GNU Toolchain、Wireless MMX、Intel IPP、Graphical Overlays、NIC、... 等項目，也開發了無線網路裝置、GSM手機，以及多媒體系統。開發過程中遇到不少技術問題，雖能大致克服，但也有重複開發的遺憾，是此，建立RI (Reference Implementation) 就是相當重要的議題，於是我們在SourceForge.net建立名為PXA27x Linux的新專案。

雖然Intel早在2004年即提供GNU/Linux (通稱，含binutils、gcc、glibc，與linux kernel) 的patch或相關的修正，但畢竟自由軟體界已經有很大的改觀，同時原本Intel的貢獻中其實有不少bug，所以PXA27x Linux匯集來自許多方的改進，提供除了BSP外，更新且效能、功能最佳化的軟體套件。又，考慮到系統層面的模擬環境，本計畫會提供以qemu為基礎的system emulator，不只模擬PXA27x指令集，還廣泛包含DMA、GPIO、LCD、MMC、PCMCIA、Timer、co-processor (CP0/CP1)、... 等，主要的參考標的是市面上的PDA或者SmartPhone，當然，現在還有很大的改進空間。

今天已將pxa27x-oabi-crosstool子專案置入SVN，以下是其簡介 (取自README檔案)：

pxa27x-oabi-crosstool : PXA27x OABI (old ABI) toolchain builder
Copyright (c) 2007 Open RazzmatazZ Laboratory (OrzLab).
Maintained by Jim Huang

The goals of pxa27x-oabi-crosstool are as following:
Bug-fixed toolchain for PXA27x
Binary compatibility for Intel Integrated Performance Primitives library (Intel IPP).
GCC 3.x-based system with enhancements.
Providing advanced features such as Application XIP, optimized memcpy, etc.

這是software stack從Old ABI跨入ARM EABI的過渡系統，考量到軟體相容性，諸如MontaVista Consumer Electronics Edition (mvlcee) 等，所以保持採用gcc-3.x與glibc-2.3.2，但陸續做了改良與backports，這些可參考patches目錄。

稍後會釋出的項目是基於OpenEmbedded的Linux kernel 2.6，以及基於qemu的system emulator，期待您的指教與參與，謝謝！

Mutex與火車排班

2007-03-04T20:47:00.000+08:00

在我心中，一直有個小心願，能以自己微弱的力量為這個社會多作些事情，包含免費的技術訓練，然而時間、精力是投入了，但不見得有效果，為此，我常常在反省。拜讀對岸高手Pengcheng Zou的blog - 「Linux地鐵」一文，我終於知道為什麼，畢竟技術或理論本身被提出，就是要克服現實問題，所以若能讓訓練本身更貼近現實，這樣才會發揮其價值。以下摘錄「Linux地鐵」一文的部份內容：

今天早上上班，快到地鐵就發現外面站了不少人，有做打車狀，有做打電話狀，隱約聽到有人說地鐵壞了。下到地鐵站台，果然看到兩列車停在那裡，站台上站滿了人。

後來在北京市地鐵運營有限公司網站上看到了事故原因：
11日早晨7點55分左右，地鐵2號線宣武門變電站瞬間過載跳閘，造成長椿街信號系統無法正常使用，列車運行方式被迫由自動閉塞改為電話閉塞，通過能力下降，運營間隔加大，造成長椿街臨近的復興門等重點站短時間乘客滯留。8點19分故障排除，地鐵運營方式隨後按自動閉塞方式運營，運營秩序逐步恢復正常。其間，2號線內外環西直門至宣武門早高峰列車間隔加大，列車最小間隔由原來3分半被迫延長到8至10分鐘，由於故障發生時正處於早高峰階段，客流本就較大，所以部分車站出現乘客短時滯留現象，地鐵1號線受此故影響有6列車在復興門站通過。13號線、八通線未受故障影響，運營正常。
何謂「閉塞」？寶貝爹地是鐵路的，正好請教。講了半天，不甚了了。只好再從網上查，得知由車站向區間發車時必須確定區間內無車，還要防止兩個車站在同一線路上向同區間發車。這種按照一定的方法組織列車在區間內的運行，稱為行車閉塞，用來聯絡的設備稱為閉塞設備。常用的閉塞設備有自動閉塞、半自動閉塞及電氣路籤閉塞等。地鐵採用自動閉塞設備。

這下懂了，地鐵就是作業系統，所謂區間就是臨界區，閉塞裝置是各種同步機制，自動閉塞相當於spinlock，電話閉塞相當於semaphore。今天早上效率比較高的spinlock失靈了，只好用效率較低而且不能用於中斷上下文的semaphore。所以導致系統性能下降，進程吞吐量明顯降低，客戶滿意度下降。不少用戶轉而使用其他作業系統。

很多唸電腦科學的學生，往往在畢業後還不能理解那些同步理論的重要性，如今，火車排班就是最好的案例。Linux kernel中有兩種mutex (互斥)機制：

semaphore
spinlock

兩者主要區別是，semaphore在無法進入critical section (臨界區) 時，會引發context-switching，而若有硬體配合 (SMP) 的話，spinlock就沒有context-switching，這是許多教科書會提到的，但聽起來很奇怪吧？我們要思考的是本質，semaphore是process-level的操作，當有process要求進入critical section，好比在上面鐵路案例中，以電話要求區間的發車權，那麼，若critical section沒有被設置旗標，就可佔用並重設旗標，也就是我們可順利發車，但若不幸遇到該區間已經有車班呢？這時候該process就被迫「睡眠」，而本身也會被送入wait queue，這種枯等的經驗，想必很多通勤的朋友都能感受。我們也可以發現，這過程牽涉到process狀態的改變，因為勢必會有資源被釋放的時候 (但不保證)，屆時，被迫「睡眠」的項目也會因而被喚醒。

spinlock的本質是busy-waiting，聽起來很沒效率，但為何說在SMP很重要呢？最主要的原因是，沒有context-switch的負擔，沒有牽涉到process的狀態變化，在多處理器的環境下，spinlock相當有效率，而在單處理器上，卻只是disable/enable isr一類的操作。換過來想火車的案例，似乎就簡單多了，用電話通知本身涉及人與人的通訊內容、線路使用量，以及現實因素，可視為單處理器狀態，但如果是自動化，個別單元的協調時間是相當短的，所以可想成SMP架構，自然這兩者的mutex機制也有使用上的落差了。

當然，真的要探討Linux semaphore/spinlock的機制，其實複雜許多，特別在2.6 kernel還添入big kernel lock等新的機制，不過這些都出自典型作業系統理論 (命名可能有出入)，只要稍微變化一下，或許也能對應到現實。

動態組字技術於Embedded領域

2007-03-02T17:49:00.000+08:00

在魔法設計師與marr的引見下，去年於COSCUP 2006有幸認識剎那工坊的陳昌江與yap前輩，談到中文組字技術與嵌入式系統的若干細節，給予我很大的鼓舞。本實驗室今年的計畫中，即有Embedded GUI Framework的項目，原本只是因應RT executive或virtualization需要 (如Linux subsystem尚在啟動或者非運作中的情況下，至少可有輕量級的人機介面與使用者互動)，所提出附加性設計，這也就是Xorz/Embedded (展示1/展示2)。但如果能順利整合中文動態組字技術，對於原本即以向量繪圖為核心架構的Xorz/Embedded，是很好的契機，或許可作為低階裝置的UI，同時我們也可以看到，開發中國家如中國大陸，更是需要動態組字技術。

為何我們要重視動態組字技術的原因，除了陳昌江前輩日前發表的大作「等待新漢碼」所提到種種根深蒂固的窘境以及文化傳承的需要，另一個現實的考量是，這類可攜式造字引擎可避免過度的Disk I/O存取，進而大幅提昇儲存裝置的壽命 (NAND/NOR Flash 皆有讀寫次數限制)，所以短期內我們應該要在Embedded平台作技術驗證，中期就是銜接現有mobile標準，克服缺字議題。

魔法設計師貢獻了許多教學文件與參考實做，可參考其 blog 之漢字研究的分類，日前張貼的「組字示範程式釋出！」一文即提供了以Java撰寫的教學程式，內含中華民國發明專利號碼第I254863號「可攜式造字引擎」專利的技術與剎那工坊維護之剎那單線體字形檔，經專利權人陳昌江同意，預先提供執行檔與資料檔供測試評估使用，詳細規格可見正體中文網，附帶一提，相關專利可望於近日釋放，成為公共財。

OrzLab很自然就成為受益者，不過小弟目前仍在規劃階段，只有零星的測試程式碼，不過抽離Xorz/Embedded內部的向量描繪引擎就是相當重要的工作，目前已經有個具體而微的向量字型編輯程式，以下是其運作畫面：

另外，也可試著與對岸許多Embedded GUI開發者打聲招呼，其實已經太多重複的工作了。今年真是刺激的一年 :-)

Ajax/Embedded

2007-03-02T09:59:00.000+08:00

之前花了一些時間作個 lightweight kHTTPd for Linux Kernel 2.6，也可用作於 HTTP accelerator / redirect server，在kernel mode處理static web data與redirection。這幾天正在實做一個user mode應用程式集，規範一個 Framework，能用 C/C++ 開發 AJAX Web Application，如此可確保footprint 與 performance都有不錯的表現。可應用於Router / Wireless AP / Embedded controller，參考硬體平台為ARM與MIPS，此專案暫定命名為Ajax/Embedded，中期的計畫就是能整合進FON (La Fonera)，以及銜接kHTTPd。

今天做了一個Preview / Proof-of-Concept的版本，展示一個GMail-like郵件撰寫與拼字檢查的Web application，連同Web server、Application Framework，以及Ajax engine，大約佔了2Mb的空間，雖然比其他Ajax解決方案來得省，不過很明顯有頗大的進步空間。

對於Ajax/Embedded來說，不僅效能與空間可獲得最佳化，事實上還可避免常見的XSS (Cross-Site-Scripting) 安全性議題，更可沒有負擔地與底層整合，比方說Wireless router查詢硬體狀態的設計就能直接呼叫ioctl。為了避免程式開發者耗費過多時間在調整UI，Web UI Framework本身必須提供夠高階的event-driven model，目前已經有類似Gtk+/Qt的Signals-Slots機制。

大於與小於50000的差異

2007-01-28T17:25:00.000+08:00

在zhcon的basefont.cpp中看到這一段程式碼時，心中突然有了些感觸。

下面所記載的程式碼，主要的目的是判斷在字型檔大於50000Bytes時，就改採用memory mapped的方式來配置，因為CJK所用的字型大部分大於這個容量，所以得另外作一些處理。而這些細心的念頭, 是在FreeType的PCF部分，還有libXFont的PCF中找不到的。想當然爾，國外地區的Hackers只需要用到ASCII的字型，誰會去關心這樣的細節呢？

因此，對於這些CJK的基礎建設，我們更應該主動去作才是。

若我們不作，還有誰會來作？

if (mBufSize > 50000) {
//hzfont use mmap
mpBuf = (char *) mmap((caddr_t) 0, mBufSize, PROT_READ,
MAP_FILE | MAP_SHARED, mFd, (off_t) 0);
if (mpBuf == MAP_FAILED)
throw (runtime_error("error in mmap gbfont!"));
} else {
//ascii font read to buffer
mpBuf = (char *) new char[mBufSize];
unsigned nread = read(mFd, mpBuf, mBufSize);
if (nread != mBufSize)
throw (runtime_error("error in reading asciifont!"));
}

你要慢跑還是漫跑?

2007-01-24T00:15:00.000+08:00

剛退伍的我，常有一種很深的學習焦慮感，尤其在希望早點獨立自主的自我期望下，凡事都急求速成，什麼東西都沾一點，卻又不夠深入。弄到最後，一件都沒有好好的學成，心情也跟著低落。

逛Blog時碰巧讀到 "Teach Yourself Programming in Ten Years" 這篇文章，作者提出了對人人學程式設計急求速成的反問，並用他的經驗告訴我們，那些求速成所花的時間, 根本就不夠養成一個真正的程式設計師。網路上形形色色的成果展示，或是創意作品，也許只有短短幾分鐘，但可知作者在背後花了多少的時間和心血，才能達到這樣的能力？

正所謂，「台上十分鐘, 台下十年功」。

之前讀到李四端對於新聞工作的感想「你要新聞慢跑還是漫跑？」，也是心有所感.，或許在汲汲騖騖的生活中，也要找機會停下腳步來想一想，自己是否真的熱愛所投身的工作、事業？還是只是漫不經意的走馬看花。

最近洽巧讀到一篇值得一看的程式設計學習的導引，"How To Become A Hacker"，除了呼應了"Teach YOurself Programming in Ten years" 所表達的觀念，也鼓勵讀者多學習性質不同的程式語言，並嘗試以不同語言的性質來思考問題。

小小繞了一圈操場，才發現真正要走的路，還很長很長...

RT executive

2007-01-23T17:19:00.000+08:00

作為RT nanokernel的應用呈現，最近花了一些時間發展相容於RTLinux-GPL的小型RTOS，目標是銜接眾多RTLinux的modules與RT applications，但不需要種種Linux沈重的包袱，僅實做最小的虛擬記憶體管理、RTLinux-GPL相容APIs、更精簡的TLB與記憶體快取機制，同時能充分控制硬體，至於原本Linux applications (non-RT tasks)，則由RT nanokernel建立特定的domain以運行。

OSDC.tw 2007 is coming

2007-01-09T21:26:00.000+08:00

OSDC.tw (Open Source Developer's Conference in Taiwan) 2007 即將在四月份舉辦，Mat與我都準備提案，希望屆時可分享我們最近的成果。

Mat 的提案名稱為："Unicode Console InputMethod Framework"，以下是提案內容：

在console輸入中文真的非常麻煩，常常需要透過其他媒介才行。在觀察當時的console上輸入法相關的程式和實作方式後，發現兩個必須要徹底解決的問題：
輸入法的支援幾乎都是寫死在程式裡
大部分沒有接軌國際架構
這些問題使得重複的基礎建設一再消耗Programmer的力氣。於是UCIMF提出以Shared Lib的方式，並用Dynamic Loading的方法來克服這兩個難題。未來幾個期待努力的方向，包括:
與SCIM接軌
用VT100的Control Sequence顯示組字

也就是將這兩年來開發UCIMF的歷程予以公開，不同以昔日閉門造車的途徑，UCIMF成功銜接IIIMF與OpenVanilla等輸入法架構，並且這個Unicode Console也支援PCF與TrueType字型描繪，提供Linux輕量卻完整的多國語文終端機解決方案。

而我的提案名稱為："RT Nanokernel for Embedded Linux"，以下為提案內容：

在台灣，開發一個新的作業系統並非不切實際的工作，相反地，在銜接Free / Open Source software運動巨變的同時，其中很重要的理念就是最佳化、通用性，與客製化。Nanokernel/Hybrid-kernel 的提出，就是針對應用需求，如行動裝置的進階能源管理機制等需大量軟硬體協同開發的技術項目，提供一種新途徑。

眾多Realtime Linux系統的提出，證明可在符合特定需求的Hard Realtime OS上面運作修改過的Linux Kernel，以兼具即時任務需求與既有 Linux 應用程式相容性。在資訊產業有句金言：「沒有完美的技術，只有合用的技術」，本議題以日漸成熟的nanokernel /para-virtualization等技術為基礎，提出輕量級且易於擴充的新設計，讓Embedded Linux發揮更大的威力。

Realtime技術已限不於自動控制，事實上，在移動裝置也能透過RT nanokernel技術，不必大幅改寫系統，卻可提昇特定需求的可靠性與穩定性，如進階能源管理或高效能I/O處理。這樣一來，眾多的Linux應用程式不僅能在更多的平台運作，更可因此創造更大的價值，這也是我們強調"Programming 2.0"概念的展現。

期待您的指教！

關於PCF的連結

2007-01-05T14:49:00.000+08:00

在網站搜了一下，才發現PCF的資料並不如想像中的那麼多，找到的網站，幾乎都是格式轉換的用法，很少有提到PCF的規格和程式碼，在wikipedia甚至沒有專頁的介紹。

少歸少，還是找到了一些不錯的技術文件如下:

「 BDF的規格書」、「 PCF的規格」眼尖的人可以發現這裡可以找到大多數字型檔的規格書: Font File Format，這些資料是FontForge用心整理的, 對字型工作者提供莫大的幫助，而主頁有放正體中文翻譯的文件教學,，內容很棒！
「BDF&PCF的深度文件」(日文) 因為是日文，所以從中得到的資訊很有限，不過有介紹到兩個字型的資料結構，內容相當深入，搜一下Google，發現作者多賀奈由太就是寫hexadecimal dump tool(hex)的人，難怪...
"Unicode fonts and tools for X11" 這篇文章也介紹了不少字型的資訊，尤其在最後兩三章提供了不少關於字型工具的聯結，很有幫助。
"QPF(QT Preredered Font)" 隨手逛到Qtopia也有自己的字型檔，不過他也支援Freetype的字型引擎，這讓我想到Freetype能否進一步輕量化，提供Embedded System高品質的字型引擎？不過文中也提到Unicode字型最大的弱點：
All supported fonts use the Unicode character encoding. Most fonts available today do, but they usually don't contain all the Unicode characters. A complete 16-point Unicode font uses over 1 MB of memory.

寫到這裡，沒想到查個文件, 東點點西點點，就花了一個下午的時間。