《2.uboot和系統移植-第3部分-2.3.零距離初體驗uboot》

第一部分、章節目錄
2.3.1_2.X210官方uboot配置編譯實踐
2.3.3.uboot的原始碼目錄分析1
2.3.4.uboot的原始碼目錄分析2
2.3.5.uboot的原始碼目錄分析3
2.3.6.SourceInsight的基本使用

第二部分、章節介紹
2.3.1.X210官方uboot配置編譯實踐1
本節課主要講解了uboot的各種來源版本以及其之間的差異
2.3.2.X210官方uboot配置編譯實踐2
本節課使用開發板廠商釋出的uboot原始碼進行配置編譯，主要目的是讓大家體驗配置編譯的過程，方便後續去分析。
2.3.3.uboot的原始碼目錄分析1
本節課開始講解uboot的目錄結構，這節主要是根目錄下的單個檔案。
2.3.4.uboot的原始碼目錄分析2
本節課講述的是uboot目錄結構中根目錄下的資料夾。
2.3.5.uboot的原始碼目錄分析3
本節課繼續講述uboot目錄結構中根目錄下的資料夾。
2.3.6.SourceInsight的基本使用
本節課介紹SourceInsight軟體的基本使用，包括建立工程、新增檔案、解析工程、查詢檔案等。

第三部分、隨堂記錄
2.3.1.X210官方uboot配置編譯實踐1
2.3.1.1、找到官方移植好的uboot（BSP概念）
(1)源頭的原始碼是uboot官網下載的。這個下載的原始碼可能沒有你當前使用的開發板的移植，甚至找不到當前開發板使用的SoC對應的移植版本。
(2)SoC廠商在推出一款SoC後，廠商的工程師會去uboot官網下載一個uboot，根據自己的SoC進行第一步的移植，移植的目標是廠商推出的開發板。（譬如三星的S5PV210晶片廠商出的開發板就叫SMDKV210）.所以三星的工程師移植的uboot是根據他們自己的SMDKV210開發板移植的。
(3)具體的開發板供應商（譬如X210的生產商深圳市九鼎科技）首先購買三星的SMDKV210開發板，然後進行裁剪（把一些無用的介面功能裁剪去，配置降低一下，某些配置會被替換）。硬體替換和裁剪之後生成的新的開發板（譬如X210）和三星官方的SMDKV210有所不同，因此uboot也不同。但是因為SoC是相同的，所以相似度至少有60%以上。所以具體開發板供應商會以三星SMDKV210中移植的uboot為藍本來移植得到自己的開發板的一個uboot移植。我們買X210開發板時廠商光碟中帶的BSP中的uboot原始碼就是他移植過的。
總結：uboot可以有3種獲取途徑：uboot官方、SoC官方、具體開發板的官方。

2.3.2.X210官方uboot配置編譯實踐2
2.3.2.1、在linux源生目錄下配置編譯
(1)X210移植過的uboot在開發板光碟的BSP中。
(2)BSP就是board support package(板級支援包，一般由開發板供應商提供)，裡面的內容就是這個開發板的所有相關的原始碼、文件、教程等。
(3)將整個BSP打包檔案弄到linux的源生目錄中去解壓分析，不要在windows中的共享資料夾中解壓開。（除非你的程式碼只在windows下去分析而不去編譯，如果你想編譯工程就一定不要在windows共享資料夾下，否則會出錯）
(4)tar -jxvf qt_x210v3_130807.tar.bz2
(5)我們在linux下維持一份uboot，在windows下也維持一份uboot，在我們沒有開始任何工作之前，這兩份uboot內容一樣的，都是九鼎官方的uboot 內容。我們這樣做目的是：在linux中進行編譯、在windwos下進行程式碼分析和觀看。（windwos下有SourceInsight等很好的工具輔助我們看程式碼、編輯程式碼，在linux下編譯和看程式碼都很麻煩·····）

