網路黑貓 BlackCat dot Net

Xubuntu on EeePC 701 4G

2012-01-18T19:45:00.000-08:00

雖然個人有多台機子, 但很少帶來帶去
幾乎是在每個會停留的地方都有台電腦可以使用
在桃園家中, 用的是 2007年推出的 EeePC 701 4G
平日最多的用途就是 Web + Music

以僅有的 4G 容量來說, 對現今系統來說都顯得捉襟見肘
而 Ubuntu 現今預設也都需要 4.x G 才能夠安裝

這篇算是留個紀錄, 最終調整好的結果:
champ@champ-eee701:~$ df
檔案系統 1K-區段已用可用已用% 掛載點
/dev/sda1 3783213 1685305 1902584 47% /

使用約 1.6G (而WinXP SP3 版, 裝完就使用了 3.xGB(80%~83%) 左右)

在這之前, 做了小小的前置作業
為了不額外安裝控制軟體
安裝前將BIOS 升級為能夠選擇 CPU 速度的 0511 測試版本

安裝採用的方式是製作Xubuntu Deskop ISO 製作開機 SD Card
開機不選擇直接安裝, 而是進入 Live環境
進入桌面後編輯 /usr/lib/ubiquity/plugins/ubi-prepare.py
搜尋 min_disk_size = size * 2 一行, 並將" * 2 "移除
如此最低要求就會是 2.1GB

接著安裝與後置步驟所參考的是
https://wiki.ubuntu.com/ReducingDiskFootprint
使用Live 環境terminal, 自行先以 mkfs.ext4 -T small /dev/sda1 格式化作為 / 的 partition
之後安裝過程中選用為 / , 並且不再格式化
光這個步驟, 就會將使用的空間自原本的 65% 降到 59%

以這樣的方式安裝完後, 接著移除不需要的 package
大致上移除了與下列相關的套件
gimp, thunderbird, transmission, gnome-games, linux-headers, gcc, xorg drivers, bluetooth, cups, sane, abiword, gnumeric, nvidia-common, manpages-dev
套件部份, 熟悉套件內容的可以再自行斟酌
移除不需要的package後, 先 apt-get clean
再請參考ReducingFootPrint 的 disable apt cache 之後再進行系統更新

接著可以參考
上述的ReducingFootPrint 的 document/locale 部份

最後如果沒有在使用 synaptic, 單純用 apt-get 可以再參考 Compress File 部份
對 apt 的 index 做壓縮 (否則 synaptic 會很慢)

剩下的 5x% 空間可以有相當的使用彈性
安裝喜歡的軟體, 放資料與音樂...etc

原本有意使用 btrfs 搭配 compress option
然而 btrfs 的 metadata 以佔去相當容量, 已經佔不了便宜
加上ubuntu 這幾版使用 btrfs w/ compress 似乎都有問題
而且在 SSD 上沒有節省到時間外, 反而更慢

Linux Undervolting - Toshiba NB550D

2011-07-20T22:31:00.000-07:00

再調整過 MSI X410 後, 不再那麼燙手了
(最後還將最高頻率設為 1.3Ghz)
就能享受其帶來的輕薄大螢幕的好處.

於是又看看另一台 Toshiba NB550D有無機會
如之前所說, 這台使用的是 AMD APU C-50
透過搜尋, 找到了一篇文章講述詳細內容的
要降低電壓, 主要是調整 msr 中對應 VID 的數值
按照文章說得, Acer W500 使用電壓組合為
1.0625V/1Ghz, 0.9375V/800Mhz

按文查表, 發現, NB550D 使用的電壓組合為
1.2250V/1Ghz, 1.025V/800Mhz

找到方法了, 接著就是測試, 並且寫入 /etc/rc.local 中
以下為我加入的內容
主要是改為0.9375V/1Ghz, 0.8250V/800Mhz
按照文章說明, 這樣應該可以降低功耗 2~3Watt
找機會來測試電池使用時間是否增加.

#to allow msr manipulation
modprobe msr

#here we undervolting C50 to 0.9375V/1000Mhz 0.8250V/800Mhz
#original is VID:34 - 1.225V/1000Mhz, VID:54 - 1.025V/800Mhz
#CPU 0
wrmsr -p 0 0xc0010064 0x800002ba00006230
wrmsr -p 0 0xc0010065 0x8000026a00007440

#CPU 1
wrmsr -p 1 0xc0010064 0x800002ba00006230
wrmsr -p 1 0xc0010065 0x8000026a00007440

相關資訊在該文章都有, 有需要可以參考

Linux PHC Undervolting - MSI X410

2011-07-13T22:32:00.000-07:00

老婆偶爾玩 Facebook 的 flash game, 閒買給她的 X410 慢
於是好一陣子之前, 拿先前的 MSI CX420 跟老婆換
(這麼說我還蠻愛 MSI 筆電的, MSI 是否該找我寫測試文...XD)

X410當時也是我決定買的, 主要看上輕薄又有 14" 大螢幕
安裝Ubuntu 使用一陣子後, 發現CPU效能對我倒是其次
總是最大轉速的風扇聲, 與左手腕放置地方過熱

搜尋了一下, Windows 上有人使用 RM CPU Clock Utility 來降壓
除了降低CPU電壓, 另外還可以使用額外的 P-state
而在Linux 上要靠 Linux PHC kernel, 達到相同的效果

MSI X410 使用的是 AMD Neo MV-40
基本上預設電壓 1.0V
也只提供 800Mhz 與 1.6Ghz 兩種頻率切換

有了這些資訊, 就開始使用 Linux PHC 來降壓
首先可以透過下列指令加入 Linux PHC PPA

sudo add-apt-repository ppa:linux-phc/ppa

接著更新套件庫與安裝 Linux PHC kernel
sudo apt-get update

sudo apt-get install linux-generic-pae-phc linux-headers-generic-pae-phc linux-image-generic-pae-phc

如果不需要原本 kernel 可以順便移除..
安裝完成後, grub 選擇 phc 的項目重開即可

登入後, 接著要安裝 phc-k8 module
請到此下載

安裝phc-k8前請安裝 dkms
sudo apt-get install dkms

接著以 root 做下列動作
1. cp phc-k8_v0.4.4b1.tar.gz /roo
2. cd /root
3. tar jxvf phc-k8_v0.4.4b1.tar.gz
4. cd phc-k8_v0.4.4b1
5. make dkms install

到這如沒出現錯誤訊息 phc-k8 安裝就完成了
重新開機讓系統載入 phc-k8 module

要測試是否 OK 可以用下列指令
cat /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
這時候你應該會看到下列資訊
8:22 0:22

這是 FID:VID 的組合, 按照說明文件
FID 的意義是 Freq = 800Mhz + (FID*100Mhz)
以筆電預設電壓 1.0V 去看
VID 的意義似乎是 Volt = 1550mv - VID*25mv

為了能夠切換更多的頻率
編譯 /etc/modprobe.d/phc-k8.conf
將 options phc-k8 direct_transitions=1 行前的 # 移除

接著在 /etc/rc.local 加入一行
echo "8:26 4:31 0:35" > /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
即可
(這裡上述的 26,31,35 是保守值, 可以自行將上述指令調整輸入, 找出最適合的數值)

重新開機後就可以感受不同了...

可以重開機後交換輸入下列指令, 去體會風扇的變化
echo "8:22 4:32 0:22" > /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
echo "8:26 4:31 0:35" > /sys/devices/system/cpu/cpu0/cpufreq/phc_controls

Update:
最近看這篇, 發現, X410 其中用了散熱'墊', 其實散熱效果很不好, 於是也塗了之前存放的散熱膏, 效果的確不錯. 廢熱明顯不容易累積, 搭配上面的方法, 就不再燙手了.

LibreOffice 3.3 released

2011-01-30T19:15:00.000-08:00

由於 Oracle 併購 Sun 公司後, 對於 Open Source 專案有著不友善的態度與作法
OpenOffice 成員與社群於是創立了 The Document Foundation (TDF)
而其 Office Suite 命名為 LibreOffice
LibreOffice 的理念也受到 Ubuntu, Fedora, OpenSuse, Go-OO, Google 等社群/公司的支持
相信在 Linux 套件的大宗上, LibreOffice 將會是主流

在TDF經過一段時間的運作, 正式釋出了第一個版本 - LibreOffice 3.3
從網頁上可以看到新的功能特性 (OpenOffice 3.3 新特性在此)

Ubuntu 上可以透過官方 ppa 的方式安裝
支援 Lucid/Maverick/Natty

安裝方式如下:
sudo add-apt-repository ppa:libreoffice/ppa
sudo apt-get update
sudo apt-get install libreoffice

安裝過程會自動將 OpenOffice 移除
個人有安裝 libreoffice-pdfimport, 如此能針對 PDF 檔案做編修

LibreOffice 編修 PDF 檔案

基本使用上與 OpenOffice 大同小異
而使用上可以感受到 LibreOffice 的啟動與反應速度加快了些
如果是一路從LibreOffice開發時期版本用到現在, 應該可以感到其進展

相信 LibreOffice 的出現, 也能帶給 FOSS 的 Office Suite 更好的生態

理想的 Linux Netbook - Toshiba NB550D

2011-01-26T19:25:00.000-08:00

使用 Asus EeePC 900 邁入了第三個年頭
除了當時就略顯過時的 Intel Celeron M ULV 353
另外感到最不滿意的即為 Intel GMA 9x0 IGP
而當時俱備相當顯示能力的機種, 多半體積大&過重/過熱/價格過高 (ex:Asus N10J)

個人理想 Netbook 的條件為:
1. Dual-Core
2. 支援OpenGL 3.2以上版本
3. 支援OpenCL 1.x
5. 電力連續使用 5 小時以上

於是在 AMD APU規格公開後, 相當吸引個人
近日AMD 發售 APU 後, 各大廠也紛紛宣佈使用 APU 的機種
在台灣, Toshiba NB550D 算是其中最早發售的

原本還想觀望 Asus 1015B (使用較高一階的AMD E-350, 但是怕跟1015N一樣遙遙無期)
然而逛店家時發現, NB550D 的喇叭效果令人驚豔
經詢價後也感到不錯 (13.1K), 於是就入手了

TOSHIBA NB550D :
Processor: AMD C-50
RAM: 1GB DDR3
Graphics: AMD Radeon HD 6250
WIFI: Atheros AR9285 PCI-Express
Ethernet: Realtek RTL8101E/RTL8102E
WebCam/SD: Realtek USB device (WebCam: 0bda:5801, SD: 0bda:0138)

在安裝Ubuntu時原以為會奮戰許久,
然而在 LiveCD下使用時,
Hotkey, WebCam, Wifi 到 SD slot 無須特別處理, 就可以正常運作
另外發現APU除了省電外, 溫度上也相當低,
比起用過的 Atom/Celeron Netbook 都低許多

另外剛入手時, 一開始最為惱人的是Ubuntu 安裝 fglrx 後,
右下角會有 "Unsupported hardware" 浮水印
安裝今日 AMD 釋出 11.1 版 driver 後, 就無此問題了
(網路上有個能去除的 script,
但是我試用發現僅對手動安裝的AMD driver有效,
如果是透過apt 安裝的版本並無效果)

如果有類似考量者, 建議可以考慮 NB550D

AMD Phenom X4 9450e vs Core i5 430M

2010-11-12T04:17:00.000-08:00

這樣比較, 是蠻怪的
主要是因為近日升級了原有桌機 Acer Aspire X3200
自 Athlon 64 X2 4400+ 換成 Phenom X4 9450e
(礙於X3200 僅有 220W的電源, 搭配 ATI 5570 1GB 顯卡)
而目前在用的 Notebook 用的是MSI CX420其CPU為Core i5 430M

沒有做甚麼各項評比,無論NB/Desktop換硬體都是希望編譯時間短些

兩者都以 make -j8 方式去編譯同一份 Android code
Phemon X4 9450e: 44 mins
Core i5 430M: 50mins

參照PassMark 的評比分數
Phenom X4 9450e: 2663
Core i5 430M: 2361

換算下來的確 2663x44(117172) 約略等同 2361x50(118050)
看來PassMark還蠻值得參考的

Clang 成功編譯能運作的 Linux kernel 2.6.36

2010-10-27T22:14:00.000-07:00

Linux 2.6.36 在上週釋出了
關心進展的可以追 KernelNewbie 和 The H Open Source

著名的 LLVM 的 C frontend - Clang
繼去年宣佈能成功編譯 FreeBSD kernel 之後
LWN 上得知, 現在已經能夠編譯能運作的 Linux 2.6.36 Kernel

相信不久之後, 除了GCC 外編譯 Linux 就有 Clang 這個新選擇

急起直追的 Firefox 4

2010-10-20T22:37:00.000-07:00

跨入十月之後, Firefox帶來了值得高興的消息
從持續紀錄 Firefox 最新 JavaScript 效能的arewefastyet網站上

Firefox 在自己的 sunspider 與 Google 的 v8bench 兩項效能評估指標
都有超越 Apple Nitro 的成績

上圖為 6月時 Firefox對比於 Apple Nitro/Google V8 優勢的窘境

隨著網頁技術的演進, 瀏覽器的角色日益重要
新興瀏覽器(Chrome, Opera, IE9)皆有著不錯的技術背景
Firefox 新的競爭者重心由以往的 IE6/7 轉向了這些新挑戰者

回顧在6月時, chrome v8/apple nitro 對於firefox 還是如此的遙不可及
在Chrome的蠶食逼近, IE9 的改頭換面下
甚至有要Mozilla放棄自有的 Gecko 投入 Webkit 的言論出現

在Chrome V8點燃的瀏覽器 JavaScript 效能競爭
並隨著之後HTML5取代Flash 以及 GPU在網頁瀏覽的應用等話題
新的瀏覽器戰爭已經揭開了序幕

在以 Firefox 揭開瀏覽器革命時代之後
Mozilla再次用行動向大眾證明了維護 Firefox/Gecko 技術平台的信念

續 Xubuntu On MSI CX420 - RT3070 dkms support

2010-10-20T18:53:00.000-07:00

昨日更新系統到 Xubuntu 10.10

由於kernel版本更新, 一再重複安裝 rt3070 驅動程式, 也是相當煩瑣
想要讓它像目前使用的 fglrx 一樣透過dkms 更新

其實一方面也是因為沒嘗試過dkms
於是參考了RT3090的範例, 昨晚花了點時將 rt3070 driver 打包為 dkms 形式

由於kernel 2.6.35改動了一些usb function的名稱, 所以ubuntu 10.04 與 10.10 稍有不同
(其實正確來說是 kernel <= 2.6.34 用 10.04, kernel >= 2.6.35 用10.10)
有需要者請自行取用: 10.04版 10.10版

後註: 其實 RALINK 官網上有對應新版的 RT3370 驅動程式, 然而 dmesg 看來雖然有驅動, 但卻無法正常運作, 所以這裡使用的是次新的版本, 有時間再來看新版的問題

Meego on OpenSuse - Smeegol

2010-10-09T05:14:00.000-07:00

上圖為在 EeePC 701 上安裝後調整的效果
(Wifi icon旁原有bluetooth的icon, eeepc沒有就移除掉了)

OpenSuse 近日發布了 Meego 的新聞
該計畫有個有趣的名字 - Smeegol (Suse Meego Linux, 諧音於Lord of Ring中的角色),
LiveCD 的下載位址在此
使用 LiveCD 開機後選取 Yast->Live Installer 就可以安裝好

由於這個Smeegol計畫, 所以初嘗Suse的系統
老實說支援很不錯, zypper也很好用
安裝在 EeePC 701 上, 效果算很不錯 (讓我的EPC 701 有復活的fu)
Meego社交網站整合已經有很多平台了
包含 flickr, facebook, twitter, last.fm, MySpace, digg 等

由於政治因素, 很可惜 Meego 官方比較親近 rpm 體系
所以目前 Debian/Ubuntu 沒有正式支援 Meego
(是有人嘗試編譯 Meego UX 安裝在 Debian 上, 並且有所成果)
雖然Canonical很用心的建構 Ubuntu Netbook Unity
但單以User Experience來看, 個人比較看好 Meego

續 Xubuntu On MSI CX420

2010-09-22T09:44:00.000-07:00

由於有人向我詢問CX420 WIFI on Ubuntu 的驅動方式

近日我針對ubuntu 10.04打包了最新版本的driver
有需要者可以下載 i386版與 amd64版
有人回報結果是可以正常驅動的

下載測試者, 煩請留言告知版本與狀況

Blogger 的另類用途

2010-09-02T17:50:00.000-07:00

在碩士時期, 曾因為lab計劃認識一個很不錯的朋友
當時就曾聽他說打算要出國留學的事情

