顯示具有 openmoko 標籤的文章。 顯示所有文章
顯示具有 openmoko 標籤的文章。 顯示所有文章

2011/1/2

Android 基本產品化的常見問題 (Framework and APP) - Part 1

剛進入 2011 民國 100 年, 就聽到水果機的鬧鐘不響, 跟 Android 簡訊有機會會亂發的 bug 在 google code 的 issue list 被 complain 到洗版. 從第一次聽到 google 要推出自己的 app framework 到現在已經 3 年多了. 想當年, 從一開始有這個消息, 就一直不斷有人問那 Openmoko 怎麼辦? 不過當初我覺得這個問題, 應該留給時間來決定, 因為我們是沒辦法管到這麼多的, 一個想要 change the world 的專案, software framework 或 business model 並不是我們能夠控制的. 同時, 要 maintain 一個 open source 的 software framework 跟搭配 FOSS community 的發展, 也並不是那麼簡單的事.

當年 (2006) FOSS (Free and Open Source Software) 並沒有像現在那麼多人認識 (多少是相對於當時, 現在並不見得真的多很多, 但是關心 Linux (驅動) 的人肯定多了不少 :P ). 由於這個專案剛開始只是內部的一個特別專案, 所以不管內外, 當年在台灣經常被問到幾個問題, 每次都跟 sean 在內部解釋半天, 可是當年解釋應該很多人聽不懂吧 :) 現在 Android model 算是比較 stable 的 model 了, 可以拿來借答一下.

* 你們開放 source 之後, 人家拿你們 source code 不是就可以做一樣的產品了嗎?

Open source 改版的 cycle 跟傳統 MS 3-5 年的 cycle 是不一樣的, 大概是 3-4 個月一個 cycle. Release source 是在產品交到市場後 "才" 需要 release source code (不過這一點是違反 real FOSS 的 release early/often 原則). 以 Android 的複雜度對一般的 RD 來說, 即使能力還不錯, 拿到 Android 最新的 source 到能夠 tune 完變成稍微 ok 產品, 最少也需要 2-3 個月或更長. 何況大部分廠商都極端依賴所謂 chip 原廠的 BSP (Windows or Android), 等到原廠 BSP 出來, 其實 Android 差不多都發新的版本了. 然後因為大部分 RD 其實都不會 (可能公司網路也不行) 加入 community development, 所以 code 就不斷的被 fork 出來, 改完一版基本上最多利用個半年, 然後重來一次. 大部分的狀況, 一堆 dirty hack 其實也只能讓產品剛剛好跑的動, 但是想要跟 S 公司的 tab 或是 H 公司手機比品質其實是很困難的. Google 可以控制 release schedule/發展方向, 即使你拿到 source, so what? 你還是痴痴的等 Android 下一版是 2.4 還是 3.0, 每天都還是不停的 google 是 4 月還是 5 月出下一版. 只要你 follow 遊戲規則, 你不知道定規則的人何時放棄跟 linux kernel upstream merge 的 policy, 或何時 freeze source code release.

Open source 很大的一部分在於分享的精神 (當然 RSM 還有對 "知道" source 在幹嘛的需求), 這一部分是東方文化背景比較難了解的. 西方相對來說對於取用別人 donate code, 再把 code donate 回去的習慣是很自然的 (可能是宗教或教育的關係). 東方相對來說, 很容易陷入藏東藏西的循環裡.

* 免費的 open source code or Linux 能用嗎(functional)?

很久很久以前 :P 是一堆人 "覺得" 或振振有詞的說 Linux 不能用 (or 不好用) 在消費性電子產品, 或是適合沒有 UI 的產品上 (先不管 QT :) ). Linux kernel (with android patch) + Android framework 現在好像這類問題什麼都沒有了. 反而是大家直接拿來 tune 一 tune 就滿坑滿谷的 Android 產品, 覺得免費真好, 用的超高興. 但是這裡有一個問題, AOSP (Android Open Source Project) 的 code, 並不是為了每一家的產品量身訂做或是 debug. 在 Nexus S/Milestone 沒問題不代表在其他 ok.

所以現在又有一個奇怪的觀念, 就是 Android 東西放上去會動不是就 ok 了嗎?

我不確定這系列能寫或該寫多深, 可能也要分個幾次寫或是修修改改補充完, 工程就是這樣, 基本 porting 跟產品化的問題並不會隨時間改變. Android 產品還是幾個部分:

* Driver
* Power management
* Media service
* USB
* Display and UI framework
* Upgrade policy/flow
* Service and Intent settings
* Prepare for next release
* Code Open = IPR Free?

寫下來自己當備忘吧...

2010/4/5

Android 的 script engine (ASE) 專案

很多嵌入式或是一般的使用者終端專案都會需要使用 script 搭配類似 corn 的機制作一些排程處理的事情. 因為 Android 大部分的功能都是架構在 dalvik VM 上. 所以前一陣子再找 Android 有沒有像 Windows WSH (Windows scriptng host) 或 PyGTK 之類的 engine 可用. 才發現有一個 ASE (Android Script Engine) 專案 host 在 google code. 看起來還蠻符合一般需要的, 而且它支援 Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl. 看起來蠻實用的. 而且是 G 公司內部的人開發的, 雖然還在 alpha stage, 但他把一般常用的功能都封裝好, 同時還有 scheduler 功能, 看起來很實用, 有時間要來試試看.

http://code.google.com/p/android-scripting/

2009/10/21

在 Freerunner 上開發 Android (cupcake) 應用程式 - 永遠的 Hello World

最近 Android 不知道在紅什麼, 一天到晚都看到新聞. 昨天突然想到自己這台電腦上 (ubuntu 8.04 LTS) 的裝的 Eclipse (3.2) 從來沒用過, 加上也沒用過最近 koolu release 的 Android 0.1.1 for Freerunner. 就想說來測一下, 來 study 一下有哪些變化. 發現目前好像 Android on Freerunner 的說明不是很完整, 就快速補一下.

首先, 參考了以下網站:
* http://developer.android.com/sdk 使用 Android SDK 相關需要的條件 (http://developer.android.com/sdk/1.6_r1/requirements.html ), 安裝 ADT (Android Development Tools) 相關的說明 (http://developer.android.com/sdk/1.6_r1/installing.html ). Download 1.6 的
SDK tar.gz 檔
* http://code.google.com/p/android-on-freerunner/ Download 最近一次的 0.1.1 release tar.gz 檔(or http://www.t0ny.net/openmoko/images/android/) 目前 android on freerunner 是用 weekly build 的方式 release fix.

Step1: 安裝 Eclipse, JDK, JRE

看了 google dev 說明依下, 就發覺一些問題. 因為我的桌機上裝的是 ubuntu 8.04 LTS, 預設 apt-get install 的 Eclipse 是 3.2 版. 完全不在 google 目前支援的範圍內 (3.4 and 3.5 版). 可是不死心, 想說 ADT 給他裝上去會不會動, 結果 install 一直失敗. 最後還是把 Eclipse 3.2 移了, 從http://www.eclipse.org/downloads/ 抓了 3.5.1 classic 版本下來 (不過 google 是建議 java 版 or RCP 版).

抓下來解壓縮放到我的 home 目錄下, 執行 Eclipse 檔, 然後按照 google 的指示 從 Eclipse 3.5 的選單 Help -> Install New Softare. 在 In the Available Software dialog, 按下 Add.... 把 Location 填上去
https://dl-ssl.google.com/android/eclipse.

接著想說按下一步就收工了, 結果一直發生 package 安裝驗證的 Error (connect to key store 或是類似的問題). 我想說我 jdk 都裝了 (雖然幾乎沒用過) 就 google 一下, 發覺是跟 gcj 相容性有關(後來在 google 的 specification 看到上面有寫 =_=?), 然後有善心人士把 command post 出來:

~$sudo apt-get install openjdk-6-jre sun-java6-jdk
~$sudo update-java-alternatives -s java-6-sun

安裝完後, 還有把 SDK 的 path export 到環境變數, 修改 ~/.bashrc 加上一行: export PATH=${PATH}:<sdk_dir>/tools ,修改 preference

Eclipse 部分大概是這樣.

Step 2: 寫一個 hello world...
寫個 helloworld, 以 Android 1.5 當 target 在 Android 模擬器上跑跑看, 編成 .apk 檔. 哈哈, 其實本篇不是教你寫 Hello world :P

Step 3: 請參考前面幾篇文章, 安裝 0.1.1 的 cupcake 到 Freerunner 上安裝完後, 到設定裏面把 screen and display 的 sleep 時間延長, 避免 suspend 時的 USB 斷線. 然後到 Application 設定裏面, 把 USB debugging/Stay awake/Allow mock locations 打勾, 然後把接受未簽名的 Unknown sources 選項打開.

Step 4: 建立 ADB 連線, 將 .apk 檔安裝到 freerunner 中.
tony@tony-945:~$ adb kill-server
tony@tony-945:~$ sudo ifconfig eth3 192.168.0.200 netmask 255.255.255.0
[sudo] password for tony:
tony@tony-945:~$ export ADBHOST=192.168.0.202
tony@tony-945:~$ adb install helloworld.apk
* daemon not running. starting it now *
* daemon started successfully *
112 KB/s (6796 bytes in 0.058s)
pkg: /data/local/tmp/helloworld.apk
Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]

原來以為這樣就收工了, 但是不知為什麼, 即使 Unknown sources 選項打開, Android 一直不讓我裝未簽名 (NO_CERTIFICATES) 的 helloworld.apk, 迫不得已, 就順便簽一下了.

Step 5: 建立 keystore 目錄, 為 .apk 簽名. 這邊只提供過程 :)
tony@tony-945:~$ mkdir android_dev_deploy
tony@tony-945:~$ cd android_dev_deploy/
tony@tony-945:~/android_dev_deploy$ mkdir keystore
tony@tony-945:~/android_dev_deploy$ cd keystore/
tony@tony-945:~/android_dev_deploy/keystore$ mkdir keys
tony@tony-945:~/android_dev_deploy/keystore$ cd keys
tony@tony-945:~/android_dev_deploy/keystore/keys$ cd ..
tony@tony-945:~/android_dev_deploy/keystore$ keytool -genkey -alias GreenRoom
-keyalg RSA -validity 20000 -keystore keys/anddev.keystore
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Neng-Yu 'Tony' Tu
What is the name of your organizational unit?
[Unknown]: GreenRoom
What is the name of your organization?
[Unknown]: GreenRoom
What is the name of your City or Locality?
[Unknown]: Taipei
What is the name of your State or Province?
[Unknown]: Taiwan
What is the two-letter country code for this unit?
[Unknown]: TW
Is CN=Neng-Yu 'Tony' Tu, OU=GreenRoom, O=GreenRoom, L=Taipei, ST=Taiwan,
C=TW correct?
[no]: yes

Enter key password for <anddev.keystore>
(RETURN if same as keystore password):
Re-enter new password:
tony@tony-945:~/android_dev_deploy/keystore$ ls
keys
tony@tony-945:~/android_dev_deploy/keystore$ cd keys
tony@tony-945:~/android_dev_deploy/keystore/keys$ ls
anddev.keystore
tony@tony-945:~/android_dev_deploy/keystore/keys$ cp
/home/tony/helloworld.apk /home/tony/android_dev_deploy/keystore/
tony@tony-945:~/android_dev_deploy/keystore/keys$ cd ..
tony@tony-945:~/android_dev_deploy/keystore$ ls
helloworld.apk keys

Step 6: apk 簽名 (Sign apk)

tony@tony-945:~/android_dev_deploy/keystore$ jarsigner -verbose -keystore
keys/anddev.keystore -signedjar helloworld_signed.apk helloworld.apk anddev.
keystore Enter Passphrase for keystore:
adding: META-INF/MANIFEST.MF
adding: META-INF/ANDDEV_K.SF
adding: META-INF/ANDDEV_K.RSA
signing: res/drawable/icon.png
signing: res/layout/main.xml
signing: AndroidManifest.xml
signing: resources.arsc
signing: classes.dex

tony@tony-945:~/android_dev_deploy/keystore$ ls
helloworld.apk helloworld_signed.apk keys

tony@tony-945:~/android_dev_deploy/keystore$ cp helloworld_signed.apk ~/
tony@tony-945:~/android_dev_deploy/keystore$

Step 7: 安裝簽名 apk (signed apk)
tony@tony-945:~$ ls hel*
helloworld.apk helloworld_signed.apk
tony@tony-945:~$ adb install helloworld_signed.apk
127 KB/s (8484 bytes in 0.064s)
pkg: /data/local/tmp/helloworld_signed.apk
Success

終於等到 Success, 然後在 Android 應用程式區上就可以看到 Helloworld
Application 了 :) 目前暫時結論是 unknown sources 選項在 0.1.1 版的 Android on Freerunner 有些問題, 所以 .apk 還是需要 sign 過才能用 adb 裝. Ya....收工.

後來發現 Eclipse 在這一版是可以自動找到 adb server, 直接從 Eclipse 將 code 丟到 0.1.1 版的 Android Freerunner 執行. 這樣直接 debug, 不需要使用 adb install 來做安裝的工作.

2009/10/29 update:

0.1.1 版的 Accelerometer 似乎有問題, 無法正確取得 accelerometer 的值, google groups/code track 也有提到. 不過 GPS/Wi-Fi/Audio/Vibrator 是可用的. SDK 的 samples 內附的 API demo 有很多範例除了看 code 怎麼寫. 還可順便測試硬體. 如果裝了 Eclispe, 可以編 API demo 試試看. GPS sample 我放了一個簡單的在 http://t0ny.net/openmoko/samples/android/gps/ , 需要注意的地方只有 AndroidManifest 要把加設 user right 有 Access fine location, 不然編完無錯誤但無法執行. google code 上有許多 android 相關的 project, 例如 http://code.google.com/p/bearing/ 也是一個 GPS data 的 viewer, 可以在 FR 上執行.

2009/8/5

取得 Freerunner 原始碼及編譯完整 image 的方式 - 使用 mokomakefile




