using bdi2000 to debug ppcboot on mpc7455

using bdi2000 to debug ppcboot on mpc7455

[Q-ha Park]

[I apologize this question is off topic in this mailing
list:ppc-embedded. But I coundn't find a better place to ask,
ppcboot-users is inactive..]

I'm new to BDI2000, and after reading a manual that came with the tool,
I tried to debug ppcboot using bdi2000 and gdb. The problem is I just
can't set the breakpoint whether be it software or hardware breakpoint;
For example, when I set the break point at "boot_cold" and type
"continue", the program just runs without ever stopping at the
breakpoint where it's supposed to stop!

Here's what I did:
a. turn on bdi2000.
b. connect to bdi2000 in gdb session.
c. set the breakpoint
d. type "continue"

==========
90              li      r21, BOOTFLAG_COLD      /* Normal Power-On: Boot
from FLASH */
(gdb) l
85              .ascii  CONFIG_IDENT_STRING, "\0"
86
87              . = EXC_OFF_SYS_RESET
88              .globl  _start
89      _start:
90              li      r21, BOOTFLAG_COLD      /* Normal Power-On: Boot
from FLASH */
91              b       boot_cold
92              sync
93
94              . = EXC_OFF_SYS_RESET + 0x10
(gdb) b boot_cold
Breakpoint 1 at 0xfff02000: file
/home/users/qpark/hobby/ppcboot-1.1.6/cpu/74xx_7xx/start.S, line 253.
(gdb) cont
Continuing.
(continues for good...)
==========

What am I probably doing wrong? FYI, I tried to remove H/W breakpoint
before I entered "go"

Any help would be greatly appreciated!!

:::::::::::::::::::::::::::::::::::::::::::::::::
Q-ha Park


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: using bdi2000 to debug ppcboot on mpc7455

[Mark A. Greer]

Q-ha Park wrote:

>I'm new to BDI2000, and after reading a manual that came with the tool,
>I tried to debug ppcboot using bdi2000 and gdb. The problem is I just
>can't set the breakpoint whether be it software or hardware breakpoint;
>For example, when I set the break point at "boot_cold" and type
>"continue", the program just runs without ever stopping at the
>breakpoint where it's supposed to stop!
>
>
Well, I haven't used the gdb interface with the 745x but I do know that
that with the telnet interface, you have to specify whether you're
setting a breakpoint on a virtual or physical addr (virtual is default,
IIRC).  How you would do this with the gdb interface, I know not but
take a close look at the manual for the 745x--it *is* different from the
7410, etc--and you may find the answer.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: using bdi2000 to debug ppcboot on mpc7455

[bradbosch]

Q-ha,

You didn't give enough details about what you tried for us guess what
is wrong, but there are several issues with debugging U-Boot or
ppcboot with the bdi2000 which require a good understanding of what is
going on.  Here is some info that may be of help.  I also have a
request for you or anyone else using the 745x processors with the
BDI2000 at the end of this message.

In addition to the issue Mark pointed out, you can't use soft
breakpoints while you are running from ROM which is the common case
for the early init parts of U-Boot.

Also, once U-Boot has relocated itself, you need to identify the new
base address and inform gdb of the new load address.

In this example GDB session, I have my BDI config file set up for
address translation and software breakpoints.  I have included some
command options which are the defaults to make it more clear what is
going on.  I have also added some comments inline:

[brad@gizmo u-boot]$ ppc-linux-gdb
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".
(gdb) add-symbol-file u-boot 0xfff00000
add symbol table from file "u-boot" at
        .text_addr = 0xfff00000
(y or n) y
Reading symbols from u-boot...done.

//// We didn't need the address above, but I wanted to make it clear
//// how it differs from the later use of add-symbol-file.

(gdb) target remote 10.100.50.221:2001
Remote debugging using 10.100.50.221:2001
_start () at /d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S:94
94              li      r21, BOOTFLAG_COLD      /* Normal Power-On: Boot from FLASH */
(gdb) b boot_cold
Breakpoint 1 at 0xfff02000: file /d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S, line 271.
(gdb) d
Delete all breakpoints? (y or n) y

//// We can't use software breakpoints yet so the above was just an easy
//// way to get the address where we want to set our hardware breakpoint.

(gdb) mon bi 0xfff02000 p
Breakpoint identification is 0

