Skip to contentSkip to conversation

Debugging U-Boot with BDI3000

U-Boot-Users onyxtape 2 participants 4 messages May 20, 2008

lore
Share & tools
lore

onyxtape

author
#0 lore raw

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:2001
0x00000000 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.
#1 lore raw
Quoted 6 lines · In message <[email protected]> you wrote:

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.

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
author
#2 lore raw

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        : 0x0ff9b084

440EP>

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

#3 lore raw
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 0xFC000000 to 0xFFFFFFFF),
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 to 0x00000000.

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 0xd eadbeef (but the BDI telnet shows the correct 0xFFFFFFFC for 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.