0xlab

Development Progress Summary about 0xlab

2012-01-04T17:33:36+00:00

Last two months, I was so honored and delighted to be invited as the speaker at Embedded Linux Conference Europe and droidcon.NL. I shared the progress about our development and various improvements for Anroid Open Source Project. As the developer at Linaro, 0xlab already contributes some fundamental works, and these eventually become the base for further collaborations. The topic of the presentation is "Develop Community-based Android Distribution and Upstreaming experience", and you can check out the presentation material as following:

Develop Community-based Android Distribution and Upstreaming Experience <iframe frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/10773288" width="425"></iframe>

View more presentations by 0xlab

Recently, we are quietly improving the performance of Android ICS (4.0.x) and submitting patches to CyanogenMod as community collaboration. Most of them are merged in CyanogenMod, and we are moving forward in more areas to enhance Android software stack.

Look forward to your feedback and the opportunities to work with each other.

BT LE FindMe profile in Bluez

2011-09-02T14:51:16+00:00

There is a post in Bluez mailing list "Current status on BLE development". It tells us current BT LE status in Bluez and also shows some git repositories with their development. I try to build their kernel and the latest bluez. I made some experiments and understood more about FindMe profile in Bluez.

* Unstable kernel with Interleaved Discovery, RSSI Threshold monitor,
LE scanning and remaining SM patches
[1] http://git.infradead.org/users/vcgomes/linux-2.6.git (branch
proximity-integration)

* BlueZ Userspace
[2] git://git.infradead.org/users/cktakahasi/bluez.git proximity-devel

Experiment I: prepare one LE device only(Key Fob/Reporter/GATT Server) and one dual mode LE/BR/EDR device (Monitor/GATT Client) in Ubuntu machine. Key Fob runs immediate alert service. Bluez register the monitor service and it can write Alert Level to reporter. If Alert Level is mild or high, the Key Fob would ring. Then user can find where is the Key Fob. Reference to Immediate Alert Service (UUID: 0x1802) page and Alert Level(UUID:0x2a06) page.

Reference from Bluetooth.org site:
The Immediate Alert service is instantiated as a Primary Service. There is only one instance of the Immediate Alert service on a device. There is only one instance of the Alert Level characteristic in an Immediate Alert service. This alert continues until one of following conditions occurs:
• An implementation specific timeout
• User interaction on this device
• A new alert level is written
• The physical link is disconnected

Examples:
If the written alert level is “No Alert”, no alerting is done on this device.
If the written alert level is “Mild Alert”, the device alerts.
If the written alert level is “High Alert”, the device alerts in the strongest possible way.

How to demo it:
1. set Key Fob to advertising mode
2. try LE scan from Ubuntu

erin@sundays:/project/upstream/bluez$ sudo hcitool -i hci0 lescan

LE Scan ...

C0:FF:EE:C0:AA:06

C0:FF:EE:C0:AA:06

C0:FF:EE:C0:AA:06

C0:FF:EE:C0:AA:06

C0:FF:EE:C0:AA:06

3. create LE connection

erin@sundays:/project/upstream/bluez$ sudo hcitool -i hci0 lecc C0:FF:EE:C0:AA:06

Connection handle 32

4. use gatttool to browse the service of LE device

erin@sundays:/project/upstream/bluez$ sudo gatttool -i hci0 -b C0:FF:EE:C0:AA:06 -m 48 --interactive

[   ][C0:FF:EE:C0:AA:06][LE]> connect

[CON][C0:FF:EE:C0:AA:06][LE]> primary

[CON][C0:FF:EE:C0:AA:06][LE]> 

attr handle: 0x0001, end grp handle: 0x000b uuid: 00001800-0000-1000-8000-00805f9b34fb

attr handle: 0x000c, end grp handle: 0x000e uuid: 00001801-0000-1000-8000-00805f9b34fb

attr handle: 0x000f, end grp handle: 0x0011 uuid: 00001803-0000-1000-8000-00805f9b34fb

attr handle: 0x0012, end grp handle: 0x0014 uuid: 00001802-0000-1000-8000-00805f9b34fb

attr handle: 0x0015, end grp handle: 0x0017 uuid: 00001804-0000-1000-8000-00805f9b34fb

attr handle: 0x0018, end grp handle: 0x001e uuid: 0000ffb0-0000-1000-8000-00805f9b34fb