//// The monitor command is a handy way to avoid switching to a telnet
//// window to use the telnet interface.  The p option forces a physical
//// mode breakpoint.

(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
boot_warm () at /d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S:271
271             li      r0, 0
(gdb) list in_flash
319             /* perform low-level init */
320             /* sdram init, galileo init, etc */
321             /* r3:  NHR bit from HID0 */
322
323             /* setup the bats */
324             bl      setup_bats
325             sync
326
327             /*
328              * Cache must be enabled here for stack-in-cache trick.
(gdb)
329              * This means we need to enable the BATS.
330              * This means:
331              *   1) for the EVB, original gt regs need to be mapped
332              *   2) need to have an IBAT for the 0xf region,
333              *      we are running there!
334              * Cache should be turned on after BATs, since by default
335              * everything is write-through.
336              * The init-mem BAT can be reused after reloc. The old
337              * gt-regs BAT can be reused after board_init_f calls
338              * board_pre_init (EVB only).
(gdb)
339              */
340     #if !defined(CONFIG_BAB7xx) && !defined(CONFIG_ELPPC)
341             /* enable address translation */
342             bl      enable_addr_trans
343             sync
344
345     #if 1
346             /* enable and invalidate the data cache */
347             bl      l1dcache_enable
348     #endif
(gdb) b 343
Breakpoint 3 at 0xfff0203c: file /d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S, line 343.
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) mon ci
(gdb) mon bi 0xfff0203c v
Breakpoint identification is 0

//// We just turned on address translation so the rest of our hardware
//// breakpoints must use virtual mode, thus the v above.

