关于U-boot调试
2011-10-31 13:42
106 查看
帖子(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中调试,个人认为这种方式比较好
目前的思路是在windows中运行gdb server,然后在虚拟机中安装linux,使用insight来调试,通过samba来共享源码
但是这个过程中需要用到网络,这个是一个限制
////////////////////////////////////////////////////
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的不同,很是蹊跷)
///////////////////////////////////////////////////////////////
当板子做好后,一般都是先用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代码呢?
[Original] [Print] [Top] |
最有效的办法: 1 用LED灯调试,直到串口能发数据 2 串口能发数据了,就用通过串口来调试 当然用AXD作为辅助调试工具也是很不错的 |
帖子(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中调试,个人认为这种方式比较好
目前的思路是在windows中运行gdb server,然后在虚拟机中安装linux,使用insight来调试,通过samba来共享源码
但是这个过程中需要用到网络,这个是一个限制
////////////////////////////////////////////////////
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的不同,很是蹊跷)
///////////////////////////////////////////////////////////////
相关文章推荐
- 关于Spring-boot的debug调试
- 关于springBoot的使用
- 四极管:关于U-BOOT start.S分析的补充说明
- 工作手记 关于GetPrivateProfileString函数以及如何即时调试debug以及release版本的程式
- 很好的关于Eclipse+Tomcat插件的编辑和调试的文章
- MPC8314 (e300核) uboot 调试
- iOS 关于归档在真机调试中不可用的问题
- 关于U_BOOT_CMD_MKENT
- am335x UART1输入u-boot 调试信息代码修改
- 关于 Visual Studio 调试 Global 的一点总结
- 关于BIOS加载BOOT.S的经典解答
- 关于RTEMS的网络调试 (上)
- U-Boot中关于TEXT_BASE,代码重定位,链接地址相关说明
- 关于eclipse调试(包括汇编显示)
- 关于vs2003调试时出错:“试图运行项目时出错:无法启动调试”解决
- spring boot 调试 - 热部署
- 关于Spring boot
- 关于调试
- Windbg内核调试之一: Vista Boot Config设置
- 关于一个系统的调试问题