attr handle: 0x001f, end grp handle: 0x0031 uuid: 0000ffa0-0000-1000-8000-00805f9b34fb

attr handle: 0x0032, end grp handle: 0x0036 uuid: 0000ffe0-0000-1000-8000-00805f9b34fb

[CON][C0:FF:EE:C0:AA:06][LE]> characteristics 0x0012 0x0014

[CON][C0:FF:EE:C0:AA:06][LE]> 

handle: 0x0013, char properties: 0x08, char value handle: 0x0014, uuid: 00002a06-0000-1000-8000-00805f9b34fb

[CON][C0:FF:EE:C0:AA:06][LE]> char-desc 0x0012 0x00014

[CON][C0:FF:EE:C0:AA:06][LE]> 

handle: 0x0012, uuid: 2800

handle: 0x0013, uuid: 2803

handle: 0x0014, uuid: 2a06

[CON][C0:FF:EE:C0:AA:06][LE]> char-read-uuid 2a06

[CON][C0:FF:EE:C0:AA:06][LE]> 

handle: 0x0011 	 value: 00 

[CON][C0:FF:EE:C0:AA:06][LE]> char-write-cmd 0x0011 02

[CON][C0:FF:EE:C0:AA:06][LE]> char-read-uuid 2a06

[CON][C0:FF:EE:C0:AA:06][LE]> 

handle: 0x0011 	 value: 02 

[CON][C0:FF:EE:C0:AA:06][LE]> disconnect

5. Key Fob would start to ring

Experiment II: prepare two BT BR/EDR devices. One is my Ubuntu laptop (daydreamer) and the other is my Ubuntu Desktop (Sundays). Daydreamer is a Key Fob (Client) and Sundays is a Monitor (Server).

1. Fake Immediate Alert profile and Link Loss profile in local data files.

erin@sundays:/project/vcgomes/linux-2.6$ cat /var/lib/bluetooth/00\:13\:EF\:F0\:C4\:46/profiles 

78:DD:08:A3:A7:52 0000110a-0000-1000-8000-00805f9b34fb 0000110c-0000-1000-8000-00805f9b34fb 0000110e-0000-1000-8000-00805f9b34fb 00001112-0000-1000-8000-00805f9b34fb 0000111f-0000-1000-8000-00805f9b34fb 00001800-0000-1000-8000-00805f9b34fb 00001801-0000-1000-8000-00805f9b34fb 00001802-0000-1000-8000-00805f9b34fb 00001803-0000-1000-8000-00805f9b34fb

erin@sundays:/project/vcgomes/linux-2.6$ cat /var/lib/bluetooth/00\:13\:EF\:F0\:C4\:46/primary 

78:DD:08:A3:A7:52 0011#0013#00001802-0000-1000-8000-00805f9b34fb 0009#000b#00001803-0000-1000-8000-00805f9b34fb

2. use dbus-send to change Alert Service value

erin@sundays:~$ dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/2617/hci1/dev_78_DD_08_A3_A7_52 org.bluez.Proximity.GetProperties

method return sender=:1.62 -> dest=:1.91 reply_serial=2

   array [

      dict entry(

         string "LinkLossAlertLevel"

         variant             string "none"

      )

      dict entry(

         string "ImmediateAlertLevel"

         variant             string "none"

      )

   ]

erin@sundays:~$ dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/2617/hci1/dev_78_DD_08_A3_A7_52 org.bluez.Proximity.SetProperty string:ImmediateAlertLevel variant:string:high

method return sender=:1.62 -> dest=:1.92 reply_serial=2

erin@sundays:~$ dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/2617/hci1/dev_78_DD_08_A3_A7_52 org.bluez.Proximity.GetProperties

method return sender=:1.62 -> dest=:1.93 reply_serial=2

   array [

      dict entry(

         string "LinkLossAlertLevel"

         variant             string "none"

      )

      dict entry(

         string "ImmediateAlertLevel"

         variant             string "high"

      )

   ]

3. use gatttool to check the Alert Level value

erin@sundays:~$ dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/2617/hci1/dev_78_DD_08_A3_A7_52 org.bluez.Proximity.SetProperty string:LinkLossAlertLevel variant:string:mild

method return sender=:1.62 -> dest=:1.96 reply_serial=2

