在依据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发布：
http://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
编译进程能够参阅http://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信息，能够找到各函数进口的地址
调试环境首要包括3个部分，仿真器，集成调试环境和开发板。下面将逐个介绍：
2.1 仿真器(emulator)
现在支撑AM335x的仿真器的类型比较多，有XDS560v2，XDS510，XDS100v2， XDS100v3，等，比较常见的是XDS560v2和XDS100v2。
XDS560v2，功用好，速度快，具有trace功用，可是价格偏贵。 XDS100v2价格比较廉价。 其具有和XDS560v2相同的根本调试功用，仅仅XDS100v2的速度相对略慢。
