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

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

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

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

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

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

網路支援完成

最近這二天適逢周末，我趁著有空閒時，開始來研究 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 了。

開機成功

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

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

以上。

目前工作

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

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

利用 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

S3C2440 開發板初體驗

自從上禮拜收到貨之後，由於本人那幾天比較忙，懶得動，是故清點完包裝內的物品後，便暫時擱在一旁。今天終於有空來玩一玩。

代理商出貨時就有先幫我燒好 Linux，是故接上 LCD 後開機就可以順利顯示圖形界面，可以確定 LCD driver 沒問題。再來開到以 COM port 連接的終端機檢視其中的 /proc 目錄，確認 CPU 的型別、記憶體大小、已驅動的裝置，再來做幾個測試，小結如下：

• USB Host：可連接 mass storage device
• MTD：可正確讀出/寫入
• OSS：可正確播放音效。不過聲音有點破破的。
• UART：沒問題
• Framebuffer：沒問題
  

目前做到這裡，接下來再來寫幾個簡單的 kernel module 來測試其他硬體。

此外，這塊板子出廠附的 bootloader 並非是 U-Boot，而是廠商自己做的 bootloader，主要功能是將 NAND Flash 自動分區並燒錄核心及檔案系統，雖然支援以 USB 下載檔案是很方便沒錯，但除了燒錄外，其他功能付之闕如。因此我想玩玩過後，還是會重新再燒個 U-Boot 吧。

新開發板入手

今天終於收到昨天新買的 s3c2440 開發板。眾所周知，三星所推出以 ARM 為基礎的 SoC 一直以「俗擱大碗」著稱；不僅價格便宜，許多該有的周邊 IO 也都不缺，不僅在學校實習課上常用到，也是像我們這些阮囊羞澀的窮人不錯的選擇。

唯一我比較在意的是，這塊板子是大陸做的；一般人印象中總是對大陸產品有品質不佳的印象，尤其代理商又賣我這麼便宜，實在很難不讓人起疑。不過在網路上找來找去，s3c2440 的開發板似乎沒有很多選擇，加上並非都有台灣的代理商在賣，我又懶得直接跟原廠購買，就姑且信之吧。好在廠商附的文件倒是不少，該有的燒錄工具也都送給你，按步就班地做，希望不會出什麼大問題。

總之，這算是我生平第一塊自費的 ARM 開發板，就來好好研究研究唄。

後記：
後來在 http://www.arm.linux.org.uk/developer/machines/ 上看到不少 2440 為基礎的開發板，不過似乎在原始碼中沒看到這麼多啊？還是只是註冊假的？