erin@sundays:/project/upstream/bluez$ sudo gatttool -i hci0 -b 78:DD:08:A3:A7:52 -p 31 -m 48 --interactive

[   ][78:DD:08:A3:A7:52][BR]> connect

[CON][78:DD:08:A3:A7:52][BR]> char-read-uuid 2a06

[CON][78:DD:08:A3:A7:52][BR]> 

handle: 0x000b 	 value: 01 

handle: 0x0013 	 value: 00

0xlab 一年來的開發狀態更新

2011-08-14T09:42:55+00:00

忙碌的日子總是過得比較快，這一年來，0xlab 歷經頗多轉變，主要有以下三方面：

技術涵蓋：為了加速 Android 系統整合與優化，我們建構了若干工具與提供一些創新的方法，比方說快速啟動 Android，詳情可見 0xlab::Technology
與知名專案與開源團隊的合作：除了過去已合作的 android-x86 與 CyanogenMod 專案外 (主要是 Graphics 與 ARM 相關效能優化)，我們也投入 Linaro 的開發，建立 Android platform 與 LAVA (Linaro Automated Validation Architecture) 的基礎
建立與主要 SoC 廠商的聯繫及協同開發：與兩家重要的 SoC 廠商 (排名 Top 20 半導體公司) 密切合作開發，在 Android 的基礎上，透過若干開源的創新，加強 SoC 競爭力，並導入產品設計

即使比過往忙碌，不過我們仍持續貢獻於開放原始碼的世界，以下是從去年發表「簡介 0xlab 新的開放原始碼專案」之後的更新：

0xdroid :作為 0xlab 的 Android 參考優化與客製化設計，其成果不僅為 Beagleboard 社群所熟知，許多內部的改進也廣泛用於 CyanogenMod，間接使許多裝置與公司團體受惠。可參考 0xdroid::Roadmap 以得知細部的演進，簡單來說，在高解析度的環境，提昇了 Android 使用者體驗 (software curosr, on-screen keyboard, launcher)，另外就是進一步的 ARM 優化，從 skia, zlib, libcore, libc, 到 libagl (libGLES_android) 都有
0xbench : 仍是截至目前為止，我們所知的最完整 Android 開放原始碼系統效能評測工具，與上個版本相較，追加了 Web/JavaScript 效能評測、LAVA 的資料格式 (bundle)、重新啟用 libMicro 等等，詳情可見 0xbench::Benchmarks
Linaro : 經 ARM 的支持，0xlab 投入 Linaro 開發，共同為改善開發原始碼軟體品質而努力。我們涉及的項目稍微繁雜些，從整合 Linaro toolchain、改善 Android runtime、強化 LAVA 的整合，到多媒體驗證都有
aster : 全名是 "Android System Testing Environment and Runtime"，著眼於 Android 系統中許多無法透過 API 呼叫所作的 black-box test，一旦 adb daemon 正常啟動後，這個系統就可依據指定的 test case 去逐一執行並驗證，此系統也允許使用者編輯操作案例
Android 快速開機: 利用優化過的 ARM hibernation (suspend-to-disk)，大幅縮減 Android 系統從 HW reset 到使用者得以操作的時間，可參考展示影片 "Android Fast Booting with CarHome"，相關的原始碼也一併釋出，可見 0xlab-kernel，儘管仍有頗大的進步空間，但這是完全可運作且開源的解決方案
AMBER : 這是我們提供的第一個完整的應用系統，概念非常簡單，考量到現有 Android 裝置相當多元，可能是手機、筆記型電腦、平板電腦、電子書，或者數位電子，這之間要進行媒體 (media/content) 的交換往往很沒效率，而且使用者還得被繁複且多樣的多媒體格式所困擾，若無適度的轉換，通常就無法在手機或者較陽春的平板上播放。我們提出的解法，就是將動作縮減為 "push" 與 "pull"，自動偵測媒體的格式與屬性，無論在近距 (家用或小範圍) 或遠距 (透過雲端或者防火牆)，挑選最合適的途徑，讓使用者盡情觀賞與交換。同樣的，這也是開放原始碼，內建於 0xdroid
Toolchain : 除了改善 Linaro Toolchain for Android 外，我們還改善了 Android ELF prelink，大幅縮減執行時期需要解析的 ELF 符號數量，也縮減了載入時間，近期內會提交到 AOSP
Android Open Source Project : 已被 Google Android 計畫正式收錄 37 個修改/貢獻

