Fred's blog

話說，Android 在某個版本後，開始提供了 USB Host API，這代表開發者可以不必再用 NDK 和硬梆梆的 C 語言去開發 USB 裝置的驅動程式，而可以完全用 Java 來開發。但是，現實往往沒有這麼美好。 日前，就協助了一個案子，解決了一個 USB 裝置驅動程式的問題，起因就是客戶用了 Android USB Host API 去控制 USB 裝置，但發現 USB 裝置的回應一直不如預期，有時像是掉資料，有時像是沒反應。而同樣的控制邏輯，用純 C 開發的驅動程式配上 libusb 就完全正常，所以我們相信肯定不是控制邏輯上的問題。 剛開始，大家都懷疑是 Java 本身的問題，懷疑是不是 JVM 執行驅動程式太慢，而造成接收 USB 裝置的資料時來不及。但我一直保持著懷疑，因為 USB 裝置回傳的資料並不多，如果 JVM 本身的效能連處理這幾 KB 的資料量都如此差，就實在是太可笑了，我無論如何不相信。 還好最後還是解決了，雖然過程曲折。 USB Request Block 的 16KB 限制 事實上，每次最多傳送 16KB 資料，是一個 bulk transfer 的 URB 限制，使用 Android USB Host API 就會直接遭遇到這個問題，所以不管用什麼方法，怎麼收資料，只要資料太大，你最多一次就只能收到 16KB。 多次收資料所發現的延遲問題 當然，既然一次最多只能收 16KB，我們可以分多次向 USB 裝置要求收資料，但就會發現會莫名掉資料。從 USB 的分析器上來看，該有的命令都有，但就是有掉，後續的資料不管怎麼取都是 0。 後續資料為 0，在這個案子的 USB 裝置設計上是可以理解的狀況，因為該 USB 裝置只會保留資料一小段時間，然後就會清空，所以若之後跟它要任何資訊，他都會回傳空的東西回來。這很明顯，就是我們要資料的過程時間，已經超過了該 USB 裝置正常的情況。 而從收到的資料來看，有收到的資料，經驗證過後發現是斷斷續續的，中間有漏資料。經過測試，發現是每個命令之間的間距時間太長，因為該 USB 裝置會不斷復寫一段緩衝區，如果我們太慢去要資料，那段緩衝區就會被新的資料蓋掉，理所當然的，我們就會漏掉一些資料。 經過各種測試紀錄，很明顯的，Android USB Host API 並沒...

當你得到 Cubieboard 後，首先要做的就是學習如何啟動你的作業系統。Cubieboard 可以支援 SD Card 啟動，這通常也是最容易入門的 Embedded System 開機方法。你只要準備一張 Micro SD Card，切割出分割區，然後把 Bootloader 和作業系統放進去即可。 安裝 u-boot Cubieboard 使用的是 u-boot 做為 bootloader，你必須先下載 Source Code 然後 Compile： git clone https://github.com/linux-sunxi/u-boot-sunxi.git make Cubieboard CROSS_COMPILE=arm-linux-gnueabihf- 如果你的系統 toolchain 都已經安裝完成，且都沒有問題，u-boot 會順利編譯通過，然後你會在 u-boot 的目錄裡得到兩個檔案： spl/sunxi-spl.bin u-boot.bin 有了這兩個檔案，安裝 u-boot 就不是什麼問題，只需要使用 dd 指令來把 bootloader 寫入 SD Card： dd if=spl/sunxi-spl.bin of=/dev/sdb bs=1024 seek=8 dd if=u-boot.bin of=/dev/sdb bs=1024 seek=32 註：/dev/sdb 是 SD Card 的裝置路徑，請依照你系統上的實際狀況，填入正確路徑。 後記 有趣的是，很久沒有玩開發板了，自從兩年多前開始陸續投入各廠商的專案後，所碰到的 ARM Board，清一色都是客製化的產品樣板。而幫大廠商做產品，和自己玩開發板相當不一樣，同樣是驅動程式有問題，要做的是打電話罵人；如果會當機，快打電話罵人；如果缺任何東西，打電話罵人就對了！所以，在客戶的專案中，做最多的總是證明硬體廠商的問題，讓硬體廠商們心甘情願幫你把問題排除。雖然還是要熟悉 Debug 的技巧，但多半不用自己煩惱『該怎麼辦』，只需要下指導棋。因此，自己也慢慢養成很多惰性，除非是真的沒人可以幫你，才肯親自出手跳下去從底層到應用程式，深入修正問題。 但是，玩開發板可不是這麼一回事。有問題？你自己搞定吧。搞不定？問 Google 大神吧。還是不行？慢慢看...

