[U-Boot-Users] Au1550 U-boot debugging - a newbie question

[Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>]

RadekFisera wrote:
> When I program the bin file to the flash (at 0xbfc00000) and run from this
> address the bootloader always hangs at 0xbfc0054c (romExcHandle in start.S).
> I can debug the code via BDI2000 and therefore I see that the code fails at
> the begining of board_init_f function where the rellocation to RAM is
> performed.

It seems relocated data corrupted. What version of U-Boot do you use?
This relocation problem was an outstanding bug, but fixed in 1.3.0.
Please try >1.3.0. Quick workarounds also available. See ML archives.

> I have some troubles also with remote debugging via gdb. I always receive
> the SIGABRT when the debug pointer reaches the first instruction in start.S.
> 
> # ${CROSS_COMPILE}gdb /var/tmp/builds/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=mips-linux".
> The target architecture is set automatically (currently mips)
> ..
> (gdb) set endian little
> The target is assumed to be little endian
> (gdb) target remote bdi2000:2001
> Remote debugging using bdi2000:2001
> _start () at start.S:41
> 41              RVECENT(reset,0)        /* U-boot entry point */
> Current language:  auto; currently asm
> (gdb) stepi
> 
> Program received signal SIGABRT, Aborted.
> reset () at start.S:211
> 211             mtc0    zero, CP0_WATCHLO
> 
> I can set breakpoint however it is not reached although it is set in the
> code before the function board_init_f. I can see the message on the BDI2000
> telnet session window: 
> *** TARGET: all hardware breakpoints in use
> I tried to clear all breakpoints after each program stop but it didn't help. 

I'm not familiar with gdb very much, but it seems gdb could not re-
write ROM. This indicates gdb was going to use software breakpoint.
Please note what you/we are going to debug, is ROM code, not RAM.
Please use hardware breakpoint, instead.


  Shinya