kernel移植——从三星官方内核开始移植
以下內容源于朱有鵬嵌入式課程的學習，如有侵權，請告知刪除。
一、內核移植初體驗
1、三星官方移植版內核獲取
- 源碼包來于三星的SMDKV210開發板附帶的光盤資料，下載地址。
2、構建移植環境
（1）Windows下建立SI工程；
- 建立前刪除不必要的目錄和文件：刪除arch目錄下非arm架構的目錄文件；刪除arch/arm目錄下不是三星的mach-xxx、plat-xxx目錄。
（2）ubuntu下解壓；
3、配置、編譯
（1）檢查Makefile中ARCH =arm 和CROSS_COMPILE =/usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-；
（2）make xx_defconfig；（如何確定xx_defconfig？這里是smdkv210_android_defconfig）
- 在arch/arm/configs下有很多，找到三星相關的。這里找一個最像的：smdkv210_android_defconfig
（3）make menuconfig；（目前還不知道修整哪些）
（4）make -j4（直接make，則會直接單線程編譯；如果make -j4，則會4線程編譯）。
4、將得到的zImage下載運行看結果
- 編譯完成后得到的內核鏡像不在源碼樹的根目錄下，而是在arch/arm/boot這個目錄下。
- 通過tftp將鏡像下載到開發板，操作過程見博客http://blog.csdn.net/oqqhutu12345678/article/details/70537721。
（1）結果
- 只見到uboot打印出的下圖信息，看不到linux自解壓代碼打印出的“Uncompressing Linux... done, booting the kernel.”
（2）分析
- 說明zImage根本沒有被解壓成功，內核代碼根本就沒有被運行。因此問題出在解壓相關的部分。
- 問題出在解壓后代碼放置的內存地址處（該地址可以由內核配置的，如果不對，則內核不能運行）。
- 內核配置的解壓地址應該等于連接地址，否則自解壓之后內核無法運行。
- 現在問題變成：第一，內核的連接地址等于多少？第二，內核中配置的解壓地址是多少？
- 這里面還有個問題：內核的連接地址是一個虛擬地址，而自解壓代碼解壓內核時需要物理地址（此時mmu還沒開，因為內核還沒有開始運行），因此連接地址對應的物理地址等于自解壓地址。
- 連接地址和對應的物理地址在head.S中可以查到，經分析（在.config中查宏TEXT_OFFSET，合成）得知分別是0xC0008000和0x30008000，那么自解壓代碼配置的解壓地址應該是30008000。
（3）修改操作
- 自解壓代碼對應的自解壓地址在mach-s5pv210/Makefile.boot文件中。
- 在此文件后面追加入下面內容。
- （實踐中這樣好像并沒有預期的結果。因此我直接賦值不使用宏。問題是，為什么這里的宏不起作用？因為我寫錯了，尷尬……）
（4）同步、編譯，重新下載運行查看結果
- 因為只修改了一些鏈接參數，不需要重新配置編譯，所以make很快就完成了。
- 自解壓代碼解壓打印信息已經出來；
- 內核還是沒有運行；
（5）問題分析
- 因為我們在uboot中配置的空間為3000 0000開始（而不是2000 0000開始），因此這里定義的物理地址不對，從20000000改到30000000即可。
（6）重新編譯，運行結果：內核打印出很多運行信息。
二、內核中機器碼的確定（知識課程）
內核支持什么架構、支持哪款cpu是怎么確定的。內核中保存了一份機器碼，會和uboot傳過來的機器碼比對（在head.s中比對uboot傳過來的機器碼），比對成功說明uboot和內核是匹配的。 之前講過uboot如何給內核傳機器碼。本課講內核的機器碼是怎么確定的，怎么來的。
每個mach-xx文件夾代表一種cpu，其內可能包含cpu相同的不同開發板。比如mach-s5pv210文件夾內有mach-smdkc110.c和mach-smdkv210.c等開發板。
1、MACHINE_START宏
- 這個宏用來定義一個機器碼的數據結構。
- 即用來定義一個結構體類型為machine_desc類型的結構體變量，名為__mach_desc_SMDKV210。
- 這個結構體變量會被定義到一個特定段.arch.info.init，因此這個結構體變量將來會被鏈接器鏈接到這個.arch.info.init段中。
比如?MACHINE_START(SMDKV210, "SMDKV210")解釋為下面內容。
static const struct machine_desc __mach_desc_SMDKV210 \__used \__attribute__((__section__(".arch.info.init"))) = { \.nr = MACH_TYPE_SMDKV210,//機器碼2456 \.name = "SMDKV210",.phys_io = S3C_PA_UART & 0xfff00000,.io_pg_offst = (((u32)S3C_VA_UART) >> 18) & 0xfffc,.boot_params = S5P_PA_SDRAM + 0x100,.init_irq = s5pv210_init_irq,.map_io = smdkv210_map_io,.init_machine = smdkv210_machine_init,.timer = &s5p_systimer, };（1）mach-xxx.c文件定義了一個機器碼的開發板的machine_desc結構體變量（一個機器碼對應一個開發板，一個cpu可以對應多個開發板）
- 這個結構體變量放到.arch.info.init段中后，表示當前內核可以支持這個機器碼的開發板。
（2）我們所移植的目標開發板使用S5PV210的CPU，開發板名字叫X210。
- 但在三星官方版本的內核中找不到mach-x210.c；
- 但不想從零開始移植，因此在三星移植的mach-s5pv210目錄下找一個mach-xx.c，使得該開發板和X210開發板最為接近（同一款cpu），然后以此為基礎來移植。
（3）經過查看，發現mach-s5pc110.c和mach-s5pv210.c與X210開發板最為接近。
- 尋找原則：開發板和三星官方的哪個開發板最為相似。
- X210開發板抄的是三星的SMDKV210，因此要找SMDKV210對應的文件（按理應該是mach-smdkv210.c，但實際是嗎？）
（4）結合mach-s5pv210目錄下的Makefile來分析，得知.config中定義CONFIG_MACH_SMDKV210后，實際綁定的是mach-smdkc110.c這個文件。
- 因此實際上mach-smdkv210.c這個文件根本沒用到。
2、硬件驅動的加載和初始化函數執行
.init_machine = smdkc110_machine_init,
- 定義了一個機器硬件初始化函數；
- 這個函數非常重要，這個函數中綁定了開發板linux內核啟動過程中會初始化的各種硬件的信息。
- 在此函數中添加的才會被初始化，否則不會被初始化。
- 這篇視頻末尾的知識，可以強化內核分析的學習。
三、解決內核啟動中的錯誤
1、認識內核啟動OOPS（內核死亡信息）
（1）內核啟動后會有打印信息，打印信息中隱藏了問題所在。
- 認真的去分析這個打印信息，從中找到對的或者錯誤的一些信息片段，才能幫助我們找到問題，從而解決問題。
（2）內核啟動中的錯誤信息的特征
- 由PC和LR的值可以看出，程序執行到dev_driver_string或者max8698_pmic_probe（這兩個是函數或者匯編中的標號）符號部分的時候出錯了。
- 我們從這兩個符號出發去尋找、思考可能出錯的地方然后試圖去解決。
2、錯誤追溯及問題解決
（1）max8698_pmic_probe
- max8698這個電源管理IC的驅動安裝函數部分出錯；
- 開發板系統中配置了支持這個電源管理IC，于是啟動時去加載它的驅動，結果驅動在加載執行的過程中出錯。
（2）這個驅動加載時為什么會出錯？
- 結合X210開發板的硬件實際情況來分析：X210開發板上根本就沒有max8698這個電源管理IC，既然硬件都沒有，執行驅動肯定會出錯。
- 移植三星版本的uboot時，在uboot的lowlevel_init.S中也有調用電源管理IC初始化函數（PMIC_init），結果會報錯，屏蔽掉該函數的調用，uboot就可以成功運行下去。
（5）為什么uboot和內核中，都默認調用這個電源管理IC的初始化代碼？
- 因為三星的SMDKV210開發板中用了max8698這個電源管理IC，因此三星的uboot和kernel中都默認支持這個。
- 但是X210中是沒用的，因此uboot和內核中都需要去掉該代碼模塊。
（6）怎么解決？
- 在uboot中，是直接改源代碼，即屏蔽掉那個初始化函數解決的；
- 在kernel中，不能直接修改源代碼。
- 因為linux kernel是高度模塊化高度可配置的，內核中每一個模塊都被配置項條件編譯；
- 因此要去掉對某個模塊的支持，需要重新配置，配置時去掉選項即可，不用改源代碼。
- 因此關鍵就是要找它對應的配置項。
（7）操作
- 先make menuconfig；
- 然后/搜索"MAX8698"這幾個關鍵字，然后看到這個配置項的路徑，然后到路徑下去按N鍵去掉這個模塊的支持，保存，重新編譯即可。
（8）重新編譯、下載運行
- 此問題被解決了；
- 內核再次啟動后直接運行到掛載rootfs才出錯。
3、分析及總結
分析：根本原因在于CONFIG_MFD_MAX8698這個配置宏。這個配置宏決定了很多東西
- 第一：這個配置宏決定了drivers目錄下的max8698對應的驅動程序源代碼是否被編譯；
- 第二：這個配置宏決定了kernel啟動過程中是否會調用一些max8698的相關的代碼；
總結：kernel是高度模塊化和可配置化的，所以在內核中做任何事情（添加一個模塊、更改一個模塊、去掉一個模塊）都必須按照內核設定的方案和流程。
四、iNand的問題和安排
1、錯誤分析
（1）內核錯誤信息：Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)。
- 內核試圖掛載根文件系統時失敗，失敗的原因是unknown-block（不能識別的塊設備）
（2）backstrace分析，可以得知錯誤信息的來源，再結合之前的內核啟動流程分析，就更加確定出錯的地方。
（3）為什么unknown-block(0,0)？
- 在kernel啟動時，uboot給內核傳遞一個cmdline。
- 其中root=xx指定rootfs在哪個設備上，內核會到相應的地方去掛載rootfs。
- 譬如root=/dev/mmcblk0p2，這里的/dev/mmcblk0p2就是rootfs所在的設備的地址。
- 它表示mmc設備0的第2個分區（設備0，即在SD0通道上的設備，即iNand）。
- 這里的問題就是沒找到mmc設備0的第2分區。
（4）為什么沒找到mmc設備0的第2分區？
- 一定是因為kernel啟動過程中加載mmc驅動的時候有問題，驅動沒有發現mmc設備0。
- 問題定位在MMC相關的驅動方面。
（5）對比九鼎版本的內核啟動信息
下圖是九鼎版本的內核啟動信息部分截圖
- 可發現待移植的內核啟動時，沒有找到MMC設備（內置的iNand和外置的SD卡都沒找到）；
- 沒找到肯定是驅動的問題，因此要移植MMC驅動。
2、知識補充
（1）SD/iNand都是由一個一個的扇區組成的
- BL1從SD卡的1扇區開始往后存放；
- SD卡的0扇區是不用的，SD卡的0扇區用來放置MBR（主引導記錄）。
（2）MBR用來描述塊設備的分區信息
- 事先定義了一個通用的數據結構來描述塊設備的分區；
- 只要將分區信息寫入MBR中，即可完成對該設備的分區；
- MBR默認存放在塊設備的第0個扇區。
（3）內核如何知道iNand分了4個分區？哪里對inand進行了分區？
- uboot中有一個命令fdisk，fdisk -c 0時，對iNand進行分區；
- fdisk命令對iNand的分區已經寫死，內核通過讀取MBR，就可以知道分區信息了；
- 由iNand本身通過MBR給內核傳遞分區信息，因此uboot給內核傳參時，不用傳遞分區表信息。
（4）如果開發板使用的是nandFlash，分區表一般是在內核中用代碼構建的。
- 因此nand版本的內核移植時，一般都需要移植、更改nand分區表。
3、解決安排
- 暫時解決不了這個問題……
五、網卡驅動的移植和添加實驗
1、移植標準
（1）網卡驅動移植ok時，啟動信息為
[ 1.452008] dm9000 Ethernet Driver, V1.31 [ 1.455870] eth0: dm9000c at e08f4300,e08f8304 IRQ 42 MAC: 00:09:c0:ff:ec:48 (platform data) （2）當前內核中網卡驅動尚未移植，因此內核啟動時有錯誤的打印信息： [ 1.130308] dm9000 Ethernet Driver, V1.31 [ 1.133113] ERROR : resetting [ 1.135700] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.140915] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.145941] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.150963] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.155992] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.161018] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.166041] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.171070] dm9000 dm9000.0: read wrong id 0x2b2a2928 [ 1.176092] dm9000 dm9000.0: wrong id: 0x2b2a2928 [ 1.180774] dm9000 dm9000.0: not found (-19).
（3）移植的目標
- 讓此版本的內核可以打印出正確情況下的啟動信息。
2、make menuconfig中添加DM9000支持
- 搜索/DM9000，找到所在路徑。
- menuconfig中選擇Y。
3、mach-smdkc110.c中邏輯分析
（1）mach-smdkc110.c中的smdkc110_machine_init是整個開發板的所有硬件的初始化函數
- 在這里被加載的硬件，在將來啟動時就會被初始化；
- 在這里沒被加載的硬件，在將來啟動時就不管。
- smdkc110_dm9000_set()，是和DM9000相關的SROM bank的寄存器設置；
- 其相當于uboot中dm9000移植時的dm9000_pre_init函數，只是讀寫寄存器的函數名稱不同了。
- smdkc110_dm9000_set()函數的更改，直接拷貝九鼎的移植好的。
4、修改相應的配置參數
（1）DM9000相關的數據配置在arch/arm/plat-s5p/devs.c中；
（2）在arch/arm/mach-s5pv210/include/mach/map.h中定義了DM9000的IO基地址，和DM9000接在哪個bank有關。
- 根據實際情況，將其改為0x8800 0300。
（3）+2改成+4
?截圖是x210的配置，可見里面是+4，因此下面要改成+4
（4）IRQ_EINT9改成10即可
5、同步、編譯、下載，查看啟動信息
六、內核啟動第一階段（匯編階段）的調試方法
1、調試的原因
（1）內核啟動在head.S中首先進行三個校驗（CPU id的校驗、機器碼的校驗、tag的校驗），然后創建頁表，然后做了一些不太會出錯的事情，然后b start_kernel。
- 基本上能運行到start_kernel，內核移植就不太會出問題了。
（2）有時候移植的內核啟動后的現象是：根本沒有啟動信息出來（下面所述主要針對這個問題）。
- 有可能是內核啟動運行了，但是運行出錯了沒啟動起來所以沒有打印信息；
- 有可能是內核根本沒運行；
- 希望能有一種調試手段來確定問題所在。
2、調試方法和原理
（1）調試方法：在內核啟動的第一階段，添加匯編操作led點亮/熄滅的方法來標明代碼運行的軌跡。
（2）將led點亮和熄滅的代碼，復制粘貼到head.S中合適位置，然后內核啟動后根據led的表現來標明代碼有無運行。
3、動手測試
（1）在head.S中合適的地方（比如函數集中域處）添加（定義）led這個函數，然后在head.S的內核起始運行階段添加調用led函數。然后重新編譯內核，運行內核看這段代碼有無被運行。
（3）分析思路
- 如果被運行，證明在調用led的步驟之前的部分都是沒問題的，如果有錯，錯誤肯定在后邊；
- 如果沒有被運行則證明錯誤在之前，那么就要去之前的部分debug。
4、典型led函數
//移植內核的led調試方法 led:// 第一步：把0x11111111寫入0xE0200240(GPJ0CON)位置ldr r3, =0x11111111 // 從后面的=可以看出用的是ldr偽指令，因為需要編譯器來判斷這個數ldr r4, =0xE0200240 // 是合法立即數還是非法立即數。一般寫代碼都用ldr偽指令str r3, [r4] // 寄存器間接尋址。功能是把r0中的數寫入到r1中的數為地址的內存中去// 第二步：把0xff寫入0xE0200244(GPJ0DAT)位置ldr r3, =0xff //開發板啟動時，led半亮，這里賦值為ff，則三顆全滅了，一顆半亮。ldr r4, =0xE0200244str r3, [r4] // 把ff寫入到GPJ0DAT寄存器中，引腳即輸出高電平，LED熄滅mov pc,lr //函數一定要返回 //r0,r1,r2在head.s中，是用來給內核傳參的，類似于全局變量。 //因此不能用這些寄存器，我們可以使用那些沒有被使用的寄存器。 //因此可以r0改為r3，r1改為r4總結
以上是生活随笔為你收集整理的kernel移植——从三星官方内核开始移植的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 仓库管理数据库系统设计
- 下一篇： Apizza在线接口调试文档工具如何方便