其他項目就要看合作夥伴的狀況了，先提到這邊。歡迎透過以下方式，與我們聯繫與交流：

Twitter: http://twitter.com/0xlab
郵件論壇: 0xlab-devel (系統開發) ; 0xlab-discuss (一般討論)
YouTube: http://www.youtube.com/0xlab
有源碼有真相: gitorious, github

一如過往，我們今年也會在台灣最大的開放原始碼研討會 COSCUP 發布最新的專案與社群計畫，期待您的指教，謝謝！

Android 2.3 Introduction & Statistics

2011-06-29T13:33:30+00:00

如果你有收看 LWN.net 的話，大概知道每次 linux kernel 有新的 release 前都會有一次針對這次 release 的統計資料，看看主要的貢獻是由哪些人，哪些公司完成。藉由這次跟 0xlab 分享 Android 2.3 新特性的時候，我學 LWN.net 做了一些小統計，還滿有趣的。

Most active Android 2.3 organizations (by changesets)

4204 google.com
1354 android.com
98 sonyericsson.com
71 gmail.com
39 codeaurora.org
39 samsung.com
38 intel.com
32 nokia.com
32 holtmann.org
29 0xlab.org
25 trusted-logic.com
17 openbossa.org
11 nxp.com
11 linux.org.tw

10 ti.com
10 acer.com.tw
8 themaw.net
8 garmin.com
7 snpe.rs
7 motorola.com
7 mc.pp.se
7 googlemail.com
5 invensense.com
4 mirbsd.org
3 windriver.com
3 realvnc.com
2 teleca.com
2 sharp.co.jp

2 nvidia.com
2 motoya.co.jp
2 lge.com
2 broadcom.com
1 yahoo-inc.com
1 xs4all.nl
1 wdsglobal.com
1 uwevoelker.de
1 strongswan.org
1 stericsson.com
1 signove.com
1 saftware.de
1 richlowe.net
1 pv.com

1 promwad.com
1 pcc.me.uk
1 padovan.org
1 osbeck.com
1 nii.net
1 martin.st
1 ilovelinux.de
1 happydroid.com
1 droidmod.org
1 cpeterso.com
1 big.or.jp
1 arm.com

Most active Android 2.3 developers (by lines changed)

Jesse Wilson
Eric Laurent
Dianne Hackborn
David 'Digit' Turner
Nick Pelly
Mathias Agopian
Nick Kralevich
Brian Carlstrom
Eric Fischer
Andreas Huber

12.8708%
12.13%
8.65%
6.84% 
5.35%
4.13%
3.42%
2.77%
2.05%
2.03%

投影片中還研究了一下各主要開發者主要研究的方向，看 log 的時候依照這個順序去看，有一定的脈絡可尋 :)

Android: Wakelocks and TuxOnIce

2011-06-29T13:02:58+00:00

最近為了把 TuxOnIce 整到 Android 上面，著實把 Linux 的電源管理系統中關於 suspend 與 hibernation 的部份研究了一下。而 Android 為了增加待機時間加入了 wakelock 的機制，讓情況變得更加複雜。

TuxOnIce

TOI Patch

TuxOnIce 簡稱 TOI，前身是 Software Suspend 2，是一個長期在 linux upstream 以外耕耘的一個休眠補釘，相較於早期整合到 linux kernel 內的 swsusp，TOI 的功能非常豐富，可以指定把記憶體內容儲存到多種不同的位置，如檔案或置換空間，還可以選擇不同的壓縮方法。

首先幫 ARM 平台加上基本的休眠功能，使用 Hiroshi DOYU 的 patch:

http://article.gmane.org/gmane.linux.power-management.general/20543

然後到 TOI 網站下載最新的 3.2 補釘，打上去的時候會有一些衝突但是都還滿容易解決，要注意的是某些衝突是看不出來的，例如因為函式移動位置而造成重複定義，要小心檢查。

然後因為 TOI 對於非 x86 平台有一些假設現在已經不適用，所以需要修改

https://gitorious.org/0xlab-kernel/kernel/commit/e551caf

OMAPFB

