基于AM335x的-BootSPL的CCS调试.docx

基于AM335x的U-Boot/SPL的CCS 调试在基于Linux的AM335x软件开发流程中，第一步就是U-Boot/SPL（Second Program Loader）的移植。在移植中遇到问题比较常见，而U-Boot/SPL的调试手段比较简陋，不便于迅速找到问题。利用仿真器可以单步调试的特点，就可以迅速定位到出问题的代码所在位置，加速移植的调试过程。本文主要介绍如何用CCS+emulator调试基于AM335x的U-Boot/SPL。AM335x Linux启动过程以及U-Boot/SPL调试代码的准备1.1 AM335x Linux的启动过程AM335x Linux的启动主要包括ROM，SPL，U-Boot和kernel四个启动步骤：ROM codeROM code是固化在芯片内部的代码，当上电时序正确，而且晶振等芯片启动所需的条件都具备时，AM335x会从ROM code开始运行。ROM code首先会读取sys_boot引脚上的配置，以确定存放SPL的存储器，或者可以获取SPL的外设。具体可以参考AM335x technical reference manual中的第26章 Initialization。ROM code会从相应的地方读取/获取SPL，并运行SPL。SPLSPL和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会进一步对芯片进行配置，主要包括以下几个方面以完成其主要职责：配置ARM core。主要包括对中断向量表，cache，MMU等的配置。配置时钟系统，主要是PLL等。这个是配置各个功能模块的基础。配置UART，timer等。主要用于输出必要的调试信息，或者提供些时钟工具。配置I2C和PMIC。这个主要是为了配置电源管理芯片。配置DDR。配置U-Boot所在的存储器或者外设。完成配置后，SPL会读取U-Boot，并运行U-Boot。U-BootU-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。KernelKernel运行起来就代表Linux运行起来了，表明了启动过程的结束。U-Boot/SPL 调试代码的准备1.2.1下载U-Boot/SPL代码U-Boot/SPL的代码在一个包里面，通过编译宏来分别编译。目前TI U-Boot/SPL 代码发布主要有两个渠道，具体如下通过GIT开源的方式发布：git:///git/projects/U-Boot-am33x.git?可以获取最新的代码，包含了最新的bug的修复。通过TI的官网的EZSDK发布：/dsps/dsps_public_sw/am_bu/sdk/AM335xSDK/latest/index_FDS.htmlEZSDK是正式发布的软件包，经过全面测试，性能稳定，U-Boot/SPL在board-support 目录中。可以选择EZSDK作为开发的基础代码。当有问题时，可到GIT上查找最新的代码是否有bug fix。1.2.2 U-Boot/SPL的编译。为了便于用CCS进行调试，在编译上需要注意两点，其一，是要加入调试信息，就是为了加入symbol等信息；其二，去掉编译器的性能优化编译选项，这个主要是因为，优化后的代码执行顺序相对C代码会有调整。针对这两点，在Uboot/SPL中，需要在config.mk中进行修改：在CFLAG 和 AFLAG中加入调试编译选项,从而加入调试信息：278 ALL_AFLAGS = $(AFLAGS) $(AFLAGS_$(BCURD