Re: [Openocd-development] Fwd: [PATCH] mflash: add mflash configure feature

[Rick Altherr]

1) This needs to be broken up into multiple patches.
2) It looked like lots of error handling was removed rather than added
3) Not sure why the mflash code is being changed to use the mg  
prefix.  What is mg supposed to mean?
4) Lots of gratuitous formatting changes.  If we want to do these  
types of changes, please use the uncrustify config file in the root of  
the source tree.  Also, make that a separate patch so we can apply it  
without hunting for actual code changes.


Rick


On May 19, 2009, at 11:22 PM, Øyvind Harboe wrote:


I received this in private email.

Obviously it was intended for the list.


-- Forwarded message --
From: unsik Kim 
Date: Tue, May 19, 2009 at 10:19 AM
Subject: [PATCH] mflash: add mflash configure feature
To: Øyvind Harboe 


Hello?

I attached mflash patch.

changed files:
src/flash/mflash.c
src/flash/mflash.h
doc/openocd.texi

Add mflash configure feature.
Large file write and dump support.
Remove unused option from mflash bank command.
Improve error handling.
Reduce too long lines.
Use "mg_" as function prefix.

---
Regards,
unsik Kim 



--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] "Short" state table enabled as of r1827

[Øyvind Harboe]

Committed

Thanks!

Michael Fischer + you have tested it now and there is upcoming work in jtag.c,
so get this patch out of the way.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] arm7_9_common: Documentation and Typos

[Rick Altherr]

On May 19, 2009, at 10:42 PM, Zach Welch wrote:


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 feel strongly pro-typedef?


I think typedefs have their place, but I agree they are BAD when  
used in

header file declarations.



It all depends.  I've seen really horrible uses of typedefs and I've  
seen really good use of typedefs.  For example, an opaque handle that  
is provided to callers of an API to track a resource is really nice as  
a typedef.  Sure, you can use the socket approach and hand back an int  
or you could hand back a pointer to a forward-declared struct, but  
that makes the API unnecessarily ugly or confusing.  Instead, a  
typedef clarifies that the argument is a handle as opposed to an  
arbitrary int and allows an easy change in the backing type assuming  
everyone recompiles.


I'm not a fan of things like 'typedef uint32_t UInt32'.  That is  
redundant and only serves as a bad hack instead of a search and replace.


Why?  Because 'struct foo' can be forward-declared safely if it will  
be

used only for pointers.


If a header includes a 'typedef struct foo foo_t', you can safely  
write foo_t * if you want to include the header or 'struct foo *' if  
you don't.  The typedef just gets rid of the C oddities of putting  
structs and enums in their own namespaces.



 In turn, this allows header files to be
decoupled from one another.  Go back and look at the changes that I
started to decouple the headers and you will see me _removing_  
typedefs

to accomplish that mission.



Technically, the typedefs didn't need to be removed to accomplish  
that.  In fact, the removal of the typedefs can easily cause more  
confusion.  For simple structs, this isn't necessarily a problem, but  
more complex types easily show the benefits of typedefs.  Consider the  
following:


int list_item_next(struct item * head, struct item * cur, struct item  
** next);


versus

typedef enum {
  ...
} list_error_t;
typedef struct item * list_item_t;
typedef struct item * list_t;

list_error_t list_item_next(list_t head, list_item_t cur, list_item_t  
* next);


Technically both have the same behavior, but the second makes the  
expected arguments clearer (don't pass an arbitrary element as the  
head of the list, next is a value-return param, etc).  It also allows  
the API to change the underlying representations of the types without  
the caller changing (but a recompile might be necessary).



As a result, the changes in this patch result in the system being more
tightly coupled than it really needs to be (and takes it in the  
opposite

direction that it should be headed), so I am fairly strongly against
applying it without first seeing the typedef changes removed.



typedefs do not introduce strong coupling in any way.  There is still  
an option to use the forward declaration via the struct when  
necessary.  Of course, the use of the struct should only be reserved  
for those cases where it needs to be a forward declaration to avoid  
include loops.


Other than that, it looks great, and I am really appreciating the  
work!


Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd support database

[Øyvind Harboe]

I haven't looked into this, but essentially it is a database over what
worked in which version?

"when" should be svn #. The time the test was run isn't *that* interesting.

W.r.t. gathering these reports. It's harder to get users to run these smoketests
when everything is working fine than when OpenOCD is broken :-)

I was thinking that we could get a lot more
information if there was a command line tool to gather information required
to post a bugreport

That way every time someone has a bug, they can gather some info for
the smoketesting database.

Eventually I expect *most* bugs to be able to creep past *all* the smoketests.

So at the top of an email w/a bug report to the list there could be a link
to smoketests run in the database for the interface/target combination...

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] openocd support database

[Zach Welch]

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 'data/') and the output generated by the
'html.pl' script (in 'html/').  If you download the files, the data
directory needs to go inside the support_db directory, but that will
probably be immediately apparent on running the scripts.

I have staged to commit the scripts in tools/support_db, but the data
files should probably not be added.  Those can exist on the Web/mail
server (and migrate into a SQL DB at some point). 

What do others think?  Is this worth checking into the repository, or
should I organize some off-line churn first?

Cheers,

Zach


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] arm7_9_common: Documentation and Typos

[Zach Welch]

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 feel strongly pro-typedef?

I think typedefs have their place, but I agree they are BAD when used in
header file declarations.

Why?  Because 'struct foo' can be forward-declared safely if it will be
used only for pointers.  In turn, this allows header files to be
decoupled from one another.  Go back and look at the changes that I
started to decouple the headers and you will see me _removing_ typedefs
to accomplish that mission.

As a result, the changes in this patch result in the system being more
tightly coupled than it really needs to be (and takes it in the opposite
direction that it should be headed), so I am fairly strongly against
applying it without first seeing the typedef changes removed.

Other than that, it looks great, and I am really appreciating the work!

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] testing tools [4 of 4]

[Zach Welch]

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 "user",
> > along with the 'version' of OpenOCD, the test 'results', along with a
> > 'comment'.  In this description, words in double-quotes ('"')
> > effectively describe various primary tables, while the words in
> > single-quotes ("'") describe column fields.
> 
> Let me suggest a summary page with a matrix that mostly
> overlooks the specific boards involved, and focusses on
> more straightforward issues:
> 
> CPU/Platform JTAG Adapter/Interface
>ft2232parport   jlink   ...
> arm920t   g y r...
> arm926ejs g g y...
> xscaleg - -...
> mips  - - g
> avr8  y g -
> 
> 
> where a "g/green" indicates multiple positives, no negatives;
> a "y/yellow" indicates mixed results or only one positive;
> a "r/red" indicates more negatives than positives; and a
> blank indicates no results.  (Or some other metric which
> is useful and morphs easily to such a status panel display.)
> 
> That could be emailed to the list ... or turned into a web
> or wiki page.  In HTML form, maybe the body of the cell would
> be a link pointing to more details ... semi-fancy versions of
> this could highlight results for the *last* release, so it'd
> be easy to see notice regressions.
> 
> If such a page shows a lot of red, that would strongly suggest
> it's not ship-ready.  Too many blanks would show "not enough
> testing yet".  Rows or columns would show patterns indicating
> particular code needs work.
> 
> Key point:  without such a summary, it'll be hard to know
> where the problems (including big unknowns!) lurk.

I agree this will be the pinnacle of the display output produced from
the data; your description is pretty much spot on what I imagined when I
started coding.  My scripts are not quite there, but they are a start.
Someone can probably use what I have done and do exactly what we want.

Since these results will only be useful once we have them, I have been
trying to focus more on the collection and storage side, such that we
can make it easy for users to produce the required smoke test reports.
If it's not fairly easy, then we may not collect as many results as we
need to make everything turn green.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] arm7_9_common: Documentation and Typos

[Øyvind Harboe]

On Wed, May 20, 2009 at 7:14 AM, 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 feel strongly pro-typedef?

I think that typedefs are useful when a level of indirection is
needed, it is non-trivial to define the type(u32, u8, intptr_t, etc.)
or the type itself is horrible to spell out(pointer to a function
which takes a pointer to)

When the type is striaghtforward(int or struct), then typedef can
make things less readable. "typedef struct x x_t" is such an example.




-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] arm7_9_common: Documentation and Typos

[David Brownell]

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 feel strongly pro-typedef?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] mip32 interrupt disable

[Rick Altherr]

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
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development



Committed revision 1850.

--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] jtag.c cleanups

[Rick Altherr]

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 while leaving the actual
algorithms intact. The code is slightly stricter on the input data and
there is a small bugfix where output data from dr_scan may not have
the tap fields set correctly (but I think the consumers of this data
don't care). I also added some documentation for doxygen.

I would break this down into smaller patches if there is a consensus
to apply these changes.

Michael
big 
.txt>___

Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development



I like the changes, but, yes, please split it up into smaller patches.

--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Further simplifications in jtag.c

[Rick Altherr]

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 'in_num_fields' and 'in_fields'
The rationale here is that almost all of these functions take some
input fields and produce from that a new set of output fields. The
patch sets the stage to later be able to use a local variable 'field'
or 'fields' to refer to fields rather then the current endless
repetitions of cmd->cmd.scan->fields[...] while at the same time
making it clear which one is the input argument and which is the
output data.

patch 02 renames a local variable 'x' into 'num_taps' to describe  
what it means


patches 03-10
add a local variable 'scan_command_t * scan' to the functions to
replace lengthy 'cmd->cmd.scan' with 'scan' to make the code more
readable
and move scan_size and a few loop variables into the local scope where
they are actually used thus reducing clutter and potential for error.

The patch files include a short commit message.

Again none of these patches change any algorithm. They are all tested
here and compile and run on arm11 (although not all of these functions
are used in arm11).

Michael
d98b8a0 
.txt 
> 
< 
commit 
-04 
-604aaca 
.txt>c5c33a2.txt>e666f03 
.txt 
> 
___

Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Further simplifications in jtag.c

[Rick Altherr]

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 declarations stand out properly

code doing work
morecode morework
decl
codecode code

is hiding things relative to the usual "split decls from code
with blank lines" policy.  Make such decls stand out properly:
no less than they do at the beginning of a block.

And by the way, there's no way it can simplify code flow, since
declarations don't *change* code flow at all.





Sure.  I'm all for adding blank lines before and after any block of  
declarations.  To pick nits, it doesn't change the control or data  
flow, but it _does_ change the code flow.  Code flow is the  
readability and clarity of the code.  Good code flow means that user  
can understand what is happening in the algorithm.


--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Further simplifications in jtag.c

[David Brownell]

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 doing work
morecode morework
decl
codecode code

is hiding things relative to the usual "split decls from code
with blank lines" policy.  Make such decls stand out properly:
no less than they do at the beginning of a block.

And by the way, there's no way it can simplify code flow, since
declarations don't *change* code flow at all.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Further simplifications in jtag.c

[Rick Altherr]

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 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 fields and produce from that a new set of output fields. The
patch sets the stage to later be able to use a local variable 'field'
or 'fields' to refer to fields rather then the current endless
repetitions of cmd->cmd.scan->fields[...] while at the same time
making it clear which one is the input argument and which is the
output data.


Seems like it can hardly break anything, yes?  That does seem
to be useful clarity.


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;
   int nth_tap;
   int scan_size = 0;

+   int num_taps = jtag_NumEnabledTaps();


Just put the "int num_taps..." up where "int x" was.


+
   /* allocate memory for a new list member */
   jtag_command_t * cmd =  
cmd_queue_alloc(sizeof(jtag_command_t));


Or what you did in a few other places, "type * ptrvar" should
be just "type *ptrvar"; those are IMO neither simplifications
nor cleanups.  Ditto using the (IMO annoying) C99 feature where
declarations don't necessarily live at the beginning of a block.



Again none of these patches change any algorithm.


Making them all coding style fixes, not simplifications.
And at one point some new comments.


I liked #5 (other than the "type * ptrvar" issue), that does
make the code more clear:  p->q->r  ==> q->r is mostly better.


I'd kind of like to see a standard "indent" ruleset agreed on,
so that at least the things that tool handles well could be
somewhat automated.



(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 diffs do.)

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Magnus Lundin]

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


> jlink_hw_jtag  3
or
> jlink_hw_jtag  2

Autodetection can be done when we know which versions JLink can use what 
setting,  (-d3 logs of setup messages )


Have a nice day
Magnus


Xiaofan Chen wrote:

On Wed, May 20, 2009 at 12:53 AM, Gene Smith  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 restart oocd, I again get
the 3 failed retries on get caps and "don't worry" like before.  If I
revert to Benjamin's patch, it comes up clean with no errors. Now I can
do telnet commands with no problem (such as jlink_info, mdb, reg, etc).

Possibly the intention was to combine these patches, I am not sure. But
anyhow, for what its worth, it is now seems to be working for me with
Ben's patch. (I have not tried to do anything with gdb yet.)



I can see two big differences between the patches. In Ben's patch,
-#define EMU_CMD_HW_JTAG3   0xcf
+#define EMU_CMD_HW_JTAG3   0xce (maybe this is
EMU_CMD_HW_JTAG2 according to Ben's Mach 16 patch).

 /* max speed 12MHz v5.0 jlink */
-#define JLINK_MAX_SPEED 12000 (this is only for V5/6/7/Pro)
+#define JLINK_MAX_SPEED 4000 (this is for V1/2/3/4 according to Segger)

The common thing is to correct the endpoint and remove the
EMU_CMD_GET_MAX_MEM_BLOCK command.

Ben's patch remove more things. I will give it a try after work.

  


Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c	(revision 1834)
+++ src/jtag/jlink.c	(working copy)
@@ -36,9 +36,13 @@
 #define JLINK_WRITE_ENDPOINT	0x02
 #define JLINK_READ_ENDPOINT		0x81
 
