[U-Boot-Users] Debugging u-boot goes to 0x70c (Program exception)
Hi,
I have problem in flash_init() to get correct manufacturer's ID. So I want to debug the function.
Once I set a breakpoint at flash_init() and issue a continue command, gdb always shows that the program stops at 0x0000070c, which means a program exception. A program exception can be caused by an illegal instruction, a privileged instruction, or a trap. I don't know which caused this exception in my case. I'm wondering it may not be u-boot itself but the way I'm debugging that caused this exception. So I attached the whole procedure I did, not very much long. Would anybody give me some hints? Thanks a lot.
-Shawn.
% ppc_82xx-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"... 0xfff00100 in ?? ()
(gdb) mon bi 0xffe00100 Breakpoint identification is 0 (gdb) mon go (gdb) mon ci (gdb) symbol-file Discard symbol table from `/u/code/u-boot-1.1.1/u-boot'? (y or n) y No symbol file now. (gdb) add-symbol-file u-boot 0x7fd9000 add symbol table from file "u-boot" at .text_addr = 0x7fd9000 (y or n) y Reading symbols from u-boot...done. (gdb) b board_init_r Breakpoint 1 at 0x7fdc9b4: file board.c, line 566. (gdb) d Delete all breakpoints? (y or n) y (gdb) mon bi 0x7fdc9b4 Breakpoint identification is 0 (gdb) c Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap. board_init_r (id=0x7fa8f98, dest_addr=0x7fd9000) at board.c:566 566 gd = id; /* initialize RAM version of global data */ (gdb) mon break soft (gdb) b flash_init Breakpoint 2 at 0x7fe1254: file flash.c, line 126. (gdb) c Continuing.
Program received signal SIGSTOP, Stopped (signal). 0x0000070c in ?? () (gdb)
U-Boot 1.1.1 (Jun 22 2004 - 15:49:59)
CPU: MPC8245 Revision 1.2 at 249.999 MHz: 16 kB I-Cache 16 kB D-Cache Board: MP8245, local bus @ 99.999 MHz DRAM: 128 MB Top of RAM usable for U-Boot at: 08000000 Reserving 152k for U-Boot at: 07fd9000 Reserving 192k for malloc() at: 07fa9000 Reserving 56 Bytes for Board Info at: 07fa8fc8 Reserving 48 Bytes for Global Data at: 07fa8f98 Stack Pointer at: 07fa8f78 New Stack Pointer is: 07fa8f78 Now running in RAM - U-Boot at: 07fd9000 FLASH:
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
In message 20040630220915.53309.qmail@web20728.mail.yahoo.com you wrote:
(gdb) mon bi 0xffe00100 Breakpoint identification is 0 (gdb) mon go (gdb) mon ci
...
(gdb) b board_init_r Breakpoint 1 at 0x7fdc9b4: file board.c, line 566. (gdb) d Delete all breakpoints? (y or n) y (gdb) mon bi 0x7fdc9b4 Breakpoint identification is 0 (gdb) c Continuing.
Why are you making all this trickery of setting and deleting breakpoints in GDB and directly in the BDI? This confuses me, and most probably it also confuses GDB, too.
(gdb) mon break soft (gdb) b flash_init Breakpoint 2 at 0x7fe1254: file flash.c, line 126.
Why don't you just set a single (hardware) breakpoint at this address, and then let the system boot without any additional messing with the debug state?
Best regards,
Wolfgang Denk
(gdb) b flash_init Breakpoint 2 at 0x7fe1254: file flash.c, line 126.
Why don't you just set a single (hardware) breakpoint at this address, and then let the system boot without any additional messing with the debug state?
Yeah. It works as you said. Somehow I had such impression to do some tricky steps to make gdb stop at wherever I want. :P
Thanks, -Shawn.
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
participants (2)
-
Shawn -
Wolfgang Denk