Hi Andreas,
I lot of things to report.
1. I have to use thumb because the kernel has assembly parts that seems to
be in thumb, when I tried to force arm only it doesn't work. What I am
saying is that compile the kernel as non-thumb or pure arm doesn't solve
the problem.
2. I was checking the routine cortex_a8_read_phys_memory() and
cortex_a8_write_phys_memory() routines and did a change to handle size 3
breakpoints like size 4. This is because the breakpoints kind 4 and 3 are
both 32 bits.
The first single step works fine and seems to be type 4, the next one is
type 3, I have no error but gdb doesn't come back to the prompt. The change
I am doing is very simple and I am probably naive, thinking that such kind
of change can fix the problem.
I have a tiny standalone code arm that works fine with software
breakpoints. I will recompile to run as thumb to have a better understand
about thumb-2 breakpoints.
Anything that come to your mind to help me is welcome.
--- src/target/cortex_a.c.org 2012-10-17 13:39:36.271316635 -0500
+++ src/target/cortex_a.c 2012-10-17 13:40:47.703318864 -0500
@@ -1946,6 +1946,7 @@
switch (size) {
case 4:
+ case 3:
retval =
mem_ap_sel_read_buf_u32(swjdp, swjdp_memoryap,
buffer, 4 * count, address);
break;
@@ -2034,6 +2035,7 @@
switch (size) {
case 4:
+ case 3:
retval =
mem_ap_sel_write_buf_u32(swjdp, swjdp_memoryap,
buffer, 4 * count, address);
break;
On Tue, Oct 16, 2012 at 7:34 PM, Jorge Ventura <
[email protected]> wrote:
> In the meantime I found out at the same site you sent me that there is a
> directive for gdb not use breakpoints type thumb.
>
> http://sourceware.org/gdb/onlinedocs/gdb/ARM.html
>
> *set arm force-mode arm*
>
> I'm going to test that tomorrow. If that works, it's all need.
>
>
>
>
> On Tue, Oct 16, 2012 at 7:20 PM, Jorge Ventura <
> [email protected]> wrote:
>
>> Ok. I guess that the problem after MMU enabled is the same.
>> While I wait for someone with a fix, I will read the link you sent me and
>> try to figure out if I can do some kind of bubble gum.
>> I'll keep you posted.
>>
>> Thank you.
>>
>>
>> On Tue, Oct 16, 2012 at 6:36 PM, Andreas Fritiofson <
>> [email protected]> wrote:
>>
>>> On Tue, Oct 16, 2012 at 11:11 PM, Jorge Ventura
>>> <[email protected]> wrote:
>>> > I did a single step at first instruction (0x80008000) but not the next
>>> and
>>> > you will see that it seems to be because size=3.
>>> > I removed all arm thumb information from the kernel configuration for
>>> not
>>> > have mixed instructions.
>>> >
>>> > Make any sense for you gdb request read physical memory with size = 3
>>> ???
>>> > Maybe the problem is not openocd but gdb !!!
>>>
>>> GDB sends the packet 'Z0,80008008,3', where 3 is the breakpoint
>>> "kind". Which is normally the length of the breakpoint. However, that
>>> is architecture-defined and according to
>>>
>>> http://sourceware.org/gdb/onlinedocs/gdb/ARM-Breakpoint-Kinds.html#ARM-Breakpoint-Kinds
>>> kind 3 is 32-bit Thumb-2 bp for ARM.
>>>
>>> I don't know if it makes sense or not for GDB to set a T2 bp in your
>>> case but OpenOCD doesn't handle kind 3 so that's wrong anyway. We
>>> erroneously refer to the parameter as "length" everywhere, and use it
>>> as such in the Cortex-A target.
>>>
>>> We need to fix that in cortex_a8_set_breakpoint() and
>>> cortex_a8_unset_breakpoint(). Patch welcome. I can probably come up
>>> with a reasonable fix, but it would be even better if someone with
>>> hardware to test it and better knowledge of armv7-a could do it.
>>>
>>> /Andreas
>>>
>>> > Debug: 1365 187001 gdb_server.c:2048 gdb_input_inner(): received
>>> packet:
>>> > 'Z0,80008008,3'
>>> > Debug: 1366 187001 gdb_server.c:1394
>>> gdb_breakpoint_watchpoint_packet(): -
>>> > Debug: 1367 187001 cortex_a.c:1986 cortex_a8_read_memory(): Reading
>>> memory
>>> > at address 0x80008008; size 3; count 1
>>> > Debug: 1368 187001 cortex_a.c:1939 cortex_a8_read_phys_memory():
>>> Reading
>>> > memory at real address 0x80008008; size 3; count 1
>>> > Error: 1369 187001 cortex_a.c:1408 cortex_a8_set_breakpoint(): Error @
>>> > cortex_a8 read_memory:-601
>>> > Error: 1370 187001 breakpoints.c:96 breakpoint_add_internal(): can't
>>> add
>>> > breakpoint: unknown reason
>>>
>>
>>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
