您的位置 首页 系统

根据AM335x的U-Boot/SPL 的CCS 调试

基于AM335x的U-Boot/SPL 的CCS 调试, 在基于Linux的AM335x软件开发流程中,第一步就是U-Boot/SPL(SecondProgram Loader)的移植。在移植中遇到

在依据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的速度相对略慢。

声明:本文内容来自网络转载或用户投稿,文章版权归原作者和原出处所有。文中观点,不代表本站立场。若有侵权请联系本站删除(kf@86ic.com)https://www.86ic.net/qianrushi/xitong/300179.html

为您推荐

联系我们

联系我们

在线咨询: QQ交谈

邮箱: kf@86ic.com

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

返回顶部