後來隨著lab計劃的告一段落, 加上之後各奔東西
雖曾斷續地聽到它的消息, 但也就因此失了聯絡

昨日驚喜地收到他寄來的 Email
即將要取得學位了,我在這裡也再次恭喜他

只是我沒想過 blogger 還有這點功用 ^^

HiRadioTray 20100826 release

2010-08-26T20:52:00.000-07:00

近日 Ubuntu 10.04 的軟體更新, 更新內容包含了 wxwidget library
因此造成了 HiRadioTray 的問題

已經重新打包放在專案下載頁面
需要者請自行下載更新

Linux Kernel 2.6.35

2010-08-18T08:44:00.000-07:00

基本上這是舊聞了
Linux Kernel 2.6.35 於 Aug. 1st. 2010 釋出
按慣例, 相關的更動細節可以至 KernelNewbies 看
The H Open 也有篇詳細的 What's New in Linux 2.6.35

簡單說這版的改進主要在於網路效能與功能上的增進

像是能更有效的分散網路流量的loading 到 CPUs 上, 相信這對 server 效能有一定的增進
在者就是支援多個 Multicast(群播) 的 routing table

相信許多人會感到興趣的 i915 對於 VC1, H.264 的硬體加速支援
改善了對於AMD ATI Radeon的支援(主要是系統上的, 像是reset與降低功耗, 而非效能上)

另外檔案系統上改善了 Btrfs/XFS

最後引人注目的核心改進功能是 Memory Compaction
Memory Compaction 對於實體記憶體管理有相當的影響
其功能主要在減少 memory 中的 fragmentation (斷離)
並且增加實體上連續的free pages供核心系統與驅動程式應用

簡短的列舉到此,有興趣的趕快去挖寶吧~

Emerald 佈景 - Moka.改

2010-08-18T03:54:00.000-07:00

自從為了簡潔因素而改用 Xubuntu 後
即無法繼續在EeePC 701/900上使用GNOME上慣用的Almond Mini metacity佈景
(主要還是因為其Window Decoration 佔用空間小)
為了享受Desktop的硬體加速, 個人習慣使用 Compiz (scrollbar 比較順...)
而xfwm無法在compiz下使用, 而必須以 Emerald 取代
原本用的是仿 Xubuntu 下預設的 Albatross 佈景
無奈於視覺上感覺佔用了太多空間

搜尋了一下 Emerald 佈景, 發現可以接受的 Moka 佈景
按鈕圖案上, 個人偏愛Shiki Minimal Match所使用的風格
(Shiki Minimal主要在於視窗沒有文字標題)
於是花了點時間做圖案的剪裁與替換
修改inactive window 的標題文字顯示(看設定是有顯示, 但是根本看不出來)
並且減少了Window Border(3->2)
效果上比原有 Moka 來得令我滿意
有興趣者可以到此下載

續 Firefox on Netbook

2010-08-15T08:32:00.000-07:00

在女兒開始會爬之後, 就需要有人隨時在側的陪伴
原本用來利用來做監視系統的EeePC 701也就又成為我的床頭機

在長時間不常使用 800x480 解析度後, 對於垂直解析度的浪費變得更無法容忍
對於這樣的topic原本寫了篇Firefox on Netbook

經過如此調整後 titlebar 還是覺得太粗了
於是又加入 Compact Classic 與 Compact Classic Options
最後就是把系統的 task panel 改為直式

這麼一來就從畫面上榨出最後的垂直顯示空間
使用 FireBBS 甚至還可以將字型大小設到 18, 還算堪用

HiRadioTray 20100809 release

2010-08-09T06:16:00.000-07:00

對於 HiRadioTray 的維護是對於使用者比較抱歉的地方
並沒有投入相當的時間在維護與更新上
今日將 script 更新並且針對ubuntu 10.04 i386/amd64 編譯並提供兩個版本

有需要者請到下載頁面下載

新的 script 使用更新功能也可以下載

Office 軟體的新選擇 - IBM Lotus Symphony 3

2010-07-22T07:05:00.000-07:00

Linux 桌面使用者對於 OpenOffice 都不陌生
OpenOffice 的確也逐漸成熟了, 儘管功能性上已經很充足
然而在易用與便利性上的確還有許多改善空間

近日安裝 Xubuntu 想安裝 OpenOffice 時忽然想起沈寂已久的 Lotus Symphony
IBM 在三年前推出 OpenOffice 1.x 為基礎的 Lotus Symphony 1.x 後
很可惜的是當年OpenOffice 以進展至 2.x 相容性與速度上都領先不少

跑去IBM Lotus Symphony官網看了之後, 大為驚人
Lotus Symphony 竟然悄悄推出 Symphony 3 beta 而且已經進展到 beta 3
官方的說明是 Lotus Symphony 是建構在 OpenOffice 3 上
搜尋了一下, 繁中網頁竟然少有資訊, 也沒有任何介紹(或許得拜台灣教育與盜版成功吧..)
除了有 Ubuntu 版本外還有 Windows, Mac OS X 與 RedHat 版本, 下載安裝後, 除了一開始一堆問號似乎是 License 的資訊

下圖為啟動程式後, 映入眼中的第一個畫面, 安裝後語言套件後即有中文

網路上隨便找個 DOC 檔來開看看, 介面的配置看來很適合寬螢幕
UI 的配色與格式看來有再設計過, 1.x 版的顯得比較擁擠

再開個 XLS 檔來看看, 這時有特別的感覺了, 維持了一貫的分頁設計
但是 Lotus Symphony 3 有做小 icon 的區別, 1.x 都是 Symphony icon

接著開個 ODP 簡報檔, 在製作時, 我覺得頗為 Smart, 當你做不同屬性的編輯時
右側的頁面會自動切換於不同個功能頁面, 下圖為開啟預設介面

選取方塊物件, 右方立刻可以編輯顏色, 外框等資訊

選擇編輯文字方塊, 旁邊便是字型選擇, 大小, 顏色
甚至是行距的調整

試用幾天後, 個人覺得雖然記憶體消耗較高些
然而 Lotus Symphony 3 的便利性相當令人滿意
如果看膩了 OOo 較為單調的介面, 不妨試試看新的 Lotus Symphony 3

淺談 OpenCore execution model

2010-07-21T07:17:00.000-07:00

由於新工作與 OpenCore 有關, 前輩考量到未來對效能調整, 希望我能了解 OpenCore 架構
為此而稍微細看OpenCore, 感到非常"新奇", "有趣"

在此先不細談 OpenCore 整體 Object Model, 而這部份網路上的談論也不少
大致上即是分為 Engine - PVMF Node - Component 三層

這裡談 OpenCore 中的執行運作模式
或許是OpenCore 受到 Symbian Active Object Framework 諸多影響(文件上也有諸多Symbian字眼)
基本上, 對於Symbian 個人認知不深
然而對於OpenCore這樣注重 realtime 特性的 Multimedia Framework 採用這樣的方式感到"新奇"

上圖為運作的圖解
OpenCore 內基本執行單位為 PVActiveBase
而衍生出的 class 為 OsclActiveObject(AO) 與 OsclTimerObject(TO)
實作中需要被執行的元件繼承 AO or TO
而每個繼承AO/TO的類別需要個別實作其要不斷被執行的 Run() 介面

OpenCore 執行模式為 single thread
在 OsclScheduler::BlockLoopL() 這個無線迴圈當中
透過 WaitForActiveObject() 來取得下一個需要被執行的AO/TO
接著呼叫 CallRunExec() 來執行 AO/TO 的 Run()

對於規劃中需要被執行的AO/TO物件
只要沒腦地執行 PVActiveBase::AddToScheduler() 即可
接著便會依序被執行該AO/TO所實作的 Run()

看似簡單的行為, 然而直覺操作上卻讓人毫無頭緒
是的, 介面上無需透過具體的 scheduler instance, 從何來, 哪裡去就像黑盒子般
這點一時間讓我有點難以接受
細看實作上透過 macro 的方式取得 current thread 的 scheduler
只能說如此的 execution model 機制顯得不太clean
這樣的 model 基本上如果是為了 single thread/co-operative multitasking 的考量
也算說得過去, 只能說真的不是很優雅與直覺

再來, 其中最有趣的一點便在於 OsclTimer 與 PVMFMediaClock 這兩個 timer 類別
實作中AO/TO通常向此兩者註冊callback function 希望通知特定 time event 的發生
OsclTimer (oscl/oscl/osclproc/src/oscl_timer.h) 仰賴著 CallbackTimer
CallbackTimer 繼承自 "OsclTimerObject" ~ Wow~
看看 PVMFMediaClock (pvmi/pvmf/include/pvmf_media_clock.h)
一堆繼承物件中, 第一個物件即為 "OsclTimerObject"
而兩者的 Constructor 都呼叫了 AddToScheduler()
其時間的資訊是去 polling 系統的 OsclTickCount 得知

這麼看來 Timer 這點可"有趣"了, Timer 的運作與通知機制也仰賴著這個 BlockLoopL
而如果某一 AO/TO Run() 稍微久一點, Timer Event 可能就失真不少

ex:
試想, 假若一個 decoder 具有硬體加速, 然而 interrupt 有問題
因此採用 polling 方式以得知硬體狀態
component 中期望 timer 能夠每 10 ms 通知一次,
方便於 check 硬體狀態來決定是否要命令硬體 decode 下一張 frame
而在此同時 audio decoder 為軟體實作, 每解一個單位需要 30ms
這麼一來 ......

是的, 如果要遷就這樣的 model, 每個 component 實作上必須特別考量到 timing
而軟體實作上可能必須是 progressive 的方式, 不要一次將全部結果解出, 減少 Run() 單一執行時間長度
以這樣的方式, 來換得 timing 的精確度

如果是為了遷就不用 thread 而使用這樣的 timer 實作呢?
那 Audio 處理與 proxy interface 中就不該大剌剌地使用 OsclThread

anyway, 很高興在 trace 期間自 jserv 那聽到 2.2 已是預設的 StageFright
雖然目前實作不若 OpenCore 完整, 然而看來就個人的理解是"正常"多了 ...

20100727 後記: 應該好好說明一下 proxy interface, 其實本文中舉的例子並不一定會出現, 這裡用這樣的例子來解釋這樣的方式的問題, 文中例子的發生與否取決於是否使用proxy interface(是的, 這是compile option, 而且意義並非網路proxy), 在OpenCORE 中 codec 以 openmax 封裝為 omx_xxx_component, 若透過 proxy interface 即 create 了各 codec 的 thread. 儘管 OpenCORE 中透過使用proxy interface如此與設計不同的方式來避開 codec 的時間問題, timer 依舊容易受到 system I/O 與 parser 之類的影響.

Xubuntu On MSI CX420

2010-07-20T06:12:00.000-07:00

近日由於工作需要編譯 Android 環境, 原有的配有 Sempron Mobile 3800+ 筆電不敷使用
到了附近的賣場看了後, 決定了購入新的筆電 - MSI CX420
所俱備的性能與價格搭配看來是具有相當高性價比的機子

當然, 拿到手第一件事當然是想辦法安裝 Linux 環境
安裝本身並不是難事, 問題發生在安裝完成後

1. 安裝 ATI 驅動程式, 無論透過 Ubuntu 的啟動ATI專有驅動程式, 或是手動安裝ATI Driver, 安裝後重新開機都會是黑螢幕(Yap, 為此我重裝一次....).
這部份的線索是從 MSI CX420 驅動程式頁上對於 XP 需要設定 Primary Display為 PEG
是的 Linux 同 XP 不支援 SG(Switchable Graphics) 特性
需要刷新 BIOS 版本, 將 Primary Display 設為 PEG(PCI-Express Graphics)
刷新後, 原本黑濛濛的畫面就變得非常亮眼~ (無需重裝Linux, 刷新後就正常了)

2. Ralink 1T1R 802.11bgn 無線網路裝置無法驅動
從 Windows 上可以看到為 USB 裝置, 也可以看到所在的 Port & Hub 位置
於 Linux 上 lsusb 可以得到下列訊息:
Bus 002 Device 002: ID 8087:0020
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0db0:3870 Micro Star International
Bus 001 Device 002: ID 8087:0020
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

喔!? 竟然顯示微星 (lsusb -v 的 verbose mode 也只能看出是 Ralink裝置, 就省略了)
搜尋 device id 0db0:3870 可以看到 rt2800 的訊息
加上看到MSI官網上的驅動程式, 解開後閱讀 inf, 標明為 rt2870, 第一時間我就以為是Ralink RT2870
跑到 Ralink 的Linux驅動程式頁面下載RT2870USB 驅動程式
還自作聰明地將device id 加入來偵測, 結果是裝置驅動了, 然而無法scan ap 與連線
不能 work 的 driver 等於沒有, 於是回到了原點

接著想找社群的 open source 方案
由於 google 0DB0 3870第一時間會看到這個頁面
這表示 rt2800usb 還是與 CX420 上的裝置有關
從頁面聯結的 rt2800usb.c 原始碼可以看到裝置歸類於 RT2800USB_UNKNOWN
然而這檔案看來也不是最新的, 當然立刻看 git.kernel.org 上最新的 rt2800usb.c
ok, 這裝置在 rt2800usb driver 中被歸類為 RT2800USB_RT30XX
於是, 這時恍然大悟, 被搞錯的型號也呼之欲出
0x0db0:0x3870 的 Ralink USB 裝置應該為 RT3070
重新去網頁下載RT3070USB驅動程式, WIFI 速度非常!

到此終於解決了 Video 與 Wifi 兩大問題.
WebCam 後來測試是ok的, bluetooth 我沒在用也就無從測起了..^^

無意取悅小螢幕裝置的 Ubuntu Unity 介面

2010-07-10T22:01:00.000-07:00

近日注意到Ubuntu 新的Distribution - Ubuntu Light
其 UI 系統稱之為 Unity

由於是屬於 Ubuntu Netbook Edition 的系列 UI
於是就裝到 EeePC 701 上測試
對於視覺呈現上並不滿意

常用的 Web Browsing 應用即能顯示出 Unity 在 800x480 解析度上的不便
首先, 螢幕上方的 toolbar 並無任何設定選項
由於高度不夠, gcin icon 就被截去了一段
側邊的 toolbar 很華麗, 整合了快速啟動與程式切換的功能
於是, 高度就在上方的 toolbar 與視窗 titlebar 雙重的浪費下, 垂直顯示範圍縮小不少
不若原有UI 在使用顯示面積上來得有效率

當然, 現今Netbook 提升至 10" 以上, 解析度上也高了一到兩階
誰還在乎EeePC 701的 800x480?
但是手持裝置的 MID(ex: SmartQ5/Q7), 中小型Tablet 這樣的解析度也是常有

然而以定位看來 Unity 目標與適用範圍在於解析度夠高的 Netbook 與 iPad 等級的 Tablet
這樣的結果看來也是無可厚非

VP8 spec study - Chapter 4 壓縮資料格式概論

2010-06-15T04:25:00.000-07:00

每個frame的 bitstream 包含了3個以上的部份. 開頭為未壓縮資料, 在 intra frame 為 10 bytes, inter frame 為 3 bytes. 緊接著的是2個或以上的段落(被稱為 partition), 每個 partition 皆為 byte alignment.

第一個 partition 包含兩個段落
1. 套用於整個 frame 的 header 資訊
2. per-macroblock 資訊, 指定讓 decoder 推測 macroblock 內容的 prediction mode.
macroblock 資訊以 raster-scan 方式存放.

剩餘的 partition 包含了每個 macroblock 用以計算 residue signal 的 DCT/WHT 參數(coefficient). 這部份大約佔用 70% 的資料量. VP8 支援將序列的 macroblock 壓縮後之 DCT/WHT 參數, pack 為分開的數個 partition. 若有不只一個 partition 用以存放這些 DCT/WHT 參數, 除了最後一個 partition 之外, 每個 partition 的位元長度, 以 little endian/3bytes 格式存放於每個 partition 的開頭. 長度欄位使得 decoder 能夠一次存取數個 partition, 平行處理這些參數.

將 predicton data 與 coefficient data 分開於不同的partiton存放, 允許 decoder 的實作更有彈性. 實作可能先存放 frame prediction 資料, 之後再計算 frame 的 residue signal. 也有可能同時處理兩個 partition 資料以 macroblock 為單位計算 prediciton 與 residue signal.

不同的 partition 必須以分開的 entropy decoder 解壓縮. 而 in-partition 的搜尋並不被支援.

Google 公開 On2 VP8 Tech.

2010-05-20T00:30:00.000-07:00

Google 又丟了一顆震憾彈, 在今日成立 WebM 計劃
該計劃以 BSD-License, royalty-free 方式公開釋出 VP8 格式標準與相關程式碼
並同時地在 Youtube HTML5 beta 支援中加入了 VP8 支援