+unsigned int jlink_write_ep = JLINK_WRITE_ENDPOINT;
+unsigned int jlink_read_ep = JLINK_READ_ENDPOINT;
+unsigned int jlink_hw_jtag_version = 2;
+
 #define JLINK_USB_TIMEOUT		1000
 
-// See Section 1.3.2 of the Segger JLink USB protocol manual
+/* See Section 1.3.2 of the Segger JLink USB protocol manual */
 /* 2048 is the max value we can use here */
 //#define JLINK_TAP_BUFFER_SIZE 2048
 #define JLINK_TAP_BUFFER_SIZE 256
@@ -60,6 +64,7 @@
 #define EMU_CMD_HW_CLOCK			0xc8
 #define EMU_CMD_HW_TMS0 			0xc9
 #define EMU_CMD_HW_TMS1 			0xca
+#define EMU_CMD_HW_JTAG2		0xce
 #define EMU_CMD_HW_JTAG3		0xcf
 #define EMU_CMD_GET_MAX_MEM_BLOCK	0xd4
 #define EMU_CMD_HW_RESET0   		0xdc
@@ -67,6 +72,7 @@
 #define EMU_CMD_HW_TRST0		0xde
 #define EMU_CMD_HW_TRST1		0xdf
 #define EMU_CMD_GET_CAPS		0xe8
+#define EMU_CMD_GET_HW_VERSION  	0xf0
 
 /* max speed 12MHz v5.0 jlink */
 #define JLINK_MAX_SPEED 12000
@@ -82,6 +88,7 @@
 
 /* CLI command handler functions */
 static int jlink_handle_jlink_info_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
+static int jlink_handle_jlink_hw_jtag_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
 
 /* Queue command functions */
 static void jlink_end_state(tap_state_t state);
@@ -301,8 +308,11 @@
 
 static int jlink_register_commands(struct command_context_s *cmd_ctx)
 {
+
 	register_command(cmd_ctx, NULL, "jlink_info", jlink_handle_jlink_info_command, COMMAND_EXEC,
 		"query jlink info");
+	register_command(cmd_ctx, NULL, "jlink_hw_jtag", jlink_handle_jlink_hw_jtag_command, COMMAND_EXEC,
+		"set/get jlink hw jtag command version [2|3]");
 	return ERROR_OK;
 }
 
@@ -318,6 +328,7 @@
 		return ERROR_JTAG_INIT_FAILED;
 	}
 
