moments notice

Android 4.0 r1 CTS diff (with Android 2.3 CTS)

2011-11-16T04:48:00.000-08:00

Some lazy diff shows Android 2.3 vs. 4.0 CTS, just for memo. People interested in CTS 4.0 r1 could:

1. download AOSP for ICS 4.0
2. make SDK
3. Check out/host/linux-x86/cts for CTS and CtsVerifier binary

git diff

git log

android.tests.sigtest 1
android.apidemos.cts 1
android.acceleration 6
android.accessibilityservice 19
android.accounts 28
android.admin 13
android.app 298
android.bluetooth 9
android.content 575
android.database 243
android.dpi 9
android.dpi2 0
android.drm 11
android.example 2
android.gesture 29
android.graphics 874
android.hardware 37
android.jni 61
android.location 86
android.media 252
android.ndef 1
android.net 97
android.os 302
android.permission2 10
android.permission 127
android.preference 4
android.provider 135
android.renderscript 154
android.sax 4
android.security 11
android.speech 9
android.telephony 52
android.text 600
android.theme 0
android.util 82
android.view 610
android.webkit 167
android.widget 986
android.core.tests.libcore.package.com 5
android.core.tests.libcore.package.dalvik 50
android.core.tests.libcore.package.libcore 3468
android.core.tests.libcore.package.org 1907
android.core.tests.libcore.package.sun 0 2
android.core.tests.libcore.package.tests 2643
android.core.vm-tests 3100
android.tests.appsecurity 6

4

2011-11-14T06:28:00.000-08:00

A magic number

Siri is HAL?

2011-10-16T05:01:00.000-07:00

不管 Apple 公司產品發表策略是什麼, iphone 4s 唯一的亮點大概就是 Siri. 這兩天在思考 Siri 到底跟以前的語音輸入有什麼不同時, 發覺我應該從客觀環境來看 Siri 出現在手機上代表著什麼.

* 手機有足夠的運算能力, 可以分析收到的資料
* 有眼睛 (Camera)
* 有耳朵 (Mic)
* 有嘴巴 (Speaker/Receiver)
* 知道自己在哪 (GPS/AGPS)
* 使用者已經習慣 always online 連線方式 (3G or 4G)
* 使用者開始習慣用手機上網取得一些服務

就功能上看 Siri 是可以有機會變成下一個世代的搜尋引擎, 或是真的當成所謂 "雲端' 服務的窗口, 就跟前一陣子的 "老闆不是人 (Horrible Bosses)" 電影一樣, 車上的服務系統隨時有個印度人 online 的感覺 ;) .

G 公司的搜尋你還可以選擇下一個連結, "感覺" 上比較可以控制 (其實也只是感覺而已, 因為下一個 click 經常也是被決定的 :P) 只是大家比較注意第一個 click 或 link 的 rank)

語音的特性是無法列表的, 所以 Siri 應該直接跟你講答案, 但是能做到多個人呢? 我的期望是 (純屬模擬):

Me: 今天幫我訂吃牛排的位置
Siri: 是常去那間嗎
Me: Yes
Siri: Ok (然後把剩下的搞定, 訂位, 發 mail, 同步行事曆到 iCloud 跟我所有的 i device)

如果訂不到:
Siri ring...: 餐廳沒位置, 要選其他的嗎
Me: 有什麼建議嗎
Siri: 根據你的收入, 月底了, 還是路邊攤吃吃就好...
Me: 果然 hold 的住
Siri: 我比 hold 住姊強多了, 謝謝

如果只能告訴我附近有哪些餐廳就有一點遜. 如果跟電話答錄機一樣跟你說一堆 options, 那應該這個助理很快就被開除了. 但是如果他是 HAL 呢?

Siri, Siri give me your answer do.
I'm half crazy all for the love of you...

不過我覺得這個功能 G 公司先推出才對.

我想歐洲應該會說, 這麼了解自己的 Siri 侵犯到隱私權吧...付錢請一個老大哥 (Big Brother) 待在身邊好像不是很 make sense.

update 10/25

Surprising news, Siri 的 co founder Dag Kittlaus just left Apple

向 Steve Jobs 致上最高的敬意

2011-10-06T02:58:00.000-07:00

對一個童年被 APPLE II 填滿生活跟閱讀 A+ jobs/woz column 長大的人來說, 今天真是個悲傷的日子.

Thank you, Steve. RIP...

穿著 Prada 的惡魔啟示錄 - 沒有甚麼是理所當然的

2011-10-04T18:59:00.000-07:00

這幾天放了個意料之外的 10/1 長假, 看到衛星電視的非x新聞又在大談 Windows 8, 雲端, ultrabook, Android....blah blah blah

突然覺得把那個皮帶選擇跟毛衣 (sweater) 故事換成 OS/雲端/open source/Android/tablet/app store/etc... 對台灣 OEM/ODM 產業/股民也是很殘忍的存在.

Android 跟 Windows 沒差別, Intel 跟 ARM 沒差別, Android Market 跟 APP store 沒差別, G 公司跟 M 公司沒差別...

穿著 Prada 的惡魔 script excerpt.
===================================
No. No, no. Nothing's…

You know, it's just that both those belts look exactly the same to me.

You know, I'm still learning about this stuff and, uh…

"This… stuff"?

Oh. Okay. I see.

You think this has nothing to do with you.

You go to your closet…

and you select… I don't know… that lumpy blue sweater, for instance…

because you're trying to tell the world that you take yourself too seriously…

to care about what you put on your back.

But what you don't know is that that sweater is not just blue.

It's not turquoise. It's not lapis.

It's actually cerulean.

And you're also blithely unaware of the fact…

Android CTS - painful with RTSP

2011-10-02T07:28:00.000-07:00

這幾個月經常被 Android CTS 的網路測試弄得火冒三丈. 尤其現在大部份時間在大陸, 要得到一個乾淨的網路 (不經過 great firewall, no tunneling, no VPN) 的環境實在太難了. 但是 CTS 本身基本是為了 Android API 相容性, 跟 Google 服務 package (GMS) 做測試的, 所以網路的設定基本上是建立在:

1. 可以使用 Google 服務的網路上
2. Device 從 DHCP 取得的網路設定是值得相信的

但是 1 跟 2 其實在大陸都很難達到. 對網路長城有一點研究就知道, 其實長城並不是靠 blocking IP 那種暴力的方式來擋住所有 connection, 而是包含 DNS redirect, URL filitering...etc 來達到 blocking 的方式. 所以 CTS 測項中跟網路有關最多的 DNS 連結跟查詢工作, 就會失敗. 不過拜both side 氣氛和緩之賜, 還是可以用 hinet 的 DNS resolve 正確的 IP, 連結到那些無害的測試網站 (like php.net/others)

原先 CTS 2.3 r5 之前, AP 的 DHCP 改個 default DNS 就可以過了, 但是從 CTS R7(錯誤的 release), R8, R9 之後, 加了該死的 RTSP/HTTP streaming test, 內容更是從該死的 youtube 下載. HTTP 還好, 先天就有可 tunneling 的優勢...但是 RTSP 真的是被弄到了.....f 理論上用 VPN 應該可以避開, 但實際結果是 Android 至少在 2.3 base, RTSP 即使 protocol ok, streaming 不見得 VPN 內可以建得起來 stream, 因為你不會知道是 VPN 的出口不能建 port 554 connection, 還是 youtube 有設 routing rule, filter 掉某些 routing. 但是結果不是被 firewall 擋就是被 youtube filter...@)@*@*#!

雖然最後靠台北同事幫忙測試 ok, 但是過程實在太怒了....

Anyway, 最後還是找一個技術上正確的 VPN 來解決這種無聊的測試環境假想設定.

Appendix: Great Firewall of China
http://en.wikipedia.org/wiki/Great_Firewall_of_China

Android 3.0 模擬器太慢 - 還是老方法, 加 RAM helps, but not much

2011-02-27T01:29:00.000-08:00

這幾天在看 Android 3.0 SDK 正式版的動畫 (http://android-developers.blogspot.com/2011/02/animation-in-honeycomb.html) 跟 renderscript (http://android-developers.blogspot.com/2011/02/introducing-renderscript.html), 發現模擬器還是跟測試版一樣慢到不行. 我想這麼重大的開發效率問題, 應該要早一點解決吧. 目前看到設定模擬器時, 將原先的 Device ram size 256 (MB) 改大到 1024 (MB), 發現動作有快一點, 開機還是一樣慢到一個程度, 這樣是不是大家都要去買一個 XOOM 啊....

輪迴的遊戲 - Nokia + Microsoft...SO?

2011-02-14T05:57:00.000-08:00

剛開始聽到 burning platform 加上跳北海的這個形容的時候, 只想到這個形容真好, 芬蘭人一定了解 sauna 的感覺, 這個例子 N 公司員工一定是感同身受啊. 沒想到接著就聽到 Nokia 棄守 symbian 跟 Meego, 投向 Windows phone 陣營起來. 連 Intel 都一副被拋棄的樣子, 更不要說 Nokia 剛領養的 QT 只能安靜的在旁邊嘆息了, 應該大家都傻眼吧. 我看 Nokia 跟 Symbian 的 twit 上, 一片罵聲連連, 員工示威. 看到 CEO stephen 還自己跳出來回 twit 說不是 M 的 trojan horse, 差點噗滋一聲笑出來. 我可以充分了解這個心情...BUT, 因為從小看過太多這類灑狗血賺人熱淚 (N 為何要棄我們而去找 M 啊...淚...)的合作案, 長大比較能冷眼旁觀 :P 不過, 還是蠻有感觸的, 所以趕快 blog 一下.

現實層面來看, Nokia 雖然在被 Android + iphone + 山寨的夾擊下, 2010 還是能保有 28% 市佔率, 其實怎麼樣看都不算弱者. M 公司雖然智慧手機被殺到只剩個位數零頭 (因為只有所謂智慧型....), 但是 Windows phone 7 的確跟 Windows mobile 6.x 完全不同. 網路上一堆把這兩間公司標成 Loser +Loser, 但是明明兩間某方面都有 dominate 市場的能力, 所以裝什麼弱啊!!! 應該反托拉斯先要準備調查一下吧! 我個人覺得Windows phone 7 跟 Zune 比較像, 很簡潔. 這年頭大家都在瘋 apple, 其實 M 的 Zune type UI 就跟 xbox 一樣, 真的用過其實會覺得還不錯 (well, 除了 my xbox 出現過多次三紅, 跟 kinect 需要大客廳外). 我個人還蠻期待 M 跟 N 做出 impress 的東西. 以及這個 marriage (營運 cost down vs. 重拾 MS platform 信心) 可以撐多久 :P

Nokia 當初跟 Intel 合作 Meego 也是蠻奇怪的事, 因為 Maemo/symbian/QT 跟 moblin 當初每個 target 不太一樣. 不過 Intel (butnot only Intel)也一直打著 x86 based mobile device 的主意,想想看, 所有的 x86 wintel 的 app 都不用 cross compile 啊, 多麼美好的世界! N 應該也寄望彌補 mobile device 上 roadmap 的空缺. x86 當然不單指小筆電的 atom, 還包括真正的 mobile device = PHONE 在內, 不過 x86 的 embedded mobile CPU solution 一直難產, 眼看 2011 年中一堆的 ARM cortex A9 dual core tablet 量產, 年底 PSP 2 的 quad-core cortex A9 量產, intel 應該不會讓 mobile computing 的餅全部被 ARMs 聯軍吃掉吧 ;)

現代三國 (Android/iOS/Windows) 還真是值得期待. 不過 x86 跟 ARM 的雲端對決應該也是觀戰重點.......低頭做筆記.

