0xdroid 正式支援 DevKit8000 開發板

沈寂的一段時間,現在 0xdroid 又恢復活躍的開發。正如稍早在 0xlab-devel 郵件討論區提及 "Return back to open source world",我們陸續將之前開發的成果,貢獻到自由軟體的世界,環繞在 0xdroid 的項目有:

  • Beagleboard 一貫的完整支援,不只是將 Android 運作起來,還要提昇整體的效能與可用性
  • 除了支援 Beagleboard 外,對 DevKit8000 也有充分的支援
  • 擴充 esuit 並整合 Android CTS (Compatibility Test Suite) Sikuli,提供涵蓋 board-level, API-level, Application-specific 的自動測試框架
  • 對 Android 為基礎的系統作全面性的功能、效能,與可靠度評比,以及整合上述的自動測試框架,以驗證量化系統的品質
在 kanru 的努力與若干網友的貢獻 (hychen, Fred, itszero) 下,現在對 DevKit8000 的支援已加入到 GIT repository,以下是執行時期的照片:
(0xdroid 的桌面與 Launcher)
(調整為直式顯示,符合原本 Android 的預期輸出假設)
目前支援 Android Donut 與 Eclair,在 0xdroid 即是 beagle-donut 與 beagle-eclair,需要搭配最新的 0xlab-kernel,對 DevKit8000 週邊做出更好的支援。以下是簡要的功能特徵描述:
  • 支援 DevKit8000 特有週邊:Ethernet, LCD panel / touchscreen, keypad
  • 提供對應的使用者介面 (UI) 設定程式,包含 Ethernet 與 Touchscrren calibration UI
  • 延續之前 0xdroid 在 TI OMAP3 平台的效能改善成果
近期內我們將會釋出新的 image installer,並持續改善 TI OMAP3 平台的 Android Eclair,而在今年的 OSDC.tw 研討會上,有個針對 0xdroid 的議程,歡迎前來指教,也希望對 0xlab 一系列開放原始碼專案有興趣的朋友,可來 0xlab-devel 郵件討論區參與討論,謝謝!

read on
Posted 張貼者: jserv 於 中午12:15 on 2010年3月10日 星期三 | 1 意見
Filed under: , , , , , ,
 

libacc : Android 2.0 內建的輕量級 C Compiler

Android 2.0 (Eclair) 原始程式碼已於一個月前釋出,在目錄 system/core 下有個 libacc 的子項目,這是開發者修改自 Fabrice Bellard 的大作 OTCC (Obfuscated Tiny C Compiler),以 C++ 與 Android 的執行時期函式庫重寫。libacc 的功能是提供給 Android 2.0 的 RenderScript 一個 C-like 語法的描述,如此一來,開發者可撰寫高效能的視覺效果與動畫,不過這部份並未完成,詳情可參考 "Android renderscript, more info' and an example application" 一文。

關於 libacc 的整合部份,可參考 frameworks/base/libs/rs 目錄下的兩個檔案:

  • rsScriptC.cpp
  • rsScriptC_Lib.cpp
筆者準備了一份可單獨執行於 GNU/Linux 環境的套件:"libacc.tar.bz2",除去 Android 的相依性並補上 Makefile,測試方式如下:
libacc$ make
g++ -I./include -DHAVE_PTHREADS -c acc.cpp
gcc -I./include -DHAVE_PTHREADS -c hashmap.c
gcc -I./include -DHAVE_PTHREADS -c logd_write.c
g++ -I./include -DHAVE_PTHREADS -c tests/main.cpp
g++ -I./include -DHAVE_PTHREADS -c tests/runtimeTest.cpp
g++ -o main \
acc.o \
hashmap.o \
logd_write.o \
main.o \
-ldl
g++ -o runtimeTest \
acc.o \
hashmap.o \
logd_write.o \
runtimeTest.o \
-ldl
libacc 的 Code generator 支援以下硬體架構:
  • x86 / IA32
  • x86_64
  • ARMv5
