Debugging U-Boot with BDI3000
Hi there,
I have a BDI3000, and I was starting a remote GDB debugging session per the instructions on http://www.denx.de/wiki/DULG/DebuggingUBoot. I reset the target prior to running these commands. I've tried this with both U-Boot 1.3.2 and 1.3.3.
When I enter the "target remote" command, it ends up in 0x00000000 instead of the reset vector at 0xfffffffc. I have pasted my commands below. Can anyone tell me what I'm missing? I just want to step through a few instructions and verify that the reset vector code jumps to _start (or _start_440 in my case), and then step through _start afterwards.
user at SW:~/work/src/eldk/ppc_4xxFP/usr/src/u-boot-1.3.3$ ppc_4xxFP-gdb u-boot GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
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=i386-redhat-linux --target=ppc-linux". The target architecture is set automatically (currently powerpc:403) ..
(gdb) target remote 192.168.1.64:2001
Remote debugging using 192.168.1.64:20010x00000000 in ?? ()
(gdb) b cpu_init_f
Breakpoint 1 at 0xfff82898: file cpu_init.c, line 211.
(gdb) c
Continuing.
Program received signal SIGSTOP, Stopped (signal). 0xbebebebe in ?? ()
(gdb) quit
The program is running. Exit anyway? (y or n) y user at SW:~/work/src/eldk/ppc_4xxFP/usr/src/u-boot-1.3.3$
Signature · 2 lines
View this message in context: http://www.nabble.com/Debugging-U-Boot-with-BDI3000-tp17346329p17346329.html Sent from the Uboot - Users mailing list archive at Nabble.com.
Quoted 6 lines · In message <[email protected]> you wrote:
When I enter the "target remote" command, it ends up in
0x00000000instead of the reset vector at0xfffffffc. I have pasted my commands below. Can anyone tell me what I'm missing? I just want to step through a few instructions and verify that the reset vector code jumps to_start(or_start_440in my case), and then step through_startafterwards.
Probably your BDI config file needs adjusting. Try what you see when you use the telnet interface directly, i. e. where do you end up after a "reset halt" ?
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "...one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." - Robert Firth
Wolfgang,
The BDI config file for the Yosemite board on the U-Boot manual doesn't work (I can't erase the full range of flash between 0xFC000000 to 0xFFFFFFFF), so I've been using the one provided by AMCC.
When I do a reset halt, the PC does get set to 0xFFFFFFFC (please see below). But GDB still goes straight to 0x00000000.
The BDI config file from the U-Boot manual only allocates 2MB of flash (there are 64MBs on this board). If I use this config file, the GDB goes to 0xdeadbeef (but the BDI telnet shows the correct 0xFFFFFFFC for the PC after a reset-halt).
U-Boot is fully operational after I flash it onto the board, regardless of which config file I use.
440EP>reset
- TARGET: processing user reset request
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: core #0 PVR is 0x422218D4
- TARGET: processing target startup passed
440EP>halt
Core number : 0
Core state : debug mode
Debug entry cause : JTAG stop request
Current PC : 0xfffffffc
Current CR : 0x280fff82
Current MSR : 0x00002000
Current LR : 0x0ff9b084440EP>
Quoted 16 lines
Probably your BDI config file needs adjusting. Try what you see when you use the telnet interface directly, i. e. where do you end up after a "reset halt" ?
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "...one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." - Robert Firth
_________________________________________________________________
Change the world with e-mail. Join the i?m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ChangeWorld
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080520/ca47003b/attachment.htm
Quoted 4 lines · In message <[email protected]> you wrote:
The BDI config file for the Yosemite board on the U-Boot manual doesn't wor k (I can't erase the full range of flash between
0xFC000000to0xFFFFFFFF),
so I've been using the one provided by AMCC.
I doubt that. The examples in the manual are generated automatically (by running DUTS); it seems to have worked by then.
BTW: Please rstrict your line length to some 70 characters or so.
Quoted 7 lines
When I do a reset halt, the PC does get set to
0xFFFFFFFC(please see below ). But GDB still goes straight to0x00000000.The BDI config file from the U-Boot manual only allocates 2MB of flash (the re are 64MBs on this board). If I use this config file, the GDB goes to
0xdeadbeef (but the BDI telnet shows the correct0xFFFFFFFCfor the PC after a
reset-halt).
I don't understand what the flash mapping has to do with the operation of GDB? As long as all of the U-Boot image is mapped, everything should be fine. Also, I think the provided config file does map 4 MB at 0xFFC00000, doesn't it?
Quoted 5 lines
Quoted 5 lines
Probably your BDI config file needs adjusting. Try what you see when you use the telnet interface directly, i. e. where do you end up after a "reset halt" ?
Best regards,
...
Please don't top-post / full-quote!
Quoted 3 lines
--_a74128a5-4aff-492d-8a22-57e20feb9b73_
Content-Type: text/html; charset?indows-1252"
Content-Transfer-Encoding: quoted-printable
And please do NOT post HTML here.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Anything free is worth what you pay for it.