On Mar 1, 2009, at 11:26 PM, Kees Jongenburger wrote:
On Sun, Mar 1, 2009 at 11:28 PM, Spencer Oliver soft.co.uk> wrote:
Subject: Re: [Openocd-development] [patch] rename description
field of thejtag-tiny.cfg
Committed.
This patch will break all win32 ftdi targets
we have had this before
On Mar 1, 2009, at 11:19 PM, Øyvind Harboe wrote:
Ugh. Can we fix this once and for all? Win32 adds the A, Linux
and OS X do
not. Perhaps we should just introduce a global variable in the TCL
that
defines the platform type. Similar to __LINUX__, __WIN32__,
__DARWIN__ that
gcc emits. T
Note that these are LENGTHY discussions and since there are several
capable people involved, I'm kinda waiting for the dust to settle.
It would probably get more people on board if you could, once the
dust settles on these discussions, write up a summary of the
problems and possible solutions.
Th
On Sun, Mar 1, 2009 at 11:28 PM, Spencer Oliver wrote:
>> Subject: Re: [Openocd-development] [patch] rename description
>> field of thejtag-tiny.cfg
>>
>> Committed.
>>
>
> This patch will break all win32 ftdi targets
> we have had this before
Was this on the jtagkey-tiny? I tried the svn log th
On Sun, Mar 1, 2009 at 11:53 PM, Rick Altherr wrote:
> On Mar 1, 2009, at 12:08 AM, Dirk Behme wrote:
>> The first and easiest idea is to add something like
>>
>> #ifdef OMAP3_SUPPORT
>> /* Do 10 TCK in RESET state to enable OMAP3 jtag */
>> omap3_init()
>> #endif
>>
>> to jtag_init_
> Ugh. Can we fix this once and for all? Win32 adds the A, Linux and OS X do
> not. Perhaps we should just introduce a global variable in the TCL that
> defines the platform type. Similar to __LINUX__, __WIN32__, __DARWIN__ that
> gcc emits. Then the problematic devices can use the appropriate
On Sun, Mar 1, 2009 at 11:28 PM, Spencer Oliver wrote:
>> Subject: Re: [Openocd-development] [patch] rename description
>> field of thejtag-tiny.cfg
>>
>> Committed.
>>
>
> This patch will break all win32 ftdi targets
> we have had this before
>
> win32 ftdi driver uses:
> ft2232_device_desc "Amon
On Mar 1, 2009, at 1:06 PM, ohar...@mail.berlios.de wrote:
Author: oharboe
Date: 2009-03-01 22:06:06 +0100 (Sun, 01 Mar 2009)
New Revision: 1393
Modified:
trunk/src/target/interface/jtagkey-tiny.cfg
Log:
Kees Jongenburger rename description
field of the jtag-tiny.cfg
Modified: trunk/src
On Mar 1, 2009, at 12:08 AM, Dirk Behme wrote:
Additionally, short status update from me:
...
And, I wonder why the new version needs ~6 initial TAP_RESET moves
as marked with OMAP3_HACK in patch in attachment. Else, the ID
code won't be detected correctly. I assume that this isn't relat
> Subject: Re: [Openocd-development] [patch] rename description
> field of thejtag-tiny.cfg
>
> Committed.
>
This patch will break all win32 ftdi targets
we have had this before
win32 ftdi driver uses:
ft2232_device_desc "Amontec JTAGkey A"
linux ftdi driver uses:
ft2232_device_desc "Amontec
Committed.
Thanks!
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.b
Committed.
Thanks!
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.be
Please verify that all patches were committed correctly.
Thanks for the effort!
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
___
Openocd-development mail
> The STM32 flash write is self-timed and should take 40us to 70us for a
> 16 bit halfword (according to datasheet). this should lead to write
> performances of 29kByte/s to 50kByte/s (without code overhead).
I guess at 13kBytes/s @ 500kHz with a maximum theoretical speed of
29kBytes/s, that ZY100
Dirk Behme wrote:
> Additionally, short status update from me:
>
> As pointed out by Kees [1], the 'do always 7 clocks tap_get_tms_path()'
> might not be flexible enough for OMAP. So I played a little with
> Holger's jtag_move_to() [2] and used it to hack a new tap_get_tms_path()
> (see patch i
Duane Ellis wrote:
> dirk> Why is irscan implemented as handle_irscan_command(), but drscan as
> dirk> Jim_Command_drscan()? What is the difference between
> dirk> handle_xx_command and Jim_command_xx?
>
> Historically - OpenOCD did not have a script language other then a
> simplistic series of c
dirk> Why is irscan implemented as handle_irscan_command(), but drscan as
dirk> Jim_Command_drscan()? What is the difference between
dirk> handle_xx_command and Jim_command_xx?
Historically - OpenOCD did not have a script language other then a
simplistic series of commands, ie: No "IF" statements
On Sun, Mar 1, 2009 at 9:08 AM, Dirk Behme wrote:.
>>>
>>> And, I wonder why the new version needs ~6 initial TAP_RESET moves as
>>> marked with OMAP3_HACK in patch in attachment. Else, the ID code won't be
>>> detected correctly. I assume that this isn't related to new
>>> tap_get_tms_path(). I v
Rick Altherr wrote:
>
> On Feb 28, 2009, at 9:20 AM, Dirk Behme wrote:
>
>>
>> Ah, yes. Understood.
>>
>> Looking at jtag.c and irscan/drscan implementations:
>>
>> Why is irscan implemented as handle_irscan_command(), but drscan as
>> Jim_Command_drscan()? What is the difference between handle_
19 matches
Mail list logo