2.3.2.2、配置
(1)uboot和linux kernel等複雜專案，都不能直接編譯，都要先配置才能編譯。
(2)uboot也要先配置，配置方法是：首先cd進入uboot原始碼的根目錄，然後在根目錄下執行：make x210_sd_config。執行配置命令後，如果出現：Configuring for x210_sd board…
說明配置好了，如果不是這個是別的說明配置出錯了。

2.3.2.3、編譯得到uboot.bin
(1)編譯之前一定要注意檢查arm-linux-gcc對不對，檢查份2步：
第一步：檢查當前編譯環境中有沒有安裝合適的arm-linux-gcc。我們裝的是arm-2009q3，因為這個是三星官方、九鼎官方開發uboot時使用的。
第二步：檢查當前目錄下（uboot根目錄）的Makefile中編譯器的設定是否正確。在工程的總Makefile中會設定交叉編譯工具鏈的路徑和名字，必須確保這個路徑和名字和我們自己裝的一致，否則編譯會出錯。
(2)確保了以上2點，即可進行編譯。編譯很簡單，直接make即可。或者可以make -j4 (多執行緒編譯，主機如果是多核心電腦，可以嘗試多執行緒編譯，會快一些)

2.3.3.uboot的原始碼目錄分析1
2.3.3.1、九鼎官方uboot和三星原版uboot對比
(1)以九鼎官方的uboot為藍本來學習的，以三星官方的這份為對照。
(2)不同版本的uboot或者同一版本不同人移植的uboot，可能目錄結構和檔案內容都有所不同。將來大家懂了後也可以自己根據需要去新增/刪除/更改目錄結構。
(3)九鼎在以三星的uboot為原材料進行移植時，把三星版本的uboot中很多不必要的資料夾、檔案給刪除掉了。這個刪除把很多完全用不到的檔案清除出去，減少了整體的檔案數量，便於工作。

2.3.3.2、各檔案介紹
(1).gitignore。git工具的檔案，git是一個版本管理工具（類似的還有個svn），這個檔案和git有關，和uboot本身無關的，不用去管。
(2)arm_config.mk。字尾是.mk，是一個Makefile檔案，將來在某個Makefile中會去呼叫它。
(3)三個Changelog檔案，修改記錄檔案，該檔案記錄了這個uboot專案的版本變遷以及每個版本較上個版本修改的記錄。正式的專案都有這些記錄的。可以直接忽略，主要是給維護uboot的人用的。
(4)config.mk。和arm_config.mk差不多性質。
(5)COPYING。版權宣告，uboot本身是GPL許可證的。
(6)CREDITS。鳴謝，裡面記錄了對uboot有貢獻的人，感謝目錄。
(7)image_split。一個指令碼，看說明是用來分割uboot.bin到BL1的，暫時用不到，先不管。
(8)MAINTAINERS。維護者，就是當前在參與維護uboot原始碼的社群工作者。
(9)MAKEALL。一個指令碼，應該是幫助編譯uboot的。
(10)Makefile。這個很重要，是uboot原始碼的主Makefile，將來整個uboot被編譯時就是用這個Makefile管理編譯的，所以我們在下個課程中研究uboot配置編譯過程時就要分析這個Makefile。
(11)mk。快速編譯的指令碼，其實就是先清理然後配置然後編譯而已。
(12)mkconfig。這個很重要，是uboot配置階段的主要配置指令碼。uboot的可移植性很大程度就是靠這個配置指令碼在維護的。我們在下個課程中研究uboot配置編譯過程時就要分析這個配置指令碼。
(13)mkmovi。暫時不去管他，一個指令碼，和iNand/SD卡啟動有關
(14)README。所有的軟體都有README，一般拿到一個東西要先讀README，這個東西其實就是個簡單的使用說明書。
(15)rules.mk。這個檔案是我們uboot的Makefile使用的規則，本身非常重要，但是我們不去分析他，不去看他。

總結：以上這些檔案中，對我們比較重要，需要認真看的有2個：mkconfig和Makefile。一個負責uboot的配置，一個負責編譯。我們在第四部分的課程中會詳細講解分析這兩個東西。

