最近新釋出的 Linux v3.3 增加一個新的 C6x 家族 CPU 支援。有用過 TI 平台的人都知道，C6x 是 TI 開發的數位信號處理器，主要使用於需要大量運算資源，如多媒體編解碼之類的應用。過去 TI DSP 上幾乎所有的軟體架構，包括 RTOS、函式庫、編譯器、IDE 等等，皆是 TI 所開發，當然也都是專屬軟體，且若無簽署 NDA，許多技術文件並不是那麼容易取得，因此相對於其他如 ARM 等較為通用的平台而言，DSP 是較為封閉的體系。許多在 Linux 下執行的應用程式，無法輕易地移植至 DSP 平台，想要實現相同的功能，就得自己從頭寫起，無形中也是一種麻煩。
是故若官方核心對於 DSP 的支援能夠逐步完善，未來或許有機會能夠將原來在 ARM 執行的程式移植至 DSP 端執行；甚至或可再更進一步，在 DaVinci 這類異質性多核心平台上，利用如 llvm 的技術，預先將應用程式編譯為中間碼，到執行時期時才根據系統負載來決定要在那一個 core 執行，如此便能提供系統執行時期更多的彈性。
參考資料：
[1] Upcoming DSP architectures
[2] c6x Linux project
2012年4月1日 星期日
2011年6月4日 星期六
Linux 即將邁入 3.0
約在五月底時，Linus 宣布了一個重大的決定，就是將開發近八年的 2.6 系列做一個結尾，並在即將 20 周年的時刻，發布 Linux 3.0。
3.0 的發布將會是一個重大的里程碑；即使它相較於 2.6.39，並未有什麼大太的改變，不過卻象徵著 Linux 的開發已經進入了一個成熟、開花結果的階段。雖然在桌面市場上仍然無法取代 Windows，但在嵌入式系統領域中卻取得了重大的成就，連帶也增加了許多相關的工作機會，並吸引優秀的軟體人才進入這個領域。從 20 週年的這個時刻來看，我想 Linux 算是相當地成功的。
當然為了讓 3.0 這個版號更為名副其實，Linus 刻意縮短了 merge window 的時間，並採取較為嚴格的審查，以確保只有真正重要的修正才會被納入。另外就是將來的穩定版的版號將不再採取三個數字的表現方式，而是採用 3.x 的方式，第三個數字則留給 maintenance team 使用。
P.S. 當初之所以會有三個數字的版號，可能是源自於從 0.99 到 1.0 的開發期間，為了不要一下子就跳到 1.0，所玩的數字遊戲。於是從這時開始，就出現了 0.99.1, 0.99.2 …… 等版號。如今 Linux 已非當年的吳下阿蒙，且開發時程也相當地制度化了，三個數字的版號已不再有實質上的意義。或許 Linus 也是基於這樣的理由，而做出這個決定吧。
3.0 的發布將會是一個重大的里程碑；即使它相較於 2.6.39，並未有什麼大太的改變，不過卻象徵著 Linux 的開發已經進入了一個成熟、開花結果的階段。雖然在桌面市場上仍然無法取代 Windows，但在嵌入式系統領域中卻取得了重大的成就，連帶也增加了許多相關的工作機會，並吸引優秀的軟體人才進入這個領域。從 20 週年的這個時刻來看，我想 Linux 算是相當地成功的。
當然為了讓 3.0 這個版號更為名副其實，Linus 刻意縮短了 merge window 的時間，並採取較為嚴格的審查，以確保只有真正重要的修正才會被納入。另外就是將來的穩定版的版號將不再採取三個數字的表現方式，而是採用 3.x 的方式，第三個數字則留給 maintenance team 使用。
P.S. 當初之所以會有三個數字的版號，可能是源自於從 0.99 到 1.0 的開發期間，為了不要一下子就跳到 1.0，所玩的數字遊戲。於是從這時開始，就出現了 0.99.1, 0.99.2 …… 等版號。如今 Linux 已非當年的吳下阿蒙，且開發時程也相當地制度化了，三個數字的版號已不再有實質上的意義。或許 Linus 也是基於這樣的理由，而做出這個決定吧。
2011年4月2日 星期六
又重回 TI 懷抱
距離上次 po 文又是許久一段時間了。這段期間除了忙於工作外，也送了一兩個 patch，只是目前尚未被接受。S3C24XX 平台已是相當穩定了，目前在 mailing list 上的開發者皆已專注於新的三星 Cortex-A8 平台的開發，而 Ben Dooks 雖仍為三星架構的維護者，但重心似乎已較偏向 I2C 子系統的維護了。
近期工作的內容又重新回到了 TI DaVinci 新平台的開發，距上次在 DaVinci 平台的接觸已是三年前的事了。除了 CPU 架構的更新之外，一路看來，TI 平台的硬體架構是相當一致的，不過中介軟體的架構卻有了重大的改變。不同於過去使用的 VISA 架構，現今改採用工業標準 OpenMAX 來做為應用程式和底層加速硬體的溝通介面。目前的實作仍不是很完整，同仁著實花了不少力氣在除錯上。期待未來的版本更新可以更穩定些。
目前 TI 的 PSP (Platform Support Package) 已經採用開放源始碼社群的開發模式，Linux kernel 以及 U-Boot 皆有專人在維護相關的源碼樹，有興趣的網友可以去以下的連結一探究竟：
近期工作的內容又重新回到了 TI DaVinci 新平台的開發，距上次在 DaVinci 平台的接觸已是三年前的事了。除了 CPU 架構的更新之外，一路看來，TI 平台的硬體架構是相當一致的，不過中介軟體的架構卻有了重大的改變。不同於過去使用的 VISA 架構，現今改採用工業標準 OpenMAX 來做為應用程式和底層加速硬體的溝通介面。目前的實作仍不是很完整，同仁著實花了不少力氣在除錯上。期待未來的版本更新可以更穩定些。
目前 TI 的 PSP (Platform Support Package) 已經採用開放源始碼社群的開發模式，Linux kernel 以及 U-Boot 皆有專人在維護相關的源碼樹，有興趣的網友可以去以下的連結一探究竟：
2010年6月29日 星期二
Status Update
2009年12月16日 星期三
SD driver with DMA support
有在研究 S3C24XX 平台的開發者應該會發現，SD 控制器驅動程式目前只支援 PIO mode，若嘗試將 DMA mode 的支援開啟，在偵測 SD 卡時就會發生問題。經過原始碼追蹤後我們可以發現到一些現象，且待我細細道來。
S3C24XX 平台的 DMA core 實作了要求佇列 (request queue) 的機制，使得它能夠接收多個 DMA 傳輸要求，並設定相關的暫存器來進行傳輸。當設定完成後，我們就可以設定 SD 控制器來觸發 DMA 控制器進行實際的資料傳輸。當要求佇列中有新的傳輸要求存在時，DMA core 會檢查 DMA 控制器是否已經在執行目前的要求；若已在執行，DMA core 就會取出新的要求，並將來源位址、目的位址以及資料長度等參數寫入暫存器中 (對暫存器寫入並不會對進行中的傳輸產生影響)。若否，DMA core 會繼續等待直到逾時為止。換言之，除非 DMA 控制器起始傳輸，否則 DMA core 是不會處理新的傳輸要求的。
MMC core 在讀取資料的過程中，預設會使用 scatter-gather DMA 來提高傳輸效率，或避免向核心要求一大塊連續的記憶體空間；然而 S3C24XX DMA 控制器並不支援此種傳輸方式，因此在執行時我們就會發現到，由於佇列中還有傳輸要求尚未設定，DMA core 不斷地在檢查 DMA 控制器是否正在執行；但是在佇列中的所有傳輸要求都被設定完成之前，SD 控制器是不會觸發 DMA 控制器來起始傳輸的 (雞生蛋，蛋生雞？)，於是我們就會看到 DMA core 一直在 busy waiting，直到 time out 為止。
因此要解決這樣的問題，在向 MMC core 註冊 host controller 時，要設定該控制器同時間只能接受一個 DMA 傳輸要求 (請見 struct mmc_host 中的 max_hw_segs 及 max_phys_segs 欄位)。同時也可開啟 bounce buffer 支援以提高傳輸效率。
S3C24XX 平台的 DMA core 實作了要求佇列 (request queue) 的機制，使得它能夠接收多個 DMA 傳輸要求，並設定相關的暫存器來進行傳輸。當設定完成後，我們就可以設定 SD 控制器來觸發 DMA 控制器進行實際的資料傳輸。當要求佇列中有新的傳輸要求存在時，DMA core 會檢查 DMA 控制器是否已經在執行目前的要求；若已在執行，DMA core 就會取出新的要求，並將來源位址、目的位址以及資料長度等參數寫入暫存器中 (對暫存器寫入並不會對進行中的傳輸產生影響)。若否，DMA core 會繼續等待直到逾時為止。換言之，除非 DMA 控制器起始傳輸，否則 DMA core 是不會處理新的傳輸要求的。
MMC core 在讀取資料的過程中，預設會使用 scatter-gather DMA 來提高傳輸效率，或避免向核心要求一大塊連續的記憶體空間；然而 S3C24XX DMA 控制器並不支援此種傳輸方式，因此在執行時我們就會發現到，由於佇列中還有傳輸要求尚未設定，DMA core 不斷地在檢查 DMA 控制器是否正在執行；但是在佇列中的所有傳輸要求都被設定完成之前，SD 控制器是不會觸發 DMA 控制器來起始傳輸的 (雞生蛋，蛋生雞？)，於是我們就會看到 DMA core 一直在 busy waiting，直到 time out 為止。
因此要解決這樣的問題，在向 MMC core 註冊 host controller 時，要設定該控制器同時間只能接受一個 DMA 傳輸要求 (請見 struct mmc_host 中的 max_hw_segs 及 max_phys_segs 欄位)。同時也可開啟 bounce buffer 支援以提高傳輸效率。
2009年10月28日 星期三
Samsung touchscreen driver issue
三星的主流核心支援其實已存在相當久，幾乎可說是所有 ARM-based SoC 中支援最完整的。但經常關心 ARM Linux kernel 發展的網友也許會發現到，怎麼核心中每項周邊都有驅動程式支援，卻獨獨缺了觸控面板？
其實相關的 patch 早已在各個專案中使用 (如 OpenMoko），但由於都是直接操作暫存器，而非架構在 Ben Dooks 的 adc driver 之上（詳見之前的文章），是故一直沒有被整合進去。今年四月初 Nelson Castillo 將原來在 OpenMoko 使用的驅動程式移植至主流核心，並使用 adc driver 來做取樣的工作。雖然已有作為先期準備的 patch 被整合，但直到目前為止完整的驅動程式仍未進行合併。
最近關於這個議題又有了新的爭論。由於 Nelson 的版本引進了多層次的濾波器（filter）來去除不合法的取樣點，Russell King 認為這違背了 policy-mechanism 分離的原則；所有的取樣點應該原封不動地往上傳遞至 user-space（tslib）來做處理，在驅動程式中使用 filter 是缺乏彈性的作法（附帶一提，Russell 是 tslib 的作者）。但 Nelson 認為，在驅動程式中，filter 可以根據需要，透過回傳值來要求 adc driver 多抓一些取樣點來作判斷；而這是 user-space 所無法達成的優點。且這樣的設計方式可以解決在電阻式面板所遇到的問題（在觸控筆按下和釋放的瞬間，會有大量的雜訊出現）。
就我個人測試過的經驗，Nelson 的 patch 確實比單純只使用 tslib，觸控板的表現要好得多，筆觸變得比較順暢，且抖動的情況減少很多。雖然在整合進 board-dependent 的程式碼時相對比較麻煩，不過其效果似乎是值得這麼做的。
其實相關的 patch 早已在各個專案中使用 (如 OpenMoko），但由於都是直接操作暫存器，而非架構在 Ben Dooks 的 adc driver 之上（詳見之前的文章），是故一直沒有被整合進去。今年四月初 Nelson Castillo 將原來在 OpenMoko 使用的驅動程式移植至主流核心，並使用 adc driver 來做取樣的工作。雖然已有作為先期準備的 patch 被整合，但直到目前為止完整的驅動程式仍未進行合併。
最近關於這個議題又有了新的爭論。由於 Nelson 的版本引進了多層次的濾波器（filter）來去除不合法的取樣點，Russell King 認為這違背了 policy-mechanism 分離的原則；所有的取樣點應該原封不動地往上傳遞至 user-space（tslib）來做處理，在驅動程式中使用 filter 是缺乏彈性的作法（附帶一提，Russell 是 tslib 的作者）。但 Nelson 認為，在驅動程式中，filter 可以根據需要，透過回傳值來要求 adc driver 多抓一些取樣點來作判斷；而這是 user-space 所無法達成的優點。且這樣的設計方式可以解決在電阻式面板所遇到的問題（在觸控筆按下和釋放的瞬間，會有大量的雜訊出現）。
就我個人測試過的經驗，Nelson 的 patch 確實比單純只使用 tslib，觸控板的表現要好得多，筆觸變得比較順暢，且抖動的情況減少很多。雖然在整合進 board-dependent 的程式碼時相對比較麻煩，不過其效果似乎是值得這麼做的。
2009年10月13日 星期二
2009年8月30日 星期日
Samsung 將釋出 Linux 原始碼
昨天收信時看到了這封信件，以及 Harald Welte 承諾將在三星採用社群開發模式上提供協助。一直以來，S3C24XX 及 S3C64XX 系列的核心支援，包含原始碼的目錄架構、驅動程式，以及各種修正，大部分都是由 Ben Dooks 所完成，也因為他所貢獻的大量基礎建設，使得像我這樣的開發者能夠相當容易地將各種 Samsung-based 開發板的支援加入 Linux 核心之中。如今三星這間半導體大廠願意投入人力來共襄盛舉，若三星自已維護的 kernel tree 能夠順利合併進入主流版本，那麼我們將可以直接自主流核心就得到官方的支援。有了大公司的加持，相信未來 Linux 對於三星 SoC 的支援完整度及執行效率上會得到大幅度的增進。對我們這些使用三星 SoC 的開發者來說，自然是再好不過了。
當然，聽其言，觀其行，我們還是要持續注意三星的實際作為才行。
PS. 有興趣的人可參考這裡所提，下載目前三星所釋出的 kernel tree.
當然，聽其言，觀其行，我們還是要持續注意三星的實際作為才行。
PS. 有興趣的人可參考這裡所提，下載目前三星所釋出的 kernel tree.
2009年7月29日 星期三
Linux gpiolib
GPIO 在嵌入式系統中是相當常見的 I/O 裝置，全名為 General Purpose I/O。由於 GPIO 針腳可被個別設定和輸出訊號，因此我們可以利用 GPIO 來驅動 LED、或者實作低速的 I/O 通訊協定（如 I2C、SPI）。也可以利用 GPIO 來做為外部訊號的輸入端，在訊號觸發時，驅動程式中可使用 polling 或中斷方式來獲得通知。在嵌入式 SoC 平台上通常配有大量的 GPIO，且多半會和其他週邊裝置共用針腳，因此在使用時要特別注意，以免發生衝突。
過去在 Linux 上的 GPIO 程式碼大部分是屬平台相依的程式碼，因此 API 的實作也是由各平台的開發者自行設計，但除了 SoC 內建的 GPIO 外，系統設計者也會額外以 FPGA 或 I/O expander 來擴充 GPIO 的數量；因此要設計一種方式，除了能夠使用內建的 GPIO 外，也能使用這些額外的 GPIO，並透過一個統一的介面來存取它們。
gpiolib 的引入為上述的問題提供了一個解決方式。gpiolib 將每個 GPIO 的來源 (SoC、FPGA，或是 I/O expander) 用 gpio_chip 結構來表示，開發者可以定義其 GPIO 的編號、數量，以及相關的回呼函式 (callback function)。開發者需要為這些 gpio_chip 結構定義不同的回呼函式來處理不同的 GPIO 來源。如此一來，使用者只需指定 GPIO 編號，gpiolib 會替我們尋找對應的 GPIO 來源，並呼叫適合的函式來存取它，非常地方便。
PS. 需要注意的是，某些 GPIO 來源（如 I2C 介面的 I/O expander）存取時可能會進入睡眠狀態，因此不能夠使用於 ISR 或 tasklet 等不可睡眠的函式之中。
過去在 Linux 上的 GPIO 程式碼大部分是屬平台相依的程式碼，因此 API 的實作也是由各平台的開發者自行設計，但除了 SoC 內建的 GPIO 外，系統設計者也會額外以 FPGA 或 I/O expander 來擴充 GPIO 的數量；因此要設計一種方式，除了能夠使用內建的 GPIO 外，也能使用這些額外的 GPIO，並透過一個統一的介面來存取它們。
gpiolib 的引入為上述的問題提供了一個解決方式。gpiolib 將每個 GPIO 的來源 (SoC、FPGA，或是 I/O expander) 用 gpio_chip 結構來表示，開發者可以定義其 GPIO 的編號、數量，以及相關的回呼函式 (callback function)。開發者需要為這些 gpio_chip 結構定義不同的回呼函式來處理不同的 GPIO 來源。如此一來，使用者只需指定 GPIO 編號，gpiolib 會替我們尋找對應的 GPIO 來源，並呼叫適合的函式來存取它，非常地方便。
PS. 需要注意的是，某些 GPIO 來源（如 I2C 介面的 I/O expander）存取時可能會進入睡眠狀態，因此不能夠使用於 ISR 或 tasklet 等不可睡眠的函式之中。
2009年6月17日 星期三
Kernel API always changes
最近因為工作上的需要，花了些時間學習如何撰寫 Linux 區塊裝置驅動程式，以及了解 Linux block subsystem 的架構。我主要參考兩本書藉，其中一本正是大名鼎鼎的 Linux Device Drivers 3rd (LDD3)；而另外一本則是去年才出版的書藉 Essential Linux Device Drivers。
我嘗試依照書本上的內容寫了一個 RAM-based 的區塊驅動程式，但在我的電腦上卻因為參考不到函式呼叫而無法成功編譯 (核心版本 2.6.28)。原因當然是因為核心 API 的改變，正如許多資深開發者所言，由於開發的需要，核心 API 總是不斷地在變化，因此若不將程式碼合併回主流版本，後續的維護將會非常麻煩。
以 LDD3 來說，其所列的範例程式片段如下：
sectors_xferred = sbull_xfer_request(dev, req);
if (! end_that_request_first(req, 1, sectors_xferred)) {
blkdev_dequeue_request(req);
end_that_request_last(req);
}
請注意 LDD3 所依據的核心版本為 2.6.10，到了 2.6.28，這些函式已被移除，取而代之的是：
sectors_xferred = sbull_xfer_request(dev, req);
__blk_end_request(req, 0, sectors_xferred << 9);
由於 __blk_end_request() 函式的第三個參數為成功傳輸的位元組 (byte)，而非區段 (sector)，所以需做單位轉換。另外可能會造成混淆的地方是 block subsystem 也提供另一個函式 blk_end_request()，兩者功能相同，差別在於後者是有加上 spin lock 的版本；不過由於核心在執行上述的程式碼之前已先行上鎖了，是故就不需要再上鎖一次了。
由以上範例，我們可以了解到，核心 API 的改變對於驅動程式的維護而言，並不僅僅是舊函式的消滅或新函式的加入而已，我們還需要評估應如何修改程式，以及修改後是否會影響程式的行為。通常核心開發者會負責將所有相關的驅動程式修改到好，但若是 out of tree 的程式碼，這部分可就得自己傷腦筋了。
我嘗試依照書本上的內容寫了一個 RAM-based 的區塊驅動程式，但在我的電腦上卻因為參考不到函式呼叫而無法成功編譯 (核心版本 2.6.28)。原因當然是因為核心 API 的改變，正如許多資深開發者所言，由於開發的需要，核心 API 總是不斷地在變化，因此若不將程式碼合併回主流版本，後續的維護將會非常麻煩。
以 LDD3 來說，其所列的範例程式片段如下：
sectors_xferred = sbull_xfer_request(dev, req);
if (! end_that_request_first(req, 1, sectors_xferred)) {
blkdev_dequeue_request(req);
end_that_request_last(req);
}
請注意 LDD3 所依據的核心版本為 2.6.10，到了 2.6.28，這些函式已被移除，取而代之的是：
sectors_xferred = sbull_xfer_request(dev, req);
__blk_end_request(req, 0, sectors_xferred << 9);
由於 __blk_end_request() 函式的第三個參數為成功傳輸的位元組 (byte)，而非區段 (sector)，所以需做單位轉換。另外可能會造成混淆的地方是 block subsystem 也提供另一個函式 blk_end_request()，兩者功能相同，差別在於後者是有加上 spin lock 的版本；不過由於核心在執行上述的程式碼之前已先行上鎖了，是故就不需要再上鎖一次了。
由以上範例，我們可以了解到，核心 API 的改變對於驅動程式的維護而言，並不僅僅是舊函式的消滅或新函式的加入而已，我們還需要評估應如何修改程式，以及修改後是否會影響程式的行為。通常核心開發者會負責將所有相關的驅動程式修改到好，但若是 out of tree 的程式碼，這部分可就得自己傷腦筋了。
2009年6月8日 星期一
移植 Ångström
因為看到另一個基於 OpenEmbedded 的 distribution Ångström，覺得它比起 Poky 來說提供更多的套件選擇，且由於 Ångström 的目錄架構和 OE 相同，所以在 OE 下新增的套件，馬上就可以套用在 Ångström 之上，而不需做任何修正。是故就決定以 Ångström 做為我移植軟體至開發板的基礎開發套件。
於是上個月的工作就是將原來寫給 Poky 用的設定檔修改以後再移到 Ångström 的目錄之下，然後再修改 Ångström 下的 linux recipe 來支援我目前使用的開發板，接著測試完成後，再提交至 OE mailing list。大功告成。
於是上個月的工作就是將原來寫給 Poky 用的設定檔修改以後再移到 Ångström 的目錄之下，然後再修改 Ångström 下的 linux recipe 來支援我目前使用的開發板，接著測試完成後，再提交至 OE mailing list。大功告成。
2009年5月13日 星期三
S3C24xx ADC driver (2)
在第一篇文章中我們提到，adc driver 簡化了一部分硬體操作的細節，並提供 API 讓驅動程式使用。但就 touchscreen 驅動程式開發者的立場來看，它仍然有一些問題（以下純屬個人意見，僅供參考）：
也許以後會有所改變吧，不過，誰知道呢 :)
- 雖然它給予驅動程式開發者在擷取數據上的方便性，但並未處理與觸控板相關的硬體操作，故開發者仍必須自行設定相關的暫存器來處理按下及釋放的事件；由於 ADC 硬體本身就額外支援觸控板的功能，adc driver 做為硬體與 touchscreen driver 間的中介層，應儘量隱藏硬體的細節，並提供完整的介面供上層驅動程式使用，而如今開發者除了須自行設定暫存器外，還必須先查看 adc driver 的原始碼，了解它如何設定暫存器，以避免自己的程式碼去干擾 adc driver 的運作，似乎失去了資訊隱藏的意義。
- 這點比較見人見智；一般來說，驅動程式在呼叫 ioremap() 之前，會先呼叫 request_mem_region() 來防止其他驅動程式存取特定的暫存器群。但為了讓 touchscreen driver 也能夠存取暫存器，adc driver 允許 touchscreen driver 映射該區塊，於是變成兩個驅動程式存取同一組暫存器群的局面。我是不知道其他人怎麼想，但我就是覺得很怪，其中一部分程式碼若不小心更新了不該更新的暫存器，那是有可能會影響到另一個驅動程式的運作，造成潛在的錯誤。
也許以後會有所改變吧，不過，誰知道呢 :)
2009年4月3日 星期五
S3C24xx ADC driver
上個月花了相當多的時間在研究 S3C24xx 的觸控面板控制器和驅動程式，在這邊稍微分享一下心得，並介紹目前在 mainstream kernel 所實做的 ADC driver core。
S3C24xx 的 ADC 控制器共有 8 個 channel，其中有四個 channel 可設定來接收觸控螢幕的訊號，並提供多種轉換模式，例如手動轉換 x 及 y 座標，或是讓控制器自動轉換等等。同時控制器也可偵測觸控筆「按下」或「釋放」的動作。但是需注意的是，同一時間只能有一種模式可以運作；換言之，驅動程式必須適時地在以下三種模式間切換：
除了被用做接收觸控訊號的四個 channel 外，剩下的另外四個則可連接其他的感測器。過去分散於各個專案中的觸控驅動程式 (截至目前尚未整合進入 mainstream)，都是直接操作控制器，因而多出的四個 channel 即便接上了裝置，該驅動程式也無法與 touchscreen driver 共存 (不同的 driver 存取同一組暫存器會發生 race condition 的問題)。因此為了讓這些不同裝置的驅動程式能夠共用該控制器，Ben Dooks 在 2.6.28 引入了 ADC driver core (以下簡稱 adc driver)，定義了一組介面，讓上層驅動程式能夠透過該介面來使用控制器。
若要使用 adc driver，驅動程式需要定義自己的回呼函式 (callback function)，並向它註冊，註冊函式會回傳一個型態為 s3c_adc_client 的指標，其後的函式呼叫則以該指標做為第一個引數。adc driver 內部維護了一個要求佇列來紀錄來自外部的服務需求，並給予觸控有關的需求最高的優先權，以便可即時回應使用者的操作。在運作過程中，adc driver 會不斷地呼叫先前所註冊的 callback 以通知驅動程式處理取樣的數據，次數則可在要求服務時以參數設定。
對觸控驅動程式的開發者來說，adc driver 簡化了一部分複雜的細節，讓開發者透過函式介面來要求服務，而不必操作底層的暫存器。但我必須指出，它只是簡化了「一部分」，並非全部；至於為何，我們留待下一篇文章來探討。
S3C24xx 的 ADC 控制器共有 8 個 channel，其中有四個 channel 可設定來接收觸控螢幕的訊號，並提供多種轉換模式，例如手動轉換 x 及 y 座標，或是讓控制器自動轉換等等。同時控制器也可偵測觸控筆「按下」或「釋放」的動作。但是需注意的是，同一時間只能有一種模式可以運作；換言之，驅動程式必須適時地在以下三種模式間切換：
- 偵測「按下」的動作
- 偵測「釋放」的動作
- 取樣並轉換 x 及 y 座標
除了被用做接收觸控訊號的四個 channel 外，剩下的另外四個則可連接其他的感測器。過去分散於各個專案中的觸控驅動程式 (截至目前尚未整合進入 mainstream)，都是直接操作控制器，因而多出的四個 channel 即便接上了裝置，該驅動程式也無法與 touchscreen driver 共存 (不同的 driver 存取同一組暫存器會發生 race condition 的問題)。因此為了讓這些不同裝置的驅動程式能夠共用該控制器，Ben Dooks 在 2.6.28 引入了 ADC driver core (以下簡稱 adc driver)，定義了一組介面，讓上層驅動程式能夠透過該介面來使用控制器。
若要使用 adc driver，驅動程式需要定義自己的回呼函式 (callback function)，並向它註冊，註冊函式會回傳一個型態為 s3c_adc_client 的指標，其後的函式呼叫則以該指標做為第一個引數。adc driver 內部維護了一個要求佇列來紀錄來自外部的服務需求，並給予觸控有關的需求最高的優先權，以便可即時回應使用者的操作。在運作過程中，adc driver 會不斷地呼叫先前所註冊的 callback 以通知驅動程式處理取樣的數據，次數則可在要求服務時以參數設定。
對觸控驅動程式的開發者來說，adc driver 簡化了一部分複雜的細節，讓開發者透過函式介面來要求服務，而不必操作底層的暫存器。但我必須指出，它只是簡化了「一部分」，並非全部；至於為何，我們留待下一篇文章來探討。
2009年2月22日 星期日
Poky porting (2)
之前能夠以核心 2.6.29-rc4 成功編譯出的 task 為 poky-image-minimal，最近這兩天開始嘗試執行 poky-image-core，兩者的差別在於 minimal 只編譯了最少量的套件，只求可以開機就行；而 core image 則包括了完整的 GNOME Mobile 環境，也因此所需的編譯時間更久，也陸陸續續地遇到一些問題，其中比較大的問題主要是在核心模組的編譯之上。
怎麼說呢？目前所使用的版本為 Pinky-3.1.1 (08年六月釋出)，如果沒記錯的話，那時的核心大約是在 2.6.25 rc 階段。不過自 2.6.28 版以後，核心引頭檔的目錄架構出現了大變動：原來在 include/asm-*/ 之下的引頭檔搬移至 arch/*/include、arch/*/mach-*/include 及 arch/*/plat-*/include 之下，並取消了 symbolic link 的使用，全由 makefile 來決定要引用的目錄。因此問題就來了，用來編譯舊版核心的 bb 檔只需要複製 include/asm-*/ 下的引頭檔至 staging 目錄下即可；但到 2.6.28 版以後，引頭檔的路徑已經改變，故需要做特別的處理。因此在 Pinky-3.1.1 下，編譯完核心後，還得再手動複製必要的引頭檔至正確的路徑之下，後續的核心模組編譯才能正確執行。
不過看了一下 Poky git 中，最新的核心版本是 moblin 的 2.6.29-rc2，不確定能不能正確處理，嗯嗯…
PS.
用 uclibc 要編譯 poky-image-core 的套件還是會遇到許多問題，且都是編譯過程的錯誤；想要順利完成的話，建議還是用 glibc 比較好。
怎麼說呢？目前所使用的版本為 Pinky-3.1.1 (08年六月釋出)，如果沒記錯的話，那時的核心大約是在 2.6.25 rc 階段。不過自 2.6.28 版以後，核心引頭檔的目錄架構出現了大變動：原來在 include/asm-*/ 之下的引頭檔搬移至 arch/*/include、arch/*/mach-*/include 及 arch/*/plat-*/include 之下，並取消了 symbolic link 的使用，全由 makefile 來決定要引用的目錄。因此問題就來了，用來編譯舊版核心的 bb 檔只需要複製 include/asm-*/ 下的引頭檔至 staging 目錄下即可；但到 2.6.28 版以後，引頭檔的路徑已經改變，故需要做特別的處理。因此在 Pinky-3.1.1 下，編譯完核心後，還得再手動複製必要的引頭檔至正確的路徑之下，後續的核心模組編譯才能正確執行。
不過看了一下 Poky git 中，最新的核心版本是 moblin 的 2.6.29-rc2，不確定能不能正確處理，嗯嗯…
PS.
用 uclibc 要編譯 poky-image-core 的套件還是會遇到許多問題，且都是編譯過程的錯誤；想要順利完成的話，建議還是用 glibc 比較好。
2009年2月17日 星期二
Poky porting
最近這幾天，我一邊研究 OpenEmbedded building system 的目錄結構及設定檔撰寫，一邊嘗試利用 Poky 來編譯目前最新穩定版本 (2.6.28) 的核心。原因無他，主要是 2.6.27 以後的核心才有支援我現在使用的開發板。是故整個過程可分為兩階段，一是增加新版本核心用的 bb 檔案，另一項則為增加新硬體的設定檔。
要加入新版本核心其實可以將 meta/packages/linux/ 下的 bb 檔找一個你覺得適合的複製一份來改，內容大同小異，操作如下：
cd meta/packages/linux
vi linux-<MACHINE>_2.6.28.bb
# 填入自訂的內容，或複製現有的來修改
...
要注意的是，我們還需要再新建一個目錄，名稱如下所示，並複製核心使用的組態檔到該目錄下，檔名隨意，方便記憶即可：
mkdir linux-<MACHINE>
cp ~/defconfig ./defconfig-2.6.28
接著在修改 bb 檔時，幾個重要的變數需要設定：
再來就是在 bb 檔中撰寫上 patch 以及複製核心組態檔用的 shell script，這部分可以參考其他 bb 檔的做法，在此就不贅述。
加入新硬體的設定檔可參考 meta/conf/machine/ 下的檔案來修改，由於我的開發板和 OpenMoko 所使用的硬體是同屬於 S3C2440 的晶片，是故就直接複製 fic-gta01.conf 來修改：
cd meta/conf/machine
cp fic-gta01.conf <MACHINE>.conf
修改的部分如下：
修改完成後，在 build 目錄下 (別忘了要 source poky-init-build-env)，鍵入以下的指令：
bitbake linux-<MACHINE>
就會開始進行編譯程序。若發生錯誤，查看 build/tmp/work/<MACHINE>-poky-linux-gnueabi/linux-<MACHINE>.../temp/ 下的紀錄檔並修正。
目前已經加入了 2.6.28 及 2.6.29-rc4 的 recipe。其中 2.6.29-rc4 包含了開發板上 SD 控制器和 LCD 控制器的支援，相信不久應該就可以看到跑 GNOME Mobile 的樣子了。
要加入新版本核心其實可以將 meta/packages/linux/ 下的 bb 檔找一個你覺得適合的複製一份來改，內容大同小異，操作如下：
cd meta/packages/linux
vi linux-<MACHINE>_2.6.28.bb
# 填入自訂的內容，或複製現有的來修改
...
要注意的是，我們還需要再新建一個目錄，名稱如下所示，並複製核心使用的組態檔到該目錄下，檔名隨意，方便記憶即可：
mkdir linux-<MACHINE>
cp ~/defconfig ./defconfig-2.6.28
接著在修改 bb 檔時，幾個重要的變數需要設定：
PV: 套件版號，OpenEmbedded 會利用該變數來決定使用那個版本來編譯，預設是找最新的版本。 S: 套件原始碼目錄，也就是 tarball 解開後放置的路徑，在這個例子中是 ${WORKDIR}/linux-2.6.28
加入新硬體的設定檔可參考 meta/conf/machine/ 下的檔案來修改，由於我的開發板和 OpenMoko 所使用的硬體是同屬於 S3C2440 的晶片，是故就直接複製 fic-gta01.conf 來修改：
cd meta/conf/machine
cp fic-gta01.conf <MACHINE>.conf
修改的部分如下：
MACHINE_FEATURES = "kernel26 vfat ext2" MACHINE_DISPLAY_WIDTH_PIXELS = "800" - MACHINE_DISPLAY_HEIGHT_PIXELS = "480"
- PREFERRED_PROVIDER_virtual/kernel = "linux-<MACHINE>"
- 移除 MACHINE_CLASS
- 移除 MACHINE_EXTRA_RDEPENDS, MACHINE_EXTRA_RRECOMMENDS
- 移除 EXTRA_IMAGECMD_JFFS2
- 移除 SERIAL_CONSOLE
- 移除 EXTRA_IMAGEDEPENDS
修改完成後，在 build 目錄下 (別忘了要 source poky-init-build-env)，鍵入以下的指令：
bitbake linux-<MACHINE>
就會開始進行編譯程序。若發生錯誤，查看 build/tmp/work/<MACHINE>-poky-linux-gnueabi/linux-<MACHINE>.../temp/ 下的紀錄檔並修正。
目前已經加入了 2.6.28 及 2.6.29-rc4 的 recipe。其中 2.6.29-rc4 包含了開發板上 SD 控制器和 LCD 控制器的支援，相信不久應該就可以看到跑 GNOME Mobile 的樣子了。
2009年2月13日 星期五
Poky Linux 建構系統使用感想
最近為了要建立一個完整可供核心掛載的檔案系統，去玩一玩了 Poky 這個嵌入式套件。無可否認的，它所根基的 OpenEmbedded 是個很有彈性的套件建構系統，在已支援的開發板上，只要改一些設定，就可從無到有建構核心及所需的檔案系統映象 (file system image)，並且會幫你處理套件間相依性的問題，也可以只建構特定套件，打包成 ipkg 或 deb 檔以供其他系統使用。有過土法煉鋼、自己抓原始碼回來編譯的痛苦經驗的人，就會了解這個功能是多麼地令人叫好。
雖然功能強大，但若要加入新的開發板的支援，或是要解決某個套件不能順利編譯的問題，你就會發現，它的設定檔也是異常的複雜難懂；每個設定檔會去引用其他共享的檔案，並且預先設定一大堆變數。有些變數是在目前檔案被設定，有些則是在被引用時才設定。而被引用的檔案又會去引用其他的檔案……沒完沒了。
就在不久前，uClibc 發生編譯錯誤 (poky 3.1.1)，從錯誤訊息看來，發現是硬體架構設定錯誤所致。但找了老半天，就是不知道應該要改那個設定檔，令人懊惱。花了一個下午的時間，才找到問題的關鍵，修正後，這才能順利編譯。我另外把它做成了一個 patch，但我沒有網頁空間可以放，有相同問題的朋友可以來找我要，或有朋友願意提供他的空間也成。
延伸閱讀：
Embedded Linux 系統性的教學看法
Embedded Linux 應用的痛處: OpenEmbedded
雖然功能強大，但若要加入新的開發板的支援，或是要解決某個套件不能順利編譯的問題，你就會發現，它的設定檔也是異常的複雜難懂；每個設定檔會去引用其他共享的檔案，並且預先設定一大堆變數。有些變數是在目前檔案被設定，有些則是在被引用時才設定。而被引用的檔案又會去引用其他的檔案……沒完沒了。
就在不久前，uClibc 發生編譯錯誤 (poky 3.1.1)，從錯誤訊息看來，發現是硬體架構設定錯誤所致。但找了老半天，就是不知道應該要改那個設定檔，令人懊惱。花了一個下午的時間，才找到問題的關鍵，修正後，這才能順利編譯。我另外把它做成了一個 patch，但我沒有網頁空間可以放，有相同問題的朋友可以來找我要，或有朋友願意提供他的空間也成。
延伸閱讀：
Embedded Linux 系統性的教學看法
Embedded Linux 應用的痛處: OpenEmbedded
2008年12月20日 星期六
關於 touch screen driver
其實 touch screen driver 的部分，這裡和這裡的文章已經提過了，只要把 patch 抓下來 apply 至核心原始碼中，再加上些修正即可。不過沒人規定不能重新發明輪子吧？我還是想先自己寫寫看，來了解一下應該如何去設定相關的控制器，以及實際在板子上的運作情況如何。既然是自己找樂趣玩，又有何不可？
不過實際寫了之後，發現雖然使用手冊詳實敘述了各個暫存器的意義，但對於該如何設定以及設定順序為何，還是非常空洞；沒辦法，再回去參考了 patch 的原始碼，才豁然開朗。但話說回來，經過了親手下去實作的過程，有了更深一層的了解，再回來看原始程式，才能很快地抓住你所想知道的關鍵部分，並立即套用至你的程式中。這也算是一種學習驅動程式撰寫的方法之一吧…
接下來，再把程式修改修改，就可以上版子來測試了。
不過實際寫了之後，發現雖然使用手冊詳實敘述了各個暫存器的意義，但對於該如何設定以及設定順序為何，還是非常空洞；沒辦法，再回去參考了 patch 的原始碼，才豁然開朗。但話說回來，經過了親手下去實作的過程，有了更深一層的了解，再回來看原始程式，才能很快地抓住你所想知道的關鍵部分，並立即套用至你的程式中。這也算是一種學習驅動程式撰寫的方法之一吧…
接下來，再把程式修改修改，就可以上版子來測試了。
2008年11月17日 星期一
2008年10月11日 星期六
加入 Frame buffer 支援
上個月底，我上傳了另一個 patch，主要為加入開發板的 LCD 支援。由於 S3C2440 的 LCD 控制器已有完整的驅動程式支援，是故在設定上也相當容易。你需要根據面板的 datasheet 來設定如解析度、pixel clock、bpp (bits per pixel)和其他相關的 timing 參數，剩下的 LCDCON5 的內容可直接參考其他開發板的設定。
和面板有關的參數設定在 struct s3c2410fb_display 這個結構中，其宣告為
struct s3c2410fb_display {
/* LCD type */
unsigned type;
/* Screen size */
unsigned short width;
unsigned short height;
/* Screen info */
unsigned short xres;
unsigned short yres;
unsigned short bpp;
unsigned pixclock; /* pixclock in picoseconds */
unsigned short left_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short right_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short hsync_len; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short upper_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short lower_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short vsync_len; /* value in lines (TFT) or 0 (STN) */
/* lcd configuration registers */
unsigned long lcdcon5;
};
以我的面板為例，這塊面板是 HITACHI 的七吋面板，型號為 TX18D16VM1CAA，根據手冊所記載，其可接受的 pixel clock 的最大週期為 33ns (相當於 30KHz)；Hsync 訊號寬度為 128 個 pclk，螢幕左方邊界寬度為 88 個 pclk，右方為 40 pclk；Vsync 訊號寬度為 2 個 Hsync 週期，上方邊界寬度為 32 個 Hsync，下方為 11 個 Hsync。解析度為 800x480。
程式碼加入後，在 make config 中開啟 S3C24xx 之 frame buffer 支援，重新編譯後下載至開發板即可。
另外，你也可以在核心啟動參數中加上 fbcon=rotate:<n> 來設定螢幕的方向。0 為不旋轉，1 為旋轉 90 度，2 為旋轉 180 度，3 為旋轉 270 度，方向皆為逆時針方向。
和面板有關的參數設定在 struct s3c2410fb_display 這個結構中，其宣告為
struct s3c2410fb_display {
/* LCD type */
unsigned type;
/* Screen size */
unsigned short width;
unsigned short height;
/* Screen info */
unsigned short xres;
unsigned short yres;
unsigned short bpp;
unsigned pixclock; /* pixclock in picoseconds */
unsigned short left_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short right_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short hsync_len; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short upper_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short lower_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short vsync_len; /* value in lines (TFT) or 0 (STN) */
/* lcd configuration registers */
unsigned long lcdcon5;
};
以我的面板為例，這塊面板是 HITACHI 的七吋面板，型號為 TX18D16VM1CAA，根據手冊所記載，其可接受的 pixel clock 的最大週期為 33ns (相當於 30KHz)；Hsync 訊號寬度為 128 個 pclk，螢幕左方邊界寬度為 88 個 pclk，右方為 40 pclk；Vsync 訊號寬度為 2 個 Hsync 週期，上方邊界寬度為 32 個 Hsync，下方為 11 個 Hsync。解析度為 800x480。
程式碼加入後，在 make config 中開啟 S3C24xx 之 frame buffer 支援，重新編譯後下載至開發板即可。
另外，你也可以在核心啟動參數中加上 fbcon=rotate:<n>
2008年9月12日 星期五
[好文] 如何加入 Linux 開發社群
How to participate in the Linux Community
http://ldn.linuxfoundation.org/book/how-participate-linux-community
就在幾個月前，動心起念想要貢獻一些程式碼時，還真是不知該如何入門；深怕一個不小心，也許是程式的錯誤，或是英文不好引起誤會，或不了解某些規矩，而被 list 上的開發者給打槍，並回以鄙夷的指責。不過在 post 了幾個 patch 之後，事實證明了我是多慮了。當然還是有些規矩要遵守，只是犯了錯也沒那麼嚴重，通常開發者會好心提醒你該作什麼事，改回來就好，社群仍然會歡迎你的加入。
當然如果可以有一些文件教導我們這些新人，豈不更好？幸好有這本小書的出現，替我們指點迷津。24 頁的內容包含新進開發者該有的心態，以及該如何和社群互動、修改程式、準備及上傳 patch、撰寫信件的注意事項、開發者常犯的錯誤等等，足夠菜鳥們在正式踏入前有個心理準備，而我也從中受惠許多，發現了一些自己不曾注意到的小細節，或許可以再做得更好。
總之，強烈推薦新進開發者一定要讀讀這本書。
http://ldn.linuxfoundation.org/book/how-participate-linux-community
就在幾個月前，動心起念想要貢獻一些程式碼時，還真是不知該如何入門；深怕一個不小心，也許是程式的錯誤，或是英文不好引起誤會，或不了解某些規矩，而被 list 上的開發者給打槍，並回以鄙夷的指責。不過在 post 了幾個 patch 之後，事實證明了我是多慮了。當然還是有些規矩要遵守，只是犯了錯也沒那麼嚴重，通常開發者會好心提醒你該作什麼事，改回來就好，社群仍然會歡迎你的加入。
當然如果可以有一些文件教導我們這些新人，豈不更好？幸好有這本小書的出現，替我們指點迷津。24 頁的內容包含新進開發者該有的心態，以及該如何和社群互動、修改程式、準備及上傳 patch、撰寫信件的注意事項、開發者常犯的錯誤等等，足夠菜鳥們在正式踏入前有個心理準備，而我也從中受惠許多，發現了一些自己不曾注意到的小細節，或許可以再做得更好。
總之，強烈推薦新進開發者一定要讀讀這本書。
訂閱：
文章 (Atom)