最近接了一個小案子，主要是協助客戶將 Qt 應用程式從舊板子移植到新的硬體上，由於硬體是 Third-party 做，當然所有的驅動程式也是由別人處理，我們並不經手，只和硬體廠商密切合作。 這次我們碰到了一些 Keyboard 問題，一開始是 Linux driver 缺少 input_sync() 的操作，導致 Qt 無法正確辯別按鍵的『壓放』。接著碰到個更棘手的問題，就是 Qt 送到應用程式的 Key 事件（Event）有很大機率會送錯。這將導致按鍵所觸發的結果，有很大的機會我們無法預期。檢查過 evdev event 和其發出來的 keycode，我們確定了 Linux Driver 是正確的，判斷應該是 Qt 的問題。 經過一番檢查後，發現是因為 Qt-Embedded 預設使用 TTY Driver(qkbdtty) 去驅動鍵盤，大部份情況下不太會有問題，但因為我們走的是標準的 Linux evdev (/dev/input/eventX)，如果很快速或多重觸發鍵盤按鍵，就有可能讓 Qt 的 TTY Driver 取樣和解析出錯誤的 Event 值。最快的解決辦法就是捨棄 Qt TTY Driver，然後改用 Qt  LinuxInput Driver(qkbdlinuxinput)。 不過 qkbdlinuxinput 並不處理 VT，這是與 qkbdtty 最大的差異，此舉會造成板子上的 Console 不正常切換，Debug 用的 Console 會因此壞掉。筆者在此對 QWS Keyboard Driver 做了些修改，讓 tty driver 使用 linuxinput driver 的方式去解析 keyboard event，並保留 VT 的處理機制。 Patch 檔案連結如下： http://fred-opensource.googlecode.com/git/patches/qkbdtty_qws.patch

