Xubuntu On MSI CX420

近日由於工作需要編譯 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 介面

近日注意到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 壓縮資料格式概論

每個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.

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

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

在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 去...

個人於上個月底離職了
主要因素是需要一段時間休息運動和調養身體
這段空檔時間, 按照慣例一樣作了一些目標設定
算是去年一月空檔時弄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去
過了有理想的年紀 架構翻新不如穩定
架構沒有那麼容易 才會特別讓人著迷
剛出社會的年紀
曾經最用心 所以最開心 曾經