[U-Boot-Users] Debugging U-Boot with BDI3000

[U-Boot-Users] Debugging U-Boot with BDI3000

[onyxtape]

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$ 

-- 
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.

[U-Boot-Users] Debugging U-Boot with BDI3000

[Wolfgang Denk]

In message <17346329.post@talk.nabble.com> 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

-- 
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

[U-Boot-Users] Debugging U-Boot with BDI3000

[M C]

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>


> 
> 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
> 
> -- 
> 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 

[U-Boot-Users] Debugging U-Boot with BDI3000

[Wolfgang Denk]

In message <BAY118-W5099133B24D94DCAAA6BEFCFC40@phx.gbl> 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.

> 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?

> > 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!

> --_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

-- 
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.