寫一支程式在 User Space 下列出目錄中的檔案清單相當容易，我們可以用 readdir() 去一項項取得檔案內容，事實上， readdir() 是由 Linux Kernel VFS(Virtual Filesystem) 所提供的 API，真正的實作在檔案系統的核心模組(Kernel Module)中。然而因為 Kernel readdir() 的相關實作牽涉到 Kernel/User space 的資料交換問題，所以如果我們是在撰寫 Kernel 的驅動程式，當然就不能使用這系列的 APIs。不過也因為所有的資訊都存在於 Kernel 的資料結構中，我們可以直接從記憶體中的 Linked list 中快速取得檔案清單。 在取得某個目錄下所有檔案資訊前，要先得到該目錄的敘述 struct dentry，VFS 用 struct dentry 的串聯組合來描述整個檔案系統的目錄結構，檔案清單則被保存在 dentry 中的 Double Linked List，因此其實只要知道如何使用 Kernel 提供的 Double Linked list，就能得到該目錄下所有的檔案資訊。而這邊要注意的是 Kernel 提供的一個通用 Linked list 結構（struct list_head），用來統一整個核心的 Linked list 操作機制，這檔案清單的 Double Linked List 就是使用這通用的結構。 這裡是 Linux Kernel 2.6.37 中 dentry 的資料結構（定義在 linux/dcache.h，其中較不重要的部份以『...』做省略，此外，某些定義與較早版本的 Kernel 有所差異，將在文章最後補上說明）： struct dentry { ...省略 struct hlist_node d_hash; /* lookup hash list */ struct dentry *d_parent; /* parent directory */ struct qstr d_name; struct list_head d_lru; /* LRU list */ /* * d_child and d_rcu can share memory *...

As you know, I've done Android Eclair porting for Devkit8000 in the past, which is based on Embinux. It's a experimental work for passing time, I have no time to maintain and fix bugs friends reported after that. However, I think it is not good because the result will be getting lost as time goes by. 0xdroid is another Android distribution which is different from Embinux, its developer  Jim Huang(jserv)  who has contacted me a few months ago, and he hope that I can try porting 0xdroid on the Devkit8000. Actually, I am glad to make 0xdroid takes over my work, it is the best result for me. Currently, I've done most works, 0xdroid can run on Devkit8000 with success. And also, My patches have been committed to 0xlab-devel mailing list. Because I have another platform SBC8100 which is also produced by Embest, I've done works on that as well. You can see my patches from 0xlab-devel mailing list, or you can visit my website to download it directly: http://people.lin...

每當說起 Linux Kernel Driver 入門，就不免提到如何寫個 Hello World 級的 Module，這樣的第一支程式，除了可供 Linux Kernel 動態載入和卸載，似乎是一點用處也沒有。與一般應用程式不同，開發 Linux Driver 最大的門檻不在於如何撰寫出 Module，而是如何設計系統架構與硬體兩者間的橋樑。其中懂得如何控制和結合 Kernel 內各種機制更是重點，最複雜的莫過於此。 這邊有個 Mouse Kernel Driver，會在 Kernel 上新增一個虛擬滑鼠裝置，然後使用者可從 sysfs 控制該虛擬滑鼠（virmouse.c）： /*  * A Virtual Mouse Driver to send fake events from userspace.  *  * Written by Fred Chien <fred@ullab.org>  *  */ #include <linux/fs.h> #include <asm/uaccess.h> #include <linux/pci.h> #include <linux/input.h> #include <linux/platform_device.h> struct input_dev *virmouse_input_dev; static struct platform_device *virmouse_dev; /* Device structure */ /* Sysfs method to input simulated coordinates */ static ssize_t write_virmouse(struct device *dev,                               struct device_attribute *attr,        ...

It's not only for fun! Porting Android is a great practice for me as well. Devkit8000 is a clone of OMAP3 Beagle(Beagleboard), so we can found many porting informations of Beagleboard from internet. It's helpful for us, we only need to deal with a few places which are some differences between Devkit8000 and Beagleboard. Google Android Eclair is working well on the Devkit8000 board now after I tried to port it last weekend. Here is the patch: http://people.linux.org.tw/~fred/patches/devkit8000-android-kernel.patch Based on Embinux , I added the Devkit8000 support, which includes: OMAP DSS Driver for display 4.3 inch LCD Panel support (480x272 60Hz) 7 inch LCD Panel support (800x480 60Hz) Touchscreen ADS7846 support Sound Codec (TWL4030) Keypad (TWL4030) Ethernet Device support (DM9000) Kernel Config for Android Compile Kernel with Devkit8000 kernel config: make omap3_devkit8000_android_defconfig make CROSS_COMPILE=arm-linux-gnueabi- uImage Kernel Comman...

之前『 淺談 USB 通訊架構之定義（一） 』已經提過 USB 大致上的概念和一些特性，以及如何從 Linux 上去嘗試驗證 USB Device 上的 Information，但還尚未談及 USB Device 是如何與 USB Host 做溝通。而且，初始化的過程也很重要，該過程會讓一個 USB Device 描述自己的『模式(Configuration)』和『介面(Interface)』以及更多配置上的關鍵訊息。雖然這些初始化過程和定義繁雜，但是拜 OS 優良的包裝所賜，一般驅動程式都可以假設已知或是透過簡單的 API 去取得這些資訊以進行開發，因為大多數初始化動作會自動由 OS Kernel 和 Firmware 所完成。 簡單的 USB Device 初始化流程 插上 USB 裝置 Host 請 裝置 報告 『 裝置 描述資訊 (Device Descriptors )』 （此過程又稱為 Enumeration ） 由 Device Descriptors 得知 『 模式的數量 (bNumConfigurations) 』 Host 請 裝置 回報 『 模式的描述資訊( Configuration Descriptors) 』 由 Configuration Descriptors 得知 『 介面的數量( bNumInterfaces ) 』 Host 請 裝置 回報 『 介面 的描述資訊( Interface Descriptors) 』 由 Interface Descriptors 得知 『 端點的數量( bNumEndpoints ) 』 Host 請 裝置 回報 『 端點 的描述資訊( Endpoint Descriptors) 』 由 Endpoint Descriptors 得知 『 該端點的 資料傳輸模式( bmAttributes ) 』等訊息 等待驅動程式進行後續處理 整個 USB Device 的描述結構可以圖表示： 當然，若不是 USB Device 設計者或是 USB Host Controller 晶片的 Firmware/Driver 開發人員，可以不用知道這麼多過程細節，因為無論是 Linux 還是其他作業系統，它們都會將這些最低階的過程包裝起來，等著驅動程式去使用，而 Linux Kernel 上負責此任務的就被稱為...

USB(Universal Serial Bus) 的應用範疇以及價值已經不需要再多做說明，其身影從 HID(Human Interface Device)、隨身碟（USB Stick、Flash drive、Pen drive）到各種類比式或非連續訊號接收器（如： Webcam、Microphone、DVB Receiver），更進一步可以講到各種通訊裝置或外接設備，甚至是取代和模擬舊式通訊傳輸線（Serial Port）。USB 所有的 Spec 和相關資訊 ，可參考 http://www.usb.org/ 。 USB 整體運作模式 一般來說 USB 的通訊結構有如 Server/Client，以 PC 上的情形為例，位於主機上的 USB 裝置稱為『USB Host』，我們可以在上面外接上數個裝置（與 USB Host 相連的裝置通常被稱為 USB Device 或 USB Client）。 底層上，『Host 負責主導整個 USB 結構的通訊』，它會輪詢所有的 USB Deivce 以檢查是否有裝置需要傳送資料，所有 USB Device 都必需要等待 Host 的命令，唯有 Host 同意時，USB Device 才可以開始傳送資料。 Host 的行為通常是由 USB Host Controller 在做控制，其控制器是一組控制晶片，而對於現代 PC ，USB Host Controller 的晶片通常都被 Layout 在主機板上，以 PCI Bus 的形式存在供作業系統控制，我們可以使用 lspci 看到它的存在： 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1a.7 USB Controller: Intel Corporati...

昨日一如往常更新了 Debian Sid 系統，重開機以後發現 Compiz 的效果變得穩定且快多了，再仔細檢查，原來 xorg-video-intel 升上了 2.8.0。還記得自從 Intel Driver 開始轉移到 DRI2 開始，所有的 3D Performance 和 Xorg 的穩定性都不是很好，不但資源吃的兇，且三天兩頭就會 Crash，但 2.8.0 這版本似乎已經把大部份問題解決。更重要的是，因為 DRI2 已經可以運作，不會再有 compiz 與 OpenGL 程式打架的問題，可以看到在開啟 Compiz 的情況下 glxgears 已經可以躲在其它 Window 的背後運作： 新版本的細節，可以查看 Release Note： http://lists.freedesktop.org/archives/xorg/2009-July/046534.html 這裡列了 Xorg Intel Driver 2.8.0 的重要新特性： Remove XAA/EXA/DRI1 and NoAccel, and only support UXA/DRI2 now (requiring xserver 1.6). - 移除所有舊的加速機制（XAA/EXA/DRI1 and NoAccel），只留下支援 UXA/DRI2 VLD support added into XvMC for Mpeg2, which decreases CPU usage when playing video. - 加入 VLD(Variable Length Decoding) 到 XvMC，減少播放影片時的 CPU 使用量 然後修正了不少嚴重的 Bugs： Fix broken front-buffer rendering https://bugs.freedesktop.org/show_bug.cgi?id=19174 Fix disabling of XvMC disabled https://bugs.freedesktop.org/show_bug.cgi?id=20790 Fix broken VT switch on some machines https://bugs.freedesktop.org/show_bug.cgi?id=19578 Improve p...

今年的『 FreedomHEC Taipei 2009 』如期於 6 月 10 日開始，請來許多重量級的外國講者，傳授很多 Kernel Driver 以及硬體相關的寶貴實作開發經驗，有人還拿著『 Linux Device Driver』一書，去找講者簽名。 :-) 小弟很榮幸受『 資策會 』邀請，並於該活動給了一場主題為『Fastboot』的 talk。現在簡報檔上線有興趣的人可以參考： FreedomHEC Taipei 2009 - Fastboot [ PDF ] Fastboot 議題自從 Netbook 效應開始，就被廣泛提出討論，也不斷有不同的實作被發展出來，『快速開機』彷彿已經是個新一代消費性電子產品的必備標準。因此，就算該議題已經被討論和研究有許多時日，許多人仍對其非常有興趣。有更多的快訴開機方法，仍未被完善的發展出來，這也是值得我們探討的一部份。

