STM32MP157核心移植相關bug

STM32MP157 官方Linux5.15核心移植相關bug

• 一、主頻問題
• 二、驅動開發時的頭檔案缺失問題
• 三、結語

一、主頻問題

  在初學STM32MP157驅動開發時，筆者曾對官方最新版的Linux核心進行了移植，但是因為一些問題，導緻移植後的系統存在一些bug。最近筆者又重新對這部分做了一些了解，發現了一些問題，有興趣的可以一起探讨。

  首先是主頻問題，按照相關教程對TF-A和U-Boot進行移植後，在U-Boot中顯示的晶片主頻為650MHz。筆者使用了很多方法嘗試修複，比如在U-Boot的裝置樹中修改 PLL 倍頻、去除U-Boot中的pmic電源晶片驗證、ADC和DAC驗證等，但是并沒有修複。最後筆者使用非驗證方式的U-Boot進行燒寫，也就是将U-Boot編譯産生的u-boot-spl.stm32作為fsbl，直接作為引導，将u-boot.stm32直接作為啟動檔案，發現可以正确識别晶片并可以使用800MHz工作頻率。然後将TF-A重新加到U-Boot的頭部之後就又回到650MHz。(這裡也使用了多種方式進行頭部驗證，包括Makefile.sdk直接編譯出fip和metadata、使用fiptool手動合成等等），是以筆者猜測在TF-A中還是存在某些驗證方式，例如pmic晶片驗證、ADC輸入電壓采樣驗證等，導緻晶片無法正确工作。

  後續筆者又采取了一些方式嘗試修複：

• 1.使用舊版本的TF-A編譯出BL32，作為新版本U-Boot的頭部驗證

  這種方式會出現BL32無法正确引導BL33(也就是U-Boot)的現象，具體表現為開機進入BL32(SP_MIN方式)後一直重新開機，無法正确加載U-Boot。

• 2.按照官方手冊，将新版U-Boot的xxxx-fw-config.dts編譯出.dtb裝置樹檔案，作為TF-A的配置檔案，然後編譯出頭部資訊添加。

  這種方式也沒法修複主頻bug。

最後将正點原子官方的出廠鏡像進行燒錄，發現該鏡像在啟動時直接跳過了頭部資訊驗證。

這裡就要提一下V2.6版本的官方移植包問題，此版本在官方的開發手冊中，原則上應該先對U-Boot進行編譯，得到u-boot-nodtb.bin檔案和u-boot.dtb檔案，然後再生成u-boot-trusted.dtb，作為TF-A的輸入配置，之後再編譯TF-A，得到fip-tf-a-trusted.bin檔案和metadata.bin檔案，其中fip-tf-a-trusted.bin就是SP_MIN驗證資訊和U-Boot的結合，metadata.bin則是對此檔案的驗證。

是以這裡筆者猜測，如果想要修複U-Boot中的主頻bug，應該使用以下方法：

1.使用原子哥的方式，直接跳過頭部資訊驗證，也就是将TF-A與U-Boot分離開來。

這種方式也存在一些問題：其一，TF-A無法再起到驗證作用，那麼這部分的開發就失去了設計的意義。其二，需要對TF-A内部進行修改，目前對筆者來說難度較大。

2.修改TF-A内部的驗證方式

筆者猜測，在ST提供的源碼中，TF-A内部應該存在某種對外設的驗證，當外部沒有此裝置時，就自動降頻到安全一點的工作模式。比如前面提到的pmic晶片、ADC采樣某個管腳的電壓值驗證等。僅是猜測，還有待驗證。

3.使用官方推薦的pmic電源晶片。

注：這部分僅為筆者猜測

，因為國産的一些第三方的開發闆與官方的闆子最大的差别就是在這裡，是以如果想自己做闆子并移植最新版的核心，目前來看還是複刻一下最好。之後有新版本的移植方式再替換。

二、驅動開發時的頭檔案缺失問題

  在基于Linux-5.15的源碼包進行開發時，會出現頭檔案缺失問題，例如<linux/ide.h>、<linux/module.h>問題，這裡筆者在源碼包下進行了查找，并沒有查詢到相關的頭檔案，也找不到能夠相容和替代的類似頭檔案。是以筆者猜測，可能是在新版本的核心中，相關的驅動開發方式有了新的變化。(也可能是官方還沒移植完善就上架了，哈哈)。

  不過筆者嘗試，将原子哥教程中的相關頭檔案，拷貝到新版本的對應目錄中，編譯出來的驅動也能夠在5.15核心中運作，是以如果确實想用新版本開發驅動，可以暫時嘗試一下此方法，之後再等待各大廠商教程的跟進。

三、結語

  筆者原以為學習完了相關教程，就能夠對這些bug進行修複，結果發現還是能力不足，學海無涯，諸君共勉。以上的bug原因也僅是筆者的猜測，歡迎有興趣的大佬們一起探讨。筆者對于Linux驅動開發的學習也到此告一段落，之後也許會找一些新的方向進行學習。