原本當初 Openmoko 新手手冊預計會寫 20 篇, 前 10 篇是基本操作, 後 10 篇預計是寫 tool/build 相關的. 最早會想寫的原因有幾個, 包含: 減少大家問重複問題的機會, 補充網路上一些中文資料不完整的地方, 還有順便當自己備忘錄 :)
後 10 篇最後沒寫是因為覺得網路上資料其實夠多, 像 OpenEmbedded (OE) 跟 git 都很多說明資料在 blog (英文很多) 或是有 PDF 格式可供下載, 一般 developer 如果這類閱讀問題沒辦法解決, 要真正加入 FOSS community development 的開發會很困難. 另外有公司組織上功能區分的原因 ;-)

原先 document team 有 "理想" 要把 wiki 內容整理到 Floss manuals 這個 project (http://en.flossmanuals.net/), 這樣只要再把整理的文件, 翻譯成中文, 這樣也比較會有一致性. 而 Flossmanuals 是另一個希望能讓 open source software 工具, 能有一個清楚説明公開文件的 project.

最早 Openmoko 在公開 wiki 時, 就提供了 SVN 的 u-boot/kernel 及 based on OpenEmbedded (OE) 的 package 在網路上供人下載. 同一時間, 少量的 Neo1973 的工程樣品, 也免費送到各個重要的 Open source community (phase 0 user) 的開發人員手上, Rod Whitby 是其中的一位, 他就幫 Openmoko 寫了一個非常強力的 makefile, 目的是讓 developer 能夠用簡單的方式, 透過 OE 能讓每個 developer 都能用 "一樣" 的 code base, 自己 build 完整的 distribution (kernel + rootfs). 早期的 mokomakefile 需要先自行安裝及設定 monotone (版本管理軟體, OE 在 2008 年前使用), 後來 OE 改用 git 當版本管理程式, mokomakefile 幾乎能全自動的完成所有 build image 的程序. 個人第一次使用時覺得: 這個 Makefile 真是超神奇跟強大的工具, 雖然當初在我的舊 PIII 1.2 G NB 編了快 3 天, 但自動化跟穩定程度真是神奇, 值得大家試試看.

* Mokomakefile 的主要說明網址: http://wiki.openmoko.org/wiki/MokoMakefile
Mokemakefile 全自動完成以下的幾件事:
* 下載 OpenEmbedded 的 Bitbake, 及相關設定檔原始檔
* 從網路上各個 bitbake recipt 指定的 git/svn 位置, 及下載套件指定訂版本原始碼
* 下載 recipt 裏的 patch 及相關設定
* 設定/建立 Host 端 OpenEmbedded 所需的設定, 包含工作目錄, 暫存目錄, image 存放目錄, 套件存放目錄...等等
* 依照編譯設定檔, 套用 recipt 指定的 patch 後, 編譯所有的套件, 包含 kernel 及建立 rootfs 所需的所有套件
* 根據設定檔的設定, 編譯套件的 ipk/opk 檔
* 將編譯好 rootfs, 根據設定, 做成 flash 可接受的 image 格式, 以及完整 rootfs.tar.gz 壓縮檔

OE 的系統龐大, 如果工具不熟, 對於開發人員是很大的負擔. 熟悉後, 它的優點及缺點大致如下:

* 優點: 能夠快速而且彈性的建立新的跨平台 embedded 專案套件, 不需要自己trace OE 套件都維持在最新的版本. 分散式開發架構, 國外開放/嵌入社群熟悉的工具及交流模式.

* 缺點: 學習曲線長, 速度慢, 開發工作易被外部的套件更新影響, 把原先簡單的工作複雜化 (如不是自己開發的套件發生 bug, 原本只需要在 local patch, 重 build, 重新 package. 使用 OE 協調多個 team 可能要繞一大圈, 效率低而且容易溝通出錯)

如果要使用 OE, 我建議還是讀一次 OE 的手冊, 尤其是第 7 跟第 8 章講授的系統概念部份.除了 OE 官方的英文外, 大陸 developer 有翻一份中文的, 如果習慣大陸編程語法的程式員們, 可以參考 http://blog.chinaunix.net/u1/52172/showart_1346396.html

Openmoko 版的 mokomakefile 現在由於無專職人員 maintain 加上 download path 有變更, 所以如果使用網站上的 mokomakefile (from freesmartphone) 會出現一些目錄找不到導致的 bitbake python 錯誤. 但是不用緊張, 還是有 community 的 team 負責維護相似的 mokomakefile. 目前主要有法國 Bearstech 的 SHR (http://shr.bearstech.com/ or http://shr-project.org/trac) 跟德國 Micky 帶領的 freesmartphone.org http://www.freesmartphone.org/index.php/Main_Page . 不過據最近 (2009.8) mailing list 討論, Freesmartphone (FSO) team 未來可能會 based on SHR 的 distribution 開發上層 dbus based application framework, 不會自己再發行 FSO distribution.

使用 mokomakefile (或是 SHR 的 Makefile) 很簡單, 但是時間可能很長 (一般來說, C2D 機器第一次 build 可能會到一整天), 大概步驟如下:

* 在 ~ 下建立一個屬於該 distro 的目錄
* 用 wget 把 http://shr.bearstech.com/ Makefile 檔案抓下來, 放到目錄下
* 根據自己 OS, 參考 http://wiki.openmoko.org/wiki/MokoMakefile 的說明, 安裝 host 端 (PC) 所需要的基本編譯套件. 每個 distribution 不太一樣, 例如 SHR 還需要額外的 curl. 基本上編譯時請先看 download site 對應的 readme, 以及編譯時的訊息, 缺什麼補什麼.
* 然後 make 或是 make "套件名稱" 像是 make shr-testing 之類的
* 然後第一次大概需要等一天, 依所使用的機器不同而不同. C2D E6420 大須需要 18-24 小時. 同時 download 套件可能需要數 G 的容量.

編譯完後, 可以在 deploy 目錄找到, 如圖.

如果你有多台電腦, OM 的 developer 會使用 icecc 來做編譯的工作, 靠著 5-7 台左右的 quad-core 電腦網路分散編譯, 把完整編譯時間縮短到一小時內. 這算一個很不錯的使用 linux 編東西 hint 跟 technique.
在 2008 資策會創新應用服務研究所的開放原始碼行動平台研討會上, 我有整理一份 Openmoko 相關環境的介紹 http://t0ny.net/openmoko/doc/Openmoko_enviorment_n.pdf 可以當參考.

2009/6/30

社群開發與嵌入式產品開發流程的衝突與妥協


Neng-Yu 'Tony' Tu
前幾個禮拜, 參加了資策會 OSS (經濟部工業局自由軟體產業應用推動計畫) http://www.oss.org.tw/ 主辦的 FreedomHEC2009 (http://www.oss.org.tw/dokuwiki/doku.php?id=freedomhec2009) . 今年在 Android 與 Moblin 的市場光環加持下, 加上工作人員也很努力的拉國外 key developer 來演講, 現場人數大概比去年多了一倍 (完全感覺不出來產業不景氣...哈哈).

Greg Kroah-Hartman 跟其他主要幾位主講人, 其實講授的內容都很實在, 對 kernel developer 來說, 有很多有用的 tips, 例如這篇 kernel report:
http://www.oss.org.tw/dokuwiki/lib/exe/fetch.php?media=kreport.pdf

提到以最近的 release 30 來說, 每天 kernel 平均增加 6500 行 131 個 changes, 這個數字看起來對一班人來說只是數字而已, 但是對很多公司的開發人員來說, 一直 trace 最新的 kernel 其實是有負擔的. 就台灣開發硬體產品的 cycle 來說, 大約開發一個全新的產品平均需要 6-8 個月, 以新 linux kernel release 週期為 15 週來看, 這一段時間 kernel 起碼已經跳了 1 到 2 個版本.

換句話說, 即使產品一開始如果就使用最新 vanilla kernel, 到出貨時, 先為了符合 GPL 而開放原始碼, 然後更有心一點再作相關 driver/patch upstream 的工作, 但為了適應新的 kernel 變更, developer 也還是需要額外的工作時間去適應新版本. 如果有公司想要像 beagle board (http://elinux.org/BeagleBoard) 一樣, 能夠讓產品直接 make omap3_beagle_defconfig 就可以透過 toolchain 編出 kernel 其實是需要時間了解 upstream 的模式. 主要包含:

* porting 前先註冊硬體資訊 (mach id..etc)
* 加入討論區, 適應 Linux community 的 coding/討論習慣
* 你要送 code 到哪邊 upstream (這顆 AP (Samsung/TI/Freescale) 的 maintainer 是誰, review 流程大概是怎麼樣)

這些都要實際 "加入" community (社群), 才能了解更多的細節. 這邊又卡到兩點 1. 開發人員本身的意願及英文能力 2. 製作產品的 RD 資源投入的時間是否應該在產品出貨後結束.

我在網路上找到一篇還不錯介紹 arm linux porting white paper 的放在這裡, 有興趣的可以參考一下. http://www.t0ny.net/foss/doc/porting/PortingLinuxKernel.pdf

因為 OEM/ODM 特性做習慣的關係, 不需要面對終端客戶, 在台灣典型的都把產品出貨當成是產品投入 RD 資源週期的結束. 但這一點, 對 community 來說, 產品到手 (hacking) 才是軟體應用可能性階段的開始, 是不太一樣的. Community base 公司的產品 (buglabs/beagleboard or LEGO like!!!), 等於把第一個產品當成是產品線的頭, 再慢慢展開看 community 需要哪些產品, 再逐漸充實產品的內容, 軟體可能增加支援的 platform (Android/Linux/Windows CE...) or 硬體 (更多的模組). 雖然這類的應用模式, 早就存在於常需要客製化的工業電腦產業中, 但是包括 Openmoko 在內, 蠻多的 (or 一部分) 趨勢都是朝著將原先客製化的模式, 帶到標準消費性產品中. 當然, 以目前這幾年的景氣 (2009-), 跟這些公司目前的狀況來看, 整個 biz model 都還在試水溫的階段, 但是最起碼提供一個產品開發的有趣方向.

一般只是拿 linux 當成是免費的 OS + 一堆好用的 utility 的一般硬體廠商而言, 是完全 or 至少一部分誤解了開放硬體的精神. 大部分廠商都停留在擔心自己的產品有違反 了 GPL 規定. 而不是利用 community 來開拓可能的市場, 及需要開放硬體專案的合作機會.

另一個矛盾就是, linux kernel "community" 只會一直 maintain 最新 2-3 個 kernel 版本, 與個例子來說, kernel.org 是不會一直幫 2.6.18 上 patch, 而是只會 maintain 目前 (2009.06) 最新的 2.6.28-30, 然後以極快的速度 (跟 MS 系統比較) 繼續往新的 release 前進. 這也是與業界的一般方式, fork 一份 2.6.24/26 的 kernel 下來, 然後自己 maintain 自己的 tree 的一般開發 (非 community) 方式有很大不同. 一般完全 fork 然後 maintain 自己藏起來的 tree 方式最大的問題就是公司最後只有少數 RD 能 maintain/patch 整個 tree, 所以公司的產品能力跟擴充方向, 也會直接或間接會受到這些 keyman 的限制. Maintain 一個 distribution 其實就是一件 "事", 如果又有其他的工作 overlap, 自己 maintain distribution 只好挖東牆補西牆, result 跟 quality 都不會太好.

當然在兩天的研討會過程中, 也反映出許多業界使用 Linux 開發, 跟融入 Linux 社群中的矛盾點, 主要的就是 release 原始碼 (源代碼) 的問題. 又想要 community 幫忙解決, 或是快速接受自己的硬體, 另一方面又不想或非常被動的 release source code. 當然 release source 有許多的問題, OM 都遇過. 包括產品中有相關 chipset 廠商的 NDA 問題. 不過這並不是無解, 或者說, 在產品開發選料前就要跟廠商談好, 不是產品要出了才進行 community friendly 工作.

在 OM 專案中, 最好的例子就是 wi-fi driver source code, 因為 FOSS community 不喜歡 binary 的 driver, Atheros 當時又是以非常 community friendly 的方式 release wi-fi 的驅動程式原始碼 (align with mainline source), 所以就溝通協調專案內容後 (我們使用的 AR6k fw 版本是 2.x), 就請 Atheros 新 release 一份對應的 GPL driver 給 OM. 當然除了 GPL 版本外, Atheros 還有另一份只能 release binary 版的 driver, 這也是 chipset vendor 經營開放軟體 community 常見的手法.

總而言之, 如果希望 Open Source Community 支援你想要接近 community 的產品, 我個人的建議是:

* 提交硬體 community 開發時, 底線是開放 kernel 部分的 source code, 最簡單的 release 方式打成 tar ball, 或文明一點放在公開 git/svn 上.
* 想辦法幫 community 或是對你的硬體有興趣的人, 解決他們的問題 (提供 documentation/跟 vendor 談 release 文件)
* 了解跟 community 成員的溝通方式
* 讓 key community member 盡早拿到硬體 (每間公司的策酪及考量不一樣, 但這的確是目前國際大廠 (you name it!!!) 為了接近 FOSS community 都在做的事), 但是不能期望這些 community key member 能提供有用的 feedback.

當然, 以上純就有興趣建立品牌或是接觸社群開發的專案. 若只是 OEM/ODM, 只要 spec 跟 term 清楚, 問題很單純, 大部分的公司, 都不缺乏這類的經驗.

很高興能在這類大拜拜場合 :) 遇到像是 matt_hsu 及 jserv, 以及目前在 0xlab 的 前 OM 優秀 developer (FOSS or not FOSS...haha). Real FOSS will be a life long way ;)

2009/5/10

Developing a FOSS / Linux friendly embedded hardware - component selection


Neng-Yu 'Tony' Tu

Hardware component selection seems like a easy job after people have google and digikey. But in real world, lots reason that make googled/digikey search result dose not mean it could be used in the mass production product. Mostly is not technical reason, but sourcing/SCM reason. Component sourcing/SCM (supply chain management) is one of the critical issue that will affect your design could go into real mass production or not.

Following are some aspect was considered during component selection process.

* Business relation:
Module vendor/chipset vendor always put business (either real money or just marketing) as first priority. Usually vendor or distributor will spent FAE/RD/support resource at confirmed customer, so it's not only about your money while you using their products into yours but also their money as well. Most hardware vendor need forecast required material quantities to
drive their upstream supply chain as well. We take LCM (LCD module) as example, if you buy module from vendor, they need to prepare:

* Flex print circuit cable
* LCM frame parts
* LCD Controller IC
* Touch panel controller chips and glass
* Many small components
* Negotiates with their factory in order assemble/delivery in time

Sometimes hardware providers will concern about of losing trading secrets/expose bugs with "open source" device. You have to clearly define about delivery target, what could release and what couldn't release to end customer, including:

* What is hardware delivery item/firmware version?
* Who should finish driver to specific firmware version?
* Documentation/source under what type license
* How to co-work on missing delivery? (Like GPL'ed version driver and re-distributable documentation).

All above will be continuous process during project period.

* Specification: Sometimes online chipset/module manuals/specifications are not updated one (or in-correct/non-function), especially those not release through official web site. There are some components I called: paper components, means not put into mass production yet or only vendor want to test the market response. Also, you have to understand specification very
well, because you also have setup acceptance standard/rules during whole process. Most embedded hardware won't fulfill every specification at design stage (durability/sensitivity/environmental tolerance/may others), you have to negotiate/track along the way.

Some vendor don't have linux friendly policy, you might not get source code of driver/testing tool. You may need to develop your own version, and find a way verify the specification before your linux driver ready.

* Unique/hard to source parts: If you using component that very unique in specification (like special cap value or fancy function). And this component could help RD simplify design or make life easier. For most developer, make mass production is not their responsibility, design good product is. Tricky part is: in many cases, using hard to source part will cause lots sourcing/logistic over head later (lead-time), and you might need to postpone whole production because of single component that seems harmless at design stage. You have to be very careful using unique/hard to source part if really want make a mass production-able device.

Some companies like using unique part as a lock (like own design function chip) to protect product, or using it as tool (like their own variation of PMU) to simplify later product design/verification cycle.

* EOL (end of life): Just like your cellar phone, electronics device chip life cycle is not long as you think. Most manufacture using the same part that "popular" device used, if "popular" device phase out (usually less than 1.5 years), sometimes component lead time will dramatically increase, because vendor will manufacture the part for you instead of moving stock around market. You your product design -> mass production period is too long (over 1 year), you must be very careful track your original deign-in part EOL date or specification change. Sometimes, you never get updated until you place next order. EOL is killer for hardware verification, for software need to have another round of test plan/driver parameter adjustment.

Some experienced people might ask: why so many industrial devices could grantee over 5 years or longer availability/replacement, answer is easy: they buy more as stock and sale product in higher price. So when manufacture stop fabricate component, they could still have on stock.

* Price: Including payment term/delivery method/tax. You could not get good price with reasonable quantities. This issue has nothing to do with software ;) but for PM, might need to keep an eye on it.

* Technical support: Most chipset/module will assign technical (FAE) and sales contact window after business cooperation. You may ask support from technical contact, usually including:

* Hardware testing/verification support
* Driver required document (may not release to public, but release to you as reference)
* Source code that under GPL license (or co-work develop one)
* Co-work on product development schedule (firmware
release/test/verification/bugfix/function add...etc)

Most of time component vendor only have driver to specific linux version (usually not updated one), and may use some strange rootfs combination. You have to double check what is "We have linux driver" means with FAE.

Component must have at least one of following charactics that makes it community/developer friendly component :)