(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
in_flash () at /d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S:343
343             sync
(gdb) symbol-file
Discard symbol table from `/d/build/brad/u-boot-discov/u-boot/u-boot'? (y or n) y
No symbol file now.
(gdb) add-symbol-file u-boot 0x0ffb8000
add symbol table from file "u-boot" at
        .text_addr = 0xffb8000
(y or n) y
Reading symbols from u-boot...done.

//// Prepare to set breakpoints after we relocate to RAM.  Throw out
//// the old symbol table and reload it with the correct base address
//// (which we got from examining the code or as reported by U-Boot before
//// it began running in RAM.

(gdb) b after_reloc
Breakpoint 5 at 0xffba92c: file db64360.c, line 416.
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) mon ci
(gdb) mon bi 0xffba92c v
Breakpoint identification is 0
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
after_reloc (gd=0xff96f9c, dest_addr=268140544) at db64360.c:416
416             board_init_r(gd, dest_addr);

//// OK.  Now we are in RAM and we can use soft breakpoints from here
//// on out.

(gdb) b board_init_r
Breakpoint 6 at 0xffc14a0: file board.c, line 589.
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
after_reloc (gd=0xff96f9c, dest_addr=268140544) at db64360.c:416
416             board_init_r(gd, dest_addr);
(gdb) list
411             }
412             memoryMapDeviceSpace(BOOT_DEVICE, CFG_FLASH_BASE, CFG_FLASH_SIZE);
413     #endif
414
415             /* now, jump to the main ppcboot board init code */
416             board_init_r(gd, dest_addr);
417
418             /* NOTREACHED */
419     }
420
(gdb) print /x dest_addr
$1 = 0xffb8000
(gdb) step


Once you get all this working, could you please do me a favor and let
me know if you ever have any problems with single step ("mon ti" or
"stepi") not working?  I have a lot of trouble with this with my
7447/Discovery II combo and I am trying to figure out if it is a board
issue or a processor issue or a BDI issue.

--Brad

Q-ha Park writes:
 >
 > [I apologize this question is off topic in this mailing
 > list:ppc-embedded. But I coundn't find a better place to ask,
 > ppcboot-users is inactive..]
 >
 > I'm new to BDI2000, and after reading a manual that came with the tool,
 > I tried to debug ppcboot using bdi2000 and gdb. The problem is I just
 > can't set the breakpoint whether be it software or hardware breakpoint;
 > For example, when I set the break point at "boot_cold" and type
 > "continue", the program just runs without ever stopping at the
 > breakpoint where it's supposed to stop!
 >
 > Here's what I did:
 > a. turn on bdi2000.
 > b. connect to bdi2000 in gdb session.
 > c. set the breakpoint
 > d. type "continue"
 >
 > ==========
 > 90              li      r21, BOOTFLAG_COLD      /* Normal Power-On: Boot
 > from FLASH */
 > (gdb) l
 > 85              .ascii  CONFIG_IDENT_STRING, "\0"
 > 86
 > 87              . = EXC_OFF_SYS_RESET
 > 88              .globl  _start
 > 89      _start:
 > 90              li      r21, BOOTFLAG_COLD      /* Normal Power-On: Boot
 > from FLASH */
 > 91              b       boot_cold
 > 92              sync
 > 93
 > 94              . = EXC_OFF_SYS_RESET + 0x10
 > (gdb) b boot_cold
 > Breakpoint 1 at 0xfff02000: file
 > /home/users/qpark/hobby/ppcboot-1.1.6/cpu/74xx_7xx/start.S, line 253.
 > (gdb) cont
 > Continuing.
 > (continues for good...)
 > ==========
 >
 > What am I probably doing wrong? FYI, I tried to remove H/W breakpoint
 > before I entered "go"
 >
 > Any help would be greatly appreciated!!
 >
 > :::::::::::::::::::::::::::::::::::::::::::::::::
 > Q-ha Park
 >
 >

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: using bdi2000 to debug ppcboot on mpc7455

[Mark A. Greer]

bradbosch@attbi.com wrote:

>Once you get all this working, could you please do me a favor and let
>me know if you ever have any problems with single step ("mon ti" or
>"stepi") not working?  I have a lot of trouble with this with my
>7447/Discovery II combo and I am trying to figure out if it is a board
>issue or a processor issue or a BDI issue.
>
>
Hi Brad.

I almost exclusively use the telnet interface (and hard breakpoints) to
the bdi b/c I do a lot of early on debug.  I have noticed with certain
processors that a single step will occasionally go several instructions
before stopping.  Unfortunately, I don't remember which processors I see
that on and I've never had a 7447 to try.  What I'm getting at is: a)
yes, I have seen some [minor] breakpoint problems with the bdi (or
possibly the breakpoint implementation on the processor); and b) try
using the telnet interface to eliminate a possible gdb-related problem.

Just my $0.02.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: using bdi2000 to debug ppcboot on mpc7455

[Q-ha Park]

Brad,

Thanks a lot for your very informative reply; it helped me greatly and I
can finally play with breakpoints. Although I failed to set the
breakpoint at after_reloc but the point right before boart_init_r.

To answer your question about "mon ti" and "stepi" causing any trouble,
"mon ti" worked and "stepi" didn't quite work. When I signle-step in
board_init_r, the ppcboot spits out the following:

------
Reserving 68 Bytes for Board Info at: 1ff3ffbc
Stack Pointer at: 1ff3ff98
New Stack Pointer is: 1ff3ff98
<<< single step >>>
NR
  R 00 0 0  8

             R: 00000000 LR: 1FFC2CEC REGS: 1ff3fe78 TRAP:
070:M01000001210P
-------
not too pretty. :-(

anyways, thanks again!

Q-ha


-----Original Message-----
From: bradbosch@attbi.com [mailto:bradbosch@attbi.com]
Sent: Thursday, September 25, 2003 11:26 PM
To: Mark A. Greer; Q-ha Park; linuxppc-embedded@lists.linuxppc.org
Subject: Re: using bdi2000 to debug ppcboot on mpc7455


Q-ha,

You didn't give enough details about what you tried for us guess what
is wrong, but there are several issues with debugging U-Boot or
ppcboot with the bdi2000 which require a good understanding of what is
going on.  Here is some info that may be of help.  I also have a
request for you or anyone else using the 745x processors with the
BDI2000 at the end of this message.

In addition to the issue Mark pointed out, you can't use soft
breakpoints while you are running from ROM which is the common case
for the early init parts of U-Boot.

Also, once U-Boot has relocated itself, you need to identify the new
base address and inform gdb of the new load address.

In this example GDB session, I have my BDI config file set up for
address translation and software breakpoints.  I have included some
command options which are the defaults to make it more clear what is
going on.  I have also added some comments inline:

[brad@gizmo u-boot]$ ppc-linux-gdb
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".
(gdb) add-symbol-file u-boot 0xfff00000
add symbol table from file "u-boot" at
        .text_addr = 0xfff00000
(y or n) y
Reading symbols from u-boot...done.

//// We didn't need the address above, but I wanted to make it clear
//// how it differs from the later use of add-symbol-file.

(gdb) target remote 10.100.50.221:2001
Remote debugging using 10.100.50.221:2001
_start () at /d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S:94
94              li      r21, BOOTFLAG_COLD      /* Normal Power-On: Boot
from FLASH */
(gdb) b boot_cold
Breakpoint 1 at 0xfff02000: file
/d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S, line 271.
(gdb) d
Delete all breakpoints? (y or n) y

//// We can't use software breakpoints yet so the above was just an easy
//// way to get the address where we want to set our hardware
breakpoint.

(gdb) mon bi 0xfff02000 p
Breakpoint identification is 0

//// The monitor command is a handy way to avoid switching to a telnet
//// window to use the telnet interface.  The p option forces a physical
//// mode breakpoint.

(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
boot_warm () at
/d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S:271
271             li      r0, 0
(gdb) list in_flash
319             /* perform low-level init */
320             /* sdram init, galileo init, etc */
321             /* r3:  NHR bit from HID0 */
322
323             /* setup the bats */
324             bl      setup_bats
325             sync
326
327             /*
328              * Cache must be enabled here for stack-in-cache trick.
(gdb)
329              * This means we need to enable the BATS.
330              * This means:
331              *   1) for the EVB, original gt regs need to be mapped
332              *   2) need to have an IBAT for the 0xf region,
333              *      we are running there!
334              * Cache should be turned on after BATs, since by
default
335              * everything is write-through.
336              * The init-mem BAT can be reused after reloc. The old
337              * gt-regs BAT can be reused after board_init_f calls
338              * board_pre_init (EVB only).
(gdb)
339              */
340     #if !defined(CONFIG_BAB7xx) && !defined(CONFIG_ELPPC)
341             /* enable address translation */
342             bl      enable_addr_trans
343             sync
344
345     #if 1
346             /* enable and invalidate the data cache */
347             bl      l1dcache_enable
348     #endif
(gdb) b 343
Breakpoint 3 at 0xfff0203c: file
/d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S, line 343.
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) mon ci
(gdb) mon bi 0xfff0203c v
Breakpoint identification is 0

//// We just turned on address translation so the rest of our hardware
//// breakpoints must use virtual mode, thus the v above.

(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
in_flash () at
/d/build/brad/u-boot-discov/u-boot/cpu/74xx_7xx/start.S:343
343             sync
(gdb) symbol-file
Discard symbol table from `/d/build/brad/u-boot-discov/u-boot/u-boot'?
(y or n) y
No symbol file now.
(gdb) add-symbol-file u-boot 0x0ffb8000
add symbol table from file "u-boot" at
        .text_addr = 0xffb8000
(y or n) y
Reading symbols from u-boot...done.

//// Prepare to set breakpoints after we relocate to RAM.  Throw out
//// the old symbol table and reload it with the correct base address
//// (which we got from examining the code or as reported by U-Boot
before
//// it began running in RAM.

(gdb) b after_reloc
Breakpoint 5 at 0xffba92c: file db64360.c, line 416.
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) mon ci
(gdb) mon bi 0xffba92c v
Breakpoint identification is 0
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
after_reloc (gd=0xff96f9c, dest_addr=268140544) at db64360.c:416
416             board_init_r(gd, dest_addr);

