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 when
the
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 in
2009-10-21 13:12, Øyvind Harboe skrev:
Testing and comments much appreciated!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
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 natural
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
Øyvind Harboe wrote:
On Wed, Oct 21, 2009 at 6:43 PM, David Brownell davi...@pacbell.net 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
Ø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
greatly
Ø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.
IMHO
Ø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
See the
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
Yauheni Kaliuta wrote:
Hi!
On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin lun...@mlu.mine.nu 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, adiv5_debug or coresight_component
Øyvind Harboe wrote:
On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Yauheni Kaliuta wrote:
Hi, Magnus!
ML == Magnus Lundin writes:
[...]
I have a simple works for me implementation of memory access with
cpu instead
Magnus Lundin wrote:
Øyvind Harboe wrote:
On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Yauheni Kaliuta wrote:
Hi, Magnus!
ML == Magnus Lundin writes:
[...]
I have a simple
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
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:
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
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
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
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 needed, same
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.
Best regards
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 a
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.
--
Ãyvind Harboe
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
config file)
At the moment no known functional changes
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
Ø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 still
Øyvind Harboe wrote:
On Tue, Sep 15, 2009 at 6:18 AM, michal smulski michal.smul...@ooma.com
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
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
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
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.
After this it is possible
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
Øyvind Harboe wrote:
On Fri, Sep 4, 2009 at 10:30 AM, David Brownelldavi...@pacbell.net 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
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
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
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 : device: 4
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 mentioned this
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 configuration
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);
dap_ap_read_reg_u32(swjdp, 0xF8, romaddr);
in ahbap_debugport_init
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 chapter
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 only
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 general improves performance when using long
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
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.
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 familiar? Do you
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 nobody submitted
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 things that
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 sanity
testing on
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-development
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? #1 to move the
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
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 it in SVN, so I
Sergey Lapin skrev:
On Mon, Jul 6, 2009 at 7:43 PM, Magnus Lundinlun...@mlu.mine.nu wrote:
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
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
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 license just
John Devereux wrote:
Anders Montonen anders.monto...@iki.fi 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
Ø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 there are
Øyvind Harboe wrote:
On Tue, Jun 23, 2009 at 11:38 PM, Magnus Lundinlun...@mlu.mine.nu wrote:
Ų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
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 code.
This is a VERY different tone from
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
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 with.
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 protocol
for FT232 (not FT2232) is neither well-known nor
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, a binary
Ø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 jtag
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
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
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;
-
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)
@@
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
Ø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 sense
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 for jlink
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
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 @@
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
Peter Denison wrote:
Some (all?) V6 firmware on the J-Link adapter fails to step the TAP
unless the first EMU_CMD_HW_JTAG3 command has 8 bits rather than 7,
immediately after adapter power-up. Add a hack to pad out to 8 bits,
the first time only.
I propose some changes to the jtag subsystem
- Add jtag_add_statmove( endstate ) call, the code is already in
jtag_add_tlr()
- Remove the JTAG_RUNTEST cmd type.
- Implement jtag_add_runtest(n) as
jtag_add_statemovet(TAP_IDLE)
jtag_stableclocks(n) /* Should be n-1 if current tap
Michael Bruck wrote:
On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
I propose some changes to the jtag subsystem
- Add jtag_add_statmove( endstate ) call, the code is already in
jtag_add_tlr()
- Remove the JTAG_RUNTEST cmd type.
- Implement
Øyvind Harboe wrote:
On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin lun...@mlu.mine.nu 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 the documentation for this fn as a separate
Ø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.
Xiaofan Chen wrote:
On Sat, May 30, 2009 at 1:01 AM, Peter Denison open...@marshadder.org wrote:
Unfortunately not mine... I still get a 1 returned (instead of a zero) as
the error code from EMU_CMD_HW_JTAG3, when I send 8 bits:
Debug: 191 667 jlink.c:1032 jlink_usb_write():
Hi
a bit more debugging
The issue seesms to be in the function jlink_tap_execute
the change in r1509 that causes the issue is:
// number of full bytes (plus one if some would be left over)
byte_length = tap_length / 8 + !!(tap_length % 8);
instead of r1508
/* Pad last byte so that
Hello list
The accepted wisdom seems to be that libftdi is slower than ftd2xx,
and when performance is low change to ftd2xx. Is this true or a myth ?
Two years ago, or three, this was true, today I am not so sure.
I have made some small tests , single stepping arm7, uploading medium
sized
Michael Bruck wrote:
On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Spencer Oliver wrote:
If you define your interface with only srst then the
software method
will be used.
Well it did last time i checked - see jtag_add_reset for code
Michael Schwingen wrote:
Magnus Lundin wrote:
Michael Bruck wrote:
On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
move to TLR works for all current states. It is 7 steps with TMS high,
that
takes you to TAP_RESET froma any
Duane Ellis wrote:
I have a observation/question
When run algorithm occurs - what/where - etc are interrupts disabled?
int arm7_9_debug_entry(target_t *target)
Look for buf_set_u32(dbg_ctrl-value, EICE_DBG_CONTROL_INTDIS, ...
and the debug_execution flag.
For instance:
Looking at
Dick Hollenbeck wrote:
Magnus Lundin wrote:
Hi
I was testing the state move work fronm Dick H. when there were a lot
of changes in the codebase. As you know I keep working from the same
base . There were some problems remaining so I have waited to send
the results, but I hope I found
Dick Hollenbeck skrev:
Zach,
I think this patch is fundamentally wrong and is a disaster the moment
it is applied.
The queue sits between the jtag api and the drivers. The api calls
track future state according to the most recent api call submitted
(and put onto the back end of the
Hi
This looks like a reset problem, not a write to flash problem. This is
the type of problems we are trying fix with the latest jtag/jlink/ft2232
patches.
What is the target configuration.
Best regards
Magnus
Xiaofan Chen skrev:
Relative long email.
I have not tried to use flashing so
Dirk Behme skrev:
Zach Welch wrote:
On Fri, 2009-05-22 at 10:57 +0200, Øyvind Harboe wrote:
Trying again...
My editor is screwing things up with whitespace, hence all those irrelevant
changes...
The second attempt was no better. Here it is done right.
First,
Common people
So much soul searching about a oneliner in jtag.c .
Setting the current tap state with cmd_queue_cur_state = TAP_RESET is
an obvious error as 5 minutes of code inspection in jtag.c will show you.
The variable is not used in any dr/ir scan code, It is only used in
Zach Welch wrote:
On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote:
Zach Welch wrote:
On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote:
Hi
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Error: J-Link command
Hi
Now when we have almost got the new state table infrastructure in plaec
and working it is time to think ahead.
Shall we retire the 7 step transitions ? No ! expand the founctionallity
to allow user (target) defined state transition tables, the current code
allows that. Maybe not the
Dean Glazeski wrote:
Magnus Lundin wrote:
Dean Glazeski wrote:
openocd.x86_64: E: statically-linked-binary
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: W: devel-file-in-non-devel-package
/usr
Øyvind Harboe wrote:
On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
Does the LPC2148 (which I have) exhibit the same problem?
I can not test the attached patch here, but it is intended to
allow switching between the long(old) or new (short)
tms_sequence
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of JLink.
This should improve the situation.
Hopefully the same trick works under win and mac os.
Have a nice day
Magnus
Index: src/jtag/jlink.c
Hi
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Error: J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (-110)
Open OCD seems to get reasonable ansvers from first two JLink commands.
The /* query hardware maximum memory block */ should not be run for this
The following patch combines my previous patch with most of Ben's patch.
It can use both EMU_CMD_HW_JTAG2 and EMU_CMD_HW_JTAG3
It defaults to EMU_CMD_HW_JTAG2 so it should work with all interfaces
but EMU_CMD_HW_JTAG3 is recommended by SEgger, you can change the
behaviour with
Hi
I was testing the state move work fronm Dick H. when there were a lot of
changes in the codebase. As you know I keep working from the same base .
There were some problems remaining so I have waited to send the results,
but I hope I found most of them now.
Here comes my patch.
Best
Øyvind Harboe wrote:
I've made a quick attempt at modifying the patch to
be against svn head, can't test beyond building it though.
This took me a couple of minutes, so this patch is only very slightly
different in svn head/1606.
Looking at the patch, it occurs to me that from a
This is some thoughts on cleaning up target.c and specifictarget
relations.
It is not an architectural change, but rather about consistent use of
the one we have.
A very common pattern is to have something like this
target_halt(target_s *target)
.
Some common cleanup and sanity checking
.
Øyvind Harboe wrote:
I think this makes sense.
It is roughly along the lines of using a base class where the
subclass implements the guts and the base class implements
the fn called by normal users.
Along the same lines, Michael Bruck was trying to find a
reasonable way to reuse the
1 - 100 of 205 matches
Mail list logo
