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.
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:
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)
cpu_init_f is the first C function called from the code in
start.C.
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
<MAXMEM> -
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
unsigned long reloc_off; /* Relocation Offset */
which is the offset between the image addresses in flash and in
RAM. You can easily print this value in gdb like that:
(gdb) print/x ((gd_t *)$r2)->reloc_off
Then add this value to the value of
TEXT_BASE as defined in your
board's
config.mk file, and you get the start address of the U-Boot
image in RAM.
With this knowledge, we can instruct gdb to forget the old symbol table
and reload the symbols with our calculated offset:
(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)
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
10.3. GDB Startup File and Utility Scripts.
