Re: [Openocd-development] [patch] cm3 reset cleanup
On Wednesday 19 August 2009, Spencer Oliver wrote: > Just for info the statement: > "Use a standard Cortex-M3 software reset mechanism" is not correct The request *is* standard... > as the sequence will not work on a stm32. > It is implementation dependant, but SoC vendors don't necessarily handle that one the same. (What happens on STM32?) > but is the correct sequence for luminary - > luminary support helped a lot sorting this problem out. The comment in the code elaborates the situation: /* Use a standard Cortex-M3 software reset mechanism. * SYSRESETREQ will reset SoC peripherals outside the * core, like watchdog timers, if the SoC wires it up * correctly. Else VECRESET can reset just the core. */ So an STM32 should use VECRESET, and maybe a bunch of manual resets of the peripherals, if it doesn't have a SRST wired up. That's what the soft_reset_halt() does (without peripheral resets). - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
On Wednesday 19 August 2009, James Lin wrote:
> Then I tried to apply the patch described in
>
> http://lists.berlios.de/pipermail/openocd-development/2009-June/008256.html
>
> I don't know if this additional step was necessary but it seemed
> to get correct mfg, part, ver.
So it *was* necessary. You seem to have had better luck than I
did, way back when I did that, in that you got that without first
forcing a reset. Right?
Maybe an updated version of that patch should merge...
> But I could not halt, or examine memory. Could someone help to
> see if I might have missed some steps? Thanks in advance.
Current SVN seems to behave with the lowlevel JTAG ops (given
a patch like the one above). But there's also the issue of
adding support for the Cortex-A8 CPU; and someday, of being
sure that works for chips other than OMAP3. See:
http://lists.berlios.de/pipermail/openocd-development/2009-July/009652.html
https://lists.berlios.de/pipermail/openocd-development/2009-July/009784.html
Plus of course:
--- a/tcl/target/omap3530.cfg
+++ b/tcl/target/omap3530.cfg
@@ -35,9 +35,7 @@ jtag newtap $_CHIPNAME jrc -irlen 6 -irc
-expected-id $_JRC_TAPID
# GDB target: Cortex-A8, using DAP
-
-# FIXME when we have A8 support, use it. A8 != M3 ...
-target create omap3.cpu cortex_m3 -chain-position $_CHIPNAME.dap
+target create omap3.cpu cortex_a8 -chain-position $_CHIPNAME.dap
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] thumb2 ldrex/strex/... disassembly
More Thumb2 disassembly:
ARMv7-M: A5.3.6 Load/store dual or exclusive, table branch
GCC will generate the table branch instructions, usually with inlined
tables that will confuse this disassembler. LDREX and STREX are not
issued by GCC without inline assembly.
This means all Thumb2 instructions implemented by Cortex-M3 can now
be disassembled. Cortex-A8 cores support more Thumb2 instructions,
but most of those aren't yet publicly documented.
---
src/target/arm_disassembler.c | 138 +++-
1 file changed, 136 insertions(+), 2 deletions(-)
--- a/src/target/arm_disassembler.c
+++ b/src/target/arm_disassembler.c
@@ -3007,6 +3007,133 @@ static int t2ev_ldm_stm(uint32_t opcode,
return ERROR_OK;
}
+/* load/store dual or exclusive, table branch */
+static int t2ev_ldrex_strex(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ unsigned op1op2 = (opcode >> 20) & 0x3;
+ unsigned op3 = (opcode >> 4) & 0xf;
+ char *mnemonic;
+ unsigned rn = (opcode >> 16) & 0xf;
+ unsigned rt = (opcode >> 12) & 0xf;
+ unsigned rd = (opcode >> 8) & 0xf;
+ unsigned imm = opcode & 0xff;
+ char *p1 = "";
+ char *p2 = "]";
+
+ op1op2 |= (opcode >> 21) & 0xc;
+ switch (op1op2) {
+ case 0:
+ mnemonic = "STREX";
+ goto strex;
+ case 1:
+ mnemonic = "LDREX";
+ goto ldrex;
+ case 2:
+ case 6:
+ case 8:
+ case 10:
+ case 12:
+ case 14:
+ mnemonic = "STRD";
+ goto immediate;
+ case 3:
+ case 7:
+ case 9:
+ case 11:
+ case 13:
+ case 15:
+ mnemonic = "LDRD";
+ if (rn == 15)
+ goto literal;
+ else
+ goto immediate;
+ case 4:
+ switch (op3) {
+ case 4:
+ mnemonic = "STREXB";
+ break;
+ case 5:
+ mnemonic = "STREXH";
+ break;
+ default:
+ return ERROR_INVALID_ARGUMENTS;
+ }
+ rd = opcode & 0xf;
+ imm = 0;
+ goto strex;
+ case 5:
+ switch (op3) {
+ case 0:
+ sprintf(cp, "TBB\t[r%u, r%u]", rn, imm & 0xf);
+ return ERROR_OK;
+ case 1:
+ sprintf(cp, "TBH\t[r%u, r%u, LSL #1]", rn, imm & 0xf);
+ return ERROR_OK;
+ case 4:
+ mnemonic = "LDREXB";
+ break;
+ case 5:
+ mnemonic = "LDREXH";
+ break;
+ default:
+ return ERROR_INVALID_ARGUMENTS;
+ }
+ imm = 0;
+ goto ldrex;
+ }
+ return ERROR_INVALID_ARGUMENTS;
+
+strex:
+ imm <<= 2;
+ if (imm)
+ sprintf(cp, "%s\tr%u, r%u, [r%u, #%u]\t; %#2.2x",
+ mnemonic, rd, rt, rn, imm, imm);
+ else
+ sprintf(cp, "%s\tr%u, r%u, [r%u]",
+ mnemonic, rd, rt, rn);
+ return ERROR_OK;
+
+ldrex:
+ imm <<= 2;
+ if (imm)
+ sprintf(cp, "%s\tr%u, [r%u, #%u]\t; %#2.2x",
+ mnemonic, rt, rn, imm, imm);
+ else
+ sprintf(cp, "%s\tr%u, [r%u]",
+ mnemonic, rt, rn);
+ return ERROR_OK;
+
+immediate:
+ /* two indexed modes will write back rn */
+ if (opcode & (1 << 21)) {
+ if (opcode & (1 << 24)) /* pre-indexed */
+ p2 = "]!";
+ else { /* post-indexed */
+ p1 = "]";
+ p2 = "";
+ }
+ }
+
+ imm <<= 2;
+ sprintf(cp, "%s\tr%u, r%u, [r%u%s, #%s%u%s\t; %#2.2x",
+ mnemonic, rt, rd, rn, p1,
+ (opcode & (1 << 23)) ? "" : "-",
+ imm, p2, imm);
+ return ERROR_OK;
+
+literal:
+ address = thumb_alignpc4(address);
+ imm <<= 2;
+ if (opcode & (1 << 23))
+ address += imm;
+ else
+ address -= imm;
+ sprintf(cp, "%s\tr%u, r%u, %#8.8" PRIx32,
+ mnemonic, rt, rd, address);
+ return ERROR_OK;
+}
+
static int t2ev_data_shift(uint32_t opcode, uint32_t address,
arm_instruction_t *instruction, char *cp)
{
@@ -3677,6 +3804,10 @@ int thumb2_opcode(target_t *target, uint
else if ((opcode & 0x1e40) == 0x0800)
retval = t2ev_ldm_stm(opcode, address, instruction, cp);
+ /* ARMv7-M: A5.3.6 Load/store dual or exclusive, tab
Re: [Openocd-development] XScale debug handler again?
On Wed, Aug 19, 2009 at 9:06 PM, Wookey wrote: > +++ Michael Schwingen [2009-07-27 21:04 +0200]: >> Hi, >> >> I just tested a new OpenOCD install on my home machine - and it still >> can't find the XScale debug handler. I thought this had been fixed? > >> This happens both using 0.2.0 and using current trunk. > > Yes. I just found this too. I thought it was fixed too. > > As it's really quite annoying on pxa (and I have a (vague) > understanding of autotools) I'll try and find out what to > prod. It was still broken back at r1979 but is good in r1609. The xscale handler search path problem is a known and understood problem. See the todo list. It just needs someone to step up to the plate and solve it in the makefiles. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] playsxvf regression
On Wed, Aug 19, 2009 at 9:10 PM, Wookey wrote: > +++ Øyvind Harboe [2009-07-21 22:56 +0200]: >> On Tue, Jul 21, 2009 at 3:07 PM, Wookey wrote: >> > +++ David Brownell [2009-07-20 15:53 -0700]: >> >> On Monday 20 July 2009, Wookey wrote: >> >> > Error: BUG: TAP path doesn't finish in a stable state >> > >> >> Looks like r1980 creating jtag_add_statemove() from the XSVF-specific >> >> code might have seeded this problem ... if later changes to the >> >> statemove() >> >> logic turned some things into errors. Do r1979 and r1980 behave, or was >> >> it already incompatible then? >> > >> > OK. I tried HEAD (r2551) and that is the same as debian's 0.2.0+r2529-1 >> > in this regard. >> > >> > Tried to build r1979 but there appears to be something wrong with the >> > autofoo because it doesn't build a libopenocd shared library and thus >> > doesn't work. I ran out of time trying to work out what was amiss. >> >> Just a thought: did you try --disable-shared? > > Thanx very much - that lets it build, and allows me to find that > PLAYXSVF is still broken (as is the xscale/ path to find debug_handler). The xscale path is a known problem and is described in the todo list. It just needs someone to do the legwork in the automake files. Meanwhile you can use the -s(???) to add the right search path. > both these problems are not present in r1609, so I see a long binary chop > process ahead where I look for likely relevant changes between those > versions. Clues welcome. For a thousand revisions you need 10 chops best case... if you can divide it a few times that would help *Greatly*. > > Wookey > -- > Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian > http://wookware.org/ > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD + beagle
Hi, I have tried to follow the information on the following page to run OpenOCD with Beagleboard & Flyswatter board using Ubuntu 9.04 and got some errors. http://lists.berlios.de/pipermail/openocd-development/2009-July/009314.html The log message was === sudo openocd -s tcl/ -f interface/flyswatter.cfg -f board/ti_beagleboard.cfg Open On-Chip Debugger 0.2.0-in-development (2009-08-19-11:52) svn:2294M BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ jtag_speed: 1 Warn : huge IR length 38 Warn : Tap/Device does not have IDCODE Error: JTAG tap: omap3530.jrc got: 0x (mfg: 0x000, part: 0x, ver: 0x0) Error: JTAG tap: omap3530.jrc expected 1 of 1: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Error: trying to validate configured JTAG chain anyway... === Then I tried to apply the patch described in http://lists.berlios.de/pipermail/openocd-development/2009-June/008256.html I don't know if this additional step was necessary but it seemed to get correct mfg, part, ver. The The log message was === j...@jlin-desktop-compaq:~/flyswatter/openocd2294$ sudo openocd -s tcl/ -f interface/flyswatter.cfg -f board/ti_beagleboard.cfg Open On-Chip Debugger 0.2.0-in-development (2009-08-19-11:52) svn:2294M BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ jtag_speed: 1 Warn : huge IR length 38 Info : JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Info : JTAG Tap/device matched === But I could not halt, or examine memory. Could someone help to see if I might have missed some steps? Thanks in advance. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] playsxvf regression
+++ Øyvind Harboe [2009-07-21 22:56 +0200]: > On Tue, Jul 21, 2009 at 3:07 PM, Wookey wrote: > > +++ David Brownell [2009-07-20 15:53 -0700]: > >> On Monday 20 July 2009, Wookey wrote: > >> > Error: BUG: TAP path doesn't finish in a stable state > > > >> Looks like r1980 creating jtag_add_statemove() from the XSVF-specific > >> code might have seeded this problem ... if later changes to the statemove() > >> logic turned some things into errors. Do r1979 and r1980 behave, or was > >> it already incompatible then? > > > > OK. I tried HEAD (r2551) and that is the same as debian's 0.2.0+r2529-1 > > in this regard. > > > > Tried to build r1979 but there appears to be something wrong with the > > autofoo because it doesn't build a libopenocd shared library and thus > > doesn't work. I ran out of time trying to work out what was amiss. > > Just a thought: did you try --disable-shared? Thanx very much - that lets it build, and allows me to find that PLAYXSVF is still broken (as is the xscale/ path to find debug_handler). both these problems are not present in r1609, so I see a long binary chop process ahead where I look for likely relevant changes between those versions. Clues welcome. Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale debug handler again?
+++ Michael Schwingen [2009-07-27 21:04 +0200]: > Hi, > > I just tested a new OpenOCD install on my home machine - and it still > can't find the XScale debug handler. I thought this had been fixed? > This happens both using 0.2.0 and using current trunk. Yes. I just found this too. I thought it was fixed too. As it's really quite annoying on pxa (and I have a (vague) understanding of autotools) I'll try and find out what to prod. It was still broken back at r1979 but is good in r1609. Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Well, the problem is that the default is to actually build a static library. If you try to disable the static library without enabling the shared library, it will still make the static library anyway. I think it's a problem with the build, but I don't know how to work with the autoconf/automake chain. // Dean Glazeski David Brownell wrote: On Tuesday 18 August 2009, Dean Glazeski wrote: I can't disable the building of libraries so I assumed the library was in use by the OpenOCD executable. Am I mistaken? On this system: $ ldd src/openocd linux-vdso.so.1 => (0x7fff7dbfe000) libdl.so.2 => /lib/libdl.so.2 (0x7fbb7561a000) libftdi.so.1 => /usr/local/lib/libftdi.so.1 (0x7fbb75414000) libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0x7fbb7520c000) libc.so.6 => /lib/libc.so.6 (0x7fbb74eaa000) /lib64/ld-linux-x86-64.so.2 (0x7fbb7581e000) $ With that /usr/local/... stuff working around Ubuntu 8.04 version issues with those libraries (configure CFLAGS=... LDFLAGS=...) If so, I can just have the spec file delete the libraries that the make process creates. If there is a configuration option I need to use to make the final server not use an external library, let me know what it is. Thanks. I use "configure ... --disable-shared ..." which IMO ought to be the default. - Dave // Dean Glazeski David Brownell wrote: On Thursday 06 August 2009, Chitlesh GOORAH wrote: Keep an eye on https://bugzilla.redhat.com/show_bug.cgi?id=502130 for further updates. You should not include a "libopenocd" ... there are are *NO* public supported programming interfaces in that code. Don't include any library at all; just "openocd" server that links against stuff like libftdi and libusb. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Board support for mini2440 (friendlyARM) samsung s3c2440 based board
On Wed, Aug 19, 2009 at 8:01 PM, Brian Findlay wrote: > Yes, I realized I misunderstood what it's purpose was.. Please provide a patch once you have a finalized version of the config file. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Board support for mini2440 (friendlyARM) samsung s3c2440 based board
Yes, I realized I misunderstood what it's purpose was.. thanks! Brian On Wed, Aug 19, 2009 at 3:13 AM, Jonas Horberg wrote: > > openocd-development-boun...@lists.berlios.de wrote on 2009-08-18 15:37:14: > > > > It's not all I want it to be, but it's more than what I started with. > > I hope it helps someone else. > > > >Best! > > > >Brian Findlay > > [attachment "mini2440.cfg" deleted by Jonas Horberg/Alm/Sauer] > > ==From mini2440.cfg= > [snip] > > # JTAG ADAPTER SPECIFIC > # IMPORTANT! Any JTAG device that uses ADAPTIVE CLOCKING will likely > # FAIL as the pin RTCK on the mini2440 10 pin JTAG Conn doesn't exist. > # This is Pin 11 (RTCK) on 20 pin JTAG connector. Therefore it is > # necessary to FORCE setting the clock. Normally this should be > configured > # in the openocd.cfg file, but was placed here as it can be a tough > # problem to figure out. THIS MAY NOT FIX YOUR PROBLEM.. I modified > # the openOCD driver jlink.c and posted it here. It may eventually end > # up changed in openOCD, but its a hack in the driver and really should > # be in the jtag layer (core.c me thinks), but haven't done it yet. My > # hack for jlink.c may be found here. > > [snip] > > #- > # JTAG ADAPTER SPECIFIC > # IMPORTANT! See README at top of this file. > #- > > jtag_khz 12000 > jtag_rclk 3000 > jtag interface > > [snip] > =end=== > > I believe that the JTAG speed setting belongs to the board configuration > file > (the placement is correct), but the jtag_rclk speed request command shall > not be used for boards without RTCK. It do not make sense to use both the > jtag_khz and jtag_rclk command in the configuration state. The one that is > used latst in the script will be used when the interface is initialized. > > The Mini2440 lacks RTCK support so jtag_rclk should be removed and > jtag_khz kept. There is a mismatch in the 12MHz and 3MHz parameters > so it is unclear which of them is valid. > > Best regards > Jonas Hörberg ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ftdi high speed support
> > Hi, > > What should the pupose be of this legacy mode? for people who want to emulate FT2232D, unlikely to be used but just incase. > (Note: my previously reported bug is back in line 78 of the patch) > No - that line is not part of the patch. Its just i have not done a svn update on that tree yet. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ftdi high speed support
openocd-development-boun...@lists.berlios.de wrote on 2009-08-19 15:27:52: > Hi, > > Attached patch makes the ftdi highspeed support a bit more dynamic. > It now check during runtime if you have attached a highspeed device and have > built openocd using an older driver. > > I have also added a cmd "ft2232_legacy_mode" to enable legacy mode for the > newer devices. > > comments? > > Cheers > Spen > [attachment "ft2232.patch" deleted by Jonas Horberg/Alm/Sauer] Hi, What should the pupose be of this legacy mode? (Note: my previously reported bug is back in line 78 of the patch) Best regards Jonas Hörberg ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] ftdi high speed support
Hi, Attached patch makes the ftdi highspeed support a bit more dynamic. It now check during runtime if you have attached a highspeed device and have built openocd using an older driver. I have also added a cmd "ft2232_legacy_mode" to enable legacy mode for the newer devices. comments? Cheers Spen ft2232.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] remove enable-ft2232-highspeed option
Hi, The attached patch removes the configure option --enable-ft2232-highspeed We already have enough options, so detecting high speed support is now automatic if ftdi support is enabled. no objections or issues i will commit. Cheers Spen configure.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] FT2232H/FT4232H support
> > One of the additions to my patch contain a small error. > The detection of a FT4232H chip by the ft2232_init_ftd2xx > function outputs "UNKNOWN" instead of "4232H". > A patch that correct this is attached to this mail. > well spotted, and committed. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] cm3 reset cleanup
> Clean up some Cortex-M3 reset handling. > > - AIRCR_SYSRESETREQ is generic; use it on any system where >SRST won't fly, not just on Stellaris-based ones. > > - Reformat and improve comments about the Stellaris quirk; and >xref the only public docs (an email) about the issue. > > It seems that *most* Stellaris chips have this problem. Tempest > parts aren't yet in general sampling; and if rev B silicon for > earlier chips exists, it's not very visible yet. > --- Just for info the statement: "Use a standard Cortex-M3 software reset mechanism" is not correct as the sequence will not work on a stm32. It is implementation dependant, but is the correct sequence for luminary - luminary support helped a lot sorting this problem out. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Board support for mini2440 (friendlyARM) samsung s3c2440 based board
openocd-development-boun...@lists.berlios.de wrote on 2009-08-18 15:37:14: > It's not all I want it to be, but it's more than what I started with. > I hope it helps someone else. > >Best! > >Brian Findlay > [attachment "mini2440.cfg" deleted by Jonas Horberg/Alm/Sauer] ==From mini2440.cfg= [snip] # JTAG ADAPTER SPECIFIC # IMPORTANT! Any JTAG device that uses ADAPTIVE CLOCKING will likely # FAIL as the pin RTCK on the mini2440 10 pin JTAG Conn doesn't exist. # This is Pin 11 (RTCK) on 20 pin JTAG connector. Therefore it is # necessary to FORCE setting the clock. Normally this should be configured # in the openocd.cfg file, but was placed here as it can be a tough # problem to figure out. THIS MAY NOT FIX YOUR PROBLEM.. I modified # the openOCD driver jlink.c and posted it here. It may eventually end # up changed in openOCD, but its a hack in the driver and really should # be in the jtag layer (core.c me thinks), but haven't done it yet. My # hack for jlink.c may be found here. [snip] #- # JTAG ADAPTER SPECIFIC # IMPORTANT! See README at top of this file. #- jtag_khz 12000 jtag_rclk 3000 jtag interface [snip] =end=== I believe that the JTAG speed setting belongs to the board configuration file (the placement is correct), but the jtag_rclk speed request command shall not be used for boards without RTCK. It do not make sense to use both the jtag_khz and jtag_rclk command in the configuration state. The one that is used latst in the script will be used when the interface is initialized. The Mini2440 lacks RTCK support so jtag_rclk should be removed and jtag_khz kept. There is a mismatch in the 12MHz and 3MHz parameters so it is unclear which of them is valid. Best regards Jonas Hörberg___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