使用 Pandaboard 加上 Android 測試才發現從休眠醒來後 LCD 不會自動點亮，通常在 x86 平台上有 pm-utils 或是 hibernate script 來幫忙處理這種關閉打開 LCD 的問題，這次我是先在 kernel 內幫 OMAPFB 加上一個電源管理的呼叫，讓 kernel 醒來的時候自己重新設定 LCD。

https://gitorious.org/0xlab-kernel/kernel/commit/21e0f14

Pandaboard & Beagleboard xM

在 Pandaboard 或 Beagleboard xM 上面沒有 NAND 可以當作儲存空間，所以一般都是把檔案放在MMC 上面，第一個 patch 讓 kernel 在開機的時候不要初始化不存在的 NAND 空間

https://gitorious.org/0xlab-kernel/kernel/commit/3ae6b4c

然後因為 MMC 的 probe 需要時間，第二個 patch 讓 TOI 等待指定的 resume device 已經偵測到之後才開始進行 resume

https://gitorious.org/0xlab-kernel/kernel/commit/1078bd7

Wakelock

wakelock 是 Android 為了讓裝置可以更積極的休眠又不妨礙正常工作的進行而加入的機制，究竟是好是壞已經在 LKML 與 LWN 上面討論過非常多次，可以參考：

失眠症

開始測試 TOI 的效果時遇到的第一個問題就是失眠症，因為 wakelock 從中作梗，導致每次休眠到一半就被取消掉。原來是因為 TOI 的休眠途徑會先強制檔案系統把內容寫回，而 MMC 子系統會在寫入/讀取一段時間後嘗試進入低耗電模式，偏偏 Android 在這裡安插了一個 wakelock，導致之後要凍結所有執行緒的時候失敗。

解法，首先因為休眠的後半段路徑其實就是要準備進行關機，而一般來說休眠都是人為啟動，因此可以假設此時使用者了解工作可能還未完成，可以忽略 wakelock，所以第一個 patch 就是讓休眠的路徑不去檢查 wakelock，避免像 MMC 這樣的問題。

https://gitorious.org/0xlab-kernel/kernel/commit/3bb5d6f

接下來是一般的待機路徑，似乎是因為新的 kernel 會積極的嘗試把 MMC 變成低耗電模式，但 OMAP 預設的 MMC timeout 是 100 毫秒，把工作放在 Queue 裡面反而不斷鎖住 wakelock 讓 Android 無法休眠，第二個 patch 就是讓 MMC 子系統在準備休眠的時候就不要作無謂的掙扎，直接進入低耗電模式。

https://gitorious.org/0xlab-kernel/kernel/commit/88823b9

嗜睡症

解決了失眠症沒想到接下來遇到嗜睡症，因為手機插著 USB 的時候是不會真正睡著的，所以一直沒機會觀察 Android 睡著是怎麼樣，原來只把 kernel 叫醒是沒用的，Android 還會檢查目前的 input event 是否屬於 user activity 的範圍，是的話才會把整個系統帶醒，不然因為 wakelock 的機制，馬上就會又睡著。

參考：

Android Power Management

Slides of the Android System Development Forum

2011-05-26T10:49:01+00:00

These are some of the slides from the technical speakers of the Android System Development Forum on April 28th, 2011. Copyrights belong to their perspective owners and distributed under their permission.

Android RenderScript on LLVM
by 廖世偉博士
<iframe height="525" src="http://www.slideshare.net/slideshow/embed_code/8103150" width="640"></iframe>

Is parallel programming hard? And if so, what can you do about it?
by Paul McKenney
<iframe height="525" src="http://www.slideshare.net/slideshow/embed_code/8103031" width="640"></iframe>

Guides To Analyzing WebKit Performance
by Holger Freyther and Jim (jserv) Huang 黃敬群
<iframe height="525" src="http://www.slideshare.net/slideshow/embed_code/8042012" width="640"></iframe>

Linaro and Android Kernel
by Andy Green
<iframe height="525" src="http://www.slideshare.net/slideshow/embed_code/8109213" width="640"></iframe>

There are still some slides missing and I’ll keep updating here.

Filed under: 0xlab, Android

OBEX Message Access Profile introduction

2011-05-06T11:03:04+00:00

Have you ever tried to push a SMS message from a laptop to an Android phone via Bluetooth? It's very similar to OPP (object push profile) and it is to use OBEX to exchange data too. I found some patches in Aurora about supporting MAP (message access profile) in Android two months ago. Finally, I got some time to play with it.

