[U-Boot-Users] Au1550 U-boot debugging - a newbie question
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
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
participants (3)
-
RadekFisera -
Shinya Kuribayashi -
Vlad Lungu