Linux Kernel 的穩定，有一部份可以歸功於它優良的記憶體管理機制，而探討該機制，有助於瞭解記憶體是如何被 Kernel 所使用，對開發 Linux Driver 的人來說，日後更有許多益處。最重要的是，Linux Kernel 之美是由此開始，優美的設計相當令人著迷。 Linux Kernel 的記憶體管理機制，主要由兩大部份組成： Buddy System Slab Allocator Buddy System(buddy allocator) 如一般的 Operating System Design，Linux Kernel 一樣是以 Page 為記憶體管理的單位，因此設計了一層針對 page（或稱分頁）的管理機制，該機制在 Linux Kernel 裡被稱為『Buddy System (buddy allocator，簡稱 buddy)』，buddy 是 Kernel 最底層的記憶體管理機制，日後所有的記憶體配置，最後都要經過 buddy 才能取得或釋放記憶體。 可以藉由觀察當前 /proc/buddyinfo ，了解目前的記憶體使用情況，當然，是以 page 為單位： $ cat /proc/buddyinfo Node 0, zone DMA 76 71 66 50 33 17 5 1 1 1 0 Node 0, zone Normal 22301 6425 45 0 1 1 1 1 1 1 0 Node 0, zone HighMem 97 13 6 10 3 0 2 0 0 0 0 如果沒有什麼意外，/proc/buddyinfo 列會出了三個 zone ，分別是 DMA、Normal、HighMem，這三種 zone 的分類，是以 Physical Memory 位置的範圍而區分，在 IA-32 架構上 為： DMA (16MB以下) Normal (16MB~896MB) HighMem (896MB以上) 不過，由於 Buddy ...

