U-Boot调试环境搭建请教~~如何实现u-boot和内核的源码级调试
目标：实现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中调试，个人认为这种方式比较好
目前的思路是在windows中运行gdb server，然后在虚拟机中安装linux，使用insight来调试，通过samba来共享源码
但是这个过程中需要用到网络，这个是一个限制 原来使用BDI2000调试 BDI2000很强大
但是太贵了 个人无法承受~~
呵呵 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的代码,好像是可以通过串口之类进行简单的调试 多谢楼上~~
今天有点事情忙 明天继续来 用vmware安装了ubuntu，不知道如何安装linux的编译环境，忘能指点一二。 LS,请参照我另外一贴，其中有很详细的说明
http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=3487946&bbs_page_no=2&bbs_id=1032 lz可以参考这个：
【转】使用J-Link GDB Server + Eclipse CDT进行ARM程序调试
http://hi.baidu.com/serial_story/blog/item/d6baee097146f788d0581be1.html
是用Eclipse加Jlink的gdb的。
我自己也没试过，有空再试试。 纯粹在Linux下面不依赖于Windows也是可能的，我就在用，OpenOCD+jlink+gdb。 我在ads中用h-jtag调试过u-boot,有一阵那
http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=3374820&bbs_page_no=1&search_mode=3&search_text=pcl001&bbs_id=9999
http://cache.amobbs.com/bbs_upload782111/files_20/ourdev_495910.JPG
(原文件名:无标题1.JPG) jlink中用gdb server不好吗？甚至是，启动windows上的gdb server，然后用linux上的ddd，kgdb等远程连接来调试。 转载，详文参考：http://www.xker.com/page/e2008/1023/63400.html
活用AXD Debugger调试器的命令行，实现u-boot的源代码级调试
其实AXD的功能非常强大，特别是其命令行。
打开AXD，按下 Alt + L ,就可以打开一个命令行，
非常有用的命令如：
LoadBinary = 将一个文件导入SDRAM
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.axf
setpc 0x00100000
run
打开AXD，按下ALT+L,键盘输入：ob d:\u-boot.txt
那么AXD会自动运行批处理文件内的命令，自动载入u-boot的二进制代码，自动载入符号表，设置指针为0x00100000,并开始运行,如果在AXD中断运行，会自动显示源代码! cool~~!
如果有命令不清楚的话，在命令行下，输入 help ,可以打开帮助文件！ 顶 最近在移植u-boot_2010.03到2440上，在SDRAM调试第二阶段的功能基本没问题，但如果下载到NAND上就跑不起来了，说明启动的第一阶段汇编部分有问题。
按照6楼说的方法实现了再AXD上面去调试，但是调试的时候AXD都是汇编的，看不到源码，就是不能像15楼的那样去调，不知道15能在C源码层上单步调试是怎么实现的？
AXD上怎样加入C源文件？ 顶起来，问19楼的问题..... mark mark 回复【15楼】pcl001
-----------------------------------------------------------------------
我用的是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的不同，很是蹊跷） mark 19楼，那个链接打不开啊，能说明一下你是怎么源码级调试u-boot的吗？我按照17楼的方法会提示DBT Warning 00005: Debugger workspace full这个 mark mark mark 现在能用keil和jlink来调试u-boot代码吗？ mark 17楼，可以说得再明白一些吧，AXD的默认是ARM7的，如何选择处理器？还有能否把操作的步骤讲具体一些吗？ 如果可以使用串口的话， 直接用串口的输出来做debug吧。 说实在的， 于其花时间精力去配置各种工具， 还不如仔细读透代码， 一出问题就上仿真器， 永远也成不了高手。 MARK 最近刚弄好调试环境
我比较喜欢的是linux下Eclipse CDT+ zylin CDT + arm-linux-gdb 远程连到windows上的jlinkGDBServer上下程序调试。
http://blog.csdn.net/kangear/article/details/8639398 这篇文章比较有用 仿真器始终是仿真，做不到百分一百准确。
用printf调试，不易出错，结果直观明了
页:
[1]