What is MAP? MAP defines a set of features and procedures to exchange messages between devices. It is especially tailored for the automotive Hands-Free use case where an onboard terminal device (typically a Car-Kit installed in the car) takes advantage of the messaging capability of a communication device (typically a mobile phone). This profile can however also be used for other use cases that require the exchange of messages between two devices.

I have no Car-Kit to verify this profile and I cannot find any platform to support it either. Therefore, I use python lightblue and write few lines to verify this function. I have one samsung smdkv210 platform and one ubuntu laptop. Below is the list about MAP profile from Aurora git repository. If you are using gingerbread, you could apply their patches easily. Also, it's just a simple list and we should review git log to retrieve more patches related to MAP profile.

native bluez
Bluetooth : Add MAP service records into SDP tool
https://www.codeaurora.org/gitweb/quic/la/?p=platform/external/bluetooth/bluez.git;a=commit;h=7f52e048879c74a35a212ed4a0ce2f14133e2806

android frameworks
frameworks/bluetooth: Changes for enabling Bluetooth MAP profile
https://www.codeaurora.org/gitweb/quic/la/?p=platform/frameworks/base.git;a=commit;h=a7d9bf26766e420be997d2858fc7b73b42868860

Bluetooth UI application
Bluetooth: Adding MAP Profile implementation
https://www.codeaurora.org/gitweb/quic/la/?p=platform/packages/apps/Bluetooth.git;a=commit;h=e900ed4897561fbb317a8c1488ac84c0fb051068

Email UI application
Email: Changes to trigger Email app to update its mailbox from Bluetooth MAP Profile
https://www.codeaurora.org/gitweb/quic/la/?p=platform/packages/apps/Email.git;a=commit;h=e11f384228e44cb8b718247436fc0501bb81673a

MMS UI application
Mms: Enable MMS app to push a MMS added to outbox by Bluetooth MAP profile
https://www.codeaurora.org/gitweb/quic/la/?p=platform/packages/apps/Mms.git;a=commit;h=703e2c2ae82f973954c539cd8e55470e4d6c3873

Add MAS service from init.rc file and then we can see MAP record from sdptool.

#cat /root/init.rc
service map /system/bin/sdptool add --channel=16 MAS
    user bluetooth
    group bluetooth net_bt_admin
    disabled
    oneshot

# sdptool browse local
Service Name: OBEX Message Access
Service RecHandle: 0x10008
Service Class ID List:
  "" (0x1132)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 16
  "OBEX" (0x0008)
Profile Descriptor List:
  "" (0x1134)
    Version: 0x0100

I use ipython to write my scripts to demo MAP function. I create an OBEX Client from my Ubuntu machine and use it to connect with Android device. It send a 'get' request to retrieve the first slot of SMS.


import lightblue
host="12:60:41:7F:03:11"
port=16
client = lightblue.obex.OBEXClient(host,port)
client.connect()
f=file('/home/erin/Desktop/temp','w+')
client.get({'type':"x-bt/message",'name':'1'},f)
f.seek(0)
f.read()
f.close()
client.disconnect()

Beagleboard Hibernation DEMO

2011-04-13T06:36:00+00:00

I gave a talk in OSDC. But I did not provide _visible_ demo by that time.
Now, seeing is believing.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="390" src="http://www.youtube.com/embed/pvcQiiikJDU" title="YouTube video player" width="390"></iframe>

The idea behind this technology is not something new. It's based on hibernation.
Special thanks for walkingice's help out on filming this, CATCAN's sponsor on LCD expansion board.

Android System Development Forum

2011-04-01T08:28:18+00:00

By coincidence, the abbreviation of this is ASDF, which is kind of geeky…

0xlab is going to co-host this event on 2011/04/28. Please refer to
http://www.digitimes.com.tw/seminar/android_1000428.htm
for more information. The introduction page is in Traditional Chinese, but some of the sessions are in English.

We think there are quite some Android summits out there, but most of them are about application development and business trends. We want to focus on the system development aspect from a more technical point of view.

Oh by the way, did I mention it’s free of charge?

Filed under: 0xlab, Android

Alternative use of Openmoko debug board

2011-03-29T10:54:27+00:00

If you have an openmoko debug board, don't throw it away as recycling.