儘管在Google 收購 On2 之後, 公開 VP8 的傳言就沒有斷過
但看到相關新聞的第一時間, 想法還只是圍繞在 VP8 規格
之後細看與思考後, 才體會到這樣作法的背後可能有著多強的效應

在視訊瀏覽服務以成為主流服務的今日
這些服務以往多半只仰賴著 Adobe Flash 技術
對於 Adobe 而言, Flash 平台可以說是金雞母, 對於 PC 有著極高的安裝率
因此也理所當然成為網頁動態/互動效果與多媒體服務的一時之選

然而對一些人對於Flash感到頭疼
像是問題早已存在於既有的智慧型手機使用者
因此手持裝置與非 x86 平台裝置開發商也對此感到感冒
著名的有如: 蘋果的 Jobs 因為不支援 Flash 問題而動怒,
ARM 也因為 Flash 延誤 Smartbook 市場策略而公開斥責
意會到手機使用者的潛在市場的網站, 也增加了HTML5 的支援 (scribd, youtube...)

這些林林總總與瀏覽器戰爭所帶來的教訓
人們都意識到與其寄望單一廠商的開放, 不如訴諸公開標準
在 Apple Inc. 提到 HTML5 後, 除了知名度大升之外, 的確也被人們寄予厚望.

然而HTML5只是格式, 對於多媒體支援並無侷限.
頓時瀏覽器都必須選邊站, 於是就成了經濟實力的角力
有錢人組的 Google, Microsoft, Apple 對於旗下瀏覽器HTML5 選擇支援 H.264
支援公開標準組的 Mozilla, Opera, ... etc 選擇支援 Theora(事實上這是On2 的VP3技術)
(這麼說是很簡化的說法, Google Chrome 也有支援 Theora)

一時間, HTML5 的視訊支援的選擇陷入了分歧, 且少有交集
H.264除了商業瀏覽器的採用外, 加上最大線上視訊服務 Youtube 採用
可以說 H.264 在 HTML5 的視訊服務採用上佔有極大優勢

或許 Google 意會到這與其網路服務業務有極大關係
選擇在這樣的方式提供了兩個陣營都可以接受的方案(微軟第一時間也決定 IE9 將支援 VP8)
同時地, Youtube HTML5 beta 服務也加入了 WebM(VP8) 的支援
也因此 VP8 非常有可能成為 HTML5 中最被廣泛採用的視訊格式.

儘管現在 Flash 依然在 Web 佔有相當重要的地位
然而在 Adobe 開放不足, 加上缺乏善意的情況下
當大眾有共識地要擺脫 Flash 的當下, Adobe 或許該好好反省
不然 Flash 很有可能要面臨成為另一個 Java 的窘境.

Linux kernel 2.6.34

2010-05-18T06:41:00.000-07:00

Linux kernel 2.6.34 日前釋出了, 在 OSNews 與 slashdot 上已看得到相關新聞訊息
概略的 kernel change log 可以參考 KernelNewbies

除此之外, 推荐 The H Open 的在釋出之前就針對 Linux kernel 2.6.34 系列介紹文章
Kernel Log: Coming in 2.6.34 (Part 1) - Network Support
Kernel Log: Coming in 2.6.34 (Part 2) - File Systems
Kernel Log: Coming in 2.6.34 (Part 3) - Graphics
Kernel Log: Coming in 2.6.34 (Part 4) - Architecture and Virtualisation
Kernel Log: Coming in 2.6.34 (Part 5) - Drivers

若是覺得把"落落長"的五篇看完太耗費精神,
還可以看The H Open在釋出後的概略介紹文 - What's new in Linux 2.6.34

個人覺得 slashdot 上第一則 comment 真的蠻無厘頭搞笑的..XD

VIA ARTiGO A1100 released

2010-04-21T23:27:00.000-07:00

在facebook上注意到威盛電子(VIA) 本週釋出了新款 PicoITX-based 產品 ARTiGO A1100
與上一代產品 ARTiGO A1000 最大的不同點在於:
使用了新一代的 Via Nano 與 VX855 取代了原有的 Via C7 與 VX700

除了 Nano 所帶來的效能增進外
由於VX855的關係, 視訊播放的硬體支援除了提升到1080p外
格式上亦新增了H.264 (具有 CABAD, 看來應該到Main Profile)
此外 ARTiGO A1100還具備了 HDMI 界面
VIA 目的應該是想藉由強大的多媒體處理能力來吸引市場注目.
(而這也是採用 ATOM 平台需要額外成本加強的部份)

個人也在 facebook 上提到, 在 x86 市場操作/推廣上
VIA 市場策略應盡量提升 x86 在消費性電子的應用性
在主流的 Desktop/Notebook 上, 可以預見的是由於知名度, 與不願得罪intel等綜合因素
VIA x86 PC接受度上依然是個問題
加上提供的特性&價格上並無讓人眼睛一亮的感覺
接著, 不錯的平台就容易掩蓋在 CPU性能與價格的單一評比之中..

購買請到此

Firmware 沒有那麼容易不只 Function Call 來 Call 去...

2010-04-06T00:18:00.000-07:00

個人於上個月底離職了
主要因素是需要一段時間休息運動和調養身體
這段空檔時間, 按照慣例一樣作了一些目標設定
算是去年一月空檔時弄Prex的延續, 然而平台已經不是S3C2440
在告一段落後, 希望能藉此能有更進一步的突破

回想這幾年, 由於工作因素不斷地在 linux 與 embedded os 間交錯
對於 firmware 相關工作日漸有些許不平之鳴
而這些林林總總, 多半在所謂良善管理與時程下而掩蓋

改寫"沒那麼簡單"歌詞: "Firmware 沒有那麼容易, 不只 Function Call 來 Call 去"
道出了 firmware 的甘苦辛酸

若以公司為出發點的角度去思考
Firmware 最大的困難之處或許不在於 coding 實作本身
而是在於相關工作難免接手的人來來去去.
這樣的情形下, 一旦 Firmware 在介面與架構缺乏良好規劃的前提
在接手/參與的人無法完全熟悉的情況下, 為了盡快地完成任務, 也只能依樣畫葫蘆
只是如此時間一拉長, 經手的人一多, 就會轉變為一個悲劇.
換來的是, 日漸膨脹混亂, 開發與除錯時間逐漸地延長.
即便在此看來簡短而淺顯易懂, 但諷刺的地方在於, 這部分很容易被管理階層所忽略

這裡舉個常見現象作為例子
一個以 MP3 player作為起始產品時可能僅支援 MP3
而在 IC 中需要 Hw 需要的功能是 Audio playback, SD Card, LED display, Buttons.
軟體上需要的就是 FAT FileSystem 與 MP3 decoder
硬體的 Audio Hw 通常透過 Interrupt 去擷取需要輸出的 audio buffer
這個 case 就是 mp3 decoder output buffer.
接著藉由某種 message 傳遞通知 decoder 繼續 decode
這樣的情況下, 很有可能的方式就是直接在 ISR 中取用 MP3 decoder buffer

然而隨著 audio 格式一多 aac, ogg ... etc
依樣畫葫蘆的結果就是針對不同codec的一堆Audio ISR
最後就是演變成 policy 與 mechanism 混亂的情形
隨著規格要求不同有不同與交錯混亂的 path
這樣的問題並不侷限在這方面, 而是廣泛見於各種軟硬體程式介面上
像是 File System, 多半好一點都會將 FS 與 flash device 做個 layer
慘一點的 flash device 與 filesystem 混著寫也是有的
鮮少見再將 SD/NAND/NOR 的 protocol 與 device 分離的實作

更不用再多說由於多數Firmware 的 monolithic 特性
很容易在缺乏訓練之下或是為了急就章, 任意呼叫不適當的 function
因而造成日後專案維護性與移植性的低落

的確很多時候是用不到 Linux 這樣龐大架構的系統
然而相對而言的lightweight OS更需要心力去維護良架構.

最後是之前隨手改的詞, 博君一笑..

=================================================

沒那麼簡單就能寫出想要的方案
尤其是在 firmware 年久失修又雜亂
總是不安只好硬幹
誰謀殺了我的責任感

沒那麼簡單就能去改別的全不看
變得實際也許好也許壞各一半
不愛加班一久也習慣
被老婆唸勝過被老闆狗幹

靈感來了就快Coding去
感覺累了就聊天打屁
主管的意見隨便聽一聽自己作決定
開會不想投入情緒
一杯咖啡配coding
在周五晚上關上了手機免得六日被Call去

Firmware沒有那麼容易不只 function call來 call去
過了有理想的年紀架構翻新不如穩定
架構沒有那麼容易才會特別讓人著迷
剛出社會的年紀
曾經最用心所以最開心曾經

OpenGL 4.0 specification released.

2010-03-14T19:22:00.000-07:00

上週引起廣大討論的新聞莫過於 OpenGL 4.0 規格的釋出
眼尖的人可以發現 GLSL 的版本編號與 OpenGL 一致了
(不再像以往有著不同的編號: ex: GLSL 1.4 - OpenGL 3.1, GLSL 1.5 - OpenGL 3.2)
同一時間 OpenGL 3.3 規格也釋出了
OpenGL 3.3主要目的在於盡可能導入4.0的功能, 提供OpenGL 3.x世代硬體所能利用的 4.0 特性
詳細關於 4.0 的介紹可以參考這篇

特別的新功能在於
1. 兩個新的 shader 來處理 geometry tesselation
2. 能夠使用 OpenGL/OpenCL 計算出的資料來繪圖 ( 如此將可大幅降低CPU運算, 也降低CPU 對於CG, Gaming 的重要性, 可以預期的是與其花大錢買高速CPU, 其效應可能不如省下來買張中階顯卡還有找 )
3. shader 支援倍精準(double) 浮點數運算, 以增進繪圖的正確性與品質.

Linux kernel 2.6.33

2010-03-14T18:50:00.000-07:00

Linux kernel 2.6.33 在 Feb 24th, 2010 釋出了
主要的更動可以參考 kernelnewbies 與 H-Online 的What's new in linux 2.6.33這篇

這個版本受到注目在於
1. 整合Nouveau - open source nvidia 3D driver (Nvidia 並無提供協助, 主要是以逆向工程實作)
2. 整合DRBD - Distributed Replicated Block Device, 能視為基於網路的 RAID-1 實作
3. 整合Compcahe - 提供 Ram-Based Compressed Swap Device, 主要是切割出一塊記憶體空間, 將需要swap-out page資料, 壓縮後存放. 如此達到在記憶體中放置更多page 的目的, 減少 Harddisk IO(現今 CPU 壓縮/解壓縮速度勝過對 HardDisk 讀寫), 提高效能.
4. Android removed from the linux kernel - 相關細節請參考 Android and the Linux kernel community (關於文章作者Kroah), 在今年二月初時此事在各大資訊相關網站廣受討論.

from linux thread to protothread

2010-03-08T07:10:00.000-08:00

去年在使用 buildroot/uClibc 環境移植 linux 過程中
由於編譯時對於 thread 選項選取預設的 linuxthreads 而非較為完整的 NTPL
因 thread 行為模式的緣故, 造成 IP 廠商提供的 OpenGL ES 環境無法正常運作
當時觀察到主要的錯誤在於每個 thread 取得的 pid 是不相同的
明顯地, 這不符合 thread 一般的認知, 然而這也與 linux thread 實作演進有相當的關係
(而linuxthreads 演進到 NTPL 的過程, 請參考 wikipedia 上的關於linux thread的歷史, 這裡就不詳加說明.)

在碰到這樣結果的當下, 稍微感到有些訝異
現今 thread 的概念在 OS 教科書中是一大重點
而 thread programming tutorial/guide 更是垂手可得
利用 thread 來改善系統效能, 更是常見於日常的程式中
這些資訊多到讓人產生一種 thread 的存在是理所當然似地
看著 wikipedia 中對於 thread 的說明, 跟教科書其實相去不遠

撇開 user-level/kernel-level 的優缺和 1:1, N:1, N:M 的 Model 不同的理論不談
kernel-level threads 間的 context switch 可能可以較容易理解, 或是寄情於OS的能力
其中最引人入勝的莫過於 user-level threads 間又是如何達成的?

對於 user-level thread 的考量點有二
1. 如何於 user space 維護 thread context
2. thread switch 的時機點
preemptive or non-preemptive

其中 1.又取決於針對 2.的考量決定複雜的程度
可以想見, 可能必須在 process 中建構屬於 thread 的context
從 PC register, stack, 甚至可能細到 signal, 取決於實作的規劃

複雜者可能如 FSU Thread 在user-level 中實作了 POSIX thread

另外常見的 user-level thread 方式是提供特定的 I/O 與 switch API
讓 programmer 決定可以選擇切換的時機
這類者像GNU Portable Thread 即為一例
對於 GNU Pth 的細節技術可以參考這篇論文
主要在於使用泛 unix 的 ucontext/setjmp 支援

然而確也可能簡單到像 Contiki 中使用的 protothread
(與 coroutine 不同的地方在於 protothread 是 stack-less)
其概念可以拜讀 Simon Tatham 關於 coroutine 的大作
jserv 於 2006 年也對 coroutine 做了簡單的介紹
其精神在於僅存放 thread 所在的狀態, 以利於切換時跳至正確的位置

由於不停地在 thread 中切換, 若 thread 的 execution time 過小
搭配 sleep 的時機不佳, 簡單者是浪費 cpu 的 busywaiting
然而延伸而言, 卻也會影響 scheduling 與 cpu freqency 切換的判斷
而需要 computation 時, thread 間執行時間的比例, 與 sleep 可能造成降低效能
而這些都與使用 user-level thread API 實作 thread routine 的方式有很大的關係

儘管 thread 帶給 programmer 許多便利性
然而需要注意 thread 在各種環境下的特性, 才能夠正確地使用

HiRadioTray 20100109 & Hinet Radio Script 20100110

2010-01-09T04:45:00.000-08:00

HiRadioTray 20100109
檔案連結: HiRadioTray_20100109_ubuntu910_i386.deb

1. 根據 Hinet 更動了 mms 取得方式
2. 修正奇美古典音樂網格式
3. 修正更新功能

由於個人疏忽, 20091010版無法使用更新功能

使用 20091010 版本的使用者:
安裝更新檔者:
請移除 ~/.HiRadioTray 目錄後再執行程式即可

不想安裝更新檔者
請到此下載 update.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正更新功能
請到此下載 get_mms.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正收聽功能

Hinet Radio Script 20100110
檔案連結: radio_20100110.tgz
或執行 update.sh 更新即可

打造簡易監控系統 - ffmpeg + lighttpd

2009-12-13T19:10:00.000-08:00

(TODO: 附圖)

由於個人與老婆必須工作, 平日就將寶貝女兒託給爸媽照顧
在家中, 女兒目前待在三樓塌塌米房間
然而難免會有需要短時間離開處理一些事務
能清楚知道baby何時醒了和哭了的時間很重要
因此母親希望能夠架設視訊系統, 方便在一樓能知道三樓狀況

的確, 最快的方式就是購買現成IP Cam產品
想想這部份的技術並不是非常高
所以第一時間想到的就是擺放在家中當床頭機的 EeePC 701
(老實說, 現在有點慶幸當時買的是有Webcam的版本, 那時嚷嚷我只需要長效電池)

接著就是作 video streaming 了
其實依開始我想到的是使用 VideoLan 來作
然而設定/使用與過高的CPU loading都不讓人滿意
加上是給父母操作使用, 使用過程愈簡單愈好

朝 flash video 方向尋找方案, 發現 ffserver/ffmpeg 是個不錯的選擇
參考ffmpeg的這篇討論文章, 搭配需求將設定檔做了些許更動
像是加入了Audio部份, (ffmpeg 的啟動指令亦必須加入 -f oss -i /dev/dsp)
另外提高VideoFrameRate至15, 移除了 VideoIntraOnly, 加入VideoGopSize 以降低bitrate
原本只打算使用 swf 格式, 如此browser 可以直接開啟播放
然而個人設定 SWF 搭配 Audio一直無法順利啟動
(如有設置上限制, 歡迎告知指正)
只好轉而使用FLV, 測試後,VGA frame, 15FPS 加上 Audio
在 630Mhz 的 EeePC, CPU loading 約為 50~60% (打開900Mhz 模式, 降低到 33%~40%)
設定好後, 假設存檔為 webcam.conf, 如此執行指令 "ffserver -f webcam.conf"
就可以在 http://MACHINE_IP:8090/webcam.flv 收到 streaming video/audio