因為某些案子的關係，春節後多日被迫關在飯店當 L （Who's L? 請參閱死亡筆記本），果然，龍崎這角色不是人當的，再關下去真的連坐姿和行為都會變得和他一樣奇怪（話說那樣的坐姿真的會讓智商提高！好像有？！）。沒枉費多日的努力，一個使用 ubuntu 的標準 config 所編譯出來之 Kernel 已經可以達到 1 秒的速度，理論上，若是再修剪 built-in 的 driver 應該可以達到更快速度。當然，單單只是 Kernel 快很容易做到，但 X Server 必需要在第 1.3 秒左右啟動，並在 第 2 秒前看到畫面，最重要的是有可用系統狀態，才算有實用的意義。 而關於 Kernel 部份，2.6.28 已做過許多快速開機的處理，其啟動已經非常快速，但是還會慢的瓶頸在於 initrd 的檢查，和各 device 初始的等待。經過 patch 後，這兩部份依硬體不同，可減少近 1 秒左右甚至更多的消耗。此外，盡可能讓 Root Filesystem 先被 Mount 也是一種手段，尤其再配合 initram 可以在瞬間就上到 User Space 的 Early boot 甚至進到 X Server，一般使用者可以看到 boot loader 一消失，緊接著就出現 X 的背景圖和 Cursor。 X Server 的快速開機處理有些方法，主要的做法是減少緩慢 I/O 的 Input Device 的等待時間，甚至是拖出正常 Initializing Progress，讓畫面先啟動。另外的瓶頸是各家 Video Driver 的問題，減少許多多餘的檢查有助於加快初始化速度。全部 patch 過後，基本上 XServer 啟動速度可達到 1 秒出頭（測試環境中，配合使用新的 Intel Video Driver）。 到此，一切看起來都很好，但最後發現 EDID 吃掉大半時間，單單為這 Monitor 的 Detect 就會影響使用 0.5 秒以上的時間，對某些 Specific 的 Hardware 可直接拿掉，但如何提前甚至時移到 Kernel 去跑，才是比較正確的做法。 目前，Boot Loader 的速度太慢，變成主要瓶頸，尤其以 Grub 的速度更令人不敢恭維，Loading 的速度比用 USB Drive 上的 Syslinux 還慢，這是還有...