* Full documentation, release in creative commons or re-distributable license, accessible from public Internet web site

* GPL'ed driver source, and driver already in upstream linux kernel tree is best

What is not acceptable is: binary driver and all documenation (user manual/datasheet/etc) under NDA, that developer could not easily track source and debug it. Sometimes vendor will only provide compilied/kernel specific driver, this is not acceptable format to FOSS developer.

2009/5/7

Developing a FOSS / Linux friendly embedded hardware - documentation and source code


Neng-Yu 'Tony' Tu

During past few years, I have been through all kinds of challenge while develop an embedded hardware project. Most software people do not need to know (also don't want to know ;) ) the difficulty and potential problems/issues about design/verification/component sourcing/supply chain/factory/quality control in hardware (or embedded hardware). The reason using English in this series posts because I think it will help more community people have general ideas about how hardware industry works, and also how to make requirement if want to provide a linux/open source friendly device to community (another reason: I could type faster :P )

For FOSS/Linux projects, there will be more requirements (sometimes special support) that related to hardware vendor (component or chipset) in order to get project process smoother also avoid potential IPR issues.

Recently, open source, open platform and some make schematics publicly (like Openmoko or beagle board) already a trend nowadays, but open source itself and hardware product provide schematics is not new concept. 20 years before, most 3C electronics still provide schematics as part of product; my Apple II+ also came with several manuals that contained full product details.

Since more electronic circuit embedded into IC, also devices became more complex. Instead of fixing it, people throwing devices away once it became non-functional. And what most customers used to are: simple device, limited function, with limited way to used it. Not like camera today ;) even have wi-fi transmission/gps capability.

Also more and more IPR enforcement process inside/outside company; branding company may not own full product knowledge and rights because out source the design to ODM company, and re-distribution rights of related documents. So, there is more and more technical (trading secrets/legal/IPR) and non technical (business requirement for product) barrier make public hardware information required by software/community development become difficult.

For people developing software that related to hardware, need following information from hardware (at least one of following item will be required):

* Complete documentation about component (chipset/module), document may need
re-distribution rights, or release under creative commons

* Driver source code (boot code and kernel driver), under GPL is best. But usually you only could get reference code from vendor with other license and also under NDA

Effective documentation will contains all necessary information (initial setting/registers/gpio/usage conditions), and you have re-distribution rights. A lot of component documentations were under NDA (sometimes even you could easily acquired from Internet, but you still under NDA), and you have to communicate to right people get the approval for re-distribution rights.

Usually, component/chipset vendor will provide following solution for
FOSS/Linux hardware:

* Component/chipset vendor might provide you a striped version of document that with full required information and you could re-distribute (very common for Intel, but rare for most embedded application processor vendor)

OR
* Provide documentation and full reference code (usually Windows mobile), but you could NOT re-distribute either one, you must write your own version

OR
* Provide a stripped GPL version of driver (means, some function was hidden - you never know). This is not ideal, but acceptable, sometimes..

OR
* Provide driver porting service, provide you binary and dynamic load-able driver with limited parameter information, this is not preferred/friendly format for FOSS community.

For module like wi-fi/GSM/Bluetooth, usually you need to know interface protocol (SPI/UART/USB/I2C), initial method, commands. For component like application processor/graphics processor/power management unit, you will need full documentation to provide a community friendly hardware product.

2009/4/2

找一台適合跑 Linux 的電腦


Neng-Yu Tu (Tony Tu)

一定很多人很奇怪, Linux 不是幾乎每一台電腦都能跑嗎 (還有人覺得爛電腦跑 linux 剛剛好 ;-) ) 這有什麼好寫的?. 如果知道當初為了找 Harald 選定 OM developer 要用的電腦, 親自跑了 4 - 5 次光華商場還找不到適合的主機板, 就可以理解我為什麼會把這件事挑出來寫一寫.

其實當初 (2007 年) 指定的規格並不複雜 ;)

* 網路晶片組必須要 Intel 或 Marvell
* Intel 整合式繪圖晶片組 (945G), 板子上必須提供 RGB 輸出
* CPU 要有 4Mbytes 以上的 layer 2 cache
* 要有 DVI add2 卡

由於大部分的電腦使用者都會買分離式的 3D 顯卡, 其實本來整合式顯卡的板子在台灣消費市場就不多. 因為缺了 3D 顯卡, 這類板子可能都是假設使用者是辦公室或居家消遣用, 搭配的網路晶片組大都使用 realtek 或 attansic 的晶片.

當初會想找 Intel 和 Marvell 網路晶片板子的理由是: 相對來說產品比較 community friendly (晶片文件, 說明, 原廠的 linux 驅動程式原始碼及支援), 同時還支援一些遠端開機/安裝等功能 (Linux driver supported). 最重要的, 據說穩定性有差, 但是我沒實際測過, 只好姑且當參考.

使用整合式顯示晶片的原因: 是因為 Intel 有一個 community type project 提供整合式晶片組, 支援 Linux 的 2D/3D 顯示驅動程式 http://intellinuxgraphics.org/documentation.html . 所以基本上你不需要另外掛 ATI 或是 Nvidia 的 binary 非 GPL 驅動程式, 還需要作一些雜七雜八的設定, 就可以 "有" 3D 加速的功能.

而 DVI ADD2 卡, 就是可以讓整合晶片組, 由原本的主機板內建的 RGB 輸出, 透過一張簡單 PCI 卡直接提供雙 DVI 輸出. 這張卡不貴, 可是可能大部分用整合式晶片組的人, 都不知道 Intel 主機板加一張 PCI 轉卡就可以有雙 DVI 輸出, 不需要另外買 3D 加速卡 (Windows 系統插上去也會主動認得, 不需要另外裝驅動程式, 神奇吧!!!). 不過 DVI ADD2 當初真是天殺的難找, 台灣大家都裝 3D 顯卡, 哪來的那種東西阿. 後來好不容透過採購管道, 找到 DVI ADD2 卡. 後來居然還有另一段插曲, 某個相關研發部門, 因為需要 DVI ADD2 卡做試驗, 而台灣的庫存卡被我們買光了, 還跑來找我們借卡試 driver.

CPU 要有 4MB 的 layer 2 cache 則是為了編譯程式的需求, 跟一般 2M 的比起來, 4M 大概可以快 20-30 %, 在當時 C2D 只有 E6420 的 CPU 有 4M layer 2 cache. 而且, 後來 C2Q 的 Q6600 有一段時間可能是因為庫存或是推廣, 賣的比 E6420 還便宜 (非常奇怪), 而且還有 8M layer 2 cache. 所以後來 E6420 買不到, 就直接升 C2Q Q6600. 結果是編 FR 的 kernel under 100 秒.

後來好不容易挑到一張 ASUS 的 P5GZ-MX 符合規格, 但是要買時, 945G 的板子又已經停產 . 台灣又沒有符合需求的 (此時發現國內廠商放在國外賣的板子種類, 跟料好像都比台灣本地要好...火...), 轉成 Gigabyte 一張 965G-DS3, 試完可以, 又因為採購的人找不到廠商願意客製化大量加保固. 後來還是輾轉買到 ASUS 某個 965G solution.

結論是, 每一個選擇, 都有背後的原因 ;) 後來果然大家也沒花什麼時間 tune driver 這 tune driver 那, 省了一些時間, 但是很多當初想要做的 fancy 功能也還是沒用到 (如網路安裝所有機器, 遠端控制...等). So, 還沒 implement 就開始 optimization 不是只會發生在 coding 上 ;)

下次各位有興趣, 可以試試找一張內建整合顯卡的主機板, 然後還是用 Marvell 跟 Intel 網路晶片的 solution 是不是很難 ...

2009/4/1

開放軟體社群專案 - 開發模式簡介, 工具名詞解釋


Neng-Yu Tu (Tony Tu)

拜微軟良好的 MSDN 及產業的 ecosystem 建立完整之賜, 加上超級強力的 IDE Virtual Studio. 一般習慣 "微軟" 開發人員進入到 Open source 環境的時候, 由於工具跟說明都是散在各個地方, 最大的問題是被一堆新名詞/新指令搞的頭昏腦脹, 或是不太清楚工具的功能或使用方式. 下面是一些常用開發名詞, 開發流程, 跟工具功能

簡單的解釋.

名詞-
* Autotools: 如果想讓你的程式能夠在各個不同平台下編譯, autotools is the ABC have to follow.
* Toolchain: 編譯跨平台程式需要編譯器組合 (for example: x86 base to ARM base)
* OE: OpenEmbedded 的縮寫, 透過 OE 提供的套件庫, 你可以編譯不同硬體架構平台相關的整個 rootfs 所需要的檔案.
* Bitbake: OE 使用編譯套件庫的 make. 一般編譯器透過 config 編譯出所需程式, bitbake 透過 receipt 編譯特定平台上的所需的: 單一套件, 多個套件, 或整個 rootfs image, 同時可協助處理相依性的問題.
* Monotone/git: OE 使用的版本管理平台, 以前是 monotone, 現在開始改為 git (git 最早也是根據 monotone 改寫), 透過各種 manifest (檔案的清單, 套件的清單, 清單的清單) 做為所有套件版本追蹤的根據.

我把 monotone/autotools/OE 相關的 usermanual 放在 http://t0ny.net/openmoko/doc/ , 最新的, 可以到 http://www.openembedded.org/ , http://monotone.ca/ http://bitbake.berlios.de/manual/ 下載. git 相關的可以很容易從網路搜尋到.

開發流程-

其實軟體的開發流程並不應該是有區分開放軟體, 或是一般軟體的差別. 現實生活中, 開發方式也跟組織方式和人力調配方式有關. 但是大型 "開放" 軟體專案, 因為可能 90% 以上的軟體元件或函式庫並不是由自己開發, 如果不想要自己管理每一個組件的版本及設計細節, 只有藉助像是 OpenEmbedded 的平台來提供相關的組件原料.

一般的商用 embedded system 套件, 大部分都是已經 freeze 裡面所有套件的版本. 有問題或功能增加時, RD 只需要更新裡面的少數套件. Windows Embedded 是這種方式的典型代表. 其他像是 MontaVista 也是類似的方式.

但是 Linux 及較不純的 Android, 因為加入了社群開發, 所以套件的修正其實是很頻繁的. 套件間又有相依性的問題, 所以要能夠自己 download source/patch, 及 daily build 的能力其實很重要. 要能Daily build 所有變更中的專案 source, 其實很麻煩 (簡直是惡夢), 所以需要 OE 這類平台及 bitbake 這類工具幫助. 當然, release 產品並不一定需要所有的 package 都是最新的, 除非是因為有某個開發模組的相依專案, 也一直在更新. 相對於傳統開發, 就等於是有多個不同小組同時開發一個大型專案. 但這種開發方式, 對於本身就是分散式開發的 Linux 是非常常見的狀況.

