On Mon, Jan 25, 2010 at 4:31 PM, Edgar Grimberg
wrote:
> On Sat, Jan 23, 2010 at 8:01 AM, David Brownell wrote:
>> I fired up GDB against an ARM1136 with current git code and
>> observed the "breakpoints work in Tcl, fail in GDB" problem.
>>
>> So I committed a fix that makes GDB work too, at lea
On Tuesday 26 January 2010, Ethan Eade wrote:
>
> >> This fixes the same problem on our iMX35 (Cogent CSB732).
> >> GDB breakpoints didn't work properly in the previous versions and do
> >> work now.
> >>
> >
> > Thanks for the confirmation!
> >
> > When you say "in the previous versions" .
On Tuesday 26 January 2010, Edgar Grimberg wrote:
> > Obviously. But did you check the buffer to see if it had the
> > right data?
>
> I'm a bit paranoid because of the deeply embedded programming
> background, where even the obvious might be false :)
Exactly why I checked ... and observed that
>
> Obviously. But did you check the buffer to see if it had the
> right data?
I'm a bit paranoid because of the deeply embedded programming
background, where even the obvious might be false :)
No, I haven't checked the buffer. Do you suspect GDB to have a problem ?
This test is on my to do list
>> This fixes the same problem on our iMX35 (Cogent CSB732).
>> GDB breakpoints didn't work properly in the previous versions and do
>> work now.
>>
>
> Thanks for the confirmation!
>
> When you say "in the previous versions" ... roughly which versions?
>
Breakpoints were working on the
On Tuesday 26 January 2010, Edgar Grimberg wrote:
> Hi David,
>
> > However: did you check the buffer to see if it had the right data?
> > What I saw was the right data in the buffer...
>
> The fail is in this code:
>
> /* MCR p14,0,R0,c0,c5,0 */
> retval = arm11_run
Hi David,
> However: did you check the buffer to see if it had the right data?
> What I saw was the right data in the buffer...
The fail is in this code:
/* MCR p14,0,R0,c0,c5,0 */
retval = arm11_run_instr_data_from_core(arm11, 0xEE000E15, &r0,
1);
David Brownell wrote:
> I fired up GDB against an ARM1136 with current git code and
> observed the "breakpoints work in Tcl, fail in GDB" problem.
>
> So I committed a fix that makes GDB work too, at least on
> an omap2420 core.
>
> It'd be worth verifying this works on other ARM1136 targets.
>
On Monday 25 January 2010, Ethan Eade wrote:
>
> David Brownell wrote:
> > I fired up GDB against an ARM1136 with current git code and
> > observed the "breakpoints work in Tcl, fail in GDB" problem.
> >
> > So I committed a fix that makes GDB work too, at least on
> > an omap2420 core.
> >
> > It
On Monday 25 January 2010, Edgar Grimberg wrote:
>
> Now I'm getting some other type of problem on my iMX.31. I try to load:
This is unrelated to breakpoints ... but it resembles what I
saw a few times trying to load code into SRAM. I had thought
it was related to some other patches (non-mainlin
On Sat, Jan 23, 2010 at 8:01 AM, David Brownell wrote:
> I fired up GDB against an ARM1136 with current git code and
> observed the "breakpoints work in Tcl, fail in GDB" problem.
>
> So I committed a fix that makes GDB work too, at least on
> an omap2420 core.
>
> It'd be worth verifying this wor
I fired up GDB against an ARM1136 with current git code and
observed the "breakpoints work in Tcl, fail in GDB" problem.
So I committed a fix that makes GDB work too, at least on
an omap2420 core.
It'd be worth verifying this works on other ARM1136 targets.
- Dave
___
On Friday 22 January 2010, Edgar Grimberg wrote:
> OK, can you provide me with the revision and the range I have to skip
> (parameters for git bisect skip)?
I think it would suffice to just make sure that both
ARM11: partial support for standard ARM register interfaces.
ARM11: rem
On Fri, Jan 22, 2010 at 7:40 AM, David Brownell wrote:
> On Thursday 21 January 2010, Edgar Grimberg wrote:
>> >> and want to see what a bisection that skips known-incomplete stuff
>> >> will turn up.
>>
>> 5eb893ec41c8c6cf6499558b6fed826b65e18a16 is first bad commit
>>
>> Does this make more sens
On Thursday 21 January 2010, Edgar Grimberg wrote:
> >> and want to see what a bisection that skips known-incomplete stuff
> >> will turn up.
>
> 5eb893ec41c8c6cf6499558b6fed826b65e18a16 is first bad commit
> commit 5eb893ec41c8c6cf6499558b6fed826b65e18a16
> Author: David Brownell
> Date: Tue N
>> and want to see what a bisection that skips known-incomplete stuff
>> will turn up.
5eb893ec41c8c6cf6499558b6fed826b65e18a16 is first bad commit
commit 5eb893ec41c8c6cf6499558b6fed826b65e18a16
Author: David Brownell
Date: Tue Nov 24 01:27:16 2009 -0800
ARM11: partial support for standar
> Do you happen to have a theory for how a patch that doesn't touch
> breakpoint logic would cause breakpoint failures?
Nope, it was a brain dead bisect done after hours. Close to the end of
the bisect there were some other error messages and I marked those
bisects as bad. How should I do this to
On Wednesday 20 January 2010, Edgar Grimberg wrote:
> $ git bisect bad
> 5eb893ec41c8c6cf6499558b6fed826b65e18a16 is first bad commit
> commit 5eb893ec41c8c6cf6499558b6fed826b65e18a16
> Author: David Brownell
> Date: Tue Nov 24 01:27:16 2009 -0800
>
> ARM11: partial support for standard ARM
On Wed, Jan 20, 2010 at 2:57 PM, Edgar Grimberg
wrote:
> I suspect there is a problem with ARM11 debugging for version
> v0.4.0-rc1-128-g0c3a4b4. It seems I cannot insert breakpoints:
I've done a git bisect:
$ git bisect log
git bisect start
# good: [70f735007d7b0f7ec9d269c4529d9f62c0eb779d] Th
I suspect there is a problem with ARM11 debugging for version
v0.4.0-rc1-128-g0c3a4b4. It seems I cannot insert breakpoints:
Here I single step, to prove that I can reach the address I want to
set the breakpoint at:
(gdb) moni reset init
JTAG tap: imx31.etb tap/device found: 0x2b900f0f (mfg: 0x7
20 matches
Mail list logo
