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 queue) via the cmd_queue_cur_st
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, thanks for helping with this patch!
Hi all,
The following RFC proposals are still on the table and need resolution:
1) library header file rework:
a) rename src/ as openocd/ (preferred)
- this will allow public #include, e.g.
b) do not rename src, e.g. #include
- something needs to be done; the library work is only hal
Hi all,
At this point, I believe almost all of the outstanding patches have been
brought up-to-date and applied to the trunk, with the two following
exceptions:
- FTD2XX high-speed device support
- remove cmd_queue_cur_state
- add target examination check in cortex m3
The following issues have b
On Sat, 2009-05-23 at 21:06 -0700, David Brownell wrote:
> On Saturday 23 May 2009, Zach Welch wrote:
> >
> > > Considering that USB bulk transfers are "best effort" and might easily
> > > be delayed by concurrent activity to a USB disk or webcam ... a single
> > > second seems absurdly short. Ev
On Saturday 23 May 2009, Zach Welch wrote:
> .
> > > One point could be the RESET signals SRST and TRST. Here the
> > > FT2232 can set both signals at the same time, which I think
> > > is used too.
> >
> > Yeah, I noticed that *sometimes* an ft2232 adapter was able
> > to come up OK ... but other
On Saturday 23 May 2009, Zach Welch wrote:
>
> > Considering that USB bulk transfers are "best effort" and might easily
> > be delayed by concurrent activity to a USB disk or webcam ... a single
> > second seems absurdly short. Even if the device were guaranteed to be
> > able to respond that qui
On Sat, 2009-05-23 at 20:16 -0700, David Brownell wrote:
> On Saturday 23 May 2009, Zach Welch wrote:
> > At this point, I have a system in place to make it unlikely for me to
> > let any threads be forgotten,
>
> Some Linux groups use a new tool called "patchwork" which monitors
> mailing lists f
On Sun, May 24, 2009 at 11:18 AM, Xiaofan Chen wrote:
> After this error, I have to unplug everything and then use lpc21isp
> to flash the target so that I can run OpenOCD again with J-Link V3.
>
> I know the hex is correct since the target works when flashing
> with lpc21isp. The hex file is buil
Relative long email.
I have not tried to use flashing so far. So today I tried to learn how to
flash the LPC2148 on board of the Olimex LPC-P2148.
I tried to halt the target and then use
"flash write_image isoc_io_sample.hex 0x0 ihex" but this does
not seem to work. Then I tried to use the follow
On Saturday 23 May 2009, Zach Welch wrote:
> At this point, I have a system in place to make it unlikely for me to
> let any threads be forgotten,
Some Linux groups use a new tool called "patchwork" which monitors
mailing lists for patches...
http://ozlabs.org/~jk/projects/patchwork/
Purely FY
On Saturday 23 May 2009, Wookey wrote:
> > At least some of
> > the confusion could go away if there were JTAG commands to
> > disable signals (SRST, RTCK, etc) at various levels (target,
> > board, adapter).
>
> Hmm, you mean something could declare that it doesn't pass/expose
> signals. That
On Sat, 2009-05-23 at 03:57 -0700, David Brownell wrote:
> > >> I am also thinking that the USB timeout value may be extended a bit
> > >> longer.
> > >> Right now it is 1000ms. Should be ok. But may not be ok for people
> > >> using VM or similar.
> > >
> > > The problem with this is that it slo
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.
Please let me know if this fixes things, and I will get it committed.
On Wed, 2009-05-20 at 22:59 -0700, Zach Welch wrote:
> On Wed, 2009-05-20 at 22:54 -0700, Rick Altherr wrote:
> > On May 20, 2009, at 10:31 PM, Zach Welch wrote:
> >
> > > On Wed, 2009-05-20 at 22:23 -0700, Rick Altherr wrote:
> > >> On Mar 25, 2009, at 2:54 PM, joern kaipf wrote:
> > >>
> > >>> *
On Sat, 23 May 2009, Zach Welch wrote:
> On Fri, 2009-05-22 at 20:28 -0700, David Brownell wrote:
> > Update two oddball NAND commands to work with {offset, length}
> > instead of block numbers, matching the other commands as well
> > as usage in U-Boot and the Linux-MTD utilities.
> >
> > Docume
On Sat, 2009-05-23 at 21:59 -0400, Nicolas Pitre wrote:
> When the CPU is in the WFI state, the JTAG interface simply doesn't
> respond at all and initial tap examination simply fails. Let's simply
> do it again when we come around to assert nSRST.
>
Committed as r1905.
--Z
___
When the CPU is in the WFI state, the JTAG interface simply doesn't
respond at all and initial tap examination simply fails. Let's simply
do it again when we come around to assert nSRST.
diff --git a/src/target/board/sheevaplug.cfg b/src/target/board/sheevaplug.cfg
index 276d6f2..d1a0cce 100644
-
On Fri, 2009-05-22 at 20:28 -0700, David Brownell wrote:
> Update two oddball NAND commands to work with {offset, length}
> instead of block numbers, matching the other commands as well
> as usage in U-Boot and the Linux-MTD utilities.
>
> Document them accordingly. Update the single in-tree use
On Fri, 2009-05-22 at 10:43 -0700, David Brownell wrote:
> NAND support for DaVinci-family drivers, with HW ECC support.
> Declare the NAND chip on the DM355 EVM board.
>
> Currently tested on DM355 for Linux interop using the standard
> large page (2KB) chip in the EVM socket; "hwecc1" and "hwecc
On May 23, 2009, at 6:48 PM, Zach Welch wrote:
On Sat, 2009-05-23 at 18:42 -0700, Rick Altherr wrote:
On May 23, 2009, at 1:30 PM, Magnus Lundin wrote:
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
On Sat, 2009-05-23 at 18:48 -0700, Zach Welch wrote:
[snip]
> At this point, I have a system in place to make it unlikely for me to
> let any threads be forgotten, but I am still trying to catch all those
> that are still in the air. One thing you might look at is David's
> recent NAND changes ([p
On Sat, 2009-05-23 at 18:42 -0700, Rick Altherr wrote:
> On May 23, 2009, at 1:30 PM, Magnus Lundin wrote:
>
> > 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 minute
On Fri, 2009-05-22 at 17:59 -0400, Dylan Reid wrote:
> I am just updated to svn 1881 to use with my STM32 and jlink(yellow
> v6.0). I had been using 1183, which worked every time, but was
> unbearably slow. Revision 1881 is lightning fast compared with the
> old revision. I am however seeing a f
On May 23, 2009, at 1:30 PM, Magnus Lundin wrote:
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
On Sat, 2009-05-23 at 21:22 -0400, Duane Ellis wrote:
> See attached patch.
>
> Doxygen does not build if source dir != build dir.
> This patch fixes that.
Does r1901 float your boat better? It's "technically more correct", as
far as I know. A PITA, but correct. ;)
Cheers,
Zach
__
See attached patch.
Doxygen does not build if source dir != build dir.
This patch fixes that.
-Duane.
Index: Makefile.am
===
--- Makefile.am (revision 1858)
+++ Makefile.am (working copy)
@@ -16,7 +16,7 @@
docs: pdf html doxygen
Looks good.
Michael
On Sat, May 23, 2009 at 11:08 PM, Zach Welch wrote:
> Hi all,
>
> The attached patch removes the cmd_queue_cur_state global variable,
> replacing all uses with calls to tap_set_state() or tap_get_state().
>
> While this seems completely trivial, I wanted to post it for review
+++ David Brownell [2009-05-22 10:32 -0700]:
> On Friday 22 May 2009, Wookey wrote:
>
> > 1) Is there any agreement that the reset info doesn't really belong in
> > the board file because it depends on the dongle and wiring too, or is
> > that an unusual case?
>
> An "openocd.cfg" file can source
On Sat, 2009-05-23 at 02:05 +0800, SimonQian wrote:
> it only changes svf_check_tdo function,
> which is used to check tdo output with desired values.
> The patch will call buf_cmp_mask function to do the comparation
> instead of
> writing the loop code. The patch also fix a bug when data length
On Sat, 2009-05-23 at 21:41 +0200, Freddie Chopin wrote:
> Zach Welch pisze:
> > So if I understand this right:
> > 1) With jtag.c patch from Magnus, it works with short delays.
> > 2) Without that patch, it requires long delays.
> >
> > Is that summary correct?
>
> No (; If there is ANY delay bot
On Sun, May 24, 2009 at 1:01 AM, Zach Welch wrote:
> On Sun, 2009-05-24 at 00:38 +0800, SimonQian wrote:
>> Add #include "stdint.h" in replacements.h to solve this problem.
>>
>
> There has been a report of this in the past, but I thought that it
> turned out to be a red herring:
>
>
> htt
On Thu, 2009-05-21 at 16:54 -0700, David Brownell wrote:
> On Thursday 21 May 2009, Michael Fischer wrote:
> > It looks that these JTAG interfaces have not the same behaviour.
> > One point could be the RESET signals SRST and TRST. Here the
> > FT2232 can set both signals at the same time, which I
On Wed, 2009-05-20 at 01:08 -0700, Zach Welch wrote:
> Hi all,
>
> I want to get the style guide up-to-date. Here's my plan.
>
> Barring any objections, I will add doc/manual/style.txt by moving the
> relevant bits out of openocd.texi. The style guide is for developers
> working on the code; th
Hi all,
The attached patch removes the cmd_queue_cur_state global variable,
replacing all uses with calls to tap_set_state() or tap_get_state().
While this seems completely trivial, I wanted to post it for review.
Any objections? All in favor?
Cheers,
Zach
---
jtag/jtag.c | 13 ++
On Sat, 2009-05-23 at 13:42 -0700, Zach Welch wrote:
> On Sat, 2009-05-23 at 09:54 +0200, Magnus Lundin wrote:
> > Comment
> >
> > - In jlink_execute_reset(jtag_command_t *cmd)
> >
> > jlink_tap_execute(); Should be removed and be superflous, actually both
> > of them should be removed.
>
> Aft
On Sat, 2009-05-23 at 09:54 +0200, Magnus Lundin wrote:
> Comment
>
> - In jlink_execute_reset(jtag_command_t *cmd)
>
> jlink_tap_execute(); Should be removed and be superflous, actually both
> of them should be removed.
After seeing your latest post, I now think I understand this to mean
that
Hello Zach,
the outstanding patches are required to get the SAM7 working.
In case of the LPC, I must use the delay here too for my
LPC2148 and LPC2294 targets. Without the delay sometimes
the LP2294 is working and sometimes not. It works more
stable with the delay.
Best regards,
Michael
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
jtag_add_path_
Zach Welch pisze:
> So if I understand this right:
> 1) With jtag.c patch from Magnus, it works with short delays.
> 2) Without that patch, it requires long delays.
>
> Is that summary correct?
No (; If there is ANY delay both versions (clean r1889 and patched
r1889) work. When we talk about the
Hello list,
I have make a new smoketest with the r1888 and the patches
which can be find here:
https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html
Tested under Windows with FT2232 and the following targets:
LPC2148, LPC2294, SAM7S256, SAM7X256, SAM7SE512, AT91R40008,
STR7
On Tue, May 19, 2009 at 2:47 PM, Xiaofan Chen wrote:
> On Tue, May 19, 2009 at 2:38 PM, Spencer Oliver wrote:
>>
>> I have tested both the filter and native driver under winxp.
>> Never tested the filter driver under vista64, but the native driver works.
>>
>
> Thanks for the confirmation. I will
On Sat, 2009-05-23 at 16:11 +0200, Freddie Chopin wrote:
> Michael Fischer pisze:
> > have you installed SVN under Cygwin too?
>
> I use MSYS + MinGW to compile, so I guess that I should use some SVN
> client for MSYS for that feature to work?
Yes. Take a look at guess-rev.sh.
--Z
On Sun, May 24, 2009 at 12:52 AM, Xiaofan Chen wrote:
> 2009/5/24 SimonQian :
>> Add #include "stdint.h" in replacements.h to solve this problem.
>>
>
> Thanks. It seems to help. Cygwin is really slow here so it is
> still building.
>
> Maybe I should learn to cross-compile OpenOCD under
> Linux f
On Sun, 2009-05-24 at 00:38 +0800, SimonQian wrote:
> Add #include "stdint.h" in replacements.h to solve this problem.
>
There has been a report of this in the past, but I thought that it
turned out to be a red herring:
http://www.mail-archive.com/openocd-development@lists.berlios.de/m
2009/5/24 SimonQian :
> Add #include "stdint.h" in replacements.h to solve this problem.
>
Thanks. It seems to help. Cygwin is really slow here so it is
still building.
Maybe I should learn to cross-compile OpenOCD under
Linux for Windows.
--
Xiaofan http://mcuee.blogspot.com
_
Add #include "stdint.h" in replacements.h to solve this problem.
2009-05-24
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
发件人： Xiaofan Chen
发送时间： 2009-05-24 00:36:17
收件人： Openocd-Dev
抄送：
主题： [Openocd-development] Building OpenOCD with Cygwin
Wi
With the help of the SparkFun thread,
http://forum.sparkfun.com/viewtopic.php?t=11221
I was tryam going to build OpenOCD but somehow it failed.
$ ./configure --enable-maintainer-mode --enable-jlink
CC="gcc -mno-cygwin" CFLAGS="-O0 -g -Wall"
This is ok.
But make failed.
mc...@acerpc ~/mcu/openocd/
Michael Fischer pisze:
only a test. Take a look at the LPC2148 here you will find the
following lines:
jtag_nsrst_delay 200
jtag_ntrst_delay 200
Please add this two lines to your lpc2103 cfg too.
With those delays the patched r1889 works. The delays can by very low -
I've tried with 10ms and
Michael Fischer pisze:
> here it is working with a LPC2148, tested with r1888
> and the pathes from Magnus:
> https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html
>
> Can you test it with the jtag_090522.patch and ft2232_090522.patch too?
I've tested with r1889. It's still
Michael Fischer pisze:
> have you installed SVN under Cygwin too?
I use MSYS + MinGW to compile, so I guess that I should use some SVN
client for MSYS for that feature to work?
regards
___
Openocd-development mailing list
Openocd-development@lists.berl
Hello Freddie,
have you installed SVN under Cygwin too?
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hello Freddie,
response to:
https://lists.berlios.de/pipermail/openocd-development/2009-May/007113.html
here it is working with a LPC2148, tested with r1888
and the pathes from Magnus:
https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html
Can you test it with the jtag_09052
Hello!
can someone tell me how to get the proper SVN revision to be displayed
in OpenOCD? I just can't make that happen...
I checkout directly into the compile folder via TortoiseSVN, compile and
always get:
Open On-Chip Debugger 0.2.0-in-development (2009-05-23-12:22) svn:unknown
);
regards
Michael Fischer pisze:
> the SAM7S256 is still broken
I've tested r1889 with LPC2103 and it fails too
I run:
openocd-r1889 -f interface/jtagkey.cfg -f target/lpc2103.cfg
Which results in:
Info : JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (Manufacturer:
0x787,
Part: 0xf1f0, Version: 0x4
On Tue, May 19, 2009 at 8:26 AM, Igor Skochinsky wrote:
> What I mean is I could write up a list of missing/underdocumented
> commands and describe their input/output parameters. I don't have a
> J-Link so I don't really need the code myself.
Are you using reverse engineering from the J-Link Wind
On Sat, May 23, 2009 at 6:57 PM, David Brownell wrote:
>> >> I am also thinking that the USB timeout value may be extended a bit
>> >> longer.
>> >> Right now it is 1000ms. Should be ok. But may not be ok for people
>> >> using VM or similar.
>> >
>> > The problem with this is that it slows down
> >> I am also thinking that the USB timeout value may be extended a bit longer.
> >> Right now it is 1000ms. Should be ok. But may not be ok for people
> >> using VM or similar.
> >
> > The problem with this is that it slows down the failure process when
> > something is actually broken. I think
On Sat, May 23, 2009 at 10:14 AM, Zach Welch wrote:
> On Sat, 2009-05-23 at 09:54 +0800, Xiaofan Chen wrote:
> [snip]
>> I am also thinking that the USB timeout value may be extended a bit longer.
>> Right now it is 1000ms. Should be ok. But may not be ok for people
>> using VM or similar.
>
> The
Hello list,
the SAM7S256 is still broken like I have reported before:
https://lists.berlios.de/pipermail/openocd-development/2009-May/006929.html
The OpenOCD output looks like:
=
C:\Temp\SAM7S256Test>openocd-1889 -
Comment
- In jlink_execute_reset(jtag_command_t *cmd)
jlink_tap_execute(); Should be removed and be superflous, actually both
of them should be removed.
This is because the jtag command queue MUST be clean at this moment,
controlled from jtag_add_reset. Otherwise we get tap sequences sent
whil
61 matches
Mail list logo