目前，無論是 Linux Kernel 內的 PenMount Touchscreen Module 或是 Xorg 下的 Driver，都無法支援新版的 PenMount 6000，在官方網站上也只有提供 Xorg 的 binary driver，而且並未開放原始碼。日前因某些案子需要在 kdrive 上驅動 PenMount 6000，就自行 Hack 並寫了一支粗糙的 Driver。由於在 kdrive 上的 touchscreen solution 都是藉由 tslib 來實作，所以這支 driver 是一個 tslib 的 plugin。 一個意外發現，kdrive 底下的 Xvesa 並未支援 tslib，所以就算在 configure 下 enable tslib，雖然相關的 function 會被編進去，但卻不會真正被註冊在 driver list 上。對此，也在這寫了一個小 patch 以解決這問題。 驅動程式原始碼和 Xvesa patch 可在這取得： http://people.linux.org.tw/~fred/drivers/pm6000_tslib.tgz 將編好的 pm6000.so 放到 plugin 指定目錄後，然後再將 tslib config file 的 module_raw 設定成 pm6000，就可直接用下列方法使 Xvesa 驅動 PenMount 6000 Touchscreen： Xvesa -mouse tslib,,device=/dev/input/eventX

If you have the Thinkpad T60 laptop, maybe you will have a problem - ethernet device doesn't work. With command "dmesg", we can get some error messages that is just like: 0000:02:00.0: The NVM Checksum Is Not Valid ACPI: PCI interrupt for device 0000:02:00.0 disabled e1000e: probe of 0000:02:00.0 failed with error -5 It means the contents of EEPROM on the ethernet device was broken, because the checksum is not valid. For all I know, so many Thinkpad T60 laptops has the problem cause e1000e or e1000 driver return the error message and the device doesn't work. Here is a patch to add a parameter - "eeprom_bad_csum_allow" for the e1000e kernel driver: e1000e-allow_eeprom_bad_checksums.patch To enable the option will lead e1000e driver to ignore checking checksums of EEPROM. So you can use the command to load the e1000e driver be patched to enable your ethernet device: sudo modprobe e1000e eeprom_bad_csum_allow=1 BTW, I think you might see the similar patch for e...

