在之前的文章有提到, 移植 Linux kernel 的情況依困難程度從難到易列出為下列四種.
而前一篇已經提過如何將新版 Linux Kernel 移植到舊有平台上進行 Kernel 版本升級
1. 將 Linux Kernel 移植到全新 CPU architecture 上
2. 將新版 Linux Kernel 移植到全新 SoC 上
3. 將新版 Linux Kernel 移植到全新平台上
4. 將新版 Linux Kernel 移植到舊有平台上進行 Kernel 版本升級
一般來說, SoC 原廠都會附上 BSP. 但基於下列原因, 建議換成自己屬意的 kernel 版本
- SoC BSP 維護年限不長, 當 EOL 之後還是要靠自己
- 各 SoC BSP kernel 版本不統一, 造成維護上的成本上升
- 發揚 R&D 魂, 親手打造並客製 kernel
而這篇主要分享將新版 Linux Kernel 移植到全新平台上所需的步驟以及需要注意的地方
在此階段的移植, 不能確定硬體具備穩定性. 所以移植上若出現問題, 要對任何事物都抱持高度懷疑的態度. 並協同 bootloader/ 硬體工程師合作解決問題
1. 事前準備事項:
- 平台規格書
→ 確保設計規格符合需求 (Verification)
- 硬體以及週邊元件電路圖
→ 確保硬體設計符合平台規格 (Validation)
- 硬體通過 bootloader 測試
→ 確保 SoC Pin multiplexing 已被設定正確 (有些 SoC 無法在 kernel 中設定 Pin multiplexing)
→ 確認振盪器頻率已被設定正確以當參考時脈
- DRAM 測試報告
→ 確認 DRAM 設定 (refresh rate, size 等等) 已被 bootloader 設定妥當, 並通過長時間測試驗證.
- SoC/ 週邊元件 datasheet
→ 根據硬體料號來找尋對應的最新版 data sheet, 必要時需連絡 FAE.
→ 根據 data sheet 以設定相對應的硬體功能.
- SoC/ 週邊元件 errata
→ 根據硬體料號來找尋對應的最新版 errata (有些errata會附在 data sheet 後面), 必要時需連絡 FAE 拿取.
→ errata 可以用來協助定位問題, 看要將問題列為功能限制或者找出 in-house patch 以進行 work-around.
- SoC 原廠 BSP, 含 device tree 以及 kernel configuration
→ 若移植出現問題時, 可用來和原廠 BSP 比較以確認問題.
→ 可協助找出 in-house patch
- “最新” mainline Linux kernel, 含 device tree 以及 kernel configuration
→ 若移植出現問題時, 可用來和新版本比較以確認問題.
- 為此平台量身打造的測試計劃以及經過驗證的測試程式
→ 因為此平台的硬體以及週邊元件皆未經過測試驗證, 所以我們需要經過驗證的測試程式以及良善的測試計劃來驗證此平台.
→ 良好的測試程式能在除錯階段提供充份資訊以供參考
2. 確立欲移植的 kernel
可至 kernel 網站下載想要移植的 kernel 版本.
- kernel newbie 網站會提供每一版 kernel 的新增修改歷程, 建議閱讀從原有版本到欲移植 kernel 每一版中的差異
- 建議下載 LTS 版本的 kernel
- 需確認該版 kernel 內含有 SoC 的 dtsi (device tree include, SoC-level 的硬體描述檔, 基本上由 SoC 廠商提供), 如果沒有則需找到含有 dtsi 的 kernel source, 適情況進行 backport
3. 進行移植
將新版 Linux Kernel 移植到全新平台上主要的階段如下:
- 撰寫平台之硬體資訊撰寫平台之硬體資訊
- 產生該平台專屬之 kernel configuration
- 找出 In-house patch, 並進行處理
- 找出 Out-of-tree patch, 並進行處理
- 產出 kernel image
- 若移植平台開不了機, 可參考這篇文章
| 階段 | 動作 | 除錯方法 | 產出檔案 |
|---|---|---|---|
|
撰寫平台之硬體資訊 |
|
|
|
| 產生該平台專屬之 kernel configuration |
|
|
|
| 找出 BSP In-house patch |
|
|
|
| 找出 Out-of-tree patch |
|
|
|
進行上述動作前, 請務必使用版本控制系統來管控開發中的 kernel source (推薦使用 git). 讓任何的修改都需有所本.
移植新平台時, 請把握四個原則
√ 先選用網路或者易插拔的裝置開機
先使用網路或者易插拔的裝置開機 e.g. tftpboot, USB, SD card 等等. 避免一開始就使用 NAND flash, eMMC, UFS 這種 on-board 的裝置進行開發. 不然一旦開發出現問題, 會耗費許多時間在進行更新.
√ 先移植網路功能
只要網路先通, 後續在 OS 中更新 kernel image/ device tree 都可以透過網路, 而不需要進行 tftpboot or 插拔 storage 等等的動作.
而網路功能需先設定下列項目
- Ethernet 相關 PIN MUX
- PHY dts & device driver
- Ethernet dts & device driver
√ 設檢查點並進行回歸測試
在開發中後期所移植的功能設定有可能會影響前期的正常功能. 但發現時往往無法追溯究竟是哪一個 commit 所造成. 此情況需要花費許多心力來查找. 所以設檢查點, 進行回歸測試就非常重要.
√ 長期且大量測試
新的平台需要層層關卡來驗證功能面, 但許多問題都是經過長期測試後才會浮現 (e.g., hwclock 一段時間後不準, 或者重開機 3000 次後會死機等等)
4. 在標的物上進行測試
√ 更新 kernel image/ device tree
在更新 kernel image/ device tree 時, 請不要直接覆蓋掉原本的 kernel image/ device tree. 先把原本可以正常運行的 kernel image/ device tree 改名 (e.g. uImage.old) 再進行更新.
如此可以避免新版 kernel image/ device tree 出問題開不了機導致需要插拔 storage等等耗費時間的動作. 只需要修改 uboot command 即可進去系統重新更新.
√ 檢查開機訊息
- 開機訊息中不能有任何 warning /error
- 系統資訊是否正確 (kernel version, machine model, clocksource等等資訊)
- 檢查開機時間是否正常. 若有開機過久的情況, 可能 kernel 移植有所問題.
√ 測試遇到問題
請先定位問題, 並先排出硬體, 治具, 測試環境, 測試程式, 網路環境等等的因素.
若是進行 driver debugging, 則可以使用 nfs 來掛載開發中的 driver 目錄. 避免一直進行重覆 copy 的動作.
√ 測試結束
請備份當下 image, 當成 golden sample. 若之後修改有問題, 還有 image 能夠對照.
SZ Lin with Cybersecurity & Embedded Linux 