Skip to contentSkip to conversation

u-boot debugging boot with gdb and bdi2000 in lubbock(PXA255) board

U-Boot-Users Juan Antonio Garcia Redondo 3 participants 6 messages Sep 4, 2003

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

Dear Juan,

Quoted 5 lines · in message <[email protected]> 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.

Quoted 1 line

o Start my target, the jtag debugger is configured to stop the execution.

...

Quoted 2 lines

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.

Quoted 2 lines

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

Signature · 4 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
There is only one way to console a widow.  But remember the risk.
                                                   -- Robert Heinlein
#2 lore raw
In reply to Juan Antonio Garcia Redondo
Quoted 5 lines

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.

#3 lore raw
Quoted 6 lines · In message <[email protected]> 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

Signature · 4 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Emotions are alien to me.  I'm a scientist.
	-- Spock, "This Side of Paradise", stardate 3417.3
#4 lore raw
Quoted 11 lines · Wolfgang Denk
Quoted 7 lines · In message <[email protected]> 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.

Quoted 5 lines

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

#5 lore raw
Quoted 7 lines · In message <[email protected]> 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.

Quoted 5 lines

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

Signature · 4 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Just because your doctor has a name for your condition  doesn't  mean
he knows what it is.