最近新釋出的 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 的程式碼時相對比較麻煩，不過其效果似乎是值得這麼做的。
訂閱：
文章 (Atom)