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

(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 的另一觀點

今日很榮幸受到先前在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 - 網路作業系統時代的來臨?

回想當年, 微軟為了擊敗如日中天的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

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 語言的進化

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

在兩年前的拙作"到底 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 原始碼

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

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 還是比較好用

我家的妹妹


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

這版是新增預約錄音前的整理版本
本版本開始產生 .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

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

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

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

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

近日改裝了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 簡報上線

從決定開始要 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

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

當初構想中的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

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

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

Android 1.6 on Zaurus C750 - Basic System Works!

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 如今又能拿來做些甚麼?
然而相關軟體都已經過時許久, 而且也無持續更新
而規格與軟體不開放, 就算有心也難為無米之炊

這就是淺景深(錢井深)

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

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

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

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

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

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

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

Linux SD/MMC Driver Stack

View more documents from Champ Yen.

Mesa 7.5 released

著名的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

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

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

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

雜記

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

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

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

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

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

Shading Language Prework - 3D Math

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

週二參加了這個活動
簡單的說, 這是 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?

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

繼先前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

經調整後的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)

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

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

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

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

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

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

謠言紛飛的Windows 7?

今日除了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

今日看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 台南行

安平豆花

安平古堡

德記洋行



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

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

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

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

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

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

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


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

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

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




你的原點(故鄉)

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

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

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

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

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

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

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

share buildroot toolchain with others

由於工作平台環境限制的緣故(見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

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

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

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

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

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

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

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

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

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

在此之前, 它即已存在了

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

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

Rocks the world! 0x1ab

zotero - 整理資料的好幫手

由於手邊有不少電子文件檔案
起先也只是用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

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

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

有興趣請到此下載

HiRadioTray

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

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

有不錯的想法也歡迎提供

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

Hinet radio script 20090414

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

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

有時間得來想想其他solution了

linux porting for new ARM platform 簡報上線

工作緣故, 這陣子將手邊關於在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

上一份的工作主要是個人踏入撰寫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

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

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

是的Hinet又更動了連結方式

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

OpenGL ES 2.0: Hello Triangle!

上圖是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

上次個人寫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

最近又得長時間在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: 三個願望一次滿足

由於新工作開始了, 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

並不是所有的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

原本是打算將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 也幫助不少
另外下列資訊也有相當得助益

• Master Boot Record
• Microsoft FAT32 Spec
• The FAT File System
  

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

目前個人正嘗試修改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!

參考著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

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

原本要撰寫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

瞭解硬體的功能特性對於撰寫移植或是撰寫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)
  

前言

拋開可以查閱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

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

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)
  

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