使用 FLV 相較於 SWF 比較麻煩的是需要 flv player
browser 上需要 swf 元件來處理 flv video
網路上免費solution不少, 像是37-flvplayer.swf與GPL的flowplayer
最簡單的方式, 就是寫個 HTML, 連到提供該元件的主機, 搭配 flv 來源URL
為了降低對外部網路系統的依賴, 搭配輕巧快速的 lighttpd 來使用是不錯的選擇
(Apache?! 殺雞焉用牛刀.)
下載好 swf 元件, 依照各個swf flvplayer 規格撰寫個簡單的 HTML
放置於 /var/www 後就完成了

如此, 一樓電腦打開browser, 設好首頁, 就完成了

想想, 在 embedded 產品上, 將 hw codec 整合至 ffmpeg 是個不錯的作法
如此很快就可以建立具有網路傳輸功能的分散式 IPCam

關於 Chrome OS 的另一觀點

2009-12-03T04:56:00.000-08:00

今日很榮幸受到先前在NCHC主管Steven的邀請
分享一些關於Chrome OS 與 GO 程式語言的心得

Chrome OS Observation

View more documents from Champ Yen.

在Chrome OS推出時, 難免將此與Google 要正面挑戰 Microsoft 做連結
並且以個人裝置的用途來思考, 因此Chrome OS也就相形見絀
在此回歸以Chrome OS的三大特性 - 快速, 簡單, 安全的方向思考
也許 Google 所規劃的是不同方向的佈局

Chrome OS - 網路作業系統時代的來臨?

2009-11-20T06:38:00.000-08:00

回想當年, 微軟為了擊敗如日中天的Netscape
刻意將Internet Explorer 內建於Windows 系統
在反托拉斯官司中, 微軟宣稱 IE 是 Windows 系統不可分割的一部份
今日Google 推出的 Chrome OS 中, Browser 的確是系統不可分割的一部份

在Google發佈Chrome OS計劃細節後,
相關的新聞已經在網路上迅速蔓延了開來
Chrome OS之所以受到如此的注目
是因為媒體將Chrome OS解讀為Google用以挑戰微軟的開始
而若不是Google盛名, Chrome OS或許也無其特殊性.

今日原本抱著期待的心尋找Chrome OS的資訊
反覆觀看計劃相關的技術文件與設計說明後,
甚至覺得有些許說不上來的感覺
Chrome OS 計劃很難與創新聯想在一起
在看完這篇文章後, 我也釐清了一些想法

網路上對於Chrome OS介紹相當的多, 這裡就不做詳細的介紹
Chrome OS 是個 Web Browsing/Application 導向的作業系統
最重要的特性是不支援也不仰賴任何其他程式,
所有應用全部依靠Web Application
因此使用者資訊完全存放於網路上, 在電腦上完全不存放任何資訊
因為如此, 系統的確能夠精簡到基本的OS, Driver & Browser, 開機快速
而不做任何更動的檔案系統, 做檢測相對上較容易, 安全性上也很好

對於Chrome OS這樣的設計,
最大的問題也在於全面網路化的時代來臨與否
說穿了, thin client並不是甚麼特別新的觀念
從早先的終端機到宏碁提出的專用電腦XC,
都是類似概念下遭到淘汰的產物
儘管現今網路應用在比以往充實許多
而這些Web Application是否真的能夠大幅取代原生軟體應用?
單單 Youtube/Lala 能夠取代一般使用者的影音需求?
列印, 照片處理, LAN檔案分享, 這都已經是普遍的一般應用

的確, 有人可能會說Chrome OS 可能定位不在此
但這樣的情況 Chrome OS 只能定位為電腦上第二個作業系統
快速開機, 上網, 安全無負擔, 在許多臨時應用上確實有其市場
然而在這個市場上已有既有實作像是著名的Hyperspace
類似環境所提供的軟體也遠甚於一個browser
甚至個人認為同樣在Web App導向的思維下
Intel Moblin v2在系統設計上的也優於Chrome OS
實用性遠遠超過 Chrome OS

而除了技術觀點上的問題外
Chrome OS 還需要挑戰人們對於資料放在網路上不安的心理
本地端資料檔案處理 & 多媒體的大量需求
以及對於原生軟體功能性的需求與追求多多益善的心態..

若Google 後續不正視與修正Chrome OS 對於 local 原生軟體應用需求的策略
那麼Chrome OS 難免落入對於網路應用一廂情願的泥淖中..

令人期待的 GIMP 2.8

2009-11-19T09:15:00.000-08:00

GIMP 2.7 的 single window mode

先前就聽說GIMP 2.8將要支援許多人引領期盼的 single window mode
雖說個人並不是很排斥GIMP原有的multiple window
但在Ubuntu Netbook Remix 下, 過多視窗就顯得不易使用
原本是指望Paint.Mono, 然而目前在Linux上有許多問題, 連堪用都稱不上

今日看到了一篇國外的blog文章
發現Single Window Mode 看來真的是很棒
相當簡潔, 不會有凌亂的視窗

於是叫出安裝已久的GIMP 2.7
果然single window mode 有相當雛型
目前看來UI的版面配置的調整有些問題
但是配置好後, 看來真的是挺有那麼一回事

由此看來, 等穩定後推出的正式版本 2.8 應該是相當令人期待

Google Go - C 語言的進化

2009-11-17T07:30:00.000-08:00

Go Language 吉祥物 - Gordon 田鼠

自上次更新blog 至今有許多大則的資訊相關新聞
像是 Ubuntu 9.10 與 Android 2.0的發佈
MontaVista 與 3Com 被併購等等

令個人注目的就是標題上談到的Google所提出的 Go Language
個人認為, 對於喜歡 C 語言的程式設計師而言, Go 會是另一個開發利器

對於Go 的背景資料, 個人就不在此詳加介紹了
在搜尋網站上搜尋就可以輕鬆找到一大堆

Let's Go.

一進入 Go 官方網站, 即說明了Go 語言的特點 - simple, fast, safe, concurrent and fun
的確, 沒有比這更簡潔有力的介紹了

從官網的範例看來, 乍看之下會以為Go又是個了無新意類似 C++/Java 的語言

package main
import "fmt"

func main() {
fmt.Printf("Hello, 世界\n")
}

是吧? 可是官網開頭範例竟然是個天大的陷阱, 從package, import 到 fmt.Printf()
一旦接著好好咀嚼 Tutorial 的話, 會發現 Go 真的蠻奇特的, 甚至與原本所想的相去甚遠

C++/Java 程式設計師第一時間可能是發現到了 - 沒有class, object!
(沒有繼承多型, 我怎麼唬人(誤))
接著會注意不太一樣的variable/function declaration (Goroutine 這是啥!?)
與不太順眼的 if-else, switch, for ...
還有看都沒看過的資料型別 - Slices/Maps/Channels (有 String 囉)
一開始摸不著頭緒的 interface

在語法上 Go 提供了精練且概念呈現較清晰的方式
像是變數宣告:
var Foo [10]int;

且流程控制的語法更為彈性
像是switch:

switch {
  case '0' <= c && c <= '9':               return c - '0'       case 'a' <= c && c <= 'f':        return c - 'a' + 10       case 'A' <= c && c <= 'F':               return c - 'A' + 10    }

另外像是 function 可以有多個 return values
語法上有諸多新的特性, 就留給大家慢慢發覺

除了語法的改良外

如同 C 語言, Go 依然是以 struct 為主
資料處理的方式, Go 採用了與 C++/Java 物件導向不同的 data - interface
在 OOP 中 data (member) 是依附特定 function (member function)處理
data - interface 中, 並不將資料與介面做緊密的結合, 而僅是有其關係
這樣的方式除了具有彈性外, 資料的操作上也較為直覺, 並且負擔較小
相對地也是達到code reuse 的另一種方式

官網 Tutorial 的範例 - Sorting:
這是個能夠排序的function (Interface 是 interface 名稱)

func Sort(data Interface) {
    for i := 1; i <>
        for j := i; j > 0 && data.Less(j, j-1); j-- {
            data.Swap(j, j-1);
        }
    }
}

所制定的 interface


type Interface interface {
    Len() int;
    Less(i, j int) bool;
    Swap(i, j int);
}

如此 Sort 可以套用在任何實作此 Interface 的資料型態
範例中列舉了int array (non-struct)與 day(struct)


type IntArray []int
func (p IntArray) Len() int           
{ return len(p); }
func (p IntArray) Less(i, j int) bool 
{ return p[i] < p[j]; }
func (p IntArray) Swap(i, j int)
{ p[i], p[j] = p[j], p[i]; }

func ints() {
  data := []int{905, 0, 0, 42, 7586, -5467984, 7586};
  a := sort.IntArray(data);
  sort.Sort(a);
  if !sort.IsSorted(a) {
      panic()
  }
}

type day struct {
  num        int;
  shortName  string;
  longName   string;
}

type dayArray struct {
  data []*day;
}

func (p *dayArray) Len() int           
{ return len(p.data); }
func (p *dayArray) Less(i, j int) bool 
{ return p.data[i].num < p.data[j].num; }
func (p *dayArray) Swap(i, j int)
{ p.data[i], p.data[j] = p.data[j], p.data[i]; }

而其他還有許多值得玩味的部份 - 像是Go 所強調支援的 concurrent 的支援, 與 Memory Model (Go 具有 Garbage Collection)
在此就不詳盡一一介紹了, 官網上的 Tutorial, Package Document 與 Effective Go 都是優質的文件資料

如官網 FAQ 所回答的, Go 概念上很多部份源自於 C
然而特性上有混合不少其他類型語言的感覺
相信喜愛 C 的人多半會樂於接受這樣的演進
另外Go 還是發展中的語言, Compiler 還在開發中
目前還缺乏動態連結的能力, 目前僅能編出靜態連結後的執行檔
儘管目前 Go 尚未廣泛地被應用, 然而依然可以從 Go 的設計看出所俱備的潛力

Android 已移植至 PowerPC 平台 & Android 2.0 釋出

2009-10-28T22:59:00.000-07:00

在兩年前的拙作"到底 Google Android 是甚麼"一文中提到
Google Android 建構了標準 library 環境與使用Dalvik VM是相當聰明的規劃
相較於WinMobile 與其他Embedded Linux Distribution而言,
Android這樣的系統特性使得在硬體平台轉換時, 依然保有長期累積的應用軟體資源
當時已可看出Android的架構並非依附在特定硬體平台上.

這樣的特性對於系統與SoC廠商這都是樂觀其成的事情, 特別是使用非ARM Processor的廠商
而這個效應正逐漸發酵中, 繼Android移植到MIPS後
近日LinuxDevices.Com上的新聞顯示現在也已經移植到PowerPC
可以遇見的是, Android 平台的優勢會漸漸浮現

同樣面對多元的硬體平台, 然而Microsoft 由於 Wintel 的成功經驗
預期相同的策略能夠在手持式平台市場複製
在Handheld Device上 Windows Mobile 硬體平台上決定限制使用ARM平台
雖然以此解決了硬體平台多元的問題, 如此的決策也造成了硬體的排他性
並非根本解決軟體相容性問題, 而相對地也同時樹立了非ARM平台業者的敵人

另外在 1.6 版發佈的一個半月後, Android 2.0 釋出了
在功能的改進與新增上有不少的更動

Symbian 基金會釋出Symbian Kernel 原始碼

2009-10-25T00:54:00.000-07:00

Symbian 終於釋出 kernel source 了
今日 Symbian Fundation 公告以Eclipse Public License授權釋出Symbian microkernel
相關的細節請至公告中提到的連結(下載source需要註冊帳號)

整份Kernel Taster Kit 包含了
* Symbian^3 核心原始碼
* 可立即使用的 QEMU 模擬器
* Symbian^3 對於 QEMU 與 Beagleboard 的基本移植
* 用以編譯原始碼的相關工具程式(免費授權於低於20人的公司)
* 可以立刻使用的 ARMV5 binary

儘管腳步比起 Android 晚了許多, 比起Windows Mobile的專制封閉, Symbian 終究走向了開放
期望開放後社群應能為Symbian帶來功能與穩定上的增進
而 Symbian 優秀的 microkernel 架構也能夠給予OS hacker 一探究竟的樂趣
並持續帶給這個領域良性的競爭與互動

ARM 發表新低功耗處理器 Cortex-A5

2009-10-24T23:48:00.000-07:00

ARM Cortext-A5 處理器單核內部架構

ARM Cortex-A5 多核架構

在 Slashdot上看到這則消息
ARM官方網站已可以看到Cortex-A5相關的訊息
iThome上也可以看到一則新聞(細節多翻譯自ARM官網)

從規格上看來, Cortex-A5是Cortext-A8/A9的精簡版
儘管公告與說明上強調與Cortex-A8/A9的相容性
然而從官網的規格細節可以看出相當的差異
* pipeline自13 stages減為 8 stages
* instruction 自 dual-issue 減為 single-issue
* NEON/FPU 為選配
* 不具有 L2 Cache

另外在記憶體系統項目強調, Cortex-A5有著最佳化的AXI bus, 提供相當於3X ARM11頻寬

從自Cortex-A8架構的精簡化到NEON/FPU的選配
可以看出ARM希望在舊有的 ARM9/ARM11 到 Cortex-A8 之間的價格與功能落差
提供一個低功耗, 低成本且具有競爭優勢與架構彈性的進階處理器
如官網所述, Cortex-A5的目標市場在於依然使用ARM9/ARM11的廠商

儘管Cortex-A5本身可能具有成本優勢, 然而依舊是single-issue的處理器
可以說性能上與ARM9/ARM11的差異性並無相當的吸引力
然而對於ARM Cortex-A5 市場區隔的重點在於NEON/FPU的授權價格
對於使用ARM9/ARM11的廠商而言, 除了具有較快的AXI bus頻寬
吸引升級的動力多半來自於SoC應用上對於NEON/FPU的需求 (Ex: 與GPU搭配)
若搭配NEON/FPU價格過於接近 Cortex-A8
廠商也有相當的可能選擇繼續使用 ARM9/ARM11 或選擇 Cortex-A8

My Baby~ Ubuntu 還是比較好用

2009-10-21T06:20:00.000-07:00

我家的妹妹

Oct 19, 2009 我家多了新成員 - 我的寶貝女兒
當然不免俗地拿起了相機拍了幾張照片

由於怕老婆空檔會想用電腦, 帶的是老婆慣用的 MSI M673
原本想透過Windows XP 來處理照片 (3.5G - Huawei E220 在9.04下還是有點小問題)
然而發現在Ubuntu下能正常使用的內建讀卡機, 竟然一直讀取不到 8GB SDHC
(O2Micro Integrated MMC/SD, 已經是XP SP3, 更新driver)
搞了許久, 插卡後Windows 就直接停在那

一整個火大後重新開機進入 Ubuntu 9.04, 無須特別設定, 就能輕鬆地把照片複製.
於是設定好3.5G後就更新系統到9.10

Baby~ 告訴你喔 Ubuntu 還是比較好用...

HiRadioTray 20091010

2009-10-09T20:22:00.000-07:00

這版是新增預約錄音前的整理版本
本版本開始產生 .deb file
新功能為斷線偵測, 自動重新連線(基本錄音功能顯示STOPPPED)

source code: HiRadioTray_20091010-2.tgz

Ubuntu 9.04
x86 deb package: HiRadioTray_20091010-2_ubuntu904_i386.deb
amd64 deb package: HiRadioTray_20091010-2_ubuntu904_amd64.deb

Ubuntu 9.10
x86 deb package: HiRadioTray_20091010-2_ubuntu910_i386.deb
amd64 deb package: HiRadioTray_20091010-2_ubuntu910_amd64.deb

錄音檔案會存放於 $HOME/RadioRecord/ 目錄下
由於錄音是新增一個 mplayer 在背景連線抓取 bitstream (如此之後才能夠聽一台錄另一台)

有使用相關問題歡迎不吝指教

Google Code Project : hiradiotray

PS. 下午測試後發現一些狀況, 目前將斷線偵測的週期拉長為 5 秒測試中, 已安裝者請重新下載安裝
PS2. 有人反應安裝執行後有錯誤訊息, 測試後發現應是 library mismatch, 新增 ubuntu 9.04 package
PS3. 修正檔案開啟過多問題

HiRadioTray 20091007

2009-10-06T20:46:00.000-07:00

看了一下, 有蠻多人有錄音相關需求
這版本主要是提供初步的實作, 驗證所構想的錄音方式
檔案請到此下載

HiRadioTray 需要 wxWidget 2.8 與 mplayer 請事先安裝好
本版加入了基本錄音功能, 點選選單的 "Start/Stop Record" 就可以開始/停止錄音
檔案名為: 年月日時分.wma ex: 200910071143.asf
未來規劃包裝.deb檔案與加入預約錄音的功能

另外更新了 URL 擷取的方式, 方便快速播放/換台, 不需錄音功能者, 使用 Update 功能即可.