2.3.4.uboot的原始碼目錄分析2
(1)api. 硬體無關的功能函式的API。uboot移植時基本不用管，這些函式是uboot本身使用的。
(2)api_examples. API相關的測試事例程式碼。
(3)board。board是板的意思，板就是開發板。board資料夾下每一個檔案都代表一個開發板，這個資料夾下面放的檔案就是用來描述這一個開發板的資訊的。board目錄下有多少個資料夾，就表示當前這個uboot已經被移植到多少個開發板上了（當前的uboot支援多少個開發板）。
問題一：思考uboot如何支援多套開發板，如何具有可移植性
問題二：board下有這麼多資料夾，究竟如何確定具體使用的是哪一個？uboot在配置階段會有一些手段幫助我們來確定具體使用的是board目錄下的哪一個資料夾。（想想為什麼不能直接編譯而要先配置）
問題三：開發板越來越多，board目錄下資料夾越來越多不方便管控。於是乎uboot就新增了一種機制，可以在board目錄下不直接放開發板目錄，而是在board下放廠家目錄（vendor目錄，以具體晶片廠商名字命名），然後將這個IC廠商的所有晶片開發板都丟到這個vendor目錄下面去。所以大家會發現我們X210對應的開發板目錄在board/samsung/x210。多了這層目錄會影響配置階段，在uboot的配置階段要注意配置時的路徑深度和實際存放要對應，不然配置後編譯時找不到檔案編譯就會失敗。注意一個細節就是歷史原因造成的相容性麻煩。最開始時board目錄下就是開發板名字，後來才改成廠商名字的。但是因為要向前相容，同一個廠商原來還是外面的開發板並沒有挪移到廠商目錄下面去。這樣就造成後來的人不知道原委的感到很奇怪，感覺很混亂。

注意：強調一下，uboot的配置階段（其實就是根目錄下面的mkconfig指令碼和Makefile中配置有關的部分）主要解決的問題就是在可移植性領域能夠幫助我們確定具體的資料夾的路徑，然後編譯時可以找到應該找到的檔案，才能編譯成功。因此board目錄下的不同會造成配置時的不同。如果移植時沒注意這裡肯定要失敗。

2.3.5.uboot的原始碼目錄分析3
(4)common。common是普遍的普通的，這個資料夾下放的是一些與具體硬體無關的普遍適用的一些程式碼。譬如控制檯實現、crc校驗的。但是更多的主要是兩類：一類是cmd開頭的，是用來實現uboot的命令系統的；另一類是env開頭的，是用來實現環境變數的。
(5)cpu。這個目錄是SoC相關的，裡面存放的程式碼都是SoC相關初始化和控制程式碼（譬如CPU的、中斷的、串列埠等SoC內部外設的，包括起始程式碼start.S也在這裡）。裡面很多子資料夾，每一個子資料夾就是一個SoC系列。
注意：這個問價是嚴格和硬體相關的，因此移植時也是要注意的。但是因為這個資料夾內都是SoC有關的，我們自己的開發板和三星的開發板雖然板子設計不同但是SoC都是同一個，因此實際移植時這個目錄幾乎不用動。
(6)disk。磁碟有關的，沒研究過，沒用過。
(7)doc。文件目錄，裡面存放了很多uboot相關文件，這些文件可以幫助我們理解uboot程式碼。但是因為是純英文的，而且很雜亂，所以幾乎沒用。
(8)drivers。顧名思義，驅動。這裡面放的就是從linux原始碼中扣出來的原封不動的linux裝置驅動，主要是開發板上必須用到的一些驅動，如網絡卡驅動、Inand/SD卡、NandFlash等的驅動。要知道：uboot中的驅動其實就是linux中的驅動，uboot在一定程度上移植了linux的驅動給自己用。但是linux是作業系統而uboot只是個裸機程式，因此這種移植會有不同，讓我說：uboot中的驅動其實是linux中的驅動的一部分。
(9)examples。示例程式碼，沒用過。
(10)fs。filesystem，檔案系統。這個也是從linux原始碼中移植過來的，用來管理Flash等資源。
(11)include。標頭檔案目錄。uboot和linux kernel在管理標頭檔案時都採用了同一個思路，就是把所有的標頭檔案全部集中存放在include目錄下，而不是標頭檔案跟著自己對應的c檔案。所以在uboot中標頭檔案包含時路徑結構要在這裡去找。
(12)lib_開頭的一坨。（典型的lib_arm和lib_generic）架構相關的庫檔案。譬如lib_arm裡面就是arm架構使用的一些庫檔案。lib_generic裡是所有架構通用的庫檔案。這類資料夾中的內容移植時基本不用管。
(13)libfdt。裝置樹有關的。linux核心在3.4左右的版本的時候更改了啟動傳參的機制，改用裝置樹來進行啟動傳參，進行硬體資訊的描述了。
(14)nand_spl。nand相關的，不講。
(15)net。網路相關的程式碼，譬如uboot中的tftp nfs ping命令 都是在這裡實現的。
(16)onenand開頭的，是onenand相關的程式碼，是三星加的，標準uboot中應該是沒有的。
(17)post。沒關注過，不知道幹嘛的。
(18)sd_fusing。這裡面程式碼實現了燒錄uboot映象到SD卡的程式碼。後面要仔細研究的。
(19)tools。裡面是一些工具類的程式碼。譬如mkimage。

