EGLIBC於S3C2410 ARM SoC的體驗

稍早於「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/

避免cross-compile的陷阱：libtool

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

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

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

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

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

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

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

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

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

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

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

# Is this an already installed library?
installed=yes

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

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

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

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

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

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

Install Poky from scratch

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

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

$ svn co http://svn.o-hand.com/repos/poky/trunk poky

2. 安裝必要之套件

$ apt-get install patch diffstat texi2html cvs svn bzip2 tar gzip gawk makeinfo qemu

2.1. 如果你要自行編譯qemu for poky還須安裝

$ apt-get install gcc-3.4 libsdl1.2-dev zlib1g-dev

3. 設定環境

$ source poky-init-build-env
確定/bin/sh指向bash，如果為dash則在編譯perl-native時會有問題

4. 編譯 Image

$ bitbake oh-image-pda

5. Try it :)

$ cd $OEROOT/build/tmp/deploy/images
$ poky-qemu zImage-qemuarm.bin oh-image-pda-qemuarm.ext2

6. 編譯qemu

$ bitbake -c build qemu
PS:如需移除套件可使用 bitbake -c clean $packname

7. 編譯完qemu之後，會放在 $OEROOT/build/tmp/work/armv5te-poky-linux-gnueabi內，使用自行編譯的qemu執行poky

$ sudo $OEROOT/build/tmp/work/armv5te-poky-linux-gnueabi/qemu-0.8.2+cvs20060723-r4/install/qemu/usr/bin/qemu-system-arm -kernel zImage-qemuarm.bin -append "root=/dev/sda console=ttyAMA0 console=tty0 mem=64M" -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=/home/blue119/poky/scripts/poky-qemu-ifup -M versatilepb -hda oh-image-pda-qemuarm.ext2 -usb -usbdevice wacom-tablet

Install OpenMoKo from MokoMakefile

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

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

$ apt-get install python patch m4 make python-psyco ccache perl diffstat \
wget curl ftp cvs subversion git

2. 於建構系統安裝Openembedded：
i. 在apt檔案庫追加Openembedded所需的套件：

$ echo "deb http://www.openembedded.org/dl/ packages/" >> /etc/apt/sources.list

ii. 安裝monotone 0.32

$ wget http://monotone.ca/downloads/0.32/monotone_0.32-0.1_i386.deb
#版本若不一樣可能會造成問題，此版本是我使用過沒問題的

$ update-alternatives --config git
＃選擇 /usr/bin/git-scm來提供git的實做，而非用/usr/bin/git.transition

3. 安裝輔助性的套件：

$ apt-get install libxml2-utils xmlto passivetex
$ apt-get install docbook

4. 建立專屬的$OMDIR目錄：

$ export OMDIR=$HOME/moko ; mkdir $OMDIR ; cd $OMDIR

5. 取得MokoMakefile:

$ wget http://www.rwhitby.net/files/openmoko/Makefile

6. 設定環境

$ make setup
PS: 請確定/bin/sh指向bash，如為dash則編譯perl-native時會有問題

7. 開始建構：

$ make openmoko-devel-image

8. 以模擬環境來執行：

$ make build-qemu
$ make flash-qemu-local
$ make run-qemu

以下是參考的執行畫面：

轉換OpenEmbedded的repository為Subversion系統

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

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

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

darcs get http://darcs.arstecnica.it/tailor/

Tailor使用Python開發，安裝也很簡單：

cd tailor ; sudo setup.py install

我們需要編輯一份Tailor所需的專案檔案，描述monotone轉換到Subversion的細節，舉例來說我們建立一個名為 "task.project" 的檔案，以下是其內容：

[DEFAULT]
verbose = True
debug = True

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

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

[svn:target]
module = /openembedded
repository = file:///src/repos

SVN的檔案庫 "file:///src/repos" 自然就是存放轉換後的版本系統所用，我們應該事先建立，操作程序如下：

$ mkdir -p /src/repos
$ svnadmin create --fs-type fsfs /src/repos

注意，建立時必須選擇FSFS的型態，否則Tailor處理可能會遇到問題。最後就是執行Tailor的操作，使用方式如下：

$ tailor task.project

沒意外的話，我們就可以看到這之間的轉換過程，最後會轉換輸出於檔案庫 "file:///src/repos/openembedded" 之中，這時候可以用SVN自己的merge工具或SVK的smerge進行套件的更新維護，畢竟我們感興趣的套件就那幾個而已。