有任何意見與問題, 請不吝指教

ChangeList:
* modify get_mms.sh to replace mms to http for quick audio access
* use slave mode to quit
* use non-block file mode
* add record function

Ubuntu Netbook/Moblin Remix

2009-10-03T08:18:00.000-07:00

Ubuntu Moblin Remix (安裝後忘了擷取圖案, 引用ubuntu官方圖片)

Ubuntu Netbook Remix 9.10, gcin 搭配 Pure 的icon(En的圖案) 竟有意想不到的整體感

由於個人桃園家中有台 EeePC 701
礙於Desktop UI 不太適合 7" 螢幕
(由於顯示的元件過多, 浪費不少空間, 另外部份文字顯示過小)

考慮到近日 Android for EeePC 701 的支援也日漸成熟
(近日0xlab olv 採用Mesa 7.6的支援, 連OpenGL ES 3D 支援都有了)
為了便於使用, 原本是有打算改安裝 Android
然而雖然增進便利性
另外一方面, 理性又告訴我, 如此在功能性上大減

除了基本的輸入法支援缺乏外
另外像是 Flash Player 與 Office 軟體
其他的功能像是網路 ATM, File Sharing(samba..)
這些在安裝了 Android後就無法使用, 而這並不是全部
如此一來, 在平日桌面應用上來說在 EeePC 701裝 Android 並不方便
可以這麼說, 若Android要跨越道Netbook 軟體支援與功能性的需求上需要更多的支援

做了一些搜尋之後感覺, Intel Moblin v2.0似乎是個不錯的選擇
有著針對 Web/Netbook 應用的 UI 設計(media player 的設計真的不錯), 開機快速等等的優點
很可惜的是, Intel 官方的 image 僅支援使用 SSE3 的 CPU (像是 ATOM 與 Core 系列 CPU)
Intel 官方宣稱如此可以加速 Moblin v2 20~30% 的效能
Yeah, you got it...
由於上述原因, EeePC 701 所使用的 Celeron 無法使用 Intel 官方的 image

繼續挖下去發現了原本的 Moblin v1是建構在 ubuntu 上, 而 2.0 轉而選擇了 RedHat
然而有如連續劇一般, Ubuntu 官方公告支援 Moblin v2
因此 Ubuntu 推出了自己的 Moblin 套件 - Ubuntu Moblin Remix

相較於官方Moblin來說, Ubuntu Moblin Remix結合了Moblin的優點與ubuntu套件管理的好處
然而由於目前Ubuntu Moblin Remix尚未正式釋出
可以明顯感覺尚未完成, 安裝過程中並無正確中文顯示
(由於缺乏字型, 即便試用liveCD, 安裝字型後, toolbar 也無法正確顯示)
中文支援上需要安裝字型與語言支援的package並且重新開機
加上瀏覽器似乎使用上有些問題, 只能使用附上的另外一個Qt/Webkit-based的
此外對於每個一般程式是以 zone 來區別, 這點上來說, 切換並不是很方便
而應用程式toolbar上只有單一項目, 再以頁面項目分類, 無法很方便快速找到軟體
以 Web 應用導向的 UI 確實很快很炫, 然而對照其他一般程式上使用的體驗似乎不過generic
而最可惜的是目前 Toolbar 的 layout 是寫死的, 無法透過修改CSS更改, 必須改寫程式碼
對於解析度寬度為800(含)以下的 layout 各種功能的icon會與系統狀態的icon混在一起

Ubuntu Netbook Remix(UNR) 9.10
UNR不是新東西了, 自 Ubuntu 8.04 就有的針對 Netbook 套件
然而建構於 Ubuntu 9.10 的 UNR, 有著與以往不同的外觀, UI的呈獻上變得更加的洗煉簡潔
Toolbar 在有限空間下提供了Main Menu, Task List, Window Title System Status/Info等功能
而每個程式的工作視窗就利用Toolbar之外的全部空間
Main Menu 提供了軟體主要分類的類別, 每個類別下可能還有次類別
雖然是簡單的概念, 在 Netbook 系統下確顯得直接明瞭
使用上雖不如Moblin 搶眼, 然而確相當實用

如果有 9" 以上的Netbook, 開機時間是重要因素的, 可以考慮使用Ubuntu Moblin Remix
而針對Netbook 使用者個人偏向推荐 Ubuntu Netbook Remix (EeePC 70x 就沒有選擇了)

Matroska File Format

2009-09-28T07:45:00.000-07:00

Matroska is a multimedia container format like AVI and aim to be an open standard.
It is open and absolutely free for use. Everyone can get specification easily and develop for their own purpose(personal, research or commercial).
The format adopts EBML(Extensible Binary Meta Language) design for extension flexibility.

There are some free implementations for matroska.
The most famous projectss are libebml & libmatroska released under LGPL.

For most case, LGPL is ok. But for commercial usage and companies, BSD License is prefered.
Before 2007, a parser released under BSD License can be found easily on internet.
But it is hard to get a copy now.
For those who try to get it, you can get it (2 files:MatroskaParser.c MatroskaParser.h)
via aegisub project (whole project released under 3-clause BSD License).

For InputStream implementation reference, mkv_wrap.cpp and mkv_wrap.h can be refered.

Ubuntu 9.10

2009-09-27T19:01:00.000-07:00

近日改裝了Ubuntu 9.10 daily build

第一時間可以明顯感覺到的是開機速度又比 Ubuntu 9.04 快些
而開機splash比較有科技感了
而系統預設的中文輸入法從 SCIM 改為 iBus
即便如此, 前者個人使用穩定性上不足, 後者反應速度上不佳
我都移除改安裝gcin

許多主要軟體都有重大的版本更新
linux kernel 2.6.31/GNOME 2.28/Mesa 7.6 (採用了新的Gallium3D 架構)
桌面環境的使用上可以感受到所帶來的效能增進
另外也修正了一些問題
(ex: 我使用的華為 E220, 原本需要做些檔案修正才可以正常使用, 現在可以直接正常上網了)

另外像是更新帶來的新特性
Firefox 3.5(TraceMonkey JavaScript Engine)
OpenOffice 3.1(強化圖形顯示)
Pidgin 2.6.2(支援Google Talk Voice chat)
gcin 1.4.5(解決著名的小灰問題)

對於 Ubuntu 的日漸成熟, 我想應該是有目共睹的

Play with Android 簡報上線

2009-09-21T01:36:00.000-07:00

從決定開始要 porting android 到 zaurus 當練習
這段期間看了一些資料, 也看到一些關於Android有趣的實做與專案
以軟體架構的角度看來, Android 的確是個饒富趣味的系統
其特殊的軟體架構, 也讓Android在Symbian, WM, Linux 三強鼎立中走出自己的路外

這份簡報的主旨並不在於教導 porting 或是 marketing 分析
僅僅輕描淡寫地談了系統架構, 動手編譯Android 到客製系統
從慢慢地動手深入 Android, 進而瞭解其相較於其他系統不同的開放與特殊性
或是進而體會到其未至成熟的部份

可以確定的是即便到了 1.6, Android 還需要更多的實作與改善
套句物理頑童費曼的名言: "這下面的空間還大著呢!"
是的, 這下面的進步的空間還大著呢

Play With Android

View more presentations from Champ Yen.

Cont. Android on Zaurus - swap

2009-09-17T09:59:00.000-07:00

finally, i compiled a static linked busybox for swap. now browsing is much responsive and smoonth. these words are input by my zaurus.

續 Android 1.6 on Zaurus C750 - Keypad/Screen View

2009-09-16T09:04:00.000-07:00

當初構想中的Android Zaurus床頭機是Landscape View
因此無線網路通了之後, 就開始著手修改

在移植過程中就已經發現一件事,
當Zaurus蓋起來時Orientation會切換到Landscape
而一旦打開時就會切到Portrait
這一切都是因為螢幕編框有的凸起, 將鍵盤上方的一個switch 壓下
透過 getevent 指令, 可以確認這是 keyboard 所發出的事件
詳細的修改就不說了, 主要是 driver/input/keyboard/corgikbd.c
針對 SWA (Switch-A) 的結果, 傳回相反值

Android 1.6 已經很聰明的會轉換 Touchscreen 的事件座標
而keyboard 的方向鍵也是 .... 這才讓我注意鍵盤方向對應我的設定有誤
Android 原本的 Screen Orientation 和方向鍵是針對手機去設計的
所以要再次調整 /system/usr/keylayout/qwerty.kl 的數值

如此就是一台堪用的床頭機...

續 Android 1.6 on Zaurus C750 - Touchscreen/Wifi

2009-09-15T06:31:00.001-07:00

近日已將 Touchscreen 與 Wireless 相關驅動程式與設定調整好
Touchscreen 驅動後即可使用, Wireless 方面是參考這篇
之後要將Screen自Portrait 轉為 Landscape

目前的執行結果如上圖
ZC750 + Android 在網頁瀏覽的反應與速度上差強人意
但是作為熟悉Android Porting是個很好的練習

Android 1.6 on Zaurus C750 - Basic System Works!

2009-09-10T07:37:00.000-07:00

Zaurus 是個人在 2003 年時夠入, 近日也不太使用
這段期間從 Cacko, OpenZaurus, pdaXrom 到 Angstrom 都玩過
最近工作需要熟悉Android 移植流程, 在硬體平台尚未完備前
就先行拿這台舊PDA 研究 Android

圖上是 Android 1.6 在 Zaurus C750 開機完成後的畫面
kernel 部份是使用 OE 2.6.26 for Zaurus C7x0
對應的Android 修改是參考 OMAP kernel android-2.6.26
並且加入了 2.6.27 部份的更新與 PMEM 與 w100fb 的 double buffer與加速的修正
目前尚未完成, 無法使用, 還需要針對鍵盤輸入與電源偵測做處理
啟動CF WIFI 來使用也是必定的

相關 source code 與 binary 會在完工後一併釋出
(這陣子survey 發現很多相關網站只釋出binary, 但一直迴避釋出source ex: Omegamoon 釋出許多binary, Zubuntu 已經到 2.0 確從未釋出任何 kernel source)

總之, 這就是開放平台的好處
與C750 同時期的PDA, 硬體或許過時然而卻也不是不堪使用
SONY CLIE UX50 or WinCE/WM PDA 如今又能拿來做些甚麼?
然而相關軟體都已經過時許久, 而且也無持續更新
而規格與軟體不開放, 就算有心也難為無米之炊

這就是淺景深(錢井深)

2009-08-28T07:23:00.000-07:00

Canon 500D + 50mm f1.8, 1.8大光圈的拍攝效果
圖中為老婆的妹妹去日本時購買給我們的平安符, 作為顯示淺景深的效果
光圈快門沒注意, 所以重新調整過色階

用了好一陣子的消費型相機, 一直很想擁有台數位單眼(DSLR)
現今的DC儘管輕巧, 儘管成像也不差, 儘管倍率也很可觀
然而一般DC在成像品質與雜訊處理上與DSLR還是有差距
而更重要的是景深的控制, 操控性上是很難望其項背的
淺景深在一般DC並非不可能, 而是在一些條件下才可以成立
對於我這個不專業的人而言, 都可以感受到DSLR的等級差

今日為了迎接即將到來的家庭新成員, 跑去物色適合的DSLR
最初是想看看有無 Nikon D60庫存品
D5000的旋轉螢幕不敢恭維,
D90的價格實在是讓人下不了手
D3000的CCD成像品質是敬謝不敏

原本一家 D90 + 18-55m kit 開價近 33K, 發現比X發賣的便宜 4K還蠻心動的
後來到另一櫃才發現這個價格還貴了 2K
就在轉向Canon 450D的同時, 被某位店員說服決定夠入Canon 500D
除了整組kit 外還加買了顆 50mm f1.8 鏡頭,
而買了些週邊, 總價格只比D90機身高些
一句關於攝影的俏皮話是"淺景深, 錢井深", 說來也是其來有自

剛拿到Canon 500D的第一印象是"對焦真快"
而f1.8 的大光圈拍攝人像很不錯, 對於練習攝影上也相當方便.
希望這台DSLR能讓我的攝影技術好一點....

Linux 上使用網路ATM

2009-08-25T06:30:00.000-07:00

其實, 這是舊聞了, 只是我今天第一次使用
已往想在Linux上使用網路ATM是求之而不可得,
儘管讀卡機在Linux已經都有driver,
然而國內的銀行多以Windows特有的ActiveX建構網路ATM服務

先前就已經在 ubuntu-tw 上看到
玉山銀行(E.SUN Bank)就感心地提供了Linux網路ATM支援
然而一直都沒有使用上的需求, 所以也沒特別去嘗試

今日按照這篇文章, 就順利使用手邊的讀卡機完成匯款
再次感謝玉山銀行提供Linux 網路ATM服務

Introduction to Linux SD/MMC Driver Stack 簡報上線

2009-08-10T22:56:00.000-07:00

近日工作與此有關
因此做了份簡短的簡報
主要只是針對Linux SD/MMC Driver Stack中,
所使用的資料結構作簡短提示
搭配參考其他實作, 應可較快上手實作

Linux Porting 該篇 slides 有缺漏字, 近日會更新版本
PDF 檔也會近日放上

Linux SD/MMC Driver Stack

View more documents from Champ Yen.

Mesa 7.5 released

2009-07-20T06:45:00.000-07:00

著名的open-source OpenGL 實作 - Mesa 釋出了最新的 7.5 版
在此版最引人注目的莫過於新特性 - Gallium3D 架構

此新架構目的在於提供更簡潔與彈性的3D 實作介面
以因應多元化的 3D API 實作 (ex: OpenGL 3.x , OpenGL ES 1.x/2.x)

以下兩圖解引用自 Gallium3D talk from XDS 2007

在已往的Mesa 的實作仰賴著 DRI Driver
由於實作的概念上緊密依附於 OpenGL,
硬體加速上也僅止於 OpenGL 與硬體間的轉換
對於作業系統上也有著高度相依性

新的Gallium3D 架構將DRI Driver 一分為三
原有的 DRI Driver 分為 State tracker, HW Driver, OS Dependencies(Winsys Layer)
藉由抽換此3個模組就能夠簡單地達到
多樣的3D API 實作(OpenGL 1.x/2.x/3.x, OpenGL ES 1.x/2.x, D3D), 簡潔的driver model, 與OS re-targetability
也提昇了系統實作的彈性

目前新架構上已經有 software pipe, i915 driver, Cell driver, ATI R300 與 nouveau (Nvidia) 實作
相信未來會有更廣泛的支援與實作

HiRadioTray & Hinet radio script 20090715

2009-07-15T08:08:00.000-07:00

今日發現不能聽Hinet 網路廣播了 (抱歉, 最近工作忙, 需要安靜)
而且看到有人反應並且提供了解法, 我就更新了一下
分析了一下更新 HiRadioTray 和 Script

因為只改reg. rule, 我覺得這樣太沒誠意了
HiRadioTray, Hinet Radio Script 這版就加入了據說坊間沒有的更新功能
有甚麼好意見就留個言, 有時間就來實作

.deb .rpm .xxx package!?
要改的太多, 那就改天吧...:P

雜記

2009-07-05T20:38:00.000-07:00

晃眼一個月就過了....
一個半月前還在思索這幾年來的歷程
想在一個月前的今日寫下自己而立之年的一些想法

月中, 也有想要把近日比較有心得的3D相關數理做個簡報,
進而探究ES Shading Language
或是把工作相關的系統建構上的issue在blog上做心得討論

然而在工作比較繁忙以及身體微恙下, 就這樣都一一拖了過去
因此blog 的六月也就成了一段空白, 現在想想還有些愧疚

週末好不容易花了點時間
研究了到手一些時日的Devkit8000,
以隨板附上的linux kernel的針對平台修正的部份
已經把ubuntu弄了上去, 接近了初期的目標
而beagleboard也因老婆工作上的需要, 已離開我好一陣子,
近日也在思索, 想購入Rev.C3

如此也算是小有展獲吧...

Shading Language Prework - 3D Math

2009-06-04T07:15:00.001-07:00

OpenGL 是個人在大二時接觸的, 當時也沒有特別深入
大概是瞭解OpenGL提供的座標系統, 會貼圖和使用 Display List 的程度
由於一直停留在 OpenGL 1.2 以前的印象
在剛看到OpenGL (ES) 2.x 時, 個人還深深懷疑是否真的學過OpenGL

在接觸到OpenGL ES 2.0
並且開始瞭解這幾年的GLSL到 ESSL之後
對於 OpenGL SuperBible 中的描述:
"This isn't your father's OpenGL" 不禁莞爾一笑
事隔十多年, 對於CS後進而言, 這真的不是上一輩的OpenGL

