在基於Linux的AM335x軟件開發流程中，第一步就是U-Boot/SPL(SecondProgram Loader)的移植。在移植中遇到問題比較常見，而U-Boot/SPL的調試手段比較簡陋，不便於迅速找到問題。利用仿真器可以單步調試的特點，就可以迅速定位到出問題的代碼所在位置，加速移植的調試過程。本文主要介紹如何用CCS+emulator調試基於AM335x的U-Boot/SPL。

　　1. AM335x Linux啟動過程以及U-Boot/SPL調試代碼的準備

　　1.1 [url=]AM335x Linux[/url]的啟動過程

　　AM335x Linux的啟動主要包括ROM，SPL， U-Boot 和kernel四個啟動步驟：

　　A. ROM code

　　ROM code是固化在芯片內部的代碼，當上電時序正確，而且晶振等芯片啟動所需的條件都具備時，AM335x會從ROM code開始運行。

　　ROM code首先會讀取sys_boot引腳上的配置，以確定存放SPL的存儲器，或者可以獲取SPL的外設。

　　具體可以參考AM335x technical reference manual中的第26章 IniTIalizaTIon。

　　ROM code會從相應的地方讀取/獲取SPL，並運行SPL。

　　B. SPL

　　SPL 和U-Boot 是bootloader的兩個階段。這裏分為兩個階段的原因是， ROM code中不會配置DDR，時鍾等最小係統，所以ROM code隻能把bootloader加載到片上SRAM中，而片上SRAM對成本影響很大，所以通常很小，例如在AM335x上隻有64K，不足夠放下整個U-Boot，所以將U-Boot分成兩部分，SPL和U-Boot。

　　SPL主要的職責就是初始化DDR，時鍾等最小係統，以讀取U-Boot，並加載到DDR中。具體來看，SPL 由ROM code加載到片上SRAM的起始位置，也就是0x402F0400。SPL會進一步對芯片進行配置，主要包括以下幾個方麵以完成其主要職責：

　　a. 配置ARM core。 主要包括對中斷向量表，cache，MMU等的配置。

　　b. 配置時鍾係統，主要是PLL等。這個是配置各個功能模塊的基礎。

　　c. 配置UART，TImer等。主要用於輸出必要的調試信息，或者提供些時鍾工具。

　　d. 配置I2C和PMIC。這個主要是為了配置電源管理芯片。

　　e. 配置DDR。

　　f. 配置 U-Boot所在的存儲器或者外設。

　　完成配置後，SPL會讀取U-Boot，並運行U-Boot。

　　C. U-Boot

　　U-Boot 主要的工作就是正確加載Kernel。和SPL類似，U-Boot也是要加載下一個階段的image，但是U-Boot提供了更多外設的支持和更多的調試工具。所以，U-Boot也要進行各個模塊的配置，上述SPL配置的部分， 除了DDR外，U-Boot也會根據需求重新配置(這裏重置主要是U-Boot是一個開源工程，其要兼容某些特殊的芯片，從而需要做重載)。此外，U- Boot也會對網口，SD卡等根據需求進行配置。

　　U-Boot 和SPL的工作流程比有一點是有較大差異的，就是會對自身進行一次重載。這個在後麵介紹U-Boot調試的時候，會有具體介紹。

　　完成配置後，U-Boot 會從相應的存儲器或者外設讀取Kernel，並傳遞參數給kernel，運行kernel。

　　D. Kernel

　　Kernel運行起來就代表Linux運行起來了，表明了啟動過程的結束。

　　1.2 U-Boot/SPL 調試代碼的準備

　　1.2.1下載U-Boot/SPL 代碼

　　U-Boot/SPL的代碼在一個包裏麵，通過編譯宏來分別編譯。目前TI U-Boot/SPL 代碼發布主要有兩個渠道，具體如下

　　A. 通過GIT開源的方式發布：

　　git://arago-project.org/git/projects/U-Boot-am33x.git

　　可以獲取最新的代碼，包含了最新的bug的修複。

　　B. 通過TI的官網的EZSDK發布：

　　//software-dl.ti.com/dsps/dsps_public_sw/am_bu/sdk/AM335xSDK/latest/index_FDS.html

　　EZSDK是正式發布的軟件包，經過全麵測試，性能穩定，U-Boot/SPL在board-support 目錄中。可以選擇EZSDK作為開發的基礎代碼。當有問題時， 可到GIT上查找最新的代碼是否有bug fix。

　　1.2.2 U-Boot/SPL的編譯

　　為了便於用CCS進行調試， 在編譯上需要注意兩點，其一，是要加入調試信息，就是為了加入symbol等信息;其二，去掉編譯器的性能優化編譯選項，這個主要是因為，優化後的代碼執行順序相對C代碼會有調整。

　　針對這兩點，在Uboot/SPL中，需要在config.mk中進行修改：

　　A. 在CFLAG 和 AFLAG中加入調試編譯選項，從而加入調試信息：

　　278ALL_AFLAGS = $(AFLAGS) $(AFLAGS_$(BCURDIR)/$(@F)) $(AFLAGS_$(BCURDIR)) –g

　　279ALL_CFLAGS = $(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR)) –g

　　B. 去掉 CFLAG中的編譯選項， -O2(U-Boot中默認是-O2)

　　61 HOSTCFLAGS = -Wall -Wstrict-prototypes -O2-fomit-frame-pointer

　　編譯過程可以參考//processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide

　　1.2.3 可執行文件

　　經過編譯後，就會生成可執行文件，也就是我們通常所說的image，這裏會生成的image主要用AM335xLinux啟動的兩個階段，MLO(SPL)和U-Boot。

　　這裏，SPL生成的image在am335/U-Boot-am33x/am335x/spl中，

　　A. am335/U-Boot-am33x/MLO 負責AM335x啟動的第一階段。

　　B. U-Boot-spl 作為帶有調試信息的image，可以在CCS中用作導入調試信息。

　　C. U-Boot-spl.bin 包含有調試信息，是調試時需要的image。

　　D. U-Boot-spl.map 這個文件裏麵存儲了spl的memory map信息，可以找到各函數入口的地址。

　　U-Boot生成的image在U-Boot-am33x/am335x中，具體如下：

　　A. U-Boot.img負責AM335x啟動的第二階段

　　B. U-Boot 包含有調試信息，屬於ELF格式，是調試時需要的image。

　　C. U-Boot.map這個文件裏麵存儲了U-Boot的memory map信息，可以找到各函數入口的地址