以 IA32 的環境為例,可透過測試程式來驗證 libacc: (參數 -R 表示作執行的動作)
libacc$ ./main -R tests/data/hello.c
Executing compiled code:
Hello, world
result: 0
其中 tests/data/hello.c 的內容為:
libacc$ cat tests/data/hello.c
int main() {
printf("Hello, world\n");
return 0;
}
若平台是 ARM 的話,還可以支援反組譯輸出,libacc 是 RenderScript 背後很重要的基礎建設,允許動態編譯 Android Graphics 的 RenderScript,輸出成機械碼並執行。參考檔案 tests/runtimeTest.cpp 可得知 RenderScript 的寫法,整個 libacc 可內嵌於程式中,比方說:
const char* text = "void op_int(int a);\n"
"void op_float12(float a, float b, float c, float d,\n"
" float e, float f, float g, float h,\n"
" float i, float j, float k, float l);\n"
"void script() {\n"
" globalVar += 3;\n"
" op_int(123);\n"
" op_float12(1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0);\n"
"}\n";
這個字串經過 libacc 的函式呼叫後,可得到以下的編譯與執行結果:
libacc$ ./runtimeTest
Executing script:
op_int(123)
op_float12(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
After script globalVar = 20
目錄 tests 還包含可在 Android 環境執行的自動測試 Python script。

read on
Posted 張貼者: jserv 於 下午4:53 on 2009年12月9日 星期三 | 3 意見
Filed under: , ,
 

在 0xdroid 充分發揮 Beagleboard/OMAP3 的硬體特性

最近 0xlab 的開發者持續改善 0xdroid,在 gitorious 的團隊排名維持在前五名的活躍程度,除了稍早提及針對 ARMv7 與底層軟體架構的改進外,0xdroid 也加入了對 Beagleboard / TI OMAP3 硬體更充分的支援。現在與多媒體處理相關的架構圖可參考以下:

紅色的部份是 Android 的 framework 層面 (Media framework, Media server),而藍色則是實做 framework 所需服務的元件 (如 OpenCore),剩下綠色的地方自然是 0xlab 關注、與硬體平台相關的元件,這裡簡要列出:

  • libaudio : 透過 ALSA 處理 Audio In/Out,針對 TI OMAP3 平台做了調整
  • libcamera : 以 V4L2 (Video For Linux) API 為基礎,提供上層 Android framework 對 camera 所需的硬體支援。透過 TI OMAP3 平台的 video overlays 作 preview 影像處理,並善用 TI DSP 的能力作 JPEG 處理
  • libopencorehw : 銜接 OpenCore,允許透過 TI OMAP3 平台的 video overlay 作高效能顯示處理
  • liboverlay : 讓 libcamera 與 libopencorehw 共用的 video overlay 操作模組
  • TI DSP / OMX : 透過 OpenMAX 標準介面,使用 TI DSP 實做的硬體多媒體 codec 運算
  • FFmpeg / OMX : 透過 OpenMAX 標準介面,使用針對 ARMv7/NEON 優化的硬體多媒體 codec 運算,這部份採納 FFmpeg 的基礎
目前上述的硬體特有的元件已有初步實做,待驗證與調整 HAL 後,就會陸續整合到 0xdroid 的公開 repository,至於開發相關的議題,可到 0xlab 的郵件討論群組 0xlab-devel 交流,謝謝。

read on
Posted 張貼者: jserv 於 下午2:38 on 2009年9月18日 星期五 | 0 意見
Filed under: , , , , ,
 

在 Beagleboard 上比較 Dalvik 與 CVM-jit 的效能

前文「對 String 操作的改進」與「Android Dalvik VM vs. Java VM」談及基於 CVM 引擎的 Java VM 與 Dalvik 的效能差異後,最近 0xlab 內部也因為挑選硬體平台,持續分析 Embedded CaffeineMark 一類量化效能的報告。參考的硬體組態是 OMAP3/ARMv7 500 MHz,粗略的效能評比如下圖:

Dalvik 取自 0xdroid (cupcake + backported from donut),而 CVM-jit 則源自 phoneME CVM svn r19264,整體分數為:

  • Dalvik VM : 1034
  • CVM + jit : 7526
CVM 的組態設定:
  • cached constant
  • cached constant inlining
  • array init bounds check elimination
  • Hardware fpu = NEON
  • AAPCS
當然 Just-In-Time compiler 不是萬靈丹,從上述效能評比可發現,CVM 在若干地方做了重要的微調,比方說透過 CNI 實做若干 class library 的關鍵 method,以及善用硬體 floating-point 操作 (注意:本組態未引入 ARMv6 與 ARMv7 的 Thumb2/Thumb-EE 指令集)。儘管 Android 團隊中 Dalvik 開發者 fadden 在郵件討論群組談及
Four String methods -- charAt, compareTo, equals, and length -- are
"inlined" by the VM, and are not going to get much faster.

There are probably a few others that could benefit from this
treatment, but I'm guessing that most string-centric processing in
Java will likely be dominated by the cost of String allocations. (The
above weren't inlined because of a measured performance need -- the
inlining was an experiment that needed a test subject.)
Dalvik 理論上可施加這些優化技術 (string allocation / native method inlining),不過目前開放的實做中,尚未引入 (至少在 donut branch 中)。即便在保持 pure interpreter 的架構下,現有 class library 與 GC (garbage collector) 仍可作些調整,以改善 Android 的應用程式執行效能與 (圖形應用導向的) 使用者互動反應表現。

read on
Posted 張貼者: jserv 於 上午10:54 on 2009年8月25日 星期二 | 4 意見
Filed under: , , , ,
 

SDL 在 Android SurfaceFlinger 的初步移植

本日仍在追蹤 0xdroid 的穩定性與效能議題,進行壓力測試時,順便將知名的 SDL 函式庫移植到 Android window system,更具體來說,就是允許在 Android Surface Manager (SurfaceFlinger) 上運作 SDL 應用程式,背景知識請參考 0xlab 圖形處理達人 olv 的簡報 "Introduction to Android Window System" (PDF)。依據 olv 提供的範例 SurfaceFlinger 操作程式,libSDL 可很快地加上 Android video backend,接著透過 libui 的 EventHub 取得來自 Linux input subsystem 的事件。現在初步的移植成果可參考下圖:
上圖展示一個以 SDL 撰寫的 NES 任天堂模擬器,顯示更新於新建立的 Android Surface 上,筆者將該 Android surface 的起始座標位置挪到 (100, 100),並設定其半透明度值,載入筆者最愛的泡泡龍 (Bubble Bobble) 遊戲 ROM。目前僅算堪用的狀態,未來要考慮到 Android Surface 限制 color space 為 RGB565 (針對 16-bit depth 顯示所做的優化限制),勢必得在 libSDL 引入若干 color space 轉換的繁瑣運算,可透過 ARM NEON 一類的硬體加速機制去改善效能。

read on
Posted 張貼者: jserv 於 晚上10:37 on 2009年8月13日 星期四 | 1 意見
Filed under: , ,
 

對 String 操作的改進

之前的文章「Android Dalvik VM vs. Java VM」提及純 interpreter 的 Dalvik VM 與具備 Just-In-Time compiler 的 JBend JVM (基於 CVM 引擎) 的效能比較,以修改過的 Embedded CaffeineMark 作為量化的依據,可發現 String 測試項目差了一個數量級 (491 vs. 5109),整體的分數是 1:4.18 (1811:433)。稍早 ansoncat 做了初步分析:

「這部分應該是由於在 CVM 中,使用了 CNI 來實作 String class 的重要操作 ... 因為 String 的分數拉高了平均,其它 benchmark 的效能差異會比平均分數的差異大的多」
目前 0xdroid 在不更動 Dalvik VM 實做的前提 (後續再談改進的途徑),對 bionic libc 的 string 相關函式作調整,移植來自 CodeSourcery/ARM 的 ARMv7 Thumb2 優化實做,就 micro-benchmark 的角度來說,效能改進約有 25% (初步分析,要考慮到不同的環境配置),但整合到 Android/Dalvik 的表現又是如何呢?筆者的實驗結果如下: (score 大者為佳)

測試環境是 Beagleboard (500MHz) 運作 0xdroid,以 ARMv7 GNU Toolchain 編譯,"armv7" 是 bionic 更動前的數據,而 "armv7-opt" 則是更動後的表現。很顯然發現,String 一項的改進大幅受到壓抑 (score = 1898:2140),致使兩者最終僅有些微的落差,可見 JNI 帶來 overhead 的著實不小。又,大部分應用程式的效能瓶頸往往在於圖形處理、系統資源的調度、檔案讀寫等 I/O 操作,所以現階段我們的想法是儘量調整 native 的部份,針對 ARM core 與 SoC 的特性作調整,並提出可行的輕量級 native method invocation 實做。

read on
Posted 張貼者: jserv 於 凌晨4:40 on | 0 意見
Filed under: , ,
 

強化 Android 的 shell

Android 預設的 shell 就是 /system/bin/sh 這個 process,移植自 NetBSD 早期的 sh 程式,原本功能算是完整,但被 Android 開發團隊移去相當多功能,致使在 shell 下的操作苦不堪言,只好透過 adb 作遠端指令的下達,但問題是,移植 Android 的平台在初期往往缺乏有效的連線機制,又需要作些調整與嘗試,實在很不方便。所以筆者就在 0xlab 最近釋出的 0xdroid 專案上,引入來自 Busybox 的 ash 實做,試著保持相近的 footprint 的前提下,提供更多的功能。

因此,我們有以下考量:

  • 必須動態連結到 bionic libc
  • 簡化 Busybox 的實做,修改 libbb 與對應的 applet
  • 保有 bash 相容模式, Line edit, history, readline 等 Busybox 特徵
稍早,0xlab 的成員 walkingice 就做了評估與實驗,讓整個 Busybox 得以動態連結到 bionic libc 並確保功能可運作,這部份有很多 hacking,暫時不談。現在這些更動已初步提交到 system/core repository。在 0xdroid 的 beagle-cupcake branch 下,相關的 ash 設定組態如下:
  • CONFIG_ASH_BASH_COMPAT
  • CONFIG_ASH_READ_NCHARS
  • CONFIG_ASH_READ_TIMEOUT
  • CONFIG_ASH_ALIAS
  • CONFIG_ASH_GETOPTS
  • CONFIG_ASH_BUILTIN_ECHO
  • CONFIG_ASH_OPTIMIZE_FOR_SIZE
  • CONFIG_ASH_EXPAND_PRMT
佔用的磁碟空間:
[build_host]$ ls -lh system/bin/{ash,sh}
87K 2009-08-13 02:24 system/bin/ash
98K 2009-08-13 01:15 system/bin/sh
佔用的記憶體空間:
[beagleboard] # ps
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 300 192 c00b2394 0000ca6c S /init
root 777 1 736 324 c0057648 afe0c3fc S /system/bin/sh
root 835 777 744 356 c0057648 afe0c3fc S /system/bin/ash
可以發現,新引入的 /system/bin/ash 佔用的磁碟與記憶體空間相似,但功能完整度卻大不相同,後者允許我們回顧歷史指令並編輯, 以及在 Embedded Linux 熟悉的操作環境。目前 ash 的移植還有很多調整改進的空間,不過算是堪用了,可在 init.rc 檔案中,將預設的 shell 指定為 /system/bin/ash。

read on
Posted 張貼者: jserv 於 凌晨3:33 on | 0 意見
Filed under: , ,
 
Developer at 0xlab.