延續OpenGL ES 2.0: Hello Triangle!文章
即便有了相關的Emulator, 若非已經在Desktop上熟悉於撰寫OpenGL Shading Language
在撰寫OpenGL ES 2.0程式上應該會感到不得其門而入
這是由於 OpenGL ES 2.0 是精簡自OpenGL 2.0
已經不若 ES 1.x 採用 fixed function的方式

在OpenGL ES 1.x 中採用的 Graphics pipeline 示意圖如下

其中每個部份OpenGL 都有提供對應的 API
像是Transforming部份的 glTranslate, glRotate, glPushMatrix 和 glPopMatrix 等
如此規劃的缺點是, 所產生的效果受限於 OpenGL (ES) 1.x 內所採用對於顏色和光線的演算法
在產生的效果上受限, 對於新的演算法上實作的複雜度高和效率上的低落

然而OpenGL (ES) 1.x 也不是全然沒有好處
相較於駕馭OpenGL (ES) 2.x shading language高門檻
只要對於Coordinate和Camera View 有點瞭解, 知道所需使用的 OpenGL (ES) 1.x API
一般人無需瞭解複雜的數理運算, 就可以寫出不錯的 3D 程式

在OpenGL ES 2.0中 pipeline 如下

其中可以看出原本的 Transformation & Lighting 由 Vertex Shader 處理
在Rasterization 後的Texture, Color, Fog, Alpha都由 Fragment Shader 處理
而shader 的實作就是靠 shading language 針對此兩部份撰寫兩個程式
由於programmable 的緣故 Vertex/Fragment Shader 能提供的能力與彈性超過於上述的項目

而由於上述以shading language處理的部份功能上被取代,
在制定的 API 上相較於 ES 1.1 顯得精簡
而這些彈性與強大的功能所需付出的代價是:
由於shading language 必須直接處理幾何/光學/著色效果.
必須對於 3D 背後的數理運算有相當的認識.

在3D數理上, 其實並沒有一般人懼怕的高深,
只複習一小部份的Linear Algebra與簡單的向量/幾何運算
即可以理解與掌握絕大部分的3D 計算
想好好複習一下可以看看"3D Math Primer for Graphics and Game Development"
(對於 Shading Language 也用不到裡面全部的內容)
可惜的是, 本書運算式上以 left-handed coordinate/row vector 為主
對於OpenGL 採用的 right-handed coordinate/column vector需要稍微對應轉換一下
然而這對於概念與數理的瞭解上並不構成太多問題.

ARM - Building Multimedia Devices with ARM and ARM Partners Solutions

2009-05-28T09:12:00.000-07:00

週二參加了這個活動
簡單的說, 這是 ARM 推廣自己的 Mali 系列相關 IP 的活動
儘管有其他像是 MontaVista, Ittiam, Aplix 等廠商的簡報,
然而水準上不若於 ARM 一般重視
而另一個可惜的是與會者做的功課不夠, 常可聽到缺乏sense的問題

著名的日商 Aplix 的簡報算是不錯, 然而定位上比較與活動主題無關
Ittiam 有如照本宣科的簡報
加上最後的 MontaVista 的簡報在內容與問答上有相當的錯謬

Mali GPU:
從 Mali 55 到 Mali 200/400
而自sigle frag. processor, vertex + frag. processor
到 vertex + 4 frag processor (with internal cache)
看得出 ARM 在這個領域上的架構與軟體支援日趨成熟
而對於之後的規劃與規格以很明確 - Vithar & Thor
甚至未來在規劃上有打算支援 OpenCL
回想當時, 應該詢問對於競爭者 Imagination, Vivante 的看法與 Mali GPU 相較的優勢為何

Mali VE:
這技術源自於 ARM 所收購的 Logipard
在Mali GPU 簡報中強調可以將 VE 的輸出直接作為 GPU 的 texture
DM上可以看出 VE 俱備了 Memory, ME, MC, Transform, Control, Parser, Output 等7個部份
由於具有彈性支援各式video format的特性
因此每個部份都具有相當的programmable flexibility
這樣的做法應該相當接近 configurable video codec 理想

buildroot - Enable setjmp/longjmp exceptions?

2009-05-27T09:23:00.000-07:00

這週花了大部分的時間在處理這件事上

繼先前share buildroot toolchain with others之後
接著近日又被詢問了 c++ compiler 的環境
當下看了看buildroot configuration 中 Toolchain 項目有著一行

[] Build/install c++ compiler and libstdc++?

心想著這應該不過 30 分鍾就可以搞定了
接著就是一連串疑問的開始

編譯過程中, 編譯 libsupc++ 時錯誤發生了

/tmp/ccxY0pxQ.s: Assembler messages:
/tmp/ccxY0pxQ.s:423: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:580: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:581: Error: duplicate .handlerdata directive
/tmp/ccxY0pxQ.s:948: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:949: Error: duplicate .handlerdata directive
make[5]: *** [eh_alloc.lo] Error 1

而即便以相似設定以 crosstool-ng 編譯也會在相同點出問題

以buildroot和錯誤訊息作為關鍵字搜索, 可以看到一些資訊, 然而無有效線索
只好嘗試往 source code 找尋蛛絲馬跡
最後找到的是處理 exceptions 相關的部份
於是檢視一下buildroot有關exception的設定, 同在 Toolchain 內有著另外一行

[*] Enable setjmp/longjmp exceptions?

該項目主要是在編譯 gcc 時增加了一個設定項目
--enable-sjlj-exceptions

簡單地說, 是以呼叫 setjmp/longjmp 的方式來作exception handling
而事實上 libsupc++ 亦是C++中處理exception的部份
雖然沒有繼續trace, 然而應該是該部份與 C library 的部份有衝突
所以這問題應該與 uClibc 是有相關的

另外, 如果不使用 setjmp/longjmp 的 exception handling model
則採用的是 call frame unwinding 的方式

這兩者間的差異和優缺就不多說了

Firefox on Netbook

2009-05-18T21:44:00.000-07:00

經調整後的Firefox 視窗顯示

儘管Google Chrome 推出了Linux版本, 有著快速的Javascrip Engine - V8
然而對Browsing 除了performance 外, user experience 也是很重要
firefox 3.5 之後將有新的 javascript engine - TraceMonkey
雖比不上 V8, 然而卻也沒有到顯著的懸殊差異
再加上Firefox 的擴充套件, 在使用便利性上Firefox還是較為方便
(長期倚賴, stylish, adblock plus, 新同文堂與 forecastfox)
但是chrome的外觀讓我瞭解一件事, titlebar 對於 browser的多餘
當然, 很多時候, 多餘的就不只是titlebar

儘管現在液晶螢幕尺寸越來越大, 然而Notebook卻是越來越輕巧
以個人長期使用EeePC 900 瀏覽網頁來說, 網頁顯示面積相當重要
1024x600 的解析度雖稱不上不足, 然而在垂直方向的顯示就相當吃緊
加上4+1大元件: titlebar, menubar, navigation bar, statusbar 和系統的 taskbar 佔去了不少空間
真正網頁顯示面積, 扣掉上面的元件部份, 恐怕只剩下不足500 pixel的高度
雖然我利用了Compact Menu 2 套件, 省去了menubar, 在網頁顯示高度上還是略顯不足

近日看到這篇文章, 感到相見恨晚, 既不失原有的功能性, 又能儘量縮減佔用的空間
於是就把Audohide Statusbar, Hide Caption 與 Hide Tab Bar 這些擴充套件安裝了
我想圖示就是這些套件最好的說明了

ofono - open source telephony stack (revised - 2009/05/14)

2009-05-12T08:09:00.000-07:00

在Android platform火熱的今日, Nokia同時走著不同的路
一方面以開放並且成立Symbian Foundation來強化Symbian平台
另一方面開發Maemo與收購Trolltech厚植自身Linux平台技術
再加上本篇主題的 ofono
顯見Nokia在平台佈局的規劃上,
一方面在於鞏固自身利基, 另一方面在於主導與開放

拜Nokia 之賜有著良好設計的 Maemo platform
而Qt 除了轉為 LGPL, 並且也加強與社群的互動

今日 intel 與 nokia 共同宣佈了 ofono 軟體專案
而對於ofono而言
如果說Android打破了手機軟體開發的硬體平台限制
那麼 ofono 要在長久封閉的電信服務上解放(Voice, SMS, Cell Broadcast...etc)

ofono 架構圖

ofono 採用的是 GPLv2 授權, 在API上使用D-Bus 介面 (因此GPL不會是大問題)
對於程式開發者, ofono提供使用電信服務的標準API;
而對於手機開發商, ofono提供標準plugin-in framework, 以加速開發整合產品

在官網上列出ofono API的四個原則

consistent (一致) : Interface properties 有著一致的操作介面
minimal (精簡) : 避免相同的目的有多種方式達成
easy to use (易於使用) : 儘可能的簡單, 讓程式開發者專注在軟體開發本身.
complete (完整) : 必須豐富且完整到足以開發功能完整的行動電話.

目前已有初期版本可以下載

ofono stack 的出現增加了許多可能性
語音通話, 簡訊就不再只是手機的專利,
而電信語音的應用上也會因為軟體創意, 將會更為多元

ofono的詳細資訊請參考linuxdevices

後記:
今日看到一則中文新聞 , 看到時差點沒當場笑出來
套句批踢踢的常見推文: 記者, 不意外
這篇是對 ofono project 相當錯誤的解讀
儘管我在文中也提到了面對Andorid, Nokia走了不同的路
然而這並不代表Nokia/Intel 推出的ofono 與 Android 是相衝突的
基本上ofono, android這是兩個層面不同的事情
更可以說在這樣的專案推出下,對 Android 是相得益彰
整合後, Android 平台也可以藉此提昇在電信服務上的應用性
所以無論是Nokia 的 Maemo, Intel 的 Moblin 與 Google Android 都能因ofono而受惠..

回到17歲 (17 Again)

2009-05-10T08:19:00.000-07:00

面對稱不上順遂的生活, 是不是會想要重新作選擇?
學生時代的精彩, 是不是讓你難以忘懷

周日晚跟老婆看了這部電影
事實上, 光看電影"回到17歲"的劇情簡介, 可以感覺題材並非新穎, 更可以說是老掉牙
甚至觀看劇中的內容,
在"回到未來", "扭轉奇蹟", "蝴蝶效應", "辣媽辣妹", "王牌天神" ... 等, 都可以看到類似的元素
然而這樣的劇情鋪陳依舊引人入勝, 帶來亮眼票房

人生就像是不可逆的化學反應, 現況就是過往的決定所累積的結果
很有趣的是, 往往人們都想知道, 如果能夠有不同的選擇, 結果又會是甚麼
當然, 沒有人真能如此,
因此人們也樂於寄情在電影多樣的詮釋之中, 而這也是這些電影的切入點..

年輕, 總有充沛的精神與體力, 有著對於未來的憧憬與無限可能
然而, 當一段時間過後, 未達理想的現實, 工作無所發揮的消磨
當好好地檢視, 會用甚麼樣的想法和心情去面對自己與周遭?
很多時候真正的答案必須探究自己的內心...

或許因為如此的題材本身帶著嚴肅的人生哲理,
因此需要用歡樂的題材去包裝, 我想這也是為何這類電影多是喜劇

謠言紛飛的Windows 7?

2009-05-08T09:42:00.000-07:00

今日除了Theora 修正forward DCT 的問題大幅提昇影像品質的新聞外
最吸引我的就是 Slashdot上的 Windows 7 "Not Much Faster" Than Vista
slashdot 引用了pcworld 的測試結果, 結果是Windows 7 並沒有比Vista 好到那去

測試的結論並不讓我感到訝異, 因為當微軟決定以Vista為Windows 7基礎, 改造時間又如此短暫
以Vista 龐大的新架構, 微軟只想花少少的力氣, 在短短的時間匆促上架, 如此就想改變局面!?
(想想XP 相容性問題, M$並不是以技術翻新架構來達成, 而是妄想用可笑的Virtualization砸錢方式帶過)

問題是Windows 7 就在beta 釋出後, 各種說法也紛紛出籠
速度大幅提昇, 硬體需求不高, 軟體相容性高各方面效能直逼XP 等等的說法紛紛出籠
(甚至是與XP相比, 但是XP 模式真的是很諷刺)
如此, 很難不去聯想有操作資訊的成分存在

說真的, 可以接受可笑的XP 模式, 不如裝個Ubuntu + VirtualBox 用無縫模式吧...

Debian 全面採用 EGLIBC

2009-05-06T19:06:00.000-07:00

今日看slashdot 看到了這則新聞
大意是Debian 將全面改用與glibc source/binary-compatible 的eglib
主要的原因可能是glibc維護者(Ulrich Drepper)與debian間的爭議
(Drepper 拒絕修正glibc一個關於 embedded的問題, 且出言不遜)
而文中的一個連結文章, 更洋洋灑灑數項採用eglibc的好處

長期使用linux的人應該對glibc相當熟悉
一直以來 glibc 在 GNU/Linux 世界中扮演著關鍵角色
或許因為世界改變得很快, glibc也面臨著考驗
除了eglibc, 還有 uClibc, newlib, dietlibc 甚至 Android的 Bionic libc
儘管如此, glibc 依舊保有重量級的地位 (至少desktop linux都是 glibc)
如今這樣的情形可能開始有變化

由於應用特性與硬體平台的多元
現今GNU/Linux不若以往那以 x86 為中心的時代
若Drepper不改變思維, 那具代表性的Debian 也只是起了個開頭
相信之後會有後續的連鎖效應

2009 台南行

2009-05-02T05:26:00.000-07:00

安平豆花

安平古堡

德記洋行

本blog轉型為吃喝玩樂blog (大誤)

趁著勞動節連假, 趁著天氣不錯開車帶著老婆往外跑
隔了兩年又再次回到台南市的街道
開車環繞成大附近的街道, 已經又有些不同
成大成功校區的圍牆消失了, 勝利校區有了新的宿舍

下午閒晃在成大週邊, 暖洋洋的天氣讓人充滿精神
而街道上點心/飲料/冰店家讓人垂涎欲滴
而車站前依舊人來人往, 深刻感受到府城的都市活力

相對於新竹工作(音近 "辛苦工作"!?)的生活
在這裡不用費心去找美食文章, 特意避開地雷(似乎貴又不好吃成了共同心得!?)
也不用去找假日往那去, 隨時都可以開始屬於你的觀光/古跡/藝文/美食小吃之旅

或許可以考慮規劃一段時日後到台南工作定居?

夏川里美 - 你的原點(故鄉)

2009-04-29T06:53:00.000-07:00

"心靈之歌"專輯封面為瑞芳車站一景

夏川里美最為台灣人熟悉的, 應該是已經廣被翻唱的"淚光閃閃"和"島歌"了

這個月月中下班開車聽廣播時
聽到新專輯"心靈之歌"的廣告, 當下覺得不錯就想要去買這張專輯
然而平時沒有時間跑唱片行, 而工作附近的家樂福也沒賣這張

就這樣拖到了上週末, 陪大姊去大潤發時看到了
回程放了來聽, 發現當時吸引我注意的是曲目的第一首 - "你的原點"
之後細看歌詞, 與曲風相當符合
再加上夏川里美輕亮柔美的歌聲, 為緊張忙碌的生活帶來一絲悠閒

你的原點(故鄉)

歡迎回來一定累了吧用南風包裡著你
母親依然沒有變在田中忙碌只是增加了幾莖白髮
漫步在出生至今的旅程上這是你的原點(故鄉)阿
要不要再一次再一次回去看看

不變的歌不論何時總是溫柔的海
連煩惱的事也隨之忘卻
遮蔽靈魂到手的東西真的真的就是重要的東西嗎?
再見了歡迎回來你該回去的地方在哪裡

過來這裡擦掉淚水我能瞭解你努力過了
偶爾和哥哥一起喝喝泡盛酒吧雖然知道你會不好意思

凝視從前搖盪過的鞦韆懷念起純真的自己
是不是如此正真直地一路走來

不變的歌不論何時總是溫柔的海
連煩惱的事也隨之忘卻
遮蔽靈魂到手的東西真的真的就是重要的東西嗎?
再見了歡迎回來你該回去的地方在哪裡

時代在逐漸擴張的黑暗中逐漸失去了互助
逐漸習慣了悲傷想要回去那個地方

不變的歌不論何時總是溫柔的海
連煩惱的事也隨之忘卻
遮蔽靈魂到手的東西真的真的就是重要的東西嗎?
再見了歡迎回來你該回去的地方在哪裡

share buildroot toolchain with others

2009-04-29T05:46:00.000-07:00

由於工作平台環境限制的緣故(見buildroot: 三個願望一次滿足一文),
所以當時採用了buildroot, 以利於產生toolchain與使用uClibc

