[U-Boot-Users] u-boot debugging boot with gdb and bdi2000 in lubbock(PXA255) board
Hello,
I have a lubbock development board and a BDI2000 jtag debuggger. I would like to debug the boot process before the relocate of the boot code.
My steps to debug the booter: o I've modified the config.mk file to enable the debug options DBGFLAGS = -g -DDEBUG. ( I haven't a u-boot.lds.debug for my board (lubbock). Do I need it ?) o Start my target, the jtag debugger is configured to stop the execution. o Start arm-linug-gdb u-boot o The ouput of the gdb is :
************************************************************ Current directory is /home/jgarcia/XSCALE/boot/u-boot-0.4.0/ GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"... (gdb) target remote bdi2000:2001 Remote debugging using bdi2000:2001 0x00000060 in ?? () (gdb) b start_armboot Breakpoint 1 at 0xa030bd4: file board.c, line 214. (gdb) monitor bi 0xa030bd4 Breakpoint identification is 0 ***************************************************************
o From here, I can stop the execution and debug the sources beginning with the start_armboot function.
My question is, How can I debug the code __before__ the start_armboot function ? I would like to debug the assembler code from the first instruction ( I can do this with the jtag debugger but I can't see the related source instruction in the gdb ).
Regards, Juan Antonio
Dear Juan,
in message 3F57233D.8060305@nabla-designs.com you wrote:
My steps to debug the booter: o I've modified the config.mk file to enable the debug options DBGFLAGS = -g -DDEBUG. ( I haven't a u-boot.lds.debug for my board (lubbock). Do I need it ?)
If the code still links you don;t need it. With some board with embedded environment you need to use a different arrangement of object files in the image as sizes grow due to debugging code.
o Start my target, the jtag debugger is configured to stop the execution.
...
My question is, How can I debug the code __before__ the start_armboot function ? I would like to debug the assembler code from the first
Use "reset halt" and/or "startup reset" to stop the CPU right out of reset.
instruction ( I can do this with the jtag debugger but I can't see the related source instruction in the gdb ).
AFter reset, you can single step on instruction level ("si" in GDB) and display the current assembler code by defining a display like "d/i $pc"
Best regards,
Wolfgang Denk
My question is, How can I debug the code __before__ the start_armboot function ? I would like to debug the assembler code from the first instruction ( I can do this with the jtag debugger but I can't see the related source instruction in the gdb ).
Juan,
I usually set TEXT_BASE=0 in board/lubbock/config.mk for debugging before start_armboot. No need to reflash. You should be able to reload symbols in gdb at offset 0, but for some reason I've never been able to get this to work correctly. So linking at 0 sets symbols for gdb correctly. Then you can use gdb in a normal manner.
HTH, Kyle.
In message E19utSW-0000xx-00@hall.mail.mindspring.net you wrote:
I usually set TEXT_BASE=0 in board/lubbock/config.mk for debugging before start_armboot. No need to reflash. You should be able to reload symbols in gdb at offset 0, but for some reason I've never been able to get this to work correctly. So linking at 0 sets symbols for gdb correctly. Then you can use gdb in a normal manner.
No need to recompile / relink. GDB will do the same when you use "symbol-file" to delte the current ymbol table and "add-symbol-file" to load the symbol file to the wanted target address (0x0).
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message E19utSW-0000xx-00@hall.mail.mindspring.net you wrote:
I usually set TEXT_BASE=0 in board/lubbock/config.mk for debugging before start_armboot. No need to reflash. You should be able to reload symbols in gdb at offset 0, but for some reason I've never been able to get this to work correctly. So linking at 0 sets symbols for gdb correctly. Then you can use gdb in a normal manner.
No need to recompile / relink. GDB will do the same when you use "symbol-file" to delte the current ymbol table and "add-symbol-file" to load the symbol file to the wanted target address (0x0).
Thanks Wolfgang and Kyle for your advice. Now, I can debug the boot process from the first instruction. Finally I've created two binaries: u-boot to execute and u-boot.debug (with TEXTBASE=0x0), to debug the first part of boot process. When the boot process arrives to the start_armboot function, I discard the current symbol file(u-boot.debug) and load the new one(u-boot).
Now, I have a new (minor) problem. The execution order which shows the gdb seems to be wrong (I`ve stopeed at the start_armboot funcion and the lines which show the gdb are different of the real execution). I suppose that it is a compiler optimization problem. Anyone knows which are the suitable flags to use with the compiler to avoid this behaviour ?
Regards, Juan Antonio
In message 3F575E48.1060507@nabla-designs.com you wrote:
Thanks Wolfgang and Kyle for your advice. Now, I can debug the boot process from the first instruction. Finally I've created two binaries: u-boot to execute and u-boot.debug (with TEXTBASE=0x0), to debug the first part of boot process. When the boot process arrives to the start_armboot function, I discard the current symbol file(u-boot.debug) and load the new one(u-boot).
You don't need to recompile or relink with TEXTBASE=0x0; the "add-symbol-file" GDB command allows you to specify an arbitrary target address.
Now, I have a new (minor) problem. The execution order which shows the gdb seems to be wrong (I`ve stopeed at the start_armboot funcion and the lines which show the gdb are different of the real execution). I suppose that it is a compiler optimization problem. Anyone knows which are the suitable flags to use with the compiler to avoid this behaviour ?
This has been discussed many times before (just a few days before).
See section "Debugging - Tips and Tricks" in our documentation at http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks Note that code size and performance will suffer from such mods.
Best regards,
Wolfgang Denk
participants (3)
-
Juan Antonio Garcia Redondo -
Kyle Harris -
Wolfgang Denk