//// OK.  Now we are in RAM and we can use soft breakpoints from here
//// on out.

(gdb) b board_init_r
Breakpoint 6 at 0xffc14a0: file board.c, line 589.
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
after_reloc (gd=0xff96f9c, dest_addr=268140544) at db64360.c:416
416             board_init_r(gd, dest_addr);
(gdb) list
411             }
412             memoryMapDeviceSpace(BOOT_DEVICE, CFG_FLASH_BASE,
CFG_FLASH_SIZE);
413     #endif
414
415             /* now, jump to the main ppcboot board init code */
416             board_init_r(gd, dest_addr);
417
418             /* NOTREACHED */
419     }
420
(gdb) print /x dest_addr
$1 = 0xffb8000
(gdb) step


Once you get all this working, could you please do me a favor and let
me know if you ever have any problems with single step ("mon ti" or
"stepi") not working?  I have a lot of trouble with this with my
7447/Discovery II combo and I am trying to figure out if it is a board
issue or a processor issue or a BDI issue.

--Brad

Q-ha Park writes:
 >
 > [I apologize this question is off topic in this mailing
 > list:ppc-embedded. But I coundn't find a better place to ask,
 > ppcboot-users is inactive..]
 >
 > I'm new to BDI2000, and after reading a manual that came with the
