新闻中心

EEPW首页 > 嵌入式系统 > 设计应用 > 基于AM335x的U-Boot/SPL 的CCS 调试

基于AM335x的U-Boot/SPL 的CCS 调试

作者:时间:2016-09-12来源:网络收藏

在基于Linux的软件开发流程中,第一步就是U-Boot/SPL(SecondProgram Loader)的移植。在移植中遇到问题比较常见,而U-Boot/SPL的调试手段比较简陋,不便于迅速找到问题。利用仿真器可以单步调试的特点,就可以迅速定位到出问题的代码所在位置,加速移植的调试过程。本文主要介绍如何用+emulator调试基于的U-Boot/SPL。

本文引用地址:http://www.eepw.com.cn/article/201609/304511.htm

1. 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的编译

为了便于用进行调试, 在编译上需要注意两点,其一,是要加入调试信息,就是为了加入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/中,

A. am335/U-Boot-am33x/MLO 负责AM335x启动的第一阶段。

B. U-Boot- 作为带有调试信息的image,可以在中用作导入调试信息。

C. U-Boot-.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的速度相对略慢。


上一页 1 2 3 下一页

关键词: AM335x spl u-boot CCS

评论


相关推荐

技术专区

关闭