Marley & Me

「一條沒有規矩的狗和一對新婚夫妻的生活，最後男主角死了，兩個配角也生了三個小孩，The End！」

DirectFB on Beagleboard

DirectFB 是 graphical library，支援 input event handling、window management 等，我們藉由 DirectFB 可以在 embedded system 上建立 GUI 的環境，DirectFB 透過 framebuffer 或 /dev/mem 控制底層硬體，所以在開始之前，先確定這兩條路在 kernel 裡有一條是通的，若是走 fbdev 別忘了在 rootfs 裡建立 /dev/fb0。



雖然是「DirectFB on Beagleboard」，但和 beagleboard 沒有太大關係，我只是把它當作 demo 的平台。CPU 是 TI OMAP3530 (Cortex-A8 / armv7a) 我並沒有特別針對 armv7a 作最佳化，同時在編譯 DirectFB 時也沒有將 beagleboard 支援的 3D 功能 enable (少了 SDK...)，所以以下的動作是可以套用在其他 arm 的平台上。

單純想要手動去建立一個系統，從 BusyBox 開始編起，慢慢拼湊自己想要的系統，唯一的好處是整個過程會遇到很多問題，所以會學到一些東西，對系統的掌握也更多。OpenEmbedded 是個好東西，只是每次下個指令就把系統建好的感覺很不踏實 ;)



下載每個套件的 source，由於套件的相依性，因此由 zlib 開始編譯最後則是 Lite，Lite 是以 directFB 為基礎的 toolkit，編譯它的目的只是為了執行它的 samples 驗證 directFB 是可以動的(此外，Lite 也是 DFBterm 的相依套件)，如果有 touchscreen 那麼 tslib 是必要的套件。

可以直接下載每個套件對應的 build-script，直接修改，例如：

make clean
STAGING=/home/sean/openmoko/embedded-gui/dist
./configure --prefix=/usr \
--host=arm-none-linux-gnueabi \
--enable-shared=yes --enable-static=yes \
CFLAGS="-I${STAGING}/usr/include" \
LDFLAGS="-L${STAGING}/usr/lib"
LIBS="-lz"

make DESTDIR=${STAGING} install

把 STAGING 改成你自己的工作目錄， --host 則是你使用的 cross-toolchain。另外， jpeg 及 directfb 先天營養不良，從官網抓下來的套件就無法順利編譯或安裝，所以下面的 patch 要先打上...

fix_errro_when_install.patch
fix_missing_libtool_error.patch
add_missing_header_file.patch

在編譯 (cross-compile) 套件時，configure 的動作要特別小心，好一點的狀況是有 error 產生，最麻煩的是 configure 時告訴你沒有問題，編譯時卻發生錯誤，事實上在 configure 程序就已經出錯了，通常是在作環境變數的檢查時 configure 搞混了，所以我會利用 screen 將整個過程紀錄下來，再稍微看一下。

以下面例子而言，在 configure 前，特別指定 LIBPNG_CONFIG 的用意是因為 configure 會找到 /usr/lib/libpng-config，但這是我 host (x86) 上的，並不是真正要的

STAGING=/home/sean/openmoko/embedded-gui/dist

LIBPNG_CONFIG=${STAGING}/usr/bin/libpng-config ./configure \
    --prefix=/usr \
    --host=arm-none-linux-gnueabi \
    --target=arm-none-linux-gnueabi \
    --enable-static=yes --enable-shared=yes \
    ...

編到 directFB 套件我們就可以先把所有產生的 header / lib / binary 等，放到 rootfs 上作測試，執行 dfbscreen 如果沒有意外的話會給你沒營養的錯誤訊息：

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.3.1 |~~~~~~~~~~~~~~~~~~~~~~~~~~
       (c) 2001-2008  The world wide DirectFB Open Source Community
       (c) 2000-2004  Convergence (integrated media) GmbH
     ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2009-05-15 09:48)
(!) DirectFB/core/system: No system found!
(!) Tools/Screen: DirectFBCreate() failed!
   --> No (suitable) implementation found!

用 strace 試著找出問題點，是因為編譯 directFB 時把 /home/sean/openmoko/embedded-gui/dist 路徑寫進產生的 library 及執行檔裡，所以執行 dfbscreen 時，如果在該目錄裡找不到它需要的，便丟出錯誤訊息。找不到是必然的，因為編譯出的檔案最後是放在 rootfs 的 / 目錄下。

路徑寫到編譯產生的檔案裡是 linker 參數 rpath 造成的，如果我們是在系統下編譯套件並把該套件安裝在系統下，那麼寫入路徑是沒有問題的，但 cross-compile 就會有麻煩了，假設你編譯了套件 A 並將它安裝在 ${STAGING} ，假若套件 B 相依於套件 A，在編譯套件 B 時必須指定套件 A 的安裝路徑，這時候就有可能發生 rpath 的問題了，我是透過修改 configure 檔，把參數 rpath 改成 rpath-link 解決這個問題，編譯後可以檢查是否還有 rpath 的影響：

#!/bin/bash
find $1 -name "*" | xargs arm-none-linux-gnueabi-readelf -d | grep RPATH

change_rpath_to_rpath-link.patch
jpeg_rpath_to_rpath-link.patch

討論 cross-compile 的路徑問題可以參考 Avoiding libtool minefields， 詳細說明會遇到的狀況。繼續編譯 Lite 會出現錯誤，類似：