所以, 透過 OE (組織) 的 monotone/git (版本管理工具) 及 bitbake (編譯選擇工具) 及 bitbake 的 receipt (編譯條件實際內容清單) 來做版本管理. 通常 Open source 專案的 binary download 網站會有幾個目錄 包含專案不同階段的 binary 及 package:

* stable: 穩定版, 或是經過測試的 release 版
* testing: 開發版, 或是正在測試中的版本
* unstable: 直接 daily build 出來, 或是未經測試的版本

如果要 sync 不同小組的工作, 每個小組都必須熟悉相同的工具, 在 linux 社群中, 因為所有的大型開發都是分散式, 所以需要不停的 sync (daily build/daily update), 使用相同 source, 才能整合不同團隊間的工作及合作.

開放軟體的開發, 通常最大的難關並不是技術或是工具的使用上. 而是讓開發人員習慣將程式碼, 每天或是每個問題有初步解決成果後, 就提交到 mailing list 中討論. 而不是悶著頭把程式寫到非常完整, 或是非常複雜才提交. 因為在開放環境下, 每一個人都可能在作同一份工作, 遇到相同的 bug. 唯一有效率的方式是當解決問題後, 盡快的提交 mailing list 或 maintainer 審核. 避免其他人也在解一樣的問題. 因為一旦 fork 太久, 任何人寫的程式都很難再與其他人程式整合.

大部分我目前遇到的 opensource developer, 例如 (harald/werner/andy...) 等, 他們解完問題到提交的時間不會多於 24 小時. 並不是在短短時間內, 他們提交的 code 一定不會有問題. 而是專案進行的模式, 就是 relaese early, release often.

2009/3/13

FreeRunner 一堆使用上的小 trick


Neng-Yu Tu (Tony Tu)

一些使用上的小 trick, 陸續增加中.

* 抓圖

在 FreeRunner 上抓圖可以很簡單, 或是很複雜 ;) 最簡單也最原始的方式就是直接:

#./cat /dev/fb0 > file.raw

當然, 你也可以把 raw 的圖, cat 回螢幕上.

#./cat file.raw > /dev/fb0

作假的程式或預覽效果還蠻方便的 :-) Android 的 fb0 的路徑不太一樣, 在 screen/display 下.

接著透過 fb2png 將 raw 的圖檔變成標準 png 檔

#./fb2png file.raw file_not_raw.png 9 480 640 16

fb2png Binary 可以從以下網址取得:
http://t0ny.net/openmoko/samples/bin/fb2png/

* 使用 VM 上的 Linux 連結 FR

拜台灣 Windows 盛行之賜, 很多 Developer 都是透過 VM (virtual box/vmware/virtual pc/others) 使用 Linux 系統. 但是透過這種方式連接 FR 時, 需要注意連接 FR 時, "記得" 視窗的 focus 要在 VM 上. 這樣 VM 才抓的到新加入的 device (FR).

透過 VM 做 ssh 跟 dfu 其實都是 ok 的, 但是 dfu 在 VM 下有時速度會很慢, 或是 dfu 到一半中斷. 同時, 請記得 ssh 連線時要把 suspend (休眠) 關掉, 不然 ssh 連線會一直斷.

* Windows 直接連 FR
Windows 是可以直接 ssh 進 FR 的, 不過你要安裝 Windows RNDIS 驅動程式:
http://t0ny.net/openmoko/driver/neo_rndis/ 然後透過 putty 或是 tunnelier (http://www.bitvise.com/tunnelier), 做 ssh 或 scp.

基本上, 你可以把 FR 是一台小的 linux 電腦, 可以透過 USB/Wi-Fi/BT 甚至 GPRS 做 ssh/scp 的工作.

2009/3/11

使用 Freerunner 的三軸動作感應器 (3 axis accelerometer) - motion sensor


Neng-Yu Tu (Tony Tu)

自從任天堂的 Wii 跟蘋果的 iPhone 出現以後, 動作感應器 (or 微機電 MEMS 系統) 感覺一下子變成顯學. 這幾年也看到越來越多的應用出現在 iPhone 或其他的 Device 上, 最常見的還是拿來當樂器或是其他控制器使用. 例如:




不過這個 air guitar 跟 Accelerometer 可能沒什麼直接關係 ;) 只是提神用!!!

Freerunner 有 2 個 ST LIS320DL 的三軸動作感應器, 一個位在機器的左上方靠近 Aux 鍵的位置, 一個在主板的右下方靠近麥克風的位置. 一般的手機只需用到 1 顆, 就可以偵測目前手機的機身狀態 (朝哪個方向傾斜/加速度). ST LIS320DL 規格是偵測區間可調 +- 2g 或 +-8g, 丟資料的頻率可設成 100 Hz 或 400 Hz. 它還有可以設定的 interrupt 腳位. 可以在特定狀況下(自由落體, 靜止突然移動), 才發出 interrupt. 這兩個 motion sensor 一個有接到可把 CPU 從 suspend 喚醒的腳位上. 詳細的 datasheet 可參考下面的網址: http://www.st.com/stonline/products/literature/ds/12726/lis302dl.htm

這兩個三軸動作感應器可以同時使用. 但是在大部分狀況下, 1 顆就已經足夠. 2 顆 motion sensor 組合起來是可以做比較複雜跟精準動作偵測 (偵測角加速度, 而不是只是單純 3 軸), 或是進一步作 gyro sensor, 生物動作特徵辨認等 or something you could dream of ;-)

簡單來說, 有一點像是原先的 Wii Remote + MotionPlus





* 設定 Accelerometer

設定 Accelerometer 可以透過 /sys 下面完成, 不過因為 kernel 版本關係, 2.6.28 版之後, 相關的 sysfs 設定會出現在

/sys/class/i2c-adapter/i2c-0/0-0073/lis302dl.{12}

root@om-gta02:/sys/devices/platform/lis302dl.1# ls
driver duration modalias sample_rate threshold wakeup
dump full_scale power subsystem uevent

可以設定包括 threshold (觸發臨界值), sample (取樣頻率) 以及其他的 Accelerometer 參數. 可以直接透過 cat threshold 或是 echo 72 > threshold 的方式改變設定數值. 同時, 設定數值有時並不是以 1 為基數, 以 threshold 來說, 就是 18 的倍數.

* 讀取 Accelerometer 數值

Openmoko wiki 一樣有詳細如何讀取 motion sensor 資料的方法, 請參考:
http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval

最簡單的存取方式 motion sensor 方式, 就是直接 cat Accelerometer 的 event 輸出.

root@om-gta02:/# cat /dev/input/event2
root@om-gta02:/# cat /dev/input/event3

event2 及 event3 分別是第 1 顆及第 2 顆 Accelerometer 的資料輸出.

Accelerometer 輸出的資料格式如下:

root@om-gta02:/# cat /dev/input/event3 hexdump
0000000 3fec 3896 ebe5 0000 0002 0000 ffb8 ffff
0000010 3fec 3896 ebf2 0000 0002 0001 0036 0000
0000020 3fec 3896 ebf7 0000 0002 0002 0414 0000
0000030 3fec 3896 ebfd 0000 0000 0000 0000 0000
0000040 3fec 3896 ee80 0000 0002 0000 ffb8 ffff
0000050 3fec 3896 eea9 0000 0002 0001 0036 0000
0000060 3fec 3896 eeaf 0000 0002 0002 0132 0000
0000070 3fec 3896 eeb5 0000 0000 0000 0000 0000

以第一筆資料來說:

3fec 3896 ebe5 0000 是時間
0000 0002 是事件的種類
接下來的 0000 是 X 軸, 而 0001, 0002 分別是 Y 軸及 Z 軸
ffb8 ffff 是 Accelerometer 的數值.

你可以參考 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval 的內容, 用 perl/python, 或是 C 來讀取 accelerometer 數值. Community 的 rui 也 donate 了一個程式 rotate, 可以偵測手機機身的狀態. Source code 可以從這取得:

http://t0ny.net/openmoko/samples/src/rotate/ 執行結果如下.

root@om-gta02:~# ./test
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-792), b(-252), c(522)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-810), b(-252), c(558)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-810), b(-270), c(540)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-774), b(-270), c(504)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-792), b(-270), c(522)
left

* 利用 Accelerometer 作動作捕捉

基本上像 Wii Sport 之類的遊戲, 都是透過比較複雜的動作捕捉方式來完成, 並不是單純的讀某一個時間的 Accelerometer 數值達成. 動作捕捉並不需要 2 顆 Accelerometer (模擬 gryo sensor 才需要), 但是需要比較/紀錄不同 Accelerometer 資料以及作加速度計算等. 在 GSoC (Google Summer of Code) 上, 有一個透過 FreeRunner 來做動作捕捉的範例.





Source code 及可安裝的 ipk 在此, 還意外的看到了 bb 檔 ;)
http://code.google.com/p/accelges/source/browse/#svn/trunk

論文位址如下:
http://dev.borza.ro/demo/Motion-based%20Gesture%20Recognition%20with%20an%20Accelerometer/Paper.pdf
另一個有關把 motion sensor 專案當成遙控器的專案是 ReMoko, 程式分為 target 端及 server 端:
Source 在:

Google Developer 也有官方的 sample

http://developer.android.com/resources/samples/AccelerometerPlay/index.html

呵, 突然發覺還是有 tube 有真相.

2009/3/10

FreeRunner 的 Koolu Android 及 Android cupcake source 位置及 image 安裝


Neng-Yu Tu (Tony Tu)