一個情人節的無聊 nerd blog...haha

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

2011-01-02T05:41:00.000-08:00

剛進入 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?

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

Reset

2010-12-19T06:36:00.000-08:00

今年好像一直在忙, 忙的意思代表 loading 很高, 但是不代表大腦 input 跟 output 很多. 加上一連多次重感冒, 感覺還蠻虛的一年 +_+

很高興的是, 拜 facebook 跟爬牆科技之賜, 還是跟以前的同學跟朋友有保持最低限度的聯絡. 算蠻值得高興的一件事. 像是沒事在 FB, 以前 MI 同學 Masaya Shinohara 就來問候一下, 還發現一起練琴的 Shugo Tokumaru 同學都出了好幾張專輯了. 真是... 光陰似箭阿....

post 一首我覺得還蠻好聽的... rum hee

他網站上 (http://www.shugotokumaru.com/ ) 整個 color/layout 蠻不錯的, nice mix

Life is full of suprise

2010-11-14T00:48:00.000-08:00

Good or Bad, 今天特別有感觸. 寫個 note 提醒自己, 當年還會痛.

Android 的 script engine (ASE) 專案

2010-04-05T02:34:00.000-07:00

很多嵌入式或是一般的使用者終端專案都會需要使用 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/

一張專輯與一首歌的距離

2010-04-05T01:52:00.000-07:00

難得在連續假期中, 找到時間出來把被工作捲在一起的心情, 像發條一樣放鬆旋轉起來. 本來低調的心情, 不斷浮現著 Poison 的 every rose has it's thorn 的旋律, 拿著上星期買的 Cort 哼彈一下, 馬上就沉靜下來.

到南京幾個月, 還沒時間出來到各景點晃一下, 總是在一樣的精品店與百貨公司周旋. 於是帶著難得充滿電的 iPod, 到夫子廟附近看看所謂的十里秦淮風光. 下了公交站, 開始放 Poison 的 Greatest hits, 從nothin' but a good time 開始了下午的旅程... 雖然我不是很喜歡這種有背景音樂的旅行方式, 但是好像也沒甚麼讓我可以隔絕小販的喧鬧聲跟不知所謂的 white noise.

我曾考慮是不是該放一些傳統一些的 BGM, 而不是泡泡糖 rock, 來代表對曾經是江南最大的貢院一些尊重. 不過在看到夫子廟及貢院的小販後, 想想歷史的尊嚴也抵不過資本主義的現實. 這 tour 本來就沒設定甚麼目標, 也許這樣才重新有心情 blog 一下.

一首 sultans of swing 的距離, 從一個終點帶回另一個起點 1912. 點了一杯熟悉的 starbucks ice latte, 在有些淡的牛奶味中, 隨著 beatles 的 Eight days a week 的歌聲中, 按下 submit 送出今天的心情.

Yellow Jackets @ 大河岸

2010-03-02T06:26:00.001-08:00

又開始工作後, 生活開始被一堆事情填滿. 本來過年想寫跟錄一堆東西, 但是總是沒辦法安靜的坐下來. 可能短時間還是只能像囈語似的寫些不知所云的東西. 因為在內地工作 (是的, 我現在是爬牆 Po 文), 也命中註定了錯過了在大河岸的 yellow jackets 表演. 雖然以前看過他們幾次表演, 但是沒辦法享受那種 refresh 的感覺, 還是很 f.

我想, 只有 hardcore 的 fusion 人才能了解這種無奈吧.

不過, 很多即使號稱是樂迷, 對 Yellow Jackets 不見得很熟, 陣中又沒有 guitar hero, 可能造成一些觀賞的意願問題. 換個角度, 也許什麼都不知道另一種幸福吧.

還是要給 Geddy 跟小儀姊拍拍手....

對 yellow jackets 有興趣的話, check http://www.yellowjackets.com/

* Some Update
They were at Taipei again for 2011 Summer Jazz festival, and great as usual.

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

2009-10-21T23:18:00.001-07:00

最近 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 上執行.

意料內的意外 = or != 行銷

2009-10-12T09:44:00.001-07:00

電視上新聞 "一直" 看到 Michael Jackson 的新單曲在正式 release 前, 很巧的 TMZ 又在網站上搶先 post 了 47 秒的 MV. 這類搶鮮試聽, 或是滿足人偷窺慾望的 release 方式, 實在覺得是很老的梗了, 不過我想應該還是很有效吧 :) 這類真真假假的娛樂新聞, 本來就很容易引起一般人的注意. 不過, 我是很佩服美國娛樂產業可以這麼快的用 "電影" 的方式, 來 release 最後未完成的 "演唱會". 除了行銷的 idea 外, 當初這些在排練 take 的畫面, 以及相關的合約 arrange, 若沒有充足的經驗, 是很難在短時間內組織出相關產品的.

很多 geek :P 可能會覺得這類娛樂新聞很無聊, 可是如果換一個方式呈現, 可能感覺就不一樣, 例如: 某個水果 3C 產品 release 一周被 hack 了, 或是某 online store 下載的軟體用很笨的 folder 方式保護. 到底是 user 破解了保護, 還是 marketing people 破解了 user 的心防.

世界真是有趣阿 :)

雲端的迷思

2009-10-08T00:13:00.001-07:00

這一陣子兩個颱風來, 大家為著氣象局的預報準不準在電視上鬧的沸沸揚揚. 媒體也乾脆把來自各國的預報路線用不同顏色疊在一起. 各電視台面對著向炸彈開花似的預報路線圖, 開始一種路線, 各自表述起來. 觀眾透過最簡單的 client 端: 電視, 收看著來自各個來自 "不同國家" 用 "不同演算法" 在所謂 "超級" 電腦中運算出來的結果. 突然覺得有點好笑, 想一想, 這也是種雲端運算吧, 只不過天邊不是只有一朵雲而已.

有趣的互動設計概念 (interactive design concept)

2009-09-23T03:11:00.001-07:00

感謝 youtube/vimeo and google, 最近看到幾個有趣的互動設計 concept.

* 這是真實物件位置跟背景光影互動

Bouncing Balls from Dofl Yun on Vimeo.

* 這是透過不同感知的方式來展現互動創作的可能性

ensemble project from Dofl Yun on Vimeo.

* 一個有趣的互動 Drum/sequencer (thanks, wilson :) )

* 可提供觸感的 3D 投影 (搭配 ultrasonic pad)

* Wii 的一個新 game, 非常令人深思的遊戲進行方式.

感動的 T-SQUARE 表演

2009-09-15T01:44:00.001-07:00

原來以為日本 Fusion 已經沒辦法再打動我了, 果然現場表演才是王道阿, 現場的氣氛讓我回想到以前天天聽他們 CD 的日子. 好聽的音樂還是好聽的音樂, 不會因為時間跟人的改變而改變.

想當年 (驚覺過了 20 年@_@ ) 開始聽 Fusion 這個領域, 最早是因為海國的老師, 拿了高中正義的虹傳說譜給我練, 當時狂練 Yngwie 掃弦的我根本不知道什麼是 fusion, 更不要說知道什麼是 jazz. 只是覺得很好聽, 但是聽不懂. 但是還是很努力的存錢, 買了一張又一張每張 700 到 1,000 起跳的原裝日本 CD. 開始慢慢喜歡上 CASIOPEA 跟 T-Square 這種華麗, 聽不懂, 也不是很吵的音樂.

後來隨著各種音樂越聽越多, 也到了美國這個 Jazz/Fusion 的發源地洗腦了兩年. 看到了許多有名或不有名但超厲害的表演. 也獨自到 NY 窩在巷子�狹小的 smalls, 呼吸充滿 jazz 的空氣, 體驗來自各個不同背景的樂手, 整晚交替表演各式不一樣風格的音樂. 每一個表演都充滿用靈魂敲擊音符的原始音樂能量. 後來有很長一段時間, 很少聽日本系的 fusion, 因為總覺得太拘謹, 過分修飾 (電味太濃) 跟華麗, 缺乏了那種生命推動音符的震撼.

好不容易過了 20 年, T-Square 終於來台灣. 可能很多人不知道 T-Square 這個團, 但其實聽過 T-Square 的音樂, 像傳統日本 F1 的轉播主題曲 Truth 就是 T-Square 的安藤(Andoh) 作品. 還有以前的 Arc the Lad (http://en.wikipedia.org/wiki/Arc_the_Lad_(series )遊戲, 跟 PS 上最有名的賽車 GT (Gran Turismo) 系列, 安藤也是音樂總監跟主題曲作者.

T-Square 官方站: http://www.tsquare.jp/free/index.html

期間 T-Square 團員也更換過好幾次了, 雖然 keyboard/bass/drums 都不是我那個年代的, 不過 "最" 主要的吉他安藤 (Masahiro Andoh) 跟負責 Sax 跟 EWI 的伊東 (Takeshi Ito) 都有來. 表演一開始, 我雞皮疙瘩就起來了, 因為我那時心情很平靜, 以為是冷氣太冷. 不過後來想想, 應該是潛意識的激動. 表演維持個一慣日系的精準, 華麗, 控制, 但是跟 CD 不一樣的是, 現場表演多了一股共鳴的張力. 果然日本 Fusion 也是可以很熱血.

現場表演很讚, 年輕鼓手的能量很夠而且完全的控制內. 加上很多來的人應該對 T-Square 都很熟, 也有很多音樂圈的樂手有來. 整體氣氛其實很 high, 最後 encore 表演 truth 更是熱血百分百. 如果沒提早開燈, 我想應該會 Encore 更多首. 雖然沒辦法像負責導聽的小呂老師有機會參加 T-Square 的慶功宴 ...>_<... 但這的確是難忘的 J-Fusion 之夜.

T-Square 最高....

產品形象 (identity)

2009-09-08T23:57:00.001-07:00

昨天到國家音樂廳, 看了我個人非常喜愛的一位吉他手 John Scofield (http://en.wikipedia.org/wiki/John_Scofield) 的 band 表演, 他很喜歡用一般 musician 不會用的 color note, 但是用非常流暢的藍調 a-like phase 跟 shuffle/funk rhythm 來表現他的音樂, 雖然曲目大部分是最近這一張專輯 gospel 類的音樂, 曲目本身結構不像他在純 jazz band 那麼複雜, 但是用音依舊是他自己的 taste, 而且非常 groovy 的一場好表演.

翻翻幾百張因為跟吉他手相關而買的 CD, 發現常聽的幾張, 音色跟旋律線的辨識度都非常高. 而且, 他們對現場即興 (improvising) 演奏的 taste 都有獨到品味難以被模仿.

美國娛樂產業發達, 有同樣技術的太多, 市場 (包含: "消費者" 以及挑選產品進市場的 "唱片公司") 非常注意原創性及獨創性, 所以能夠出現在一般人面前同時受歡迎的專輯, 其實都是打敗了數以萬計的競爭者才冒出頭的. 換句話說, 通常一般人看到的都是已經 build 好的 identity, 經紀/ marketing/promoter 對這些 identity 建立, 都下了許多一般人看不見的功夫 (選擇 artist/包裝/行銷) 在裡面.

人透過 identity (tag/icon) 來認識一樣東西是被從小訓練的. 例如: 受教育的過程本身就是一個 format 認知的過程, 如果大家都考一樣的試, 搶念一樣的學校, 看一樣的 MTV, 把一樣的人當偶像 (藝人 or 非藝人). 說實在的, 如果教育 build-in 這麼深, 要一般消費者有獨立思考跟自我品味這件事其實太強人所難 :)

正因為大家對於 identity 的認知多半來自於外部的描述, 而少有自己的感受, 所以廣告跟行銷手法才有發揮作用的地方. 很多人覺得 identity 是被包裝出來的, 我個人的看法有些不太一樣. 例如, 一般電子產品常見的 identity (簡化的):

* 最便宜
* 最炫, 最牛B
* 最物超所值
* 功能最多
* 服務最好
* 最方便
* 最有品味

其實建立好任何一樣 identity, 應該都可以在市場上存活, 持續重現這些 identity 的能力也都是每間公司的 know-how. 以製造業最擅長的 cost-down 為例, 都會知道一直做到 "最" 便宜其實也沒那麼容易, 因為從流程 - 設計 - 生產, 每個細節都會影響 "最" 這個字, 不小心就會讓 "最" 變得很 "一般".

從另一個角度來說, 當要作一個最有品味的產品, 出發點就是品味 :) 所有的包裝 (marketing/promote) 都會繞著品味打轉. 產品定義的人的 mindset 就跟 cost-down 的人 mindset 就完全不一樣. 人通常也不會是同一種人. 在現實生活, 經常 marketing 要把原先設計 " 功能最多" 的產品, 轉化成 "最有品味" 的產品 image, 其實不是那麼容易. 因為要改變產品的既有印象是很困難的, 除非 marketing 的人找到一個夠好的 story.