tool,
 > I tried to debug ppcboot using bdi2000 and gdb. The problem is I just
 > can't set the breakpoint whether be it software or hardware
breakpoint;
 > For example, when I set the break point at "boot_cold" and type
 > "continue", the program just runs without ever stopping at the
 > breakpoint where it's supposed to stop!
 >
 > Here's what I did:
 > a. turn on bdi2000.
 > b. connect to bdi2000 in gdb session.
 > c. set the breakpoint
 > d. type "continue"
 >
 > ==========
 > 90              li      r21, BOOTFLAG_COLD      /* Normal Power-On:
Boot
 > from FLASH */
 > (gdb) l
 > 85              .ascii  CONFIG_IDENT_STRING, "\0"
 > 86
 > 87              . = EXC_OFF_SYS_RESET
 > 88              .globl  _start
 > 89      _start:
 > 90              li      r21, BOOTFLAG_COLD      /* Normal Power-On:
Boot
 > from FLASH */
 > 91              b       boot_cold
 > 92              sync
 > 93
 > 94              . = EXC_OFF_SYS_RESET + 0x10
 > (gdb) b boot_cold
 > Breakpoint 1 at 0xfff02000: file
 > /home/users/qpark/hobby/ppcboot-1.1.6/cpu/74xx_7xx/start.S, line 253.
 > (gdb) cont
 > Continuing.
 > (continues for good...)
 > ==========
 >
 > What am I probably doing wrong? FYI, I tried to remove H/W breakpoint
 > before I entered "go"
 >
 > Any help would be greatly appreciated!!
 >
 > :::::::::::::::::::::::::::::::::::::::::::::::::
 > Q-ha Park
 >
 >


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: using bdi2000 to debug ppcboot on mpc7455

[Wolfgang Denk]

In message <16242.64239.133401.668446@waldo.lisle.iphase.com> you wrote:
>
> In addition to the issue Mark pointed out, you can't use soft
> breakpoints while you are running from ROM which is the common case
> for the early init parts of U-Boot.
>
> Also, once U-Boot has relocated itself, you need to identify the new
> base address and inform gdb of the new load address.

And not to forget that, in the very  early  startup  code  (like  the
symbol  "boot_cold" mentioned by Q-ha Park), the memory controller is
still running in the reset configuration, i. e.  the  PC  will  still
point  to the reset vector area (0x0000'01xx or 0xFFF0'01xx), and NOT
yet  to  the  addresses  in  the  U-Boot  symbol  table.  Only  after
"in_flash" the symbols are correct.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"A little knowledge is a dangerous thing."                - Doug Gwyn

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: using bdi2000 to debug ppcboot on mpc7455

[Wolfgang Denk]

In message <005e01c383f2$65430080$2a21a8c0@qha> you wrote:
>
> Thanks a lot for your very informative reply; it helped me greatly and I
> can finally play with breakpoints. Although I failed to set the
> breakpoint at after_reloc but the point right before boart_init_r.

For debugging U-Boot / PPCBoot after relocation see
http://www.denx.de/twiki/bin/view/DULG/DebuggingUBoot#Section_9.1.2.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Heavier than air flying machines are impossible.
                    -- Lord Kelvin, President, Royal Society, c. 1895

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: using bdi2000 to debug ppcboot on mpc7455

[Rod Boyce]

Ok so with a bit of tongue and cheek.... To Quote Wolfgang from the 24th of
May 2001...

"Everybody listen: I _will_ mention this trick a 9th  time  for  free. The
10th person asking the same question will owe me a beer."

Does this mean that Q-ha Park owes Wolfgang a beer? ;-)

Rod

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd@denx.de]
> Sent: Wednesday, 1 October 2003 9:35 a.m.
> To: Q-ha Park
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: using bdi2000 to debug ppcboot on mpc7455
>
>
> In message <005e01c383f2$65430080$2a21a8c0@qha> you wrote:
> >
> > Thanks a lot for your very informative reply; it helped me greatly and I
> > can finally play with breakpoints. Although I failed to set the
> > breakpoint at after_reloc but the point right before boart_init_r.
>
> For debugging U-Boot / PPCBoot after relocation see
> http://www.denx.de/twiki/bin/view/DULG/DebuggingUBoot#Section_9.1.2.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> Heavier than air flying machines are impossible.
>                     -- Lord Kelvin, President, Royal Society, c. 1895
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: using bdi2000 to debug ppcboot on mpc7455