Cupcake 是 Android 在 release 1.0 之後, 開發人員根據 Android 的 roadmap 及問題, 提供的 update 版本 (接下來的 codename 根據 wiki 好像是甜甜圈). 這個版本基本上是以一個 development branch 的方式進行, 所提供的 update 及 bugfix 最終會 merge 到下一個 Android 的 release 版本.
cupcake branch 的詳細內容 http://source.android.com/roadmap/cupcake
目前 android on Freerunner 已經 host 在 google code 上 (http://code.google.com/p/android-on-freerunner/), 完整 freerunner android cupcake source 放在 http://gitorious.org/android-on-freerunner 的 git 上.

Koolu 是 Openmoko 在北美地區的經銷商, 專注在 Android 在 FreeRunner 上的應用. 從某個角度來說, Koolu 是 FreeRunner 的 Android distro maintainer. 所以 Koolu 的 Android image 會每個月更新. Koolu Android maintainer 是 brian code 及 maddog, 相關的討論可以到 koolu 的 forum 找到:

http://forum.koolu.org/

Koolu Android Beta 4 開始, 提供了更簡單的 FreeRuuner 安裝方式. 同時, Beta4 及 cupcake beta1 最大的改變是取消了原來 FR Android 需要 SD 卡的限制. 同時, 安裝程序簡單許多. 安裝步驟如下:

* 到 http://koolu.com/~marcelo/ , http://code.google.com/p/android-on-freerunner/downloads/list 或 http://t0ny.net/openmoko/images/android/ 下載 Beta4 或 cupcake 的壓縮檔.
* 將檔案解壓縮後, 直接 copy 到 fat 格式的 SD 卡 (不需要分割)
* 將 Copy 完的 SD 卡放入 FR, 按下 Aux 鍵後按 Power 鍵開機, 用 Aux 鍵選 Boot From SD card
* 安裝程式會自動完成安裝動作, 重新開機後即可進入 Android. 同時 ... SD 卡可移除!!!
另外, debug 的連現在 beta4/rc1 有一些改變, 以前 USB connection 都是 hook 在 usb0, Koolu beta4/rc1 開始 hook 在 eth3 (or ethx) 上.
原先的 debug 連線命令:
#ifconfig usb0 192.168.0.200 netmask 255.255.255.0
#ADBHOST 192.168.0.202 ./adb shell
新的 debug 連線命令:
#ifconfig eth3 192.168.0.200 netmask 255.255.255.0
#ADBHOST 192.168.0.202 ./adb shell
ADB tools 是 SeanMcNeil 提供的 tool, 可以從 http://t0ny.net/openmoko/util/target/ 下載 adb binary

2008/12/26

Neo FreeRunner 新手手冊 (10) 認識 Openmoko 社群, 環境, 工具以及開發人員


Neng-Yu Tu (Tony Tu)

Openmoko 是一個非常特別的專案, 也是目前唯一軟體及硬體都完全根據 Open source 社群精神公開的專案. 2006 年底, 第一個產品 Neo1973 (GTA01) 在市場上販售前, 所有相關的程式碼及開發資訊就已在網路上公開. 在2008 年 6 月 FreeRunner (GTA02) 發售後, 相關的電路圖 (schematics: http://downloads.openmoko.org/developer/schematics/ ) 以及外型設計 CAD 檔 (Housing: http://downloads.openmoko.org/developer/CAD/) 也都開放給開發人員下載. 同時也提供了大部分的硬體 datasheet 供開發人員有機會 base on 在原設計下進行自己的設計.

[開放原始碼社群常使用的工具]
這幾年來, 許多硬體產品除了原先的出貨的功能外, 會有開放原始碼社群加入開發或以 hack 的方式增加原先產品的功能. 比較有名的例如最早建立在 Linksys 的 WRT54G 的 OpenWRT ( http://openwrt.org/ ) 專案, 提供了無線 AP 的相關 firmware. 或是最近的 Google Android 也提供了幾乎完整的原始碼在 http://android.git.kernel.org/ .

而其它的像是 Gumstix ( http://gumstix.com/ ) 也有 Windows CE (http://www.codeplex.com/gumstix) 及 OpenEmbedded (http://www.gumstix.net/) 不同的討論社群. 基本上, 開放原始碼社群進行開發 (極端的分散式開發 ;) ) 使用的工具有下列幾項:

* 郵件/即時線上討論: IRC, mailing list, jabber
* 原始碼管理: svn 及 git
* 知識管理: wiki
* Developer 個人的分享: planet/blog
* Bug 追蹤/Issue tracker: Trac/Bugzilla
* Project 管理: taskjuggler
* 常用的免費服務: sourceforge, google xxx (code/calendar/docs) 等
* 釋出版本及套件下載

[線上討論]
Oopenmoko 的線上公開討論區是在 Freenode 的 #openmoko , Windows 的使用者可以用 mIRC 或是其他 IRC 軟體.

[郵件討論]
在開放原始碼社群 (open source community)中, 傳統的 mailing list 是最常見的討論方式, 以及 irc. 這一點和國內常用的討論區方式不同. Openmoko 的 mailing list 列表在這裡: http://lists.openmoko.org/mailman/listinfo/ 如果你習慣討論區的介面, 可以透過http://lists.openmoko.org/nabble.html 來加入討論.

最重要的有:

* community: 社群主要的討論區, 包含常見問題, 發展方向, 抱怨, 希望...等
* devel: 軟體相關討論: 主要是在應用程式 level, 包含工具, 各個 distribution, release package 討論
* kernel: 相關 kernel porting/driver bugs, 以及介於 software 和 hardware 相關的問題
* hardware: 硬體相關問題討論, hardware bugs
* support: 常見的 distribution 問題, 硬體瑕疵和軟體使用問題等

在這些 mailing list 進行訂閱動作後, 相關的討論 mail 就會寄到你的信箱, 通常一個單一 list 一天都會有數封到數十封不等的信件. Android 或其他的 Open Source 專案, 都以類似的方式進行資訊分享與協同開發.

[原始碼伺服器]
Openmoko 是一個開放原始碼專案, 當然提供所有相關的原始碼供使用者下載. Openmoko 使用下列原始碼伺服器:

<git 伺服器>
位址: http://git.openmoko.org/

可能一般開發人員對 svn 或是 virtual source safe 的原始碼管理方式比較熟悉, 但是對於 git 可能會有一些陌生. git 最主要的優點就是分散式設計, 可以快速 branch. 舉例來說, 每個人自己 clone 下來的 git 都是可以自己 branch, 同時可以在本機 commit 自己的 code. 不需要連回原 server 做 commit 的動作. 網路上的有許多的 cheat sheet (http://git.or.cz/gitwiki/GitCheatSheet), 可以印出來, 讓你快速習慣工具使用. Openmoko 的 git 裏, 主要有:

* Linux Kernel 相關的原始碼及 patch
* u-boot 相關原始碼及 patch
* qi 一個精簡的 boot 程式, 最早是 werner 想用 k-boot 換掉 u-boot, 後來變成帶有東方味的 qi (氣)
* xglamo: FreeRunner 用的 X driver
* 產測相關軟體 production-testing
* 開發人員的自己使用的 tools 及 Distribution fork

Openmoko 的 git 基本上是從 vanilla linux kernel (未修改的 linux kernel from kernel.org), 加上 ARM 相關的 patch, 再加上 Ben Dooks 的 S3Cxxxx 的 porting patch, 最後加上 Openmoko 自己的patches. 相關的說明可以參考這一頁:
http://git.openmoko.org/?p=kernel.git;a=summary

<svn 伺服器>
位址: http://svn.openmoko.org/

Neo1973 開發時, Openmoko 使用的主要版本控制系統. 不過目前 kernel 及 u-boot 都已經被移到 git 中繼續開發. Svn 留下的是一些比較小型的專案/工具, 以及開發人員所會用到的開發工具放在 svn 中.

[Bug 追蹤/Issue tracker]
Openmoko 使用 Trac (http://trac.edgewall.org/) 作為主要的 Bug track 及 Issue track. 通常這類 Bug/issue tracker 工具的功能都差不多, Trac 的介面整合了 wiki 跟 issue tracker 的功能, 是用 python 作維護. Openmoko 的 Trac 在 http://docs.openmoko.org/trac/

[知識管理 - wiki]
開放原始碼專案大部分都會提供某一種的 "共筆" 平台, 讓參加專案以及想發表心得的人可以有一個地方把資訊有系統的紀錄下來. 通常許多的話題都是從 mailing list 開始, 然後討論的結果會到 wiki 或是 Trac �. Openmoko.org 的首頁就是 wiki (http://wiki.openmoko.org/wiki/Main_Page), 同時, Openmoko 的 wiki 也是使用 wikipedia 使用的 media wiki.

* Mailing list 討論有明確結果 -> Wiki
* Mailing list 討論有 bug -> Trac/Bugzilla

要新增/修改/刪除 wiki 頁面上的資料, 必須先在 wiki 上建立帳號, 同時 wiki 上有 一些重要頁面是保護狀態. 只有 Wiki Administrator 才能修改.
[釋出版本及套件下載]
Openmoko 目前釋出的版本及對應的套件 (testing/released/un-stable) 都是放在 http://downloads.openmoko.org/ . 各個社群的 Distributions 可以從各自的網站下載. 要使用預先打包好 opkg 應用程式, 可以參考 http://www.opkg.org/

[相關應用開發]
Openmoko 有自己的 project server (http://projects.openmoko.org/), 申請帳號後即可在 project server 建立新專案. 但是 Openmoko 有計畫要 phase out 這個 server. 所以目前 Openmoko 內部的公開 project, 開始 host 在 google code 上, 例如 motion senor (accelerometer) 的 omnewrotate, 新的 contacts/sms/dialer 介面專案 paroli 等.

[主要開發人員]
Openmoko 最早成員是 Sean Moss/Michael Lauer (Framework)/Harald (Low Level driver and HW consultant)/Werner (bootloader and HW consultant), Sean 帶領了大家開始了這個奇妙旅程.

Openmoko 主要的開發人員都在 wiki 的 Who is Who 頁面中 ( http://wiki.openmoko.org/wiki/Who_is_Who ). 透過 mailing list 或是討論區介面的 mailing list nabble (http://lists.openmoko.org/nabble.html) 是最直接的方式.
雖然大部分的 developer 已經成為歷史 (Sad...), 但是我還是把名字列出來 (2009, March upadte)

[SW]

Andy Green: kernel/Driver (http://warmcat.com/_wp/)
Werner Almesberger: Kernel/Driver/u-boot (http://www.almesberger.net/cv/papers.html)
Matt_Hsu: Kernel/Driver (http://matthsu-abacus.blogspot.com/)
Michael 'Mickey' Lauer: FSO/GTK (http://www.vanille-media.de/site/index.php/about/)
Brenda: Wiki
Roh: IT infrastructure
Gismo: IT infrastructure/SysOP
Marek Linder: Project coordinator
John_lee: OE/Distribution maintenance (http://asleepfromday.wordpress.com/)
Holger 'zecke' Freyther: System/QT (http://zecke.blogspot.com/)
Wendy: Testing
Regina: Testing
Tick: opkg/installer/etk/OE (http://linuxocarina.blogspot.com/)
Will: Design, Product manager
Guillaume 'Charlie' Chereau: FSO/Python (http://charlie137-2.blogspot.com/2009/01/paroli-get-website.html)
Julian: Distribution (http://walkingice.twbbs.org/blog/)
Olv: X/LBS application (http://olvaffe.blogspot.com/)
Erin: GTK/Python (http://i-miss-erin.blogspot.com/)
Jeremy: LBS
Willie: Early kernel/production work (http://openmoko.wordpress.com/)
Sean Chiang: gsmd/gps application
Miles: production test
Jelan Hsu: certification/production test
Raster: enlightment/etk/everything (http://www.rasterman.com/)
Harald Welte: kernel/everything (http://laforge.gnumonks.org/weblog/)
Jserv: kernel/application

[HW]

Tim Lee: EE
Allen: EE
Shawn: RF


And Me ;) GTA01/02 PM, the one should be damned :)

2008/12/22

Neo FreeRunner 新手手冊 (9) 安裝 Android, SHR, FDOM, Debian 到 SD (SDHC) 卡


Neng-Yu Tu (Tony Tu)

一般手機或移動式行動裝置只能執行預先安裝的作業系統, 應用程式的寫作也受到 framework 本身的限制, 也不能更換作業系統. Openmoko 的硬體基本上打破了這些人為加上的限制, 透過公開線路圖及取得相關技術文件授權的方式, 提供一般裝置使用者, 可以取得足夠的資訊開發新的移動裝置軟體. 這也是 Openmoko 和 Android 最大不同的地方. 相關完整的說明請參考 http://wiki.openmoko.org/wiki/Boot_from_sd_card

Openmoko 為了解決使用者需要在快速不同作業系統/版本間切換的問題, 所以在 u-boot 設計時, 設計了可從 SD 卡開機的功能, 這個功能同時可由開機的選單啟動或關閉.

FR 的兩份 u-boot, 都可支援 Boot from SD 功能, NOR flash 裡面的 u-boot, 預設開機選單即可選擇從 SD 卡啟動 (先按下 Aux 鍵, 再按電源鈕). 一份是在 NAND flash, NAND u-boot 預設無開機選單.開機看不到開機選單的原因是: u-boot 預設不顯示開機選單, 但可以用先按 power 鍵開機 0.5 至 1 秒後, 按下 AUX 鍵不要放的方式, 使 NAND 的 u-boot 出現開機選單.

注意: 但是 NOR 裡面的 u-boot (可能比較舊) 在 boot SDHC 的 SD 卡時, 可能會無法啟動. 此時就只能使用 NAND 的 u-boot. 同時, 某些 SDHC 有相容性的問題, 請參考: http://wiki.openmoko.org/wiki/Supported_microSD_cards 的內容, 確認你使用的 FR 使用的是支援的 SD 或 SDHC卡, 建議直接使用 SanDisk 的 SD/SDHC 卡可以省去許多相容性的問題.

開機後, u-boot 就會去尋找檔名為 uImage.bin 的檔案 (2008/04 前的 NOR 或 NAND u-boot, 會尋找檔名為 uImage 的檔案)

[修改 NAND 開機選單 (NAND u-boot)]
你可以透過 u-boot 修改環境變數, 加入 menu items 及對應的啟動數值. 或是直接利用 dfu-util 更新環境變數檔案 (可從這邊下載檔案 http://t0ny.net/openmoko/samples/config/env_menu.new). 直接 ./dfu-util -a 2 -R -D env_menu.new . 在 u-boot 的 command prompt, 可以利用 printenv 來看到目前的參數, 用 setenv 來設定每個參數的值.

[製作可開機的 SD 卡]
目前 Openmoko u-boot 對於可開機的 SD 卡的限制, 是必須包含兩個 partition, 第一個 partition 必須是 vfat 格式 (2008/8 月前的 u-boot 都有此限制), 用來放置檔名為 uImage.bin 的 kernel image 檔案. 第 2 個 partition 必須為 ext2/3, 用來放置整個 rootfs 的檔案.

Step 1: 分割 SD (SDHC) 卡 (一般來說, SD 卡原先都會預先 format 成 fat32, 請一樣用 fdisk, 先刪除原有的 fat32 partition)
root@ubuntu:~# fdisk /dev/mmcblk0
The number of cylinders for this disk is set to 125632.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-125632, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-125632, default 125632): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (246-125632, default 246):
Using default value 246
Last cylinder or +size or +sizeM or +sizeK (246-125632, default 125632):
Using default value 125632
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.

Step 2: 格式化 SD (SDHC) 卡
root@ubuntu:~# mkfs -t vfat /dev/mmcblk0p1
mkfs.vfat 2.11 (12 Mar 2005)
root@ubuntu:~# mkfs -t ext3 /dev/mmcblk0p2
mke2fs 1.40.2 (12-Jul-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
501952 inodes, 1003096 blocks
50154 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1027604480
31 block groups
32768 blocks per group, 32768 fragments per group
16192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

格式結束後, 這一張 SD (SDHC) 卡就可以準備放入 uImage.bin (第 1 個 partition vfat)及 rootfs (第 2 個 partition ext2/ext3) 的檔案及目錄.

[下載需要 kernel 及 rootfs]
每一個 Distribution 幾乎都是一組對應的 rootfs 及 kernel 方式存在. 原因大部分都是因為每一個 Distribution 裡面的程式已經都是在某個時間點將所使用的 package 做 snapshot 或是 fork 出來, 同時某些驅動程式版本及設定檔位置, 也會隨著 Distribution 不一樣. 所以幾乎每一個不同的 Distribution 都提供了成組的 kernel 及 rootfs. 目前 (2008 Dec)唯一不同的是 FDOM, 因為 FDOM 預設的 kernel 對象是 2008.X, 所以 FDOM 使用的 kernel 可以從 downloads.openmoko.org 取得.

同時, 開機 SD 卡裏的 rootfs 是直接以目錄及檔案的方式存在, 所以需要 download rootfs.tar.gz 的整包壓縮檔, 而不是使用 flash 到 NAND flash 的 .jffs2 檔.

請到下面網址, 取得 image 檔案, 有一些網站還提供了 gta01 的版本, download 時請注意.

SHR: http://shr.bearstech.com/
FDOM: http://www.tuxbrain.com/fdom_en.html
Debian: http://wiki.debian.org/DebianOnFreeRunner
Android: http://people.openmoko.org/sean_mcneil/ 或是 http://freerunner.android.koolu.com/release-files or http://t0ny.net/openmoko/images/android/ 在這邊放了一份 snapshot

[安裝 SHR]
SHR 是法國的 bearstech 所提供的版本, 主要以 illume 的 theme 為主的 Distribution. 安裝 SHR 很簡單, 只要 download image 後, 直接 copy uImage.bin 及 rootfs 的檔案到 SD 卡中.

Step 1: 製作一張標準的開機 SD 卡 (最好需要 512 MB 或以上)
Step 2: 複製 uImage.bin 到第一個 SD 卡的 vfat partition 中. 請注意, kernel 檔案必須是 uImage.bin , u-boot 才會認得.

root@ubuntu:~/moko/shr_images# ls
shr-image-om-gta02.jffs2 uImage-om-gta02-latest.bin
root@ubuntu:~/moko/shr_images# cp uImage-om-gta02-latest.bin /media/disk-1/uImage.bin

Step 3: 下載並解開 rootfs.tar.gz 檔案 (tar zvxf rootfs.tar.gz)
Step 4: 到解開的檔案根目錄下, 將整個根目錄 structure 複製到 SD 卡的第 2 個 partition (ext2/ext3) 中 (cp -r . /media/disk-2)

root@ubuntu:~/moko/shr# ls
bin dev home linuxrc media proc tmp var boot etc lib local mnt sbin sys usr
root@tony-ubuntu:~/moko/shr# cp -r . /media/disk-2

Step 5: 用 sync 命令確定檔案已經完整複製過去
Step 6: umount 後將 SD 卡放到 FR 中, 由 NAND 或是 NOR boot 開機選擇 Boot From SD card 選單開機.

[安裝 Debian]
在 SD 卡上安裝 Debian 很簡單, 但是程序有些不一樣. 因為 Debian community 寫了一個 script 讓安裝到 SD 卡的動作自動化. 我覺得這個 script 跟 mokomakefile 一樣, 都是發揮 linux 安裝優點, 而且非常有趣的 script.

Step 1: 製作一張標準的開機 SD 卡 (最好需要 512 MB 或以上)
Step 2: 將 SD 卡放到 FR 中, 同時以 2008.X 或 FSO milestone 3/4 開機
Step 3: 建立 FR 到 Internet 的連線 (可透過 USB 或是 WiFi/Bluetooth)
Step 4: 在 home 目錄下執行:
$ wget http://pkg-fso.alioth.debian.org/freerunner/install.sh
$ chmod +x install.sh
$ ./install.sh all

Step 5: 此時 install script 會將所有檔案, 複製到 SD 卡的第 1 個及第 2 個 partition 中.
Step 6: 複製完後, 可檢查 uImage.bin 檔是不是放到第 1 個 partition 中, 以及相關的 rootfs 是不是放到第 2 個 partition 中.
Step 7: 安裝完, 關機, 重新由 NOR 或 NAND u-boot 開機後, 選擇從 SD 卡開機即可.

目前 Debian Distribution 預設的使用者 UI 是 FSO 的桌面, 所以如果你不確定你執行的是 Debian 還是 FSO, 可以直接用 uname -a 看 kernel 的版本.

[安裝 Android]
Android image 跟一般 image 不一樣的地方在於 Android 目前無法單獨放到 SD 卡上執行. Android 執行時, 需要 NAND flash 及一張空白的 SD (非 SDHC)卡在 FR 中. 所以要在 FR 執行 Android, 需要利用 dfu-util 或是 Neotools 安裝 Android 的 uImage 及 Android 的 rootfs 到 NAND flash 中, 並準備一張 128 MB (512 MB 或以上 preferred) 的 "空白" SD 卡.

Android 需要的空白 SD 卡一樣需要 2 個 partition, 第一個 partition 建議還是使用 vfat (非必要), 第 2 個 partition 需要 ext3 格式. 第一個 partition 中, Android 在第一次開機時, 會建立存放 media 檔案 (影像/聲音) 的相關資料夾. 而在第 2 個 partition 中, Android 會建立 kernel 相關需要的設定檔 folder.

Step 1: 準備 Android 所需要的空白 SD 卡 (非 SDHC 卡)
Step 2: 下載 Android 所需要的相關檔案
Step 3: 執行 dfu-util 將 Android 的 uImage.bin 及 rootfs dfu 到 FR 中. 請注意, kernel 檔案必須是 uImage.bin , u-boot 才會認得.

Step 4: 將 SD 卡放到 FR 後開機. 一般來說, 第一次開機需時 2-3 分鐘. 若超過 5 分鐘無法開機, 請重新移除 SD 卡, 放回 SD 卡後, 重新開機.

同時 2008/11 月前的 FR Android kernel 會發生 suspend 後無法 resume 的情形, 請 disable suspend (在 system settings 最下方有一個 suspend 的時間設定) 功能. 2008/11的 image 進入 suspend 無法開機時, 可刪除第 2 個 ext3 partition 的檔案 (kernel/setting 檔), 通常即可開機.
Koolu 目前 update 的 image 可以從下網址下載 http://freerunner.android.koolu.com/release-files

2008/12/9

Neo FreeRunner 新手手冊 (8) 已知的硬體問題


Neng-Yu Tu (Tony Tu)


FreeRunner 和一般的一般的嵌入式硬體開發及使用過程不太一樣的地方, 就是幾乎所有的開發流程跟硬體問題都可以在討論區找到. 同時也會有許多社群上的人會幫忙測試及提供解答. 所以原先當 FR 在開發流程中沒有測試到的 test case 產生的硬體 Bugs, 也都可以看到社群上的人幫忙整理及討論. 比較詳細的問題在以下的 wiki 網頁中.

http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware_Issues 以下是一些常見硬體 Bug 的問題及解決辦法.

[你的硬體版本及軟體版本]
FR 到目前已知有 A5, A6, A7 版本, 從 A5 版本起就是真正量產版本. 觀察版本有幾個方法, 一個是透過 part number, 另一個是透過 cat 手機內的硬體版本資訊. 用軟體指令無法區分是 850/1800/1900 或是 900/1800/1900 硬體版本.

1) Software
* kernel : uname -a
* rootfs : cat /etc/version or cat /etc/om-version
* u-boot: grep Bootloader /dev/mtdblock0 (yields the NOR u-boot version) or grep Bootloader /dev/mtdblock0 (yields the NOR u-boot version)

2) Hardware
* cat /proc/cpuinfo 或 cat
從 revsion ATAG 得知目前的版本, 0350 是 A5, 0360 是 A6, 0370 是 A7 等

3) Part number:
* 56-21146-00 A5 850/1800/1900 版本
* 56-21147-00 A5 900/1800/1900 版本
* 56-21176-00 A6 850/1800/1900 版本
* 56-21175-00 A6 900/1800/1900 版本
* 56-21210-00 A7 850/1800/1900 版本
* 56-21209-00 A7 900/1800/1900 版本

[GPS]

* 問題
這是第一個被發現出來的問題, 就是使用者無法利用內建的 GPS 定位系統得到自己的定位. 這個問題會發生在量產品原因是在設計 test case 時, SD 卡及 GPS 協同運作時 GPS 的訊號是從增強過的 GPS 室內天線發出. 同時產測也是使用增強的 GPS 天線以便配合測試. 所以當使用者在正常 GPS 訊號強度下, 同時使用 SD 卡時, GPS 會無法定到位, 或是需要數十分鐘到數小時才能定位. 這個問題被社群反映後一週, 有人確認此情況只在 SD 卡插入時才發生. 之後確認是 SD card 的 sd_clk 產生的背景干擾.

* 修正方式
Openmoko 1 天後提出第一個這個問題的軟體解法, 就是當無 SD 卡存取動作時. 驅動程式會自動關閉 sd_clk 訊號. 這個修正已經套用在所有 2008 年 8 月後的 kernel 驅動程式中. 一週後提供了硬體解法, 該解法是在 sd_clk 跟 sd_gnd 中間加一個 10 pF 的電容過濾/改變/減低會影響 GPS 的高頻雜訊位置. 此修正已套用在 GTA02 A6 版以後的版本. 經過社群的測試, 軟體修正的效果跟硬體修正的效果類似, 所以 FR 的 GPS 問題目前用 2008 年 8 月以後的 kernel 即可解決.

* 測試方式
可以參考前面 GPS 相關的使用說明

[GSM SIM 卡相容性]
一般的手機有區分為 2G/2.5G 手機及 3G 手機, SIM 卡也有區分 2G 及 3G 的 SIM 卡, 同時 SIM 根據本身設計, 還有 5V, 3V, 1.8V 等不同電壓規格.
GTA02 出貨用的 GSM firmware 預設為 moko8 或是 moko9-beta 1 版本. 目前 FR 可用及有問題的 SIM 卡, community 將資訊收集在以下網址:
http://wiki.openmoko.org/wiki/FreeRunner_unable_to_work_with_3G_SIM_cards

由於 GSM firmware 擁有獨立的版本, 記憶體儲存位置. 所以並沒辦法經由更換 kernel 或是 rootfs 解決.必須透過 TI 提供的 calypso firmware 更新程式 fulid 來更新. 目前最新的版本是 moko 10, 初步測試可解決 GSM 3G SIM 卡相容性的問題, 使用者可參考以下網址更新:http://wiki.openmoko.org/wiki/GSM/Flashing

GSM firmware 更新有可能會失敗, 意思是可能會讓 GSM (手機功能) 無法使用.請注意

[GSM Buzz]
FR 在 A5/A6/A7 均受到程度大小不一的 GSM buzz (有些人稱為 TDD noise) 的問題, 這也是已知無法用軟體修正的問題. 主要是 FR 內 GSM RF 干擾發生的.目前討論區已有硬體改電阻加電容的 workaround 解法, Openmoko 提出的 A5/A6 版修正 SOP 在以下位置 http://people.openmoko.org/joerg/GSM_EMI_noise/

[SD 卡相容性]
* 問題
市面上有許多品牌/規格不同的 SD 卡, 並不是每一種 FR 上面都可以直接使用. 原因是因為各家 SD 卡供應商都有自己的控制晶片, 各晶片對於 SD 規格相容程度不一. 同時, 目前有 SD 卡也有兩種規格 SD 及 SDHC, 後者是較新的規格. 目前 2GB 以上的 SD card 均為 SDHC 的規格. 由於 FR 使用的 SD 驅動程式並沒有經過這麼多種類的 SD 卡測試, 所以僅提供了 "有限的" 相容性. 目前測試已知相容性最好的是 Sandisk 的 SDHC flash 卡.
* 修正方式
目前 Community 測試 microSD 卡最大的是 16 G 的 SDHC, 但是可能需要做一些 SD 卡時脈設定及調整的工作. 經過測試可使用的 SD 卡也都列在 wiki 中 http://wiki.openmoko.org/wiki/Supported_microSD_cards

[電池過度放電的問題]
*問題
由於 FR 的軟/硬體組合設計上, 還有可能會發生關機不完全的漏電現象, 導致電池放電至低於 3.4v, 甚至到幾近 0v 的狀態. 此時會發生一個狀況, 就是當電池放到 FR 中後, 即使插上充電器, 還是無法充電的狀態. 原因是因為無法開機到最基本的 u-boot, 電源管理 IC 無法被正確設定可充電. 同時, 因為電池電壓已經過低, 甚至 PMU "不認為" 電池已經放入 FR 中. 所以導致無法即使插入充電器, 還是無法充電.
*修正方式
有幾個方式可以讓過度放電的電池重新充電:

1) 最快, 也最方便的方式就是使用 Nokia BL-4C/5C/6C 相容的電池充電器替 FR 電池充電, 因為 FR 的電池基本上和 Nokia BL-4C/5C/6C 電池相容. 所以一般市面上 200 元的 Nokia 電池相容充電器均可替 FR 電池充電.

2) 利用 BL-4C/5C/6C 的電池替 FR 開機後 (按下 Aux 鍵, 後按電源鈕從 NOR flash 開機), 接著連接 USB 充電器或是電腦的 USB 埠. FR 可以靠 USB 電源維持開機的狀態, 然後放入已過度放電的電池進行充電.

3) 可以試著拔除電池, SIM 卡, 及 SD 卡, 用 USB 線連接 FR 及電腦或直接使用包裝中附的 USB 充電器, 然後按下 AUX 鍵及電源鍵開機至 NOR 的 u-boot (GTA02 A6 版及以後的硬體, 均應該設計搭配此功能), 開機後, 放入已過度放電的電池進行充電.

2008/12/3

Neo FreeRunner 新手手冊 (7) GPS 及 A-GPS 功能


Neng-Yu Tu (Tony Tu)


Openmoko FreeRunner 使用的是 U-Blox 4 ANTARIS 的晶片組, 這個晶片組提供了 16 個 channel 的標準 GPS 及透過輔助資料快速定位的 A-GPS 功能. GPS 功能啟動後, 就可以從 Neo 的 ttySAC1 得到 NMEA 碼. U-Blox 的 GPS 功能跟一般 GPS 一樣, 一般所需時間從 40 秒 (U-Blox 規格) 到數分鐘不等. 這個時候可以透過一般 GPS 軟體 (TangoGPS/Openmoko AGPSUI/Others) 來做定位的動作. 完整 FR 的 GPS 相關資料可參考.

http://wiki.openmoko.org/wiki/GTA02_GPS

U-Blox 的 A-GPS (Assisted GPS) 分為 A-GPS online 跟 A-GPS offline 兩種不一樣的功能, 差別如下:

* AGPS online: 每次使用時, 需連上網路, 到 agps.u-blox.com 下載約 2-3 k 的定位輔助資料. 定位輔助資料包含了目前使用者上方應該有哪些衛星等資料. 每次下載的資料有效時間約 4 小時.

* AGPS offline: 若原先硬體設計時就包含一顆額外的 Flash 記憶體, U-Blox GPS 在啟動時, 會先從該記憶體找輔助定位資料. 輔助定位資料可以預先從 http://alp.u-blox.com/ 下載, 資料大小從數 k 到數十 k 不等, 資料最長有效時間約 2 個星期, 依下載的檔案而定.
這 2 種定位方式都可以有效的將定位時間縮短到 20 秒內, FR 硬體設計只支援 AGPS online 的模式. FR 也提供 GPS 外接天線的 MMCX 插座, 當連接外部天線時, 硬體會自動切換訊號成外部的 GPS 訊號來源, 軟體無法知道硬體是使用內部還是外部的天線. 一般市面上的有 MMCX 的 GPS 天線, "原則" 上都可以使用.
使用 A-GPS 功能可以加快定位的速度, 但是無 A-GPS 輔助, FreeRunner 還是擁有 GPS 的功能.

[** 硬體BUGS**]
A5 版硬體 (ATAG 0350) FR 的 GPS 功能有一個已知的問題, 就是 microSD 卡插入時, sd_clk 訊號, 可能會干擾 GPS 天線. 這個問題有兩種方法可以解決, 一個是更換新的 FR kernel driver, 這個 driver 可在不使用 microSD 卡時, 關閉 sd_clk. 一個是在硬體的 sd_clk 及 sd_gnd 腳位加一個電容, 濾掉部分會干擾 GPS 頻率的雜訊. 目前 kernel driver 修正已經套用在所有 2008/7 月後的 kernel, 相關資料, A6 版及以後的硬體, 也都已套用此修正, 請參考: http://wiki.openmoko.org/wiki/GPS_Problems

[基本 GPS 使用及測試]
使用 GPS 前, 必須先開啟 GPS 的電源. 開啟 GPS 電源可以下命令或是從 2008.X 使用者介面上的 Setting �, 開啟 GPS 電源. 然後接著可以把 ttySAC1 的資料吐出 來.

root@om-gta02:~# echo "1" > /sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron
root@om-gta02:~# cat /dev/ttySAC1
W 80040001*26
$GPTXT,01,01,02,ROM CORE 5.00 Jan 09 200$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79

如果要檢查是否有得到定位, 可以可以從 ttySAC1 得到 GPS 吐出的 NMEA 資料, NMEA 資料基本的格式是: 項目 - 數據. 簡要的項目說明如下:
$GPBOD - Bearing, origin to destination
$GPBWC - Bearing and distance to waypoint, great circle
$GPGGA - Global Positioning System Fix Data
$GPGLL - Geographic position, latitude / longitude
$GPGSA - GPS DOP and active satellites
$GPGSV - GPS Satellites in view
$GPHDT - Heading, True
$GPR00 - List of waypoints in currently active route
$GPRMA - Recommended minimum specific Loran-C data
$GPRMB - Recommended minimum navigation info
$GPRMC - Recommended minimum specific GPS/Transit data
$GPRTE - Routes
$GPTRF - Transit Fix Data
$GPSTN - Multiple Data ID
$GPVBW - Dual Ground / Water Speed
$GPVTG - Track made good and ground speed
$GPWPL - Waypoint location
$GPXTE - Cross-track error, Measured
$GPZDA - Date & Time

參考這邊可以得到完整 NMEA 的說明. http://www.gpsinformation.org/dale/nmea.htm
由於 NMEA 資料很多, 若你只要定位與否相關資料, 可以cat /dev/ttySAC1 grep GGA , 就可以過濾掉額外的資訊.

[使用 AGPSUI]
Openmoko-agpsui2 是 Openmoko 常用的 GPS 測試程式, 可以以圖形方式, 看到 GPS 訊號強度, 衛星在天頂的位置, 定位詳細資料等. openmoko-agpsui2 可以透過 opkg install openmoko-agpsui2 或是從這邊下載 opkg 檔安裝:

http://t0ny.net/openmoko/opkg/samples/agpsui_0.0+svnr3372-r0_armv4t(3).ipk

下載後, 利用 scp copy 到 FR, 直接執行: opkg install agpsui_0.0+svnr3372-r0_armv4t(3).ipk 接著就可以按下畫面下的 one fix 執行.

Openmoko-agpsui2 的原始程式碼, 可以從: http://projects.openmoko.org/scm/?group_id=127 下載. 但是由於 Openmoko 正在 phase out 目前的 project server 並轉移到其他的 platform (如 google code), 所以你可以這邊 download offline 的 source. 詳細使用 AGPSUI 的方法, 請參考: http://wiki.openmoko.org/wiki/Howto_Test_Your_GPS_with_agpsui

[gpsd 及 TangoGPS]
因為 ttySAC1 對 linux 來說是標準的 serial port, 所以當某一個程式 (如 openmoko-agpsui) 佔住後, 其他程式就無法讀取 GPS 資料. 為了要解決多個程式使用 GPS 的問題, 同時增加客戶端程式寫作的彈性及架構. 所以 community 有人做了一個 GPS 的 daemon, 叫做 gpsd ( http://gpsd.berlios.de/ ). 應用程式可以透過網路連線 (localhost) 方式 (TCP port 2947), 讓多個不同的程式同時取得 GPS 的定位資料. GPSD 相關的說明請參考http://wiki.openmoko.org/wiki/Gpsd#GPS_on_GTA02

TangoGPS ( http://www.tangogps.org/ ) 則是一個使用 gpsd 及 OpenStreetMap/Topo/Aerial 的地圖程式. 它提供了一個類似 2008.X 的 Location 程式的功能, 但是它可以提供更多的定位相關資料, 例如目前速度, 平均速度等. 含還蠻適合運動使用. 要使用 TangoGPS 前, 必須先安裝 gpsd.

root@om-gta02:~# pkill packagekit
root@om-gta02:~# opkg install gpsd
root@om-gta02:~# opkg install tangogps_0.9.3-r1_armv4t.ipk

如果 gpsd 或相關套件找不到, 你可能要把 opkg feed 換到 testing feed (/etc/opkg/*.conf) 安裝完後, 啟動 tangoGPS 前, 必須修改 /etc/default/gpsd �, gpsd 的 tty 設定.

設定成 GPS_DEV="/dev/ttySAC1". 更多的設定 (FSO/others), 請參考 http://www.tangogps.org/gps/articles/7-Installation.html

[使用 A-GPS]
每一間 GPS 廠商都有不同的 A-GPS 實做方法, U-Blox 提供了公開的文件及帳號申請程序, 讓使用 U-Blox 的使用者可以使用 A-GPS 服務. 使用 A-GPS 的流程大致如下:

* 申請 A-GPS 帳號: 發一封主旨跟內容都空白的信, 到 agps-account@u-blox.com 申請一個 A-GPS online 的帳號
* 將 FR 利用 GPRS/Wi-Fi 或其他方式連上 Interent, 利用帳號及目前大略的經緯度, 利用 http://svn.openmoko.org/developers/matt_hsu/agps-online/ 的程式, 連上 U-Blox 網站. 取得 A-GPS 定位輔助資料
* 這個程式會利用 U-Blox 的 binary 指令, 將定位輔助資料送進 GPS 模組
* GPS 模組利用這些資料, 節省搜尋衛星的時間

其他更詳細的方式, 請參閱 http://wiki.openmoko.org/wiki/GTA02_GPS .

2008/12/2

Neo FreeRunner 新手手冊 (6) 使用 Debug Board


Neng-Yu Tu (Tony Tu)

Debug Board 對一般應用程式開發人員來說, 可能並不是十分需要. 但是換個角度來說, Openmoko 擁有完全開放的硬體, 從網路上也可以下載 FreeRunner 以及 Neo1973 的硬體線路圖. 同時, Openmoko 的機器在設計上, 就已經將常用的 debug port 如 JTAG/UART/SPI/I2C 等介面連接到主板上的 Debug Connector, 或是將這些 test point 留在主板上容易接取的地方. 簡單來說 Debug Board 是 FreeRunner 設計完全開放硬體的一部分 ;) 如果要學習或練習嵌入式系統開發, 最好還是有 Debug Board 比較好.


Debug Board 留了 1 個 20 pin 的 JTAG 延伸插座, 以及 2 個 10 pin 的 UART/SPI/I2C 插座, 如果有需要, 焊上這些接頭, 就可以在其他的裝置上使用 Openmoko Debug Board. 不過需要注意的地方是, Debug Board 的 JTAG signaling 是使用 3.3v, 對於一些 1.8v 或 5v 的 JTAG signaling 裝置並不適用.

Openmoko 的 Debug Board 共有 3 個版本, 第 3 版 (v3) 跟前面兩個版本的差別在於: 修改了電源及完全符合 USB 規格的一些設計, 同時也將 FR 上 Debug port 預留的 SPI 及 I2C bus 接出到 Debug Board 上. 同時第 3 版的 Debug Board 也增加一個 GPIO 接腳設定功能, 讓 Debug Board 能透過 pull-high 電路讓 FR 上面的 NOR 可以開啟被寫入模式. Debug Board 的電路圖, 可以從以下網址下載.

http://downloads.openmoko.org/developer/schematics/

若要作 JTAG 和 UART 終端機的 Debug 功能, 這 3 個版本都可以達到一樣的功能. 同時 FreeRunner 預設的 u-boot 環境變數, Debug 輸出是 ttyACM0, 並不一定要使用 Debug Board 才能進行 u-boot 的操控.

Debug board 上有一顆 FTDI FT2232 的晶片, 它本身具備有兩個 UART port, 這個晶片奇特的地方在於它可以透過軟體 (不同的函式庫), 轉換不同的通訊協定 (a little like bitbang), 達到支援 RS-232/482/485, DI/O, Address 或是 JTAG. FT2232 的 JTAG 比 Wiggler 快了大約 20-30 倍, 對於除錯時, 節省大量資料寫入的時間有極大幫助 (例如寫入 kernel 及 u-boot 到 nand flash 中)

目前 Openmoko default 的設定是當成 JTAG (port 1) 及 UART (port 2). 同時, 原本這顆 chip 的標準 USB ID 是 FTDI 0403:6010. 0403 是 FTDI 公司的 USB ID, 而 6010 是依據產品別給的不同 ID.

Openmoko debug board 預設的 USB ID 是 1457:5118. 1457 是 FIC 的公司 USB ID. 而 Openmoko 後期的 Freerunner 使用新申請的 1D50 開頭作為標準 ID.

你可以從下面的網址, 找到所有已註冊 USB.org 的公司/裝置 ID.
http://www.linux-usb.org/usb.ids

或 Openmoko 的 wiki, 也紀錄了使用的 ID 位址.
http://wiki.openmoko.org/wiki/USB_Product_IDs

FTDI 公司也提供了標準的 Windows 驅動程式, 讓你可以在 Windows 利用 FT2232 模擬成雙 UART port 的裝置, 或是一個 JTAG, 一個 UART 裝置. 但是由於 Windows 只認識 FTDI 的 0403:6010 ID, 所以必須修改一下 .inf 檔. 下面可以下載 Windows 下的 FTDI 驅動程式: http://t0ny.net/openmoko/driver/debugboard_win32/

除了 Openmoko 外, Linux 社群也常用另一種類似建立在 FT2232 裝置來做 JTAG, 例如 Amontec JTAGkey: http://www.amontec.com/jtagkey.shtml . 這種裝置比較小巧, 同時支援 1.4V 到 5V 的 JTAG signaling, 常被配合標準公版的 20 pin 插座使用.

[安裝 FTDI lib]

會用到 3 個不同的 package, 分別是 libftdi-dev, libftdi-eeprom, libftdi0, 建議開始使用 Debug Board 前先安裝這些 package.

[連接 FR 的 Debug Output (UART)]

由於 Linux 只認識 Default 的 FTDI 裝置 (0403:6010), 所以 Openmoko Debug Board 需要額外載入 FTDI 的 SIO driver. 利用以下指令可載入 FTDI 的 SIO driver. 請使用 root 或是 sudo 來做 I/O port 設定動作.

root@ubuntu:~# rmmod ftdi_sio
root@ubuntu:~#modprobe ftdi_sio vendor=0x1457 product=0x5118

成功之後會在 /dev 目錄下看到 ttyUSB0 及 ttyUSB1, Openmoko 使用 USB1 作為 UART 連線. 連線參數為 115200, N, 8, 1, no hardware flow control 成功後, 使用 minicom/cutecom 或是 cu 可從 UART 輸出得到 Debug port 輸出資料.

[使用 JTAG]

Openmoko 預設的 JTAG 工具是 OpenOCD + Debug Board . OpenOCD 的功能像是一個 middleware (TCP sever with JTAG protocol), 提供了 JTAG 及 gdb 的介面. OpenOCD 詳細的資料可參考:

http://openocd.berlios.de/web/

OpenOCD 也支援了許多不同的處理器架構, 從 ARM7 到 ARM11 都可以使用, 可以下載原始碼後編譯, 或直接從以下網址下載已經編譯好的執行程式. 同時, OpenOCD 需要 FTDI 的 library - libftdi, 版本需要 0.8 或之後的版本.

http://www.ftdichip.com/Drivers/3rdPartyDrivers.htm#Linux

http://www.intra2net.com/de/produkte/opensource/ftdi/index.php

可試著從前面敘述的 apt-get install 包括 libftdi-dev, libftdi-eeprom, libftdi0,libusb 等必要的 package. 也可以從這

http://t0ny.net/openmoko/util/host/gta02/openocd/ 下載已編譯好的 openocd 執行檔及 openocd 需要的裝置設定檔. 接下來:

<Step 1> 連接 Neo 及 Debug Board, 以及連接 Debug Board 到 PC USB port, 開啟 Neo 電源, 然後執行:

root@ubuntu:~/GTA02-DM1/tmp# ./openocd -f openocd-debugv2.cfg
Info: openocd.c:84 main(): Open On-Chip Debugger (2007-01-31 12:00 CET)

正常執行狀況下, 螢幕會停住在Open On-Chip Debugger (2007-01-31 12:00 CET) 這一行.

<Step 2> 接下來使用 telnet localhost 4444 即可進入 CPU, 透過 JTAG 下 command.

root@ubuntu:~# telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger


> halt
requesting target halt...
> Target 0 halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x60000053 pc: 0x33f8b7ec
MMU: disabled, D-Cache: enabled, I-Cache: enabled
>

<Step 3> 執行需要的 script

OpenOCD 可以透過 script 執行連續的 command, 例如寫入多個不同的位址, 大小的檔案到 NAND/SDRAM 的記憶體中並執行. 命令格式是:

> script "script.ocd"

Openocd 執行檔的下載目錄中, 有一個 script.ocd 範例, 若想要學習如何手動寫 u-boot 到 NAND 記憶體中或更多 script 命令, 請參考:

http://wiki.openmoko.org/wiki/U-boot 的內容.

如果看到以下訊息, 代表 JTAG 連線失敗, 請重新連接 USB, 關閉 FR 電源, 開啟 FR 電源, 按下 Debug Board Reset 鈕, 試試是否可以正常停在 Open On-Chip Debugger (2007-01-31 12:00 CET) 這一行..
root@ubuntu:~/GTA02-DM1/tmp# ./openocd -f openocd-debugv2.cfg
Info: openocd.c:84 main(): Open On-Chip Debugger (2007-01-31 12:00 CET)
Error: jtag.c:1181 jtag_examine_chain(): JTAG communication failure, check
connection, JTAG interface, target power etc.

[打開 NOR flash 的寫入功能]

在 FreeRunner 出廠時, NOR flash 預設是防寫的狀態, 所以即使 NAND flash 裡面的 u-boot 受損, 依舊可按 AUX 鍵及電源鍵, 由 NOR 開機後執行更新 image 的工作. 簡單來說, NOR 裡面的 u-boot 包含以下特性:

* 預設是不可變更的
* NOR u-boot 包含了 u-boot/splash screen/environmental variable 環境變數 (MTD parts, default tty output)
* 開機時按下 AUX 鍵, Samsung stepping stone 會跳到 NOR 執行開機的動作

V3 版的 Debug Board 有提供一個 pull-high 電阻 IO 可以解除 FR 上的 NOR 防寫功能, 這個功能必須要透過一個小的公用程式 norwp 啟動.

norwp 的原始碼可以從 http://svn.openmoko.org/trunk/src/host/norwp/ 下載. 要編譯這個程式, 需要 libusb 及 libftdi . 也可以從下面的網址, 下載編譯過的 binary. http://t0ny.net/openmoko/samples/bin/norwp/

使用這個 Utility 很簡單, 只要連接 Debug Board 及 FR 後, 執行:
root@ubuntu:~/norwp# ./norwp rw

就可以開啟 NOR 寫入的功能, 而:
root@ubuntu:~/norwp# ./norwp ro 可關閉寫入的功能

從 openmoko 的 git server, 可以 download u-boot 及 NOR 版 u-boot 的 source code. http://git.openmoko.org/?p=u-boot.git;a=summary

簡單來說, 用 git clone 下來後, 使用 openmoko 官方的 toolchain 即可編譯出相關的檔案. 關於 toolchain 的用法, 這邊先略過.

2008/12/1

Neo FreeRunner 新手手冊 (5) 透過 sysfs 作硬體開關控制


Neng-Yu Tu (Tony Tu)


在 Openmoko 的官方網頁中, FreeRunner 是基於以下的規格需求所開發出來:
http://wiki.openmoko.org/wiki/Neo1973_GTA02_Hardware

在此網頁中, 包含 3 個重點, 分別是:

* 規格設定條件
* 硬體選擇
* 簡要的改版 - 生產紀錄

簡單來說, 在 FreeRunner 中包含了以下的硬體.

* Samsung S3C2442 B54 MCP (含 64 MB SDRAM, 256 MB NAND), running @400Mhz
* 外接一顆 64 MB SDRAM
* ST 8 MB NOR flash
* NXP PCF50633 04 N3 電源管理 IC
* 2顆 LED, Aux 紅色, Power 藍/橘
* S-Media 圖形加速器
* u-blox 4 A-GPS
* microSD card (插槽) (目前 community 測試最大支援到 16 G 的 SDHC microSD 卡)
* 2 顆 ST 3-axis 的 accelerometer (8G/2G 敏感度及 interrupt 模式)
* Atheros AR6001GZ Wi-Fi, firmware version 2.0.0.89 (Accton module)
* CSR BC4 Bluetooth v2.0 (Delta module)
* USB host (同時可提供 5V power, 不需外接電源)
* Calypso GSM/GPRS modem
* 支援聰明電池 (coulomb battery), 可模擬 HDQ 協定的硬體 GPIO 設計
* 硬體可讀版號, 會對應從 u-boot 傳到 kernel 的 ATAG 值 (0350 = v5 版, 0360 = v6 版)

FreeRunner 的完整電路圖, 也可以從 Openmoko 網站下載:

http://downloads.openmoko.org/developer/schematics/

大部分的硬體, 都可以透過 /sysfs 來作開關及讀取一些基本資料. 詳細的內容, 可參閱 wiki 下的網址. http://wiki.openmoko.org/wiki/GTA02_sysfs 同時, sysfs 對應的位置會因為 upstream 相容性改變, 2.6.28 開始, 因為 upstream 的關係, 目錄位址開始變更. 但是基本使用方式及原則是不變的, 可以用 find 指令來找相關的位置.

舉例來說:

<開關 Aux 鍵的 LED>
要開關 Aux key LED, 可以直接使用以下命令:
echo "255" > /sys/devices/platform/gta02-led.0/leds/gta02-aux:red/brightness
或是
echo "0" > /sys/devices/platform/gta02-led.0/leds/gta02-aux:red/brightness

<讀取電池的充電狀態>
讀取 PMU 的的充電狀態是快充還是其他狀態:
cat /sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/chgmode

<讀取電池電量> 讀出的數值以百分比表示
cat /sys/devices/platform/bq27000-battery.0/power_supply/bat/capacity

<讀取硬體版本>
root@om-gta02:~# cat /sys/devices/platform/neo1973-version.0/pcb

利用 sysfs, 就可以利用 script 開關硬體, 或是執行簡單的系統測試. 但是例如像是 wi-fi 模組是直接透過 SDIO 連接, 就無法用硬體的方式 power off 模組, 只能用軟體的方式執行 power off 命令.

2008/11/27

Neo FreeRunner 新手手冊 (4) 建立 FreeRunner 對外網路連線 - Bluetooth


Neng-Yu Tu (Tony Tu)

Bluetooth 和 GPRS 裝置和 FreeRunner (以下簡稱 FR) 上的 USB 連線或 Wi-Fi 連線不一樣, 在使用前, 需要額外透過 command 先將這些裝置開啟, 然後才能執行. 先針對 Bluetooth 裝置說明. 詳細的內容可以參考 wiki 上的 http://wiki.openmoko.org/wiki/Manually_using_Bluetooth 網頁的說明. 此外 FR 上面的 Bluetooth 是 Delta 的模組, chipset 是 CSR 的 Bluetooth 2.0.

FR 使用的 Bluetooth stack 是 Marcel 的 BlueZ, 但是 BlueZ 能提供的功能, 在 FR 上都可以達到. 但 FR 並沒有提供完整的 profile 操作介面供連線/功能操作使用.

直接使用 BlueZ 的公用程式, 確實可以進行常見的 GAP, FTP, HID, PAN 的 "功能", 唯一的問題是: 必須手動完成大部分的功能及 handshake 驗證, 或是需要修改 /etc/Bluetooth/hcid.conf 的設定.

FR 上的 Bluetooth 是透過 USB 介面連接到 CPU, 預設的狀態是關閉的. 所以使用前必須先開啟 Bluetooth. 開啟的方式很簡單, 只要透過 command 就可以直接開關 Bluetooth 裝置.

同時, 由於 etc/network/interfaces 裡面的 Bluetooth 設定, 預設是 iface bnep0

inet dhcp. 建議先用 # disable 掉這個功能.

<Step 1> 開啟 FR 上的 Bluetooth device

root@om-gta02:~# echo 1 > /sys/bus/platform/devices/neo1973-pm-bt.0/power_on
root@om-gta02:~# echo 0 > /sys/bus/platform/devices/neo1973-pm-bt.0/reset

<Step 2> 執行 hciconfig, 透過這個命令我們可以確認 Bluetooth 是否正常執行, 以及取得目前 FR Bluetooth 的位址.

root@om-gta02:~# hciconfig
hci0: Type: USB
BD Address: 00:06:6E:16:DE:BD ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:949 acl:0 sco:0 events:23 errors:0
TX bytes:342 acl:0 sco:0 commands:23 errors:0

如果沒有得到上述訊息, 可以用 hciconfig hci0 up 強迫啟動, 或是重複 Step 1 到 2.

<Step 3>

此時連線步驟要先切回 Host (ubuntu) 端, 請先開啟 Host 端的 Bluetooth, 執行以下命令.
root@ubuntu:~# modprobe bnep
root@ubuntu:~# pand --listen --role NAP

<Step 4> 在 FR 執行以下命令, 00:11:22:AA:BB:CC 處請填上 Host 端的 Bluetooth MAC 位址.
root@om-gta02:~# pand -c 00:11:22:AA:BB:CC --service NAP --autozap
root@om-gta02:~# ip a add 10.0.0.2/24 dev bnep0
root@om-gta02:~# ip r del default
root@om-gta02:~# ip r add default via 10.0.0.1

你可以從這邊下載完整的 script
http://t0ny.net/openmoko/samples/script/bt_net.sh

有時建立連線會失敗, 或 bnep0 沒啟動, 請執行下面這一行指令.

root@om-gta02:~# ip l set bnep0 up

<Step 5> 然後回到 PC 端, 設定 Bluetooth network 及 IP forwarding 的規則

FR 建立連線後, 可先用:

root@ubuntu:~# pand --show --list -l
應該會看到:
Bnep0 00:06:6E:XX:XX:XX NAP
看到這個訊息代表 FR 真的連上線了, 然後執行:
root@ubuntu:~# ip a add 10.0.0.1/24 dev bnep0
root@ubuntu:~# ip l set bnep0 up

接著可以從 Host 端, 及 FR 端分別 ping 10.0.0.2 及 10.0.0.1 看看是否可以雙向連上線.

root@ubuntu:~# ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=47.2 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=22.0 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=24.0 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=17.0 ms

或是從 ifconfig 中看到.
root@om-gta02:~# ifconfig
bnep0 Link encap:Ethernet HWaddr 00:06:6E:16:DE:BD
inet addr:10.0.0.2 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::206:6eff:fe16:debd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:268 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:284 (284.0 B) TX bytes:11737 (11.4 KiB)

<Step 6>

如果需要, 請在 Host 端, 和 USB 連線一樣, 再加入 packet forward 的功能.

2008/11/26

Neo FreeRunner 新手手冊 (3) 建立 FreeRunner 對外網路連線 - USB/Wi-Fi


Neng-Yu Tu (Tony Tu)


FreeRunner 分別可以透過無線 (Bluetooth, Wi-Fi, GPM(GPRS) 以及有線 (USB) 的方式. 但是從使用者介面上可以完成部分 Wi-Fi 連線功能外, 其他的連線方式可能需要進到命令模式, 然後透過手動下 script 的方式完成.

不同的 Distribution 可以用的 script (例如 FSO 有提供許多的 python binding service) 也不一樣, 當然最原始的方式就是直接下 bash script. 以下提供了 Host (PC) 端及 FreeRunner 端的連線 command 方式. 接下來以 ubuntu 為例, 分別設定以下幾種連線.

[USB 連線]

FreeRunner 的 USB port 預設在 USB 1.1 slave 的模式, 可以透過 Host 端電腦的 NAT 和外部的網路建立雙向連線. 下面分別是 Host PC/Neo 端分別需要下的命令.

更詳細的資料可以參考: http://wiki.openmoko.org/wiki/USB_Networking

* Host (ubuntu) 端
Host 端分成兩個步驟, 第一段是建立 SSH 的連線, 第二段是建立 packet forwarding 規則.

<Step 1>

sudo ifconfig usb0 192.168.0.200 netmask 255.255.255.0

ssh root@192.168.0.200

<Step 2>

Sudo iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
Sudo sysctl -w net.ipv4.ip_forward=1

不同的 distribution/version 會有不同的指令設定, 不同防火牆也可能會有不同的結果. 可以直接參考 http://wiki.openmoko.org/wiki/USB_Networking

* FreeRunner 端:

Host PC 端跟 FreeRunner 連線後, FreeRunner 的預設 image 需要 "額外" 的一項設定, 需要加入 DNS nameserver 的名稱解釋服務.
echo nameserver 208.67.222.222 > /etc/resolv.conf
echo nameserver 208.67.220.220 >> /etc/resolv.conf

當然, 你可以熟悉 FreeRunner 的設定後, 套用到 FreeRunner 的

/etc/network/interfaces 裡面.

[Android Cupcake 0.1.1 and after]
PC side:

iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
sysctl -w net.ipv4.ip_forward=1

FR side:
route add default gw 192.168.0.200 dev usb0
setprop net.dns1 168.95.1.1

[Wi-Fi 連線]

目前 FreeRunner 的 Wi-Fi Atheros AR6001 module 是透過 SDIO 介面連接 (所以如果你需要 Samsung 的 SDIO host controller code 可以參考 OM 的 implement, OM 的 implement 基本上是 based on OpenHand 的 Samuel 的 implement), 所以並不需要做 power on/off 的動作就可以使用模組. Wi-Fi 連線設定的關鍵, 主要在兩種連線加密模式 WEP 跟 WPA 的設定.

更多的資料可以參考: http://wiki.openmoko.org/wiki/Neo_FreeRunner_Wifi

* WEP

<Step 1>

登入 GTA02 後, 先看附近有哪些無線 AP

iwlist eth0 scan

<Step 2>

Key 欄位填入連接網路 AP 的 key
Essid 填入網路的 AP 名字 (essid)

iwconfig eth0 key 1234567890 essid myAP
ifdown eth0 && ifup eth0
udhcpc

最後一行指令是利用 udhcpc 動態取得 DHCP 的位址

* WPA

<Step 1> 建立 WPA 設定檔
利用 vi 或其他文字編輯程式, 建立如下設定檔

-----------
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
fast_reauth=1

# WPA2:

network={
ssid="WPA2_AP_Name"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=TKIP CCMP
psk="YourPSK"
priority=50
}

# WPA:
network={
ssid="WPA_AP_Name"
proto=WPA
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP
scan_ssid=1
psk="YourSPK"
priority=10
}

# WEP:
network={
ssid="WEP_AP_Name"
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0="your WEP key"
priority=8
}
# Open:
network={
ssid=""
key_mgmt=NONE
priority=5
}
-------
<Step 2> 套用 WPA 設定檔, 重新啟動

wpa_supplicant -i eth0 -c /home/root/wpa_supplicant.conf -B
ifup eth0

如果無法連上, 可以試試 ifdown eth0 再試試.
連上後, 可以 ping http://www.hinet.net/ 或是 168.95.1.1 看看是否 DNS 跟網路的連線都 ok 了.
 
Creative Commons License
本 著作 係採用創用 CC 姓名標示-非商業性-相同方式分享 3.0 台灣 授權條款授權.