總結：資料夾裡面比較重要的，後面會分析涉及到的有：board、common、cpu、drivers、include、lib_arm、lib_generic、sd_fusing

2.3.6.SourceInsight的基本使用
2.3.6.1、為什麼要使用SourceInsight
(1)對於一個真正的一個專案，往往有幾十幾百甚至上萬個c檔案、h檔案，程式碼量非常大，程式碼之間關聯非常複雜，就帶來一個問題，程式碼的分析、閱讀越來越難。譬如這裡引用了一個函式但是這個函式可能在另外一個目錄下的一個資料夾中存放，這樣情況下程式碼查詢和閱讀很困難，我們希望有一個好工具能夠幫助。於是乎有了SourceInsight。
2.3.6.2、建立工程及新增檔案
(1)要使用SI看程式碼，首先要建立一個工程。選單欄：Project->new project。在彈出的對話方塊中上面輸入工程名字（自己起名字，隨便寫，但是一般要和工程相對應免得時間長了忘記了），下面輸入工程檔案存放的位置。
(2)工程專案檔案和工程中管理的原始碼檔案目錄可以不同，但是我一般習慣放在一起。放在：C:\winshare\s5pv210\uboot\uboot-jiuding\SI_Proj
點確定，進入new project setting，直接點ok進入下一步。
(3)到了向專案中新增檔案的步驟。
在左側選擇uboot-jiuding這個目錄，然後點右側邊欄的add tree即可新增，發現添加了1054個檔案進去。
(4)本來應該已經結束了，但是有遺留問題。因為SI軟體有個特點，它只能發現自己識別了的檔案型別，對於它未識別的檔案型別它就看不到。譬如start.S檔案就未包含在內，因為SI預設不認識.S字尾的檔案。
解決方案：第一種是自己配置；第二種是載入我提供的AstonSICFG。
(5)解決了4中的問題然後再次新增檔案。選單欄　Project->Add and Remove Project Files 再次瀏覽到uboot-jiuding目錄下，再次add tree，發現添加了額外的19個檔案。

2.3.6.3、解析工程檔案
(1)SI工作原理就是預先把所有原始碼中的所有符號全部解析儲存到資料庫中，然後等我們進行符號查詢時，SI不是查檔案而是查資料庫幫我們索引符號，因此SI查詢速度非常快。
(2)因此我們使用SI查閱原始碼前應該預先進行原始碼解析。在選單欄Project->Syneronize Files，選中上面2個，然後確定。

2.3.6.4、常用技巧