最近 ， 『 Fast Boot』、『 快速開機』、『 5 秒開機』、『 XPUD』 這些關鍵字紅到爆炸 ， 經常在快速開機的討論 話題 中所聽到 。自從 EeePC 的推出 ， 自豪的標榜 15 秒開機後 ， 『 快速開機 』 的話題越來越熱門 ，然後 Aspire One 驚人的 11 秒開機 ，讓 『 開機的速度 』一時間變成了各家研究的首要方向 。不久前 。 由知名 Penk 所發展的 7 秒開機 XPUD ，直到最近 『 Intel Moblin 』 所展示的 5 秒開機 ，都著實讓人感到不可思議 。 接下來呢？難道 5 秒開機真的已經是極限了嗎？ 由於到處打工 ，也碰到許多與相關的案子 ，近來更被許多老闆們要求進行加快開機的速度 。進行加速的過程中 ， 從開始幾秒鐘為單位的計較 ，到最後連小數位以下的時間都要精精算計 ，每一次都證明了 『 5 秒鐘 』 似乎真的是極限 。 一個開機速度所會碰到的瓶頸大致上如下： Kernel Initializing Driver Initializing Filesystem Initializing I/O 通常 Kernel + Driver + Filesystem 使用 2 秒（經過數不清的調較和修改 kernel 後） ，Userspace Initializing + Xorg + Desktop Environment 用 2.x 秒 ，整個估算大概會是 5 到 6 秒鐘 。經過測試 ， 其實應該有可以再加速的空間 。 仔細觀察了 Kernel ， Synaptic Touchpad 就吃了 0.5 秒 ，IDE 的 probe 也吃了 0.6 秒 ，單是這兩支 driver 就吃掉了近五分之一的開機時間 ， 實在是慢的驚人 。其中有趣的是 ，通常在 netbook 上 ， ide1 沒有 Device ，但在這部份卻要花上 0.16 秒 ，讓人很想要 dirty hack ， 直 接讓 kernel 閃過 ide1 的 scan 。 :P 其實在整個開機流程中 ，最大的瓶頸在於 I/O ，Userspace 的程式都伴隨著大量的 config file 、Font、Library ，如何提升載入速度是很重要的課題 。這部份 ， Moblin 的 Super Readahead 作法的確很暴力 ，...

近年來 Linux 在台灣資訊業的蓬勃發展 ，讓誰都不敢漠視這一塊市場 ，就連過去與微軟緊緊相結合的硬體廠 ，都開始 『 鬆口 』 和 『 鬆手 』 來支援 Linux 。資策會這次於11月 20、21 日舉辦了一個『 Freedom 硬體工程師研討會 - Freedom Hardware Engineer Conference Taipei 』 ， 邀請了許多國外講者 ，演說內容包括了 Linux Driver 和相關硬體的開發 ，除了讓原有自由軟體開發者與相互交流外 ，也希望讓國內廠商能夠更了解 ， 如何有效參與 Linux 硬體產品的開發 。 話說議程內容還不錯 ，看到有個 ACPI EC driver 的 session ，眼睛都亮起來了 。個人希望各個廠商能夠多了解這議題 ，不要再隨便脫口就說： 『因為在 Windows 上正常 ，所以都是 Linux 的問題 』。與 Linux 的開發者共同解決才是正確之道 ，在未來也能夠更省時省力 ，也或許可以共同促使 BIOS 廠多擔起一點責任 。 心內真心的吶喊：對 Linux 的開發者來說 ，現在實在是太辛苦了 。

最近碰到個難解的問題 ，就是系統無法 Restart 的 Bug ，有 usplash 的人會卡死在關機畫面 ，在 console 底下 ，會停在 kernel 吐的最後一行訊息： 『 Restarting system 』。有趣的是 ，這 bug 只會在 suspend/resume 之後才發生 。沒錯 ，這應該是 ACPI 的 Bug ，但其實可以透過 Patch Kernel 來修正 。 這 patch 可由此下載： linux-kernel-restart.patch 後記 因為 BIOS 的人永遠不承認是自己的錯 ，我們只好自己動手 。