[Wolfgang Denk]

In message <8D7C5F56B409554D9D46AC22195807F3061D5C@exchwenz01.dmcwave.co.nz> you wrote:
>
> Ok so with a bit of tongue and cheek.... To Quote Wolfgang from the 24th of
> May 2001...
>
> "Everybody listen: I _will_ mention this trick a 9th  time  for  free. The
> 10th person asking the same question will owe me a beer."

:-)

> Does this mean that Q-ha Park owes Wolfgang a beer? ;-)

Well, actually I just had some beer right now, so  he  shall  go  for
free, too :-)

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I wish Captain Vimes were here. He wouldn't have  known  what  to  do
either, but he's got a much better vocabulary to be baffled in.
                                 - Terry Pratchett, _Guards! Guards!_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: using bdi2000 to debug ppcboot on mpc7455

[Q-ha Park]

Soft breakpoints just don't work for me. I have two BDI tools, and they
behave the same. Not only that, "next", "step", and other commands just
don't work properly.

Here's what I get:
(gdb) add-symbol-file ppcboot 0x1ffc0000
add symbol table from file "ppcboot" at
        .text_addr = 0x1ffc0000
(y or n) y
Reading symbols from ppcboot...done.
(gdb) b board_init_r
Breakpoint 1 at 0x1ffc2cb0: file board.c, line 570.
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) mon bi 0x1ffc2cb0 v
Breakpoint identification is 0

///// I have to use "mon bi" to make the program stop properly.

(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
board_init_r (bd=0x1ff3fffa, dest_addr=536084376) at board.c:570
570     {
------------------------
(gdb) b flash_init
Breakpoint 2 at 0x1ffd4100: file flash.c, line 330.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
board_init_r (bd=0x1ff3fffa, dest_addr=536084376) at board.c:570
570     {

/////// It stopped at board_init_r again..... not flash_init

(gdb) d
Delete all breakpoints? (y or n) y
(gdb) b flash_init
Breakpoint 3 at 0x1ffd4100: file flash.c, line 330.
(gdb) c
Continuing.
warning: Cannot insert breakpoint -1:
Error accessing memory address 0xfff00100: Unknown error 4294967295.
(gdb)

And now I get this. Did anyone go thru something like this?

Q-ha Park


-----Original Message-----
From: bradbosch@attbi.com [mailto:bradbosch@attbi.com]
Sent: Thursday, September 25, 2003 11:26 PM
To: Mark A. Greer; Q-ha Park; linuxppc-embedded@lists.linuxppc.org
Subject: Re: using bdi2000 to debug ppcboot on mpc7455

<snip>

//// OK.  Now we are in RAM and we can use soft breakpoints from here
//// on out.

(gdb) b board_init_r
Breakpoint 6 at 0xffc14a0: file board.c, line 589.
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
after_reloc (gd=0xff96f9c, dest_addr=268140544) at db64360.c:416
416             board_init_r(gd, dest_addr);
(gdb) list
=======================


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: using bdi2000 to debug ppcboot on mpc7455

[Wolfgang Denk]

In message <000501c387e9$52901590$2a21a8c0@qha> you wrote:
>
> Soft breakpoints just don't work for me. I have two BDI tools, and they
> behave the same. Not only that, "next", "step", and other commands just
> don't work properly.
>
> Here's what I get:
> (gdb) add-symbol-file ppcboot 0x1ffc0000
> add symbol table from file "ppcboot" at
>         .text_addr = 0x1ffc0000

Are you sure  that  0x1ffc0000  is  a  correct  address  of  for  the
relocated image? Do you really have 512 MB of RAM on your system? And
does your U-Boot image really require exactly 256 kB of space?

I think these numbers might be wrong...

> Error accessing memory address 0xfff00100: Unknown error 4294967295.
> (gdb)
>
> And now I get this. Did anyone go thru something like this?

Sounds like you are using bogus addresses.

#define DEBUG when compiling lib_ppc/board.c and check the output.



BTW: this discussion if off-topic in linuxppc-embedded;  please  post
any follow-ups to u-boot-users instead.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It is your destiny.                                     - Darth Vader

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/