DebuggingUBoot < DULG

%SECTION0{name=DebuggingUBoot}% Debugging of U-Boot

When U-Boot starts it is running from ROM space.  Running from flash would
make it nearly impossible to read from flash while executing code from flash
not to speak of updating the U-Boot image in flash itself.  To be able to do
just that, U-Boot relocates itself to RAM.  We therefore
have two phases with different program addresses.  The following sections
show how to debug U-Boot in both phases.

%SECTION1{name=DebuggingUBootBefore}% Debugging of U-Boot Before Relocation

Before relocation, the addresses in the ELF file can be used without any
problems, so debugging U-Boot in this phase with the BDI2000 is quite easy:

<verbatim>
bash[0]$ ${CROSS_COMPILE}gdb u-boot
GNU gdb 5.1.1
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=i386-redhat-linux --target=ppc-linux"...

(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0xfffffffc in ?? ()
(gdb) b cpu_init_f
Breakpoint 1 at 0xfffd3310: file cpu_init.c, line 136.
(gdb) c
Continuing.
 
Breakpoint 1, cpu_init_f () at cpu_init.c:136
136             asm volatile("  bl      0f"             ::: "lr");
(gdb) s
137             asm volatile("0:        mflr    3"              ::: "r3");
(gdb)
138             asm volatile("  addi    4, 0, 14"       ::: "r4");
(gdb)
</verbatim>

=cpu_init_f= is the first C function called from the code in =start.C=.

%SECTION1{name=DebuggingUBootAfter}% Debugging of U-Boot After Relocation

For debugging U-Boot after relocation we need to know the address to which
U-Boot relocates itself to.  When no exotic features like =PRAM= are used, this
address usually is =&lt;MAXMEM&gt;= - =CONFIG_SYS_MONITOR_LEN=.  In our example with 16MB 
RAM and =CONFIG_SYS_MONITOR_LEN= = 192KB this yields the address =0x1000000= - =0x30000= =
=0xFD0000=.

In other cases, check the source code, and apply some common sense.
For example, on Power Architecture® we use "r2" to hold a pointer to the "global
data" structure (="struct global_data"=); this structure contains a
field
<verbatim>
unsigned long   relocaddr;      /* Start address of U-Boot in RAM */
</verbatim>
which is the start addresses of U-Boot after relocation to
RAM. You can easily print this value in gdb like that:
<verbatim>
(gdb) print/x ((gd_t *)$r2)->relocaddr
</verbatim>
With this knowledge, we can instruct gdb to forget the old symbol table
and reload the symbols with our calculated offset:

<verbatim>
(gdb) symbol-file
Discard symbol table from `/home/dzu/denx/cvs-trees/u-boot/u-boot'? (y or n) y
No symbol file now.
(gdb) add-symbol-file u-boot 0xfd0000
add symbol table from file "u-boot" at
        .text_addr = 0xfd0000
(y or n) y
Reading symbols from u-boot...done.
(gdb) b board_init_r
Breakpoint 2 at 0xfd99ac: file board.c, line 533.
(gdb) c
Continuing.

Breakpoint 2, board_init_r (id=0xfbb1f0, dest_addr=16495088) at board.c:533
533     {
(gdb)
</verbatim>
=board_init_r= is the first C routine running in the newly relocated C friendly RAM
environment.

The simple example above relocates the symbols of only one section, =.text=.
Other sections of the executable image (like =.data=, =.bss=, etc.) are not relocated
and this prevents =gdb= from accessing static and global variables by name.
See more sophisticated examples in section
%REF{type=Section, topic=GDBScripts, name=GDBScripts}%.
10. Debugging		1. Abstract		10.2. Linux Kernel Debugging
Prev		Home		Next