我常聽到: A 產品本身就沒有什麼特色可包裝, 所以廣告跟 marketing 效果不好. 但是, 經常問題來自於 A 產品當初建立時就沒有什麼明確的核心思想, 或本來的核心思想跟要進入的市場無關, 所以後來 marketing/promoter 在包裝時, 累得半死想破頭加減一些無關緊要的東西, 目的讓產品在要進入的市場看起來更 attractive, 經常是事倍而功半.

如果能在 identity 中, "建立" 一個市場沒有的字彙, "然後" 又獲得認同. 通常就是該新市場的 leading 角色了. But keep leading always another story :)

硬體產品專案管理經驗分享 - 時程 (schedule)

2009-09-07T02:33:00.001-07:00

不論專案或是產品, 通常都有俗話所謂的 deadline 或是market window 限制. 基本上 PM 被賦予的任務就是得到目標後 (明確 or 不明確 :P 的目標都有可能), 在指定的時間內, 協調公司內外部 resource (錢, 人員, 組織), 達成指定目標. 所有的 resource 投入, 都是為了在某個時間點取得某個成果 (working sample/demo/trade show/shipping/etc). 錯過了時間點, 後果通常都很嚴重. 通常影響 schedule 最大的是 scope 變更, 但這裡不討論 scope 變更的問題.

這幾天又在 HBO 看到 "大敵當前 (Enemy at the Gates )" 這部片子, 這個戰爭電影有一句還蠻經典的對白:

Vodka is a luxury we have. Caviare is a luxury we have. Time is not.
-Enemy at the Gates, Nikita Khrushchev

意思是說, 我們可以享用 (一般老百姓沒有的) 伏特加跟魚子醬, 但是唯一沒有時間可以浪費 (Time is not luxury we have). PM 可以協調找到資源, 但是永遠缺時間. 假你錯過時間, 可能產品失敗的機會或隱藏的成本, 一般來說會呈現 "幾何" 倍數增加. 要有一個重要概念: 最後一個月追加 30% 的預算跟 delay schedule 東西 marketing/sales 預估少賣 30% 的量, 到底是哪一個損失比較大. cost 觀念不是只有 PM 要有, 同時專案裡的人對 cost 要有相同共識.

Schedule 這個東西 "看" 起來很簡單, 不過就是做一件事需要多少時間, 把所有需要的時間按照發生的先後順序調整一下就好 (跟 programming 很像, 不是嗎 XD ). 問題來了:

* 如何知道做這個軟/硬體或做這個 project 一共有哪些事情 (scope 有多大)
* 這些事情對應的 function 組織及負責人是誰
* 如何知道這些事情需要多少時間
* 如何分辨這些事情出錯造成的風險跟衝擊有多大
* 遇到問題的應變跟通知對象

這一部分其實就是大部分 Developer 踏入 PM 領域的第一項 "技術" 門檻, 因為瞭解組織跟認識 API/function block 一樣, 都需要時間跟精神. 同時, 跟 "人" 溝通不是下 command 給電腦, 不是馬上有結果 or 每次結果如你預期一樣. 當然某個程度來說, 做產品/專案有一點像 coding, 只不過 coding 的對象是組織而不是 library. 當然, 你對組織/流程/工具越熟, 就越能有效率跟機會達成原先設定的目標. 根據不同的成長經驗, 每一個 PM 都有每一個 PM 不同的風格, 下面是我覺得一開始比較重要的:

* 了解並釐清公司內部組織跟流程規範

每一間稍具規模的硬體公司, 都會有標準的流程或是 follow 公司訂的 ISO 流程. 認識這些流程是了解硬體相關專案管理的第一步. 台灣從純代工的 OEM 到現在佔世界 3C ODM 跟 OBM 的重要地位也有幾十年了. 從微利的代工開始, 所以設計到製造其實分工很細, 流程本身相對於很多其他產業來說也嚴謹許多, 每一個細節為什麼這樣做都有其歷史原因. 一般來說, 因為其實細節太多, PM 可以了解或不了解, 不懂可以問, 但最好不要用猜的.

* 總共有哪些重要項目, 哪些時間是固定的, 例如 (但不限於):

a. 每一個階段 (EVT/DVT/PVT or 不同 flow 階段) 的 check point 時間, 跟 check point 對應的 check item 是什麼.
b. BOM 裏面的關鍵零組件備料時間 (採購通常會提出一個安全反應時間, 有一些例如: 發 PCB gerber 到交貨時間, 常都是固定的天數)
c. 硬體產品認證時間 (Lab 會評估如果 sample "軟" + "硬" 體都沒問題, 多少時間可測完)
d. 每一個關鍵硬體功能的需要驗證時間 (從發出需求給 vendor, 到 sample 驗完)
e. 採購的作業時間
f. 整合測試的 cycle time, 例如發行軟體測一個 round 需要多少時間
g. 量產從 RD 到 PE 到工廠的技轉時間
h. 工廠的前置作業時間

* 產出重要文件需要的時間請放入 schedule 中

文件通常不是交付或驗收標的物, 所以很多人就忽略文件的重要性. 一般 Follow "標準" (ISO/CMMI) 流程的專案 (如果公司跑 ISO/CMMI/PDM 的話), 會產出一堆的文件, 用這些必然產出的文件當控制點是蠻方便作法. 但是因為跑流程, 有額外的文件負擔, 許多小規模的專案, 常只產出少量文件或完全沒有文件. 因為口說無憑, 進行到後段經常會很難收尾. 如果該產出的重要文件, 我個人覺得還是要放入 schedule 計畫中比較好. 有時前面為了省一些寫文件時間, 後面會浪費更多協調溝通時間.

* 將預先設定好的 milestone, 跟必然產出的文件項目放入 project 管理軟體

用最簡單的例子: product spec 展開後可以有-> hardware design spec + software design spec, 接下來又有各有對應的 verification citeria 跟 factory test item. 這有一定會產出的 item, 可以像樹狀圖一樣依照分類 (軟體/硬體/測試/etc) 先放到 project schedule 軟體, 這樣對整個 project scope 跟各個事件的相依性會清楚很多. 當然, 如果最後畫的出 critical path 更好, 不過在現實世界的互動裡, critical path 會隨專案進行變動的 ;)

* 保持溝通透明與順暢

專案越大, 協調溝通的人越多, 溝通透明跟順暢就越重要. 透明是盡量讓溝通過程中造成的誤解減少, 原則是對事不對人, 記得傳遞訊息的目的是解決問題. 順暢是讓專案成員願意主動傳遞訊息 (不論是好消息還是壞消息). 專案進行中有意識 or 無意識自我過濾訊息, 通常是災難的開始. Schedule 很多東西是看不到的, 通常事情都是發生問題, 才能從 schedule 看到 delay. 溝通的透明跟順暢讓這些看不出的問題, 影響 schedule 的程度減少, 同時縮短下對策的反應時間.

硬體產品專案管理經驗分享 - 專利 (IPR)

2009-09-02T02:45:00.000-07:00

記得很久以前, 小時候看天下雜誌還是商業週刊, 提到企業的資訊蒐集及 data mining 能力很重要. 那時只是很抽象的知道這件事很重要, 但是並沒有意識到到底有多重要 (or 多可怕). 工作一段時間之後, 透過許多不同的方式, 看到各家的產業報告, VC (venture capital) 的投資分析, 以及 real world 的專利分析報告. 才驚覺自己所學在整個產業中的渺小.

並不是每個人都喜歡 Intellectual Property Right (IPR) 的觀念, 跟所造成的壟斷跟限制, 但是現在除非是都是以專案 (非歐美地區) 或是封閉性小眾客戶為主, 我個人認為, 做產品很難不遇到 IPR 問題. 所以做某個跟 $$ 相關的決定, 要能先意識到 IPR 問題是很重要的, 因為這代表著隱藏的時間, 成本, 跟風險. 這類跟 IPR 相關的產品管理不是只出現在電子 or 製造業. 其它例如藥品業, 也是產品開發時就已經結合 IPR 跟生命週期管理. 透過有組織的分析各種公開資訊 (專利/法律/財報), 可以看見很多公司內部的訊息, 常見的包含:

* 公司未來可能產品方向跟佈局
* 公司有哪些專利訴訟正在進行 <- 有哪些 IPR 是經的起考驗, 或真的有 value 可以跟人家 trade
* 專利申請人有哪些 <- 通常是有 know-how 的 key man
* 用 IPR 被引用的次數, 做公司實際 value 的評估

另外, 很多人把 IPR 管理/分析, 跟商標/專利申請混為一談. 也很常常見到低品質, 或是其實無任何保護或攻擊效力的專利申請, 當成是 IPR 應用的全部. IPR 這個領域也已經有百多年歷史了, 其實有分工非常細的生態, 不是簡單可以說完的. 我個人是覺得科技業的企業整體戰力, 跟 IPR 法務戰力基本上是成正比的. 產品遇到的 IPR 問題, 也通常跟產品的熱門程度成正比 :)

很多人對 IPR 有很多迷思, 典型的例如: 這個產品是我們自己設計的, 沒有參考別人, 就沒有 IPR 問題. Or 我的 reference design 來自某某知名公司, 不會有相關 IPR 授權金問題. Or 用 Open source 沒有權利金的問題... 很多啦, 這幾個敘述都該打 X, 因為都是錯的 :) . 這邊有幾點常見注意的問題.

* 產品有哪些關鍵零組件 (key components), 這些關鍵零組件本身是否已經 cover 了 IPR (尤其是需要 essential IPR (基礎專利, 簡單來說就是你不可能做出功能一樣, 但是不侵犯專利的產品) 的元件, 如 GSM/3G/etc...)的費用? 一般來說, chipset solution 不 cover 終端產品的 IPR, 而 module solution 有些會, 有些不會. 在選料時要先確認.

* 很多專利 alliance/pool, 是找 manufacturer 簽約付授權金, 而不是根據 design house 或是 branding company 的實際生產/出貨數量. 這會造成 manufacturer 不見得願意付, 或是跟你一起跟 alliance/pool 談.

* 若使用的硬體 chipset 有內建 codec (MEPG2/MPEG3/others), 或 firmware (software) 包含 codec, 就有可能需要付授權費. 簡單的使用者 2 次加工 (例如: 出貨時功能不全, 但使用者把某一個東西放進 device, 或是按下某個鍵, 就可以讓 device 功能完整), 不見得能規避 IPR 的問題.

