On Thu, 2009-05-28 at 23:45 -0700, Rick Altherr wrote:
> On May 28, 2009, at 7:04 PM, Zach Welch wrote:
[snip]
> > In addition, the following issues appear to require resolution, in
> > order
[snip]
> > - fix jlink to work with large scan chains (e.g. R.Doss svf test).
>
> As long as the fix is
On Thu, 2009-05-28 at 23:45 -0700, Rick Altherr wrote:
> On May 28, 2009, at 7:04 PM, Zach Welch wrote:
>
> >
> > In addition, the following issues appear to require resolution, in
> > order
> > to decided whether they should be accomplished for 0.2.0 or postponed:
> > - ft2232 high-speed device
On May 28, 2009, at 7:04 PM, Zach Welch wrote:
In addition, the following issues appear to require resolution, in
order
to decided whether they should be accomplished for 0.2.0 or postponed:
- ft2232 high-speed device support
Not necessary for 0.2.0, but if a patch was ready, it would go
(sorry for sending to Zach and not to the list, IMHO that "Reply-To"
behaviour is annoying, despite what was written about that in the past)
From the "ordinary-user" point of view.
> - ft2232 high-speed device support
Does anyone use those? They are still pretty new and I haven't seen any
fini
On Fri, May 29, 2009 at 10:04 AM, Zach Welch wrote:
> The following tasks appear to be pending for the 0.2.0 release:
> - fix OMAP3 problems reported by Dick Behme (or did these get resolved?)
> - final packaging fix-ups (RPM file layout)
> - reporting/testing tools
> - documentation:
> - updates
On Fri, May 29, 2009 at 10:08 AM, Duane Ellis wrote:
> I'm talking about basic continuity and pin drive, and ability to read a
> digital value on a pin.
>
> If I had a program that could take the Schematic netlist + the BSDL files
> for a couple complex chips - and give me a SVF file or something
duane> [I want a board test feature]
> How does those higher end tester like Agilent 3070 in circuit tester
work?
> Do they require extra add-on for JTAG related stuff like Boundary Scan?
> Do they use BDSL files? I know they can flash some MCUs but not all.
> Last time we have to use off-lin
Hi all,
Since my last Status Update, there has been quite a bit more activity
than I was expecting. The mailing list continues to surge with patches,
most of which have now been committed to the repository. In addition to
these issues, I went back a little further and picked up a few things
that
On Thu, 2009-05-28 at 18:16 -0700, David Brownell wrote:
> Provide basic documentation for some of the other flash drivers.
>
> avr ... looks incomplete, may work with one AVR8 microcontroller
> ecosflash ... can't find docs
> lpc288x ... an NXP part, driver seems lpc2888-specific
> ocl ... so
Provide basic documentation for some of the other flash drivers.
avr ... looks incomplete, may work with one AVR8 microcontroller
ecosflash ... can't find docs
lpc288x ... an NXP part, driver seems lpc2888-specific
ocl ... some arm7/arm9 thing, can't find docs
pic32mx ... looks incomplete, fo
On Fri, May 29, 2009 at 7:22 AM, Duane Ellis wrote:
> No - actually it is useful for other purposes... a method to flash something
> - however slow it may be - is better then no method to flash something, or
> the ability to flash a board with a CPU you do not support.
>
> UrJTAG's approach is to
Alan Carvalho de Assis wrote:
> Hi Duane,
>
> On 5/27/09, Duane Ellis wrote:
>
>> FYI - most of UrJTAG's support is *BOUNDARY*SCAN* - based external chip
>> flash programing via boundary scan
>>
>>
> Arggg, then it will not help too much!
No - actually it is useful for other purposes... a
On Thu, 2009-05-28 at 14:55 -0700, David Brownell wrote:
> Start converting the architecture-specific commands to @deffn format,
> reviewing against the code.
>
> * armv4_5 disassemble ... now documented; although Jazelle code
> is not handled
>
> * It's "armv4_5 core_state" not "core_mod
On Thursday 28 May 2009, Øyvind Harboe wrote:
> In the mists of time SRST & TRST probably had some
> well defined function and meaning.
I think they still *do* ... but it seems vendors
have felt free to play with at least TAP resets in
ways that prevent tools that conform only to JTAG
specs from w
On Thursday 28 May 2009, Nico Coesel wrote:
> An 'erase all' command would be nice. A complete erase is
> often required. It is a big plus for automated programming.
> One thing less to detect.
-ENOPATCH
:)
___
Openocd-development mailing list
Open
Start converting the architecture-specific commands to @deffn format,
reviewing against the code.
* armv4_5 disassemble ... now documented; although Jazelle code
is not handled
* It's "armv4_5 core_state" not "core_mode"; although Jazelle state
is not handled
* arm7/9 "debug" comma
On Thursday 28 May 2009 12:57:38 massimiliano cialdi wrote:
> Maybe the opensource libftdi? Do I need to try with ftd2xx driver
> provided by Amontec? I don't think that is for 64bit systems, isn't
> it?
Hi,
You could try ftd2xx lib directly from ftdichip -- they have x86_64 version.
Here is li
>On Thursday 28 May 2009, Spencer Oliver wrote:
>>
>> One point i would make - you have added a comment that the mass_erase cmds
>> are pointless.
>> Ttue the same thing can be acheived using erase_address or erase_sector but
>> you need to know the flash info.
>>
>> mass_erase enables the whole
On Thu, May 28, 2009 at 5:41 PM, Øyvind Harboe wrote:
> There ARE interfaces that do not have TRST and SRST both, but
> really one is much better off considering reset_config a configuration
> on how to operate the target. If TRST support is *required* by the target,
> e.g. XScale, then interfaces
On Thursday 28 May 2009, Spencer Oliver wrote:
>
> One point i would make - you have added a comment that the mass_erase cmds
> are pointless.
> Ttue the same thing can be acheived using erase_address or erase_sector but
> you need to know the flash info.
>
> mass_erase enables the whole device to
In the mists of time SRST & TRST probably had some
well defined function and meaning.
However, over time MCU vendors have repurposed these
signals, tied them to other signals, etc. for various mysterious
and more or less well intended purposes.
The reset_config doc should explain that what SRST a
On Thu, May 28, 2009 at 5:12 PM, Spencer Oliver wrote:
> Hi,
>
> I notice that the meminfo cmd seems to be zylin specific
> (ecosboard.c/ioutil.c).
> Currently this is in the openocd texi - this should really be removed.
This is not Zylin specific. This is useful for embedded hosts to
check how m
On Wed, May 27, 2009 at 11:25 PM, Magnus Lundin wrote:
> Michael Schwingen wrote:
>> Magnus Lundin wrote:
>>
>>> Michael Bruck wrote:
>>>
>>>
On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin wrote:
> move to TLR works for all current states. It is 7 steps with TMS high,
> t
Hi,
I notice that the meminfo cmd seems to be zylin specific
(ecosboard.c/ioutil.c).
Currently this is in the openocd texi - this should really be removed.
Thoughts?
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Just took a quick look and the one thing that jumped out at me was your JTAG
speed. jtag_speed is a depreciated command ... it should be jtag_khz. I
too have a eval board based on a ARM926EJS core ... it is a Atmel
at91sam9260ek based board. The thing I ran into was my board initially runs
using
>
> Here are more doc updates
>
> - get rid of most PDF generation errors, like the
>"line too long" ones, as well as the "can't do
>sane linebreak" warnings
>
> - restructure flash driver descriptions so each
>driver's info is in one place, not scattered
>through up to three l
Hi Duane,
On 5/27/09, Duane Ellis wrote:
> FYI - most of UrJTAG's support is *BOUNDARY*SCAN* - based external chip
> flash programing via boundary scan
>
Arggg, then it will not help too much!
> There is a variant/fork of UrJTAG - (link below) that ADI supports - a
> private fork ADI maintains
**ALL**
This subject of this thread no longer is about "OpenOCD" or JTAG.
It should not remain on *THIS* (a jtag debugging mailing list) and
should end (on this list) now.
If you feel you should reply, please do so *off*list*
-Duane
___
Openocd-dev
I tried openocd r1836 and r1938 with the same results.
I need to flash an AT91SAM7X256 (the board is evaluation buord from
atmel) with an Amontec jtagkey-tiny.
My PC runs ubuntu linux 8.10 64bit, and I use libftdi 0.16 (configured
as defaults)
PC is an intel core2 q8300 and 4GB ram
I run openocd
> -Oorspronkelijk bericht-
> Van: openocd-development-boun...@lists.berlios.de
> [mailto:openocd-development-boun...@lists.berlios.de] Namens
> Michel Catudal
> Verzonden: donderdag 28 mei 2009 5:33
> Aan: Duane Ellis; openocd-development
> Onderwerp: Re: [Openocd-development] NEC V850 Co
30 matches
Mail list logo