當然, 單單在個人環境下使用buildroot不太會有問題
(意外是會接二連三發生的...:P)
最近要與他人co-work, 所以要把開發環境設好
天真如我, 反射性地, 就把 buildroot目錄下的 build_arm/staging_dir 打包後丟了出去
直到同事遇到了一堆 include/library search path 問題, 向我反映, 這才發現不妙
套句國見比呂的話, 現在才想要轉用crosstool-ng實在是太遜了
而使用alias 去傳入 sysroot 參數對於別人也不是好主意

問題發生的主要原因在於toolchain 對於 include/library search path找不到所需檔案
簡單的說, 就去觀察toolchain的path 設置, 並且把找不到的檔案放在適當位置即可
預設的include path可以透過 arm-linux-cpp -v 來取得
而library path 是由 arm-linux-gcc -print-search-dirs 取得

接著就是做一些file link or move
比較要注意的是libc.so 這個文字檔, 把裡面GROUP的path prefix 移除就可以了

anyway, 不這麼做的話, 比呂和英雄是不會對決的...
但是我們可不會水平外曲球, 下次還是改用crosstool-ng or scratchbox吧

0x1ab

2009-04-26T19:30:00.000-07:00

好一陣子前與jserv聊天談到他對於之後的規劃

他提到了0xlab, 該組織亦在今日也開了成立記者會

0xlab成員們自我期許開創出更好的軟體環境,為台灣提昇軟體技術紮根且與世界接軌

而這樣的抱負和理想也讓我聯想起現今失落已久的工匠精神

細看0xlab的專案細目, 涵蓋範圍相當廣,

從platform construction, software and compilation technology, robotics 到 computer graphics

不甚瞭解的人可能以為單單是充數的

這可是這群人一路走來累積的成果

可以如此說0xlab只是具體的組織化

在此之前, 它即已存在了

是的, 充滿理想抱負的行動, 比精心設計的講演更能感動和激勵人心

儘管規模並不大, 然而我相信會持續帶給人耳目一新的作品

Rocks the world! 0x1ab

zotero - 整理資料的好幫手

2009-04-20T08:48:00.000-07:00

由於手邊有不少電子文件檔案
起先也只是用OpenOffice 編個 spreadsheet 來歸類處理
問題在文件累積到一定的數量後開始出現

很簡單的問題像是, 假設你有兩個類別 linux 與 network
而當你拿到了"linux network programming guide" 的文章, 你會如何分類?
當然, 應該還是會歸類在linux類別, 但是心裡又覺得它應該也要有network屬性

這時心裡難免會想, 資料的整理功能若能像寫blog 或是 gmail的標籤一樣, 那該多好!?

有了這樣的需求, 當然就開始找方案
一開始是從file tagging著手, 但是看到了相關的方案(gnome/kde/tag2find...etc)
看了看又覺得太簡略了, 畢竟除了標籤外, 每個文件還有各字的屬性

就這樣, 中途還嘗試使用GcStar, 但是似乎又不太好用
之後的過程就看到了referencer, 雖是管理引用資料的程式, 但心裡已經覺得功能上很接近了
最後是在wiki的相關軟體比較列表看到了zotero

zotero的slogon為 The Next-Generation Research Tool
個人用過的感想是, 這樣的說法一點也不誇張
也建議好好看一下網路上的功能展示影片
相信一定會愛上這個擴充套件

最近找到這個套件後, 就開始使用zotero來重編手邊資料的索引
使用中發現超出預期的好用, 除了拿來寫論文引用
像我拿來管理資料的用途, 如果想要拿來管理會議記錄, 雜項資料也是不錯的
甚至功能上取代google notebook也是可行的
真的是相當實用的firefox套件

HiRadioTray Beta 20090417

2009-04-17T06:36:00.001-07:00

今晚做了些修正
主要是實作了mplayer slave mode控制
目前用在切換電台, 靜音與音量控制

另外新增了停止選項, 提示顯示目前收聽電台名稱
有時間改為使用home中的隱藏目錄
到時就會包成 deb file

有興趣請到此下載

HiRadioTray

2009-04-16T21:42:00.000-07:00

雖然個人偏好script, 但是....
Yeah..everyone loves GUI
昨晚花了點空餘時間(事實上被老婆念了一下),撰寫了HiRadio這支程式
程式目的跟hinet radio script一樣, 只是整合了GUI
目前的版本可到此下載
這只是堪用的初始版本

未來要透過mplayer的slave mode加上音量控制之類的選項
切換電台也會使用不同的機制, 另外建立.hiradiotray 目錄

有不錯的想法也歡迎提供

話說wxWidgets挺好上手的, 下午看文件學wxWidgets
晚上就把這支程式主架構完成了

Hinet radio script 20090414

2009-04-14T07:52:00.000-07:00

今日忽然發現連不上Hinet網路電台了
透過Firefox連上網頁, 看了看頁面全改了
看來Hinet 打算在Hichannel全面採用DRM了
看來臺灣網路電台被Hinet壟斷的苦果開始出現了....

今日依照這篇留言改了一下script
有需要者請到此下載

有時間得來想想其他solution了

linux porting for new ARM platform 簡報上線

2009-04-12T19:12:00.000-07:00

工作緣故, 這陣子將手邊關於在ARM平台上的Linux Porting過程,
以及收集到的相關資料整理了一番, 製作了份簡報

Linux Porting

View more presentations from Champ Yen.

Apr 23rd, 2009: slides updated for DMA and make use of slideshare

Essential Linux Device Drivers

2009-04-08T09:41:00.000-07:00

上一份的工作主要是個人踏入撰寫linux driver的起點
而Linux Device Driver的撰寫以往只有Oreilly 的 Linux Device Drivers 一書
(後簡稱LDD, 目前出到第三版)
個人在去年十月注意到2008年8月出版的Essential Linux Device Drivers(後簡稱ELDD)這本書
而這次的工作, 這兩本書也都用上了

個人的想法是:
LDD該書的內容, 比較偏向以linux kernel的角度來談linux device driver
對於了解driver 與 Linux系統內部行為以及底層的意義上相當不錯
然而在Device Model上, 對於現今Linux Kernel中眾多的Subsystem就顯得力不從心
相對地, ELDD這本書的內容比較單純的以Device Driver的角度
一開始系統的從kernel 提供 device driver的服務
接著切入 linux kernel中各個subsystem (從input, audio, video 到 PCI, PCMCIA)
對於想直接以device driver著手的人來說, 相較於LDD是值得列為優先閱讀的書籍
等上手之後再閱讀LDD以了解更深入的部分.

當然個人最推薦同時擁有這兩本切入角度不同的書

Embedded Linux Porting

2009-04-06T22:11:00.000-07:00

Framebuffer device 驅動後的Tux logo

使用PicoTK在Framebuffer上隨機繪圖(線圓/長方形, 實心圓/長方形)
來產生類似screensaver的效果

新工作一個多月了, 上面兩張圖是這一陣子來的工作成果
工作內容的緣故需要在工作平台上建構Linux 環境
儘管port過幾個embedded os, 針對embedded linux platform寫過driver
然而從頭到尾作Linux kernel porting這倒是頭一遭
兩張圖是porting後實作framebuffer device driver, 並且在kernel與application上的結果
(picotk的畫圓的過程, 是相當著名的演算法)

出乎我意料的是, linux porting相關的資訊並不算是豐富
有機會再在blog上分享一些心得

以下是boot log (敏感部份, 經過馬賽克處理)

Uncompressing Linux.........................

.. done, booting the kernel.
Linux version 2.6.27.15 (champ@champ-laptop) (gcc version 4.3.2 (GCC)
) #423 Fri Apr 3 15:05:02 CST 2009
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Machine: XXXXX XXXXX Technology XXXXXX processor
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 508
Kernel command line: mem=2M@0x1000000 initrd=0x1180000,161524
Trying to install interrupt handler for IRQ0
Trying to install interrupt handler for IRQ1
Trying to install interrupt handler for IRQ2
Trying to install interrupt handler for IRQ3
Trying to install interrupt handler for IRQ4
Trying to install interrupt handler for IRQ5
Trying to install interrupt handler for IRQ6
Trying to install interrupt handler for IRQ7
Trying to install interrupt handler for IRQ8
Trying to install interrupt handler for IRQ9
Trying to install interrupt handler for IRQ10
Trying to install interrupt handler for IRQ11
Trying to install interrupt handler for IRQ12
Trying to install interrupt handler for IRQ13
Trying to install interrupt handler for IRQ14
Trying to install interrupt handler for IRQ15
Trying to install interrupt handler for IRQ16
Trying to install interrupt handler for IRQ17
Trying to install interrupt handler for IRQ18
Trying to install interrupt handler for IRQ19
Trying to install interrupt handler for IRQ20
Trying to install interrupt handler for IRQ21
Trying to install interrupt handler for IRQ22
Trying to install interrupt handler for IRQ23
Trying to install interrupt handler for IRQ24
Trying to install interrupt handler for IRQ25
Trying to install interrupt handler for IRQ26
Trying to install interrupt handler for IRQ27
Trying to install interrupt handler for IRQ28
Trying to install interrupt handler for IRQ29
Trying to install interrupt handler for IRQ30
Trying to install interrupt handler for IRQ31
PID hash table entries: 16 (order: 4, 64 bytes)
console [ttyXXX0] enabled
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 2MB = 2MB total
Memory: 1036KB available (660K code, 45K data, 60K init)
Calibrating delay loop... 47.82 BogoMIPS (lpj=239104)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
done
Freeing initrd memory: 157K
fb0: XXXXXX frame buffer alive and kicking !
Serial: XXXXXX driver
ttyXXX0 at I/O 0xe0006400 (irq = 25) is a XXXXXX
Freeing init memory: 60K
sh: can't access tty; job control turned off
#

是的, 你沒看錯, 記憶體只有2MB
經過調整, 開機後還有600KB 左右的空間

過程中使用的是buildroot 建構toolchain, 以降低application的大小
有興趣的或是工作相關者, 歡迎討論, 並交換一下訊息與意見.

Hinet radio script 20090403

2009-04-02T22:39:00.000-07:00

昨天還可以聽的. 今日發現怎麼也連不上

是的Hinet又更動了連結方式

如有需要最新的script 請到此下載

OpenGL ES 2.0: Hello Triangle!

2009-03-18T06:36:00.000-07:00

上圖是OpenGL ES 2.0 Programming Guide第二章的範例
書中的範例是使用AMD OpenGL ES Emulator
很可惜的是AMD的OpenGL ES SDK僅只提供Windows平台版本
個人是使用PowerVR OpenGL ES SDK

除了書中的範例外也參考了PowerVR提供的example寫成
將書中使用而無Linux版的esUtil部份補上, 完成整個example
提供在Linux上學OpenGL ES 2.0的另一途徑
Linux版的範例請在此下載
懶得寫Makefile 可以覆蓋PowerVR SDK的example編譯

未來希望能夠將整個esUtil 在Linux上實做
(有部份是OS independent ex:Transform)

shader的方式是比以往透過function來得到效果, 顯得彈性且自由多了...:)

OpenGL ES 2.0 Programming Guide

2009-03-10T21:52:00.000-07:00

上次個人寫OpenGL程式, 已是碩士班時期的事情了
那時還停留在OpenGL 1.x, 因此對於2.x可說是知悉甚微....

由於beagleboard所用的OMAP3530的緣故
(OMAP 3530 使用 PowerVR 的3D Accelerator)
個人開始注意到OpenGL ES 2.0
與OpenGL ES 1.x 源自OpenGL 1.5不同
OpenGL ES 2.0 源自於OpenGL 2.0
而上圖的OpenGL ES 2.0 Programming Guide,
可以說是目前唯一的參考書目了

而稍微看了一下簡介
OpenGL (ES) 2.x相對1.x強調programmable pipeline以及shading language
一些範例也相當有趣, 而OpenGL 與 OpenGL ES間的相容性是相當不錯的
以OpenGL ES 2.0作為另一個起點, 似乎是不錯的選擇

苦無OpenGL ES 2.0的硬體練習嗎?
沒關係PowerVR貼心地提供了PC Emulation SDK(Linux/Windows Platform)
let's OpenGL~

Choice of Programming Editor

2009-03-10T09:38:00.000-07:00

最近又得長時間在Windows下寫程式, 所以又做了editor的survey
吃寫程式這行飯的人, 因為必須長使間使用code editor
對於用來編寫程式的環境, 多多少少有自己的偏好和選擇

個人很羨慕我相當好的朋友, 在碩士期間習得vim大法, 搭配tag, cscope
在windows上有gvim, 回泛Unix環境也如魚得水, 各種環境應該對他都不是問題

很可惜, 個人沒有這麼勤勞去學習, 只會用用簡單的GUI Editor
很多人都習慣使用Source Insight 或是微軟的 Visual Studio環境
個人盡量不去使用非法軟體, 而又不想被綁在M$的牢籠中
因此多半是靠著Makefile + Scite作為主要開發環境
想學已久的cmake也還沒開始啃 ^^;

而對於初學者以及一些Programmer而言
整合開發環境(IDE:Integrated Development Environment)是不可或缺的
長久以來, 我一直都停留在Eclipse/Anjuta/KDevelope的印象
也或許因為疏於注意, 這類工具我從來沒有好好學習和使用過
近日看了看Wiki的IDE比較表, CodeLite/CodeBlock倒是相當吸引我的興趣

看來是該找時間把 cmake/eclipse/(codelite or codeblock) 好好地學一學

對了, 還有QT近日最新力作QT Creator, 看來也是不錯的工具

buildroot: 三個願望一次滿足

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

由於新工作開始了, Prex的部份以後會慢慢推進
(目前mp3 decoder ok了, 還要弄audio driver/daemon)
而buildroot就是因為新工作的內容而開始接觸 (以前就聽過, 只是一直沒機會去玩.)

在開發embedded system中, crossplatform toolchain的選擇是相當重要的一環
在數年前, 產生對應平台的 gcc cross toolchain是相當麻煩的一件事情
glibc/gcc/binutils..版本的排列組合有可能會造成不同的問題
(ex: compiler編不過, compiler編完了不能編kernel)
因此需要花時間嘗試組合, 找到較佳的組合, 過程冗長繁複
而這幾年來令個人印象深刻的是Dan Kegel當時所撰寫的build script
方便的設定, 大大地簡化了如此測試的程序

現今cross toolchain可以說垂手可得了, 相當方便
稍微google一下就可以得到不少訊息和編譯好的工具
像是移植prex的過程中, 個人選擇CodeSourcery的Toolchain
主要的目標硬體平台(x86, ARM, MIPS, ColdFire, PowerPC)都有
也貼心地提供Linux/Windows兩種版本,
而CodeSourcery也隨著時間不斷地提供新版本和新平台的支援
不想親自動手準備相關環境情況下, 算是相當高品質的選擇

對於Embedded Linux而言, 除了toolchain, kernel外
除了Toolchain還得張羅root file system
buildroot提供相當方面的介面(類似編譯linux kernel的menuconfig), 滿足這三種需求
buildroot是uClibc的相關project, 提供uClibc-based的gcc toolchain
相對glibc/gcc所建構的環境, 在所需空間上節省不少
而且也編譯好busybox, 方便迅速地建構適用的環境
套句廣告詞: 三個願望一次滿足!

另外, 除了CodeSourcery toolchain, buildroot 外, Scratchbox也是不錯的選擇
而較龐大且全面的Embedded Linux專案可以考慮OpenMoko所採用的OpenEmbedded

Embedded FAT implementations

2009-02-17T05:00:00.000-08:00

並不是所有的embedded system都具有良好的file system support, 在此方面使用FAT 還是相當普遍. 而使用FAT的原因相當簡單, 因為FAT 沒有複雜的設計, 降低實做的code size, 多數3C產品與一般OS屬於預設的支援.

目前屬於Open Source FAT implementation有下
ELM - FAT File System Module
具有相當不錯的介面設計, 很接近一般VFS的介面
具有格式化功能, 算是相當完整的實做
並無明顯的授權聲明, 在source 中的 readme.txt 聲明自負風險下不限制使用於任何用途

EFSL - Embedded File System Library
有相當完整的文件說明
授權: LGPL

libfat
授權: GPL

dosfs
source中的readme.txt 聲明自負風險下不限制使用於任何用途.

Prex - FAT32

2009-02-15T08:48:00.000-08:00

原本是打算將ELM FAT implementation移植到Prex上
然而因為Prex的Embedded VFS設計的緣故(該設計相當接近於VFS in Sun Unix),
若採用整合ELM FAT的方式需要相當的時間
而其中原因在於資料結構上的考量
因此就改為直接修改Prex本身具有的FAT 12/16以支援FAT32
如此還能針對FAT深入瞭解