* (歐洲) 某些國家海關 (如: 德國), 海關可以直接扣押主觀認為有侵權疑慮的產品, 所以可能在沒收到任何 IP holder 的 letter 下, 毫無預警被扣押.

*產品交貨是 FOB, DDU 或是 DDP, IPR 授權金基本上跟出貨地點有間接關係 (who will pay), 在考慮整體 cost 跟 BOM 時, PM 應該把這一部份成本跟 schedule 考慮進去.

* 因為通常一個產品裡面會有多個 function block, 每個 function 都有可能有 patent 的問題. 所以被人發 letter claim IPR fee 時, 先確認人家 claim 什麼? 很多公司都是發警告信, 但是不會在第一時間跟你說要 claim 什麼. 此時不要 panic, 請先回信確認他代表哪些 IPR pool, 他要 claim 什麼?

* 如果產品中有包含 Open Source (GPL) 軟體/tools (如 busybox), 產品相關的 source code 也需要公佈, for example: http://thinkingopen.wordpress.com/2008/06/10/busybox-is-back-back-again/ 如果用到 codec, 還是要付 codec alliance 的 IPR.

當初 google android 不直接使用 Java ME VM 在產品中, 而自己重做 Dalvik VM, 其實也是有 patent 跟策略考慮在裡面, 因為能 open source code 跟能將 code 以硬體產品方式散佈是不同的授權 (不知道有沒有人冒冷汗 ^^!). 其中還點到 MS 跟 Sun 當初對 JVM 交換授權的問題. 有興趣可以搜尋一下 dalvik vm 相關的文章. 例如這一篇: http://www.betaversion.org/~stefano/linotype/news/110/ 裏面把 google 不使用 sun 的技術的原因, 從策略角度上做了不錯的說明. 除了規避之外, Microsoft 買了 Andy Rubin (Android leader) 的前一個 fund 的公司 Danger (同樣 base on JVM), 很多分析家都在看 Microsoft 何時會拿出這張牌.

即使是單純接收資料的 GPS, 可能在不同地區也會被 claim IPR (會發生很奇怪的現象, 收美國軍方衛星資料, 但要付歐洲公司錢??) 所以沒有什麼不會被 claim 的.

相關 IPR 的資訊現在開始越來越多, 下面幾個網站我覺得還蠻值得入門參考的:

* 國家實驗研究院科技政策研究與資訊中心 http://cdnet.stpi.org.tw/intro.htm
* 資策會科技法律中心 http://stlc.iii.org.tw/

參考書籍的話, 周延鵬 (周律師) 的書不錯, 很多 Business 上的細節都有點到, 很值得參考, 推一下 :)

硬體產品專案管理經驗分享 - 規格 (specification)

2009-08-27T00:33:00.001-07:00

前一陣子有朋友問到硬體產品專案設計/生產/測試該注意到的問題. 本來我想翻一下 google 找一些比較完整的說明 forward, 除本身這個話題範圍很廣外, 不知是我關鍵字用錯還是怎樣, 找不到比較適合的, 就順便就把我覺得 PM 該知道, 該注意的寫出來.

在有規模的系統廠, 組織的分工比較細, 硬體專案進行都有自己公司的標準 ISO 流程或 PDM/PLM 系統. 從前段規格確認, IP 專利分析規避, 合約檢查, 中段的設計檢查, 量場規劃, 到後段生產 flow, 生產 ramp up 該做的流程都蠻固定的, 但項目說起來頗多 (其實是非常多, 理論上所有 ISO 流程文件都會產出, 並且最後入到 DCC (document control center) 做統一管理). 像手持裝置 ("非" feature phone 類的) 變化又更多, 所以, 這邊介紹時會簡化很多.

在這邊除了寫規格該注意的事項外, 我覺得有幾個非技術的事情 PM 要隨時注意, 例如:

* 要保持對狀況的靈敏度 (例如: 要交付的目標是什麼, 目前共識有哪些, pending issue 有哪些, 問題的優先順序跟其他人是否一樣). 重點是, 不要讓自己或團隊狀況外. 你的產品會忠實呈現團隊狀況外的程度.

* 認識 team member 的行為模式, 不見得每個人都是華盛頓 (either 沒事會去砍櫻桃樹或面對問題認錯), 自我感覺良好不是高官們的專利. 從辦公室打掃的, 到公司管理階層, 沒出大事之前大家的感覺都會很好.

* 對自己不了解的問題, 不要輕易放水. 放水不代表不用負責, 只代表還不夠專業.

* 要記得追蹤有風險的決定, 不要以為一開始沒事就沒事. 莫非定律出現的機會通常比你的運氣好. 如果要用趕工 (crashing) 或是同步作業 (fast tracking), 請記得讓大家知道這叫 fast tracking 跟 crashing, 是有額外 cost 的. 要記得警告大家風險成本是多少.

* 問題能早解決就早解決, 拖到最後還是要解. 常見有人剛開始跟你說 ok, 但最後大家都得健忘症, 代價沒人願意承擔. 遇到這種情形, 請把深海魚油跟雞精準備好, 魚油給別人補腦力, 雞精留給自己熬夜吧 =_=

雖然大家都知道這些, 但是常因為現實環境 (成本, 時間, 部門利害關係) 而犧牲. 但是, 不管如何, 還是要隨時注意. 下面每個主題, 都只簡單介紹該領域我覺得最簡要的部份 (也就是包括, 但不限於的意思啦):

* 不要覺得規格確認是 one time work
規格確認不是一件做完就不用管的事, 而是一件到產品 phase out 之前都可能會跟著你的問題. 因為可能發生的狀況太多, 有可能零件停產, 某批零件 quality 有問題, 客戶發現新的設計問題, 有新的法規等... 不過以項目來說, 主要下面幾點:

** 硬體功能需求: 要有哪些硬體功能, 以及這些硬體功能的規格要求. 舉例來說: wi-fi 不是 chipset solution 決定就好, 輸出的 power 跟天線敏感度, 耗電量這些細節都要放到文件裡. 現在 wi-fi chipset 都會有 firmware 或是執行時要載入 firmware. Firmware 經常會有細小的差異跟 bugfix, 這些都會影響中段產品測試, 認證及產測規格. 如果客戶有指定或覺得重要的 test case (穩定在某個環境, 傳輸多少資料的效率或不中斷之類的測試), 請一定要做.
如果 wi-fi 傳輸時要亮燈, 或是可以用 packet 喚醒 suspend (IP phone 標準) 狀態的 wi-fi, 這些都跟電路的設計相關. 通常設計階段還會跟硬體及機構件的 placement (晶片放在電路板哪些位置) 相關, 這些都會影響 schedule 跟最終客戶驗收的 quality, 請注意.

** 與硬體相關使用者行為確認
使用者介面分為兩個, 一個是純軟體的 UI, 另一個是跟硬體的互動 (通常是 LED/按鍵/Dial/track ball 等等). 拿 iPod 當例子來說, 當 iPod 在播放音樂時, 把耳機線拔掉, 音樂就會停. 這就是硬體設計 interrupt 支援軟體行為可能性的範例. 盡可能把所有 user case 釐清楚. 請千萬記住, 硬體是沒辦法跟軟體一樣說改就改. 軟體按 make 重新 compile 的成本很低 (至少一般人感覺很低啦 =_= ), 以為改硬體也是重新焊個元件, 改個電路, 加個電阻或換個 filter. 但是改硬體馬上就有原有料變廢料,重新驗証新料/電路的時間, 新洗板子, 打件驗証的時間, DFM (design for manufacturing) 變更, 這時間跟成本其實是難以想像的高.
或許有人會提 rework 可節省一些驗證的時間, 但是問題是: rework 的 quality 通常不穩定, 很多驗證時會發生: 這是原有的問題, 還是 rework 的問題? 功能可能可以 rework 驗證, 但 DFM 可能還是要重新來一次才能確保 quality.

** 使用環境: 裝置是手持式, 車用, 家用, 工業用, 玩具都有不同的測試規範. 主銷非洲市場跟用在俄羅斯的產品要做的測試重點也不太一樣. 請針對環境可能的需求, 讓客戶盡量描述清楚, 並跟相關人員討論增加一些對應的 test case, 以及對應的入料檢驗規範. 在環測測試中, 你會發覺大部分東西遠比你想像的容易壞, 而零件的價格跟品質大部分都是有道理的. 請記得, 零件供應商的產品規格不檢驗的問題在 "你", 客戶通常是不會找零件供應商的. 東西該摔就要摔, 該震就要震, ESD 該打多少就多少. 產品的 quality 控制就靠這些細節執行. 我也相信 PMI 說的 quality 是 design in, 不是 inspect in, 但事實是: 通常大家都覺得已經 design in 了, 直到 fuse 爆掉那一天.

** 使用壽命: 使用壽命跟產品的成本 Life cycle 管理, 供應商管理, 售後服務都有關係. 跟產品的設計, 用料都有直接的關係. 機構料本身的 cycle 數使用限制, 到 SD 卡插槽的跟 SD 卡接點 pin 耐磨程度, connector 的鍍金厚度. 都是 base on 使用環境跟使用者行為來評估. 另外售後服務的時間, 跟備 customer support 的料的量, 都應該找相關部門以評估成本.

** 認證: 認證大致有幾種 1. 安規 Safty 類 2. 不同國家進口的額外需求 3. 客戶營運商需求 (PTRCB/FTA/etc) 4. 綠色環保類 (Green, RoHS, WEEE) 5. 還有要掛 Logo 類 (Bluetooth/Wi-Fi/etc). 不同國家的安規規定, 也會造成產品包裝/標示/說明書問題, 甚至送認證的名稱都可能會影響後續進口流程及系列產品認證, 這些都在認證時要考慮.

標準的安規例如 FCC/CE, 需要注意的地方是要跟安規實驗室 (lab) 討論 user test case. 產品的硬體版本, 及相關 accessory (尤其是變壓器/充電器), 連接 cable 等, 在進 lab 前請先確認. 同時, 進 lab 前記得要先做 pre-test, 如果 pre-test 沒過, 通常都是有 RD 沒說的隱藏問題, 一般來說送 lab 前還有這些問題, 這些問題都會影響最後 quality.

安規看起來大家都在做很平常, 但其實可以幫你從外部 lab 角度看產品 EMC/EMI 跟穩定問題. 不同國家, 可能有不同的認證需求, 像手機進台灣還要做 NCC. 如果是包含 GSM/3G 功能, 但是使用的是 chipset 而不是現成的 module (如原為 Siemens 的 Cinterion), CE 還會需要 GSM protocol 相關測試, 這類 protocol 測試一個 run 要上百小時. 如果包含多個 RF 射頻的智慧型裝置, 不同國家還有不同的功率規定及通報規費 and 額外的時間, 請把它算到你出貨的 schedule.

Green 相關常見有 RoHS 跟 WEEE, RoHS 可依廠商宣告書管裡做自我宣告, 這部份每個公司對於廠商宣告書的 policy 跟管理工具都不太一樣. 當然 Lab 也有 X ray 掃描或化學方式可做分析, 但是大部分還是以供應商管理比較多. WEEE 除了要拆解說明書外,還要跟歐盟認可的廢棄物處理商簽約才算有效.

