Skip to main content.
Navigation:
DENX
>
DULG
>
DebuggingUBoot
Translations:
Edit
|
Attach
|
Raw
|
Ref-By
|
Printable
|
More
DULG
Sections of this site:
DENX Home
|
DULG
|
ELDK-5
|
Know
|
Training
|
U-Boot
|
U-Bootdoc
Topics
DULG Home
BoardSelect
Manual
FAQ
Application Notes
Changes
Index
List of pages in DULG
Search
%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 =<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 <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