而經過數日的奮戰
目前Prex 已經能夠操作 FAT32 檔案系統
也簡短地測試過, 檔案/目錄的新增移除是正常的
尚未支援用以輔助配置free block的 FSINFO以及長檔名的LFN(Long File Name)
有機會再把實做補上
由於處理FAT32的緣故, 研讀了些關於FS的相關資料
而先前所提到的書 File System Forensic Analysis 也幫助不少
另外下列資訊也有相當得助益

boot log如下:
Prex version 0.8.1 for arm-at2440ii (Feb 12 2009)
Free pages:
start end size
-------- -------- --------
00000000 - 00010000 64K
00033800 - 01c27000 28622K
01c39c00 - 04000000 36633K
used=142K free=65319K total=65461K
Time slice is 50 msec
IRQ10 attached priority=10
Clock rate: 1000 ticks/sec
Prex driver module built: Feb 12 2009
Calibrating delay loop... ok count=837
Initializing NULL device
Initializing Power Management
pm: Default power policy is performance mode
Initializing Zero device
Initializing Serial Console
UBRDIV0:0x23
IRQ28 attached priority=1
Initializing RAM disk
RAM disk at 0x01c270e0 (74K bytes)
Initializing SD card
Init. SD Freq. is 401256Hz

In idle
MMC check end!!

In SD ready

End id
RCA=0x9ffc
SD Frequency is 33304320Hz

In stand-by

****4bit bus****
SD disk
IRQ21 attached priority=2
Initializing TTY device
Driver initialized
Loading task:'boot'
Loading task:'proc'
Loading task:'fs'
Loading task:'exec'
Starting Bootstrap Server
Starting Process Server
Starting File System Server
Starting Exec Server
boot: Mounting file systems
VFS: Mounting ramfs dev= dir=/
VFS: Mounting devfs dev= dir=/dev
VFS: Mounting arfs dev=/dev/ram0 dir=/boot
VFS: Mounting fifofs dev= dir=/fifo
VFS: Mounting fatfs dev=/dev/card0 dir=/mnt/floppy
fatfs_mount device=/dev/card0
0 1 1 0 b 1f fd f7 3d 0 0 0 c3 42 1e 0
fatfs partition at sect: 3d
----- FAT 12/16/32 info ----- 3c673
drive:80
total_sectors:1983170
heads :32
serial :49984554
cluster size:8 sectors
fat_start :5d
root_start :2
data_start :f77
fat_type :FAT32
fat_eof :0xfffffff

boot: Run init process
Prex version 0.8.1 (arm-at2440ii)
[prex:/]# cat /mnt/floppy/champ.txt
fatfs_lookup: name=champ.txt
fat_lookup_denode: cl=0 name=champ.txt
fat_lookup_dirent: Ac
fat_lookup_dirent: found sec=3959
fatfs_lookup: cl=4
fatfs_read: vp=38e3c
Hello World!
fatfs_read: vp=38e3c
[prex:/]#

File System Forensic Analysis

2009-02-11T19:24:00.000-08:00

目前個人正嘗試修改Prex上的FAT 12/16實做, 以便支援FAT 32. 過程中, 很令我很訝異的, 儘管FAT廣為人知,良好解釋FAT的文件卻付之闕如. 雖然, FAT 相關實做已經非常的多, 網路上相關的訊息卻非常零散且難以消化, 缺乏有系統和概念性的完整資訊.

File System在各種實際應用系統中, 都扮演著舉足輕重的角色. 從系統效能, 到基本的資料保存, 都與File System 息息相關. 然而很可惜的, 對於File System而言, 許多人的印象似乎只是附屬的存在, 常常容易被忽略.

那麼非得下去好好trace code才能獲得相關知識? 對於File System有興趣研究的人該怎麼下手?對此File System Forensic Analysis是關於FS相當不錯的參考書目, 該書除了提供目前主流各式File System的說明外, 也提供了相關的基本知識, 在章節的規劃與內文的易讀性, 都相當不錯. 目前市面上專注於此方面的書並不多, 而部份甚至已經顯得過時. 對FS有興趣者, 相當建議購買一本來閱讀.儘管許多進階的檔案系統(ex: ext4, xfs, zfs) 沒有納入介紹, 然而書的內容對於瞭解這些FS的設計與規劃也有相當的助益.

S3C2440A - SD Card works on Prex!

2009-02-09T06:43:00.000-08:00

參考著Samsung的測試程式與u-boot, 把SD driver for prex 移植完畢
目前使用的是處理read/write interrupt的方式完成實做
一開始是採用使用DMA方式實作, 然而碰到無法讀寫完畢
像是read counter會有尚未讀出的資料, 而停留在Rx Active的狀態
今日全部改寫後就可以使用了, 日後會多花時間在blog上撰寫文件與porting過程

日後會實做AC97 driver與 Audio Server
接著就是完成所設定目標的CLI MP3 Player

prex本身有FAT16的支援(之後有打算將fat32移植上去)

以下是開機到把SD Card上名為TEST.TXT的檔案內容印出的過程

Prex Boot Loader V1.00
loading: hdr=01c02008 module=000030e4 name=prex
loading: hdr=01c0a290 module=00003114 name=dev.ko
loading: hdr=01c0e260 module=00003144 name=boot
loading: hdr=01c0fe78 module=00003174 name=proc
loading: hdr=01c12a38 module=000031a4 name=fs
loading: hdr=01c21880 module=000031d4 name=exec
bootdisk base=01c26358 size=000128bc
kernel_entry=00010074
Entering kernel...

Prex version 0.8.1 for arm-at2440ii (Feb 9 2009)
Free pages:
start end size
-------- -------- --------
00000000 - 00010000 64K
00032c00 - 01c26000 28621K
01c39000 - 04000000 36636K
used=140K free=65321K total=65461K
Time slice is 50 msec
IRQ10 attached priority=10
Clock rate: 1000 ticks/sec
Prex driver module built: Feb 9 2009
Calibrating delay loop... ok count=837
Initializing NULL device
Initializing Power Management
pm: Default power policy is performance mode
Initializing Zero device
Initializing Serial Console
UBRDIV0:0x23
MMC check end!!

In SD ready

End id
RCA=0x9ffc
SD Frequency is 33304320Hz

In stand-by

****4bit bus****
SD disk
IRQ21 attached priority=2
Initializing TTY device
Driver initialized
Loading task:'boot'
Loading task:'proc'
Loading task:'fs'
Loading task:'exec'
Starting Bootstrap Server
Starting Process Server
Starting File System Server
Starting Exec Server
boot: Mounting file systems
VFS: Mounting ramfs dev= dir=/
VFS: Mounting devfs dev= dir=/dev
VFS: Mounting arfs dev=/dev/ram0 dir=/boot
VFS: Mounting fifofs dev= dir=/fifo
VFS: Mounting fatfs dev=/dev/card0 dir=/mnt/floppy
boot: Run init process
Prex version 0.8.1 (arm-at2440ii)
[prex:/]# cat /mnt/floppy/TEST.TXT
Hello World !!

[prex:/]#

S3C2440A - Memory Address Space

2009-02-04T23:48:00.001-08:00

S3C2440A的Memory Address Space的分佈有兩種模式
基本上兩種模式主要的位置分佈都相同
SDRAM都是分佈在 0x30000000 ~ 0x40000000

不同的僅是 0x0 位置對應的裝置
兩種模式取決於是否使用boot from NAND FLASH
當使用Nand開機時, 0x0 對映的是 4KB 的 SRAM
而不使用Nand開機時, 0x0 對映的是 ROM
(手邊的板子是先前發售的版本, 附有2MB NOR FLASH, 新版本的目前已經不附了, 猜想u-boot是寫入NAND中)

對於S3C2440A惱人的一點就是:
無論如何DRAM的起始位置都固定於 0x30000000
而且沒有提供硬體 remap 的功能
(許多IC具有選擇將ROM or DRAM map 到 0x0 的設定, 方便開機後將ARM環境交給DRAM)

這對於後續要放置的 Exception Vector 比較麻煩
目前沒有特別測試是否SRAM內能否直接放置 Exception Vector
而若寫死後固定放入NOR中, 如此對於之後更新擴充上比較麻煩
不管系統為何都需要遷就放置NOR中寫的處理位置
如此Exception處理速度上變得是需要作兩次branch
對於效率上來說有相當的傷害, 稱不上好的方式
(網路上有人使用這種比較拖泥帶水的作法)

S3C2440A既然使用了ARM920T
具有MMU, 這就是一個漂亮簡單的解法
當使用MMU時, CPU所產生的address皆為 virtual memory address
透過MMU轉換產生physical memory address, 存取適當位置

關於ARM MMU的設定在ARM Architecture Reference Manual 中有詳細的說明
這裡只作簡單說明

ARM MMU Level 1 table 將以1MB 為單位作為對映單位, 管理4GB 定址空間
因此需要 4GB/1MB * 4 = 16KB 空間, 而alignment亦為16KB

每個Entry 有三種選擇可以設定, section, coarse, fine
section: 直接對映連續 1MB 空間到指定的位置
coarse: 指定level 2 table所在位置, level 2 中每個位置指定page size為 64KB/4KB 的page table的位置, table 大小為 1KB ((1MB/4KB) * 4 = 1KB), alignment為 1KB (若page size為64KB, 需要重複每個entry 16次)
fine: 在ARM VMSAv6中已經不支援此設定, 與coarse 相似, 但page size為 4KB/1KB, 而level 2 page table 大小為 4KB ((1MB/1KB)*4 = 4KB), alignment 為 4KB (若page size 為 4KB, 每個entry需要重複4次)

MMU的主要用途不用多說, 在OS教科書中都有說明
主要是透過每個中process的page table建構屬於每個process獨立的 virtual memory space
在embedded system中還有一個用法. 就是建立global page table統一管理記憶體, 解決記憶分配造成的fragmentation, 將physical address不連續的page解釋為連續的空間. 亦可以用此方式管理, 以產生physical address連續的空間提供給hardware使用

對於S3C2440A, 最簡單的方法即是建立一個global的level 1 page table, 並且使用section 方式, 將physical address 0x3000000 map到 virtual address 0x0, 即可正常處理各種exception

S3C2440A - Clock & Power Controller

2009-02-04T06:46:00.000-08:00

原本要撰寫SD Driver for prex, 但是看到test program中SD部份必須清楚知道PCLK
因此先花時間搞清楚S3C2440A關於Clock的設置與目前設定

這裡只列出Programmer 需要注意的地方

S3C2440A 中 Clock Controller 負責產生所需的 clock signals
包含提供給CPU的FCLK, 給AHB週邊的HCLK, 給APB週邊的PCLK
S3C2440A 有兩組PLL, 一組提供FCLK, HCLK, PCLK, 另一組提供給USB(48MHz)

這裡Clock Manager的設定將直接影響到CPU 頻率與後續需要注意PCLK的週邊(Ex:UART, Timer, SD )的設定

手邊的AT2440-II 使用的 oscillator freq = 16.9344 Mhz

輸出頻率取決於 M/P/S divider
Mpll = (2*m*Fin)/(p*(2^s))
m = M (the value for divider M)+ 8, p = P (the value for divider P) + 2

文件列出了數種設定組合方便programmer 使用
Output Freq. MDIV PDIV SDIV
47.98 MHz 60(0x3c) 4 2
95.96 MHz 60(0x3c) 4 1
266.72 MHz 118(0x76) 2 2
296.35 MHz 97(0x61) 1 2
399.65 MHz 110(0x6e) 3 1
530.61 MHz 86(0x56) 1 1
533.43 MHz 118(0x76) 1 1

(47.98/95.96 為 48/96近似值, 提供USB使用 (48Mhz) )
而HCLK/PCLK 取決於 CLKDIVN 中的HDIVN 與 PDIVN
HCLK 可為 1, 1/2, 1/3, 1/4, 1/6, 1/8 FCLK
PCLK 可為 1, 1/2 HCLK
UCLK 可為 1, 1/2 UPLL

測試後顯示, 板上的u-boot boot後設定值為 399.65Mhz
(Mpll = (2*(110+8)*16.9344)/((3+2)*2) = 399.65184 Mhz )

此外Clock Controller 提供四種模式
Four Modes
* Normal:
Clock Controller提供CPU, 週邊 clocks
當啟動所有週邊, 功耗將達到最大值
* Slow :
Non-PLL模式, 使用外部clock (XTIpll or EXTCLK)作為FCLK
* Idle :
停止提供FLCK給CPU, 僅提供週邊
* Sleep :
停止內部電源, 除了wake-up 電路, 其他部份皆無電源消耗

S3C2440A

2009-02-02T18:32:00.000-08:00

瞭解硬體的功能特性對於撰寫移植或是撰寫embedded system是必要的
選擇S3C2440A的原因, 僅只是因為向友人借的EVB使用的是這顆IC

詳細的datasheet可以到此下載
簡單敘述S3C2440A的硬體特性為:

ARM920T core
AC97 codec
SD interfacce
RTC
USB Host/Device controller
LCD controller
Uart

ARM920T詳細資訊可以在ARM官網上取得

另外建議手邊有著下列書目以便參考使用

ARM Architecture Reference Manual 2/e (ARM官網這裡有免費的第一版)
ARM System Developer's Guide
ARM Procedure Call Standard (ARM's Calling Convention)

前言

2009-02-02T18:20:00.000-08:00

拋開可以查閱Wiki或是IEEE而來的無聊制式定義
每個資訊從業人員對於embedded system都有著或深或淺的認知, 而各自有著用以理解它的一套思維. 然而除了親自去trace一窺究竟, 更甚者去coding之後, 才能深刻體會其中所充斥的挫折與饒富的樂趣所在.

不得已而接觸它的人可能會覺得複雜, 麻煩, 不知所以, 沒有規則; 樂在其中的人卻也喜於享受它的多種樣貌,抽絲剝繭的趣味, 欣賞巧奪天工的設計, 或是一手掌握的成就感. 是的, embedded system就是這麼樣地讓人又愛又恨.

對於許多人而言, 在desktop 上使用SDK, 熟悉的語言加上各式的library/framewrk, 從coding, compilation, linking產生程式到 load-in & execute 的一氣呵成, 一切是那麼方便, 是那麼的理所當然.如此一來, 那些曾囫圇吞棗背念的computer organization/architecture, compiler, system Ssoftware, operating systems, 在現今分工細膩且功能完善的OS與toolkit中, 似乎還顯得有些多餘. 的確, 現今Linux/Windows這樣desktop-oriented的OS也走入了embedded system領域, 但即便有心深入, 不考慮封閉性, 對大多數人來說, 無論Linux/Windows都顯得過於龐大且複雜. 對於系統著實難以一窺其精妙, 例如想把Linux Virtual Memory Management看到有所心得是一件不小的工程, 這樣作有時也難免有著見樹不見林的缺憾. 而使用Linux/Windows的硬體成本較高, 在應用上也有不適合的時候.

如此說法, 並非是要拋棄Linux/Windows, 一切要從頭來過.
畢竟在許多方面有其應用層面的考量. 而embedded system的樂趣之一在於, 透過實作所獲得的應用性外, 經由設計良好具體而微的embedded system也能夠讓自己更瞭解整體系統, 自硬體平台到軟體系統的設計與來龍去脈也能夠有更深一層的認知. 如此即便再面對Linux/Windows也有不同層次的心得, 或有提綱見領之效. 也因為如此, 反過來說, 面對embedded system, 對於軟硬體所需要的瞭解與面對的問題更甚於開發一般desktop application.

Plan

2009-01-22T07:34:00.000-08:00

由於正處於一段空檔時間, 除了休息外, 也做了一些規劃
當然, 不外乎唸書, 念英文, 為了在專業能力上的精進
所以個人也規劃了兩個個人專案

1. Prex on AT2440-II

Fig: Prex 在 AT2440-II上運作情形

這個專案的目的主要在於期望自己對於軟硬體的系統有更深一層的認識
設立的目標有

OS porting
SD/MMI device driver
FAT32 file system
Audio device driver
MP3 playback
Memory Management
Power Management

在這一週來已經有基本的實做, OS port已經完成, Prex本身已經能夠在板上運作
日後會補足porting過程, Prex/S3C2440的細節介紹
未來是著重於實做與文件的撰寫, 並且完成進一步的目標

2. BeagleBoard
前一陣子取得了Rev.B7的板子
OMAP3530-based的平台, 而且目前已經有相當多的軟體資源
專案目標在於讓自己熟悉幾點

ARM NEON technology
DSP programming model, ex: TI OpenMax IL implementation
embedded linux
Android (System, OpenCore)

總之, 一個專案比較講求底層基礎技術, 另一為追求高階系統整合架構所設立的目標