+	jlink_hw_jtag_version = 2;
 	check_cnt = 0;
 	while (check_cnt < 3)
 	{
@@ -543,7 +554,7 @@
 {
 	int result;
 	int len;
-	u32 jlink_caps, jlink_max_size;
+	u32 jlink_caps, jlink_max_size, jlink_hw_version;
 
 	/* query hardware version */
 	jlink_simple_command(EMU_CMD_VERSION);
@@ -579,21 +590,38 @@
 	jlink_caps = buf_get_u32(usb_in_buffer, 0, 32);
 	LOG_INFO("JLink caps 0x%x", jlink_caps);
 
+	if (jlink_caps & (1<<1)) /* EMU_CAP_GET_HW_VERSION */
+	{
+		/* query hardware version */
+		jlink_simple_command(EMU_CMD_GET_HW_VERSION);
 
-	/* query hardware maximum memory block */
-	jlink_simple_command(EMU_CMD_GET_MAX_MEM_BLOCK);
+		result = jlink_usb_read(jlink_jtag_handle, 4);
+		if (4 != result)
+		{
+			LOG_ERROR("J-Link command EMU_CMD_GET_HW_VERSION failed (%d)\n", result);
+			return ERROR_JTAG_DEVICE_ERROR;
+		}
 
-	result = jlink_usb_read(jlink_jtag_handle, 4);
-	if (4 != result)
-	{
-		LOG_ERROR("J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (%d)\n", result);
-		return ERROR_JTAG_DEVICE_ERROR;
+		jlink_hw_version = buf_get_u32(usb_in_buffer, 0, 32);
+		LOG_INFO("JLink hw version %i", jlink_hw_version);
 	}
 
-	jlink_max_size = buf_get_u32(usb_in_buffer, 0, 32);
-	LOG_INFO("JLink max m

Re: [Openocd-development] [RFC][PATCH] [0/4] x16_as_x8 tentative implementation.

[Rick Altherr]

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 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  
order to

trunk.

 The patchset consists of 4 patches, whose interest areas I
explain and comment below:

01-x16_as_x8-consolidate_addresses
 · Manufacturer and device id retrieval in cfi_probe function  
weren't using

the generic flash_address. Use it there.

02-x16_as_x8-command_address
 · Creation of a command_address function intended as flash  
addresses arranger
depending on the x16_as_x8 parameter existence or not. This is  
basically an
override of flash_address function, only that takes into account the  
x16_as_x8

parameter. The other options for this functionality would be adding an
additional parameter to flash_address function or, if it is shown  
that it is an
equivalent of flash_address, include x16_as_x8 functionality into  
flash_address.


03-x16_as_x8-command_address-subst
 · Substitution of flash_address function for command_address  
function, except
on code specific to intel. I have just focused on spansion flashes  
and I hadn't
review intel flash specifications, so I decided to be conservative  
at first.
Maybe someone can tell if the command_address function is also valid  
for intel
chips. If so this patch could be grown to include those or  
eventually include

the x16_as_x8 functionality into flash_address not needing this one.

04-x16_as_x8-multibyte_read
 · cfi_query_u16 and cfi_query_u32 function uses multibyte accesses,  
this is 2
or 4 byte read. This will fail in the x16_as_x8 case since this  
would lead
reading, e.g.: addresses 0x0 and 0x1 instead of 0x0 and 0x2 in the  
16bit case.

Do a byte by byte read in the x16_as_x8 case.

 Regards,

--
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned





smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] OpenOCD Quick Reference

[Dean Glazeski]

Hey all,

I ran into this during my random googlings: oocd-quickreference 
.  
I was thinking, this might be something cool to put together as part of 
the next release.  I'd be willing to help kick it off, just wanted to 
see what people though.


// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] arm7_9_common: Documentation and Typos

[Dean Glazeski]

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 
happily.  Let me know if I should split these changes up.  I'm still not 
100% on when to split patches.


// Dean Glazeski
Index: arm7_9_common.c
===
--- arm7_9_common.c (revision 1839)
+++ arm7_9_common.c (working copy)
@@ -38,7 +38,7 @@
 
 
 int arm7_9_debug_entry(target_t *target);
-int arm7_9_enable_sw_bkpts(struct target_s *target);
+int arm7_9_enable_sw_bkpts(target_t *target);
 
 /* command handler forward declarations */
 int handle_arm7_9_write_xpsr_command(struct command_context_s *cmd_ctx, char 
*cmd, char **args, int argc);
@@ -214,7 +214,7 @@
  * queue.  For software breakpoints, this will be the status of the
  * required memory reads and writes
  */
-int arm7_9_set_breakpoint(struct target_s *target, breakpoint_t *breakpoint)
+int arm7_9_set_breakpoint(target_t *target, breakpoint_t *breakpoint)
 {
armv4_5_common_t *armv4_5 = target->arch_info;
arm7_9_common_t *arm7_9 = armv4_5->arch_info;
@@ -336,7 +336,7 @@
  * queue.  For software breakpoints, this will be the status of the
  * required memory reads and writes
  */
-int arm7_9_unset_breakpoint(struct target_s *target, breakpoint_t *breakpoint)
+int arm7_9_unset_breakpoint(target_t *target, breakpoint_t *breakpoint)
 {
int retval = ERROR_OK;
 
@@ -412,7 +412,7 @@
  * @return An error status if there is a problem adding the breakpoint or the
  * result of setting the breakpoint
  */
-int arm7_9_add_breakpoint(struct target_s *target, breakpoint_t *breakpoint)
+int arm7_9_add_breakpoint(target_t *target, breakpoint_t *breakpoint)
 {
armv4_5_common_t *armv4_5 = target->arch_info;
arm7_9_common_t *arm7_9 = armv4_5->arch_info;
@@ -463,7 +463,7 @@
  * @return Error status if there was a problem unsetting the breakpoint or the
  * watchpoints could not be cleared
  */
-int arm7_9_remove_breakpoint(struct target_s *target, breakpoint_t *breakpoint)
+int arm7_9_remove_breakpoint(target_t *target, breakpoint_t *breakpoint)
 {
int retval = ERROR_OK;
armv4_5_common_t *armv4_5 = target->arch_info;
@@ -500,7 +500,7 @@
  * @return Error status if watchpoint set fails or the result of executing the
  * JTAG queue
  */
-int arm7_9_set_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
+int arm7_9_set_watchpoint(target_t *target, watchpoint_t *watchpoint)
 {
int retval = ERROR_OK;
armv4_5_common_t *armv4_5 = target->arch_info;
@@ -572,7 +572,7 @@
  * @return Error status while trying to unset the watchpoint or the result of
  * executing the JTAG queue
  */
-int arm7_9_unset_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
+int arm7_9_unset_watchpoint(target_t *target, watchpoint_t *watchpoint)
 {
int retval = ERROR_OK;
armv4_5_common_t *armv4_5 = target->arch_info;
@@ -621,7 +621,7 @@
  * @param watchpoint Pointer to the watchpoint to be added
  * @return Error status while trying to add the watchpoint
  */
-int arm7_9_add_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
+int arm7_9_add_watchpoint(target_t *target, watchpoint_t *watchpoint)
 {
armv4_5_common_t *armv4_5 = target->arch_info;
arm7_9_common_t *arm7_9 = armv4_5->arch_info;
@@ -655,7 +655,7 @@
  * @param watchpoint Pointer to the watchpoint to be removed
  * @return Result of trying to unset the watchpoint
  */
-int arm7_9_remove_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
+int arm7_9_remove_watchpoint(target_t *target, watchpoint_t *watchpoint)
 {
int retval = ERROR_OK;
armv4_5_common_t *armv4_5 = target->arch_info;
@@ -683,7 +683,7 @@
  * @return Error status if there is a timeout or a problem while executing the
  * JTAG queue
  */
-int arm7_9_execute_sys_speed(struct target_s *target)
+int arm7_9_execute_sys_speed(target_t *target)
 {
int retval;
 
@@ -736,7 +736,7 @@
  * @param target Pointer to the target to issue commands to
  * @return Always ERROR_OK
  */
-int arm7_9_execute_fast_sys_speed(struct target_s *target)
+int arm7_9_execute_fast_sys_speed(target_t *target)
 {
static int set=0;
static u8 check_value[4], check_mask[4];
@@ -773,6 +773,14 @@
return ERROR_OK;
 }
 
+/**
+ * Get some data from the ARM7/9 target.
+ *
+ * @param target Pointer to the ARM7/9 target to read data from
+ * @param size The number of 32bit words to be read
+ * @param buffer Pointer to the buffer that will hold the data
+ * @return The result of receiving data from the Embedded ICE unit
+ */
 int arm7_9_target_request_data(target_t *target, u32 size, u8 *buffer)
 {

Re: [Openocd-development] Balloon board config and some queries

[David Brownell]

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
> just quietly use the defaults and save us all having to specify these
> in thousands of config files?

Yes, IMO it should just **QUIETLY** use the defaults.  Which should
be clearly documented (if they're not) as output of initialization.

That's a special case of a more general issue with the server process:
it spews too much crap.  Those messages are just the first spewn.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] OpenOCD RPM

[Dean Glazeski]

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 
remaining errors I have from rpmlint on the final rpm package:


openocd.x86_64: E: statically-linked-binary 
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section 
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: W: devel-file-in-non-devel-package 
/usr/share/openocd/contrib/libdcc/example.c
openocd.x86_64: W: devel-file-in-non-devel-package 
/usr/share/openocd/contrib/libdcc/dcc_stdio.c
openocd.x86_64: W: devel-file-in-non-devel-package 
/usr/share/openocd/contrib/libdcc/dcc_stdio.h

openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz
1 packages and 0 specfiles checked; 2 errors, 4 warnings.

I'm not sure if the first two need to be fixed.  They are meant for an 
embedded systems, I think.  If anyone in OpenOCD land knows what these 
files are for, I'd be grateful to learn about them :).  Thanks for the 
help.  I've attached the current spec file.


// Dean Glazeski
Name:   openocd
Version:0.1.0
Release:1%{?dist}
Summary:Debugging, in-system programming and boundary-scan testing for 
embedded devices

Group:  Development/Tools
License:GPLv2
URL:http://openocd.berlios.de/web/
Source0:%{name}-%{version}.tar.gz
BuildRoot:  %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
BuildRequires:  chrpath

%description
The Open On-Chip Debugger (OpenOCD) provides debugging, in-system programming 
and boundary-scan testing for embedded devices.  Various different boards, 
targets, and interfaces are supported to ease development time.

Install OpenOCD if you are looking for an open source solution for hardware 
debugging.

%prep
%setup -q

%build
%configure --enable-parport --enable-parport_ppdev --enable-ft2232_libftdi 
--enable-ep93xx --enable-at91rm9200 --enable-usbprog --enable-presto_libftdi 
--enable-jlink --enable-vsllink --enable-rlink --enable-dummy --enable-gw16012 
--enable-amtjtagaccel
make %{?_smp_mflags}

%install
rm -rf %{buildroot}
make install DESTDIR=%{buildroot}
rm -f %{buildroot}/%{_infodir}/dir
chrpath --delete %{buildroot}/%{_bindir}/openocd

%post
if [ -x /sbin/install-info ]; then
/sbin/install-info %{_infodir}/%{name}.info.gz %{_infodir}/dir
fi

%preun
if [ -x /sbin/install-info ]; then
/sbin/install-info --delete %{_infodir}/%{name}.info.gz %{_infodir}/dir
fi

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root,-)
%doc README COPYING AUTHORS ChangeLog NEWS TODO
%{_bindir}/%{name}
%{_libdir}/%{name}
%{_datadir}/%{name}
%{_infodir}/%{name}.info.gz
%{_mandir}/man1/*

%changelog
* Tue Mar 17 2009 Dean Glazeski  0.1.0-1
- Created initial package for Fedora
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Wed, May 20, 2009 at 12:53 AM, Gene Smith  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 restart oocd, I again get
> the 3 failed retries on get caps and "don't worry" like before.  If I
> revert to Benjamin's patch, it comes up clean with no errors. Now I can
> do telnet commands with no problem (such as jlink_info, mdb, reg, etc).
>
> Possibly the intention was to combine these patches, I am not sure. But
> anyhow, for what its worth, it is now seems to be working for me with
> Ben's patch. (I have not tried to do anything with gdb yet.)

I can see two big differences between the patches. In Ben's patch,
-#define EMU_CMD_HW_JTAG3   0xcf
+#define EMU_CMD_HW_JTAG3   0xce (maybe this is
EMU_CMD_HW_JTAG2 according to Ben's Mach 16 patch).

 /* max speed 12MHz v5.0 jlink */
-#define JLINK_MAX_SPEED 12000 (this is only for V5/6/7/Pro)
+#define JLINK_MAX_SPEED 4000 (this is for V1/2/3/4 according to Segger)

The common thing is to correct the endpoint and remove the
EMU_CMD_GET_MAX_MEM_BLOCK command.

Ben's patch remove more things. I will give it a try after work.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Further simplifications in jtag.c

[Nicolas Pitre]

On Wed, 20 May 2009, Michael Bruck wrote:

> On Wed, May 20, 2009 at 12:05 AM, David Brownell  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 diffs do.)
> 
> I don't think flooding the list with 10 mails is a good idea,
> especially if people start replying to the mails randomly.

I must side with David here.  Yes, please do flood the list with 10 
emails (10 emails is not _that_ bad), and prefix your subject line with 
[PATCH 1/10] and so on.  This way it is easy for people uninterested in 
such patches to skip/delete the entire series.  The burden should be on 
the submitter side and not on the reviewers side.


Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Wed, May 20, 2009 at 12:04 AM, Gene Smith  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.
You can get more examples here:
http://piklab.wiki.sourceforge.net/USB+Port+Problems

I think you should be fine with either the PolicyKit version or the
Suse/Arch version since you are using Fedora 8. You just
need to change the VID/PID to your J-Link.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Wed, May 20, 2009 at 12:53 AM, Gene Smith  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 failed retries on get caps and "don't worry" like before.

This is in line with my testing of V3. You have a V4.

> If I revert to Benjamin's patch, it comes up clean with no errors. Now I can
> do telnet commands with no problem (such as jlink_info, mdb, reg, etc).

Glad to know that. I will try Ben's patch.

> Possibly the intention was to combine these patches, I am not sure. But
> anyhow, for what its worth, it is now seems to be working for me with
> Ben's patch. (I have not tried to do anything with gdb yet.)



-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Further simplifications in jtag.c

[Michael Bruck]

On Wed, May 20, 2009 at 12:05 AM, David Brownell  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;
>>         int nth_tap;
>>         int scan_size = 0;
>>
>> +       int num_taps = jtag_NumEnabledTaps();
>
> Just put the "int num_taps..." up where "int x" was.

The block above num_taps is gone in the final version.
jtag_NumEnabledTaps() is not a trivial initialization but rather a
step of the algorithm. That's why it is set apart from the variable
declarations.

>> +
>>         /* allocate memory for a new list member */
>>         jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t));
>
> Or what you did in a few other places, "type * ptrvar" should
> be just "type *ptrvar"; those are IMO neither simplifications

The "* ptrvar" was added to enable the modification in #5 that you
seemed to agree with. I personally prefer the syntax with spaces as I
generally add spaces around anything that looks like an operator for
better readability.

> nor cleanups.  Ditto using the (IMO annoying) C99 feature where
> declarations don't necessarily live at the beginning of a block.

Why do you need them at the beginning of the block, considering that they
- are not used at that point
- use up an extra statement
- separate initialization from definition thus adding potential for
errors and reducing readability.

>> Again none of these patches change any algorithm.
>
> Making them all coding style fixes, not simplifications.
> And at one point some new comments.

Simple to read and simple to modify. That was the goal here. The point
was that jtag.c contains utterly trivial algorithms that are hidden in
bloated code.

> I liked #5 (other than the "type * ptrvar" issue), that does
> make the code more clear:  p->q->r  ==> q->r is mostly better.
>
>
> I'd kind of like to see a standard "indent" ruleset agreed on,
> so that at least the things that tool handles well could be
> somewhat automated.
>
>
>
> (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 diffs do.)

I don't think flooding the list with 10 mails is a good idea,
especially if people start replying to the mails randomly. What
extension will make your reader highlight the code?


Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] release strategy [2 of 4]

[David Brownell]

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 months or so, to make sure bugfixes
and new capabilities don't sit too long in the kitchen before
being served as entrees or appetizers?

There's also the issue of how to get proper "user feedback"
into the cycle.  Requiring folk to subscribe to the developer
list, or get a berlios account to submit a bug report, rather
minimizes the amount of such feedback.


>   Once we have machine-generated records of 
> certain combinations of hardware having worked with a certain version of
> OpenOCD, it will be virtually impossible for us to miss regressions with
> particular hardware combinations.

No, it'll still be really easy.  Especially at this level of
system development, hardware comes and goes.  Someone may
test with a board but need to return it, so they can't retry
with a later release.  Or it may break, or become obsolete
so it goes into a box and doesn't get retested.

The way to get reproducibility is to have dedicated test
hardware, and dedicated test resources ... Øyvind was working
on some of that.

But also, expect that goofs will happen, and make it easy
for "users" to report problems ... they will have access to
a *LOT* of hardware the main developers don't.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] testing tools [4 of 4]

[David Brownell]

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 "user",
> along with the 'version' of OpenOCD, the test 'results', along with a
> 'comment'.  In this description, words in double-quotes ('"')
> effectively describe various primary tables, while the words in
> single-quotes ("'") describe column fields.

Let me suggest a summary page with a matrix that mostly
overlooks the specific boards involved, and focusses on
more straightforward issues:

CPU/Platform JTAG Adapter/Interface
   ft2232parport   jlink   ...
arm920t   g y r...
arm926ejs g g y...
xscaleg - -...
mips  - - g
avr8  y g -


where a "g/green" indicates multiple positives, no negatives;
a "y/yellow" indicates mixed results or only one positive;
a "r/red" indicates more negatives than positives; and a
blank indicates no results.  (Or some other metric which
is useful and morphs easily to such a status panel display.)

That could be emailed to the list ... or turned into a web
or wiki page.  In HTML form, maybe the body of the cell would
be a link pointing to more details ... semi-fancy versions of
this could highlight results for the *last* release, so it'd
be easy to see notice regressions.

If such a page shows a lot of red, that would strongly suggest
it's not ship-ready.  Too many blanks would show "not enough
testing yet".  Rows or columns would show patterns indicating
particular code needs work.

Key point:  without such a summary, it'll be hard to know
where the problems (including big unknowns!) lurk.

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] features for 0.2.0 [1 of 4]

[David Brownell]

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 moderately
complete test matrix filled out on the

{ CPU/platform x adapter/interface }

dimension.  I don't think the "board" dimension will be
as important for such issues, except that a few boards
might have "interesting" characteristics (including some
non-CPU devices).

Then the release after this next one should just remove
the old tables.

- Dave


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Further simplifications in jtag.c

[David Brownell]

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 fields and produce from that a new set of output fields. The
> patch sets the stage to later be able to use a local variable 'field'
> or 'fields' to refer to fields rather then the current endless
> repetitions of cmd->cmd.scan->fields[...] while at the same time
> making it clear which one is the input argument and which is the
> output data.

Seems like it can hardly break anything, yes?  That does seem
to be useful clarity.


> 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;
> int nth_tap;
> int scan_size = 0;
>
> +   int num_taps = jtag_NumEnabledTaps();

Just put the "int num_taps..." up where "int x" was.

> +
> /* allocate memory for a new list member */
> jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t));

Or what you did in a few other places, "type * ptrvar" should
be just "type *ptrvar"; those are IMO neither simplifications
nor cleanups.  Ditto using the (IMO annoying) C99 feature where
declarations don't necessarily live at the beginning of a block.


> Again none of these patches change any algorithm.

Making them all coding style fixes, not simplifications.
And at one point some new comments.


I liked #5 (other than the "type * ptrvar" issue), that does
make the code more clear:  p->q->r  ==> q->r is mostly better.


I'd kind of like to see a standard "indent" ruleset agreed on,
so that at least the things that tool handles well could be
somewhat automated.



(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 diffs do.)

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] milestone strategy [3 of 4]

[David Brownell]

On Monday 18 May 2009, Nico Coesel 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.

Yeah, leading zeroes are bad that way.  One of the alternatives
is to use datecodes, like 2009.05 ... they're unique enough, and
clearly don't reflect any "deeper meaning" like a "0.x" or "x.0".

As for $SUBJECT, why not just say "no feature before its time"
and just let them catch the next release going out the door?

That is, use the release train model.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] svn head should now be OK again

[Peter Denison]

On Mon, 18 May 2009, Peter Denison wrote:

> On Mon, 18 May 2009, Peter Denison wrote:
>
>> Now, on to the actual crash. I will do more investigation, but for now,
>> here's the backtrace:
>>
>> Starting program: /src/.libs/lt-openocd -f
>> ../../../openocd-usr8200-jlink.cfg
>> Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827M
>>
>> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>>
>> $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
>> jtag_speed: 16
>> Error: J-Link command EMU_CMD_VERSION failed (-110)
>>
>> Error: J-Link command EMU_CMD_VERSION failed (-110)
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
>> 940  result = usb_bulk_write_ex(jlink_jtag->usb_handle,
>> JLINK_WRITE_ENDPOINT,
>> (gdb) bt
>> #0  jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
>> #1  0xb7feaaf8 in jlink_simple_command (command=1 '\001') at jlink.c:509
>> #2  0xb7febbb0 in jlink_get_version_info () at jlink.c:549
>> #3  0xb7febf2d in jlink_init () at jlink.c:324
>> #4  0xb7fe2bbf in jtag_interface_init (cmd_ctx=0x804a008) at jtag.c:2333
>
> Preliminary look at this seems to be that jlink_jtag_handle is overwritten
> with junk. This sits in memory directly after usb_emu_result_buffer, which
> is 64 bytes long. Are any of the new in_handler replacement callbacks
> overwriting the end of this buffer?

Sorry - that was a wild guess, and was totally wrong.

It seems that the interface (I have the yellow J-Link V6) can get into an 
odd state where it responds incorrectly to an EMU_CMD_VERSION command 
(0x01). In this state, it replies with the string "J-Link ARM V6 compiled 
Mar  3 2008 18:04:42" immediately, without sending the 0x0070 length field 
first.

I have confirmed this with the kernel-level USB trace provided by usbmon.

The result is that the first two characters get interpreted as a length, 
"J-" = 0x4a 0x2d => 0x2d4a = 11594, much larger than the 2048 bytes 
allocated for the USB input buffer.

With the changes introduced in r1475, where the expected length is passed 
to the bulk read function, this will now time out and/or overwrite 
usb_read_buffer. In jlink_usb_read() we should definitely check that the 
expected size is not larger than the buffer. That will catch the segfault.

What the correct course of action after that is, I don't know. Put in an 
explicit check for length == 0x2d4a, and emit a message suggesting an 
adapter power-cycle? I'm open to suggestions.

I'll see if I can produce a workable patch...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Compile error under Cygwin

[Spencer Oliver]

> 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 i recall i also had this error with cygwin.

Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Compile error under Cygwin

[SimonQian]

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

SimonQian(simonq...@simonqian.com)  www.SimonQian.com



发件人： Zach Welch 
发送时间： 2009-05-20  02:26:23 
收件人： SimonQian 
抄送： Openocd-Dev 
主题： Re: [Openocd-development] Compile error under Cygwin 
 
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
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Compile error under Cygwin

[Zach Welch]

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

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Compile error under Cygwin

[SimonQian]

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
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] testing tools [4 of 4]

[Zach Welch]

On Tue, 2009-05-19 at 00:09 -0700, Paul Thomas wrote:
> On Mon, May 18, 2009 at 10:49 PM, Zach Welch 
> 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).
[snip]
> Known problems:
> - I have tried to KISS, so there are going to be definite
> limits.
> - Additional database design work needs to be done.
> - Static output only.
> - Missing an 'email.pl' script to provide a gateway from
> e-mail messages
> sent by the automated tester.
> - Automated tester does not report PASS/FAIL and send e-mails.
[snip]
> 
> I think that would be great. As a user what is our interface to this?
> Do we just send an email with lines in the specified format? I haven't
> used the regression test suite so maybe that would explain this some. 

The "test suite" was just started recently (look in src/target/test/).
It's a work-in-progress, but the goal will be to "connect the dots"
between scripts like this and a my current work.

> One way to aggregate the data would be to create a web form that users
> could fill out manually, but also have another perl script in the test
> suite that could automatically fill out the form. The most elegant way
> would be to tie the form directly to the SQL database, but for
> something quick & dirty we could just use a google form like this:
> (https://spreadsheets.google.com/viewform?formkey=cnpOSWRCcE9DRjl1a3E5NURnUFQ4Rnc6MA..),
>  and then pull a csv file of the data when we wanted to. Just a thought. I 
> know some PERL & SQL so I'm willing to help out.

My initial plan was simply to allow a script to call sendmail (SMTP), as
I can create an account to receive the messages and deliver them into
the DB.  However, Duane has me re-considering my backup plan to just
using curl and a web form. 

Either way, the contents will be generated from a locally run script
(probably perl, but maybe just shell).  I imagine the user involvement
requiring at most two steps (after setup):

0) Configure your user-preferences.
1) Choose the interface and target to test (platform may be inferred).
2) Run 'make INTERFACE=X TARGET=Y smoketest' (or something similar).
  - For some platforms, may run it from OpenOCD's built-in web server.

