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

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

[RadekFisera]

Hi everybody,
I'd like to exploit U-boot as a linux bootloader on the board with Au1550
(128MB RAM, 64MB NOR flash). So I put necessary files in /board/<my_board>
subdir, adjusted Makefile and successfully created binary image in my build
directory. I use crosstooll from ELDK 4.1. I have BDI2000 at disposal also. 

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.
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 suspect that there are some wrong settings in
/include/configs/<my_board>.h . My settings:
#define CFG_SDRAM_BASE		0x80000000
#define	CFG_MONITOR_BASE	TEXT_BASE
#define	CFG_MONITOR_LEN		(192 << 10)
#define CFG_INIT_SP_OFFSET	0x10000000 
#define CFG_FLASH_BASE		0xbc000000 
TEXT_BASE = 0xbfc00000

Thank you in advance
-- 
View this message in context: http://www.nabble.com/Au1550-U-boot-debugging---a-newbie-question-tp15546519p15546519.html
Sent from the Uboot - Users mailing list archive@Nabble.com.

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

[Shinya Kuribayashi]

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

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

[RadekFisera]

I'm using U-boot 1.3.0. The hardware breakpoint option is set in BDI2000
configuration file in target part (initial memory controller registers
settings is also in this file)
[TARGET]
JTAGCLOCK   0      		;use 16 MHz JTAG clock
CPUTYPE     AU1000	        ;AU1000  ;the used target CPU type
ENDIAN      LITTLE              ;target is little endian
STARTUP     RESET
RESET       JTAG		;the reset type (NONE, JTAG, HARD)
BDIMODE     AGENT   	        ;the BDI working mode (LOADONLY | AGENT)
BREAKMODE   HARD          	;SOFT or HARD, HARD uses PPC hardware breakpoints
STEPMODE    JTAG                ;JTAG, HWBP or SWBP
VECTOR      CATCH               ;catch unhandled exceptions

I know that during debugging program in flash only HW breakpoints are
enabled. I tried to set breakpoint in gdb via command "break" and "hbreak"
also. In both case I have observeeed the same behaviour (SIGABRT after stepi
and "*** TARGET: all hardware breakpoints in use " in the telnet session
window). I've tried HWBP option instead of JTAG when chosing the stepmode
for BDI 2000.
 

Shinya Kuribayashi-2 wrote:
> 
> 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
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Au1550-U-boot-debugging---a-newbie-question-tp15546519p15559852.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

[Vlad Lungu]

RadekFisera wrote:
> I'm using U-boot 1.3.0. The hardware breakpoint option is set in BDI2000
> configuration file in target part (initial memory controller registers
> settings is also in this file)
> [TARGET]
> JTAGCLOCK   0      		;use 16 MHz JTAG clock
> CPUTYPE     AU1000	        ;AU1000  ;the used target CPU type
> ENDIAN      LITTLE              ;target is little endian
> STARTUP     RESET
> RESET       JTAG		;the reset type (NONE, JTAG, HARD)
> BDIMODE     AGENT   	        ;the BDI working mode (LOADONLY | AGENT)
> BREAKMODE   HARD          	;SOFT or HARD, HARD uses PPC hardware breakpoints
> STEPMODE    JTAG                ;JTAG, HWBP or SWBP
> VECTOR      CATCH               ;catch unhandled exceptions
>
> I know that during debugging program in flash only HW breakpoints are
> enabled. I tried to set breakpoint in gdb via command "break" and "hbreak"
> also. In both case I have observeeed the same behaviour (SIGABRT after stepi
> and "*** TARGET: all hardware breakpoints in use " in the telnet session
> window). I've tried HWBP option instead of JTAG when chosing the stepmode
> for BDI 2000.
>   
Are you sure you have hardware breakpoints  on that target? And if you 
do, isn't that breakpoint (it's probably only one available)
already used maybe? Check the BDI and Au1000 docs.

Also, maybe you should try commenting VECTOR CATCH. That signal looks 
funny to me.


Vlad

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

[RadekFisera]

I think I've overcome the debugging problem (at least partially). When the
bit in the coprocessor register that enables single stepping is set I can
step instructions in gdb (I'm using DDD GUI). However after each step the
hardware breakpoints have to be cleared by CI (in BDI2000 telnet session). 
But this is very awkward. I'm trying to find another way...


Vlad Lungu wrote:
> 
> RadekFisera wrote:
>> I'm using U-boot 1.3.0. The hardware breakpoint option is set in BDI2000
>> configuration file in target part (initial memory controller registers
>> settings is also in this file)
>> [TARGET]
>> JTAGCLOCK   0      		;use 16 MHz JTAG clock
>> CPUTYPE     AU1000	        ;AU1000  ;the used target CPU type
>> ENDIAN      LITTLE              ;target is little endian
>> STARTUP     RESET
>> RESET       JTAG		;the reset type (NONE, JTAG, HARD)
>> BDIMODE     AGENT   	        ;the BDI working mode (LOADONLY | AGENT)
>> BREAKMODE   HARD          	;SOFT or HARD, HARD uses PPC hardware
>> breakpoints
>> STEPMODE    JTAG                ;JTAG, HWBP or SWBP
>> VECTOR      CATCH               ;catch unhandled exceptions
>>
>> I know that during debugging program in flash only HW breakpoints are
>> enabled. I tried to set breakpoint in gdb via command "break" and
>> "hbreak"
>> also. In both case I have observeeed the same behaviour (SIGABRT after
>> stepi
>> and "*** TARGET: all hardware breakpoints in use " in the telnet session
>> window). I've tried HWBP option instead of JTAG when chosing the stepmode
>> for BDI 2000.
>>   
> Are you sure you have hardware breakpoints  on that target? And if you 
> do, isn't that breakpoint (it's probably only one available)
> already used maybe? Check the BDI and Au1000 docs.
> 
> Also, maybe you should try commenting VECTOR CATCH. That signal looks 
> funny to me.
> 
> 
> Vlad
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Au1550-U-boot-debugging---a-newbie-question-tp15546519p15585816.html
Sent from the Uboot - Users mailing list archive at Nabble.com.