- J-link stability and compatibility
- CFI driver chip/bus width issues (status??)
- PIC32 support (long-term)
Should we make the old tms sequences default for 0.2? I don't like it
from the point of view that we can't then *force* users to test it.
On Tue, 2009-05-19 at 08:04 +0200, Øyvind Harboe wrote:
- J-link stability and compatibility
- CFI driver chip/bus width issues (status??)
- PIC32 support (long-term)
Should we make the old tms sequences default for 0.2? I don't like it
from the point of view that we can't then *force*
The other choice is to use the libusb-win32 device driver.
In that case, you create the INF using the INF wizard and
replace the stock Segger driver with libusb-win32 device
driver.It works better than the filter driver and works under
Vista 32 bit. But in this case, you can no longer use
On Tue, May 19, 2009 at 2:38 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
I have tested both the filter and native driver under winxp.
Never tested the filter driver under vista64, but the native driver works.
Thanks for the confirmation. I will try out the libusb-win32 device driver
for
Does the LPC2148 (which I have) exhibit the same problem?
I can not test the attached patch here, but it is intended to
allow switching between the long(old) or new (short)
tms_sequence tables. The patch uses the short table as default.
Try:
tms_sequence long
tms_sequence short
-Oorspronkelijk bericht-
Van: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] Namens
Zach Welch
Verzonden: dinsdag 19 mei 2009 7:49
Aan: openocd-development
Onderwerp: [Openocd-development] milestone strategy [3 of 4]
Hi all,
On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
Does the LPC2148 (which I have) exhibit the same problem?
I can not test the attached patch here, but it is intended to
allow switching between the long(old) or new (short)
tms_sequence tables. The patch uses the
On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
Does the LPC2148 (which I have) exhibit the same problem?
I can not test the attached patch here, but it is intended to
allow switching between the long(old) or new (short)
tms_sequence tables. The patch uses the
On Mon, May 18, 2009 at 10:05 PM, David Brownell davi...@pacbell.net wrote:
Minor NAND updates:
- Comment which IDs are museum IDs: obsolete first-gen parts,
some with IDs that are reused with newer parts, 256-byte pages.
Linux doesn't support these by default, and OpenOCD rejects
On Mon, May 18, 2009 at 10:49 PM, Zach Welch z...@superlucidity.net wrote:
Hi all,
Since this weekend, I have spent some time working on a set of Perl
scripts to prototype the back-end system that will aggregate the data
and present it for review (pre-analysis).
I started on this to
On Tuesday 19 May 2009, Øyvind Harboe wrote:
I don't know anything about nand, but I'll be happy to commit this if
you believe the chances of regressions are slight.
Do it, then.
___
Openocd-development mailing list
On Tue, May 19, 2009 at 2:55 PM, Nico Coesel ncoe...@dealogic.nl wrote:
Short note from the marketing department: shouldn't 0.2.0 be released as
1.0? The 0.2.0 version number may scare potential users away thinking
OpenOCD is not ready for any serious work.
But I notice libusb 0.1 is forever
Øyvind Harboe wrote:
On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
Does the LPC2148 (which I have) exhibit the same problem?
I can not test the attached patch here, but it is intended to
allow switching between the long(old) or new (short)
tms_sequence
This is a series of patches against r1834 that further simplify the
code in jtag.c to make it more readable.
patch 01 is a rather large one that renames the function arguments
'num_fields' and 'fields' into 'in_num_fields' and 'in_fields'
The rationale here is that almost all of these functions
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of JLink.
This should improve the situation.
Hopefully the same trick works under win and mac os.
Have a nice day
Magnus
Index: src/jtag/jlink.c
On Tue, 2009-05-19 at 10:53 +0200, Magnus Lundin wrote:
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of JLink.
Let's not remove the test, even if it only works with newer versions.
For now, I
zach - Missing an 'email.pl' script to provide a gateway
zach from e-mail messages sent by the automated tester.
I question this, as email like this that is not sent from a proper client
through approved channels is/could be often blocked by either the corporate it
dept (my case @ office) - or
Hello Magnus,
thanks for your patch... that is half the way needed to make my V3 JLink work.
The other thing is that at least mine doesn't support the EMU_CMD_HW_JTAG3
command. This is not documented in the USB protocol description as far as I
know. My JLink doesn't answer at all to this
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches touch just src/flash/cfi.c file and should apply in this
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches
Hi, I've been doing quite a lot of beating my head against open OCD
over the last few weeks in order to get it working with balloonboard.
Results detailed at
http://www.balloonboard.org/balloonwiki/Balloon3OpenOCD and
http://www.balloonboard.org/balloonwiki/BalloonJTAGing
I have various comments,
Hi,
On Tue, May 19, 2009 at 12:43, Wookey woo...@wookware.org wrote:
But we've been using these dongles for years to program these boards,
and so have others, so clearly it can work.
Is there some way to make openOCD behave in a sufficiently
simple-minded manner to work with old-fashion
Wookey == Wookey woo...@wookware.org writes:
Hi,
Wookey 1) Is there a way to output a user message? Currently
Wookey flash write_image erase kernel/zImageInitrd 0x20 bin
Wookey involves a 10-minute pause. It would be great if there was a way to
Wookey display
Wookey 'programming
Committed.
Thanks!
Note that you can list several -expected-id on the same command line.
W.r.t. reset capabilities then really for XScale it is probably better to
stick with a dongle that can assert srst trst separately.
--
Øyvind Harboe
Embedded software and hardware consulting services
+++ Peter Korsgaard [2009-05-19 13:41 +0200]:
Wookey == Wookey woo...@wookware.org writes:
Hi,
Wookey 1) Is there a way to output a user message? Currently
Wookey flash write_image erase kernel/zImageInitrd 0x20 bin
Wookey involves a 10-minute pause. It would be great if there
+++ Øyvind Harboe [2009-05-19 13:54 +0200]:
Committed.
Thanks!
Note that you can list several -expected-id on the same command line.
OK. that's good, but I'm not sure it addresses teh more general
question about why isn't the cpu.cfg file supplying those default IDs
instead of 0x?
Xiaofan Chen wrote:
On Mon, May 18, 2009 at 11:09 PM, Gene Smith g...@chartertn.net wrote:
Mine says: Updating firmware: J-Link compiled Feb 20 2006 18:20:20 --
Update --
Mine says: Replacing firmware J-Link compiled Dec 2 2004 09:13:33
Mine says: S/N : -3
Kind of strange. Could you try
On Tue, May 19, 2009 at 4:53 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of JLink.
This should improve the situation.
Hopefully the same trick
On Tuesday 19 May 2009 03:19:06 pm Gene Smith wrote:
Info : J-Link compiled Dec 2 2004 09:13:33
That seems like a very very old firmware version. And I just remembered
something...
When I got my JLink, it was on a somewhat old firmware version as well...
Linux segger tool did nothing at
I have checkout r1836 of opeocd
I use ubuntu 8.10 64bit and amontec jtagKey tiny
I downloaded libftd2xx0.4.16_x86_64
and I configured as follow
$ ./configure --prefix=/opt/openocd --enable-ioutil --enable-httpd
--enable-ft2232_ftd2xx --with-ftd2xx-lib=static
Magnus Lundin wrote:
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of JLink.
This should improve the situation.
Hopefully the same trick works under win and mac os.
Have a nice day
On Tue, May 19, 2009 at 9:30 PM, Gene Smith g...@chartertn.net wrote:
Running openocd command or the segger utility commands does produces no
new messages. (FYI: this is fedora 8 with last possible updates.) But
openocd commands to the jlink cause the LED to go off but segger
commands don't.
Hi,
The following patch has been in my local tree for a while.
It simply brings the mips step/resume interrupt handling inline with the
rest of openocd.
Tested on svn head using pic32mx target.
No objections i will commit.
Cheers
Spen
mips32_int.patch
Description: Binary data
On Tue, May 19, 2009 at 10:36 PM, Xiaofan Chen xiaof...@gmail.com wrote:
Now I see the same behavior of my black J-Link. This is even
after adding part of the patch from Magnus to correct the endpoint.
Once the LED goes off after running openocd, run Segger's
utility and you will know that it
On Tue, May 19, 2009 at 10:43 PM, Xiaofan Chen xiaof...@gmail.com wrote:
Now if I compare V6 to V3 based on some simple test, it
seems my V6 works (no problem with halt target and single step)
and my V3 does not (can not halt target and step).
But between yesterday (V1809) and today (V1836),
Benjamin Schmidt wrote:
On Tuesday 19 May 2009 03:19:06 pm Gene Smith wrote:
Info : J-Link compiled Dec 2 2004 09:13:33
That seems like a very very old firmware version. And I just remembered
something...
When I got my JLink, it was on a somewhat old firmware version as well...
Linux
Hi
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Error: J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (-110)
Open OCD seems to get reasonable ansvers from first two JLink commands.
The /* query hardware maximum memory block */ should not be run for this
On Tue, May 19, 2009 at 9:39 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Tue, May 19, 2009 at 4:53 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of
2009/5/19 Raúl Sánchez Siles rsanch...@infoglobal.es:
Looks like the problem is on ioutils. I don't know what exactly they are and
if you really need them, but if you don't need it try configuring without
specifying the --enable-ioutil flag.
ok
I have disabled httpd and ioutin and I added
Zach Welch pisze:
On Tue, 2009-05-19 at 08:04 +0200, Øyvind Harboe wrote:
Should we make the old tms sequences default for 0.2? I don't like it
from the point of view that we can't then *force* users to test it.
https://lists.berlios.de/pipermail/openocd-development/2009-May/006762.html
I
We want to make OpenOCD robust against the particular path
taken do we not?
This is black jtag controller magic, I have tested short
table for imx21 and omap3530 a lot, seems cortex-m3 does not
like the startup sequences.
Try to change the first row in the short table, the out
Hello Øyvind,
yes the same behaviour with a LPC2148 here.
Regards,
Michael
-Ursprüngliche Nachricht-
Von: oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com]im Auftrag
von Øyvind Harboe
Gesendet: Montag, 18. Mai 2009 22:05
An: Michael Fischer
Cc: Openocd-Dev
Betreff: Re:
Hello Øyvind,
yes the same behaviour with a LPC2148 here.
Does my patch or using tms_sequence long fix the problem?
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Gene Smith wrote:
Gene Smith wrote:
Benjamin Schmidt wrote:
On Tuesday 19 May 2009 03:19:06 pm Gene Smith wrote:
Info : J-Link compiled Dec 2 2004 09:13:33
That seems like a very very old firmware version. And I just remembered
something...
When I got my JLink, it was on a somewhat old
Hello list,
I want to build a static version under Mac OS X. But the
new build with the libtool produce some libraries too.
I do not understand why this was changed, does it have any
advantages? In the moment it looks that it need more time
to build.
Best regards,
Michael
Hello Rick,
I believe you can disable the building of the shared library with --
disable-shared to configure.
Thanks, this works here.
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Tue, 2009-05-19 at 00:09 -0700, Paul Thomas wrote:
On Mon, May 18, 2009 at 10:49 PM, Zach Welch z...@superlucidity.net
wrote:
Hi all,
Since this weekend, I have spent some time working on a set of
Perl
scripts to prototype the back-end system that
Hi,
In replacement.h standard integer type is used but stdint.h isn't included.
2009-05-20
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Wed, 2009-05-20 at 02:22 +0800, SimonQian wrote:
Hi,
In replacement.h standard integer type is used but stdint.h isn't
included.
However, types.h includes it, and that file should always be included
before replacements.h. In what file do you see otherwise?
Cheers,
Zach
In file included from ../../config.h:264,
from binarybuffer.c:24:
./replacements.h:213: error: syntax error before Elf32_Addr
..
replacements.h is included in config.h.
I check the config.h and system.h, types.h is not included.
2009-05-20
Best Regards, Simon Qian
In file included from ../../config.h:264,
from binarybuffer.c:24:
./replacements.h:213: error: syntax error before Elf32_Addr
..
replacements.h is included in config.h.
I check the config.h and system.h, types.h is not included.
try running bootstrap again.
If
The cosmetic cleanups should IMO just merge.
On Tuesday 19 May 2009, Michael Bruck wrote:
patch 01 is a rather large one that renames the function arguments
'num_fields' and 'fields' into 'in_num_fields' and 'in_fields'
The rationale here is that almost all of these functions take some
input
On Monday 18 May 2009, Øyvind Harboe wrote:
Should we make the old tms sequences default for 0.2?
Not unless there's a complete failure of testing, or
they prove to be deeply flawed, IMO.
Plan on using the new ones, fixing them (e.g. merging the
fix Spencer sent earlier today), and getting a
On Monday 18 May 2009, Zach Welch wrote:
The tactical goal of each release should to be focus on delivering a
product with steadily increasing stability and device support (whether
host, target, or interface).
I can't quite imagine what other goals might be. ;)
So ... releases every three
On Wed, May 20, 2009 at 12:05 AM, David Brownell davi...@pacbell.net wrote:
patch 02 renames a local variable 'x' into 'num_taps' to describe what it
means
Except I don't like seeing declaration blocks split into
sections with whitespace:
{
jtag_tap_t *tap;
- int x;
On Wed, May 20, 2009 at 12:53 AM, Gene Smith g...@chartertn.net wrote:
Using the Magnus patch, I just noticed that after openocd starts the
jlink LED goes off indicating further USB comm is not possible (it seems
to be true) and telnet cmds fail. If I try to restart oocd, I again get
the 3
On Wed, May 20, 2009 at 12:04 AM, Gene Smith g...@chartertn.net wrote:
I forgot that I have to run ./start as root or sudo or you get this error.
It is not difficult to apply the correct udev rules to be able to run openocd
or ./start as normal user. OpenOCD has an example in the distribution.
On Wed, 20 May 2009, Michael Bruck wrote:
On Wed, May 20, 2009 at 12:05 AM, David Brownell davi...@pacbell.net wrote:
(By the way, suggestion: only one patch per mail. It's painful
enough to try reviewing attachments, especially text/plain ones
that won't get the syntax highlighting that
On Wed, May 20, 2009 at 12:53 AM, Gene Smith g...@chartertn.net wrote:
OK, one more reply to self...
Using the Magnus patch, I just noticed that after openocd starts the
jlink LED goes off indicating further USB comm is not possible (it seems
to be true) and telnet cmds fail. If I try to
Hey Chitlesh,
I have created a SPEC file that seems to work okay against the 0.1.0
release of OpenOCD. Once a 0.2 gets a bit closer, or even on SVN head
for testing, I'll look at the spec file again. I had to use chrpath to
fix some rpath issues, so I hope that's okay. These are the only
On Tuesday 19 May 2009, Wookey wrote:
2) base.cfg just specifies the default port info:
-
telnet_port
gdb_port
tcl_port
-
But if I don't put this in I get warning messages about how these are
not specified- using defaults. Is that really necessary? Shouldn't it
Hey all,
I've done another section of the documentation in arm7_9_common.c and
arm7_9_common.h. I found a couple of typos and fixed them. I also
changed all 'struct target_s' to 'target_t' to keep things consistent.
I've built and tested against my SAM7 board and it seems to be working
From my cursory reading, everything looks fine and straightforward.
Since you marked this as an RFC, I'll hold off committing until it is
resent to the list.
Rick
On May 19, 2009, at 3:54 AM, Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank
The following patch combines my previous patch with most of Ben's patch.
It can use both EMU_CMD_HW_JTAG2 and EMU_CMD_HW_JTAG3
It defaults to EMU_CMD_HW_JTAG2 so it should work with all interfaces
but EMU_CMD_HW_JTAG3 is recommended by SEgger, you can change the
behaviour with
We, as a community, seem to have adopted C99. As such, using C99
style declarations inside a block is fine. In some cases it can
really simplify the flow of the code.
Rick
On May 19, 2009, at 3:05 PM, David Brownell wrote:
The cosmetic cleanups should IMO just merge.
On Tuesday 19 May
On Tuesday 19 May 2009, Rick Altherr wrote:
We, as a community, seem to have adopted C99. As such, using C99
style declarations inside a block is fine. In some cases it can
really simplify the flow of the code.
In that case let's make the declarations stand out properly
code
On May 19, 2009, at 9:53 PM, David Brownell wrote:
On Tuesday 19 May 2009, Rick Altherr wrote:
We, as a community, seem to have adopted C99. As such, using C99
style declarations inside a block is fine. In some cases it can
really simplify the flow of the code.
In that case let's make the
Committed in r1840-1849.
Rick
On May 19, 2009, at 1:46 AM, Michael Bruck wrote:
This is a series of patches against r1834 that further simplify the
code in jtag.c to make it more readable.
patch 01 is a rather large one that renames the function arguments
'num_fields' and 'fields' into
On May 19, 2009, at 7:36 AM, Michael Bruck wrote:
I have attached the final result of the changes I had planned for the
moment. One is a patch (against the patches I posted earlier today)
the others are the resulting files, since the patch is rather messy.
The changes are mainly restructuring
On May 19, 2009, at 7:41 AM, Spencer Oliver wrote:
Hi,
The following patch has been in my local tree for a while.
It simply brings the mips step/resume interrupt handling inline with
the
rest of openocd.
Tested on svn head using pic32mx target.
No objections i will commit.
Cheers
Spen
On Wed, May 20, 2009 at 7:14 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 19 May 2009, Dean Glazeski wrote:
changed all 'struct target_s' to 'target_t' to keep things consistent.
I'd rather do away with all typedefs myself, except maybe
for int variants. Ditto that *_t
On Tue, 2009-05-19 at 15:35 -0700, David Brownell wrote:
On Monday 18 May 2009, Zach Welch wrote:
The tables track reports from users detailing the results from running
the regression test suite. A report will specify the platform,
interface, and target or board that was tested by the
On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote:
On Tuesday 19 May 2009, Dean Glazeski wrote:
changed all 'struct target_s' to 'target_t' to keep things consistent.
I'd rather do away with all typedefs myself, except maybe
for int variants. Ditto that *_t convention.
Anyone
Hi all,
I have posted the prototype of my OpenOCD Support Database (scripts and
data files) at the following URL. [[Be nice to my server/bandwidth.]]
http://openocd.superlucidity.net/
The code can be downloaded piecemeal (in 'support_db/'). You can also
view the raw data files (in
77 matches
Mail list logo