For users with only one system configuration to test, Step 1 should only
need to be done once.  Thus, many users should simply be able to run the
last command, after 'make setup_smoketest' perhaps.  In theory.

The purpose of TAB-delimited files would be to allow trivial importing
into an SQL database, which I have considered required from the start
(just not for the very first version).

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] How to build a static version under Mac OS X?

[Michael Fischer]

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
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] How to build a static version under Mac OS X?

[Rick Altherr]

I believe you can disable the building of the shared library with "-- 
disable-shared" to configure.  The advantage is a longer-term goal of  
being able to use the OpenOCD internals as part of another program  
such as a GUI for programming flashes.  For now, it just makes the  
build take longer.

--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned



On May 19, 2009, at 10:26 AM, Michael Fischer wrote:


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

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development




smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] How to build a static version under Mac OS X?

[Michael Fischer]

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

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Gene Smith]

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 firmware version as well...
>>> Linux segger tool did nothing at all...
>>> But when I hooked it up to the windows version of these segger tools, it 
>>> asked 
>>> me whether to update the device or not. (Wine did not do the job, had to 
>>> use a 
>>> native win xp setup for that)
>>>
>>> After that I could use the linux tool as well
>>>
>>> Maybe you could try that first
>>>
>>> Benjamin
>> Just loaded the windows tools and ran J-Link Commander. Can't seem to 
>> copy/paste from its terminal so I will type in what it says:
>>
>> SEGGER J-Link Commander V4.05i ('?' for help)
>> Compiled May 18 2009 19:21:08
>> DLL version V4.05i, compiled May 18 2009 19:20:52
>> Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
>> Hardware: V4.30
>> S/N : 10001576
>> OEM: IAR
>> VTarget = 3.250V
>> Info: TotalIRLen = 4, IRPrint = 0x01
>> Found 1 JTAG device, Total IRLen = 4:
>>   Id of device #0: 0x3f0f0f0f
>> Found ARM with cord Id 0x3f0f0f0f (ARM7)
>> JTAG speed: 5 kHz
>>
>> This did not ask me to update f/w. I think yesterday linux version may 
>> have actually updated it to what is says above, not sure. The info above 
>> looks right. The serial number is correct and matches what is printed on 
>> the bottom.
>>
>> I may not have mentioned that the Linux version of J-Link Commander 
>> always says after starting:
>> "Can not connect to J-Link via USB"
>> while windows version above issues no such complaint.
> 
> I forgot that I have to run "./start" as root or sudo or you get this error.
> 
>> Appears to probably be a USB comm problem. But I have no problem with 
>> other USB devices on same linux box (mem sticks, SD cards, eth adapters, 
>> etc.)
> 
> Well, I was wrong.  Running this in Windows (XP) does seem to do 
> something to the jlink device. When I put it back on linux version of 
> J-Link Cmdr it now works better (have to run as root).
> 
> [g...@localhost jlink-segger]$ sudo ./start
> Password:
> SEGGER J-Link Commander V4.03a ('?' for help)
> Compiled Feb  2 2009 11:34:21
> DLL version V4.03a, compiled Feb  2 2009 11:34:13
> Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
> Hardware: V4.30
> S/N : 10001576
> OEM : IAR
> VTarget = 3.250V
> Info: TotalIRLen = 4, IRPrint = 0x01
> 
> WARNING: Identified core does not match configuration. (Found: ARM7, 
> Configured: None)
> Found 1 JTAG device, Total IRLen = 4:
>   Id of device #0: 0x3F0F0F0F
> Found ARM with core Id 0x3F0F0F0F (ARM7)
> JTAG speed: 5 kHz
> J-Link>f
> Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
> Hardware: V4.30
> 
> Also, now when I run openocd it seem better now:
> 
> 
> [g...@localhost src]$ sudo ./openocd -f target/interface/jlink.cfg -f 
> target/board/iar_str712_sk1.cfg
> Password:
> Open On-Chip Debugger 0.2.0-in-development (2009-05-19-10:03) svn:1833M
> 
> 
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
> 
> 
> $URL: svn://localhost:36903/openocd/trunk/src/openocd.c $
> 10 kHz
> Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
> Info : JLink caps 0x3
> Info : Vref = 3.251 TCK = 1 TDI = 1 TDO = 0 TMS = 1 SRST = 1 TRST = 1
> 
> Info : J-Link JTAG Interface ready
> Error: usb_bulk_read failed (requested=1, result=-110)
> Error: jlink_tap_execute, wrong result -107 (expected 1)
> Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive 
> packet not sent! (3217). Workaround: increase "set remotetimeout" in GDB
> Error: usb_bulk_read failed (requested=1, result=-110)
> Error: jlink_tap_execute, wrong result -107 (expected 1)
> Error: usb_bulk_read failed (requested=1, result=-110)
> Error: jlink_tap_execute, wrong result -107 (expected 1)
> Warn : no telnet port specified, using default port 
> Warn : no gdb port specified, using default port 
> Warn : no tcl port specified, using default port 
> 
> However, when telnet'ing, I still get usb_bulk_read failed errors when I 
> do anything such as jlink_info, halt or reg.
> 
> A few more observations: When I plug the linux usb to the jlink the 
> blinking time is now only about a second (before it was 30-45 seconds). 
> Also, lsusb -vvv now shows the segger device like Xiaofan posted. So 
> running the windows J-Link Cmdr did something to the jlink.
> 
> I am using the jlink.c patch from Magnus he posted this morning.
> 
> -gene

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 restart oocd, I again get 
the 3 failed retries on get caps and "don't worry" like before.  If I 
revert to Benjamin's patch, it comes up clean wit

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Gene Smith]

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 firmware version as well...
>> Linux segger tool did nothing at all...
>> But when I hooked it up to the windows version of these segger tools, it 
>> asked 
>> me whether to update the device or not. (Wine did not do the job, had to use 
>> a 
>> native win xp setup for that)
>>
>> After that I could use the linux tool as well
>>
>> Maybe you could try that first
>>
>> Benjamin
> 
> Just loaded the windows tools and ran J-Link Commander. Can't seem to 
> copy/paste from its terminal so I will type in what it says:
> 
> SEGGER J-Link Commander V4.05i ('?' for help)
> Compiled May 18 2009 19:21:08
> DLL version V4.05i, compiled May 18 2009 19:20:52
> Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
> Hardware: V4.30
> S/N : 10001576
> OEM: IAR
> VTarget = 3.250V
> Info: TotalIRLen = 4, IRPrint = 0x01
> Found 1 JTAG device, Total IRLen = 4:
>   Id of device #0: 0x3f0f0f0f
> Found ARM with cord Id 0x3f0f0f0f (ARM7)
> JTAG speed: 5 kHz
> 
> This did not ask me to update f/w. I think yesterday linux version may 
> have actually updated it to what is says above, not sure. The info above 
> looks right. The serial number is correct and matches what is printed on 
> the bottom.
> 
> I may not have mentioned that the Linux version of J-Link Commander 
> always says after starting:
> "Can not connect to J-Link via USB"
> while windows version above issues no such complaint.

I forgot that I have to run "./start" as root or sudo or you get this error.

> 
> Appears to probably be a USB comm problem. But I have no problem with 
> other USB devices on same linux box (mem sticks, SD cards, eth adapters, 
> etc.)

Well, I was wrong.  Running this in Windows (XP) does seem to do 
something to the jlink device. When I put it back on linux version of 
J-Link Cmdr it now works better (have to run as root).

[g...@localhost jlink-segger]$ sudo ./start
Password:
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb  2 2009 11:34:21
DLL version V4.03a, compiled Feb  2 2009 11:34:13
Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
Hardware: V4.30
S/N : 10001576
OEM : IAR
VTarget = 3.250V
Info: TotalIRLen = 4, IRPrint = 0x01

WARNING: Identified core does not match configuration. (Found: ARM7, 
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
  Id of device #0: 0x3F0F0F0F
Found ARM with core Id 0x3F0F0F0F (ARM7)
JTAG speed: 5 kHz
J-Link>f
Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
Hardware: V4.30

Also, now when I run openocd it seem better now:


[g...@localhost src]$ sudo ./openocd -f target/interface/jlink.cfg -f 
target/board/iar_str712_sk1.cfg
Password:
Open On-Chip Debugger 0.2.0-in-development (2009-05-19-10:03) svn:1833M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://localhost:36903/openocd/trunk/src/openocd.c $
10 kHz
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Info : Vref = 3.251 TCK = 1 TDI = 1 TDO = 0 TMS = 1 SRST = 1 TRST = 1

Info : J-Link JTAG Interface ready
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive 
packet not sent! (3217). Workaround: increase "set remotetimeout" in GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : no telnet port specified, using default port 
Warn : no gdb port specified, using default port 
Warn : no tcl port specified, using default port 

However, when telnet'ing, I still get usb_bulk_read failed errors when I 
do anything such as jlink_info, halt or reg.

A few more observations: When I plug the linux usb to the jlink the 
blinking time is now only about a second (before it was 30-45 seconds). 
Also, lsusb -vvv now shows the segger device like Xiaofan posted. So 
running the windows J-Link Cmdr did something to the jlink.

I am using the jlink.c patch from Magnus he posted this morning.

-gene



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] "Short" state table enabled as of r1827

[Michael Fischer]

Hello Spen,

YES, your patch fix the problem here.

Best regards,

Michael

-Ursprüngliche Nachricht-
Von: Spencer Oliver [mailto:s...@spen-soft.co.uk]
Gesendet: Dienstag, 19. Mai 2009 17:45
An: 'Michael Fischer'; 'Øyvind Harboe'
Cc: 'Openocd-Dev'
Betreff: RE: [Openocd-development] "Short" state table enabled as of
r1827



>
> 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
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] "Short" state table enabled as of r1827

[Spencer Oliver]

> 
> 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
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] "Short" state table enabled as of r1827

[Michael Fischer]

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: [Openocd-development] "Short" state table enabled as of
r1827


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

--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] "Short" state table enabled as of r1827

[Spencer Oliver]

> > 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 from 
> TAP_RESET to the long version. This will not affect 
> performance but give some extra tck clocks in reset.
> Some target really like that.
> 

I tried your suggestion and it seems to fix the ftdi/cortex error with the
first jtag examine call.

Cheers
Spen



jtag.c.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] features for 0.2.0 [1 of 4]

[Freddie Chopin]

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 have seen *very* little testing in the openocd list in response to posted
>> patches, but once things are committed to svn head, testing proceeds 
>> smoothly.
>>
> 
> What would be the community consensus on this item?  I cannot judge.

You can enable new options in the 0.2.0 release. If the features are 
buggy, there will be a reason for 0.2.1 release (;

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] failed to build openocd

[massimiliano cialdi]

2009/5/19 Raúl Sánchez Siles :
>  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 --disable-werror

So the configure command line is
$ ./configure --prefix=/opt/openocd  --enable-httpd
--enable-ft2232_ftd2xx --with-ftd2xx-lib=static
--with-ftd2xx-linux-tardir=~/download/openocd/libftd2xx0.4.16_x86_64
--enable-jlink --enable-rlink --enable-arm-jtag-ew --disable-werror

Now all files are compiled but I have an error in linking:

libtool: link: gcc -std=gnu99 -g -O2 -I/opt/openocd/include
-I~/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes
-Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
-Wcast-align -Wredundant-decls -Wl,-rpath -Wl,/opt/openocd/lib -o
.libs/openocd main.o
~/download/openocd/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16
 -L/opt/openocd/lib ./.libs/libopenocd.so /usr/lib/libusb.so -ldl