要把 Wi-Fi 跟 Bluetooth 的認證 Logo 合法掛在盒子上, 通常都有額外的認證/測試流程. 想掛 Logo 你必須先加入對應組織的會員 ( Alliance 或是 SIG (special interest group)). 加入價錢從免費 (Bluetooth), 到數千 USD 不等, 你必須選擇適合你的 package. 然後才是根據掛 Logo 需要的條件做認證. 請記得, 有 Wi-Fi 跟 Wi-Fi certified 是兩件事. RD 說功能 ok 不代表你可以掛 Logo. 掛 Logo 不是紙盒上印就有的, 要 1. 加入會員, 2. 做過認證 3. 符合相關掛 logo 規定才算. 最後記得把成本算進去. 有些 Logo 還有 IPR 的費用 (DVD/CD/MP3/etc), 付費方式也不一, 請先注意.

如果是你自己開公司作產品, 或公司本身先前沒有為 device 申請 MAC 專屬位置: 還需要先到 IEEE 申請一個 OUI (就是 MAC 位址前3 byte 啦), USB forum 申請一個 USB ID. 含通訊功能的手機或移動裝置的話, 還需要去申請一段空的 IMEI number 供使用.

IEEE OUI: http://standards.ieee.org/regauth/index.html
USB: https://www.usb.org/members_landing
IMEI: http://www.babt.com/gsm-imei-number-allocation.asp

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

2009-08-05T21:33:00.001-07:00

原本當初 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 可以當參考.

被忽略的M2M (Machine to Machine / 物聯網)

2009-08-02T20:08:00.001-07:00

近來好像大家的注意焦點都擺在小筆電, 或是智慧型手機平台這類產品上. 不論各家廠商如何行銷自己的功能 (多點觸控, 待機時間長, 便宜, UI 炫, 開機使用服務快不快) 但檢驗法則很簡單, 就是使用者 (人) 對於產品的接受度.

小筆電 (x86 based netbook) 目前基本上廠商都只能在 Intel 跟 MS 定下的規則下面玩 (螢幕尺寸, 使用的周邊 chipset, 甚至 Windows 版本). 接下來半年應該是看看 ARM based 的 smartbook 面世後, 看的是一般使用者對於效能及功能上的滿意度. 還有 netbook 跟 smartbook 的 BOM/Retail 價格是不是能重新區隔出一個市場.

Smartphone 智慧型手機看起來雖然家數很多, 目前能提供整合軟硬體的使用者體驗的其實只有 Apple (iTunes/App store) 跟 Blackberry (push mail). 不把 Google/Nokia/HTC/Samsung 算進去是因為 Google 不是自己作硬體, 而 Nokia 的 Ovi store 使用者太少, HTC/Samsung 並沒有使用者忠誠度高的軟體服務.

最近一則新聞沒佔到什麼版面, 不小心閒閒沒事翻 news 翻到, 引起了我的注意. 就是 Verizon Wireless 跟 Qualcomm 要合資組一間專做 M2M 的公司. M2M 是 Machine to Machine 的縮寫, 字面上來說, 就是機器對機器. 寫到這邊, 覺得本篇的標題下錯了. 因為, 今年暑假最 hito 的就是 M2M 啦, 連小孩都愛的 M2M...變形金剛啦!!!

基本上 M2M 涵蓋的範圍很廣, 簡單的例子, 從搭捷運用 RFID 卡到高速公路 ETC 易通機, 或者計程車隊服務都算 M2M 的基本應用. M2M 通常需要整合軟體服務架構及硬體設備, 以提供一個穩定的服務, 所以大部分都是以專案的方式進行. 這裡有一篇介紹 m2m scope 的內容可參考.

http://cdnet.stpi.org.tw/techroom/analysis/2008/pat_08_A021.htm

因為 M2M 中間並不會有 "人", 所以系統穩定性要求很高, 軟體服務設計架構與測試也比一般的 utility 難度高很多. 因為不管是工業應用上的 SCADA 或是移動式車隊服務, 考慮通訊時的狀態/通訊 handshaking 時間窗口/連線穩定都是很大的挑戰. 但是由於資訊服務是內嵌在 M 的 (machine), 所以 M (machine) 只要工作, 就會 "固定" 使用到這些資訊服務跟頻寬, 提供這些服務跟頻寬的公司就可以收到 $$. 這個 ecosystem 裡, 一般通常包含以下的角色:

* 硬體提供者: 製作硬體的公司
* 通訊服務提供者: 通常是電信公司或是網路營運商
* 軟體服務提供者: 提供特定的軟體後台, 以及通訊 middleware
* System Integrator: 整合軟硬體服務

目前專案 M2M 大概包含這些角色. 但是 M2M 是不是只有這樣呢? 前幾年因為專案的關係, 做過一些 M2M applications, 後來因緣際會 Project 剛好有機會接觸到 Dash Navigation 的公司 (前一陣子被 Blackberry 的 RIM 併購), 除了 GPS 導航軟體/通訊服務 (T-mobile/Google wi-fi network)/軟體後台 (JMS/Oracle) 外, 他們基本上扮演了第 5 種角色:

* 整合資訊流提供者: 包含即時路況播送, 網路搜尋, 以及其他 LBS (location based service) 相關資訊提供給 device, 同時 device 也將最新的資料透過內建的統計資料庫及 trigger 將資料即時 feedback 回資訊提供者.

傳統的 M2M 的資料都在原先建好的系統架構中流動, 跟外界基本上是隔絕的. 但是資訊流提供者的角色, 是將整合不同的資訊流 (政府即時路況/搜尋/車隊特定服務/ Telcom 網路) 不斷的將新的外界資訊 Push/Sync 到 Machine 中, Machine 也把資料回饋給外部系統, 讓 Machine 跟 Machine, 以及 Machine 跟人有新的互動可能性. 這也是目前許多 GPS/LBS 廠商, 想要整合的 "功能". 但是, 其實這是一個整合資訊流的新角色.

現在除了 LBS (location based service) 外開始有另一個新名詞 real-time GPS. 也許以後支援這類動態 + 即時 + 雙向交換資訊的 GPS (PND) 會貼一個 real-time GPS, 然後 powered by T-Mobile (or other Telcom) 也說不定.

Dash Navigation 提供不同的資訊流整合 (即時路況/搜尋引擎/來自各地的訊息) 技術, 透過客戶端 request 或將客製化的資訊 push 到每一台 device. 這個軟體 framework 是獨立在硬體之上的, 所以可以預見 RIM 以後, 有計畫提供這類的 LBS based push 服務 (push LBS?).

舉例來說, 這類服務除了可以幫你找附近哪間加油站便宜, 超商在特價外. 對商用人士的服務甚至可能幫你安排兩個人見面的最適當地點, 提供最有效率的評估, 提供建議, 並完成安排行程所有程序 (booking tickets/make reservations/etc).
Verizon Wireless 跟 Qualcomm 的合資 M2M 是只是朝 MVPN 邁進, 還是會像新的整合資訊流提供者呢?

PMP 唸書感想 - 2009

2009-07-27T22:04:00.001-07:00

這一陣子離開 Openmoko 之後, 多了很多時間可以做這幾年計畫要做, 但是一直沒時間做的事. 生活也恢復到比較有趣的狀態. PMP 考試是我其中一個前幾年預計要做, 但一直沒做的事. PMP (Project Management Professional) 是一個專案管理的認證, 不是拍馬屁的縮寫 XD . 從 2000 年之後, 專案管理也一直是一個蠻 hot 的 topic, 我想大概是因為這十年來, 許多的公司原本的 operation 模式都遇到成長的瓶頸, 需要新型態的管理與加強原有組織資源的運用能力, 所以專案管理雖然不是什麼新的學問, 但是這幾年在一般公司才開始比較普及.

對很多人來說, PM (project manager, 有些公司把專案經理叫 jm, 產品經理叫 pm) 就只是幫忙管 schedule, 協調人員/資源的一個角色. 但是實際上, 專案管理的範疇並不是只有這樣. 當然, 有去上過 PMP 課程的都知道 PMBOK 9 大流程: integration, scope, time, cost, quality, HR, communication, risk, procurement 跟 42 個子流程 (PMBOK v4). 看起來 9 個流程好像很多, 也不見得組織內會在 Job description 中遇到, 但是我自己的經驗是一定都碰得到, 只不過不見得是 PM 的執掌, 有些可能是其他 function manager 的勢力範圍. PMI 只是把整個 PM scope outline 出來, 這一點我覺得還不錯, 讓所有準備 PMP 的人有心理準備, PM 不是只把落落長的 schedule gantt chart 填出來就好. 就算要填, 可能也要把 critical path 跟 float/slack 一起確認出來, 不然考試就不會過 XD

不過, 只要是流程, 就有 overhead 跟最小經濟規模. 這一點 PMI 隻字未提, 用一句 organization assets 就帶過去了, 也不管你的 assets 是 ISO 還是 CMMI. 還有如何整合 PMI 的 knowledge 到組織系統中, PM 知道這些東西 (像是 project charter) 的重要是一回事, 能讓想要引進專案系統的公司或組織, 提供一個友善的升級或是銜接方法也是很重要的. 我想一般 PM 管 project 內部的事情就管不完了, 應該沒辦法花太多時間對相關專案執行人員解釋每個流程的重要.

在上課期間, 聽到 effective PM 跟 successful PM 這兩個名詞, 感觸還蠻多的. 因為很多人覺得 effective (有效率) = execution (執行力) = successful (成功) 這幾件事畫上等號, 誤以為把 resource 跟時間投下去, manager 們開始緊迫釘人, 不需要特別的 planning 跟 risk management, 不斷的變更 scope, 只要投入的 resource 夠, project 還是可以得到預期的成果. Effective 可以是一種 PM/Manage style, 但是不見得是專案 successful 的保證 (經常只是把錢燒光). 這幾個名辭中都有潛藏的意思跟條件, 不然他們就該是同一個字. 專案經理的職責, 應該還是要確認專案能如 project charter 設定跟 sponsor 的最終期望 (公司或專案成功) 來設定行為標準.

PMP 考題跟模擬題很多問題很有趣, 剛開始讀會腦筋打結. 因為實務跟 PMI 的理想還有一段差距. 問的問題都很實務, 雖然不見得標準答案很實際. 哈哈... 不過, 撇開考試不談, 一個有經驗的 PM 應該是把盡量把答案準備好來等問題. 如果遇到問題再找答案通常都是災難. 當然無法預測的是風險的特色之一, 但是 PM 對大部分問題 (技術問題 or business 的問題) 應該心裏要有底.

網路上很多 PMP 考試的準備方法, 我基本上也是 base on 這些方法. 因為以前微軟 :P 的試考太多了, 對 CAT 類型的考試還有 Prometric 都很熟啦 :P 加上以前 SD 的 70-300 或更早的 Windows Architecture 也是這類模擬兩可 = 看起來沒標準答案的考試. 就上完課當天就向 PMI 提出考試申請, 一個星期通過申請後, book 時間, 強迫自己念書. 雖然還蠻多人警告 PMBOK v4 剛改版上線, 等幾個月在考, 考試資訊會比較多. 但我實在等不及了, 想說做 PM 那麼久, 被 PMI 當掉也不過只是個被 PMI 當掉的 PM >_< 只是考試費 4xx USD...很貴的失敗代價 >_< 第一次 booking 時間約 2 星期後, 發覺唸不完. 趕快延幾天. 考試 200 題, 寫到 3/4 就覺得超累, 因為大部分都要想一下. 還好最後撐完而且有過...PMP 入手. 以前每次想說考完這一次, 就不要再考試了. 不過好像每次都有意外... =_=

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

2009-06-30T06:59:00.001-07:00

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 ;)

Open Platform Player

2009-06-17T09:11:00.001-07:00

Neng-Yu 'Tony' Tu

最近所謂的開放平台解決方案真是越來越多了, base on linux 的, 數一數已經有下面幾家 player:

