[U-Boot-Users] debug uboot-1.1.1 with BDI2000 after it relocated

Hi,
I am having trouble to debug u-boot-1.1. 1 once it has relocated itself. The platform I am using is the LITE5200 (64 MB RAM). For these tests, I am loading uboot in RAM ("TEXT_BASE = 0x00020000"), so starting address is 20100. I am using gdb 6.3 with the BDI2000 debug interface.
I can debug fine until u-boot relocate to the end of the available RAM:
/phoenix/uboot-1.1.1$ powerpc-linux-gdb --nx GNU gdb 6.3 Copyright 2004 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=powerpc-linux". (gdb) target remote bdi:2001 Remote debugging using bdi:2001 <signal handler called> (gdb) symbol-file u-boot Reading symbols from /phoenix/uboot-1.1.1/u-boot...done. (gdb) break relocate_code Breakpoint 1 at 0x2333c: file /phoenix/uboot-1.1.1/cpu/mpc5xxx/start.S, line 572. (gdb) c Continuing.
Breakpoint 1, relocate_code () at /phoenix/uboot-1.1.1/cpu/mpc5xxx/start.S:573 573 mr r9, r4 /* Save copy of Global Data pointer */ (gdb) break 661 Breakpoint 2 at 0x23424: file /phoenix/uboot-1.1.1/cpu/mpc5xxx/start.S, line 661. (gdb) del 1 (gdb) c Continuing.
Breakpoint 2, relocate_code () at /phoenix/uboot-1.1.1/cpu/mpc5xxx/start.S:661 661 blr (gdb) si Cannot access memory at address 0x206d6ff5 (gdb) bt #0 <signal handler called> Cannot access memory at address 0x206d6ff5 (gdb)
From there, using the BDI2000 telnet interface, I check PC:
BDI>info Target CPU : MPC8280/8220/5200 (Zeppo) Target state : debug mode Debug entry cause : trace Current PC : 0x03f85428 Current CR : 0x24000004 Current MSR : 0x00003002 Current LR : 0x03f85428 BDI>
We are now running <in_ram>. Its address before relocation is 0x23428. After relocation, it is 0x03f85428. Delta is 0x3F62000, and that matches the address I was expecting to find (0x3F82000 is the new destination address provided to the function <relocate_code>)
Then I reload the symbol table within gdb:
(gdb) symbol-file (gdb) add-symbol-file u-boot 0x3F82000 add symbol table from file "u-boot" at .text_addr = 0x3f82000 (gdb) p in_ram $1 = {<text variable, no debug info>} 0x3f85428 <in_ram> (gdb) bt #0 <signal handler called> Cannot access memory at address 0x206d6ff5 (gdb) break board_init_r Breakpoint 3 at 0x3f86680: file board.c, line 566. (gdb) c
Breakpoint 3, <signal handler called> (gdb) bt #0 <signal handler called> Cannot access memory at address 0x313135b2
I stop on the function, but can't see the source, as I would expect... (please note that I use HW breakpoints
Any idea what I am doing wrong or missing ? TIA and Best Regards, Olivier

In message 32845.64.16.143.89.1102004325.squirrel@64.16.143.89 you wrote:
I am having trouble to debug u-boot-1.1. 1 once it has relocated itself.
Problem # 1: you are using old code. Why don't you use the latest version, i. e. top of CVS?
For these tests, I am loading uboot in RAM ("TEXT_BASE = 0x00020000"),
Problem # 2: You do something which is explictely unsupported and for which you will not receive any help on this list. See http://www.denx.de/twiki/bin/view/DULG/CanUBootBeConfiguredSuchThatItCanBeSt...
Best regards,
Wolfgang Denk
participants (2)
-
olivier@singla.us
-
Wolfgang Denk