-lpthread -Wl,-rpath -Wl,/opt/openocd/lib
./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer'
./.libs/libopenocd.so: undefined reference to `FT_Close'
./.libs/libopenocd.so: undefined reference to `FT_SetBitMode'
./.libs/libopenocd.so: undefined reference to `FT_OpenEx'
./.libs/libopenocd.so: undefined reference to `FT_Read'
./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts'
./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID'
./.libs/libopenocd.so: undefined reference to `FT_Write'
./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer'
./.libs/libopenocd.so: undefined reference to `FT_ListDevices'
./.libs/libopenocd.so: undefined reference to `FT_Purge'
collect2: ld returned 1 exit status

Where I am wrong?
I wonder if I can use opensource ftdi driver ftdi2232 or since I use
amontec jtagkey I need to use libftd2xx (but I wonder if exist 64bit
version)


>  BTW, make sure you run bootstrap prior to configure.
Yes I run ./bootstrap before ./configure

thanks
-- 
Assioma di Cole: "La somma dell'intelligenza sulla Terra è costante;
la popolazione è in aumento"

Massimiliano Cialdi
cia...@gmail.com
massimiliano.cia...@powersoft.it
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Tue, May 19, 2009 at 10:53 PM, Magnus Lundin  wrote:
> 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
> version, I had removed it in my patch. Next patch will use results from
> JLink caps to select what info to query.
>

I will try your full patch tomorrow. Thanks. The endpoint detection part
works well.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Tue, May 19, 2009 at 9:39 PM, Xiaofan Chen  wrote:
> On Tue, May 19, 2009 at 4:53 PM, 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.
>>
>
> Yes you are right that the output endpoint used is different for my
> V3 and V6 J-Link. And your patch for detecting the endpoint
> seems to be right. But I am not a programmer.
>

I've tested your patch with V3 and V6 J-Link. I think it does not
affect V6 and seem to help V3. Thanks. Maybe at least the
endpoint detection part should be commited.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Magnus Lundin]

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
version, I had removed it in my patch. Next patch will use results from
JLink caps to select what info to query.

I am waiting for more info from Segger about version diffrences and
endpoints.

Have a nice day,
Magnus




___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Gene Smith]

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 segger tool did nothing at all...
> But when I hooked it up to the windows version of these segger tools, it 
> asked 
> me whether to update the device or not. (Wine did not do the job, had to use 
> a 
> native win xp setup for that)
> 
> After that I could use the linux tool as well
> 
> Maybe you could try that first
> 
> Benjamin

Just loaded the windows tools and ran J-Link Commander. Can't seem to 
copy/paste from its terminal so I will type in what it says:

SEGGER J-Link Commander V4.05i ('?' for help)
Compiled May 18 2009 19:21:08
DLL version V4.05i, compiled May 18 2009 19:20:52
Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
Hardware: V4.30
S/N : 10001576
OEM: IAR
VTarget = 3.250V
Info: TotalIRLen = 4, IRPrint = 0x01
Found 1 JTAG device, Total IRLen = 4:
  Id of device #0: 0x3f0f0f0f
Found ARM with cord Id 0x3f0f0f0f (ARM7)
JTAG speed: 5 kHz

This did not ask me to update f/w. I think yesterday linux version may 
have actually updated it to what is says above, not sure. The info above 
looks right. The serial number is correct and matches what is printed on 
the bottom.

I may not have mentioned that the Linux version of J-Link Commander 
always says after starting:
"Can not connect to J-Link via USB"
while windows version above issues no such complaint.

Appears to probably be a USB comm problem. But I have no problem with 
other USB devices on same linux box (mem sticks, SD cards, eth adapters, 
etc.)

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Tue, May 19, 2009 at 10:43 PM, Xiaofan Chen  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), something happens to
J-Link. Sometimes it segfaults. The next run will be ok.

mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f myopenocd.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-19-21:59) svn:1836


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
RCLK - adaptive
Error: J-Link command EMU_CMD_VERSION failed (-110)

Segmentation fault

mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f myopenocd.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-19-21:59) svn:1836


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
RCLK - adaptive
Error: J-Link command EMU_CMD_VERSION failed (-110)

Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18
Info : JLink caps 0xf7fbf
Info : JLink max mem block 9992
Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1

Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3101). Workaround: increase "set remotetimeout" in
GDB
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f
(Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
Warn : no tcl port specified, using default port 
Warn : DBGACK set while target was in unknown state. Reset or initialize target.
target state: halted
target halted in ARM state due to breakpoint, current mode: System
cpsr: 0x805f pc: 0x0894
Info : accepting 'telnet' connection from 0
 TapName| Enabled |   IdCode  ExpectedIrLen
IrCap  IrMask Instr
---||-|||--|--|--|-
 0 | lpc2148.cpu|Y| 0x4f1f0f0f | 0x4f1f0f0f | 0x04 |
0x01 | 0x0f | 0x0c
Runtime error, file "command.c", line 453:
Unknown command: go
Runtime error, file "command.c", line 453:
Unknown command: run
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f
(Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x805f pc: 0x085c
target state: halted
target halted in ARM state due to single-step, current mode: System
cpsr: 0x805f pc: 0x0860



-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Tue, May 19, 2009 at 10:36 PM, Xiaofan Chen  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 is out of sync. So there are
> still some problems. The only way to recover seems to disconnect
> everything and restart again.
>

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).

I believe your version is similar to my V3 and with even
older firmware.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] mip32 interrupt disable

[Spencer Oliver]

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
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Tue, May 19, 2009 at 9:30 PM, Gene Smith  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.

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 is out of sync. So there are
still some problems. The only way to recover seems to disconnect
everything and restart again.

mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb  2 2009 11:34:21

WARNING: Out of sync , resynchronising...


WARNING: Out of sync , resynchronising...


WARNING: Out of sync , resynchronising...

Can not connect to J-Link via USB.
J-Link>exit

mc...@ubuntu904:~/Desktop/build/openocd/jlinkold$ openocd -f myopenocd.cfg
Open On-Chip Debugger 0.2.0-in-development modified J-LINK by Magnus
Lundin (2009-05-19-22:19) svn:1836M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
RCLK - adaptive
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)

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)

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)

Info : J-Link initial read failed, don't worry
Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (9128). Workaround: increase "set remotetimeout" in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3011). Workaround: increase "set remotetimeout" in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3238). Workaround: increase "set remotetimeout" in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : no tcl port specified, using default port 
Info : accepting 'telnet' connection from 0
 TapName| Enabled |   IdCode  ExpectedIrLen
IrCap  IrMask Instr
---||-|||--|--|--|-
 0 | lpc2148.cpu|Y| 0x | 0x4f1f0f0f | 0x04 |
0x01 | 0x0f | 0x0f
Error: Target not examined yet
Runtime error, file "command.c", line 453:

mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb  2 2009 11:34:21
DLL version V4.03a, compiled Feb  2 2009 11:34:13
Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
Hardware: V3.00
S/N : 3330
OEM : IAR
VTarget = 3.290V
Info: TotalIRLen = 4, IRPrint = 0x01

WARNING: Identified core does not match configuration. (Found: ARM7,
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
 Id of device #0: 0x4F1F0F0F
Found ARM with core Id 0x4F1F0F0F (ARM7)
  ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
JTAG speed: 5 kHz

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] failed to build openocd

[Raúl Sánchez Siles]

On Tuesday 19 May 2009 16:15:22 massimiliano cialdi wrote:
> 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
> --with-ftd2xx-linux-tardir=~/download/openocd/libftd2xx0.4.16_x86_64
> --enable-jlink --enable-rlink --enable-arm-jtag-ew
>
> make stop with an error:
> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..
> -I../../src/server -I../../src/target
> -DPKGDATADIR=\"/opt/openocd/share/openocd\"
> -DPKGLIBDIR=\"/opt/openocd/lib/openocd\" -g -O2 -I/opt/openocd/include
> -I~/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes
> -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
> -Wcast-align -Wredundant-decls -Werror -MT libhelper_la-ioutil.lo -MD
> -MP -MF .deps/libhelper_la-ioutil.Tpo -c ioutil.c  -fPIC -DPIC -o
> .libs/libhelper_la-ioutil.o
> cc1: warnings being treated as errors
> ioutil.c: In function ‘handle_append_command’:
> ioutil.c:230: error: ignoring return value of ‘fwrite’, declared with
> attribute warn_unused_result
> ioutil.c:233: error: ignoring return value of ‘fwrite’, declared with
> attribute warn_unused_result
> ioutil.c:236: error: ignoring return value of ‘fwrite’, declared with
> attribute warn_unused_result
>
>
> what is wrong?
>
> thanks

  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. 

  BTW, make sure you run bootstrap prior to configure.

  Regards,
-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Gene Smith]

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
> Magnus
> 

See the same messages startup with this as with Benjamin's patch. Also, 
still see this after connecting with telnet:

 > jlink_info
J-Link command EMU_CMD_VERSION failed (-110)

Also, don't see "segger" or "j-link" mentioned when I do lsusb -vvv

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] failed to build openocd

[massimiliano cialdi]

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
--with-ftd2xx-linux-tardir=~/download/openocd/libftd2xx0.4.16_x86_64
--enable-jlink --enable-rlink --enable-arm-jtag-ew

make stop with an error:
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..
-I../../src/server -I../../src/target
-DPKGDATADIR=\"/opt/openocd/share/openocd\"
-DPKGLIBDIR=\"/opt/openocd/lib/openocd\" -g -O2 -I/opt/openocd/include
-I~/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes
-Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
-Wcast-align -Wredundant-decls -Werror -MT libhelper_la-ioutil.lo -MD
-MP -MF .deps/libhelper_la-ioutil.Tpo -c ioutil.c  -fPIC -DPIC -o
.libs/libhelper_la-ioutil.o
cc1: warnings being treated as errors
ioutil.c: In function ‘handle_append_command’:
ioutil.c:230: error: ignoring return value of ‘fwrite’, declared with
attribute warn_unused_result
ioutil.c:233: error: ignoring return value of ‘fwrite’, declared with
attribute warn_unused_result
ioutil.c:236: error: ignoring return value of ‘fwrite’, declared with
attribute warn_unused_result


what is wrong?

thanks
-- 
Assioma di Cole: "La somma dell'intelligenza sulla Terra è costante;
la popolazione è in aumento"

Massimiliano Cialdi
cia...@gmail.com
massimiliano.cia...@powersoft.it
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Benjamin Schmidt]

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 all...
But when I hooked it up to the windows version of these segger tools, it asked 
me whether to update the device or not. (Wine did not do the job, had to use a 
native win xp setup for that)

After that I could use the linux tool as well

Maybe you could try that first

Benjamin
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Xiaofan Chen]

On Tue, May 19, 2009 at 4:53 PM, 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.
>

Yes you are right that the output endpoint used is different for my
V3 and V6 J-Link. And your patch for detecting the endpoint
seems to be right. But I am not a programmer.

My black J-Link V3 (IAR OEM version) information from lsusb -vvv.
Bus 002 Device 010: ID 1366:0101
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x1366
  idProduct  0x0101
  bcdDevice0.01
  iManufacturer   1 SEGGER
  iProduct2 J-Link
  iSerial 3 123456
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Device Status: 0x0001
  Self Powered


>From my yellow J-LINK V6 (IAR OEM version)
Bus 002 Device 008: ID 1366:0101
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x1366
  idProduct  0x0101
  bcdDevice0.01
  iManufacturer   1 SEGGER
  iProduct2 J-Link
  iSerial 3 123456
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Device Status: 0x0001
  Self Powered



-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Gene Smith]

Xiaofan Chen wrote:
> On Mon, May 18, 2009 at 11:09 PM, Gene Smith  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 the segger utilities under Windows?

Will give it a try.

> 
> C:\Program Files\SEGGER\JLinkARM_V337a>jlink
> SEGGER J-Link Commander V3.37a ('?' for help)
> Compiled Aug  8 2006 19:16:44
> DLL version V3.37a, compiled Aug  8 2006 19:16:40
> Firmware: J-Link ARM V6 compiled Dec 03 2007 17:34:18
> Hardware: V6.00
> S/N : xx
> OEM : IAR
> ...
> 
>> WARNING: No matching core found. Selecting default core (ARM7)
>>
>> *** Error: could not read hardware status!
>> JTAG speed: 5 Hhz
>> J-Link>
>> Green LED goes off then *don't* see exactly what you see:
> 
> What does dmesg says when this happens? Something
> is wrong with your kernel or this particular version of J-Link.

The only thing I see with dmesg or tail -f /var/log/messages is this 
series of messages when I plug the usb into the yellow jlink. The LED 
blinks fast for about 30-45 seconds then goes solid when the last 
message appears:

May 19 09:20:20 localhost kernel: usb 5-1: USB disconnect, address 61
May 19 09:20:24 localhost kernel: usb 5-1: new full speed USB device 
using uhci_hcd and address 62
May 19 09:20:34 localhost kernel: usb 5-1: string descriptor 0 read 
error: -110
May 19 09:20:54 localhost kernel:last message repeated 2 times
May 19 09:20:54 localhost kernel: usb 5-1: configuration #1 chosen from 
1 choice
May 19 09:20:54 localhost kernel: usb 5-1: New USB device found, 
idVendor=1366, idProduct=0101
May 19 09:20:54 localhost kernel: usb 5-1: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3

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.

> 
>> My libusb on my fedora 8 is libusb-0.1.12-10.fc8. Do you think I might
>> need a newer libusb? That is the last version it updated to.
>>
> 
> That should be fine. libusb 0.1 has not changed for a while.
> 
> David Brownell is on this list and he is a prominent member of the
> Linux USB kernel team. So if there is a real USB/Kernel issue here,
> I think he can probably help you here. ;-)
> 
> 

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Gene Smith]

Benjamin Schmidt wrote:
> Does either rev 1833 or 1833 with my patch displaying something like this in 
> the beginning?
> 
> Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
> Info : JLink caps 0x3
> Info : JLink max mem block 32
> Info : Vref = 3.283 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 255

This is what I see with 1833 with your patch. It is some different that 
my original post of the reaction, but not sure if it is OK or not. Does 
this look correct?:

[g...@localhost src]$ sudo ./openocd -f target/interface/jlink.cfg -f 
target/board/iar_str712_sk1.cfg
Password:
Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:21) svn:1833M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://localhost:36903/openocd/trunk/src/openocd.c $
10 kHz
Info : J-Link compiled Dec  2 2004 09:13:33
Error: J-Link command EMU_CMD_GET_CAPS failed (-110)

Info : J-Link compiled Dec  2 2004 09:13:33
Error: J-Link command EMU_CMD_GET_CAPS failed (-110)

Info : J-Link compiled Dec  2 2004 09:13:33
Error: J-Link command EMU_CMD_GET_CAPS failed (-110)

Info : J-Link initial read failed, don't worry
Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive 
packet not sent! (9219). Workaround: increase "set remotetimeout" in GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive 
packet not sent! (3029). Workaround: increase "set remotetimeout" in GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: usb_bulk_read failed (requested=1, result=-110)
Warn : no telnet port specified, using default port 
Warn : no gdb port specified, using default port 
Warn : no tcl port specified, using default port 


> 
> The problem is that my old JLink uses a different USB endpoint, so if one 
> version succedes this simple output message, the other WILL fail because it 
> is 
> sending to a channel where the jlink doesn't answer at all
> 
> I only have access to a stm32 and an at91sam7s64 board
> 
> ./src/openocd -f ./src/target/interface/jlink.cfg -f 
> ./src/target/target/stm32.cfg
> That's how i call oocd atm...

Mine is about the same but I am using the file for str710 (but my board 
is str712 that I copied to target/board/iar_str712_sk1.cfg

> 
> With my patch I only get one Error: J-Link command EMU_CMD_VERSION failed 
> (-110) error in the beginning and every other 2 or 3 times it doesn't detect 
> the jlink at all, but if the JLink info message appeares, there's no more 
> errors...
> 
> Benjamin
> 
> 

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Gene Smith]

Benjamin Schmidt wrote:
> There's this segger closed source linux gdm server tool...
> 
> http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz
> 
> 
> 
> It can show the hardware version.
> 

Firmware not retrievable:

J-Link>f
Unable to retrieve firmware info !
J-Link>

But status and hwinfo read up (don't know if it is meaningful):

J-Link>st
VTarget=0.000V
ITarget=0mA
TCK=0 TDI=0 TDO=0 TMS=0 TRES=0 TRST=0
Supported JTAG speeds:
  - 16 MHz/n, (n>=4. => 4000kHz, 3200kHz, 2666kHz, ...
J-Link>

J-Link>hwinfo
HWInfo[00] = Target power is disabled
HWInfo[02] = 0mA(ITarget)
HWInfo[03] = 0mA(ITargetPeak)
HWInfo[04] = 0mA(ITargetPeakOperation)
HWInfo[05] = 0x
HWInfo[06] = 0x
HWInfo[07] = 0x
HWInfo[08] = 0x
HWInfo[09] = 0x
HWInfo[10] = 0ms(ITargetMaxTime0)
HWInfo[11] = 0ms(ITargetMaxTime1)
HWInfo[12] = 0ms(ITargetMaxTime2)
HWInfo[13] = 0x
HWInfo[14] = 0x
HWInfo[15] = 0x
HWInfo[16] = 0x
HWInfo[17] = 0x
HWInfo[18] = 0x
HWInfo[19] = 0x
HWInfo[20] = 0x
HWInfo[21] = 0x
HWInfo[22] = 0x
HWInfo[23] = 0x
HWInfo[24] = 0x
HWInfo[25] = 0x
HWInfo[26] = 0x
HWInfo[27] = 0x
HWInfo[28] = 0x
HWInfo[29] = 0x
HWInfo[30] = 0x
HWInfo[31] = 0x
J-Link>



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] pxa270.cfg patch

[Wookey]

+++ Ø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?

> W.r.t. reset capabilities then really for XScale it is probably better to
> stick with a dongle that can assert srst & trst separately.

Of course, but we have lots of legacy hardware here. The question is
is it _possible_ to use dumb parallel dongles via openOCD to reduce
the amount of config/code maintained?

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Balloon board config and some queries

[Wookey]

+++ Peter Korsgaard [2009-05-19 13:41 +0200]:
> > "Wookey" == Wookey   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 flash with kernel/root image now - should take 10 mins'
>  Wookey> so the user didn't think it had died.
> 
> Yes, just use echo "message"

OK. Great. (cheers peter)

But I failed to find any mention of that in 'General commands' in the
manual. And it's not listed in 'help' either. So attached is a patch
for the manual so that people have a fighting chance of discovering
it. (how many other secret commands are there I wonder :-) 

Loking at the source I see that ocd_find, echo and capture are all
registered with Jim_CreateCommand and have no help associated with
them because Jim_CreateCommand doesn't support that, whereas
register_command does. I'm not at all familar with this stuff so
hesitate to go fiddling where I don't understand.

But clearly having those commands appear in the help, along with some
explanation would be a useful improvement. And SFAICT neither capture
nor ocd_find appear in the manual either. I haven't added them as I
have no idea what they do.

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
--- openocd.texi~	2009-05-19 09:18:25.0 +0100
+++ openocd.texi	2009-05-19 13:22:55.0 +0100
@@ -2588,6 +2588,10 @@
 openocd -c "fast enable" -c "interface dummy" -f target/str710.cfg
 @end example
 
+...@subsection echo <@var{message}>
+...@cindex echo
+...@*output message to stdio. e.g. echo "Programming - please wait"
+
 @subsection log_output <@var{file}>
 @cindex log_output
 @*Redirect logging to  (default: stderr) 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] pxa270.cfg patch

[Spencer Oliver]

> This patch also lists the two CPU IDs I've found in testing. 
> This leads on to two related points about how the CPUTAPID 
> thing is used.
> 
> 1) How do I specify that a bit is don't care for 
> -expected-id? As you can see pxas can be (at least) rev 7 and 
> rev4: 0x79265013 and 0x49265013. Either of these answers is 
> valid, but I failed to find a 'don't care' mask.
> 

Just leave the -expected-id line out to not check the id
A better option would be to put multiple -expected-id cfgs.

Cheers
Spen

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] pxa270.cfg patch

[Øyvind Harboe]

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
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Balloon board config and some queries

[Peter Korsgaard]

> "Wookey" == Wookey   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 flash with kernel/root image now - should take 10 mins'
 Wookey> so the user didn't think it had died.

Yes, just use echo "message"

-- 
Bye, Peter Korsgaard
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] features for 0.2.0 [1 of 4]

[Raúl Sánchez Siles]

On Tuesday 19 May 2009 07:46:10 Zach Welch wrote:
> Hi all,
>
> I updated The List in r1828 (see the TODO file) to help prepare the
> OpenOCD project for its forthcoming 0.2.0 release.  Please review it to
> make sure that it contains the features that you want OpenOCD to have
> before it is "done" (not only for 0.2.0).  Please reply to this thread
> with patches or suggestions; other maintainers are welcome patch the
> file directly.
>
> OpenOCD Release 0.2.0: Feature Status Report
>

[...]

> - CFI driver chip/bus width issues (status??)
  I've just sent some patches addressing the issue, which is likely to be more 
about lack of the x16_as_x8 parameter implementation than any other chip/bus 
width real problem.

  I don't think the issue is very intrusive and I'd love having it available 
for 0.2.0 but it's not me who decides ;)

[...]

>
> Cheers,
>
> Zach Welch
> Corvallis, OR

  Regards,

-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Balloon board config and some queries

[Wookey]

As described on
http://www.balloonboard.org/balloonwiki/Balloon3OpenOCD I have working
configs for use with the balloon board and Olimex and Amontec JTAG
dongles. I won't copy them all into this message - look at that page
for the detailed file contents.

Putting this config into openOCD itself as board support seems
sensible. However there about a million ways of setting out these
config files, and proper paramerisation and having info reside at the
right levels is tricky. I partly adressed this in my pxa.cfg patch
mail (where should the reset config and CPUTAPID live), but here are
some other queries that arise.

I have top-level files for a port/dongle/interface-cabling/board
combination like this:
balloon3-cpu-olimex.cfg  (olimex dongle, pxa jtag port, full init)
balloon3-cpld-olimex.cfg (olimex dongle, cpld jtag port, xsvf-only init)
and then script files for uploading code:
loadloon.cfg  (load bootloader and kernel/initrd into NOR)
loadfpga.cfg  (load FPGA image into NOR)
loadcpld.cfg  (just play xsvf file)

The top-level files refer to:
base.cfg
.cfg (should be stock from openOCD)
pxa270.cfg (should be stock from openOCD, but currently isn't)
then specify 
* a CPUTAPID
* a reset config
* a NOR flash device
* initialisation of chain ready for programming

Things are complicated because we have build flavours with FPGA and
CPLD, and various dongle/interface arrangements to the CPU and
CPLD/FPGA which sometimes chain the JTAG ports and sometimes don't.

This seems to leave a choice between an awful lot of top-level files
(one for each combo of dongle/chaining) or loads of tiny little files
and a lot of knowledge required to know which set to select. I have
tried to find a happy medium here, and offer these files for
inclusion, but some of this stuff has wider implications for board
files in general I suspect so am happy to take suggestions about how
best to do this.

I also have some questions about how things currently work.

1) Is there a way to output a user message? Currently 
flash write_image erase kernel/zImageInitrd 0x20 bin
involves a 10-minute pause. It would be great if there was a way to
display
'programming flash with kernel/root image now - should take 10 mins'
so the user didn't think it had died.

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
just quietly use the defaults and save us all having to specify these
in thousands of config files? If not then having this 'base.cfg' for
such default info might be a good idea generally?

3) What's with the 'A' on the end of all the USB ft2232_device_desc
names?
Originally I had to change the Olimex.cfg file to a) have the correct
vip_pid numbers (now correct in svn) and b) remove the A, so it
worked. Now it seems that leaving the A in can work because OpenOCD
strings it off and tries without it, but it still seems confusing.
Shouldn't the config file not have this info and it gets added on and
checked for in the strange Windows case where apparently it is needed?

4) When running correctly I get a lot of grumbling which I don't
understand how to fix:
tap creation outputs:
-
Info : JTAG tap: pxa270.cpu tap/device found: 0x49265013 (Manufacturer: 0x009, 
Part: 0x9265, Version: 0x4)
Info : JTAG Tap/device matched
-

so that's OK, but then 'reset halt' gives:
-
Info : JTAG tap: pxa270.cpu tap/device found: 0x49265013 (Manufacturer: 0x009, 
Part: 0x9265, Version: 0x4)
Info : JTAG Tap/device matched
Warn : TAP pxa270.cpu:
Warn : value captured during scan didn't pass the requested check:
Warn : captured: 0x00 check_value: 0x02 check_mask: 0x07
Warn : in_handler: w/o "in_value", mismatch in SDR
Error: JTAG error while writing DCSR
Warn : TAP pxa270.cpu:
Warn : value captured during scan didn't pass the requested check:
Warn : captured: 0x00 check_value: 0x01 check_mask: 0x7F
Warn : in_handler: w/o "in_value", mismatch in SIR
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x58d3 pc: 0x
MMU: disabled, D-Cache: disabled, I-Cache: disabled
(processor reset)

What are the 'requested checks' referred-to? What should I specify
where to stop it whinging? 

erm. There is probably more but that'll do for now :-)

I hope this stuff is useful.

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] parallel port reset config with xscale

[Igor Skochinsky]

Hi,

On Tue, May 19, 2009 at 12:43, Wookey  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 parallel dongles?
> Perhaps emitting a 'hit reset manually' message? Would that help?
>
> If there is then I'll finish adding support for the lart/jtux device
> and send it in, but currently I'm stuck.
jflash/bflash and such use boundary scan to toggle pins connected to
flash chips and program them. AFAIK OpenOCD does not have that
ability, it can only use CPU debug mode to access the memory (and thus
the flash). XScale is rather tricky to get into debug as it needs some
fine timing with srst and trst signals. So I don't think you can get
your "dumb" dongles to work without adding boundary scan option to
OpenOCD.
I once had to dump a flash from a PXA270 board with a simple 4-wire
adapter and was not able to make OpenOCD work. In the end I hacked
bflash (I think) to do it with boundary scan (slw but hey, it
worked).
Another option is [X]SVF files. I don't know much about them, but I
think they can be used to program flash via boundary scan too.

-- 
WBR, Igor
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] pxa270.cfg patch

[Wookey]

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, queries and patches as a result. I'll try to
separate them by subject rather than one big mail. 

first nice simple one. The pxa270.cfg is wrong. When I started it
still had old-style config lines but it looks likes that's been fixed
in svn. It still has a line for a flash chip on some random board
which clearly shouldn't be in the generic pxa270.cfg file, so my patch
removes it. That should be in the board config.

This patch also lists the two CPU IDs I've found in testing. This leads
on to two related points about how the CPUTAPID thing is used.

1) How do I specify that a bit is don't care for -expected-id? As you
can see pxas can be (at least) rev 7 and rev4: 0x79265013 and
0x49265013. Either of these answers is valid, but I failed to find a
'don't care' mask.

2) Also the .cfg files set a duff CPUTAPID, and seem to expect a
CPUTAPID to be passed in from some higher-level config. But it seems
to me that in general the user doesn't know this value and would
expect it (or at least the default) to be supplied in the .cfg
file? Am I misunderstanding how it is supposed to be used?

3) Also doesn't the reset capability depend on the
board/dongle/interface combination and thus sadly doesn't really go in
the cpu config file, much as we'd like it to? e.g. I get different
reset capabilities with USB and parallel dongles onto the same board,
so a generic pxa reset config cannot be correct. Perhaps the idea is
that the file specifies a likely default and that is overridden later
in the main config if it's not right for you?



--- /home/wookey/balloon/openocd/svn/trunk/src/target/target/pxa270.cfg 
2009-05-13 02:41:22.0 +0100
+++ 
/home/wookey/balloon/loontest/balloonsvn/trunk/utils/openocd/r1409/pxa270.cfg   
2009-05-19 09:24:30.0 +0100
@@ -12,6 +12,9 @@
set  _ENDIAN little
 }
 
+#IDs for pxa270. Choose one. Are there others?#
+#set CPUTAPID 0x79265013
+#set CPUTAPID 0x49265013
 if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
 } else {
@@ -26,10 +29,6 @@
 # set the jtag_ntrst_delay to the delay introduced by a reset circuit
 # the rest of the needed delays are built into the openocd program
 jtag_ntrst_delay 0
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst separate
-#jtag scan chain
-
 
 set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
 jtag newtap $_CHIPNAME cpu -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id 
$_CPUTAPID
@@ -38,7 +37,3 @@
 # maps to PXA internal RAM. If you are using a PXA255
 # you must initialize SDRAM or leave this option off
 $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x5c00 
-work-area-size 0x1 -work-area-backup 0
-
-#flash bank 
-# works for P30 flash
-flash bank cfi 0x 0x100 2 4 0


Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [RFC][PATCH] [4/4] x16_as_x8 tentative implementation.

[Raúl Sánchez Siles]

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 touch just src/flash/cfi.c file and should apply in this order
> to trunk.
>
>   The patchset consists of 4 patches, whose interest areas I
> explain and comment below:
>

> 04-x16_as_x8-multibyte_read
>   · cfi_query_u16 and cfi_query_u32 function uses multibyte accesses, this
> is 2 or 4 byte read. This will fail in the x16_as_x8 case since this would
> lead reading, e.g.: addresses 0x0 and 0x1 instead of 0x0 and 0x2 in the
> 16bit case. Do a byte by byte read in the x16_as_x8 case.

-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01


--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -222,9 +242,18 @@
 static u16 cfi_query_u16(flash_bank_t *bank, int sector, u32 offset)
 {
 	target_t *target = bank->target;
+	cfi_flash_bank_t *cfi_info = bank->driver_priv;
 	u8 data[CFI_MAX_BUS_WIDTH * 2];
 
-	target->type->read_memory(target, flash_address(bank, sector, offset), bank->bus_width, 2, data);
+	if(cfi_info->x16_as_x8)
+	{
+		u8 i;
+		for(i=0;i<2;i++)
+			target->type->read_memory(target, command_address(bank, sector, offset+i), bank->bus_width, 1,
+&data[i*bank->bus_width] );
+	}
+	else
+		target->type->read_memory(target, flash_address(bank, sector, offset), bank->bus_width, 2, data);
 
 	if (bank->target->endianness == TARGET_LITTLE_ENDIAN)
 		return data[0] | data[bank->bus_width] << 8;
@@ -235,9 +264,18 @@
 static u32 cfi_query_u32(flash_bank_t *bank, int sector, u32 offset)
 {
 	target_t *target = bank->target;
+	cfi_flash_bank_t *cfi_info = bank->driver_priv;
 	u8 data[CFI_MAX_BUS_WIDTH * 4];
 
-	target->type->read_memory(target, flash_address(bank, sector, offset), bank->bus_width, 4, data);
+	if(cfi_info->x16_as_x8)
+	{
+		u8 i;
+		for(i=0;i<4;i++)
+			target->type->read_memory(target, command_address(bank, sector, offset+i), bank->bus_width, 1,
+&data[i*bank->bus_width] );
+	}
+	else
+		target->type->read_memory(target, flash_address(bank, sector, offset), bank->bus_width, 4, data);
 
 	if (bank->target->endianness == TARGET_LITTLE_ENDIAN)
 		return data[0] | data[bank->bus_width] << 8 | data[bank->bus_width * 2] << 16 | data[bank->bus_width * 3] << 24;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [RFC][PATCH] [3/4] x16_as_x8 tentative implementation.

[Raúl Sánchez Siles]

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 touch just src/flash/cfi.c file and should apply in this order
> to trunk.
>
>   The patchset consists of 4 patches, whose interest areas I
> explain and comment below:
>
> 03-x16_as_x8-command_address-subst
>   · Substitution of flash_address function for command_address function,
> except on code specific to intel. I have just focused on spansion flashes
> and I hadn't review intel flash specifications, so I decided to be
> conservative at first. Maybe someone can tell if the command_address
> function is also valid for intel chips. If so this patch could be grown to
> include those or eventually include the x16_as_x8 functionality into
> flash_address not needing this one.
>

-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01


--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -182,7 +182,7 @@
 	target_t *target = bank->target;
 	u8 data[CFI_MAX_BUS_WIDTH];
 
-	target->type->read_memory(target, flash_address(bank, sector, offset), bank->bus_width, 1, data);
+	target->type->read_memory(target, command_address(bank, sector, offset), bank->bus_width, 1, data);
 
 	if (bank->target->endianness == TARGET_LITTLE_ENDIAN)
 		return data[0];
@@ -200,7 +200,7 @@
 	u8 data[CFI_MAX_BUS_WIDTH];
 	int i;
 
-	target->type->read_memory(target, flash_address(bank, sector, offset), bank->bus_width, 1, data);
+	target->type->read_memory(target, command_address(bank, sector, offset), bank->bus_width, 1, data);
 
 	if (bank->target->endianness == TARGET_LITTLE_ENDIAN)
 	{
@@ -417,7 +417,7 @@
 	if ((pri_ext->pri[0] != 'P') || (pri_ext->pri[1] != 'R') || (pri_ext->pri[2] != 'I'))
 	{
 		cfi_command(bank, 0xf0, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, 0, 0x0), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, 0, 0x0), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
@@ -490,7 +490,7 @@
 	if ((atmel_pri_ext.pri[0] != 'P') || (atmel_pri_ext.pri[1] != 'R') || (atmel_pri_ext.pri[2] != 'I'))
 	{
 		cfi_command(bank, 0xf0, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, 0, 0x0), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, 0, 0x0), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
@@ -729,37 +729,37 @@
 	for (i = first; i <= last; i++)
 	{
 		cfi_command(bank, 0xaa, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, 0, pri_ext->_unlock1), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, 0, pri_ext->_unlock1), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
 
 		cfi_command(bank, 0x55, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, 0, pri_ext->_unlock2), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, 0, pri_ext->_unlock2), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
 
 		cfi_command(bank, 0x80, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, 0, pri_ext->_unlock1), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, 0, pri_ext->_unlock1), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
 
 		cfi_command(bank, 0xaa, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, 0, pri_ext->_unlock1), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, 0, pri_ext->_unlock1), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
 
 		cfi_command(bank, 0x55, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, 0, pri_ext->_unlock2), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, 0, pri_ext->_unlock2), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
 
 		cfi_command(bank, 0x30, command);
-		if((retval = target->type->write_memory(target, flash_address(bank, i, 0x0), bank->bus_width, 1, command)) != ERROR_OK)
+		if((retval = target->type->write_memory(target, command_address(bank, i, 0x0), bank->bus_width, 1, command)) != ERROR_OK)
 		{
 			return retval;
 		}
@@ -769,7 +769,7 @@
 		else
 		{
 			cfi_command(bank, 0xf0, command);
-			if((retval = target->type->write_memory

Re: [Openocd-development] [RFC][PATCH] [2/4] x16_as_x8 tentative implementation.

[Raúl Sánchez Siles]

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 touch just src/flash/cfi.c file and should apply in this order
> to trunk.
>
>   The patchset consists of 4 patches, whose interest areas I
> explain and comment below:
>
> 02-x16_as_x8-command_address
>   · Creation of a command_address function intended as flash addresses
> arranger depending on the x16_as_x8 parameter existence or not. This is
> basically an override of flash_address function, only that takes into
> account the x16_as_x8 parameter. The other options for this functionality
> would be adding an additional parameter to flash_address function or, if it
> is shown that it is an equivalent of flash_address, include x16_as_x8
> functionality into flash_address.
>

-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01


--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -127,6 +127,26 @@
 
 }
 
+/* inline u32 command_address(flash_bank_t *bank, int sector, u32 offset) */
+static __inline__ u32 command_address(flash_bank_t *bank, int sector, u32 offset)
+{
+	cfi_flash_bank_t *cfi_info = bank->driver_priv;
+
+	/* while the sector list isn't built, only accesses to sector 0 work */
+	if (sector == 0)
+		return bank->base + (offset * bank->bus_width << cfi_info->x16_as_x8 );
+	else
+	{
+		if (!bank->sectors)
+		{
+			LOG_ERROR("BUG: sector list not yet built");
+			exit(-1);
+		}
+		return bank->base + bank->sectors[sector].offset + (offset * bank->bus_width << cfi_info->x16_as_x8 );
+	}
+
+}
+
 static void cfi_command(flash_bank_t *bank, u8 cmd, u8 *cmd_buf)
 {
 	int i;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [RFC][PATCH] [1/4] x16_as_x8 tentative implementation.

[Raúl Sánchez Siles]

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 touch just src/flash/cfi.c file and should apply in this order
> to trunk.
>
>   The patchset consists of 4 patches, whose interest areas I
> explain and comment below:
>
> 01-x16_as_x8-consolidate_addresses
>   · Manufacturer and device id retrieval in cfi_probe function weren't
> using the generic flash_address. Use it there.

-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01


--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -2129,11 +2129,11 @@
 	if (bank->chip_width == 1)
 	{
 		u8 manufacturer, device_id;
-		if((retval = target_read_u8(target, bank->base + 0x0, &manufacturer)) != ERROR_OK)
+		if((retval = target_read_u8(target, flash_address(bank, 0, 0x00), &manufacturer)) != ERROR_OK)
 		{
 			return retval;
 		}
-		if((retval = target_read_u8(target, bank->base + 0x1, &device_id)) != ERROR_OK)
+		if((retval = target_read_u8(target, flash_address(bank, 0, 0x01), &device_id)) != ERROR_OK)
 		{
 			return retval;
 		}
@@ -2142,11 +2142,11 @@
 	}
 	else if (bank->chip_width == 2)
 	{
-		if((retval = target_read_u16(target, bank->base + 0x0, &cfi_info->manufacturer)) != ERROR_OK)
+		if((retval = target_read_u16(target, flash_address(bank, 0, 0x00), &cfi_info->manufacturer)) != ERROR_OK)
 		{
 			return retval;
 		}
-		if((retval = target_read_u16(target, bank->base + 0x2, &cfi_info->device_id)) != ERROR_OK)
+		if((retval = target_read_u16(target, flash_address(bank, 0, 0x02), &cfi_info->device_id)) != ERROR_OK)
 		{
 			return retval;
 		}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [RFC][PATCH] [0/4] x16_as_x8 tentative implementation.

[Raúl Sánchez Siles]

  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 order to 
trunk.

  The patchset consists of 4 patches, whose interest areas I 
explain and comment below:

01-x16_as_x8-consolidate_addresses
  · Manufacturer and device id retrieval in cfi_probe function weren't using 
the generic flash_address. Use it there.

02-x16_as_x8-command_address
  · Creation of a command_address function intended as flash addresses arranger 
depending on the x16_as_x8 parameter existence or not. This is basically an 
override of flash_address function, only that takes into account the x16_as_x8 
parameter. The other options for this functionality would be adding an 
additional parameter to flash_address function or, if it is shown that it is an 
equivalent of flash_address, include x16_as_x8 functionality into flash_address.

03-x16_as_x8-command_address-subst
  · Substitution of flash_address function for command_address function, except 
on code specific to intel. I have just focused on spansion flashes and I hadn't 
review intel flash specifications, so I decided to be conservative at first. 
Maybe someone can tell if the command_address function is also valid for intel 
chips. If so this patch could be grown to include those or eventually include 
the x16_as_x8 functionality into flash_address not needing this one.

04-x16_as_x8-multibyte_read
  · cfi_query_u16 and cfi_query_u32 function uses multibyte accesses, this is 2 
or 4 byte read. This will fail in the x16_as_x8 case since this would lead 
reading, e.g.: addresses 0x0 and 0x1 instead of 0x0 and 0x2 in the 16bit case. 
Do a byte by byte read in the x16_as_x8 case.

  Regards,

-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] parallel port reset config with xscale

[Wookey]

I now have working openOCD with Olimex and Amontec USB based dongles. 
It would be nice to get our old parallel port dongles working too so
that I can throw away a lot of legacy code (jflash and bflash (which
was an attempt to do something with similar flexibility to openOCD but
only addressed boundary-scan)), and use openOCD for everything.

However. Parallel port dongles like the xilinx-alike DLC5 and the
LART/JTUX adaptor (both listed here:
http://www.balloonboard.org/balloonwiki/BalloonJTAGing )
are very dim and don't control the reset lines themselves.

So far as I can tell this makes such devices impossible to use with
openOCD, but I must be missing something as support for such things is
there. 
I use this config (expanding source [find ...]  lines for clarity)

---
jtag_khz 100

#'aleph1/xilinx' dongle
interface parport
parport_port /dev/parport0
parport_cable dlc5

set CPUTAPID 0x49265013
source [find pxa270.cfg]

reset_config none
# 29LV650 64Mbit Flash
flash bank cfi 0x 0x80 2 2 0

init
-

And that does the boundary-scan OK, but 'reset halt' fails (not
suprisingly as it's has no control of the reset lines) and so far as I
can tell I can't go on to do _anything_ else without getting the CPU
into state halt.

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 parallel dongles?
Perhaps emitting a 'hit reset manually' message? Would that help? 

If there is then I'll finish adding support for the lart/jtux device
and send it in, but currently I'm stuck.

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Benjamin Schmidt]

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 command.
So I switched to "EMU_CMD_HW_JTAG2"
I'ts all the same with the exception of the 0-Read for success.
With that my JLink works with at least with AT91SAM7S and STM32

Benjamin

On Tuesday 19 May 2009 10:53:28 am 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
> Magnus

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] testing tools [4 of 4]

[Duane Ellis]

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 private ISP (ie: at home)

-Duane.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch] NAND: update ids, "nand list" bugfix

[Øyvind Harboe]

Committed.

Thanks!

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Zach Welch]

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 would prefer it to be '#if 0'd out or moved to a function.
Once we have version detection, we can put it back into the flow.

> This should improve the situation.

Despite the above, I am following this thread and curious about the
success with older versions, so please continue testing this.  I like to
see this progress and hope to make some time of my own to contribute
this week.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD and different versions of J-Link

[Magnus Lundin]

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
===
--- src/jtag/jlink.c	(revision 1834)
+++ src/jtag/jlink.c	(working copy)
@@ -36,9 +36,12 @@
 #define JLINK_WRITE_ENDPOINT	0x02
 #define JLINK_READ_ENDPOINT		0x81
 
+unsigned int jlink_write_ep = JLINK_WRITE_ENDPOINT;
+unsigned int jlink_read_ep = JLINK_READ_ENDPOINT;
+
 #define JLINK_USB_TIMEOUT		1000
 
-// See Section 1.3.2 of the Segger JLink USB protocol manual
+/* See Section 1.3.2 of the Segger JLink USB protocol manual */
 /* 2048 is the max value we can use here */
 //#define JLINK_TAP_BUFFER_SIZE 2048
 #define JLINK_TAP_BUFFER_SIZE 256
@@ -543,7 +546,7 @@
 {
 	int result;
 	int len;
-	u32 jlink_caps, jlink_max_size;
+	u32 jlink_caps;
 
 	/* query hardware version */
 	jlink_simple_command(EMU_CMD_VERSION);
@@ -579,21 +582,6 @@
 	jlink_caps = buf_get_u32(usb_in_buffer, 0, 32);
 	LOG_INFO("JLink caps 0x%x", jlink_caps);
 
-
-	/* query hardware maximum memory block */
-	jlink_simple_command(EMU_CMD_GET_MAX_MEM_BLOCK);
-
-	result = jlink_usb_read(jlink_jtag_handle, 4);
-	if (4 != result)
-	{
-		LOG_ERROR("J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (%d)\n", result);
-		return ERROR_JTAG_DEVICE_ERROR;
-	}
-
-	jlink_max_size = buf_get_u32(usb_in_buffer, 0, 32);
-	LOG_INFO("JLink max mem block %i", jlink_max_size);
-
-
 	return ERROR_OK;
 }
 
@@ -661,7 +649,7 @@
 	int bit_index = tap_length % 8;
 	u8 bit = 1 << bit_index;
 
-	// we do not pad TMS, so be sure to initialize all bits
+	/* we do not pad TMS, so be sure to initialize all bits */
 	if (0 == bit_index)
 	{
 		tms_buffer[index] = tdi_buffer[index] = 0;
@@ -814,6 +802,24 @@
  */
 usb_set_altinterface(result->usb_handle, 0);
 #endif
+int i;
+for (i =0 ; iconfig[0].interface[0].altsetting[0].bNumEndpoints; i++)
+{
+	u8 epnum = dev->config[0].interface[0].altsetting[0].endpoint[i].bEndpointAddress;
+	{		
+		if (epnum&0x80)
+		{ 
+			LOG_DEBUG("usb ep in %02x",epnum);
+			jlink_read_ep = epnum;
+		}
+		else
+		{
+			LOG_DEBUG("usb ep out %02x",epnum);
+			jlink_write_ep = epnum;
+		}
+	}
+}
+
 return result;
 			}
 		}
@@ -937,7 +943,7 @@
 		return -1;
 	}
 
-	result = usb_bulk_write_ex(jlink_jtag->usb_handle, JLINK_WRITE_ENDPOINT,
+	result = usb_bulk_write_ex(jlink_jtag->usb_handle, jlink_write_ep,
 		(char *)usb_out_buffer, out_length, JLINK_USB_TIMEOUT);
 
 	DEBUG_JTAG_IO("jlink_usb_write, out_length = %d, result = %d", out_length, result);
@@ -951,7 +957,7 @@
 /* Read data from USB into in_buffer. */
 static int jlink_usb_read(jlink_jtag_t *jlink_jtag, int expected_size)
 {
-	int result = usb_bulk_read_ex(jlink_jtag->usb_handle, JLINK_READ_ENDPOINT,
+	int result = usb_bulk_read_ex(jlink_jtag->usb_handle, jlink_read_ep,
 		(char *)usb_in_buffer, expected_size, JLINK_USB_TIMEOUT);
 
 	DEBUG_JTAG_IO("jlink_usb_read, result = %d", result);
@@ -965,7 +971,7 @@
 /* Read the result from the previous EMU cmd into result_buffer. */
 static int jlink_usb_read_emu_result(jlink_jtag_t *jlink_jtag)
 {
-	int result = usb_bulk_read_ex(jlink_jtag->usb_handle, JLINK_READ_ENDPOINT,
+	int result = usb_bulk_read_ex(jlink_jtag->usb_handle, jlink_read_ep,
 		(char *)usb_emu_result_buffer, 1 /* JLINK_EMU_RESULT_BUFFER_SIZE */,
 		JLINK_USB_TIMEOUT);
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] Further simplifications in jtag.c

[Michael Bruck]

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 take some
input fields and produce from that a new set of output fields. The
patch sets the stage to later be able to use a local variable 'field'
or 'fields' to refer to fields rather then the current endless
repetitions of cmd->cmd.scan->fields[...] while at the same time
making it clear which one is the input argument and which is the
output data.

patch 02 renames a local variable 'x' into 'num_taps' to describe what it means

patches 03-10
add a local variable 'scan_command_t * scan' to the functions to
replace lengthy 'cmd->cmd.scan' with 'scan' to make the code more
readable
and move scan_size and a few loop variables into the local scope where
they are actually used thus reducing clutter and potential for error.

The patch files include a short commit message.

Again none of these patches change any algorithm. They are all tested
here and compile and run on arm11 (although not all of these functions
are used in arm11).

Michael
commit 7130b09dfccb1d93d68ae828e630fda3532f7bc9
Author: Michael Bruck 
Date:   Sun May 17 13:44:44 2009 +0200

- rename input parameters 'num_fields' and 'fields' to 'in_num_fields' and 
'in_fields' in all jtag.c interface functions

diff --git a/src/jtag/jtag.c b/src/jtag/jtag.c
index 4a11658..a4f5d51 100644
--- a/src/jtag/jtag.c
+++ b/src/jtag/jtag.c
@@ -37,8 +37,8 @@
 
 int jtag_flush_queue_count; /* count # of flushes for profiling / debugging 
purposes */
 
-static void jtag_add_scan_check(void (*jtag_add_scan)(int num_fields, 
scan_field_t *fields, tap_state_t state),
-   int num_fields, scan_field_t *fields, tap_state_t state);
+static void jtag_add_scan_check(void (*jtag_add_scan)(int in_num_fields, 
scan_field_t *in_fields, tap_state_t state),
+   int in_num_fields, scan_field_t *in_fields, tap_state_t state);
 
 /* note that this is not marked as static as it must be available from outside 
jtag.c for those
that implement the jtag_xxx() minidriver layer
@@ -554,45 +554,44 @@ static void jtag_prelude(tap_state_t state)
cmd_queue_cur_state = cmd_queue_end_state;
 }
 
-void jtag_add_ir_scan_noverify(int num_fields, scan_field_t *fields, 
tap_state_t state)
+void jtag_add_ir_scan_noverify(int in_num_fields, scan_field_t *in_fields, 
tap_state_t state)
 {
int retval;
jtag_prelude(state);
 
-   retval=interface_jtag_add_ir_scan(num_fields, fields, 
cmd_queue_end_state);
+   retval=interface_jtag_add_ir_scan(in_num_fields, in_fields, 
cmd_queue_end_state);
if (retval!=ERROR_OK)
jtag_error=retval;
 
 }
 
 
-void jtag_add_ir_scan(int num_fields, scan_field_t *fields, tap_state_t state)
+void jtag_add_ir_scan(int in_num_fields, scan_field_t *in_fields, tap_state_t 
state)
 {
if (jtag_verify&&jtag_verify_capture_ir)
{
/* 8 x 32 bit id's is enough for all invoations */
-   int j;
-   for (j = 0; j < num_fields; j++)
+
+   for (int j = 0; j < in_num_fields; j++)
{
-   fields[j].check_value=NULL;
-   fields[j].check_mask=NULL;
+   in_fields[j].check_value=NULL;
+   in_fields[j].check_mask=NULL;
/* if we are to run a verification of the ir scan, we 
need to get the input back.
 * We may have to allocate space if the caller didn't 
ask for the input back.
 */
-   fields[j].check_value=fields[j].tap->expected;
-   fields[j].check_mask=fields[j].tap->expected_mask;
+   in_fields[j].check_value=in_fields[j].tap->expected;
+   in_fields[j].check_mask=in_fields[j].tap->expected_mask;
}
-   jtag_add_scan_check(jtag_add_ir_scan_noverify, num_fields, 
fields, state);
+   jtag_add_scan_check(jtag_add_ir_scan_noverify, in_num_fields, 
in_fields, state);
} else
{
-   jtag_add_ir_scan_noverify(num_fields, fields, state);
+   jtag_add_ir_scan_noverify(in_num_fields, in_fields, state);
}
 }
 
-int MINIDRIVER(interface_jtag_add_ir_scan)(int num_fields, scan_field_t 
*fields, tap_state_t state)
+int MINIDRIVER(interface_jtag_add_ir_scan)(int in_num_fields, scan_field_t 
*in_fields, tap_state_t state)
 {
jtag_tap_t *tap;
-   int j;
int x;
int nth_tap;
int scan_size = 0;
@@ -632,13 +631,13 @@ int MINIDRIVER(interface_jtag_add_ir_scan)(int 
num_fields, scan_field_t *fields,
cmd->cmd.scan->fields[nth_tap].in_value = NULL; /* do not 
collect input for tap's in bypass */
 

Re: [Openocd-development] "Short" state table enabled as of r1827

[Magnus Lundin]

Øyvind Harboe wrote:
> On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver  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 short table as default.
>>>
>>> Try:
>>>
>>> tms_sequence long
>>> tms_sequence short
>>>
>>>   
>> Just checked with a luminary target i had to hand.
>> Using tms_sequence long fixes the error's seen during the first
>> jtag_examine_chain call.
>> 
>
> Could this be a missing jtag_add_pathmove()?
>
> 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 from TAP_RESET 
to the long version. This will not affect performance but give some 
extra tck clocks in reset.
Some target really like that.

Have a nice day
Magnus


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] milestone strategy [3 of 4]

[Xiaofan Chen]

On Tue, May 19, 2009 at 2:55 PM, Nico Coesel  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 0.1 (latest is 0.1.12) and that does not
prevent it from widely used, including being used by OpenOCD. ;-)
usbutils (lsusb) is again always below 1.0.

And version 8 (>>1) might scare people away actually. ;-)
Just kidding.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch] NAND: update ids, "nand list" bugfix

[David Brownell]

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
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] testing tools [4 of 4]

[Paul Thomas]

On Mon, May 18, 2009 at 10:49 PM, Zach Welch  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 replace the static developer table that I was using
> to augment The List.  I think most of what I am doing will need to be
> rewritten in SQL to scale up, but I wanted the first draft to avoid any
> serious external dependencies (e.g. a SQL engine).
>
> These scripts work on plain text table files: one line per row, '\t'
> delimits the columns.   The 'tool.pl' script can be used to manipulate
> the data from the shell (or other non-Perl scripts), and the 'html.pl'
> script can convert the data into cross-linked static HTML pages.  Both
> use the included 'Tables.pm', which I whipped together this weekend for
> this purpose.
>
> 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 "user",
> along with the 'version' of OpenOCD, the test 'results', along with a
> 'comment'.  In this description, words in double-quotes ('"')
> effectively describe various primary tables, while the words in
> single-quotes ("'") describe column fields.
>
> Similarly, each user may specify a list of devices that they can use for
> testing, so specific users may be prompted for testing particular
> configurations.  This last feature also allows me to create a developer
> roster that improves on the one that I had been tracking in The List
> (until r1828).
>
> Presently, this user-tracking half is (all but) complete, since that was
> the reason I started this work.  The reporting then builds on it; users
> with one platform, interface and target should not be made to specify
> these parameters repeatedly when they will be contributing a single
> time-series of data points.
>
> Known problems:
> - I have tried to KISS, so there are going to be definite limits.
> - Additional database design work needs to be done.
> - Static output only.
> - Missing an 'email.pl' script to provide a gateway from e-mail messages
> sent by the automated tester.
> - Automated tester does not report PASS/FAIL and send e-mails.
>
> I will try to post my initial implementation in the next day or two, but
> I am curious what others think of this approach.
>
> Cheers,
>
> Zach Welch
> Corvallis, OR
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>

I think that would be great. As a user what is our interface to this? Do we
just send an email with lines in the specified format? I haven't used the
regression test suite so maybe that would explain this some.

One way to aggregate the data would be to create a web form that users could
fill out manually, but also have another perl script in the test suite that
could automatically fill out the form. The most elegant way would be to tie
the form directly to the SQL database, but for something quick & dirty we
could just use a google form like this: (
https://spreadsheets.google.com/viewform?formkey=cnpOSWRCcE9DRjl1a3E5NURnUFQ4Rnc6MA..),
and then pull a csv file of the data when we wanted to. Just a thought. I
know some PERL & SQL so I'm willing to help out.

thanks,
Paul
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch] NAND: update ids, "nand list" bugfix

[Øyvind Harboe]

On Mon, May 18, 2009 at 10:05 PM, David Brownell  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
>   the 256-byte pages.
>
>  - Recognize Micron as a NAND manufacturer.
>
>  - For "nand list", part numbers are the same whether or not the
>   part has been probed yet.

I don't know anything about nand, but I'll be happy to commit this if
you believe
the chances of regressions are slight.

The chances that anyone else will review your changes are small I guess.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] "Short" state table enabled as of r1827

[Øyvind Harboe]

On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver  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 short table as default.
>>
>> Try:
>>
>> tms_sequence long
>> tms_sequence short
>>
>
> Just checked with a luminary target i had to hand.
> Using tms_sequence long fixes the error's seen during the first
> jtag_examine_chain call.

Could this be a missing jtag_add_pathmove()?

We want to make OpenOCD robust against the particular path taken do we not?


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development