2008年6月30日 星期一

為何要和主流核心保持互動?

就在幾天前我送出第一個針對開發板移植的 patch 後,Eric Miao 看到了我的訊息,便利用 gTalk 丟水球來聊一聊。Eric 是 PXA 架構的維護者,本身也在 Marvell 工作。他以為我是開發版廠商裡頭的人,我跟他說我是以個人名義做開發,他才了解怎麼一回事,並開玩笑地說我可以去向他們要錢了。

不過他提到,大陸在做開發板的公司,由於成本考量,往往移植的核心都固定在某一個版本,而不願意跟著主流核心版本做維護,這引發了我另外一種的思考。不錯,當公司的產品還不夠普遍時,確實需要另外請人維護並確保新版核心可以在產品上運作;不過將修改過的原始碼合併至主流版本的同時,你也達到了廣告的效果,告訴人們你有在賣這類產品,並且最新版的核心直接就可以在上面運作。能夠增加曝光的機會,代表的是可能會有更多的訂單進來。當你的銷售量達到一定規模、夠普遍的時候,你不需要請人,自然就會有人來接手維護的工作,那麼額外的人事成本就能夠節省下來。

所以問題在於,公司願不願意多花些錢做點廣告,介紹你的產品,讓全世界的人都能認識你的產品,並為你的產品多增加些潛在的客群?

當然,對我而言,動機就單純得多。我只是想要在上面跑最新版的核心,但不希望每次新版釋出就要再改一次程式碼,於是將修正貢獻合併回主流核心就成了最佳的選擇。

一點意見,還請不吝指教。

2008年6月29日 星期日

網路支援完成

最近這二天適逢周末,我趁著有空閒時,開始來研究 git kernel 及原廠自行修改的 DM9000 網路晶片驅動程式原始碼。不過兩相對照之下,初始化過程其實差不多,雖然在 dm9000_rx() 函式中程式有些不同,不過經過測試後發現其實沒什麼影響。後來我根據初始化時所做的條件判斷及開發板的線路圖,在開發板初始化程式中再加入了以下的定義:

static struct dm9000_plat_data at2440evb_dm9k_pdata = {
    .flags = (DM9000_PLATF_8BITONLY | DM9000_PLATF_NO_EEPROM),
};

意思是指示驅動程式晶片的資料埠寬度為 8 bits,且晶片並未連接 eeprom。
不過測試時卻無法驅動。我照著線路圖和晶片手冊設定的應該沒錯,可就是不會動,真是百思不得其解。後來無意間設定成 DM9000_PLATF_16BITONLY,竟然就可以動了…可是這樣一來就和線路圖產生矛盾了…難不成廠商給我的是錯的???有必要再釐清一下。

花了一個下午的時間,網路算是可以正常工作了,稍後整理一下就可以送 patch 了。

2008年6月17日 星期二

開機成功

經過幾天的 code tracing,大致上已經了解 S3C24xx 架構的原始碼是如何安排的,接下來我在 ARM Linux 的 machine registry 去註冊了新的 machine type,接著開始移植的工作。我先以 arch/arm/s3c2440/ 目錄下的 mach-anubis.c 為樣板,刪去了不需要的程式碼,並加入了一些板子獨有的硬體設定,接著修改 Kconfig 以及 Makefile,最後重新編譯核心,第一階段完成。

接下來將核心的 rootfs 掛載為 initramfs,可以順利開機,其他基本的驅動程式,如 RTC,UART,NAND 等也順利啟動,唯一有問題的就是網路晶片。核心原始碼中已附有 DM9000 的驅動程式,但不知為何,無法正確驅動,我猜測可能是始初化過程的問題。最近這幾天要再拿隨貨附的原始程式來對照一下。

以上。

2008年6月12日 星期四

目前工作

目前正在進行的項目是將最新版本的 Linux kernel (2.6.26-rc5)移植到這塊開發板上。雖然購買這塊板子時已隨貨附上修改過的 Linux 2.6.18.2 原始碼,但原作者似乎並未將這些修正合併回主流核心版本中。是故我的計畫是將這些修改過的程式做個整理,以符合核心的 coding style,然後註冊新的 machine type,將整理完的程式碼送上 mailing list。

當然過程中,仍少不了要追蹤硬體初始化的部分,來和晶片使用手冊的說明相對照。所幸拜 Ben Dooks 的努力,S3C24xx 系列的程式碼發展地相當完整,要加入新開發板的支援比較方便,只要將現有的程式碼拿來直接套用即可,剩下的工作就是針對開發板上特殊的周邊做些修改了。

2008年6月7日 星期六

利用 busybox 實作熱插拔機制

目前在 PC 系統下的 Linux 2.6 熱插拔機制是採用 udev 來實作;核心在偵測到硬體插入/移除時,會發出事件通知 udev daemon,udev 則根據事先設定好的規則來建立裝置檔案、symlink 或做其他處理。

在嵌入式系統中,當然也可以使用 udev 來設定當硬體熱插拔時要做那些處理,不過若你的目的相對比較單純時,其實 busybox 也提供了名叫 mdev 的 applet 來達成相同的功能。mdev 可以說是精簡版本的 udev,其設定檔相較於 udev,規則簡單,但也犧牲了一些 udev 才有的彈性。

要使用 mdev,只需在 kernel 啟動後的初始化程式(如 linuxrc 或是 /etc/init.d/ 下的 scripts),先掛載 /dev 及 /sys,接著下指令:
mdev -s
以建立裝置檔案,然後再設定使用 mdev 程式做為核心熱插拔事件的處理程式:
echo "/sbin/mdev" > /proc/sys/kernel/hotplug
如此,在核心熱插拔事件發生時,mdev 就可根據核心傳入的參數來建立對應的裝置檔案。

若你有在 busybox 中勾選 mdev 設定檔的支援,你還可以透過撰寫設定檔來客制化你的熱插拔機制。該檔案位於 /etc/mdev.conf,其語法如下:
<device name regex> <uid>:<gid> <umask> [<@|$|*> command]
例如要設定當 MMC 卡插入時要執行自定的 script 時,可以這樣寫:
mmcblk[0-9]p[0-9]* 0:0 660 *myscript

除 mdev 外,busybox 也提供許多有用的工具以方便嵌入式系統的開發,非常值得開發人員好好地玩玩。

相關連結:
busybox:http://busybox.net/
udev:http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html