我們在今年八月中旬的 COSCUP 研討會中，很榮幸地向與會的朋友介紹 0xlab 若干新的開放原始碼專案，本文稍作整理回顧。0xdroid 是 0xlab 最早的一項整合性開放原始碼專案，目的是建構於 Beagleboard 開放的硬體之上，提供 Android 的參考實做環境，經過一年多的累積，裡頭的成果被帶到不同的移動裝置中，比方說手機與 Tablet。今年二月份，有幸在 Mobile World Congress 2010 展示基於 Android 的移動裝置，Tieto 也在 TI OMAP3 平台展示 0xdroid，這些都讓我們更有信心，擴展到多元的應用。

這半年間，延續 0xdroid 的經驗，我們發展 / 貢獻以下專案：

• 0xRobocat : 與 CATCAN 合作的專案，目的是打造一組控制伺服馬達與相關零組件的軟體框架，可提供給 Android 或 GNU/Linux 使用，以 Apache License 2.0 授權釋出。除了用於打造機器人外 (是真的可走動的 "Android")，本專案可用於 Android 裝置 (如手機) 的自動測試
  
• 0xBench : 有鑑於 Android 上的系統效能評比程式，不是不完整，就是非開放原始碼，所以我們決定重新打造一個。0xBench 可從 C 函式庫/系統呼叫的層面，一路從 Dalvik VM 評測到 Android framework，仍持續擴充，並且我們提供 Web service，允許貢獻評測的結果，用互動的方式來分析。程式主體是 Apache License 2.0 授權
• android-toolchain : 0xlab 特製的 GNU Toolchain，以 Android team 的成果為基礎，整合來自 Linaro Toolchain Working Group 的改善。這些主要是 GNU GPLv3 授權
  
• Android Open Source Project (AOSP) : 提交 0xlab 過去在 TI OMAP 與 Qualcomm 72xx 平台的一些修改，經過公開的 Review 機制，慢慢整合到 AOSP
• CyanogenMod : 社群版本的 Android，在 Nexus One, HTC Dream 等裝置有相當優越的表現，收錄若干來自 0xlab 的改良，比方說 Bluetooth HID profile
  

除了以上的開放原始碼專案，我們內部正進行一個基於 Android 的新型態應用，未來也會將相關的專案程式碼，以開放原始碼的形式釋出，完整的列表可參考 0xlab Projects。至於 AOSP，我們現有更改的項目是：

• build - 調整 Android build system、修正工具程式的瑕疵
• bionic - 提供 ARM optimizations，針對 ARMv6/ARMv7
• PixelFlinger - 基本的 refactoring，以及 ARM 實做的改良
• libpng / libz - 利用 GCC visibility，進一步縮減 code size
• elfcopy - ELF 工具的調整
• bionic / apriori / build - 支援 DT_GNU_HASH，加快動態連結的速度
• toolchain - 加強 build system 的彈性

以上，歡迎舊雨新知給我們支持與指教，謝謝。

read on

沈寂的一段時間，現在 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

最近 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

前文「對 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

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

這幾周，0xlab 的開發者都在準備新的 Android distribution，標的平台是 Beagleboard，可望在 COSCUP 到來前釋出，過程中順便寫了一個簡單易用的 Image Installer，可從 SD card 開機並將可運作的 Android system image 植入 Beagleboard 之上的 NAND flash，而不必依據繁瑣的流程，才能體驗我們的新創作。目前已有初步成果，可參見下圖：
已實做的特徵有：

• 僅需要放置單一檔案 (uImage.bin) 到 VFAT 格式的 SD card 中，在 Beagleboard 插入 SD 開機進入 Image Installer，即有簡單俐落的 UI
• 整個 Image Installer (kernel + busybox + file system + MTD tools + UI) 佔用不到 2Mb 的空間
• 預設讀取 SD card 裡頭的 android_beagle.ubi 與 0xkernel-beagle.bin 兩個檔案，自動寫入 NAND flash，並設定必要的 u-boot 環境參數。放置 image 檔案的動作可在多數的作業系統平台下進行，舉凡 MS-Windows, GNU/Linux, Mac OS X 等等，只要支援 VFAT 與 SD/MMC 讀寫即可

貌似單純的 Image Installer 開發，卻折騰了好幾天，歸納有若干因素：

• 準備在 Beagleboard/OMAP3 環境下可最小可啟動的 Linux image，需要考慮到 device driver 間的相依性，比方說若將 USB subsystem 完全移除的話，很可能無法正常開機。又，OMAP3 內建的 MFD (Multi-Function Device) 要注意到驅動順序的議題，不然功能無法正確運作
• 要留意 TI OMAP3 / Beagleboard 啟動順序，即使 boot from SD，但 u-boot 與其 u-boot bootenv 很可能仍讀取自 NAND flash，這導致後續啟動的 Linux kernel 採用了預設值，致使 Image Installer 無法在預期的環境參數下啟動
• ARM/Linux 啟動過程中，會試圖自一段特別的記憶體空間讀取 command line parameters，這空間稱為 ATAGS，係由 boot loader (以 Beagleboard 來說就是由 X-Loader 帶起的 u-boot) 填寫的記憶體內容，也就是所謂的 u-boot bootenv。但對 Image Installer 來說，雖然 u-boot 給予頗大的彈性，但也使得執行環境充滿不確定性

關於 ARM/Linux 的 ATAGS 實做程式碼可參考 arch/arm/boot/compressed/head.S 與 arch/arm/kernel/setup.c 兩個檔案，筆者做了簡單的 hack 以迴避：

--- android-omap.orig/arch/arm/kernel/setup.c 2009-08-08 18:40:30.000000000 +0800
+++ android-omap/arch/arm/kernel/setup.c 2009-08-08 18:43:09.000000000 +0800
@@ -613,7 +613,6 @@

static int __init parse_tag_cmdline(const struct tag *tag)
{
- strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
return 0;
}

由此可見，原本的動作是將 u-boot 對 ATAGS 寫入的資料寫入預設的 command line。至於安裝 Linux kernel image 與 root file system image 到 NAND flash 後，還得作 (NAND 裡頭的) u-boot bootenv 的編輯動作，這部份的工作原理可參考 Openmoko 開發的 Devirginator。喔，忘了說，這些惱人的限制，會在轉換到 Qi boot-loader 後迎刃而解 :)

read on