Hi all!
On Wednesday 17 February 2010 00:10:43 David Brownell wrote:
> On Tuesday 16 February 2010, Øyvind Harboe wrote:
...
> But rather complicated, compared with using real flush
> ops (not via scanchain 15).
>
Sure, I will the "execute one instruction" method today!
Regards
Marc
__
On Wed, Feb 17, 2010 at 12:10 AM, David Brownell wrote:
> On Tuesday 16 February 2010, Øyvind Harboe wrote:
>> >
>> > Another option of course is to
>> >
>> > - first invalidate the line(s) you'll be writing
>>
>> This will break things as the cache line can already
>> contain stuff should
On Tuesday 16 February 2010, Øyvind Harboe wrote:
> >
> > Another option of course is to
> >
> > - first invalidate the line(s) you'll be writing
>
> This will break things as the cache line can already
> contain stuff should be flushed, i.e. that you need to
> modify *part* of the cache li
On Tue, Feb 16, 2010 at 11:31 PM, David Brownell wrote:
> On Tuesday 16 February 2010, Marc Pignat wrote:
>> If I understand the arm920t TRM well, there is no way to flush something
>> using
>> the JTAG interface (only invalidate),so support for data cache in write back
>> mode will be difficult.
On Tuesday 16 February 2010, Marc Pignat wrote:
> If I understand the arm920t TRM well, there is no way to flush something using
> the JTAG interface (only invalidate),so support for data cache in write back
> mode will be difficult.
Not using scanchain 15 operations, no.
But I don't think there'
On Tuesday 16 February 2010, Øyvind Harboe wrote:
> > Is there somewhere in the code an example of executing code on the target?
>
> Of course to execute code on the target, you would need to flush the
> code written
> to memory first...
There's also "execute single instruction" code, which ISTR
On Sunday 14 February 2010, David Brownell wrote:
>
> > I will look at this, it seems that interpreted accesses can only be used for
> > a restricted set of MCR/MRC instructions!
>
> Right. That's sort-of-explained in the ARM920t reference manual.
Section 9.6.7 in particular.
> I thought I h
> If I understand the arm920t TRM well, there is no way to flush something using
> the JTAG interface (only invalidate),so support for data cache in write back
> mode will be difficult.
>
> I see some solutions:
> 1) execute the code on the target (clean and invalidate data cache)
> * This solutio
On Tuesday 16 February 2010 13:47:37 Øyvind Harboe wrote:
> I prefer the patch you posted earlier for 0.4.
>
> really I'd like some long term fix that handles the flushing problem, but
> 0.4 is right around the corner...
Sure, I am late with my patches for 0.4.0
This is not really a problem for
> Here is a patch using 'MCR p15,0,Rd,c7,c10,2' (Invalidate data cache using
s/MCR p15,0,Rd,c7,c10,2/MCR p15,0,Rd,c7,c6,1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-developme
I prefer the patch you posted earlier for 0.4.
really I'd like some long term fix that handles the flushing problem, but
0.4 is right around the corner...
What else could we do?
Flush entire cache instead of just one entry?
Surely there is a way to handle this, but I don't know how...
--
Øyvi
On Tuesday 16 February 2010 12:11:42 Øyvind Harboe wrote:
> On Tue, Feb 16, 2010 at 12:06 PM, Marc Pignat wrote:
> > On Tuesday 16 February 2010 11:45:36 Øyvind Harboe wrote:
...
> We're late in the 0.4 release cycle, so we'll have to have the release
> managers approval for that.
What about a mi
On Tue, Feb 16, 2010 at 12:06 PM, Marc Pignat wrote:
> On Tuesday 16 February 2010 11:45:36 Øyvind Harboe wrote:
>> If we can solve that last little bit about also flushing the cache,
>> then I think we
>> should push the change for 0.4.
>
> The write back mode is probably broken even without patc
On Tuesday 16 February 2010 11:45:36 Øyvind Harboe wrote:
> If we can solve that last little bit about also flushing the cache,
> then I think we
> should push the change for 0.4.
The write back mode is probably broken even without patch, so
I think this change should be pushed.
>
> Did you have
If we can solve that last little bit about also flushing the cache,
then I think we
should push the change for 0.4.
Did you have any luck with other cp15 access methods?
arm920t_execute_cp15?
--
Øyvind Harboe
Visit us at Embedded World, March 2nd-4th. IS2T's stand, HALL 10 - 118
http://www.zy
Hi all!
Here is the complete story, just for the record, (or the git log).
The commit f37c9b8d1560d0081e53c71c55113a3c9858011a introduced a bug
in arm920t data cache handling. The command used (Clean and invalidate DCache)
can't be used in interpreted cp15 mode.
This patch fix the problem by Inv
Hi all!
Here is a fix for my problem, at least.
Problem : Clean and Invalidate DCache is not available in cp15 interpreted mode.
workaround : Use the Invalidate only.
The problem still remains for write back data cache, but at least it will work
for write through.
Marc
diff --git a/src/target/
On Sunday 14 February 2010, Marc Pignat wrote:
>
> I will look at this, it seems that interpreted accesses can only be used for
> a restricted set of MCR/MRC instructions!
Right. That's sort-of-explained in the ARM920t reference manual.
I thought I had added comments identifying the relevant ta
On Friday 12 February 2010 16:56:06 Øyvind Harboe wrote:
> > I can't make it work, but if I read well int
> > arm920t_write_cp15_interpreted, we should put
> > the address in value...
> >
> > I mean we use MCR p15,0,r0,... and we put the VMA in r1, so it will be
> > unused?
>
> I don't know and
> I can't make it work, but if I read well int arm920t_write_cp15_interpreted,
> we should put
> the address in value...
>
> I mean we use MCR p15,0,r0,... and we put the VMA in r1, so it will be unused?
I don't know and haven't read up on what arm920t is really doing here.
I don't know
what "int
On Friday 12 February 2010 11:58:02 Øyvind Harboe wrote:
> On Fri, Feb 12, 2010 at 9:29 AM, Marc Pignat wrote:
> > On Friday 12 February 2010 08:59:08 David Brownell wrote:
> >> On Thursday 11 February 2010, Marc Pignat wrote:
> >> > What happens when we flush an address that is not in the data c
On Fri, Feb 12, 2010 at 9:29 AM, Marc Pignat wrote:
> On Friday 12 February 2010 08:59:08 David Brownell wrote:
>> On Thursday 11 February 2010, Marc Pignat wrote:
>> > What happens when we flush an address that is not in the data cache?
>>
>> We obviously *want* it to be a NOP... which is what s
On Friday 12 February 2010 08:59:08 David Brownell wrote:
> On Thursday 11 February 2010, Marc Pignat wrote:
> > What happens when we flush an address that is not in the data cache?
>
> We obviously *want* it to be a NOP... which is what section 2.3.11 of
> the ARM920T spec (mine says ARM DDI 015
On Thursday 11 February 2010, Marc Pignat wrote:
> What happens when we flush an address that is not in the data cache?
We obviously *want* it to be a NOP... which is what section 2.3.11 of
the ARM920T spec (mine says ARM DDI 0151B) seems to imply. Table 2-15:
Clean and Invalidate D entry usin
> About the data cache flush, I'm pretty sure this instruction is not in the
> data
> cache. What happens when we flush an address that is not in the data cache?
I don't know.
Here are some experiments you could run:
1. Use telnet only(no gdb)
2. reset init
3. Modify some ram address to have
On Friday 12 February 2010 08:24:01 you wrote:
> On Fri, Feb 12, 2010 at 8:23 AM, Marc Pignat wrote:
> > On Thursday 11 February 2010 17:30:42 you wrote:
> >> >> If it works it fixes a bug as well as adds a new feature.
> >> >
> >> > Error: arm920_virt2phys: not implemented
> >> >
> >> >
> >> > I
On Fri, Feb 12, 2010 at 8:23 AM, Marc Pignat wrote:
> On Thursday 11 February 2010 17:30:42 you wrote:
>> >> If it works it fixes a bug as well as adds a new feature.
>> >
>> > Error: arm920_virt2phys: not implemented
>> >
>> >
>> > I tried to copy virtphys from 926ejs, the debugged software still
On Thursday 11 February 2010 17:30:42 you wrote:
> >> If it works it fixes a bug as well as adds a new feature.
> >
> > Error: arm920_virt2phys: not implemented
> >
> >
> > I tried to copy virtphys from 926ejs, the debugged software still crashes.
>
> Could you provide a patch for a tested virtphy
> I don't know if this info is useful, but when disabling the data cache flush,
> the
> debugged software does not crash!
That would indicate that the flushing code is broken and that it happens to
work without it. However, we must flush so the Q is how to write that code
correctly
--
Øyvin
>> If it works it fixes a bug as well as adds a new feature.
>
> Error: arm920_virt2phys: not implemented
>
>
> I tried to copy virtphys from 926ejs, the debugged software still crashes.
Could you provide a patch for a tested virtphys implementation for arm920?
That would be a step in the right d
On Thursday 11 February 2010 15:47:24 Øyvind Harboe wrote:
> On Thu, Feb 11, 2010 at 3:37 PM, Marc Pignat wrote:
> > On Thursday 11 February 2010 15:10:12 Øyvind Harboe wrote:
> >> Backing out that change, will break non-MMU execution. Baaad
> >>
> >> I tried to copy & paste the solution from
On Thu, Feb 11, 2010 at 3:37 PM, Marc Pignat wrote:
> On Thursday 11 February 2010 15:10:12 Øyvind Harboe wrote:
>> Backing out that change, will break non-MMU execution. Baaad
>>
>> I tried to copy & paste the solution from 926ejs which also supports
>> writing breakpoints to memory marked as
On Thursday 11 February 2010 15:10:12 Øyvind Harboe wrote:
> Backing out that change, will break non-MMU execution. Baaad
>
> I tried to copy & paste the solution from 926ejs which also supports
> writing breakpoints to memory marked as read only by the MMU.
> Bonus!
>
> I don't have hardware
Backing out that change, will break non-MMU execution. Baaad
I tried to copy & paste the solution from 926ejs which also supports
writing breakpoints to memory marked as read only by the MMU.
Bonus!
I don't have hardware to test on.
If it works it fixes a bug as well as adds a new feature.
(once more, forgotten to cc the list)
Hi!
Ok I used git bisect for my first time and it seems that I have found something!
I haven't looked at the code yet, but the log seems very promising!
Here is what I've found:
f37c9b8d1560d0081e53c71c55113a3c9858011a is the first bad commit
commit f37c9b
35 matches
Mail list logo