arm-none-linux-gnueabi-ranlib .libs/liblite.a
creating liblite.la
/bin/sed: can't read /usr/lib/libfusion.la: No such file or directory
libtool: link: `/usr/lib/libfusion.la' is not a valid libtool archive
make[1]: *** [liblite.la] Error 1

找不到 /usr/lib/libfusion.la，root cause 也是因為路徑的問題，函式庫之間會有相依性，我們也許只知道某個套件需要函式庫 A，但不清楚 A 是相依於哪些函式庫，libtool / .la 則是可以用來解決這樣的問題，只是在 cross-compile 時，反而造成問題。以下節錄 libdirectfb.la 檔：

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

# Libraries that this one depends upon.
dependency_libs=' -L/home/sean/openmoko/embedded-gui/dist/usr/lib \
        /usr/lib/libfusion.la /usr/lib/libdirect.la -lpthread \
        /home/sean/openmoko/embedded-gui/dist/usr/lib/libjpeg.la \
        /usr/lib/libpng.la -lz -lm /usr/lib/libfreetype.la \
        /usr/lib/libts.la -ldl

...
dependency_libs 會提供該套件相依的 library，但是路徑卻是錯的，解決的方法是把所有 *.la 的 dependency_libs 注解掉，取而代之的是在 configure 時就指定 linker or compiler 所需的參數：

#!/bin/bash
find $1 -name "*.la" | xargs sed -i 's/dependency_libs/#dependency_libs/g'

最後附上 lite_simple 在 beagleboard 上的執行畫面

星期日一早帶齊裝備後就到內湖山裡做野採，對象是青苔，除了長在山壁上的，生長在石頭上的青苔也是這次採集的目標，溪邊的山璧很適合青苔的潮溼、陰暗生長環境。



在山裡(或溪裡)活動，保持靈敏聽覺和嗅覺是很重要的，如果聽到奇怪的聲音或聞到奇怪的味道，慢慢地退到安全的地方。往溪水下游的方向走去，走沒幾公尺先是聞到一股惡臭，同時聽到一群拍打翅膀的嗡嗡聲，經驗法則附近有屍體，就回頭往上游方向了...

想起小時候和表弟在鄉下大水溝裡抓魚的恐怖記憶，抓的很開心的時候，旁邊浮來全身發漲發黑的死豬(還有死雞)，所以我到現在還是會害怕看到水裡的麻布袋 ;)

人生就像飄在水面的麻布袋，不打開看，你永遠不知道裏面裝甚麼死人骨頭...









遇到剛羽化的蜻蜓幼蟲水蠆(ㄔㄞ')






儘量不要一個人跑到山裡，很難預測會有甚麼突如其來的事情發生，找個伴。這次的主角青苔正在育嬰室，如果有活下去就可以出來亮像了 ;)

比肥的

Bootable USB Image

前幾天，不務正業的幫公司處理工廠生產的問題，作為代工廠，系統影像檔是由客戶提供，所以測試程式不可能讓你包在出貨用的 Image 裡，一來是因為「髒」，再者是程式自身的需求或許需要某些套件的搭配，比較好的方式為測試程式量身打造一個系統。

要求很簡單，Boot From USB、越小越好、開機後直接執行測試程式，且可以簡單、快速的大量複製該測試系統，Moblin Image Creator 可以幫助我們簡化整個過程，把整個框架建好，我們可以專心在整合測試程式，同時安裝程式需要的套件、modules，接著手動修改設定檔，整個過程就像在拼圖一樣。即便有了 MIC，手動的地方還是不少，最後作出來的影像檔大小 300 MB，雖然還可以縮減，但以現在隨身碟的容量及 USB 2.0 的傳輸速度，其實意義不大；對於大量複製的要求，工廠只要執行 dd bs=1024 if=usb.img of=/dev/sd? 便可以做好測試用的隨身碟。

學習應該是這樣，首先你找到黑盒子幫你解決問題，接下來要去了解黑盒子，最後你試著做出一個很陽春但可以用的透明盒子。我將整個過程抽出重新寫成 Scripts，一樣可以作出符合要求的檔案 ;)

重點是，這樣的過程，你必須不斷地把做好的 Image 寫到隨身碟，關機，重新開機(Boot From USB)，檢查作出來的隨身碟能不能正常開機，如果你真的不斷重複這樣的過程，我只能說連猩猩都會利用工具釣魚了... ;)



透過 QEMU，不必重新開機，就可以測試我們做好的隨身碟，利用 lsusb 得到 usb flash drive 的 vendor 及 product id 後，利用 qemu 模擬整個開機的過程

sudo qemu usb.img -no-acpi -usbdevice host:3538:0050

不務正業，我就是討厭 Notebook...

Kenting

四月的某個週末，因為姊夫參加在墾丁舉辦的國際鐵人三項比賽，就趁著這個機會和家人一起再回到墾丁，還好，今年四月的氣溫還是舒服的 ;)

我們不是參賽者，比較像是自由行的人，就這樣開著車沒有目地的到處跑。跑去海角七號的場景拍照，跑去四重溪享受只有我們一家人的溫泉，天空還飄著毛雨，跑去只有我們的沙灘，順便找所謂的港口茶，最後在慢速的開在漂亮的佳鵝公路上。





或許是被海趨使，回到台南後，就立刻拖著我家的狗跑到黃金海岸，站在海裡，迎著海浪的沖擊，對著海大笑(狗爬式很搞笑)，等到太陽西下，遠方燈塔的橘燈和藍燈亮起，瞬間陷入沈寂裡。

像這樣把時間留給家人，也是不錯的生活(茶)...