On Wednesday 27 May 2009, Zach Welch wrote:
Basically after these three patches, NOR and NAND
flash docs use parallel structure, and the command
index is much more filled out. The NOR docs are
now a *LOT* more complete and accurate.
Committed, r1936-1938. Very nice work. Keep 'em
-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 Core
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
**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
___
Hi Duane,
On 5/27/09, Duane Ellis open...@duaneellis.com 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
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 locations
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
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
On Wed, May 27, 2009 at 11:25 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
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,
On Thu, May 28, 2009 at 5:12 PM, Spencer Oliver s...@spen-soft.co.uk 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
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
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 be
On Thu, May 28, 2009 at 5:41 PM, Øyvind Harboe oyvind.har...@zylin.com 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.
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 be
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
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 commands
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
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
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_mode;
Alan Carvalho de Assis wrote:
Hi Duane,
On 5/27/09, Duane Ellis open...@duaneellis.com 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
On Fri, May 29, 2009 at 7:22 AM, Duane Ellis open...@duaneellis.com 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.
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,
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 ... some
On Fri, May 29, 2009 at 10:04 AM, Zach Welch z...@superlucidity.net 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
-
(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
finished
25 matches
Mail list logo
