David Brownell wrote:
> Use the new "reset-assert" event; else SRST; else fail.
> Tested on an OMAP3, using the event.
>
> NOTE: still doesn't handle "reset halt". For some reason
> neither VCR nor PRCR seemed effective; they held the value
> that was written, but VCR didn't trigger debug entry w
As usual, I vote for not retiring old versions to quickly.
/M
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
> Thanks for commenting on actual mrc/mcr stuff :-)
>
> I can't really comment on whether read_cp/write_cp would be better,
> I trust you on that one. It should be a trivial modification to the
> command or interface once we have something common across
> the implementations to build on.
>
>> The n
2009-10-21 13:12, Øyvind Harboe skrev:
Testing and comments much appreciated!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios
2009-10-25 12:31, Øyvind Harboe skrev:
> You make excellent general points in your post and I agree
> to what you are saying, however here I'm discussing mrc/mcr
> specifically and how to proceed with that one.
>
> Did you read up on mrc/mcr in targets and consider
> the current patches& changes i
Øyvind Harboe wrote:
> On Wed, Oct 21, 2009 at 6:43 PM, David Brownell wrote:
>
>> On Wednesday 21 October 2009, Řyvind Harboe wrote:
>>
>>> Once these changes and discussion has had some time to settle,
>>> it would make sense to retire all the mXX_phys commands and let
>>> the target.c i
Øyvind Harboe wrote:
> Would anybody object strongly to making target_write_memory()
> temporarily disable MMU read-only bits?
>
> This would be e.g. to enable setting breakpoints in memory
> the MMU has mapped as read-only.
>
> If someone has tips or ideas on how to implement this, I would
> great
Øyvind Harboe wrote:
> There is an autoerase option to flash write_image.
>
> Would you object strongly to autoerase automatically
> unlocking the flash if necessary?
>
>
>
On some targets the write with autoerase is very slow. A sector erase or
full erase followed by write is much faster.
IM
Øyvind Harboe wrote:
> What's the most reasonable way to refer to a git version
> for human beings?
>
> In svn it's a small integer("only" in the thousands).
>
> I was thinking about something like "0.2 + N versions".
>
>
Actually you can checkout things like
$ git checkout master~2 Makefile
S
Magnus Lundin wrote:
> Øyvind Harboe wrote:
>
>> On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin wrote:
>>
>>
>>> Yauheni Kaliuta wrote:
>>>
>>>
>>>> Hi, Magnus!
>>>
Øyvind Harboe wrote:
> On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin wrote:
>
>> Yauheni Kaliuta wrote:
>>
>>> Hi, Magnus!
>>>
>>>
>>>
>>>>>>>> "ML" == Magnus Lundin writes:
>>>>&g
Yauheni Kaliuta wrote:
> Hi, Magnus!
>
>
>>>>>> "ML" == Magnus Lundin writes:
>>>>>>
>
> [...]
>
> > > I have a simple "works for me" implementation of memory access with
> > > cpu
Yauheni Kaliuta wrote:
> Hi!
>
> On Thu, Oct 1, 2009 at 9:41 PM, Magnus Lundin <mailto:lun...@mlu.mine.nu>> wrote:
>
> Any ideas how OpenOCD should handle virtual addressing and cache
> coherency?
>
>
> [..]
>
>
> I am planning to imp
Yauheni Kaliuta wrote:
> Hi!
>
> On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin wrote:
>
>> Without looking deeply (lot of other work the coming weeks) I think this
>> is good, but I would like it in a separate file(module). Called
>> adiv5_component, adiv
Without looking deeply (lot of other work the coming weeks) I think this
is good, but I would like it in a separate file(module). Called
adiv5_component, adiv5_debug or coresight_component ??
So the adiv5 code talks to the MEMAP registers but does not handle the
memory mapped components that are a
Please add me to the OpenOCD Sourceforge git, loginid: mlusf
Best regards
Magnus
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
My impression, after using git just a little, is that it is a good tool,
it takes some learning for effective use.
For development work it seems that it gives me much better support for
testing several different versions of experimental code than SVN so here
it is a big step forward.
I do not k
Very good comments from Dave, I will think about them, do some testing
on vector catch and the state after reset.
For now I have commited but the omap3_reset function is removed, since
this is handled by "reset halt"
Regards,
Magnus
___
Openocd-develo
Any ideas how OpenOCD should handle virtual addressing and cache coherency?
Using the DAP MEMAP found on ARMv7 processors mean that we can write
directly to memory mapped resources like RAM, FLASH, system control
registers, debug registers and I/O control registers.
This access can be done in in
For testing and comments
This patch adds :
int cortex_a8_assert_reset(target_t *target);
int cortex_a8_deassert_reset(target_t *target);
Full testing is hard to do with the BeagleBoard since there are
no SRST or TRST, but this brings reset handling closer to standard
OpenOCD (as confusing as
David Brownell wrote:
> I think that's not quite following the model which the code in
> the src/helper/startup.tcl file is expecting ... a closer match
> would use reset-assert-pre (or maybe "post") not reset-start.
>
I have done some more testing and trying to understand the reset
handling in
We can, and sometimes we want to, write to memory while the CortexA8
core is running,
but for gbd to load a program and the i-caches to be cleared to core
must be halted.
So I think there must be a monitor halt after the monitor omap3_dbginit
>
> No. I just do
>
> > arm-none-linux-gnueabi-gdb
David Brownell wrote:
> On Tuesday 29 September 2009, Magnus Lundin wrote:
>
>> +omap3.cpu configure -event reset-start "omap3.cpu mww $PRM_RSTCTRL 2"
>> +omap3.cpu configure -event reset-end "omap3_dbginit"
>>
>
> Isn't there a chic
>>>
>> At the end of the reset handling we reinitialise the tap and the
>> debug interface with omap3_dbginit
>> omap3_reset is really reset+reinit+halt and you call it if you want
>> to debug the loading of u-boot by the X-Loader
>
> Do you mean omap3_reset should be called 'manually' if nee
Well, some days our work is a bit more confused then other days.
Dirk Behme wrote:
Magnus Lundin wrote:
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Something is wrong with the patch in attachment? It
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Best regards,
Magnus
===
.
.
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
Dirk Behme wrote:
> David Brownell wrote:
>
>> Update the DaVinci target configs so they have JTAG post-reset
>> event handlers which:
>>
>> - run the 100 JTAG clocks ICEpick wants
>> - ensure the ARM (and ETB) taps are enabled
>> ---
>> The OMAP3 post-reset handlers should probably do somethi
Magnus Lundin wrote:
For comments and testing:
Add actual code to the previously empty :
cortex_a8_init_debug_access()
Remove details of common cortex8a debug initalisations from
omap3_dbginit and replace with call to externally eposed
"cortex_a8 dbginit" function.
Be
Øyvind Harboe wrote:
> Thank you for a *much* better analysis of the problem.
>
> (I checked a few sites and you missed a case where cfi.c is broken
> if you remove the warning, i.e. no error/warning is logged if you
> run out of working area, but otherwise a very productive post)
>
>
>> I'm sti
For comments and testing:
Add actual code to the previously empty :
cortex_a8_init_debug_access()
Remove details of common cortex8a debug initalisations from
omap3_dbginit and replace with call to externally eposed
"cortex_a8 dbginit" function.
Best regards,
Magnus
michal smulski wrote:
> Here is a patch against r2715 that makes the arm11 memwrite burst work
> again with Olimex JTAG.
>
> As far I can see in the code, the original ft2232_add_pathmove()
> function was split into two ft2232_add_pathmove & clock_tms(). I think
> that clock_tms() is working ok as
Dirk Behme wrote:
> Magnus Lundin wrote:
>> For comments:
>>
>> This patch changes cortex_a8 to use a variable armv7a->debug_base
>> instead of hardedcoded OMAP3530_DEBUG_BASE .
>> This prepares for looking of debug_base from ROM Table scan (or from
>>
Øyvind Harboe wrote:
> Use the source Luke :-)
>
>
I most certainly do.
But you vere saying that this particular patch breaks the error reporting
in other places. And in my linited knowlege of the source, this is not
the case.
It is like having malloc writing error messages to the console. An
>> The proposed patch does not try to solve the general problem of
>> errorhandling in OpenOCD. It simply wants to change the debug level at
>> which this exception is reported to the user.
>>
>> Whats the problem ??
>
> The attached patch *breaks* error reporting in other places.
>
>
> --
> Ãyvin
>> I think this is OK, it does not change the return value, it is still
>> reported as an error/exception condition, not ERROR_OK. So for the
>> codebase nothing is changed. In the calling functions we do fall back to
>> smaller buffers or alternative implementations. So the error warning
>> should
> Hi,
>
> This turns a warning into a debug message. It is printed if there is not
> as much working area as requested. Many callers try iteratively until a
> working area of suitable size is found. The current warnings are
> irritating.
>
> It should be up to the caller to decide if this is worth
For comments:
This patch changes cortex_a8 to use a variable armv7a->debug_base
instead of hardedcoded OMAP3530_DEBUG_BASE .
This prepares for looking of debug_base from ROM Table scan (or from
config file)
At the moment no known functional changes.
Best regards,
Magnus
__
For comments:
This patch changes cortex_a8 to use a variable armv7a->debug_base
instead of hardedcoded OMAP3530_DEBUG_BASE .
This prepares for looking of debug_base from ROM Table scan (or from
config file)
At the moment no known functional changes.
Best regards,
Magnus
_
Øyvind Harboe wrote:
> On Tue, Sep 15, 2009 at 6:18 AM, michal smulski
> wrote:
>
>> I noticed that something was not right with my svn repo after doing
>> various up-rev's and down-rev's and decided to start fresh.
>>
>> It turns out that last 'memwrite burst' working is actually rev 1824 an
Magnus Lundin wrote:
> For testing and comments.
>
> Best regards,
> Magnus
>
>
>
> ___
> Openocd-development mailing list
> Openocd-develo
For testing and comments.
Best regards,
Magnus
Index: src/target/cortex_a8.c
===
--- src/target/cortex_a8.c (revision 2701)
+++ src/target/cortex_a8.c (working copy)
@@ -1253,6 +1253,24 @@
exit(-1);
}
+ /* The Cache handling
More CortexA8 debug register definitions.
Commited.
Index: src/target/cortex_a8.h
===
--- src/target/cortex_a8.h (revision 2700)
+++ src/target/cortex_a8.h (working copy)
@@ -43,6 +43,7 @@
#define CPUDBG_DIDR 0x000
#define CPUD
The arguments was not passed to the MCR instruction in cortex_a8_write_cp.
Commited.
Best regards,
Magnus
Index: src/target/cortex_a8.c
===
--- src/target/cortex_a8.c (revision 2700)
+++ src/target/cortex_a8.c (working copy)
@@ -22
No furter comments received. Commited.
Best regards,
Magnus
Magnus Lundin wrote:
> Here are two very small patches.
>
> The first one fixes the reporting of instruction state.
>
> The second one makes sure the processor stays in Thumb state when
> restoring the PC.
&g
Here are two very small patches.
The first one fixes the reporting of instruction state.
The second one makes sure the processor stays in Thumb state when
restoring the PC.
After this it is possible to single step Thumb code.
Best regards,
Magnus
Index: src/target/armv7a.c
==
Øyvind Harboe wrote:
> The only way we get a decent amount of regression testing is
> to commit.
>
> If you are reasonably confident about that this is the right direction
> and there appears to be no regressions, then it should be
> committed for testing.
>
>
>
Commited
__
Hello,
If there are no known regressions then perhaps this patch should be
commited ?
http://lists.berlios.de/pipermail/openocd-development/2009-September/010335.html
There are more thumb handling stuff to be fixed so I think this should
go first.
Regards,
Magnus
Hello list.
For those of you who has not yet had the time to read all the TRM's
covering Cortex-A8 and ARM ADIv5, I have started to write up an easy
introduction to the debug components in a Cortex-A8 system.
This is not intended to replace the TRM's but to help the casual reader
gain an under
2009-09-05 21:40, Michael Schwingen skrev:
> Dave Webb wrote:
>
>> Hi all!
>>
>> I came along a (very) small problem when compiling a freshly
>> checked out openocd.
>>
>> I used:
>> # svn checkout svn://svn.berlios.de/openocd/trunk
>> # ./bootstrap
>> # ./configure --enable-parport
>> # make
>
Øyvind Harboe wrote:
> On Fri, Sep 4, 2009 at 10:30 AM, David Brownell wrote:
>
>> On Friday 04 September 2009, Matt Hsu wrote:
>>
>>> retval = mem_ap_write_atomic_u32(swjdp,
>>> OMAP3530_DEBUG_BASE + CPUDBG_DRCR, 0x1);
>>>
>> Why are you still discard
Matt Hsu wrote:
> Hi Øyvind,
>
> This is a resend patch.
> It only improves the description as Magnus suggested.
>
> Cheers,
> Matt
>
Looks good.
Magnus
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/m
Matt Hsu wrote:
>
>>>
>>>
>> Hi Matt,
>>
>> It makes me very happy to se active work with this code.
>Hi Magnus,
>
>It's all based on you guys great work. :)
>I'm just standing on the shoulders of giants. (stealing from
> Holger's blog:
> http://zecke.blogspot.com/2009/08/standing-
Dirk Behme wrote:
> Hi Magnus!
>
> Magnus Lundin wrote:
>> Hello all Cortex_A8 fans !
>>
>> Please test the following patch that hopefully corrects some insane
>> errors in Thumb state handling.
>> (Yes I wrote it myself, but it seems UBoot for BeagleBoard d
Alain Mouette wrote:
> Hi, I just changed my Cortex-M3 from LS3S6965 to ML3S6611 and it stopped
> working :(
>
> When I start openocd (0.2, Linux, FTD2232) I get:
> Open On-Chip Debugger 0.2.0 (2009-07-15-14:00) Release
> [...]
> 500 kHz
> jtag_nsrst_delay: 100
> jtag_ntrst_delay: 100
> Info : dev
Hello all Cortex_A8 fans !
Please test the following patch that hopefully corrects some insane
errors in Thumb state handling.
(Yes I wrote it myself, but it seems UBoot for BeagleBoard does not use
Thumb Mode)
Best regards
Magnus
Index: src/target/cortex_a8.c
===
Matt Hsu wrote:
> Hi all,
>
> This series patches fix the hardware single-step logic mainly.
> With these patches, you can do the step operation on the telnet session.
> Also, the programming breakpoints works as well.
> Cheers,
> Matt
> -
Matt Hsu wrote:
>
>> So in the OMAP initialisation script we have the line
>>
>> # set DBGEN signal
>>mww 0x5401d030 0x2000
>>
> Hi Magnus,
>
>It seems that the debug address space is remapped from 0xD401
> to 0x5401.
>But I could not find out any sections menti
Harald Welte wrote:
> Hi Magnus,
>
> On Mon, Aug 31, 2009 at 05:36:11PM +0200, Magnus Lundin wrote:
>
>
>>> dap_ap_select(swjdp, 1);
>>> before the two lines
>>> dap_ap_read_reg_u32(swjdp, 0xFC, &idreg);
>>>
>> 3) One feature that I think may make sense to add at some point in the
>> future to the main software is support for label/value associations that
>> allow hexadecimal register values to be associated with more legible and
>> understandable names. Looking at "mww 0x3ec2 0x2" in a configura
Beautiful work.
Harald Welte wrote:
> Hi All!
>
> Throughout the last week or so, I've been trying to get OpenOCD to work
> on a new (not public yet) Cortex-A8 based SoC. Right now I feel a bit
> stuck, despite having read the CoreSight docs from ARM as well as the
> Cortex-A8 reference manual ch
Hello list.
Maybe this is my fault that I have not paid enogh attention to some of
the style discussions.
But I have stopped to regularily print out code before working on it,
and my screen can easily support 1000-1200 pixel wide edit windows.
That is 120-140 characters before line wrapping.
S
Sorry for double responses but it is getting late and my brain is going
to sleep on its own.
>
Holger Freyther wrote:
>
> I sincerely disagree here. These bits directly come out of the Cortex A8
> Technical Reference Manual and not following them is not making things fast
> but it makes them
Holger Freyther wrote:
> On Friday 28 August 2009 19:28:50 Magnus Lundin wrote:
>
>
>> The usual way for OpenOCD targets to check if a PROCESSOR_HALTED flag
>> has been set is not to do it in the halt command but rather in the poll
>> command.
>> This in genera
Holger Freyther wrote:
> Hey,
>
> today Matt Hsu and me sat together to look into why OpenOCD does not work on
> the beagle board. We have found and fixed some issues with the code, it
> should
> make it more robust and we have fixed the root cause for us.
>
> cortex_a8_dap_read_coreregister_u32
Holger Freyther wrote:
> On Thursday 27 August 2009 16:43:34 Dirk Behme wrote:
>
>> Holger Freyther wrote:
>>
>
>
>>> Okay, turns out that I'm not able to omap3_dbginit scan once the linux
>>> kernel is running and when linux is starts the "poll" will start to fail.
>>> Does this sound f
Freddie Chopin wrote:
> Rohit Chandel pisze:
>
>> Is there any quick test to find out that openocd is installed correctly?
>>
>
> use it.
>
>
That is funny, and true.
But the OpenOcd application is almost always installed correctly and
from a users point of view there are lots of thing
David Brownell wrote:
> On Tuesday 25 August 2009, Matt Hsu wrote:
>
>> The problem is I would like to issue commands such as reset halt,
>> bp, resume. The source code shown their implementation are NULL.
>>
>> So I'm curious why coretex_a8 does not have these support?
>>
>
> Because nob
>
>> On Wednesday 15 July 2009, Øyvind Harboe wrote:
>> > I've made an attempt at bringing Magnus Cortex A8 work up
>> to SVN HEAD.
>> >
>> > It builds and I hope I resolved the few conflicts correctly. Not
>> > tested on Cortex M3 or A8.
>>
>> This splits the remaining work in two parts. It needs
> On Wed, 2009-07-15 at 09:30 -0700, David Brownell wrote:
>> On Wednesday 15 July 2009, Øyvind Harboe wrote:
>> > It builds and I hope I resolved the few conflicts correctly. Not
>> > tested on Cortex M3 or A8.
>>
>> Hmm, could you maybe split this into two patches, more like what
>> Magnus did?
> Should I commit it if there are no regressions?
>
> --
> Ãyvind Harboe
> Embedded software and hardware consulting services
> http://www.zylin.com
>
If Cortex-M3 is not not broken then I think it should be commited.
Regards
Magnus
___
Openocd-devel
> I've made an attempt at bringing Magnus Cortex A8 work up to SVN HEAD.
>
> It builds and I hope I resolved the few conflicts correctly. Not
> tested on Cortex
> M3 or A8.
>
> I believe the best thing would be to commit his work in progress and then
> hopefully Magnus and others can tinker with A8
Thc cortex_m3_poll function does not identify that a target is running
unless we transition from RESET.
This patch correctly identifies a running target.
Regards
Magnus
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c
Sergey Lapin skrev:
> On Mon, Jul 6, 2009 at 7:43 PM, Magnus Lundin wrote:
>
>> Wookey skrev:
>>
>>> +++ Sergey Lapin [2009-07-06 19:02 +0400]:
>>>
>>>
>>>> Hi, all!
>>>>
>>>> Is there any news rega
Wookey skrev:
> +++ Sergey Lapin [2009-07-06 19:02 +0400]:
>
>> Hi, all!
>>
>> Is there any news regarding support of BeagleBoard in OpenOCD?
>> Last time I checked, there was none, I'm interested to help, so I
>> want to know the status and what can I do.
>>
>
> There is a config file for
Simple project for a CS student.
A wrapper with a libftdi interface calling libftd2xx, as a project using
a LGPL license
So any user can take their binary copy of OpenOCD linked against libftdi
and simply replace the libftdi dll file, no need to play with system
files or drivers.
Is such a
David Brownell wrote:
> On Tuesday 23 June 2009, Magnus Lundin wrote:
>
>> The protocol to talk to MPSSE is well known/open (they do praise
>> developers of open alternatives on thier web site) ,
>>
>
> Though for the record ... the "bitbang" prot
Thomas A. Moulton wrote:
> On Tue, 2009-06-23 at 15:33 -0700, Rick Altherr wrote:
>
>
>> The community as a whole can easily decide to remove your code,
>> replace it, and relicense. The community can also choose to follow an
>> alternate interpretation of the license that you may not agree
Photo Leecher wrote:
> Where does it say that you cannot revoke an exception in a new
> version/revision?
> That doesn't make sense???
>
Sure
But it only applies to new code since last release when other rights
were granted.
This is NOT a GPL problem, it applies anytime you give somebody a time
Photo Leecher wrote:
> Oh really?
> So one can no longer remove code that uses FTDI2xx in a newer
> revision/version and remove it from the license?
> You should get yourself a lawyer... That will be the day when one is
> not allowed to DELETE CODE.
>
Cool it crazy wont build support.
The
David Brownell wrote:
> On Tuesday 23 June 2009, Magnus Lundin wrote:
>
>> Zach does not speak for me. As far as I can see he and David are
>> actively against any exception, I am not!!!
>>
>
> I'm not against adding such an exception for the FTD2XX cod
Øyvind Harboe wrote:
> On Tue, Jun 23, 2009 at 11:38 PM, Magnus Lundin wrote:
>
>> Ųyvind Harboe wrote:
>>
>>> Could you explain a bit about your thoughts on closed source
>>> target and interface drivers together with OpenOCD?
>>>
>>>
Øyvind Harboe wrote:
> Could you explain a bit about your thoughts on closed source
> target and interface drivers together with OpenOCD?
>
> I can imagine that a lot of CPU vendors would love the ability
> to provide a closed source plugin that talks to their CPU.
>
> Similarly I believe that ther
John Devereux wrote:
> Anders Montonen writes:
>
>
>> On Jun 23, 2009, at 21:20, Freddie Chopin wrote:
>>
>>> Anders Montonen pisze:
>>>
Right, but section four says "You may not copy, modify, sublicense,
*or*
distribute the Program" (emphasis added). If it just con
Zach Welch wrote:
> On Tue, 2009-06-23 at 20:20 +0200, Freddie Chopin wrote:
> [snip]
>
>>> Why do you consider it OK to ignore a license just because it
>>> inconveniences you? Do you hold the same view regarding things you create?
>>>
>> Why do you consider it OK to overinterpret the l
Zach Welch wrote:
> On Sun, 2009-06-21 at 17:38 -0400, Duane Ellis wrote:
>
>> zach> Please DO NOT try to cheat the GPL license. You do not understand how
>> zach> far I am willing to take these matters, and I believe any form of
>> binary
>> zach> distribution to be a violation: a DLL wrapper,
Øyvind Harboe wrote:
> Q: should dr/irscan throw an error if polling is enabled?
>
> OpenOCD does background polling based on a timer, so
> two consecutive ir/drscan commands could see other
> JTAG operations intervening, wreaking havoc.
>
> Targets such as the OMAP needs to run a sequence
> of jta
Øyvind Harboe wrote:
>> Which information do you need to get an idea what the beagle script is
>> expected to do?
>>
>
> I can't dive into the OMAP stuff with the time I have for OpenOCD, so
> I'll await specific feedback. I just know that the endstate command
> was broken in seven different w
Can anybody explain we OpenOCD uses blocks of size 560 for dump_image (
target.c line 2241 ) ??
Regards,
Magnus
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
It won't work, but is is not an error. Return ERROR_OK so other targets
in the chain can be examined.
Reagrds
Magnus
Index: src/target/target.c
===
--- src/target/target.c (revision 2051)
+++ src/target/target.c (working copy)
@@
Regards
Magnus
Index: src/target/target.c
===
--- src/target/target.c (revision 2051)
+++ src/target/target.c (working copy)
@@ -1945,9 +1965,9 @@
const char *value_fmt;
switch (size) {
- case 4: value_fmt = "%8.8x"; break;
- c
Zach Welch wrote:
On Thu, 2009-06-04 at 12:49 +0200, Magnus Lundin wrote:
Hi
The number of bits used for TAR autoincrement when using
CSW_ADDRINC_PACKED must be at least 10 according to ARM ADI
specifications. Cortex-M3 uses 12 bits (4k blocks) and OMAP35xx uses 10
bits (1k blocks
Hi
The number of bits used for TAR autoincrement when using
CSW_ADDRINC_PACKED must be at least 10 according to ARM ADI
specifications. Cortex-M3 uses 12 bits (4k blocks) and OMAP35xx uses 10
bits (1k blocks).
This patch adds support for different TAR autotincrement sizes and sets
it to 12
Gene Smith wrote:
Magnus Lundin wrote:
Here is a patch that helps against the well known OVERRUN errors for
Cortex-M3 ( the problem is even worse for Cortex-A8 )
Basically the patch adds a fixed number ( default 8 ) of extra tck
clocks before every DR scan that accesses the target
Yeah ... things happen, but lets try again :)
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 1977)
+++ src/target/arm_adi_v5.c (working copy)
@@ -59,43 +59,39 @@
*
Here is a patch that helps against the well known OVERRUN errors for
Cortex-M3 ( the problem is even worse for Cortex-A8 )
Basically the patch adds a fixed number ( default 8 ) of extra tck
clocks before every DR scan that accesses the target memory bus through
the DAP_MEMAP.
This makes it po
Gene Smith wrote:
> Gene Smith wrote:
>
>> I am unable to set h/w breakpoints or step in my new cortex-m3
>> (stm3210e-eval board) now using jlink. It was working OK for a while
>> yesterday but now it refuses to do anything. This is with the informal
>> patches we were doing a few weeks ago
Øyvind Harboe wrote:
> - RESET is an illegal end state. It's split out as a separate thing for lots
> of
> reasons, including that this triggers events that listeners are listening
> for, etc.
>
> - irscan should use the drscan code implementation. They are almost identical.
>
> - DRPAUSE makes no
Øyvind Harboe wrote:
> Committed 1980
>
> Moved helper fn from xsvf.c to jtag.c to promote it to a helper fn.
>
> This does *NOT* change any of the lower level parts of the
> JTAG API or drivers, just "shows" how to use the JTAG API.
>
>
> ---
Øyvind Harboe wrote:
> On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin wrote:
>
>> I propose some changes to the jtag subsystem
>>
>> - Add jtag_add_statmove( endstate ) call, the code is already in
>> jtag_add_tlr()
>>
>
> Could you write t
Michael Bruck wrote:
> On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin wrote:
>
>> I propose some changes to the jtag subsystem
>>
>> - Add jtag_add_statmove( endstate ) call, the code is already in
>> jtag_add_tlr()
>>
>> - Remove th
1 - 100 of 282 matches
Mail list logo
