学步园

帖子（1） 

当板子做好后，一般都是先用AXD初始化好sdram，然后将U-boot下载到sdram中进行调试，然后等flash调试好后，就可以将U-boot烧写到flash中再进行调试

问题：
1.为了能将U-boot下载到sdram中调试，除了要定义CONFIG_SKIP_LOWLEVEL_INIT和CONFIG_SKIP_RELOCATE_UBOOT这两个宏之外，是否还应该在CFLAGS中

加入-gdwarf2（这个名字对吗）这个选项（我是用arm-linux-gcc在linux下交叉编译的）?

2.编译好U-boot后，会生成u-boot(elf格式),u-boot.bin(二进制格式)，u-boot.srec（Motorola S-Record格式），如果要把u-boot下载到sdram调试，要用到哪个文件呢？

3.当我把u-boot.bin通过AXD下载到sdram后，可以调试，但是只能看到汇编，不能看到后面的C语言代码，那如何才能做到源码级调试呢？

4.是否可以通过AXD调试已经烧到flash中的U-boot代码呢？

另外还有一篇收藏的帖子、讨论了这个问题

帖子（2）

目标：实现uboot、kernel源代码级调试

——————————————————————————————————————————

已有资源：
一块2440的板子
JLink V7
——————————————————————————————————————————

考虑上面的情况，所以调试仿真只能建立在JLink的基础上

我目前了解到JLink支持两种调试方式：
1.RDI
2.GDB Server
——————————————————————————————————————————

对于RDI这种方式，可以采用的debugger有ADS1.2中的AXD以及RVDS2.2/RVDS3.0中的RVD(RVDS3.1及以上版本已经不再支持RDI)

这个也是windows下比较方便的解决方案

有两种方法可以实现：
一是将u-boot代码全部移植到ads/rvds下，编译、调试；
一是使用linux下的交叉编译工具编译，然后将编译产生的elf格式的文件，拿到axd/rvd下进行调试
从网上查知的信息表明将u-boot移植到ads/rvds下是个很繁杂的工作，不是很好。这种方式就直接排除。可以参看这个网址http://hi.baidu.com/loun/blog/item/1b43bdaf7d056ecd7dd92a2b.html

将linux下用交叉编译工具链生成的elf格式文件调到axd/rvd下进行调试，貌似用axd时会有不少问题，所以也排除
那这里就只剩下rvd这一种方式了。

///////////////////////////////////////////////////////对于GDB Server方式，就可以在linux中调试，个人认为这种方式比较好

////////////////////////////////////////////////////

http://forum.eepw.com.cn/thread/71959/1

从这里知道：
axd使用的是axf格式文件，而linux下的cross toolchain生成的是elf文件
但是axd=elf，所以也能使用axd来实现源码级的uboot调试】
只不过在linux下编译uboot时需要包含dwarf-2格式的调试信息

另：rvd使用的也是elf格式

////////////////////////////////////////////////

http://www.programmer-club.com.tw/ShowSameTitleN/embedded/2374.html

这里提到一个需要注意的地方（其实我也没有完全明白）：
用厂商编译出来的 elf 和 axd 不一样，所以无法加载做 software level debug，如果你有 ARM RVD 2.2 ，只要在厂商的编译器中设定 -gdwarf-2 ，将 armboot 更改为 armboot.elf 即可给 RVD "Load Image" 就可以做 Software level debug / trace 了。

必须注意的是因为 GNU 与 ARM 的 assembler 有差异, 所以 RVD无法解释 .S file, 但是会有 symbol 在 disassemble 窗口内直接提供 debug. 而 .C source 可以做 source trace, 第一次会要求提供档案, 之后 RVD 自动建立 Source Mapping, 即不需再提供目录.

为什么会不知道 source 在哪? 因为 armboot 是在 linux 下面编译,所以对应的路径是参考 linux 下的路径.

////////////////////////////////////////////////

用ADS（AXD Debugger），实现u-boot的源代码级调试(c语言级)
——————————————————————————————————————————————
如果板子没有网口，在调试U-Boot和uclinux时就没法用gdb调试。

这时只能利用串口和JTAG口进行调试，linux下可以用BDI这个玩意调试，可是BDI非常昂贵，不适合大众需求。

我总结了下，根据我的调试经验，可以用ADS调试linux的程序。

打开AXD，按下 Alt + L ；或者点System Views下Command Line Interface，就可以打开一个命令行：

输入help查看帮助文件。

比较有用的命令如：
LoadBinary = 将一个文件导入RAM   
LoadSymbols = 导入符号表               
SetPC = 设置PC寄存器                      
Run = 开始运行
OB + 文件名 = 按照批处理文件运行

