Hi, all

This issue seemed to be relative to cache. When I disable the I cache, 
gdb runs very ok, the command 's' 'n' and 'c' do their work exactly.

The breakpoint instruction "0xe1200070" write to the memory when I set 
the breakpoint. When the breakpoint is triggered, breakpoint instruction 
"0xe1200070" need to replace by the original instruction by writing 
memory. The bug maybe exist in writing memory without invalidate the I 
cache.

Openocd did not support arm946es, so I set the target to arm966e at my 
config file. The arm966e did not contain cache, so maybe this is the 
problem.

Does openocd have plan to support arm946es in future? Thanks!

Xiaochen Zhou

Xiaochen Zhou 写道:
> Hi, all
>
> I'm using openocd v0.1.0 + wiggler to debug Marvell 88E6218(ARM946ES).
> Openocd is running in Windows 2000 workstation and the remote gdb v6.8
> is running in Fedora core 4.
>
> I set a breakpoint, and when the breakpoint is triggered, the cpu halt
> successfully. When I press 'c', the same breakpoint is triggered again
> except I delete the breakpoint. When I press 's' and 'n', the status is
> same.
>
> The openocd + wiggler is OK for debugging ARM922T, so the hardware is OK.
>
> Below is the gdb console and cfg file.
>
> Thanks for advance,
>
> Xiaochen Zhou
>
> ------------------------------------------------------
> [zhouxiaoc...@fedoradell sdk]$ arm-elf-gdb demo
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
> (gdb) target remote 192.200.200.196:2001
> Remote debugging using 192.200.200.196:2001
> hal_idle_thread_action (count=1686108302)
> at
> /home/zhouxiaochen/br104h/d009/ecos-2.0/packages/hal/arm/arch/v2_0/src/hal_misc.c:225
> 225 }
> (gdb) break os_show_threads
> Breakpoint 1 at 0x1bc14: file os_cmd.c, line 58.
> (gdb) c
> Continuing.
>
> Breakpoint 1, os_show_threads (argc=0, argv=0x0) at os_cmd.c:58
> 58 cyg_handle_t thread = 0;
> (gdb) c
> Continuing.
>
> Breakpoint 1, os_show_threads (argc=0, argv=0x0) at os_cmd.c:58
> 58 cyg_handle_t thread = 0;
> (gdb) c
> Continuing.
>
> Breakpoint 1, os_show_threads (argc=0, argv=0x0) at os_cmd.c:58
> 58 cyg_handle_t thread = 0;
> (gdb) c
> Continuing.
>
> Breakpoint 1, os_show_threads (argc=0, argv=0x0) at os_cmd.c:58
> 58 cyg_handle_t thread = 0;
> (gdb) c
> Continuing.
>
> Breakpoint 1, os_show_threads (argc=0, argv=0x0) at os_cmd.c:58
> 58 cyg_handle_t thread = 0;
> (gdb)
>
> ------------------------------------------------------
> # script for Insilica IS-5114
> # AKA: Atmel AT76C114 - an ARM946 chip
> # ATMEL sold his product line to Insilica...
>
> if { [info exists CHIPNAME] } {
> set _CHIPNAME $CHIPNAME
> } else {
> set _CHIPNAME br104h
> }
>
> if { [info exists ENDIAN] } {
> set _ENDIAN $ENDIAN
> } else {
> # this defaults to a little endian
> set _ENDIAN little
> }
>
> if { [info exists CPUTAPID ] } {
> set _CPUTAPID $CPUTAPID
> } else {
> # force an error till we get a good number
> set _CPUTAPID 0x159463d3
> }
>
> # jtag speed. We need to stick to 16kHz until we've finished reset.
> #jtag_rclk 16
>
> reset_config trst_only
>
> jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x01 -irmask 0xf
>
> #arm946e-s and
> set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
> target create $_TARGETNAME arm966e -endian $_ENDIAN -chain-position
> $_TARGETNAME -variant arm966e
>
> $_TARGETNAME configure -work-area-phys 0xfff80000 -work-area-virt
> 0xfff80000 -work-area-size 0x80000 -work-area-backup 1
>
>
> _______________________________________________
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
>   

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to