By combining om-debugboard and MOSFET drivers, you can issue commands to power on/off your device. But why do so?

Sometimes, when a system such as android is in development, system library would be crashed from time to time. Even adbd is down. At this moment, what you can do is to reset the device through power on/off. But this usually requires manual operation. Think about another scenario, if you want to run CTS on android device, you of course prefer everything is automatic. You definitely need an approach to shutdown the power of your device or turn it on.

The keyword is openmoko debug board, relay leg and MOSEFT drivers.

Thanks my bro's help out and his lab from NTUST. The corresponding circuit is simple enough. I will make schematic later. Since my TODO list can't be added any more options recently. :(

The way to control the GPIO on debugboard is easy. libftdi provides many features on this. The easiest approach is to enable bitbang mode. I implemented a simple program to control GPIO(TDO pin) output.
You can download it here:

http://www.0xlab.org/~matt/om-debugb-gpio.tar.bz2

Introducing 0xBench

2010-08-13T12:24:00+00:00

Today (Aug 14) we are announcing the release of 0xBench, an open source Android benchmarking app...

Eclair Libgralloc Deadlock Problem

2010-06-10T01:50:15+00:00

As we are developing 0xdroid beagle-eclair branch, we occasionally encounter screen flipping issue. This issue rarely happens however it bothers the user experience very much when running some resource eating applications. Last week in the Computex Taipei 2010 show, we demoed 0xdroid beagle-eclair connecting wireless modules and played games. I noticed that this issue happens very often while playing a game called "Frozen Bubble". (It's a good game, we all love this game a lot, and spent a lot of time on it. ;-) ) It's kind of embarrassing when the screen keeps flipping on the show. Therefore I decided to dig out this issue.

E/SurfaceFlinger(  768): eglSwapBuffers: EGL error 0x3002 (EGL_BAD_ACCESS)
E/gralloc (  768): handle 0x13f8c0 not locked
~E/gralloc (  768): handle 0x13f8c0 already locked for write
E/libagl  (  768): eglSwapBuffers() failed to lock buffer 0x1368e0 (640x480)
E/SurfaceFlinger(  768): eglSwapBuffers: EGL error 0x3002 (EGL_BAD_ACCESS)
E/gralloc (  768): handle 0x13f8c0 not locked
E/gralloc (  768): handle 0x13f8c0 already locked for write
E/libagl  (  768): eglSwapBuffers() failed to lock buffer 0x1368e0 (640x480)
E/SurfaceFlinger(  768): eglSwapBuffers: EGL error 0x3002 (EGL_BAD_ACCESS)
E/gralloc (  768): handle 0x13f8c0 not locked
E/gralloc (  768): handle 0x13f8c0 already locked for write
E/libagl  (  768): eglSwapBuffers() failed to lock buffer 0x1368e0 (640x480)
E/SurfaceFlinger(  768): eglSwapBuffers: EGL error 0x3002 (EGL_BAD_ACCESS)
E/gralloc (  768): handle 0x13f8c0 not locked

Therefore I checked the libgralloc and adding some debug message. The libgralloc plugin 0xdroid used is branched from original eclair source tree. I took few hours created the omap3/libgralloc at the first day when I got eclair source code months ago. Since it works well for the most of time, I didn't pay too much attention to it, until I found the deadlock issue goes crazy on frozen bubble.
After noticing the lock log and swap error, I took a close look of the gralloc_lock and gralloc_unlock in hardware/omap3/libgralloc/mapper.c

int gralloc_lock(gralloc_module_t const* module,
        buffer_handle_t handle, int usage,
        int l, int t, int w, int h,
        void** vaddr)
{
    if (private_handle_t::validate(handle) < 0)
        return -EINVAL;

    int err = 0;
    private_handle_t* hnd = (private_handle_t*)handle;
    int32_t current_value, new_value;
    int retry;

    do {
        current_value = hnd->lockState;
        new_value = current_value;

        if (current_value & private_handle_t::LOCK_STATE_WRITE) {
            // already locked for write 
            LOGE("handle %p already locked for write", handle);
            return -EBUSY;
        } else if (current_value & private_handle_t::LOCK_STATE_READ_MASK) {
            // already locked for read
            if (usage & (GRALLOC_USAGE_SW_WRITE_MASK | GRALLOC_USAGE_HW_RENDER)) {
                LOGE("handle %p already locked for read", handle);
                return -EBUSY;
            } else {
                // this is not an error
                //LOGD("%p already locked for read... count = %d", 
                //        handle, (current_value & ~(1<<31)));
            }
        }

        // not currently locked
        if (usage & (GRALLOC_USAGE_SW_WRITE_MASK | GRALLOC_USAGE_HW_RENDER)) {
            // locking for write
            new_value |= private_handle_t::LOCK_STATE_WRITE;
        }
        new_value++;

        retry = android_atomic_cmpxchg(current_value, new_value, 
    } while (retry);

    if (new_value & private_handle_t::LOCK_STATE_WRITE) {
        // locking for write, store the tid
        hnd->writeOwner = gettid();
    }

    if (usage & (GRALLOC_USAGE_SW_READ_MASK | GRALLOC_USAGE_SW_WRITE_MASK)) {
        if (!(current_value & private_handle_t::LOCK_STATE_MAPPED)) {
            // we need to map for real
            pthread_mutex_t* const lock = &sMapLock;
            pthread_mutex_lock(lock);
            if (!(hnd->lockState & private_handle_t::LOCK_STATE_MAPPED)) {
                err = gralloc_map(module, handle, vaddr);
                if (err == 0) {
                    android_atomic_or(private_handle_t::LOCK_STATE_MAPPED,
                            (volatile int32_t*)&(hnd->lockState));
                }
            }
            pthread_mutex_unlock(lock);
        }
        *vaddr = (void*)hnd->base;
    }

    return err;
}

int gralloc_unlock(gralloc_module_t const* module, 
        buffer_handle_t handle)
{
    if (private_handle_t::validate(handle) < 0)
        return -EINVAL;

    private_handle_t* hnd = (private_handle_t*)handle;
    int32_t current_value, new_value;

    do {
        current_value = hnd->lockState;
        new_value = current_value;

        if (current_value & private_handle_t::LOCK_STATE_WRITE) {
            // locked for write
            if (hnd->writeOwner == gettid()) {
                hnd->writeOwner = 0;
                new_value &= ~private_handle_t::LOCK_STATE_WRITE;
            }
        }

        if ((new_value & private_handle_t::LOCK_STATE_READ_MASK) == 0) {
            LOGE("handle %p not locked", handle);
            return -EINVAL;
        }

        new_value--;

    } while (android_atomic_cmpxchg(current_value, new_value, 
            (volatile int32_t*)&hnd->lockState));

    return 0;
}

The code looks reasonably for the first look. Lock and unlock pair looks good. However there is a very tricky part "android_atomic_cmpxchg may fail". Understanding this, it is not hard to see there is a potential bug in gralloc_unlock. If android_atomic_cmpxchg fails, it will run the do while loop for more than once. However for the first run, the hnd->writeOwner will be changed to 0. And then the new_value will not be changed anymore. This lock will goes crazy here after.

The patch solves this problem.

diff --git a/mapper.cpp b/mapper.cpp
index 16ebcc2..1f3e722 100644
--- a/mapper.cpp
+++ b/mapper.cpp
@@ -267,13 +267,13 @@ int gralloc_unlock(gralloc_module_t const* module,
         if (current_value & private_handle_t::LOCK_STATE_WRITE) {
             // locked for write
             if (hnd->writeOwner == gettid()) {
-                hnd->writeOwner = 0;
                 new_value &= ~private_handle_t::LOCK_STATE_WRITE;
             }
         }
 
         if ((new_value & private_handle_t::LOCK_STATE_READ_MASK) == 0) {
             LOGE("handle %p not locked", handle);
+            hnd->writeOwner = 0;
             return -EINVAL;
         }
 
@@ -282,5 +282,6 @@ int gralloc_unlock(gralloc_module_t const* module,
     } while (android_atomic_cmpxchg(current_value, new_value, 
             (volatile int32_t*)&hnd->lockState));
 
+    hnd->writeOwner = 0;
     return 0;
 }

It make sure the value hnd->writeOwner is the same as the first loop, if android_atomic_cmpxchg fails.

This issue comes from the original eclair source tree, and it is still there, and had been inherited to many different platforms. If you encounter two frames crazily flipping and having the lock message, you may try to take a look of your libgralloc.