截至這篇文章為止，『 Linux Kernel 』的 latest stable version 是 2.6.25-4，或許是因為 2.6.25 正式 release 才約短短一個月左右，多數人應該都還停留 2.6.24 以下的版本。原本用得好好的人，應該也不會去趕流行而換上最新的 kernel，畢竟人人都不願意當白老鼠呀。 今天，不怕死的將 EeePC 裡面 Debian 的 kernel 從 2.6.24-2 換成了 2.6.25-2 ，因為原本 Kernel 的 snd-hda-intel driver 一直無法正確驅動 EeePC 900 的聲音晶片〔EeePC 900 和 701 的晶片有出入〕，所以我換上最新版的 kernel 碰一碰運氣。不過運氣真是不錯， Linux kernel 2.6.25-2 讓 EeePC 900 不再是啞巴了，成功解決 EeePC 900 沒聲音的問題〔不然原本打算要跟 Asus 要 Source Code 了〕。 升級 kernel 後，一切看起來都很正常，唯獨 LXPanel 的電池狀態是壞掉的。追了一下 kernel source code 和 debien bugs 發現， /proc/acpi/battery 和 /proc/acpi/ac_adapter 已經在 2.6.25 被拿掉，統一轉移到 2.6.23 之後被加入的 /sys/class/power_supply。 這樣的大改動，意味著許多 userspace 的電池狀態偵測程式要做改寫才能在 Linux kernel 2.6.25 之後的系統上運作正常。還好，這問題並不大，至少支援 Hal 的電池狀態偵測程式可不用擔心，Hal 早在數個月前已處理好這問題，唯有少數幾個不愛 Hal 的程式會受到影響，如 LXPanel batt plugin 。:-( 後記 已著手在修正這問題，未來幾天在 LXDE 的 SVN 上，應該就會出現改好的 code。

3G、3.5G 這半年多來炒的沸沸揚揚，令誰都想去辦個門號一探究竟。不過，談各家電信業者的 3G 服務品質已經沒什麼意思，來 Hacking 一下 3G 網卡的裝置訊息似乎會有趣得多 :)。目前，各家業者的 3G 門號，都是搭配『 Huawei 』的網卡，尤其以『 E220 HSDPA USB Modem 』最為普遍，其小巧又乾淨的外型相當討喜，因此就選擇拿它來開刀。 如何在 Linux 上安裝 E220 就不多說了，任何人都能在 Google 找到不少文獻，比較值得注意的是，安裝過程中會出現三個令人迷惑的 device file〔ttyUSB0、ttyUSB1、ttyUSB2〕。經搜尋過網路上的資料和實地測試後，已經大概知道這三個 Device file 的用途： ttyUSB0: 被當成一般 modem 通道使用，處理 3G 網路撥接用 ttyUSB1: 回傳相關的裝置和連線訊息 ttyUSB2: 放驅動程式的儲存裝置〔不確定〕。 如果你有將網卡裝起來，通常可以使用 pppd 透過 ttyUSB0 連線到 3G 網路，我想這部份就不用再多做解釋了。倒是 ttyUSB1 的部份比較特殊，會回傳一堆奇奇怪怪的 messages 〔可以使用 cat /dev/ttyUSB1 看到內容〕，而這些 messages code 又各是代表什麼意思，就相當令人好奇，當然，這也是這次 Hacking 的目的。 :D 經過一番測試後，整理了一些 ttyUSB1 回傳的狀況。 不論網路是否有連線，每固定一段時間就會回傳： ^BOOT:82907211,0,0,0,6 不過目前為止，還不了解此訊息的內容是什麼意思，有可能是裝置編號或是 firmware 的版本。 撥號連線後，就開始會回傳一些不一樣的訊息： 目前的網路模式： ^MODE:5,5 ^MODE:5,4 其中 5 是代表 HSDPA ， 4 是代表 WCDMA。而其他的 3、2、1 應該分別是 EDGE、GPRS、GSM，不過，大台北地區的 3G 基地臺相當完整，我還沒機會碰到有 3G 以下的模式，所以無法確定。 連線訊號強度： ^RSSI:8 其中的數字 8 即代表訊號的強弱，理論上 10 應該是最強，而 0則代表沒訊號〔目前還沒機會測試到〕。 然後有資料傳輸的相關資訊和統計〔每兩秒鐘更新一次〕： ^DSFLOWRPT...