* Intel: Moblin
* Nokia: QT, oFono, maemo
* Google: Android
* Palm Pre (http://opensource.palm.com/)

很多人可能不知道, Palm 的核心也是 linux, Palm 也有把 kernel 相關的 patch release 出來. 當然還有 LiMo 跟其他的 foundation, 但是 LiMo 是採會員制的 (Samsung's 採用 LiMo 後做出的 OMNIA), 會員才能取得完整的 source tree).

就連學習曲線很高的 OpenEmbedded 都有蠻多 company 開始 adopt (包括 MontaVista 開始用 bitbake), 雖然 OE 有時不見得是開發嵌入產品最適合的工具.

下面這幾間都是這幾年(最近)比較受到注意的公司, 也有用到 package system (like OE).

* Beagleboard http://beagleboard.org/
* Gumstix
* Bug Labs http://www.buglabs.net/

這幾間公司都有一些蠻有趣玩 embedded 的 idea 跟 community 互動的方式. 大家對 open source 及 community development 有興趣可以參考.

另外, 最近有一家做 open hardware 的樂器公司還蠻 inspire 我的, 他不是做一般的 embedded, 他是做樂器類的應用 http://www.zoybar.net/ . 我一直覺得做音樂的很多工具/模擬器/社群經營都比一般的 embedded 進步 :-P 軟體類如 propellerhead 的 reason 跟 ableton live, 硬體類也有一堆, 例如 http://www.generalguitargadgets.com/ , 可能是音樂跟流行本身就是需要交流產生新的火花吧, 跟單向的生產 -> 銷售是不太一樣的行為.

Developing a FOSS / Linux friendly embedded hardware - component selection

2009-05-10T19:55:00.001-07:00

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.

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

2009-05-07T21:58:00.001-07:00

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.

一篇有意思的 Matrix (駭客任務) 影片分析

2009-04-23T06:46:00.001-07:00

這幾天跟朋友因為討論一些粗淺的神學, 哲學問題, 又討論到 Matrix 這一部我很喜歡的電影, 以前我對這一部電影非常著迷 (and still), 所以會去網路找一些有趣的 review 來讀, 這一篇是我覺得寫的很好的, 然後寫信給原作者讓我翻成中文, 以前這篇放在當代的版上 ( http://www.modernmusician.com/forum/showthread.php?t=21417&page=2 ). 原 post 如下:

-----------------------

以下翻譯自 http://corporatemofo.com/media_and_mediocrity/the_matrix_reloaded_the_corpor.html 此由 Ken Mondschein 授權我中文翻譯此文，並作為非商業用途使用.

網路上也流傳一份有關 Matrix 3 的劇情說明，疑似試片影工作人員外流的劇情，以下網站中，有簡體中文翻譯第 3 集劇情，如果不想知道劇情的，請勿進入!

==========================================
在去看 Matrix: Reload 之前，我對於第二集是不是跟第一集一樣，有出色的特效跟打鬥畫面，並不是那麼在意。在第一集中，故事其實充滿著 Gnostic 的二元論哲學思

想。我比較關心的是 Wachowski 導演兄弟怎麼樣延伸原先的有趣故事，而不是一堆有阿沒的電影效果。那些武打啦，慢動作閃子彈啦的炫程度，遠比不上把我們這個世界，直接說成是假的來的猛。那些特效跟功夫打鬥，其實都是紅色藥丸的糖衣，讓高中生跟一般人比較能接受這部電影 (自從我開始學習武術之後，發覺有許多超現實的隱喻在功夫裡面。像 Thibault's 的神秘圓圈走位方式還真是有趣。

注: Thibault's http://www.dctkd.org/bibliography/re....cfm?pubID=260

雖然大部分的人看不懂 Wachowskis 導演兄弟在 Reloaded 這一部片要表達什麼，注意力也都集中在公路追逐的畫面。但 Reloaded 並沒有讓我失望，那些畫面對我來說還好，比較驚訝的是那兩兄弟將死海捲軸 (Dead Sea Scrolls) 跟俄利根 (Origen...註)

的神學理論巧妙地用在劇本中，實在是非常聰明的想法。我明白劇中東出現一個人物，西出現一句的劇本實在很難令人了解。而劇情，只在飛車追逐跟動作畫面的休息時間出現。下面是對 Reloaded 這部片的一點解釋，如果你還沒看 Reloaded，請先忍一下吧!

Martrix 基本上就是基努李維的地下世界之旅 (跟阿比阿弟暢遊鬼門關蠻像的)，如果 Neo 除了變超人那招外，帶著阿弟回到 Matrix 應該會更有趣。在金枝 (Goloden Bough...註) 書中有女預言家，在 Matrix 中有 Oracle 引導 Neo 進行它的旅程 (Oracle 可能並不如表面上看起來那麼善良，即使她沒惡意，但是把 Neo 拖下水也有它的一份)。

Neo 的第一個任務就是從 Merovingin 手中解救 Key Maker (Randall Duk Kim 扮演)，Merovingian 是 Matrix 上一個版本所留下來的背景服務程式 (Merovingians 是 Frankish 王朝的統治者，後來被查理曼 (Charlemagne ) 大帝家族所繼承 (包括有卡洛琳 (Carolingians) 王朝及之後的卡佩 (Capetians) 王朝，他們相信自己有耶穌的後裔血統)。在我常去買燕麥捲跟豆奶的健康食品店裡面，大家都認為 Merovingian 是 Neo 的前身。但是從 Merovingin 在電影中對於人類情慾如此有興趣，我想到聖經創世紀 6:4 節中的內容: "那時候有偉人在地上、後來神的兒子們、和人的女子們交合生子、那就是上古英武有名的人 ........"。而天使與人的交合後，產生了許多的怪物 (吸血鬼跟死靈)......對應到劇情，就是以前 Matrix 程式所留下來的那一堆無法刪除的程式。從線索中 ( 即使 Merovingian 是前個世界留下來的人，它角色仍然像是冥王 Hades 一樣 (由他老婆叫 Persephone (冥后) 可知，掌管著地下世界的鑰匙。像是特洛伊 (Troy) 戰爭中的勇士 Aeneas 的嚮導 Sybil 女巫，給了Aeneas 的金色樹枝，讓它順利進入地下世界。Neo 也利用 Key Maker 順利的進入 Matrix 系統中心。

接著經過一連串的戰鬥和爆破畫面後，Neo 終於殺進 Matrix 的核心，然後遇到了 Matrix 的建造者 Architect。如果你以為在 Matrix 中 Architect 是扮演上帝的角色，那你就錯了。從 Gnostic 派的看法中，建立世界以奴役人性的當然是撒旦而不是上帝。Architect 放出那一堆八爪章魚來毀滅 Zion，也代表開啟世界末日的序幕。我猜第 3 集 (Revolutions) 中會揭露誰在 Architect 後面搞鬼，那個人就是把 The One 送進 Matrix ，我猜它長得一定很像 Neo (譯註)。

其實重點是 Architect 跟 Neo 說的是真的還是假的，他說 " 99% 的人都相信 Matrix 是真的，但是還有 1% 的人不相信這個虛擬的世界 (相對於少數 Gnostic 教派的信仰者)。所以 Matrix 系統會變得不穩定，隨時有當機的危險" (所以電影中，在 Zion 出現的人多半是有色人種。如果你是白人，住在郊區的住宅區，開著你在 Matrix 的休旅車到 Matrix 的高爾夫俱樂部.....那幹嘛沒事找事懷疑自己所處的世界是不是真的?)

所以 Matrix 容許這些不相信 Matrix 系統真實性的人轉移到 Zion，然後他們可以定期清除 Zion 這些不合群的人。同時 Matrix 也創造出 The One 傳說，而 The One 其實是為了增強 Matrix 人性化，讓 Matrix 的存在更穩定的設計。然後 The One 就可以啟動 Zion 的毀滅程序。在馬雅文化及佛教中，這種滅世後重生想法經常出現，在馬雅文化中，目前我們正處於第 5 次循環，而第 6 次循環從 2016 年開始。

利用 Zion 跟救世主的預言，建立另一層 Matrix 的概念，其實出自於 French 哲學。這電影使用了波德來爾 (Baudrillard) 摹物與摹像 (Simulacra and Simulation)，並加入了傅科 (Foucault) 和達希達 (Derrida) 的結構與解構主義的觀點。在他們的理論中，系統對於語言及其他社會功能的限制，只是間接展示控制權的工具。而預言本身就何其他的預言一樣，是信仰的一部分。John Zerzan 曾寫過信仰的目的在於操作符號 (signs)，而那些預言也包含了某些控制目的。Zion 在 Matrix 中是一個應許之地，脫離了善惡的戰爭，人們身處其中而不會疑問存在的世界是否還是真實的。

要了解 Matrix 中的世界，還必須了解 Asimov's (埃席克•艾西莫夫（俄裔美籍，1920-1992) 的三大機械人定律 (Laws of Robotics)，機器人如 Smith 之流，並沒有自由意志，即使脫離了 Matrix，他還是要苦苦追殺 Neo (在許多神學理論中，天使和許多其他具有神格的東西並不像人一樣擁有自由意志)。Morpheus (作夢之神) 在第一集說那些機器將人囚禁起來，當作生物電池之類的說明根本是放屁。機器統治世界之後還將靈魂思考關在 Matrix 中，是因為他們本來就是創造來服務人類，而且機器本身還是需要人來做一些選擇。所以機器並無法摧毀人性 (靈魂)，反而需要人來做一些選擇。

正如 Architect 所說的 Neo 不是第一個，而是第六個.....但為什麼是第六個呢? 答案就是 Neo 之前的化身代表 Five Books of Moses 代表聖經中的舊約。 Neo (代表救世的基督，也代表著新約時期)，跟他前面幾代 Neo 不同的地方在於他具有 "愛" (希臘文中的 eros) 的能力。在 Origen of Alexandria 的神學理論以及早期的基督教徒筆下，耶穌基督因為愛而降世救贖人性。而 Neo 單字本身代表著 "新" 或換言之的新約時期。 Matrix 在這一次又一次的循環中，也遇到一個會為了 Trinity 而毀滅人性的不合邏輯決定的 Neo。[Note to the theology geeks who've been e-mailing me:

I know the difference between eros and agape, but Origen used both terms for reasons I'd have to delve into pre-Socratic philosophy to explain.]

當 Architect 給 Neo 選擇的時候，是讓他選擇純機器世界，或純人類世界，而不僅把 Neo 變成能重新清除並啟動 Zion 的工具，。Architect's 說 The One 的目的在於清除所有的人性，但是由於 Neo 具有人性的部分，所以機器並無法控制，讓 Matrix 間接變得不是真的能準確預測。Neo 在 Origen 的神學理論中就是基督的化身，能打破生死間的循環，讓人性有一個新未來。在影片的最後 Neo 跟 Smith 先生，都在所謂的 "真實" 世界得到了一樣大的力量，也間接證明了 Matrix 模擬不只一層，所以 Neo 在這兩層都有力量。

一些有趣的花絮:
* Neo 跟 Trinity 在拱廊下愛愛的畫面，和馬澳其賽的三位一體圖有異曲同工之妙 (原圖請參閱原文，而說明請見 http://ceiba.cc.ntu.edu.tw/th9_207/w...messages/5.htm
* The One 來自機械世界的說法，巧妙地讓基努李維避免掉許多無法表演的內心....(程式) 運作戲碼。
*在來自 St. Augustine's 的神學理論中，像是 Oracle 跟 Neo 的預知能力都可以得到很好的解釋。
*j我看電影的時候，旁邊坐了一個非常可愛的女孩

在第三部片子應該會揭露一些迷團:

* 誰在 Architect 後面搞鬼
* Neo 必須要做出一些選擇，但重點是 "選擇是什麼"
* 正邪間的大戰必定爆發，但打完後呢?
* Agent Smith 到底是幹嘛的? 他有類似驅魔的能力 (....一人方陣兵團)，但是我打賭他會和 Neo 結盟.....
* Neo 為什麼會有能力在現實世界中，把機械章魚幹掉?
* Tank 怎麼掛的?
* Link 會再次見到 Zee 嗎?
* Niobe 會離開 Jason Lock 回到 Morpheus 的懷抱嗎?
* Gloria Foster (Oracle) 怎麼辦? 也掛了嗎? (他在 Reloaded 中拍了有不少的鏡頭，但 Revolutions 卻沒有多少鏡頭)
* 教士服會變成流行服飾嗎?
* 那位給 Neo 湯匙的小沙彌有什麼關鍵性的意義嗎?
* Neo 會殺了 Bane 嗎? Bane 所損毀的 Zion 防禦有多嚴重
* 誰帶 Morpheus 去找 Oracle 的?
* 在第 2 集的 "真實" 世界如果也是假的，是不是有一層疊一層的 "Matrix" 呢.....(譯註: 果然是名符其實的 Matrix...Hehehe....)?
* 如果第 3 集 Zion 確定是假的，那麼 Neo 會將那些人帶到真的的世界嗎 (當然再怎麼樣會扯，這都是一部電影，他們當然跑不出來)
* Neo 會突然醒過來說 "幹，你一定不相信我做了一個什麼夢....?"

註 Origen of Alexandria 的參考網址 http://www.christian-assembly.org/se...0030309-03.htm

註: 西元843年凡爾登協約(Treaty of Verdun)將卡洛林王朝(Carolingian)劃分為法蘭西(France)與日爾曼(Germania)

參考網址:
查理曼大帝 http://homework.wtuc.edu.tw/~wenlurg/forghis/0226-6.htm

Gnostic 跟金枝 (Golden Bough) 說明 http://deepskies.virtualave.net/orig...hers_3zoro.htm
http://www.lsmchinese.org/big5/07onl...s/3-1/3101.htm

創世紀 6:4 節，有關諾雅方舟的故事 http://www.chinachristianbooks.org/

Kabbalah http://god.hifate.com.tw/icp/icp46.asp

Architect 在資訊科技產業 (IT) 代表的是能整合許多不同知識的資深工程師，台灣常翻成架構工程師

譯註: 我反而猜它長得像 Trinity (Most the Guy think Trinity should be the Guy, Right? ^_^ )

北京記遊 2009 04

2009-04-23T05:51:00.001-07:00

最近 project 告一段落, 有時間到處走一走. 剛好有朋友在北京工作, 以前出差都在大陸南方跟西邊的城市 (上海/深圳/武漢/西安...etc), 也沒到過北京 + 外公也算北京人, 所以就趁機到北京感覺一下大陸首都的氣氛.

2009 4 beijing

北京的空氣感覺蠻像 LA 的, 都是那種乾乾的空氣. 然後地鐵很方便, 聽說是奧運前把整個路網完成. 除了長城跟 13 陵外, 幾乎所有的重要景點都可以坐地鐵到達, 算是非常方便. 可能北京經過奧運洗禮的關係, 整體的環境跟人文素質的確比一般人所認知的大陸城市要好很多. 從地鐵上拿 iPhone 跟 Nokia/Blackberry 的人數, 就可以感覺的出來 :)

當然不免俗的, 我也紫禁城/長城/13 陵/前門大街/王府井/頤和園/798 等等地方走了一圈. 到大陸腳力真的要好, 不然長城學校教科書遠拍的照片看起來都是平的, 八達嶺的長城的階梯大概起碼有 30-50 層樓高, 沒一點腳力真的會累死. 平地的頤和園走一圈大概也要一整天, 大概半天腳就軟了.

頤和園果然不虛此名, 園內建築集江南庭園山水之長. 雖然歷史上將甲午戰爭戰敗歸咎於慈禧挪用軍費修園. 不知現在到頤和園熙來人往的人群, 看到頤和園欣賞美麗的風景同時, 會不會對歷史有另一番看法.

798 是另一個值得去的景點, 這裡原先是北京將廢置的廠房便宜出租給藝術工作人員, 供創作及展覽的地方. 目前算是經營很成功的藝術展出場地, 也有不錯的餐廳跟定期展覽 (UCCA). 整個園區也需要 6-8 小時才能逛完, 雖然展出風格有些一致, 但還是非常的不錯, 值得一遊.

找一台適合跑 Linux 的電腦

2009-04-02T04:33:00.001-07:00

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-04-01T04:10:00.001-07:00

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.

who I am

2009-03-26T08:30:00.000-07:00

當具備多種不同專長能力後, 很多事情到後來是對生活態度跟生活方式的選擇. 每個選擇, 會有現實的理由, 當然也有抽象的原因. 很多時候, 人的一部分自我都活在別人的猜測跟想像中, 真實的那個, 本人可能都不見得認的清吧!

所有抽象具像化, 唯一的結果就是失真. 我很想解釋, 但是唯一的方式就是用失真的範例, 透過破碎的共同認知, 傳達一個注定模糊無意義的訊息.

我只知道, 我愛音樂, 也愛電腦及各式科技帶來的可能性. 每個人在某個時間點, 都會遇到 Neo pick pill 的問題. And, you never know what the choice means...

Life is still moving forward...

專注力 - Ichiro

2009-03-25T08:35:00.001-07:00

昨天很難得的, 有閑也有心情看棒球經典賽. 打開電視的時候, 日本還以 1 分領先, 後來一連串拉鋸的過程很精采, 但是我真正有興趣的一瞬, 是 ichiro 面對 10 局上, 面對命運之神帶著一點挑臖意味, 關鍵打席的表現.

我對於 Ichiro 的印象就是 baseball monk, 就是把棒球運動當成是一種修行, 包括練習的態度, 對球具的尊重...等. 而修行的成果, 可以從一路以來, 在比賽中的穩定表現看出來.

10 局上, Ichiro 站上運命的位置後, 一直很注意他的眼神跟動作, 我很好奇, 在這麼關鍵時間, 關鍵位置, 關鍵表現. 到底是: 苦修的專注力勝利? 還是球是圓的, 一切都是運氣?

就在 Ichiro 跟投手展開一連串的纏鬥, 連挖地瓜的球都擊成界外後, 我突然覺得, Ichiro 的穩定表現不是僅是個人專注力, 專注力更進一步的影響了整個氣氛. 運氣變成專注力有機會表現的舞台.

最後, 很 Ichiro 的安打, 結束了兩隊的糾纏. 運氣也許讓他站上了決定勝敗的關鍵位置. 但我想, 在那一瞬間, 我只能從 Ichiro 眼中看到專注力, 沒有運氣.

It's a great game - thanks to all players in this game!!!

FreeRunner 一堆使用上的小 trick

2009-03-13T03:24:00.001-07:00

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 的工作.

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

2009-03-11T02:08:00.001-07:00

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 端:

http://wiki.openmoko.org/wiki/ReMoko

Source 在:

http://code.google.com/p/remoko/

Google Developer 也有官方的 sample

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

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

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

2009-03-10T00:01:00.001-07:00

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

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

2008-12-26T03:49:00.001-08:00

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 主要的開發人員都在 wiki 的 Who is Who 頁面中 ( http://wiki.openmoko.org/wiki/Who_is_Who ). 透過 mailing list 或是討論區介面的 mailing list nabble (http://lists.openmoko.org/nabble.html) 是最直接的方式.

雖然大部分的 developer 已經成為歷史, 但是我還是把名字列出來 (2009, March upadte)

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

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

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

2008-12-22T03:25:00.000-08:00

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

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

2008-12-09T00:38:00.000-08:00

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 版及以後的硬體, 均應該設計搭配此功能), 開機後, 放入已過度放電的電池進行充電.

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

2008-12-03T03:49:00.001-08:00

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 .

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

2008-12-02T00:31:00.001-08:00

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 的用法, 這邊先略過.

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

2008-12-01T01:09:00.001-08:00

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 命令.

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

2008-11-27T19:46:00.001-08:00

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 的功能.

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

2008-11-26T03:00:00.001-08:00

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 了.

Neo FreeRunner 新手手冊 (2) 登入 FreeRunner 終端機及安裝/更新套件

2008-11-25T20:50:00.001-08:00

Neng-Yu Tu (Tony Tu)

FreeRunner 基本上有兩種終端機 (Terminal) 模式, 分別是 u-boot 時的 UART 終端機模式以及開機完成後, 可以透過 FreeRunner 預設的 SSH server 連進 FreeRunner. 基本上直接用 Linux (或是 vmware 上的 Linux) 的系統做這些連線比較簡單, 只要直接連上就可以直接從 /dev/ttyACM0 或是 ifconfig 看到 USB0. Windows 則需要裝另外的 RNDIS gadget 驅動程式 .inf 檔案. 接下來會針對這幾種方式說明.

Neo 還有一個 debug board (上面還有一顆蠻神奇的 FTDI 晶片), 可以透過主板上的 debug port (UART/JTAG) 對 Neo 做低階除錯動作. 在此先略過.

[U-Boot 終端機]

U-Boot 的終端機是典型的 UART terminal, NOR flash 跟 NAND flash 裡面的 u-boot 預設的輸出導向都是 USB tty. U-boot 終端機可以用來做一些低階的 register 開關或設定動作. 或是像是重設開機環境變數之類. 相關的資料可以從:

http://wiki.openmoko.org/wiki/U-boot 找到. 以 NOR u-boot 來說, 開機時按下 Aux 鍵, 再按下開機鈕, 畫面會停在 u-boot 上. 此時連接 FreeRunner 及手機上的 USB 接頭, 應該可以在 /dev 下看到 ttyACM0.

然後可以挑一個習慣的 COM port 公用程式, 像是 minicom 或是圖形的 cutecom. 或是個人常用的 neocon/cu . neocon 可以從http://svn.openmoko.org/developers/werner/neocon/ 找到.

連接參數為 115200, N, 8, 1, no hardware flow control

[用 SSH 連到 Neo]

FreeRunner 預設的 image 都有 SSH server/client (dropbear), 可以透過 SSH 進到 FreeRunner , 同時可以用 SCP 做一些檔案傳輸的工作. FreeRunner USB 埠預設的

IP address 是 192.168.0.202, netmask 是 255.255.255.0 這些設定都可以在FreeRunner /etc/network/interfaces 下修改.

所以當開機完成後, 連接電腦及 FreeRunner, 然後用 root 帳號登入 192.168.0.202 (使用 sudo or login as root), 密碼是空白:

root@ubuntu:~# ifconfig usb0 192.168.0.200 netmask 255.255.255.0
root@ubuntu:~# ssh root@192.168.0.202
root@192.168.0.202's password:
root@om-gta02:~#

然後接下來你就可以下一般的 linux command 及使用 script 了.

[安裝及更新套件]

Openmoko 使用源自 ipkg 的 opkg 套件管理系統, 改名的原因有很多, 但是重點是: 基本架構 opkg 跟 ipkg 是很類似的. 如果使用過 yum 或是 apt-get, opkg 的用法也是差不多的. 所以安裝套件有 3 種方式, 一種是將套件檔 xxx.ipk 或 xxx.opk 從網路上下載, 然後手動進終端機畫面後安裝. 第 2 種, 是利用 Neo 本身的 USB/Wi-Fi/Bluetooth 網路功能, 連線後透過終端機進行套件的安裝工作. 或是第 3 種, 網路連線後, 透過 2008.x 上面的 Installer 來進行安裝.

由於 Openmoko 本身非常具有 "community development" 的特性 ;) 所以套件的相關位址和狀態一直在變化. 最早隨 FreeRunner 出貨的 200804 GTK (有時也被稱為 2007.x 版) 版本, 是無法直接用 opkg update 或是 opkg upgrade 到最新的 Om2008. 9 or later . 建議直接參考其他資料先進行 FreeRunner 更新 image 的動作. 同時 2008.x 也有 release/un-stable/testing 的幾個不同的 tracking. 不同 Tracking 的差別會稍後說明.

FreeRunner 相關的 opkg feed 設定, 可以在 etc/opkg/ 的 .conf 檔案中找到. opkg 套件管理程式主要的 maintainer 是 tick.

* 手動安裝
Step 1: 搜尋一下哪裡有提供 neo package 的位址, 或可以從 http://t0ny.net/openmoko/opkg/samples/ 下載 orrery_2.0_arm_2008.8.ipk 然後繼續下面的步驟.

Step 2: 透過下面的命令連線:
root@tony-ubuntu:~# ifconfig usb0 192.168.0.200 netmask 255.255.255.0
root@tony-ubuntu:~# ssh root@192.168.0.202
root@192.168.0.202's password:
root@om-gta02:~# scp root@192.168.0.200:~/Desktop/opk/orrery_2.0_arm_2008.8.
ipk root@192.168.0.202:~
WARNING: Ignoring unknown argument '-x'
WARNING: Ignoring unknown argument '-oClearAllForwardings yes'
WARNING: Ignoring unknown argument '-n'
root@192.168.0.200's password:
root@om-gta02:~# ls

Step 3: 直接利用 opkg install orrery_2.0_arm_2008.8.ipk 安裝套件. 有時套件系統會因為某一些系統行為停掉, 此時你必須使用killall packagekitd 來停掉 opkg 服務再重新進行安裝程序.

* 透過網路安裝
透過網路連線需要幾個額外的步驟, 建立 USB/wi-fi/Bluetooth 網路連線及設定 Neo 的 DNS 設定. 設定完後, 就可以直接透過 opkg install 安裝.

root@om-gta02:~#opkg install packagename.opk

* 透過 UI 上的 Installer 安裝
必須先建立網路連線, 才能透過 Installer 安裝相關的 package. 你必須先到 2008.x 的主畫面中, 選擇 Settings, 然後啟動 wi-fi 並輸入 WPA 密碼. 螢幕小鍵盤的使用方式很 tricky, 你必須在鍵盤右側的黑框上, 上下移動選擇數字或其他特殊符號. 由於 2008.x 的 wi-fi 設定程式有些 bug, 建議參考其他方式確認網路連線後, 再透過 Installer 安裝.

[移除 package]
移除 package 可以使用 opkg remove package_name , 相關的命令可以用 opkg --help 找到

Neo FreeRunner 新手手冊 (1) 認識 Distribution 及更新 image

2008-11-25T00:27:00.001-08:00

Neng-Yu Tu (Tony Tu)

[認識 Openmoko 的相關 Distribution]

通常拿到 Neo 第一件是要學會的就是如何更新手機裡面的image. 目前 Neo 有以下的 image 可供選擇.

* Om2007.2: 由 Open Hand 主導的使用者介面設計 (work for Intel Moblin now) , 建立在 GTK 的基礎上, image 可以從以下網址找到:
Image: http://t0ny.net/openmoko/images/200804/

* Om2008.x : 這是目前 (2008 年) 還在維護的版本, 基本上是由 open source 版的 QT/X11 加上 raster 的 illum ETK. ETK 提供了自己的圖形介面 API, 還有自己的 python binding.
Image: http://t0ny.net/openmoko/images/200809/

* Android: 根據 Google釋出的原始碼, 由 Sean McNeil 維護的 Neo Android 版本, Beta 4 (RC1) / Cupcake 之前的版本在 FR 上需要一張額外的 uSD 記憶卡 (128 MB 以上).
說明: http://wiki.openmoko.org/wiki/Android
Image: http://t0ny.net/openmoko/images/android/

* QT extended: Trolltech(a Nokia company now)/Qtopia 維護的版本, 目前到 4.4.x
http://wiki.openmoko.org/wiki/Qtopia_/_Qt_Extended_on_FreeRunner

image: http://www.qtopia.net/modules/mydownloads/index.php

* Debian: Debian 社群開發並維護的版本.

http://wiki.debian.org/DebianOnFreeRunner

* FSO: Mickey 跟 2009 年 openmoko framework 可能方向, 基本上 FSO 是建立在 D-Bus 上的應用程式架構, 透過 python binding 的 toolkit (如 GTK/ETK) 來呈現使用者介面的畫面.
http://wiki.openmoko.org/wiki/OpenmokoFramework

* SHR 及 FDOM: 基本上是社群上的人自己維護的 image, SHR 主要重點在提供 illum/enlightment 標準介面/畫面以及 tangoGPS 程式. FDOM 目的是解決官方版釋出的 image 裡面的套件不足以供一般的開發需要. 同時省掉需要 opkg install/upgrade 的麻煩. 詳細差別可以參考以下網址:
http://wiki.openmoko.org/wiki/SHR

[SHR] http://shr.bearstech.com/

[FDOM] http://www.tuxbrain.com/fdom_en.html

[更新 FreeRunner image 的方法]

更新 FreeRunner 的 image 有兩種辦法:
<方法 1>
一個是透過 FreeRunner 上面的 USB, 透過 DFU (Device firmware update) 協定及 dfu-util 程式, 然後利用開機進到 kernel 前的 u-boot, 更新 image. 此外, 目前只有 linux 的電腦才能做 DFU update 的工作. 當然如果你用 vmware 之類的 emulator 上跑的 linux 也是可以的, 不過記得連接 FreeRunner 時的程式 focus (視窗) 要是 vmware 的 Linux 才行.

FreeRunner 的 DFU 是由 Werner 維護開發的, 相關的原始碼在 http://svn.openmoko.org/trunk/src/host/dfu-util/ . 更多的資料可以查
http://wiki.openmoko.org/wiki/Dfu-util.

<方法 2>
如果你有 micro SD card, 最快的方法是直接把 image copy 到 micro SD card, 然後從 micro SD card 執行 script. 你可以參考以下 script 來做更新 FreeRunner 裡面的 image.
http://t0ny.net/openmoko/samples/script/dl_finalimg

[更新 FreeRunner image 的步驟]

< Step 1>
從上面的連結中下載 dfu-util 的原始碼自行編譯或是 download 已編譯好的套件

< Step 2>
到 http://downloads.openmoko.org/releases/ 下載最新的 images, 或從前面的連結中, 找到相關的檔案, 下載到本機上.

< Step 3>
如果是啟動 NOR boot (先按 Aux 鍵, 再按開機紐), 開機畫面就會停住. 同時此時你可以透過 USB 將 FreeRunner 跟你的 Linux 連起來. 然後就可以用 sudo 或是 root 權限執行 dfu-util 進行升級的動作.

<Step 4>

* 更新 rootfs:
./dfu-util -a rootfs -R -D /path/to/openmoko-devel-image.jffs2
OR
./dfu-util -a 6 -R -D /path/to/openmoko-devel-image.jffs2

* 更新 kernel:
./ dfu-util -a kernel -R -D /path/to/uImage
OR
./ dfu-util -a 3 -R -D /path/to/uImage

* 更新 bootloader
./dfu-util -a u-boot -R -D /path/to/u-boot.bin
OR
./dfu-util -a 1 -R -D /path/to/u-boot.bin

* 更新開機 splash image
./dfu-util -a splash -R -D /path/to/splash.gz
OR
./dfu-util -a 4 -R -D /path/to/splash.gz

* 更新開機參數 (environment variable)
./dfu-util -a u-boot_env -R -D /path/to/env_new
OR
./dfu-util -a 2 -R -D /path/to/env_new

<Step 5>

記得檢查 DFU 的結束的訊息, 當進度條結束並不代表更新一定成功. 如果 DFU 一直中斷, 記得檢查 DFU 的參數是不是下錯, 或是 USB cable 是不是沒接好. 如果你是從一般 u-boot (不是從 NOR 的 u-boot) 更新, 可能更新 NAND 裡面的 u-boot 也是一個方法.

memorial

2008-11-14T04:24:00.001-08:00

2008 Nov 14, really a sad day. 2007 Nov 14, a happy day.

XTC HB3 2009

2008-10-29T20:55:00.000-07:00

Finally, after 5 weeks of waiting, get my second Giant last week.

全部相片請點這 All my XTC HB3 snapshot could click here :)

First ride to Taipei Tamshui is cool, with some Openmoko colleagues, and trip total about 50 Km. I forget bring the sunglass, a little dizzy during whole trip.

Unfortunately, the bike have few serious _dings_ during first ride. Anyway, I love this bike so far :)

光陽 Racing 的廣告

2008-10-22T22:00:00.001-07:00

難得最近看到一個覺得有打動自己某個部分的摩托車廣告, 女主角側面還蠻像 Yanzi 感覺. 不過看了一下她本人無名基本資料 http://www.wretch.cc/mypage/pig2003zoo 比 Yanzi 本人大隻一些 :) 看 blog 的 title: You are reading my shit. 態度十足, 能力就再看看囉

另外歌也還不錯聽, 跟廣告畫面一氣呵成, Sunshine state 的歌果然很有 sunshine 的感覺 http://www.sunshinestate.ca/ 聲音跟編制都很像 Frente 的風格, 蠻適合校園的青春大學生的 Tune.

A Good CF...

instant messaging

2008-08-04T00:30:00.001-07:00

I have 4 different messaging client installed (MSN/Skype/irc/jabber),
now I understand why some people need trillian as IM client. It so
strange even for the same function, still need so many clients and
protocols. It just a waste from dark side, maybe it also represent the
world diverse in the bright side.

ghost is everywhere, always

2008-07-31T03:04:00.001-07:00

Chinese ghost month will start from tomorrow for 1 lunar month. For Chinese, ghost only could legally out of hell into human world during ghost month. And ghost has another meaning for describe malicious/odd/smart people in Chinese. So, ghost is everywhere, always :D

Jack Black's Tenacious D in The Pick of Destiny

2008-07-28T00:05:00.001-07:00

I thought school rock could be end of jack black's rock BS :) but Tenacious D in The Pick of Destiny is more hilarious. Nowadays rock n' rolls become a joke even in serious duel with devil (well, at least crossroads has some serious fight, IMO). Maybe next time have some movie do JB vs. JB (Jack Black vs. Jack Butler).

Anyway, good job, jack.

Amazing Community

2008-07-26T09:43:00.001-07:00

Well, since I been accept the modernmusician music/theory discussion forum moderator few years ago, and now the openmoko project. I was so amazed community member's insight of on discussion topic. Some people just could see through things even more clearly than people actual working on things. Just very cool!

Mail and Post

2008-07-25T04:59:00.000-07:00

It's first time using mail posting function of blogspot. Posting through
e-mail have strange feel for me, maybe because of the interface remind me the daily work.

And I made a mistake at first post, wrong e-mail address... a usual
un-deliverable reason after several times of check on update.

重新開始

2008-07-19T07:55:00.000-07:00

這幾年在各個地方 post 了一堆東西, 但是卻沒有一個集中的地方放這些東西. 想一想還是就放在一開始接觸 blog 的 blogspot 吧.

從脫離學校以來, 一路走來奇奇怪怪. 呵, 從好處想是各式各樣的生活都體驗過了, 應該可以寫一個有趣的 blog.