? ? ? ? 轉載自前同事zhouyuanjie。?

• 問題環境

project：ubox

openwrt：v18.06.4

kernel：4.14.98

uboot：2018.03

• 問題現象

在openwrt編譯ubox鏡像后，使用鏡像啟動偶現鏡像卡在“Starting kernel ...”階段。

ubox鏡像是通過mkimage工具做的FIT鏡像，配置如下：

• 問題分析

分析一：????????

因未打包的源文件在uboot中使用的是booti命令啟動，FIT鏡像需要使用bootm命令啟動，所以將有問題的FIT鏡像采用booti的命令啟動，發現能夠正常啟動，判斷FIT打包前的源文件是沒有問題的，排除因去掉了不該去掉的配置造成不能啟動的情況。

分析二：

因問題是屬于uboot->kernel的交付階段，在此階段沒有可用調試工具和設備，則采用黑盒和代碼分析的方法，首先分析bootm的啟動流程：

do_bootm	bootm命令
do_bootm_states	完成image和fdt的查找、解壓、裝載等動作
boot_selected_os	選擇從什么啟動系統并設置回調函數
do_bootm_linux	為啟動image做準備，如關閉dcache等
armv8_switch_to_el2	選擇啟動模式（32 or 64）和級別（el2為系統級別）
armv8_switch_to_el2_m	實際啟動內核

經上述流程分析發現，uboot在實際啟動前做了級別切換，懷疑CPU在進入kernel前進入了某種模式，導致CPU卡死在uboot中？然后分析kernel啟動代碼，并在kernel中添加點亮led的方式確定CPU是否成功進入內核，代碼如下：

經上述內核代碼調試分析后發現，在上圖（1）的位置CPU會拋出（synchronoud abort異常，led實則未點亮，看拋出的這個異常大致確定是尋址或譯碼上的問題，此處并未深究，但能夠拋出異常也能確定是進入kernel中），而去掉圖（1）在圖（2）出則會卡死，分析問題點代碼{

????????adr_l x0, __hyp_stub_vectors

????????msr vbar_el2, x0

}，異常點代碼是在設置異常向量表后卡死。經objdump分析判斷CPU在uboot交付kernel后產生異常，進入異常處理（死循環），詳見下圖：

經上述分析，啟動過程中是卡死在kernel階段，并且是在設置異常向量表后出現的異常，所以排除是因uboot模式切換錯誤導致的卡死。因無法確定CPU是產生的哪種異常，所以啟動流程暫停分析。

分析三：

結合分析一、分析二，在有問題的FIT的鏡像使用FIT源文件用booti命令能夠成功啟動。則嘗試在do_bootm_states鏡像裝載完成后，調用booti去啟動內核，代碼如下：

經嘗試，在bootm鏡像裝載完成后，使用booti命令啟動問題依然。繼續分析booti和bootm啟動流程的差異點，發現booti和bootm的啟動流程基本相同，所不同的是，在booti在調用do_bootm_states前對裝載的鏡像做了偏移操作，如下：

經偏移操作后，kernel的FIT鏡像中的Load地址為0x4380000，經偏移后實際使用地址為0x43880000，懷疑問題在kernel或fdt的load地址上。

分析四：

經分析三結論，嘗試修改FIT鏡像中的kernel和fdt的load地址，如下：

經多次嘗試發現一個共同點，就是kernel的地址后面必須是0x80000（bootm并不會做對齊操作），并且fdt的load地址必須對齊（fdt的load地址在openwrt中默認是沒有的，則bootm解析FIT后fdt的load地址為bootm裝載的地址），結合分析三和linux-4.14.98/Documentation/arm64/booting.txt，以及查看kernel頭部信息確認，頭部信息中確實設置了相關位置，并且load的地址需要做偏移，如下：

• 結論

經問題分析測試后，確定問題有兩點。

• kernel的load地址必須偏移0x80000，如基址是0x43800000則實際的load地址必須是0x43880000；
• 固定fdt的load地址。

因上述兩點則會導致，進入kernel后CPU出現異常被掛起。

總結

以上是生活随笔為你收集整理的imx8mm偶现启动内核失败问题分析报告的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。