所有的命令在GUI里面也是有的，可以利用批处理文件(OB命令)来免去敲命令和点菜单的麻烦，

以调试u-boot为例，写一个批处理文件放在D盘，文件名为u-boot.txt，内容如下：
loadbinary Y:\u-boot-1.1.4\u-boot.bin 0x00100000
loadsymbols Y:\u-boot-1.1.4\u-boot
setpc 0x00100000
run

打开AXD，按下ALT+L,键盘输入：ob d:\u-boot.txt

那么AXD会自动运行批处理文件内的命令，自动载入u-boot的二进制代码，自动载入符号表，设置指针为0x00100000,并开始运行。

在调试时，最后自己一步步输入命令做

loadbinary简写lb，只能将二进制文件加载到ram中，不能将地址指定到flash中

在loadsymbols之后，等待进度条显示加载完成，将setpc (pc)指到u-boot.bin的加载位置，即可单步调试。

这时ads会提示寻找u-boot的入口文件start.s地址，此时需要手动指定start.s的位置，通常这时可以在linux下建立smaba服务共享，将整个u-boot的文件夹映射成windows下一个盘符，这样就可以指定目录地址了。

在进入c语言代码中后，ads还可能出现提示指定board.c、string.c等其他文件的地址，这都需要手动做。

此后就可以用ads进行c语言级的u-boot源码调试了！

这种方法应该没问题的，因为我实验了很多次了，都成功了，这可是偶找了近一个月才弄清楚的方法..........

同样，这种方法不知道是否可以用在uclinux上调试，正在进行试验。

////////////////////////////////////////////////////////////////////

不是可以使用win下面的insight吗？

如果要自己搭建insight的话，需要用到cygwin，编译过程还是挺简单的。我当时用的编译器是codesourcery lite，没带insight。后来自己编译了一个，将target定为arm-none-eabi，就可以编译出和codesourcery lite兼容的调式器。如果你是使用arm-elf-gcc的话就要将target定为arm-elf。

还有一种调试器应该也可以，那就是eclipse的调试器。使用gdb作前端，网上有文章写怎么和j l i n k连接起来，不过我没具体测试过。但应该和gdb是兼容的。

这是我的一些看法，如有错误希望大家指正。

///////////////////////////////////////////////////////////////

多谢~~

我不想用cygwin，个人觉得用cygwin还不如用vmware装个linux系统

我用的交叉工具链是自己编译的，是利用gentoo中crossdev来得到的
具体可见

http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=3487946&bbs_page_no=1&search_mode=3&search_text=lofeng&bbs_id=9999

使用insight这种思路，如果用JLink的话，都是通过GDB Server来实现调试的
这个过程中需要网络

/////////////////////////////////////////////////////////

主要在于开发工具的支持,一般而言,可以通过-gdwarf-2等参数编译带调试信息的elf,然后载入调试.

arm中我没这样调试过uboot,不过在powerpc中,我都是直接用denx的eldk在linux中进行编译,然后将生成的带调试的uboot拷贝到windows中,用freescale的code warrior载入elf,此时它自自动寻找其中符号的源代码.由于linux中的路径与windows的路径不一样,这时需要手动指定源文件的位置.一般而言,指定一个以后,它就会在相应的目录下继续进行查找.对于linux kernel的调试也是类似的.另外在windriver的visionclick/Workbench for OCD,也是类似的.

也就是说,要进行源代码设计,一是生成带调试信息的elf,二是相应的工具支持载入elf(可能必要时要进行路径的映射).

另外,我看uboot的代码中,有kgdb的代码,好像是可以通过串口之类进行简单的调试

///////////////////////////////////////////////////////////

我用的是ads 1.2, axd, Real Multi-ICE，交叉编译器用的是arm-linux-gcc 3.3.2

在linux中编译u-boot 2010.06，在config.mk中修改了：DBGFLAGS = -gdwarf-2

但是axd加载u-boot.axf时，提示：
DBT Warning 00056: Debug table format error at offset 0x91 in area .debug_info

网上查了资料，让用RVCT 3.0的--dwarf2选项，可我只能用ads1.2啊。

另外，0x91是什么意思？看了section header，我的.debug_info在Section 9, 二者之间是否有何联系？ 是否因为axd可识别的调试信息格式与dwarf 2格式的不同？

用fromelf转换ads自己编译的axf文件到elf格式，比较二者文件，发现毫无区别。

（话外：还试着直接加载bin格式文件到内存，发现内容与bin的不同，很是蹊跷）

///////////////////////////////////////////////////////////////