Committed.
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
Fred Koehler wrote:
> hi,
>
> I've tested 1 and 2 as Dirk suggested. With both versions I get the
> same results. I'm able to connect jtag consistently and from a telnet
> session issue the omap3_dbginit command. Lots of improvement from the
> last time I tried.
Hi all,
Thanks Dirk's
David Brownell wrote:
> On Tuesday 25 August 2009, Magnus Lundin wrote:
>> * Eclipse must be installed with correct scripts and addons to relibly
>> make gdb talk to OpenOCD
>
> I'd like to see a writeup of what's involved with
> that for current Eclipse versions become part of
> the User's Guide
hi,
I've tested 1 and 2 as Dirk suggested. With both versions I get the
same results. I'm able to connect jtag consistently and from a telnet
session issue the omap3_dbginit command. Lots of improvement from the
last time I tried.
I try halt, resume, halt and that consistently produces
Clock updates/fixes for the Stellaris flash driver:
- Bugfixes:
* internal osc: it's *12* MHz (not 15 MHz) on _current_ chips
+ except new Tempest parts where it's 16 MHz (and calibrated!)
+ or some old Sandstorm ones, where 15 MHz was valid
* crystal config:
+ read a
On Tuesday 25 August 2009, Øyvind Harboe wrote:
> > I see no problem ... TAP_RESET is a stable state, and
> > JTAG adapters are allowed to let TCK run freely there.
>
> But that's not what the code is doing. It goes to TAP_RESET,
> then cycles 100 times in runtest idle and then back to TAP_RESET..
On Tuesday 25 August 2009, Magnus Lundin wrote:
> * Eclipse must be installed with correct scripts and addons to relibly
> make gdb talk to OpenOCD
I'd like to see a writeup of what's involved with
that for current Eclipse versions become part of
the User's Guide ...
___
Freddie Chopin wrote:
> Rohit Chandel pisze:
>
>> Is there any quick test to find out that openocd is installed correctly?
>>
>
> use it.
>
>
That is funny, and true.
But the OpenOcd application is almost always installed correctly and
from a users point of view there are lots of thing
Rohit Chandel pisze:
> Is there any quick test to find out that openocd is installed correctly?
use it.
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Committed.
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
Committed.
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
Committed.
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
Committed.
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
Committed.
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
> I see no problem ... TAP_RESET is a stable state, and
> JTAG adapters are allowed to let TCK run freely there.
But that's not what the code is doing. It goes to TAP_RESET,
then cycles 100 times in runtest idle and then back to TAP_RESET
I guess I would be more comfortable with a change that
David Brownell wrote:
> On Friday 21 August 2009, Dirk Behme wrote:
>> While reading in the git thread the keyword "branch":
>>
>> What's about a "beagle-testing" or similar branch with the patches
>> mentioned above?
>
> Feel free to set up such a GIT branch in a repository
> you create ... :)
More jtag_add_reset() cleanup:
Unify the handling of the req_srst parameter, and rip out a
large NOP branch and its associated FIXME. (There didn't seem
to be anything that needs fixing; but that was unclear since
the constraints were scattered all over the place not unified.)
---
src/jtag/core.
On Friday 21 August 2009, Dirk Behme wrote:
> While reading in the git thread the keyword "branch":
>
> What's about a "beagle-testing" or similar branch with the patches
> mentioned above?
Feel free to set up such a GIT branch in a repository
you create ... :)
___
Various updates to 0.3.0 NEWS
---
NEWS | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
--- a/NEWS
+++ b/NEWS
@@ -1,13 +1,30 @@
-This file should include items worth mentioning in the
-OpenOCD openocd-0.2.0 source archive release.
-
-The following areas of OpenOC
Tweak disassembly commands:
For ARMv4/ARMv5:
- better command parameter error checking
- don't require an instruction count; default to one
- recognize thumb function addresses
- make function static
- shorten some too-long lines
For Cortex-M3:
- don't require an instruction count; d
Some jtag_add_reset() cleanup:
- Track whether TRST and/or SRST actually change:
* If they're not changing, don't ask the JTAG adapter to do anything!
(JTAG TCK/TMS ops might still be used to enter TAP_RESET though.)
* Don't change their recorded values until after the adapter says
More jtag_add_reset() cleanup:
Unify the handling of the req_tlr_or_trst parameter. Basically,
JTAG TMS+TCK ops ("TLR") is always used ... unless TRST is a safe
option in this system configuration.
---
src/jtag/core.c | 35 ++-
1 file changed, 18 insertions(+),
Accomodate targets which don't support various target-specific
reset operations. Maybe they can't; or it's a "not yet" thing.
Note that the assert/deassert operations can't yet trigger for
OMAP3 because resets currently include JTAG reset in all cases,
resetting the ICEpick and thus disabling the
On Tuesday 25 August 2009, Øyvind Harboe wrote:
> 01_openocd_beagle.patch is problematic because it modifies the behavior
> for *all* targets.
>
> Thoughts?
I see no problem ... TAP_RESET is a stable state, and
JTAG adapters are allowed to let TCK run freely there.
> We need some more general m
No worry's mate!
Ferdinand
Pieter Conradie wrote:
>
> Hi Gary and Ferdinand,
>
>
>
> Mea Culpa. I broke the jtag_ntrst_delay in target/at91sam9260.cfg. It
> worked fine on my target board and the AT91SAM9260-EK. There is
> something funny with the target reset timing of the different Atmel
>
David Brownell wrote:
> On Tuesday 25 August 2009, Matt Hsu wrote:
>
>> The problem is I would like to issue commands such as reset halt,
>> bp, resume. The source code shown their implementation are NULL.
>>
>> So I'm curious why coretex_a8 does not have these support?
>>
>
> Because nob
On Tuesday 25 August 2009, Dirk Behme wrote:
> - Fix "soft_reset_halt" segfault
Patch in the works ...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Tuesday 25 August 2009, Michael Schwingen wrote:
> > That one example shouldn't go *between* the @deffn blocks ...
> > it's part of the preceding @deffn, giving the bit semantics,
> > not a free-standing chunk of text.
> >
>
> I must admit I do know nothing about texinfo.
>
> How about this
On Tuesday 25 August 2009, Michael Schwingen wrote:
> Luca Ottaviano wrote:
> > 2 - No documentation whatsoever to start using Openocd: when using a
> > jtag interface you need to learn about libusb-win32 drivers, the
> > difference between libusb versions (libusb0.1, libusb1.0, libusb-filters
>
On Tuesday 25 August 2009, Matt Hsu wrote:
> The problem is I would like to issue commands such as reset halt,
> bp, resume. The source code shown their implementation are NULL.
>
> So I'm curious why coretex_a8 does not have these support?
Because nobody submitted patches implementing them yet.
Ok, I did it... but how do i make sure that drivers have installed
correctly?
I used FTClean.exe to remove all FTDI drivers and then installed the new
ones.
In Device manager under "LibUSB-Win32 Devices" I have got an entry for
"Olimex OpenOCD JTAG TINY A".
Also in driver Properties-> Driver detai
On Tue, Aug 25, 2009 at 4:33 PM, Dirk Behme wrote:
> Øyvind Harboe wrote:
>>
>> I have committed all but 01_openocd_beagle.patch to hopefully get things
>> moving along
>>
>> 01_openocd_beagle.patch is problematic because it modifies the behavior
>> for *all* targets.
>>
>> Thoughts?
>
> You mi
Rohit Chandel pisze:
> It might seem silly question for an experienced person but please
> excuse for this. Does that mean that I need to first install the the
> drivers which came along with the ARM-USB-TINY on a CD and then
> uninstall the driver for JTAG. And then install libusb-
Øyvind Harboe wrote:
> I have committed all but 01_openocd_beagle.patch to hopefully get things
> moving along
>
> 01_openocd_beagle.patch is problematic because it modifies the behavior
> for *all* targets.
>
> Thoughts?
You might have noticed that I'm not really an expert of OpenOCD's code
Let's try to organize this a little and summarize the status:
1. Last time I tried was *r2604*:
https://lists.berlios.de/pipermail/openocd-development/2009-August/010035.html
To reproduce this, you have to apply the four patches in attachment of
that mail to r2604.
Fred and Matt: Please try
Committed.
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
Hi Gary and Ferdinand,
Mea Culpa. I broke the jtag_ntrst_delay in target/at91sam9260.cfg. It worked
fine on my target board and the AT91SAM9260-EK. There is something funny with
the target reset timing of the different Atmel AT91SAM9xx targets and
jtag_ntrst_delay/jtag_nsrst_delay, but I have n
Øyvind Harboe wrote:
> Did you try with the patches I committed today?
>
Hi Øyvind,
Thanks for your reply.
Yes. I applied the patch your committed. It definitely works.
The jtag session could be established.
The problem is I would like to issue commands such as reset halt,
On Tue, Aug 25, 2009 at 1:17 PM, Matt Hsu wrote:
> Øyvind Harboe wrote:
>>
>> Did you try with the patches I committed today?
>>
>
> Hi Øyvind,
>
> Thanks for your reply.
> Yes. I applied the patch your committed. It definitely works.
> The jtag session could be established.
>
> The probl
Did you try with the patches I committed today?
--
Ø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/listin
Fred Koehler wrote:
> hi,
>
> http://elinux.org/BeagleBoardOpenOCD reports success with using
> OpenOCD and the Flyswatter to establish a JTAG connection with the
> Beagle board. I've tried to reproduce these steps but am having some
> issues.
>
Hi Fred,
No one is an island.
I'm trying
Luca Ottaviano wrote:
> 2 - No documentation whatsoever to start using Openocd: when using a
> jtag interface you need to learn about libusb-win32 drivers, the
> difference between libusb versions (libusb0.1, libusb1.0, libusb-filters
> and so on), Vista issues (32-bit differs from 64-bit), jtag
On Tue, Aug 25, 2009 at 5:26 PM, Luca Ottaviano wrote:
> I can summarize the problems I've had so far with Windows builds of Openocd:
> 1 - No official exe on the website: building with Cygwin or MinGW under
> Windows it's *really* a pain. I really appreciate Freddie's work here.
I think this is a
Zach Welch ha scritto:
> Freddie,
>
> I appreciate all the effort that you have put into the Windows build,
> and I hope you will continue to work with the community to improve it.
>
> That does not make it acceptable for you to continue trolling here.
IMO, I think he's frustrated by the number
On Tue, Aug 25, 2009 at 3:39 PM, Gary Carlson wrote:
>
> I am still working through some remaining issues with the "reset init"
> command, but at this point I am inclined to believe those are related to
> configuration issues with the at91sam9g20 processor I am using rather then
> software bugs in
I'm actually doing this in a GUI application. If you set the debug_level
to 2 you'll see the progress.
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Luca Ottaviano
> Sent: dinsdag 25 augustus
Hi Ferdinand,
That is indeed what was causing the problem.
I didn't notice a change had been made to that particular configuration
file. Those files rarely evolve and given that the modification was so
subtle, I completely missed it.
I am still working through some remaining issues with the "re
Hi all,
it would be nice for Openocd to output the progress when flashing a
target, something like mplayer does.
Two use cases I'm thinking of are command line users, who will see
activity report, and other processes (eg. GUIs) which can launch Openocd
in background and report progress to the us
Committed.
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
David Brownell wrote:
> That one example shouldn't go *between* the @deffn blocks ...
> it's part of the preceding @deffn, giving the bit semantics,
> not a free-standing chunk of text.
>
I must admit I do know nothing about texinfo.
How about this version?
cu
Michael
Index: src/target/xscal
Hi,
a small CFI cleanup bit that has been in my local version for some time.
cu
Michael
Index: src/flash/cfi.c
===
--- src/flash/cfi.c (revision 2606)
+++ src/flash/cfi.c (working copy)
@@ -74,7 +74,7 @@
static void cfi_fixup_atmel
On Tue, Aug 25, 2009 at 3:22 PM, Rohit Chandel wrote:
> On Mon, Aug 24, 2009 at 9:02 PM, Freddie Chopin
> wrote:
>> >the inf file is fine, but you need the "original" drivers for the RS-232
>> >channel. You may of course ignore that channel if you don't need it.
>
> Does ignoring means that I shou
Sorry the link given by me is not a direct one. I meant following device at
Olimex website:
*ARM-USB-OCD* 3-IN-1 FAST USB ARM JTAG, USB-TO-RS232 VIRTUAL PORT AND POWER
SUPPLY 5-9-12VDC DEVICE (SUPPORTED BY OPENOCD OPEN SOURCE ARM DEBUGGER)
On Tue, Aug 25, 2009 at 12:52 PM, Rohit Chandel wrote:
>
On Mon, Aug 24, 2009 at 9:02 PM, Freddie Chopin wrote:
> 1st of all - write to the list
>
> >It does have a USB <=> RS-232 converter. FT2232 is like 2 devices in one
> >chip - one is the JTAG (that's FT2232 channel A), and the other is
> >RS-232 converter (that's FT2232 channel B). Those two devi
This is fixed in svn head now.
--
Ø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-develop
Committed.
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
Committed.
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
Committed.
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
Committed.
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
Committed.
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
I have committed all but 01_openocd_beagle.patch to hopefully get things
moving along
01_openocd_beagle.patch is problematic because it modifies the behavior
for *all* targets.
Thoughts?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Appended is th
61 matches
Mail list logo
